Hypercare-Phase: Was nach dem Go-live von Software und KI-Automatisierung passieren muss

Die Hypercare-Phase ist die zeitlich begrenzte Phase intensiver Betreuung direkt nach dem Go-live einer Software. Das Entwicklungsteam bleibt eng am System, behebt Fehler schnell, beobachtet den Betrieb und sammelt alle Rückmeldungen an einer Stelle. Üblich sind zwei bis sechs Wochen. Sie endet aber nicht nach Kalender, sondern wenn vorher vereinbarte Exit-Kriterien erfüllt sind. Danach übernimmt der Regelbetrieb mit Wartung, Support und Weiterentwicklung.

Der Begriff stammt aus großen ERP- und SAP-Einführungen. Er ist aber genauso wichtig für Individualsoftware und KI-Automatisierungen im Mittelstand. Gerade dort fehlt die Hypercare oft ganz: Das System geht live, das Projekt gilt als abgeschlossen, und die ersten Probleme landen per Zuruf bei der Person, die zufällig erreichbar ist. In diesem Beitrag erfahren Sie:

• was eine Hypercare-Phase genau ist und wie sie sich vom Regelbetrieb unterscheidet,
• wie lange sie dauern sollte und woran Sie das Ende erkennen,
• welche fünf Bausteine in jede Hypercare gehören,
• worauf Sie bei KI-Automatisierungen zusätzlich achten müssen,
• und wie der Übergang in Wartung und Betrieb gelingt.

Was ist eine Hypercare-Phase?

„Hypercare“ heißt wörtlich übersetzt etwa „besonders intensive Betreuung“. Gemeint ist der Zeitraum, in dem ein neues System zum ersten Mal unter echten Bedingungen läuft: mit echten Daten, echten Nutzerinnen und Nutzern und echtem Zeitdruck. In diesem Zeitraum zeigen sich Fehler, die kein Test gefunden hat. Sonderfälle, an die niemand gedacht hat. Abläufe, die in der Praxis anders laufen als im Konzept.

Die Hypercare ist deshalb kein Puffer für Unfertiges. Sie ist eine eigene Projektphase mit eigenem Ziel: das System so zu stabilisieren, dass es danach ohne erhöhte Aufmerksamkeit zuverlässig läuft.

Dahinter steht eine Haltung, die Amazon-CTO Werner Vogels schon 2006 in einem Interview mit ACM Queue auf fünf Wörter gebracht hat: „You build it, you run it.“ Wer ein System baut, betreibt es auch (AWS News Blog). Bei Amazon war das die Antwort auf Software, die über die Mauer zum Betrieb geworfen wurde. Im Mittelstand ist es die Antwort auf ein verbreitetes Muster: Eine Agentur baut ein MVP, übergibt es und ist weg. Wir bei TAISC arbeiten bewusst anders, weil ein Projekt mit dem Launch nicht fertig ist. Dann beginnt erst der Betrieb.

Go-live, Hypercare, Regelbetrieb: Was ist der Unterschied?

Wichtig ist der Wechsel in der dritten Zeile. In der Hypercare bleibt das Team, das das System gebaut hat, verantwortlich. Es kennt den Code, die Datenflüsse und die Entscheidungen hinter jedem Sonderfall. Wer genau diese Leute direkt nach dem Go-live abzieht, verlängert jede Fehlersuche um Tage.

Wie lange dauert eine Hypercare-Phase?

Eine feste Dauer gibt es nicht. In der Praxis sind zwei bis sechs Wochen üblich. SAP bietet für bestimmte Services Hypercare-Pakete von vier oder acht Wochen an, das ist aber kein allgemeiner Standard (LeverX). Wie lange es bei Ihnen dauert, hängt vor allem von vier Faktoren ab:

• Anzahl der Nutzer und Standorte. Mehr Menschen finden mehr Sonderfälle.
• Schnittstellen. Jede Anbindung an ein anderes System ist eine mögliche Fehlerquelle, die erst mit echten Daten sichtbar wird.
• Kritikalität des Prozesses. Ein System, über das Aufträge, Rechnungen oder Löhne laufen, braucht eine längere und engere Hypercare als ein internes Wiki.
• Anteil an KI-Schritten. Automatisierungen mit Sprachmodellen zeigen manche Schwächen erst nach Wochen, wenn genug unterschiedliche Fälle durchgelaufen sind (dazu unten mehr).

Unsere Faustregel aus Projekten im Mittelstand, als Schätzung: Für ein internes Tool mit wenigen Schnittstellen reichen oft zwei bis drei Wochen. Ein Portal, mit dem ein ganzes Team täglich arbeitet und hinter dem Automatisierungen laufen, braucht eher vier bis acht Wochen. Entscheidend ist ohnehin nicht die Zahl der Wochen, sondern die Frage, ob die Exit-Kriterien erfüllt sind.

