Wie wir den Business Case einer lokalen KI berechnen

Das Wichtigste in Kürze

• Ausgangspunkt sind die heutigen Kosten des gesamten Prozesses, nicht nur die reine Bearbeitungszeit.
• Auch nach der Einführung bleiben Prüfung, Ausnahmen und Betrieb — sie gehören in die Rechnung.
• Lokale KI kostet Hardware oder Miete, aber vor allem Integration, Tests, Schulung und Wartung.
• Eine Rechnung mit mehreren Annahmen zeigt, ab welcher Menge und Qualität sich das Vorhaben trägt.
• Freie Kapazität ist ein eigener Nutzen. Sie muss nicht sofort in Stellenabbau übersetzt werden.

Bei Cloud-KI wird gern über Tokenpreise gesprochen. Bei lokaler KI richtet sich der Blick schnell auf den Rechner. Beides ist für einen Business Case zu klein gedacht.

Ein Modellaufruf erzeugt noch keinen Nutzen. Nutzen entsteht, wenn ein kompletter Prozess schneller, verlässlicher oder überhaupt erst ausführbar wird. Dazwischen liegen Schnittstellen, Prüfungen, Freigaben und täglicher Betrieb.

Wir berechnen nicht den Preis der KI. Wir berechnen die Veränderung eines Geschäftsprozesses.

Die Rechnung hat vier Blöcke: den heutigen Prozess mit seiner Zeit, seinen Fehlern, Rückfragen und Liegezeiten; den Zielprozess mit Automatik, Prüfung und Ausnahmen; den Aufbau mit Analyse, Entwicklung, Test und Einführung; und den laufenden Betrieb mit Plattform, Pflege, Strom und Verantwortung. Wer einen der vier weglässt, rechnet sich das Projekt schön oder kaputt — beides kommt vor.

1. Die heutigen Prozesskosten bestimmen

Die Rechnung beginnt mit der Zahl der Vorgänge und der tatsächlichen Zeit je Vorgang. Schon die erste Größe ist selten bekannt. In einem Projekt gingen die Schätzungen im Raum weit auseinander — jede Abteilung kannte ihren Ausschnitt, niemand das Ganze. Gezählt hat am Ende das Sammelpostfach.

Dazu kommt der interne Stundensatz. Er umfasst nicht nur den Bruttolohn, sondern die betriebliche Vollkostenrechnung. An dieser Stelle nennt erfahrungsgemäß jemand den Lohn, der Controller nennt die Vollkosten, und die Runde wird kurz still.

Zusätzlich betrachten wir:

• Rückfragen zwischen Abteilungen,
• doppelte Erfassung in mehreren Systemen,
• Korrekturen und Reklamationen,
• Liegezeiten mit Wirkung auf Kunden oder Produktion,
• Überstunden oder externe Unterstützung in Spitzenzeiten,
• Arbeit, die liegen bleibt, weil qualifizierte Kapazität gebunden ist.

Eine künstliche Genauigkeit auf Cent-Ebene hilft nicht. Eine ehrliche Größenordnung schon.

2. Den Zielprozess realistisch beschreiben

Nicht jeder Fall wird vollständig automatisch. Für eine belastbare Rechnung teilen wir die Vorgänge in drei Gruppen:

Die wichtigste Annahme ist häufig nicht die Modellgenauigkeit, sondern die verbleibende Prüfzeit. Wir haben Lösungen gesehen, die fast alle Felder richtig lasen und trotzdem kaum Zeit sparten — weil die Prüferin aus Gewohnheit jedes Feld erneut gegen das PDF hielt. Die Prüfzeit sinkt erst, wenn die Oberfläche Vertrauen verdient: mit Fundstellen im Dokument und einem klaren Hinweis, welche Werte unsicher sind. Das ist keine Frage des Modells, sondern der Gestaltung.

3. Einmalige Kosten vollständig erfassen

• Prozessanalyse und klare fachliche Regeln,
• Aufbereitung echter Fälle und Aufbau des Testsatzes,
• Auswahl von Modell und Hardware,
• Entwicklung der Agenten und Schnittstellen,
• Oberfläche für Prüfung und Freigabe,
• Sicherheits-, Datenschutz- und Rechtsprüfung,
• Pilot, Abnahme, Dokumentation und Schulung,
• interne Zeit aus Fachbereich, IT und Projektleitung.

