Hypercare - Management der Risiken rund um das Unerwartete

Was ist Hypercare

Hypercare ist der Zeitraum unmittelbar nach einem System Go Live, in dem ein erhöhtes Maß an Unterstützung
zur Verfügung steht, um die nahtlose Einführung eines neuen Systems zu gewährleisten.

Es ist das zeitlich begrenzte, verbesserte Maß an Governance und Ressourcen, um sicherzustellen, dass
während der Systemstabilisierung ein angemessenes Maß an Unterstützung bereitgestellt wird, Probleme
schnell behoben werden und Wissenstransfer an die Service Delivery Organization stattfindet.

In einfachen Worten
 Beginnt mit Go-Live
 Befristete Frist (Gewährleistungsfrist)
 System läuft mit Autopilot
 Support rund um die Uhr und 7 Tage die Woche für alle technischen Probleme verfügbar
 KMUs übernehmen während der Hypercare die volle Verantwortung
Definition
Hypercare in der Anwendungsunterstützung kann als die Phase nach der Anwendung in der Produktion
betrachtet werden. Der Hauptzweck der Hypercare-Phase besteht darin, die Anwendung genau zu
überwachen, um auf jede Art von funktionalen, technischen und Sicherheitsproblemen zu reagieren/diese zu
lösen, damit die implementierte Anwendung reibungslos funktioniert. Die Faustregel lautet, dass das System
nach Beendigung des Hypercare-Supports als stabil deklariert wird und sich in sicheren Händen des AMS-Teams
befindet, das in vollem Umfang in der Lage sein sollte, Probleme zu unterstützen und zu lösen.

Einige der Bereiche, auf die Sie sich während der Hypercare konzentrieren sollten
 Bestätigen Sie, dass Business-as-usual funktioniert
 Defekte verwalten
 Kunden- (Endbenutzer-) Support
 Datenintegrität
 Verfügbarkeit und Leistung des Systems
 Roll-off des Lieferanten-Supports (Wissensdatenbank)
 Einige Teammitglieder sollten sich auf die Einführung in der nächsten Phase konzentrieren, indem sie
„Lessons Learned“ ansprechen, während sie
Risiken und Probleme, die während der Hyperpflege häufig auftreten
 Problempriorisierung
 Die Reaktionszeit für den Support kann sich verzögern
 Ressourcenbeschränkungen (intern vs. Anbieter)
 Mangelnde Schulung (z. B. Materialien, Referenzhandbücher, persönlich)
 Mangel an sachkundigen Fachexperten
 Notfallzugriffsanforderungen können zu einem übermäßigen privilegierten Zugriff führen
Risikofaktoren – Mitarbeiter, Prozess- und
Technologiemitarbeiter:
 Fehlende Unterstützung auf Führungsebene/fehlendes Bewusstsein für die Kritikalität nach dem Go-Live
 Mangel an engagierten Geschäftsprozessen und technischen Fachkräften
 Mangel an ausreichender Beteiligung der Geschäftsprozessverantwortlichen in der Hypercare-Phase
 Mangel an notwendigem ERP-Know-how im Implementierungsteam (einschließlich Management- und
Bereitschaftspartner)
 Unzureichende Schulung der Endbenutzer
 Die Bedeutung des Änderungsmanagements wird unterschätzt oder ineffektiv durchgeführt
 Fehlendes effektives Wissensmanagement
 Unzureichende Governance-Strategie rund um Aufgabentrennung, Stammdaten und Reporting
Prozess:

 Fehlen eines formalisierten Projektbüros, das für die Bestandsaufnahme, Priorisierung und Überwachung
der verschiedenen auftretenden konkurrierenden Probleme verantwortlich und rechenschaftspflichtig ist
Technologie: z. B. SAP-Sicherheitsmodul:

 SAP-Sicherheit wird nicht proaktiv angesprochen, um eine Strategie zu entwerfen, die die mit Kontrollen
