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

Eingang: rund 1 200 Rechnungen im Monat, also etwa 60 an einem Arbeitstag, mit Spitzenfaktor zum Monatsende。

Der entscheidende Befund: Die Summe der Bearbeitungszeiten liegt bei 20 bis 30 Minuten je Rechnung, die tatsächliche Durchlaufzeit bei acht bis zwölf Arbeitstagen。Zwischen beiden liegen rund drei Grössenordnungen, und diese Lücke besteht fast vollständig aus Wartezeit、überwiegend vor der sachlichen Freigabe。

Der Grund ist strukturell und hat nichts mit Nachlässigkeit zu tun： Freigeben ist kein Vollzeitjob、sondern eine Nebentätigkeit von vierzehn Personen。Daraus folgen sehr hohe Streuung (zehn Minuten oder sechs Tage) und fehlende Vertretung。Zwei Eigenschaften、die zusammen die Wartezeit erzeugen。

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です。

この例の詳しい解析は記事「Rechnungsfreigabe: warum OCR die Durchlaufzeit nicht halbiert」に掲載されています。(/de/blog/rechnungsfreigabe-engpass)

現状を固定し、あるレバーを変更してもう一度実行すると、比較結果は以下を示します：

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

出力は2つのPDFになります：意思決定者向けの提案書と、追跡可能性のためのドキュメントです。貴社のレターヘッドを登録している場合はそれを使用します。

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

各テンプレートはウェルカムウィンドウの「Vorlagen ansehen」から開きます。初回は、自分のモデルを始める前にひとつ開いてみる価値があります。そうしないと細かく作り込みすぎてしまいます。