Oberflächlich betrachtet hat die Finanzkrise die Anzahl an Unternehmenszusammenschlüssen und -übernahmen deutlich verringert. Andererseits bietet sie vielen Unternehmen, die noch über Liquiditätsreserven verfügen, gute Chancen für rentable Investments: Zum einen lassen sich eventuell notwendige Restrukturierungen des eigenen Geschäftsmodells gerade jetzt durch einen Merger oder ein Carve-out schnell vorantreiben. Zum anderen stellen sich zuvor teure Investitionen heute möglicherweise viel vorteilhafter dar.

IT-Aspekte spielen für solche Entscheidungen kaum eine Rolle. Der Beschluss für einen Merger oder Carve-out steht längst, wenn die zumeist komplexen Auswirkungen auf die IT-Landschaft ins Blickfeld rücken. Die IT muss dann versuchen, die Veränderungen auf der unternehmerischen Seite systemtechnisch nachzubilden. Dabei hat sie fast immer einen engen Zeitplan einzuhalten. Ein standardisierter Prozess zur Integration beziehungsweise Desintegration der IT-Landschaften zweier Unternehmensteile spart Kapital und Ressourcen. Wie ein solcher Prozess aussehen kann, lässt sich anhand von sieben Kernfragen beschreiben.

Welche Management-Aufgaben fallen bei einem Merger an?

Ein IT-Projekt im Rahmen einer Post-Merger-Integration (PMI) oder eines Carve-out muss vier Handlungsfelder adressieren:

• Management,

• Strategie,

• Design und

• Transition.

Das Management unterstützt alle Phasen des Projekts, indem es die Qualifikationen der Teammitglieder identifiziert, deren Auswahl und Coaching übernimmt sowie Schulungsprogramme organisiert. Darüber hinaus stellt es Templates für Prozesse sowie Controlling- und Reporting-Instrumente bereit. Eine weitere zentrale Aufgabe besteht darin, die passenden Governance-Funktionen sowie die dazu notwendigen Kontrollgremien zu etablieren.

Außerdem sind Termine für regelmäßige Projekt-Reviews mit den eventuell notwendigen Steuerungsmaßnahmen einzurichten. So müssen etwa Kommunikations- und Eskalationsprozesse implementiert werden - für den Fall, dass die zuvor definierten Zeitpläne hinsichtlich des Transfers in Gefahr geraten. Ebenfalls ein kritischer Punkt ist die Steuerung der beteiligten Partner. Sie muss sich vor allem dann beweisen, wenn etwas schiefläuft. So kommt es bei der Migration zweier Anwendungssysteme, die von unterschiedlichen IT-Dienstleistern betreut werden, im Fehlerfall schnell zu gegenseitigen Schuldzuweisungen.

Wie bleibt der Bezug zur Geschäftsstrategie gewahrt?

Die Strategiephase wird - aus Kostengründen - in vielen PMI-Projekten vernachlässigt. Das ist gefährlich, denn in dieser Phase wird die Brücke zwischen Geschäftsstrategie und IT-Umsetzung geschlagen (Stichwort IT-Business-Alignment). Wie die Praxis zeigt, geben die Unternehmen originär durch einen Merger begründete IT-Projekte gern komplett an die IT ab. Das führt oft dazu, dass die Projekte lediglich aus einer funktionalen Perspektive heraus gesteuert werden. Der Bezug zur ursprünglichen Geschäftsstrategie geht damit verloren.

Um das Business-IT-Alignment sicherstellen zu können, sollten die IT-Verantwortlichen die Geschäftsstrategie im Vorfeld analysieren - und zwar nach fünf Dimensionen: Im Produktbereich sind unbedingt die aktuellen und künftig geplanten Produktlinien zu untersuchen. Hinsichtlich der Dimension Markt stehen die vom Management geforderten Vertriebskanäle im Blickfeld. Die Dimensionen Innovation und Technologie werfen beispielsweise die Frage auf, ob das Enterprise-Content-Management oder eine andere IT-Lösungen für das Geschäftsmodell und die Interaktion mit dem Kunden erfolgskritisch ist. Die Dimension Wertschöpfung definiert schließlich, wo und wie sich im IT-Produktionsablauf - etwa durch bestimmte PLM- und Sourcing-Entscheidungen - die Wertschöpfungskette optimieren lässt. Für alle Services, die innerhalb dieser Dimensionen bereits existieren, gilt es, die geplanten sowie die aktuellen Geschäftsanforderungen und Service-Levels aufzunehmen.

