請求書承認の完成済み計算モデル

到着： 月に約1,200件の請求書、つまり1営業日あたり約60件で、月末にピーク係数がかかります。

決定的な所見： 処理時間の合計は請求書1件あたり20〜30分ですが、実際のリードタイムは8〜12営業日です。両者の間にはおよそ3桁の開きがあり、その差はほぼすべて待ち時間で、大半は内容の承認の前に生じています。

原因は構造的なもので、怠慢とは関係ありません。承認はフルタイムの仕事ではなく、14人の兼務です。そこから非常に大きなばらつき（10分のこともあれば6日のこともある）と代理の不在が生じます。この2つが重なって待ち時間を生みます。

1. 「1日の処理量」。過去1年の請求書受領数 ÷ 稼働日数。買掛金会計またはERPレポートに載っています。
2. 「ピーク係数」。最も忙しい日に、通常日と比べて請求書が何倍来ますか。多くは月末で、係数は1.5から2が一般的です。この値がないと、常に負荷のかからないプロセスとして計算してしまいます。
3. 「会計部門の処理能力」。人数 × 1日の実働時間。経験則：持ち席比率 × 7時間であり、×8時間ではありません。会議、照会対応、中断は処理時間に含みません。
4. 「承認者の人数」。実務上承認する人数は何人ですか。この数値は他のどの要素よりもばらつきを決めます。
5. 「承認の頻度」。承認者は平均してどれくらいの頻度で自分のトレイを確認しますか？毎日、週2回、不定期か。承認そのものの所要時間ではなく、処理の間隔として入力してください。
6. 「各ロールの総原価率」。総支給額 × 1.5から1.8 を、年間約1,500の実働時間で割ります。例えば年収50,000ユーロのポジションはこれで約53€/時間になり、給与÷2,080で出る単純計算の約24€とは異なります。単純な算出で入力すると、後のユーロ換算が批判される可能性があります。

「計算前の確認」：現在待機中の請求書数を数え、それを1日の処理量で割ってください（Little's Law）。そこから得られる既知のリードタイムと概ね一致すればモデルは有用です。大きくずれる場合は待ち行列が欠落しています。多くは仕入先への照会や、一定金額以上で第2承認段階が必要なケースです。

レバー1．受領書類認識（OCR）による入力。 入力時間を大幅に短縮します。計算してみると、承認工程に何が起きるかがわかります：承認はこれまでの制限された量ではなく全量を受け取るようになり、承認自体がボトルネックになります。処理時間は入力時間ほどは短くなりません。この効果こそが自動化プロジェクトのビジネスケースが成立しない最も一般的な理由です。

レバー2．金額閾値による事務的承認。 閾値以下の請求書は個別承認を行わず、代わりに事後の抜き取り検査を行います。これは承認の量を減らすので時間ではなく、待ち時間が発生する箇所に効果があります。

レバー3．代理ルールとプール。 承認を速めるのではなくばらつきを減らします：不在時は固定の代理人、個人ごとのバスケットではなく部門ごとの共通バスケットを使用します。待ち時間はばらつきの二乗で増加します。ばらつきを半分にすれば、その寄与は4分の1になります。

レバー4．支払処理を週2回ではなく毎日に。 最もコストの低いレバーで、多くは設定変更だけで済みます。平均して約1日分の短縮になります。

4つのレバーを個別に試算し、効果を工数で並べ替えてください。この種のモデルではほとんどの場合、レバー2か3がレバー1よりも効果が大きくなります。しかし市場で提供されているのはレバー1です。

この例の詳しい評価は記事請求書承認：OCRでリードタイムが半分にならない理由にあります。

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

• 変更前後の処理時間 をP50とP90で表示します。約束は中央値ではなくP90に対して行います。
• ピーク日の各工程の稼働率 と、対策後に生じる新たなボトルネック。
• 年間人件費への影響 を幅として示します。これは件数、時間、総原価率から算出します。
• 想定一覧 として、推定入力のすべてを記載します。たとえば「サプライヤーへの照会はモデル化していない」という一文は、最も厳しい照会が実際に行われる前にその突っ込みの鋭さを和らげます。

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

• 受注処理は注文から受注確認までの流れです。役割が分割されているケース：個別には簡単に見える二つのステップが、同じ人の午後に重なることがあります。
• 見積プロセスは問い合わせから送付済み見積りまでの流れです。リードタイムがコストではなく売上に直接影響するケースです。
• 「Rechnungsfreigabe」はこのページです。
• クレーム処理ではボトルネックが社外にあり、したがって正直な推奨は「自動化しない」です。
• 従業員オンボーディングは関係者が多く、件数は少なくばらつきが大きいです。予定のつながりがリードタイムを決めるケースです。
• ITチケットは分岐を伴う典型的な待ち行列挙動を示します：65％が即時解決、35％が第二レベルへ進みます。

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