ROI-Modeling für KI: Business Cases, die Finance standhalten
Wie Sie Kostenkategorien, Wertfaktoren und Payback-Zeiträume für KI-Initiativen so modellieren, dass der Business Case auch im CFO-Review Bestand hat.
Wie Sie Kostenkategorien, Wertfaktoren und Payback-Zeiträume für KI-Initiativen so modellieren, dass der Business Case auch im CFO-Review Bestand hat.
Ohne Sonderbehandlung, nur weil "KI" draufsteht: Die erste Frage, die Controlling in einem solchen Review stellt, ist fast immer dieselbe: Wo genau taucht diese Rendite in der GuV auf? Wer zwischen zwei völlig unterschiedlichen Dingen nicht sauber trennt – freigesetzter Kapazität und tatsächlich realisiertem Geld – hat auf diese Frage keine Antwort parat. Ein KI-System, das einer Sachbearbeiterin zwei Stunden pro Tag erspart, erzeugt noch keinen einzigen Euro Wert, solange diese zwei Stunden nicht irgendwo ankommen. Entweder wird die Person auf höherwertige Tätigkeiten umgeleitet, deren Ergebnis sich beziffern lässt, oder es verändert sich tatsächlich die Kostenbasis, weil weniger Personal, weniger Zeitarbeit oder weniger Überstunden benötigt werden. Passiert keins von beidem, bleibt die Zeitersparnis eine hübsche Zahl auf einer Folie, aber ohne Gegenwert in der GuV.
Genau an diesem Punkt kippen die meisten Business Cases im internen Review. Controlling und Finance sind darauf trainiert, "Effizienzgewinne" zu hinterfragen, die sich nicht in einer Buchung wiederfinden. Wer eine KI-Initiative vorschlägt und dabei Stundenersparnis unreflektiert in Euro umrechnet, liefert der Gegenseite die einfachste denkbare Angriffsfläche. Ein Business Case, der diese Prüfung übersteht, macht das Gegenteil: Er benennt von Anfang an, welcher Teil der prognostizierten Wirkung sofort kassenwirksam ist, welcher Teil eine organisatorische Entscheidung voraussetzt (Umverteilung, Abbau, Nicht-Nachbesetzung), und welcher Teil schlicht eine Kapazitätsreserve schafft, die erst bei Wachstum in Wert umschlägt. Diese Differenzierung ist die Grundlage für alles Weitere in diesem Dokument – sie zieht sich durch Kostenrechnung, Wertfaktoren, Zeithorizonte und die typischen Fehler gleichermaßen.
Ein häufiger Anfängerfehler ist, alle Kosten einer KI-Initiative unter einer einzigen Zeile "Implementierung" zu bündeln. Das verschleiert genau die Kostenblöcke, die später den größten Unterschied zwischen Plan und Ist ausmachen. Wir empfehlen, konsequent vier getrennte Kategorien zu führen.
Implementierung und Integration umfasst die eigentliche technische Bauarbeit: Anbindung an bestehende Systeme, Aufbau der Datenpipeline, Prompt- beziehungsweise Modell-Engineering, gegebenenfalls eine eigene Benutzeroberfläche. Diese Kosten sind meist am besten zu schätzen, weil sie sich an klassischen IT-Projekten orientieren.
Lizenzen und Compute sind strukturell anders, weil sie nicht fix, sondern nutzungsabhängig sind. Ob pro Sitzplatz oder pro API-Aufruf beziehungsweise Token abgerechnet wird – diese Kosten skalieren mit dem Volumen und damit auch mit dem Erfolg der Initiative. Wer hier mit einer Jahrespauschale rechnet, unterschätzt fast immer, was passiert, sobald die Nutzung tatsächlich anzieht.
Change Management und Enablement ist die Kategorie, die in ersten Entwürfen am häufigsten fehlt oder nur als Randnotiz auftaucht – und zugleich fast immer die größte und am langsamsten amortisierende Position ist. Dazu gehören Schulungen, die Neugestaltung von Prozessen und Rollen, interne Multiplikatoren beziehungsweise "Champions" und die Kommunikationsarbeit, die nötig ist, damit ein Tool tatsächlich in den Arbeitsalltag übergeht statt in der Schublade zu landen.
Laufender Betrieb schließlich umfasst Monitoring, die menschliche Prüfung von Ausgaben im Sinne von Human-in-the-Loop-QA, das Nachtrainieren oder Anpassen von Prompts, wenn Modellanbieter ihre Basismodelle aktualisieren, sowie Support. Diese Kategorie wird regelmäßig auf null oder auf eine symbolische Wartungspauschale reduziert, obwohl sie über die Lebensdauer einer Anwendung erhebliche laufende Kosten verursacht.
Die Trennung dieser vier Blöcke lohnt sich doppelt: Sie macht die Schätzung transparenter, und sie zeigt im Nachhinein, welche Annahme tatsächlich falsch lag – statt einer einzigen unspezifischen Abweichung bei "Implementierung".
Auf der Nutzenseite lassen sich die meisten KI-Initiativen vier Wertkategorien zuordnen, die sich in ihrer Messbarkeit deutlich unterscheiden.
Zeitersparnis ist am einfachsten zu messen, weil sich Bearbeitungszeiten vorher und nachher vergleichen lassen. Der entscheidende Vorbehalt: Sie zählt im Business Case nur dann als ROI, wenn die frei werdende Zeit tatsächlich anderswo eingesetzt wird. Ohne diese Anschlussentscheidung ist Zeitersparnis eine operative Beobachtung, kein finanzieller Effekt.
Fehler- und Qualitätsreduktion sollte nicht als "weniger Fehler" formuliert, sondern in vermiedene Kosten übersetzt werden: Nacharbeit, Reklamationen, Nachbesserungsaufwand, im schlimmsten Fall Haftungsrisiken. Wer eine Fehlerquote senkt, muss zeigen, was diese Fehler bislang tatsächlich gekostet haben, um den Effekt beziffern zu können.
Kapazitätssteigerung bedeutet, dass dieselbe Belegschaft ein höheres Volumen bewältigt, ohne dass zusätzliches Personal aufgebaut werden muss. Diese Kategorie ist besonders relevant für Funktionen, deren Wachstum bislang durch Personalkapazität begrenzt war – etwa Kundenservice, Sachbearbeitung oder Vertriebssupport in Wachstumsphasen.
Umsatzeffekte – etwa durch bessere Konversion, gezieltere Upsell-Ansprache oder höhere Kundenbindung – sind die Kategorie mit der größten Unsicherheit. Sie lassen sich kaum sauber auf eine einzelne Maßnahme zurückführen, wenn nicht mit einer Kontrollgruppe oder einem belastbaren Vorher-Nachher-Vergleich gearbeitet wird. Ein seriöses Modell weist diesen Effekten deshalb bewusst eine breitere Bandbreite zu als den anderen drei Kategorien – nicht weil sie unwichtig wären, sondern weil ihre Zurechenbarkeit strukturell schwächer ist.
Dieser Punkt verdient eine eigene, vertiefte Betrachtung, weil er in der Praxis am häufigsten zur Ablehnung von Business Cases führt. Eine KI-Anwendung, die Bearbeitungszeit reduziert, produziert zunächst nur eines: freie Kapazität. Was mit dieser Kapazität geschieht, entscheidet darüber, ob daraus ein finanzieller Effekt wird.
Es gibt im Grunde drei mögliche Wege. Erstens: Die Kapazität wird auf Tätigkeiten umgelenkt, die zuvor liegen geblieben sind oder extern zugekauft wurden – dann lässt sich der Wert an den vermiedenen externen Kosten oder am zusätzlichen Output dieser Tätigkeiten festmachen. Zweitens: Die Kapazität führt dazu, dass eine Position nicht nachbesetzt wird, ein Zeitarbeitsvertrag ausläuft oder Überstunden zurückgehen – dann ist der Effekt unmittelbar an der Kostenbasis ablesbar. Drittens, und das ist der Fall, der am häufigsten übersehen wird: Die Kapazität verpufft, weil niemand die organisatorische Entscheidung trifft, sie umzuleiten. Die Mitarbeitenden haben schlicht mehr Luft im Tagesgeschäft, was angenehm ist, aber in keiner Bilanz auftaucht.
Für den Business Case bedeutet das: Zeitersparnis darf nur so weit als Wert eingerechnet werden, wie eine konkrete, verantwortete Entscheidung über ihre Verwendung existiert. Fehlt diese Entscheidung, sollte die Zeitersparnis entweder mit deutlich reduziertem Gewicht in die Rechnung eingehen oder als reine "Kapazitätsreserve" ausgewiesen werden, deren Realisierung von einer noch zu treffenden Organisationsentscheidung abhängt. Diese Ehrlichkeit kostet auf den ersten Blick Attraktivität in der Präsentation – sie ist aber genau der Unterschied zwischen einer Zahl, die eine Finanzabteilung akzeptiert, und einer, die sie zerlegt.
Eine der unglücklichsten Angewohnheiten in Angebotspräsentationen ist die Nennung einer einzelnen, branchenweiten Amortisationszahl. Belastbarer ist ein Rahmen, der den erwarteten Payback-Zeitraum an den Charakter der Initiative koppelt, statt eine pauschale Kennzahl zu behaupten.
Eng geschnittene Automatisierungsvorhaben mit einem klar abgegrenzten Prozess, bekanntem Volumen und bereits quantifizierter Kostenbasis pro Vorgang amortisieren sich in aller Regel am schnellsten – hier lässt sich vorher und nachher direkt vergleichen, und die Wertfaktoren sind überschaubar. Breiter angelegte, transformative Initiativen, die mehrere Arbeitsabläufe, Rollenveränderungen und Organisationsdesign gleichzeitig berühren, benötigen dagegen deutlich länger und tragen ein spürbar höheres Schätzrisiko, weil mehr Annahmen gleichzeitig zutreffen müssen.
Die belastbare Formulierung gegenüber Entscheidern lautet deshalb nicht "im Schnitt X Monate", sondern "abhängig von Umfang und Qualität der Ausgangsbasis". Ein Business Case, der diese Abhängigkeit explizit macht und den eigenen Anwendungsfall entsprechend einordnet, wirkt in der Prüfung glaubwürdiger als einer, der sich an einer Benchmarkzahl aus einer Studie oder einem Vendor-Pitch orientiert, die für den eigenen Kontext nie validiert wurde.
Aus wiederkehrenden Reviews lassen sich sechs Fehlerbilder benennen, die überproportional häufig dafür sorgen, dass ein Business Case in der internen Prüfung durchfällt oder seine eigenen Prognosen später nicht erreicht.
Der erste und wichtigste Fehler ist das Fehlen einer quantifizierten Ausgangsbasis. Wenn die aktuelle Bearbeitungszeit, Fehlerquote oder Kostenrate pro Vorgang vor Projektstart nie gemessen wurde, ist jede Vorher-Nachher-Behauptung im Nachhinein nicht überprüfbar – und wird weder ein internes Audit noch eine kritische CFO-Prüfung überstehen. Die Baseline-Messung muss der erste Schritt jedes Business Case sein, nicht eine nachträgliche Fußnote.
Der zweite Fehler ist die strukturelle Unterschätzung der Betriebskosten. Weil Inferenz- beziehungsweise API-Kosten, Monitoring-Infrastruktur und die menschliche Prüfkapazität für Grenzfälle mit der Nutzung skalieren, reicht es nicht, die Kosten des ersten Einführungsjahres zu betrachten. Belastbar ist eine Modellierung der Gesamtbetriebskosten über zwei bis drei Jahre.
Der dritte Fehler behandelt Change Management und Adoption als Randnotiz, obwohl diese Kategorie meist die größte und am langsamsten wirkende ist. Prozessneugestaltung, veränderte Rollen, Schulung und interne Kommunikation entscheiden, ob ein Tool überhaupt genutzt wird. Business Cases, die diese Zeile auslassen oder pauschal minimieren, überschätzen fast immer den tatsächlich realisierten Wert.
Der vierte Fehler sind zu optimistische Annahmen zur Adoptionskurve. Modelle, die von nahezu vollständiger Nutzung ab dem ersten Monat ausgehen, statt eine realistische Rampe mit Pilotnutzern, anfänglichem Widerstand und Reibungsverlusten im Arbeitsalltag anzunehmen, überzeichnen systematisch den ROI der frühen Phase – mit der Folge, dass der Business Case seinen eigenen prognostizierten Amortisationszeitpunkt verfehlt.
Der fünfte Fehler ist die Annahme, dass sich die Wirtschaftlichkeit eines Piloten unverändert auf den Produktivbetrieb übertragen lässt. Die Kosten pro Vorgang und die Genauigkeit eines Proof of Concept wirken oft besser, als sie im Vollbetrieb sein werden, weil Pilotphasen häufig mit kuratierten Daten und ausgewählten Fällen arbeiten. Der Produktivbetrieb bringt Randfälle, Ausnahmebehandlung und Integrationsaufwand mit sich, die die tatsächlichen Kosten pro Vorgang erhöhen.
Der sechste Fehler ist die Präsentation als einzelne, präzise wirkende Zahl ohne Sensitivitätsanalyse. Ein belastbarer Business Case zeigt eine Bandbreite aus konservativem, mittlerem und optimistischem Szenario und macht sichtbar, auf welche Annahme der ROI am empfindlichsten reagiert – statt eine scheinbar exakte Zahl zu liefern, die bei der ersten kritischen Rückfrage in sich zusammenfällt.
Für Unternehmen im deutschsprachigen Raum kommen mehrere Kostenpositionen hinzu, die in international übersetzten Business-Case-Vorlagen häufig fehlen und in der Praxis reale Budget- und Zeitfaktoren sind, keine bloßen Rechtsfußnoten.
Wenn eine KI-Anwendung Arbeitsabläufe von Mitarbeitenden verändert oder in irgendeiner Form Leistungs- beziehungsweise Verhaltensdaten berührt, greifen Mitbestimmungsrechte des Betriebsrats. Die daraus resultierenden Abstimmungs- und Genehmigungsprozesse benötigen Zeit und sollten von Beginn an als eigener Zeitplan-Baustein eingeplant werden, nicht erst dann, wenn die Einführung eigentlich schon starten sollte.
Sobald personenbezogene oder Kundendaten in ein Modell einfließen, entsteht Aufwand für eine datenschutzrechtliche Bewertung, in vielen Fällen eine Datenschutz-Folgenabschätzung. Dieser Aufwand ist real, planbar und sollte als eigene Position in der Implementierungskategorie erscheinen.
Je nach Anwendungsfall und dessen Risikoeinstufung nach dem EU AI Act entsteht zusätzlicher Aufwand für Compliance- und Klassifizierungsarbeit. Auch dieser Punkt gehört in die Kostenplanung und den Zeitplan, nicht in eine separate juristische Prüfung, die erst nach Projektfreigabe beginnt.
Alle drei Punkte werden in ersten Entwürfen von Business Cases regelmäßig übersehen, weil sie aus einer rein technischen oder betriebswirtschaftlichen Perspektive nicht unmittelbar sichtbar sind. Wer sie von Anfang an benennt, vermeidet spätere Zeitplan- und Budgetüberraschungen, die den ursprünglichen Business Case diskreditieren, selbst wenn die eigentliche Kalkulation solide war.
Ein Business Case, der eine ernsthafte Prüfung übersteht, folgt einer erkennbaren methodischen Reihenfolge. Am Anfang steht die Messung der Ausgangslage – Bearbeitungszeit, Fehlerquote, Kosten pro Vorgang, aktuelles Volumen – bevor überhaupt über die KI-Lösung selbst gesprochen wird. Ohne diese Baseline ist jede spätere Verbesserungsbehauptung eine Meinung, keine Messung.
Darauf aufbauend sollten alle zentralen Annahmen – Adoptionsgeschwindigkeit, Betriebskosten pro Einheit, Umfang der Change-Management-Maßnahmen – nicht als einzelne Zahl, sondern als konservatives, mittleres und optimistisches Szenario dargestellt werden. Wichtiger als die drei Szenarien selbst ist die Sensitivitätsanalyse: Welche einzelne Annahme verändert das Ergebnis am stärksten, wenn sie nach oben oder unten korrigiert wird? Diese Transparenz ist genau das, was ein Finance-Team von einem Vendor-Pitch unterscheidet – und sie erhöht die Wahrscheinlichkeit, dass der Business Case im Review nicht an einer einzelnen angreifbaren Annahme aufgehängt und verworfen wird.
Ebenfalls in die Modellierung gehört die Entscheidung zwischen Einkauf einer bestehenden Plattform und Eigenentwicklung, weil beide Wege unterschiedliche Kostenstrukturen erzeugen. Plattform- beziehungsweise Anbieterlösungen tendieren zu vorhersehbareren, stärker vorne im Projekt anfallenden Kosten. Eigenentwicklungen tragen dagegen tendenziell offenere, länger laufende Engineering- und Wartungskosten. Diese Weichenstellung sollte im Modell explizit sichtbar sein, weil sie bestimmt, welche Kostenkategorie im Zeitverlauf dominiert – sie sollte nicht implizit vorausgesetzt werden, ohne dass sie als eigene Variable auftaucht.
Ein Business Case endet nicht mit der Freigabe, sondern mit der Frage, wer nach der Einführung für die ROI-Zahl verantwortlich ist. Diese Verantwortung sollte bei der fachlichen Prozesseigentümerin oder dem Prozesseigentümer liegen, nicht bei IT oder beim Anbieter – beide haben zwar Einblick in die technische Funktion, aber keinen unmittelbaren Zugriff auf die geschäftliche Wirkung.
Ebenso wichtig ist ein festgelegter Rhythmus, in dem geplanter und tatsächlicher Wert verglichen werden – etwa quartalsweise in den ersten zwölf bis achtzehn Monaten nach Einführung. Fehlt dieser Mechanismus vollständig, entsteht ein strukturelles Problem, das über die einzelne Initiative hinausreicht: Finance-Teams, die wiederholt erleben, dass KI-Projekte ohne Nachweismessung eingeführt werden, verlieren generell das Vertrauen in KI-Business-Cases – nicht nur in den, der gerade zur Debatte steht. Ein Review-Mechanismus nach Go-live ist deshalb kein bürokratisches Add-on, sondern die Voraussetzung dafür, dass zukünftige Vorschläge überhaupt noch mit offener Aufmerksamkeit geprüft werden.
In der Summe entsteht so ein Business Case, der nicht auf einer einzelnen beeindruckenden Zahl beruht, sondern auf einer nachvollziehbaren Kette aus gemessener Ausgangslage, sauber getrennten Kostenkategorien, ehrlich gewichteten Wertfaktoren und einer klaren Verantwortung für die Zeit nach der Einführung. Genau diese Nachvollziehbarkeit – nicht die Höhe der prognostizierten Rendite – ist es, was eine KI-Initiative durch die Finanzprüfung trägt.