Business Case für Process Mining: Vier Kennzahlen für das Finanzwesen

Ein Business Case für Process Mining liefert dem Finanzbereich vier Kennzahlen für die Bewertung: das Ausmaß des Problems, die Kosten der Lösung, die Pilotkosten und den Zeitraum bis zum ersten Nachweis. Drei davon lassen sich aus einem einzigen Export Ihrer Prozessdaten ermitteln. Ist ein Wert noch geschätzt, kennzeichnen Sie ihn als Schätzung und geben Sie an, wann Sie ihn messen.

Ein Antrag, „Process Mining einzuführen“, lässt sich schwer bewerten, weil er weder ein Problem noch eine Entscheidung oder einen Termin für Belege nennt. Viele gescheiterte Business Cases beruhen auf dem, was sich jemand von der Software erhofft, statt auf dem tatsächlichen Prozessverhalten. Deshalb konzentriert sich diese Seite auf einen einzelnen Prozess: Was Sie messen, was die Änderung kostet und wann Sie Gewissheit haben.

Welche vier Kennzahlen braucht ein Business Case für Process Mining?

Nennen Sie alle vier Kennzahlen, bevor Sie für eine davon argumentieren, und erläutern Sie jeweils, worauf sie beruhen.

1. Problemumfang: die aktuellen Prozesskosten, angegeben in einer Einheit, die Ihr Unternehmen bereits erfasst, etwa in Tagen Zykluszeit, Verzugsgebühren, Days Sales Outstanding oder FTE-Stunden. Verwenden Sie Ihre eigenen Volumen und Zeiten als Grundlage.
2. Kosten der Änderung: der Aufwand, um den Prozess zu verändern, nicht um ihn zu analysieren. Eine Richtlinienänderung mit anschließender Schulung ist ein anderes Vorhaben als eine Systemänderung. Die Schätzung sollte von der Person stammen, die für die Änderung verantwortlich ist.
3. Pilotkosten: Lizenz, Datenaufbereitung und interner Zeitaufwand für die Ermittlung der Fakten.
4. Zeit bis zum ersten Beleg: der erwartete Termin für die Auswertung und die Kennzahl, anhand derer Sie das Ergebnis beurteilen.

Drei der vier Kennzahlen stammen in der Regel aus derselben Quelle. Ein Export der Prozessdaten zeigt den Problemumfang, den Aufwand für die Datenaufbereitung und die Dauer der Analyse. Nur die Kosten der Änderung hängen von einer noch nicht getroffenen Entscheidung ab. Deshalb braucht es dafür eine benannte verantwortliche Person und einen Termin statt einer frei erfundenen Zahl.

Kennzeichnen Sie jede Zahl im Business Case als gemessen oder geschätzt. Der Finanzbereich wird nach dem Unterschied fragen. Ein Business Case, der diese Frage beantwortet, lässt sich schwerer zurückweisen als vier selbstbewusst präsentierte Zahlen ohne erkennbare Grundlage.

Warum verlieren Business Cases für Process Mining an Rückhalt?

Business Cases scheitern selten an einer falschen Zahl. Ein Business Case für Process Mining scheitert, wenn sich nichts überprüfen lässt.

Sie beantragen eine Funktion statt einer Entscheidung. „Wir erhalten Transparenz über den Order-to-Cash-Prozess“ sagt dem Finanzbereich weder, wofür die Mittel eingesetzt werden, noch wie Sie das Ergebnis bewerten. „Wir prüfen, ob der zweite Freigabeschritt bei einem Drittel der Bestellungen eine Woche Verzögerung verursacht, und legen das Ergebnis bis zum 15. November vor“ ist dagegen konkret.

Sie stützen sich auf Prozentwerte aus Benchmarks. Die Aussage, Process Mining senke die Zykluszeit üblicherweise um einen bestimmten Prozentsatz, sagt nichts über Ihren Prozess aus. Ihre eigene Ausgangsbasis ist hilfreicher, auch wenn sie weniger beeindruckend ausfällt.

Sie berücksichtigen den Aufwand für die Daten nicht. Daten zu extrahieren, Cases zu identifizieren, Timestamps zu ordnen und Aktualisierungen einzurichten, kostet Zeit. Führt Ihr Business Case nur die Lizenz auf, sind die Pilotkosten zu niedrig angesetzt. Lesen Sie zuerst die Kostenaufstellung, um die einzelnen Kostenpunkte genauer zu betrachten.

