迪森实施项目的经验与大家分享，文字较长......

值得耐心阅读，相信会收获颇多！

​

根据国外研究表明，SAP系统在长期运行后，对于企业战略及卓越运营的支撑能力在逐步降低，其中七年是一个拐点。造成这一问题的原因很多：技术架构、解决方案、数据、硬件、运维、业务及组织的变革、IT组织架构……

 

正是在这样背景下，许多公司都在进行SAP系统的优化实施工作，而优化项目不同于新的实施项目，在需求分析、方案设计、系统测试、数据切换等阶段都有着许多需要特别关注的地方，以下以一个实际优化项目为例深度剖析。

 

▼背景介绍：这是一家通过经销商或卖场将产品卖到到最终消费者的企业，因此对经销商的信用、返利的管控有很高的要求。七、八年前首次实施SAP，并通过标准功能和自开发结合实现了信用、返利的管理。但随着市场的发展和内控的需要，迫切需要对目前信用返利管理应用进行优化完善。

 

 

还原需求本质

▼项目启动后，首先开始需求调研分析。经过几轮调研下来，第一个问题来了，之前客户提到的按品类进行额度授信的真正需求并不是为了区分授信，而是在授信额度中对某些品类的产品有销量要求，例如在给客户授信100万时，客户如果想用完这100万额度，至少要买8万的某类产品。

 

从业务实质需求来看，这是考虑到季节原因，希望某类产品多卖，而信用管控不是控制在额度范围内卖吗？这不是矛盾的吗？

 

既然是优化，先看看之前方案是怎样做的，客户希望优化的点是什么。

 

经过进一步分析发现，之前系统中将此100万授信分成了92万和8万两部分额度，客户授信92万可以买所有产品，然后给该客户再创建一个相应的专用产品客户（只能购买专用产品），该专用产品客户的额度为8万，这样这个客户如果想用满100万，必须用这两个客户下单，通过专用产品客户用满8万额度，实现100万额度用完至少满够8万专用产品的目的。

 

显然一个客户在系统中要对应创建一个专用产品客户，如果以后有多个专用产品要进行这样信用管理，一个客户将会有多个对应的专用产品客户，未来无论是给经销商还是给公司客户管理都带来巨大困难，因此，迫切需要改变这种专用产品客户的做法。

 

从大的思路上来看，之前将100万分成92万和8万两部分信用额度的做法还是很巧妙的，按照这个思路，只需设置专用产品信控范围对应销售范围取代专用产品客户就可以了，8万额度设在专用产品信控范围下，取消专用产品客户。其余就是考虑新的销售范围、信控范围带来的影响分析及应对等等。

 

总结：分析需求时一定要搞清背后的实质业务需求，充分分析现有方案，确定最终优化点，同时，可借鉴现有方案思路制定优化方案。

 

▼很快，第二个问题来了，客户返利管理的复杂度超出预期。首先客户有多种返利模式，在系统中针对不同类型的返利业务有不同的TCODE（事务代码）进行处理。现有方案针对返利是通过生成特定预收款凭证来增加信用额度的。

 

本次项目的优化需求就是要取消生成凭证的做法，因此，首先要搞清楚哪些业务和应用涉及这部分处理。虽然通过与主要业务人员调研基本理清了主要的业务场景和类型，但是等上线后，由于后台关闭了生成这类预收款凭证的设置，上线当天突然有用户反映有些返利业务做不了了，经进一步了解，才发现有些业务涉及其它部门和人员，调研时没有考虑到，要不是把系统后门关了，是很难及时发现这些当初没纳入项目范围的业务的。

 

 

总结：优化项目的客户往往上线应用了比较长的时间，涉及的业务、应用和人员比较多，往往一个业务部门和人员很难把所有业务讲清楚，一个IT人员也很难把所有相关的应用和程序讲清楚，因此，调研分析时不能局限于某些主要业务部门和人员，要系统、全面地对业务和IT现状进行梳理分析。

 

另外，优化项目中客户提的需求大部分都是之前已经有方案实现的需求，只是方案需要优化，因此，当客户提出一个需求的时候，不能习惯思维地想成是新需求，按照新需求的套路走，而要多问多了解该需求目前是否有实现，实现的方案是怎样的。

 

 

探寻解决方案之道

