SAP项目风险评估：实用版

SAP项目风险评估，列出可能让项目脱轨的因素，并按概率和影响给每项风险打分。每项风险都有一位指定的负责人，以及在风险发生之前就商定好的应对措施，这份清单每周复查一次。让SAP项目沉没的风险，很少是意外：数据迁移、集成、人员可用性、范围漂移和接受度。本文写给项目经理和发起人，他们需要的是一份能改变决策的风险登记表，而不是一份躺在文件夹里的登记表。内容包括一个带评分的矩阵、一份风险登记表模板、三个公开的失败案例，以及RISE with SAP和Clean Core带来的风险。先从为您手上已有的每一项风险指定负责人开始。

多数SAP风险评估，是在第一次指导委员会之前做好的，复查一次，之后再没有人碰过。那不是风险管理。那是一份文档。

我见过一些风险被忽视，因为它们太让人不舒服，没人愿意早早提出来。这种沉默几乎总是在日后付出更高的代价。起初只是物料管理中的一个小小的集成问题，转眼就卡住了财务。一份在测试中看起来没问题的报表，在系统更新之后坏掉了。这样的事，我见过不止一次。

这些风险并不是意外。它们有记录。只是没有人对它们采取行动。

范围：项目从标准模块开始。然后有人加一份“就这一份”报表，再加一个看板，再加几项增强。危险在于，范围的变更是在工作坊、邮件和走廊闲谈中非正式地引入的，项目经理往往要等配置完成之后才听说。我的避免范围蔓延指南讲了这方面的控制手段。

资源：架构师被拉去处理生产问题。一位关键开发人员离职。业务用户因为日常工作不会停下来，错过测试周期。要让人员可用性落成书面。口头承诺在人手压力下会蒸发。

技术：字段映射从未对照目标结构验证过。通过单元测试的接口，在真实事务量下失灵。自定义代码，在生产负载到来之前看起来都没问题。只要您知道该往哪里看，这些都是可以预见的。

时间线：蓝图延误挤压了测试，但上线日期保持不变。UAT、培训和数据准备被仓促对待。几乎每个错过阶段关口、却没有调整下游计划的项目，都会出现同样的模式。

接受度：人们会排斥自己不理解的东西。薄弱或过晚的培训会催生变通办法，变通办法会拖垮数据，而系统要为一次变革管理的失败背锅。

这些案例是公开的，记录充分。同样的模式在各种规模上重复出现。

Lidl：七年约5亿欧元

Lidl于2011年启动了基于SAP for Retail的eLWIS项目，在一些较小的国家上线，并在2018年放弃了它，据报道成本约为5亿欧元。一个被广泛报道的原因是：Lidl按采购价对库存估值，而SAP的标准零售模型使用零售价。Lidl选择了定制，而不是改变这种做法，公司表示，以合理的努力无法实现最初的目标。

教训：您的数据模型与SAP标准之间的不匹配，是第一周就该面对的风险，而不是第五年才发现的问题。

HP：约4亿美元的收入损失

2004年，HP把部分服务器业务迁移到一套基于SAP、整合后的订单和供应链系统上。订单在旧的前端和SAP之间掉了出去，需要手工处理，积压的订单翻了一番。HP的CEO表示，这些问题让服务器和存储业务部门损失了约4亿美元的收入和2.75亿美元的营业利润，留下了1.2亿美元的积压订单。HP的CIO后来说，团队只计划了三周的中断，本该为四到六周做好应急准备。

教训：应急预案要按糟糕的切换来定规模，而不是按平均水平，并且要在切换之前就建立库存或渠道缓冲。

Nike：超过1亿美元的销售损失

2000年，Nike在其SAP ERP项目之前，先上线了i2需求计划软件。这套软件为了配合Nike的旧系统，做了大量定制，运行缓慢，并在产品量面前崩溃了。它对有些鞋订多了，对另一些又订少了。Nike损失了超过1亿美元的销售额，股价下跌约20%。Nike后来把短期和中期计划挪进了SAP。

