企业官网建设流程全解析

简介：这份《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 重新分组，会得到一张比目录更好用的地图：

通用层是“写下来”的，运行层是“跑起来”的，闭环层是“查得到”的。三层的证据形态完全不同：通用层交文件，运行层交记录，闭环层交结论。新手最常见的误区是三层的证据互相替代，比如拿一堆工单记录去证明 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 先分清“必须有”和“自己定”

把全篇点名的成文信息筛一遍，能得到一张最短清单：

这张表的用法是反过来的：先按“必须有”一列建目录，再回头检查你现有的文件体系里有没有等价物。很多团队真正缺的不是文件数量，而是“服务管理计划”这一份统摄性文件——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% 是按自然月还是按合同月度？计划内停机怎么扣？这些不写清楚，到年底跟客户对数时就是一场拉锯战。血泪经验是，把所有“不计入”的例外情形在 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 条专门提到：删除了发布策略要求，替换为定义发布类型和频率的要求。这条被大量组织误读成“不用写发布策略了”，实际上要求更硬——你得定义清楚有哪几类发布、每类的频率是多少。

一个可落地的参数表长这样：

这张表的价值在于它同时约束了三件事：变更管理的审批负担、发布窗口的容量、回退能力的下限。3.2.13 把发布定义为“作为一项或多项变更的结果，部署到实际运行环境，服务或服务组件以及新服务的一个或多个变更的组合”，注意发布是变更的组合，不是单个变更——所以发布的回退方案必须覆盖组合内所有变更，不能只写主变更的回退。

4.3 8.7 服务保证：四项能力的指标口径

服务保证项下是可用性、容量、连续性、信息安全四块。它们的共同点是都属于“非功能性”要求，最容易被写成“我们会保障 XX”，也最容易在审核时被判无证据。

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 是没有；1 是有但不满足要求；2 是满足但无持续记录；3 是满足且有连续三个月以上记录。这个分档的好处是它逼你区分“写了”和“跑起来了”，很多组织卡在 2 分，自己以为已经到位了。

抽样节奏上，条款 8 的记录类证据按“近三个月 + 近一次重大变更”两个维度抽，条款 9 和 10 的记录按“最近一个完整周期”抽。取证时优先要原始记录，不要汇总报表——汇总报表能证明结论，证明不了过程，而审核看的是过程。

还有一个我踩过的坑值得单独说：gap 分析不要一次铺满全部条款。第一次先做条款 4、5、6、7 这四章，因为它们决定后面所有章的边界和口径；这四章的分值稳定在 2 分以上之后再做条款 8，否则你会把大量时间花在改流程文件上，而流程文件改了边界又变，白改。我自己吃过这个亏，第一轮就把条款 8 的十几个流程全部重写了一遍，结果半个月后范围声明调整，三分之一的流程要推倒重来。

从那以后我每次接手这类认证准备，都强制先只做一件事：把条款逐条写成“要求—证据—责任人”三列表，填不满的行就是风险点，按分值排序处理，绝不靠开会讨论进度。希望帮到你。

本文还有配套的精品资源，点击获取