▼如同大多客户一样，由于人员频繁流动、文档管理不善，留下来可供项目组参考的文档很有限，没办法通过文档对整个方案和具体技术细节快速了解，只能根据业务理解看程序代码了。

 

首先看返利导入，这是源头，通过搜索生成会计凭证的BAPI自然就找到了这段代码，如同黑箱子，这段代码的输入、输出要保留，黑箱里的凭证处理逻辑替换掉，只是输入输出有点复杂，需要花时间慢慢梳理。正在庆幸之余，突然发现，导入的返利数据不仅生成凭证，还更新到了一些表里，这就有点复杂了，进一步分析这些表，才发现是管理返利导入和汇总的。

 

通过对导入的分析，发现返利导入时分会计凭证和数据表两条线进行了更新，那按照这个理解，在消耗时应该也是两条线。由于是事后返，返利的消耗在开发票的时候处理，开发票用了自定义的TCODE，那一定是为了返利消耗处理包了一层壳。

 

迫不及待地去打开这个壳，里面真是复杂，各种规则进行批量发票的处理等，但是按照创建会计凭证的BAPI和返利表的关键字在程序中都没有搜到处理代码。难道判断有误？看来这层壳不是为了处理返利的，只是为了处理批量发票。那在哪处理这返利的消耗呢？一定是增强。然后CMOD、SMOD、标准程序搜索、会计凭证替代都没有找到，感觉人间蒸发了，但返利数据经过测试确实消耗更新了。再一次陷入死胡同。

 

 

看来只有最后一招了，既然返利数据更新到自建表里去了，查这个表的所用处清单，看哪些程序、函数用到了这个表，一下子查出了几十条，其中一条让人眼前一亮，就是它，发票的BADI。此处必须致敬一下，这个增强点找的很好。果然返利消耗表的数据在此BADI处理，但并没有看到会计凭证的处理。

 

两条线的消耗，只找到了一条线，另外一条呢？再度陷入迷茫，有点黔驴技穷的感觉。只能再次如法炮制，查生成凭证BAPI的所用处清单，这次并没有增强用到，而是有一堆自开发的程序用到了，通过进一步筛选终于找到了这个程序，并且，这个程序是每五分钟通过后台作业调用执行的，从而实现相对实时地创建会计凭证。

 

至此，两条线导入、消耗的轮廓出来了，整个过程如同寻宝、探案。在此基础上，后续优化方案很快就制定出来了。

 

 

总结：前期项目文档对于优化项目非常重要，甲方应该充分重视并建立一套规范的文档管理体系。对于乙方来说，甲方文档是否规范是评估项目风险的一个重要因素。对于技术人员来说，SAP对象的所用处清单是个很好的手段。

 

高难度的方案替换和信用规则实现

▼方案定下来了，就开始系统实现了。这个过程如同给病人做换心手术，之前心脏连着许多血管、神经，新的心脏换上去后也必须和原来的血管、神经连上，才能保证机体正常运转。本次项目也是一样，把会计凭证的生成处理换掉了，但新的逻辑处理必须和处理前的输入参数、处理后的消息处理、状态回写等无缝接上，这样才不会破坏原来程序总的逻辑处理，并且回归测试工作量会减少。

 

因此，接下来就是要静下心来仔细分析这些输入、输出参数的具体赋值和被其它地方使用到的情况。难度很大，需要保持清晰的思路。经过细致、繁琐的分析、对应过程，这部分工作顺利完成。整个过程中，脑子里经常浮现的是手术台上一刀、一针、一线做手术的场景。

 

总结：优化项目的具体实现不同于新实施项目，需要在原方案基础上仔细考虑细节，尽量少动原来的代码，保证新方案的业务处理和现有其它业务处理无缝衔接。

 

▼系统实现过程中另外一个挑战就是信用管理的规则实现。由于业务需要，经常会有一些客户属于母子客户（多个客户号归属同一客户主体）。这些母子客户授信额度共用，但预收账款不共用。

 

针对这个需求，可以考虑的方案还是比较多的，母子客户可以考虑客户主数据合作伙伴关系设置、FSCM的合作伙伴管理等，针对授信额度共用可以考虑信用账户共用等，预收账款不共用可考虑分开信控范围或用户出口增强。最终统一考虑，选择在SAP标准信贷基础上，通过信用用户出口处理。

 

