従業員オンボーディングの完成済みの計算モデル

流入： 年間260件の入社、つまり1営業日あたり約1.05件、日ごとのばらつきは30％、ピーク因子は全体の6％の日で1.4です。採用は等間隔ではなく波のように来ます。

決定的な所見。 1日1件の処理というとボトルネックは発生しないように思えます。計算は別のことを示します：2.5時間に利用率92％は138分です。平均して1件あたり110分なら、これは1日あたり1.3件の処理能力で、流入の1.05件に対して余裕があります。これは、ある日の需要がその日のキャパシティを超えない限り成立します。内定が重なるため、全体の28％の日でそれを上回ります。

この列は合計して100％になります：各実行につき、その日の中で最も負荷が高い1つの拘束工程だけが数えられます。「86％」は「86％の稼働率である」という意味ではありません。この数値は隣にあり、平均では86％ですが、負荷の大きい日には134％になります。

キャパシティは在席時間ではありません。 ITは一日中在席していますが、オンボーディングに使えるのは2.5時間です。人数だけを記入して時間を記入しないと、決してボトルネックにならないプロセスを計算してしまい、初出勤日にノートパソコンがないことに驚かれます。

1. 1営業日あたりの入社数。 過去1年の入社数 ÷ 営業日数。人事部に記載がございます。小規模な組織では新しい人事番号の数で十分でございます。
2. ピーク係数。 採用は波でやってまいります。入社時期、四半期の開始、新しいチームなど。最も多かった月において、通常日と比べて1日に何件の入社が集中するかを示します。1.4〜2が一般的でございます。この値がない場合、負荷がかからない前提でプロセスを計算してしまい、まさにプロセスが破綻するその週を見落としてしまいます。
3. ITがオンボーディングに割ける時間。 ITの人数ではなく時間でございます。重要なのは、通常業務の合間に実際にセットアップに充てられる1日あたりの時間で、概ね2〜4時間でございます。
4. ITセットアップの処理時間の幅。 下限と上限であり、平均値ではございません。「標準的な作業環境」と「3つの専門アプリが必要な特殊ケース」の差がまさにこの幅であり、待ち時間に対して平均値よりも強い影響を与えます。
5. 1日に作成できる受け入れ計画の数。 必要なときにチームリーダーが1日にいくつ作成できるかです。テンプレートでは1.8で、この工程は全シミュレーションの13％で2番目のボトルネックになります。ほとんど測定されておりません。
6. 役割ごとのフルコスト率。 総支給額 × 1.5〜1.8 ÷ 年間約1,500時間の生産時間。年収50,000ユーロのポジションは1時間あたり約53€となり、給与 ÷ 2,080時間で得られる素朴な24€とは異なります。

計算前のクロスチェック： 入社初日に何かが欠けていた、直近12週間の入社件数をお数えください。その割合がモデルが示す能力超過日（キャパシティを超えた日）の割合に近ければ、そのモデルは有用でございます。

テンプレートに含まれていない、そしてここが最も影響が大きい点でございます。 リードタイムは、処理時間に加えて、作業日ベースの待ち行列から成ります。カレンダー依存の連鎖（署名済み契約書の返送、ノートPCの納期、安全教育の予定）はモデル化されておりません。実務では、これらがオンボーディングの所要時間の大部分を占めることが多うございます。これらが判明している場合は、個別の待ち工程としてご入力ください。そうすれば、モデルは新入社員が実際に経験する週数を計算し、背後の作業量だけでなく実際の経過時間を反映いたします。

レバー1. オンボーディングにITの時間を増やす。 1日1時間の追加を、期待ではなく取り決めとして確保します。リードタイムのP90は9.6営業日から2.7営業日に、ピーク日の稼働率は134 %から96 %に下がります。必要なのは人員ではなく取り決めです。その1時間が実際に確保される限り、費用対効果が最も高いレバーです。

