# 10 Roll-out und Hypercare > Page ID: 467740446 | Parent: TAF-TAP-TSI-Programmakte ---   Diese Seite dient der Übersicht und Dokumentation zu den Themen Roll-out- und Hypercare im Rahmen des TTT Programms.   | | Bearbeitungsstatus | | Status | YellowWIP | | Bearbeiter*in |   | | Letzte abgestimmte Version (Versionsnummer) | | | Erläuterung Abstimmung (z.B. Gremium, Protokoll) | ## Einführungsplanung   ## Zielsetzung Hypercare - Sicherstellung des stabilen IT-Betriebs nach Go-Live durch abgestimmte Verfügbarkeiten und klare Eskalationswege - Schnelle Fehlerbehebung & Reaktion im Störungsfall - Auch bei intensiver Hypercare planmäßige Weiterentwicklung für spätere Fahrplanphasen (z.B. ujBau) sicherstellen - Fokus / Kritische Erfolgsfaktoren: - Erreichbarkeit der Teams (Zeitslots) - Schnelle Reaktionszeiten bei Defects/Incidents - Klare und schnelle Eskalationswege bei Störungen - Hypercare in diesem Ausmaß ist Projekt- und kein Betriebsaufwand - Wunsch für Teamverfügbarkeit für betroffene Teams - kann team-individuell im Detail festgelegt werden - - Unter der Woche: - Mindestzeit: 08:00–18:00 Uhr - Ideal: 07:00–19:00 Uhr - Rufbereitschaft / möglicher Einsatz: am Wochenende zur Bearbeitung neuer Defects (Prio 1 und 2) oder auch Abarbeitung von Lastspitzen geplant in erwarteten "heißen Phasen" ## Planung und Gestaltung Hypercare Wir begleiten die Fahrplanphasen und fachlichen Rollout durch Hypercare, d.h. mit zusätzlicher Aufmerksamkeit und schnellen Reaktionszeiten für Beobachtungen auf Produktion. Dazu unterscheiden wir zwei Ausprägungen: | | Hypercare | Heiße Phase Hypercare | | - Erhöhte Aufmerksamkeit und Reaktionszeit für Incidents - Mitwirkende Teams haben Kapazität frei für Analyse/Incident Behebung - Teams sind auch in Tagesrandzeiten unter der Woche zuverlässig verfügbar - Standardisierter Management Bericht über aktuellen Stand | zusätzlich: - punktuelle Rufbereitschaft oder Arbeit außerhalb üblicher Arbeitszeiten für Wochenenden geplant -   Es ist nicht unser Ziel, regelmäßig am Wochenende zu arbeiten. Das ist ausschließlich eine Absicherung für den Fall, dass wir eine Bugwelle aufbauen, die wir zeitlich beschleunigt abbauen müssen.  Weitere Details werden auf den Unterseiten ausgearbeitet: