一、ISO/IEC 20000-1:2018 4.3 标准原文
条款要求：组织应确定服务管理体系的边界和适用性，在确定范围时应考虑4.1中的内外部因素、4.2中的相关方要求，以及由组织或其他方实施的服务及其组成部分。范围应以成文信息予以保持并可供获取。
二、标准条款解读说明
2.1 范围界定的核心维度
| 维度 | 需要回答的问题 | 常见审核关注点 |
|---|---|---|
| 组织边界 | 哪些部门、团队、子公司纳入体系 | 职能是否覆盖服务交付关键环节 |
| 服务边界 | 纳入哪些服务、哪些服务不纳入 | 服务目录与认证范围是否一致 |
| 地点边界 | 哪些站点、机房、服务台、远程团队纳入 | 多地点活动如何统一管理 |
| 供方边界 | 哪些活动由外部供方执行，组织如何控制 | 不能把关键责任完全甩给供应商 |
2.2 核心理解
ISO 20000 的范围界定比很多管理体系更敏感，因为服务往往不是在单一地点、单一部门内完成。一个看似简单的桌面支持服务，背后可能涉及总部服务台、区域现场工程师、云厂商、网络运营商和外包座席。如果范围写得过宽，组织无法证明控制能力；写得过窄，又会把关键过程排除在外，导致体系失真。
因此，4.3 的关键不是“写得漂亮”，而是让声明的范围与实际交付模式一致。凡是会直接影响服务质量、服务连续性、客户体验和合规结果的活动，即使由外部供方实施，也必须在范围描述中说明管理方式和接口关系。
2.3 一份合格范围声明至少要回答的五个问题
第一，组织到底为谁提供服务，是外部客户、内部业务部门，还是两者兼有；第二，提供的是什么类型的服务，是基础设施运维、应用支持、服务台，还是托管和云服务；第三，哪些组织单元、地点和团队纳入统一治理；第四，哪些关键活动由第三方承担，组织如何实施控制；第五，哪些活动暂未纳入，以及不纳入的合理原因是什么。能把这五个问题说清楚，范围基本就不会失真。
在实际审核中，范围最容易出问题的地方不是文字表述，而是“声明范围”和“证据范围”不一致。比如范围写了全国统一服务台，但只有总部有统一工单系统；范围写了托管运维服务，但夜间支持完全依赖未纳入治理的外包团队。这样的范围看起来大，实际上会给审核和后期运行带来持续风险。
三、实施要点
3.1 从服务目录反推范围
- 先列出拟纳入认证和管理的服务清单，再识别对应组织、地点、技术平台和支撑流程。
- 对不纳入范围的服务说明原因，例如尚处于建设期、由独立法人完全管理、尚未纳入统一治理。
3.2 处理多地点和远程交付
- 明确主服务台、二线支持、现场支持、灾备地点、远程运维中心之间的关系。
- 保证各地点在方针、流程、工单、监控、升级和报告方面采用一致规则。
3.3 处理供应商和云服务依赖
- 列出关键外部方承担的活动，如机房托管、网络专线、云主机、外包服务台。
- 说明组织如何通过合同、考核、报告、接口会议和审计维持控制。
3.4 让范围描述可审核
- 范围表述要与营业执照主体、组织结构、服务目录、网站宣传和合同承诺保持一致。
- 若使用“提供给某类客户的某类服务”表述，应能拿出对应样本客户和服务场景证明。
3.5 多地点、多主体场景下的范围处理原则
- 若集团内部多个法人共同参与服务交付，应先明确哪个主体对体系承担管理责任，哪些活动属于受控外部提供。
- 若不同地点成熟度差异较大，可分阶段纳入范围，优先纳入已经统一工具、统一规则、统一指标的区域。
- 对共享资源如统一监控平台、统一服务台、统一供应商合同，要在范围说明中写清其对纳入范围服务的支撑关系。
- 范围一旦调整，应同步更新服务目录、方针目标、审核计划和对外宣传口径，避免后续材料互相矛盾。
四、常用工具与实施方法
| 方法 | 适用场景 | 输出 |
|---|---|---|
| 范围界定工作坊 | 多部门共同确认边界 | 范围草案、纳入/排除说明 |
| 服务目录映射 | 按服务识别支撑团队和地点 | 服务到组织边界矩阵 |
| RACI职责图 | 理清内外部责任分配 | 责任界面表 |
| 供方依赖清单 | 外包和云服务较多的场景 | 关键供方控制点 |
| 范围声明模板 | 形成统一书面表达 | 正式范围声明文本 |
五、典型案例
案例一：多地服务台认证
某全国连锁企业希望将总部和三地共享服务台纳入ISO 20000认证。最初范围只写“集团IT支持服务”，审核前发现不同城市使用不同工单平台和升级规则。组织重新梳理范围后，只纳入已实现统一工具和统一流程的两地团队，同时列明远程支持和现场支持边界，范围描述与实际能力相符，审核更顺利。
案例二：云服务重度依赖场景
某SaaS公司核心服务跑在公有云上，数据库备份由第三方工具完成。组织没有回避这些外部依赖，而是在范围声明中说明“面向客户的SaaS应用运维与支持服务”，并补充供方控制机制、接口责任和例行评审安排，最终证明了对外部活动的治理能力。
案例三：多地交付但分阶段纳入
某全国性运维企业原计划一次性把五个区域中心全部纳入ISO 20000范围，但盘点后发现其中两个区域仍在使用本地工单系统，升级路径和供应商接口也未统一。组织最终选择先纳入三个成熟区域，并在范围说明中清楚标明尚未纳入的区域和原因。这样的做法虽然看起来保守，但保证了认证范围与实际管理能力一致，后续再扩展范围时也更稳妥。
还有一个常见误区，是把范围声明写成营销口号，希望范围看起来更大、更全面。对体系而言，这种写法风险很高，因为范围越宽，组织需要证明的能力边界就越大。真正稳妥的做法，是先让范围与治理能力完全一致，再在后续成熟后逐步扩展。范围写得真实，往往比范围写得宏大更有发表和认证价值。
从管理延展看，范围条款还有一个隐藏价值，就是帮助组织建立“边界意识”。很多服务问题之所以久拖不决，并不是没人做事，而是谁都默认“这应该不归我管”。当范围被定义清楚之后，服务目录、接口责任、供应商边界和客户承诺都会更容易统一，体系中的很多争议也会自然减少。
六、成文信息管理要求
- 形成正式的《服务管理体系范围声明》，包括组织、服务、地点、技术边界和外部依赖。
- 保留范围确定依据，如服务目录、组织架构图、客户合同样本、供方接口说明。
- 当服务新增、组织整合、地点迁移或外包模式变化时，应同步评审和更新范围。
七、常见误区及踩坑提醒
| 误区 | 表现 | 正确做法 |
|---|---|---|
| 范围写得过大 | 把未成熟、未统一治理的服务全部写入 | 优先纳入已经具备管理基础和证据的服务 |
| 范围写得过窄 | 故意排除关键支撑过程和关键地点 | 凡直接影响服务结果的关键活动都要说明管理关系 |
| 忽略外包活动 | 声明中不提供应商，实际交付却高度依赖外部 | 在范围中清晰说明外部方及组织控制方式 |
| 范围与宣传不一致 | 证书范围和官网、合同介绍差异明显 | 统一对内对外表述，避免过度营销 |