Last modified by superadmin on 2026/02/20, 07:36
From version < 2.1 >
edited by superadmin
on 2026/02/04, 16:36
To version < 4.1
edited by superadmin
on 2026/02/20, 07:36
<
Change comment: There is no comment for this version

Summary

Details

Icon Page properties
Content
... ... @@ -3,51 +3,64 @@
3 3  
4 4  
5 5  (% style="text-align:center" %)
6 -[[image:11.png]]
6 +[[image:11.png||height="304" width="501"]]
7 7  
8 8  
9 -如果设计阶段不把体验与治理做进去，后面就只能用事故和返工补。很多组织在谈“设计”时，第一反应是 UI、交互、原型、需求评审，似乎设计就是“把功能画出来”。但你如果负责过端到端交付，你一定知道：真正昂贵的不是把功能做出来，而是上线后才发现体验断点、控制点缺失、证据链断裂、数据口径不一致，然后用一轮又一轮返工去补。
9 +如果设计阶段不把体验与治理做进去，后面就只能用事故和返工补。 很多组织在谈“设计”时，第一反应是 UI、交互、原型、需求评审，似乎设计就是“把功能画出来”。 但你如果负责过端到端交付，你一定知道：真正昂贵的不是把功能做出来，而是上线后才发现体验断点、控制点缺失、证据链断裂、数据口径不一致，然后用一轮又一轮返工去补。
10 10  
11 -ITIL v5 把 Design（设计）放在 Discover（发现）之后，并把它明确纳入产品与服务生命周期，是在提醒你：设计的对象不是单一功能，而是端到端的服务旅程与价值流。更重要的是，设计不只设计“用户看到什么”，还要设计“系统如何可控、如何可运维、如何可审计、如何可持续改进”。你在设计阶段不做这些，后面再做就不是设计，是救火。
12 12  
12 +ITIL v5 把 Design（设计）放在 Discover（发现）之后，并把它明确纳入产品与服务生命周期，是在提醒你：设计的对象不是单一功能，而是端到端的服务旅程与价值流。 更重要的是，设计不只设计“用户看到什么”，还要设计“系统如何可控、如何可运维、如何可审计、如何可持续改进”。 你在设计阶段不做这些，后面再做就不是设计，是救火。
13 +
14 +
13 13  所以这一篇我们聚焦一个核心主题：以人为中心如何落到 ITIL 第5版的设计语境里，以及作为产品、体验、架构负责人，你在设计阶段到底该产出什么，才能让后续 Acquire、Build、Transition、Operate、Deliver、Support 走直路而不是绕路。
14 14  
15 15  
18 +
16 16  == 一、更新内容概述：六个要点如何重塑“设计”这件事 ==
17 17  
21 +
18 18  我们先回顾一下 ITIL 第5版的核心更新内容。我会用“设计阶段必须承担的新责任”来解释六个要点对 Design 的影响。
19 19  
20 20  **1、定位升级：数字化产品和服务管理**
21 21  
22 -设计不再是“项目交付前的一道工序”，而是数字化产品和服务管理的一部分。你要设计的是可持续运营的产品与服务，而不是一次性交付物。
26 +设计不再是“项目交付前的一道工序”，而是数字化产品和服务管理的一部分。 你要设计的是可持续运营的产品与服务，而不是一次性交付物。
23 23  
28 +
24 24  **2、生命周期模型升级：八个活动覆盖从发现到支持**
25 25  
26 -Design 是后续活动对齐的关键。设计阶段输出的验收准则、度量方案、控制点与责任分配，决定后续活动能否协同。
31 +Design 是后续活动对齐的关键。 设计阶段输出的验收准则、度量方案、控制点与责任分配，决定后续活动能否协同。
27 27  
33 +
28 28  **3、人工智能进入方法论核心**
29 29  
30 30  当 AI 参与服务台、知识管理、自动化编排时，设计必须把风险边界、人工确认点、证据链与可审计性设计进去，否则上线后治理会失效。
31 31  
38 +
32 32  **4、指导原则更强调取舍：尤其是优化和自动化**
33 33  
34 -设计阶段就要做取舍：哪些环节值得自动化，哪些必须保留人工确认；哪些体验提升是关键触点，哪些是可延后优化。取舍不在设计阶段做，后面会被时间线逼着做，结果往往更糟。
41 +设计阶段就要做取舍：哪些环节值得自动化，哪些必须保留人工确认；哪些体验提升是关键触点，哪些是可延后优化。 取舍不在设计阶段做，后面会被时间线逼着做，结果往往更糟。
35 35  
43 +
36 36  **5、实践从清单走向组件库：强调适用性与可裁剪**
37 37  
38 -设计阶段要考虑你需要哪些能力组件来支撑方案：知识管理、配置记录、度量与报告、事件管理、变更实施等。你要设计的是可裁剪的方案，而不是一刀切模板。
46 +设计阶段要考虑你需要哪些能力组件来支撑方案：知识管理、配置记录、度量与报告、事件管理、变更实施等。 你要设计的是可裁剪的方案，而不是一刀切模板。
39 39  
48 +
40 40  **6、持续改进的对象扩大**
41 41  
42 -设计不只是为上线服务，也要为持续改进服务。你必须设计反馈回路：哪些数据会被采集、如何分析、如何触发改进举措、如何验证效果。
51 +设计不只是为上线服务，也要为持续改进服务。 你必须设计反馈回路：哪些数据会被采集、如何分析、如何触发改进举措、如何验证效果。
43 43  
53 +
44 44  你会发现，ITIL 第5版对 Design 的要求更像“端到端方案设计”，而不是“界面与流程设计”。
45 45  
46 46  
57 +
47 47  == 二、以人为中心到底指什么：不是迎合需求，而是设计一段可交付、可感知、可持续的体验 ==
48 48  
49 -“以人为中心”最容易被误解成一句温柔的口号：多问问用户、多做做调研、多画画旅程图。它当然包含这些，但 ITIL 第5版的语境更强调：以人为中心要能落到交付与运营上，否则就是漂亮的故事。
50 50  
61 +“以人为中心”最容易被误解成一句温柔的口号：多问问用户、多做做调研、多画画旅程图。 它当然包含这些，但 ITIL 第5版的语境更强调：以人为中心要能落到交付与运营上，否则就是漂亮的故事。
62 +
63 +
51 51  你可以把以人为中心拆成三层含义：
52 52  
53 53  **1、以人的目标为中心：人要完成什么任务**
... ... @@ -58,6 +58,7 @@
58 58  
59 59  • 他们最怕的失败是什么
60 60  
74 +
61 61  **2、以人的成本为中心：人在旅程里付出了什么代价**
62 62  
63 63  • 等待时间、重复沟通、被迫升级
... ... @@ -66,6 +66,7 @@
66 66  
67 67  • 需要理解复杂规则或术语
68 68  
83 +
69 69  **3、以人的信任为中心：系统是否可靠、透明、可预期**
70 70  
71 71  • 发生问题时是否容易求助
... ... @@ -76,13 +76,16 @@
76 76  
77 77  信任一旦被破坏，体验再美也无效。
78 78  
79 -你会发现，以人为中心并不排斥治理与控制点。恰恰相反：可靠、透明、可预期，本身就是体验的一部分。设计阶段不把这些做进去，体验一定会在关键时刻崩塌。
80 80  
95 +你会发现，以人为中心并不排斥治理与控制点。 恰恰相反：可靠、透明、可预期，本身就是体验的一部分。 设计阶段不把这些做进去，体验一定会在关键时刻崩塌。
81 81  
97 +
98 +
82 82  == 三、Design 的对象是什么：服务旅程的关键触点 + 价值流的关键活动 ==
83 83  
84 -如果你把设计对象理解成“功能列表”，你会自然走向局部最优：每个功能都不错，但端到端体验仍然破碎。ITIL 第5版更强调两类对象：
85 85  
102 +如果你把设计对象理解成“功能列表”，你会自然走向局部最优：每个功能都不错，但端到端体验仍然破碎。 ITIL 第5版更强调两类对象：
103 +
86 86  **1、服务旅程的关键触点**
87 87  
88 88  • 用户在哪些接触点形成体验印象
... ... @@ -91,6 +91,7 @@
91 91  
92 92  • 哪些触点一旦失败就会引发投诉或升级
93 93  
112 +
94 94  **2、价值流的关键活动与交接处**
95 95  
96 96  • 哪些活动决定周期时间
... ... @@ -102,10 +102,12 @@
102 102  当你用这两类对象做设计，你会发现设计讨论会更“落地”：不再是做不做某个功能，而是这个触点的目标是什么、这段旅程如何被支撑、这条价值流如何更顺畅。
103 103  
104 104  
124 +
105 105  == 四、设计阶段必须产出的六类内容：让后续活动能跑起来 ==
106 106  
107 -下面这部分是给方案负责人最实用的清单，但我会刻意避免把它写成“模板要求”，而是把它写成你在设计阶段必须解决的六个问题。每个问题对应一种产出。
108 108  
128 +下面这部分是给方案负责人最实用的清单，但我会刻意避免把它写成“模板要求”，而是把它写成你在设计阶段必须解决的六个问题。 每个问题对应一种产出。
129 +
109 109  **1、体验与服务旅程：用户怎么走，在哪些点会卡**
110 110  
111 111  • 服务旅程描述与关键触点定义
... ... @@ -114,14 +114,16 @@
114 114  
115 115  • 体验相关验收准则：满意度、一次解决率、升级次数等
116 116  
138 +
117 117  **2、设计规范与原型：方案长什么样，交付物怎么验收**
118 118  
119 -• 设计规范 (design specification)：交互、信息架构、可用性要求
141 +• 设计规范（设计规范）：交互、信息架构、可用性要求
120 120  
121 121  • 原型与关键场景演示
122 122  
123 123  • 验收准则：做到什么算完成，而不是做了什么算完成
124 124  
147 +
125 125  **3、风险边界与控制点：哪些必须人工确认，哪些可自动化**
126 126  
127 127  • 高风险决策点清单：影响范围、不可逆操作、合规与隐私
... ... @@ -130,6 +130,7 @@
130 130  
131 131  • 自动化安全阈值与失败恢复策略
132 132  
156 +
133 133  **4、数据与证据链：数据质量门槛在哪里，可审计性怎么保证**
134 134  
135 135  • 最小数据集：关键字段与口径统一
... ... @@ -138,6 +138,7 @@
138 138  
139 139  • 可审计性要求：关键决策能否回溯，依据是否可解释
140 140  
165 +
141 141  **5、可观测性与运维设计：上线后怎么监控、怎么定位、怎么恢复**
142 142  
143 143  • 关键指标与仪表板设计：周期时间、错误率、升级率、返工率
... ... @@ -146,6 +146,7 @@
146 146  
147 147  • 恢复策略：回滚、降级、灾难恢复计划的触发条件
148 148  
174 +
149 149  **6、责任与协作方式：谁负责端到端结果**
150 150  
151 151  • 角色与责任分配：谁负责交付、谁负责运营、谁负责支持
... ... @@ -157,10 +157,12 @@
157 157  如果你把这六类产出做扎实，后续 Acquire、Build、Transition 的争议会明显减少，因为大多数争议其实是设计阶段没有把边界说清。
158 158  
159 159  
186 +
160 160  == 五、设计阶段最常见的三个坑：看起来很忙，实际上在为返工铺路 ==
161 161  
162 -我见过太多设计阶段“很热闹”的项目，最后还是失败。原因往往不是团队不努力，而是踩了三个典型坑。
163 163  
190 +我见过太多设计阶段“很热闹”的项目，最后还是失败。 原因往往不是团队不努力，而是踩了三个典型坑。
191 +
164 164  **1、只设计正向流程，不设计失败路径**
165 165  
166 166  • 不考虑异常、错误、告警与升级
... ... @@ -169,6 +169,7 @@
169 169  
170 170  结果是：上线后第一次事故就暴露体系缺口。
171 171  
200 +
172 172  **2、只设计功能，不设计数据**
173 173  
174 174  • 字段定义不清、口径不统一
... ... @@ -179,6 +179,7 @@
179 179  
180 180  结果是：AI 与自动化无法闭环，度量与报告失真。
181 181  
211 +
182 182  **3、只设计交付物，不设计责任**
183 183  
184 184  • 角色边界模糊
... ... @@ -189,13 +189,17 @@
189 189  
190 190  结果是：问题发生时没有人能快速拍板，恢复慢，争议多。
191 191  
222 +
192 192  你会发现，这三个坑都不是“设计能力不足”，而是“设计对象选错”：把设计当成了交互与功能，而不是端到端可运营的方案。
193 193  
194 194  
226 +
195 195  == 六、把设计思维真正放进 ITIL v5：用“假设—验证—迭代”驱动设计，而不是用“拍板—交付”驱动 ==
196 196  
197 -ITIL 第5版强调持续改进与反馈回路，设计阶段就应该体现这种精神。你可以把设计当作一组假设的验证，而不是一次拍板。
198 198  
230 +ITIL 第5版强调持续改进与反馈回路，设计阶段就应该体现这种精神。 你可以把设计当作一组假设的验证，而不是一次拍板。
231 +
232 +
199 199  我建议你用三步走：
200 200  
201 201  • 把关键触点的目标写成假设：例如用户满意度提升、周期时间缩短
... ... @@ -204,11 +204,11 @@
204 204  
205 205  • 根据反馈迭代设计规范与控制点：把验证结果写回验收准则与度量方案
206 206  
207 -这样做的好处是：你不会把“漂亮方案”当成真理，而会把“可验证方案”当成目标。对复杂系统而言，后者更可靠。
241 +这样做的好处是：你不会把“漂亮方案”当成真理，而会把“可验证方案”当成目标。 对复杂系统而言，后者更可靠。
208 208  
209 209  
210 -Design 在 ITIL 第5版里不是“画界面、写流程”，而是把体验、治理、数据与可运维性一起设计进端到端方案里。你只要抓住服务旅程关键触点与价值流关键活动，把验收准则、控制点、证据链、可观测性与责任分配在设计阶段做扎实，后续活动就会少走弯路，组织也更容易把改进做成可持续能力。
244 +Design 在 ITIL 第5版里不是“画界面、写流程”，而是把体验、治理、数据与可运维性一起设计进端到端方案里。 你只要抓住服务旅程关键触点与价值流关键活动，把验收准则、控制点、证据链、可观测性与责任分配在设计阶段做扎实，后续活动就会少走弯路，组织也更容易把改进做成可持续能力。
211 211  
212 212  
213 213  
214 -我是AI+ITIL教练长河achotsao，欢迎交流。关注我，即可第一时间获得ITIL 第5版最新动态及官方特邀中国区大使的深度解析，全网同名。
248 +我是AI+ITIL教练长河achotsao，欢迎添加长河老师微信 achotsao 深入交流，即可第一时间获得ITIL 第5版最新动态及官方特邀中国区大使的深度解析，全网同名。
深圳市艾拓先锋企业管理咨询有限公司