受注処理を完成した計算モデルとして

入力： 年間6 000件の受注、つまり1営業日あたり24件、日ごとのばらつきは24％、ピーク係数は全体の7％の日に1.3です。月初、枠発注、キャンペーンの終了。

「訪問数」列は、このテンプレートがほかと異なる読み方をする最初の手がかりです。ステップ03と04は各受注につき1回ではなく、1,18回実行されます。理由は一行下にあります。承認の15％は問題案件として価格決定に戻り、先に進みません。

決定的な所見。 20 000回の実行から得た各ステップのボトルネック確率：

この列は合計で100,0％になります。各実行では、その日に最も高い稼働率を示す拘束的なステップが正確に1つカウントされます。

信用審査は、受注が最も通過しにくい箇所です。9–18分で照会し、限度額を確認し、承認します。それでも4分の3の実行で拘束ステップになるのは、担当が一人で、すべての受注がその人を通るからです。1日の利用可能時間は370分で、平均処理時間13.2分で割ると28件、到着する24件に対して平均では足ります。ですが30％の日には足りず、そのとき待ち行列は稼働率の上昇よりも速く伸びます。

そして中央の二行は一体として捉えるべきです。 9,7％＋9,7％は実行の19,4％で、図では二つのボックスとして示される一人の人物に束縛されています。これは信用審査に次ぐモデル上の第二の重要なボトルネックであり、独立した行を持っていません。

共有された役割。 承認（ステップ04）と問題案件（ステップ05）はテンプレート上で二つのキャパシティではなく、一つのリソースです：営業責任者、1日6.5時間で稼働率86％、つまり335分です。両ステップがそこから要求するもの：

これは一人分の53％です。個別に測りますと、各ステップに独立したキャパシティを割り当てた場合、そこには**41％と12％**が表示されます。誰も疑問を持たない二つの都合の良い数字です。作業は同じで、異なるのは何に対して割るかだけです。個別には余裕があるように見える二つのステップは、同じ人の午後です。

ですからモデル上の両方のボックスは同じ稼働率を示し、繁忙日には約87％になります。両者は一人を共有し、運命をも共有します。この人がある日欠勤すれば、二つのステップがともに停止し、一つだけが止まるわけではありません。二つの独立したキャパシティを仮定するモデルは、この箇所で決して同じ日に病欠しない二人の上司がいると計算してしまいます。

再作業ループ。 承認の15％は問題案件として価格決定に戻ります。戻るのであって進むのではありません。これは分岐ではなく帰還であり、左から右へ読むだけでは見えない帰結があります。ステップ03と04は受注あたり1/(1 − 0,15) = 1,18回実行され、問題案件自体は0,18回です。

ループがない同じモデルと比較して、それが何を費やすか：

したがってループは受注あたりの工数の約11％と、営業責任者の稼働率の約3分の1を追加で消費しますが、それでもボトルネックではありません。 ここで二つの問いが別れる点が重要です。多くの方が同一視しがちな「これはいくらかかるか？」と「何が遅らせているか？」は、このモデルでは別々の答えを持ちます。テンプレートは両方を計算しており、その違いが主張の半分を構成します。

ループを「ただの例外」だからと省きますと、訪問数、コスト、時間の三つの数字を同時に失います。帰還のないモデルは、実際のプロセスより受注あたり11％安く、0.7日速いと読めてしまいます。

1. 1日あたりの受注数。 受注行または過去1年の受注数 ÷ 営業日数。処理単位と合わせてください：ある受注を12行で一度に入力するなら受注数で計算し、行ごとに確認するなら行数で計算します。どちらも正しく、混在は誤りです。
2. ピーク係数。 最も繁忙な日に通常日と比べて何倍の受注が来るか。月初、枠発注、値引きキャンペーンの終了など。係数は通常1.3〜2です。この値がないと、常に余裕のある内勤を想定し、与信審査がちょうどその日に集中する計算になります。
3. 与信審査が実際に受注に割ける時間。 債権会計の人数ではありません。督促処理や入金照合を兼務している人は、与信審査に7時間丸々使えません。この一つの数値がボトルネックを決めます。
4. 与信審査の処理時間幅。 下限と上限。常連で与信枠内なら2分、新規で情報取得や問合せがあると30分。平均ではなく、この幅が待ち時間を生みます。
5. 照会案件の割合。 テンプレートでは15％。報告書に載っていることは稀ですが、午後に数えればわかります：先月、何件の受注が価格判定のために戻ってきましたか？この値だけが、コスト、稼働率、通過時間のすべてに同時に影響します。
6. 役割ごとのフルコスト率。 総支給額 × 1.5〜1.8 を年約1 500の実働時間で割る。共有役割の率を忘れないでください：テンプレートではリソースに設定され、二つのステップには設定しません。さもないと承認を担当者レートで計算してしまいます。

