变革管理计划：在抵触情绪出现之前就解决它

ERP 项目的变革管理计划，说明人们将如何从今天的工作方式，转变为新系统所需要的工作方式，以及由谁负责把他们带到那里。它从动员阶段开始，而不是从培训开始。它有七个部分，每个部分都有指定的负责人，并且与章程、设计研讨会和质量关口挂钩，而不是作为一条旁路来运行。

大多数抵触情绪不是凭空出现的。它是在启动之前很久，慢慢积累起来的。您能从早期会议上旁敲侧击的评论里听到它。您会注意到关键的业务负责人变得沉默。等到正式的变革计划被起草出来时，大部分损害已经造成。

它通常从几个可预见的地方开始：

1. 关键用户被排除在早期设计之外。
2. 部门负责人对从未有人与他们讨论过的影响感到意外。
3. 含糊的沟通招来猜疑。
4. 过去失败的项目留下了悄悄的不信任。

这些是结构性问题，而不只是沟通问题。如果指导委员会消极被动，就预料会有摩擦。如果项目章程对采纳只字未提，您就已经失去了一个杠杆。

1. 01动员梳理影响力，收集非正式的历史
2. 02设计商定采纳度 KPI，核心用户共同参与编写
3. 03测试业务用户测试自己的流程
4. 04培训基于角色，使用真实数据，安排在人们能参加的时间
5. 05上线关口采纳度门槛，而不只是功能签批
6. 06最初 90 天跟踪登录、错误、工单和权宜做法

在权宜做法变成习惯之前就发现它们

变革计划不是一份沟通日历。这是七个组成部分，以及每一部分应该由谁负责。

组成部分	目的	负责人
角色和影响力映射	所有受影响的人，以及他们的影响力，而不只是头衔	变革负责人
变革影响评估	每个群体的角色、流程和工具会发生怎样的变化	流程负责人与变革团队
沟通计划	受众、信息、渠道和时机，附反馈闭环	沟通负责人
培训和赋能	基于角色的课程、练习、就绪度检查	培训经理
领导层参与	领导者保持一致、了解情况，并公开支持变革	执行发起人与变革负责人
采纳度 KPI	在设计阶段商定、并在上线后持续跟踪的行为指标	变革负责人
抵触监测	与团队对应的早期预警信号	所有工作流负责人

在大多数变革计划中，沟通意味着简报、邮件和全员大会。这些并不能打动人。

我记得有一次上线，我们按时沟通了所有事项，可没有人能解释流程为什么要改变。我们有量，却没有清晰。

按受众量身定制。 高级经理要先听到业务影响。终端用户需要从自己的直属经理那里听到，而不是从一位他们从未见过的项目负责人。功能负责人如果自己承担一部分信息，反应会更好。

内置反馈。 只有单向的沟通，只是半份计划。我合作过一个团队，每周一次的问答电话，比任何邮件都更有影响。把您听到的内容与风险登记册联系起来，这样薄弱点会在公开浮现之前就显现出来。

把握好时机。 太早会造成混乱。太晚会显得勉强。在一次上线中，用户以为自己的工作要被取代了。没有人这样说过。但沉默填补了空白。要直接而及早地回应这种恐惧，在别人替您回应之前。

不要重复使用上一个项目的人员地图。影响力因项目而异。从头构建这张地图，并且每月更新。

对每个人，跟踪三件事：变革对他们影响多大、他们今天的立场（支持、中立或抵触），以及他们对他人有多大影响力。一位抵触的中层经理，若有一支追随他的团队，比一位抵触的个别用户更重要。

也要收集非正式的历史。过去失败的项目以经验总结文档从未记录的方式塑造着行为。花几个小时听听人们记得什么，您就知道自己真正在应对什么。我的相关方管理指南更详细地讲了这种映射。

培训是变革管理的一部分，不是全部。常见的失败是培训来得太晚、形式不对，而且在人们有信心之前就停了。上线前两周的一天课程，不等于就绪。

有效的做法：

1. 基于角色的内容。 教每个群体他们自己的工作所需要的内容，而不是系统导览。
2. 用真实数据练习。 使用业务自己的数据和交易，而不是演示场景。
3. 让核心用户当培训师。 人们从自己信任的同事那里学得更好。把核心用户当作设计的共同作者，而不只是测试人员。
4. 在合适的时间培训。 我合作过的一个财务团队，因为课程安排的时间不对而缺课。调整时间就解决了。
5. 上线后的支持。 信心在上线之后下降，而不是之前。让能快速回答真实问题的人来担任 Hypercare。

