ISO20000 IT服务管理体系

ISO/IEC 联合标准 · 第三方认证

ISO 20000 IT服务管理体系认证

ISO/IEC 20000-1:2018 — IT Service Management System

全球IT服务管理的"国际标准"——它不是让你学会"怎么做IT运维"，而是建立一套从服务目录→SLA承诺→事件/问题/变更→服务报告→持续改进的管理体系。它不保证你的服务器不出故障，但保证你的IT服务有标准流程、有SLA指标、有持续改进机制——让IT部门从"成本中心"变成"可度量的服务提供者"。

4-8
个月获证
3年
证书有效期
34
项服务管理过程
 
OVERVIEW

ISO 20000 不是"IT运维工具箱"——它是"IT服务管理体系"

4张卡片——从ITIL根基到商业价值

 
⚙

什么是ISO 20000

ISO 20000是ISO（国际标准化组织）和IEC（国际电工委员会）联合发布的IT服务管理体系标准——最新版本为ISO/IEC 20000-1:2018。它与9001/27001等管理体系使用统一的HLS高阶结构（10个条款编号完全相同）——但管控的对象不是产品质量或信息安全——而是IT服务的全生命周期。它基于ITIL最佳实践但不等于ITIL——ISO 20000规定"你必须有服务级别管理、事件管理、问题管理等过程"，但不规定你必须用ITIL的哪一版。

📚

ISO 20000和ITIL的关系：标准vs最佳实践

这是全行业最核心的概念混淆。ITIL（信息技术基础架构库）是最佳实践框架——告诉你怎么做最好——但ITIL没有认证审核——你不能"拿到一张ITIL证书"。ISO 20000是可认证的国际标准——告诉你怎么做才算达标——审核员持ISO 20000条款对你逐项验证。两者的关系是：ITIL给方法（how）→ISO 20000给标准（what must）→审核员拿标准丈量你的方法是否有效。因此实践中——企业通常先按ITIL建框架→再对照ISO 20000条款做差距分析→补足缺失→拿证。

📈

管理什么：34个服务管理过程的四维架构

ISO 20000-1:2018定义了34个服务管理过程——分布在四大维度中：服务交付过程（服务级别管理/报告/预算核算/容量/可用性/连续性/信息安全）→关系过程（业务关系/供应商管理）→解决过程（事件/服务请求/问题管理）→控制过程（变更管理/配置管理/发布部署管理）。34个过程不是34个独立文件——而是互相依赖的服务管理生态——事件触发问题、问题驱动变更、变更同步配置库、配置库支撑所有过程。

🏆

认证的商业价值：IT外包合同的"信任通行证"

ISO 20000在IT外包和服务采购中有独特的"信任溢价"——比ISO 9001更精准地证明"你的IT管理能力"。如果你是一家IT运维/IDC/云服务/系统集成商——客户招标文件中越来越多的出现"投标人须具备ISO 20000认证"——这不是加分项而是准入门槛。如果你是企业内部的IT部门——ISO 20000的体系框架可以帮你把"IT究竟干了什么/花在哪里/响应多快"量化为可汇报给CEO的管理报表——从此IT预算申请有数据支撑。

ITIL vs ISO 20000 vs ISO 9001

三件事三个层级：最佳实践 → 服务标准 → 质量体系

三者缺一不可——但定位完全不同

 
ITIL

ITIL（最佳实践）

告诉你"怎么做"的最佳实践框架——34个管理实践涵盖服务价值链全流程。ITIL没有认证审核——你学完ITIL不等于拿到任何证书——但ITIL的知识体系是建立ISO 20000体系的唯一方法来源——你不用ITIL方法论就写不出ISO 20000要求的管理过程文件。

20K

ISO 20000（服务管理标准）

告诉你"做到什么地步才算达标"的可认证标准——审核员拿着34个过程的条款逐项验证。它是ITIL方法论的"检查清单版"——你不必完全照搬ITIL每个实践细节——但你必须证明每个过程的存在性+有效性+持续改进机制。

9K

ISO 9001（质量管理体系）

