Outsourcing, Offshoring & Alliances - Transition
Phase 3: Transition
Implementierung, Transition
Die Implementationsphase ist im Standardfall ein klassisches Projekt.
Es hat fast immer alle Merkmale eines großen Organisationsprojektes wie
Firmenübergreifend und manchmal auch länderübergreifend
Großes Projektbudget
Großer Zeitdruck
Komplexe Anforderungen
Die Implementierungsphase bei großen Outsourcingprojekten realisiert eine umfassende, bereichsübergreifende und inhaltlich weit reichende Veränderung. Es muss neben der Lösung der technischen Herausforderungen auch berücksichtig werden, dass sehr viele Personen im Unternehmen nach der Transition andere Aufgaben, andere Kollegen, einen anderen Arbeitsort oder gar keine Arbeitsstelle mehr haben. Um die Betroffenen dennoch zur Mitarbeit zu motivieren ist ein großes Fingerspitzengefühl seitens des Projektleiters erforderlich.
Die technischen Anforderungen sind meist auch sehr groß, können aber bei guter Vorbereitung in der Due Diligence Phase auch von einem geübten Projektmanager ohne IT-Spezialwissen abgewickelt werden. Der Projektleiter muss allerdings bei der Ausarbeitung der Leistungsverträge bereits aktiv eingebunden sein.
Die technischen Details unterscheiden sich natürlich von Projekt zu Projekt. Auf der Metaebene haben diese Projekte immer zwei Hauptaufgaben. Es sind dies die technische Implementierung und die Integration der Mitarbeiter.
Integration der Technik
Hier wird sich in fast allen Fällen der Ort der Leistungserbringung verändern. Prinzipiell sind informationstechnische Dienstleistungen nicht an Örtlichkeiten gebunden. Es gibt aber eine Reihe von technischen Details deren Nichtbeachtung für den Endbenutzer zu einer Nichtverfügbarkeit der Systeme führen kann (z.B. IP-Adressenänderung oder Serverkonsolidierung).
Zentraler Aspekt dieser Phase ist ein funktionierendes Business Continuity Management. Da sich in der Transition Phase unter Umständen bei mehreren Prozessen, die Prozessverantwortlichen ändern und auch die Schnittstellen organisatorisch und technisch geändert werden, besteht in dieser Phase die größte Gefahr einer Prozessunterbrechung für das Unternehmen. Der einzige Vorteil dabei ist, dass bei sorgfältiger Vorbereitung die möglichen Gefahrenpunkte sachlich und zeitlich relativ genau definiert werden können. Da nicht alle Aspekte im Vorhinein getestet werden können, ist ein Business Continuity Plan unerlässlich. Das bedeutet, dass man für die wesentlichen Teilschritte, ein Fallback-Szenario vorbereiten muss.
Neben der funktionellen Planung dieser Szenarien muss auch der Zeitplan so definiert sein, dass zumindest ein Teil der Notszenarien so eingeplant ist, dass keine Terminüberschreitung dadurch verursacht wird.
Man sollte aber in der Implementierungsphase nur die aufgrund des neuen Umfeldes notwendigen Änderungen durchführen. Eine Optimierung des Betriebes in dieser Phase wird das Projekt meist überfordern und kann Ursache für ein Scheitern sein.
Typische kritische Phasen sind zum Beispiel, die Umschaltung von Datenleitungen zwischen verschiedenen Anbietern und Standorten oder ein erzwungener Wechsel eines Betriebssystems im Transition Projekt.
Integration der Mitarbeiter
Die Integration von Mitarbeitern ist nicht nur ein Thema wenn ein großer Teil der Mitarbeiter zum Outsourcer wechselt. Auch wenn keine Mitarbeiter den Dienstgeber wechseln (Shared Service, Beibehaltung der personalrechtlichen Zugehörigkeit, etc) bedeuten solche Projekte immer eine massive Änderung der Organisation speziell der Kommunikationswege sowie der Arbeitsinhalte.
Die Integration von Mitarbeitern in eine neue Organisation ist oft anspruchsvoller als die Integration der Technik. Die Qualität der IT-Dienstleistung steht und fällt maßgeblich mit der Qualifikation und besonders der Motivation der Mitarbeiter. Werden Mitarbeiter übernommen, müssen diese in die für sie neue Struktur sukzessive überführt werden. Eine frühzeitige Einbindung der Mitarbeitervertretungen und Mitarbeiter bereits während der Detailanalyse ist wichtig. Dies kann in Form von Workshops, Einbindung des Betriebsrates und einer offenen Kommunikation mit den zu übernehmenden Mitarbeitern geschehen.
Transitionsansatz anhand eines Beispieles
Während bei der Evaluierung die ganzen Prozesse betrachtet werden, sind die anderen Phasen des Projektes nach Sachthemen strukturiert. Je nach Outsourcinggegenstand (Prozesse, Teilprozesse) werden sich bereits in der Due Diligence Phase jeweils andere Personen bei den Verhandlungen gegenübersitzen.
Bei der Ausformulierung der Teilaspekte sind die Sachkenntnisse wesentlich. Am deutlichsten merkt man diese Unterteilung in der Transition Phase. Hier sind je Sachgebiet/Teilprozess/Applikationen jeweils eigene Teilprojekte mit unterschiedlichen Teams zu definieren. Je nach Abhängigkeiten zwischen den Applikationen können diese tw. oder zur Gänze parallel abgewickelt werden. Es müssen allerdings für jedes Teilprojekt die oben angeführten Überlegungen bezüglich Business Continuity Management bzw. Wiederaufsetzpunkte geplant werden.
Auch im Betrieb ist im Normalfall die Struktur genau erkennbar. Häufig wird für jede Applikation ein eigener Leistungsvertrag abgeschlossen. Diese Teilverträge können sowohl unterschiedliche Service Levels als auch unterschiedliche Laufzeiten haben.
Bei Cloud Computing werden nur eine oder mehrere Applikationen vom Anbieter abgelöst (SaaS) oder vom Anbieter übernommen (PaaS). Das Transition Projekt besteht in diesem Falle nur aus Datenübernahme, Datenmigration und Test der Daten. Da bei diesen Projekten praktisch immer die Applikation wechselt, kann kaum eine 1:1 Übernahme erfolgen. Müssen danach historische Daten übernommen werden so ist dies häufig mit einem größeren Migrationsaufwand verbunden.
Ein Aspekt ist auch das Zeitverhalten der Applikation, das oft erst nach Übernahme aller Produktionsdaten wirklich getestet werden kann.
Transition vs. Transformation
Im Übergang der Leistung an den Outsourcer sind oftmals zwei Phasen abzugrenzen: Transition und Transformation.
Die Transition ist dabei ein rein horizontaler Prozess. Die Leistungserbringung wechselt vom Outsourcing-Kunden oder vom Bestandsvendor (auch oft als Incumbent Provider bezeichnet) zum neuen Outsourcer. Die Art der Leistungserbringung bleibt dabei jedoch im Kern unverändert (CMO / Current Mode of Operations). Die Transformation hingegen ist ein vertikaler Prozess, der die Leistungserbringung verändert und in den sogenannten Future Mode of Operation (FMO) bringt. Die Transformation spielt dabei eine wesentliche Rolle, denn damit können erst die eigentlichen Ziele des Outsourcings erreicht werden. Eine Transformation befasst sich beispielsweise mit der Konsolidierung von Prozessen, Applikationen, der Reduktion und Standardisierung von Hard- und Software, etc. Abbildung 15 zeigt den Zusammenhang von Transition, Transformation, dem CMO und dem FMO.
Nun kann eine Transformation bereits im Zuge einer Transition oder erst danach stattfinden. Viele Entscheidungsträger werden erstere Variante nachfragen, da damit in der Regel auch schneller die erwarteten Ziele eintreten können. Dem entgegen steht die gewaltige Komplexität, die durch die Vermischung von Transition und Transformation entsteht. Die Gestaltung des Übergangs sollte damit genau überlegt werden.
