Budgetzeit, Vorsicht vor dem Versprechen 'mit KI bauen'
SaaS gegen ein mit KI gebautes System in Budgetzeit tauschen? Sieh, warum die Wartungskosten mehr wiegen als die Baukosten mit Vibe Coding ohne Prozess.
Wir befinden uns in der Budgetperiode in einem großen Teil der Unternehmen, und du hast diesen Satz sicher schon in irgendeinem Meeting gehört: "dieses System bauen wir intern, mit KI wird es billiger". Der Vorschlag scheint offensichtlich. Das Problem ist, dass nicht immer die richtigen Kosten berechnet werden.
Mit dem Fortschritt der KI ist es üblich geworden, Vibe Coding zu nutzen, um Systeme schnell zu bauen, ohne einen formalen Software-Engineering-Prozess zu durchlaufen. Und genau dort liegt das Risiko, vor dem ich in diesem Artikel warnen möchte.
Das Risiko, SaaS gegen mit Vibe Coding gebaute Software zu tauschen
Vibe Coding löst ein spezifisches Problem: Geschwindigkeit. Die KI baut schnell Code, aber Code ist nur ein Teil des Baus einer Software. Der Prozess ist es, der die Dinge organisiert, der Anforderungen, Architektur, Verantwortungsebenen, automatisierte Tests, Versionierung und Konfigurationsmanagement definiert.
Ohne Prozess hast du kein System. Du hast einen Prototyp, der heute funktioniert und den morgen kaum jemand erklären kann.
Die größten Kosten liegen nicht im Bau, sondern in der Wartung
Ich arbeite seit über 16 Jahren an Projekten zum Bau und zur Wartung von Systemen und kann bestätigen: Das ist der Punkt, der in der Entscheidung am meisten wiegt und im Budgetgespräch am wenigsten vorkommt. Der größte Teil des Aufwands und des Geldes einer Software liegt nicht im Bau, er liegt in der Wartung über die Jahre.
Wenn die Direktion erwägt, ein SaaS gegen ein internes System zu tauschen, vergleicht sie normalerweise die Kosten des aktuellen Abonnements mit den Baukosten. Diese Rechnung ist unvollständig. Es fehlt die Frage: Wie viel kostet es, diese neue Software zu warten? Wer wird Bugs korrigieren, Abhängigkeiten aktualisieren, sich an sich ändernde Systeme anpassen, Neueinsteiger schulen? Wie ich schon über wer zahlt, wer kauft und wer ein System wartet gesprochen habe, verlangt jede dieser Zielgruppen eine andere Rechnung, und wer am Ende die schlecht berechnete Wartung bezahlt, ist immer das Team, das bei dieser Entscheidung außen vor blieb.
Ohne einen gut definierten Entwicklungsprozess beim Bau wird die Wartung teurer, als im Budget vorgestellt.
Das aktuelle System zu klonen, löst das Problem nicht
Ein weiterer häufiger Fehler bei dieser Entscheidung ist, das Projekt als eine Kopie zu behandeln. Das Unternehmen will in der Praxis das SaaS duplizieren, das es schon nutzt, einschließlich Funktionen, die es nie wirklich genutzt hat und die für eine andere Realität gedacht waren (an die größtmögliche Anzahl von Kunden zu verkaufen), ein anderes Unternehmen, ein anderer Kontext.
Das ist nicht der Bau eines neuen Systems. Es ist die Replikation geistigen Eigentums Dritter und bringt dieselben Probleme ins eigene Haus, die das aktuelle System schon hatte, wie Anforderungen und Funktionen, die kaum Wert hinzufügen. Das Ziel sollte ein anderes sein: zu überlegen, was diese neue Software für die spezifische Realität deines Unternehmens sein muss, nicht das, was der SaaS-Anbieter zu bauen entschieden hat. Es geht im Grunde darum, die Spezifikationen zu hinterfragen, bevor man anfängt zu kopieren.
Der Weg, der funktioniert: Prozess, nicht nur Code
Auf einem soliden Modell zu bauen, ist das, was es ermöglicht, das System jahrelang zu warten und weiterzuentwickeln, weil der größte Teil der Arbeit in der Wartung liegt, nicht im Bau.
Das bedeutet nicht, auf KI zu verzichten. Es bedeutet, sie innerhalb eines Prozesses zu nutzen. KI-Agenten kommen hinzu, um die Kapazität des Software-Ingenieurs zu erweitern, und agieren innerhalb eines Flusses, der die Geschwindigkeit der KI mit der Kontrolle des Prozesses vereint. Frameworks organisieren die Arbeit dieser Agenten innerhalb des Entwicklungsflusses. Und der Kontext — die Dateien, die Regeln, die beteiligten Menschen — ist das, was diese Agenten aktuell und mit der Realität des Unternehmens abgestimmt hält.
Ich glaube, dass das die Kombination ist, Prozess plus KI, die ein System langfristig trägt. Vibe Coding allein, ohne Prozess, liefert Geschwindigkeit in jede Richtung. Ich sage das aus eigener Erfahrung: Ich versuchte, 3 Monate lang ein System ohne Fundament aufrechtzuerhalten, und das Ergebnis war offensichtlich — verwerfen und auf die richtige Art neu anfangen.
Die Frage, die vor der Budgetgenehmigung bleibt
Bevor du dieses SaaS kündigst, weil du denkst, dass du sparen wirst, stell dem Team diese Frage: Wir nehmen auf der einen Seite Kosten weg, aber welche Kosten erzeugen wir auf der anderen? Wie viel kostet es, diese neue Software zu warten, und was müssen wir strukturiert haben — Architektur, Versionierung, Konfiguration, Prozess —, um diese Wartung für die nächsten Jahre zu tragen? Und wenn diese Technologie das Unternehmen verlässt? Was kann getan werden? Welches Risiko hat diese Bewegung für das Geschäft?
Wenn diese Antwort vor der Budgetgenehmigung nicht existiert, ist das Problem nicht die Technologie. Es ist die Entscheidung.
Einen Gruß! Leandro | PMP | Projekt- und PMO-Manager
