Wiki source code of 价值链模式:为什么 ITIL 第5版要告诉你“常见操作模型长什么样”
Last modified by superadmin on 2026/02/20, 07:33
Show last authors
| author | version | line-number | content |
|---|---|---|---|
| 1 | 2026年1月29日,PeopleCert正式发布了ITIL 第5版。作为ITIL官方中国区产品大使,我将会推出系列文章帮大家解读ITIL 第5版到底有哪些重大的更新。 | ||
| 2 | |||
| 3 | |||
| 4 | |||
| 5 | (% style="text-align:center" %) | ||
| 6 | [[image:11.png||height="306" width="505"]] | ||
| 7 | |||
| 8 | ITIL 第5版已于 2026 年 1 月 29 日正式发布。 很多组织在做体系设计、运营模型设计或 IT 转型咨询时,都会遇到一个相似的困惑: | ||
| 9 | |||
| 10 | • 每个人都懂价值流,但画出来的价值流完全不一样 | ||
| 11 | |||
| 12 | • 每个部门都觉得自己的流程合理,但拼在一起就不顺 | ||
| 13 | |||
| 14 | • 体系文档越写越厚,实际运行却越来越依赖“个人经验” | ||
| 15 | |||
| 16 | 这不是能力问题,而是缺少“共同的操作模型参考”。 ITIL 第5版引入**价值链模式**,本质上是在补这一块短板: 不是告诉你“应该怎么画流程”,而是先告诉你——**在现实世界中,成熟组织通常是用哪几种方式在跑价值链的**。 | ||
| 17 | |||
| 18 | |||
| 19 | 换句话说,价值链模式不是模板,而是“常见成功路径的抽象”。 它的作用不是替你设计体系,而是让你在起步时不要从零猜。 | ||
| 20 | |||
| 21 | |||
| 22 | |||
| 23 | == 一、更新内容概述:六个要点如何把“模式思维”推到前台 == | ||
| 24 | |||
| 25 | |||
| 26 | 按照惯例,本篇依然完整覆盖 ITIL 第5版更新内容概述,但我会专门从“为什么需要模式”的角度来解读。 | ||
| 27 | |||
| 28 | |||
| 29 | **1、定位升级:数字产品和服务管理** | ||
| 30 | |||
| 31 | 当管理对象从 IT 服务扩展到数字产品和服务,组织的运营方式必然出现分化: | ||
| 32 | |||
| 33 | • 有的组织以产品为核心 | ||
| 34 | |||
| 35 | • 有的组织以服务交付为核心 | ||
| 36 | |||
| 37 | • 有的组织以平台与生态为核心 | ||
| 38 | |||
| 39 | 如果不承认这种差异,而强行套一套流程,体系必然失真。 | ||
| 40 | |||
| 41 | |||
| 42 | **2、生命周期模型升级:八个活动覆盖从发现到支持** | ||
| 43 | |||
| 44 | 八个活动提供了“全景坐标系”,但不同组织在这些活动上的重心、顺序与强度并不相同。 模式的意义,在于帮你识别“哪几段是主干,哪几段是支撑”。 | ||
| 45 | |||
| 46 | |||
| 47 | **3、人工智能进入方法论核心** | ||
| 48 | |||
| 49 | AI 会进一步放大组织运行方式的差异: | ||
| 50 | |||
| 51 | • 有的组织更偏自动化与平台化 | ||
| 52 | |||
| 53 | • 有的组织更偏协作与人工判断 | ||
| 54 | |||
| 55 | 模式能帮助你判断:AI 应该嵌在哪些活动里,而不是平均撒。 | ||
| 56 | |||
| 57 | |||
| 58 | **4、指导原则强调取舍** | ||
| 59 | |||
| 60 | 取舍要有参照物。 模式提供的正是这种参照:在类似情境下,成熟组织通常如何取舍。 | ||
| 61 | |||
| 62 | |||
| 63 | **5、实践从清单走向组件库** | ||
| 64 | |||
| 65 | 组件库意味着组合,而组合一定需要“骨架”。 价值链模式就是骨架的候选形态。 | ||
| 66 | |||
| 67 | |||
| 68 | **6、持续改进对象扩大** | ||
| 69 | |||
| 70 | 持续改进不再只是局部优化,而是可以针对“运营模型本身”进行调整。 没有模式,你甚至不知道该改哪一层。 | ||
| 71 | |||
| 72 | |||
| 73 | 所以,价值链模式不是附加内容,而是 ITIL 第5版体系化思维的自然延伸。 | ||
| 74 | |||
| 75 | |||
| 76 | |||
| 77 | == 二、先厘清三个容易混淆的概念:价值链、价值流、价值链模式 == | ||
| 78 | |||
| 79 | |||
| 80 | 在咨询现场,这三个概念经常被混用。 我先帮你把它们摆清楚。 | ||
| 81 | |||
| 82 | • 价值链:一组通用的管理活动骨架,用来承载价值创造 | ||
| 83 | |||
| 84 | • 价值流:某个具体产品或服务从需求到价值实现的真实路径 | ||
| 85 | |||
| 86 | • 价值链模式:多条价值流在组织中反复出现后,形成的“常见运行方式” | ||
| 87 | |||
| 88 | |||
| 89 | 你可以这样理解: | ||
| 90 | |||
| 91 | • 价值链是“骨骼结构” | ||
| 92 | |||
| 93 | • 价值流是“肌肉运动” | ||
| 94 | |||
| 95 | • 价值链模式是“典型姿态” | ||
| 96 | |||
| 97 | ITIL 第5版给你模式,是为了让你在设计体系时,不至于让骨骼、肌肉和姿态完全脱节。 | ||
| 98 | |||
| 99 | |||
| 100 | |||
| 101 | == 三、为什么 ITIL 第5版要给“模式”,而不是让你自由发挥 == | ||
| 102 | |||
| 103 | |||
| 104 | |||
| 105 | 很多人会问:既然强调情境与可裁剪,为什么还要给模式?答案恰恰相反:**只有理解模式,你才能真正裁剪**。 | ||
| 106 | |||
| 107 | |||
| 108 | 在我见过的大量案例里,体系失败通常不是因为“照抄模式”,而是因为“没有任何模式意识”: | ||
| 109 | |||
| 110 | • 把高度产品化的组织,设计成项目驱动型 | ||
| 111 | |||
| 112 | • 把强监管的运行环境,设计成实验探索型 | ||
| 113 | |||
| 114 | • 把平台型组织,套成传统服务交付模型 | ||
| 115 | |||
| 116 | |||
| 117 | 模式的价值在于: | ||
| 118 | |||
| 119 | • 帮你快速识别“我更像哪一类组织” | ||
| 120 | |||
| 121 | • 帮你避免明显不适配的设计 | ||
| 122 | |||
| 123 | • 帮你在合理区间内做裁剪,而不是盲目创新 | ||
| 124 | |||
| 125 | |||
| 126 | |||
| 127 | == 四、六类常见价值链模式:不是标准答案,而是现实原型 == | ||
| 128 | |||
| 129 | |||
| 130 | ITIL 第5版总结了六类常见价值链模式。 我不会逐字复述定义,而是用“你在什么情况下会用它”来讲。 | ||
| 131 | |||
| 132 | |||
| 133 | **1、项目驱动型模式** | ||
| 134 | |||
| 135 | 典型特征: | ||
| 136 | |||
| 137 | • 价值流以项目为主 | ||
| 138 | |||
| 139 | • 阶段清晰,交付有明确里程碑 | ||
| 140 | |||
| 141 | 适用组织: | ||
| 142 | |||
| 143 | • 定制化交付为主 | ||
| 144 | |||
| 145 | • 政府组织、大型企业内部 IT 项目 | ||
| 146 | |||
| 147 | 常见风险: | ||
| 148 | |||
| 149 | • 项目结束即能力流失 | ||
| 150 | |||
| 151 | • 运营与支持容易被弱化 | ||
| 152 | |||
| 153 | |||
| 154 | **2、产品驱动型模式** | ||
| 155 | |||
| 156 | 典型特征: | ||
| 157 | |||
| 158 | • 以产品生命周期为主线 | ||
| 159 | |||
| 160 | • 持续迭代、持续交付 | ||
| 161 | |||
| 162 | 适用组织: | ||
| 163 | |||
| 164 | • 数字产品团队 | ||
| 165 | |||
| 166 | • SaaS、平台型产品组织 | ||
| 167 | |||
| 168 | 常见风险: | ||
| 169 | |||
| 170 | • 忽视运行稳定性 | ||
| 171 | |||
| 172 | • 支持与运营被边缘化 | ||
| 173 | |||
| 174 | |||
| 175 | **3、服务交付型模式** | ||
| 176 | |||
| 177 | 典型特征: | ||
| 178 | |||
| 179 | • 以服务请求与交付为主 | ||
| 180 | |||
| 181 | • 强调可重复性与效率 | ||
| 182 | |||
| 183 | 适用组织: | ||
| 184 | |||
| 185 | • 托管服务提供方 | ||
| 186 | |||
| 187 | • 内部共享服务中心 | ||
| 188 | |||
| 189 | 常见风险: | ||
| 190 | |||
| 191 | • 过度标准化,体验僵化 | ||
| 192 | |||
| 193 | • 难以支持创新型需求 | ||
| 194 | |||
| 195 | |||
| 196 | **4、平台与生态型模式** | ||
| 197 | |||
| 198 | 典型特征: | ||
| 199 | |||
| 200 | • 能力通过平台对外提供 | ||
| 201 | |||
| 202 | • 强依赖合作伙伴与接口 | ||
| 203 | |||
| 204 | 适用组织: | ||
| 205 | |||
| 206 | • 大型平台企业 | ||
| 207 | |||
| 208 | • 多供应商生态组织 | ||
| 209 | |||
| 210 | 常见风险: | ||
| 211 | |||
| 212 | • 治理复杂度急剧上升 | ||
| 213 | |||
| 214 | • 责任边界模糊 | ||
| 215 | |||
| 216 | |||
| 217 | **5、运营稳定型模式** | ||
| 218 | |||
| 219 | 典型特征: | ||
| 220 | |||
| 221 | • 以稳定、可靠为第一目标 | ||
| 222 | |||
| 223 | • 变更节奏谨慎 | ||
| 224 | |||
| 225 | 适用组织: | ||
| 226 | |||
| 227 | • 关键基础设施 | ||
| 228 | |||
| 229 | • 金融、能源等高监管领域 | ||
| 230 | |||
| 231 | 常见风险: | ||
| 232 | |||
| 233 | • 组织速度偏慢 | ||
| 234 | |||
| 235 | • 创新成本高 | ||
| 236 | |||
| 237 | |||
| 238 | **6、探索与创新型模式** | ||
| 239 | |||
| 240 | 典型特征: | ||
| 241 | |||
| 242 | • 小范围试点 | ||
| 243 | |||
| 244 | • 快速验证假设 | ||
| 245 | |||
| 246 | 适用组织: | ||
| 247 | |||
| 248 | • 新技术孵化 | ||
| 249 | |||
| 250 | • AI 能力探索 | ||
| 251 | |||
| 252 | 常见风险: | ||
| 253 | |||
| 254 | • 如果边界不清,容易影响生产环境 | ||
| 255 | |||
| 256 | 这六类模式不是“选一个就完事”,而是很多组织会同时具备两到三类,只是主次不同。 | ||
| 257 | |||
| 258 | |||
| 259 | |||
| 260 | == 五、体系设计时如何用价值链模式,而不是被模式绑住 == | ||
| 261 | |||
| 262 | |||
| 263 | 作为体系设计者或咨询顾问,我通常建议三步用法: | ||
| 264 | |||
| 265 | **1、先识别主模式** | ||
| 266 | |||
| 267 | • 哪一类价值流贡献最大 | ||
| 268 | |||
| 269 | • 哪一类风险最不可接受 | ||
| 270 | |||
| 271 | 主模式决定你的设计基调。 | ||
| 272 | |||
| 273 | |||
| 274 | **2、再识别辅模式** | ||
| 275 | |||
| 276 | • 哪些能力需要不同节奏 | ||
| 277 | |||
| 278 | • 哪些区域允许不同治理 | ||
| 279 | |||
| 280 | 辅模式决定你在哪些地方需要差异化设计。 | ||
| 281 | |||
| 282 | |||
| 283 | **3、最后做裁剪与组合** | ||
| 284 | |||
| 285 | • 在主模式下裁剪实践组合 | ||
| 286 | |||
| 287 | • 在辅模式下放宽或收紧治理 | ||
| 288 | |||
| 289 | • 用持续改进验证是否匹配 | ||
| 290 | |||
| 291 | 这样,模式帮你“少走弯路”,而不是限制你“不能创新”。 | ||
| 292 | |||
| 293 | |||
| 294 | |||
| 295 | == 六、一个常见误区:把价值链模式当成组织结构 == | ||
| 296 | |||
| 297 | |||
| 298 | 价值链模式描述的是“工作如何流动”,不是“人怎么汇报”。 | ||
| 299 | |||
| 300 | • 你可以是职能型组织,但跑产品驱动型模式 | ||
| 301 | |||
| 302 | • 你可以是矩阵结构,但核心是服务交付型模式 | ||
| 303 | |||
| 304 | 当你把模式误用为组织结构,就会出现大量不必要的组织调整,反而伤筋动骨。 | ||
| 305 | |||
| 306 | |||
| 307 | ITIL 第5版引入价值链模式,不是为了给你新的模板,而是为了给你“对照现实的参照系”。 你只要用模式识别主干,用价值流验证真实发生的工作,再用实践组件支撑活动,体系设计就会从“拍脑袋”升级为“有依据的选择”。 | ||
| 308 | |||
| 309 | |||
| 310 | 我是AI+ITIL教练长河achotsao,欢迎添加长河老师微信 achotsao 深入交流,即可第一时间获得ITIL 第5版最新动态及官方特邀中国区大使的深度解析,全网同名。 |