用户验收测试同样是采纳的一部分。我记得一次 UAT，定价逻辑里的一个小错误本会导致开错发票。一位团队负责人发现了它。别人都没有发现。这一次发现省下了好几周的清理工作，而它之所以发生，是因为一位业务用户觉得这个系统有一部分是属于他们的。

把采纳度门槛写进您的质量关口。“系统能用”是功能签批。“用户已经准备好在其中工作”是另一种签批，而大多数项目只要求第一种。我的 SAP 培训策略指南更深入地讲了培训计划。

上线前要商定的采纳度 KPI

在设计阶段设定这些，这样才有一个可供衡量的基线：

1. 最初 90 天内各用户群体的登录率。
2. 关键交易的错误率，与遗留系统的基线对比。
3. 按数量和类别统计的支持工单。
4. 权宜做法的频率：导出到电子表格、并行记录、系统之外的手工审批。
5. 通过简短的脉冲调查得到的经理汇报的信心。

窗口很窄。我见过用户在几周内就悄悄切回电子表格，不是因为系统坏了，而是因为没有人帮他们度过这次变革。上线几个月后，权宜做法就变成了习惯。

数字化采用工具

SAP 于 2024 年 9 月完成了对 WalkMe 的收购，股权价值约 15 亿美元。SAP 当时表示，WalkMe 的 AI 能力会为 Joule 在各工作流中增加情境感知的帮助。这意味着 SAP 现在拥有两款各有所长的采用工具：

• SAP Enable Now 适合结构化的培训内容：把一个流程录制一次，就能据此生成文档、模拟演示和测试脚本。
• WalkMe 适合在使用的当下提供应用内的引导，并且可以跨越 SAP 和非 SAP 应用。

把它们放在一起评估。如果您想要不与 SAP 绑定的采用工具，Whatfix 是主要的独立替代方案。这些工具都不能取代经理去解释变革为什么重要。

即使准备充分，新的摩擦还是会出现。过度控制通常适得其反。目标是及早发现它。

警告信号包括缺席研讨会、会议上的沉默、测试中含糊的反馈，以及关键用户建立非官方的权宜做法。把每个信号对应到它来自的团队，这样您就能在它传到指导委员会之前采取行动。

有一种做法行之有效：按阶段轮换变革负责人。一个人在两年的项目里一直负责变革，通常会筋疲力尽、失去视角。随着抵触的性质变化，应对它的人也应该变化。

最重要的是，让变革管理留在项目结构之内。行为方面的成果属于项目章程。团队过载和对遗留系统的不信任这类人员风险，与技术风险一起放进风险登记册。当变革管理只是汇入通用 PMO 更新的一项时，它就成了走过场。

变革管理计划应该包含什么？

七个部分：影响力映射、变革影响评估、带反馈闭环的沟通计划、基于角色的培训、领导层参与、采纳度 KPI 和抵触监测。每一部分都需要指定负责人，并且计划应该与章程、设计研讨会和质量关口挂钩。

变革管理的 5C 是什么？

有好几种版本。我使用的是：清晰（人们知道对自己有什么改变）、一致（领导者说同样的话）、承诺（发起人保持可见）、沟通（相关、及时、双向）和能力（培训、支持和适应的时间）。缺少任何一项，人们就会退回旧习惯。

变革管理的 7R 是什么？

它们来自 IT 服务管理，用于在采取行动之前评估一项变更请求。谁提出的、原因、预期回报、风险、所需资源、谁负责，以及与其他变更的关系。它们适用于技术变更控制，而不是项目中人的这一面。

组织变革管理和技术变更管理有什么区别？

组织变革管理让人们做好准备：在工作方式的转变中提供沟通、培训和支持。技术变更管理则通过传输请求、审批、测试和回退，控制哪些变更进入 SAP 系统。ERP 项目通常把技术这一面管得很好；采纳的失败来自组织这一面。我的 SAP 技术变更管理工具指南讲了技术这一面。

我应该用 WalkMe 还是 SAP Enable Now？

往往两者都用。SAP Enable Now 更擅长在上线前创建结构化的培训内容。WalkMe 更擅长上线后的应用内引导，尤其是用户在 SAP 与其他应用之间切换时。由于 SAP 拥有两者，请把它们放在一起评估。Whatfix 是主要的独立替代方案。

ERP 项目中，变革管理应该何时开始？

在动员阶段，第一次设计研讨会之前。最重要的早期行动是梳理影响力、收集过去项目的非正式历史、把行为方面的成果写进章程，以及确定发起人的沟通节奏。