教训：集成在用生产量级的真实数据跑过之前，千万不要假定它能行。

建立在假设之上的评估，比没有评估更糟，因为它制造了虚假的信心。有六项输入很重要：

1. 范围文档：章程、已批准的范围和已签字的需求。如果它们不存在，范围风险就已经很高了。
2. 资源承诺：部门负责人的书面承诺、关键角色的技能矩阵，以及每个关键岗位的指定后备人选。
3. 预算和时间线：含应急储备的已批准预算，以及与可比项目核对过的时间线。为一次完整的推广只给六个月和极少的资金，是现在就该指出的风险。
4. 供应商承诺：带有服务级别和罚则的合同。在RISE上，则是SAP的责任和升级路径。
5. 技术架构：旧系统的兼容性、数据迁移的复杂度、部署模式，以及针对任何定制工作的Clean Core计划。
6. 过往项目记录：以往SAP或ERP项目的风险登记表、问题日志和复盘。大多数风险并不新鲜。

按概率和影响，对每项风险从1到5打分，然后相乘。下面的例子是S/4HANA项目的一个典型起点；您的分数会有所不同。

风险	概率（1-5）	影响（1-5）	得分	优先级
数据迁移失败	4	5	20	高
集成延误	4	4	16	高
资源受限	4	4	16	高
预算超支	3	5	15	中
核心中的自定义代码阻碍升级	3	5	15	中
范围蔓延	4	3	12	中
测试覆盖存在缺口	3	4	12	中
高峰负载下的性能	3	4	12	中
合规缺口	2	5	10	中
没有向SAP升级问题的路径（RISE）	2	5	10	中
用户接受度低	3	3	9	中
订阅或许可成本的风险敞口	2	4	8	中
关键指标没有被跟踪	3	2	6	低

得分在16及以上的，需要指定负责人并立即行动。得分从8到15的，需要监控，并设定明确的升级触发条件。低于8的，保留在登记表里，但不必占用优先级时间。分数是起点，而不是裁决：在受监管的行业里，得10分的合规缺口可能变成25分。

光有分数，什么也改变不了。每项风险都需要填写下面这些字段。

字段	写什么	示例
风险	用一句话描述这个事件	供应商主数据在第2次模拟加载之前没有清洗
负责人	一位指定的人	应付账款负责人
得分	概率 × 影响	4 × 5 = 20
触发条件	您采取行动的可衡量节点	第1次模拟抽取中的重复率高于5%
应对措施	规避、缓解、转移或接受，并写明行动	缓解：安排两名应付账款分析师用三周时间做清理
下次复查	日期	下周一的风险复查
状态	未结、处理中、已关闭	处理中

能用实际数字表述成本的，就用数字。“高风险”是含糊的。“UAT延迟一周，团队时间的损失约为六位数，并可能把上线推后三周”，才会引起重视。

自定义代码本身就是一个风险类别。在S/4HANA Cloud公有版上，核心里不可能有自定义代码。扩展要通过SAP BTP、已发布的API或关键用户工具来进行。在私有云和本地部署上，您仍然可以修改核心，习惯这么做的合作伙伴也会这么做。这种技术债会在第一次重大升级时浮出水面。要跟踪已识别的定制中，有多少已有商定的Clean Core方案，检查合作伙伴在BTP扩展方面的经验，并在探索阶段结束之前建立一个评审论坛。

RISE改变了谁来负责可用性。SAP运营基础设施，所以风险从“我们的团队负责可用性”转变为“SAP负责，而出问题时我们需要一条快速接入的渠道”。要记录SAP的指定联系人、升级路径和服务级别，以及在上线之前商定好的事件处理计划。没有这些，本该交给SAP的问题，会在项目团队内部耽搁太久。

