mcpField
C
change-management

change-management

github.com/alirezarezvani其他28.9k621 次安装2 天前更新
代码仓库

关于 change-management

面向创业团队的变革管理技能,将 ADKAR 用于流程变更、组织调整、战略转向和文化变化。内容涵盖沟通、阻力诊断、采纳与变革疲劳管理。

主要功能

  1. 01适配创业团队的 ADKAR 指南
  2. 02四类变革的行动方案
  3. 03变革阻力模式诊断
  4. 04变革疲劳预防
  5. 05沟通与推进步骤

适用场景

  1. 01规划工具或流程迁移
  2. 02沟通组织架构调整
  3. 03应对战略转向阻力
  4. 04减少多项变革带来的疲劳

安装

复制下面的命令,在终端中运行。

$npx skills add https://github.com/alirezarezvani/claude-skills --skill change-management

安装后在 Claude Code 中输入/change-management确认已加载。

附带文件references/change-playbook.md

详细介绍

变更管理手册

大多数变更失败于执行阶段,而非设计阶段。ADKAR 模型能告诉你原因,并给出修复方法。

关键词

change management, ADKAR, organizational change, reorg, process change, tool migration, strategy pivot, change resistance, change fatigue, change communication, stakeholder management, adoption, compliance, change rollout, transition

核心模型:面向初创公司的 ADKAR

ADKAR 是 Prosci 提出的变更管理模型。原版面向大型企业。这里是适合初创公司节奏的改编版本。

A — 认知(Awareness)

含义: 人们理解变更为什么发生,即业务原因,而不只是通知本身。

常见错误: 在说明 WHY 之前就先讲 WHAT。比如,还没说明"我们现有的流程正在拖垮我们",就先宣布"我们要换新的 CRM"。

人们需要听到的内容:

  • 我们要解决什么问题?(请坦诚。如果原因是"我们需要降本",就直说。)
  • 为什么是现在?如果不变,会发生什么?
  • 这个决定是谁做的,又是如何做出的?

初创公司捷径: 由 CEO 或决策者录制一段 5 分钟视频,用平实的语言解释"为什么",每次都比正式的变更公告文档更有效。


D — 意愿(Desire)

含义: 人们愿意推动变更发生,或者至少不会积极抵制。

常见错误: 以为沟通就能产生意愿。认知 ≠ 意愿。人们可以理解一项变更,同时又非常讨厌它。

什么能激发意愿:

  • "这对我有什么好处?"——针对每一类利益相关者,坦诚地回答这个问题
  • 即使"做什么"已经定好,也让人们参与"怎么做"的讨论
  • 直接回应担忧:"有些人担心这意味着他们的角色会改变。事实是:[坦诚的回答]"

什么会消磨意愿:

  • 把变更描述得比实际上对每个人都更好
  • 无视人们将真实承受的损失
  • 在没有任何征询的情况下直接发布公告

初创公司捷径: 在公告发布后 48 小时内组织一次简短的"顾虑与问题"会议。目的不是撤回决定,而是回应担忧,并表明你在倾听。


K — 知识(Knowledge)

含义: 人们知道如何在新环境中工作,即具体的技能、行为和流程。

常见错误: 宣布变更后,假定人们自己会搞明白。

人们需要什么:

  • 新流程的分步文档
  • 上线前的培训或练习课
  • 对"遇到[常见场景]时我该怎么做?"的清晰解答
  • 卡住时该找谁

知识转移的方式:

方式最适合时机
现场培训技能型变更、复杂工具上线前
文档流程变更、参考资料始终提供
视频演示工具迁移全天候可用,自主学习
旁观学习 / 同伴学习行为变更上线后第 2–4 周
答疑时间边缘情况较多的任何变更前 4–6 周

A — 能力(Ability)

含义: 人们拥有时间、工具和支持,能够真正做出不同的做法。

常见错误:"我们已经培训过所有人"≠"所有人现在都能做到"。培训是知识,能力则需要通过实践获得。

什么能建立能力:

  • 在接受评估之前有时间练习
  • 允许犯错的安全环境(不对早期的挣扎进行公开批评)
  • 在过渡期减轻负担(如果要求人们学习新技能,就不要同时额外堆加新工作)
  • 能够获得帮助(例如 Slack 频道、联络人、文档)

能力缺口的信号:

  • 人们在压力下退回旧的行为
  • 出现变通办法(人们自行发明绕开新系统的方式)
  • 培训成绩很高,但实际行为并未改变

R — 强化

它是什么: 变化要能固化下来,新行为成为默认做法。

常见错误: 在上线当天就宣布胜利。变化之所以失败,往往是因为从未得到强化。

什么能带来强化:

  • 可见的度量(我们是否在跟踪采用情况?)
  • 表彰早期采用者("Sarah 在第 2 周就完全迁移到了新工作流——可以问问她是怎么做到的")
  • 领导示范(如果 CEO 仍在用旧方式,所有人都会照做)
  • 移除旧选项(条件允许时——消除阻力最小的路径)
  • 对不采用的后果(明确说明,并始终如一地执行)

采用与合规:

  • 合规: 人们在被监督时照做,无人监督时就恢复原样
  • 采用: 人们照做是因为相信它更好

只有强化才能带来采用。合规是强制执行的结果。应以采用为目标。


变革类型与 ADKAR 的应用

流程变更(新工具、新工作流)

时间线: 4–8 周实现完全采用 最难的阶段: 能力(人们知道该做什么,但还没有养成习惯) 关键强化措施: 移除或弃用旧工具/旧流程

