企业官网建设流程全解析

简介：ISO/IEC 20000-1:2018中文版PDF是信息技术服务管理体系（ITSM）领域的国际标准正式译本，由北京中大华远认证中心翻译，面向认证审核人员、IT服务管理者及体系咨询从业者，用于依据新版标准实施审核与体系建设。标准于2018年9月发布，取代2011版，围绕服务管理体系（SMS）的建立、实施、维护与持续改进提出要求，正文涵盖组织背景、领导力、规划、支持、体系操作、绩效评估与改进等章节，并给出服务组合、关系与协议、供需、服务设计构建与转换、解决与履行等过程的详细条款，同时收录管理体系与服务管理专用术语。资源包共1个PDF文件，约551KB，目录结构完整、条款编号清晰，便于按章节检索与对照学习。目前已有4358人学习下载，适合需要系统研读标准原文、准备审核或搭建服务管理体系的读者参考使用。

1. 从一份 29 页的中文译稿说起：ISO/IEC 20000-1:2018 到底解决什么问题

很多做 IT 服务管理的同行第一次接触 ISO/IEC 20000-1，都是在甲方审核或者投标文件里被“服务管理体系”这几个字卡住。手上拿到的往往是一份英文原版，条款结构复杂、术语密度高，光“服务”“服务组件”“配置项”这几个词就够绕半天。这份 29 页的中文译稿，把 2018 年第三版的正文、前言、引言和术语定义完整翻了出来，覆盖从第 1 章范围到第 10 章改进的全部条款，对需要对照标准做体系文件、内审检查表或者认证准备的人来说，省掉了大量逐句啃英文的时间。它适合三类人：正在搭建或转版 SMS 的体系负责人、需要按条款出审核证据的内审员、以及给客户做 IT 服务交付却总被问“你们有没有体系”的项目经理。下面我不讲标准发展史，只讲这份译稿怎么读、怎么用、哪些地方容易翻车。

2. 条款结构拆解：从第 4 章到第 10 章怎么对应到实际工作

2.1 高阶结构（HLS）带来的条款重组逻辑

2018 版最大的变化是全面采用附件 SL 的高阶结构，把原来 2011 版按流程罗列的写法，改成了和其他管理体系标准（比如 ISO 9001、ISO/IEC 27001）对齐的十章框架。译稿前言里写得很清楚：第三版取消了第二版，进行了技术性修订，结构重组后引入了“组织背景”“目标策划”“应对风险和机会”这些通用要求。这意味着如果你手上还有 2011 版的体系文件，不能直接改个年份就用，条款映射关系变了。

具体到章节，第 4 章“组织的背景”要求你先搞清楚组织环境、相关方需求和 SMS 范围；第 5 章“领导力”对应最高管理者的承诺、方针和角色权限；第 6 章“规划”处理风险和机会、服务管理目标及其实现规划；第 7 章“支持”覆盖资源、能力、意识、沟通、成文信息和知识；第 8 章“运行”是整份标准最厚的一块，从运营计划控制、服务组合、关系和协议、供需，一直写到服务设计构建转换、解决和履行、服务保证；第 9 章“绩效评估”管监测测量分析和评估、内部审核、管理评审、服务报告；第 10 章“改进”分不符合和纠正措施、持续改进两条。

读这份译稿时，建议先看目录页的条款编号，再跳到对应正文。译稿的目录保留了完整的层级编号，比如 8.5 是“服务设计，构建和转换”，8.6 是“解决和履行”，8.7 是“服务保证”，每个一级条款下还有细分。对照目录定位比从头翻要快得多。

2.2 第 8 章运行条款的落地映射

第 8 章是实操中最常被审核追问的部分。译稿把 8.2 服务组合拆成了服务交付、服务计划、服务生命周期涉及的相关方的控制、服务目录管理、资产管理、配置管理；8.3 关系和协议拆成商务关系管理、服务等级管理、供应商管理；8.4 供需拆成服务的预算和核算、需求管理；8.5 服务设计构建和转换拆成变更管理、服务设计和过渡、发布和部署管理；8.6 解决和履行拆成事件管理、服务请求管理、问题管理；8.7 服务保证拆成服务可用性管理、容量管理、服务连续性管理、信息安全管理。