Ein Durchschnittswert verdeckt das Problem. Eine durchschnittliche Bearbeitungszeit verteilt eine Wartezeit von fünf Tagen gleichmäßig auf alle Cases. Dadurch wirkt der Wert gering und eine mögliche Verbesserung noch kleiner. Zeigen Sie stattdessen, wo die Zeit anfällt: bei welchem Schritt, in wie vielen Cases und über welchen Zeitraum. „Rund 12.000 Bestellungen pro Quartal; etwa ein Drittel wird nicht zum zugesagten Termin geliefert, die Ursache ist unklar“ gibt Prüfenden einen konkreten Ansatz. „Erhebliche Ineffizienz im Auftragsmanagement“ nicht.

Welche Ergebnisse liefern Process-Mining-Projekte typischerweise?

Wenn Sie wissen, welche Belege eine Analyse liefert, fällt es leichter, den Business Case zu formulieren. Eine erste Analyse der Ereignisdaten für einen Prozess beantwortet in der Regel Fragen wie diese:

• Wohin die Zeit fließt: Wartezeit je Aktivität im Vergleich zur Bearbeitungszeit, damit der Unterschied sichtbar wird.
• Wie oft sich der Prozess wiederholt: Schleifen und Nacharbeit, einschließlich Schritten, die ein dokumentiertes Modell nicht zeigt.
• Wie viele Personen oder Stellen einen Case bearbeiten: Übergaben zwischen Teams und Systemen.
• Wie stark der Prozess variiert: Anzahl unterschiedlicher Abläufe und Anteil der Cases, die dem häufigsten Ablauf folgen.
• Wo der Prozess von den Regeln abweicht: Abweichungen vom vorgesehenen Prozess.
• Welche Schritte sich für eine Automatisierung eignen: Schritte mit hohem Volumen, klaren Regeln und geringen Schwankungen, für die eine gemessene Ausgangsbasis vorliegt.
• Welchen Aufwand jeder Schritt verursacht: Zeitaufwand je Schritt und Case, damit sich geplante Änderungen beziffern lassen.

Welche dieser Erkenntnisse Sie gewinnen, hängt von Ihrem Prozess und Ihren Daten ab. Ein Event Log mit Case-ID, Aktivität und Timestamp beantwortet die ersten vier Fragen. Für die übrigen sind weitere Details nötig, teilweise auch ein Vergleichsmodell. Erfahren Sie, wie Process Mining Ihre Prozessdaten analysiert. Falls die Daten noch nicht verwendbar sind, zeigt der Weg zur Process-Mining-Readiness, welche Voraussetzungen zuerst erfüllt sein müssen.

Eines sollte klar sein: Das Tool liefert Ihnen nicht die Antwort. Es liefert Belege, aus denen Sie einen Business Case entwickeln können. Keine der genannten Erkenntnisse sagt Ihnen, welchen Wert eine Änderung hat, ob ein Schritt überhaupt notwendig ist oder wie viel Kapazität Ihr Team tatsächlich zurückgewinnen kann. Das sind weiterhin unternehmerische Entscheidungen, die sich mit vorhandenen Messwerten leichter treffen lassen. Der Nutzen von Process Mining hängt davon ab, welche Änderungen auf Grundlage dieser Entscheidungen umgesetzt werden.

Deckt das Event Log nur einen Teil des Prozesses oder einen begrenzten Zeitraum ab, weisen Sie bei den Zahlen darauf hin. Auch eine Teilmessung ist ein Beleg, sofern klar ist, was sie umfasst und was nicht.

Wie leiten Sie den erwarteten Nutzen aus Ihren eigenen Messwerten ab?

Die Größe eines Problems wird erst dann zum Nutzen, wenn Sie benennen, was sich dadurch ändert. Der Wert von Process Mining zeigt sich daran, welche Entscheidung die Erkenntnisse beeinflussen. Richten Sie den Business Case deshalb an einer konkreten Entscheidung aus, die Ihre Organisation treffen muss. Für eine erste Investitionsbegründung in Process Mining reichen meist zwei Berechnungsmodelle:

Liquidität oder Working Capital:

eingesparte Tage × betroffene Cases × Wert pro Case-Tag × Kapitalkosten

Kapazität:

eingesparte Stunden pro Zeitraum × Vollkosten pro Stunde

Achten Sie auf drei klare Unterscheidungen:

• Verwenden Sie eine Einheit, die in Ihrem Unternehmen bereits gebräuchlich ist. Beziffern Sie den Nutzen in Tagen Durchlaufzeit, vermiedenen Verzugsgebühren, einer verkürzten DSO oder zurückgewonnenen Arbeitsstunden. „Effizienz“ allein lässt sich nicht überprüfen.
• Unterscheiden Sie zwischen Liquidität und Kapazität. Freigesetzte Kapazität schafft nicht automatisch Liquidität. Geben Sie an, ob der Wert daraus entsteht, dass dasselbe Team mehr Fälle bearbeitet, oder aus einer Personalentscheidung. Benennen Sie auch, wer diese Entscheidung trifft.
• Benennen Sie die unsicherste Annahme. Legen Sie offen, welcher Teil der Schätzung am wenigsten belastbar ist und wie Sie ihn überprüfen wollen.

