Was eine Übernahme mit der Systemlandschaft macht
Das übernommene Unternehmen bringt einen funktionierenden operativen Stack mit. Es verfügt über ein eigenes ERP, eigene Lager- und Produktionssysteme, ein eigenes Reporting und Mitarbeiter, die wissen, wie alles zu bedienen ist. Nichts davon hört am Tag des Abschlusses auf zu funktionieren.
Was jedoch nicht mehr funktioniert, ist alles, was darüber liegt. Die Konzernfinanzabteilung kann zwei Kontenpläne nicht konsolidieren, die nie für eine Abstimmung ausgelegt waren. Der Einkauf kann die kombinierten Ausgaben bei einem Lieferanten, den beide Unternehmen nutzen, nicht einsehen. Niemand kann sagen, wie hoch der Gesamtbestand eines gemeinsamen Bauteils in der Gruppe ist, da jedes System es unter einer anderen Artikelnummer führt.
Dies sind keine technischen Fehler. Jedes System ist in sich korrekt und berichtet präzise über seinen eigenen Geschäftsbereich. Das Problem ist, dass die Gruppe nun eine wirtschaftliche Einheit, aber zwei Datenlandschaften ist, und nur die erste davon ist für den Vorstand sichtbar.
Warum dauert die Post-Merger-Integration so lange?
Migrationsarbeit wird durch Prozessunterschiede begrenzt, nicht durch das Datenvolumen. Die Überführung des übernommenen Unternehmens in das ERP der Muttergesellschaft erfordert die Einigung auf einen Kontenplan, ein Artikelnummernsystem, einen Kundenstamm und einheitliche operative Prozesse. Jeder dieser Punkte ist eine Verhandlung zwischen Teams, die beide bereits funktionierende Lösungen haben.
Der Zeitplan dehnt sich weiter aus, wenn das übernommene Unternehmen operativ anders aufgestellt ist. Ein Mutterkonzern, der auf Lager produziert, und eine Übernahme, die auftragsbezogen fertigt, haben keine gemeinsame Konfiguration, die nur darauf wartet, gefunden zu werden. Einer der beiden muss seine Arbeitsweise ändern, und das ist ein Change-Management-Projekt und keine reine Datenmigration.
Währenddessen darf das Geschäft nicht stillstehen. Aufträge müssen versendet, Monatsabschlüsse erstellt und Kunden während eines Übergangs, den sie nicht angefordert haben, weiterhin bedient werden. Das ist der gleiche Grund, warum ERP-Modernisierung in Phasen und nicht als einzelner Cutover erfolgt, und eine Übernahme fügt dem Ganzen noch den Widerstand einer zweiten Organisation hinzu.
Die Kosten des Wartens auf ein einheitliches System
Der Standardplan macht den Wert der Übernahme von einem Migrationsdatum abhängig. Die Kosten dafür, in etwa der Reihenfolge, in der sie die Gruppe spürt:
- Manuelle Konsolidierung bei jedem Abschluss: die Finanzabteilung gleicht jedes Quartal zwei Kontenpläne manuell ab, bis das zweite ERP abgeschaltet ist
- Einsparungen, die ungenutzt verfallen: gebündelte Einkaufsmacht bleibt ungenutzt, während Lieferantenverträge zu alten Konditionen verlängert werden
- Führungskräfte gebunden: langwierige Konsolidierungsprogramme binden genau das operative Personal, das das Tagesgeschäft benötigt
- Wissen geht verloren: die Fluktuation steigt, während das übernommene Unternehmen weder vollständig unabhängig noch vollständig integriert ist, und die ausscheidenden Mitarbeiter kannten die Systeme
- Vertrauensverlust im Vorstand: jedes Quartal mit manuell abgeglichenen Zahlen macht es schwieriger, den Business Case für die Übernahme zu rechtfertigen
Die Verbindung zuerst herzustellen, kehrt die Reihenfolge um. Das Berichtswesen funktioniert frühzeitig, die Entscheidung zur Konsolidierung kann in Ruhe auf Basis der Fakten getroffen werden, und in manchen Fällen stellt die Gruppe fest, dass es sich lohnt, das zweite System beizubehalten.
Was eine Post-Merger-Integration zuerst leisten muss
Das meiste, was im Business Case versprochen wurde, erfordert gar kein einheitliches System. Es erfordert lediglich gemeinsame Daten über beide Systeme hinweg.
- Konsolidiertes Finanzberichtswesen: zugeordnete Kontenstrukturen, die in eine gemeinsame Konzernsicht einfließen, ohne auf einen einheitlichen Kontenplan warten zu müssen
- Kombinierte Lieferantenausgaben: Einkaufsdaten beider Einheiten, normalisiert auf einen gemeinsamen Lieferantenstamm, denn genau dort entstehen die ausgehandelten Einsparungen
- Bestandstransparenz im Konzern: gemeinsame Komponenten, die über zwei Nummerierungssysteme hinweg abgeglichen werden, damit Lagerbestände der einen Einheit den Bedarf der anderen decken können
- Kundenüberschneidungen: eine Übersicht der Konten, die bereits von beiden Unternehmen beliefert werden, also dort, wo in der Regel die Synergien für Cross-Selling kalkuliert wurden
- Gemeinsame Stammdaten: eine abgestimmte Definition der relevanten Entitäten, die einmal festgelegt und auf beide Systemlandschaften angewendet wird
Jeder dieser Punkte lässt sich innerhalb weniger Wochen umsetzen, ohne dass bestehende Systeme verändert werden müssen. Das ist wirtschaftlich entscheidend, da Synergien am Zeitplan der Transaktion gemessen werden und nicht an der IT-Roadmap.
Wie eine Integrationsplattform mehrere Einheiten verbindet
Die Alternativen sind erwähnenswert, da jede von ihnen ihre Berechtigung, aber auch ihre Grenzen hat. Ein Data Warehouse kann Berichte konsolidieren, ohne in den operativen Betrieb einzugreifen, was zwar die Fragen des Vorstands beantwortet, aber nicht bei der täglichen Nutzung gemeinsamer Bestands- oder Lieferantendaten hilft. Punkt-zu-Punkt-Verbindungen zwischen zwei ERP-Systemen lösen zwar einen spezifischen Datenfluss, vervielfachen sich jedoch mit steigendem Bedarf. Die manuelle Konsolidierung in Tabellenkalkulationen ist das, was die meisten Konzerne tatsächlich tun; sie skaliert jedoch mit der Anzahl der Mitarbeiter und nicht durch technologische Unterstützung.
Eine Integration Platform-as-a-Service (iPaaS) fungiert als Bindeglied zwischen beiden Landschaften und ermöglicht deren Weiterbetrieb, während die gemeinsamen Daten zwischen ihnen ausgetauscht werden. Das wirft eine berechtigte Frage auf: Wenn zwei Einheiten nun eine gemeinsame Ebene nutzen, gefährdet dann eine Migration in der einen Einheit die andere?
Die Antwort hängt davon ab, wie diese Ebene strukturiert ist, und genau das ist das Problem, das das Multi-Entity-Modell löst. Alumio Spaces für Unternehmensgruppen bietet jeder Einheit eine eigene, isolierte Umgebung, während das zentrale Team den Überblick über die gesamte Gruppe behält. Auf der Alumio iPaaS bewirkt diese Struktur für eine Gruppe mitten in der Integration vier Dinge:
- Isolation der Einheiten: jedes Unternehmen arbeitet in seinem eigenen Space mit einer dedizierten Data Engine, sodass eine ERP-Migration oder ein Replatforming innerhalb einer Einheit die anderen nicht destabilisieren kann
- Einheitliche Definition für die gesamte Gruppe: ein Transformer normalisiert Artikelnummern und Lieferantendatensätze während der Übertragung, sodass eine gemeinsame Komponente für beide Einheiten erkennbar ist, ohne dass eines der Systeme angepasst werden muss
- Zentrale Aufsicht und Audit-Trail: Echtzeit-Status- und Gesundheitsüberwachung pro Space in einem Dashboard, inklusive Protokollierung der Datentransfers zwischen den Einheiten, damit die Intercompany-Abstimmung jederzeit nachvollziehbar bleibt
- Phasenweise Einführung mit Gruppenstandards: eine neue Einheit wird innerhalb von Minuten mit eigenen Umgebungen und rollenbasiertem Zugriff bereitgestellt, wobei bei Übereinstimmungen gemeinsame Vorlagen und bei Abweichungen lokale Konfigurationen genutzt werden
Diese Abläufe werden konfiguriert, anstatt sie für jedes Systempaar manuell zu programmieren. Sollte eine Regel nicht über die Konfiguration abbildbar sein, steht der Code Transformer zur Verfügung. Die nächste Akquisition wird einfach an das bereits Bestehende angebunden.
Post-Merger-Integration, die mit jedem Mal günstiger wird
Konzerne, die regelmäßig Unternehmen akquirieren, hören auf, Konsolidierung als Selbstläufer zu betrachten. Sie binden die neue Einheit schnell an, etablieren Reporting und Datenaustausch und entscheiden dann System für System, ob sich eine Migration wirtschaftlich lohnt. Manchmal ist sie sinnvoll, manchmal betreibt ein zugekauftes Unternehmen jedoch ein System, das besser zu seinen operativen Anforderungen passt als das der Muttergesellschaft.
Das definiert den Zweck der Integrationsschicht neu. Sie ist keine Brücke mehr, die nach Abschluss der Migration abgerissen wird, sondern wird zum dauerhaften Ort, an dem Unterschiede auf Unternehmensebene zu einer Sicht auf Konzernebene zusammengeführt werden.
Der Konzern profitiert davon durch ein Berichtswesen, das bereits im ersten Quartal und nicht erst im zweiten Jahr vor dem Vorstand Bestand hat. Einkaufsvorteile werden realisiert, solange sich die Neuverhandlung von Lieferantenverträgen noch lohnt. Und für einen durch Zukäufe wachsenden Konzern wird die Integration jedes weiteren Unternehmens kostengünstiger. Die Schicht, an die das vorherige Unternehmen angebunden wurde, steht bereits, wenn das nächste hinzukommt.
.svg)
.svg)
.svg)
.svg)
.svg)
.svg)
.svg)
