价值流与跨部门流程视图是什么
价值流描述从需求提出到价值交付的完整流转过程，包含各环节的处理时间与等待时间。它最常得出的结论是：等待时间远大于处理时间，改进重点在排队与交接，而不在单点提速。画图时按环节标注处理时间与等待时间，用量化数据定位瓶颈；效率指标常用增值时间占比，即增值时间除以总前置时间。价值流也用于界定项目边界：跨部门流转的断点正是需要重点协调的位置。
基本信息
| 构成 | 环节、处理时间（PT）、等待时间（WT） |
|---|---|
| 关键指标 | 前置时间、增值时间占比、在制品数量 |
| 常见结论 | 等待时间远大于处理时间 |
| 改进重点 | 减少排队、批量与交接次数 |
| 用途 | 定位瓶颈、界定项目边界、评估改进效果 |
典型使用场景
- 判断交付周期长的主因是产能不足还是排队等待
- 界定项目边界，把跨部门交接断点纳入协调范围
- 评估工具或自动化改进后，前置时间是否真的缩短
- 识别批量处理环节，判断能否改为小批量流转
- 向管理层说明改进机会时，用时间数据替代主观判断
价值流图要素
| 要素 | 含义 | 记录要求 |
|---|---|---|
| 环节 | 受理、评审、开发、测试、上线等 | 按实际流转顺序画，不按部门 |
| 处理时间 | 该环节真正在工作的时间 | 单位统一，注明统计口径 |
| 等待时间 | 排队、等审批与交接的时间 | 最易忽略，也最容易改进 |
| 前置时间 | 从提出到交付的总时间 | 等于处理时间与等待时间之和 |
| 增值时间占比 | 增值时间除以总前置时间 | 比例低说明改进空间在等待 |
价值流记录样例
价值流记录样例
需求受理：处理 0.5 天，等待 1 天 # 等待来自受理人不在岗
评审：处理 0.5 天，等待 3 天 # 排队等待评审会档期
开发：处理 5 天，等待 2 天 # 等待环境与接口就绪
测试：处理 2 天，等待 4 天 # 排队等待测试环境
上线：处理 0.5 天，等待 2 天 # 等待发布窗口
合计：处理 8.5 天，等待 12 天 # 改进重点在等待而非产能只画流程不量化时间，瓶颈就只能靠猜：多数人凭印象认为开发是瓶颈，量化后常发现排队等待占比更高，改错了地方白花成本。
改进要盯交接而不只是单环节提速：把每个环节各自加快百分之二十，效果通常小于减少一次串行审批带来的前置时间缩短。
忽视交接与排队、只在单环节加班或加人，整体前置时间往往没有变化，成本却已经上升。