Mit einer gemessenen Ausgangsbasis lässt sich die weitere Berechnung besser begründen. Wenn die Arbeitsstunden aus Ihren eigenen Event-Daten stammen, bleibt als einzige Annahme die Höhe der Reduktion. Diese Zahl kann ein Prüfer hinterfragen. Ein Nutzen, der sowohl auf einer angenommenen Ausgangsbasis als auch auf einer angenommenen Reduktion beruht, hält einer Besprechung selten stand. Können Sie keinen konkreten Prozentsatz für die Reduktion begründen, nennen Sie die geprüfte Bandbreite und geben Sie an, welchen Wert daraus Sie verwendet haben.

Diese Angaben können Sie in den ProcessMind-ROI-Rechner eingeben: jährliches Case-Volumen, durchschnittliche Bearbeitungszeit, Vollkosten pro Stunde, erwartete Reduktion, Vorfälle samt durchschnittlichen Kosten sowie die Lizenzangaben zum Tarif. Der Rechner ermittelt den jährlichen Gesamtnutzen, den Nettonutzen, den Return on Investment und die Amortisationsdauer.

Das Modell ist allgemein gehalten, und genau darin liegt sein Nutzen: Es zeigt, wie die einzelnen Eingaben zusammenwirken. Zu Ihrem Business Case wird es erst, wenn Sie die Standardwerte durch Ihre eigenen Volumen, Zeitangaben und Kosten ersetzen. Implementierungsaufwand und Datenaufbereitung berücksichtigt der Rechner nicht auf der Kostenseite. Ergänzen Sie diese Posten daher separat. Ein Modell, das Sie nicht auf Ihre Situation zuschneiden können, ist noch kein Business Case.

Wie sieht ein Business Case mit vier Kennzahlen in der Praxis aus?

Die folgenden Zahlen dienen nur zur Veranschaulichung. Übernehmen Sie die Methode, nicht die Werte.

Ausgangslage: Ein Prozess bearbeitet 12.000 Aufträge pro Quartal. Die mediane Durchlaufzeit beträgt 18 Tage, das 90. Perzentil (P90) liegt bei 41 Tagen. Etwa ein Drittel der Aufträge wartet an einem Genehmigungsschritt länger als fünf Tage. Die eigentliche Arbeit an diesem Schritt dauert rund vier Minuten.

1. Umfang des Problems: Die Wartezeit betrifft etwa 4.000 Aufträge pro Quartal. Beträgt die durchschnittliche Wartezeit an diesem Schritt sechs Tage, entspricht das pro Quartal 24.000 Auftrags-Tagen Durchlaufzeit. Für die eigentliche Arbeit an diesem Schritt fallen im selben Zeitraum rund 270 Stunden an. Welche der beiden Zahlen in den Business Case gehört, hängt davon ab, ob die Verzögerung Kosten verursacht, das Serviceniveau beeinträchtigt oder beides. Prüfen Sie beide Werte anhand Ihrer eigenen Daten, bevor Sie sie verwenden. Achten Sie auch auf die Einheit: Auftrags-Tage sind nicht mit Euro gleichzusetzen. Soll der Business Case einen Geldbetrag ausweisen, müssen Sie auch diese Umrechnung als Annahme benennen und überprüfen.

2. Kosten der Änderung: Eine mögliche Änderung wäre, den Schwellenwert so anzuheben, dass der Genehmigungsschritt nur noch für 8 Prozent statt für 33 Prozent der Aufträge gilt. Außerdem könnte eine Vertretung einspringen, wenn die genehmigende Person abwesend ist. Klären Sie Richtlinien, Kontrollen und Umsetzungskosten mit den Verantwortlichen, bevor Sie die Änderung als kostengünstig einstufen.

3. Kosten des Piloten: Begrenzen Sie den Piloten auf einen Prozess und einen festgelegten Zeitraum. Berücksichtigen Sie die Lizenz, die Arbeitszeit der Analysten für die Datenaufbereitung und den Zeitaufwand der Prozessverantwortlichen. Kennzeichnen Sie den Aufwand für die Datenaufbereitung als Schätzung, wenn Sie ihn noch nicht bestätigt haben. Ein Business Case für Process Mining, der nur die Lizenzkosten aufführt, unterschätzt den tatsächlichen Aufwand.

4. Zeit bis zu ersten Erkenntnissen: Legen Sie einen Termin fest, an dem Sie die Durchlaufzeit des betroffenen Segments überprüfen. Ändert sich die Wartezeit nicht, steht Ihnen für die nächste Entscheidung trotzdem eine Ausgangsbasis zur Verfügung.

