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