Die meisten ERP-Einführungen in KMU scheitern nicht am Go-Live-Tag. Sie scheitern in den ersten vier Wochen danach — wenn der Anbieter das Abnahmeprotokoll bereits unterschrieben hat und deine Leute gerade erst anfangen, das System mit echten Aufträgen zu nutzen. Diese Phase hat einen Namen: Hypercare. Und fast niemand plant sie ein.
Das Szenario, das wir immer wieder sehen, läuft so: Nach sechs Monaten Projektarbeit unterschreibt ihr am Freitag die Abnahmedokumente, am Montag geht das System produktiv, der Berater des Anbieters ist „telefonisch erreichbar", arbeitet aber faktisch schon am nächsten Projekt bei einem anderen Kunden. Deine Leute lernen in dieser Zeit das neue System am lebenden Organismus — und alle paar Stunden stoßen sie auf etwas, das in den Tests nicht aufgetaucht ist, weil niemand die Variante „Anzahlungsrechnung für einen Nicht-EU-Kunden mit Pfand auf Mehrwegverpackung" getestet hat.
Hypercare ist kein Luxus. Es ist der Unterschied zwischen einer Einführung, die nach drei Monaten läuft, und einer Einführung, die nach drei Monaten mit „bei uns funktioniert das irgendwie nicht" zum Berater zurückkommt.
Was Hypercare überhaupt ist
Hypercare ist eine definierte Phase direkt nach dem Produktivstart — in der Regel 2 bis 6 Wochen — in der das Projekt formal „abgeschlossen" ist, aber faktisch noch in erhöhter Beobachtung weiterläuft. Das Einführungsteam verschwindet nicht, es wechselt in einen anderen Arbeitsmodus. Tickets werden in Stunden bearbeitet, nicht in Tagen. Es gibt eine Person auf deiner Seite, die alle Probleme sammelt. Es gibt tägliche kurze Besprechungen, nicht wöchentliche Status-Updates.
Im Vertrag mit dem Anbieter sollte Hypercare eine eigene Position sein — mit Reaktionszeit, Umfang, Beraterverfügbarkeit und einem klaren Ende. Wenn das Angebot mit „24-monatigem SLA-Service" endet und keine separate Hypercare-Zeile enthält, bekommst du Ticket-Support mit „bis zu 2 Werktagen" Reaktionszeit — und das reicht nicht, wenn das Lager stillsteht, weil eine Warenausgangsbuchung nicht bestätigt werden kann.
- Hypercare ist nicht dasselbe wie „Einführungsgarantie" — die Garantie schützt dich vor Mängeln, Hypercare vor alltäglicher Reibung.
- Hypercare ist keine Schulung — Schulungen sollten vor dem Go-Live abgeschlossen sein.
- Hypercare ist kein SLA-Service — das SLA greift später.
Ein Beispiel aus der Praxis — 25-Personen-Großhandel für Baumaterial
Bei einem unserer Kunden — einem 25-Personen-Großhandel für Dachbaustoffe in der Woiwodschaft Masowien — haben wir eine Migration von Subiekt zu Comarch Optima mit WMS durchgeführt. Das Projekt selbst lief vier Monate, der Abnahmetest ging sauber durch, Go-Live am Montagmorgen.
In Woche eins stellte sich heraus, dass 40% der Rechnungen für eine Produktgruppe (Dachdecker-Zubehör) den falschen Mehrwertsteuersatz hatten — das Feld „Satz" wurde aus dem alten Produktstamm migriert, aber in der neuen Produktstruktur fehlte das Mapping für zwei Untergruppen. In den Tests ist das niemandem aufgefallen, weil wir die Top-50-Produkte getestet haben, und dieses Zubehör hat 180 Codes mit jeweils 2-3 Rechnungen pro Monat. Insgesamt 60 ausgestellte Rechnungen zur Korrektur in den ersten vier Tagen.
In Woche drei kam das zweite Problem ans Licht — das Lager druckte Warenausgangsbelege, klickte aber „bestätigen" im neuen System nicht, weil in Subiekt dieser Schritt automatisch lief. Zwei Wochen lang gab es 320 „offene" Warenausgänge in der Datenbank, die aus Sicht der Buchhaltung noch nicht existierten.
Beide Probleme wurden innerhalb eines Tages gelöst, weil Hypercare aktiv war: täglich 15-minütige Besprechung um 9:00 Uhr, eine Person (Key User aus dem Vertrieb) sammelte Tickets, ein technischer Berater war von 8 bis 16 Uhr auf Teams erreichbar. Nach vier Wochen schrumpfte die tägliche Problemliste von 23 Punkten auf 2-3. Dann — und erst dann — sind wir in den normalen Service-Modus übergegangen.
Hätten wir am Freitag abgenommen und „ruft an, wenn was ist" gesagt, wären diese 60 Rechnungen an Kunden rausgegangen. Und das Gespräch einen Monat später wäre nicht über Korrekturen gelaufen, sondern über eine Steuerprüfung.
Was du vor dem Produktivstart planen solltest
Hypercare plant man vor dem Go-Live, nicht währenddessen. Wenn du erst in Woche zwei nach dem Go-Live anfängst darüber nachzudenken, ist es schon zu spät — deine Leute sind müde, der Berater ist in einem anderen Projekt und du löschst Brände.
Das Minimum, das in den Vertrag und in den Kalender gehört:
- Dauer. Für eine einfache Einführung (nur ERP-Wechsel in einem Unternehmen bis 30 Personen) reichen 3 Wochen. Für eine Einführung mit Integrationen (ERP + WMS + Onlineshop + Bank) plane 6 Wochen.
- Beraterverfügbarkeit. Nicht „telefonisch erreichbar", sondern konkrete Zeiten (z.B. 8 bis 16 Uhr an Werktagen) und ein konkreter Kanal (Teams, Slack, dedizierte E-Mail-Adresse — kein Ticket im Portal).
- Reaktionszeit. Für blockierende Fehler — innerhalb von 2 Stunden. Für alles andere — bis zum Ende des Arbeitstags. Das ist ein separates SLA, nicht das langfristige Service-Agreement.
- Eine Person auf deiner Seite. Ein Key User, der alle Tickets sammelt, Duplikate filtert und entscheidet, was dringend ist. Ohne diese Rolle versinkt der Berater in Fragen von 15 Personen, die alle dasselbe fragen.
- Tägliche 15-Minuten-Besprechung. Nicht wöchentlich, nicht „wenn's nötig ist". Täglich, zur festen Zeit, die gesamte Hypercare-Phase lang. Gibt es keine Themen, ist sie nach 5 Minuten vorbei. Gibt es welche, sammelt sich nichts drei Tage lang an.
- Ticket-Protokoll. Eine einfache Tabelle oder eine Liste im Ticketsystem — was, wer hat gemeldet, Status, wer löst, Abschlussdatum. Ohne das weiß nach zwei Wochen niemand mehr, was gefixt wurde und was noch offen ist.
- Altsysteme im Nur-Lese-Modus. Schalte Subiekt / das alte Dynamics nicht am Tag eins ab. Lass es mindestens 60 Tage lang lesend erreichbar. Das ist deine Versicherung — passt im neuen System etwas nicht zur Historie, kannst du jederzeit nachschauen.
Was du in der Hypercare-Phase messen solltest
Hypercare ohne Messung ist nur Intuition. Und Intuition sagt „mir kommt es vor, als liefe es schlechter" — ein miserables Argument im Gespräch mit dem Anbieter.
Drei Zahlen, die man täglich erheben sollte:
- Anzahl offener Tickets. Sollte in Woche eins steigen, in Woche zwei stabilisieren, ab Woche drei sinken. Sinkt sie nicht — entweder Hypercare verlängern oder im System steckt mehr als „die Leute lernen noch".
- Zeit bis Ticket-Schluss. Median, nicht Durchschnitt (ein hängendes Ticket zerstört den Durchschnitt). Zielwert: 1 Werktag für Fehler, 3 Tage für Verbesserungen.
- Anzahl der zu korrigierenden Rechnungen / Belege. Das ist der echte Indikator, dass das System produktiv korrekt läuft. Null wird es nicht sein, aber die Tendenz muss von Woche zu Woche sinken.
Füge dazu eine wöchentliche Zusammenfassungssitzung mit der Geschäftsleitung hinzu, in der du diese drei Zahlen zeigst. Das ist keine überflüssige Bürokratie — das ist der Weg, zu verhindern, dass die Geschäftsleitung in Panik nach einem Schuldigen sucht, weil „die halbe Firma sagt, das neue System sei hoffnungslos". Daten entschärfen Emotionen.
Wann du Hypercare formal beenden solltest
Hypercare endet nicht, wenn der geplante Termin erreicht ist, sondern wenn drei Bedingungen gleichzeitig erfüllt sind: die tägliche Ticketzahl ist unter einen vereinbarten Schwellwert gefallen (z.B. 3), kein offener Punkt blockiert den Betrieb, und die Key User bestätigen „das ist jetzt nutzbar". Erst dann wechselst du in den normalen Service-Modus — mit Reaktionszeit in Tagen, nicht Stunden.
Dieser Abschluss sollte formal sein: ein Protokoll, benannte Unterzeichner (du und der Anbieter), eine Liste der offenen Punkte, die ins Backlog verschoben werden, und eine klare Aussage, dass der Kontakt ab morgen über Standard-Tickets läuft. Ohne diesen Moment driftet Hypercare — der Berater „schließt noch ab" und du denkst, es sei normal, dass drei Monate später immer noch tägliche Anrufe kommen.
Eine Einführung endet nicht am Tag der Abnahme-Unterschrift. Sie endet, wenn die Leute aufhören zu fragen „wie macht man das im neuen System", weil sie es einfach wissen.
Der Go-Live-Tag ist nicht das Ende des Projekts, sondern das Ende seiner ersten Etappe. Der eigentliche Test kommt in Woche vier, wenn alle schon dachten, es sei Ruhe eingekehrt.