28.10.2017 | Alexander Jung
Merger, Akquisitionen, Carve-outs – Wie Unternehmen ihre IT-Systeme transformieren
1. Einleitung
Bei Mergers, Acquisitions, Buy-outs und Carve-outs stehen Unternehmen nicht nur vor großen organisatorischen und prozessualen Veränderungen und vor der Aufgabe, ihr Personal motiviert zu halten. Sie stehen auch immer vor einer erheblichen IT-Herausforderung. Nicht mehr nur betriebswirtschaftliche und unternehmensstrategische Aspekte sind bei der Überlegung eines Kaufs oder einer Akquisition wichtig, sondern zunehmend auch die Frage, wie die bestehende IT übernommen bzw. integriert werden kann.[1. Johanning: IT-Strategie: Optimale Ausrichtung der IT an das Business in 7 Schritten, Wiesbaden, 2014, S.25.] Die Systeme und Prozesse rund um Warenwirtschaft, Kundenbeziehungen und Finanzen – um nur einige zu nennen – müssen an die neue Unternehmensgröße, Organisation und möglicherweise an die neuen Reporting- und Rechnungslegungsvorgaben angepasst werden. Die Königsdisziplin ist dabei die Bereitstellung und das Handling der Daten und der Datenhistorie in den Systemen.
Mit dem Closing des Deals fängt die Arbeit IT-seitig erst an. Das neue Unternehmen wird nur dann ab „Day One“ erfolgreich agieren können, wenn es die relevanten rechtlichen, organisatorischen und IT-technischen Anforderungen bedacht, konsequent umgesetzt und die Mitarbeiter darauf vorbereitet hat. Die IT-Abteilung steht zum Beispiel vor den Herausforderungen, ganz unterschiedliche Prozesswelten und -infrastrukturen miteinander zu verschmelzen, Unternehmen auf der Ebene von Buchungs-/Kostenrechnungskreisen zu entflechten und die historischen Daten bereitzustellen. Je größer das Unternehmen ist, umso öfter geht es dabei um SAP-Systeme. Ob die Veränderungen erfolgreich verlaufen, ist stark davon abhängig, wie Unternehmen die Umstellung planen und durchführen.[2. Siehe dazu Schwarze, Röscheisen, Mengue: IT-Integration im Kontext von Unternehmensfusionen. In: HMD Praxis der Wirtschaftsinformatik, Volume 44, Issue 5, 2007, S.55-66.]
2. Greenfield-, Brownfield- und Blackfield-Ansatz
Bei der Transformation der Hard- und Software können Unternehmen aus unterschiedlichen Ansätzen für den Aufbau des neuen Systems wählen. Dabei werden die Ansätze Greenfield-, Brownfield- und Blackfield unterschieden. Mit jedem dieser Ansätze sind bestimmte Vor-, aber auch Nachteile verbunden.
2.1 Greenfield
Erstellt das neue Unternehmen seine Zielsysteme auf der „grünen Wiese“ (Greenfield) komplett neu, so ergibt sich die Möglichkeit, die Prozesse und Daten optimal auf die Unternehmensstrategie und neuen Anforderungen auszurichten. Doch die Einführung und Konfiguration neuer Systeme kostet viel Zeit. Und da sich Strukturen und Datenformate ändern (unter anderem wegen des Einsatzes neuerer Software-Releases), geht mit dem Greenfield-Ansatz immer ein teilweiser oder auch kompletter Verlust der Datenhistorie einher. Der Greenfield-Ansatz kommt oft in Carve-outs und gelegentlich bei Mergers zum Einsatz. Bei Akquisitionen ist es dagegen die Regel, dass die Systeme des auf kaufenden Unternehmens beibehalten werden.[3. Siehe dazu Juan Garcia, Begonha, Peyracchia: Two ways to modernize IT systems for the digital era. In: McKinsey on Business Technology, 2015, S.3-5.]
2.2 Blackfield
Wird der Blackfield-Ansatz gewählt, so können mehrere SAP-Mandanten parallel auf einem System betrieben werden. Dies erscheint bei einem ersten flüchtigen Blick einfach und kostengünstig wegen der gemeinsamen Nutzung eines SAP-Systems. Der Blackfield- Ansatz eignet sich vor allem für Carve-outs, weil dem neuen Unternehmen auf diese Weise neue Systeme schnell zur Verfügung stehen. Bei genauerer Betrachtung und Bewertung erhöht sich jedoch die technische Abhängigkeit der Mandanten voneinander. Und der Aufwand bei Veränderungen steigt verglichen mit dem Betrieb separater Systeme, beispielsweise wegen der gemeinsamen Downtime und „Frozen Zones“ (siehe unten). Auf Dauer kann eine Entscheidung für den Blackfield-Ansatz ineffiziente Prozesse für ein kleines Unternehmen bedeuten und damit langfristig hohe Folgekosten verursachen.
2.3 Brownfield
Nutzt eine neue Firma eine 1:1-Kopie des Systems der Muttergesellschaft (Brownfield) – dies ist der klassische Ansatz bei Carve-outs –, so entfällt der Konfigurationsaufwand weitgehend. Die Datenformate müssen nicht angefasst werden und für die Mitarbeiter entsteht kein zusätzlicher Trainingsbedarf. Aber der Aufwand, den relevanten Datenbestand für das Unternehmen bereitzustellen, bleibt bestehen. Denn hier müssen in der Regel im Nachgang Daten gelöscht werden. Wichtig ist es aber vor allem zu prüfen, ob die kopierten Prozesse für die neue Firma passen.[4. Vgl. Meyer, Estrin: Brownfield Entry in Emerging Markets. In: Journal of International Business Studies, 2001, Volume 32, Issue 3, S. 575-576.] Die bisher vorhandenen Prozesse könnten für das neu entstehende kleinere Unternehmen eine Nummer zu groß sein. Für dieses macht es häufig keinen Sinn, in der Finanzbuchhaltung wie in einem Weltkonzern zu arbeiten. Das zeigt sich dann etwa darin, dass man die Rechnungslegung nur noch nach einem System, zum Beispiel nach HGB und nicht mehr nach US GAAP oder IFRS, sicherstellen muss. Oft sind Änderungen ratsam, zum Beispiel die Löschung von Tausenden nicht mehr benötigter Konten, die aus dem ehemaligen Konzernkontenplan stammen.
3. Der Umgang mit den Daten und Datenhistorie
Das Handling der Daten bei der IT-Transformation eines Unternehmens ist immer ein Spagat. Das gilt unabhängig davon, ob Unternehmen verschmelzen oder sich aufspalten. Einerseits sind die Unternehmen darauf angewiesen, dass alle relevanten und aus juristischen Gründen unverzichtbaren Daten in dem neuen Unternehmen vorhanden und nutzbar sind. Zugleich dürfen bestimmte Daten aus rechtlichen Gründen eben nicht in allen beteiligten Systemen bereitgestellt werden. Die Daten, die vorhanden bleiben müssen, von denen zu unterscheiden, die nicht vorhanden bleiben dürfen, ist eine hochkomplexe Angelegenheit.
Selbst wenn hier alles richtig gemacht wird, wäre das rechtlich immer noch nicht ausreichend, weil der Prozess auch auditierbar sein muss. Zuverlässige Transformationssoftwaretools müssen also obendrein dafür sorgen, dass die relevanten Daten, wie auch die notwendige Datenhistorie in den Systemen, in denen diese zur Verfügung gestellt werden müssen, auch prüfungssicher zu Verfügung gestellt werden.
Als wäre das nicht schon schwierig genug, müssen Unternehmen Daten vereinheitlichen, konsolidieren und bereinigen. Dies geht angesichts heutiger Datenmengen nur anhand eines methodischen, standardisierten, planmäßigen Vorgehens und mithilfe eines weitgehend automatisierten Datenmappings. So werden die Datenmodelle aus unterschiedlichen Quellsystemen aufeinander referenziert. Eine der großen Herausforderungen dabei ist die Datenqualität.
Dies lässt sich am Problem von Dubletten veranschaulichen: Es ist zwar normal, dass zum Beispiel ein Debitor in mehreren der beteiligten Systeme als Stammsatz angelegt ist. Probleme bereiten aber die Dubletten, die bereits in den Ausgangssystemen vorhanden sind. Wenn der gleiche Debitor in einen System viermal und im anderen zweimal angelegt ist, so ist das Ergebnis eines automatisierten Mappings kaum vorhersagbar. Dies kann nur gelöst werden, indem die Datenqualität schon vorab in den Quellsystemen optimiert wird. Dies stellt einen unerwünschten Zusatzaufwand in einer früheren Projektphase dar und wird daher oft übergangen. Doch der Schritt macht sich bezahlt, denn er reduziert später den Aufwand für das Mapping und für das Testing erheblich. Um Datensätze im Rahmen einer IT-Transformation zu vereinheitlichen, bedarf es professioneller Vorgehensweisen, zertifizierter Entwickler und Berater sowie spezialisierter Datentransformationstools.
4. Weitere Herausforderungen der IT-Transformation
Die schlechte Datenqualität in den Ausgangssystemen ist aber nur einer der Punkte, die die Beteiligten zu Beginn eines Mergers oder Carve-outs regelmäßig unterschätzen. Beispiele für weitere Herausforderungen sind Downtime, Eigenentwicklungen und die Frozen Zone, die in den folgenden Abschnitten erklärt werden.[5. Mehr zu M&A-Prozessen in Musil, Schalast: Due Diligence. In: Schalast, Raettig (Hrsg.): Grundlagen des M&A-Geschäfts, Frankfurt am Main, 2013.]
4.1 Downtime
Geplante Downtime ist die Zeit, in denen IT-Systeme nicht zur Verfügung stehen, zum Beispiel wegen Wartungsarbeiten, Softwareaktualisierungen oder Hardware- Migration. Jedes Unternehmen versucht, die Downtime geschäftskritischer Systeme möglichst kurz zu halten und sie zu Geschäftszeiten ganz zu vermeiden. Den Unternehmen, die vor einer IT-Transformation stehen, ist oft nicht klar, wie kurz die Zeitspanne ist, in der die IT-Systeme abgeschaltet werden können, um diese Transformation durchzuführen. Oft gibt es die Vorstellung, man könne an einem festgelegten Freitag um 18 Uhr (oder vor einem langen Wochenende) das System abschalten und habe dann bis Montag 8 Uhr Zeit, alle Änderungen durchzuführen und zu testen. Doch angesichts von Backup-Prozessen für Systeme und Geschäftstätigkeit in verschiedenen Zeitzonen (und mit unterschiedlichen Feiertagsregelungen) stehen oft weit weniger als 48 Stunden für die Datentransformation und Produktivsetzung der neuen Systeme zur Verfügung. Ein großes Unternehmen, das sich von einer kleinen Einheit trennt, wird selten eine Downtime zu Geschäftszeiten tolerieren.
Das bedeutet im Umkehrschluss: Die Projekte müssen akribisch geplant, die Cut-over-Planung detailliert vorbereitet und alle Beteiligten eindeutig und transparent informiert sein. Mit mehreren Testtransformationen muss sichergestellt sein, dass am Tag X wirklich alles wie am Schnürchen funktioniert.
4.2 Kundenindividuelle Eigenentwicklungen
Häufig ergänzen Unternehmen ihre IT-Systeme mit Eigenentwicklungen. Diese bieten oft mit relativ wenig Programmieraufwand unternehmensindividuelle Funktionen und Prozesse, die sich mit Standardsoftware nur schwer umsetzen lassen. Das Problem dabei im Zuge der IT-Transformation: Sie nutzen oft Festwerte (sogenannte „hard coded values“). Das heißt, sie sind auf statische Weise mit der vorhandenen Umgebung verbunden. Sie können nicht mit vertretbarem Aufwand in eine neue IT-Umgebung übernommen werden. Da die Eigenentwicklungen aber in der Vergangenheit und manchmal über Jahrzehnte hinweg die Unternehmensprozesse optimal unterstützt haben, geben die Beteiligten diese Systeme nur ungern preis.
Regelmäßig wird der Arbeitsaufwand unterschätzt, diese Programme fit für die Zukunft zu machen: IT-Spezialisten tüfteln wochenlang an einer Lösung für die neue Umgebung, die aber am Ende auch wieder nicht vollständig funktioniert und schließlich doch professionell entwickelter Standardsoftware weichen muss, die sich konfigurieren und integrieren lässt. Durch das Festhalten an Eigenentwicklungen verzögern sich viele IT-Transformationen stark. Spezialisten für IT-Transformationen können schnell feststellen, ob es sich lohnt, eine Eigenentwicklung weiterzuentwickeln, oder ob sie ersetzt werden muss.
4.3 Frozen Zone
Wie erwähnt, können es sich IT-Abteilungen und Unternehmen nicht leisten, dass am Tag der Migration etwas schiefgeht. Der Begriff „Frozen Zone“ beschreibt die Phase in einem Projekt, in der alle Tests erfolgreich verlaufen sind und keine Veränderungen an den Strukturen der Prozesse und Daten mehr vorgenommen werden dürfen. Mit dem Start der Frozen Zone bis zur Go Live Migration darf an den Systemen nichts mehr geändert werden, weil dies das Funktionieren des gesamten Unternehmens bedrohen könnte. Es muss garantiert sein, dass sich nach dem letzten Test keine neuen Strukturen oder Prozesse ergeben, die einen erneuten Test nötig machen würden. Wer sich mit IT-Transformation beschäftigt, weiß, wie delikat der Prozess des Datenmappings und der Datenmigration ist. Doch von anderer Seite wird oft unterschätzt, wie massiv die Folgen einer Missachtung der Frozen Zone sein können – in größeren Unternehmen bis hin zum Verlust von Tau senden von Arbeitsstunden. Es kommt immer wieder vor, dass Mitarbeiter die Frozen Zone nicht beachten, Änderungen vornehmen und damit die Migrationsprojekte gefährden. Es ist also zwingend, dass alle Mitarbeiter mit Zugriff auf die Systeme vom leitenden Management über die Bedeutung der Frozen Zone informiert werden und dass jegliche Systemänderungen während der Frozen Zone mit der Projekt und IT-Leitung abgestimmt werden.
5. Spezialexpertise und Spezialtools
5.1 Transformer
Die beschriebene Vielfältigkeit der Herausforderungen zeigt: Allenfalls wenige, sehr große Unternehmen, die regelmäßig Akquisitionen tätigen, können über IT-Spezialisten verfügen, die ausreichend Übung erlangt haben, diese Herausforderungen zu bewältigen. Alle anderen Organisationen sollten – wie in einschlägigen Rechts- oder Personalfragen auch – für die IT-Transformation externe Spezialisten für ihre Herausforderung finden: Diese IT-Berater, sogenannte „IT-Transformationsexperten“, wissen zum Beispiel, wie sie frühzeitig Wirtschaftsprüfer bei der Ausarbeitung der IT-Konzepte miteinbeziehen, wie sie zertifizierte Spezialtools zur Datenvereinheitlichung und -migration auswählen und einsetzen, wie sie zeitliche Vorgaben für die Umstellung einhalten, indem sie Prozesse rückwirkend anpassen, und wie sie Menschen zusammenbringen und in Workshops zu einer guten Zusammenarbeit motivieren. Die Annahme, erfahrene SAP- oder Prozessberater könnten eine solche Transformation alleine bewältigen, trügt. Nur wer viele solcher IT-Transformationsvorhaben begleitet hat, weiß genau, wie er methodisch vorzugehen hat und welche Schritte aufeinander folgen müssen.
5.2 Transformationstools
Transformationstools verbinden Beratungs-Know-how mit Software zur Planung, Strukturierung und professionellen Umsetzung von Transformationsprojekten. Sie erlauben es Unternehmen, ihre komplette Daten- und Beleghistorie in ein neues System mit neuen Prozessen mitzunehmen, und arbeiten mit den alten Informationen auf den neuen Prozessen und Systemen.
5.3 Projektmanagement für IT-Transformationen
Transaktionen verlaufen auf Dauer erfolgreich, wenn die verantwortlichen Manager diese nicht als reine Finanz- oder IT-Projekte behandeln, sondern ganzheitlich angehen und sich erfahrene Hilfe ins Projekt holen. Es braucht ein stringentes, durchgeplantes Vorgehen und eine erprobte Methodik, um das Potenzial des neu zugeschnittenen Unternehmens zu entfalten. Mit der richtigen Methodik lassen sich alle Klippen in Transformationsprojekten erfolgreich umschiffen. Wie das Beispiel der Datenbereinigung vor der Datenmigration zeigt, spart es oft sehr viel Zeit, wenn die richtigen Schritte in der richtigen Reihenfolge erfolgen. Anders gesagt: Die IT-Transformation ist eine Reise, auf der man keine Abkürzungen nehmen darf. Sehr wohl aber schnellere Transportmittel.[6. Vgl. Johanning: IT-Strategie: Optimale Ausrichtung der IT an das Business in 7 Schritten, Wiesbaden, 2014, S.37-38.]
6. Zusammenfassung
Dass Merger, Acquisitions und Carve-Outs auf vielen Ebenen Herausforderungen darstellen, ist bekannt. Im Gegensatz zu anderen Change-Prozessen ist die Transformation der IT aber davon geprägt, dass ein absolut strukturiertes Projektmanagement mit viel Erfahrung unverzichtbar ist. Fehler in einer frühen Projektphase lassen sich später nur unter erheblichem Zeitverlust und Kosten korrigieren. So kann es passieren, dass ein neues Unternehmen zeitweise ohne Zugriff auf Kundendaten, Buchhaltungsdaten oder ähnlich geschäftskritische Informationen dasteht. Das neue Unternehmen kann aber nur dann erfolgreich agieren, wenn die Daten produktiv nutzbar sind, es seine IT-Systeme perfekt auf die Unternehmensstrategie ausrichtet und es in der Lage ist, von Tag eins alle rechtlichen Anforderungen zu erfüllen und alle Abgrenzungen zum Kaufdatum korrekt vorzunehmen. Die Komplexität der Verschmelzung oder des Auseinanderdividierens von Systemen und Daten wird zu Beginn des Prozesses fast immer unterschätzt. Bewährte Methodiken und Best Practices helfen, das Ziel der „Day One Readiness“ ohne Abstriche zu erreichen.
