那次流程协调会，我差点把笔掰断。
事件处理流程明明写得清清楚楚，可一个P1故障却拖了四个小时没人闭环。
安全组说是应用问题，应用组说要等运维排查，运维组说“我们只执行变更”。
最后我忍不住问了一句：“那谁负责解决？”
全场沉默。
其实流程一点都没错，错的是——没人真的“对号入座”。

一、冲突：当流程比人聪明


我见过太多企业的ITSS项目陷入这种怪圈：
流程文档比人清醒，图表比会议还详细，可落地时一团乱。
原因往往只有一个——组织架构没跟上。
那家企业自信地通过了ITSS三级评估，
但上线半年后，他们的服务目录形同虚设。
为什么？因为没人知道谁该为哪块服务负责。
事件管理有了值班表，但没人维护；
变更流程有审批链，但CAB开会无人到场。


ITSS不是写给系统的，而是写给人的。
如果角色没定清楚，流程再标准也只是“漂亮的幻觉”。
我在会上问他们：“你们的服务负责人（Service Owner）是谁？”
有人回答：“我们是扁平化团队，没有明确划分。”
我笑了：“那你们其实不是扁平，而是散装。”




二、反思：职责不清，流程再好也白搭


那次会议后我彻夜没睡。 我在想，为什么我们这些年讲ITSS讲了那么多流程，却总有人跑不起来？ 后来我明白了——流程只是骨架，职责是肌肉。
组织架构的问题，不在于人多或人少，而在于边界。
每个人都想做“支撑者”，没人愿意做“责任人”。
没有明确的职责矩阵，沟通再多也解决不了问题。
我开始重新梳理他们的组织结构。
从服务视角出发，不再以部门为核心，而是以“流程角色”为核心。


我们在白板上画出RACI矩阵：

• R（Responsible）：谁真正执行；
• A（Accountable）：谁最终负责；
• C（Consulted）：谁要被征询；
• I（Informed）：谁需要被告知。
  

就这四个字母，让团队第一次明白，
“做”与“负责”其实是两回事。
本文由艾拓先锋ITSS官方授权认证培训讲师熊健淞原创，未经许可谢绝转载。
我常在课堂上举这个例子：当RACI不清时，任何流程都会演变成“互相等待”的循环。
但一旦人和职责绑到位，流程反而变轻，决策变快，效率也自然提升。




三、重构：从“部门思维”到“服务思维”


我们用了一个月时间，做了三件事：

• 角色清单重建 不再以部门划分，而是以流程视角识别角色—— 服务台、事件经理、变更审批人、配置管理员、发布协调人。 每个角色都有职责描述、汇报路径与交接机制。
• 建立治理节奏 每周一次“流程健康会”，所有流程负责人汇报执行数据。 出现扯皮事件，现场立刻讨论边界，次周更新矩阵。 这不是审查会议，而是“调整会”。 因为ITSS体系不是一劳永逸，而是需要不断修正。
• 引入绩效联动机制 我们将SLA、MTTR、变更成功率等指标嵌入绩效体系。 让每个人都知道，流程执行不是任务，而是业绩。
  

我记得那位安全主管后来私下跟我说：“原来我们不是缺制度，是缺角色。”
这句话，我一直记在心里。




四、启示：人对了，流程才会顺


半年后，那家企业的流程投诉率下降了70%。
以前出问题都找“流程不合理”，
现在出问题先问“谁该处理”。
组织变清晰后，会议变短、决策变快、复盘变真。
最明显的变化是：大家开始主动跨部门合作。
因为边界清晰，沟通才有底气。


我在最后一次项目总结会上说：

“流程跑不动，不是因为制度弱，而是因为人没站对位。”

ITSS的本质，不是流程比谁多、文档比谁厚，
而是让人、职责、机制形成一套有机的运行系统。
当组织学会围绕“服务”而不是“部门”去思考，
标准才会真正落地。