方案定好，压力就在开发代码了，如何通过代码实现信用管理规则成为关键。考虑到信用规则不仅在订单检查时用，在许多信用相关报表和接口都会用到，这部分代码一定要模块化，并且一定是RFC函数。框架搭好了了，就开始逻辑实现了，取信用规则所需的基础数据比较简单，从S066、S067、KNKK这些表取数就都搞定了，但这个规则实现就没有那么简单了，由于一部分额度是共用的，母子客户都可以去抢，而预收账款是独享的。共用额度部分如同春运抢火车票的逻辑。

 

在整个逻辑处理中，针对先共用、后预收和先预收、后共用规则前后做了近10个版本的逻辑处理，但总是在某些业务场景下有些不太合理的情况出现。其中甚至客户提出要模拟系统计算信用更新数据的处理，这一点被断然否掉，SAP ECC的信用管理中信用更新部分是最容易有问题的（S/4HANA应该是解决了这个问题）。最后在不断修正规则、调整算法的基础上，圆满完成。

 

总结：SAP SD模块的信用管理功能非常强大，企业信用管理需求尽量用标准功能实现。对于特殊需求，SAP提供了信用出口进行信用检查增强，但对于信用数据更新不要去做调整处理。

 

 

针对性地高效测试

因为对优化点和原方案的调整点比较清楚，所以项目组有针对性地设计了新的信控范围、新的信用规则和返利优化方案的测试场景，并有针对性地做了回归测试，虽然业务人员比较忙，测试工作还是比较顺利、高效地完成了。

 

总结：由于优化工作都是对原方案的整体优化或局部优化，所以对于系统的回归测试是难免的，为了最大限度地提高测试效率，除了一方面在方案和实现上尽量少动原代码，并做到与其它相关部分无缝衔接，另一方面，需要针对优化点有针对性地设计测试场景和进行回归测试。

 

 

平滑切换上线

系统切换上线除了系统功能切换外，最重要的就是数据切换了。由于现有业务还在系统上处理，系统作为后台支撑着前台经销商下单系统，原则上是不能停机的。这就对数据切换提出了很高的要求。所以在制定整个优化方案的时候，就重点考虑了数据切换方案，包括切换数据、切换方式等，以保证将数据切换工作量降到最小。

 

考虑到客户业务的连续性和数据清理的难度，制定了两套切换方案，一套是自然切换法，即新业务新办法、老业务老办法，历史数据随着业务发生自然消耗调整结束。另一套是整体切换法，即将历史数据整体按新方案切换，之后业务都按新方案执行。由于客户有能力将历史数据清理和调整，也需要短时间内清理历史数据，因此，很快确定了整体切换方案。

 

接下来顾问就开始着手准备切换工具，客户开始清理和调整历史数据，一切有条不紊。按照制定的切换方案，系统并没有停机，也没有锁用户，只是针对一些特定某几个TCODE进行了锁定，停掉了几个后台作业，对业务运作基本没有什么影响。

 

总结：优化方案不能单纯考虑问题解决方案，还要结合数据切换方案一起考虑，数据切换方案往往对切换工作量和时间有很高的要求，要根据客户的数据基础和清理调整能力制定数据切换方案。

 

 

以上是一个优化项目的回顾和总结，其中还有许多故事就不一一叙述了。

 

每个项目都有自己的故事和特点，各有各的不同；每个项目的经验和教训又是相似的。

优化项目不同于新的实施项目，以上总结的内容希望能给大家带来一些借鉴和参考。

 

 

以上内容均为【迪森】原创出品，版权归迪森所有，严禁任何形式的抄袭行为，否则将追究其法律责任，敬请遵守！敬请各位维护好良好的SAP圈内正能量环境，我们会分享越来越多的精华，谢谢！

 

 

服务指南

如需了解更多SAP课程资讯、项目咨询运维，请拨打迪森官方咨询热线： 400-600-8756

【迪森微课堂】

SAP圈内最接地气的纯技术交流、纯干货分享平台，全球SAP顾问与业界顶尖名师的聚集地，是SAP顾问进阶的官方桥梁。

 

【如何加入迪森微课堂】

请即刻关注迪森官方微信公众平台，第一时间获得迪森最新动态，秒抢宝贵席位！