从格力高事件谈SAP项目质量管理

最近我相信大家都听说了格力高SAP项目上线后因为某些原因系统不能出货的事故，对于格力高这么一家著名的食品公司来说，无疑是非常严重的问题。对于本次事件的解读，大家可以参考各路业内人士的文章或者视频。今天我想借这个话题，聊一下SAP项目中的质量管理。

从事过软件开发工作的人都知道在软件开发领域一直在追求把软件开发作为一项系统工程来看待，也就是可以把开发一款软件比作建造一座房子，如果房子的使用年限是100年，那么建造标准、建造方法、材料等级等都需要围绕这个目标来制定，并且需要有一套严格的质量标准来控制。所以在软件开发领域有CMMI评级，来检验软件开发公司的软件能力成熟度，这其中就包括了软件质量评估。

很可惜我在SAP项目管理领域并没有看到类似的评估标准，所以造成了在实施SAP项目过程中出现了很多质量问题，除了像格力高这种上线后不能出货这种典型问题外，还有比如数据迁移后财务报表不平、开发没有注释和文档导致后期程序难以理解、测试不完整导致问题没有提前发现等等都是SAP项目中的典型质量问题。

那我们如何能最大程度的避免这些质量问题的发生呢?我觉得要从以下几个方面着手。

• 实施范围管理

SAP项目作为实施企业管理流程和SAP系统的项目，实施范围是项目所有工作的基本前提。实施范围管理是一个不断细化的过程， 特别是采用了敏捷项目方法论后，需要逐步把实施范围完善。但是不管采用哪种方式，实施范围必须清晰可见的，以便项目组成员都清楚的知道什么在实施范围内什么不在。实施范围具体体现在1）在项目章程中的基本项目范围2）项目实施范围管理列表或者是用户故事列表，有了明确的实施范围，才能保证项目后续的工作都有明确的目标，从而避免流程或者功能没有实施、有流程完全没有被测试到的情况。

• 变更流程和技术标准

项目中提出的需求或者用户故事，我们要避免用户和顾问商量一下就可以实施的情况，需要经过一定的变更流程才能开始实施和测试，这也是保证质量的重要手段，因为有了变更流程才可以确保需求描述清楚、审批人有相应的职权和知识、相应文档齐全、经过全面的测试。另外配置、开发、增强等技术工作也需要制定一定的技术标准，比如对命名标准、代码规范、技术文档等，这样可以大大的增加可维护性，出了问题可以快速准确的定位。

• 知识(文档)管理

对项目中所有的知识都需要进行一定的管理，除了我们常规理解的文档，比如需求说明文档、用户故事、流程说明文档、用户操作手册、技术文档等，还有一些决定、会议纪要等都需要以一定的方式记录，记录的好处是可以查询当初是怎么讨论的、怎么决定的，这样测试的时候出现一些分歧或者上线后出现的非技术问题都有据可循。当然，文档也不是越全越好，文档的内容可以根据复杂程度适当增减，最主要的是保留和传递信息，而不是写冗余和无效的信息。最后，最好对文档还有一定的审核机制，以确保文档的撰写、修订都是规范的。

• 阶段验收标准

我们知道SAP项目是分为不同的阶段来执行的，上一个阶段中所有任务的完成是下一个阶段的准备和前提，所以为了确保项目按时推进和保质保量的完成本阶段的所有任务，制定阶段的验收标准尤为重要，不管是在ASAP方法论中的里程碑还是在Activate方法论中的质检门都是这个目的。为了使全体项目成员理解每个阶段的工作重点，阶段验收标准必须提前制定并宣布并且在阶段结束前进行评估，如果有标准没有达到，还需要制定相应的应对方案，最严重的情况是需要延迟下一阶段的开始时间，因为如果强行继续，到上线的时候会出现更严重的后果。

SAP Activate方法论中已经制定了非常详细的质检门，大家可以参考以下链接获取信息

质检门定义：https://support.sap.com/content/dam/SAAP/SAP_Activate/PM_210.pptx

质检门检查列表：https://support.sap.com/content/dam/SAAP/SAP_Activate/S4H_0271.xlsx

• 测试和问题管理

SAP项目中测试是质量控制的最后一道关卡，虽然我一直强调SAP项目实施的不仅仅是SAP系统，但是实施的核心或者说最终体现是在SAP系统里面的。如何更好的组织和管理测试是一个比较复杂的问题，为什么往往我们测试的时候没有什么问题，但是一旦上线后就一堆问题？其实道理很简单，测试的用例和范围都太理想化了，只考虑了最简单的流程，现实企业在运营过程中会出现很多问题，或者说有问题是常态，没有问题才是不正常的。简单的例子，质量问题可能出现在采购、生产、仓储、运输过程中的任何环节，但是我们测试的时候会考虑这么多吗？

那么我们如何更好的准备和执行测试呢？首先我们要严格按照项目实施范围来指导我们准备测试用例，当然在范围管理的时候就不能仅仅考虑“最好的情况”，各种异常情况也需要考虑在实施范围以内。其次，测试必须要准备测试脚本，这是规范我们测试步骤的最好方式，如果第一次测试的时候发现脚本的步骤有问题，第二次测试前还可以修改完善。最后就是需要建立一定的问题管理和反馈机制，测试出来的技术和非技术问题都需要一一记录，并且追踪落实解决。我个人最讨厌看到的是，同一个问题在不同的测试中反复出现，这就说明问题并没有得到反馈和解决，这是非常浪费时间的事情。

• 管理工具

对于以上提到的实施范围管理、测试和问题管理等都需要一定的管理工具来确保项目组成员可以访问一致的信息，最简单的方式当然是使用Excel来管理，不需要太多的成本。如果项目达到一定的规模可能就需要像Azure DevOps中的Boards或者Jira来管理，SAP ALM也提供类似的功能，如果公司购买了云版本的SAP，这个工具是免费的。另外，如果出现了复杂严重的质量问题，推荐使用鱼骨图来层层分析，这也可以避免在找原因过程中相互推诿的好办法。好的管理工具可以帮助我们事半功倍，从纷繁复杂的项目事务中定位当前状态并且发现根本问题。