这个拆分方式和 2011 版差别很大。2011 版把事件管理、服务请求管理、服务连续性管理、服务可用性管理、服务级别管理、服务目录管理、容量管理、需求管理这些流程合并在一起写，2018 版做了条款分离。译稿前言第 e 条专门提到了这一点。做体系文件时，如果你的程序文件还是按 2011 版的流程名来编，审核员对照 2018 版条款时会对不上号，需要重新做一次条款与文件的映射表。

2.3 术语变化对文件编写的影响

译稿第 3 章把术语分成了 3.1 管理体系标准专用术语和 3.2 服务管理专用术语两组。几个关键变化必须注意：“服务提供方”被“组织”取代，“内部小组”被“内部供方”取代，“供方”被“外部供方”取代。“信息安全”的定义和 ISO/IEC 27000 保持一致，“可用性”被“服务可用性”取代，以区别于信息安全领域的“可用性”。

这些术语变化直接影响体系文件的措辞。比如你原来的《服务提供方管理程序》按 2018 版应该改成《外部供方管理程序》或者《供应商管理程序》，原文里的“服务提供方”要替换成“组织”或“服务提供者”（注意 3.2.24 又定义了“服务提供者”这个术语，和“组织”有区分）。译稿在术语条目下保留了注释，比如 3.1.14“组织”的注 2 写明“管理和提供服务或向内部客户或外部客户提供服务的组织或组织部分可称为服务提供方”，注 3 说明如果 SMS 范围仅涵盖组织的一部分，则“组织”指 SMS 范围内的部分。这些注释在写体系文件时是重要的边界依据。

3. 用这份译稿做体系文件对照：一份可抄的条款映射操作

3.1 建立条款与现有文件的映射表

拿到译稿后，第一步不是从头读，而是做一张映射表。用表格把译稿的条款编号、条款名称、你现有体系文件的名称、文件编号、版本号对应起来。下面是一个映射表的字段示例，你可以直接拿去用：

这张表的作用是让你一眼看出哪些条款有文件覆盖、哪些是空白、哪些文件需要修订。译稿的目录页可以直接作为条款清单来源，29 页的篇幅里目录占了 2 页，条款编号完整，抄起来不费劲。

3.2 用译稿术语表统一文件措辞

术语不统一是内审时最常见的低级不符合。译稿第 3 章给出了完整的术语和定义，建议把 3.1 和 3.2 两组术语做成一份术语对照表，发给所有写文件的人。比如：

• “服务提供方”统一改为“组织”或“服务提供者”，视语境而定
• “内部小组”统一改为“内部供方”
• “供方”统一改为“外部供方”
• “可用性”在服务管理语境下统一改为“服务可用性”
• “配置管理数据库”不再作为强制文件要求，改为“配置信息”

译稿前言第 g 条和第 h 条详细列出了这些变化。特别是第 h 条提到，2018 版最小化了成文信息的要求，删除了容量管理计划文件、可用性计划文件、配置管理数据库、发布策略、持续改进策略这些强制文件要求，替换为容量计划、服务可用性要求和目标、配置信息、发布类型和频率、改进机会评估标准。这意味着你的文件清单可以精简，但精简的前提是你能证明这些策划活动确实在运行。

3.3 内审检查表的条款抽样方法

做内审时不可能把 29 页条款全部查一遍，需要抽样。抽样逻辑是按第 8 章运行条款的高风险区域来选。译稿 8.2.3 提到“对涉及服务生命周期各方的管控”，8.3.2 服务等级管理，8.5.1 变更管理，8.6.1 事件管理，8.7.4 信息安全管理，这几个条款是审核员最爱追问的。

