BPMNツールとシミュレーション：表記が計算できることとできないこと

Inhaltsverzeichnis+

ツールの選定で誤った判断を招く決まり文句があります。「Unser BPMN-Tool kann auch Simulation。」これは多くの場合真実ですが、ほとんど役に立ちません。なぜなら「妥当性チェック」から「完全なイベント駆動モンテカルロシミュレーション」まで、あらゆる意味に取り得るからです。

理由は記法そのものにあります。

BPMNが記述するものとしないもの

BPMN 2.0はOMGの標準で、プロセスの構造を定義します：タスク、イベント、ゲートウェイ、レーン、メッセージフロー。「どの順番で何が起き、誰がそれを行うか？」という問いに対して完全かつ正確に答えます。

しかし計算には記法にそもそも含まれていない5つの情報が欠けています：

1. 到着プロセス。 どれだけの実体が到着し、どのように分布しているか。1日に20件が均等に到着する場合と、月曜朝にまとめて20件来る場合ではまったく状況が異なります。
2. 処理時間のばらつき。 「10分」ではなく「5〜20分、通常は8分」という具合です。待ち行列を生むのは平均値ではなくばらつきです。
3. リソースごとの容量。 何名がどの稼働率で、どの役割がプールを共有しているか。
4. 分岐確率。 XORゲートウェイは分岐することを示しますが、どの経路がどの頻度で選ばれるかは図にありません。
5. カレンダー。 1日8時間、祝日、シフト。金曜16:50に到着した案件は10分待つのではなく3日待つことになります。

この問題のために作られたのがBPSimです。WfMCの標準で、シミュレーションパラメータをBPMNモデルに付加しますが記法自体は変えません。この標準の存在こそ、BPMNだけでは計算できないことの最良の証拠です。

BPMNツールのシミュレーションモジュールが典型的に提供するもの

一般的なモデリングスイート（Bizagi Modeler、SAP Signavio、ARISなど）は段階的なシミュレーション機能を備えています。メーカーに関係なく典型的な構成は次のとおりです：

• 構造検査。 トークンはモデルを通過するか、行き止まりや到達されない枝があるかを確認します。役立ちますが厳密な意味でのシミュレーションではありません。
• 時間分析。 各タスクの所要時間からリードタイムを算出します。まだ容量制限がないため待ち行列は考慮されません。
• リソース分析。 ここで初めて重要になります：人員と容量により待ち行列や稼働率が発生します。
• カレンダー分析。 勤務時間やシフトにより待ち時間が現実的になります。

Camundaは意図的にこの列挙に含めていません：Camundaは実行エンジンであり、シミュレーション環境ではありません。実際の案件をプロセスに流して測定する点で、シミュレーションより有用です。ただしそれはプロセスがすでに自動化されている場合に限ります。判断を下す前には役に立ちません。

工具に対する5つの質問

モデル作成ツールを開いて10分で次を確認してください：

1. 所要時間をレンジで入力できますか？ フィールドが単一の数値しか受け付けない場合、ツールは平均値で計算します。その結果は系統的に楽観的になります。待ち行列はばらつきから生じ、ばらつきがなければ待ち行列も生じません。

2. 幅（スパン）付きの結果が得られますか？ 「6,4日」というスカラーは情報ではなく数値にすぎません。「P10 4,1〜P90 11,8日」は意味ある主張です。点推定しか出さないツールは、決定論的に計算したか、ばらつきを隠しています。

3. 役割はプールで容量を共有できますか？ 実務では同じ人が3つの異なるステップを担当します。タスクごとに容量を管理するツールは各ステップを余裕で処理するように見えますが、3つとも担当する人は余裕がありません。

4. ピーク日の値か月平均かが分かりますか？ 月平均ではほとんどの役割の稼働率は80％未満です。しかしピーク日にはまさにそこでプロセスが破綻します。稼働率の数値が何に対するものか示されていなければ無意味です。

5. 改善にかかる費用と効果は示されますか？ ほとんどのモデリングツールはこれに答えません。コストレートや投資額はモデルの一部ではないからです。しかしプロジェクトを決定するのはまさにその数値です。

優れたモジュールが止まる点

仮にツールが上の5つの検査をすべて満たしたとします。それでも最後の問いが残ります。多くの解析はここで失敗します。技術的な限界ではなく、誰もこの問いを立てないからです：

ボトルネックを解消したとき、どこに移動しますか？

誰もが知っている例：検査工程が遅いので自動化する。シミュレーションは検査時間が80％減ると示します。しかししばしば示さないのは、その結果として後続の承認工程はこれまで26分ごとに処理を受けていたのが10分ごとに処理を受けて過負荷になることです。スループットは期待通りに上がらず、節約された時間は新たな待ち行列に吸収されます。

これは稀な特殊例ではなく常態です。ボトルネックは消えるのではなく移動します。こうした移動を秒単位で試験できないモデルは、運用時に成立しないビジネスケースを導きます。

実務的な推奨

• すでにシミュレーションモジュール付きのモデリングスイートをお持ちですか？ それを使ってください。5つの質問のいずれかでつまずく場合にのみ別のツールが有益です。
• これからモデリングを始めますか？ BPMNから始めないでください。BPMNは文書化向けの記法です。「どこが詰まっていて変更で何が得られるか？」という問いには、まず学習の手間を踏む遠回りになります。
• 投資を正当化する必要がありますか？ その場合はレンジ、ピーク日、共有リソースプール、そしてユーロでのビフォー／アフターが必要です。新しいツールを買う前に、既存のどのツールがそれを提供するかを確認してください。

FlowVisualは意図的にBPMNを採用していません：記法の代わりに6つのブロック、所要時間はレンジ、ピーク日の稼働、共有プールを採用しています。最終的にはP10–P90の幅を伴うユーロでのビフォー／アフターを提供します。BPMNが文書化のために必要ならそれを置き換えるものではありません。別の問いに答えるツールです。