und Wartung verbundenen Kosten ausgleicht
 Das mit der SAP-Standardfunktionalität verbundene Risiko wird nicht angesprochen (SAP*, SAP_ALL,
SAP_NEW, RSPARAM-Schwachstellen)
 Fehlende negative Sicherheitstests, um unbeabsichtigte Kombinationen von gewährten Zugriffen zu
identifizieren
 Schnittstellen werden nicht gründlich getestet
 Berichte sind nicht ohne weiteres verfügbar, um die verschiedenen Prozesse zu unterstützen
Hypercare Readiness Scorecard für Golive – Beispiel
Kriterien Phase 1 Phase 2 Notizen und Aktionen für 100 % erforderlich
usw.,
Prozesse Steuerungsintegration, Schulung
Werkzeuge Anwendungsüberwachung
Berichte Fehlerbericht, EAM-Bericht (Enterprise Asset
Management)
Rollen & Schulungsteam, Supportteam, Audit etc.
Verantwortlich
keiten
Personalpläne Globaler 24-Stunden-Kriegsraum-Support für Woche 1
Deckungspläne Wöchentliche Aktualisierung fortsetzen
Infrastruktur Vorbereitung der technischen Ausrüstung für
Standorte, mobile Geräte
Schulung Probelauf komplett?
Weiche Stellen Minderungspläne entwickelt und an Benutzer- und
Hypercare-Teams weitergegeben?
Kritische Umwandlung von SIT/UAT-kritischen Tickets in
Workarounds Hypercare-Tickets
Workaround-Pläne, die den Benutzer- und Hypercare-
Teams übermittelt werden

Hinweis: Fügen Sie diesen Artikel in die endgültige Go-Live-Genehmigungsentscheidung ein

Beispielberichte: Anzahl kritischer Defekte

Dauer
 Basierend auf dem Projekt und der Kritikalität der Anwendung, in der Regel 45 – 60 Tage
Wann endet die Hypercare-Phase?
 Wählen Sie nicht nur einen beliebigen Zeitraum (z. B. 45 Tage)
 Überwachen Sie Folgendes:
o Anzahl kritischer Defekte und/oder Workarounds
o Anzahl der Änderungen an Anwendungsrollen
o Anzahl der Feuerwehrmann-Nutzungen
o Häufigkeit der Durchführung von Geschäftstransaktionen durch die IT
 Kommunizieren Sie sowohl mit internen als auch mit externen Auditoren über den Plan und den Zeitplan
für kurzfristige Hypercare-Kontrollen und den längerfristigen neuen Kontrollrahmen
 Lassen Sie uns in einem praktischen Szenario sprechen
Auslöser/Szenarien für Hypercare-Support
 Implementierung – Standard (oder) benutzerdefinierte Anwendung
 Upgrade - Standard (oder) benutzerdefinierte Anwendung
Arten von Problemen in Hypercare
 Benutzerprobleme
o Passworteinstellungen
o benutzerverwaltung
 Technische Probleme
o Backup
o Erholung
 Probleme mit dem Änderungsmanagement
o Genehmigungen ändern
o Prüfung
Unterstützungsarten in der Hypercare
1. Technischer Support
2. Schulung vor Ort
3. Umgang mit Problemen und Fragen
4. Eskalationsplan
5. Sicherstellung einer reibungslosen Übergabe

Technischer Support: Ein wichtiges Ziel des Hypercare-Supports ist die Lösung technischer Fragen des
Endbenutzers, der an der Anwendung arbeitet, sowie von Fehlern und Korrekturen. Dies ermöglicht es der
Anwendung, sich unter anderem in der neuen IT-Umgebung zu stabilisieren und effizient zu arbeiten. Dies
kümmert sich auch um die Datenintegration, die mit verschiedenen anderen bestehenden Systemen
stattfindet.

