Wiki source code of 从 SLA 到体验:为什么 ITIL第5版把体验放到核心位置
Last modified by superadmin on 2026/02/21, 07:24
Hide last authors
| author | version | line-number | content |
|---|---|---|---|
| |
3.1 | 1 | 如果你已经接受了一个前提: |
| 2 | **ITIL第5版 中,产品是一种“需要被持续验证的价值假设”。** | ||
| 3 | 那接下来,一个绕不开的问题就会浮现出来:这个价值,是谁来验证的?又是通过什么方式被感知的? | ||
| 4 | |||
| 5 | |||
| 6 | 答案只有一个:**体验(Experience)**。 | ||
| 7 | 这也是为什么,在 ITIL第5版 中,你会看到一个非常明确、也非常“冒险”的表达: | ||
| 8 | **Experience at the Core(体验处于核心位置)** | ||
| 9 | 这不是一句口号,而是 ITIL 在管理逻辑上的一次重心转移。 | ||
| 10 | \\\\ | ||
| 11 | |||
| 12 | (% style="text-align:center" %) | ||
| 13 | [[image:1.png||height="203" width="334"]] | ||
| 14 | |||
| 15 | === | ||
| |
4.1 | 16 | \\\\**一、先承认一件事:SLA 本身并没有错** === |
| |
3.1 | 17 | |
| 18 | |||
| |
4.1 | 19 | \\在进入“体验”之前,我们必须先为 SLA 说一句公道话。 |
| |
3.1 | 20 | \\SLA(服务级别协议)在过去二十多年里,确实解决了一个非常重要的问题: |
| 21 | |||
| 22 | * 让 IT 服务变得可衡量 | ||
| 23 | * 让责任变得可追溯 | ||
| 24 | * 让交付有了最基本的边界 | ||
| 25 | |||
| 26 | 如果没有 SLA,IT 服务管理几乎无法规模化。 | ||
| 27 | \\但问题不在 SLA 本身,而在于 **SLA 能解决的问题,已经不够用了**。 | ||
| 28 | |||
| 29 | === | ||
| |
4.1 | 30 | **二、数字化环境下,SLA 正在系统性失效** === |
| |
3.1 | 31 | |
| 32 | |||
| |
4.1 | 33 | 在 ITIL第5版 所假设的数字化环境中,很多价值特征已经发生了变化: |
| |
3.1 | 34 | |
| 35 | * 服务是跨系统、跨团队、跨供应商组合出来的 | ||
| 36 | * 用户并不关心“哪个系统宕了”,只关心“我能不能把事办完” | ||
| 37 | * 大量交互发生在人与 AI、人机混合流程中 | ||
| 38 | |||
| 39 | |||
| |
4.1 | 40 | 在这种情况下,SLA 开始暴露出它的天然盲区: |
| |
3.1 | 41 | |
| 42 | * 系统可用 ≠ 体验可用 | ||
| 43 | * 响应时间达标 ≠ 用户感知良好 | ||
| 44 | * 服务交付完成 ≠ 价值真正实现 | ||
| 45 | |||
| 46 | |||
| |
4.1 | 47 | 于是你会看到一个非常熟悉的场景:SLA 全绿,但用户仍然不满意。 |
| |
3.1 | 48 | |
| 49 | 这不是运维的问题,而是**管理指标选错了层级**。 | ||
| 50 | |||
| 51 | === | ||
| |
4.1 | 52 | **三、ITIL第5版 的判断:价值只能通过体验被感知** === |
| |
3.1 | 53 | |
| 54 | |||
| |
4.1 | 55 | ITIL第5版 对“体验”的态度,比以往任何版本都要明确。 |
| |
3.1 | 56 | \\它不再把体验当成: |
| 57 | |||
| 58 | * 满意度调查的结果 | ||
| 59 | * 服务改进的参考输入 | ||
| 60 | |||
| 61 | |||
| |
4.1 | 62 | 而是直接指出: |
| |
3.1 | 63 | **价值,必须通过体验才能被用户感知和验证。** |
| 64 | 这句话非常关键。 | ||
| 65 | 因为一旦你接受它,就意味着: | ||
| 66 | |||
| 67 | * 你不能只对“交付结果”负责 | ||
| 68 | * 你必须对“使用过程中的感受和效果”负责 | ||
| 69 | |||
| 70 | 这也是 ITIL第5版 把体验提升到“核心”的根本原因。 | ||
| 71 | |||
| 72 | === | ||
| |
4.1 | 73 | **四、从 SLA 到 XLA:不是换指标,而是换视角** === |
| |
3.1 | 74 | |
| 75 | |||
| |
4.1 | 76 | 很多人在第一次看到 XLA(Experience Level Agreement)时,会产生一个误解:不就是把 SLA 指标换成体验指标吗? |
| |
3.1 | 77 | |
| 78 | |||
| 79 | (% style="text-align:center" %) | ||
| 80 | [[image:142224lzluug2rm42rifwf.jpg.thumb.jpg||height="210" width="634"]] | ||
| 81 | |||
| 82 | 但在 ITIL第5版 的语境中,**XLA 并不是 SLA 的升级版**,而是一个完全不同的管理视角。 | ||
| 83 | \\SLA 关注的是: | ||
| 84 | |||
| 85 | * 我们承诺交付什么 | ||
| 86 | * 是否按约定完成 | ||
| 87 | |||
| 88 | 而 XLA 关注的是: | ||
| 89 | |||
| 90 | * 用户在关键场景中,是否顺利达成目标 | ||
| 91 | * 体验是否支撑了产品的价值假设 | ||
| 92 | |||
| 93 | 换句话说: | ||
| 94 | SLA 衡量“服务表现”, | ||
| 95 | XLA 衡量“价值是否真的发生”。 | ||
| 96 | |||
| 97 | === | ||
| |
4.1 | 98 | **五、为什么说 XLA 必然是“跨职能”的?** === |
| |
3.1 | 99 | |
| 100 | |||
| |
4.1 | 101 | 这也是很多组织在引入 XLA 时最痛苦的地方。 |
| |
3.1 | 102 | 因为体验,从来不属于某一个团队。 |
| 103 | \\一次真实的用户体验,往往同时受制于: | ||
| 104 | |||
| 105 | * 产品设计是否合理 | ||
| 106 | * 流程是否顺畅 | ||
| 107 | * 技术是否稳定 | ||
| 108 | * 支撑是否及时 | ||
| 109 | * 决策是否及时调整 | ||
| 110 | |||
| 111 | |||
| |
4.1 | 112 | 这意味着: |
| |
3.1 | 113 | **你无法通过“某个流程负责人”来对体验负责。** |
| 114 | 而 ITIL第5版 正是通过“产品 + 体验”的组合,把责任重新组织起来: | ||
| 115 | 体验,不再是服务管理的副产品, | ||
| 116 | 而是产品治理必须面对的核心判断依据。 | ||
| 117 | |||
| 118 | === | ||
| |
4.1 | 119 | **六、体验为什么会成为 AI 时代的管理锚点?** === |
| |
3.1 | 120 | |
| 121 | |||
| |
4.1 | 122 | 还有一个非常现实的背景,是 ITIL第5版 没有明说、但处处体现的: |
| |
3.1 | 123 | **AI 正在接管越来越多“可衡量的执行动作”。** |
| 124 | 当自动化、智能决策越来越普遍时,单纯衡量: | ||
| 125 | |||
| 126 | * 响应时间 | ||
| 127 | * 处理效率 | ||
| 128 | * 执行准确率 | ||
| 129 | |||
| 130 | 这些指标的管理价值,反而在下降。 | ||
| 131 | \\而体验,恰恰是 AI 最难“替你判断”的那一层: | ||
| 132 | |||
| 133 | * 用户是否信任系统 | ||
| 134 | * 是否愿意持续使用 | ||
| 135 | * 是否理解并接受结果 | ||
| 136 | |||
| 137 | |||
| |
4.1 | 138 | 这也是为什么,在 ITIL第5版 中: |
| |
3.1 | 139 | 体验,成为连接 **人、产品、AI 与价值**的关键锚点。 |
| 140 | |||
| 141 | === | ||
| |
4.1 | 142 | **七、一个很现实的结论** === |
| |
3.1 | 143 | |
| 144 | |||
| |
4.1 | 145 | ITIL第5版 并不是“否定 SLA”, |
| |
3.1 | 146 | 而是承认了一件事: |
| 147 | **SLA 只能证明你“没有做错”,但体验,才能证明你“做对了”。** | ||
| 148 | 当组织开始以产品为单位思考价值, | ||
| 149 | 就必然要以体验为方式验证价值。 | ||
| 150 | \\这不是趋势问题, | ||
| 151 | 而是逻辑必然。 | ||
| 152 | |||
| 153 | === | ||
| |
4.1 | 154 | **写在最后:你会在哪里最先感受到这个变化?** === |
| |
3.1 | 155 | |
| 156 | |||
| |
4.1 | 157 | 不是在指标报表里, |
| |
3.1 | 158 | 而是在这些时刻: |
| 159 | |||
| 160 | * 你开始讨论“关键用户旅程”,而不是“关键系统” | ||
| 161 | * 你开始为“完成一件事”定义成功,而不是“系统运行正常” | ||
| 162 | * 你开始接受:有些问题,流程没错,但体验就是不好 | ||
| 163 | |||
| 164 | 这,正是 ITIL第5版 想把你带到的管理位置。 | ||
| 165 | \\下一篇,我们会继续往下走: | ||
| 166 | **当体验成为核心,ITIL第5版 是如何重新理解“价值共创”的?** | ||
| 167 | 那将是整个体系中, | ||
| 168 | 最容易被误解、也最值得重新理解的一部分。 | ||
| 169 | \\\\我是AI+ITIL教练长河achotsao,欢迎添加长河老师微信 achotsao 深入交流,即可第一时间获得ITIL 第5版最新动态及官方特邀中国区大使的深度解析,全网同名。 |