SAP与AI交付的七个咨询框架

当SAP或AI项目陷入停滞时，原因通常是结构性的，而七个简单的框架能把它找出来。梳理现状。用RACI约定谁决定什么。把工作与业务能力关联起来。用五个为什么找到根本原因。用MoSCoW给需求排序。按真正能让项目停摆的因素给风险排序。每个阶段之后做一次真正的复盘。这篇指南写给SAP和AI交付中的项目经理、顾问和发起人。先看下面的表格：找到您的症状，先用对应的框架。

卡塔尔一家中型媒体公司正在多个地区推广SAP。财务和采购在第一阶段上线。它还希望在报表中加入AI预测模型。

到第6周，延误开始累积。业务用户说他们已经对需求签字确认，却仍然搞不清自己会得到什么。AI应用场景已经提出来了，却没有人说得清数据归谁，产出的结果又将如何使用。人们开会迟到，或者干脆不来。

那是一个夹在中间的阶段。说它失败还为时过早。假装它会自己好起来又太晚。

我们一步一步地应用这些框架。起初并非所有做法都受欢迎。有些会议很沉默。有些则跑偏了。但这套结构让工作变得更容易：团队不再原地打转，待办清单变得可以掌控，AI应用场景也有了真正的负责人。项目比计划晚了8周上线。谈不上完美。但它落地了，第二阶段在更好的基础上起步，未知因素也更少。

我在海湾地区、欧洲及其他地方的SAP、Oracle和AI项目交付的23年里，用过这七个框架的各种版本。没有一个是稀奇古怪的。只要您带着纪律去应用，而不是把它们当成文档作业，每一个都管用。

把症状与框架对应起来：

您看到的症状	框架	它产出什么	通常的工作量
用户对需求签了字，却仍然困惑	1. 现状梳理	一张共同认可的、今天工作实际如何运转的图	3到5天的工作坊
决策在各个会议之间来回推	2. 关键决策的RACI	为20到30项关键决定指定决策负责人	一次工作坊，之后是执行落实
发起人已不再关心“IT项目”	3. 能力映射	以业务能力来汇报进展	融入Fit-to-Standard
同一类缺陷不断重现	4. 五个为什么	一个您能改变的根本原因	每个问题一次主持式会议
一切都被标为高优先级	5. MoSCoW	一份排好序的范围，附一份现实的“必须有”清单	业务与IT联合的一次会议
风险清单看起来没问题，团队却很紧张	6. 风险排序	把能让项目停摆的风险和只是添麻烦的风险分开列出	每周30分钟的评审
同样的错误阶段接着阶段重复	7. 复盘	3到5项带负责人的改变	每个阶段之后半天

项目开始时最常见的错误，是在记录现有情况之前就跳到解决方案。流程文档通常已经过时。人们描述的是事情应该怎么运转，而不是实际怎么运转。两者之间的差距，正是实施问题所在之处。

一份有用的现状图，需要与实际做事的人，而不是管理他们的人，开3到5天的工作坊。它涵盖按顺序排列的流程步骤、每一步使用的系统、人工干预和变通做法，以及各部门之间的数据流。

要找的是没人提起、因为已经变得隐形的人工步骤，运行了太久、如今已被视为标准流程的变通做法，以及人人皆知却没人修复的数据质量问题。

在卡塔尔，现状图来自与用户开的工作坊，而不是来自文档。关于已签字确认的需求的困惑，正是从那时开始消散的。

做得好，现状图只需几天。如果把它当作收集文档的练习，就要花几个月，产出的东西还没人信任。

决策权是SAP和AI项目中最常缺失的结构性要素。人人都有看法。没有人知道谁做最终决定。决策被推到下一次会议，那次会议又推给指导委员会，指导委员会再把它们退回工作组。

RACI矩阵（Responsible执行、Accountable问责、Consulted咨询、Informed知会）为每一项决策和交付物指定了负责人。问责人只有一位，可以同时负责执行，也可以委派给他人。被咨询者提供意见。被知会者了解结果。

实用的做法：列出当前阶段最关键的20到30项决策，在决策者到场的情况下开一次RACI工作坊。某项分配存在争议，说明您有所发现：要么治理不清晰，要么是围绕权限的政治斗争。无论哪种，都要在第2周就把它暴露出来，而不是第14周。

没有执行落实的RACI只是装饰。名字必须对应拥有真正权限的人。把问责分配给一个角色头衔，而不是一个具名的人，是在回避“谁来承担风险”的那场对话。

