用每步三项数字找到瓶颈
进行一次瓶颈分析不需要来自 ERP 的流程数据，也不需要咨询项目。每个步骤只需数量、时长和产能，要用真实的区间而不是平均值，并且即使结果指向与预期不同的另一个步骤，也要愿意相信它。
瓶颈分析会为每个流程步骤计算负荷率 ρ = 需求 ÷ 能力，并据此对步骤排序。最高的值就是瓶颈。并非处理时间最长的步骤，也并非投诉最多的那个步骤。大约从85％开始就变得关键：在那个负荷率下，等待时间已是处理时间的5.7倍；在95％时则为19倍。计算以高峰日为准，而非月均值，并且在每项改进后重新计算，因为一旦某个瓶颈被消除，瓶颈就会移动到下一个步骤。
2,3×
等待时间与处理时间的比值。
5,7×
从这里开始，任何数量增加都很昂贵。
19×
高出十个百分点，等待时间变为三倍。
5–10步骤
更精细地建模不会改变瓶颈位置。
瓶颈是利用率最高的步骤。
不是最慢的，也不是最嘈杂的。这一区别决定了一项措施是有效还是徒劳。
利用率 ρ = 需求 ÷ 产能
=（数量 × 处理时长）÷ 可用工作时间
示例。 步骤“审查”每天收到 120 个工单，每个耗时 12 分钟。三位员工每天各有七小时的有效工作时间。
- 需求：120 × 12 min = 1 440 min/天
- 产能：3 × 7 h = 1 260 min/天
- ρ = 1 440 ÷ 1 260 = 114 %
超过 100 % 意味着：等待队列每天持续增长。不是“会稍微久一些”，而是无限增长，直到有人升级、加班或工单被搁置。
其他步骤耗时 40 分钟在此并不影响，只要那里有足够的产能即可。时长不是利用率。 完整的计算过程连同 Little's Law 和 Kingman 近似见文章 Engpass berechnen。
五个步骤，半天
顺序比精确度更重要。若以数据收集开始而不是以界定开始，您会为与问题无关的步骤收集三周的数据。
1. 确定边界。流程从哪里开始，到哪里结束？ 一句话，所有相关人员都会签署的描述：“从发票入账到批准付款。”如果没有这句话，两个部门会就不同的流程展开讨论，并对不同的数字感到困惑。
2. 粗略建模。五到十个步骤。 不要三十个。只有在流程确实分支时才画出决策，并在每条边上标注分配比例。所有离开流程的情况（撤回、拒绝、搁置）都作为中止处理。否则您会用永远到达不了的数量进行计算。
3. 每个步骤收集三项数据。 数量、作为区间的处理时长、产能。允许估计，不允许杜撰：每一项估计都要作为假设记录并在结果中体现。
4. 计算并排序。 按步骤计算 ρ，降序排列。标记超过 85% 的，超过 100% 的标红。用 Little's Law 做交叉验证：在制品 ÷ 日吞吐量 应大致等于测得的流转时间。如果差别很大，模型中缺少一个等待队列，多半是一项追问或一个审批。
5. 检查杠杆点。单独检查，不要打包。 提高产能、降低波动、改道数量、对步骤进行自动化。每做一项单独改动就重新计算。三项同时改动会产生一个没有人能把因果归于单一杠杆的数字，因此无法形成 Business Case。
您需要哪些数据以及它们在哪里？
反对瓶颈分析的最常见借口是“我们没有数据”。数据通常分布在四个系统中，每位部门负责人都能打开。
| Angabe | Woher | Ersatz, wenn nichts vorliegt |
|---|---|---|
| Volumen Pro Tag | ERP, Ticketsystem, Rechnungseingang, Postbuch | 四周计数，足够用于第一轮 |
| Spitzentag | 同一来源，取最大值而非平均值 | 经验法则：月末或周初，系数 1.5–2 |
| Bearbeitungsdauer von–bis | Zeiterfassung, Selbstauskunft | 分别询问三位处理者，取他们回答的区间 |
| Kapazität je Schritt | Stellenplan × produktive Stunden | 人数 × 小时 × 0.7 以考虑故障和附带工作 |
| Bestand (wartende Vorgänge) | Postkorb, Warteliste, offene Tickets | 在三天内计数 |
| Vollkostensatz je Rolle | Controlling | 毛工资 × 1.5 到 1.8 ÷ 每年 1500 小时 |
Zur letzten Zeile: Eine 50 000-Euro-Stelle kostet rund 53 € je Stunde, nicht die naiven 24 €, die aus Gehalt ÷ 2 080 Stunden entstehen。Mit dem naiven Satz ist jede Euro-Aussage später angreifbar。Sie wird angegriffen。Die weiteren typischen Rechenfehler stehen in Prozesskosten in Excel。
五个会让任何瓶颈分析失败的误解
1. 使用平均值计算。 一个月平均产能利用率为70％但月初达到130％的流程存在问题，而平均值会将其掩盖。请计算第90百分位的那一天。
2. 将最长的步骤当作瓶颈。 持续时间并不等于利用率。一个有充足产能的40分钟步骤无害，而一个没有产能的12分钟步骤则有问题。
3. 将抱怨最大的人当作瓶颈。 经常抱怨的人通常位于瓶颈的后面，以突发的方式收到工作。抱怨是真实的，但原因在前一工序。
4. 忽视瓶颈的转移。 一旦解决了当前瓶颈，全部工作量会冲击下一个步骤。不把这种连锁影响计入商业案例，会承诺一个永远无法实现的节省。这是自动化项目未达标最常见的原因。
5. 追求最大化利用率。 95％的利用率不是效率的标志，而是等待时间的标志。把流程调到高利用率，是以非常不划算的代价用交付周期换取吞吐量。
可靠结论长什么样
一个被决策委员会采纳的结论包含四个部分。缺一项，就会出现质询，进而耽搁一切。
- “各环节的负荷排序”，按峰值日计算，每一步都显示所作假设。
- “作为区间的交付周期”：P50 和 P90，而非均值。承诺以 P90 为准，而不是以中位数为准。
- “仅一项改动的效果”清晰呈现，前后对比，按时间和欧元计，并包含说明改动后瓶颈将移至何处。
- “未覆盖项清单”。句子“未对供应商的追问建模”会在问题提出前就削弱会议中最尖锐的质疑。
FlowVisual 正是生成这四项内容并导出：P90 日的瓶颈及其负荷，作为区间的交付周期，按欧元的前后对比，以及假设清单。输出为面向决策者的报价 PDF 和用于可追溯性的文档 PDF。
- 关键指标
- 利用率 ρ = 需求 ÷ 产能，逐步骤计算，以高峰日为准。
- 警戒值
- ρ > 85%。在此处，等待时间已达到处理时间的5.7倍。
- 交叉检验
- Little's Law：在制品量 ÷ 日吞吐量 ≈ 测得的交付周期。
- 模型规模
- 5–10 步骤；更精细地建模不会改变瓶颈位置。
- 数据采集
- 数量、处理时长作为区间、能力。允许估算，但必须以假设形式可见。
- 结果
- 排序、P50/P90 交付周期、一个杠杆的欧元效应、假设清单。
常见问题
从哪个利用率起，一个流程步骤会变得关键？
作为经验法则，从85%起。原因是排队论中的因子 ρ/(1−ρ)：在85%时，等待时间已是处理时间的5.7倍，在95%时是19倍。两者之间只差十个百分点的数量增长。因此，崩溃看似突然，但其实并非如此。
我能用 Excel 做瓶颈分析吗？
每个步骤的利用率可以，用 Excel 就能算出，这是最重要的部分。Excel 做不到的是链式关联：瓶颈之后的步骤在表格里看起来很从容，因为它只会得到瓶颈放行的量。瓶颈解决后，它会自己变成新的瓶颈。正是这种迁移导致表格中的商业案例在实际运行中无法实现。
做瓶颈分析需要 Process Mining 吗？
不需要。Process Mining 从系统日志测量过去，当存在贯穿的事件日志时非常强大。要回答一旦某步骤自动化或某岗位被填补后会发生什么，则需要对一个尚不存在的流程做计算。为此，每步的数量、时长和产能就足够了。
做一次瓶颈分析需要多长时间？
对于一个界定明确、包含五到十个步骤的流程：半天，其中大部分时间用于数据收集。模型本身大约30分钟可建成。若界定有争议，则耗时更长。在那种情况下，界定本身才是主要工作，不是计算。
如果我有多个瓶颈，该怎么办？
逐个处理。任何时点只有一个限制步骤；其他步骤之所以看起来很高，是因为它们尚未获得全部数量。先解决最上面的，重新计算，然后处理下一个。同时解决所有问题会产生成本，其效果之后将无法再归因。
对您的流程进行瓶颈分析
创建步骤，输入数量和区间，启动压力测试。最上方的条是您的瓶颈。然后改变一个杠杆，观察它向何处移动。
Guide: seven steps to the number