BPMNは処理の流れを記述します。シミュレーションにはさらに四つの指定が必要です。

BPMN 2.0 が記述するもの： アクティビティ、イベント、ゲートウェイ、シーケンスフロー、プールとレーン、メッセージ、サブプロセス。つまり、処理の構造です。完全に規格化され、ツール間で交換可能です。

BPMN 2.0 が記述しないもの： 負荷下での振る舞いです。具体的に不足するのは次の四つの情報です：

WfMC 拡張の BPSim（Business Process Simulation Interchange Standard）はまさにこのための規格で、これらのパラメータを BPMN ファイルに独立したセクションとして付加します。実務上は普及度が限られています。ほとんどのツールがシミュレーションパラメータを独自のフィールドに保存するため、ツールを変えても再入力が不要になることはめったにありません。

お客様のプロジェクトへの帰結： BPMN ダイアグラムをインポートすれば構造は取り込めますが、データは取り込めません。そしてデータが作業です。

ツールを決める前に各ベンダーに確認する三つの質問：

1. シミュレーションは「この」エディションに含まれているか、それともより高価なものか？
2. 空いていない工程の前で待ち行列を扱うか、それとも経路に沿って単に処理時間を加算するだけか？
3. 結果は幅（P10–P90）で受け取れるか、それとも単一の数値か？

質問2でカテゴリが分かれる：経路上の所要時間を合算するツールは結果を「Durchlaufzeit」と呼ぶが、意味しているのは処理時間である。事務系プロセスではその差が三倍未満であることはめったにない。

BPMN図は、人とシステムのためのものであり、流れを知る必要のある方々に向けられています： 品質管理、監査、教育、ソフトウェア開発。図は何年も使われ、バージョン管理されます。

計算モデルは意思決定のためのものです： この自動化は採算が取れるか、プロセスは倍の量に耐えられるか、どこで半人月相当を配置するか。計算モデルは数週間生き、決定がなされたら廃棄されます。

通常の進め方：

1. 文書化すべきならBPMNで流れを記録します。構造、責任、例外を記します。
2. 意思決定のために大まかな計算モデルを立てます：五〜十のステップ、三十ではありません。ボトルネックはほとんど詳細にはありません。
3. 数量、幅、キャパシティ、レートを入力します。これはBPMNが代わりにやってくれない作業です。
4. 計算し、現状を保存し、一つのレバーを変更して比較します。
5. 結果で意思決定を裏付け、図は文書化のために残します。

ステップ2をステップ1と同じツールで行うと、ツール切替を省けますが、その代わりに生じるのは詳細化の圧力です。文書化に耐える図は三十のアクティビティを持ちますが、計算可能なモデルは十を要します。追加の各アクティビティは五つの入力欄を増やします。

FlowVisualは開始、作業、判断、統合、中止および終了を認識します。プールやレーン、メッセージイベント、サブプロセスマーカー、記法チェックはありません。

「何がかかるか」：ここで得られるのは規格準拠のプロセス文書ではありません。もし品質管理がBPMN-2.0の図を要求するなら、BPMNツールが必要です。それは避けられません。

「何が得られるか」：担当部門は記法ではなくプロセスについてワークショップで議論します。モデルは2時間ではなく10分で成立します。また存在するすべての入力欄は、結果を変えるものです：量、幅、能力、役割、システム、バッチ。

「正直な経験則」：

• 規格や監査を満たす文書が必要であれば → BPMNツール。
• 意思決定者が署名する数値が必要であれば → 計算モデル、記法は二次的。
• 両方必要であれば → 両方を用いるが順序を分け、同一の成果物にはしない。

この比較の詳しい説明は記事「BPMN-Tool mit Simulation」にあります。(/de/blog/bpmn-tool-mit-simulation)