Changes for page ITIL v5:数据质量不是口号,AI时代逼着你重做数据治理
Last modified by superadmin on 2026/02/20, 07:23
Change comment:
There is no comment for this version
Summary
Details
- Page properties
-
- Content
-
... ... @@ -1,73 +1,93 @@ 1 1 === 一、ITIL 第5版已发布,数据治理从“最好有”变成“必须先有” === 2 2 3 + 3 3 2026年1月29日,PeopleCert正式发布了ITIL 第5版。作为ITIL官方中国区产品大使,我将会推出系列文章帮大家解读ITIL 第5版到底有哪些重大的更新。 4 4 5 -[[image:https://my.feishu.cn/space/api/box/stream/download/asynccode/?code=NDAxYmQ0N2MzMWYzMWJiYThiY2Q1YTA0OWQ5ZTA3NmJfYWprZzg4c3dYQWNTdUdhczJqT2dXNE5DOXF2anIxMGpfVG9rZW46SEZDNWJURWV1bzVxTmt4RlN6c2NNMHN3bnNrXzE3NzA3MjYyNTk6MTc3MDcyOTg1OV9WNA||height="214" width="353"]] 6 6 7 -ITIL v5(中文语境下通常称为ITIL 第5版)已经正式发布。很多人把这次升级理解为“框架更大了、覆盖更广了、AI也写进去了”,这些都对,但站在数据与平台负责人的角度,最值得重视的其实是一个更朴素的变化:数据质量不再是“做得好会加分”,而是“做不好会直接让AI与自动化失效”。 7 +(% style="text-align:center" %) 8 +[[image:1.png||height="272" width="448"]] 8 8 9 - 过去几年,很多组织都经历过类似场景:AI试点做了,演示很好看;上线后效果开始漂移,误判越来越多,最后不得不把关键步骤退回人工,把所谓的自动化变成“半自动化”,效率收益被反复纠错消耗掉。问题往往不在算法(algorithm,算法)不够强,也不在算力不够,而在最基础的三件事没过门槛:数据不完整、口径不一致、证据链不可追溯。你把AI塞进这种底座里,得到的不是更聪明的系统,而是更快扩散偏差的系统。10 +ITIL v5(中文语境下通常称为ITIL 第5版)已经正式发布。 很多人把这次升级理解为“框架更大了、覆盖更广了、AI也写进去了”,这些都对,但站在数据与平台负责人的角度,最值得重视的其实是一个更朴素的变化:数据质量不再是“做得好会加分”,而是“做不好会直接让AI与自动化失效”。 10 10 11 -ITIL 第5版把AI治理推到核心语境之后,数据治理的地位自然被抬高。因为一旦AI参与决策链路,组织就必须回答:凭什么相信它、错了怎么纠偏、出了事谁承担问责、如何证明可审计性。这些问题听起来像治理问题,最终都会落回数据问题:没有稳定的数据资产与治理机制,你无法持续获得收益,更无法把风险关进边界里。 12 12 13 +过去几年,很多组织都经历过类似场景:AI试点做了,演示很好看;上线后效果开始漂移,误判越来越多,最后不得不把关键步骤退回人工,把所谓的自动化变成“半自动化”,效率收益被反复纠错消耗掉。 问题往往不在算法(algorithm,算法)不够强,也不在算力不够,而在最基础的三件事没过门槛:数据不完整、口径不一致、证据链不可追溯。 你把AI塞进这种底座里,得到的不是更聪明的系统,而是更快扩散偏差的系统。 13 13 15 + 16 +ITIL 第5版把AI治理推到核心语境之后,数据治理的地位自然被抬高。 因为一旦AI参与决策链路,组织就必须回答:凭什么相信它、错了怎么纠偏、出了事谁承担问责、如何证明可审计性。 这些问题听起来像治理问题,最终都会落回数据问题:没有稳定的数据资产与治理机制,你无法持续获得收益,更无法把风险关进边界里。 17 + 18 + 19 + 14 14 === 二、ITIL 第5版升级内容全景 === 15 15 22 + 16 16 把“数据质量为什么变成硬门槛”讲清楚,必须先把ITIL 第5版的更新内容要点完整交代,因为数据治理不是孤立话题,它与管理对象、生命周期、体验与AI治理强耦合。 17 17 18 -[[image:https://my.feishu.cn/space/api/box/stream/download/asynccode/?code=NzdkMGFlZWI0OTFjNjhmNDVkYzllMGQ2ZjQ4MTRhODRfd2FHUHJkbXhSVk5wcUFqdjJqbG9SNktkNVhmak9qblBfVG9rZW46UnpYMGJ4ZUR1bzU0WGV4dVJ6aGNWZWJHbmJCXzE3NzA3MjYyNTk6MTc3MDcyOTg1OV9WNA||height="715" width="414"]] 19 19 20 20 ==== 1)定位升级:从服务管理走向数字产品与服务管理 ==== 21 21 22 -ITIL 第5版把管理对象扩展为数字产品与数字化服务的整体,强调端到端价值交付。数据不再只是运维侧的日志与告警,也不只是BI报表,而是贯穿产品与服务全生命周期的共同资产:上游用于洞察与设计,中段用于风险控制与转换,下游用于运营、交付与支持闭环。 28 +ITIL 第5版把管理对象扩展为数字产品与数字化服务的整体,强调端到端价值交付。 数据不再只是运维侧的日志与告警,也不只是BI报表,而是贯穿产品与服务全生命周期的共同资产:上游用于洞察与设计,中段用于风险控制与转换,下游用于运营、交付与支持闭环。 23 23 30 + 24 24 ==== 2)生命周期模型升级:八个阶段覆盖从想法到退役 ==== 25 25 26 -ITIL 第5版提出产品与服务生命周期的八个阶段:发现(Discover,发现)、设计(Design,设计)、获取(Acquire,获取)、构建(Build,构建)、转换(Transition,转换)、运营(Operate,运营)、交付(Deliver,交付)、支持(Support,支持)。每一阶段都会产生数据与记录:洞察记录、验收标准、配置、发布说明、变更记录、事件与工单、知识条目、度量与报告。生命周期拉长后,数据质量差带来的后果也会从局部放大到端到端。 33 +ITIL 第5版提出产品与服务生命周期的八个阶段:发现(Discover,发现)、设计(Design,设计)、获取(Acquire,获取)、构建(Build,构建)、转换(Transition,转换)、运营(Operate,运营)、交付(Deliver,交付)、支持(Support,支持)。 每一阶段都会产生数据与记录:洞察记录、验收标准、配置、发布说明、变更记录、事件与工单、知识条目、度量与报告。 生命周期拉长后,数据质量差带来的后果也会从局部放大到端到端。 27 27 35 + 28 28 ==== 3)体验进入核心:体验的好坏需要证据,而证据来自数据 ==== 29 29 30 -ITIL 第5版强调体验进入核心,意味着组织要能度量触点摩擦、旅程质量与客户满意度。体验不可能靠感觉管理,最终一定要落到数据:触点停留、等待、反复确认、返工、升级失败、一次解决率等都需要可靠记录,否则体验就只能停留在口头争论。 38 +ITIL 第5版强调体验进入核心,意味着组织要能度量触点摩擦、旅程质量与客户满意度。 体验不可能靠感觉管理,最终一定要落到数据:触点停留、等待、反复确认、返工、升级失败、一次解决率等都需要可靠记录,否则体验就只能停留在口头争论。 31 31 40 + 32 32 ==== 4)AI进入框架中心:从工具话题走向治理与能力边界 ==== 33 33 34 -ITIL 第5版强调AI带来效率机会,也带来治理挑战。想在可接受风险之内使用AI,必须有数据准确性、完整性、一致性,以及明确的责任、授权与问责机制,还要具备可审计性。没有这些条件,AI输出再“像人”,也只是不可控建议。 43 +ITIL 第5版强调AI带来效率机会,也带来治理挑战。 想在可接受风险之内使用AI,必须有数据准确性、完整性、一致性,以及明确的责任、授权与问责机制,还要具备可审计性。 没有这些条件,AI输出再“像人”,也只是不可控建议。 35 35 45 + 36 36 ==== 5)实践使用方式变化:实践不是清单,而是围绕价值流的组合 ==== 37 37 38 -在ITIL 第5版语境里,实践更像组件库。数据治理要和度量与报告、知识管理、风险管理、信息安全、监控与事态管理、事件管理、变更实施等实践组合,嵌入价值流形成闭环。数据治理不再是“单独一条线”,而是“所有实践的底座”。 48 +在ITIL 第5版语境里,实践更像组件库。 数据治理要和度量与报告、知识管理、风险管理、信息安全、监控与事态管理、事件管理、变更实施等实践组合,嵌入价值流形成闭环。 数据治理不再是“单独一条线”,而是“所有实践的底座”。 39 39 50 + 40 40 这五点决定了本篇的核心判断:ITIL 第5版之所以让数据质量变成硬门槛,不是因为框架偏爱数据,而是因为端到端价值交付、体验度量与AI治理都离不开可用的数据资产。 41 41 53 +(% style="text-align:center" %) 54 +[[image:24aedefb-807d-4428-a4dd-4896fcd694f9.jpg]] 42 42 43 43 === 三、AI时代为什么逼着你重做数据治理:真正的痛点不是“数据少”,而是“数据不可信” === 44 44 45 -数据治理最容易被误解成“建个数据湖、打通接口、上个主数据”。这些当然重要,但在AI与自动化场景里,最致命的问题往往不是数据量不够,而是数据不可信、不稳定、不可追溯。所谓“重做”,不是推倒重来,而是把治理从“工程项目”变成“运行机制”。 46 46 59 +数据治理最容易被误解成“建个数据湖、打通接口、上个主数据”。 这些当然重要,但在AI与自动化场景里,最致命的问题往往不是数据量不够,而是数据不可信、不稳定、不可追溯。 所谓“重做”,不是推倒重来,而是把治理从“工程项目”变成“运行机制”。 60 + 61 + 47 47 从落地经验看,AI时代逼着你重做数据治理,通常来自三股压力同时到来: 48 48 49 49 **• 压力一:决策链路被拉长,错误传播速度更快** 50 50 51 -以前数据错了,可能只影响一张报表;现在数据错了,可能影响分类、分派、优先级、自动触发行动,最后变成事故或投诉。风险传播速度变了,容错空间就小了。 66 +以前数据错了,可能只影响一张报表;现在数据错了,可能影响分类、分派、优先级、自动触发行动,最后变成事故或投诉。 风险传播速度变了,容错空间就小了。 52 52 68 + 53 53 **• 压力二:跨系统协作更频繁,口径不一致会制造系统性摩擦** 54 54 55 -同一个“事件”在A系统叫事件,在B系统叫故障,在C系统叫告警;同一个“服务”在不同团队有不同边界;同一个“优先级”在不同部门有不同含义。口径不一致会直接制造等待与返工,端到端价值流会不断绕路。 71 +同一个“事件”在A系统叫事件,在B系统叫故障,在C系统叫告警;同一个“服务”在不同团队有不同边界;同一个“优先级”在不同部门有不同含义。 口径不一致会直接制造等待与返工,端到端价值流会不断绕路。 56 56 73 + 57 57 **• 压力三:治理要求更现实,问责与可审计性必须落到证据链** 58 58 59 -当AI参与决策,组织必须回答“为什么这样做”“依据是什么”“谁批准的”。如果证据链缺失,问责就会变成吵架,治理就会变成形式,最后只能退回“多审批、多人工”,效率收益被抵消。 76 +当AI参与决策,组织必须回答“为什么这样做”“依据是什么”“谁批准的”。 如果证据链缺失,问责就会变成吵架,治理就会变成形式,最后只能退回“多审批、多人工”,效率收益被抵消。 60 60 61 -这三股压力叠加在一起,会把数据治理从“最好做”变成“必须先做”。你可以不追求一步到位,但不能没有最小闭环。 62 62 79 +这三股压力叠加在一起,会把数据治理从“最好做”变成“必须先做”。 你可以不追求一步到位,但不能没有最小闭环。 63 63 81 + 64 64 === 四、最常见的三类根因:不完整、不一致、不可追溯 === 65 65 66 -把问题说得再大,落地时仍然要回到根因。数据质量之所以成为硬门槛,通常不是因为某个系统崩了,而是因为这三类根因长期存在、却被当成“正常现象”。 67 67 85 +把问题说得再大,落地时仍然要回到根因。 数据质量之所以成为硬门槛,通常不是因为某个系统崩了,而是因为这三类根因长期存在、却被当成“正常现象”。 86 + 87 + 68 68 ==== 1)记录不完整:缺字段、缺链路、缺上下文 ==== 69 69 70 -最常见的情况是:工单有标题没影响范围,变更有描述没回滚,告警有时间没关联服务,事件有结论没证据。看起来都“记录了”,实际上无法支撑决策与复盘。 90 +最常见的情况是:工单有标题没影响范围,变更有描述没回滚,告警有时间没关联服务,事件有结论没证据。 看起来都“记录了”,实际上无法支撑决策与复盘。 71 71 72 72 在AI与自动化场景里,不完整会造成两类后果: 73 73 ... ... @@ -75,11 +75,12 @@ 75 75 76 76 • **失控**:自动化无法验证前置条件与后置结果,触发错误行动 77 77 78 -需要特别警惕的是:不完整不是偶发问题,它往往来自流程与工具的默认设计。你不改机制,它不会自己变好。 98 +需要特别警惕的是:不完整不是偶发问题,它往往来自流程与工具的默认设计。 你不改机制,它不会自己变好。 79 79 100 + 80 80 ==== 2)口径不一致:同名不同义、同义不同名 ==== 81 81 82 -口径不一致最容易制造“指标漂亮但问题不见”的幻觉。不同团队各自优化各自的数字,端到端却没有改善。更严重的是,AI把这些口径混在一起,会把噪声当信号,把例外当规则。 103 +口径不一致最容易制造“指标漂亮但问题不见”的幻觉。 不同团队各自优化各自的数字,端到端却没有改善。 更严重的是,AI把这些口径混在一起,会把噪声当信号,把例外当规则。 83 83 84 84 典型表现包括: 85 85 ... ... @@ -93,9 +93,10 @@ 93 93 94 94 口径不一致不是靠“开会对齐一次”解决的,它需要制度化:统一定义、统一字典、统一校验规则、统一数据契约。 95 95 117 + 96 96 ==== 3)不可追溯:缺版本、缺来源、缺审批链 ==== 97 97 98 -可追溯不仅是合规要求,更是工程与治理的基本能力。不可追溯会让组织陷入一种低效状态:问题发生时只能靠猜,猜不到就加审批,加了审批又更慢,最后变成组织性的内耗。 120 +可追溯不仅是合规要求,更是工程与治理的基本能力。 不可追溯会让组织陷入一种低效状态:问题发生时只能靠猜,猜不到就加审批,加了审批又更慢,最后变成组织性的内耗。 99 99 100 100 不可追溯常见于: 101 101 ... ... @@ -112,13 +112,15 @@ 112 112 113 113 === 五、别急着做大:数据治理的最小闭环应该先解决“能用、可信、可审计” === 114 114 115 -很多平台团队一谈治理就想“一次性做全”。结果往往是项目很大、周期很长、落地很慢,最后被业务节奏打断。更稳的做法,是先建立最小治理闭环,把“能用、可信、可审计”做出来,再扩面。 116 116 138 +很多平台团队一谈治理就想“一次性做全”。 结果往往是项目很大、周期很长、落地很慢,最后被业务节奏打断。 更稳的做法,是先建立最小治理闭环,把“能用、可信、可审计”做出来,再扩面。 139 + 117 117 建议把最小闭环拆成五个抓手,每个抓手都能直接对应到ITIL 第5版的端到端价值与AI治理要求。 118 118 142 + 119 119 ==== 抓手一:先定口径,再谈打通 ==== 120 120 121 -先选一条价值流或一个关键场景,把必要口径统一起来。不要从全域开始,从“高价值、高频、高风险”的对象开始。 145 +先选一条价值流或一个关键场景,把必要口径统一起来。 不要从全域开始,从“高价值、高频、高风险”的对象开始。 122 122 123 123 可优先统一的口径通常包括: 124 124 ... ... @@ -134,9 +134,10 @@ 134 134 135 135 口径先统一,打通才有意义;否则你只是把不一致搬到同一张表里。 136 136 161 + 137 137 ==== 抓手二:定义“必须字段”与校验规则,把不完整堵在入口 ==== 138 138 139 -数据质量不是靠事后清洗,而是靠入口控制。把关键记录的必须字段定义清楚,并用工具做校验。 164 +数据质量不是靠事后清洗,而是靠入口控制。 把关键记录的必须字段定义清楚,并用工具做校验。 140 140 141 141 例如: 142 142 ... ... @@ -148,9 +148,10 @@ 148 148 149 149 把“必须字段”做成默认机制,比事后追责有效得多。 150 150 176 + 151 151 ==== 抓手三:建立证据链与版本机制,确保可追溯与可审计 ==== 152 152 153 -证据链不必一开始就做得很重,但必须存在。至少要能回答:输入是什么、决策是什么、执行了什么、结果怎样。 179 +证据链不必一开始就做得很重,但必须存在。 至少要能回答:输入是什么、决策是什么、执行了什么、结果怎样。 154 154 155 155 建议优先覆盖: 156 156 ... ... @@ -162,9 +162,10 @@ 162 162 163 163 证据链一旦建立,复盘质量会立刻提高,治理也会从“拍脑袋”变成“有证据”。 164 164 191 + 165 165 ==== 抓手四:把责任边界讲清楚:谁维护口径,谁维护数据质量,谁对结果问责 ==== 166 166 167 -数据治理失败的常见原因不是没工具,而是没人负责。责任要分清三层: 194 +数据治理失败的常见原因不是没工具,而是没人负责。 责任要分清三层: 168 168 169 169 • **定义责任**:谁定义口径与字段标准 170 170 ... ... @@ -174,9 +174,10 @@ 174 174 175 175 责任一清,治理才会变成日常经营,而不是临时运动。 176 176 204 + 177 177 ==== 抓手五:用最小度量集驱动持续改进,让治理能“自己变好” ==== 178 178 179 -没有度量,治理就只能靠感觉推进。建议用最小度量集把治理变成可管理对象: 207 +没有度量,治理就只能靠感觉推进。 建议用最小度量集把治理变成可管理对象: 180 180 181 181 • **完整性指标**:关键记录必须字段的缺失率 182 182 ... ... @@ -188,14 +188,14 @@ 188 188 189 189 • **影响指标**:端到端周期时间、等待占比、返工次数变化 190 190 191 -度量不是为了报表好看,而是为了持续改进。你能量化,才能迭代。 219 +度量不是为了报表好看,而是为了持续改进。 你能量化,才能迭代。 192 192 193 193 194 194 === 六、把治理嵌入价值流:三类场景优先做,收益最稳 === 195 195 224 + 196 196 如果要在有限资源下优先选择治理切口,更建议从“能直接提升端到端价值交付与体验,并且能支撑AI治理”的场景入手。 197 197 198 -[[image:https://my.feishu.cn/space/api/box/stream/download/asynccode/?code=YTc2ZGRmY2U4YzY1MDBkOGM4N2IzOGFmYWU5ZDQxNzJfSW5tcm9pQ2hnRVA5M3IxeHAwQm5YMzdxeGlYZ0FNdTdfVG9rZW46WUp2V2JNWHllb2lqdXN4V2NpcmM4NUNlbjJlXzE3NzA3MjYyNTk6MTc3MDcyOTg1OV9WNA||height="268" width="469"]] 199 199 200 200 **场景一:支持与运营数据** 201 201 ... ... @@ -203,6 +203,7 @@ 203 203 204 204 • 直接影响一次解决率、升级效率与满意度 205 205 234 + 206 206 **场景二:转换阶段数据** 207 207 208 208 • 变更、发布、风险评估、回滚与批准链 ... ... @@ -209,6 +209,7 @@ 209 209 210 210 • 直接影响风险曲线与可审计性 211 211 241 + 212 212 **场景三:体验与度量数据** 213 213 214 214 • 端到端周期时间、等待占比、旅程摩擦点 ... ... @@ -220,23 +220,27 @@ 220 220 221 221 === 七、最容易踩的三种坑:一旦出现,就要果断纠偏 === 222 222 223 -数据治理一旦走偏,成本会越来越高。以下三种坑最常见,也最致命。 224 224 254 +数据治理一旦走偏,成本会越来越高。 以下三种坑最常见,也最致命。 255 + 225 225 **• 坑一:只做“打通”,不做“口径与入口控制”** 226 226 227 -打通之后问题更大,因为你把不一致规模化了。纠偏的关键是先统一定义与校验规则。 258 +打通之后问题更大,因为你把不一致规模化了。 纠偏的关键是先统一定义与校验规则。 228 228 260 + 229 229 **• 坑二:把治理当项目,不把责任与节奏固化到BAU** 230 230 231 -项目结束就回到老样子。纠偏的关键是把责任、度量与复盘节奏固化为日常经营。 263 +项目结束就回到老样子。 纠偏的关键是把责任、度量与复盘节奏固化为日常经营。 232 232 265 + 233 233 **• 坑三:急着上AI,把数据质量当后续再补** 234 234 235 -AI效果漂移、误判增多,最后退回人工。纠偏的关键是先建最小闭环:必须字段、证据链、问责机制、可审计性。 268 +AI效果漂移、误判增多,最后退回人工。 纠偏的关键是先建最小闭环:必须字段、证据链、问责机制、可审计性。 236 236 237 -这些坑背后共同点是:忽略了“治理是运行机制”。ITIL 第5版强调的正是这种机制化能力,而不是一次性工程。 270 +这些坑背后共同点是:忽略了“治理是运行机制”。 ITIL 第5版强调的正是这种机制化能力,而不是一次性工程。 238 238 239 239 240 240 我个人的体会:ITIL v5之所以把数据质量推成硬门槛,是因为ITIL 第5版把端到端数字产品与服务管理、体验度量与AI治理放进同一条主轴:没有完整、一致、可追溯的数据资产与证据链,AI与自动化就无法在可接受风险之内稳定释放收益;与其追求一次性做大,不如先用口径统一、入口校验、证据链可审计、责任边界清晰和最小度量集建立治理闭环,让数据治理成为可持续的日常经营能力。 241 241 242 -我是AI+ITIL教练长河achotsao,欢迎+V:achotsao交流,即可第一时间获得ITIL 第5版最新动态及官方特邀中国区大使的深度解析,全网同名。V:a 275 + 276 +欢迎加长河老师微信achotsao,深入交流ITIL 第5版最新资讯。