数値ではない重要な確認項目。 計算前に、ここで実際に誰が人を共有しているかを確認してください。テンプレートでは承認と照会が共有されています。貴社では別の組合せかもしれません。入力と確認が同一担当者、価格判定と承認が同じ営業責任者ということはよくあります。こうした結びつきを入力しないと、1人を計算上2人に分配してしまい、モデルは厳しい役割ではなく二つの余裕のあるステップを返します。

計算前のチェック： ERPの未確定の受注数を数え、1日で確定する受注数で割ってください（Little's Law）。既知の確定時間が出ればモデルは妥当です。大きくずれる場合、待ち行列が抜けています。ここではほとんど常に「顧客の返答待ち」というステータスです。

テンプレートに含まれていないもの。 受注確認でモデルは終わります：ピッキング、出荷、請求は意図的にモデル化していません。別のプロセスで別のキャパシティです。同様に含まれないのは、資材の可用性、顧客への再照会（カレンダー時間で、労働時間ではない）、優先度です。モデルは到着順で処理します。本当に緊急受注を優先するなら、別のブランチと専用のキャパシティで表現してください。

レバー1．与信照会のインターフェース化。 与信情報会社を自動で照会し、限度超過やヒットなしのケースだけ人が判断します。審査時間は9–18分から4–9分に短縮します。効果：リードタイムP90が5,81日から0,28作業日に、繁忙日の稼働率が132 %から65 %に、受注あたりの作業コストが60,85 €から53,96 €に低下します。現場で最も強力なレバーであり、人員を増やさずに済む唯一の対策です。

興味深いのは最後の列です：その結果、最も起こりやすいボトルネックは「価格＆受注確認」で41 %になります。この列だけをご覧になると、より大きな塊を見落とします。承認と照会はそれぞれ25,3 %と25,1 %で、合わせると**全処理の50,4 %**になります。レバー1の後は、ボトルネックは場所ではなく一人の担当者になります。

レバー2．与信審査に第二人員を追加。 実質的に同じ効果（0,30日対0,28日）ですが、半人〜1人分の人件費がかかり、受注あたりの作業コストは変わりません：同じ作業を二人で分担するだけです。レバー1（インターフェース）とレバー2（一人分の人員）の比較がこの表の本質です（差は0,02日）。

レバー3．照会割合を15 %から5 %へ。 明確な価格ルール、条件の登録、あるいはある閾値以下は承認しないとする対策です。効果：受注あたりの作業コストが60,85 €から56,00 €に、分担された役割の稼働率が53 %から40 %に、リードタイムP90が5,81日から5,20日に改善します。良い成果ですが、ボトルネックは解決しません：与信審査が占める割合はむしろ増えます（74,7 %から89 %へ）。競合相手が消えるためです。このレバーは一人の負担を軽くしコストを下げますが、顧客への約束（リードタイム）はほとんど改善しません。

レバー4．分担された役割を解消する。 最初の「効果なし」の所見であり、より厄介な方です。承認を第二の上長に回し、照会は第一の上長に残します。二つのステップはセクション02のゆとりある41 %と12 %になります。リードタイムP90は5,81日から5,31日に下がり、受注あたりの作業コストは60,85 €のまま、与信審査のボトルネック確率はむしろ上昇します（74,7 %から86,6 %へ）：影のボトルネックは消えますが、本当のボトルネックはそのままです。**分担された役割という所見は正しくても、与信審査が前に立ちはだかる限り、それ自体は対策になりません。**対策になるのは、レバー1か2が先に実行された後です。そのとき初めて全処理の半分を占めるようになります。重要なのは選択ではなく順序です。

