Last modified by superadmin on 2026/02/20, 07:23
From version < 5.1 >
edited by superadmin
on 2026/02/20, 15:23
To version < 4.1 >
edited by superadmin
on 2026/02/11, 08:36
< >
Change comment: There is no comment for this version

Summary

Details

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