AI能帮忙处理文书，帮不了判断。SAP Cloud ALM中基于Joule的助手，以及Microsoft Copilot之类的工具，可以根据状态报告、缺陷日志和会议纪要，起草风险登记表条目和指导委员会材料。在源数据干净的项目里，这会加快登记表的维护。它找到的，是数据里本来就看得见的风险。它决定不了哪些风险值得行动，也推动不了负责人去行动，更不会升级领导层宁愿忽视的风险。

1. 识别全部五个类别的风险：与IT、业务和供应商开展工作坊；各方看到的风险不同。在RISE上，至少要在一次工作坊里加入SAP的联系人。团队通常漏掉的风险有：IT和业务期待的东西不同、定义不清的外部集成、没有时间的UAT负责人，以及非正式的范围变更。
2. 给每项风险打分，按概率和影响，尽可能用真实的数字。
3. 每项风险指定一位负责人：是一个人，而不是一个团队。没有负责人，就没有跟踪，也就没有解决。
4. 在风险降临之前，就定义好应对措施：规避、缓解、转移或接受。“监控并应对”不是计划。它是被推迟的决定。
5. 每周复查：检查未结风险，加入新风险，在条件变化时重新打分，并升级任何接近触发条件的风险。把最重要的风险带到指导委员会，附上一项建议的决策，而不是一种颜色。

1. 01识别全部五个类别
2. 02打分概率 × 影响，1到5
3. 03指定负责人一个人，而不是一个团队
4. 04定义应对措施规避、缓解、转移或接受
5. 05每周复查重新打分，接近触发条件时升级

16或以上：指定负责人，本周行动

SAP项目中的风险评估是什么？

它是识别什么可能出错、按概率和影响给每项风险打分、为每一项指定负责人，并在风险发生之前商定应对措施的过程。SAP项目同时运行多个模块、集成、数据迁移、变革项目和一个固定的上线日期，所以非正式的风险管理撑不住。一份由真实风险和负责人组成的简短清单，胜过一份没人读的长文档。

如何为SAP项目建立风险矩阵？

列出范围、资源、技术、时间线和接受度各方面的风险，再加上RISE上的Clean Core和向SAP升级问题的路径。按概率和影响，对每项风险从1到5打分并相乘。16及以上算高，8到15算中，低于8算低。给每一项中、高风险指定负责人和可衡量的触发条件，例如“如果到第16周UAT完成率低于80%，上线日期就要接受复查”。每周重新打分，并在每个阶段关口重新打分。

SAP实施中最常见的风险有哪些？

数据迁移失败，因为旧数据几乎总是比估计的更乱。集成延误，尤其是涉及没有文档的旧接口和第三方供应商时。范围蔓延，挤压了测试和培训。资源受限，例如关键人员被调走，或者月末UAT期间用户抽不出时间。接受度低，源于培训只是演示屏幕，而不是模拟这份工作。在RISE上，还要加上核心中的自定义代码，以及缺少向SAP升级问题的路径。

SAP项目中，应该在什么时候做风险评估？

在项目开始之前，此时数据模型不匹配或时间线不切实际之类的结构性风险，修复起来成本最低。在每个SAP Activate阶段关口之前，因为每个阶段都会改变风险状况。在范围、预算或资源发生变化的任何时候。还有在风险变成问题的时候，检查它还影响到什么。在这些节点之间，每周复查。

在SAP项目中，应该由谁负责风险？

能对风险采取行动的人。数据负责人负责数据迁移风险，技术架构师负责集成风险，变革负责人负责接受度风险，解决方案架构师负责Clean Core风险。在RISE上，CIO或项目总监负责向SAP升级问题的路径。项目经理跟踪登记表的健康状况，但不负责每一项风险。

跳过ERP风险评估会发生什么？

在大规模上，您会遇到像Lidl这样的案例，它在花掉约5亿欧元之后，于2018年放弃了SAP零售项目。或者像HP，它在2004年迁移SAP订单系统，让服务器业务部门损失了约4亿美元的收入。在较小的规模上，机制是一样的：数据模型不匹配到很晚才发现，集成在生产事务量下失灵，培训薄弱造成接受度失败。这些风险在变成问题之前，本来是可以识别的。