那次流程协调会，我差点把笔掰断。
事件处理流程明明写得清清楚楚，可一个P1故障却拖了四个小时没人闭环。
安全组说是应用问题，应用组说要等运维排查，运维组说“我们只执行变更”。
最后我忍不住问了一句：“那谁负责解决？”
全场沉默。
其实流程一点都没错，错的是——没人真的“对号入座”。

一、冲突：当流程比人聪明


我见过太多企业的ITSS项目陷入这种怪圈：
流程文档比人清醒，图表比会议还详细，可落地时一团乱。
原因往往只有一个——组织架构没跟上。
那家企业自信地通过了ITSS三级评估，
但上线半年后，他们的服务目录形同虚设。
为什么？因为没人知道谁该为哪块服务负责。
事件管理有了值班表，但没人维护；
变更流程有审批链，但CAB开会无人到场。


ITSS不是写给系统的，而是写给人的。
如果角色没定清楚，流程再标准也只是“漂亮的幻觉”。
我在会上问他们：“你们的服务负责人（Service Owner）是谁？”
有人回答：“我们是扁平化团队，没有明确划分。”
我笑了：“那你们其实不是扁平，而是散装。”




二、反思：职责不清，流程再好也白搭


那次会议后我彻夜没睡。 我在想，为什么我们这些年讲ITSS讲了那么多流程，却总有人跑不起来？ 后来我明白了——流程只是骨架，职责是肌肉。
组织架构的问题，不在于人多或人少，而在于边界。
每个人都想做“支撑者”，没人愿意做“责任人”。
没有明确的职责矩阵，沟通再多也解决不了问题。
我开始重新梳理他们的组织结构。
从服务视角出发，不再以部门为核心，而是以“流程角色”为核心。


我们在白板上画出RACI矩阵：

• R（Responsible）：谁真正执行；
• A（Accountable）：谁最终负责；
• C（Consulted）：谁要被征询；
• I（Informed）：谁需要被告知。
  

就这四个字母，让团队第一次明白，
“做”与“负责”其实是两回事。
本文由艾拓先锋ITSS官方授权认证培训讲师熊健淞原创，未经许可谢绝转载。
我常在课堂上举这个例子：当RACI不清时，任何流程都会演变成“互相等待”的循环。
但一旦人和职责绑到位，流程反而变轻，决策变快，效率也自然提升。




三、重构：从“部门思维”到“服务思维”


我们用了一个月时间，做了三件事：

• 角色清单重建 不再以部门划分，而是以流程视角识别角色—— 服务台、事件经理、变更审批人、配置管理员、发布协调人。 每个角色都有职责描述、汇报路径与交接机制。
• 建立治理节奏 每周一次“流程健康会”，所有流程负责人汇报执行数据。 出现扯皮事件，现场立刻讨论边界，次周更新矩阵。 这不是审查会议，而是“调整会”。 因为ITSS体系不是一劳永逸，而是需要不断修正。
• 引入绩效联动机制 我们将SLA、MTTR、变更成功率等指标嵌入绩效体系。 让每个人都知道，流程执行不是任务，而是业绩。
  

我记得那位安全主管后来私下跟我说：“原来我们不是缺制度，是缺角色。”
这句话，我一直记在心里。




四、启示：人对了，流程才会顺


半年后，那家企业的流程投诉率下降了70%。
以前出问题都找“流程不合理”，
现在出问题先问“谁该处理”。
组织变清晰后，会议变短、决策变快、复盘变真。
最明显的变化是：大家开始主动跨部门合作。
因为边界清晰，沟通才有底气。


我在最后一次项目总结会上说：

“流程跑不动，不是因为制度弱，而是因为人没站对位。”

ITSS的本质，不是流程比谁多、文档比谁厚，
而是让人、职责、机制形成一套有机的运行系统。
当组织学会围绕“服务”而不是“部门”去思考，
标准才会真正落地。