Thought Leadership
Die mit einem Unternehmenszukauf verbundene IT-Integration stellt eine besondere Herausforderung für alle Beteiligten dar. Im Projektmanagement müssen neben der Planung und Steuerung der technologischen Umsetzung sowie dem Risikomanagement auch die Kosten im Auge behalten werden. Allzu leicht läuft ein großes Projekt aus dem Ruder und scheitert schlussendlich oft aus finanziellen Gründen.
Nach einer Studie der WHU – Otto Beisheim School of Management werden komplexe Projekte vor allem dann abgebrochen, wenn die geplanten Laufzeiten bereits überschritten und rund 90 Prozent des Personalaufwandes verbraucht wurden, obwohl das Projekt nur zur Hälfte fertig gestellt ist. Die Gefahr des „Verzettelns“ ist gerade bei großen IT-Projekten immanent und kann nur durch eine genaue, aber gleichzeitig flexible Planung vermieden werden.
Für das erfolgreiche Management eines geschäftskritischen Migrationsprojektes gibt es verschiedene Ansätze. Ein aktuelles Beispiel zeigt, wie eine über zwei Jahre laufende IT-Verschmelzung in der Versicherungsbranche trotz einiger Widrigkeiten erfolgreich zum Abschluss gebracht werden konnte. Bei der PBV Lebensversicherung fiel der Startschuss 2007 mit der Entscheidung der Postbank zur strategischen Neuausrichtung: Die eigenen Versicherungsaktivitäten wurden im Rahmen des neuen Kooperationsvertrages an den langjährigen Partner Talanx AG übertragen. Auch wenn die Produkte weiterhin unter der Marke „PB Versicherungen“ exklusiv über die Vertriebswege der Postbank angeboten werden, liegt die organisatorische Verantwortung für die PBV Lebensversicherung jetzt bei der Proactiv Holding AG, die im TalanxKonzern die Bank Assurance- Tätigkeiten bündelt. Fragen zum ROI standen in diesem Fall nicht zur Diskussion, da der Merger davon nicht abhängig war.
Genaue und flexible Planung ist Pflicht
Bei näherer Betrachtung des konkreten Projekts zeigte sich die Komplexität eines solchen Vorhabens. Wie bei über die Jahre gewachsenen IT-Strukturen zu erwarten, beherbergten diese auch im Fall der Proactiv ein proprietäres Kernsystem, das über diverse Schnittstellen mit teilweise in verschiedenen Sprachen programmierten Umsystemen verbunden war.
Der Teufel steckt dabei im Detail: Bei Proactiv erforderte beispielweise die Kopplung von übernommenen COBOL-Programmen mit neuen Java-Komponenten zusätzlich eine „Softwarebrücke“, die anfangs nicht eingeplant war. Im Projekt musste daher auf Fachleute für die unterschiedlichsten Bereiche – von Netzwerk- und Anwendungsspezialisten über COBOL- und Java-Experten bis hin zu Datenbankprofis – zurückgegriffen werden. Insgesamt wurden etwa 9.000 Personentage verplant, um die rund 30.000 Aufgaben abzuleisten. Über die eigenen Mitarbeiter hinaus waren zwölf externe Firmen mit über 60 Spezialisten gefordert. Neben reinen IT-technischen Fragen spielten auch integrative Fragestellungen eine wichtige Rolle.
Stufenweiser Ansatz
Der enorme Aufwand ließ sich vor dem Hintergrund des geschäftskritischen Einflusses der IT-Integration auf den Gesamterfolg der Akquisition nicht vermeiden: Einzelne Fehler konnten bereits zum Stillstand essenzieller geschäftlicher Abläufe führen. Aufgrund dieser Abhängigkeit war ein exaktes, vorausschauendes Vorgehen gefragt. Aus Risikogesichtspunkten wurde eine BigBang-Migration verworfen und statt dessen ein stufenweiser Ansatz gewählt (siehe Bild 1).
Für jedes System wurde ein passgenaues Migrationsvorgehen gewählt und sich zwischen Carve-out und Carve-in oder der Ablösung durch ein Neusystem mit Übernahme der Daten entschieden. Das Projekt basierte von Anfang an auf definierten Zielen. Dabei stand die Entwicklung einer zukunftsfähigen Architektur ganz oben auf der Liste. Diese sollte über eine risikoarme Implementierung beziehungsweise Migration – unterstützt vom Aufbau einer optimalen Betriebsorganisation für einen weiterhin stabilen Einsatz – erreicht werden.
Eine erste Analyse in den Handlungsfeldern der bestehenden IT-Architektur kristallisierte vier Projekttypen heraus:
- Software-Entwicklung
- Infrastruktur
- Migration
- Implementierung
Diese Vielschichtigkeit verlangte nach dem Einsatz von über 60 Fachleuten aus zwölf externen Unternehmen. Jedes brachte sein eigenes Spezialwissen ein und für jedes wurde ein unterschiedlicher Vertragstyp mit verschiedensten Vereinbarungen festgelegt: Angefangen vom Gewerk mit Festpreis bis zur Dienstleistung auf Zeit- und Material-Basis. Nachdem das Grundgerüst stand, konnten die ersten Kernthemen für das Programmmanagement angegangen werden. Fragen zur Expertise der Projektleiter, der Programmplanung, den Reviews und Abnahmen sowie dem Programmreporting standen zur Diskussion und mussten vorab geklärt werden.
Programm- und Projektleitung
Projektleiter oder Projektmanager – wer soll die Verantwortung übernehmen? Nach einer Abwägung der Kriterien fiel eine „und“- Entscheidung: Es wurden Doppelspitzen gebildet, bestehend aus einem internen und einem externen Projektleiter: Der interne Projektleiter bringt das Know-How über die bestehende System- und Prozesslandschaft mit und kann so die inhaltliche Vollständigkeit und Qualität der Arbeit bewerten, der externe Projektleiter ergänzt dies durch Methodenwissen in Projektmanagement und die entsprechende Erfahrung mit Projekten hoher Komplexität. Den höheren Steuerungs- und Abstimmaufwänden standen die Positivaspekte der realistischen Zeit- und Aufwandseinschätzungen sowie der Risikoabwägung gegenüber. Diese waren für das Projekt schlussendlich ausschlaggebend. Vor allem die Bestimmung von Eintrittswahrscheinlichkeit und Schadenspotenzial im Risikomanagement (siehe Bild 2) profitierte von der „Doppelspitze“.
Programm- und Projektplanung
Gerade bei einem starken Anteil an eigenentwickelter Software ist eine strikte Planung über längere Projektlaufzeiten kaum möglich. Viele Prozesse sind im Standard nicht abgedeckt und – wenn überhaupt – nur rudimentär dokumentiert. Das nötige Durchleuchten jedes einzelnen Software-Pakets auf seine Funktion sowie die Betrachtung der aktuellen und künftig nötigen Schnittstellen sind zwar zeitintensiv, aber wichtig. Ein fest vorgegebener Produktiv- beziehungsweise Ablösungstermin und eine fixe Abstimmung mit den Teams in verbundenen Projekten lassen sich so allerdings nicht umsetzen. Die Alternative einer rollierenden Planung sorgt zwar für einen vertretbaren Planungsaufwand, kann aber – je nach Unternehmensstruktur – wegen einer naturgemäß schlechten Synchronisation mit der jährlichen Budgetplanung sowie mit weiteren Projekten für Unruhe bei den Stakeholdern führen. Alles in allem ist eine intensive Planung die Grundvoraussetzung für das Gelingen eines solchen Vorhabens. Beim Beispielprojekt der Versicherung entschied man sich für eine Mischung aus harter Meilensteinund rollierender Personaleinsatzplanung. Das ließ der Programmorganisation Spielräume in der Ausführung – sozusagen etwas mehr „Luft zum Atmen“ – und erlaubte eine genauere Planung des jeweils anstehenden Abschnittes im Projekt. Die Akquise von Spezial-Knowhow benötigte teilweise jedoch einen längeren Vorlauf als im Planungshorizont vorgesehen. Außerdem sorgte das gewählte Modell der rollierenden Planung zumindest am Anfang für eine höhere Nervosität bei den Stakeholdern. Durch die regelmäßige Kommunikation mit den Fachbereichen konnten jedoch deren Unterstützung gesichert und etwaige Ängste minimiert werden.
Reviews und Abnahmen
Vertrauen ist gut, Kontrolle ein Muss. Ein Review durch einen externen Gutachter und damit eine unabhängige Instanz bürgt für eine garantiert unverfälschte und kritische Experteneinschätzung. Allerdings sind entsprechende Kenntnisse nicht immer zu hundert Prozent vorhanden. Zudem wird zusätzlicher Overhead und Aufwand erzeugt. Bei einem Review beziehungsweise einer Abnahme durch interne Mitarbeiter – zum Beispiel involvierte Projektleiter – kann das bestehende Wissen aus dem Projekt genutzt werden, allerdings steigt dafür deren Arbeitsbelastung. Darüber hinaus sind bei einem Review oder einer Abnahme durch Projektleiter ein Interessenskonflikt und die Gefahr eines schnellen „Durchwinkens“ denkbar. Die möglicherweise negativen Folgen zeigen sich vielleicht erst später im Projekt durch das Wiederaufflammen neuer Diskussionen um „alte“ Fragestellungen, die zu Verzögerungen führen können.
Daher gilt: Der Voreingenommenheit („Fachblindheit“) involvierter Mitarbeiter sollte soweit wie möglich begegnet werden. Da sich durch verschiedene Blickweisen auf ein Thema die Qualität erhöht, setzte die Versicherung auf ein stufenweises Vorgehen. Konzeptreviews wurden durch ein Team aus internen Systemverantwortlichen und externen Testmanagern durchgeführt, die Abnahme der Konzepte erfolgte durch die verantwortlichen Projektleiter und die Abnahme der Systeme durch die Fachbereiche.
Programm-Reporting
Ein stetes Reporting sorgt für mehr Sicherheit innerhalb des Projekts und bei den Stakeholdern. Je nach Ebene und Gewichtung in der Projektorganisation sind Reportingzyklen von wenigen Tagen bis zu Monaten denkbar. Im Beispielprojekt der Versicherung entschied man sich wie folgt: In den Teilprojekten betrugen die Reportingzyklen wenige Tage, für das Projekt- und Programmreporting blieb eine Woche. Hinzu kamen monatliche Lenkungskreissitzungen. Durch die kurzen Reportingzyklen innerhalb der Teilprojekte konnten vor allem externe Mitarbeiter in den ausführenden Ebenen eng an den Projektplan gebunden werden. Auch die Verzahnung einzelner Arbeitspakete ist so besser organisierbar. Etwaige Risiken können schnell erkannt und beseitigt werden. Demgegenüber steht grundsätzlich der höhere Aufwand beim Erstellen der Reports, der seitens der Projektleiter und -mitarbeiter zu leisten ist.
Fazit
Eine intensive Analyse zur Erstellung der Roadmap war die Grundvoraussetzung für das Gelingen des Vorhabens im Fall der Proactiv. Diese Projektphase erfordert vollste Aufmerksamkeit und sollte sorgfältig und keinesfalls aufwandsminimiert durchgeführt werden. Nur über die detaillierte Betrachtung der Ist-Situation und Definition des Ziel-Zustands können Aufwände und Kosten realistisch abgeschätzt sowie eine Aussage zum erwarteten Return on Investment getroffen werden.
Hier zeigt sich die Bedeutung einer ausführlichen, stufenweisen Planung, die anfangs so genau wie möglich Zielzustände definiert, aber gleichzeitig die Flexibilität bei der Umsetzung berücksichtigt. Die Wahl neuer Systeme muss mit der wiederholten Überprüfung der für den Projekterfolg relevanten Kriterien einhergehen. Ansonsten kann es bei einer unzureichend detaillierten Analyse zu unerwarteten Aufwänden in der Realisierungsphase führen, was unter Umständen mittel- oder langfristig zum Scheitern des Projektes führt.
Dr. Roland Engl, www.cronosnet.de
Diesen Artikel lesen Sie auch in der it management , Ausgabe 11-2011.