Schulung vor Ort: Dies ist ein weiterer Aspekt des Hypercare-Supports, der die Verfügbarkeit des Support-
Teams vor Ort umfasst. Dies ist so implementiert, dass Endbenutzeranfragen ohne Zeitverlust vor Ort gelöst
werden können. Dazu gehören auch Schulungen vor Ort für die Endbenutzer, die ihnen helfen, ein vollständiges
Verständnis der Anwendung zu erlangen, was die Anzahl der Anfragen, die während des laufenden Supports
auf den Support-Desk treffen, erheblich reduziert. Vor-Ort-Schulungen erleichtern es dem Endbenutzer auch,
sich vollständig mit der Anwendung vertraut zu machen. Dies erleichtert die Verwendung und erfüllt somit den
Hauptzweck der Anwendung.

Umgang mit Konfigurationsproblemen und Abfragen: Die Behandlung von Konfigurationsproblemen und
damit verbundenen Abfragen wird ebenfalls unter Hypercare Period verwaltet. Dazu gehören die Konfiguration
von Feldern, das Hinzufügen von Dropdown-Werten, das Ändern von Feldnamen, das Ändern von Positionen
der Felder usw. Dies sind einige der Aufgaben, die während der Hypercare für das reibungslose Funktionieren
der anwendungsbezogenen Prozesse erledigt werden. Dies trägt dazu bei, die Anwendung
benutzerfreundlicher zu gestalten und die Auflösungszeit so kurz wie möglich zu halten.

Sicherstellung einer reibungslosen Übergabe: Dies ist die letzte Aktivität, die unter die Hypercare-
Unterstützung fällt. Dazu gehören verschiedene Übergabeaktivitäten wie Dokumentation, Bestätigung der
Endbenutzer über verschiedene in der Anwendung konfigurierte Prozesse. Dazu gehört auch die Übergabe der
Administratorrechte der Anwendung an das Support-Team. In dieser Phase wird über die Bestätigung der
Lösung wichtiger Probleme berichtet.
Hypercare-Ansatz

Schematischer Vorfall/Ticket auf hoher Ebene – Ablauf/Eskalation (Beispiel)

 1 – Der Benutzer identifiziert einen "Fehler" oder "Fehler" in der Anwendung.
2a – Der Benutzer findet seinen Super-User, indem er die Liste der SUs nachschaut und sie
kontaktiert (wenn es dringend ist). Der Superuser analysiert den „Bug“ oder „Fehler“.
2b – Wenn das Problem dringend ist, wird sich der Benutzer direkt an den SD wenden
(Portal/E-Mail/Telefon).
3 – Der Superbenutzer kontaktiert den SD im Namen des Benutzers, um ein Ticket für den
Anwendungssupport anzufordern, um den "Fehler" oder "Fehler" (Break – Fix-Ticket) zu
beheben.
4 – Der SD durchläuft sein Skript, protokolliert den Vorfall und stellt sicher, dass er alle
Beschreibung relevanten Informationen erfasst und den Break-Fix dem entsprechenden Service zuweist.
Management-Ticket-Warteschlange. Problemtyp „Anwendung“.
5a – Das Ticket wird an IT Ops 2nd Line weitergeleitet.
5b – Wenn das IT Ops 2nd Line Team den Vorfall nicht lösen kann, wird das Ticket an das
Projektteam eskaliert.
6 – Das Projektbereitstellungsteam kann den Projektverantwortlichen zur gewählten Lösung
konsultieren.
7 – Das Projekt kann vorschlagen, dass der Änderungsprozess eingeleitet wird.
Während dieses Prozesses spielen der Product Owner und die Super User eine Rolle bei der
Implementierung der Änderung und testen/schulen den Endbenutzer nach Bedarf.

Schlüssel

Stakeholder/Hauptakteure: Rollen und Verantwortlichkeiten

 Die Implementierungsressourcen arbeiten eng mit dem Kunden zusammen, um alle Produktionsprobleme