Was könnte die Schlussfolgerung verändern? Dient der Genehmigungsschritt dazu, einen Kontrollfehler aufzudecken, könnte ein höherer Schwellenwert diese Kontrolle schwächen. Berücksichtigen Sie dieses Risiko im Business Case und beziehen Sie die für die Kontrolle verantwortliche Person ein, bevor Sie eine Änderung empfehlen.

Fassen Sie die vier Zahlen und die Fragen aus dem Finanzbereich auf einer Seite zusammen:

Jede Zeile dieser Tabelle sollte sich auf eine Messung oder auf eine Schätzung einer namentlich genannten verantwortlichen Person stützen. Für eine Berechnung des Process-Mining-ROI gilt dasselbe: Stellen Sie eine Schätzung erst dann als Einsparung dar, wenn Ihre eigenen Daten und die vorgeschlagene Änderung sie stützen.

Welche Schritte sich überhaupt für eine Änderung eignen könnten, erfahren Sie in unserem Leitfaden zu Automatisierungspotenzialen mit Process Mining.

Warum sollte Ihr erster Business Case ein Pilotprojekt betreffen?

Der erste Business Case sollte sich auf einen Piloten beziehen, nicht auf eine Plattform. Dafür sind die vier Kennzahlen ausgelegt: ein Prozess, eine Entscheidung und ein Zeitraum, der kurz genug ist, um das Ergebnis zu prüfen, bevor Sie sich auf ein größeres Vorhaben festlegen. Betrachten Sie den Piloten als Nachweis des Nutzens von Process Mining: als Messung, nicht als kleine Einführung.

Fangen Sie klein an und bleiben Sie bei den Anforderungen realistisch: Der Business Case sollte überzeugend einfach sein. Ist er das nicht, ist der Umfang zu groß. Lassen Sie zuerst die Daten sprechen und bauen Sie das Vorhaben dort aus, wo es sich lohnt. Ein Pilot, der nur wenige Sitzplätze und einige Wochen Arbeitszeit von Analysten kostet, muss eine deutlich niedrigere Hürde nehmen als ein Plattformprogramm. Außerdem liefert er etwas, das ein Plattformprogramm nicht bieten kann: Ihre eigene Ausgangsbasis.

Klein anzufangen ist auch eine Softwareentscheidung. Ergibt ein Werkzeug nur als unternehmensweite Einführung Sinn, muss der Business Case schon vor seiner Ausarbeitung groß sein. ProcessMind wird pro Sitzplatz berechnet. Nach der Testphase gibt es einen kostenlosen Tarif. Die kostenlose Testphase dauert 14 Tage und erfordert keine Kreditkarte. Für die erste Analyse ist also keine Enterprise-Vereinbarung nötig. Informieren Sie sich über die Kosten der einzelnen Tarife.

Klären Sie diese vier Punkte, bevor Sie mit einem Process-Mining-Piloten beginnen:

• Ein Prozess: so klar abgegrenzt, dass eine einzelne Frage den Umfang bestimmt.
• Eine Entscheidung: die Entscheidung, die durch die Erkenntnisse unterstützt werden soll.
• Abbruchkriterien: vorab vereinbart, damit klar ist, welche Ergebnisse für eine Fortsetzung und welche für einen Abbruch sprechen.
• Ein Prüftermin: der Termin, an dem Sie die Erkenntnisse bewerten und über die nächsten Schritte entscheiden.

Stützen die Ergebnisse des Piloten weitere Arbeiten, können Sie damit den nächsten Prozess begründen. Andernfalls haben Sie trotzdem eine Ausgangsbasis und wissen genauer, warum Sie den Kurs ändern sollten. Legen Sie vor dem Start die drei möglichen Ergebnisse im Business Case fest: Die Erkenntnisse sprechen für diese Änderung, für eine andere Änderung oder für einen Abbruch. Eine Messung, die nur mit einem einzigen möglichen Ergebnis enden kann, ist keine echte Messung.

Was, wenn die Zahlen noch nicht vorliegen?

Dann ist die Investition möglicherweise noch nicht gerechtfertigt. Das festzustellen ist ein Ergebnis, kein Scheitern. Meist gibt es dafür einen von drei Gründen: Das Prozessvolumen ist zu gering, als dass sich der Aufwand lohnen würde, die Daten liegen nicht in einer brauchbaren Form vor oder niemand wartet auf die Entscheidung.

Sind die Daten vorhanden und ist der Prozess klein, messen Sie die Ausgangsbasis zunächst manuell. Sind die Daten nicht brauchbar, planen Sie stattdessen die erforderliche Datenaufbereitung und beantragen Sie noch keine Lizenz. Halten Sie fest, was sich ändern müsste, bevor Sie den Business Case erneut prüfen.