关于 change-management-plan
这项技能为组织变革制定结构化管理计划,供发起人和变革经理使用。它涵盖利益相关者、沟通与培训、阻力应对及上线后的采用情况追踪。
主要功能
- 01变革与利益相关者分析
- 02影响评估
- 03沟通计划
- 04培训与阻力管理计划
- 05采用指标和里程碑
适用场景
- 01规划系统或流程的推出
- 02帮助经理传达组织变革信息
- 03追踪变革上线后的采用情况
安装
复制下面的命令,在终端中运行。
$
npx skills add https:/ / github.com/ mohitagw15856/ pm-claude-skills --skill change-management-plan安装后在 Claude Code 中输入/change-management-plan确认已加载。
详细介绍
变更管理计划 Skill
制定结构化的变更管理计划——因为大多数变更计划失败,并非变更本身有问题,而是人们没有得到充分引导,未能跟上变更。
必需输入
根据已提供的信息开展工作。若缺少以下任一信息,仍需生成完整内容:用合理假设填补每处空缺,并标注 (假设,需确认),并在末尾列出这些假设。只有在核心主题本身缺失(无内容可写)时,才先提问。
- 变更内容(什么将发生变化?当前状态是什么?)
- 规模(影响多少人?涉及多少个团队/地点?)
- 时间线(变更何时上线?过渡期有多长?)
- 发起人(谁在高层负责?)
- 关键顾虑(采用变更的最大风险是什么?)
- 变更失败的后果(采用率低会造成什么后果?)
输出结构
变更管理计划:[变更名称]
变更发起人: [执行负责人] 变更经理: [负责推进此事的人] 上线日期: [日期] 受影响人群: [N 人,N 个团队/地点]
1. 变更摘要
从(当前状态): [对当前情况的具体描述] 到(未来状态): [对变更内容的具体描述] 变更原因: [坦诚说明原因——人们了解真实原因后,会更快接受变更] 保持不变的内容: [明确说明哪些内容不会改变,以减轻焦虑]
2. 利益相关者分析
| 利益相关者群体 | 人数 | 影响程度 | 当前态度 | 他们的需求 |
|---|---|---|---|---|
| [群体] | [N] | 高/中/低 | 支持/中立/抵触 | [具体顾虑或需求] |
需要尽早沟通的关键影响者: [列出非正式领导者、受尊敬的人士和早期采用者,他们可以提供帮助。也要列出需要直接关注的抵触者。]
3. 影响评估
| 领域 | 影响 | 严重程度 | 所需行动 |
|---|---|---|---|
| 日常工作流 | [日常工作会有哪些变化] | 高/中/低 | [培训/支持/重新设计] |
| 系统或工具 | [哪些工具会受到影响] | ||
| 角色和职责 | [角色是否有变化] | ||
| 流程 | [流程变化] | ||
| 指标和目标 | [KPI 是否有变化] |
4. 沟通计划
核心信息: [所有人都应理解并记住的一句话摘要]
| 受众 | 信息重点 | 渠道 | 时间 | 负责人 |
|---|---|---|---|---|
| 全体员工 | [变更原因+预期情况] | 全员会议/电子邮件 | [上线前 6 周] | 发起人 |
| 经理 | [如何支持团队] | 经理简报会 | [上线前 5 周] | 变更经理 |
| 直接受影响的团队 | [对他们具体有哪些变化] | 团队会议 | [上线前 4 周] | 直属经理 |
| [其他群体] | [针对性信息] |
沟通原则:
- 多沟通——人们需要听到一条信息 7 次才能内化
- 利用经理逐级传达,而不只是自上而下发布公告
- 建立反馈渠道——问题得不到解答,就会变成谣言
5. 培训和支持计划
| 受众 | 培训类型 | 时间 | 时长 | 形式 | 负责人 |
|---|---|---|---|---|---|
| [群体] | [例如,系统实操培训] | [上线前 2 周] | [2 小时] | [线下/线上] | [负责人] |
上线支持:
- [第 1 天可提供哪些支持——帮助台、现场巡查人员、倡导者]
- [前 30 天的问题升级路径]
6. 抵触情绪管理
预期的抵触来源:
| 顾虑 | 持有者 | 根本原因 | 应对措施 |
|---|---|---|---|
| [例如:“这会增加我的工作量”] | [中层管理者] | [自主权受损] | [采取具体措施来应对] |
抵触情绪管理原则:
- 真诚地承认顾虑——轻视抵触情绪只会使其加剧
- 尽可能让抵触者参与设计——将他们转变为倡导者
- 区分真正的顾虑(值得解决)和偏好维持现状(需要管理,而非解决)
7. 采用指标
| 指标 | 基线 | 目标 | 测量时间点 | 负责人 |
|---|---|---|---|---|
| [系统使用率] | [0%] | [80%] | [上线后 30 天] | [负责人] |
| [流程合规率] | [X%] | [Y%] | [60 天] | [负责人] |
| [员工信心评分] | [调查评分] | [目标] | [90 天] | [负责人] |
采用里程碑:
- D+7:[首次检查——发现早期问题]
- D+30:[首次采用情况评审]
- D+90:[确认持续采用,或启动补救计划]
质量检查
- 明确说明“哪些方面保持不变”
- 利益相关者分析涵盖抵触者,而不只是支持者
- 沟通计划通过管理者逐级传达(而非仅自上而下)
- 培训安排在上线之前(而非之后)
- 采用指标列明测量日期和负责人
- 抵触情绪管理包含具体应对措施(而不只是“加强沟通”)
反模式
- 不要把沟通当作一次性公告——人们需要多次听到同一信息才会真正理解;应规划反复触达
- 不要在未让直线经理参与的情况下,将变更管理交给单一负责人——经理是最有效的逐级传达渠道,必须先于团队接受简报
- 不要把培训安排在上线之后——在需要使用新系统的当天才学习的人会退回旧流程
- 不要在利益相关者分析中忽视抵触者——未被明确沟通的抵触者会破坏采用,尤其是非正式领导者
- 不要只在上线时衡量采用情况——真正的考验是 90 天后的持续采用,此时新鲜感已消退
示例触发语
- “为 [计划] 撰写变更管理计划”
- “帮我规划面向 [团队/组织] 的 [系统变更] 推出方案”
- “为 [变更] 制定沟通和培训计划”
- “如何管理对 [变更] 的抵触?”
评论
支持 Markdown