告诉你"怎么保证质量"的通用管理体系——管的是产品/服务质量+客户满意——不局限于IT服务。ISO 20000和9001共用HLS框架——天然适合一体化整合——9001覆盖"质量"，20000覆盖"IT服务"，两者加起来=IT服务商的全域管理能力证明。

最务实的路径：先学ITIL建立方法论→再做ISO 20000拿到证书→再做ISO 9001覆盖质量维度。三个体系可以同时推进——共用一套文件架构（手册/方针/目标/内审/管审）——最大程度复用体系建设工作——认证审核时也可以安排联合审核（一个审核组一次审核出三张证）。
COMPARISON

ISO 20000 vs 9001 vs 27001——IT企业的"三角认证"

三个标准管三件事——合在一起=IT服务商的完整能力拼图

 
维度 ISO 20000（IT服务） ISO 9001（质量） ISO 27001（信息安全）
管控对象 IT服务的设计、交付和改进 产品和服务的质量+客户满意 信息资产的CIA三性
核心方法论 ITIL + 服务管理过程 过程方法 + PDCA 风险评估 + 控制措施
关键文件 服务目录 + SLA + 服务报告 质量手册 + 过程文件 资产清单 + 风险评估报告 + SoA
典型KPI 事件响应时间/SLA达成率/变更成功率/可用性指标 客户满意度/一次合格率/投诉处理时效 安全事件次数/补丁安装时间/访问权限审查频率
谁最需要 IT运维/IDC/云服务/系统集成/IT外包 制造业/工程/食品——所有行业通用 软件开发/SaaS/金融/医疗/政府IT
审核员关注什么 "你说的SLA做得到吗"——抽查服务报告和事件记录交叉比对 "你的过程受控吗"——抽查生产/服务记录 "你管好了信息资产吗"——抽查风险评估和SoA一致性
与中国其他资质关系 独立标准——没有中国本土替代品 通用体系——可映射到各行业质量体系 与等保互补——27001管体系/等保管系统
三者关系 IT服务商的核心能力证明——证明你能管好IT 基础质量证明——证明你做得好 安全能力证明——证明你管得严
IT服务商的最佳认证组合：ISO 20000 + ISO 27001（双标同审——共用HLS框架——一次内审+一次管审覆盖两套体系）。如果你的主营业务是IT运维外包/IDC托管/云服务——两套体系合在一起的成本增量远小于分别做——因为50%以上的体系文件（方针/目标/内审/管审/文件控制/记录控制）可以共用——只需在20000的服务过程文件之上加上27001的风险评估和SoA即可。
WHO NEEDS IT

哪些企业在做ISO 20000

8个最高频场景——从IT外包到金融机构IT部门

 
🖥

IT运维外包

传统IT外包商的第一张"能力证书"——客户招标第一条就是20000——"你能用什么标准管理我的IT"——没有20000=丢失入场资格

☁

IDC/云服务商

机房托管和云服务=IT服务产品的标准形态——服务目录+SLA+可用性承诺——天然就是20000的管理对象

💻

系统集成/MSP

管理服务提供商(MSP)——你的产品就是"替客户管IT"——20000是你的"产品说明书"——客户通过你的20000证书了解你的服务能力

🏦

大型企业IT部门

自建IT部门不需要"客户认可"但需要"CEO认可"——20000让你能把IT投入转化为可度量的服务报告——IT预算从此有理有据

🏧

银行/金融IT中心

银保监对银行IT连续性管理有强监管要求——20000的连续性/可用性/容量管理完美映射监管检查项——一张证覆盖多项合规

🏥

医院IT / 政务IT

HIS系统/PACS系统运维——系统宕机=诊疗中断——20000的事件管理/问题管理/变更管理直接保障医疗业务连续性

🔧

软件运维/DevOps

SaaS公司的运维团队——客户问"你们SLA是多少/变更发布多久一次/故障恢复多长时间"——20000让你把所有问题量化为服务报告

🌐

跨国IT服务出海

