Vom Pilot in die Fläche warum die Skalierung das Geld kostet.

Ein KI-Pilot lässt sich erstaunlich günstig aufsetzen: ein abgegrenzter Anwendungsfall, ein kleines Team, eine Handvoll Nutzer, ein paar Wochen Arbeit. Die Begeisterung ist groß, die Ergebnisse überzeugen, die Geschäftsführung gibt grünes Licht für den Rollout. Und dann passiert, was viele Unternehmen kalt erwischt: Der Übergang vom funktionierenden Prototyp in den Regelbetrieb kostet ein Vielfaches des Piloten, dauert länger als geplant und stößt auf Probleme, die im kleinen Maßstab gar nicht sichtbar waren. Der Pilot war billig, weil er von vielem verschont blieb, was im Produktivbetrieb unverzichtbar ist: Integration, Sicherheit, Betrieb, Governance, Change-Management. Dieser Beitrag zeigt, welche Kostentreiber zwischen Proof of Concept und produktivem System lauern, warum eine naive Hochrechnung in die Irre führt und wie eine belastbare Skalierungsrechnung aussieht, die böse Überraschungen vermeidet und ein Projekt nicht zwischen Erfolg und Ernüchterung scheitern lässt.

Warum der Pilot ein trügerisches Preisschild trägt.

Ein Pilot ist absichtlich vereinfacht. Er nutzt einen sauberen Ausschnitt der Daten, läuft für wenige wohlwollende Nutzer, verzichtet auf tiefe Integration und ignoriert die meisten Sonderfälle. Genau diese Vereinfachungen machen ihn günstig, und genau sie verschwinden im Produktivbetrieb.

Das führt zu einem systematischen Denkfehler: Man nimmt die Pilotkosten und multipliziert sie linear mit der Zahl der Nutzer oder Anwendungsfälle. Diese Rechnung ist fast immer falsch, weil sie die Kostenarten verwechselt. Der Pilot deckt vor allem die Machbarkeit ab, der Rollout dagegen die Industrialisierung, und das sind unterschiedliche Aufgaben mit unterschiedlichen Kostenstrukturen.

Eine realistische Faustregel aus vielen Projekten: Wenn der Pilot einen bestimmten Betrag gekostet hat, liegt der Weg in einen stabilen Produktivbetrieb oft beim Drei- bis Zehnfachen, in komplexen Fällen darüber. Das ist keine Ausnahme, sondern die Regel, und wer es einplant, vermeidet die Enttäuschung, dass das Projekt nach dem erfolgreichen Pilot plötzlich teuer und mühsam wird.

Die Integration, die im Pilot fehlte.

Im Pilot werden Daten oft manuell bereitgestellt, Exporte hin und her geschoben, Ergebnisse von Hand übernommen. Im Produktivbetrieb muss das System in die bestehende IT-Landschaft eingebettet sein, und genau diese Anbindung ist einer der größten Kostentreiber.

Konkret geht es um Schnittstellen zum ERP, CRM, zu Dokumentenmanagement, Datenbanken und Identitätsverwaltung. Jede dieser Anbindungen bringt Abstimmungsaufwand, Tests, Berechtigungskonzepte und Wartung mit sich. Hinzu kommt die Datenaufbereitung im Dauerbetrieb: Daten, die im Pilot einmalig sauber gemacht wurden, müssen nun kontinuierlich und automatisiert in der nötigen Qualität fließen.

Unterschätzt wird auch die Heterogenität der Realität. Im Pilot betrachtet man einen Standort, eine Abteilung, ein Format. In der Fläche treffen unterschiedliche Systeme, Datenstände, Sonderlocken und gewachsene Prozesse aufeinander. Was für einen Fall funktioniert, muss für zwanzig Varianten angepasst werden, und diese Anpassungen summieren sich.

Betrieb, Sicherheit und Governance kommen hinzu.

Ein Pilot läuft oft auf provisorischer Infrastruktur und unter den Augen seines Erbauers. Im Produktivbetrieb braucht es einen echten Betriebsrahmen, und der erzeugt laufende Kosten, die der Pilot nicht hatte:

• Verfügbarkeit und Überwachung: Das System muss verlässlich laufen, überwacht werden, Ausfälle müssen behandelt werden.
• Sicherheit: Zugriffskontrollen, Protokollierung, Penetrationstests, Datenschutz, je nach Anwendung erheblicher Aufwand.
• Wartung der Modelle: Modelle veralten, Daten verschieben sich, Qualität muss kontinuierlich geprüft und nachjustiert werden.
• Support: Nutzer haben Fragen, melden Fehler, brauchen Hilfe, das bindet dauerhaft Ressourcen.
• Governance und Compliance: Dokumentation, Freigaben, regulatorische Anforderungen, gerade bei kritischen Anwendungen.

Diese Posten sind im Pilot fast unsichtbar, weil ein Prototyp sie nicht braucht. Im Regelbetrieb sind sie unverzichtbar und machen einen großen Teil der laufenden Kosten aus. Wer nur die Entwicklung einplant und den Betrieb vergisst, baut ein System, das niemand zuverlässig am Laufen halten kann.

