★ FEATURED ARTICLE 简介《ISO/IEC 20000-1:2018中文版》PDF面向IT服务管理人员、内审员、认证审核人员及准备转版或建立服务管理体系SMS的组织帮助读者理解新版标准在服务设计、交付、关系与绩效管理等方面的要求也适用于内审员培训、体系文件编制和认证审核前的条款梳理。文件共1个PDF约551KB由北京中大华远认证中心翻译中文表述便于国内读者快速查阅正文按范围、规范性引用文件、术语和定义、组织背景、领导力、规划、支持、运行、绩效评估与改进等章节展开目录完整便于按条款检索。已有4376人学习下载可作为SMS实施、内部审核和认证审核的条款对照参考其中服务组合、关系和协议、供需、服务设计构建与转换、解决和履行等内容能帮助读者把标准要求落到流程与审核检查点并对照2011版理解新版变化。1. 知识地图先看清 4 到 10 这条主干再钻条款刚碰信息技术服务管理体系的人最常见的动作是从第 8 章那些流程名背起事件管理、问题管理、变更管理、容量管理。背完一轮发现还是不会用因为这份标准的重点不在流程清单上。2018 版把结构整体换成了管理体系通用的高阶结构条款 4 到 10 是一条从“组织为什么做”到“做完怎么改”的主线4 组织背景、5 领导力、6 规划、7 支持、8 运行、9 绩效评估、10 改进。第 8 章只是主干上最粗的一段。从 2011 版转版过来的人、准备认证审核的人、做 ITSM 落地的人读法完全不同前两种要能从 8 的每条流程倒推回 4 到 7 的证据后一种要顺着 4 到 10 往下推。这份笔记按倒推的读法整理。2. 体系骨架条款 4 到 7 的四块地基怎么打条款 4 到 7 是标准的“通用骨架”跟 ISO 9001、ISO/IEC 27001 共用同一套高阶结构所以很多人会下意识跳过去觉得“这些是套话”。实际情况正好相反认证审核里最容易被追问的恰恰是这四章因为它们决定了第 8 章那些流程到底是不是为一个明确的组织、明确的范围服务的。骨架没打牢后面的流程做得再漂亮也只是一堆没有出处的表格。2.1 组织背景与 SMS 范围4.1 到 4.4 的四个动作4.1 要求组织确定与其宗旨相关、并影响服务管理体系预期结果的内外部因素4.2 要求确定相关方以及这些相关方与服务管理体系相关的要求。这两条合在一起本质上是让组织先把“谁在看我、我怕什么”写清楚。相关方在标准里的范围比直觉宽客户、用户、外部供方、内部供方、监管机构、组织内 SMS 范围之外的部门都算。4.3 确定范围是整份文件里最该花时间的地方。范围声明要回答四件事覆盖哪些服务、覆盖哪些组织单元与场所、覆盖哪些支撑流程、与范围之外的部分怎么接口。范围写宽了审核时会被要求为每个角落拿出证据范围写窄了等于把能证明体系有效运转的部分切出去。1.2 把这条线划得很硬条款 4 到条款 10 中的任何要求都不允许以“排除条款”的方式剔掉。4.4 要求建立、实施、保持和持续改进 SMS并确定体系所需的过程及其相互作用。落地时最实用的做法不是画一张漂亮的流程图而是做一张“过程—所有者—输入—输出—接口”的表这张表后面会反复用到6.1 的风险从这里找8.1 的控制对象是这里9.1 的监视对象还是这里。2.2 领导力5.1 到 5.3 里真正会被查的三件事5.1 领导和承诺要求最高管理者对 SMS 的有效性负责5.2 方针要求方针与组织宗旨相适应、包含满足适用要求的承诺和持续改进的承诺、形成成文信息、在组织内沟通并可被相关方获取5.3 角色、责任和权限要求分配职责与权限并形成成文信息。被查得最多的是三样东西。一是管理者参与的痕迹管理评审的主持记录、方针的发布与内部宣贯记录、资源投入的依据。二是职责分配的颗粒度写“IT 部门负责服务管理”基本等于没写要写到“谁批准变更、谁接受风险、谁签服务级别协议、谁对外部供方绩效负责”这一层。三是方针与服务管理目标是否对得上5.2 的承诺在 6.2 里必须有对应的可测量目标否则就是两张皮。提示5.3 里“权限”二字常被忽略。有责无权是最常见的组织缺陷尤其在变更授权和服务连续性决策上一线团队被要求对结果负责却不具备停机窗口的决策权。2.3 规划风险与机会、服务管理目标怎么写成可查的6.1 应对风险和机会的行动要求组织在规划 SMS 时考虑 4.1 提到的因素和 4.2 提到的要求确定需要应对的风险和机会并规划应对措施、如何整合进过程、如何评价有效性。这一条是 2018 版转版时的重点变化之一风险不再是某个单独流程的事而是贯穿整个体系。6.2 服务管理目标的规划要求目标与服务管理方针一致、可测量、考虑适用的要求、可监视、可沟通、适时更新并保留成文信息。写目标时最容易翻车的是“可测量”这一项把“提升客户满意度”写成目标不算违规但要能回答“用什么量、多久量一次、达到多少算达成”。真正可查的写法是“服务可用性 ≥ 99.5%按月统计超标即触发纠正措施”。2018 版在前言里明确说到新增了关于知识和规划服务的内容所以 6.2 不只管体系层面的目标还要管到具体服务的规划。这里给一个实用的对齐方式方针一句话 → 目标三到五条 → 每条目标挂一到两个第 8 章的过程 → 每个过程挂一个 9.1 的度量。链条断了的地方就是审核时会被问住的地方。2.4 支持7.1 到 7.6 里最容易被做薄的两块7.1 资源、7.2 能力、7.3 意识、7.4 沟通都是常规动作确定并提供所需资源、确定岗位所需能力并采取措施获得、让相关人员意识到方针与自身贡献、确定内外部沟通的内容与时机与对象。这些条款不难难在证据的连续性。真正的重点在 7.5 成文信息和 7.6 知识。7.5 要求体系的成文信息包括本标准要求的成文信息和组织为体系有效性所必需的成文信息还要控制创建与更新、控制分发与访问、存储与防护、更改控制、保留与处置。2018 版的一个明确取向是最小化保留成文信息的要求只保留关键的比如服务管理计划。但“最小化”不等于“可以没有要求”这点在第 5 章会单独拆开讲。7.6 知识是 2018 版新增的条款要求组织确定运行和交付服务所需的知识保持并在需要的范围内可获取。它的实际含义是某个资深工程师离职后那些“只有他知道”的判断依据不能变成黑匣子。最低限度的做法是把知识条目和配置项、服务目录条目关联起来让知识有归属、有更新触发条件。条款核心要求审核时通常找的证据4.1 / 4.2识别内外部因素与相关方需求背景与相关方分析记录、需求清单4.3 / 4.4划定 SMS 范围、建立体系及其过程范围声明、过程清单与相互作用说明5.1 / 5.2 / 5.3领导承诺、方针、角色职责权限方针发布与沟通记录、职责与权限文件、管理评审参与记录6.1 / 6.2风险与机会、服务管理目标风险登记与应对措施评价、目标分解与监视记录7.1—7.6资源、能力、意识、沟通、成文信息、知识培训与能力评价记录、沟通安排、服务管理计划、知识条目与更新记录3. 运行上半场服务组合、关系和协议、供需三条线的落地要点第 8 章是全文最长的一章也是把 4 到 7 兑现成日常动作的地方。它前半段8.1 到 8.4管的是“有什么服务、跟谁签了什么、钱和需求怎么走”后半段8.5 到 8.7管的是“改、修、保”。先看前半段因为后半段所有流程的输入都来自这里。3.1 运行的规划和控制8.1 不是一句废话8.1 要求组织规划、实施和控制满足要求所需的过程实施 6.1 确定的措施保持成文信息以确信过程按策划进行对策划的变更进行控制并评审非预期变更的后果必要时采取措施降低不利影响确保外包的过程受控。这条之所以常被当成废话是因为它读起来没有任何具体流程名。但它是唯一一条把“计划”和“实际”绑在一起的要求变更控制的真正源头在这里不在 8.5。很多组织 8.5 的变更流程做得很规范8.1 的“非预期变更后果评审”却是空的一被问到“上个月那次临时扩容有没有评估对其他服务的影响”就答不上来。3.2 服务组合服务交付、服务计划、服务目录、资产与配置8.2 是一组关系极密的子条款。服务交付要求按服务级别协议交付服务服务计划要求为服务建立计划写清服务内容、服务级别目标、依赖的服务组件与相关方对涉及服务生命周期各方的控制要求对其他方提供的服务、服务组件或过程进行管控明确角色、职责、权限和接口服务目录管理要求建立并保持服务目录且服务目录是需要控制的成文信息资产管理要求识别资产并记录其价值、风险与生命周期配置管理要求识别配置项、记录配置信息、维护配置项之间的关系与基线。这里最容易忽略的是“服务目录”和“配置信息”不是一回事。服务目录是给客户看的他能申请什么配置信息是给运维看的它由什么组成、谁依赖谁。两个东西混成一个表最后两边都不好用。# 配置信息记录8.2.6重点不是用什么数据库存而是这条记录能不能回答影响分析 ci_id: CI-APP-0142 name: 订单服务生产环境 type: 应用系统 service: 订单受理服务 # 指回 8.2.4 服务目录条目 owner_role: 应用负责人 # 写责任角色不写具体人员 relationships: - type: depends_on target: CI-DB-0031 # 数据库实例 - type: depends_on target: CI-NET-0007 # 负载均衡 - type: provides_to target: CI-APP-0143 # 下游结算服务 baseline: version: v3.4.1 applied_at: 2025-03-11 change_ref: CHG-2025-0219 # 变更编号形成可追溯链 asset_ref: AST-0098 # 对应资产记录可以为空这段记录的每个字段都对应一条要求service把配置项挂回服务目录relationships支撑影响分析与事件处理baseline加上change_ref让变更与配置形成闭环。特别注意asset_ref允许为空因为 3.2.1 的注释说得很清楚资产可以是配置项但某些配置项可能不是资产两者不是一一映射硬凑成一张表迟早出错。3.3 关系和协议商务关系、服务等级、供应商三条链商务关系管理8.3.1处理的是与客户的日常关系包括沟通机制、投诉处理、满意度收集、服务评审这类动作它的产出是服务的改进输入。服务等级管理8.3.2处理的是服务级别协议与其中的服务级别目标签署、监视、报告、评审、更新。供应商管理8.3.3处理的是外部供方合同、绩效监视、变更与终止以及对分包供方的可见性。这三条链的关系可以用一句话概括商务关系管“客户还愿不愿意合作”服务等级管“答应的指标有没有做到”供应商管“上游掉链子时有没有兜底”。三者的接口是同一份服务级别目标所以指标口径必须一致——服务级别协议里写“可用性 99.5%按月”供应商合同里就不能写“可用性 99.9%按季度”否则中间那段差值没人负责。服务级别目标度量口径统计周期常见误用服务可用性 ≥ 99.5%约定时间 − 不可用时间/ 约定时间月度分母用自然时间而非约定服务时间一级事件响应 ≤ 15 分钟从受理时间到首次响应时间月度用“解决时间”冒充“响应时间”服务请求履行 ≤ 2 个工作日从审批通过到交付完成月度把服务请求当事件统计拉高整体解决率变更成功率 ≥ 95%未导致事件的变更数 / 变更总数季度变更基数口径不写清数字随意波动3.4 供应和需求预算核算与需求管理的配合服务的预算和核算8.4.1要求对服务进行预算、核算与成本分析让服务的成本可被看见需求管理8.4.2要求识别、预测并管理对服务的需求并与服务组合、容量等过程联动。这两条在实务中经常被做成分开的两个表格其实它们是一件事的两面需求预测决定预算盘子成本核算反过来约束需求承诺。一个可复现的做法是把需求做成带时间轴的量按服务、按业务线、按季度列出当前用量与预测量再挂上单服务的成本项。这样在客户提出“下季度业务量翻一倍”时能立刻给出两句话的回答——容量需要增加多少、预算需要追加多少。缺了这层联动需求管理就退化成收集愿望清单。4. 运行下半场设计转换、解决履行与服务保证的复习重点如果条款 4 到 7 是地基、8.1 到 8.4 是账本那么 8.5 到 8.7 就是真正每天在跑的机器。这一段的难点不在流程多少而在边界变更和发布怎么分、事件和服务请求怎么分、问题和已知错误怎么分。分不清后面的指标全是糊的。4.1 服务设计、构建和转换变更、设计转换、发布部署变更管理8.5.1要求对变更进行分类、记录变更请求、评估影响与风险、授权、实施、评审结果并对紧急变更设定专门的处理路径。服务设计和转换8.5.2要求对新建、变更或退役的服务进行设计与转换包括确定服务要求、设计服务组件与度量、制定验收准则、规划转换活动。发布和部署管理8.5.3要求定义发布的类型与频率并规划、验证、部署发布。这里有个 2018 版的实质变化值得记住旧版要求有“发布策略”文件新版改为要求定义发布的类型和频率。文件可以不叫策略、可以只有一页但“我们有哪些发布类型、多久发一次、谁能批准例外”这些问题必须有答案。这是典型的“要求还在、载体放宽”。变更和发布的分界线也可以一句话说清变更管的是“这个改动该不该做、谁批准”发布管的是“这批改动怎么装进去、装完怎么验”。混在一起的表现是变更单里写着“已于当晚发布完成”但没有任何验收结论出了事故无从回溯。4.2 解决和履行事件、服务请求、问题的分界线事件管理8.6.1要求记录、分级、处理、升级、解决和关闭事件并按需要与问题管理联动。服务请求管理8.6.2处理的是预定义的、常规的客户请求比如权限申请、标准配置发放。问题管理8.6.3从实际或潜在事件中识别问题查明原因记录已知错误与临时措施并在需要时提交变更请求。三个词的定义差别是理解的关键3.2.5 把事件定义为服务的意外中断以及导致服务质量下降但尚未对客户或用户的服务产生影响的事项3.2.9 把已知错误定义为已识别根本原因、或已找到减少或消除其对服务影响的方法的问题3.2.10 把问题定义为一个或多个实际或潜在事件的原因。也就是说事件是“症状”问题是“原因”已知错误是“被看穿的原因”。类型触发来源目标输出常见误用事件监控告警、用户报障尽快恢复服务事件记录、解决措施把问题当事件只做重启不做根因服务请求用户按目录发起按约定履行请求请求记录、履行结果与服务目录脱节靠口头受理问题重复事件、重大事件找到并消除根因问题记录、已知错误、变更请求只记录不驱动变更问题长期挂着变更请求任何方提出改动受控地改变服务或组件变更记录、评审结论先做后补紧急变更无授权痕迹4.3 服务保证可用性、连续性、容量、信息安全服务可用性管理8.7.1要求确定服务的可用性要求与目标监视并报告达成情况。服务连续性管理8.7.2要求确定连续性要求制定并测试连续性方案注意它与业务连续性管理是上下位关系而非同一件事。容量管理8.7.3要求确定容量要求、制定容量计划、监视容量与性能、预测未来需求。信息安全管理8.7.4要求确定信息安全要求与目标实施控制措施并管理信息安全事件。这四个子条款共享一个结构先定目标和指标再监视再触发改进。因此把可用性算准是把这一组流程做扎实的起点。下面的脚本按照约定的服务时间计算可用性并反推停机预算——后者比前者有用得多因为它能直接回答“这个月还能停多久”。def service_availability(agreed_minutes: int, downtime_minutes: int) - float: 按 3.2.16 的口径计算服务可用性实际可用时间 / 约定时间 if agreed_minutes 0: raise ValueError(约定时间必须大于 0) available agreed_minutes - downtime_minutes return round(available / agreed_minutes * 100, 3) # 假设一个月约定服务时间为 30 天 × 10 小时 agreed 30 * 10 * 60 # 单位分钟共 18000 for down in (60, 180, 420): used down / agreed * 100 print(f不可用 {down} 分钟 - 可用性 {service_availability(agreed, down)}%已消耗停机预算 {used:.2f}%)agreed_minutes必须用约定的服务时间不能用 24×7 的自然时间否则算出来的数会虚高downtime_minutes要包含计划外不可用与超过约定窗口的计划停机。把两个参数换成你所在服务的口径就能得到每月允许的停机分钟数——99.5% 在 18000 分钟里只允许 90 分钟不可用这个数字一摆出来很多关于“小停机不算停机”的争论就自然结束了。4.4 绩效评估与改进9 和 10 的闭环怎么闭合第 9 章要求组织确定监视、测量、分析和评估的对象、方法、时机保留成文信息并对结果进行评估要求按计划的间隔开展内部审核开展管理评审以及向相关方提供或沟通服务报告。第 10 章要求处理不符合与纠正措施并持续改进。2018 版在这一段有两个容易漏掉的变化。其一标准删除了对 Plan-Do-Check-Act 的引用和相关图示因为高阶结构没有专门使用它很多改进方法都能与管理体系一起用——这意味着自评表里那些“因为 PDCA 循环所以……”的表述不再是条款依据。其二取消了对持续改进策略的要求改为要求确立识别改进机会的评估标准。也就是说不必先把改进战略写得很正式但必须说清“什么情况会被判定为改进机会”。闭环是否真的闭上看一个细节就够了管理评审的输入里有没有 9 和 8 的具体数据输出里有没有落成变更请求或改进项的条目。如果评审结论永远是“总体运行良好”那基本可以判定这个环是断的。5. 易错点五个最容易翻车的条款理解与证据缺口这一段是复习时最该反复过的部分。前面几章是按条款顺序走的容易理解也容易记住但真正扣分的往往不是“不知道有这条要求”而是“把这条要求理解反了”或者在旧版模板里抄顺手了根本没意识到新版已经换了说法。下面五处按整理过的角度逐条拆开。5.1 条款理解上的三处易漏其一把 8.2.3 对相关方的控制读成“外包出去就不用管了”。易漏点认为签了外包合同责任就随合同转移了。为什么漏这在日常管理里是顺理成章的直觉而且不少旧模板是围绕“治理”写的读起来像是把外包商的流程管好就行。怎么补把 1.2 的两句话背下来——组织应提供承担本标准规定要求责任的证据即便相关方参与满足 6 到 10 的要求如果其他方承担提供或运行 SMS 范围内所有服务、服务组件或流程的所有责任组织不能声称符合本标准。落地动作是列一张接口清单每一个外包环节写清输入、输出、责任人、验收方式这张清单就是 8.2.3 的证据。其二把成文信息的“最小化”读成“这也不用写那也不用写”。易漏点看到前言里那一串删除项就以为相关要求消失了。为什么漏这段是标准的修订说明读起来像减负清单很容易被当成“以后不用文件了”。怎么补分清“要求”和“载体”。容量管理计划的文件要求删掉了改为容量计划的要求可用性计划文件的要求删掉了改为服务可用性要求和目标的文件配置管理数据库要求删掉了改为配置信息要求发布策略要求删掉了改为定义发布类型和频率的要求持续改进策略要求取消了改为确立改进机会的评估标准。要求一条没少只是不强制用某个文件形态来承载而服务管理计划这类关键成文信息仍然必须保留。其三把事件、服务请求、问题、变更请求当成同一个“工单”。易漏点系统里只有一个工单类型全凭填写人心情选。为什么漏一线口语里都叫“报修”或“提单”流程文档也常常只画一条线。怎么补在记录里加一个必填的“类型判定”字段并给出判定规则是否有意外中断或质量下降事件、是否是目录内的常规请求服务请求、是否在追问原因问题、是否要改动服务或组件变更请求。类型不是标签是流向事件流向问题问题流向变更变更回到发布四者构成一条链链路一断统计口径立刻失真。5.2 术语与证据上的两处易漏其四服务报告的要求只在第 9 章找。易漏点把服务报告当成 9 里的一个条款做一张模板就算完成。为什么漏2011 版把服务报告的详细要求集中写在服务报告条款里转版惯性会让人继续在那一条附近找。怎么补2018 版把服务报告的详细要求从服务报告条款移到了可能产生服务报告的各个条款所以报告里的每个数据项都应该能追到某个流程条款可用性追到 8.7.1事件量追到 8.6.1变更成功率追到 8.5.1供应商绩效追到 8.3.3。做模板时按这个映射建列比在 9 里憋一份格式要靠谱得多。其五术语换了还在照抄旧模板。易漏点文件里到处是旧称谓。为什么漏模板是老的替换成本高而且新旧词在中文语感上差别不大。怎么补做一张替换对照表逐条改。标准里明确的变化包括“服务提供方”被“组织”取代以符合高阶结构的通用描述“内部小组”被“内部供方”取代“供方”被“外部供方”取代“信息安全”的定义与 ISO/IEC 27000 保持一致因此“可用性”被“服务可用性”取代以区别于信息安全里使用的“可用性”。另外两组容易混的术语也要回到定义客户是接受服务的组织或组织的一部分用户是使用服务的个人或角色一个人可以既是客户又是用户资产与配置项不是同义词资产有独立的价值与生命周期视角。6. 复习清单把 4 到 10 压成一张能自检的表真正复习的时候不建议再从第一条往下读。用一张空表自检效率高得多左边写条款右边只填“证据的名字”填不出来的格子就是漏点。检查项能填上就算过填不上说明什么4.3 范围一句能背出来的范围声明边界不清后面全是连带问题5.2 方针方针里能指出满足要求与持续改进两句承诺方针是抄的6.2 一定对不上6.1 风险至少三条与本组织服务相关的风险及应对风险登记是通用模板7.6 知识两个具体知识条目及其更新触发条件关键判断仍只存在人脑里8.2.4 服务目录客户能自助看懂的服务清单目录只是内部资产表的改名8.3.2 服务级别目标口径、周期、分母都写清的三条指标指标无法复算8.5.1 变更一次紧急变更的完整授权链变更记录只有结果没有决策8.6.3 问题一个已转为变更请求的问题问题管理停在记录层9 绩效评估一次管理评审的输入数据清单评审只有结论没有数据10.1 不符合一条闭环的纠正措施及其有效性验证纠正措施只写“已培训”这张表还有个用法把它当成转版自查的对照物。哪一格填不上就去补哪一格对应的条款不要一上来就重写全部文件——大部分组织的漏点集中在 8.2.3、8.6.3、9 这三处把这三处补齐体系的完整性会明显不一样。最后说个血泪经验。我最早做这类梳理时喜欢从第 8 章往里钻觉得流程做完体系就成了结果每次被问到“这个流程服务的是哪个范围里的哪条目标”就卡住只能回头补 4 到 7。从那以后我每接一份新范围都强制按 4 到 10 的顺序走一遍这张空表先把每格填上证据的名字再谈流程优化和工具选型。这套顺序看起来笨但它能省掉后面反复返工的时间。希望帮到你。本文还有配套的精品资源点击获取
阅读完成 · 觉得有帮助？
