Wiki source code of ITIL v5:6C AI能力模型先别背,用它做一次“AI用例体检”
Version 4.1 by superadmin on 2026/02/11, 08:37
Hide last authors
| author | version | line-number | content |
|---|---|---|---|
| |
1.1 | 1 | 2026年1月29日,PeopleCert正式发布了ITIL 第5版。作为ITIL官方中国区产品大使,我将会推出系列文章帮大家解读ITIL 第5版到底有哪些重大的更新。 |
| 2 | |||
| |
4.1 | 3 | (% style="text-align:center" %) |
| 4 | [[image:1.png]] | ||
| |
1.1 | 5 | |
| 6 | ITIL v5(中文语境下通常称为ITIL 第5版)已经正式发布。对很多组织来说,真正的困惑不是“要不要上AI”,而是“上什么AI、先上哪里、怎么上才不翻车”。热度永远不缺,工具也永远不缺,缺的是一种能把AI从概念拉回到管理能力的框架:让组织在做决策之前,先看清用例的价值边界、风险边界与数据门槛。 | ||
| 7 | |||
| 8 | 这正是6C AI能力模型的意义。很多人第一次接触这类模型,习惯把它当成考试要点去记:六个C分别是什么、每个C的定义是什么。背下来当然没坏处,但真正有价值的用法,是把它当成“体检表”,在立项前把AI用例过一遍,避免两种典型悲剧:要么做了半天发现价值不大;要么做得很快却把风险放大,最后不得不回到人工兜底,效率收益被抵消。 | ||
| 9 | |||
| 10 | ITIL 第5版把AI治理放进核心语境之后,6C更像是一张能力地图:它告诉你,AI不是单点工具,而是一组能力组合;你不是在买一个模型,而是在建设一套可持续、可审计、可问责的组织能力。把6C用对了,体检一次,就能少走几个月弯路。 | ||
| 11 | |||
| 12 | |||
| 13 | === 一、ITIL 第5版升级内容全景 === | ||
| 14 | |||
| 15 | 在进入6C体检方法之前,先把ITIL 第5版的更新内容概述完整交代,因为6C并不是孤立的,它必须嵌在ITIL 第5版的整体结构里才能发挥作用。 | ||
| 16 | |||
| 17 | ==== 1)定位升级:从服务管理走向数字产品与服务管理 ==== | ||
| 18 | |||
| 19 | ITIL 第5版把管理对象扩展为数字产品与服务的整体,强调端到端价值交付。这意味着AI用例不应被局限在服务台或运维工具层,而要放进端到端价值流中评估:它到底改善了哪段旅程、哪类结果、哪种体验。 | ||
| 20 | |||
| 21 | ==== 2)生命周期模型升级:八个阶段覆盖从想法到退役 ==== | ||
| 22 | |||
| 23 | ITIL 第5版提出产品与服务生命周期的八个阶段:发现、设计、获取、构建、转换、运营、交付、支持。AI用例可能出现在任何阶段,体检也必须能回答:它落在哪个阶段,如何与上下游协作,风险在哪些阶段被放大或被控制。 | ||
| 24 | |||
| 25 | ==== 3)体验进入核心:价值不只看效率,更看旅程摩擦与结果 ==== | ||
| 26 | |||
| 27 | AI让流程更快不一定让体验更好。ITIL 第5版强调体验进入核心,意味着体检必须问:AI减少了哪些摩擦、是否引入新的摩擦、客户满意度是否会被真实改善。 | ||
| 28 | |||
| 29 | ==== 4)AI进入框架中心:从工具话题走向治理与能力边界 ==== | ||
| 30 | |||
| 31 | ITIL 第5版强调AI带来的不仅是效率机会,也是治理挑战。数据质量、责任边界、授权与问责、可审计性是硬底座。体检必须明确:这个用例需要什么数据门槛、谁承担问责、如何确保可审计性。 | ||
| 32 | |||
| 33 | ==== 5)实践使用方式变化:从清单背诵走向情境化组合 ==== | ||
| 34 | |||
| 35 | AI落地往往需要多实践组合:事件管理、请求履行、知识管理、度量与报告、风险管理、信息安全等要被按环境拼装。体检要能提示:哪些实践能力不足会成为瓶颈。 | ||
| 36 | |||
| 37 | 有了这张全景图,6C体检就不再是“AI团队自己的事”,而会变成数字产品与服务管理体系的一部分:从价值、到数据、到治理、到持续改进,形成闭环。 | ||
| 38 | |||
| 39 | |||
| 40 | === 二、6C AI能力模型的正确打开方式:它不是分类表,而是“立项前的风险与收益扫描仪” === | ||
| 41 | |||
| 42 | 做AI用例体检,目标不是把用例打分打到漂亮,而是快速识别三件事: | ||
| 43 | |||
| 44 | • 这件事值不值得做 | ||
| 45 | |||
| 46 | • 它改善的是端到端价值,还是只优化了局部指标 | ||
| 47 | |||
| 48 | • 它带来的收益是否可度量、可持续 | ||
| 49 | |||
| 50 | • 这件事能不能做稳 | ||
| 51 | |||
| 52 | • 数据门槛是否满足准确性、完整性与一致性 | ||
| 53 | |||
| 54 | • 风险边界是否清晰,是否具备可审计性与问责机制 | ||
| 55 | |||
| 56 | • 这件事该怎么排顺序做 | ||
| 57 | |||
| 58 | • 先做哪一个C,后做哪一个C | ||
| 59 | |||
| 60 | • 哪些能力不足会让用例“看起来能做、实际上做不稳” | ||
| 61 | |||
| 62 | 把这三件事扫清,才是6C体检的价值。接下来进入方法本身:如何体检、体检什么、如何下结论。 | ||
| 63 | |||
| |
4.1 | 64 | (% style="text-align:center" %) |
| 65 | [[image:2.jpg||height="305" width="311"]] | ||
| |
1.1 | 66 | |
| 67 | === === | ||
| 68 | |||
| 69 | === 三、AI用例体检的标准流程:四步走,把热情变成可控决策 === | ||
| 70 | |||
| 71 | 不论你要做的是智能服务台、自动分派、告警聚合、知识生成,还是风险评估与变更建议,都建议按四步体检流程推进。它比“先PoC再说”更省成本,也更符合ITIL 第5版强调的治理与可持续性。 | ||
| 72 | |||
| 73 | ==== 第一步:定义用例的端到端结果与边界 ==== | ||
| 74 | |||
| 75 | 很多AI用例失败不是技术问题,而是边界问题:目标不清、范围膨胀、期望失控。体检的第一步要把用例钉在端到端价值上。 | ||
| 76 | |||
| 77 | 建议明确三条边界: | ||
| 78 | |||
| 79 | **业务结果边界** | ||
| 80 | |||
| 81 | • 目标是缩短端到端周期时间,还是减少等待,还是提升满意度 | ||
| 82 | |||
| 83 | **触点边界** | ||
| 84 | |||
| 85 | • AI介入哪些触点,改变谁的体验,影响哪些决策点 | ||
| 86 | |||
| 87 | **执行边界** | ||
| 88 | |||
| 89 | • AI是只给建议,还是自动执行动作 | ||
| 90 | |||
| 91 | • 哪些动作必须由授权人批准 | ||
| 92 | |||
| 93 | 边界不清,后面所有C都无从谈起。 | ||
| 94 | |||
| 95 | ==== 第二步:用6C逐项扫描,找出收益来源与风险缺口 ==== | ||
| 96 | |||
| 97 | 这一步是核心。不要急着求全,先求“看见缺口”。6C的具体命名在不同材料中可能存在表述差异,但体检时更重要的是每个C对应的能力维度与检查问题。以下给出一套可直接落地的体检问法,把6C变成可用工具。 | ||
| 98 | |||
| 99 | ==== 第三步:给出体检结论与优先级顺序 ==== | ||
| 100 | |||
| 101 | 体检不是写报告,而是为了决策。结论建议分成三类: | ||
| 102 | |||
| 103 | **立即可做** | ||
| 104 | |||
| 105 | • 数据质量过门槛,治理边界清晰,收益可度量 | ||
| 106 | |||
| 107 | **需要先补能力再做** | ||
| 108 | |||
| 109 | • 用例方向对,但存在关键能力缺口(例如数据记录不一致、问责不清) | ||
| 110 | |||
| 111 | **暂缓或收缩范围** | ||
| 112 | |||
| 113 | • 收益不大、风险很高、或边界难以治理 | ||
| 114 | |||
| 115 | ==== 第四步:把体检结果嵌入价值流与持续改进节奏 ==== | ||
| 116 | |||
| 117 | AI用例不是一次性上线,而是持续演进。体检结论要落到: | ||
| 118 | |||
| 119 | • 价值流的哪个环节试点 | ||
| 120 | |||
| 121 | • 用什么最小度量集验证收益 | ||
| 122 | |||
| 123 | • 用什么复盘节奏识别偏差并持续改进 | ||
| 124 | |||
| 125 | 这一步做不到,AI用例就很容易变成“上线即巅峰”,后续被噪声与风险拖垮。 | ||
| 126 | |||
| 127 | |||
| 128 | === 四、6C体检清单:每个C问这几件事,就能快速识别缺口 === | ||
| 129 | |||
| 130 | 下面进入最关键的部分:把6C变成体检清单。为了可操作,这里用“每个C三到五个问题”的方式呈现,读者可以直接把自己的用例逐条过一遍。 | ||
| 131 | |||
| 132 | ==== C1:Creation(生成)——AI产出的内容与建议到底用来干什么 ==== | ||
| 133 | |||
| 134 | 这一类能力关心“AI产出什么、产出是否可用”。体检要问: | ||
| 135 | |||
| 136 | **产出类型是什么** | ||
| 137 | |||
| 138 | • 是文本(例如工单回复、知识条目),还是结构化结论(例如分类、优先级),还是行动建议(例如排障步骤) | ||
| 139 | |||
| 140 | **产出使用场景是什么** | ||
| 141 | |||
| 142 | • 面向内部员工,还是面向外部客户 | ||
| 143 | |||
| 144 | • 产出一旦错误,会带来什么后果 | ||
| 145 | |||
| 146 | **产出验收标准是什么** | ||
| 147 | |||
| 148 | • 什么叫正确、可用、合规 | ||
| 149 | |||
| 150 | • 如何验证,谁负责验证 | ||
| 151 | |||
| 152 | • 是否存在“看起来很好、实际上不可用”的风险 | ||
| 153 | |||
| 154 | • 例如语气自然但事实错误 | ||
| 155 | |||
| 156 | • 例如回答完整但不符合组织政策 | ||
| 157 | |||
| 158 | 如果这一关说不清,后面就别谈自动化,因为你连“产出是否合格”都无法判断。 | ||
| 159 | |||
| 160 | ==== C2:Curation(筛选与治理)——知识与数据是否干净,是否可追溯 ==== | ||
| 161 | |||
| 162 | 这一类能力关心“输入与知识资产是否可靠”。体检要问:• | ||
| 163 | |||
| 164 | **输入与知识从哪里来** | ||
| 165 | |||
| 166 | * ((( | ||
| 167 | 数据与知识来源是什么 | ||
| 168 | ))) | ||
| 169 | * ((( | ||
| 170 | 来自工单、变更记录、监控告警、知识库,还是外部文档 | ||
| 171 | ))) | ||
| 172 | * ((( | ||
| 173 | 是否区分人工沉淀、系统记录、外部引入、AI 生成内容 | ||
| 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 | ))) | ||
| 217 | * ((( | ||
| 218 | AI 生成内容是否会回流到知识库 | ||
| 219 | ))) | ||
| 220 | * ((( | ||
| 221 | 回流前是否有审核机制与明确责任人 | ||
| 222 | ))) | ||
| 223 | |||
| 224 | **错误输入的风险评估** | ||
| 225 | |||
| 226 | * ((( | ||
| 227 | 如果输入本身是错的,AI 是否会放大错误 | ||
| 228 | ))) | ||
| 229 | * ((( | ||
| 230 | 是否存在“越用越脏”的风险 | ||
| 231 | ))) | ||
| 232 | |||
| 233 | 这是AI用例最常见的“隐形瓶颈”。很多团队一上来就做Creation,结果被Curation卡死:数据不干净,输出自然不稳。 | ||
| 234 | |||
| 235 | ==== C3:Communication(沟通)——AI如何与人协作,如何避免误导与信任损耗 ==== | ||
| 236 | |||
| 237 | 这一类能力关心“AI输出如何被理解与使用”。体检要问: | ||
| 238 | |||
| 239 | **输出是否足够透明** | ||
| 240 | |||
| 241 | * ((( | ||
| 242 | AI 的关键假设是否明确说明 | ||
| 243 | ))) | ||
| 244 | * ((( | ||
| 245 | 使用了哪些前提条件或默认判断 | ||
| 246 | ))) | ||
| 247 | * ((( | ||
| 248 | 是否清楚区分事实、推断与建议 | ||
| 249 | ))) | ||
| 250 | |||
| 251 | **不确定性是否被显式表达** | ||
| 252 | |||
| 253 | * ((( | ||
| 254 | 是否提示置信度、适用范围或不确定性 | ||
| 255 | ))) | ||
| 256 | * ((( | ||
| 257 | 是否说明哪些地方可能是猜测、近似或补全 | ||
| 258 | ))) | ||
| 259 | |||
| 260 | **人机协作关系是否清晰** | ||
| 261 | |||
| 262 | * ((( | ||
| 263 | 人在这个环节中扮演什么角色 | ||
| 264 | |||
| |
4.1 | 265 | * |
| |
1.1 | 266 | |
| 267 | 审核者、执行者,还是最终决策者 | ||
| 268 | ))) | ||
| 269 | * ((( | ||
| 270 | 哪些情况下必须人工介入 | ||
| 271 | ))) | ||
| 272 | * ((( | ||
| 273 | 哪些输出只能作为参考而不能直接执行 | ||
| 274 | ))) | ||
| 275 | |||
| 276 | **对用户体验的真实影响** | ||
| 277 | |||
| 278 | * ((( | ||
| 279 | 输出更快是否真的带来更好的体验 | ||
| 280 | ))) | ||
| 281 | * ((( | ||
| 282 | 是否引入新的摩擦 | ||
| 283 | |||
| |
4.1 | 284 | * |
| |
1.1 | 285 | |
| 286 | 反复确认 | ||
| 287 | |||
| |
4.1 | 288 | * |
| |
1.1 | 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 | ))) | ||
| 319 | |||
| 320 | 很多AI用例的失败不是因为“答错”,而是因为“让人误以为答对”。信任损耗一旦发生,恢复成本很高。 | ||
| 321 | |||
| 322 | ==== C4:Coordination(协同与编排)——AI如何触发行动,如何把工作编排起来 ==== | ||
| 323 | |||
| 324 | 这一类能力关心“从建议到行动”的链路是否可控。体检要问: | ||
| 325 | |||
| 326 | **AI 输出会触发哪些动作** | ||
| 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 | ))) | ||
| 391 | |||
| 392 | Coordination做不好,AI就只能停留在“聊天机器人”层,无法形成真正的效率闭环;但Coordination做得太快,又会把风险放大,所以治理边界必须同时到位。 | ||
| 393 | |||
| 394 | ==== C5:Control(控制与治理)——风险边界、授权、问责、可审计性是否完整 ==== | ||
| 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 | ))) | ||
| 454 | |||
| 455 | Control是“必修课”的核心。没有Control,前面四个C做得越好,风险放大得越快。 | ||
| 456 | |||
| 457 | ==== C6:持续改进(持续改进)——上线之后如何变得更好,而不是更乱 ==== | ||
| 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 | ))) | ||
| 520 | |||
| 521 | 持续改进缺失时,AI用例常见路径是:上线初期看起来很强,三个月后被噪声与例外打垮,最后回到人工兜底,组织对AI产生疲劳与不信任。 | ||
| 522 | |||
| 523 | |||
| 524 | === 五、体检结论怎么写才有用:给出“能做、怎么做、先做什么” === | ||
| 525 | |||
| 526 | 体检结果要能直接驱动行动。建议把结论写成三层: | ||
| 527 | |||
| 528 | **能做什么** | ||
| 529 | |||
| 530 | • 哪些场景适合先做,哪些要暂缓 | ||
| 531 | |||
| 532 | **怎么做** | ||
| 533 | |||
| 534 | • 先在哪条价值流试点,AI角色是建议还是执行 | ||
| 535 | |||
| 536 | • 关键控制点与授权机制如何配置 | ||
| 537 | |||
| 538 | **先做什么** | ||
| 539 | |||
| 540 | • 六个C里最短板的是哪一个 | ||
| 541 | |||
| 542 | • 先补数据治理与证据链,还是先补编排与自动化闭环 | ||
| 543 | |||
| 544 | 为了更易落地,可以把行动项按优先级写成: | ||
| 545 | |||
| 546 | **• 第一优先:补Curation与Control** | ||
| 547 | |||
| 548 | • 先把数据门槛、证据链、授权与问责补齐 | ||
| 549 | |||
| 550 | **• 第二优先:补Coordination** | ||
| 551 | |||
| 552 | • 在可控边界内做自动化编排,形成闭环 | ||
| 553 | |||
| 554 | **• 第三优先:优化Communication与持续改进** | ||
| 555 | |||
| 556 | • 降低误导风险,建立复盘节奏,让用例长期变好 | ||
| 557 | |||
| 558 | 这个顺序不是绝对,但在多数ITSM与平台场景里非常实用:数据与治理是地基,编排是骨架,沟通与改进是肌肉与神经。 | ||
| 559 | |||
| 560 | |||
| 561 | === 六、常见误判与纠偏:为什么很多AI用例“看起来能做,最后做不稳” === | ||
| 562 | |||
| 563 | 用6C体检,最值钱的往往是提前识别误判。以下三类误判最常见: | ||
| 564 | |||
| 565 | **• 误判一:把Creation当全部** | ||
| 566 | |||
| 567 | 只盯生成效果,不看数据质量与治理边界。纠偏方式是先补Curation与Control,把证据链与问责机制落地。 | ||
| 568 | |||
| 569 | **• 误判二:把自动化闭环当作越快越好** | ||
| 570 | |||
| 571 | Coordination推进过快,触发条件与异常降级不清晰,导致误作扩大影响。纠偏方式是明确执行边界:先建议、后执行;先低风险、后高风险。 | ||
| 572 | |||
| 573 | **• 误判三:把上线当终点** | ||
| 574 | |||
| 575 | 没有持续改进节奏,偏差积累成噪声,最终回到人工兜底。纠偏方式是把度量与复盘固化为BAU,让用例持续演进。 | ||
| 576 | |||
| 577 | 这些误判背后其实只有一句话:AI用例不是模型问题,而是管理能力问题。6C体检的价值,就是把管理能力的缺口提前照出来。 | ||
| 578 | |||
| 579 | |||
| 580 | ITIL v5时代用6C AI能力模型做“AI用例体检”的正确姿势,是把它当成一张能力地图而不是背诵清单:先用端到端价值与边界定义把用例钉住,再用Creation到持续改进逐项扫描识别收益与缺口,尤其优先补齐数据筛选与治理控制这两块硬底座,最后把试点嵌入价值流与复盘节奏;体检做得好,AI用例就能在可接受风险之内稳定释放效率与体验收益,而不是上线越快、翻车越快。 | ||
| 581 | |||
| 582 | |||
| 583 | 我是AI+ITIL教练长河achotsao,欢迎+V:achotsao交流,即可第一时间获得ITIL 第5版最新动态及官方特邀中国区大使的深度解析。 |