Last modified by superadmin on 2026/02/20, 07:06
From version < 5.1
edited by superadmin
on 2026/02/20, 07:06
To version 1.1 >
edited by superadmin
on 2026/02/20, 14:46
Change comment: There is no comment for this version

Summary

Details

Icon Page properties
Content
... ... @@ -1,6 +1,6 @@
1 1  很多组织的服务目录，看起来很“齐全”，点进去却让人头大：
2 2  
3 -一堆名词、几十个分类、各种缩写，用户根本不知道该点哪个。 好不容易选了一个，表单长得像报税，填到一半还要问同事“这个字段怎么写”。 最后用户干脆不走目录了，直接找熟人、直接私聊支持、直接在群里@人。
3 +一堆名词、几十个分类、各种缩写，用户根本不知道该点哪个。好不容易选了一个，表单长得像报税，填到一半还要问同事“这个字段怎么写”。最后用户干脆不走目录了，直接找熟人、直接私聊支持、直接在群里@人。
4 4  
5 5  
6 6  然后支持团队就开始抱怨：“你们为什么不走流程？”
... ... @@ -8,10 +8,10 @@
8 8  用户也开始抱怨：“你们的流程为什么这么难用？”
9 9  
10 10  
11 -这种矛盾很常见，但我想说一句实话：很多服务目录并不是“服务目录”，更像“内部仓库清单”。 它满足了管理的整齐，却没满足用户的顺手。 你把入口做得别扭，用户自然会绕开；用户一绕开，支持就会更乱；支持越乱，你越想加规则，最后就是恶性循环。
11 +这种矛盾很常见，但我想说一句实话：很多服务目录并不是“服务目录”，更像“内部仓库清单”。它满足了管理的整齐，却没满足用户的顺手。你把入口做得别扭，用户自然会绕开；用户一绕开，支持就会更乱；支持越乱，你越想加规则，最后就是恶性循环。
12 12  
13 13  
14 -ITIL 第5版之所以值得你重新看服务目录与服务请求，是因为它把管理对象扩展到数字产品与数字服务，并强调体验优先。 换句话说，第5版很像在提醒你：目录和请求不是后台管理功能，它们就是你的“产品门面”。 门面不好用，再好的后台也救不了。
14 +ITIL 第5版之所以值得你重新看服务目录与服务请求，是因为它把管理对象扩展到数字产品与数字服务，并强调体验优先。换句话说，第5版很像在提醒你：目录和请求不是后台管理功能，它们就是你的“产品门面”。门面不好用，再好的后台也救不了。
15 15  
16 16  
17 17  == 一、为什么目录与请求在第5版里更像“产品化能力” ==
... ... @@ -29,13 +29,13 @@
29 29  
30 30  • AI 与自动化纳入体系，强调能力分层与治理边界
31 31  
32 -服务目录与服务请求落在哪？它们直接影响交付与支持，也影响体验。 更关键的是，它们会把组织的边界、承诺、标准化程度暴露给用户。 目录做得清，用户预期就稳；请求履约做得顺，支持就会轻。
32 +服务目录与服务请求落在哪？它们直接影响交付与支持，也影响体验。更关键的是，它们会把组织的边界、承诺、标准化程度暴露给用户。目录做得清，用户预期就稳；请求履约做得顺，支持就会轻。
33 33  
34 34  
35 35  == 二、服务目录到底是什么：不是清单，是承诺与预期管理 ==
36 36  
37 37  
38 -很多团队做服务目录，思路是“把我们能提供的都列出来”。 这听起来很合理，但用户真正想知道的通常是：
38 +很多团队做服务目录，思路是“把我们能提供的都列出来”。这听起来很合理，但用户真正想知道的通常是：
39 39  
40 40  • 我该找谁
41 41  
... ... @@ -47,11 +47,10 @@
47 47  
48 48  • 出问题怎么办
49 49  
50 -这就是目录真正的价值：它是一份承诺的说明书，也是预期管理的工具。 你目录里如果只写“账号开通、权限申请、VPN申请”，但不写清楚“多长时间、需要什么信息、哪些情况会被拒绝、审批路径是什么”，用户就会自行脑补预期，脑补出来的预期往往比你能做到的更高。 后面体验差、投诉多，其实是预期没管住。
50 +这就是目录真正的价值：它是一份承诺的说明书，也是预期管理的工具。你目录里如果只写“账号开通、权限申请、VPN申请”，但不写清楚“多长时间、需要什么信息、哪些情况会被拒绝、审批路径是什么”，用户就会自行脑补预期，脑补出来的预期往往比你能做到的更高。后面体验差、投诉多，其实是预期没管住。
51 51  
52 52  
53 -(% style="text-align:center" %)
54 -[[image:3.jpg||height="283" width="549"]]
53 +[[image:https://my.feishu.cn/space/api/box/stream/download/asynccode/?code=YmMxYmM4MGZjM2M5YTJmNGNlZmQyZjE2MjJjZmFhNTdfb25rMHFrTHZ5MUltYWhodzRlUGF3bDg2THpMbEc0MzNfVG9rZW46UUxGN2JwWFZwb2R6b0R4U2tVSWNjOUVUbjFkXzE3NzE1Njk5MjA6MTc3MTU3MzUyMF9WNA||height="323" width="627"]]
55 55  
56 56  所以服务目录要做得像产品：信息要让用户一眼看懂，承诺要能兑现，边界要明确。
57 57  
... ... @@ -59,7 +59,7 @@
59 59  == 三、服务请求为什么会变成工单堆：因为你把“标准化履约”做成了“人工处理” ==
60 60  
61 61  
62 -服务请求的本质，是标准化履约。 比如开通账号、申请权限、发放设备、创建项目空间、恢复访问、重置密码。 这些事情如果每次都靠支持人工判断、人工沟通、人工推进，那你越做越累是必然的。
61 +服务请求的本质，是标准化履约。比如开通账号、申请权限、发放设备、创建项目空间、恢复访问、重置密码。这些事情如果每次都靠支持人工判断、人工沟通、人工推进，那你越做越累是必然的。
63 63  
64 64  
65 65  ITIL 第5版强调价值链全生命周期和治理，从请求视角看就是：
... ... @@ -72,42 +72,42 @@
72 72  
73 73  • 请求履约要能被度量和持续改进
74 74  
75 -把请求做顺，支持压力会明显下降；支持压力下降，体验反而会上来。 很多人觉得这矛盾，其实不矛盾——支持最累的时候，体验往往最差。
74 +把请求做顺，支持压力会明显下降；支持压力下降，体验反而会上来。很多人觉得这矛盾，其实不矛盾——支持最累的时候，体验往往最差。
76 76  
77 77  
78 78  == 四、用八个阶段活动把目录与请求做“端到端”：别只在支持端修修补补 ==
79 79  
80 80  
81 -你如果只在支持端优化目录和请求，比如改表单、改分类、加入口，很容易治标不治本。 ITIL 第5版的八个阶段活动给你一个更完整的视角：目录和请求从发现开始就应该被设计。
80 +你如果只在支持端优化目录和请求，比如改表单、改分类、加入口，很容易治标不治本。ITIL 第5版的八个阶段活动给你一个更完整的视角：目录和请求从发现开始就应该被设计。
82 82  
83 83  
84 -(% style="text-align:center" %)
85 -[[image:d4aeb615-48e4-46cf-87ef-1a6687d8fb93.jpg||height="101" width="490"]]
83 +[[image:https://my.feishu.cn/space/api/box/stream/download/asynccode/?code=MjM1MmIyYjMwNjNlZjZjZGQ1YTI1ZGZlOGJhMTYwMGVfVU9MdWZPZk9iaDJBVTA3T0lBUXFwcmprZzlSdVIwakRfVG9rZW46WUNHdmI0aXhsb2tzN2R4bDJIWmNNMFlPblRjXzE3NzE1Njk5MjA6MTc3MTU3MzUyMF9WNA||height="129" width="623"]]
86 86  
87 87  
88 88  1. (((
89 -**发现**：先搞清楚用户为什么来找你 很多目录失败是因为分类按内部组织结构来，而不是按用户目的来。 用户不是来找“基础架构部服务”的，用户是来“快速开通能用的东西”的。 发现阶段要做的是识别用户意图：他们最常要什么、最焦虑什么、最怕填什么、最讨厌等多久。
87 +**发现**：先搞清楚用户为什么来找你 很多目录失败是因为分类按内部组织结构来，而不是按用户目的来。用户不是来找“基础架构部服务”的，用户是来“快速开通能用的东西”的。发现阶段要做的是识别用户意图：他们最常要什么、最焦虑什么、最怕填什么、最讨厌等多久。
90 90  )))
91 91  1. (((
92 92  **设计**：把请求设计成“最小输入、最大确定性” 设计阶段要决定： • 用户必须填哪些信息才能完成履约 • 哪些信息可以自动获取、自动填充 • 哪些审批是必要的，哪些是历史遗留 • 哪些异常情况必须提前告知用户 设计不做好，支持就会在后端反复补信息，来回问用户，体验一定差。
93 93  )))
94 94  1. (((
95 -**获取**：能力与工具要准备好 比如身份系统、审批系统、资产系统、自动化编排能力、知识库、通知通道。 获取阶段如果没准备好能力，支持就只能靠手工和人情推进。
93 +**获取**：能力与工具要准备好 比如身份系统、审批系统、资产系统、自动化编排能力、知识库、通知通道。获取阶段如果没准备好能力，支持就只能靠手工和人情推进。
96 96  )))
97 97  1. (((
98 98  **构建**：把高频请求做成标准流程与自动化 构建阶段不是写流程图，而是把标准件做出来： • 表单字段合理 • 校验规则明确 • 自动化动作可回滚 • 通知与状态更新有节奏
99 99  )))
100 100  1. (((
101 -**转换**：上线前把口径和支持准备好 目录和请求也会变更。 转换阶段要做的事很朴素： • 变更公告与说明 • 已知问题与应对 • 支持话术与升级路径 否则目录一改，用户一头雾水，支持就被打爆。
99 +**转换**：上线前把口径和支持准备好 目录和请求也会变更。转换阶段要做的事很朴素： • 变更公告与说明 • 已知问题与应对 • 支持话术与升级路径 否则目录一改，用户一头雾水，支持就被打爆。
102 102  )))
103 103  1. (((
104 104  **运营与支持**：用数据把目录越做越轻 运营与支持阶段要关注的是： • 哪些请求量最大 • 哪些请求最容易卡住 • 哪些字段经常填错 • 哪些审批最慢 这些就是持续改进的抓手。
105 105  )))
106 106  
105 +
107 107  === 五、目录怎么做才“像产品”：先砍掉一半再说 ===
108 108  
109 109  
110 -服务目录最常见的问题不是不全，而是太全。 太全的本质是：你没有做取舍。 用户一旦需要在几十个选项里做选择，体验就已经输了一半。
109 +服务目录最常见的问题不是不全，而是太全。太全的本质是：你没有做取舍。用户一旦需要在几十个选项里做选择，体验就已经输了一半。
111 111  
112 112  
113 113  我建议你从这几件事入手，效果很快：
... ... @@ -128,7 +128,7 @@
128 128  == 六、请求履约怎么做才“顺”：让用户看到进度，比让他等更重要 ==
129 129  
130 130  
131 -体验差往往发生在等待阶段。 用户不是不能等，他不能接受的是“等得没谱”。 所以请求履约最值钱的改造，往往不是把处理时间从2小时变成1小时，而是把进度透明起来。
130 +体验差往往发生在等待阶段。用户不是不能等，他不能接受的是“等得没谱”。所以请求履约最值钱的改造，往往不是把处理时间从2小时变成1小时，而是把进度透明起来。
132 132  
133 133  
134 134  你可以做得很简单：
... ... @@ -145,17 +145,16 @@
145 145  == 七、AI与自动化怎么用在目录与请求：先做“整理和沟通”，再做“协调” ==
146 146  
147 147  
148 -ITIL 第5版强调AI治理，放到目录与请求场景里，其实非常实用。 但要记住顺序：先把信息一致性和标准化做起来，再谈更深的自动协调。
147 +ITIL 第5版强调AI治理，放到目录与请求场景里，其实非常实用。但要记住顺序：先把信息一致性和标准化做起来，再谈更深的自动协调。
149 149  
150 150  
151 -(% style="text-align:center" %)
152 -[[image:2.jpg||height="282" width="288"]]
150 +[[image:https://my.feishu.cn/space/api/box/stream/download/asynccode/?code=MzNiN2RhNTZlNzNjZjMzYTZkOGEzMTU5YTk1YmJkZjVfWjd3Rll5M3d4TGswSm9mWVQ3QUdicmdTbmJBQVVYS2NfVG9rZW46T0JpeWI3Y2RCb0I1RGZ4dGFneWN5NFgybkdoXzE3NzE1Njk5MjA6MTc3MTU3MzUyMF9WNA||height="498" width="507"]]
153 153  
154 154  更稳的用法包括：
155 155  
156 156  • **整理**：把请求聚类，识别高频与痛点，优化目录结构
157 157  
158 -•** 生成：**生成请求说明的草稿、提示语草稿、知识条目草稿
156 +•** 生成：**生成请求说明的草稿、提示语草稿、知识条目草稿
159 159  
160 160  • **沟通**：生成状态更新文案，提高一致性，但必须审核
161 161  
... ... @@ -172,11 +172,9 @@
172 172  
173 173  • 支持不需要反复补信息
174 174  
175 -你只要把这十个请求做顺，支持压力会明显下降，用户体验也会明显提升。 之后再扩展到Top 20、Top 30，就很自然了。
173 +你只要把这十个请求做顺，支持压力会明显下降，用户体验也会明显提升。之后再扩展到Top 20、Top 30，就很自然了。
176 176  
177 177  
178 178  2026年1月29日，PeopleCert正式发布了ITIL 第5版。作为ITIL官方中国区大使，我将会推出系列文章帮大家解读ITIL 第5版到底有哪些重大的更新。
179 179  
180 -
181 -
182 182  欢迎加长河老师微信achotsao，深入交流ITIL 第5版最新资讯。
Icon 2.jpg
Author
... ... @@ -1,1 +1,0 @@
1 -XWiki.superadmin
Size
... ... @@ -1,1 +1,0 @@
1 -91.0 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 d4aeb615-48e4-46cf-87ef-1a6687d8fb93.jpg
Author
... ... @@ -1,1 +1,0 @@
1 -XWiki.superadmin
Size
... ... @@ -1,1 +1,0 @@
1 -35.4 KB
Content Icon
深圳市艾拓先锋企业管理咨询有限公司