承接海外客户的IT运维外包——国外客户对"你有ISO 20000吗"的认知比国内更成熟——它是国际IT服务采购的通用语言

6 PROCESS GROUPS

ISO 20000 六大核心服务管理过程组

34个过程模块——分布在六大过程组中——这是20000与其他ISO标准最根本的内容差异

 
1

服务交付过程(Service Delivery)

这是20000体系的"心脏"——服务级别管理(SLM)定义每个服务的SLA指标（响应时间/可用性/恢复时间）→服务报告定期出具→预算核算管理服务成本→容量管理确保资源够用→可用性管理确保服务在线→服务连续性管理确保灾难可恢复→信息安全管理。这7个子过程合在一起=服务承诺+服务监控+服务保障的完整闭环。

2

关系过程(Relationship)

对外关系的"两面管理"：业务关系管理(BRM)——管理你和你客户的关系——定期服务回顾会议——客户满意度调查——服务投诉处理。另一方是供应商管理——你用的云平台/硬件维保/线路就是你的供应商——供应商的SLA会影响你的SLA——"供应商故障导致你SLA不达标"=你的责任（客户不关心供应商是谁）。

3

解决过程(Resolution)

IT运维的日常——事件管理（故障处理——目标=尽快恢复服务）和服务请求管理（标准化请求——如开通账号/安装软件——走标准化流程）。两者的根本区别：事件="坏了"（恢复服务→可能用临时方案）+ 服务请求="要个东西"（交付标准结果）。问题管理则是"事后复盘"——找根因→永久修复→防止复发——事件和问题的分离是成熟IT组织的标志。

4

控制过程(Control)

变更管理——IT组织中最容易出事故的环节。按标准分三类：标准变更（预授权——低风险——走简单流程）、正常变更（须CAB评审——中等风险）和紧急变更（事后补手续——但须有明确授权+回滚方案）。变更管理旁有配置管理——所有IT资产和服务组件的配置项(CI)和关系存入CMDB——是你变更评估的数据基础。发布和部署管理——从测试环境推到生产环境的受控过程。

5

服务目录 + SLA体系

服务目录不是简单的服务列表——它是你对外承诺的正式文档。标准服务目录须含：服务名称+服务描述+服务时间+响应时间+解决时间+升级路径+服务限制（如"仅覆盖工作日9:00-18:00——非工作时间响应时间×4"）。SLA是服务目录的法律化版本——签署后成为合同义务。SLA指标须"可度量+可报告+有基线和趋势分析"——"我们事故很少"不等于SLA——必须用数据说话。

6

服务报告——体系的"仪表盘"

服务报告是20000体系的"输出端"——它向客户和管理层证明"我做的事情有结果"——须含：SLA达成率（每一服务的每一指标）→事件统计（总量/趋势/分类/平均解决时间）→变更统计（总量/成功率/回滚率）→容量趋势（存储/CPU/带宽/许可证消耗率）→客户满意度趋势→重大事件回顾和改进。服务报告不是做给审核员看的——是做给客户和管理层看的——是IT证明自身价值的唯一途径。

这六组不是孤立的——它们之间有强依赖关系：服务目录定义了"我提供什么"→SLA定义了"多快多好"→事件管理处理"什么时候坏了"→问题管理找出"为什么会坏"→变更管理控制"怎么修好"→配置管理提供"修什么的数据"→服务报告汇总"修得怎么样"。这个闭环是20000体系审核的核心——审核员会随机抽取一个真实事件——回溯整个链条中的每一个过程——看你的执行记录——"你们的系统真在按自己文件写的运作吗"。
VS REALITY

ISO 20000的体系 vs 现实中的"IT服务"——两个世界的碰撞

