Hypercare Phase kalkulieren, bevor die Marge kippt

Ein Projekt gilt als abgeschlossen, wenn das System live ist. In der Praxis beginnt genau dann eine neue Phase: die Hypercare-Phase. Anwender melden Fehler, Prozesse laufen noch nicht rund, Change Requests kommen auf informellem Weg herein. Für IT-Consultings ist das der Moment, in dem viele Projekte wirtschaftlich in eine unkontrollierte Schieflage geraten, ohne dass es in der Auslastungsplanung sichtbar wird.

Typisch ist dabei folgendes Muster: Der Vertrag wird als abgeschlossen betrachtet, das Team bleibt aber informell weiter am Kunden gebunden. Diese Grauzone zwischen offiziellem Projektende und tatsächlichem Aufwandsende betrifft nahezu jedes größere Implementierungsprojekt im IT-Consulting, unabhängig davon, ob es sich um eine SAP-Einführung, ein Cloud-Migrationsprojekt oder eine Individualsoftware-Entwicklung handelt.

Das Problem ist strukturell. Hypercare wird in vielen Angeboten überhaupt nicht als eigenständige Leistungsphase kalkuliert. Sie hängt am Ende eines Projekts, wird pauschal mitverkauft oder bleibt unabgerechnet, weil das Team „sowieso noch da ist“. Genau diese Grauzone macht die Phase teuer.

Für Projektleitung und Geschäftsführung zeigt sich der Effekt oft erst Wochen später: Die Projektmarge, die beim Kickoff-Meeting noch solide aussah, ist im Monatsabschluss plötzlich niedriger als geplant. Ursache ist meist dieselbe Lücke: Aufwand, der zwischen Go-Live und offiziellem Projektabschluss entstanden ist, taucht in der Kalkulation nirgends auf.

Das Wichtigste in Kürze:

• Marge: Nicht abgerechnete Hypercare-Stunden schmälern die Projektmarge nachträglich, oft erst im Monatsabschluss sichtbar.
• Auslastung: Berater bleiben gebunden, obwohl sie für das nächste Projekt eingeplant sind.
• Ressourcen: Skill-Träger werden doppelt verplant, weil Hypercare-Aufwand in der Kapazitätsplanung fehlt.
• Forecast: Folgeprojekte kalkulieren mit einer Aufwandshistorie, die den tatsächlichen Support-Bedarf nach Go-Live nicht enthält.
• Projektkosten: Die tatsächlichen Gesamtkosten eines Projekts werden erst Wochen nach dem vermeintlichen Abschluss sichtbar.

Für Geschäftsführung und Projektleitung stellt sich damit eine konkrete Frage: Wie lässt sich eine Phase kalkulieren, deren Umfang beim Vertragsabschluss noch nicht feststeht?

Ein Rechenbeispiel macht die Größenordnung greifbar. Bei einem mittelgroßen ERP-Rollout mit fünf Beratern, die im Schnitt jeweils vier Stunden pro Woche über sechs Wochen Hypercare-Aufwand leisten, ohne dass diese Zeit gesondert kalkuliert wurde, summiert sich das auf 120 Beratungsstunden. Bei einem durchschnittlichen Tagessatz im IT-Consulting entspricht das schnell einem Betrag im fünfstelligen Bereich, der komplett an der ursprünglichen Projektkalkulation vorbeiläuft. Für ein einzelnes Projekt mag das verkraftbar sein. Bei einem Portfolio aus zehn oder fünfzehn parallelen Implementierungsprojekten pro Jahr wird aus diesem einzelnen Effekt schnell eine strukturelle Margenlücke, die sich im Jahresabschluss deutlich bemerkbar macht.

Was eine Hypercare-Phase tatsächlich umfasst

Hypercare bezeichnet den Zeitraum nach dem Go-Live, in dem das Projektteam eng am System und an den Anwendern bleibt, um Stabilisierung sicherzustellen. Der SAP GoingLive Check beschreibt diese Phase als kritischen Übergang zwischen Projektabschluss und Regelbetrieb, in dem technische und organisatorische Risiken am größten sind. Die Dauer variiert je nach Projektumfang typischerweise zwischen zwei und acht Wochen.

Zu den typischen Hypercare-Aktivitäten gehören:

• Incident-Bearbeitung mit priorisierter Reaktionszeit
• Feinjustierung von Konfigurationen und Workflows
• Anwenderschulung im laufenden Betrieb
• Monitoring von Performance und Datenqualität
• Abgrenzung von Bugfixes gegenüber neuen Change Requests

