订单处理流程作为成型的计算模型

入口： 每年 6 000 个订单，因此每个工作日 24 个，日波动率为 24％，且 7％ 的日子有 1,3 的高峰因子。月初、框架性调用、活动结束。

“访问次数” 列是第一个提示，说明该模板与其他模板的阅读方式不同：步骤 03 和 04 并非每个订单只执行一次，而是执行 1,18 次。原因在下一行。15％ 的批准会作为疑问返回到定价阶段，而不是继续前进。

关键发现。 每个步骤在 20 000 次运行中的成为瓶颈的概率：

该列合计为 100,0％：每次运行都恰好计入一个当日负荷最高的约束步骤。

信用审核是订单最少能顺利通过的环节。九到十八分钟用于获取信息、检查额度、批准。不过它在四分之三的运行中仍是约束步骤，因为这是一个由一人承担的岗位，且每个订单都要经过该人员：每天可用 370 分钟，除以平均 13,2 分钟的处理时间，得到 28 个订单，而到达的是 24 个。平均来看足够。但在 30％ 的日子里不够，这时队列增长的速度超过了负荷的上升。

中间的两行是连在一起的。 9,7％ 加 9,7％ 共计 19,4％ 的运行，是被同一位在图中显示为两个方框的人所束缚。这是继信用审核之后模型中的第二重要瓶颈，但它没有独立的一行。

共享角色。 模板中批准（步骤 04）和疑问处理（步骤 05）并不是两个独立的容量，而是同一资源：Vertriebsleitung，工作 6,5 小时/天，利用率为 86％，即 335 分钟。两步对其的需求如下：

这占一人时间的 53％。如果把两步分开计量、分别设置独立容量，会得到 41 % 和 12 %：两个看起来宽松的数字，没人会质疑。工作内容相同，差别只是用来计算的量不同。两个单独看起来宽松的步骤，是同一人下午的工作。

因此模型中两个方框读到的是相同的负荷，在高峰日约为 87％。它们共用一人并共担命运：如果此人某天缺勤，两个步骤都会停止，而不是只有一个。假定两个独立容量的模型，会在此处计算出两个主管，且他们不会在同一天同时病倒。

返工循环。 15％ 的批准会作为疑问返回到定价环节。是返回，而不是继续。这不是一个分支，而是一个回流，它有一个从从左到右阅读时看不到的后果：步骤 03 和 04 每个订单会以 1/(1 − 0,15) = 1,18 次 运行，疑问处理本身为 0,18 次。

与不含循环但使用相同模型相比，这带来的成本：

因此该循环使每个订单的人工时间增加约 11％，并使销售主管的利用率增加约三分之一，但它仍然不是瓶颈。 在这里恰恰分开了两个常被混为一谈的问题：“这要花我多少成本？”和“是什么在阻碍我？”在此模型中两者得到不同答案。模板同时计算了两者，它们之间的差异就是核心结论的一半。

若删除一个循环，认为它“只是个特例”，将同时丢失所有三项数字：访问次数、成本和时间。一个不含回流的模型读起来会比实际流程便宜 11％ 并快 0.7 个工作日。

1. 每日工作日的订单量。 去年订单项或订单总数 ÷ 工作日。请使用与处理相同的单位：如果一次录入包含十二个订单项，则按订单计算；如果按每一项检查，则按订单项计算。两种做法都对，但混合则错误。
2. 高峰系数。 在最忙的一天，与普通日相比会有多少订单？月初、框架调用、价格促销结束。系数通常为 1,3 到 2。没有这个数值，您会计算出内部客服从未负荷过重，而信用审查恰好集中在这些日子。
3. 信用审查实际用于订单的小时数。 不是应收会计的人数。如果同时还要做催款和匹配收款，就没有七小时用于信用审查。这一个数字决定瓶颈所在。
4. 信用审查的处理时长范围。 下限和上限。老客户在额度内两分钟，新客户有询证和回访三十分钟。正是这个范围推动等待时间，而不是均值。
5. 需澄清情况的比例。 模板中为 15 %。这个数很少出现在报告里，但可以在一下午里数出来：上个月有多少订单因价格需要回退？这是模型中唯一同时影响成本、利用率和通过时间的数值。
6. 按角色的完全成本费率。 税前工资 × 1,5 到 1,8，除以每年约 1 500 个有效工作小时。别忘了分担角色的费率：在模板中该费率写在资源上，而不是两个步骤上。否则您会按办事员的费率来计算一次放行。

那一项不是数字的说明。 在计算前：确认实际由谁共用一名人员。在模板里是放行和澄清。在您那里可能是另一对。录入与确认常由同一办事员负责，定价与放行常归同一销售经理。您若不记录这些绑定，就会把一名人员在计算上分配到两处，模型会报告两个闲置的步骤而非一个紧张的角色。

计算前的交叉验证： 在 ERP 中统计未确认的未完成订单数，并除以您一天能确认的订单数（Little's Law）。如果得到的确认时间与您知道的相符，模型可用。若差别很大，说明缺少一个队列，这里几乎总是缺少“等待客户反馈”的状态。

模板未包含的内容。 模型在订单确认处结束：拣货、发运和开票故意未建模。那是另一个具有不同产能的流程。同样未包含：物料可用性、向客户的询问（日历时间，不是工作时间）以及优先级。模型按到达顺序工作。若确实要优先处理加急订单，请把它们建模为第二条具有独立产能的支路。