澄清三个最高频的认知偏差——"我们已经有ITIL了""我们已经在做运维了""这不就是写流程文件吗"

 
维度 裸奔的IT运维 做了ITIL的IT团队 通过ISO 20000认证的IT组织
事件处理 谁有空谁接→靠记忆和微信群——处理结果无记录——同一故障反复出现 有了工单系统→有事件分类→但SLA是口头约定——没人追踪达成率 工单系统+SLA自动计时+超时自动升级→月报自动生成SLA达成率——事件记录可追溯
变更管理 "你改一下服务器配置"——没有审批→没有回滚方案→出问题靠经验抢救 有变更流程文档→但"紧急"大过天——大部分变更是"事后补单" 变更分类+分级审批+CAB评审+测试方案+回滚方案+变更窗口——变更成功率可量化
问题管理 没有"问题"概念——只有"故障"——故障修完就完了——同一个根因可能触发5个事件但无人连接 有"根源分析"意识但没有系统化的记录和追踪——分析结果变为邮件躺在某人收件箱 事件→问题→根因分析→已知错误→永久修复→知识库——全链路可追踪——重复事件率降
客户界面 客户投诉→老板找IT经理→IT经理找工程师——人肉传话 定期发个"服务月报"——内容是随手写的几行字——无数据支撑 标准服务报告按月出具——含SLA达成率数据+趋势图+事件分析+变更统计——客户知道IT到底在干什么
体系文件 无 有一些流程文件——但"写的和做的不一样"——文件是写出来应付检查然后束之高阁 文件→执行记录→内审→管审→改进——审核员随机抽查"你写的和做的一样吗"——体系是"活的"
ISO 20000的核心不是"写出一套漂亮的流程文件"——而是"你说你做的事——你真的做了——有记录证明——并且你在持续改进"。审核员不要求你的体系完美——但要求你的体系和实践之间没有"两层皮"——书面写了SLA响应时间是15分钟——实际工单记录显示平均响应45分钟——并且你没有对这个差距进行任何分析和改进——这就是严重不符合。
REQUIREMENTS

申请ISO 20000认证的条件

与9001共用的基础条件 + 三项20000独有要求

 
1

SMS范围清晰界定

须书面定义服务管理体系(SMS)的覆盖范围——包括哪些IT服务在体系内、服务对象是谁、服务地点在哪里。范围可以是一个具体的IT服务（如"数据中心托管服务"）或整个IT服务目录——但不能写"全公司所有IT"而不说清楚具体管哪些。

2

服务目录 + SLA正式发布

20000独有——9001/27001没有这个要求。须建立正式的服务目录（每个服务含服务描述/服务时间/响应时间/解决时间/升级路径）并与客户签署SLA或通过合同/服务手册等形式正式发布。服务目录不是"给审核员看的Excel"——它应该真正被一线工程师的工单系统使用来驱动SLA计时。

3

34个过程全部建立+至少运行3个月

不是"你有工单系统就够了"——每一个过程须有成文的过程定义（目的/范围/角色职责/活动步骤/输入输出/KPI）——且有至少3个月的运行记录（事件工单/变更记录/服务报告/问题记录等）。审核员会随机抽查3个月的记录——看趋势和一致性。

4

服务报告连续出具

20000独有——其他ISO标准没有"服务报告"要求。须按月或按约定的频率出具正式服务报告——含SLA达成率/事件统计/变更统计/容量趋势/客户满意度——并且有接收方审阅记录（如客户签收邮件或服务回顾会议纪要）。服务报告是审核员最花时间的文件——他会比对报告中的数据和工单系统的原始记录是否一致。

5

至少一轮完整内审+一次管理评审

同9001——但20000的内审范围覆盖全部34个服务过程——且须审核SLA与运营实际的一致性（"你的SLA响应时间30分钟写在合同里——实际工单记录平均响应42分钟——你为什么不修改SLA或改进响应速度"——这是20000内审独有的审视视角）。

6

IT服务管理工具/平台

虽然没有严格要求——但实践中没有工单系统或ITSM平台就难以低成本证明"过程运行有效"——工单是事件/变更/问题/配置管理过程的核心数据源——审核员会登录你的工单系统抽查原始记录——Excel手工台账只适合极小范围（5人以下IT团队）。

7

人员能力+培训记录

IT服务人员须具备岗位所需能力——尤其是事件管理/变更管理/问题管理的责任人——须有相应的培训记录（ITIL基础认证或内部培训均可）。这不是20000的硬性要求——但审核员会抽样问执行层"你知道你的职责在这个过程里是什么吗"——回答"不知道"=不符合。

