关于 change-management
为组织变革制定计划的技能,适用于流程调整、重组、战略转向和文化变革。它以 ADKAR 为核心,提供沟通安排、阻力诊断、变革疲劳应对及采纳度衡量方法。
主要功能
- 01按变革类型选择实施方案
- 02基于 ADKAR 诊断变革阻力
- 03规划沟通顺序与节奏
- 04识别并应对变革疲劳
- 05衡量采纳度与执行情况
适用场景
- 01推出新流程或工具迁移
- 02规划组织重组的员工沟通
- 03诊断变革停滞或员工抵触
- 04评估新做法的采纳情况
安装
复制下面的命令,在终端中运行。
npx skills add https:/ / github.com/ borghei/ claude-skills --skill change-management安装后在 Claude Code 中输入/change-management确认已加载。
包含的文件
除 SKILL.md 外,安装时一起下载的参考资料和脚本。
scripts/adoption_tracker.pychange_readiness_assessor.pycommunication_planner.py详细介绍
变革管理手册
大多数变革失败在实施阶段,而非设计阶段。本技能提供了全面的框架,帮助组织推行变革——从流程微调到全面战略转型——将干扰降至最低,并最大限度地提高采纳率。
关键词
变革管理,ADKAR,组织变革,重组,流程变更,工具迁移,战略转型,变革阻力,变革疲劳,变革沟通,利益相关者管理,采纳,合规,变革推行,过渡
先明确情况
开始生成前,请确认以下信息。如果有任何信息未知或含糊不清,请提问——不要自行假设:
- 变革类型(流程、组织/重组、战略转型或文化)——用于选择手册、时间线,以及最难推进的 ADKAR 阶段
- 变更内容及其真实的业务原因——原因是每次沟通的锚点;若缺少原因,推行就会显得武断并滋生阻力
- 受影响对象及影响方式(直接受影响者与更广泛的组织)——决定沟通顺序,以及不同受众获知变更的先后次序
- 目前还有多少项变更正在进行——如果有 3 项或更多变更正在推进,且尚未充分被吸收,那么计划必须先处理变革疲劳,再增加新变更
停止规则:只询问最可能改变输出的 2-3 个问题。如果用户说“直接起草”,就继续,并在产出内容顶部列出你的假设。
变革类型选择
START: Change is needed
|
v
[What type of change?]
|
+-- Process Change (new tools, workflows)
| Timeline: 4-8 weeks
| Hardest phase: Ability
| See: Process Change Playbook
|
+-- Org Change (reorg, new leader, team restructure)
| Timeline: 3-6 months
| Hardest phase: Desire
| See: Org Change Playbook
|
+-- Strategy Pivot (new direction, killed products)
| Timeline: 3-12 months
| Hardest phase: Awareness
| See: Strategy Pivot Playbook
|
+-- Culture Change (values refresh, behavior expectations)
Timeline: 12-24 months
Hardest phase: Reinforcement
See: Culture Change Playbook
核心模型:ADKAR(适用于初创企业的版本)
概述
| 阶段 | 含义 | 失败表现 |
|---|---|---|
| Awareness(认知) | 人们了解变革发生的原因 | “没人告诉我为什么” |
| Desire(意愿) | 人们愿意参与(或至少不会抵制) | “我明白,但我不同意” |
| Knowledge(知识) | 人们知道如何按照新方式做事 | “我想做,但不知道该怎么做” |
| Ability(能力) | 人们有时间、工具和支持来进行变革 | “我知道怎么做,但暂时做不到” |
| Reinforcement(巩固) | 变革成为新的默认做法并持续下去 | “我们试过,但又回到了旧方式” |
ADKAR 诊断
变革遇到困难时,请找出哪个阶段出了问题:
| 表现 | 出问题的阶段 | 解决方法 |
|---|---|---|
| “我们为什么要这么做?” | Awareness(认知) | 用数据重新说明原因 |
| “这是个馊主意” | Desire(意愿) | 解决顾虑,让他们参与方式设计 |
| “我不知道该怎么做” | Knowledge(知识) | 培训、文档、开放答疑时间 |
| “我总是回到旧习惯” | Ability(能力) | 安排练习时间、减轻工作量、提供支持 |
| “我们开始了,但后来停下来了” | Reinforcement(巩固) | 衡量进展、表彰认可、淘汰旧方式 |
ADKAR 实施时间线
| 周 | 阶段 | 关键活动 |
|---|---|---|
| -4 | 认知准备 | 确定利益相关者,起草沟通内容 |
| -2 | 启动认知阶段 | CEO/领导发布视频,说明原因 |
| -1 | 建立意愿 | 举办顾虑讨论会、消除担忧、让大家参与方式设计 |
| 0 | 知识 + 正式上线 | 培训、文档、上线 |
| 1-2 | 能力支持 | 开放答疑时间、服务台、减轻工作量 |
| 3-4 | 能力 + 初期巩固 | 检查采纳情况、公开展示成果、收集反馈 |
| 6-8 | 全面巩固 | 淘汰旧方式、衡量采纳情况、予以认可 |
阻力模式与应对
抵触诊断矩阵
| 模式 | 他们说的话 | 传递的信号 | 应对方式 |
|---|---|---|---|
| 公开反对 | “这行不通” | 认知或可信度存在差距 | 提供证据,承认顾虑 |
| 质疑时机 | “为什么是现在?” | 认知存在差距 | 说明紧迫性和拖延的代价 |
| 抱怨流程 | “没人征求我的意见” | 缺乏意愿 | 表示理解,并让他们现在参与讨论如何推进 |
| 以能力不足为由 | “我没时间” | 能力存在差距 | 减轻工作量或延长时间线 |
| 提及过去经历 | “我们以前试过” | 信任存在差距 | 说明这次有什么不同 |
| 默默不配合 | [没有口头反对,只是不做改变] | 可能处于任一阶段 | 进行一对一沟通以诊断问题 |
| 恶意敷衍执行 | [形式上照做,实际却从中作梗] | 意愿存在严重差距 | 直接沟通,了解真正的顾虑 |
抵触应对决策树
START: Resistance detected
|
v
[Is it vocal or silent?]
|
+-- VOCAL --> Good. They care enough to push back.
| |
| v
| [Is the concern valid?]
| |
| +-- YES --> Modify the change. Resistance is information.
| +-- NO --> Address with data and empathy. Do not dismiss.
|
+-- SILENT --> Dangerous. Could be any ADKAR phase.
|
v
[1:1 conversation with specific questions]
"What concerns you about this change?"
"What would need to be true for this to work for you?"
"What support would help?"
应对抵触最糟糕的方式
“有些人就是抗拒改变。”
这把抵触视为性格缺陷,而不是一种信号。每种抵触模式都表明 ADKAR 的某个阶段存在问题。先诊断,再应对。
变革沟通框架
沟通顺序
| 受众 | 顺序 | 渠道 | 内容 |
|---|---|---|---|
| 领导团队 | 第 1 位 | 线下/视频会议 | 完整背景+他们在推行过程中的职责 |
| 直接受影响的员工 | 第 2 位 | 经理一对一沟通或小组会议 | 个人影响+可获得的支持 |
| 全体员工 | 第 3 位 | 全员大会或书面通知+问答 | 原因+内容+时间线+常见问题 |
| 外部利益相关者 | 第 4 位(如适用) | 合适的渠道 | 仅提供必要信息 |
沟通模板(CEO/领导者公告)
Structure:
1. What is changing (1-2 sentences, direct)
2. Why it is changing (the business reason -- honest)
3. What this means for you (practical impact)
4. What is NOT changing (stability anchor)
5. Timeline (specific dates)
6. How to ask questions (channel, person, office hours)
7. What happens next (first concrete step)
不同变革类型的沟通节奏
| 变革类型 | 预先通知 | 发布日 | 第 1 周 | 第 1 个月 | 第 3 个月 |
|---|---|---|---|---|---|
| 流程 | 提前通知负责人 | 全员邮件 | 发布常见问题 | 检查采用情况 | 停用旧方式 |
| 组织 | 与受影响人员一对一沟通 | 同步会议 | 常见问题+经理一对一沟通 | 回顾总结 | 健康状况检查 |
| 战略 | 领导层达成共识 | 含问答环节的全员大会 | 团队层面说明“这意味着什么” | 证明资源到位 | 第一个里程碑 |
| 文化 | 收集意见 | 以故事为基础的公告 | 行为准则 | 绩效评估体现相关要求 | 持续推进 |
变革疲劳
疲劳迹象检测
| 信号 | 严重程度 | 应对方式 |
|---|---|---|
| 公告期间翻白眼 | 早期 | 承认变革节奏,并展示先前变革的成果 |
| 变革会议出席率低 | 中等 | 允许自愿参加,但让成果清晰可见 |
| 表面迅速合规,实际采用缓慢 | 严重 | 暂停非关键变革 |
| 评论“又来了” | 严重 | 审查变革清单,传达稳定性 |
| 完全不投入 | 危急 | 暂停变革,重建信任 |
预防变革疲劳的规则
| 规则 | 执行方式 |
|---|---|
| 有始有终 | 在上一项变革尚未被吸收时,不启动新的变革 |
| 一次只进行一项重大变革 | 重大变革之间间隔 2-3 个月 |
| 明确说明保持不变的内容 | 明确说明哪些内容不会改变 |
| 展示成果 | 启动下一项变革前,公布上一项变革的成果 |
| 变革预算 | 将组织注意力视为有限资源 |
变革清单
启动任何新变革之前,先列出所有正在进行的变革:
| 变革 | 阶段 | 开始日期 | 吸收率 | 能否暂停? |
|---|---|---|---|---|
| 新 CRM 推行 | 能力 | 2 周前 | 60% | 否 |
| 工程团队重组 | 意愿 | 1 个月前 | 40% | 是 |
| 价值观更新 | 强化 | 3 个月前 | 75% | 否 |
规则:如果有 3 项或更多变革正在进行,且吸收率低于 70%,则不要再增加新的变革。
Playbook 1:流程变更
时间线:4-8 周 | 最难阶段:能力
| 周 | 活动 | 负责人 |
|---|---|---|
| -2 | 宣布 WHY + 上线日期 | 变更发起人 |
| -1 | 开放培训课程 | 变更团队 |
| 0 | 正式上线 + 提供支持人员 | 变更团队 |
| 2 | 检查采用情况:谁在使用,谁没有 | 变更团队 |
| 4 | 收集反馈 + 公开分享成果 | 变更发起人 |
| 8 | 弃用旧系统 | IT + 变更团队 |
Playbook 2:组织变更
时间线:3-6 个月 | 最难阶段:意愿
| 时间 | 活动 | 负责人 |
|---|---|---|
| 第 0 天 | 宣布变更并说明 WHY——优先采用同步、面对面的方式 | CEO/领导者 |
| 第 1 天 | 由直属经理与受影响最大的人进行一对一沟通 | 经理 |
| 第 1 周 | 发布 FAQ,提供坦诚的回答 | HR + 变更团队 |
| 第 2-4 周 | 按新架构开展工作(不要拖延) | 所有领导者 |
| 第 2 个月 | 首次回顾 | 变更团队 |
| 第 3-6 个月 | 定期健康检查 | HR |
关于领导者离职该怎么说:坦诚说明你能分享的信息。不要只说“我们不能分享原因”,却不说明你能说的、这对团队意味着什么。
Playbook 3:战略转向
时间线:3-12 个月 | 最难阶段:认知
| 时间 | 活动 | 负责人 |
|---|---|---|
| 宣布前 | 领导层达成共识(所有人必须步调一致) | CEO |
| 第 0 天 | 先进行内部宣布(员工优先于媒体) | CEO |
| 第 1 周 | 在团队层面讨论“这对我们意味着什么” | 团队负责人 |
| 第 2 周 | 宣布资源重新分配 | CFO + COO |
| 第 1 个月 | 新方向的首个里程碑清晰可见 | 相关领导者 |
| 持续进行 | 定期更新新方向的进展 | CEO |
扼杀战略转向的因素:宣布新方向的同时,仍以同等力度为旧方向提供资金。重新分配资源,否则转向就不是真正的转向。
Playbook 4:文化变革
时间线:12-24 个月 | 最难阶段:强化
| 阶段 | 活动 | 时间线 |
|---|---|---|
| 输入 | 邀请有代表性的群体参与定义变革 | 第 1-2 个月 |
| 宣布 | 以故事为基础的宣布,并列出观察到的行为 | 第 2 个月 |
| 锚定 | 为每项文化变革定义可观察的行为 | 第 2-3 个月 |
| 示范 | 领导团队率先清晰地示范新行为 | 第 3 个月起 |
| 融入 | 在绩效评估中纳入新行为 | 下一个评估周期 |
| 庆祝 | 观察到新行为时,公开予以表扬 | 持续进行 |
采用情况衡量
采用 vs. 遵从
| 维度 | 遵从 | 采用 |
|---|---|---|
| 行为 | 被监督时才这样做 | 因为这样做更好而主动这样做 |
| 持续时间 | 放松执行后就会回到原状 | 无需强制也能持续 |
| 态度 | 不情愿 | 愿意或积极主动 |
| 来源 | 外部压力 | 内心认同 |
只有强化才能促成采用。遵从是强制执行的结果。目标应是实现采用。
采用指标
| 指标 | 衡量方式 | 目标 |
|---|---|---|
| 使用率 | 积极使用新流程/工具的人数占比 | 第 8 周前 > 80% |
| 回归率 | 回到旧方式的人数占比 | < 10% |
| 满意度 | 调查:“新方式更好吗?” | > 60% 表示赞同 |
| 速度 | 按新旧方式完成任务所需的时间 | 第 4 周前新方式更快 |
| 支持请求 | 求助请求数量 | 逐周下降 |
危险信号
- 在周五下午宣布变更——人们会在整个周末反复琢磨
- 以“这是最终决定,不欢迎提问”的方式表述——会引发暗中抵制
- 没有发布常见问题解答,也没有安全提问的渠道——疑虑得不到解决
- 上线 6 周后旧系统仍在运行——变更并未真正落实
- 要求所有人做出改变的领导者却不受变更约束——会摧毁公信力
- 没有衡量采用情况——想当然地认为上线就等于成功
- 多项重大变更同时进行——必然造成变更疲劳
- 变更后没有回顾——缺少反馈闭环
- 宣布变更时没有指定负责人——没有人对成功负责
与高管层的协作
| 当……时 | 变革管理与……协作 | 以便…… |
|---|---|---|
| 流程变更 | COO(coo-advisor) | 在宣布前设计新流程 |
| 组织架构重组 | CHRO + CEO | 评估对人员的影响并进行沟通 |
| 战略转向 | CEO(ceo-advisor) | 确保一致并制定叙事 |
| 文化变革 | Culture Architect(culture-architect) | 将价值观转化为行为 |
| 工具迁移 | CTO(cto-advisor) | 制定技术推广计划 |
| 运营系统变更 | Company OS(company-os) | 建立新的节奏和周期 |
| 变更后的协同一致 | Strategic Alignment(strategic-alignment) | 确认变更后的层层传达效果 |
输出成果
| 请求 | 交付内容 |
|---|---|
| “规划变更推广” | 基于 ADKAR 的变更计划,包含时间表和负责人 |
| “我们要进行组织架构重组” | 组织变更手册,包含沟通计划 |
| “管理对 [变更] 的抵制” | 抵制原因诊断 + 针对性应对措施 |
| “我们是否出现了变更疲劳?” | 变更清单 + 疲劳评估 + 建议 |
| “[变更] 的沟通计划” | 按顺序安排的沟通计划,包含模板 |
| “衡量 [变更] 的采用情况” | 采用情况指标仪表板,包含目标 |
工具参考
change_readiness_assessor.py
使用 ADKAR 模型评估组织的准备情况,识别抵制模式,衡量变更疲劳,并制定干预计划。
# Run with demo data
python scripts/change_readiness_assessor.py
# Specify change type
python scripts/change_readiness_assessor.py --type org
# From JSON assessment data
python scripts/change_readiness_assessor.py --input assessment.json
# JSON output
python scripts/change_readiness_assessor.py --json
adoption_tracker.py
跟踪使用率、回退率、满意度和支持请求,以区分真正的采用与表面上的遵从。
# Run with demo data
python scripts/adoption_tracker.py
# From JSON with weekly data
python scripts/adoption_tracker.py --input adoption_data.json
# JSON output
python scripts/adoption_tracker.py --json
communication_planner.py
生成按受众排序的沟通计划,包含模板、渠道建议和时间安排。
# Generate for process change
python scripts/communication_planner.py --type process --name "New CRM Rollout" --date 2026-04-15
# Generate for org change
python scripts/communication_planner.py --type org --name "Engineering Restructure"
# From JSON
python scripts/communication_planner.py --input comm_plan.json
# JSON output
python scripts/communication_planner.py --type strategy --json
故障排除
| 问题 | 可能原因 | 解决方法 |
|---|---|---|
| 使用率高但满意度低 | 只是遵从而非真正采用——人们是被迫使用的 | 调查影响满意度的因素;不要只依赖强制执行;改进工具或流程本身 |
| 采用率停滞在 60-70% | 剩余的 30% 存在尚未解决的 ADKAR 缺口(通常是能力方面) | 按群体细分未采用者;开展一对一诊断;提供有针对性的支持 |
| 变更在上线几周内就回退 | 跳过了强化阶段;旧系统仍可访问 | 移除旧系统的访问权限;衡量并认可新行为;将其纳入绩效评估 |
| 领导者不受变更约束 | “只许州官放火,不许百姓点灯”的模式 | 领导者必须率先行动,并让大家看见。不得例外。这是摧毁公信力的头号因素 |
| 多项变更同时进行且都进展不顺 | 变更疲劳——组织注意力已耗尽 | 列出所有正在进行的变更;暂停非关键变更;将重大变更间隔 2-3 个月 |
| 已有沟通计划,但疑虑仍然存在 | 沟通只是单向广播,没有反馈渠道 | 增加问答环节、指定联系人和匿名反馈渠道 |
成功标准
- 上线前 ADKAR 准备度评分高于 70/100(通过 change_readiness_assessor.py 测量)
- 上线后 8 周内采用率超过 80%(衡量实际使用情况,而非仅看是否遵守要求)
- 第 8 周时回退率低于 10%(通过系统使用数据测量)
- 第 8 周时,满意度调查显示 60% 以上的受访者认同“新方式更好”
- 第 2 周后,支持请求逐周减少(表明能力阶段正在见效)
- 不在周五下午宣布变更(通过沟通日志时间戳测量)
- 在变更后 90 天内开展回顾,并记录经验教训
范围与限制
范围内:基于 ADKAR 的准备度评估、阻力诊断与应对、变更疲劳度量、沟通规划与排序、采用情况跟踪,以及针对流程、组织、战略和文化变更的操作手册。
范围外:具体工具迁移的执行(CRM、ERP 配置)、员工裁减方面的法律合规、工会谈判、劳动法、个人辅导或治疗。
限制:ADKAR 评分基于评估输入,反映的是感知,而非客观测量。大多数指标需要手动收集数据才能进行采用情况跟踪。沟通规划工具提供模板,但无法考虑公司的特定政治动态。变更疲劳评估仅供参考;实际组织承载能力因公司文化而异。
集成点
| 技能 | 集成 |
|---|---|
coo-advisor | 宣布变更前设计流程变更;做好运营准备 |
chro-advisor | 评估人员影响;为组织重组安排沟通顺序 |
ceo-advisor | 确保战略转向叙事一致;由 CEO 担任主要沟通者 |
culture-architect | 制定文化变更操作手册;将价值观转化为行为 |
company-os | 新 OS 推行遵循 ADKAR 模型;调整会议节奏 |
chief-of-staff | 转交变更管理问题;协调跨职能团队达成一致 |
strategic-alignment | 验证变更后的目标逐级分解;确认新方向已体现在 OKR 中 |