Der Angebotsprozess als fertiges Rechenmodell

開始： 年間550件の問い合わせ、つまり平日1日あたり約2.2件で、日次のばらつきは26％、ピーク日は7％の日に1.35倍の負荷となります。

決定的な所見。 製造設計は1日の業務時間のうち5時間を見積りプロセスに割いています。残りは進行中のプロジェクトに属します。5時間に利用率89％を掛けると267分になり、技術的検討が平均103分であると1日あたり2.6件の処理が可能で、対して到着は2.2件です。理論上は足ります。しかし、繁忙日の場合は足りません。

ストレステストはまさにそのことを示しており、成績ではなく確率として示します。

列の合計は100％になり、これは偶然ではありません。各シミュレーション走行について、その日の最高稼働率を示す単一の拘束ステップを1つだけ数えているためです。したがって「79％」は「79％の稼働率である」という意味ではなく、五日中四日はその手順がスループットを制限するという意味です。

社内でボトルネックと見なされていた見積り作成は、単一の走行でも一度もボトルネックにはなっていません。

1. 1日の問い合わせ数。 過去1年の問い合わせ数 ÷ 営業日数。CRM または見積番号の通番に記載されています。
2. ピーク係数。 最も多い日に、通常日に比べて何件の問い合わせが来るか。見積では展示会や季節によることが多く、1.3〜1.5が一般的です。この値がないと、負荷のかからないプロセスを計算することになります。本当に負荷がかかったときに、見積が期日どおりに出るかどうかが決まります。
3. 設計がこのプロセスに割く時間。 人員数ではありません。重要なのは、技術的に確認する担当者が1日に実際に見積に使える時間の割合で、通常は3〜6時間、8時間になることはありません。
4. 技術確認の所要時間幅。 下限と上限、平均値ではありません。幅が決定要因です：分散は待ち時間に二乗で寄与し、平均値は線形にしか影響しません。
5. 1日に行う承認件数。 日に承認すべき見積がある場合、営業マネージャーは何件を承認するか。この数が承認が第二のボトルネックになるかを決めます。テンプレートでは5日のうち1日でそれが起きます。
6. 役割ごとの総原価率。 総支給額 × 1.5〜1.8、を年間約1 500稼働時間で割ります。年収50 000ユーロの職はこれで約53 €／時となり、給与 ÷ 2 080時間の安直な24 €ではありません。安直な率を使うと、後のユーロ換算が批判される可能性があります。

計算前の確認： 現在保留中の問い合わせ件数を数え、1日に出せる見積件数で割ってください（Little's Law）。それでおおむね既知のリードタイムが出ればモデルは有用です。大きく異なる場合は待ち行列が抜けています。見積ではほとんどの場合、顧客への追加確認や、納入業者の見積を待つ工程が欠けています。

テンプレートに含まれていないもの。 リードタイムは処理時間と待ち行列の合計で、単位は営業日です。納入業者が価格提示に要する3日や、顧客からの折返しの週といった固定のカレンダー時間はモデル化されていません。そうした要素がある場合は別のステップとして入力してください。でなければモデルは顧客の体感よりも早く計算します。

レバー1．問い合わせ登録時の必須項目。 設計が常に尋ねる6つの情報を登録時に入力させます。登録には時間がかかり（15〜30分、従来の10〜22分より長い）、技術確認は短くなります（45〜100分、従来の70〜140分）、問い合わせのやり取りのラウンドが不要になるためです。モデル上の結果：リードタイムのP90は7,2日から1,6営業日に下がり、ピーク日の設計の稼働率は133 %から94 %に下がります。入口での時間はボトルネックでの時間より安価です。以上が要点です。

レバー2．見積プロセスに対する設計時間の増加。 1時間の増加です。効果はありますが期待ほど大きくはありません：ピーク日は133 %から111 %に下がり、技術確認は56 %のランで依然としてボトルネックになります。過負荷の工程は線形に反応しない、という正直な代価です。

レバー3．2人目の設計者を半日配置。 最もコストがかかるレバーで、結果はレバー1とほとんど変わりません。それでも計算する価値がある理由は明らかです：どちらの場合もボトルネックが承認に移動し、そこから先は設計が制約要因でなくなるからです。

レバー4．承認を軽減する。 無意味な結果であり、学びの多い示唆です。承認はピーク日に92 %で2番目に逼迫した工程です；承認能力を倍にしても0,3日しか削減できません。なぜなら技術確認がボトルネックである限り、承認まで十分な処理が到達しないためです。第二のボトルネックに対するレバーは半分の成功ではなく、成功ではありません。

四つをそれぞれ計算し、効果をコスト順に並べてください。レバー1はフォーム、レバー3は人員配置で、モデル上の差は0,3日です。

20 000回のランから各工程の割合がどのように算出されるかは記事「Monte Carloシミュレーション für Prozesse」(/de/blog/monte-carlo-simulation-prozesse)に、P50とP90の差がなぜ本質的な意味を持つかは「P10, P50, P90 verstehen」(/de/blog/p10-p50-p90-verstehen)に記載されています。

現状を保存し、レバーを変更して二度目の実行を行うと、比較は次のものを示します。

• 通過時間の前後比較 をP50とP90として示します。営業へのご提出は中央値ではなくP90に基づいて行います。中央値が0.7だからといって「2日」とお約束なさると、5回に1回は守れないことになります。
• ピーク日の各ステップの稼働率 と、対策後の新しいボトルネック。このモデルでは、最も効果的な二つのレバーで解放に向けて働くと、ボトルネックが解放に移ります。これは対策の通常の帰結であり、エラーではありません。
• スループット を週あたりのオファー件数として、流入件数と比較します。現状では11件中10.3件が外へ出ていきます。差分は損失ではなく、ボトルネックが毎週新たに積み上げる滞留です。
• 年間の人件費影響 を、数量・時間・フルコスト率からの幅として示します。テンプレートは1件あたり約254 €の作業時間で計算しています。年間で941時間が設計に充てられます。
• 前提条件リスト として推定された入力値をすべて示します。文言「サプライヤー価格の待機時間はモデル化していない」は、最も厳しいご質問の矛先を、提示前に和らげます。

出力は二つのPDFです。意思決定者向けの提案書と、追跡可能性のためのドキュメンテーションで、貴社のレターヘッドをご設定済みであればそれが反映されます。

同じテンプレート、二つの問い。 このページは計算上の問いにお答えします：79％がどこから来るのか、そしてボトルネックを解消するとどこに移るのか。もう一つの問い（何を推奨するか、何もしないといくらかかるか）は手法に属し、道具には属しません。これはFlowrefyの分析アーカイブにあり、これらのテンプレートが生まれた手順とともに掲載されています。1つのデータセット、2つの問い、2つの読者層。

• 受注処理 は注文から受注確認までを扱います。分担された役割のケース：個別には余裕があるように見える二つのステップが、同じ人の午後になります。
• 見積プロセス がこのページの内容です。
• 請求書承認 は変動性のケースです。平均では許容量の範囲内ですが、月末にはそれを上回ります。
• クレーム処理 ではボトルネックが社外にあり、率直な推奨は「自動化すること」ではありません。
• 従業員オンボーディング は量が少なく関与者が多く、あるステップが全実行の86％を拘束します。
• ITチケット は分岐を伴う古典的な待ち行列挙動を示します。65％が即時解決、35％が第二レベルへ移ります。

各テンプレートはウェルカムウィンドウのテンプレートを見るから開けます。初めての場合は、ご自身のモデルを開始なさる前に一つ開いておかれることをおすすめいたします。そうなさらないと細かく作りすぎてしまいます。