服务价值流该看什么指标？联想 IT 与 ITIL 第 5 版教学心得分享

从流程 KPI 到端到端体验，成熟 IT 团队需要新的观察维度

本系列为ITIL先锋论坛长河老师2026年5月联想ITIL 5内训课程教学心得分享，共五篇，本文为第二篇。

服务价值流如果只画出来，而没有指标，就很容易变成一张漂亮的图。

这次联想 ITIL 5 Foundation 内训课程里，价值流之所以讨论得深入，不只是因为大家理解了概念，而是因为大家开始追问：这条价值流跑起来之后，应该看什么数据？哪些指标能说明端到端价值交付变好了？哪些指标只是在流程内部看起来不错，却不能代表用户体验？这个问题对成熟 IT 组织特别重要。

在流程化管理阶段，每个流程都有自己的 KPI：事件管理看响应时长、恢复时长；变更管理看审批合规、变更成功率；配置管理看数据完整性和准确性；发布和部署管理看实施成功率。这些指标都必要，没有它们流程无法被管理，但用户体验不是按流程分段感知的。用户只会问：我的问题什么时候解决？我的需求现在到哪一步？为什么已经提交很久还没有完成？这就要求我们从端到端价值流角度重新看指标。

在课堂研讨中，大家选择了"非核心业务系统硬件设备更换"作为价值流试点场景。这个场景从事件管理开始，进入变更实施，涉及 IT 资产、配置管理、发布和部署管理，最后回到事件关闭。它跨流程，但风险相对可控，非常适合讨论价值流指标。

如果只看单个流程，每个环节都可能说自己完成得不错。事件团队及时响应，变更团队按规审批，资产信息有人更新，部署也按计划执行。但从端到端角度看，问题可能出在流程之间：事件信息不完整导致变更反复补充，审批等待时间过长，配置更新滞后影响后续确认，部署结果反馈不及时导致事件关闭延迟。这些地方，单流程 KPI 未必能反映出来。所以价值流指标首先要看端到端周期时间——用户从提出事件或需求，到最终被满足，中间总共用了多久。这个总时长比任何一个局部流程时长都更接近用户真实感受。

第二要看等待时间。很多价值损耗不是发生在工作本身，而是发生在等待中：等待审批、等待补充信息、等待资源确认、等待下游接手。这些时间如果不单独标出来，就会被淹没在整体流程里。

第三要看返工和补充信息次数。在跨流程协作中，信息质量非常关键。事件单移交给变更团队时诊断信息是否完整？变更审批需要退回几次？部署前是否发现资产信息不一致？这些反复，既消耗时间，也消耗团队信任。如果价值流看板只显示节点状态，而不记录返工次数，就容易错过改进机会。成熟组织要看的，不只是"走到哪一步"，还要看"为什么来回走"。

第四要看瓶颈节点的健康程度。这里我更愿意借用健康管理里的说法：一个人不是所有指标都要同时最优，而是要找到真正影响整体状态的关键指标。价值流也是一样——不是每个节点都要平均用力优化，而是要看哪几个节点长期积压、长期等待、长期触发补充信息，那些就是价值流里的高风险指标。

第五要看业务侧参与指标。价值流不是 IT 自己的内部通道，很多时候业务审批、业务确认、业务反馈也会影响端到端效率。如果当前瓶颈卡在业务领导审批，业务侧也应该能够看见并主动推动。价值共创不是口号，它需要指标让双方看到各自对旅程的影响。

中午的走廊很安静，午后的阳光把整条通道打得透亮。我作为官方《ITIL 基础第 5 版》中国区翻译组组长、做过 ITSM 落地实践，一路走来有一个感受越来越清晰：ITIL 的价值流理论，最难的不是理解概念，而是让路径产生管理作用。要做到这一点，就必须有指标。端到端周期时间、等待时间、返工次数、节点积压、信息完整度、业务侧参与度、用户满意度——这些指标组合起来，才能让价值流从图变成管理工具。