Der Go-live ist kein Abschluss.

Vor dem Go-live arbeitet das System unter kontrollierten Bedingungen

Während der Entwicklung werden Anforderungen strukturiert, Testfälle vorbereitet und Daten gezielt geprüft. Selbst produktionsnahe Tests können jedoch nicht vollständig abbilden, wie sich ein System im Alltag verhält.

Nach dem Go-live entstehen neue Erkenntnisse:

• Nutzer verwenden Funktionen anders als erwartet.
• Sonderfälle treten häufiger auf als angenommen.
• Datenquellen liefern unvollständige oder veränderte Inhalte.
• Prozesse werden organisatorisch angepasst.
• Last und Nutzung verteilen sich anders.
• Schnittstellen verhalten sich nicht immer stabil.
• Neue regulatorische oder geschäftliche Anforderungen entstehen.

Der Go-live beendet damit die Entwicklungsphase, aber nicht die Produktentwicklung.

Technischer Betrieb ist die Grundlage

Ein geschäftskritisches System benötigt nach der Inbetriebnahme mindestens:

Diese Aufgaben sorgen dafür, dass technische Probleme erkannt und behoben werden können. Sie sagen aber noch nicht automatisch, ob das System fachlich richtig arbeitet.

Fachlicher Betrieb ist ebenso wichtig

Eine Datenpipeline kann technisch erfolgreich laufen und trotzdem zu wenige Datensätze liefern. Ein KI-System kann erreichbar sein und dennoch schlechtere Ergebnisse erzeugen. Eine Commerce-Schnittstelle kann Antworten liefern, aber veraltete Bestände übertragen.

Deshalb braucht es fachliche Betriebsindikatoren:

• Sind die Daten aktuell?
• Sind erwartete Mengen vollständig eingegangen?
• Haben Prozesse alle vorgesehenen Schritte durchlaufen?
• Steigen Fehler- oder Eskalationsquoten?
• Werden ungewöhnlich viele Datensätze manuell korrigiert?
• Verändert sich die Qualität von KI-Ergebnissen?
• Gibt es Abweichungen zwischen Systemen?
• Bleiben Vorgänge in einem Zwischenstatus hängen?

Produktbetrieb verbindet technische Observability mit fachlicher Plausibilität.

Reale Nutzung verändert Prioritäten

Vor dem Launch entstehen Prioritäten aus Annahmen, Interviews und Geschäftsstrategie. Nach dem Launch kommen tatsächliche Nutzungsdaten und Supportfälle hinzu.

Das kann zeigen:

• Eine vermeintlich kleine Funktion ist im Alltag zentral.
• Ein geplanter Ausbau wird kaum nachgefragt.
• Nutzer umgehen einen Prozess, weil ein Zwischenschritt fehlt.
• Ein Datenproblem verursacht mehr Aufwand als eine fehlende Oberfläche.
• Bestimmte Rollen oder Organisationen benötigen andere Abläufe.
• Ein manueller Kontrollpunkt kann sicher automatisiert werden.
• Eine vollständige Automatisierung erzeugt an anderer Stelle neue Risiken.

Kontinuierliche Produktentwicklung bedeutet, diese Erkenntnisse systematisch in Architektur und Roadmap zu überführen.

Integrationen verändern sich

Externe und interne Systeme bleiben nicht statisch. APIs werden aktualisiert, Datenfelder verändern sich, Authentifizierungsverfahren wechseln und Quellsysteme werden ersetzt.

Ein belastbares Produkt benötigt deshalb:

• Versionsmanagement
• Monitoring von Schnittstellen
• Wiederholungs- und Fehlerstrategien
• nachvollziehbare Datenflüsse
• klar definierte Verantwortlichkeiten
• Tests für kritische Integrationen
• kontrollierte Migrationen

Je mehr Systeme beteiligt sind, desto stärker wird Integrationsbetrieb zu einer eigenen Disziplin.

KI benötigt kontinuierliche Evaluation

Bei KI-Systemen kommen zusätzliche Veränderungen hinzu:

• Modelle werden aktualisiert oder ausgetauscht.
• Prompts und Orchestrierung entwickeln sich weiter.
• Wissensquellen verändern sich.
• Neue Nutzerfragen treten auf.
• Fachregeln werden angepasst.
• Qualitätsanforderungen steigen.

Eine einmalige Abnahme reicht deshalb nicht. Testsets, reale Korrekturen, Fehlermuster und Nutzerfeedback müssen in einen fortlaufenden Evaluationsprozess einfließen.

Architektur muss Veränderung ermöglichen

Ein System, das nur für den ersten Launch optimiert wurde, wird bei jeder Erweiterung teurer und riskanter.

Wichtige Grundlagen für langfristige Weiterentwicklung sind:

• klare Modul- und Systemgrenzen
• nachvollziehbare Datenmodelle
• automatisierte Tests
• reproduzierbare Deployments
• dokumentierte Integrationen
• kontrollierte Konfiguration
• Rollen- und Berechtigungsmodelle
• Observability
• geeignete Migrationsmechanismen

Wartbarkeit ist damit keine rein technische Qualitätsdimension. Sie bestimmt, wie schnell das Unternehmen auf neue Anforderungen reagieren kann.

Ein dauerhaftes Verantwortungsmodell

Nach dem Go-live muss klar sein:

• Wer überwacht das System?
• Wer bewertet fachliche Auffälligkeiten?
• Wer priorisiert Weiterentwicklungen?
• Wer entscheidet über Architekturänderungen?
• Wer kommuniziert bei Störungen?
• Wer pflegt Integrationen und Abhängigkeiten?
• Wer verantwortet Daten- und KI-Qualität?

Diese Verantwortung kann intern, extern oder in einem gemeinsamen Produktteam organisiert werden. Entscheidend ist, dass sie ausdrücklich vorhanden ist.

Abschluss

Ein digitales Produkt ist nicht fertig, wenn es erstmals erreichbar ist. Es wird im laufenden Betrieb belastbar, verstanden und wertvoller. Deshalb sollten Architektur, Team und Verantwortungsmodell von Anfang an auf Weiterentwicklung ausgelegt sein.