ISO/IEC 20000-1:2018转版：SMS成文信息与条款8落地

简介这份《ISO/IEC 20000-1:2018》中文版PDF面向信息技术服务管理体系ITSM认证人员、内审员、咨询顾问及负责服务体系建设与转版的从业者可作为理解新版标准要求、开展审核对照和内部培训的参考资料。文件为1个PDF约551KB轻量便于检索与携带内容由北京中大华远认证中心翻译明确供认证人员依据标准实施审核时参考。已有4376人学习说明其在ITSM转版与认证准备场景中具有一定关注度。正文按标准结构展开涵盖组织背景、领导力、规划、支持、服务管理体系操作、绩效评估与改进等章节并细化服务组合、关系和协议、供需、服务设计构建转换、解决履行及服务保证等过程术语定义和文件化信息、知识管理等要求也便于读者建立统一语境快速定位标准条款并用于体系文件梳理、内审检查和认证审核准备。1. 一份 29 页的中文译本能替你回答什么某公司去年投标一个运维外包项目甲方在招标文件里只加了一句话投标方需具备信息技术服务管理体系认证。负责人翻出这份 29 页的中文版标准第一反应是“这不像技术文档”——通篇没有一行配置示例全是“组织应……”。问题恰恰在这里ISO/IEC 20000-1:2018 是要求类标准它只规定服务管理体系SMS必须达到什么状态用什么工具、设几个岗、写几级文件全部留给组织自己决定。这份译本面向依据该标准实施审核的人员措辞紧贴审核判断口径对内部推动落地的工程师反而更好用顺着每一个“应”字句能反推出审核员会要什么证据。适合正做 2011 转 2018 的组织、准备首次认证的运维团队以及要给甲方交服务报告的乙方项目经理。2. 条款 4~10 的重排逻辑HLS 高阶结构把标准切成了三层2018 版最容易被忽略的不是新增了哪条流程而是整本标准的骨架换了。前言 a) 说得很直白结构按附件 SL 的高阶结构HLS重组引入组织背景、目标策划、应对风险和机会的通用要求。这件事的直接后果是条款编号不再按“服务生命周期”排布而是按管理体系逻辑排布。很多人拿着 2011 版的经验去对条款对到第 8 章直接迷路。2.1 为什么“组织的背景”被提到条款 4条款 4 一共四小节4.1 了解组织及其背景、4.2 了解相关方的需求和期望、4.3 确定服务管理体系的范围、4.4 服务管理体系。这四节单看都是“务虚”的但 1.2 应用里有一句话把它们钉死了组织声称符合本标准时排除条款 4 到条款 10 中规定的任何要求都是不可接受的。也就是说4.3 的范围声明不是开场白而是后面所有条款的适用边界。你在 8.2 服务组合里列的每一个服务都必须落进 4.3 划的那个圈里圈外的服务审核时不算数也不查。我在某实验室见过一份范围声明写的是“XX 部门全部 IT 服务”结果 8.3 供应商清单里躺着一堆范围外的外包合同两边对不上整改花了两个月。条款 4 还有个隐藏考点1.2 明确区分了责任归属。组织应证明自身符合条款 4 和 5但可以由其他方提供支持比如代做内部审核或支持 SMS 建设而条款 6 至 10 由其他方参与满足时组织要提供承担责任的证据指向 8.2.3。最后一句最关键如果其他方承担了 SMS 范围内所有服务、服务组件或流程的全部责任组织就不能声称符合本标准。这句话直接否掉了“把运维整体外包出去、自己挂个证”的做法。2.2 三层结构通用层、运行层、闭环层把条款 4 到 10 重新分组会得到一张比目录更好用的地图层级覆盖条款这一层要回答的问题典型产出物通用层4、5、6、7边界在哪、谁拍板、目标怎么量化、资源够不够范围声明、方针、角色职责矩阵、风险机会台账、服务管理目标、成文信息清单运行层8日常服务怎么规划、设计、转换、交付、解决服务目录、SLA、变更与发布记录、事件与问题记录、可用性与容量报告闭环层9、10怎么证明有效、出问题怎么改监视测量结果、内部审核报告、管理评审记录、服务报告、不符合与纠正措施台账通用层是“写下来”的运行层是“跑起来”的闭环层是“查得到”的。三层的证据形态完全不同通用层交文件运行层交记录闭环层交结论。新手最常见的误区是三层的证据互相替代比如拿一堆工单记录去证明 6.2 的服务管理目标已经实现——工单只能证明“做了”证明不了“达成了”。2.3 十条变化里真正影响写文件的是这四条前言列了 a) 到 j) 十条变化其中三条是结构性描述真正会改到你手上文件的是下面四条第一条款 e) 把原先被合并的事件管理、服务请求管理、服务连续性管理、服务可用性管理、服务级别管理、服务目录管理、容量管理、需求管理全部拆成独立条款。拆分的意义不在于数量而在于每一项都要单独取证。2011 版可以写一份“服务运维管理程序”糊过去2018 版不行可用性和容量各有各的要求。第二条款 h) 系统性地削减了强制成文信息删掉容量管理计划文件的要求替换为容量计划的要求删掉可用性计划文件的要求替换为服务可用性要求和目标的要求删掉配置管理数据库要求替换为配置信息要求删掉发布策略要求替换为定义发布类型和频率的要求取消持续改进策略改为确立改进机会的评估标准。方向很清楚——不再要求你写某份叫某某计划的文档而是要求那件事的结果存在。第三条款 g) 把第 3 章术语拆成 3.1 管理体系专用术语和 3.2 服务管理专用术语。“服务提供方”统一改成“组织”“内部小组”改成“内部供方”“供方”改成“外部供方”“可用性”改成“服务可用性”以区别于信息安全语境下的可用性。术语改名的实际影响是如果你的内部文件还写着 2011 版的名词内审时容易被判“未按现行标准建立”虽然不致命但解释成本很高。第四条款 f) 把“由其他各方运行的流程治理”改名为“对涉及服务生命周期各方的管控”并明确阐明其他方承担全部责任时组织无法证明符合性。这条和 1.2 是呼应的落地时要写进供应商管理和内部供方协议里。3. 把要求转成成文信息服务管理计划、SLA 与服务目录的最小写法条款 7.5 是标准的枢轴条款它决定了你后面要写多少纸。7.5 要求组织的 SMS 包含标准所要求的成文信息以及组织为 SMS 有效性所确定的必要成文信息。翻译成人话标准点名的必须有没点名的你自己判断判断的依据是“没有它这件事会不会失控”。3.1 先分清“必须有”和“自己定”把全篇点名的成文信息筛一遍能得到一张最短清单成文信息出处是否可由组织裁剪SMS 范围4.3否必须明确服务管理方针5.2否角色、职责和权限5.3否风险和机会及应对措施6.1否服务管理目标6.2否服务管理计划条款 8 规划与控制否2011 版保留下来的核心文件服务目录8.2 服务组合否服务级别协议与目标8.3 关系和协议否供应商与内部供方协议8.3否容量计划8.7 服务保证要求保留“计划”不保留“计划文件”服务可用性要求和目标8.7同上结果存在即可配置信息8.2 服务组合不要求 CMDB要求配置信息可得发布类型和频率的定义8.5不要求发布策略文件改进机会的评估标准10.2替代了原来的持续改进策略这张表的用法是反过来的先按“必须有”一列建目录再回头检查你现有的文件体系里有没有等价物。很多团队真正缺的不是文件数量而是“服务管理计划”这一份统摄性文件——2011 版就有要求2018 版继续保留但大多数人把它写成了目录页。3.2 服务管理计划该写哪几段服务管理计划不需要长但必须能把条款 6 和条款 8 串起来。我一般按五段搭第一段范围与相关方。直接引用 4.3 的范围声明附上 4.2 识别出的相关方及其需求注明哪些需求转成了服务要求。这一段的作用是让审核员一眼看到边界。第二段目标与测量口径。把 6.2 的服务管理目标逐条列出每条配“指标定义、数据来源、统计周期、责任人”四列。缺了后三列目标就只是口号。第三段服务组合与服务目录的对应关系。列出范围内每个服务标注它是标准服务、可定制服务还是已退役服务以及对应的 SLA 编号。第四段运行控制点。把 8.1 的运营和计划和控制落到具体节奏上日巡检、周变更评审、月度服务报告、季度管理评审。这一段是内审时找证据的时间轴。第五段资源与能力。对应 7.1 和 7.2说明关键岗位的能力要求和当前满足情况。这五段写完通常 8 到 15 页比一份厚厚的程序文件好用得多。常见做法是先写第五段以外的四段跑一个季度再补能力矩阵因为能力要求往往要在实际排班里才能定准。3.3 SLA 和服务级别目标措辞决定能不能审3.2.20 给 SLA 的定义是组织与客户之间用于定义服务及其达成一致服务指标的形成文件的协议并注明 SLA 也可在组织与外部供方、内部供方或作为供方的客户之间建立。3.2.21 把服务级别目标定义为组织承诺的服务的具体可测量的特性。两个定义合起来看一个合格的 SLA 条目要同时具备三个要素服务对象哪个服务、哪个客户群、指标可测量、承诺值。实际写的时候最容易翻车的是“可测量”这一项常见写法问题建议改写系统保持高可用无指标服务可用性不低于 99.5%按月统计计划内停机不计入故障及时响应无时限、无起算点一级事件 15 分钟内响应起算点为工单创建时间尽快恢复服务无承诺值一级事件 4 小时内恢复超时触发升级流程用户满意度良好无口径季度满意度调查平均分不低于 4.05 分制样本量不少于 30改写之后还要补一条统计口径和数据来源。99.5% 是按自然月还是按合同月度计划内停机怎么扣这些不写清楚到年底跟客户对数时就是一场拉锯战。血泪经验是把所有“不计入”的例外情形在 SLA 附件里逐条列出来宁可写长一点。3.4 服务目录和配置信息是两回事3.2.17 定义服务目录为组织向其客户提供服务的成文信息注意是“向客户提供”所以服务目录是面向客户的视图写的是客户能买到什么、边界在哪。而 3.2.2 的配置项定义是“需要加以控制以提供服务的一个元素”配置信息是面向内部的视图写的是支撑这些服务的东西有哪些。2018 版删掉了配置管理数据库CMDB的强制要求改成配置信息要求这不是放松而是把判断权交回来了你得自己说清楚哪些配置项需要控制、控制到什么颗粒度、信息存在哪里。我一般建议从服务目录倒推每个服务下挂 5 到 15 个关键配置项先覆盖能直接影响服务可用性的那批别一上来就追求全量。服务目录的写法上一个坑是把内部团队名当服务名。客户买的是“邮件服务”不是“基础架构二组支持”服务目录里出现组织架构名称基本说明还没从 2011 版的职能视角转过来。4. 条款 8 的流程落地事件、问题、变更、可用性与容量的接口参数条款 8 是整本标准里最厚的一块占了目录的一半以上。它的组织方式不是按流程一个个排而是按“运行规划和控制 → 服务组合 → 关系和协议 → 供应和需求 → 服务设计、建立和转换 → 解决和实现 → 服务保证”七段推进。理解这个顺序比背子条款编号有用。4.1 8.6 解决和实现事件与服务请求必须分开3.2.5 对事件的定义是服务的意外中断以及导致服务质量下降但尚未对客户或用户的服务产生影响的事项。后半句是 2018 版的关键变化——“尚未产生影响”也算事件这比 2011 版严格意味着你不能等到用户报障了才开工单。而服务请求是另一类东西用户主动提出的、标准化的、可预先定义处理路径的诉求。3.2.14 变更请求的定义里提到服务变更包括提供新服务、转移服务或删除不再需要的服务可见变更、请求、事件三者是有明确边界的。落地时的判定顺序可以固化成三步第一步看是不是中断或降级。是走事件否则进第二步。 第二步看是不是标准化诉求。是走服务请求否则进第三步。 第三步看是不是要改配置或改服务本身。是走变更请求否则退回需求管理。这个顺序写进流程文件后工单类型混乱的问题基本能压下去一半。剩下的那一半靠培训——让一线知道“用户说系统慢”不一定是事件可能只是容量问题得走 8.7 的容量管理。踩过的坑是把服务请求当事件统计导致事件量虚高、MTTR 失真服务报告里的数字连自己都不信。4.2 8.5 变更、发布和部署类型和频率要写成可控参数前言 h) 第 4 条专门提到删除了发布策略要求替换为定义发布类型和频率的要求。这条被大量组织误读成“不用写发布策略了”实际上要求更硬——你得定义清楚有哪几类发布、每类的频率是多少。一个可落地的参数表长这样发布类型触发条件频率审批层级回退时限紧急修复一级事件根因修复按需月度不超过 4 次值班经理 变更经理30 分钟内常规发布计划内功能或配置调整双周一次变更评审会2 小时内重大发布涉及架构调整或跨系统季度一次变更评审会 服务负责人4 小时内需回退预案这张表的价值在于它同时约束了三件事变更管理的审批负担、发布窗口的容量、回退能力的下限。3.2.13 把发布定义为“作为一项或多项变更的结果部署到实际运行环境服务或服务组件以及新服务的一个或多个变更的组合”注意发布是变更的组合不是单个变更——所以发布的回退方案必须覆盖组合内所有变更不能只写主变更的回退。4.3 8.7 服务保证四项能力的指标口径服务保证项下是可用性、容量、连续性、信息安全四块。它们的共同点是都属于“非功能性”要求最容易被写成“我们会保障 XX”也最容易在审核时被判无证据。能力项关键术语指标口径要写清什么取证材料服务可用性3.2.16 服务可用性约定时间窗、可用判定标准、计划内停机是否计入月度可用性统计、停机台账容量8.7 容量管理当前用量、阈值、扩容触发条件与提前期容量计划、趋势分析服务连续性3.2.19 服务连续性关键服务、RTO/RPO、演练频率连续性方案、演练报告信息安全3.2.6 信息安全机密性、完整性、可用性三类控制点风险评估、事件记录3.2.16 明确说服务可用性可表示为服务或服务组件实际可用的时间与约定时间的比率或百分比这个比率的分母就是“约定时间”所以口径必须写在 SLA 里不能事后解释。3.2.19 提到服务连续性管理是业务连续性管理的子过程这一句给了个很好的复用提示如果组织已经有业务连续性体系连续性这块可以直接引用上位文件不必另起炉灶。3.2.6 信息安全沿用 ISO/IEC 27000:2018 的定义即保护信息的机密性、完整性和可用性注释里还提到真实性、可核查性、不可否认性和可靠性也可以包括进来。这意味着如果你的组织已经过了信息安全管理体系认证8.7 的信息安全部分可以做接口复用避免两套体系各查各的。4.4 8.3 和 8.4内部供方、外部供方与需求管理3.2.8 对内部供方的定义是“大型组织中服务管理体系范围之外的一部分该部分签订有成文的协议以促进规划、设计、转换、交付或者改进服务、服务组件或过程”举的例子是采购、基础设施、财务、人力资源、设备等部门。这个定义解释了一个高频困惑为什么同一个公司内部的部门还要签协议因为它在 SMS 范围之外。3.2.4 的外部供方是“与组织签订合同参与规划、设计、转换、交付或者改进服务、服务组件或者过程的组织外方”并且注明外部供方包括指定的主要供方但不包括其分包供方。这里要注意分包链条——如果你的主要供方把一部分活转包了那部分在标准视角下不自动算你的外部供方但 8.3 的关系和协议仍然要覆盖对它的管控。配合 1.2 的“组织应承担本标准中规定要求责任的证据见 8.2.3”这条链就完整了协议签了不算完得有不定期抽查、服务回顾会、绩效评分这类管控证据。某公司曾经把服务台整体外包合同齐全、月度报告也有但审核时被判 8.3 不符合原因是他们拿不出“对外包方处理事件的准确性做过任何验证”的证据——报告是对方写的组织只是转发。8.4 供需里最容易被跳过的是需求管理。它要求组织收集、分析当前和未来的服务需求并把需求转成服务要求。实际操作中需求管理的输出往往和 6.1 的风险机会台账、8.2 的服务组合变更连在一起所以建议在需求评审表上加两个字段这条需求会影响哪个服务条目、是否需要触发变更请求。不加这两个字段需求评审就永远是走过场。5. 转版与预审阶段的五类典型问题现象、成因与处置这一节按“现象 → 原因 → 解决”来写都是我在实际准备过程中反复遇到的。5.1 范围声明写成了部门清单现象4.3 的 SMS 范围写的是“信息技术部、运维部、数据中心”审核员追问“这三个部门提供的哪些服务在范围内”时答不上来。原因把组织边界当成了服务边界。4.3 要求确定的是 SMS 的范围而 SMS 覆盖的是服务不是组织架构图。解决范围声明改成“服务 地点 支撑组织”三段式。先列服务目录里在范围内的服务条目再写提供服务的地点最后写参与支撑的组织单元。改完之后8.2 服务组合、8.3 供应商清单、9 绩效评估的对象都能对齐同一份清单。5.2 每个子条款配一份程序文件文件之间互相冲突现象条款 8 拆细之后团队按 8.2、8.3、8.5、8.6、8.7 各写一份程序文件结果事件管理程序里写的升级时限和 SLA 里的承诺值不一致变更程序里的审批层级比发布程序里少一级。原因编文件的人各写各的没有以服务管理计划为顶层约束。标准并不要求一个条款对应一份文件这是自己加的负担。解决先定服务管理计划的四张附表——服务清单、角色职责矩阵、目标与口径表、流程接口表所有下级文件只允许引用附表不允许另立数值。文件数量从十几份压到五六份冲突面自然消失。5.3 SLA 有指标没有测量口径现象SLA 写了“可用性不低于 99.5%”年度评审时客户拿出自家监控数据说只有 98.7%双方对不上。原因3.2.21 要求服务级别目标是“具体可测量的特性”但没规定测量方法必须由谁定结果就是各测各的。分母口径、采样点位置、计划内停机处理方式这三项任意一项不一致结果就能差出几个百分点。解决在 SLA 附件里固定三件事——监测工具与探针位置、统计周期与出数时间、免责情形清单。有条件的话让客户参与月度数据确认把争议前置到每个月而不是攒到年底。5.4 供应商管控只有合同没有责任证据现象8.3 的供应商档案里躺着厚厚一叠合同和保密协议审核员翻了两分钟就问“上季度你们对这个供方的服务绩效做过什么评价”。原因把“有关系”当成了“有管控”。1.2 要求组织承担条款 6 至 10 的责任证据合同只证明关系存在证明不了管控发生。解决给每个关键外部供方建一份管控记录至少包含季度绩效评分、问题整改跟踪、服务回顾会纪要三样。评分表可以简单到五个维度各打一分但必须有且必须有组织方签字不能只有供方自己出的月报。5.5 把参考译本当正式引用版本现象内部文件、投标材料里直接写“依据 ISO/IEC 20000-1:2018 中文版第 X 条”被对方要求提供正式发布版本时拿不出来。原因手上这份是面向审核人员参考使用的中文译本不是正式发布的等同采用版本。用它做内部理解和落地推演完全没问题但对外引用、写进合同附件时措辞和条款编号都要以正式发布版本为准。解决内部培训、流程设计、gap 分析用译本效率高、读得顺对外文件里统一写标准号不引用具体译文措辞。团队内部约定一句口头规则就够了——译本用来干活正式版本用来签字。6. 用这份译本做一次内部 gap 分析打分表、抽样与取证节奏预审阶段最高效的动作是把条款 4 到 10 逐条变成一张可打分的检查表而不是开会讨论“我们大概齐差不多了”。我一般的做法是三列打底、加两列管理字段条款检查项要什么证据现有证据成熟度 0-3责任人4.3SMS 范围声明含服务、地点、支撑组织有文档但不含服务清单1服务负责人5.3角色职责矩阵覆盖标准要求的职责有岗位说明书未映射标准条款1HR 服务负责人6.1风险机会台账含应对措施和责任人有台账措施栏空白1服务负责人7.5成文信息清单标注保存期限与载体无0质量岗8.6事件与服务请求分类规则及近三个月工单有工单分类混用1服务台主管9内部审核报告覆盖全部条款有但只覆盖 81内审员成熟度就定四档0 是没有1 是有但不满足要求2 是满足但无持续记录3 是满足且有连续三个月以上记录。这个分档的好处是它逼你区分“写了”和“跑起来了”很多组织卡在 2 分自己以为已经到位了。抽样节奏上条款 8 的记录类证据按“近三个月 近一次重大变更”两个维度抽条款 9 和 10 的记录按“最近一个完整周期”抽。取证时优先要原始记录不要汇总报表——汇总报表能证明结论证明不了过程而审核看的是过程。还有一个我踩过的坑值得单独说gap 分析不要一次铺满全部条款。第一次先做条款 4、5、6、7 这四章因为它们决定后面所有章的边界和口径这四章的分值稳定在 2 分以上之后再做条款 8否则你会把大量时间花在改流程文件上而流程文件改了边界又变白改。我自己吃过这个亏第一轮就把条款 8 的十几个流程全部重写了一遍结果半个月后范围声明调整三分之一的流程要推倒重来。从那以后我每次接手这类认证准备都强制先只做一件事把条款逐条写成“要求—证据—责任人”三列表填不满的行就是风险点按分值排序处理绝不靠开会讨论进度。希望帮到你。本文还有配套的精品资源点击获取