Prozess simulieren: acht Schritte mit durchgerechnetem Beispiel

Inhaltsverzeichnis+

この手順はツール非依存です：シミュレーションラボでも、Pythonライブラリでも、簡素な意思決定ツールでも同様に機能します。FlowVisual向けのキーボード中心版は実践ガイドにあります。

ステップ 1：範囲を一文で定める

「請求書の受領から支払承認まで。」

この一文が関係者全員に署名できるものでなければなりません。これがないと、二つの部門が別のプロセスについて議論し、なぜ数字が合わないのか不思議に思います。

この一文が欠けている場合、それを決めること自体が本来の作業であり、計算ではありません。

ステップ 2：大まかに分解する、5〜10ステップ

30ステップではありません。ボトルネックは最も稼働率が高い箇所にあり、大まかなモデルでも詳細なモデルでも同様に見えます。不要な活動を追加するたびに入力項目が5つ増え、結果はほとんど動きません。

三つのルール：

• 実際に分岐する箇所にのみ分岐を置くこと、各枝ごとに割合を指定します。
• プロセスを離れるものはすべて中断として扱うこと：取り下げ、却下、失効など。中断を書かないと到達しない量で計算してしまいます。
• 待ち時間はステップではない。 キャパシティが逼迫するとモデル内部で自動的に発生します。「滞留時間 3日」をステップとして登録すると、計算する代わりに結果を先取りしてしまいます。

ステップ 3：各ステップに三つの数値

範囲について：「5〜15分」は「平均10分」より良い指定であり、現場も答えやすいです。ばらつきは不正確さではなく、待ち行列の原因です。

**キャパシティについて：**フルタイム1人当たり生産的時間を7時間で計算してください、8時間ではありません。会議、問合せ、中断は処理時間ではありません。

ステップ 4：到着ストリームを記述する

もっとも省略されがちで、かつ影響が大きいステップです。三つの指定：

• 1日あたりの平均件数。
• **変動：**処理は均等に来るか、塊で来るか。
• **ピーク係数：**繁忙日はどれほど増えるか。月末や週初めで、係数1.5〜2が一般的です。

平均だけで計算すると、負荷がかからないプロセスをシミュレートすることになり、現場では存在しない短いリードタイムが出てしまいます。

ステップ 5：計算させる、何百回も

単一の実行はサンプル1つに過ぎません。新しい乱数で繰り返すことで、求めるべき結果、つまりP10、P50、P90が読める分布が得られます。

必要な出力：スループット、レンジとしてのリードタイム、各ステップの稼働率、待ち行列長。

ステップ 6：対照検証

Little's Lawは最も手軽な検証で、分布に関する仮定を必要としません：

リードタイム W  =  在庫 L  ÷  スループット λ

現在待っている件数を数え、日次スループットで割って、モデルの出力と比較してください。

• **概ね合っている場合：**先に進みます。
• **モデルが明らかに現実より速い場合：**待ち行列が抜けています。ほとんどの場合、追加の問合せ、二段階承認、あるいは一括処理が原因です。
• **モデルが明らかに遅い場合：**キャパシティを過小評価しているか、割合を取り除く分岐を見落としています。

ステップ 7：一つのレバーを変える

現状を保存してください。次にちょうど一つだけ変更します：

• キャパシティを増やす
• ばらつきを減らす（処理を種類ごとに分ける、入力を平準化する、問合せを減らす）
• 件数を迂回させる（価値基準、抜き取り検査にする）
• ステップを自動化する

再計算して比較します。次のレバーに移る前に元に戻して一つずつ行ってください。三つ同時に変えると、どのレバーの効果か分からなくなります。

ステップ 8：仮定とともに書き残す

四つの構成要素：ピーク日の稼働率の順位、P50とP90としてのリードタイム、レバーの効果（時間とユーロ）および新しいボトルネック、そしてカバーしていない項目の一覧。

完全な計算例

例示モデル、顧客データではありません。

**プロセス：**返金申請の処理。1営業日あたり80件、月初にピーク係数1.6。

**第一の読み：**ボトルネックは承認（93 %）で、内容確認（89 %）が僅差です。三つとも85 %を超えています。つまり待ち時間はすでに処理時間の何倍にもなっており、ピーク係数1.6の時は三つとも100 %を超えます。

**シミュレーション結果：**リードタイム P50 = 4.8日、P90 = 11.2日。処理時間の合計は13〜31分。25分と4.8日の間に本質的な問題があります。

**対照検証：**平均で受信トレイに390件、スループット80/日 → 4.9日。一致します。

**レバーA：内容確認に0.5人増員：**P50は3.9日に、P90は8.4日に低下。ボトルネックは承認（93 %）に明確になります。

**レバーB：承認を兼務ではなく固定の担当にする：**P50は3.1日に、P90は6.0日に。承認ステップのばらつき低減がより大きなレバーでしたが、人件費は不要でした。

**レバーC：支払を週2回から毎日にする：**P50が0.7日短縮、実質的にコストはほとんどかかりません。

**効果対努力の順位：**C、B、A。典型的な答えである「人員を増やす」は最後に来ます。

五つの高コストな誤り

1. **待ち時間をステップとして登録すること。**これにより結果を先取りしてしまいます。
2. **平均値で計算すること。**ばらつきがなければ待ち行列は生じず、現実的なリードタイムは得られません。
3. **ピーク日を無視すること。**平均で85 %のプロセスはピーク日には100 %を超えます。そこに蓄積が発生し、何週間も続きます。
4. **過度に細かくモデル化すること。**30ステップでも同じ答えで、手間は3倍になります。
5. **対照検証なしに公開すること。**Little's Lawは5分ででき、信頼性を守ります。