Wie ist die operative Handlungsfähigkeit zu gewährleisten?

Bereits in der Strategiephase ist der zu integrierende beziehungsweise herauszulösende Unternehmensteil einer genauen Analyse zu unterziehen. Zu den Aufgaben, die hier anfallen, gehören das Studium extern verfügbarer Informationen, ein High-Level-Screening der genutzten IT-Techniken sowie eine erste Schätzung der laufenden Betriebs- und Personalkosten.

Darauf folgen eine Grobanalyse der funktionalen Abhängigkeiten zwischen den IT-Prozessen sowie die Identifikation und Evaluierung von Risiken für den Ausfall von IT-Systemen während der Umstellung. Im Fall einer IT-Integration ist es von entscheidender Bedeutung, alle relevanten Anwendungen konstant verfügbar zu halten. E-Mail-Systeme sowie zentrale Produktions-, Vertriebs- und Abrechnungsprozesse dürfen nicht für längere Zeit unterbrochen sein.

Eine weitere wichtige Frage betrifft den notwendigen oder gewünschten Integrationsgrad der IT-Systeme. Ist nur eine teilweise Integration geplant, so muss geklärt werden, ob - wie oft üblich - nur das Desktop-Management vereinheitlicht wird, also die Anwendungssysteme weiter isoliert betrieben werden sollen. Eine pragmatische Variante besteht darin, nur die Controlling- und E-Mail-Systeme zu vereinheitlichen, um Corporate-Governance- und Compliance-Anforderungen erfüllen zu können.

Im Falle eines Carve-out hingegen gilt es zu analysieren, welche IT-Systeme für den auszugliedernden Unternehmensteil in jedem Fall erforderlich sind. Denn er muss auch aus der IT-Sicht als autonome Einheit handlungsfähig bleiben.

Welche Ergebnisse sollte die Strategiephase liefern?

Nach der Analyse der technischen Abhängigkeiten und Risiken ist als Abschluss der Strategiephase ein strategischer IT-Blueprint zu definieren, der die Struktur der künftigen IT-Systeme beschreibt. Diese "Blaupause" beziehungsweise die dahin führenden IT-Projekte sollten einer Business-Case-Betrachtung unterzogen werden.

Auf dieser Basis lässt sich dann eine belastbare Budgetstruktur für das Gesamtprojekt ermitteln. Und aufgrund von Geschäftsstrategie, strategischem IT-Blueprint und skizziertem Budgetrahmen wird schließlich ein Migrationsszenario samt Umsetzungs-Roadmap entwickelt.

Wie sind die IT-Blueprints in der Designphase zu behandeln?

Mit der Ausarbeitung spezifischer IT-Blueprints für alle relevanten IT-Lösungen - auf Basis des in der Strategiephase entwickelten Migrationsszenarios - beginnt die Designphase. Sie behandelt beispielsweise die Detailplanung für die Konsolidierung von ERP- und CRM-Systemen. Dabei sind jeweils die Ressourcen-, Zeit- und Kostenpläne sowie die Mengengerüste für Services, Server sowie Standort- und Netzstrukturen zu erarbeiten.

Aus diesen Informationen lassen sich dann die zu erwartenden laufenden Kosten sowie die Investitions- und Transitionsaufwände für Infrastruktur, Ausschreibungen und Personal ableiten. Es ist sinnvoll, unterschiedliche Szenarien im Hinblick auf Qualität, Flexibilität und Grad der Zielerreichung für die Geschäftsanforderungen zu entwickeln und zu bewerten.

In dieser Phase lassen sich über alle Teilprojekte hinweg technische Synergiepotenziale identifizieren (zum Beispiel durch Hardwarevirtualisierung). Das kann in eine Aggregation von Funktionen und/oder eine Konsolidierung von Systemplattformen münden.

Im besten Fall wurde schon in der Strategiephase festgestellt, welche Applikationen welche Kerngeschäftsprozesse unterstützen. Um Redundanzen und Komplexität zu verringern, sollte in der Zielarchitektur die jeweilige Anwendung möglichst nur noch einen Kerngeschäftsbereich, auch IT-Domäne genannt, unterstützen (hierzu siehe auch: "Vom Manufakturmodell zur industrialisierten IT").