8

SMS范围不能太小——也不能太大

范围太小（如"只覆盖服务器巡检服务"）=体系太"骨架"——34个过程中很多没有用武之地——审核员会怀疑体系真实性。范围太宽（"全公司所有IT部门的所有活动"）=体系太"宽"——实际建设工作量极大且部分过程可能形同虚设——审核难度急剧上升。建议从一个核心IT服务（如"应用系统运维"或"桌面支持服务"）作为首次认证范围——后续扩项。

DOCUMENTS

认证申请材料清单

比9001多出一组"服务证据"——因为你要证明的不是质量而是服务管理

 
1

认证申请书（认证机构统一模板）

含企业基本信息、SMS范围描述（精确到服务名称+服务对象+地点）、IT团队人数——范围描述直接影响审核人日

2

营业执照副本

经营范围须覆盖IT服务相关业务——如系统集成/IT运维/软件开发/数据处理等

3

SMS范围文件 + 组织架构图

认证范围内的组织架构图（显示服务管理团队各角色）、认证覆盖的物理位置列表、主要IT服务清单

4

服务管理方针 + 服务管理目标

同9001——但目标必须量化到具体的IT服务指标——如"事件解决SLA达成率≥95%""变更成功率≥98%""系统可用性≥99.9%"——不能是"提升客户满意度"的定性表述

5

服务目录 + SLA文档

20000独有核心文件。每个认证范围内的服务——须有正式的服务描述和SLA承诺——含服务时间/响应时间/解决时间/升级路径/例外条款。SLA可体现在合同或服务手册中——必须有客户确认

6

服务报告（连续至少3个月）

20000独有核心文件。3个月以上的正式服务报告——含SLA达成率数据、事件统计、变更统计、可用性趋势。报告须有客户或内部服务使用方审阅记录——不能是"自己做了自己看"

7

34个服务管理过程文件

每个过程须有成文定义——含过程目的/适用范围/角色和职责/活动步骤/输入输出/关键指标/与相关过程的接口。34个过程不是34个独立文件——可合并为一个服务管理手册或多个过程文件包

8

过程运行记录（工单/变更/事件/问题）

3个月以上的工单系统记录——含事件工单、变更工单、问题记录、资产管理/配置管理记录。审核员会登录系统抽查——不是Excel截图

9

内审记录 + 管理评审报告

内审须覆盖全部服务管理过程（34个）——管理评审须含SLA达成率评审、重大事件回顾、客户满意度趋势、资源需求和改进计划

10

业务关系管理记录 + 供应商管理记录

服务回顾会议纪要/客户满意度调查/供应商SLA绩效评审——证明"你不仅管好了自己，也管好了服务对象和供应商"

服务目录+SLA+服务报告——这三份文件是20000审核的"三件套"——占审核时间40%以上。最高频的失败模式：服务目录中写了SLA但工单系统没有使用SLA自动计时（工单系统与服务目录脱节）、服务报告里的数据与工单系统原始记录对不上、SLA设置了但从未修订（2年前的SLA仍在用但与现实严重不符）——"文件与实际脱节"是20000审核的开具不符合项的首要原因。
PROCESS

ISO 20000认证完整流程

从零到拿到证书的六步路径——4到8个月

 
1

差距分析

界定SMS范围→现状与20000条款差距→制定实施计划
2-4周

2

体系设计

服务目录→SLA→34个过程文件→配置ITSM工具
4-8周

3

体系运行

按过程运行≥3个月→积攒工单+变更+报告→生成服务报告
3+个月

4

内审+管审

覆盖34个过程的首次内审→管理评审→改进不符合项
2-4周

5

一二阶段审核

一阶段看文件+SLA→二阶段深入验证运行记录+工单系统
3-8天

6

整改获证

关闭不符合项→技术委员会评定→颁发证书
1-2个月