Die Übergabe in den Regelbetrieb ist ein gestufter Prozess mit mehreren Zwischenschritten, kein einzelner Stichtag. Genau diese Unschärfe ist der Grund, warum Hypercare in vielen Verträgen nur vage adressiert wird. Wer die Phase als eigenständiges Leistungspaket mit definiertem Umfang, definierter Dauer und definierten Eskalationsstufen versieht, verhindert, dass die Kalkulation dem Zufall überlassen bleibt.

Praxisrelevant ist vor allem die Abgrenzung zwischen Hypercare und regulärem Support. Ein Incident-Ticket wegen eines Bugs gehört in die Hypercare-Leistung. Eine neue Anforderung, die während der Stabilisierungsphase auftaucht, ist ein Change Request und gehört separat abgerechnet. Diese Grenze wird im Tagesgeschäft häufig verwischt, weil Kunden und Berater unter Zeitdruck stehen.

In der Praxis hat sich eine dreistufige Struktur bewährt, die sich unabhängig von der jeweiligen Systemlandschaft auf die meisten Projekte übertragen lässt:

Stufe 1: Intensivphase. In den ersten ein bis zwei Wochen nach Go-Live ist das Kernteam eng am Kunden, häufig mit täglichen Abstimmungen. Reaktionszeiten auf Incidents sind kurz definiert, meist innerhalb weniger Stunden.

Stufe 2: Stabilisierungsphase. Die Frequenz der Meldungen nimmt ab, das Team reduziert die Präsenz, bleibt aber mit klar definierten Reaktionszeiten erreichbar. Diese Phase dauert typischerweise zwei bis vier Wochen.

Stufe 3: Übergabe in den Regelbetrieb. Verbleibende offene Punkte werden entweder als reguläre Change Requests eingeplant oder in ein Wartungs- beziehungsweise Support-Modell überführt. Erst hier endet die Hypercare-Phase im eigentlichen Sinn.

Diese Staffelung ist auch deshalb relevant, weil sie eine faire Preislogik ermöglicht: Die Intensivphase ist personalintensiv und entsprechend teurer zu kalkulieren, die Übergabephase deutlich schlanker. Wer Hypercare pauschal über die gesamte Laufzeit mit demselben Tagessatz kalkuliert, verschenkt in der Regel Marge in der Anfangsphase oder überzeichnet die Kosten am Ende.

Warum Hypercare im Alltag so schwer zu steuern ist

Die eigentliche Herausforderung liegt in der täglichen Umsetzung. Das Regelwissen zur Hypercare-Phase ist in den meisten Teams durchaus vorhanden, an der konsequenten Anwendung im Projektalltag hapert es trotzdem. Drei Muster tauchen in IT-Consultings immer wieder auf.

Erstens: Die Zeiterfassung reißt genau dann ab, wenn sie am wichtigsten wäre

Solange ein Projekt aktiv läuft, buchen Berater ihre Stunden meist zuverlässig auf das entsprechende Projekt. Sobald das System live ist, ändert sich die Wahrnehmung. Viele Teams empfinden Hypercare als Nebenaufgabe neben dem nächsten Mandat, kaum noch als reguläre Projektarbeit. Die Folge: Stunden werden zunehmend unpräzise gebucht. Sie verschwinden in allgemeinen Support-Buckets oder bleiben ganz undokumentiert.

Für die Projektleitung bedeutet das: Am Ende der Hypercare-Phase gibt es keine belastbare Zahl, wie viele Stunden tatsächlich investiert wurden. Eine Nachkalkulation wird damit zur Schätzung, eine Abrechnung strittiger Stunden gegenüber dem Kunden lässt sich kaum noch begründen. Wer im Nachgang belegen muss, wie viel Aufwand tatsächlich in der Stabilisierung steckte, hat ohne lückenlose Zeiterfassung wenig in der Hand.

Zweitens: Die Kapazität wird doppelt verplant

Berater, die in der Hypercare-Phase eines Projekts gebunden sind, werden in der Ressourcenplanung häufig trotzdem für das nächste Projekt eingeteilt, weil die Hypercare-Bindung nicht als planbare Auslastung erfasst ist. Wenn dann parallel Incidents eskalieren, entsteht ein Konflikt: Wer bearbeitet den kritischen Bug, wenn dieselbe Person zeitgleich im Kickoff-Workshop des Folgeprojekts sitzt?

