ITIL 4 客户旅程：推式 vs 拉式，两种工作流管理范式的对决

一、推式机制的问题根源：不透明、不稳定、不可控

1.推式机制的本质

在传统服务管理或项目交付流程中，推式工作机制是最常见的组织形式——计划制订者把任务“推送”到执行者那里，不考虑执行端当前的处理能力与状态。这种方式虽然初看上去逻辑清晰，但在复杂服务交付环境中，问题频出。

推式机制的根本逻辑是“谁排计划谁说了算”，而不是“谁准备好了谁拉取”。它假设了计划与现实之间始终一致，但ITIL 4的视角告诉我们，在动态环境中，这种假设很容易失效。

2.推式机制带来的典型困扰

• 隐形任务激增：团队成员经常手头任务不断累积，但这些任务在系统中没有明确记录，导致管理者无法感知实际负荷；

• 无序堆积：任务堆在各个节点，谁都忙但谁都交不出结果；

• 协同困难：各环节关注点不同，缺乏节奏对齐，互相等待甚至推诿。

在课堂上我曾举过一个例子：某金融科技公司上线一个客户服务平台，需求按计划直接下发到开发团队，导致需求端“堆活”，开发端“应付”，测试和上线却严重滞后，整个流程“推得动却走不通”。这是典型的推式失控后果。

二、拉式机制的核心逻辑：节奏驱动、状态可视、以备就绪为启动信号

1.从“工作流”转向“流工作”

ITIL 4引入拉式机制，不是为了反对计划，而是希望工作启动的时点由“接受者的准备状态”来决定。

当一个阶段准备好了，才去“拉取”上游的任务，这样每一个节点都可以根据自身状态合理安排节奏。工作不再是被压过来的，而是流动起来的。

拉式机制最重要的一点，是每个工作项的状态都明确可视，团队成员可以随时掌握当前流程的瓶颈在哪、任务正在哪个节点、下一个“可启动”任务在哪个队列中。

2.可视化带来的主动性和弹性

借助拉式机制和看板工具，团队不再需要频繁开会协调谁该做什么，而是通过任务状态的变化主动拉取、协同和响应。这种机制在服务管理中尤为重要，尤其是在应对突发事件、高并发任务时，能显著提升管理弹性。

三、推拉结合机制：场景适配与动态调整的实践逻辑

1.不是非此即彼，而是找准“起始点”和“转换点”

现实中，很多组织在尝试拉式机制时遇到困难，原因往往在于误解了“拉式≠不计划”。在ITIL 4的服务交付链中，很多前置任务仍然需要计划启动，而后续流程则可以转为拉动模式。

比如某数字政务平台的建设项目，需求收集与审批采用推式机制推进，但进入开发、测试、上线阶段后转为拉式，由各团队根据准备状态拉取任务，实现更稳的节奏掌控。

这种混合机制的关键是定义好“转换节点”：在哪个阶段由推改为拉？哪些任务仍需按优先级强制推进？哪些则可按资源流动自适应推进？这是一种需要运营经验和数据支撑的能力。

2.场景分析：哪些适合拉？哪些仍需推？

适合拉式的场景：

• 多团队协作、任务间依赖关系强；

• 需求波动大、频繁变更；

• 强调客户体验、需要快速响应。

适合推式的场景：

• 明确计划、固定周期的发布流程；

• 外部监管约束较强的合规性任务；

• 成本、资源固定，需强控制的项目管理任务。

推拉结合适用于大多数混合型项目，通过建立“拉式主导+推式引导”的策略，实现兼顾灵活性与可控性的服务交付。

四、如何判断组织当前适配哪种机制？

1.从任务流动性看适应性

组织是否具备拉式机制的基础，首先要看任务是否可拆解、可追踪、可视化。如果工作项彼此割裂、信息闭塞、没有明确状态定义，那无论如何也拉不动。

ITIL 4强调服务的“价值流导向”，所以我们必须以任务流动为单位来重塑组织协作结构。若组织内部已经建立起清晰的任务流通路径、明确的状态看板与反馈机制，那么推进拉式就是顺势而为。

2.从团队文化与治理结构做评估

推式强调“上级安排、下级执行”，对领导力、控制力依赖大；而拉式更依赖“主动承担、协同驱动”，需要组织内部有较高的透明度、信任度与目标一致性。

因此组织是否适配拉式，不仅是流程问题，更是文化与治理模型的问题。可以通过以下几个方面做初步判断：

• 团队是否愿意共享状态？

• 是否有明确优先级机制？

• 是否支持角色自我协调？

• 管理者是否愿意放手不控制每个细节？

只有当这些条件逐步具备，拉式机制才真正有可能落地生根。

ITIL 4大师级课程官方授权讲师长河老师原创，末经许可，不得转载