杠杆 1. 通过接口获取信用报告。 自动调用征信机构，仅由人工处理超出额度或无匹配的案件。审查时间从 9–18 分降到 4–9 分。效果：P90 通过时间从 5,81 降至 0,28 工作日，高峰日负荷从 132 % 降至 65 %，每单工时成本从 60,85 € 降至 53,96 €。这是现场最强的杠杆，也是唯一不需要额外人手的措施。

有趣的部分在最后一列：之后最可能的瓶颈变为“价格与订单确认”，占 41%。仅看这一列会忽略更大的总体区块。放行与澄清随后分别为 25,3 % 和 25,1 %，合计为 50,4 % 的运行。在杠杆 1 之后，瓶颈不再是一个岗位，而是一名人员。

杠杆 2. 在信用审查增加第二人手。 效果几乎相同（0,30 天 对比 0,28 天），但需增加半个到一个岗位，且不改变每单工时成本：相同的工作由两个人分担。与杠杆 1（一个接口对一名人员、相差 0,02 天）的比较，才是这张表的核心结论。

杠杆 3. 将澄清比例从 15 % 降至 5 %。 通过更明确的定价规则、登记的条件、一个不需放行的金额下限来实现。效果：每单工时成本从 60,85 € 降至 56,00 €，分担角色的负荷从 53 % 降至 40 %，P90 通过时间从 5,81 降至 5,20 天。结果不错，但并不能解决瓶颈：信用审查绑定的运行反而更多（89 % 而非 74,7 %），因为竞争对手位置消失了。该杠杆减轻一名人员负担并节省成本；对客户承诺的改善则很小。

杠杆 4. 取消分担角色。 首个零效果发现，也是更令人不悦的那种。放行交给第二位上级，澄清仍在第一位。两个步骤因此落在第 02 节中的 41 % 和 12 % 的舒适位置。P90 通过时间从 5,81 降到 5,31 天，每单工时成本仍为 60,85 €，信用审查的瓶颈概率上升从 74,7 % 到 86,6 %：影子瓶颈消失了，真正的瓶颈依旧存在。分担角色是一个真实的现象，但在信用审查位于前面的情况下并非一项措施。 当杠杆 1 或 2 实施后，它才会成为措施；届时它会绑定一半的运行。先后顺序重要，而非选择。

杠杆 5. 通过 EDI 或客户门户录入订单。 第二个零效果发现，同时也是在此类流程中最常见的建议：订单通过电子邮件收到并被人工录入；门户或 EDI 可避免该步骤。录入时间从 8–17 分降至 3–7 分，每单工时成本从 60,85 € 降至 54,12 €。强日的通过时间从 5,81 降至 5,79 天。几乎无变化。录入的负荷为 55 %，高峰日为 74 %。它从未堵住流程。该措施是正确的，但“因此会更快”这一理由并不成立。 它每单节省 6,73 €，对一年 6 000 单的情况是一个独立的论点，只是不同的论点。

请分别计算这五项，并按“效果除以投入”排序。五项中有两项能影响通过时间；三项能影响成本或利用率。只要不把一项当成另一项出售，两者都是结果。

关于如何从 20 000 次运行得到每个步骤的百分比，请见文章 Monte Carlo-Simulation für Prozesse；为什么即使是 85 % 的负荷也过高，请见 Engpass berechnen。

在记录现状、改变一个杠杆并进行第二次运行后，比对结果显示：

• 改进前后通过时间 以 P50 和 P90 表示。中位数为 0,16 个工作日。若据此向销售承诺“同日确认”，每第十天就会出错，误差接近六个工作日。承诺应基于 P90，而不是中位数。
• 各步骤在高峰日的利用率 以及措施后的新瓶颈。在此模型中，五个杠杆中有两个会将瓶颈转移到“价格与订单确认”，其后是共享角色中的较大阻塞。
• 各共享资源的利用率，与步骤分开显示。这是那种无法在步骤行中展示的数字：销售主管在两个格子上分配的 178/335 分钟。
• 吞吐量 以每周确认订单对比到达订单表示：现状为 112 对 120。差额为每周有八个订单被搁置。
• 每单工作时间成本 及年度成本，基于数量、时间和全成本率。模板计算为每单 60,85 €，其中 6,90 € 属于澄清环路。
• 假设清单 包含每项估计输入。句子“拣货、发货和开票未建模”在最尖锐的质疑提出之前就消除了其锋芒。

输出为两份 PDF：供决策者的报价和用于可复查性的文档，若您已上传信头则会使用您的信头。

同一模板，两个问题。 本页回答计算问题：74,7% 从何而来，为什么两个格子显示相同利用率，以及将时间和成本各回退 15% 要付出什么代价。另一个问题（会建议什么，以及一个订单在等待三天征信报告时成本多少）属于方法层面而非工具。其内容位于 Flowrefy 的分析档案，以及这些模板来源的 方法说明。一份数据，两类问题，两个受众。

• 订单处理 即本页内容。画廊的第一张卡片，也是唯一包含共享角色与返工循环的案例。
• 报价流程 是那个由通过时间影响收入而非成本的案例。
• 发票审批 是波动性案例：平均在产能之下，但月末超出产能。
• 在 投诉处理 中，瓶颈位于外部，因此诚实的建议并非“自动化”。
• 员工入职 量少且参与者多，其中一步占据了 86% 的流程次数。
• IT 工单 是带分支的案例：65% 立即解决，35% 进入二线。

每个模板可在欢迎窗口通过 查看模板 打开。首次使用时，建议先打开一个模板再开始创建您自己的模型。否则模型会建得过于精细。