レバー5．受注入力をEDIまたは顧客ポータル化。 二つ目の「効果なし」の所見で、このプロセス群で最も頻出する提案です：注文がメールで届き手入力されているなら、ポータルやEDIで省力化できます。入力時間は8–17分から3–7分に短縮され、受注あたりの作業コストは60,85 €から54,12 €に下がります。繁忙日のリードタイムは5,81日から5,79日へ。ほとんど変わりません。入力は通常55 %の稼働率、繁忙日で74 %です。プロセスを止めていたことはありません。**対策自体は正しいものの、「これで速くなる」という根拠は正しくありません。**1件あたり6,73 €の節約で、年間6 000件ならそれ自体が十分な根拠になりますが、リードタイム短縮とは別の話です。

五つを個別に計算し、効果対コストで並べ替えてください。二つはリードタイムを動かし、三つはコストまたは稼働率を動かします。どちらも成果ですが、一方を他方として売らないでください。

20 000件の処理から各ステップの割合をどう出すかは記事「Monte Carloのプロセス応用」(/de/blog/monte-carlo-simulation-prozesse)に、なぜ85 %の稼働でも多すぎるのかは「ボトルネックを計算する」(/de/blog/engpass-berechnen)に解説があります。

現状を保存し、ある変更されたレバーと二度目のシミュレーションを行うと、比較は次のことを示します。

• 前後の処理時間 を P50 と P90 で表示します。中央値は 0.16 労働日を示します。これに基づいて営業が「同日確認」を約束しますと、10 回に 1 回は誤りで、その誤差はほぼ 6 労働日になります。約束は中央値に対してではなく P90 に対して行うべきです。
• 山場の日における各ステップの稼働率 と、対策後の新しいボトルネックです。このモデルでは、5 つのレバーのうち 2 つでボトルネックが「価格・受注確認」に移動し、その後ろにより大きな塊を持つ共有ロールが待ち構えています。
• 共有リソースごとの稼働率（ステップとは分離）。これはステップ行では示せない数値です：営業責任者の 335 分中 178 分が、2 箇所のボックスに分配されています。
• スループット は週間あたりの確定受注数と受注入力数の比較です：現状では 112 に対して 120。差の 8 件が毎週新たに滞留します。
• 受注あたりの労働時間コスト と年間コストを、量・時間・完全原価率から算出します。テンプレートは受注あたり 60.85 € を計算し、そのうち 6.90 € が照会ループに充当されます。
• 想定一覧 には推定したすべての入力が含まれます。「ピッキング、発送、請求処理はモデル化していない」という文言は、最も厳しい追及の先手を打ちます。

出力は 2 部の PDF です：意思決定者向けの提案書と、追跡可能性のためのドキュメント。差し込み用ヘッダーを登録していればそれが使われます。

同じテンプレート、二つの問い。 本ページは計算の問いに答えます：74.7 % がどこから来るのか、なぜ二つのボックスが同じ稼働率を示すのか、そして時間とコストを 15 % 戻すにはいくらかかるのか。もう一つの問い（何を推奨するか、信用照会を三日待つ受注のコストはいくらか）は方法論に属し、ツールの範囲ではありません。それは Flowrefy の分析アーカイブ にあり、これらのテンプレートが生まれた 手順 とともに掲載されています。データセット一つ、問い二つ、公開先二つ。

• 受注処理 がこのページの主題です。ギャラリーの最初のカードであり、共有ロールと手直しループを含む唯一のケースです。
• 見積もりプロセス は、処理時間がコストではなく売上に影響するケースです。
• 請求承認 は変動性のケースです：平均では容量内に収まり、月末には超過します。
• クレーム処理 ではボトルネックが社外にあり、そのため誠実な推奨は「自動化する」ではありません。
• 従業員オンボーディング は量が少なく関係者が多く、あるステップが 86 % の実行を占めます。
• IT チケット は分岐があるケースです：65 % が即時解決、35 % がセカンドレベルに回ります。

各テンプレートはウェルカムウィンドウの テンプレートを見る から開きます。最初はご自身のモデルを作り始める前に一つ開いておくことをお勧めします。そうしないと細かく作り込み過ぎてしまいます。