[font=微软雅黑][size=3]那次流程协调会，我差点把笔掰断。[/size][/font]
[font=微软雅黑][size=3] 事件处理流程明明写得清清楚楚，可一个P1故障却拖了四个小时没人闭环。[/size][/font]
[font=微软雅黑][size=3] 安全组说是应用问题，应用组说要等运维排查，运维组说“我们只执行变更”。[/size][/font]
[font=微软雅黑][size=3] 最后我忍不住问了一句：“那谁负责解决？”[/size][/font]
[font=微软雅黑][size=3] 全场沉默。[/size][/font]
[font=微软雅黑][size=3]其实流程一点都没错，错的是——没人真的“对号入座”。[/size][/font]
[font=微软雅黑][size=3]
[/size][/font]
[align=center][/align]
[font=微软雅黑][size=3]
[/size][/font]
[font=微软雅黑][size=3]
[/size][/font]
[b][font=微软雅黑][size=3]一、冲突：当流程比人聪明[/size][/font][/b]
[font=微软雅黑][size=3]
[/size][/font]
[font=微软雅黑][size=3]我见过太多企业的ITSS项目陷入这种怪圈：[/size][/font]
[font=微软雅黑][size=3] 流程文档比人清醒，图表比会议还详细，可落地时一团乱。[/size][/font]
[font=微软雅黑][size=3] 原因往往只有一个——组织架构没跟上。[/size][/font]
[font=微软雅黑][size=3]那家企业自信地通过了ITSS三级评估，[/size][/font]
[font=微软雅黑][size=3] 但上线半年后，他们的服务目录形同虚设。[/size][/font]
[font=微软雅黑][size=3] 为什么？因为没人知道谁该为哪块服务负责。[/size][/font]
[font=微软雅黑][size=3] 事件管理有了值班表，但没人维护；[/size][/font]
[font=微软雅黑][size=3] 变更流程有审批链，但CAB开会无人到场。[/size][/font]
[font=微软雅黑][size=3]
[/size][/font]
[font=微软雅黑][size=3]ITSS不是写给系统的，而是写给人的。[/size][/font]
[font=微软雅黑][size=3] 如果角色没定清楚，流程再标准也只是“漂亮的幻觉”。[/size][/font]
[font=微软雅黑][size=3]我在会上问他们：“你们的服务负责人（Service Owner）是谁？”[/size][/font]
[font=微软雅黑][size=3] 有人回答：“我们是扁平化团队，没有明确划分。”[/size][/font]
[font=微软雅黑][size=3] 我笑了：“那你们其实不是扁平，而是散装。”[/size][/font]
[font=微软雅黑][size=3]
[/size][/font]
[font=微软雅黑][size=3]
[/size][/font]
[b][font=微软雅黑][size=3]二、反思：职责不清，流程再好也白搭[/size][/font][/b]
[font=微软雅黑][size=3]
[/size][/font]
[font=微软雅黑][size=3]那次会议后我彻夜没睡。 我在想，为什么我们这些年讲ITSS讲了那么多流程，却总有人跑不起来？ 后来我明白了——[b]流程只是骨架，职责是肌肉。[/b][/size][/font]
[font=微软雅黑][size=3]组织架构的问题，不在于人多或人少，而在于边界。[/size][/font]
[font=微软雅黑][size=3] 每个人都想做“支撑者”，没人愿意做“责任人”。[/size][/font]
[font=微软雅黑][size=3] 没有明确的职责矩阵，沟通再多也解决不了问题。[/size][/font]
[font=微软雅黑][size=3]我开始重新梳理他们的组织结构。[/size][/font]
[font=微软雅黑][size=3] 从服务视角出发，不再以部门为核心，而是以“流程角色”为核心。[/size][/font]
[font=微软雅黑][size=3]
[/size][/font]
[font=微软雅黑][size=3] 我们在白板上画出RACI矩阵：[/size][/font]
[list]
[*][font=微软雅黑][size=3][b]R（Responsible）[/b]：谁真正执行；[/size][/font]
[*][font=微软雅黑][size=3][b]A（Accountable）[/b]：谁最终负责；[/size][/font]
[*][font=微软雅黑][size=3][b]C（Consulted）[/b]：谁要被征询；[/size][/font]
[*][font=微软雅黑][size=3][b]I（Informed）[/b]：谁需要被告知。[/size][/font]
[/list][font=微软雅黑][size=3]就这四个字母，让团队第一次明白，[/size][/font]
[font=微软雅黑][size=3] “做”与“负责”其实是两回事。[/size][/font]
[font=微软雅黑][size=3]本文由艾拓先锋ITSS官方授权认证培训讲师熊健淞原创，未经许可谢绝转载。[/size][/font]
[font=微软雅黑][size=3] 我常在课堂上举这个例子：当RACI不清时，任何流程都会演变成“互相等待”的循环。[/size][/font]
[font=微软雅黑][size=3] 但一旦人和职责绑到位，流程反而变轻，决策变快，效率也自然提升。[/size][/font]
[font=微软雅黑][size=3]
[/size][/font]
[font=微软雅黑][size=3]
[/size][/font]
[b][font=微软雅黑][size=3]三、重构：从“部门思维”到“服务思维”[/size][/font][/b]
[font=微软雅黑][size=3]
[/size][/font]
[font=微软雅黑][size=3]我们用了一个月时间，做了三件事：[/size][/font]
[list=1]
[*][font=微软雅黑][size=3][b]角色清单重建[/b] 不再以部门划分，而是以流程视角识别角色—— 服务台、事件经理、变更审批人、配置管理员、发布协调人。 每个角色都有职责描述、汇报路径与交接机制。[/size][/font]
[*][font=微软雅黑][size=3][b]建立治理节奏[/b] 每周一次“流程健康会”，所有流程负责人汇报执行数据。 出现扯皮事件，现场立刻讨论边界，次周更新矩阵。 这不是审查会议，而是“调整会”。 因为ITSS体系不是一劳永逸，而是需要不断修正。[/size][/font]
[*][font=微软雅黑][size=3][b]引入绩效联动机制[/b] 我们将SLA、MTTR、变更成功率等指标嵌入绩效体系。 让每个人都知道，流程执行不是任务，而是业绩。[/size][/font]
[/list][font=微软雅黑][size=3]我记得那位安全主管后来私下跟我说：“原来我们不是缺制度，是缺角色。”[/size][/font]
[font=微软雅黑][size=3] 这句话，我一直记在心里。[/size][/font]
[font=微软雅黑][size=3]
[/size][/font]
[font=微软雅黑][size=3]
[/size][/font]
[b][font=微软雅黑][size=3]四、启示：人对了，流程才会顺[/size][/font][/b]
[font=微软雅黑][size=3]
[/size][/font]
[font=微软雅黑][size=3]半年后，那家企业的流程投诉率下降了70%。[/size][/font]
[font=微软雅黑][size=3] 以前出问题都找“流程不合理”，[/size][/font]
[font=微软雅黑][size=3] 现在出问题先问“谁该处理”。[/size][/font]
[font=微软雅黑][size=3]组织变清晰后，会议变短、决策变快、复盘变真。[/size][/font]
[font=微软雅黑][size=3] 最明显的变化是：大家开始主动跨部门合作。[/size][/font]
[font=微软雅黑][size=3] 因为边界清晰，沟通才有底气。[/size][/font]
[font=微软雅黑][size=3]
[/size][/font]
[font=微软雅黑][size=3][b]我在最后一次项目总结会上说：[/b][/size][/font]
[indent][font=微软雅黑][size=3]“流程跑不动，不是因为制度弱，而是因为人没站对位。”[/size][/font]
[/indent][font=微软雅黑][size=3]ITSS的本质，不是流程比谁多、文档比谁厚，[/size][/font]
[font=微软雅黑][size=3] 而是让人、职责、机制形成一套有机的运行系统。[/size][/font]
[font=微软雅黑][size=3] 当组织学会围绕“服务”而不是“部门”去思考，[/size][/font]
[font=微软雅黑][size=3] 标准才会真正落地。[/size][/font]