沟通节奏:

  1. 第 -2 周:宣布原因及上线日期
  2. 第 -1 周:提供培训课程
  3. 第 0 周(上线):正式启用,并安排联络负责人随时答疑
  4. 第 2 周:采用情况检查(谁在用?谁没在用?)
  5. 第 4 周:收集反馈,公开宣传成功案例
  6. 第 8 周:弃用旧系统

组织变更(重组、新领导、团队拆分或合并)

时间线: 3–6 个月实现完全稳定 最难的阶段: 意愿(人们担心自己的角色和人际关系) 关键强化措施: 新领导持续表现出一致的行为

沟通节奏:

  1. 第 0 天:当面或通过同步视频宣布变更,并说明"原因"
  2. 第 1 天:由各自经理与大多数受影响的团队成员进行一对一沟通
  3. 第 1 周:发布常见问题解答,坦诚回应十个最常见的顾虑
  4. 第 2–4 周:新结构开始运作(不要推迟实施)
  5. 第 2 个月:首次复盘——哪些方面运转良好,哪些需要调整
  6. 第 3–6 个月:定期检查团队健康状况与士气

领导离任或被替换时该怎么说: 对能够分享的内容保持坦诚。切忌说:"我们不能说明原因。"应始终选择以下之一:如实说明原因,或说"具体细节我们暂时无法分享,但我可以告诉你这对你意味着什么"。


战略转向(新方向、产品下线)

时间线: 3–12 个月实现完全对齐 最难的阶段: 认知(人们不相信这次转向是真的) 关键强化措施: 资源重新分配,并以明显可见的方式证明转向正在发生

沟通节奏:

  1. 始终先对内沟通。员工不应该从新闻稿中得知战略转向。
  2. 召开全员会议,完整说明背景:市场发生了什么变化,你们在做什么,这对各团队意味着什么
  3. 每位团队负责人与团队开展一次"这对我们意味着什么?"的讨论
  4. 在 2 周内宣布资源重新分配(如果资金没有变动,人们不会相信转向是真的)
  5. 公开庆祝新方向的第一个里程碑

什么会让转向失败: 一边宣布新方向,一边仍以同样的力度为旧方向投入资金。


文化变革(价值观更新、行为期望)

时间线: 真正的行为改变需要 12–24 个月 最困难的阶段: 强化(仅仅宣布价值观,行为并不会随之改变) 关键强化手段: 体现新价值观的可见决策

沟通顺序:

  1. 集思广益:让公司有代表性的一部分人参与定义这场变革
  2. 用故事宣布:“这是我们观察到的情况,这是我们要做的改变以及原因”
  3. 行为锚点:针对每项文化变革,用可观察的具体语言描述所期望的行为
  4. 领导层示范:管理团队必须率先明确地践行新行为
  5. 绩效融合:新的期望行为在一个评估周期内纳入绩效评审
  6. 表彰正确的行为:当有人体现新文化时,公开点名表扬

抵触模式

抵触是一种信号,而非对抗。先诊断,再应对。

抵触模式它意味着什么应对方式
“这行不通”认知差距或可信度差距解释支持该变革的证据基础
“为什么是现在?”认知差距说明紧迫性——如果不改变会发生什么
“没有人征求我的意见”意愿差距承认这一差距;现在就让他们参与“如何做”的环节
“我没有时间做这个”能力差距减轻他们的工作负担,或推迟时间表
“我们以前试过”信任差距说明这次有哪些不同。要具体。
沉默的不合规可能是任何一种差距进行一对一谈话以诊断原因

应对抵触最糟糕的做法: 无视它。把抵触当作人格缺陷而非信号,比如说“有些人就是抗拒变化”。


变革疲劳

当组织变化过快时,人们会不再相信任何变革能够持久。

信号
  • 变革公告期间的翻白眼(“又来了”)
  • 变革相关会议的出席率低
  • 纸面上合规很快,实际采纳很慢
  • “上个月我们还在做 X,现在又改成做 Y 了”之类的评论
预防
  • 做完再开始。 在上一项变革尚未被消化之前,不要宣布新的变革。
  • 拉开变革间隔。 一次只推进一项重大变革。在重大变革之间留出 2–3 个月的稳定期。
  • 宣布哪些不会改变。 处于变革疲劳中的人需要知道什么是稳定的。
  • 展示成果。 在启动下一项变革之前,公布上一项变革取得的成效。
如果已经处于变革疲劳之中
  • 暂停非关键性变革
  • 进行一次“变革盘点”:目前同时有多少项变革在进行?
  • 严格排定优先级:哪些变革现在必须做?哪些可以等待?
  • 传递稳定感:“本季度不会改变的是以下内容”

变革管理的关键问题

  • “对这项变革最持怀疑态度的是哪些人?我们是否已经直接与他们沟通?”
  • “人们理解我们为什么这样做,还是只知道我们在做什么?”
  • “在我们根据新方式衡量绩效之前,是否已经给了人们练习的时间?”
  • “旧方式是否仍然可用?如果可用,人们就会继续使用它。”
  • “领导者自己是否在践行新行为?”
  • “我们目前同时在推进多少项变革?”

危险信号

  • 在周五下午宣布变革(人们会在周末焦虑不安)
  • “这是最终决定,不接受提问”的表述方式
  • 没有公开的常见问题解答,也没有安全的提问渠道
  • “上线”六周后,旧系统或旧流程仍在运行
  • 领导者被豁免于他们要求其他人执行的变革
  • 不衡量采纳情况,默认上线即成功

详细参考

  • references/change-playbook.md — ADKAR 深入解析、抵触应对策略、沟通模板、变革疲劳管理

评论

支持 Markdown