ISO20000认证中，产品范围“悄悄变了”？别慌，内部评估得有章法

你是不是也遇到过这种情况：刚把服务范围梳理清楚，准备提交ISO20000认证材料，结果业务部门突然上线了个新运维平台，或把某块外包系统收归自管——产品范围“咔”一下就变了？这时候别急着改文件、补记录，更别硬着头皮往上冲。真正的关键，是启动一套看得见、走得通、留得住痕的内部评估流程。

为什么范围一动，认证就“卡壳”？

ISO20000不是静态快照，而是对IT服务管理体系持续有效性的动态验证。一旦产品/服务范围调整（比如新增云监控服务、下线旧OA运维支持），原认证覆盖边界就可能失效——轻则现场审核时被开不符合项，重则影响证书有效性。很多企业栽在这儿，不是没做变更，而是没走评估，就直接改了范围。

内部评估，不是走形式，而是“三问定乾坤”

在九蚂蚁陪跑过的几十家获证企业里，真正稳的企业都有一套默契动作：
✅ 一问“影响面”：这个变化牵动哪些SLA、配置项、事件流程？是否涉及新角色权限或供应商协作？
✅ 二问“证据链”：变更是否有服务请求单、变更评审纪要、CMDB更新截图？有没有同步更新服务目录和SOP？
✅ 三问“落地度”：一线工程师真按新范围执行了吗？上个月的事件报告里，相关服务是否已纳入统计？

这三步做完，不是为了填表，而是让每一次范围调整，都成为体系“长肌肉”的机会。

别等审核老师来问，先让内审员“提前踩点”

我们建议客户每季度做一次轻量级范围健康扫描——不用大阵仗，拉上IT服务经理、配置管理员、内审接口人，用一张A4纸清单过一遍：当前实际交付的服务，和认证范围声明、服务目录、CMDB里的记录，是否“三合一”？发现偏差？当场标红、定责任人、设闭环节点。小问题不积压，大调整才有底气报备认证机构。

说到底，产品范围会变，但管理逻辑不能乱。在九蚂蚁，我们帮客户把这套评估动作“揉进日常”，而不是堆在审核前一周突击补救。毕竟，靠谱的ISO20000，从来不是纸上谈兵，而是每次业务呼吸之间，体系都跟得上节奏。