Version 1.1 by superadmin on 2026/02/10, 20:06
Hide last authors
superadmin 1.1 1 2026年1月29日，PeopleCert正式发布了ITIL 第5版。作为ITIL官方中国区产品大使，我将会推出系列文章帮大家解读ITIL 第5版到底有哪些重大的更新。
2
3 [[image:https://my.feishu.cn/space/api/box/stream/download/asynccode/?code=YzEzMjFmMjU4ODZmNmI1MDc0Mzc1N2RmMTViNzJiNWJfRWpFQVZXb0VPZ0MzN3NNZ2dQdXJvRWFmV1F0OXJHS0FfVG9rZW46REppMWJCcU9Mb2pRNHl4WVFna2MyTFk5blFkXzE3NzA3MjUxMjQ6MTc3MDcyODcyNF9WNA||height="258" width="425"]]
4
5 ITIL v5（中文语境下通常称为ITIL 第5版）已经正式发布。对很多组织来说，真正的困惑不是“要不要上AI”，而是“上什么AI、先上哪里、怎么上才不翻车”。热度永远不缺，工具也永远不缺，缺的是一种能把AI从概念拉回到管理能力的框架：让组织在做决策之前，先看清用例的价值边界、风险边界与数据门槛。
6
7 这正是6C AI能力模型的意义。很多人第一次接触这类模型，习惯把它当成考试要点去记：六个C分别是什么、每个C的定义是什么。背下来当然没坏处，但真正有价值的用法，是把它当成“体检表”，在立项前把AI用例过一遍，避免两种典型悲剧：要么做了半天发现价值不大；要么做得很快却把风险放大，最后不得不回到人工兜底，效率收益被抵消。
8
9 ITIL 第5版把AI治理放进核心语境之后，6C更像是一张能力地图：它告诉你，AI不是单点工具，而是一组能力组合;你不是在买一个模型，而是在建设一套可持续、可审计、可问责的组织能力。把6C用对了，体检一次，就能少走几个月弯路。
10
11
12 === 一、ITIL 第5版升级内容全景 ===
13
14 在进入6C体检方法之前，先把ITIL 第5版的更新内容概述完整交代，因为6C并不是孤立的，它必须嵌在ITIL 第5版的整体结构里才能发挥作用。
15
16 ==== 1）定位升级：从服务管理走向数字产品与服务管理 ====
17
18 ITIL 第5版把管理对象扩展为数字产品与服务的整体，强调端到端价值交付。这意味着AI用例不应被局限在服务台或运维工具层，而要放进端到端价值流中评估：它到底改善了哪段旅程、哪类结果、哪种体验。
19
20 ==== 2）生命周期模型升级：八个阶段覆盖从想法到退役 ====
21
22 ITIL 第5版提出产品与服务生命周期的八个阶段：发现、设计、获取、构建、转换、运营、交付、支持。AI用例可能出现在任何阶段，体检也必须能回答：它落在哪个阶段，如何与上下游协作，风险在哪些阶段被放大或被控制。
23
24 ==== 3）体验进入核心：价值不只看效率，更看旅程摩擦与结果 ====
25
26 AI让流程更快不一定让体验更好。ITIL 第5版强调体验进入核心，意味着体检必须问：AI减少了哪些摩擦、是否引入新的摩擦、客户满意度是否会被真实改善。
27
28 ==== 4）AI进入框架中心：从工具话题走向治理与能力边界 ====
29
30 ITIL 第5版强调AI带来的不仅是效率机会，也是治理挑战。数据质量、责任边界、授权与问责、可审计性是硬底座。体检必须明确：这个用例需要什么数据门槛、谁承担问责、如何确保可审计性。
31
32 ==== 5）实践使用方式变化：从清单背诵走向情境化组合 ====
33
34 AI落地往往需要多实践组合：事件管理、请求履行、知识管理、度量与报告、风险管理、信息安全等要被按环境拼装。体检要能提示：哪些实践能力不足会成为瓶颈。
35
36 有了这张全景图，6C体检就不再是“AI团队自己的事”，而会变成数字产品与服务管理体系的一部分：从价值、到数据、到治理、到持续改进，形成闭环。
37
38
39 === 二、6C AI能力模型的正确打开方式：它不是分类表，而是“立项前的风险与收益扫描仪” ===
40
41 做AI用例体检，目标不是把用例打分打到漂亮，而是快速识别三件事：
42
43 • 这件事值不值得做
44
45 • 它改善的是端到端价值，还是只优化了局部指标
46
47 • 它带来的收益是否可度量、可持续
48
49 • 这件事能不能做稳
50
51 • 数据门槛是否满足准确性、完整性与一致性
52
53 • 风险边界是否清晰，是否具备可审计性与问责机制
54
55 • 这件事该怎么排顺序做
56
57 • 先做哪一个C，后做哪一个C
58
59 • 哪些能力不足会让用例“看起来能做、实际上做不稳”
60
61 把这三件事扫清，才是6C体检的价值。接下来进入方法本身：如何体检、体检什么、如何下结论。
62
63 [[image:https://my.feishu.cn/space/api/box/stream/download/asynccode/?code=ODA5NTU3ZDhlNzM2MjBlZjQ4ZWMwYWU1MWJiZGMwNDBfejgxZFB2M2JSWVR5eFduSE9NU28zcGRPcVFwaXpmNDhfVG9rZW46TERLMGJVTGJpb1JFOEt4SVZYSmN5MGplbmxlXzE3NzA3MjUxMjQ6MTc3MDcyODcyNF9WNA||height="358" width="365"]]
64
65 === ===
66
67 === 三、AI用例体检的标准流程：四步走，把热情变成可控决策 ===
68
69 不论你要做的是智能服务台、自动分派、告警聚合、知识生成，还是风险评估与变更建议，都建议按四步体检流程推进。它比“先PoC再说”更省成本，也更符合ITIL 第5版强调的治理与可持续性。
70
71 ==== 第一步：定义用例的端到端结果与边界 ====
72
73 很多AI用例失败不是技术问题，而是边界问题：目标不清、范围膨胀、期望失控。体检的第一步要把用例钉在端到端价值上。
74
75 建议明确三条边界：
76
77 **业务结果边界**
78
79 • 目标是缩短端到端周期时间，还是减少等待，还是提升满意度
80
81 **触点边界**
82
83 • AI介入哪些触点，改变谁的体验，影响哪些决策点
84
85 **执行边界**
86
87 • AI是只给建议，还是自动执行动作
88
89 • 哪些动作必须由授权人批准
90
91 边界不清，后面所有C都无从谈起。
92
93 ==== 第二步：用6C逐项扫描，找出收益来源与风险缺口 ====
94
95 这一步是核心。不要急着求全，先求“看见缺口”。6C的具体命名在不同材料中可能存在表述差异，但体检时更重要的是每个C对应的能力维度与检查问题。以下给出一套可直接落地的体检问法，把6C变成可用工具。
96
97 ==== 第三步：给出体检结论与优先级顺序 ====
98
99 体检不是写报告，而是为了决策。结论建议分成三类：
100
101 **立即可做**
102
103 • 数据质量过门槛，治理边界清晰，收益可度量
104
105 **需要先补能力再做**
106
107 • 用例方向对，但存在关键能力缺口（例如数据记录不一致、问责不清）
108
109 **暂缓或收缩范围**
110
111 • 收益不大、风险很高、或边界难以治理
112
113 ==== 第四步：把体检结果嵌入价值流与持续改进节奏 ====
114
115 AI用例不是一次性上线，而是持续演进。体检结论要落到：
116
117 • 价值流的哪个环节试点
118
119 • 用什么最小度量集验证收益
120
121 • 用什么复盘节奏识别偏差并持续改进
122
123 这一步做不到，AI用例就很容易变成“上线即巅峰”，后续被噪声与风险拖垮。
124
125
126 === 四、6C体检清单：每个C问这几件事，就能快速识别缺口 ===
127
128 下面进入最关键的部分：把6C变成体检清单。为了可操作，这里用“每个C三到五个问题”的方式呈现，读者可以直接把自己的用例逐条过一遍。
129
130 ==== C1：Creation（生成）——AI产出的内容与建议到底用来干什么 ====
131
132 这一类能力关心“AI产出什么、产出是否可用”。体检要问：
133
134 **产出类型是什么**
135
136 • 是文本（例如工单回复、知识条目），还是结构化结论（例如分类、优先级），还是行动建议（例如排障步骤）
137
138 **产出使用场景是什么**
139
140 • 面向内部员工，还是面向外部客户
141
142 • 产出一旦错误，会带来什么后果
143
144 **产出验收标准是什么**
145
146 • 什么叫正确、可用、合规
147
148 • 如何验证，谁负责验证
149
150 • 是否存在“看起来很好、实际上不可用”的风险
151
152 • 例如语气自然但事实错误
153
154 • 例如回答完整但不符合组织政策
155
156 如果这一关说不清，后面就别谈自动化，因为你连“产出是否合格”都无法判断。
157
158 ==== C2：Curation（筛选与治理）——知识与数据是否干净，是否可追溯 ====
159
160 这一类能力关心“输入与知识资产是否可靠”。体检要问：•
161
162 **输入与知识从哪里来**
163
164 * (((
165 数据与知识来源是什么
166 )))
167 * (((
168 来自工单、变更记录、监控告警、知识库，还是外部文档
169 )))
170 * (((
171 是否区分人工沉淀、系统记录、外部引入、AI 生成内容
172 )))
173
174 **输入是否满足质量门槛**
175
176 * (((
177 数据质量是否达标
178 )))
179 * (((
180 准确性、完整性、一致性是否满足要求
181 )))
182 * (((
183 关键字段是否缺失
184 )))
185 * (((
186 指标口径、术语定义是否统一
187 )))
188
189 **输入是否可追溯、可审计**
190
191 * (((
192 是否可以追溯到具体来源
193 )))
194 * (((
195 是否有版本信息与更新时间
196 )))
197 * (((
198 是否支持审计与事后核查
199 )))
200
201 **输出是否“有据可查”**
202
203 * (((
204 能否证明某次输出基于哪些数据或知识
205 )))
206 * (((
207 是否能回答“你凭什么这么说”
208 )))
209
210 **知识是否存在污染风险**
211
212 * (((
213 是否混入未经验证或低可信内容
214 )))
215 * (((
216 AI 生成内容是否会回流到知识库
217 )))
218 * (((
219 回流前是否有审核机制与明确责任人
220 )))
221
222 **错误输入的风险评估**
223
224 * (((
225 如果输入本身是错的，AI 是否会放大错误
226 )))
227 * (((
228 是否存在“越用越脏”的风险
229 )))
230
231 这是AI用例最常见的“隐形瓶颈”。很多团队一上来就做Creation，结果被Curation卡死：数据不干净，输出自然不稳。
232
233 ==== C3：Communication（沟通）——AI如何与人协作，如何避免误导与信任损耗 ====
234
235 这一类能力关心“AI输出如何被理解与使用”。体检要问：
236
237 **输出是否足够透明**
238
239 * (((
240 AI 的关键假设是否明确说明
241 )))
242 * (((
243 使用了哪些前提条件或默认判断
244 )))
245 * (((
246 是否清楚区分事实、推断与建议
247 )))
248
249 **不确定性是否被显式表达**
250
251 * (((
252 是否提示置信度、适用范围或不确定性
253 )))
254 * (((
255 是否说明哪些地方可能是猜测、近似或补全
256 )))
257
258 **人机协作关系是否清晰**
259
260 * (((
261 人在这个环节中扮演什么角色
262
263 *
264
265 审核者、执行者，还是最终决策者
266 )))
267 * (((
268 哪些情况下必须人工介入
269 )))
270 * (((
271 哪些输出只能作为参考而不能直接执行
272 )))
273
274 **对用户体验的真实影响**
275
276 * (((
277 输出更快是否真的带来更好的体验
278 )))
279 * (((
280 是否引入新的摩擦
281
282 *
283
284 反复确认
285
286 *
287
288 表达含糊、解释成本上升
289 )))
290 * (((
291 用户是否更容易理解和行动
292 )))
293
294 **误导与权威错觉风险**
295
296 * (((
297 错误输出是否容易被当成“权威结论”
298 )))
299 * (((
300 是否存在“说得很像专家但其实是错的”风险
301 )))
302 * (((
303 是否通过措辞、展示方式降低误导性
304 )))
305
306 **纠错与升级机制是否存在**
307
308 * (((
309 用户是否有明确的纠错入口
310 )))
311 * (((
312 是否支持升级到人工处理
313 )))
314 * (((
315 错误被发现后是否能被修正、反馈、闭环
316 )))
317
318 很多AI用例的失败不是因为“答错”，而是因为“让人误以为答对”。信任损耗一旦发生，恢复成本很高。
319
320 ==== C4：Coordination（协同与编排）——AI如何触发行动，如何把工作编排起来 ====
321
322 这一类能力关心“从建议到行动”的链路是否可控。体检要问：
323
324 **AI 输出会触发哪些动作**
325
326 * (((
327 自动分派、自动升级、自动通知、自动补救等
328 )))
329 * (((
330 是建议型输出，还是直接触发执行
331 )))
332
333 **自动执行的触发条件**
334
335 * (((
336 触发条件与安全阈值是什么
337 )))
338 * (((
339 哪些条件满足才能自动执行
340 )))
341 * (((
342 是否区分高风险 / 低风险动作
343 )))
344
345 **异常与失控时的处理机制**
346
347 * (((
348 触发异常时如何停止与降级
349 )))
350 * (((
351 是否支持人工中断
352 )))
353 * (((
354 是否有兜底路径
355 )))
356
357 **与现有工作流的对齐程度**
358
359 * (((
360 与现有工作流如何对齐
361 )))
362 * (((
363 是否会制造新的交接与等待
364 )))
365 * (((
366 是否引入隐形瓶颈
367 )))
368
369 **与现有工具链的兼容性**
370
371 * (((
372 是否与现有工具链冲突
373 )))
374 * (((
375 是否绕过原有控制点
376 )))
377
378 **问责与授权机制**
379
380 * (((
381 自动执行动作的授权人是谁
382 )))
383 * (((
384 授权是一次性的，还是持续有效的
385 )))
386 * (((
387 出错时责任链路是否清晰
388 )))
389
390 Coordination做不好，AI就只能停留在“聊天机器人”层，无法形成真正的效率闭环；但Coordination做得太快，又会把风险放大，所以治理边界必须同时到位。
391
392 ==== C5：Control（控制与治理）——风险边界、授权、问责、可审计性是否完整 ====
393
394 这一类能力关心“在可控范围内获得收益”。体检要问：
395
396 **风险边界是否明确**
397
398 * (((
399 哪些决策可自动化
400 )))
401 * (((
402 哪些必须人工批准
403 )))
404
405 **授权与权限控制**
406
407 * (((
408 授权机制是否清楚
409 )))
410 * (((
411 谁是授权人
412 )))
413 * (((
414 授权条件是什么
415 )))
416
417 **问责机制是否可执行**
418
419 * (((
420 谁承担问责
421 )))
422 * (((
423 如何追溯到决策链路
424 )))
425 * (((
426 是否存在“无人负责区”
427 )))
428
429 **可审计性是否满足要求**
430
431 * (((
432 输入、决策、执行证据是否完整
433 )))
434 * (((
435 是否支持事后审计与复盘
436 )))
437
438 **违规与异常处理机制**
439
440 * (((
441 违规与异常如何处理
442 )))
443 * (((
444 触发器是否明确
445 )))
446 * (((
447 升级路径是否清晰
448 )))
449 * (((
450 是否具备纠偏机制
451 )))
452
453 Control是“必修课”的核心。没有Control，前面四个C做得越好，风险放大得越快。
454
455 ==== C6：持续改进（持续改进）——上线之后如何变得更好，而不是更乱 ====
456
457 这一类能力关心“长期可持续”。体检要问：
458
459 **度量体系是什么**
460
461 * (((
462 端到端周期时间、等待占比、返工次数、满意度是否纳入
463 )))
464 * (((
465 指标口径是否明确、能否长期稳定采集
466 )))
467
468 **误差与偏差如何被捕捉**
469
470 * (((
471 误差与偏差如何被捕捉
472 )))
473 * (((
474 是靠抽检、反馈、对照实验，还是自动监测
475 )))
476
477 **哪些场景最容易出错**
478
479 * (((
480 哪些场景最容易出错
481 )))
482 * (((
483 是否识别高风险/高复杂度场景并单独监控
484 )))
485
486 **错误类型如何分类与统计**
487
488 * (((
489 错误类型如何分类与统计
490 )))
491 * (((
492 是否能区分“事实错误、策略不符、流程不匹配、体验误导”等类别
493 )))
494
495 **复盘节奏是什么**
496
497 * (((
498 复盘频率
499 )))
500 * (((
501 参与角色
502 )))
503 * (((
504 输出物是什么（结论、行动项、变更清单等）
505 )))
506
507 **迭代策略如何制定**
508
509 * (((
510 迭代策略如何制定
511 )))
512 * (((
513 先修数据还是先调策略
514 )))
515 * (((
516 先收缩边界还是先增加控制点
517 )))
518
519 持续改进缺失时，AI用例常见路径是：上线初期看起来很强，三个月后被噪声与例外打垮，最后回到人工兜底，组织对AI产生疲劳与不信任。
520
521
522 === 五、体检结论怎么写才有用：给出“能做、怎么做、先做什么” ===
523
524 体检结果要能直接驱动行动。建议把结论写成三层：
525
526 **能做什么**
527
528 • 哪些场景适合先做，哪些要暂缓
529
530 **怎么做**
531
532 • 先在哪条价值流试点，AI角色是建议还是执行
533
534 • 关键控制点与授权机制如何配置
535
536 **先做什么**
537
538 • 六个C里最短板的是哪一个
539
540 • 先补数据治理与证据链，还是先补编排与自动化闭环
541
542 为了更易落地，可以把行动项按优先级写成：
543
544 **• 第一优先：补Curation与Control**
545
546 • 先把数据门槛、证据链、授权与问责补齐
547
548 **• 第二优先：补Coordination**
549
550 • 在可控边界内做自动化编排，形成闭环
551
552 **• 第三优先：优化Communication与持续改进**
553
554 • 降低误导风险，建立复盘节奏，让用例长期变好
555
556 这个顺序不是绝对，但在多数ITSM与平台场景里非常实用：数据与治理是地基，编排是骨架，沟通与改进是肌肉与神经。
557
558
559 === 六、常见误判与纠偏：为什么很多AI用例“看起来能做，最后做不稳” ===
560
561 用6C体检，最值钱的往往是提前识别误判。以下三类误判最常见：
562
563 **• 误判一：把Creation当全部**
564
565 只盯生成效果，不看数据质量与治理边界。纠偏方式是先补Curation与Control，把证据链与问责机制落地。
566
567 **• 误判二：把自动化闭环当作越快越好**
568
569 Coordination推进过快，触发条件与异常降级不清晰，导致误作扩大影响。纠偏方式是明确执行边界：先建议、后执行；先低风险、后高风险。
570
571 **• 误判三：把上线当终点**
572
573 没有持续改进节奏，偏差积累成噪声，最终回到人工兜底。纠偏方式是把度量与复盘固化为BAU，让用例持续演进。
574
575 这些误判背后其实只有一句话：AI用例不是模型问题，而是管理能力问题。6C体检的价值，就是把管理能力的缺口提前照出来。
576
577
578 ITIL v5时代用6C AI能力模型做“AI用例体检”的正确姿势，是把它当成一张能力地图而不是背诵清单：先用端到端价值与边界定义把用例钉住，再用Creation到持续改进逐项扫描识别收益与缺口，尤其优先补齐数据筛选与治理控制这两块硬底座，最后把试点嵌入价值流与复盘节奏;体检做得好，AI用例就能在可接受风险之内稳定释放效率与体验收益，而不是上线越快、翻车越快。
579
580
581 我是AI+ITIL教练长河achotsao，欢迎+V：achotsao交流，即可第一时间获得ITIL 第5版最新动态及官方特邀中国区大使的深度解析。
深圳市艾拓先锋企业管理咨询有限公司