IT-Providerwechsel brauchen ein stringentes Konzept

Auch wenn neuer IT-Provider und Kunde bereits in früheren Jahren erfolgreich zusammengearbeitet haben, ist die erneute Serviceübernahme nach einem Provider-Intermezzo dennoch kein Kinderspiel und kann zum Lehrstück werden. noventum consulting hat einen solchen Fall beratend begleitet und die Erkenntnis auf allen Seiten nach erfolgreichem Projektabschluss ist: die Kombination eines Providerwechsels mit weitreichenden Systemwechseln darf nicht überspannt werden, wenn zugleich der Zeitdruck hoch ist. Die frühzeitige Beteiligung aller betroffenen Abteilungen und Personen an der Transition ist eine weitere wichtige Forderung an jeden künftigen Providerwechsel. Trotz aller Routine und Expertise von beiden Seiten kann die Übernahme immer wieder herausfordernd werden. Daran ändert auch die intime Kenntnis der IT-Landschaft, die es zu übernehmen gilt, nichts.

Anlass für die erneute Übernahme der IT-Services des Kunden, eines Abrechnungsdienstleisters mit nationalem und internationalem Fokus, war die routinemäßige Neuausschreibung seiner IT zum Ende der Vertragslaufzeit. Die vertieften Kenntnisse der Geschäftsprozesse des Kunden und seines Mutterkonzerns waren bei der Ausschreibung für den übernehmenden Provider sicher von Vorteil, so dass der Kunde erfolgreich zurückgewonnen wurde. Seit mehr als 20 Jahren im Bereich des IT-Hostings tätig und mit der Betreuung zahlreicher Systeme nationaler sowie internationaler Kunden betraut, durfte der alte/neue Provider zunächst von einer reibungslosen Übernahme ausgehen.

Die Sourcing-Berater der noventum consulting waren bei dem Provider aus erfolgreichen Projekten der Vergangenheit als Transitionsexperten gelistet. In früheren Projekten hatte noventum Kunden gegenüber dem Dienstleister vertreten, nunmehr sollten die noventum Berater auf seiner Seite eine ganzheitliche Sicht im Projekt vertreten, die Kunden- und Providersicht gleichermaßen berücksichtigt.

SAP Umgebung für europaweite Abrechnungsprozesse

Der wichtigste Bestandteil der Anwendungslandschaft des Kunden ist ein mächtiges SAP-Umfeld, das dieser für seine Abrechnungsläufe nutzt. Mit vielen tausend Akzeptanzstellen betreibt das Unternehmen eines der größten Verkaufsnetze seiner Branche.  Massenhafte Abrechnungsläufe gehen (mehrere Male im Monat) zwischen Kunden, Zwischenhändlern und Händler in zwei Richtungen umher. Das reibungslose Funktionieren dieser Abrechnungsläufe ist geschäftskritisch und Verzögerungen eines Laufs haben signifikante Auswirkungen. Daher wurde ein dedizierter SLA für die Verfügbarkeit und Performance aller am Abrechnugslauf beteiligten Systeme vereinbart, auch wenn der Kunde den Ablauf selbst verantwortet und steuert. Das reibungslose Funktionieren dieser Services ist sind im SLA an harte Vertragsklauseln und Pönalen geknüpft, was die außerordentliche Bedeutung des SAP-Systems unterstreicht. 

Die Transition der IT umfasste in Summe die folgenden Systeme: 

• SAP System 
• Windows Systeme 
• Linux Systeme 
• Netzkomponenten, -anbindungen 
• Internetzugang, VPN etc. 

Neben der Transition waren umfangreiche Neuerungen im Gepäck 

Der Sourcing Kunde nahm den Providerwechsel zum Ansatz umfangreicher Neuinstallationen in der Zielumgebung. Die Fachleute bei Kunde und Provider waren sich einig, dass diese Updates wertvolle Verbesserungen versprachen. Neben neuer Hardware gab es im Zuge des Providerwechsels im Zielsystem auch einige neue Anwendungen, Plattformen und Verknüpfungen, so z.B. den Ersatz einer Linux-Umgebung durch eine AIX Power-Umgebung. Weitere Anwendungen erfuhren ein Versionsupdate. Damit waren die Risiken dieses Providerwechsels nicht unerheblich. 

Eine strukturierte Übersicht aller Anwendungskomponenten, beginnend mit der SAP-Landschaft und endend mit kleineren Anwendungen und der übrigen Datenbasis, erstellte der Kunde. Hintergrund war, dass der Provider mit Ausnahme der SAP-Anwendungen für alle übrigen Anwendungen lediglich das Betriebssystem, Datenbanken bzw. und die Dateninfrastruktur zur Verfügung stellen sollte.  

