IT运维企业大多有工单系统，也有值班表和升级机制，看起来离ISO 20000不远。
但真开始摸底就会发现，服务目录是按合同随手写的，SLA指标无法统计，事件和问题的边界没人说得清。
本文按服务目录、合规资质、岗位职责、资源计划四个方面，说明IT运维企业差距分析应当核到哪一层。
ISO 20000看的是服务管理体系能否稳定交付承诺的服务水平，差距分析要从“承诺了什么、怎么度量、谁负责”三处切入。
下表可用于首次申请前的自查，也可用于判断现有工具能否支撑体系运行。
| 过程域 | 常见现状 | 差距怎么判断 | 优先动作 |
|---|---|---|---|
| 服务目录与SLA | 目录来自合同附件，指标口径不统一 | 能否按月出报告并解释偏差 | 高：先统一目录和指标定义 |
| 事件与问题管理 | 工单只记录处理结果，未分类 | 能否区分事件与问题并做趋势分析 | 高：补分类字段和升级规则 |
| 变更与发布 | 变更靠群通知，回滚方案临时定 | 抽查变更是否有审批、验证和回滚记录 | 中：固化审批与验证环节 |
| 配置管理 | 资产表由不同团队各自维护 | 配置项与工单、变更能否关联 | 中：先统一关键配置项 |
如果服务目录和SLA这两项做不实，其余过程的整改很难被审核认可。
差距分析不要一上来就对着条款编号逐条打勾，先按服务生命周期走一遍：服务怎么设计、怎么上线、怎么交付、怎么改进。
每个环节问三个问题：有没有明确的责任人、有没有书面规则、有没有可查的记录。三者缺一，就是一条实打实的差距。
运维团队常见的短板是“只救火不总结”。事件处理很快，但没有问题管理，同类故障反复发生，这在审核中会被追问根本原因分析。
涉及数据中心、网络接入、云服务的业务，要先核对自己持有的经营许可和备案是否覆盖实际业务。
承接政府或金融客户的项目，通常还涉及等级保护测评和安全审查要求，这些义务要转成内部检查项，而不是只在投标时提供一份证书。
外包和分包也要理清。哪些环节由自己交付、哪些由合作方交付，合同和实际执行要一致，服务级别责任不能含糊。
服务经理要对服务水平和客户沟通负责，过程负责人要对事件、问题、变更等流程的执行质量负责，两者不能由同一人兼任到底。
服务台是门面，接单、分类、派单、回访的动作要标准化，否则后端再规范也体现不出服务水平。
同创云在运维类项目中一般建议先做一次岗位盘点，把7×24值班、二线支持和厂商接口人梳理清楚，再确定体系文件的责任分工。
预算主要花在工具改造、监控补点、知识库建设和人员培训上。已有工单系统的，优先做字段和报表改造，比换系统更实际。
时间安排要考虑数据积累周期。SLA报告至少要有连续几个月的完整数据，才能支撑审核时的趋势分析。
如果同时在推等保整改，建议把两套检查项合并，减少一线团队的重复填报。
可以。范围聚焦在主要服务线和核心客户，人员和过程要求按实际规模裁剪，但记录和度量不能省。
不是。ITIL是实践框架，ISO 20000是认证标准。企业可以借鉴ITIL的做法，但审核依据是标准要求。
不一定，但指标要能反映服务承诺且可统计。不同服务可以选择响应及时率、恢复时间或解决率等。
不建议。缺少完整工单数据，SLA达成情况无法证明，审核时很难说明体系已经运行。
差距分析要把“承诺、度量、责任”三件事对齐，体系才跑得起来。同创云长期做ISO 20000等体系认证咨询与审核辅导，官网 https://www.shtcyun.com。
首次申请的条件核对可参考申请条件里容易漏掉什么，服务目录与SLA的证据准备见这篇说明，其他体系可查看体系认证标准页。
具体认证要求、审核安排和证书状态，以认证机构及国家认监委（CNCA）官方最新通知为准。更多问答见体系认证常见问题栏目。
本文由同创云体系认证研究中心整理，内容参考相关管理体系标准与认证认可通用规则；具体政策以认证机构和监管部门官方最新通知为准。