Was gehört in die Hypercare? Fünf Bausteine

Ein gut gebautes System ohne Betriebsprozess wird schnell unübersichtlich. Das liegt nicht an der Technik, sondern daran, dass Rückmeldungen über viele Kanäle von vielen Personen kommen: per Mail, per Telefon, im Flur, im Chat. Niemand hat den Überblick, niemand priorisiert, und Ausfälle fallen erst auf, wenn sich jemand beschwert. Diese fünf Bausteine verhindern das.

1. Ein Meldeweg mit Ticketnummer

Alle Rückmeldungen laufen über genau einen Kanal, zum Beispiel eine eigene Support-Adresse. Jede Meldung bekommt automatisch eine Ticketnummer. Das klingt bürokratisch, löst aber drei Probleme auf einmal: Nichts geht verloren, jeder kann nachfragen, und doppelte Meldungen zum selben Problem werden sichtbar. Ein großes Ticketsystem ist dafür nicht nötig. Für die meisten Mittelständler reicht anfangs eine Support-Adresse, die Tickets in einer einfachen Liste anlegt.

2. Ein festes Log

Jede Meldung, jede Ursache, jede Lösung landet an einer Stelle. Dieses Log ist in der Hypercare das wichtigste Dokument. Es zeigt, welche Fehler sich häufen, welche Bereiche instabil sind und ob die Zahl neuer Meldungen sinkt. Am Ende der Hypercare wird daraus die Grundlage für das Betriebshandbuch: Welche Fehler kennen wir, woran erkennt man sie, was ist zu tun?

3. Ein kleiner Kreis an Meldeberechtigten

Nicht jede Person im Unternehmen meldet direkt an das Entwicklungsteam. Stattdessen gibt es wenige Key User, die das System gut kennen. Sie beantworten einfache Fragen im eigenen Team, filtern Bedienfehler heraus und bündeln echte Probleme. Das entlastet beide Seiten und sorgt dafür, dass Meldungen mit genug Kontext ankommen, um sie schnell zu lösen.

4. Ein fester Review-Termin

In der Hypercare gehören kurze Abstimmungen fest in den Kalender, anfangs gern mehrmals pro Woche. Für den Regelbetrieb hat sich bei uns ein Review alle zwei Wochen bewährt. Dort wird das Log durchgegangen: Was ist gelöst, was ist offen, was ist ein Fehler und was ein Wunsch für die Weiterentwicklung? Genau diese Trennung geht ohne festen Termin verloren. Dann werden kleine Wünsche zu dringenden Fehlern erklärt, und echte Fehler warten hinter Komfortfunktionen.

5. Monitoring, das vor den Nutzern meldet

Der wichtigste Baustein ist der technische. Ein System, bei dem Ausfälle erst durch Beschwerden auffallen, ist nicht betriebsbereit. Mindestens nötig sind:

• Fehlerbenachrichtigungen für abgebrochene Abläufe, fehlgeschlagene Schnittstellenaufrufe und Server-Fehler.
• Prüfungen auf Stille. Eine Automatisierung, die seit gestern keinen einzigen Lauf hatte, ist oft kaputter als eine, die Fehler wirft.
• Wenige, aber relevante Alarme. Das Site-Reliability-Handbuch von Google formuliert es klar: Jede Benachrichtigung, die einen Menschen weckt, muss eine Handlung erfordern (Google SRE Book). Wer bei jeder Kleinigkeit alarmiert, wird bald gar nicht mehr hinschauen.

Dazu kommen kleine, häufige Korrekturen statt großer Updates, getrennte Test- und Produktionsumgebungen und ein getesteter Rollback. Wie das technisch aussieht, beschreiben wir im Beitrag Vibe Coding in Produktion bringen.

Ein Beispiel aus der Praxis

Für den Wärmepumpen-Fachbetrieb Wärme mit Konzept haben wir ein Auftragsportal für Subunternehmer gebaut, mit einer Automatisierung im Hintergrund, die Daten zwischen den Systemen abgleicht. Seit dem Go-live im Sommer arbeitet das Team täglich damit, und entsprechend viele Rückmeldungen kamen in den ersten Wochen. Das ist ein gutes Zeichen: Ein System, zu dem niemand etwas sagt, wird meist nicht genutzt.

Anfangs liefen diese Rückmeldungen über verschiedene Kanäle und Personen. Gemeinsam mit dem Kunden haben wir deshalb genau die Bausteine von oben eingeführt: eine eigene Support-Adresse mit Ticketnummer, ein festes Log, einen Review-Termin alle zwei Wochen und einen kleinen Kreis an Meldeberechtigten. Aus Zuruf und Bauchgefühl wurde so ein Ablauf, der Prioritäten kennt und Störungen früh sichtbar macht. Das Portal wird seitdem Schritt für Schritt besser, statt mit jeder neuen Anfrage unübersichtlicher.

