ERP项目上线，通常会选择在五一、国庆、元旦假期，假期前盘点库存和整理数据，假期中停产停机，便于系统切换上线。那年元旦，我们项目也没例外，假期前做好上线的准备工作，假期系统部署完毕，生产系统顺利切换。在全公司上上下下的殷切期盼中，第一笔业务数据开始录入，前端平台通过IDOC再传到SAP ECC中，就在大家的都觉得进到ECC，在ECC中走完整个流程毫无悬念时，毕竟经历了这么多轮测试，何况这又是核心流程，可偏偏就在这个节骨眼，卡住了，销售订单生成失败。原本满心期待还略微有些兴奋的项目组同事，顿时出现了短暂停滞，齐刷刷看向我们组，面带疑惑，不可思议中夹杂着些许忧虑，气氛骤然紧张了起来，这可是正常的销售业务流程，没了销售订单，后续所有业务都进行不了，ECC中再好的戏也出不来。
在此当口，我们组同事迅速投入战斗，从进到ECC的IDOC数据结构开始查起，在极短的时间从数据结构查到程序代码，期间还接到好几拨各级领导打进来的关心电话，接这几通电话的工夫却啥也没耽误，效率反而出奇的高，地毯式搜索后很快锁定到问题根源，inbound IDOC中的一个字段的数据元素（Data element）被删除，导致进来的业务数据无法存储而报错。
那么，删除了表结构中的数据元素，那是哪个组的同事干的呢？交叉测试怎么没有测试到这个问题？还有没有更多的数据元素也被删除了？除了销售订单的创建以外还会影响到系统其他哪些地方？如果数据元素创建恢复回去会有什么影响？会影响到哪些也用到这个结构的程序和业务流程？
带着这一堆疑问，在开发配置环境中，从表结构直接查到传输请求，很快定位到删除该内容的请求人和该项目上的开发同事？火急火燎地打通对方电话，边沟通边将他们项目的实施和开发同事拉到同一个电话会议上，这才了解到他们项目中由于删除数据结构中的一个字段，误删到了这个数据元素，由于删除的字段是只有他们项目在用，所以没有做交叉测试。而这个误删的数据元素却是我们这些个字段共用的，了解了来龙去脉，解决方案也就清晰起来了，但关键的是还有没有别的类似的误删？前面提到的这些个疑问如何处理？为解答疑虑，合力研究并核查了系统，反复论证，明确只是一处误删，没有涉及到更多的地方以及其他模块和项目，并证实将此数据元素创建回去，对方项目不会有影响，同样不会影响其他的地方，所以最终确定了方案，及时上报后解决此次危机。所有人都松了口气，各自缓缓的添了杯咖啡。
这样的画面，是否似曾相识？历经ERP项目实施的你，是不是想起一道道再熟悉不过的风景？需求分析、系统测试亦或是上线切换，难免会遇到各种各样棘手的问题。me too！ 得益于早年系统开发实施以及项目管理的经历，逐渐养成的ERP项目实施中分析解决问题的三步法，在这么多年的顾问生涯中，一直影响着笔者更加高效解决问题、防止问题扩大化以及预防留下隐患等，在这里和大伙一起提炼并总结：
第一步：解决问题：就所遇问题进行全面检查，找到原因并及时解决；
第二步：深究根源：进一步深入分析，造成这个问题的根本原因，避免此类问题再次发生；
第三步：追查关联：追查此问题的关联方、关联模块、关联业务部门会不会受到牵连或影响，避免问题扩大，继而影响到相关方或者上下游。ERP系统有其特殊性，是一个高度集成的平台，供应链业务环环相扣，以及与财务业务自动集成，系统内的配置和开发增强也都是有着千丝万缕的关联，一旦某处出现问题，难免会波及其余，将问题放到全局中考虑，查漏补缺，能很好的将隐患消灭在萌芽中。负责任的说，在项目中不小心埋藏的雷，含泪也要排完，不然指不定哪天就爆了。
当然，我们也不能只是当项目中遇到问题时才开始这么处理，自我们一开始讨论需求、梳理流程以及撰写开发文档时，就需要我们对需求或者问题做全面而准确的分析，一是尽可能的穷举，将需求列全，既有广度又有深度，还要有时间维度上的考量。二是搜集需求做到不遗漏的同时，还需要我们从具象到抽象的建模中，合乎逻辑的分门别类，做到既独立又不重叠，业务线清晰。准确反映需求，通过配置或者开发，在ERP系统中完整实现并能让整个业务流程顺畅跑通。
平时面对复杂的ERP系统以及范围又广的项目，在项目管理、系统实施以及增强开发等各个角色中的你，希望这简单三步可以助你更加高效不留隐患的处理问题，交付一个流畅的ERP系统平台。
