作为现成计算模型的报价流程
模板随 FlowVisual 一起提供：从请求到已发出报价的六个步骤，包含已录入的数量、处理区间、产能与费率。您将六个数替换为您自己的数，并在二十分钟内看到哪个步骤真正阻碍了您的报价。通常不是公司怀疑的那个步骤。
报价流程模板将从询价到发送报价的路径分为六个步骤：记录询价，技术澄清，成本核算，审批，编写报价，发送与跟进。模板设置为每年550份询价，约每个工作日2.2份，采用一家中等规模供应商的处理时间跨度、角色产能与全面成本费率。在20 000次运行的压力测试中，技术澄清在79%的运行中成为限制性瓶颈，审批在21%的运行中成为瓶颈；其余所有步骤在任何一次运行中都不是瓶颈。中位数的交付周期为0.7个工作日，而在强负荷日（P90）为7.2个工作日。两者之间的差距才是真正的结论，而不是平均值。
3,7h
每个报价的六个步骤总和。
0,7 → 7,2天
普通日与强日对比。差异就是结论。
79%
该步骤成为瓶颈的运行比例。
6
订单，报价，发票审批，投诉，入职，IT 工单。
模板包含内容
这些数字来自示例模型，不来自客户委托。它们的选择与一家中型供应商相符。作为起点，而非参考。
输入： 每年550个询价，即每个工作日约2.2个，日变动率为26％，在7％的工作日出现1.35的峰值因子。
| 步骤 | 角色 | 处理时间 | 产能 | 平均负载 | 峰值日负载 |
|---|---|---|---|---|---|
| 01 记录询价 | 销售内勤 | 10–22 min | 12/Tag | 19 % | 26 % |
| 02 技术澄清 | 设计 | 70–140 min | 1 Person × 5 h → 2,6/Tag | 87 % | 133 % |
| 03 成本核算 | 成本核算 | 30–70 min | 5/Tag | 45 % | 62 % |
| 04 审批 | 销售管理 | 5–14 min | 3,4/Tag | 67 % | 92 % |
| 05 撰写报价 | 销售内勤 | 20–40 min | 8/Tag | 28 % | 39 % |
| 06 寄送与跟进 | 销售 | 10–20 min | 10/Tag | 23 % | 31 % |
关键发现。 设计在报价流程中每天提供五小时的时间。其余时间属于正在进行的项目。五小时乘以89％的利用率为267分钟；按每次技术澄清平均103分钟计算，相当于每天2.6个作业，而每天到达量为2.2个。理论上产能足够。但在强日则不足。
压力测试正是这样表明，而且它以概率而非评分的形式给出结论：
| 步骤 | 成为瓶颈的概率 | 超出产能的天数 |
|---|---|---|
| 01 记录询价 | 0 % | 0 % |
| 02 技术澄清 | 79 % | 29 % |
| 03 成本核算 | 0 % | 0 % |
| 04 审批 | 21 % | 6 % |
| 05 撰写报价 | 0 % | 0 % |
| 06 寄送与跟进 | 0 % | 0 % |
该列加总为100％，这并非巧合：每次运行只计数当天负载最高的一个约束步骤。因此“79％”并非“负载为79％”，而是：在五天中有四天该步骤就是限制吞吐量的那一步。
在内部被认为是瓶颈的成本核算在所有运行中都不是瓶颈。
您要替换的六个数字
其他任何内容都可以保持不变。谁做更多调整，并不会改善结果，只会延长期限。
- 每个工作日的询单数。 过去一年的询单 ÷ 工作日。记录在 CRM 或报价编号序列中。
- 峰值系数。 在最繁忙的一天，询单数比普通日多多少？对于报价通常取决于展会或季节；1,3 到 1,5 常见。没有这个数值，您会计算出一个永远不处于负荷下的流程。恰恰在负荷之下，才能决定某个报价是否能及时发出。
- 为该流程由技术部门提供的工时。 不是人数。关键指标是技术澄清人员实际上用于报价的每日时间，占用比例通常为三到六小时，从不会是八小时。
- 技术澄清的处理时长范围。 下限和上限，而不是均值。范围是驱动因素：它作为离散度对等待时间的影响是二次的，而均值只有线性影响。
- 每天的审批数。 当有报价待审批时，销售管理一天能审批多少份？这个数字决定审批是否为第二个瓶颈。在模板中，它在每五天中的一天是瓶颈。
- 按角色计算的全成本费率。 毛薪 × 1,5 到 1,8，再除以大约 1 500 年度有效工时。由此 50 000 欧元的岗位每小时成本约为 53 €，而不是用薪资 ÷ 2 080 小时天真得出的 24 €。用那种天真的费率，您以后用欧元表述的结论容易被质疑。
计算前的交叉检验： 统计当前未结的询单数量并除以您一天能发出的报价数（Little's Law）。如果得到的大致是您已知的平均通过时间，模型就是可用的。若差异很大，说明缺少一个队列，在报价场景中几乎总是缺少向客户的回询或一个需要等待的供应商报价。
模板未包含的内容。 通过时间等于处理时间加上以工作日计的排队时间。固定的日历时间（例如供应商需要三天出价、客户回电需要一周）未被建模。若存在此类固定时间，请将其作为独立步骤录入；否则模型算出来的时间会比客户实际体验的要快。
四个杠杆，逐一计算
每次只改变一个杠杆。三个同时改变会产生一个无法归因于单一杠杆的数字，因此无法形成商业案例。以下四次运行使用相同模板，每次仅改变一项输入。
| Hebel | Durchlaufzeit P90 | Last Klärung am Spitzentag | Neuer wahrscheinlichster Engpass |
|---|---|---|---|
| Ist-Stand der Vorlage | 7,2 Tage | 133 % | Technische Klärung (79 %) |
| 1 Pflichtfelder bei der Erfassung | 1,6 Tage | 94 % | Freigabe (69 %) |
| 2 Konstruktion gibt 6 statt 5 Stunden | 3,7 Tage | 111 % | Technische Klärung (56 %) |
| 3 Zweiter Konstrukteur halbtags | 1,3 Tage | 89 % | Freigabe (74 %) |
| 4 Freigabe entlasten (Takt 3,4 → 6) | 6,9 Tage | 133 % | Technische Klärung (99 %) |
杠杆 1. 在询单录入时设为必填字段。 将构造团队通常会问的六项信息在录入时采集。录入因此耗时更长（15–30 分钟而非 10–22 分钟），技术澄清变短（45–100 分钟而非 70–140 分钟），因为省去了回问环节。模型结果：通过时间的 P90 从 7,2 工作日降至 1,6 工作日，构造在峰值日的负载从 133 % 降至 94 %。在入口花费时间比在瓶颈处花费时间要便宜。这就是全部结论。
杠杆 2. 为报价流程增加构造时间。 每天多一小时。有效，但效果不如预期：峰值日为 111 % 而非 133 %，且在 56 % 的模拟中澄清仍然是瓶颈。这正说明了一个过载步骤的响应并非线性的代价。
杠杆 3. 第二名构造人员半日制。 最昂贵的杠杆，结果却几乎不比杠杆 1 好。仍要计算它的人会看到原因：瓶颈在两种情况下都会转移到审批，而从那之后构造不再受限。
杠杆 4. 缓解审批负担。 零效果但最有教育意义的发现。审批在峰值日以 92 % 为第二紧缺的步骤；将其加倍只带来 0,3 天的改善。因为只要澄清步骤仍在受限，送到审批的量根本不够。一个对第二瓶颈的杠杆不是半个成功，而是没有成功。
分别计算这四个杠杆并按投入产出排序。杠杆 1 是一个表单，杠杆 3 是一个岗位，在模型中它们相差 0,3 天。
关于如何从 20 000 次运行得到每个步骤的百分比，请参见文章 Monte-Carlo-Simulation für Prozesse；关于为什么 P50 与 P90 之间的扩散才是实质性的结论，请参见 P10, P50, P90 verstehen。
最终纸面上的内容
在现状基础上保存、在改变的杠杆和第二次运行后，比对会给出：
- 改进前/改进后循环时间 以 P50 和 P90 表示。对销售的承诺应以 P90 为准，而不是以中位数为准。若因为中位数是 0,7 而承诺“两个工作日”，则意味着每五天就有一天达不到承诺。
- 各步骤在高峰日的利用率 以及措施后的新瓶颈。在此模型中，瓶颈会在两个最有效的杠杆处迁移至“释放”。这是措施的正常结果，而非错误。
- 吞吐量 以每周的报价数对比到达数。在现状下，每周有 11 个到达，10.3 个离开；两者的差额不是损失，而是瓶颈每周新产生的积压。
- 年度人力成本影响 以区间表示，基于数量、时间和完全成本费率。模板按每个报价约 254 € 的工作时间估算；一年中 941 小时归属于工程设计工作。
- 假设清单 列出每一项估计输入。句子“等待供应商价格的时间未建模”能在最尖锐的问题被提出前就消除其锋芒。
输出为两个 PDF：给决策者的报价，和用于可追溯性的文档；若您已上传信头，则使用您的信头。
同一模板，两类问题。 本页回答计算问题：79% 的来源以及当解决瓶颈时瓶颈会迁移到何处。另一个问题（应建议做什么，以及不采取措施的成本）属于方法而非工具。该问题的内容可以在 Flowrefy 的分析存档 中找到，连同这些模板来源的 方法说明。一组数据，两类问题，两类受众。
其他模板
随附六个模型。全部按同一模式：结构已成型，数字典型，有六个可调数值，且恰有一个明确瓶颈。
- 包含于
- FlowVisual 适用于 macOS 13+ 和 Windows 10/11，在欢迎窗口的“查看模板”中
- 范围
- 6 个步骤，带到达波动和峰值系数，产能，处理时长区间，角色，系统，每步成本费率，每步停工假设
- 需调整
- 日均请求，峰值系数，设计工时，技术澄清时长区间，日均放行，小时费率
- 计算依据
- 20 000 次运行，Seed 42。App 默认计算 400 次。中位数保持不变，P90 会变化几个百分点
- 典型陈述
- 技术澄清为瓶颈（79%），不是核算（0%）
- 数字来源
- 示例模型，无客户数据。模板中已标注为示例
常见问题
模板中的数字是真实的客户数据吗？
不是。它们是示例值，符合中型供应商的典型量级，且在模板中已标注为示例。用途是让模型能立即运行并展示一个完整模型的样子。应由您自己的六个数值替换。
“瓶颈概率 79%”具体是什么意思？
意思是：在 100 个模拟天中有 79 天，技术澄清是占用率最高的步骤，因此限制了整个流程的吞吐量。这并不意味着该步骤的占用率为 79%；这个数字在旁边，指的是发生频率，而占用率的数值平均为 87%，在繁忙日为 133%。每次运行只计一个制约步骤，因此所有步骤的数值相加为 100%。
为什么中位数为 0,7 天却比 P90 的 7,2 小那么多？
因为接近容量极限的流程只有两种状态，没有平均值。平常的一天没有积压，一个报价大约需要其处理时间。繁忙的一天，设计时间不足，上午的积压会延长下午每个工序的持续时间。平均值无法描述这两种中的任意一种。这正是 FlowVisual 给出区间并报告峰值日占用率而不是月平均的原因。
我们设有一个数值门槛，超过该门槛则需第二位审批人签字。能否建模？
可以，通过带路由比例的决策：一部分报价走第二级，剩余则不走。IT 工单模板用相同结构，比例为 65 与 35%。如果您计算的通过时间明显低于测得值，通常就是缺少这样的分支，或缺少对外部人员的等待时间。
为什么加快审批几乎没有效果？
因为审批处接收到的量不足。审批在峰值日以 92% 的占用率是第二紧缺的步骤，但它只能处理技术澄清放行的那些。若将其节拍加倍，P90 的通过时间将从 7,2 天降至 6,9 天，而澄清成为瓶颈的概率则从 79% 上升到 99%。对第二瓶颈施加杠杆并不是半个成功。这是技术上成功的措施在通过时间上看不见效果的最常见原因。
我是否必须使用模板，还是可以直接开始？
您可以直接开始。但经验表明，第一个自建模型通常做得过于细致（三十步而非六步），额外的细化需要更多输入时间，却不改变瓶颈。在一个已成型的模板中节省三十秒即可免去这些工作。
打开模板并输入您的六个数值
下载 FlowVisual，在欢迎窗口选择“查看模板”，打开报价流程。建模与压力测试免费。
Guide: seven steps to the number