während dieses Zeitraums zu verfolgen und zu lösen.
 Alle Probleme mit hoher Priorität sollten entweder gelöst werden oder einen Plan zur Lösung haben, bevor
der Kunde zum Support und Customer Success Manager (CSM) übergeht.
 Es ist auch unerlässlich, die Kunden bei der Messung der Akzeptanzmetriken während dieser Phase zu
unterstützen, um sicherzustellen, dass der Wert von Anfang an erreicht wird.

Rollen Zuständigkeiten
Support-Lead nach dem  Verantwortlich für PGLS Deliverable
Go-Live  Verwalten Sie den Plan und das Hochfahren und Herunterfahren
der Ressourcen
 Konsolidierte Ansicht des PGLS-Status
 Eskalationspunkt für das Unternehmen und die Stakeholder
 Eine einzige Kommunikationsquelle für alle PGLS-Aktivitäten
 Zentrale Koordinierungsstelle für PGLS zur Sicherstellung der
parteiübergreifenden Abstimmung (Business, Deployment Team, SD
etc.,)
 Management von Risiken und Problemen während der gesamten
PGLS-Phase
 Meldet PGLS-Status
 Überprüfung und Empfehlung der Funktionsbereitschaft, PGLS in
die Bau zu verlassen
Service Delivery Manager  Verbindung zwischen IT-Delivery, Service-Delivery und Business
 Sicherstellung der Abstimmung zwischen IT-Bereitstellung,
Servicebereitstellung und Geschäftsprioritäten/ Fokus
 Unterstützt die Lösung von Problemen
 Bietet Inputs/Anleitungen für das Unternehmen
 Verständnis von protokollierten Vorfällen und Trends
  Berichte PGLS Status für Funktionsbereich (Konsolidieren IS und
Business Review)
 Bericht über die Bereitschaft, PGLS in die Bau zu verlassen
IT-Delivery-Manager  Repräsentiert die IT-Delivery-Organisation
 Verantwortlich für die Lösung von Vorfällen während der
Garantiezeit
 Mängelbeseitigung vorgetragen in Bau
 Unterstützung der Service-Delivery-Organisation bei offenen
Incidents
Business Change Lead  Vertretung des Unternehmens
 Kommunikationsverbindung ins Geschäft
 Eskalationspunkt für Business-Funktion und Super-User
 Kerngeschäftsthemen und -prioritäten verstehen und
kommunizieren
 Risiken überwachen, Risikominderung implementieren und
Eventualitäten planen
 Sicherstellung der Einführung einer neuen Lösung innerhalb des
Unternehmens
 Außerbetriebnahme der Workloads sicherstellen
 Messen und Berichten von KPIs, Bewertungsaustrittsbereitschaft an
Bau
 Messung der KPIs des Anzeigenberichts, Bewertung der
Austrittsbereitschaft zur Bau
Super-User  Vertretung des Endbenutzers
 Firstline-Business-Support (On-Floor-Support)
 Beteiligen Sie sich an der Identifizierung, Lösung und
Kommunikation von Problemen (bidirektional)
 Unterstützung des Endbenutzers bei der Meldung von Vorfällen

(OR)
Wichtige Schritte, die zu einer erfolgreichen Hypercare beitragen
1. Richten Sie einen Kriegsraum ein – eine zentrale Unterstützungsbasis für Operationen
2. Identifizieren und platzieren Sie Projekt-Champions in Schlüsselbereichen, die am stärksten von
Veränderungen betroffen sind
3. Leicht zugängliche Schulungsinhalte
4. Dem Kunden zugeordnete dedizierte Projektmitglieder mit technischer Expertise des aufgerüsteten
Systems
Zu berücksichtigende Schlüsselelemente
 Endbenutzer-Support bei der Systemakzeptanz
 Technischer Support bei Incident- und Problemlösung
 Eskalationsmanagement
