Excelでのプロセスコスト：ビジネスケースを覆す四つの誤り

Inhaltsverzeichnis+

プロセス改善のビジネスケースは、ほとんどの場合スプレッドシートで作られます。それ自体はまったく問題ありません。問題になるのは、誰かが計算し直すときです。

ここで四つの誤りがあまりにも定期的に現れるため、典型型として扱えます。どれも怠慢ではありません。すべて道具の限界です。

先に一つだけ線引きをしておきます：ここでは計算方法、つまりご自身の表で四つの誤りを見つける方法と、代わりに何を計算すべきかを説明します。もう一方の問い（ボトルネックが年間で何ユーロのコストなのか、その数値を経営陣にどう提示するか）は、プロセスコスト計算機 on Flowrefy.comが答えます。完全原価率、隠れたコスト、削減可能幅まで含めた計算はそちらの方が速いです。数値を提出したいならそちらを使ってください。数値がどうしてそうなるのかを知りたいなら、この先を読み進めてください。

Fehler 1: Mit Mittelwerten rechnen

表には「処理時間：7.5分」とあります。実際にはその処理は4分から25分かかり、もっともよくあるのは6分です。

これは丸めの問題ではありません。非線形な関係では、期待値の結果は期待値の結果とは限りません。これはイェンセンの不等式で、一般には「Flaw of Averages」として知られています。待ち行列は非常に強く非線形です。

実務的に言えば：各処理が正確に7.5分かかるプロセスと、同じ平均だがばらつきの大きいプロセスでは、まったく異なるリードタイムになります。後者の方が明らかに遅くなります。スプレッドシートは両者を同一視します。

見分け方： モデル内の各所要時間が単一の数値になっている。『最短』や『最長』の列がない。

対処法： 所要時間を幅として取得してください。「どれくらいかかりますか？」ではなく「良い日はどれくらいかかり、先月あなたが経験した最悪の場合はどれくらいでしたか？」と尋ねます。

Fehler 2: Bearbeitungszeit mit Durchlaufzeit verwechseln

表は足し算をします：5 + 12 + 8 + 10 = 35分。計算は正しい。ただしそれは顧客が体験するものとは別物を測っています。

顧客が体験するのは：申請は月曜に届き、通知は木曜に来る。35分の作業の間に、郵便トレイ、承認、照会のやり取りで3日間の待ちが存在します。

多くの行政手続きでは、処理時間がリードタイムに占める割合は一桁台前半のパーセントです。したがって処理時間を20％削減しても、リードタイムのごく一部しか短縮されず、それが「20％速くなる」として売られてしまいます。

見分け方： 合計行が『Durchlaufzeit（リードタイム）』となっているが、中身は処理時間の合計である。

対処法： Little's Lawを逆算の照合に使ってください。待機している案件数を数え、日次のスループットで割ります。もしその結果があなたの合計と大きく異なるなら（通常はそうなります）、モデルに待ち行列が抜けています。

Fehler 3: Auslastung im Monatsmittel

表にはこうあります：「事務処理 74％稼働、つまりまだ余裕がある」。

月平均値は最もやさしい指標です。問題を引き起こす要素を隠してしまいます。平均74％のプロセスは、月に5日間は130％で稼働しているかもしれません。まさにその5日間に全ての滞留が発生し、残りの15日でそれを解消します。

さらに非線形効果があります：待ち時間は因子 ρ/(1−ρ) で増大します。74％なら因子は2.8、95％なら19です。両方の状態の平均を取っても意味がありません。関係が曲線的だからです。

見分け方： 表に利用率の数値があるが、それがどの基準日・期間を指すのか書かれていない。

対処法： 90パーセンタイル日の想定で計算してください。もし月次データしかないなら：月間数量を稼働日数で割り、ピーク用に1.4〜1.8の係数を掛け、その想定を文書に明記します。

Fehler 4: Am falschen Schritt sparen

これは最も高くつく誤りで、実際の投資に導くことが多いです。

表はこう計算します：「ステップ4は18分、半分を自動化して9分に短縮、9分×1200件×65€/h = 年間23,400€」。掛け算は正しい。しかし節約は実際には発生しません。

なぜならステップ4がボトルネックでなければ、その加速はスループットに対して何も変えないからです。空いた時間は損益計算書に現れません。実際には実際のボトルネックの前で待ち時間になります。これがTheory of Constraintsの核心であり、導入したツールが「効果がなかった」となる現場の経験です。

逆に、本当のボトルネックを解消すれば、しばしば計算以上の効果が出ます。ただしボトルネックが別の工程に移り、そこで再び足かせになるまでです。

見分け方： ビジネスケースが時間短縮×時給×件数で計算しているが、どの工程がボトルネックかを一言も示していない。

対処法： まず工程ごとの稼働率を計算して並べ替えてください。最も高い値でないものはスループットに寄与しません。それでも意味はあり得ます（品質、エラー率、職務満足など）、その場合はビジネスケースでその理由を明確に示す必要があります。

四つの誤りを並べて

表がそもそもできないこと

上の四点は規律で軽減できますが、構造的に残る問題があります：スプレッドシートは待ち行列を知らないということです。セルを計算するだけで、互いに待つ案件を扱いません。だから改善後に何が起きるか、つまりボトルネックが解消されるとその処理量が次の工程に一斉に流れ、次の工程がボトルネックになる、といったことを見抜けません。

まさにそのためにシミュレーションがあります。個々の案件をモデルに通し、ばらつきやカレンダーを考慮して何百回も試行します。出力は単一の数値ではなく分布になり、批判的な照会に耐えうる結果になります。

提出前のチェック

ビジネスケースを決裁書類に出す前に、以下の四つの質問に文書で答えてください：

1. どの工程がボトルネックか、そしてそれは何で分かるか？
2. 自分が参照しているのは処理時間かリードタイムか？
3. 利用率の数値はどの日を基準にしているか？
4. 削減見込みの幅はどれくらいか、最悪のケースは何か？

この四つに答えられる人はビジネスケースを持っています。答えられない人は単なる表を持っているだけです。