Ist der neue Hosting-Vertrag unterzeichnet, atmet der Einkauf auf und die IT ein: jetzt wird es kritisch, die Systeme wollen bewegt werden. Hier empfiehlt sich wie so oft eine detaillierte und vorausschauende Planung, denn nur so wird das Transformationsprojekt zum Erfolg.
Das Umziehen Ihrer IT-Rechenzentrumslandschaft von einem Anbieter zu einem anderen gehört zu den interessantesten Herausforderungen im IT Infrastruktur-Management. Einerseits kann das Projekt sehr groß werden, andererseits hat man darin – im Idealfall – wenig Übung. Wohl dem, der sich der Vorbereitung und falls nötig der Partnerwahl mit ausreichend Vorlauf widmet.
Der Ablauf
Das Transitionsprojekt wird je nach Kunde und Anbieter immer ein wenig anders aussehen, sowohl was den Inhalt als auch was die Timeline betrifft. Grundsätzlich lassen sich aber folgende Phasen unterscheiden:
- Projekt-Start
- Sandbox-Test
- Test-Umzug
- Produktions-Cutover
- Nachbereitung
Etwas detaillierter, hier beispielhaft für eine SAP 3-System-Landschaft mittlerer Kritikalität Datenbank-Größe die erneute Auflistung der Phasen mit Inhalten und Abschätzungen:
- Start: 5 Tage Aufwand (Zeitraum 4 Wochen): Kickoff, Bestellung WAN, Cutover-Termin festlegen
- Sandbox: 5 Tage Aufwand (Zeitraum 2 Wochen): detaillierte Ablaufplanung, Übernahme erster Testsysteme
- Test: 5 Tage Aufwand (Zeitraum 4 Wochen): Übernahme Testlandschaft, Test
- Produktion: 15 Tage Aufwand (Zeitraum 4 Wochen): Vorbereitung, Optimierung, Durchführung Produktions-Umzug
- Nachbereitung: 5 Tage Aufwand (Zeitraum 1 Woche): Hypercare, Abwicklung, Optimierung
Bitte berücksichtigen Sie mögliche Komplexitätstreiber wie Verfügbarkeitsanforderungen, Datenbankgröße oder Komplexität des Unternehmens. Stehen Sie vor solchen Herausforderungen, sollten Sie die gemachten Schätzungen auf jeden Fall mit entsprechenden Zuschlägen versehen.
Während der Projektbeginn recht einfach festzulegen ist, gilt das für das Projektende nicht immer. Die Abgrenzung zwischen Produktivsetzung und Produktivbetrieb (und dessen Optimierung) ist nicht immer klar ersichtlich. Achten Sie hier darauf schon vorab so eindeutig wie möglich zu definieren wann das Projekt als abgenommen gilt. So geht einerseits die IT nicht zu früh in die Betriebsverantwortung, andererseits hat das Projekt einen klaren Rahmen in dem es operieren kann. Klären Sie in diesem Zusammenhang auch bis wann Incidents und offene Punkte im Projekt aufgenommen werden, und wann diese in die Aufgaben des Betriebs fallen.
Natürlich kann man sich hier gütlich verständigen ohne um einzelne Stunden zu feilschen, eine transparente Kommunikation vorab verringert jedoch das Risiko des Scope-Creeps beträchtlich.
Die ersten Schritte
Im Normalfall geht dem Transitionsprojekt eine Ausschreibung voraus. Hier ist oft der Druck hoch, schon vor Ende der Ausschreibung mit ersten Tätigkeiten zu beginnen. Achten Sie darauf, auf jeden Fall vor Beginn der Umsetzung eine Unterschrift unter dem neuen Hostingvertrag (-swerk) haben. Viele Hosting-Partner bieten großzügig an auch schon vor der Klärung aller Details auf Basis eines LoI (Letter of Intent) mit der Transition zu beginnen.
Davon rate ich dringend ab, denn die Klärung der Details kann im schlimmsten Fall zum Scheitern der Verhandlungen führen. Dann sitzen Sie ohne Vertrag auf einem Berg an internem und externem Aufwand, womöglich haben Sie sogar schon einen Teil Ihrer Systeme beim Partner (und damit keinerlei Hebel mehr in den Verhandlungen, und kaum noch Rückzugsmöglichkeiten). Sie können also gern schon planen, umsetzen sollten Sie jedoch erst dann, wenn die Unterschrift trocken ist.
Es hat sich empfohlen sowohl von Kunden- als auch von Partnerseite jeweils einen Projektleiter zu benennen, von denen jedoch nur einer die Gesamtverantwortung übernimmt. Sobald beide bekannt sind, entwerfen Sie die grundlegenden Dokumente zum Projekt: Ziel und Umfang, Organisation, Stakeholder, Zeit- und Ablaufplan. Diese Informationen sind nach Abnahme durch den Auftraggeber (meist der CIO) die Grundlage des Kickoff-Termins. Sind die dort anwesenden Ansprechpartner nicht entscheidungsbefugt, sollten die präsentierten Inhalte natürlich zunächst jeweils abgestimmt werden.
Kleiner Tipp: gleichen Sie möglicherweise kritische Projektinhalte unbedingt vor den großen Terminen ab. Eine hitzige Diskussion zum Umzug des produktivkritischen selbstentwickelten Print-Daemons auf dem zweiten Linux-Server von links raubt Ihnen einerseits Zeit, und schwächt andererseits das Ansehen des Projekts bei den Zuschauern. Ermitteln Sie also mögliche Klippen, und nehmen Sie diese vorab im kleinen Kreis. Das Kickoff ist kein Diskussionstermin, sondern eine Präsentation des Projektinhalts. Etwaiges Feedback sollten Sie natürlich trotzdem zulassen und aufnehmen.
Die erste operative Amtshandlung (gern schon vor dem Kickoff) ist das Design der zukünftigen Landschaft und die Bestellung der WAN-Anbindung. Die Bereitstellung dieser wird je nach Anbindungsart mehrere Monate betragen, und stellt für Transitionsprojekte den übergreifenden kritischen Pfad dar.
In dieser Phase legen Sie vor und nach dem Kickoff die Rahmenbedingungen für das Projekt fest:
- Organisation: wo werden zentrale Dokumente (Projektplan, Incidentliste, Offene Punkte usw.) abgelegt, wer pflegt
- Dokumentation: Audit-Anforderungen abklären
- Übernahmeart: Migrationsexport nötig? Filer oder WAN?
- Ressourcen: drei beteiligte Partner (zwei Hosting-Provider und das Kundenunternehmen)
- Testen: wer soll in welcher Detailtiefe testen, wer erstellt Testpläne und hält sie nach
- Cutover: wie viel Zeit steht für den produktiven Cutover zur Verfügung, erste Terminplanung
- non-SAP: existieren hier Tools und Know-How zur Übernahme
Der Probelauf
Nachdem alle Beteiligten das Vorhaben kennen und Ressourcen eingeplant haben, kann der Testlauf beginnen. Die Testübernahmen sollten so spät wie möglich an den produktiven Übernahmen stattfinden, um Prozesse und eingesetzte Werkzeuge auf Einsatzfähigkeit zu prüfen, und der Landschaft nicht die Möglichkeit zu geben sich zu weit von der Testumgebung zu entfernen.
Die mit den Partnern entwickelte Timeline sollte klar kommuniziert werden (vor allem bei Änderungen), um den beteiligten Fachbereichen die Einplanung der Ressourcen zu ermöglichen. Sind die Termine bestätigt (oder zumindest unwidersprochen) kann die Umsetzung beginnen. Für kritische Ressourcen im Projekt reicht die stillschweigende Hinnahme nicht aus, stimmen Sie hier proaktiv mit betroffenen Mitarbeitern und Führungskräften den geplanten Einsatz ab.
Im Normalfall beginnt man mit einem beliebigen System (kann auch das produktive sein) und führt einen ersten Sandbox-Lauf durch. Der muss weder konsistent (offline) sein, noch schnell gehen. Wichtig ist nur das geplante Vorgehen ein Mal grundsätzlich durchzutesten. Wird das Produktivsystem verwendet, achten Sie darauf dass es nach dem Testaufbau im Ziel nicht kommuniziert (alle User sperren, alle Batchjobs deaktivieren).
War dieser Lauf erfolgreich, kann die Übernahme der nicht-produktiven Systeme beginnen. Die Bemessung der Testzeiträume erfolgt je nach Anforderungen der Fachbereiche, SAP empfiehlt für Migrationen 4 Wochen Testzeitraum.
Gestalten Sie die Tests nur so aufwändig wie nötig. Konzentrieren Sie sich auf Kommunikationsprozesse (SAP Logon, Print, Up/Download, IDOC, PI, Files, ..) denn diese sind am stärksten von der Änderung betroffen. Klären Sie, welche Prüfreports vor- und nach dem produktiven Umzug laufen sollen (FI und CO stehen hier im Fokus), und testen Sie wie viel Zeit sie für diese brauchen.
Cutover und die Zeit danach
Setzen Sie zusätzlich zum Projektplan einen detaillierten Cutover-Plan auf, in den auch diese Zeiten einfließen. Wer hat außerdem wann was zu tun? Welche finalen Tätigkeiten müssen direkt vor dem Cutover erfolgen, welche direkt danach? Welche Prozesse und Funktionalitäten müssen geprüft werden, bevor nach erfolgtem Umzug die Systeme wieder an den Kunden freigegeben werden können? Wie und wo werden die Prüfprotokolle abgelegt?
Nicht zu vergessen ist die Frage des Fallbacks. Wichtig ist hierbei, dass Sie sich überlegen
- An welchen Punkten müssen Sie Fallback-Möglichkeiten (oft ein Full Backup) schaffen?
- Wie lange dauert die Umsetzung des Fallback-Szenarios?
- Wann müssen Sie beginnen, um das Altsystem im Notfall noch im Wartungsfenster wieder bereitzustellen?
- Gibt es zusätzlich zur Produktivsetzung einen weiteren Point of no return, der eine gesonderte Freigabe erfordert?
- Wie lange halten Sie Fallback-Szenarien vor?
- Wie lange muss (bspw. aus Revisionsgründen) das letzte Backup vor der Umstellung aufbewahrt werden?
Denken Sie darüber hinaus auch an Ihre Projektmitglieder. Umzugsprojekte finden häufig am Wochenende und außerhalb der Büroarbeitszeit statt. Insbesondere in Deutschland sollten Sie hier rechtzeitig mit Führungskräften und Betriebsrat in Kontakt treten, um die Arbeitseinsätze abzustimmen.
Im Anschluss an die Cutover-Phase inklusive des GoLives folgt nach Produktivfreigabe an die Fachbereiche eine Phase des intensiveren Supports – die sogenannte Hypercare-Phase. In dieser werden Kundenanfragen noch durch das Projektteam beantwortet, welches sich zu diesem Zweck in erhöhter Alarmbereitschaft (oft mit Rufbereitschaftsnummern) befindet. Die Linienorganisation wird unterstützen, um sich vom Projektteam in den ersten Wochen des Produktivbetriebs on-the-job ausbilden zu lassen. Die Hypercare-Phase endet typischerweise 4-6 Wochen nach dem Produktivstart. Tauchen in hoher Anzahl schwerwiegende Fehler auf, muss eine RCA erfolgen die ggf. in einen Projekt-Change mündet. Theoretisch ist so auch ein Redesign mit Delta-Implementierung, -Test und Mini-GoLive möglich. In den meisten Fällen bekommt man das System aber auch ohne solch drastische Maßnahmen in den Griff.
Abschluss
Ist das System final abgenommen, endet das Projekt. Das System, die Dokumentation und der Supportprozess wird offiziell an die Linien-IT übergeben. Die vorab in Trainings und on-the-job trainierten IT-Kollegen sollten nun in der Lage sein, den Produktivbetrieb selbständig zu unterstützen. Zwischenzeitlich in Status-Meetings aufgezeichnete Rückmeldungen zu Problemen und Potentialen (Lessons Learned) wird nun zusammengeführt und mit dem Team besprochen. Die Ergebnisse werden zentral abgelegt, um auch Folgeprojekten den Zugriff zu ermöglichen.
Sie haben es geschafft, Zeit mit dem Team (Linie und Projekt) den Erfolg zu feiern. Auch im noch so knappen Projektbudget sollte ein wenig Geld vorhanden sein um bei einem Feierabend-Schwarztee Projektanekdoten und Zukunftspläne auszutauschen. Das rundet das Projekt angenehm ab, und erleichtert den Einstieg für das nächste Vorhaben.
Eine möglichst problemarme Umstellung,