一个可操作的抽样方法是：每个一级条款至少抽一个二级条款，第 8 章每个二级条款至少抽一个三级条款。比如抽到 8.5.1 变更管理，就查变更请求记录、变更评审记录、变更授权记录、变更后评审记录。译稿在 8.5 条款下对变更管理的输入输出有描述，对照着查证据是否齐全。

提示：译稿是认证中心翻译的参考版本，条款编号和英文原版一致，但措辞上有个别地方存在翻译腔。做体系文件引用时，建议以英文原版条款编号为准，中文措辞可以参考译稿但不必逐字照搬。

4. 避坑与排查：读这份译稿时最容易翻车的五个地方

4.1 把译稿当正式标准引用

现象：在体系文件或投标文件里直接写“依据 ISO/IEC 20000-1:2018 中文版第 X 条”，但没有注明译稿来源。

原因：这份译稿是认证中心翻译的参考版本，不是官方发布的中文标准。译稿前言和页脚都写明了“仅供认证人员在依据 ISO/IEC 20000-1:2018 标准实施认证审核时参考使用”。

解决：引用标准条款时，用英文原版的条款编号和名称，中文翻译作为理解辅助。如果一定要用中文表述，注明“参考译稿”并附英文原文条款号。

4.2 忽略 2011 版到 2018 版的条款映射

现象：体系文件转版时只改了封面年份，条款结构和文件内容没动，内审时发现大量条款对不上。

原因：2018 版采用了高阶结构，条款编号和 2011 版完全不同。译稿前言第 a 条到第 j 条列出了十项主要变化，包括结构重组、术语更新、文件要求精简、流程条款分离等。

解决：先做一张 2011 版到 2018 版的条款映射表，再逐条检查现有文件是否覆盖新条款。译稿目录可以作为 2018 版条款清单，2011 版条款清单需要另外找。

4.3 误读“删除文件要求”为“不需要做”

现象：看到译稿前言说删除了容量管理计划、可用性计划、配置管理数据库等文件要求，就把这些文件全部废止，结果审核时被开不符合。

原因：2018 版删除的是“计划文件”这个强制载体要求，不是删除策划活动本身。译稿前言第 h 条写的是“删除了容量管理计划文件的要求，并替换为容量计划的要求”，意思是你可以用任何形式记录容量计划，但策划活动必须有。

解决：文件可以简化，但策划记录、评审记录、更新记录要保留。比如容量管理，你可以不做一份独立的《容量管理计划》，但要有容量需求分析、容量规划、容量监控和调整的记录。

4.4 术语混用导致内审沟通偏差

现象：内审时审核员问“外部供方管理”，被审核部门回答“我们供应商管理程序里有”，但程序里写的是“服务提供方”，双方对不上。

原因：2018 版把“供方”改为“外部供方”，“服务提供方”改为“组织”或“服务提供者”。译稿第 3 章术语表有完整定义，但很多组织的文件没有同步更新。

解决：做一份术语对照表，把旧术语和新术语并列，发给所有相关部门。内审前先做一次术语培训，确保审核员和被审核方用同一套语言。

4.5 第 8 章条款分离后接口关系不清

现象：事件管理和问题管理分开后，事件升级到问题的触发条件没有定义，导致问题管理记录缺失。

原因：2011 版把事件管理和问题管理放在一起写，2018 版做了条款分离，译稿 8.6.1 是事件管理，8.6.3 是问题管理，两者之间的接口需要组织自己定义。

解决：在事件管理程序里明确写清楚什么情况下事件要升级为问题，比如重复发生的事件、重大事件、根因不明的事件。译稿 3.2.9 定义了“已知错误”，3.2.10 定义了“问题”，对照这两个定义来设定升级条件。

5. 从译稿到审核证据：一个条款取证的具体技巧

读标准最终是为了出证据。我一般会拿译稿的条款当检查清单，逐条问三个问题：有没有策划、有没有执行、有没有检查。以 8.7.4 信息安全管理为例，译稿在 8.7 服务保证下写了信息安全管理的要求，但具体条款内容需要对照正文。取证时我会按下面的路径走：

第一步，查信息安全方针和信息安全风险评

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