Last modified by superadmin on 2026/02/20, 07:21
From version < 7.1
edited by superadmin
on 2026/02/20, 07:21
To version 1.1 >
edited by superadmin
on 2026/02/10, 20:36
Change comment: There is no comment for this version

Summary

Details

Icon Page properties
Content
... ... @@ -3,13 +3,13 @@
3 3  
4 4  2026年1月29日，PeopleCert正式发布了ITIL 第5版。作为ITIL官方中国区产品大使，我将会推出系列文章帮大家解读ITIL 第5版到底有哪些重大的更新。
5 5  
6 -(% style="text-align:center" %)
7 -[[image:1.png||height="275" width="454"]]
6 +[[image:https://my.feishu.cn/space/api/box/stream/download/asynccode/?code=OWIyMjk0NjFjNTMxZWI2NjRmNmMyNDYwZmY2Y2UzOTVfNUJjT0ZKejRWckUyUzJQY0NWUDZFcGpzOERyTWg2N0xfVG9rZW46SjJaU2J5Wnpkb0RkUjR4U0NPNWNXQVRCbkZlXzE3NzA3MjY5NDk6MTc3MDczMDU0OV9WNA||height="273" width="450"]]
8 8  
9 -ITIL v5（即ITIL 第5版）已经正式发布。 很多人第一次看到生命周期的八个阶段里把Discover（发现）放在第一步，会下意识觉得：这不就是“需求分析”的换皮吗？但做过产品与交付的人都知道，组织最常见的浪费，恰恰发生在“需求看起来很明确”的时候——你以为你在高效推进，其实你在把未经验证的假设快速变成系统欠账。
8 +ITIL v5（即ITIL 第5版）已经正式发布。很多人第一次看到生命周期的八个阶段里把Discover（发现）放在第一步，会下意识觉得：这不就是“需求分析”的换皮吗？但做过产品与交付的人都知道，组织最常见的浪费，恰恰发生在“需求看起来很明确”的时候——你以为你在高效推进，其实你在把未经验证的假设快速变成系统欠账。
10 10  
10 +[[image:https://my.feishu.cn/space/api/box/stream/download/asynccode/?code=MDgwMzUwZWJlNmUyNGI0Yjc4MzgxZTNlNmZhNDk4NjhfV2l3YzNrcHpFU0lkUTVzdkh2OE1RMmJ3a2lGZUl3bzhfVG9rZW46SDVaVGJlWGd4b3F4azV4SkpDemNyZlpDbkRnXzE3NzA3MjY5NDk6MTc3MDczMDU0OV9WNA||height="130" width="558"]]
11 11  
12 -所谓伪高效，就是把“收需求”当成起点：业务说要什么，团队赶紧写方案、排期、开发、上线。 上线之后才发现：
12 +所谓伪高效，就是把“收需求”当成起点：业务说要什么，团队赶紧写方案、排期、开发、上线。上线之后才发现：
13 13  
14 14  • 需求描述的是手段，而不是目的
15 15  
... ... @@ -21,63 +21,45 @@
21 21  
22 22  • 支持与运营压力激增，体验摩擦被放大
23 23  
24 +这类问题不是努力不够，而是起点错了。Discover被放到第一位，就是ITIL 第5版在提醒组织：价值交付的起点不是“需求”，而是“机会”。机会意味着你要先看见问题的本质，先识别价值在哪，先把不确定性压下去，然后再进入设计与构建。否则你会把团队的能力消耗在无效建设上，最后用事故、返工与抱怨来支付利息。
24 24  
25 -这类问题不是努力不够，而是起点错了。 Discover被放到第一位，就是ITIL 第5版在提醒组织：价值交付的起点不是“需求”，而是“机会”。 机会意味着你要先看见问题的本质，先识别价值在哪，先把不确定性压下去，然后再进入设计与构建。 否则你会把团队的能力消耗在无效建设上，最后用事故、返工与抱怨来支付利息。
26 +Discover不是更慢，而是更稳;不是更玄，而是更可控。它的目标只有一个：让后面的每一步都更接近真实价值。
26 26  
27 -
28 -Discover不是更慢，而是更稳; 不是更玄，而是更可控。 它的目标只有一个：让后面的每一步都更接近真实价值。
29 -
30 -
31 -
32 -(% style="text-align:center" %)
33 -[[image:3.jpg||height="356" width="690"]]
34 -
35 -(% class="wikigeneratedid" %)
36 -=== ===
37 -
38 38  === 二、ITIL 第5版升级内容全景 ===
39 39  
40 -
41 41  要理解Discover为什么关键，必须先把ITIL 第5版的更新内容概述完整交代。因为Discover不是单点技巧，它被放在第一位，是整个框架重心迁移的一部分。
42 42  
43 -
44 44  ==== 1）定位升级：从服务管理走向数字产品与服务管理 ====
45 45  
46 -ITIL 第5版把管理对象扩展为数字产品与服务的整体，强调端到端价值交付。Discover之所以重要，是因为数字产品与服务的价值往往来自对机会的把握，而不是对需求清单的完成。 你需要先识别“要创造的结果”，再决定“要交付的形态”。
34 +ITIL 第5版把管理对象扩展为数字产品与服务的整体，强调端到端价值交付。Discover之所以重要，是因为数字产品与服务的价值往往来自对机会的把握，而不是对需求清单的完成。你需要先识别“要创造的结果”，再决定“要交付的形态”。
47 47  
48 -
49 49  ==== 2）生命周期模型升级：八个阶段覆盖从想法到退役 ====
50 50  
51 -ITIL 第5版提出生命周期八个阶段：Discover、Design、Acquire、Build、Transition、Operate、Deliver、Support。Discover位于第一步，意味着框架要求组织把洞察与价值定义做成正式阶段，而不是靠经验拍脑袋。 它要给后续阶段提供清晰输入，减少返工与风险集中爆发。
38 +ITIL 第5版提出生命周期八个阶段：Discover、Design、Acquire、Build、Transition、Operate、Deliver、Support。Discover位于第一步，意味着框架要求组织把洞察与价值定义做成正式阶段，而不是靠经验拍脑袋。它要给后续阶段提供清晰输入，减少返工与风险集中爆发。
52 52  
53 -
54 54  ==== 3）体验进入核心：Discover阶段决定体验上限 ====
55 55  
56 -体验进入核心后，Discover不再只是“业务访谈”，它必须看到用户旅程（service journey，服务旅程）的摩擦点，识别触点（touchpoint，接触点）上的不确定性与绕路。 很多体验问题不是支持阶段解决不了，而是上游从一开始就没有把旅程看清。
42 +体验进入核心后，Discover不再只是“业务访谈”，它必须看到用户旅程（service journey，服务旅程）的摩擦点，识别触点（touchpoint，接触点）上的不确定性与绕路。很多体验问题不是支持阶段解决不了，而是上游从一开始就没有把旅程看清。
57 57  
58 -
59 59  ==== 4）AI进入框架中心：没有高质量输入，AI与自动化只会放大偏差 ====
60 60  
61 61  AI越深入，数据质量门槛越高。Discover阶段如果不能定义清晰的验收标准（acceptance criteria，验收标准）、口径与证据链，后续自动化与智能化就无法稳定落地，风险边界也无法治理。
62 62  
63 -
64 64  ==== 5）实践使用方式变化：从清单背诵走向情境化组合 ====
65 65  
66 66  Discover并不属于某一个“流程实践”的独角戏，它需要多实践协同：业务分析、关系管理、度量与报告、风险管理、知识管理等围绕价值流组合，形成可持续的洞察与决策机制。
67 67  
68 -
69 69  这五点连起来，你会发现Discover被放在第一位，是因为ITIL 第5版要组织先把价值与不确定性管理好，再去谈速度与规模。
70 70  
71 -
72 72  === 三、Discover到底在做什么：不是收集“想要”，而是识别“值得做” ===
73 73  
74 -
75 75  把Discover做成“收需求”，最大的风险是：你会把业务表达的解决方案当成问题本身。真正的Discover要完成三件事：找机会、验假设、定价值。
76 76  
58 +[[image:https://my.feishu.cn/space/api/box/stream/download/asynccode/?code=NTQzYjFiMjc4MTdkMGYzNWNhOTU1YzAzZDI5ODI1ZjZfZUJzeEJHNGtzQXZpMXlIRERrRHpPUHhrbFMycmlJdWFfVG9rZW46TFFxUGJaRFRJb1NyeEF4UXlyNmM1TXlvblZiXzE3NzA3MjY5NDk6MTc3MDczMDU0OV9WNA||height="198" width="450"]]
77 77  
78 78  ==== 1）找机会：把问题从局部症状拉回端到端旅程 ====
79 79  
80 -机会往往藏在旅程断点里，而不是藏在某个部门的抱怨里。 Discover要做的是把问题放回端到端价值流，看清摩擦在哪里。
62 +机会往往藏在旅程断点里，而不是藏在某个部门的抱怨里。Discover要做的是把问题放回端到端价值流，看清摩擦在哪里。
81 81  
82 82  常见机会识别角度包括：
83 83  
... ... @@ -93,15 +93,13 @@
93 93  
94 94  • **风险集中**：事故与投诉最常发生在哪段链路
95 95  
96 -这一步的价值是：把“想要一个功能”变成“要消除一个摩擦”，把“想上线一个系统”变成“要缩短一个周期时间”。 机会一旦清晰，解决方案才有可能做对。
78 +这一步的价值是：把“想要一个功能”变成“要消除一个摩擦”，把“想上线一个系统”变成“要缩短一个周期时间”。机会一旦清晰，解决方案才有可能做对。
97 97  
98 -
99 99  ==== 2）验假设：把“我觉得”变成“我能证明” ====
100 100  
101 -需求往往带着假设：做了A就会带来B。 但如果不验证，组织就会把假设当事实，把不确定性推给后面阶段。 Discover要做的是把关键假设找出来，并设计验证方式。
82 +需求往往带着假设：做了A就会带来B。但如果不验证，组织就会把假设当事实，把不确定性推给后面阶段。Discover要做的是把关键假设找出来，并设计验证方式。
102 102  
103 -(% style="text-align:center" %)
104 -[[image:4.jpg||height="373" width="485"]]
84 +[[image:https://my.feishu.cn/space/api/box/stream/download/asynccode/?code=YjcyMTgwMDEwZTA5NWM1ODZmMmI4YjY3YTgzYmZhMDZfMnNlT1pQQXZxNnRZdEpINWRpMmtza0hUWENPME1xSDlfVG9rZW46R1ZkeWJBVzFHb21QVkV4c2xNdmM4dURkbldlXzE3NzA3MjY5NDk6MTc3MDczMDU0OV9WNA||height="208" width="403"]]
105 105  
106 106  常见关键假设包括：
107 107  
... ... @@ -115,12 +115,11 @@
115 115  
116 116  • 数据能支撑度量与自动化，还是口径混乱
117 117  
118 -验证不一定很重。 很多时候，一个小范围试点、一个可运行原型（prototype，原型）、一段影子流程，就能把假设验证掉一半。Discover的目的不是把一切确定，而是把最危险的不确定性提前暴露。
98 +验证不一定很重。很多时候，一个小范围试点、一个可运行原型（prototype，原型）、一段影子流程，就能把假设验证掉一半。Discover的目的不是把一切确定，而是把最危险的不确定性提前暴露。
119 119  
120 -
121 121  ==== 3）定价值：把“做了什么”换成“产生什么结果” ====
122 122  
123 -Discover阶段要把价值定义成“结果”，而不是“功能列表”。 结果需要可衡量，否则后续就无法判断是否成功。
102 +Discover阶段要把价值定义成“结果”，而不是“功能列表”。结果需要可衡量，否则后续就无法判断是否成功。
124 124  
125 125  结果可以从三类维度定义：
126 126  
... ... @@ -138,13 +138,11 @@
138 138  
139 139  当价值以结果形式定义，团队的讨论会变得更清晰：不是争论要不要做某个功能，而是讨论哪种方式更能达成结果。
140 140  
141 -
142 142  === 四、Discover的核心产出：四个交付物，决定后面七步会不会返工 ===
143 143  
122 +Discover不是讨论会，它必须产生可用交付物。否则它就会被贴上“空谈”的标签。更实用的做法，是把Discover的核心产出收敛到四类交付物，每一类都能直接喂给后续阶段。
144 144  
145 -Discover不是讨论会，它必须产生可用交付物。 否则它就会被贴上“空谈”的标签。 更实用的做法，是把Discover的核心产出收敛到四类交付物，每一类都能直接喂给后续阶段。
146 146  
147 -
148 148  ==== 1）机会陈述：问题是什么，机会在哪里，为什么现在做 ====
149 149  
150 150  机会陈述不需要长，但要硬：
... ... @@ -157,10 +157,9 @@
157 157  
158 158  • 为什么现在值得做（例如业务窗口期、合规要求、客户体验压力）
159 159  
160 -
161 161  ==== 2）价值假设与验证计划：要验证什么，用什么方式验证 ====
162 162  
163 -这部分是Discover的灵魂。 建议明确：
139 +这部分是Discover的灵魂。建议明确：
164 164  
165 165  • 关键假设清单
166 166  
... ... @@ -174,10 +174,9 @@
174 174  
175 175  有了验证计划，后续就不会把“未知”带着跑。
176 176  
177 -
178 178  ==== 3）验收标准：什么算成功，怎么验证，谁来确认 ====
179 179  
180 -验收标准（acceptance criteria，验收标准）不是测试团队的事情，它是端到端协作的共同语言。 建议包括：
155 +验收标准（acceptance criteria，验收标准）不是测试团队的事情，它是端到端协作的共同语言。建议包括：
181 181  
182 182  • 结果性指标与目标值
183 183  
... ... @@ -189,7 +189,6 @@
189 189  
190 190  验收标准越清晰，后面返工越少。
191 191  
192 -
193 193  ==== 4）最小范围与路线图：先做什么，后做什么，如何扩展 ====
194 194  
195 195  Discover阶段要给出最小可行的路径，而不是一次性大而全：
... ... @@ -204,16 +204,13 @@
204 204  
205 205  这四类产出一旦齐，Discover就不再是“讨论”，而是“把不确定性压到可控范围内的决策”。
206 206  
207 -
208 208  === 五、Discover怎么做得稳：一套可直接照做的动作集 ===
209 209  
183 +下面给出一套更贴近现场的Discover动作集。它不追求完美，但足够把方向拉正，把风险压下去。
210 210  
211 -下面给出一套更贴近现场的Discover动作集。 它不追求完美，但足够把方向拉正，把风险压下去。
212 -
213 -
214 214  ==== 动作一：从一条旅程开始，而不是从一份需求开始 ====
215 215  
216 -先选定一条端到端旅程，把触点串起来：谁发起、谁处理、谁交接、谁验证、谁受影响。 重点找摩擦点与绕路点。
187 +先选定一条端到端旅程，把触点串起来：谁发起、谁处理、谁交接、谁验证、谁受影响。重点找摩擦点与绕路点。
217 217  
218 218  可用问题清单：
219 219  
... ... @@ -232,7 +232,7 @@
232 232  
233 233  ==== 动作二：把关键假设写在桌面上 ====
234 234  
235 -假设不写出来，就会被默认当事实。 建议把假设按三类拆开：
206 +假设不写出来，就会被默认当事实。建议把假设按三类拆开：
236 236  
237 237  • 价值假设：做了就会带来什么收益
238 238  
... ... @@ -240,7 +240,6 @@
240 240  
241 241  • 风险假设：可能翻车在哪里，边界怎么定
242 242  
243 -
244 244  ==== 动作三：设计最小验证，把“拍脑袋”变成“拿证据” ====
245 245  
246 246  验证方式不必复杂，但要能快速给方向：
... ... @@ -257,10 +257,9 @@
257 257  
258 258  关键是把验证结果能对齐到验收标准，让后续决策可追溯。
259 259  
260 -
261 261  ==== 动作四：提前把运营与支持拉进来，避免欠账 ====
262 262  
263 -很多项目失败不是做不出来，而是做出来后没人接得住。 Discover阶段就要问：
232 +很多项目失败不是做不出来，而是做出来后没人接得住。Discover阶段就要问：
264 264  
265 265  • 运营需要什么可观测性与手册
266 266  
... ... @@ -275,28 +275,24 @@
275 275  
276 276  === 六、最常见的三种坑：Discover做不好，后面七步会加倍还债 ===
277 277  
278 -
279 279  最后点三种常见坑，很多团队都踩过。
280 280  
281 281  ==== 1）把Discover当需求收集会 ====
282 282  
283 -需求越收越多，方向越走越散。 Discover的目标不是把愿望装满，而是把机会与结果钉住，把不确定性压下去。
251 +需求越收越多，方向越走越散。Discover的目标不是把愿望装满，而是把机会与结果钉住，把不确定性压下去。
284 284  
285 -
286 286  ==== 2）没有验收标准，导致“做完了但没法证明” ====
287 287  
288 -没有验收标准，项目就只能靠感觉验收，返工与扯皮不可避免。 验收标准必须在Discover阶段定下来，并能被验证。
255 +没有验收标准，项目就只能靠感觉验收，返工与扯皮不可避免。验收标准必须在Discover阶段定下来，并能被验证。
289 289  
290 -
291 291  ==== 3）不把运营与支持纳入早期决策，导致欠账滚到后期爆炸 ====
292 292  
293 -最昂贵的欠账，往往来自上游没想清楚的边界：日志不全、手册缺失、发布说明不清、知识无法回流、数据口径不一致。 Discover阶段不处理，后面只能用救火来偿还。
259 +最昂贵的欠账，往往来自上游没想清楚的边界：日志不全、手册缺失、发布说明不清、知识无法回流、数据口径不一致。Discover阶段不处理，后面只能用救火来偿还。
294 294  
261 +Discover不是为了写漂亮文档，而是为了减少返工、减少事故、减少体验摩擦。它看起来慢一点，但能让整体更快。
295 295  
296 -Discover不是为了写漂亮文档，而是为了减少返工、减少事故、减少体验摩擦。 它看起来慢一点，但能让整体更快。
297 297  
264 +ITIL v5把Discover放在生命周期第一步，是ITIL 第5版对“伪高效”的纠偏：Discover不是收需求，而是围绕端到端旅程识别机会、把关键假设摆上桌面并用最小验证拿到证据，再用验收标准把结果定义清楚、把不确定性压到可控范围内，同时提前把运营与支持的承接条件纳入决策;当你把这一步做扎实，后面七个阶段才不会靠返工与救火来完成所谓的交付。
298 298  
299 -ITIL v5把Discover放在生命周期第一步，是ITIL 第5版对“伪高效”的纠偏：Discover不是收需求，而是围绕端到端旅程识别机会、把关键假设摆上桌面并用最小验证拿到证据，再用验收标准把结果定义清楚、把不确定性压到可控范围内，同时提前把运营与支持的承接条件纳入决策; 当你把这一步做扎实，后面七个阶段才不会靠返工与救火来完成所谓的交付。
300 300  
301 -
302 -欢迎加长河老师微信achotsao，深入交流ITIL 第5版最新资讯。
267 +我是AI+ITIL教练长河achotsao，欢迎+V：achotsao交流，即可第一时间获得ITIL 第5版最新动态及官方特邀中国区大使的深度解析，全网同名。
Icon 1.png
Author
... ... @@ -1,1 +1,0 @@
1 -XWiki.superadmin
Size
... ... @@ -1,1 +1,0 @@
1 -335.1 KB
Content Icon
Icon 3.jpg
Author
... ... @@ -1,1 +1,0 @@
1 -XWiki.superadmin
Size
... ... @@ -1,1 +1,0 @@
1 -61.8 KB
Content Icon
Icon 4.jpg
Author
... ... @@ -1,1 +1,0 @@
1 -XWiki.superadmin
Size
... ... @@ -1,1 +1,0 @@
1 -36.6 KB
Content Icon
深圳市艾拓先锋企业管理咨询有限公司