由 superadmin 于 2026/05/27, 20:33 最后修改
Show last authors
| author | version | line-number | content |
|---|---|---|---|
| 1 | 2026年1月29日,PeopleCert正式发布了ITIL 第5版。作为ITIL官方中国区产品大使,我将会推出系列文章帮大家解读ITIL 第5版到底有哪些重大的更新。 | ||
| 2 | |||
| 3 | |||
| 4 | (% style="text-align:center" %) | ||
| 5 | [[image:1.png||height="336" width="554"]] | ||
| 6 | |||
| 7 | ITIL v5(中文语境下通常称为ITIL 第5版)已经正式发布。对很多组织来说,真正的困惑不是“要不要上AI”,而是“上什么AI、先上哪里、怎么上才不翻车”。 热度永远不缺,工具也永远不缺,缺的是一种能把AI从概念拉回到管理能力的框架:让组织在做决策之前,先看清用例的价值边界、风险边界与数据门槛。 | ||
| 8 | |||
| 9 | |||
| 10 | 这正是6C AI能力模型的意义。 很多人第一次接触这类模型,习惯把它当成考试要点去记:六个C分别是什么、每个C的定义是什么。 背下来当然没坏处,但真正有价值的用法,是把它当成“体检表”,在立项前把AI用例过一遍,避免两种典型悲剧:要么做了半天发现价值不大;要么做得很快却把风险放大,最后不得不回到人工兜底,效率收益被抵消。 | ||
| 11 | |||
| 12 | |||
| 13 | ITIL 第5版把AI治理放进核心语境之后,6C更像是一张能力地图:它告诉你,AI不是单点工具,而是一组能力组合; 你不是在买一个模型,而是在建设一套可持续、可审计、可问责的组织能力。 把6C用对了,体检一次,就能少走几个月弯路。 | ||
| 14 | |||
| 15 | |||
| 16 | |||
| 17 | === 一、ITIL 第5版升级内容全景 === | ||
| 18 | |||
| 19 | |||
| 20 | 在进入6C体检方法之前,先把ITIL 第5版的更新内容概述完整交代,因为6C并不是孤立的,它必须嵌在ITIL 第5版的整体结构里才能发挥作用。 | ||
| 21 | |||
| 22 | ==== 1)定位升级:从服务管理走向数字产品与服务管理 ==== | ||
| 23 | |||
| 24 | ITIL 第5版把管理对象扩展为数字产品与服务的整体,强调端到端价值交付。 这意味着AI用例不应被局限在服务台或运维工具层,而要放进端到端价值流中评估:它到底改善了哪段旅程、哪类结果、哪种体验。 | ||
| 25 | |||
| 26 | |||
| 27 | ==== 2)生命周期模型升级:八个阶段覆盖从想法到退役 ==== | ||
| 28 | |||
| 29 | ITIL 第5版提出产品与服务生命周期的八个阶段:发现、设计、获取、构建、转换、运营、交付、支持。 AI用例可能出现在任何阶段,体检也必须能回答:它落在哪个阶段,如何与上下游协作,风险在哪些阶段被放大或被控制。 | ||
| 30 | |||
| 31 | |||
| 32 | ==== 3)体验进入核心:价值不只看效率,更看旅程摩擦与结果 ==== | ||
| 33 | |||
| 34 | AI让流程更快不一定让体验更好。ITIL 第5版强调体验进入核心,意味着体检必须问:AI减少了哪些摩擦、是否引入新的摩擦、客户满意度是否会被真实改善。 | ||
| 35 | |||
| 36 | |||
| 37 | ==== 4)AI进入框架中心:从工具话题走向治理与能力边界 ==== | ||
| 38 | |||
| 39 | ITIL 第5版强调AI带来的不仅是效率机会,也是治理挑战。 数据质量、责任边界、授权与问责、可审计性是硬底座。 体检必须明确:这个用例需要什么数据门槛、谁承担问责、如何确保可审计性。 | ||
| 40 | |||
| 41 | |||
| 42 | ==== 5)实践使用方式变化:从清单背诵走向情境化组合 ==== | ||
| 43 | |||
| 44 | AI落地往往需要多实践组合:事件管理、请求履行、知识管理、度量与报告、风险管理、信息安全等要被按环境拼装。 体检要能提示:哪些实践能力不足会成为瓶颈。 | ||
| 45 | |||
| 46 | 有了这张全景图,6C体检就不再是“AI团队自己的事”,而会变成数字产品与服务管理体系的一部分:从价值、到数据、到治理、到持续改进,形成闭环。 | ||
| 47 | |||
| 48 | |||
| 49 | |||
| 50 | === 二、6C AI能力模型的正确打开方式:它不是分类表,而是“立项前的风险与收益扫描仪” === | ||
| 51 | |||
| 52 | |||
| 53 | 做AI用例体检,目标不是把用例打分打到漂亮,而是快速识别三件事: | ||
| 54 | |||
| 55 | • 这件事值不值得做 | ||
| 56 | |||
| 57 | • 它改善的是端到端价值,还是只优化了局部指标 | ||
| 58 | |||
| 59 | • 它带来的收益是否可度量、可持续 | ||
| 60 | |||
| 61 | • 这件事能不能做稳 | ||
| 62 | |||
| 63 | • 数据门槛是否满足准确性、完整性与一致性 | ||
| 64 | |||
| 65 | • 风险边界是否清晰,是否具备可审计性与问责机制 | ||
| 66 | |||
| 67 | • 这件事该怎么排顺序做 | ||
| 68 | |||
| 69 | • 先做哪一个C,后做哪一个C | ||
| 70 | |||
| 71 | • 哪些能力不足会让用例“看起来能做、实际上做不稳” | ||
| 72 | |||
| 73 | 把这三件事扫清,才是6C体检的价值。 接下来进入方法本身:如何体检、体检什么、如何下结论。 | ||
| 74 | |||
| 75 | |||
| 76 | (% style="text-align:center" %) | ||
| 77 | [[image:2.jpg||height="305" width="311"]] | ||
| 78 | |||
| 79 | === === | ||
| 80 | |||
| 81 | === 三、AI用例体检的标准流程:四步走,把热情变成可控决策 === | ||
| 82 | |||
| 83 | |||
| 84 | 不论你要做的是智能服务台、自动分派、告警聚合、知识生成,还是风险评估与变更建议,都建议按四步体检流程推进。 它比“先PoC再说”更省成本,也更符合ITIL 第5版强调的治理与可持续性。 | ||
| 85 | |||
| 86 | ==== 第一步:定义用例的端到端结果与边界 ==== | ||
| 87 | |||
| 88 | 很多AI用例失败不是技术问题,而是边界问题:目标不清、范围膨胀、期望失控。 体检的第一步要把用例钉在端到端价值上。 | ||
| 89 | |||
| 90 | 建议明确三条边界: | ||
| 91 | |||
| 92 | **业务结果边界** | ||
| 93 | |||
| 94 | • 目标是缩短端到端周期时间,还是减少等待,还是提升满意度 | ||
| 95 | |||
| 96 | **触点边界** | ||
| 97 | |||
| 98 | • AI介入哪些触点,改变谁的体验,影响哪些决策点 | ||
| 99 | |||
| 100 | **执行边界** | ||
| 101 | |||
| 102 | • AI是只给建议,还是自动执行动作 | ||
| 103 | |||
| 104 | • 哪些动作必须由授权人批准 | ||
| 105 | |||
| 106 | 边界不清,后面所有C都无从谈起。 | ||
| 107 | |||
| 108 | |||
| 109 | ==== 第二步:用6C逐项扫描,找出收益来源与风险缺口 ==== | ||
| 110 | |||
| 111 | 这一步是核心。 不要急着求全,先求“看见缺口”。 6C的具体命名在不同材料中可能存在表述差异,但体检时更重要的是每个C对应的能力维度与检查问题。 以下给出一套可直接落地的体检问法,把6C变成可用工具。 | ||
| 112 | |||
| 113 | |||
| 114 | ==== 第三步:给出体检结论与优先级顺序 ==== | ||
| 115 | |||
| 116 | 体检不是写报告,而是为了决策。 结论建议分成三类: | ||
| 117 | |||
| 118 | **立即可做** | ||
| 119 | |||
| 120 | • 数据质量过门槛,治理边界清晰,收益可度量 | ||
| 121 | |||
| 122 | **需要先补能力再做** | ||
| 123 | |||
| 124 | • 用例方向对,但存在关键能力缺口(例如数据记录不一致、问责不清) | ||
| 125 | |||
| 126 | **暂缓或收缩范围** | ||
| 127 | |||
| 128 | • 收益不大、风险很高、或边界难以治理 | ||
| 129 | |||
| 130 | |||
| 131 | ==== 第四步:把体检结果嵌入价值流与持续改进节奏 ==== | ||
| 132 | |||
| 133 | AI用例不是一次性上线,而是持续演进。 体检结论要落到: | ||
| 134 | |||
| 135 | • 价值流的哪个环节试点 | ||
| 136 | |||
| 137 | • 用什么最小度量集验证收益 | ||
| 138 | |||
| 139 | • 用什么复盘节奏识别偏差并持续改进 | ||
| 140 | |||
| 141 | 这一步做不到,AI用例就很容易变成“上线即巅峰”,后续被噪声与风险拖垮。 | ||
| 142 | |||
| 143 | |||
| 144 | |||
| 145 | === 四、6C体检清单:每个C问这几件事,就能快速识别缺口 === | ||
| 146 | |||
| 147 | |||
| 148 | 下面进入最关键的部分:把6C变成体检清单。 | ||
| 149 | |||
| 150 | |||
| 151 | ==== ==== | ||
| 152 | |||
| 153 | == 第一种能力:生成(Creation)—— 让AI"创造"新内容 == | ||
| 154 | |||
| 155 | >**官方定义**:AI根据提示或触发器生成全新的输出。包括制作内容、代码、文档或任何其他之前不存在的工件。 | ||
| 156 | |||
| 157 | **Creation是大多数组织最先接触到的能力**。生成文本、摘要、说明、草稿,这是生成式AI最直接的应用方式。 | ||
| 158 | |||
| 159 | **在ITSM场景中,Creation的典型用例:** | ||
| 160 | |||
| 161 | * 对用户的问题生成答案 | ||
| 162 | * 为沟通生成个性化文本,调整信息以适应利益相关方的语言、角色和偏好 | ||
| 163 | * 根据结构化的发布数据,自动生成发布说明、变更公告和部署计划 | ||
| 164 | * 起草服务描述或服务级别协议(SLA) | ||
| 165 | * 根据已定义的条件或业务规则生成工作流 | ||
| 166 | |||
| 167 | **这一层的关键不是AI"能不能生成",而是三件事:** | ||
| 168 | |||
| 169 | * 输入是否干净:记录是否完整、字段是否规范 | ||
| 170 | * 输出是否可控:是否有人工审核与修改权 | ||
| 171 | * 责任是否清晰:生成内容谁负责发布 | ||
| 172 | |||
| 173 | 如果没有这些控制,Creation很快会从"省时间"变成"制造错误"。 | ||
| 174 | |||
| 175 | ---- | ||
| 176 | |||
| 177 | == 第二种能力:整理(Curation)—— 让AI帮你"收拾烂摊子" == | ||
| 178 | |||
| 179 | >**官方定义**:AI通过识别冗余、过时信息、不一致或不合规之处来改善现有数据或知识的质量、组织结构和相关性。 | ||
| 180 | |||
| 181 | 很多组织跳过这一层直接冲别的,但如果你不整理数据底座,后面的能力就都是空中楼阁。 | ||
| 182 | |||
| 183 | **Curation的典型用例:** | ||
| 184 | |||
| 185 | * 检测并标记过时的知识库文章 | ||
| 186 | * 检测和清理产品和服务管理数据库中的重复记录 | ||
| 187 | * 突出服务级别协议与供应商补充合同之间的差异 | ||
| 188 | * 通过检查与已批准的公司政策和规则的一致性来验证文件 | ||
| 189 | |||
| 190 | **在ITSM中,Curation的典型场景包括:** | ||
| 191 | |||
| 192 | * 知识条目去重与合并 | ||
| 193 | * 将事件与问题、已知错误关联 | ||
| 194 | * 把历史处理经验整理成可复用知识 | ||
| 195 | |||
| 196 | **这一层的能力要求是:** | ||
| 197 | |||
| 198 | * 知识有生命周期 | ||
| 199 | * 内容有版本与责任人 | ||
| 200 | * AI的建议只是输入,不是最终裁决 | ||
| 201 | |||
| 202 | 没有Curation,生成式AI只会让知识库更"吵"。 | ||
| 203 | |||
| 204 | ---- | ||
| 205 | |||
| 206 | == 第三种能力:解释(Interpretation)—— 让AI帮你"看懂"信息 == | ||
| 207 | |||
| 208 | >**官方定义**:AI通过总结、改写、重组或翻译,帮助用户查找、理解、定位或改进现有内容。 | ||
| 209 | |||
| 210 | 这是教材中6C模型的第三种能力(注意:不少文章把这一层误写为"Classification分类",这是不准确的)。 | ||
| 211 | |||
| 212 | **Interpretation的典型用例:** | ||
| 213 | |||
| 214 | * 为管理报告总结复杂的事件工单 | ||
| 215 | * 将知识文章重写以便更易理解 | ||
| 216 | * 使用自然语言提示语,根据特定的上下文生成摘要报告 | ||
| 217 | * AI增强的IT成本分类和归因,以实现准确的成本分配、分析和报告 | ||
| 218 | |||
| 219 | **在ITSM场景中,解释能力的价值:** | ||
| 220 | |||
| 221 | * 把海量的事件日志变成管理层能看懂的摘要 | ||
| 222 | * 将技术语言翻译成业务语言 | ||
| 223 | * 帮助非技术人员用自然语言查询数据 | ||
| 224 | |||
| 225 | **这一层的边界:** | ||
| 226 | |||
| 227 | * AI做的是"翻译和提炼",不是"下结论" | ||
| 228 | * 解释的准确性需要人来验证 | ||
| 229 | * 过度依赖AI解释可能导致信息失真 | ||
| 230 | |||
| 231 | ---- | ||
| 232 | |||
| 233 | == 第四种能力:认知(Cognition)—— 让AI帮你"发现隐藏的模式" == | ||
| 234 | |||
| 235 | >**官方定义**:AI识别数据中的模式、异常或隐藏的见解,从而实现主动检测、预测和分析。 | ||
| 236 | |||
| 237 | 注意:不少文章把这一层写成"Calculation计算",这也是偏差。教材原文是**Cognition(认知)**,它不是做数学运算,而是发现数据中人类不容易察觉的模式。 | ||
| 238 | |||
| 239 | **Cognition的典型用例:** | ||
| 240 | |||
| 241 | * 分析重大事件以更好地理解可能的原因和后果 | ||
| 242 | * 检测反复出现的事件趋势,这表明存在更深层次的问题 | ||
| 243 | * 识别流程或价值流中的瓶颈 | ||
| 244 | * 识别复杂环境中因变化引起的潜在问题 | ||
| 245 | * 根据历史使用模式和季节性趋势,预测系统工作负载的增加情况 | ||
| 246 | |||
| 247 | **在ITSM中,认知能力对应的是:** | ||
| 248 | |||
| 249 | * 异常检测 | ||
| 250 | * 根因推断候选路径 | ||
| 251 | * 趋势预测 | ||
| 252 | * 告警聚类与降噪 | ||
| 253 | |||
| 254 | **这一层最容易被滥用:** | ||
| 255 | |||
| 256 | * AI给出的是"发现和建议",不是"结论和判决" | ||
| 257 | * 误报率需要持续校正 | ||
| 258 | * 如果直接让AI自动执行基于认知的决策,而没有质量门槛与回滚机制,风险会被迅速放大 | ||
| 259 | |||
| 260 | ---- | ||
| 261 | |||
| 262 | == 第五种能力:沟通(Communication)—— 让AI做"沟通界面" == | ||
| 263 | |||
| 264 | >**官方定义**:AI作为一种沟通性界面,帮助用户与服务和系统自然地互动。 | ||
| 265 | |||
| 266 | 这是智能服务台最常被寄予厚望的一层能力。 | ||
| 267 | |||
| 268 | **Communication的典型用例:** | ||
| 269 | |||
| 270 | * 聊天机器人帮助用户获得技术支持 | ||
| 271 | * 虚拟智能体协助提交服务请求 | ||
| 272 | * 为终端用户提供个性化的重大事件沟通,调整信息以适应他们的语言、角色和偏好 | ||
| 273 | * AI智能体进行调查、收集反馈,并应用情感分析来评估和报告利益相关方的满意度 | ||
| 274 | |||
| 275 | **这一层的关键边界:** | ||
| 276 | |||
| 277 | * AI可以解释与引导 | ||
| 278 | * AI不应做关键承诺 | ||
| 279 | * 对外表达必须有模板与限制 | ||
| 280 | |||
| 281 | 成熟组织往往先让AI"解释系统在发生什么",而不是"代表组织承诺结果"。 | ||
| 282 | |||
| 283 | ---- | ||
| 284 | |||
| 285 | == 第六种能力:协调(Coordination)—— 让AI"执行和编排操作" == | ||
| 286 | |||
| 287 | >**官方定义**:AI自主在系统间执行、协调或触发操作,通常是响应事件、请求或模式。 | ||
| 288 | |||
| 289 | 这是很多组织真正开始感受到AI价值的层级,也是风险最高的一层。 | ||
| 290 | |||
| 291 | **Coordination的典型用例:** | ||
| 292 | |||
| 293 | * 对用户请求进行分类,并将其分配给最合适的团队 | ||
| 294 | * 基于实时分析自动升级高影响事件 | ||
| 295 | * 检测到特定错误、事态或趋势后触发补救工作流 | ||
| 296 | |||
| 297 | **这一层的硬前提是:** | ||
| 298 | |||
| 299 | * 工作流清晰 | ||
| 300 | * 权限与责任明确 | ||
| 301 | * 所有动作可追溯、可回滚 | ||
| 302 | |||
| 303 | 没有清晰工作流,AI只会把混乱编排得更快。 | ||
| 304 | |||
| 305 | ---- | ||
| 306 | |||
| 307 | == 用6C做"AI用例体检":一张真正实用的清单 == | ||
| 308 | |||
| 309 | 作为ITSM或平台负责人,你可以用6C模型做三件非常现实的事: | ||
| 310 | |||
| 311 | **第一件:盘点现状——我们在哪几层已经有能力,哪些只是概念** | ||
| 312 | |||
| 313 | |=能力|=典型场景|=我们做到没有|=成熟度 | ||
| 314 | |生成|自动生成事件摘要、变更说明|☐|低/中/高 | ||
| 315 | |整理|知识条目去重与合并|☐|低/中/高 | ||
| 316 | |解释|为管理报告总结事件工单|☐|低/中/高 | ||
| 317 | |认知|检测事件趋势、识别瓶颈|☐|低/中/高 | ||
| 318 | |沟通|聊天机器人技术支持|☐|低/中/高 | ||
| 319 | |协调|自动分派、自动升级|☐|低/中/高 | ||
| 320 | |||
| 321 | **第二件:排定顺序——下一步补哪一层最有价值、风险最可控** | ||
| 322 | |||
| 323 | 6C模型的价值在于:它给你一个很合理的推进顺序。不是"先上哪个技术",而是"先建哪类能力"。先夯实数据与责任(生成→整理→解释),再引入认知与协调,AI才会成为放大组织能力的杠杆,而不是放大风险的放大器。 | ||
| 324 | |||
| 325 | **第三件:对齐治理——哪些层级必须加强人工确认与审计** | ||
| 326 | |||
| 327 | ITIL第5版强调治理,不是为了给你加审批,而是为了让AI能力可控、可追溯、可纠偏。对AI能力来说,治理至少要回答四个问题: | ||
| 328 | |||
| 329 | * **责任**:AI建议错了谁负责,自动操作错了谁负责 | ||
| 330 | * **边界**:哪些场景允许自动,哪些必须人工确认 | ||
| 331 | * **审计**:决策依据如何记录,事后如何追溯 | ||
| 332 | * **纠偏**:模型如何被反馈、如何更新、如何防止旧错误复发 | ||
| 333 | |||
| 334 | |||
| 335 | |||
| 336 | === 五、体检结论怎么写才有用:给出“能做、怎么做、先做什么” === | ||
| 337 | |||
| 338 | |||
| 339 | 体检结果要能直接驱动行动。 建议把结论写成三层: | ||
| 340 | |||
| 341 | **能做什么** | ||
| 342 | |||
| 343 | • 哪些场景适合先做,哪些要暂缓 | ||
| 344 | |||
| 345 | |||
| 346 | **怎么做** | ||
| 347 | |||
| 348 | • 先在哪条价值流试点,AI角色是建议还是执行 | ||
| 349 | |||
| 350 | • 关键控制点与授权机制如何配置 | ||
| 351 | |||
| 352 | |||
| 353 | **先做什么** | ||
| 354 | |||
| 355 | • 六个C里最短板的是哪一个 | ||
| 356 | |||
| 357 | • 先补数据治理与证据链,还是先补编排与自动化闭环 | ||
| 358 | |||
| 359 | |||
| 360 | 为了更易落地,可以把行动项按优先级写成: | ||
| 361 | |||
| 362 | **• 第一优先:补Curation与Control** | ||
| 363 | |||
| 364 | • 先把数据门槛、证据链、授权与问责补齐 | ||
| 365 | |||
| 366 | **• 第二优先:补Coordination** | ||
| 367 | |||
| 368 | • 在可控边界内做自动化编排,形成闭环 | ||
| 369 | |||
| 370 | **• 第三优先:优化Communication与持续改进** | ||
| 371 | |||
| 372 | • 降低误导风险,建立复盘节奏,让用例长期变好 | ||
| 373 | |||
| 374 | 这个顺序不是绝对,但在多数ITSM与平台场景里非常实用:数据与治理是地基,编排是骨架,沟通与改进是肌肉与神经。 | ||
| 375 | |||
| 376 | |||
| 377 | |||
| 378 | === 六、常见误判与纠偏:为什么很多AI用例“看起来能做,最后做不稳” === | ||
| 379 | |||
| 380 | |||
| 381 | 用6C体检,最值钱的往往是提前识别误判。 以下三类误判最常见: | ||
| 382 | |||
| 383 | **• 误判一:把Creation当全部** | ||
| 384 | |||
| 385 | 只盯生成效果,不看数据质量与治理边界。 纠偏方式是先补Curation与Control,把证据链与问责机制落地。 | ||
| 386 | |||
| 387 | |||
| 388 | **• 误判二:把自动化闭环当作越快越好** | ||
| 389 | |||
| 390 | Coordination推进过快,触发条件与异常降级不清晰,导致误作扩大影响。 纠偏方式是明确执行边界:先建议、后执行;先低风险、后高风险。 | ||
| 391 | |||
| 392 | |||
| 393 | **• 误判三:把上线当终点** | ||
| 394 | |||
| 395 | 没有持续改进节奏,偏差积累成噪声,最终回到人工兜底。 纠偏方式是把度量与复盘固化为BAU,让用例持续演进。 | ||
| 396 | |||
| 397 | 这些误判背后其实只有一句话:AI用例不是模型问题,而是管理能力问题。 6C体检的价值,就是把管理能力的缺口提前照出来。 | ||
| 398 | |||
| 399 | |||
| 400 | ITIL v5时代用6C AI能力模型做“AI用例体检”的正确姿势,是把它当成一张能力地图而不是背诵清单:先用端到端价值与边界定义把用例钉住,再用Creation到持续改进逐项扫描识别收益与缺口,尤其优先补齐数据筛选与治理控制这两块硬底座,最后把试点嵌入价值流与复盘节奏; 体检做得好,AI用例就能在可接受风险之内稳定释放效率与体验收益,而不是上线越快、翻车越快。 | ||
| 401 | |||
| 402 | |||
| 403 | 欢迎加长河老师微信achotsao,深入交流ITIL 第5版最新资讯。 |