Während der Designphase werden technische Lösungen grundsätzlich so erarbeitet, dass sie die Geschäftsanforderungen möglichst gut abbilden. Im Hinblick auf eine effektive und effiziente Implementierung der IT-Systeme sollten aber nicht nur die Anforderungen des Managements (top-down) durchgesetzt, sondern auch alle IT-Blueprints (bottom-up) mit den Fachbereichen abgestimmt werden.

Aufgrund zeitlicher Rahmenbedingungen bleibt dieses Vorgehen aber oft Theorie. Wenn dann die Einarbeitungszeit beginnt oder das neue System operativ genutzt werden soll, heißt es plötzlich, im Vorfeld sei nicht ausreichend diskutiert worden, und das alte System funktioniere sowieso besser. Um einer solchen Generalkritik zu entgehen, ist es am besten, frühzeitig Key-User zu benennen und eng in das Vorhaben einzubeziehen.

Wie lassen sich strenge Zeitpläne am besten einhalten?

Ein strukturiertes Framework inklusive Checklisten und Best Practices ist für einen reibungslosen Projektfortgang unverzichtbar. Ein weiterer Handlungsgrundsatz besteht darin, sich auf die Kernaufgaben zu konzentrieren und nicht zu versuchen, alle Randbereiche optimal abzudecken. Nur so lassen sich Komplexität und zeitliche Restriktionen unter einen Hut bringen. Jeder Merger schließt diverse Aktivitäten ein, auf die sich leicht viel Kapazität verwenden lässt, ohne dass dadurch das Gesamtergebnis nachhaltig besser würde. Deshalb muss die Projektleitung einschätzen können, welche IT-Ausfälle sich wie auf die Unternehmensmarken auswirken. Beispielsweise ist das Web-Portal im Gegensatz zum Personalbuchhaltungssystem für eine Bank extrem geschäftskritisch. Ein Personaldienstleister hingegen könnte einen Tag lang keine Vermittlungsarbeit leisten, wenn er nicht in der Lage wäre, Arbeitsaufträge zu buchen.

Generell lassen Commodity-Komponenten wie File-Server, E-Mail, SAP-Datenbanken oder Middleware keinen konkreten Wertbeitrag erwarten. Hier kann systematisch standardisiert und konsolidiert werden. Für wettbewerbsdifferenzierende Funktionen wie CRM- und SCM-Systeme sollten dagegen die Top-down- und die Bottom-up-Anforderungen umfassend durchdacht und umgesetzt werden, um die bestmögliche Systemkonfiguration sicherzustellen.

Inwiefern sind Workarounds in der Transitionsphase erlaubt?

Am Ende einer idealen Designphase existieren spezifische IT-Blueprints mit Schnittstellendefinitionen und Umsetzungsplänen für alle Transformationsprojekte. Die darauf folgende Transitionsphase widmet sich der Realisierung. Wurden in den vorhergehenden Phasen keine signifikanten Fehler gemacht, lässt sich die Umsetzung relativ einfach anhand der vorhandenen Struktur abarbeiten. Vor allem ein Carve-out ist auf diese Weise standardisiert und effizient umzusetzen.

Doch in der Realität ist es aufgrund enger zeitlicher und finanzieller Rahmenbedingungen oft nötig, die funktionale Leistungsfähigkeit der Ziellösungen zu beschneiden. Realisiert werden dann einfachere beziehungsweise billigere Lösungen als "Workaround".

Leider tendieren solche - zunächst als provisorisch gedachten - IT-Systeme dazu, sich zu institutionalisieren; sie werden dann mittelfristig weitergenutzt. Die Verantwortlichen sollten sich jedoch darüber im Klaren sein, dass das Gefahren birgt. Infolge neuer Geschäftsanforderungen müssen irgendwann mit hoher Wahrscheinlichkeit die Nachteile dieser Workarounds kompensiert werden - und verursachen dann möglicherweise hohe Investitionsaufwände. Hier heißt es, die Vor- und Nachteile der Billiglösung nicht nur kurzfristig zu betrachten. (qua)

Kommentar