So funktioniert es
Hypercare-Kunden wird ein ausgewiesener zentraler Ansprechpartner (dediziertes Portal/E-Mail/Nummer) für
alle Supportanfragen zur Verfügung gestellt, der als Client Advocate bezeichnet wird. Der Kundenanwalt bietet
Hyper-Care-Kunden mehrere Vorteile, darunter:

1. Zentrale Anlaufstelle für den Kunden

2. Verwandte Anwendungslösungsexpertise
3. Vorhandene Kenntnisse der Kundenlandschaft und der Anforderungen
4. Zugangspunkt zu allen entsprechenden Ressourcen
5. Fortlaufender Kunden-Champion und Projektmanager für Ticketlösung

Teilnahmekriterien
 Befolgt die Bestätigung der Betriebsbereitschaft und die Inbetriebnahme

Betriebsfaktoren (Beispiele unten – auf Ihr Projekt zugeschnitten)

 Die Verantwortung verbleibt beim Projektbereitstellungsteam
 Vorfälle werden alle vom Endbenutzer, Superbenutzer oder Prozessschwerpunkt über den Service Desk an
das Projektbereitstellungsteam gemeldet
 Alle Vorfälle werden im Service Management Tool nachverfolgt
 Alle Vorfälle werden vom Projektbereitstellungsteam untersucht und gelöst
 Das Änderungsmanagement wird für alle Änderungen befolgt
 Projektteam führt Änderungen am Quellcode und der zentralen Konfiguration durch
 IT-Abteilungen nehmen an wöchentlichen Incident-Meetings teil
 Das Projektbereitstellungsteam ist für alle Supportaktivitäten verantwortlich, einschließlich aller
Bearbeitungs- oder Wartungsaufgaben.

Ausstiegskriterien
Was ist, wenn das Geschäft sehr anspruchsvoll ist und sich nicht auf den Ausstieg einigen will?
Stellen Sie sicher, dass Sie sich lange im Voraus auf Exit-Kriterien einigen. Vorzugsweise vor der UAT und in dem
Moment, in dem sie Probleme bemerken. Stellen Sie sicher, dass Sie Geschäftsinhaber haben, die KPIs für
Geschäftsprozesse definieren und wichtige Geschäftsaktivitäten auflisten, die mit der Projektunterstützung
durchgeführt werden müssen. Wenn diese Aktivitäten (mit "First-Run" -Datum) reibungslos ablaufen, gibt es
keinen Grund, sich nicht auf einen Austritt zu einigen. Wir nennen es „Business Criticality Calendar“.

z.B. solcher Aktivitäten im Finanzbereich könnte

 Erster Zahllauf aus neuem System

 Buchungsbeginn Eingangsrechnungen
 Erste Bearbeitung von Kontoauszügen
 FI-Abstimmung - Vermögenswerte

Quellen:
https://www.theshelbygroup.com/post-implementation-support-part-2-silence-bliss/ (Link nur auf Englisch)

https://systemsplusgroup.blogspot.com/2014/07/hypercare-support.html

https://www.snp-poland.com/de/better-business/case-studies/hypercare-support-after-sap-upgrade/

https://www.plantvision.se/hypercare/

https://opsasto.blog/2017/09/der-service-cutover-plan/

https://www.linkedin.com/pulse/went-live-now-what-part-1-ausra-gustainiene/ (Link nur auf Englisch)

https://www.acronotics.com/bot-wartung

https://success.coupa.com/Implement/Overview/04_Deploy/4.4_Hypercare_Plan einrichten

http://wpc.0b0c.edgecastcdn.net/000B0C/Presentations/GRC2016_Marrs_Hypercarehowtohandlesecurity.pdf
https://www.gartner.com/de/documents/3178218/how-to-plan-your-erp-project-s-go-live-hypercare-and-sta

https://prezi.com/3dhep-u49p2x/hypercare-model-kudu-wave-1/ (Link nur auf Englisch)

https://slideplayer.com/slide/14254660/