ROI von KI-Automatisierung seriös berechnen
Ein belastbarer Business Case beginnt mit gemessener Ausgangsleistung, vollständigen Kosten und mehreren Szenarien – nicht mit einer pauschalen Einsparungsquote.
1. Die heutige Leistung messen
Ohne Baseline bleibt jede Verbesserung eine Behauptung. Erheben Sie über einen repräsentativen Zeitraum Volumen, Bearbeitungszeit, Wartezeit, Rückfragen, Nacharbeit, Fehler, Eskalationen und gegebenenfalls entgangene Vorgänge. Trennen Sie Normalfälle von Ausnahmen. Ein Durchschnitt kann sonst verdecken, dass wenige komplizierte Fälle den Großteil der Kosten verursachen.
Die Baseline muss den tatsächlich veränderten Ablauf abbilden. Wird nur die Klassifizierung von E-Mails automatisiert, darf nicht die gesamte Bearbeitungszeit als Einsparung angesetzt werden. Außerdem zählt freigesetzte Zeit nur dann als wirtschaftlicher Nutzen, wenn das Unternehmen sie anderweitig produktiv einsetzen oder echte Kapazitätskosten vermeiden kann.
Messung ohne perfekte Prozessdaten
Viele KMU verfügen nicht über eine vollständige Prozessanalyse. Beginnen Sie dann mit einer begrenzten, dokumentierten Stichprobe. Wählen Sie unterschiedliche Tage und Falltypen, notieren Sie Start- und Endpunkte und markieren Sie Wartezeit getrennt von aktiver Bearbeitung. Ergänzen Sie Systemdaten mit einer kurzen Einschätzung der Mitarbeitenden, aber kennzeichnen Sie Schätzwerte. Das Ziel ist nicht statistische Scheingenauigkeit, sondern eine nachvollziehbare Ausgangslage.
Halten Sie fest, ob Arbeitszeit tatsächlich variabel ist. Eine vermiedene Minute führt nicht automatisch zu einer Kostensenkung, wenn Personal unverändert gebunden bleibt. Sie kann trotzdem wertvoll sein: Teams können Spitzen abfangen, Rückstände abbauen oder mehr Zeit in Beratung investieren. Im Business Case sollte dieser Kapazitätsnutzen getrennt von realisierten Geldeffekten erscheinen.
2. Nutzen in Kategorien statt Wunschzahlen
- Kapazität: weniger manuelle Schritte, geringere Spitzenbelastung oder mehr bearbeitbare Vorgänge.
- Qualität: vollständigere Daten, konsistentere Prüfung, weniger Nacharbeit.
- Geschwindigkeit: kürzere Antwort- oder Durchlaufzeit.
- Verfügbarkeit: Anliegen können außerhalb klassischer Bearbeitungszeiten aufgenommen werden.
- Risikoreduktion: bessere Protokollierung, Pflichtprüfungen oder frühere Eskalation.
Nicht jeder Nutzen lässt sich sofort in Euro übersetzen. Dokumentieren Sie operative Kennzahlen separat und legen Sie offen, welche Umrechnung verwendet wird. Beispielsweise ist eine schnellere Erstreaktion nicht automatisch zusätzlicher Umsatz.
3. Total Cost of Ownership einbeziehen
| Einmalig | Laufend |
|---|---|
| Prozessanalyse, Datenaufbereitung, Integration, Sicherheitsprüfung, Pilot, Schulung | Modell/API, Hosting, Monitoring, fachliche Kontrolle, Support, Evaluation, Wissenspflege |
| Rechtliche und betriebliche Freigabe, Dokumentation, Change Management | Änderungen an Systemen und Modellen, Vorfallbearbeitung, erneute Prüfungen |
Auch menschliche Kontrolle ist eine Kostenposition. Sie ist kein Zeichen für gescheiterte Automatisierung, sondern bei vielen Prozessen ein bewusstes Qualitätselement. Schätzen Sie die erwartete Übergabequote und die Zeit zur Prüfung anhand von Pilotdaten.
ROI im betrachteten Zeitraum = (realisierter Nutzen − Gesamtkosten) ÷ Gesamtkosten. Entscheidend ist nicht die Formel, sondern die Nachvollziehbarkeit jeder Eingabe.
Kostentreiber als Mengenmodell abbilden
Trennen Sie feste und fallabhängige Kosten. Feste Kosten umfassen beispielsweise Grundbetrieb, Monitoring und regelmäßige Evaluation. Fallabhängig sind Modellaufrufe, Dokumentverarbeitung, Nachrichten oder menschliche Nachprüfung. Ein Mengenmodell zeigt, ob der Anwendungsfall bei steigendem Volumen günstiger wird oder ob externe Gebühren und Übergaben proportional wachsen.
Berücksichtigen Sie zudem Ersatz- und Wechselkosten. Wenn eine Schnittstelle, ein Modell oder ein Wissenssystem geändert wird, müssen Tests und gegebenenfalls Schulungen wiederholt werden. Eine austauschbare Architektur kann zunächst etwas mehr Aufwand bedeuten, senkt aber die Abhängigkeit von einzelnen Komponenten. Ob das wirtschaftlich relevant ist, hängt von Laufzeit und Kritikalität ab.
4. Drei Szenarien und klare Abbruchkriterien
Rechnen Sie mindestens konservativ, erwartet und positiv. Variieren Sie dabei Volumen, Anteil erfolgreich bearbeiteter Fälle, Übergabequote, Qualitätskosten und laufende Nutzungskosten. Verwenden Sie keine bessere Automatisierungsquote, nur weil das Modell in einer Demo gut wirkte. Pilotdaten sollten die Annahmen schrittweise ersetzen.
Beispielhafte, nicht finanzielle Entscheidungstore
- Der Ablauf erreicht definierte Mindestqualität auf einem eingefrorenen Testset.
- Ausnahmen werden zuverlässig erkannt und mit genügend Kontext übergeben.
- Schreibende Systemaktionen sind technisch begrenzt und protokolliert.
- Fachbereich, IT und Datenschutz haben Verantwortung und Betriebsweg bestätigt.
- Der konservative Business Case bleibt innerhalb des akzeptierten Rahmens.
Definieren Sie vor dem Pilot, wann das Vorhaben gestoppt oder neu zugeschnitten wird. Das schützt vor dem Weiterführen eines Projekts, nur weil bereits Aufwand investiert wurde.
Von Pilotwerten zu realisiertem Nutzen
Eine technische Pilotmessung ist noch kein realisierter ROI. Im Live-Betrieb verändern Einarbeitung, neue Fallvarianten und tatsächliche Nutzung das Ergebnis. Vereinbaren Sie deshalb einen Beobachtungszeitraum und vergleichen Sie ihn mit einer passenden Baseline. Prüfen Sie, ob Bearbeitung nur verschoben wurde: Wenn automatisierte Fälle später häufiger korrigiert werden, gehört diese Nacharbeit in die Rechnung.
Ordnen Sie jede Nutzenposition einer verantwortlichen Person und einer Datenquelle zu. Der Fachbereich bestätigt Prozessqualität, Controlling die Bewertungslogik, IT die Betriebskosten. Diese gemeinsame Sicht verhindert, dass eine einzelne technische Kennzahl zur finanziellen Wahrheit erklärt wird.
Entscheidungsvorlage für das Management
Eine belastbare Vorlage zeigt Zielprozess und Grenze, Baseline, konservatives und erwartetes Szenario, Gesamtkosten, zentrale Risiken und noch unbelegte Annahmen. Ergänzen Sie die Entscheidung, die jetzt tatsächlich benötigt wird: Budget für einen Pilot, Freigabe eines Datenzugangs oder Übergang in den Betrieb. So bleibt die Kalkulation mit dem Reifegrad des Vorhabens verbunden.
Nach dem Start sollte der Business Case aktualisiert werden. Volumen, Kosten und Qualitätsanforderungen können sich verändern. Eine Lösung, die heute sinnvoll ist, kann durch einen geänderten Prozess oder eine neue Standardfunktion überflüssig werden. Ein regelmäßiger Review ist daher auch eine Stop- und Vereinfachungsoption.
Unsicherheit sichtbar machen
Ergänzen Sie eine einfache Sensitivitätsanalyse: Welche zwei oder drei Annahmen verändern das Ergebnis am stärksten? Häufig sind dies tatsächliches Fallvolumen, Übergabequote oder realisierbare Kapazitätsnutzung. Konzentrieren Sie Pilotmessung und Risikomaßnahmen auf diese Größen. Eine lange Liste kleiner Annahmen vermittelt dagegen Genauigkeit, ohne die Entscheidung robuster zu machen.
Dokumentieren Sie zu jeder Schlüsselannahme Datenquelle, verantwortliche Rolle und nächsten Prüfzeitpunkt. Dadurch bleibt der Business Case auch nach Personalwechsel oder einer veränderten Anbieterrechnung nachvollziehbar.
Ein guter Business Case verspricht nicht die größte Einsparung. Er macht sichtbar, unter welchen Bedingungen ein messbarer Nutzen entsteht.
Verwandte Lösungen
Quellen und Methoden
- NIST AI Risk Management Framework
- ISO/IEC 42001: AI management systems
- European Commission: AI regulatory framework
Beispielstruktur ohne individuelle Finanz-, Steuer- oder Rechtsberatung.