Die Lehre daraus: Den Betriebsprozess hätten wir schon vor dem Go-live festlegen können. Heute ist er bei uns fester Teil jedes Projektplans.

Hypercare bei KI-Automatisierungen: Was ist anders?

Klassische Software ist deterministisch. Ein Fehler tritt bei denselben Eingaben immer wieder auf, und wenn er behoben ist, ist er behoben. Bei Automatisierungen mit Sprachmodellen gilt das nur eingeschränkt. Vier Punkte brauchen deshalb in der Hypercare besondere Aufmerksamkeit.

Stille Fehler. Ein KI-Schritt, der eine Mail falsch einordnet oder ein Feld aus einer PDF falsch ausliest, wirft keine Fehlermeldung. Das Ergebnis sieht plausibel aus und ist trotzdem falsch. In der Hypercare gehören deshalb Stichproben dazu: Ein Mensch prüft regelmäßig eine Auswahl echter Ergebnisse. Bei folgenreichen Schritten bleibt eine menschliche Freigabe im Prozess, das Prinzip Human-in-the-Loop.

Sonderfälle brauchen Zeit. Ein Sprachmodell trifft im Test oft die typischen Fälle. Die schwierigen kommen erst nach Wochen: ungewöhnliche Formate, Mischsprachen, unvollständige Angaben. Jeder davon gehört in eine Sammlung von Testfällen, mit der Sie Änderungen später automatisch prüfen. Mehr dazu im Glossar unter Evaluation.

Abbrüche müssen laut sein. Workflow-Tools bieten dafür eigene Mechanismen. In n8n lässt sich für jeden Workflow ein Fehler-Workflow hinterlegen, der bei jedem fehlgeschlagenen Lauf startet und zum Beispiel eine Mail oder eine Slack-Nachricht verschickt (n8n-Dokumentation). Diese Einstellung kostet fünf Minuten und fehlt trotzdem in vielen Workflows, die wir übernehmen.

Kosten und Modelle ändern sich. Modellanbieter aktualisieren und ersetzen Modelle regelmäßig. Die Kosten pro Vorgang hängen davon ab, wie viel Text tatsächlich verarbeitet wird. Beides gehört ins Monitoring, nicht erst in die Monatsabrechnung.

Ein weiterer Grund, die Hypercare ernst zu nehmen: Mit KI entsteht Software heute deutlich schneller, aber nicht automatisch stabiler. Laut DORA-Report 2024 von Google Cloud ging steigender KI-Einsatz in der Entwicklung mit einer geschätzt um 7,2 % geringeren Stabilität der Auslieferung einher. Die Autoren folgern, dass ein schnellerer Entwicklungsprozess nicht automatisch bessere Auslieferung bedeutet, solange Grundlagen wie kleine Änderungen und robuste Tests fehlen. Kleine Schritte und ein sauberer Betrieb sind also gerade bei KI-gestützter Entwicklung kein Luxus.

Woran erkennen Sie, dass die Hypercare vorbei ist?

Die Hypercare endet, wenn das System ohne erhöhte Aufmerksamkeit zuverlässig läuft. Legen Sie die Kriterien dafür vor dem Go-live fest, damit das Ende keine Gefühlsentscheidung wird. Mit dem folgenden Check sehen Sie, wo Ihr System steht:

Nach der Hypercare: Software-Wartung und Regelbetrieb

Mit dem Ende der Hypercare beginnt der längste Teil im Leben einer Software. Laut der International Software Benchmarking Standards Group entfallen auf Wartung und Pflege einer Anwendung schätzungsweise 65 bis 85 % der gesamten Kosten über ihre Lebensdauer (ISBSG, 2022). Selbst wenn Ihr Anteil am unteren Ende liegt: Wer nur die Entwicklung budgetiert, plant den kleineren Teil.

Zur Software-Wartung im Regelbetrieb gehören vier Arten von Arbeit:

Für die Priorisierung hilft eine einfache Einteilung. Die folgenden Reaktionszeiten sind ein Beispiel aus der Praxis, keine Norm. Was für Sie passt, hängt davon ab, wie kritisch der Prozess ist.

Hypercare selbst übernehmen oder mit einem Partner?

Wenn Ihr Team das System selbst gebaut hat und Kapazität für den Betrieb hat, können Sie die Hypercare selbst übernehmen. Die fünf Bausteine oben gelten genauso. Ein Partner lohnt sich, wenn das System von einem Dienstleister gebaut wurde, wenn intern niemand Zeit für Monitoring und Updates hat oder wenn ein selbst gebautes System erstmals von vielen Menschen genutzt wird. Im letzten Fall gehört vor den Go-live ohnehin ein unabhängiger Blick auf Rechte, Daten und Schnittstellen, wie bei unserem Security-Check für eine selbst gebaute Intranet-Lösung.

