一、ISO/IEC 20000-1:2018 5.3 标准原文
条款要求：最高管理者应确保服务管理体系相关岗位的职责和权限得到分配、沟通和理解。组织应明确谁负责体系符合性、体系绩效报告、服务管理活动实施以及跨部门协同，确保关键事项有明确责任和升级路径。
二、标准条款解读说明
2.1 关键角色与职责表
| 角色 | 典型职责 | 权限重点 |
|---|---|---|
| 最高管理者/服务治理负责人 | 批准方针目标、审议绩效、提供资源 | 重大风险、重大变更、资源配置决策 |
| 服务负责人 | 对单项服务端到端表现负责 | 协调跨团队资源，推动服务改进 |
| 过程负责人 | 负责事件、问题、变更等过程设计与优化 | 定义流程规则、指标和审核要求 |
| 执行团队 | 按流程处理工单、升级、记录和沟通 | 在授权范围内执行标准操作和例外处理 |
| 支持职能 | 采购、法务、人力、安全、财务等支撑过程 | 保障合同、预算、人员和合规要求落实 |
2.2 核心理解
服务管理体系最常见的失效原因之一，就是职责模糊。比如发生重大故障时，谁负责最终恢复？谁决定是否升级为重大事件？谁协调供应商？谁批准应急变更？如果这些问题只能靠临场拍板，说明5.3没有落实。
ISO 20000 的职责不是简单按部门切块，而是强调端到端责任。服务负责人要对服务整体结果负责，过程负责人要对流程有效性负责，执行团队要对操作及时性和记录完整性负责，管理层要对资源和绩效负责。只有将角色责任、决策权限、升级路径同时明确，体系运行才不会在接口处掉链子。
2.3 职责设计最容易被忽略的三个界面
第一是跨部门界面，例如服务台和技术团队之间谁来判定升级级别，谁来对客户统一发声；第二是跨时段界面，例如白班、夜班和值班交接之间如何保证责任不断档；第三是内外部界面，即供应商做的事情谁来管、谁来验、谁对结果负责。这三类界面如果没设计好，再清晰的部门职责也会在真实场景中失效。
另外，职责条款常常暴露组织成熟度。成熟组织在谈职责时，不只是展示岗位说明书，而是能拿出审批链、值班表、升级路径和系统权限配置来证明角色设计已经进入运行机制。对发表型文章来说，这一点尤其值得强调，因为很多读者真正缺的不是概念，而是如何把职责从文档变成可执行结构。
三、实施要点
3.1 明确关键岗位
- 至少识别服务负责人、事件经理、问题经理、变更经理、供应商经理、服务级别经理等关键角色。
- 对小型组织可一人兼任多岗，但必须说明兼任范围和冲突控制方式。
3.2 建立RACI或责任矩阵
- 对主要过程明确谁负责、谁审批、谁协作、谁获知，特别是跨部门和跨地点活动。
- 重大事件、应急变更、服务中断沟通等高风险场景应单独设置权限规则。
3.3 把职责写进机制而不只是岗位说明书
- 在流程文件、会议机制、工单系统审批链中固化责任和升级关系。
- 把过程指标与责任岗位关联，避免“大家都负责，等于没人负责”。
3.4 做好替补和轮值安排
- 关键岗位应有备份人，确保休假、离岗、夜班和值班期间职责不断档。
- 对外包人员承担的职责，应通过合同和日常管理确保责任可控。
3.5 用权限设计保障职责真正落地
- 为关键角色配置与职责一致的系统权限、审批权限和报告权限，防止纸面职责与系统实际不一致。
- 对重大事件经理、变更经理、服务负责人等关键岗位，设置清晰的升级触发条件和授权边界。
- 发生组织调整、岗位轮换或外包模式变化时，应同步更新职责矩阵和权限配置，而不是等出现问题后再补。
- 定期抽查几个典型场景，例如应急变更、供应商升级、夜间故障，看责任链是否真的能跑通。
四、常用工具与实施方法
| 工具 | 用途 | 输出 |
|---|---|---|
| RACI矩阵 | 定义流程角色分工 | 责任权限矩阵 |
| 岗位说明书 | 明确岗位职责和任职要求 | 岗位职责文件 |
| 升级路径图 | 处理故障、投诉和例外事项 | 升级和通知清单 |
| 审批流配置 | 在ITSM系统中固化权限 | 工单审批规则 |
| 绩效关联表 | 让责任与结果挂钩 | 岗位KPI映射 |
五、典型案例
案例一：重大事件中职责不清
某企业发生ERP中断时，服务台只负责接单，基础设施团队认为是应用问题，应用团队又等待供应商反馈，三小时内无人统一指挥。后续依据5.3明确重大事件经理角色和升级权，建立跨团队指挥机制，再次发生故障时整体响应效率明显提升。
案例二：小团队通过兼岗实现标准化
一家中型SaaS公司人员有限，同一位运维主管同时担任服务负责人和变更经理。组织没有简单回避，而是通过RACI矩阵定义其审批边界，对高风险变更增加CTO复核，对问题管理引入独立验证，既满足条款要求，也符合现实资源情况。
案例三：集团化组织的接口再设计
某集团总部掌握统一平台，分子公司掌握本地现场支持，过去双方在故障处理中经常互相等待。重做5.3时，集团把“服务恢复责任”“现场执行责任”“客户沟通责任”拆分到不同角色，并通过升级路径图固定在平台中。之后即使问题跨越多个层级，责任界面也比过去清晰得多。
从体系成熟角度看，5.3 的终极目标不是“把责任写出来”，而是让每个关键流程在任何班次、任何地点、任何接口上都能找到明确责任人，并且这个责任人具备相应授权与替补机制。做到这一点，组织的服务稳定性会出现质的提升。
职责真正清楚以后，很多原本依赖个人经验的临场协调，也会逐步被制度化的升级和交接机制所替代。
在认证和日常运行中，5.3 还有一个非常现实的意义，就是帮助组织判断“问题卡在哪个接口”。如果事件恢复慢、变更审批慢、客户反馈慢，而大家都觉得自己已经做了该做的事，那么十有八九是职责和权限设计没有真正穿透到接口场景。把条款写深、做实，本质上是在降低组织内部的协同摩擦成本。
对服务组织而言，这种“可快速说明、可快速启动、可快速接替”的责任体系，本身就是服务稳定能力的重要组成部分。
也正因为如此，5.3 的好坏往往会在组织最忙、最乱、最需要快速决策的时候被放大。平时看不出的职责模糊，在重大事件、跨部门变更和供应商升级时最容易暴露出来。
六、成文信息管理要求
- 保留岗位职责说明、RACI矩阵、授权清单、值班和替补安排表。
- 对重大事件、重大变更、供应商升级等关键场景，保留审批和执行记录，证明权限实际有效。
- 职责调整、组织变更、外包模式变化时，应及时更新文件和系统权限。
七、常见误区及踩坑提醒
| 误区 | 表现 | 正确做法 |
|---|---|---|
| 只画组织架构图 | 看得到部门，看不到过程责任 | 补充RACI、升级路径和审批规则 |
| 职责有了但没授权 | 流程负责人不能推动跨部门协同 | 在制度和系统里赋予必要权限 |
| 关键岗位无备份 | 人员请假或离职后流程失控 | 建立备岗、轮值和知识交接机制 |
| 外包角色游离于体系外 | 做事的人在供应商，责任却没人管 | 把外包岗位纳入统一职责和考核链条 |