Prozesskosten in Excel: vier Fehler, die jeden Business Case kippen

Der Business Case für eine Prozessverbesserung entsteht fast immer in einer Tabelle. Das ist völlig in Ordnung — bis jemand nachrechnet.

Vier Fehler tauchen dabei so regelmäßig auf, dass man sie als Bauform bezeichnen kann. Keiner davon ist Nachlässigkeit. Alle vier sind Grenzen des Werkzeugs.

Fehler 1: Mit Mittelwerten rechnen

In der Tabelle steht „Bearbeitungszeit: 7,5 Minuten“. In Wirklichkeit dauert der Vorgang zwischen 4 und 25 Minuten, meistens 6.

Das ist kein Rundungsproblem. Bei nichtlinearen Zusammenhängen ist der Erwartungswert des Ergebnisses nicht das Ergebnis des Erwartungswerts — die Ungleichung von Jensen, populär als „Flaw of Averages“ bekannt. Und Warteschlangen sind hochgradig nichtlinear.

Praktisch heißt das: Ein Prozess, in dem jeder Vorgang exakt 7,5 Minuten dauert, und ein Prozess mit demselben Mittelwert aber breiter Streuung haben völlig verschiedene Durchlaufzeiten. Der zweite ist deutlich langsamer. Die Tabelle sieht beide als identisch an.

Erkennungszeichen: Jede Dauer im Modell ist eine einzelne Zahl. Es gibt keine Spalte „von“ und „bis“.

Was hilft: Dauern als Spanne erheben. Fragen Sie nicht „wie lange dauert das?“, sondern „wie lange dauert es an einem guten Tag, und wie lange im schlimmsten Fall, den Sie letzten Monat hatten?“.

Fehler 2: Bearbeitungszeit mit Durchlaufzeit verwechseln

Die Tabelle addiert: 5 + 12 + 8 + 10 = 35 Minuten. Die Rechnung stimmt. Nur misst sie etwas anderes als das, was der Kunde erlebt.

Der Kunde erlebt: Antrag geht Montag ein, Bescheid kommt Donnerstag. Zwischen den 35 Minuten Arbeit liegen drei Tage Warten — in Postkörben, vor Freigaben, in Rückfrageschleifen.

In den meisten Verwaltungsprozessen liegt der Anteil echter Bearbeitung an der Durchlaufzeit im niedrigen einstelligen Prozentbereich. Ein Business Case, der 20 % der Bearbeitungszeit einspart, spart also einen Bruchteil eines Bruchteils der Durchlaufzeit — während er als „20 % schneller“ verkauft wird.

Erkennungszeichen: Die Summenzeile heißt „Durchlaufzeit“, ist aber die Summe der Bearbeitungszeiten.

Was hilft: Little's Law als Gegenprobe. Zählen Sie die wartenden Vorgänge und teilen Sie durch den Tagesdurchsatz. Weicht das Ergebnis stark von Ihrer Summe ab — und das tut es —, fehlen in Ihrem Modell die Warteschlangen.

Fehler 3: Auslastung im Monatsmittel

Die Tabelle sagt: „Sachbearbeitung 74 % ausgelastet, also noch Luft.“

Der Monatsmittelwert ist die freundlichste aller Kennzahlen. Er verbirgt genau das, was schiefgeht. Ein Prozess mit 74 % im Mittel kann an fünf Tagen im Monat bei 130 % stehen — und an genau diesen fünf Tagen entsteht der gesamte Rückstau, den die restlichen 15 Tage danach abarbeiten.

Dazu kommt der nichtlineare Effekt: Wartezeit wächst mit dem Faktor ρ/(1−ρ). Bei 74 % ist das der Faktor 2,8. Bei 95 % ist es 19. Ein Mittelwert über beide Zustände ist keine sinnvolle Zahl, weil der Zusammenhang gekrümmt ist.

Erkennungszeichen: In der Tabelle steht eine Auslastungszahl ohne Angabe, worauf sie sich bezieht.

Was hilft: Mit dem 90.-Perzentil-Tag rechnen. Wenn Sie Ihre Mengen nur monatlich haben: Monatsmenge durch Arbeitstage, dann mit dem Faktor 1,4 bis 1,8 für die Spitze multiplizieren — und diese Annahme im Dokument benennen.

Fehler 4: Am falschen Schritt sparen

Das ist der teuerste Fehler, weil er zu echten Investitionen führt.

Die Tabelle rechnet: „Schritt 4 dauert 18 Minuten, wir automatisieren die Hälfte, macht 9 Minuten × 1200 Vorgänge × 65 €/h = 23.400 € im Jahr.“ Die Multiplikation stimmt. Die Ersparnis tritt trotzdem nicht ein.

Denn wenn Schritt 4 nicht der Engpass ist, ändert seine Beschleunigung am Durchsatz nichts. Die frei gewordene Zeit landet nicht auf der Gewinn- und Verlustrechnung — sie landet als Wartezeit vor dem eigentlichen Engpass. Das ist der Kern der Theory of Constraints und gleichzeitig die Erfahrung jedes Prozessverantwortlichen, der schon einmal ein Werkzeug eingeführt hat, das „nichts gebracht hat“.

Umgekehrt gilt: Wer den echten Engpass löst, bekommt oft mehr als gerechnet — bis der Engpass an einen anderen Schritt wandert und dort erneut bremst.

Erkennungszeichen: Der Business Case rechnet Zeitersparnis mal Stundensatz mal Menge, ohne dass irgendwo steht, welcher Schritt der Engpass ist.

Was hilft: Zuerst die Auslastung je Schritt ausrechnen und sortieren. Alles, was nicht der höchste Wert ist, bringt beim Durchsatz nichts — es kann trotzdem sinnvoll sein (Qualität, Fehlerquote, Arbeitszufriedenheit), aber dann muss der Business Case das auch so begründen.

Die vier Fehler nebeneinander

Was eine Tabelle grundsätzlich nicht kann

Diese vier Punkte lassen sich mit Disziplin abmildern, aber ein Rest bleibt strukturell: Eine Tabelle kennt keine Warteschlange. Sie rechnet Zellen, keine Vorgänge, die aufeinander warten. Deshalb sieht sie auch nicht, was nach einer Verbesserung passiert — dass ein gelöster Engpass die volle Menge an den nächsten Schritt weitergibt und dieser dann zum Engpass wird.

Genau dafür gibt es Simulation. Sie lässt einzelne Vorgänge durch das Modell laufen, mit Streuung und Kalender, hunderte Male. Die Ausgabe ist dann keine Zahl, sondern eine Verteilung — und die überlebt eine kritische Rückfrage.

Der Test vor der Abgabe

Bevor Ihr Business Case in ein Entscheidungspapier geht, beantworten Sie vier Fragen schriftlich:

1. Welcher Schritt ist der Engpass, und woran erkenne ich das?
2. Beziehe ich mich auf Bearbeitungs- oder auf Durchlaufzeit?
3. Auf welchen Tag bezieht sich meine Auslastungszahl?
4. Wie breit ist die Spanne meiner Ersparnis, und was ist der ungünstige Fall?

Wer alle vier beantworten kann, hat einen Business Case. Wer es nicht kann, hat eine Tabelle.