20000的周期与9001相当——瓶颈不在体系建立而在"运行积累"。关键区别在第二步：20000的体系设计阶段需要建立的不只是一套"文件架构"（9001的工作）——还需要配置ITSM工具和工单系统与SLA的集成——如果工具不到位——靠Excel手工记录——审核员会质疑体系运行的真实性和可持续性。建议体系设计阶段就把ITSM工具（如Jira Service Management/ServiceNow/ManageEngine/开源ITSM等）配置到位——把SLA自动计时、事件升级路径、变更审批流程嵌入工具——让体系文件"自动化"地运转。
COST & TIMELINE

认证周期与费用结构

与9001同等价位——但多出一项ITSM工具配置的隐性成本

 

📅 时间线概览 4-8个月

  • 差距分析 + SMS范围界定：2-4周（确定认证覆盖的IT服务——首次认证建议选1-2个核心服务——后续扩项）
  • 体系设计（34个过程文件+ITSM工具+服务目录+SLA）：4-8周（最关键阶段——工具配置和过程设计并行——须IT团队和咨询师密切配合）
  • 体系运行：不少于3个月（硬性要求——从SMS文件生效日起算——须在此期间产生足够的工单/变更/事件记录）
  • 内审 + 管理评审：2-4周（须覆盖34个过程——内审中发现的问题须在二阶段审核前关闭）
  • 一阶段+二阶段审核：3-8天（取决于IT团队规模和SMS范围——20-50人团队：一阶段1-2天+二阶段2-4天）
  • 整改+发证：1-2个月

💰 费用结构 3-8万元

  • 咨询费：1-4万元——含差距分析+体系文件编写+服务目录和SLA辅导+内审培训——与20000一对一
  • 认证审核费：1.5-3.5万元——取决于IT团队人数+认证覆盖服务数+物理地点数——小团队(<30人)/单一服务约1.5-2.2万
  • 隐性成本——ITSM工具：0-3万元/年——取决于选择开源还是商业——Jira SM≈免费(10人)/ManageEngine≈免费(5技术员)/ServiceNow≈贵——但工单系统是20000体系的"引擎"——没有工具=手工台账=审核风险
  • 监督审核费：0.5-1.2万元/年（第1和第2年各一次）
  • 再认证费：第3年再认证≈初审费——前提是体系持续有效运行
低价陷阱："5000元全包两个月拿20000证"一定是虚假证书——20000的强制性审核人日比9001更高（因为20000须审核34个过程+SLA+服务报告+工单系统——审核工作量显著超过9001"过程方法"的审核深度）。查证：登录全国认证认可信息公共服务平台(cx.cnca.cn)——查询认证机构——确认其CNAS认可范围含"服务管理体系(SMS)——信息技术服务管理体系"——不是所有认证机构都有20000资格。
TIPS

ISO 20000 认证的8条注意事项