[hr]
原始来源：https://itil.org.cn/thread-365031-1-1.html
迁移说明：本文由旧论坛历史帖子迁移至 ITIL 先锋论坛，用于承接旧链接访问。

[font=微软雅黑][size=3]那次流程协调会，我差点把笔掰断。[/size][/font]
[font=微软雅黑][size=3] 事件处理流程明明写得清清楚楚，可一个P1故障却拖了四个小时没人闭环。[/size][/font]
[font=微软雅黑][size=3] 安全组说是应用问题，应用组说要等运维排查，运维组说“我们只执行变更”。[/size][/font]
[font=微软雅黑][size=3] 最后我忍不住问了一句：“那谁负责解决？”[/size][/font]
[font=微软雅黑][size=3] 全场沉默。[/size][/font]
[font=微软雅黑][size=3]其实流程一点都没错，错的是——没人真的“对号入座”。[/size][/font]
[font=微软雅黑][size=3]
[/size][/font]
[align=center][/align]
[font=微软雅黑][size=3]
[/size][/font]
[font=微软雅黑][size=3]
[/size][/font]
[b][font=微软雅黑][size=3]一、冲突：当流程比人聪明[/size][/font][/b]
[font=微软雅黑][size=3]
[/size][/font]
[font=微软雅黑][size=3]我见过太多企业的ITSS项目陷入这种怪圈：[/size][/font]
[font=微软雅黑][size=3] 流程文档比人清醒，图表比会议还详细，可落地时一团乱。[/size][/font]
[font=微软雅黑][size=3] 原因往往只有一个——组织架构没跟上。[/size][/font]
[font=微软雅黑][size=3]那家企业自信地通过了ITSS三级评估，[/size][/font]
[font=微软雅黑][size=3] 但上线半年后，他们的服务目录形同虚设。[/size][/font]
[font=微软雅黑][size=3] 为什么？因为没人知道谁该为哪块服务负责。[/size][/font]
[font=微软雅黑][size=3] 事件管理有了值班表，但没人维护；[/size][/font]
[font=微软雅黑][size=3] 变更流程有审批链，但CAB开会无人到场。[/size][/font]
[font=微软雅黑][size=3]
[/size][/font]
[font=微软雅黑][size=3]ITSS不是写给系统的，而是写给人的。[/size][/font]
[font=微软雅黑][size=3] 如果角色没定清楚，流程再标准也只是“漂亮的幻觉”。[/size][/font]
[font=微软雅黑][size=3]我在会上问他们：“你们的服务负责人（Service Owner）是谁？”[/size][/font]
[font=微软雅黑][size=3] 有人回答：“我们是扁平化团队，没有明确划分。”[/size][/font]
[font=微软雅黑][size=3] 我笑了：“那你们其实不是扁平，而是散装。”[/size][/font]
[font=微软雅黑][size=3]
[/size][/font]
[font=微软雅黑][size=3]
[/size][/font]
[b][font=微软雅黑][size=3]二、反思：职责不清，流程再好也白搭[/size][/font][/b]
[font=微软雅黑][size=3]
[/size][/font]
[font=微软雅黑][size=3]那次会议后我彻夜没睡。 我在想，为什么我们这些年讲ITSS讲了那么多流程，却总有人跑不起来？ 后来我明白了——[b]流程只是骨架，职责是肌肉。[/b][/size][/font]
[font=微软雅黑][size=3]组织架构的问题，不在于人多或人少，而在于边界。[/size][/font]
[font=微软雅黑][size=3] 每个人都想做“支撑者”，没人愿意做“责任人”。[/size][/font]
[font=微软雅黑][size=3] 没有明确的职责矩阵，沟通再多也解决不了问题。[/size][/font]
[font=微软雅黑][size=3]我开始重新梳理他们的组织结构。[/size][/font]
[font=微软雅黑][size=3] 从服务视角出发，不再以部门为核心，而是以“流程角色”为核心。[/size][/font]
[font=微软雅黑][size=3]
[/size][/font]
[font=微软雅黑][size=3] 我们在白板上画出RACI矩阵：[/size][/font]
[list]
[*][font=微软雅黑][size=3][b]R（Responsible）[/b]：谁真正执行；[/size][/font]
[*][font=微软雅黑][size=3][b]A（Accountable）[/b]：谁最终负责；[/size][/font]
[*][font=微软雅黑][size=3][b]C（Consulted）[/b]：谁要被征询；[/size][/font]
[*][font=微软雅黑][size=3][b]I（Informed）[/b]：谁需要被告知。[/size][/font]
[/list][font=微软雅黑][size=3]就这四个字母，让团队第一次明白，[/size][/font]
[font=微软雅黑][size=3] “做”与“负责”其实是两回事。[/size][/font]
[font=微软雅黑][size=3]本文由艾拓先锋ITSS官方授权认证培训讲师熊健淞原创，未经许可谢绝转载。[/size][/font]
[font=微软雅黑][size=3] 我常在课堂上举这个例子：当RACI不清时，任何流程都会演变成“互相等待”的循环。[/size][/font]
[font=微软雅黑][size=3] 但一旦人和职责绑到位，流程反而变轻，决策变快，效率也自然提升。[/size][/font]
[font=微软雅黑][size=3]
[/size][/font]
[font=微软雅黑][size=3]
[/size][/font]
[b][font=微软雅黑][size=3]三、重构：从“部门思维”到“服务思维”[/size][/font][/b]
[font=微软雅黑][size=3]
[/size][/font]
[font=微软雅黑][size=3]我们用了一个月时间，做了三件事：[/size][/font]
[list=1]
[*][font=微软雅黑][size=3][b]角色清单重建[/b] 不再以部门划分，而是以流程视角识别角色—— 服务台、事件经理、变更审批人、配置管理员、发布协调人。 每个角色都有职责描述、汇报路径与交接机制。[/size][/font]
[*][font=微软雅黑][size=3][b]建立治理节奏[/b] 每周一次“流程健康会”，所有流程负责人汇报执行数据。 出现扯皮事件，现场立刻讨论边界，次周更新矩阵。 这不是审查会议，而是“调整会”。 因为ITSS体系不是一劳永逸，而是需要不断修正。[/size][/font]
[*][font=微软雅黑][size=3][b]引入绩效联动机制[/b] 我们将SLA、MTTR、变更成功率等指标嵌入绩效体系。 让每个人都知道，流程执行不是任务，而是业绩。[/size][/font]
[/list][font=微软雅黑][size=3]我记得那位安全主管后来私下跟我说：“原来我们不是缺制度，是缺角色。”[/size][/font]
[font=微软雅黑][size=3] 这句话，我一直记在心里。[/size][/font]
[font=微软雅黑][size=3]
[/size][/font]
[font=微软雅黑][size=3]
[/size][/font]
[b][font=微软雅黑][size=3]四、启示：人对了，流程才会顺[/size][/font][/b]
[font=微软雅黑][size=3]
[/size][/font]
[font=微软雅黑][size=3]半年后，那家企业的流程投诉率下降了70%。[/size][/font]
[font=微软雅黑][size=3] 以前出问题都找“流程不合理”，[/size][/font]
[font=微软雅黑][size=3] 现在出问题先问“谁该处理”。[/size][/font]
[font=微软雅黑][size=3]组织变清晰后，会议变短、决策变快、复盘变真。[/size][/font]
[font=微软雅黑][size=3] 最明显的变化是：大家开始主动跨部门合作。[/size][/font]
[font=微软雅黑][size=3] 因为边界清晰，沟通才有底气。[/size][/font]
[font=微软雅黑][size=3]
[/size][/font]
[font=微软雅黑][size=3][b]我在最后一次项目总结会上说：[/b][/size][/font]
[indent][font=微软雅黑][size=3]“流程跑不动，不是因为制度弱，而是因为人没站对位。”[/size][/font]
[/indent][font=微软雅黑][size=3]ITSS的本质，不是流程比谁多、文档比谁厚，[/size][/font]
[font=微软雅黑][size=3] 而是让人、职责、机制形成一套有机的运行系统。[/size][/font]
[font=微软雅黑][size=3] 当组织学会围绕“服务”而不是“部门”去思考，[/size][/font]
[font=微软雅黑][size=3] 标准才会真正落地。[/size][/font]




[hr]
原始来源：https://itil.org.cn/thread-365031-1-1.html
迁移说明：本文由旧论坛历史帖子迁移至 ITIL 先锋论坛，用于承接旧链接访问。