レバー2. 個別作業ではなく標準イメージ。 最も多い3つの役割向けに、あらかじめ用意したイメージを使います。セットアップは75–150分から40–80分に短縮されます。効果：P90は9.6営業日から1.0営業日に、ピーク日の稼働率は134 %から71 %に、入社1件あたりの作業コストは€243から€188に下がります。キャパシティではなく処理時間に手を入れるため、時間と費用の両方を動かす唯一のレバーです。

レバー3. ITに2人目。 最も高価なレバーで、結果はレバー2より弱くなります。それでも計算すると理由が分かります。半人分の追加はキャパシティを倍にしますが、作業そのものは変わらず110分かかります。作業を短くする方が、人手を増やすより効きます。

レバー4. 受け入れ計画を速める。 効果なしの所見です。受け入れ計画はピーク日に87 %で2番目に逼迫したステップで、実行の13 %でボトルネックになります。それでもタクトをほぼ倍にして得られるのは0.2日です。ITが制約になっている間は、チームリーダーのもとに十分な仕事が届かないからです。2番目のボトルネックに効くレバーは、半分の成功ではなく、成功ではありません。

注目すべきは逆方向の動きです。4つのレバーのうち3つで、ボトルネックは受け入れ計画、つまり今日誰も原因だと思っていないチームリーダーへ移ります。各ステップを個別に計算する表には、まさにこの波及効果が現れません。

20,000回の実行からステップごとの割合がどう出るかは記事プロセスのモンテカルロ・シミュレーションに、P50とP90の差こそが本質である理由はP10・P50・P90を理解するにあります。

「前の状態をキャプチャ」のあと、レバーを1つ変えて2回目を実行すると、ページ見出しの「証明」に次が表示されます：

• 処理時間（前後） をP50とP90で表示します。関係部門への約束は中央値ではなくP90に基づいて行います。中央値が1.3日だからといって「初日ですべて揃う」と約束なさると、10回に1回は守れない約束になってしまいます。
• 各工程の稼働率（ピーク日の値） と、対策後の新しいボトルネック。このモデルでは、4つのレバーのうち3つでボトルネックが研修計画に移動します。
• スループット を週あたりの入件数として、到着数に対する比率で示します。現状では5.3に対して4.9です。
• 1件あたりの労働時間コスト と年間コストを、数量・時間・総原価率から算出します。テンプレートでは1件あたり約243 €、そのうち年間でITに477時間を見込んでいます。
• 前提条件リスト と、推定したすべての入力値。「ハードウェアの納期はモデル化していない」という一文が、最も厳しい追及の先手を打ちます。

出力は2つのPDFです：意思決定者向けの提案書と、追跡可能性のためのドキュメント。無料では試用マーク付き、Proでは透かしなしで自社のレターヘッド入りになります。

同じテンプレート、2つの問い。 本ページは計算上の問いに答えます：86％がどこから来たのか、そしてボトルネックを解消したときにどこへ移動するのか。もう一つの問い（何を推奨するか、非生産的な最初の1週間のコストはいくらか）は手法に関するものでありツールの範囲外です。その内容はFLOWREFYの分析アーカイブにあり、これらのテンプレートが生まれた手順とともに掲載しています。1つのデータセット、2つの問い、2つの読者層です。

• 受注処理は注文から受注確認まで進行します。役割が分割されるケースでは：個別には簡単に見える二つのステップが同じ人の午後に当たります。
• 見積プロセスはリードタイムがコストではなく売上に影響するケースです。
• 請求書承認は変動性のあるケースです：平均では処理能力の下にあり、月末ではそれを超えます。
• クレーム処理ではボトルネックが社外にあり、そのため率直な推奨は「自動化しないこと」です。
• 「Mitarbeiter-Onboarding」はこのページです。
• ITチケットは分岐を伴う典型的な待ち行列の挙動を示します：65 % が即時解決、35 % が第2レベルに回ります。

各テンプレートは、紹介シートの「テンプレートを参照」またはメニューの「ファイル」→「テンプレート…」から開けます。初めての場合は、自分のモデルを作り始める前に一つ開いておくことをおすすめいたします。そうしないと細かく作り過ぎてしまいます。