从SLA设置到工单系统配置——每条都是用审核上的不符合换来的

 
⚠
SLA不是"设得越高越好"——是"你真正能做到的水平"。把事件响应SLA设为5分钟——但实际工单记录显示平均37分钟——审核员不会表扬你"志向高远"——而是出不符合："SLA承诺与实际能力不符——且未对差距进行分析和改进"。设SLA的第一步是：先收集至少1个月的历史工单基线数据→在这个数据基础上设置合理的"渐进改善目标"。
⚠
事件和问题必须分开管理——不能"事件单下面写了几行根因分析"就算问题管理。这是20000审核最高频的不符合项——事件管理的目标是"恢复服务"（可以临时方案）——问题管理的目标是"找根因并永久解决"。两者必须有独立的记录、独立的状态流转、独立的关联关系（一个事件可以关联到一个问题——一个问题可以关联多个事件）。
⚠
变更管理中的"紧急变更"不是"免审批"——是"事后补审批"。紧急变更须在实施后不超过1个工作日内完成补审批——且须记录"为什么是紧急"（如"系统已宕机——不立即修影响XX业务——无法等待常规变更窗口"）。审核员会问：你的紧急变更有多少比例——如果超过10-15%——他就会追问"你的变更管理是否失效——为什么总是紧急"。
⚠
配置管理(CMDB)不要试图"管理所有IT资产"——从服务依赖的"关键CI"开始。CMDB是20000体系中最容易被"贪大求全"导致失败的过程——试图把所有PC/交换机/软件/许可证都录入CMDB——最终CMDB半年不更新变成一堆过期数据。正确的做法：只管理核心业务服务的依赖组件（服务器→数据库→中间件→网络——这几十个CIs）——做到100%准确+实时更新——审员看的是准确性而非覆盖面。
⚠
供应商管理——"云平台不是供应商"是最大误区。AWS/Azure/阿里云是你的供应商——它们的SLA直接影响你的SLA——你必须对他们的SLA进行评审（他们的可用性99.95%——你的服务可用性承诺99.9%——这里有0.05%的"责任空白"你必须用自己的冗余架构填上）。审核员会问：你的供应商SLA评审记录在哪里——最坏路径是什么——你有什么应对措施。
⚠
服务报告不是"审核前赶出来的一份PPT"——它必须是"定期出具+递送客户+有反馈"的体系化机制。审核员会看：报告出具日期是否定期（每月/每季固定日期）、报告内容是否与工单系统数据一致、客户是否审阅（签名/邮件回复/会议纪要）、报告发现了什么问题并触发了什么改进。如果报告是审核前一次性编写的——日期断层一眼就能被识破。
⚠
"我们用的是ServiceNow/Jira——所以过程一定合规"=误区。工具有过程模板≠过程在执行——审核员会随机抽查工单系统中的一个真实事件→追溯全过程"事件→问题→变更→配置→知识库"——工具只提供了能力——执行的质量取决于人——"事件关了但关之前没填解决方案"=不符合——工具不会代替审计判断。
⚠
20000+27001双标同审——节约成本30-40%——但两者的审核视角完全不同——不能合并成一张内审检查表。20000审核员关注"服务做得好不好"——27001审核员关注"信息安全管得严不严"。同一份变更记录在20000审核中被审查"审批流程是否完整"——在27001审核中被审查"变更是否涉及安全配置修改——是否触发了安全评估"——两张检查表/两组审计证据——但同一个审计窗口期可以完成。
FAQ

常见问题