SAP和AI项目会产生大量业务看不见的技术活动。正在构建的东西与它应该带来的成果之间的联系，变得抽象。发起人抽身而去，而“IT项目”背了锅，承担了实际上属于业务决策的延误。

能力映射把系统功能与业务能力连接起来：组织需要能够做到什么。您不再跟踪采购订单工作流是否配置完成，而是跟踪组织能否在收到供应商发票后3天内处理完毕。配置是机制。能力才是成果。

在SAP Activate中，这对应于探索阶段的Fit-to-Standard工作坊。范围内的每个流程都是一项能力，SAP标准与所需能力之间的每个差距都是一项决策：接受标准、配置一个变体，或者扩展。让对话停留在能力层面，能在整个构建期间保持业务的关注，也能暴露出人人以为在范围内、却没人确认过的能力。

当同一类问题在多个冲刺或阶段中反复出现时，逐个修补并没有用。原因在上游。

五个为什么是最简单的根本原因工具。先问问题为什么发生，再问那个原因又为什么发生，一直问到您能改变的地方。5轮通常能触及真正的原因。2轮通常停在症状上。

一个数据迁移的例子。试加载出现数据质量错误：这是症状。为什么？源数据抽取的字段映射有误。为什么？映射规格说明从未经业务数据负责人审阅。为什么？数据负责人是在映射完成之后才指定的。为什么？计划没有把数据负责人的参与设为映射的前置依赖。这就是根本原因，而修复办法是一项治理决策，不是数据修正。我那篇SAP数据迁移为何失败显示，这条完全一样的链条出现得有多频繁。

1. 01试加载出错症状
2. 02字段映射有误加载为什么失败？
3. 03规格说明从未审阅映射为什么有误？
4. 04负责人指定太晚规格说明为什么没有审阅？
5. 05计划漏掉了前置依赖负责人为什么晚了？

根本原因是一项治理决策，而不是数据修正

在不追究责任的会议室里做根本原因分析，会得到坦率的答案。在追究责任的会议室里，只会引来防御心态。主持人的工作是让对话围绕流程，而不是围绕人。我关于结构化思维与问题解决的指南，谈到了在开始问为什么之前，如何拆解一个乱麻般的问题。

每一场SAP和AI的范围讨论里都有一个共识陷阱。没人愿意做取舍，于是一切都成了高优先级。当一切都是高优先级时，就没有什么是高优先级了，而构建团队想把所有事都做完。

MoSCoW（必须有、应该有、可以有、这次不做）迫使人做出选择。必须有，是上线所需的最低限度。应该有，重要但不是阻碍。可以有，在时间和预算允许时是值得拥有的。这次不做，是明确推迟。

纪律体现在“必须有”这条线上。MoSCoW练习的第一轮，通常会把太多东西放进“必须有”。MoSCoW的出处，Agile Business Consortium的DSDM指南，为“必须有”设定了占工作量60%的上限，并警告超过这个比例会让交付面临风险。第一轮与现实清单之间的差距，大多来自未经检验的假设。

让业务和技术在同一个房间里做MoSCoW。分开做的话，IT的“必须有”清单和业务的“必须有”清单会互不相容，而在配置开始之前，没有人去调和它们。

大多数风险登记册是一长串按概率和影响打分的清单，每月评审一次，RAG状态很少变动。它们记录了风险，却没有驱动行动。

把能让项目停摆的风险，与只是让项目更难做的风险区分开。第一类需要负责人、应对计划和每周的可见度。第二类需要监控。

在卡塔尔，风险清单在纸面上看起来没问题，但每个人都感到忐忑。一个快速的风险影响矩阵，每周而不是每月评审一次，把真正的担忧带了出来。

登记册看起来没问题，而团队却很紧张，几乎总是有什么东西被藏起来了。登记册不是真相；围绕它的对话才是。每周的评审如果问“昨晚什么让您睡不着？”，比问“第14项的状态是什么？”能挖出更多东西。我的SAP风险评估矩阵提供了打分和责任分配的模板。

在一个阶段或上线之后做复盘，能防止同样的错误在下一阶段重演。它也是进度吃紧时最先被砍掉的事。

一次有用的复盘问四个问题。我们计划实现什么，实际实现了什么？哪些做得好，应该重复？哪些做得不好，原因是什么？我们会有什么不同的做法？结束时应该有3到5项具体行动，每项都有负责人，而不是一份总结发生了什么的文件。

常见的失败，是变成一场辩解练习，团队为自己的决策辩护，而不是审视它们。要着眼未来。问题不是谁造成了第6周的延误。而是什么样的结构性改变，能在下一阶段防止它们。

