1. 一个具体问题
每个部门都说自己处理申请只需半小时，客户却要等待两周。申请在共享表格、邮箱和审批队列之间移动，大部分时间无人实际处理。只优化某个部门的操作速度，很可能节省几分钟，却无法触动真正拖长交付的等待。
2. 一句话解释
价值流图从客户需求到最终交付描绘工作、物料和信息的整体流动，帮助识别等待、库存、交接及局部优化造成的浪费。
3. 出处与原意
价值流图与丰田及精益管理实践相关，Lean Enterprise Institute 提供了系统介绍。它通常包含现状图与未来状态设想，不只是普通流程图加上几个时间。分析关注完整交付系统，尤其是信息如何触发工作和各环节之间积压了多少未完成项。
4. 原理与机制
先选择一类相近需求，实际跟踪其流动，再记录处理时间、等待、在制量、返工和触发规则。处理时间不自动等于增值时间，某些检查可能必要却不直接增加客户价值。未来状态应说明如何改变批量、拉动、交接和信息条件，而不是要求每个人加速。跨不同工作日历计算时间时必须统一单位，避免把工时与自然日直接相加。
当前状态应来自现场观察或可靠记录，不能只依赖各部门估计的理想时间。未来状态也不必一次实现，可以拆成若干有先后依赖的改进。每完成一项都重新看整体流动，防止瓶颈已经转移，资源却仍投入原来的位置。
5. 一个完整案例
以下是假设案例。团队以连续工作小时为统一口径，跟踪设备借用申请：登记处理十分钟、等待四小时；审批处理二十分钟、等待八小时；设备准备处理三十分钟、等待四小时。总处理时间一小时，总等待十六小时，合计十七小时。即使把三个处理步骤都加速一半，也只节省半小时。调查发现审批每天只集中一次，准备环节又看不到已批准申请。团队改为在约定窗口及时审批，并让批准结果直接进入准备队列。试行后等待降到八小时，处理仍一小时，总计九小时。还需检查加急请求是否挤压普通申请，防止局部改善损害另一类用户。
6. 适用条件与反例
适合跨部门、重复交付且等待明显的流程。必须选择有共同路径的需求类型，混合所有业务会使平均值失去意义。反例是为了提高设备利用率，一次生产更多半成品，让下游库存增加；单个工位看似高效，整个价值流的交付时间可能更长。
7. 今天可以尝试的行动
追踪一个真实需求到完成，逐段写下实际处理与等待时间，以及谁通过什么信号开始工作。先找最长等待，再问它由批量规则、缺信息还是能力不足造成。为一个等待点设计小试验，同时观察总交付时间与下游积压。