8个最高频的咨询问题——从"要不要先学ITIL"到"内部IT部门值得做吗"

 
我们公司已经用了ITIL实践——还需要ISO 20000认证吗？▼
需要——因为"我们用了ITIL"无法向客户证明"我们的IT管理达到国际标准"。ITIL是方法论，没有认证审核——你的客户看不到任何可验证的证书。ISO 20000是以ITIL为蓝本的可认证标准——审核员独立验证你的实践是否达标——证书是全球通用的"服务管理能力证明"。如果你已经具备ITIL实践基础——做20000的差距会比从零开始的公司小50%以上——差的通常是：服务目录的正式化、SLA的可度量化和服务报告的体系化——这三项是ITIL实践者最容易疏忽但20000要求最严格的。
我们只是企业内部IT部门——不做对外服务——需要20000吗？▼
取决于"内部IT部门想如何被公司看待"。如果你满足于"坏了有人修"——那20000对你没有价值。如果你想证明"IT部门不是一个只会花钱的成本中心——而是一个有服务级别承诺、有绩效指标、有持续改进的服务部门"——20000体系框架就是你的最佳管理工具。很多大型企业的IT部门做20000不是为了拿证（有些甚至不在CNCA平台查询）——而是用20000的体系框架向CFO/CEO汇报"这就是IT的工作量和绩效——我们是可度量的"。内部IT的SLA可以是与业务部门签署的内部服务水平协议(OLA)——而不是外部合同。
我们团队只有5个人——ISO 20000会不会过度投入？▼
5人团队做20000确实有挑战——但不是不可以。小团队的优势在于34个过程中的很多角色可以合并（一个人同时做事件管理、问题管理、变更管理——只要在文件中明确了角色合并即可——20000不禁止一人多角色）。挑战在于：事件和问题的"独立分离"——一个人同时做事件处理和问题分析——审核员会挑战"你如何保证问题分析的客观性"。建议的最小操作规模：5-8人IT团队、有工单系统、有一个对外IT服务（如"应用运维"或"桌面支持"）。费用可以控制在3-4万元打包——并且能显著提升团队的专业形象。
我们有ITSM系统——还需要做配置管理(CMDB)吗？▼
ISO 20000要求的是"配置管理过程"——不是"有一个CMDB数据库"。如果你的ITSM系统有资产管理模块——但没有人维护、数据过期、与实际环境不一致——那你只有工具没有"过程"。配置管理的核心是：有明确的配置项(CI)识别范围→有责任人更新→变更发出更新通知→配置库始终保持与真实环境同步。审核员会在你的工单系统中随机选一台服务器→看它的配置记录和真实环境是否一致——不一致=不符合——不管你用的工具多贵。
ISO 20000和ISO 27001可以同时做吗？先做哪个？▼
可以同时做——而且是成本最优的方案。两者共用HLS框架（10个条款编号相同）——体系文件（方针/目标/文件控制/内审/管审等）大量共用——可以做联合审核——总费用比分别做节省30-40%。优先级建议：如果你的主营业务是IT外包/IDC/云服务——20000先行（因为它直接对应你的核心业务——客户最关心你能否管好IT）——然后做27001（补上安全维度）——最后做9001（补上质量维度）。如果你的主营业务是软件开发/SaaS——27001先行——再20000。两种顺序都没问题——只是对客户的说服力先后不同。
我们没有客户合同中有SLA——怎么做20000的SLA管理？▼
SLA不必须有"对方盖章的法律合同"——你可以单方面发布服务承诺。如果你是一个公共云服务商——你的官网"服务等级协议(SLA)"页面就是你的SLA——审核员接受这个形式。如果你是内部IT部门——你可以发布一份"IT服务承诺书"——由IT总监签发——发送给所有业务部门——这就可以作为SLA证据。如果你是IT外包商但客户合同中没有SLA——你仍然可以在服务目录中列明你自己的服务标准——带"参考标准"字样——审核员看到就行。关键是"有承诺且被受众知晓"——不是"有法律效力"。
我们不是IT公司——我们是一个制造企业有IT部门——能做20000吗？▼
能做——但认证范围有限。认证范围可以是"XX公司IT部门对内的IT运维服务"——但这个范围的20000证书在市场上对外说服力有限（因为外部客户无法验证你如何管理内部IT）。实践中——非IT公司做20000一般是内部管理目的——不是为了外部投标。如果你们是与IT运维相关的服务（如SaaS平台——客户用你的平台来做业务）——20000的价值就更大——因为客户的使用体验直接依赖于你的IT服务质量。
拿到20000证书后——SLA不达标怎么办？证书会丢吗？▼
SLA不达标本身不会丢证书——但"不达标后没有分析和改进"会丢证书。20000的体系逻辑是PDCA——它允许你SLA暂时达不到——但要求你发现差距→分析原因→制定改进计划→监控改进效果。监督审核中——审核员会看你上一周期的SLA达成率——不达标的指标是否有趋势分析、改进计划和行动证据。如果你的SLA连续3个月不达标但你没有任何改进动作——这就是不符合。如果你的SLA不达标但你降低了SLA承诺值并重新与客户签署——这也是合理的改进方式——因为SLA的目标是与现实一致。

用ISO 20000让IT部门从"修电脑的"变成"可度量的服务提供者"

从服务目录到SLA运营——全程辅导——让你的IT管理经得起任何客户的审计考验

立即咨询 · 获取方案 ➔
넳 넲
首页  ꄲ  资质  ꄲ  企业认证  ꄲ  ISO20000 IT服务管理体系
ꁱ 免费咨询

在线咨询

您的姓名 *

联系电话 *

需要办理的服务 *

咨询内容 *

在线即时自助沟通 — 企咨宝

企咨宝智能客服

在线 · 平均响应 <30秒
由 企咨宝 提供技术支持 · 京ICP备11031915号