Gerade die Zeit der Fachleute wird oft vergessen. Die Person, deren Urteil der Testsatz braucht, ist erfahrungsgemäß dieselbe, die im Tagesgeschäft am schwersten zu entbehren ist. Ihre Stunden gehören in die Rechnung — nicht als Fußnote, sondern als Posten.

4. Den laufenden Betrieb einrechnen

Ein Rechenmuster mit runden Zahlen

Ein Betrieb bearbeitet 1.000 Vorgänge im Monat. Heute dauert ein Vorgang im Mittel zwölf Minuten. Bei internen Vollkosten von 50 Euro je Stunde entstehen 10.000 Euro direkte Arbeitskosten pro Monat.

Im Zielprozess verteilen sich die Fälle so:

• 700 Standardfälle mit je zwei Minuten Prüfung,
• 250 Prüffälle mit je sechs Minuten Arbeit,
• 50 Ausnahmen mit je zwölf Minuten Arbeit.

Damit bleiben rund 58 Stunden Arbeit oder knapp 2.900 Euro. Kommen 1.800 Euro laufende Systemkosten hinzu, liegt der monatliche Aufwand bei etwa 4.700 Euro. Gegenüber dem heutigen Prozess werden rund 5.300 Euro Kapazität frei.

Bei einmaligen Projektkosten von 80.000 Euro läge die einfache Rückzahlungszeit bei rund 15 Monaten. Fehlerkosten, kürzere Antwortzeiten und weitere Anwendungen auf derselben Plattform sind dabei noch nicht berücksichtigt.

Die Grundformel dahinter ist unspektakulär: Der monatliche Nutzen ist die Differenz aus heutigen Prozesskosten, den Kosten des Zielprozesses und den laufenden Systemkosten. Die Rückzahlungszeit ergibt sich, indem die einmaligen Projektkosten durch diesen Nutzen geteilt werden. Anspruchsvoll ist nicht die Formel. Anspruchsvoll sind ehrliche Zahlen für ihre drei Bestandteile.

Mehrere Annahmen statt einer schönen Zahl

Fallmenge, Prüfzeit und Anteil der Ausnahmen sind selten sicher. Deshalb rechnen wir mindestens drei Lagen:

Die Rechnung zeigt damit, welche Annahmen den Erfolg tragen. Genau diese Größen müssen im Pilotprojekt gemessen werden — nicht vermutet, gemessen.

Nutzen ist mehr als eingesparte Zeit

Bei knappen Fachkräften ist freie Kapazität oft wertvoller als ein rechnerischer Personalabbau. Sie kann in Kundenarbeit, Planung, Qualität oder Wachstum fließen. In einem Projekt war die erste sichtbare Folge der Entlastung, dass ein seit Monaten aufgeschobenes Lieferantengespräch endlich stattfand. In keiner Tabelle wäre das aufgetaucht.

Weitere messbare Wirkungen sind:

• schnellere Antwort an Kunden,
• weniger Übertragungsfehler,
• gleichmäßigere Bearbeitung in Spitzenzeiten,
• kürzere Einarbeitung neuer Mitarbeitender,
• bessere Nachvollziehbarkeit,
• weitere Anwendungen auf einer bereits betriebenen Plattform.

Diese Wirkungen werden nicht beliebig in Euro verwandelt. Sie gehören getrennt in die Entscheidung.

Wann die Rechnung nicht trägt

• Der Vorgang tritt zu selten auf.
• Die heutige Arbeit ist kaum belastend und bereits zuverlässig.
• Jeder Fall bleibt eine vollständige manuelle Prüfung.
• Die Datenlage erfordert dauerhaft viel Nacharbeit.
• Die Anbindung an Altsysteme ist unverhältnismäßig teuer.
• Eine Standardsoftware löst denselben Engpass günstiger.

Fazit

Der Business Case einer lokalen KI ist eine Prozessrechnung. Sie verbindet heutige Arbeit, realistische Entlastung, Projektkosten und laufenden Betrieb.

Eine gute Rechnung enthält Unsicherheit. Sie zeigt, bei welcher Fallmenge, Prüfzeit und Fehlerquote das Vorhaben trägt. Damit liefert der Pilot nicht nur eine technische Antwort, sondern die Zahlen für eine vernünftige Entscheidung.

Quellen und weiterführende Hinweise

1. NIST: AI Risk Management Framework
2. BSI: Informationen zu Künstlicher Intelligenz

Ein Business Case braucht echte Prozessdaten

Menge, Bearbeitungszeit, Prüfaufwand und Ausnahmen bilden die Grundlage einer belastbaren Rechnung.

Business Case besprechen