Dieses Muster trifft besonders Teams mit hohem Freelancer- und Partnerressourcen-Anteil, wie sie im IT-Consulting üblich sind. Externe Ressourcen sind oft nur für einen definierten Zeitraum gebunden, Hypercare-Verzögerungen sprengen dann direkt das nächste Staffing.

Die Konsequenz strahlt über das aktuelle Projekt hinaus in die gesamte Projektpipeline aus. Wenn ein Skill-Träger für Zertifizierungslogik oder ein spezielles Modul länger als geplant in der Hypercare-Phase gebunden ist, verschiebt sich häufig der Start eines Folgeprojekts, für das genau diese Person eingeplant war. Der Kunde des Folgeprojekts merkt davon zunächst nichts, bis die Terminverschiebung kommuniziert werden muss. An dieser Stelle wird ein internes Kalkulationsproblem zu einem Thema, das die Kundenbeziehung im nächsten Mandat direkt betrifft.

Drittens: Die Abrechnung wird zur Verhandlungssache statt zur Formsache

Wenn Aufwand und Leistungsumfang der Hypercare-Phase nicht dokumentiert sind, verschiebt sich die Abrechnung von einer vertraglich geregelten Position zu einer Diskussion. Kunden verweisen darauf, dass „der Support doch inklusive war“, Projektleiter können ohne belastbare Datenbasis wenig entgegensetzen. Genau an dieser Stelle kippt die kalkulierte Marge eines Projekts nachträglich, teilweise Wochen nach dem eigentlichen Projektabschluss.

Der Ausweg aus diesen drei Mustern liegt in einer klaren Struktur. Hypercare muss von vornherein als eigenständige Projektphase angelegt werden, mit eigener Zeiterfassung, eigenem Budget und eigener Auslastungssicht. Appelle an mehr Disziplin im Team greifen hier erfahrungsgemäß kaum, solange die Systematik dahinter fehlt. Genau hier zeigt sich der Unterschied zwischen einer Excel-Liste, die rückblickend Stunden summiert, und einer Steuerungslogik, die während der laufenden Phase Transparenz liefert.

Ein weiterer Aspekt, der in der Praxis oft übersehen wird: Hypercare betrifft selten nur eine Person. Häufig ist ein kleines Kernteam aus zwei bis vier Beratern beteiligt, die sich Schichten oder Zuständigkeiten je Modul aufteilen. Ohne eine gemeinsame Übersicht über gebuchte Stunden pro Person und pro Themenbereich verliert die Projektleitung schnell den Überblick, wer welchen Anteil am Gesamtaufwand trägt und ob die Verteilung noch zur ursprünglichen Kalkulation passt.

Mit ZEP Compact lässt sich Hypercare als separates Teilprojekt im laufenden Kundenprojekt anlegen: mit eigenem Budget, eigener Zeiterfassung und eigener Auswertung gegenüber dem ursprünglichen Projektumfang. Die Ressourcenplanung zeigt frühzeitig, wenn ein Berater durch laufende Hypercare-Verpflichtungen für das nächste Projekt nicht wie geplant verfügbar ist. Damit wird die Doppelverplanung sichtbar, bevor sie zum Eskalationsfall wird.

{{blog-cta}}

Viertens: Reporting gegenüber dem Kunden fehlt die Grundlage

Kunden, die für Hypercare zahlen oder eine inkludierte Leistung erwarten, fragen zunehmend nach Nachweisen: Wie viele Tickets wurden bearbeitet, wie schnell, mit welchem Aufwand? Ohne strukturierte Erfassung kann die Projektleitung diese Fragen nur mit groben Schätzungen beantworten. Das schwächt die Verhandlungsposition bei der nächsten Vertragsverlängerung und wirkt sich direkt auf die Kundenbindung aus, gerade in einem Marktumfeld, in dem Auftraggeber zunehmend belastbare Reports erwarten, bevor sie ein Folgemandat vergeben.

Ein strukturierter Nachweis muss dabei nicht aufwendig sein. Entscheidend ist, dass die Daten aus derselben Quelle stammen wie die Zeiterfassung während der Implementierung, statt aus einer separaten, händisch gepflegten Liste rekonstruiert werden zu müssen.

Warum Hypercare zum Auslöser für systematische Steuerung wird

Der Punkt, an dem IT-Consultings beginnen, Hypercare systematisch zu kalkulieren, ist meist der zweite oder dritte Fall mit ähnlichem Margenverlust, seltener der erste. Sobald sich über mehrere Projekte hinweg abzeichnet, dass Hypercare-Phasen strukturell zu knapp kalkuliert oder unvollständig abgerechnet werden, wird aus einem Einzelfall ein Muster, das die Geschäftsführung direkt beschäftigt.