Der SAP-Verantwortliche des Kunden hatte mit der Migration seines Bereiches von Linux auf AIX einen besonders anspruchsvollen Job zu leisten. Sämtliche Daten wurden von einem Backup in eine Linux-Installation beim Provider zurück gesichert. Danach wurde per SAP Export/Import Verfahren der Plattformwechsel auf AIX durchgeführt. Dieses komplexe Verfahren war aufgrund der unterschiedlichen Endianness (Byte Reihenfolge) der x86 und Power Systeme erforderlich. 

Die geplanten Systemänderungen im Kleinen wie Großen waren vielfältig. Eine Vorverlegung der Transition um einen Monat auf Kundenwunsch erhöhte das Anforderungsniveau für alle Beteiligten. 

Kunde und Provider installierten für den Übergang interne und externe Projektverantwortliche und -berater. Auf der Kundenseite war vor allem die IT im Planungsprozess involviert, die Verantwortlichen der unterschiedlichen Anwendungsbereiche beim Kunden (z.B. Prozessverantwortliche) wurden erst später in den Lenkungs- und Planungsgremien aktiv. 

Transition und Systemwechsel im zweiten Anlauf gelungen 

Der Cutover lief die ersten Stunden reibungslos. Anwendungen wurden heruntergefahren, Datenausleitungen durchgeführt und über die Migrationsleitung in das neue Rechenzentrum transportiert. Die Linux Systeme für die SAP Migration wurden erfolgreich aufgesetzt und das Export/Import Verfahren gestartet. Hierbei traten dann mehrere Fehlerbilder auf, welche den Export einiger Systeme sehr stark verzögerten. Wiederholten Analysen und Versuchen zum Trotz, verhielten sich die Exporte am Cutover-Wochenende anders als bei den wiederholt durchgeführten Testläufen. Am Sonntag wurde gemeinsam beschlossen, in Teilen ein Rollback durchzuführen.  

In einer Ad-Hoc Session mit allen Anwendungsverantwortlichen des Kunden und den Systemverantwortlichen des Providers wurde festgelegt, welche Umgebungen schon in der Zielumgebung starten können und welche vom Fall Back betroffen sind. Dieser Plan wurde ausgeführt und die Produktion in der neuen Situation wieder aufgenommen. Ein Teil der alten Systeme musste noch einige Zeit länger ihren Dienst tun. 

Eine tiefgehende Analyse des Cutover erbrachte, dass verschiedene Fehlerquellen zusammen für die unerwarteten Laufzeiten des Exports/Imports und einen weiteren Systemfehler verantwortlich waren. Dies betraf sowohl Infrastrukturkapazitäten als auch Anwendungs- und Datenlogiken.  

Im zweiten Anlauf konnten so die Fehler vermieden werden und der Umzug vollständig und tatsächlich noch innerhalb des ursprünglich veranschlagten Zeitraums umgesetzt werden. Marc Buzina, noventum Berater und Projektleiter auf der Seite des alten/neuen Providers ist trotz aller Widrigkeiten sehr zufrieden mit dem Ergebnis. „Auch der Umgang mit Fehlern und Krisen will gekonnt sein. Wir haben auf der Seite von Provider und Kunde gleichermaßen professionell auf die Schwierigkeiten reagiert, die im Datentransfer aufkamen. Heute sind beide zufrieden mit dem Ergebnis.“ 

Ein gutes Krisenmanagement muss auch „Stopp“ sagen können 

Frage an den Berater: „Welche Konsequenz und Lehre kann aus einem Providerwechsel gezogen werden, der nicht im ersten Anlauf funktioniert?  

Marc Buzina: „Jede Transition ist im Detail besonders, so dass man nicht für jede Eventualität ein Rezept in petto haben kann. Das ist aber nicht schlimm, solange es eine klare Rollenverteilung gibt. Und hier muss bei einer nachträglichen Fehlersuche auch die Analyse beginnen.  

• Um die Anforderungen, die man als Provider hat, durchzusetzen, muss man die Möglichkeit nutzen, alle substanziell Beteiligten auch wirklich mit an den Tisch zu bekommen. Bei fachlichen Differenzen sollten Eskalationswege auch genutzt werden.  
• Nicht neu und dennoch wichtig ist es auch, Testszenarien so nah wie irgend möglich an der Realität auszurichten. Jede Abweichung kann zum Problem werden. Hierfür ist beim Provider und Kunden genügend Zeit und Kapazität einzuplanen. Dies bedeutet gegebenenfalls die Durchführung einer vollständigen Generalprobe.“ 

Frage: „Sollte die Richtlinienkompetenz für die Regeln einer Transition ungeschmälert beim Provider liegen?“ 

Marc Buzina: „Dort liegt sie ohnehin. Der Provider steuert den Übergang per se. Es ist im Regelfall nicht die Kernkompetenz eines Kunden, die Überführung seiner IT von einem Provider zum nächsten zu steuern. Dennoch lässt sich nicht alle Verantwortung outsourcen. Weil das so ist, müssen und sollten sich Kunden für diese Phase eine entsprechende beratende Kompetenz ins Haus holen. Am besten eine gute.“