Hypercare ist der kurze Zeitraum direkt nach dem Produktivstart, in dem zusätzliche Mittel und Aufmerksamkeit den Anwendern und den Geschäftsprozessen zur Verfügung stehen. Hier wird Akzeptanz gewonnen oder verloren.
7 Min. LesezeitEinführungAdoption
Definition in Kürze
Hypercare ist ein kurzer Zeitraum nach dem Go-live, in dem zusätzliche Ressourcen und Aufmerksamkeit bereitstehen, um Anwender und Geschäftsprozesse zu unterstützen.
Es ist kein Regelsupport: Die Reaktionszeiten sind kürzer und die eingesetzten Mittel bewusst größer als im Normalbetrieb.
Die Dauer ist nicht normiert – kein Hersteller veröffentlicht einen Richtwert.
Das Ende sollte anhand von Kennzahlen entschieden werden, nicht anhand eines Budgetdatums.
Was ist Hypercare?
Microsoft gibt die nüchternste Definition: Hypercare ist ein kurzer Zeitraum nach dem Go-live, in dem zusätzliche Ressourcen und Aufmerksamkeit bereitgestellt werden, um Anwender und Geschäftsprozesse zu unterstützen (Microsoft Learn). Die zugehörige Go-live-Checkliste formuliert es als Auftrag: direkt nach dem Produktivstart ein erhöhtes Supportniveau sicherstellen, damit die Anwender reibungslos in das neue System hineinfinden.
Im Deutschen wird der Anglizismus verwendet; das Cloud Adoption Framework von Microsoft übersetzt ihn mit erweiterter Supportzeitraum (Hypercare) und empfiehlt, Entwicklung und Betrieb in dieser Zeit in Bereitschaft zu halten, um Probleme früh zu erkennen (Microsoft Learn DE). Einen Duden-Eintrag gibt es nicht.
Was Hypercare vom Regelsupport unterscheidet, ist nicht die Art der Anfragen, sondern das Aufgebot:
kürzere Reaktionszeiten, teils Präsenz vor Ort;
benannte Fachbereichs-Ansprechpartner in jedem Team, nicht nur eine zentrale Hotline;
das Projektteam weiterhin abrufbar, einschließlich Integrator und Hersteller;
tägliche Störungsübersicht mit schneller Entscheidung über Korrekturen;
ein offenes Ohr für Umgehungen, die Reibungspunkte früher zeigen als Tickets.
Wie lange soll Hypercare dauern?
Hier ist Klarheit nötig: Keine Primärquelle veröffentlicht einen Richtwert. Microsoft spricht von „einem kurzen Zeitraum“, ohne Zahl. Die kursierenden Angaben – zwei Wochen, ein Monat, ein Quartal – sind Marktpraxis, keine dokumentierte Empfehlung.
Eine von Microsoft veröffentlichte Fallstudie zeigt den Denkfehler des Budgetansatzes. In diesem Projekt sollten die vertraglich vorgesehenen Hypercare-Stunden des Einführungspartners vier bis sechs Wochen reichen, waren aber binnen zwei Wochen aufgebraucht, weil das interne Supportteam deutlich mehr Unterstützung brauchte als angenommen (Microsoft Learn). Nicht die Dauer war das Problem, sondern die Dimensionierung.
Die richtige Frage lautet daher nicht „wie viele Wochen“, sondern „unter welchen Bedingungen verlassen wir die Hypercare-Phase“. Drei Kriterien halten einer Prüfung im Gremium stand:
Das Ticketvolumen hat ein Plateau erreicht, und dieses Plateau ist vom Regelsupport tragbar.
Die Art der Tickets hat sich verändert: keine breiten Nutzungsfragen mehr, sondern Einzelfälle und Fehler.
Die kritischen Prozesse sind mindestens einmal real gelaufen – Monatsabschluss, Lohnlauf, Inventur, je nach Bereich.
Der letzte Punkt wird am häufigsten vergessen. Ein am Ersten des Monats gestartetes ERP hat seinen ersten Abschluss noch vor sich; Hypercare davor zu beenden, heißt das Netz am Vorabend des Sprungs abzubauen.
Was ein überlastetes Hypercare kostet
Das Final Notice der FCA zur TSB-Migration im April 2018 liefert ein seltenes Maß dafür, was ein überlastetes Unterstützungsteam bewirkt. Die Umstellung fand am Wochenende vom 20. bis 22. April statt; die Folgen zogen sich über Monate.
225.492
Beschwerden gingen bei TSB zwischen April 2018 und April 2019 infolge der Migration ein – rund 4,3 % des Kundenbestands.
Der Fall TSB ist extrem und betrifft die technische Auslegung genauso wie den Support. Er zeigt dennoch eine allgemeine Mechanik: Schwierigkeiten, die in den ersten Tagen unbearbeitet bleiben, bleiben keine technischen Schwierigkeiten. Sie werden zu Beschwerden, zu dauerhaften Umgehungen und zu einem Misstrauen, das die Korrekturen am System lange überlebt.
Hypercare und Akzeptanz: dasselbe Zeitfenster
Hypercare gilt als Supportthema. Tatsächlich ist es das entscheidende Fenster der digitalen Adoption: Die Gewohnheiten, die die Anwender in den ersten zwei Wochen annehmen, sind die, die sie behalten.
Ist der korrekte Weg mühsam und die Umgehung bequem, setzt sich die Umgehung durch – und sie wieder abzubauen kostet ein Vielfaches dessen, was eine Anleitung an der richtigen Stelle am ersten Tag gekostet hätte.
Deshalb lohnt es, einen Teil des Hypercare vom System selbst tragen zu lassen: Eine Digital Adoption Platform beantwortet wiederkehrende Fragen in der Oberfläche, hält die Menschen für die echten Fälle frei und zeigt, welche Schritte blockieren – bevor das Ticket kommt.
Beispielszenario · Ausstieg aus dem Hypercare
Ausgangslage
Ein neues ERP startet am 1. März. Das Hypercare ist auf vier Wochen budgetiert, der Integrator ist vor Ort.
Der Bruchpunkt
Ende März ist das Ticketvolumen gesunken, das Gremium beschließt den Ausstieg. Der erste Monatsabschluss findet in der Woche darauf statt: Er bringt Abstimmungsdifferenzen zutage, die im Fachbereich niemand allein bearbeiten kann. Der Integrator ist abgereist.
Worauf zu schauen gewesen wäre
kritische Prozesse, die real noch nie gelaufen sind;
die Art der Tickets, nicht nur ihre Anzahl;
Systemfunktionen, die seit dem Start nie genutzt wurden;
Umgehungen, die die Fachbereichs-Ansprechpartner melden.
Das sinkende Ticketvolumen zeigte nicht, dass die Anwender das System beherrschten, sondern dass sie aufgehört hatten zu fragen.
Die Expertise von Knowmore
Wie Knowmore
die Hypercare-Phase entlastet.
Ein erheblicher Teil der Anfragen der ersten Wochen betrifft wiederkehrende Nutzungsfragen: wo erfassen, in welcher Reihenfolge, welches Feld ein Pflichtfeld ist. K-NOW beantwortet sie auf dem Bildschirm, in dem Moment, in dem sie auftreten.
K-VALUE liefert dem Gremium, was ihm beim Ausstieg aus dem Hypercare am häufigsten fehlt: die Liste der tatsächlich genutzten Funktionen, der Schritte, an denen Anwender abbrechen, und der Bildschirme, die Blockaden erzeugen – bevor daraus ein Ticket wird.
Hypercare ist keine verlängerte Garantie, sondern der Zeitraum, in dem eine Organisation unter enger Beobachtung lernt, mit ihrem neuen System zu arbeiten.
Die Dauer zählt weniger als der Ausstieg. Wer an einem Budgetdatum aussteigt, bevor die kritischen Prozesse gelaufen sind, verwandelt ein gelungenes Projekt in eine dauerhafte Belastung des Betriebs.
Häufige Fragen
Wie lange dauert die Hypercare-Phase?
Keine Primärquelle nennt einen Richtwert: Microsoft spricht von „einem kurzen Zeitraum“, ohne Zahl. Die in Projekten genannten Dauern – zwei Wochen bis drei Monate – sind Praxis, keine Norm. Besser ist es, Ausstiegskriterien zu definieren, als vorab eine Dauer festzulegen.
Was ist der Unterschied zwischen Hypercare und First-Level-Support?
Der First-Level-Support ist ein dauerhaftes Aufgebot, ausgelegt auf ein Regelvolumen. Hypercare ist zeitlich befristet, bewusst überdimensioniert und bindet Kompetenzen ein, die der Regelsupport nicht hat: Projektteam, Integrator, Hersteller. Beide laufen in dieser Zeit parallel.
Wer soll die Hypercare-Phase tragen: der Integrator oder das interne Team?
Beide, mit ausdrücklicher Übergabe. Der häufige Fehler besteht darin, die Hauptlast dem Integrator zu überlassen, dessen Stunden aufgebraucht sind, bevor das interne Team selbstständig ist. Eine von Microsoft veröffentlichte Fallstudie beschreibt genau dieses Muster: ein für vier bis sechs Wochen geplantes Budget, verbraucht in zwei.