在卡塔尔，复盘在上线后立即进行，聚焦于行动而不是追责。这在很大程度上是第二阶段在更好的基础上起步的原因。

框架没有变。变的是应用它们的方式，体现在三个方面。

起草变快了；倾听没有。 AI工具现在几分钟内就能把工作坊逐字记录和流程文档变成第一版图，SAP Cloud ALM也可以根据Fit-to-Standard的逐字记录起草需求。工作坊本身花的时间和以往一样，因为倾听才是重点。起草省下的时间，应该用来与人一起质疑这张图。

RACI草稿现成了，难的部分依然在。 通用的AI助手，一分钟就能根据章程和工作包清单生成RACI。纪律转向了协商：每一个单元格都需要一次关于权限和升级的真正对话。构建草稿省下的时间，应该花在这些艰难的对话上。

有AI在场，MoSCoW变得更难。 AI给出的需求排序看起来合理、光鲜，却往往对当地的政治一无所知。不加质疑就接受它的顾问，产出的优先级清单比从一张白纸开始的顾问更差。把AI草稿当作起点，绝不是答案。

在这些框架之上的判断力，现在更值钱，而不是更不值钱。如果您作为顾问正在培养这些技能，SAPopedia的职业路径说明了在SAP职业生涯的每个阶段，哪些技能最重要。

什么是咨询框架，SAP项目为什么要用它们？

它们是用于分析、决策和解决问题的结构化方法。在SAP和AI项目中，它们让业务负责人、架构师、项目经理、集成商和发起人有了共同的方法。

没有它，每个群体都会回到自己的思维模型：流程成果、架构，或者时间表和资源。现状梳理、RACI和MoSCoW这类框架，让分歧变得明确，也变得可以解决。SAP Activate本身就是关于阶段、关口和交付物的框架；这七个框架在它之内运作，处理的是单靠方法论解决不了的结构性问题和人的问题。

现状梳理在SAP实施中是如何运作的？

它记录的是配置开始前流程实际如何运转，而不是现有文档说它们应该如何运转。要通过与运行这些流程的人开工作坊来构建：步骤、系统、交接、人工干预和变通做法。

它为SAP Activate探索阶段的Fit-to-Standard工作坊提供输入，在那里，现状成为与SAP标准流程比较的基线。要在这些工作坊开始之前完成它，否则您的差异分析就建立在假设之上。

什么是MoSCoW优先级排序，在SAP项目中什么时候使用？

MoSCoW把需求分为必须有、应该有、可以有和这次不做。“必须有”是上线的最低要求；“这次不做”被明确排除，以免它们悄悄溜回来。

它在探索阶段最有用，那时Fit-Gap发现推动着扩展决策；在实现阶段也很有用，那时缺陷和增强功能在争夺构建时间。常见的问题是，第一轮把太多东西放进了“必须有”。DSDM建议“必须有”占工作量不超过60%；一位逐项质疑的主持人，让业务和IT在同一场会议里，就能让您达到这个比例。

如何在SAP项目中开展有效的风险评审？

把它当作一场对话，而不是状态更新。先从开放式问题开始，例如“本周有什么让您最担心的、而不在登记册里的事？”，然后再过登记册。

对每一项高优先级风险，问：有什么变化，采取了什么行动，趋势是否在改善，应对计划是否仍然合适。连续几周评级不变、也没有行动的风险，往往被低估了。在活跃阶段每周评审，并向指导委员会展示前5项风险的状态和下一步行动，而不是完整的登记册。

SAP上线后的复盘，怎样才算有用？

为下一阶段提出具体、可执行的改变。对发生了什么的总结，只是一份记录，不是复盘。

涵盖您原本要实现什么、实际实现了什么、哪些有效、哪些无效。要深挖“我们资源不足”这类表面解释：是资源计划错了，范围错了，还是升级路径断了？结束时列出3到5项改变，每项都有负责人和日期。

在SAP环境中，咨询框架如何帮助AI实施？

AI项目失败的结构性原因与SAP项目相同，另外还有一些自己的原因：数据无人负责、成功标准未定义，以及没有就如何根据输出采取行动达成一致的流程。

现状梳理显示模型所需数据归谁，质量如何。RACI回答谁来验证输出、谁决定据此行动，以及输出有误时谁来负责。MoSCoW把必须做的应用场景与只是有趣的区分开。先从2到3个有明确负责人和成功标准的关键场景开始，而不是一下子上15个。