Typische Auslöser für den Wechsel von Excel-Nachkalkulation zu systematischer Steuerung:

• Mehrere Projekte in Folge zeigen nachträgliche Margeneinbußen durch Hypercare
• Die Ressourcenplanung kann Hypercare-Bindung nicht von freier Kapazität unterscheiden
• Kunden fordern zunehmend transparente Nachweise über tatsächlich geleistete Support-Stunden
• Die Geschäftsführung will Projektkosten inklusive Nachlaufphase sehen, nicht nur bis zum Go-Live
• Freelancer und Partnerressourcen sind durch unklare Hypercare-Laufzeiten schwerer verlässlich zu planen
• Angebote für Folgeprojekte kalkulieren weiterhin mit unrealistischen Support-Annahmen, weil die Historie fehlt

Für die Geschäftsführung ist an dieser Stelle vor allem eine Zahl relevant: Wie viel Prozent der ursprünglich kalkulierten Projektmarge geht im Durchschnitt durch nicht abgerechnete Hypercare-Stunden verloren? Sobald diese Zahl im zweistelligen Bereich liegt, was in der Praxis keine Seltenheit ist, wird aus einem operativen Detail ein Thema für die Portfoliosteuerung.

Genau an diesem Punkt wird deutlich, warum ZEP als durchgängige Plattform gedacht ist und weniger als isoliertes Zeiterfassungstool funktioniert. Projektzeit, Ressourcenplanung und Projektcontrolling greifen in ZEP Compact auf dieselbe Datengrundlage zu. Wer zusätzlich Angebotswesen und Rechnungsstellung für Hypercare-Leistungen direkt aus dem System heraus abbilden will, findet diese Funktionen in ZEP Professional, das den gesamten Weg von der Kalkulation bis zur Rechnung abdeckt. Project-to-Bill bedeutet in diesem Zusammenhang konkret: Die in der Hypercare-Phase erfassten Stunden fließen direkt in die Abrechnung, ohne manuellen Umweg über eine separate Tabelle.

Für Projektleiter, die heute noch mit Excel arbeiten, liegt der Mehrwert vor allem darin, künftig eine Phase weniger im Nachgang rekonstruieren zu müssen. Die Daten liegen bereits vor, wenn die Abrechnung fällig wird.

Ein letzter Punkt ist für die Skalierung des Geschäfts relevant: Je mehr Projekte parallel in unterschiedlichen Hypercare-Stadien stecken, desto wichtiger wird eine zentrale Übersicht über alle laufenden Nachlaufphasen gleichzeitig. Für ein einzelnes Projekt lässt sich der Überblick notfalls noch mit einer Tabelle behalten. Bei zehn oder mehr parallelen Mandaten, wie sie in wachsenden IT-Consultings üblich sind, wird diese Übersicht zur eigentlichen Steuerungsaufgabe der Projektleitung.

Fazit: Hypercare braucht einen eigenen Kalkulationsrahmen

Definieren Sie Hypercare vertraglich als eigenständige Leistungsphase mit klarer Laufzeit, klarem Eskalationsmodell und einer eindeutigen Abgrenzung zu Change Requests. Legen Sie diese Phase intern als eigenes Teilprojekt mit eigenem Budget an, statt sie an das ursprüngliche Projekt anzuhängen. Erfassen Sie Zeiten während der Hypercare-Phase mit derselben Konsequenz wie während der Implementierung, nicht mit weniger. Und prüfen Sie nach jedem größeren Go-Live, wie stark die tatsächliche Hypercare-Dauer von der kalkulierten Dauer abweicht, um künftige Angebote realistischer zu kalkulieren. Wer diese vier Punkte umsetzt, verhindert, dass die Marge eines eigentlich erfolgreichen Projekts erst Wochen nach dem Go-Live kippt. Der Aufwand für diese Umstellung ist überschaubar, sobald Zeiterfassung, Ressourcenplanung und Projektcontrolling auf derselben Grundlage arbeiten. Der Effekt zeigt sich bereits beim nächsten Projekt, das mit realistischeren Zahlen kalkuliert werden kann als das letzte. Wichtig ist, die Umstellung direkt am aktuell laufenden Projekt als Testfall zu erproben, statt erst beim übernächsten Go-Live damit zu beginnen. So lässt sich der Effekt unmittelbar am eigenen Datenmaterial überprüfen, statt auf eine theoretische Kalkulation zu vertrauen.