業務プロセスをシミュレーションする:実践的なガイド
業務プロセスをシミュレーションする価値があるのは、処理が待ちになる場面、すなわち承認、申請、クレーム、見積もり、オンボーディング、サービスチケットのような業務です。効果はモデルの精密さからではなく、表では得られない三つの示唆から生まれます:どのステップがスループットを制限するか、対策後にボトルネックがどこへ移るか、そしてその対策がユーロでいくらの価値があるかであり、いずれも範囲(幅)で示されます。最初の取り組みには、範囲が明確なプロセス、5〜10のステップ、各ステップにつき三つの数値、そしておよそ半日が必要です。よくある誤りは、細かすぎるモデル、平均値での計算、複数の対策を同時に試すこと、そして前提を明示しない結果です。
Inhaltsverzeichnis
シミュレーションは製造業で長年の評判を築いてきました:モデル構築に数週間、専門家のノウハウ、理解できるのは三人ほどの報告書です。しかし業務プロセスでは事情が異なります。そこでは手間は半日程度、成果は意思決定会議で使える一枚の紙です。
必要なことはここにまとめてあります。
企業でシミュレーションが役に立つこと
ドキュメント化のためではありません。コンプライアンスのためでもありません。役立つのは正確に三つの判断です:
1. 本当にどこが詰まっているのか? ボトルネックは最も稼働率の高いステップであり、最も遅い工程でも最も騒がしい工程でもありません。文句を言う人はしばしばボトルネックの「後ろ」に座っており、仕事が塊で届きます。
2. それを解決すると何が起きるか? ボトルネックは移動します。ステップ2が114%の稼働率にある間、ステップ3は余裕があるように見えます。ほとんど仕事が回ってこないからです。ステップ2を解決するとステップ3に仕事が一気に来ます。この連鎖効果が自動化プロジェクトが目標値を達成できない最も一般的な理由です。
3. それはユーロでいくらの価値か? 「速くなる」ではなく、出どころのわかる数値、レンジとして、前提を明記したものです。
それ以外(見映えのよい図、完全なプロセスマップ、規格準拠の表記)は別のツールの仕事です。
どんなプロセスが向いているか
目安:業務がかごに溜まり誰かを待っているところならどこでも。
| プロセス | 向いている理由 | 典型的な所見 |
|---|---|---|
| 請求書承認 | 多くの関係者、承認が副次作業で行われる | 事務的承認がボトルネックであり、入力作業ではない |
| 見積りプロセス | リードタイムが売上に影響し、費用ではない | 原価計算と社内承認が足かせになっている |
| クレーム対応 | 問い合わせが二重の待ちを生む | 問い合わせ対応がボトルネックであり、処理自体ではない |
| 申請・承認手続き | 固定したキャパシティ、変動する投入 | ピーク日がリードタイムを決める |
| 社員オンボーディング | 関係者多数、ボリュームは小さく予定が連鎖する | 予定待ちの時間が問題であり、処理時間ではない |
| ITチケット/サービスデスク | 優先度付けとエスカレーション | セカンドレベルが制約ステップである |
| 採用プロセス | 複数カレンダーでの日時調整 | 返答までの時間が辞退を決める |
向かない例: キャパシティのかなり下で稼働し滞留がないプロセス。そこでは処理時間がそのままリードタイムになり、単純な加算で十分です。待ちがなければシミュレーションする意味はありません。
最終的に紙に載るもの
意思決定会議が受け入れる結果は四つの要素から成ります:
- 稼働率の順位付け、月平均ではなくピーク日の観点で算出します。
- P50とP90によるリードタイムのレンジ。 約束はP90に対して行います;中央値を約束すると半分の確率で破られます。
- ひとつの施策の効果、前後比較で時間とユーロ換算、そしてその後ボトルネックがどこに移るかの明記。
- カバーされていない事項の一覧。 「サプライヤーへの再確認はモデル化していない」という一文が、最も鋭い問い合わせの先制を防ぎます。
項目4が欠けると問いは必ず来ます。ただし会議の場で、返答なしに来ます。
最初の取り組みを現実的に計画する
| ステップ | 工数 | 誰が |
|---|---|---|
| 一文で範囲を定義 | 30分 | プロセス責任者 |
| おおまかなフローを取る、5–10ステップ | 1時間 | 業務部門、共同作業 |
| 各ステップに三つの数値を用意 | 2時間 | 業務部門、コントローリング |
| モデル構築と実行 | 30分 | 1名 |
| 施策を個別に試算 | 1時間 | 同じ人 |
| 結果を整理 | 1時間 | 同じ人 |
純粋な作業で半日程度、カレンダー上は約一週間に分散します。データ収集がボトルネックであり、計算ではありません。範囲の定義が争点になる場合、それが本当の作業です;その場合は正当に時間がかかります。
取り組みを失敗させる四つの誤り
1. 詳細にやりすぎる。 8ステップの代わりに30ステップ。追加のアクティビティごとに五つの入力欄が増え、ボトルネックは移りません。ボトルネックは最も稼働率の高い箇所にあり、それは大まかでも細かくても同様に見えます。
2. 平均値で計算する。 月平均で70%、月初に130%というプロセスは平均値が問題を隠します。90パーセンタイルの日で計算してください。
3. 三つの施策を同時に変える。 結果がどの施策に起因するかが分からなくなります。そうなるとビジネスケースは成立せず、数値だけの主張になります。
4. 単一値を出す。 「リードタイムが43.7%短縮」には反論が生まれます。「P50が6.1日から3.4日に、P90が14日から7日に、前提は付録参照」という表現は反論されにくいです。
どのツールを使うか
簡潔に:詳しい解説は四カテゴリの比較にあります。
- 描画ツール(Visio、Lucidchart、draw.io)はドキュメント化はするが計算はしません。
- BPMスイート(Signavio、ARIS、Bizagi)は企業全体のプロセスを管理します;シミュレーションは多機能の一モジュールです。
- シミュレーションラボ(Arena、Simul8、AnyLogic、FlexSim)は最も強力な計算エンジンを持ち製造業由来です。設備には適切ですが承認プロセスには扱いにくいことが多いです。
- 意思決定支援ツールはFlowVisualのように計算の深さを抑え、数時間で前後比較をユーロで提示します。
カテゴリが重要であり、機能一覧だけで決まるものではありません。最初の取り組みでは何よりも「実際にやること」が決め手です。
要約
- シミュレーションは業務が待ち状態になる箇所で有効であり、ドキュメント化のためではありません。
- 利益は三つの判断に集約されます:ボトルネック、移動、ユーロでの価値。
- 最初の取り組みは純作業で半日、データ収集がボトルネックです。
- 5–10ステップ、ピーク日での評価、施策は一つずつ、結果は前提付きのレンジで示してください。
よくある質問
どの規模の会社でプロセスシミュレーションが有益ですか?
規模は誤った指標です。重要なのは案件が待つかどうかです。従業員40人で月1 200件の請求書がある事業は、量と能力の比率が同じなら大企業と同じ滞留を持ちます。逆に大企業でも限界をはるかに下回っているプロセスはあります。そうしたところではシミュレーションは不要です。
結果はどれくらい正確ですか?
入力と同じ精度です。そのため結果は幅として提示されます。利得は絶対値ではなく、同じ仮定の下で二つの状態を比較する点にあります。同じ仮定が両方の実行に入っていれば、比較ではそれが相殺されます。だから「この施策は年間78 000〜121 000ユーロを節約する」という表現は「プロセスのコストは412 000ユーロである」よりも信頼できます。
そのためにERPのデータが必要ですか?
役に立ちますが必須ではありません。各ステップについて必要なのは三つの数値です:量、処理時間の幅、処理能力。ボリュームはERPやチケットシステムにあり、処理能力は人員計画にあり、処理時間は別々の三人の担当者に尋ねてその回答から幅を作って得ます。推定は、前提として明示される限り許容されます。
誰がモデルを作るべきですか?
一人が現場で、担当部門の前でライブで作成するべきです。三人を順に面談するのではありません。共同でのモデリングの価値は対立にあります。ワークショップで出た修正は、最終報告の場ではもう出てきません。最後には、結果を議論する前に全員が同意したモデルが出来上がります。
もし結果が私たちの経験と矛盾したらどうしますか?
まずモデルを現実と照らして検証してください。在庫を数え、日次スループットで割り(Little's Law)、既知のリードタイムと比較します。大きくずれているなら、待ち行列が抜けています。多くは問い合わせや二段階目の承認です。突合せが合っていても結果がなお矛盾する場合、それこそがこの取り組みの本当の成果です。
ご自身のプロセスで計算してみてください。
FlowVisualはこの記事の数値を、お客様の処理量、お客様の処理能力、お客様の利益幅を用いて実行されるモデルにします。
Guide: seven steps to the number- 手法
Excelでのプロセスコスト:ビジネスケースを覆す四つの誤り
ほとんどすべてのプロセス最適化のビジネスケースはExcelで作られます。そしてほとんどすべてに同じ四つの誤りが含まれます。これは注意不足ではなく、表計算が構造的に特定の事柄を表現できないためです。
読書 - 手法
Prozess simulieren: acht Schritte mit durchgerechnetem Beispiel
順序は道具よりも重要です。八つのステップ、計算済みの具体例と、モデルに待ち行列が欠けていることに気づくための検算。
読書 - 手法
プロセスシミュレーションとは何ですか。定義、手法、限界
プロセスシミュレーションは、プロセスを記述する代わりに人工的に実行させます。この違いは学問的なものではありません。変更について意見を持つだけなのか、数値を得られるのかを左右します。
読書