Wichtig ist bei jedem Modell, dass die Hypercare Teil des Projektplans und des Budgets ist, nicht ein Nachtrag. Wie der Weg vom ersten Piloten bis in den Betrieb insgesamt aussieht, beschreiben wir im Beitrag KI-Implementierung: Vom Pilot zum Produktivbetrieb.

Bei TAISC in Karlsruhe begleiten wir Systeme von der Idee bis zum laufenden Produkt: Entwicklung, Hypercare, Wartung, Support, Fehlerbehebung und neue Schnittstellen. Welche Formen der Zusammenarbeit es gibt, finden Sie unter Services.

Häufige Fragen zur Hypercare-Phase

Was ist eine Hypercare-Phase?

Die Hypercare-Phase ist die zeitlich begrenzte Phase intensiver Betreuung direkt nach dem Go-live einer Software. Das Projektteam bleibt eng am System, behebt Fehler schnell, überwacht den Betrieb und sammelt alle Rückmeldungen an einer Stelle. Ziel ist, das System so zu stabilisieren, dass es danach im Regelbetrieb ohne erhöhte Aufmerksamkeit zuverlässig läuft.

Was bedeutet Hypercare auf Deutsch?

Hypercare bedeutet sinngemäß „besonders intensive Betreuung“. Im IT-Projekt ist damit die Stabilisierungsphase nach dem Go-live gemeint. Der englische Begriff hat sich auch im deutschen Sprachraum durchgesetzt, vor allem durch ERP- und SAP-Einführungen.

Wie lange dauert eine Hypercare-Phase?

Üblich sind zwei bis sechs Wochen, bei komplexen Systemen mit vielen Schnittstellen auch länger. Die Dauer sollte sich nicht nach dem Kalender richten, sondern nach vorher vereinbarten Exit-Kriterien: keine offenen kritischen Fehler, stabile Kernprozesse, funktionierendes Monitoring und ein geregelter Betrieb danach.

Was ist der Unterschied zwischen Hypercare und Wartung?

Die Hypercare ist zeitlich begrenzt und dient der Stabilisierung direkt nach dem Go-live, mit sehr schnellen Reaktionszeiten und enger Begleitung durch das Projektteam. Die Wartung beginnt danach und läuft dauerhaft. Sie umfasst Fehlerbehebung, Sicherheitsupdates, Anpassungen an andere Systeme und die Weiterentwicklung nach vereinbarten Prioritäten.

Wer ist in der Hypercare zuständig?

In der Hypercare bleibt das Team verantwortlich, das das System gebaut hat, denn es kennt Code, Datenflüsse und Sonderfälle am besten. Auf Kundenseite bündeln wenige Key User die Rückmeldungen aus dem Team. Nach der Hypercare geht die Verantwortung an den Regelbetrieb über, intern oder bei einem Partner.

Brauchen KI-Automatisierungen eine Hypercare?

Ja, oft sogar eine längere. KI-Schritte machen Fehler, ohne eine Fehlermeldung auszulösen, und schwierige Sonderfälle tauchen erst nach Wochen auf. In der Hypercare sollten deshalb Stichproben der Ergebnisse geprüft, neue Sonderfälle als Testfälle gesammelt und Abbrüche über Fehler-Workflows gemeldet werden.

Was ist ein Exit-Kriterium für die Hypercare?

Ein Exit-Kriterium ist eine vorab vereinbarte Bedingung, die erfüllt sein muss, bevor die Hypercare endet. Typisch sind: keine offenen Fehler der höchsten Priorität, mehrere Wochen stabile Kernprozesse, sinkende Zahl neuer Meldungen, funktionierendes Monitoring, getesteter Rollback und eine klare Regelung für Wartung und Weiterentwicklung.

Fazit

Der Go-live ist nicht das Ende eines Softwareprojekts, sondern der Anfang des Betriebs. Die Hypercare-Phase sorgt dafür, dass dieser Anfang gelingt: mit einem festen Meldeweg, einem Log, wenigen Key Usern, regelmäßigen Reviews und einem Monitoring, das Fehler meldet, bevor es die Nutzer tun. Bei KI-Automatisierungen kommen Stichproben und Testfälle dazu, weil manche Fehler leise sind. Wer diese Phase von Anfang an einplant, bekommt ein System, das mit der Zeit besser wird, statt mit jeder Anfrage unübersichtlicher.

Sie haben ein System, das bald live geht oder schon läuft, aber keinen geregelten Betrieb hat? Buchen Sie ein unverbindliches Erstgespräch. Wir schauen gemeinsam, was für einen stabilen Betrieb noch fehlt.