带仿真的 BPMN 工具：标记能计算什么、不能计算什么

Inhaltsverzeichnis+

在工具选择中常常导致错误决策的一句话是：“我们的 BPMN 工具也能做模拟。”这句话多数情况下是真的，却几乎总是无用的，因为它可以指从一个合理性检查到一个完整的事件驱动模拟器的任何东西。

原因在于符号本身。

BPMN 描述什么、不描述什么

BPMN 2.0 是 OMG 制定的关于流程结构的标准：任务、事件、网关、泳道、消息流。它完整且精确地回答了“以何种顺序发生什么，谁来做？”这个问题。

用于计算还缺少五项信息，这些在符号中根本没有规定：

1. 到达过程。 有多少事务到达，它们如何分布？二十个申请均匀分布到一天与周一早上集中到达的二十个，结果完全不同。
2. 处理时长的离散程度。 不是“10 分钟”，而是“5 到 20 分钟，通常为 8”。离散程度是排队的驱动因子，而不是均值。
3. 每个资源的容量。 有多少人以什么岗位比例，哪些角色共享一个池？
4. 分支概率。 XOR 网关表明发生分支，但哪个路径被选中以及多频繁，在图中并不存在。
5. 日历。 每天八小时、节假日、班次。周五 16:50 到达的事项不会等待十分钟，而是等三天。

为了解决这个问题正是产生了 BPSim。WfMC 的这个标准把仿真参数附加到 BPMN 模型上，而不改变符号。正是需要这个标准，最有力地证明了 BPMN 本身不能用于运算。

BPMN 工具中的仿真模块通常提供什么

流行的建模套件（如 Bizagi Modeler、SAP Signavio、ARIS 等）以分阶段的方式提供仿真。典型结构，不论厂商如何：

• 结构校验。 一个令牌能否通过模型，是否存在死路或永远不被触达的分支？有用，但还不是严格意义上的仿真。
• 时间分析。 每个任务的时长，由此得出通过时间。仍然没有容量上限，因此没有排队。
• 资源分析。 到这一步才开始有意思：人员及其容量，由此产生排队和利用率。
• 日历分析。 工作时间和班次，使等待时间更真实。

Camunda 故意不在此列：它是一个执行引擎，而不是仿真环境。它让真实事务在流程中运行并对其进行测量。这比任何仿真都更有价值。但只有在流程已经自动化运行时才适用。在决策之前，它无能为力。

对您的工具的五个问题

打开您的建模工具，在十分钟内检查：

1. 能否以区间输入一个持续时间？ 如果该字段只接受一个数字，工具就用均值计算。这样结果系统性地偏向有利。排队来自离散性，没有离散性就没有排队。

2. 我能得到带区间的结果吗？ “6.4 天”的通过时间不是结论，而只是一个数字。“P10 4.1 到 P90 11.8 天”才是结论。只输出点值的工具，要么是做了确定性计算，要么隐瞒了区间。

3. 角色会共享容量吗？ 在实际中，同一人会做三个不同步骤。按任务而不是按池管理容量的工具，会把每个步骤单独算得很轻松。而实际上承担全部三项的那个人在任何一步都不会轻松。

4. 我看到的是峰值日还是月均值？ 按月均值几乎每个角色的利用率都低于 80%。在峰值日，流程恰恰在此处崩溃。如果利用率数字没有说明其基准，它就毫无价值。

5. 改善的成本是多少，能带来什么收益？ 几乎没有建模工具能回答这个问题，因为成本率和投资不是模型的一部分。但正是这个数字决定项目的可行性。

即使好的模块也止步之处

假设您的工具通过了以上五项检查。仍然有最后一个问题。大多数分析在这里失败，不是因为技术做不到，而是因为没人问它：

如果我消除了某个瓶颈，瓶颈会向哪里转移？

一个人人皆知的例子：审批太慢，于是将其自动化。仿真显示：审批时间下降 80%。但它常常不会显示的是：后面的放行步骤此前每 26 分钟收到一件，因为审批限制了流量。现在每 10 分钟收到一件，本身就超负荷。吞吐量并没有按预期增长，节省下来的时间转而进入了新的排队。

这不是罕见的特例，而是常态。瓶颈不会消失，它会转移。如果一个模型不能让您在数秒内演练这种迁移，您就会得到在实际运行中不会出现的商业案例。

实用建议

• 您已经有带仿真模块的建模套件？使用它。如果在五个问题中的任何一项失败，才考虑第二个工具。
• 您刚开始建模？不要从 BPMN 开始。该符号为文档编写而生；要回答“哪里卡住、改动带来什么”，用它是绕远，因为您还得先学会这门语言。
• 您需要为一项投资做论证？那您需要区间、峰值日、共享资源池以及以欧元表示的前/后对比。先检查现有工具哪个能提供这些，再决定是否购买新工具。

FlowVisual 有意放弃 BPMN：用六个构件代替一种符号，持续时间以区间表示，显示峰值日的利用率，采用共享池。最终给出带 P10–P90 区间的欧元前/后对比。需要 BPMN 作文档的人不能把它替代；它回答的是另一类问题。