Der menschliche Faktor wird am häufigsten übersehen.

Die teuerste und am meisten unterschätzte Kategorie ist nicht technisch, sondern organisatorisch. Ein Pilot überzeugt eine kleine, motivierte Gruppe. Der Rollout muss eine ganze Belegschaft mitnehmen, und das ist Arbeit, die sich nicht mit Software erledigen lässt.

Change-Management bedeutet Schulung, Kommunikation, das Auffangen von Widerständen, das Anpassen von Prozessen und Rollen. Mitarbeiter müssen verstehen, warum sich ihre Arbeit ändert, und sie müssen dem System vertrauen lernen. In vielen Projekten ist genau das die Klippe, an der die Wirtschaftlichkeit kippt: Die Technik funktioniert, aber die Nutzung bleibt aus, weil niemand den Übergang aktiv gestaltet hat.

Realistisch sind hier Zeiträume von Monaten, nicht Wochen, bis ein neues System in einer Organisation wirklich angekommen ist. Diese Zeit, und die damit verbundenen Kosten für Begleitung und Produktivitätsdelle in der Umstellungsphase, gehören in jede ehrliche Skalierungsrechnung. Wer sie weglässt, plant ein Projekt, das auf dem Papier rentabel ist und in der Praxis stockt.

Eine belastbare Skalierungsrechnung aufsetzen.

Statt die Pilotkosten linear hochzurechnen, lohnt sich eine Rechnung, die zwischen einmaligen und laufenden Kosten und zwischen den verschiedenen Kostenarten trennt. Die folgende Struktur hilft, nichts zu vergessen:

Aus dieser Struktur ergeben sich zwei Zahlen, die getrennt betrachtet werden müssen: eine einmalige Investition für den Übergang in die Fläche und laufende Betriebskosten pro Jahr. Erst beide zusammen, gestellt gegen den erwarteten Nutzen, ergeben einen tragfähigen Business Case. Eine reine Investitionsbetrachtung ohne Betriebskosten führt regelmäßig zu Projekten, die sich nie rechnen.

Früh dagegen planen, statt später zu reparieren.

Die wirksamste Gegenmaßnahme ist, die Skalierung schon im Pilot mitzudenken. Das heißt nicht, den Piloten zu überladen, sondern bewusste Entscheidungen zu treffen, die einen späteren Rollout erleichtern statt erschweren.

Bewährt hat sich, beim Piloten gezielt die schwierigen Fälle anzuschauen, nicht nur die einfachen, damit man die Bandbreite der Realität früh kennt. Ebenso hilft es, früh mit der IT zu klären, wie eine echte Integration aussehen würde, statt das auf später zu verschieben. Und es lohnt sich, schon im Piloten zu beobachten, wie die Nutzer reagieren, weil das die spätere Akzeptanz vorhersagt.

Ein zweiter Hebel ist die Wahl des Vorgehens. Ein stufenweiser Rollout, der mit einem Bereich beginnt und schrittweise ausweitet, verteilt Kosten und Risiko und erlaubt Lernen. Ein Big-Bang-Rollout über die ganze Organisation auf einmal ist verlockend, weil schneller, aber er erhöht das Risiko, dass alle Probleme gleichzeitig auftreten.

Wann sich die Skalierung nicht lohnt.

Zur Ehrlichkeit gehört auch die Bereitschaft, einen erfolgreichen Piloten nicht zu skalieren. Nicht jeder Anwendungsfall, der im Kleinen funktioniert, trägt die vollen Kosten der Industrialisierung. Manchmal ist der Nutzen real, aber zu klein, um die Integration, den Betrieb und das Change-Management zu rechtfertigen.

Das ist kein Scheitern, sondern eine kluge Entscheidung, vorausgesetzt, sie fällt bewusst und auf Basis einer ehrlichen Rechnung. Schlimmer ist der Fall, in dem ein Projekt aus Stolz oder Trägheit weiterläuft, obwohl die Wirtschaftlichkeit nicht trägt, und dauerhaft Ressourcen bindet, die anderswo mehr bringen würden.

Die nüchterne Einordnung lautet deshalb: Der Pilot beweist die Machbarkeit, nicht die Wirtschaftlichkeit im Maßstab. Erst eine vollständige Skalierungsrechnung beantwortet die eigentliche Frage, und manchmal lautet die richtige Antwort, es bei einem klugen Pilot zu belassen und die Mittel in den nächsten, größeren Hebel zu lenken.

Ihr KI-Pilot überzeugt und Sie wollen wissen, was der Rollout wirklich kostet, bevor Sie ihn starten? Unverbindlich anfragen — wir erstellen mit Ihnen eine belastbare Skalierungsrechnung über Integration, Betrieb und Change, sodass Sie die Entscheidung für oder gegen die Fläche auf Zahlen stützen, nicht auf Hoffnung.