Die Akquisitions-Schuld: acht Standorte, 25.000 Artikel, ein schmaler Konnektor.

Eine europäische Bootsbaugruppe hat ihre IT-Modernisierung nach Lehrbuch durchgeführt - Cloud-ERP nah am Standard gehalten, ein PLM als Stammdatensystem für Produktdaten, eine echte zentrale IT-Organisation. Und ist trotzdem an eine Wand gestoßen. Denn die schwierigsten Datenprobleme leben in keinem System. Sie leben dazwischen.

Ein Unternehmen, das die Modernisierung richtig angeht

Dies ist nicht die Geschichte eines Unternehmens, das seine IT vernachlässigt hat. Die Gruppe - rund 800 Mitarbeitende an über acht Standorten, schnell durch Akquisitionen gewachsen - hatte drei Jahre damit verbracht, aufzubauen, was den meisten ihrer Wettbewerber noch fehlt: eine echte zentrale IT-Organisation, gehärtete Sicherheit, moderne Infrastruktur und ein unternehmensweites Transformationsprogramm.

Auch die Zielarchitektur war mustergültig: SAP S/4HANA Public Cloud als zentrales ERP, bewusst nah am Standard gehalten; ein führendes PLM, vorgelagert positioniert als Stammdatensystem für Produktdaten; ein klares Prinzip der digitalen Durchgängigkeit - Daten werden einmal erzeugt, leben in ihrem Stammsystem und werden von dort ohne Duplizierung genutzt. Rund 600 Anwender, bis hinunter in die Produktion, arbeiten täglich im ERP.

Und dennoch hakte der Rollout immer wieder. Nicht an den Systemen - an dem, was die Akquisitionen hinterlassen hatten, und an allem, was fließen muss zwischen den Systemen.

Bruchstelle Nr. 1

Jede Akquisition brachte ihre eigene Wahrheit mit

Wachstum durch Akquisition ist ein Datenereignis, nicht nur ein finanzielles. Jedes übernommene Unternehmen kam mit eigenen Systemen, eigenen Artikelnummern, eigenen Lieferantenstammsätzen - und niemand führt Stammdaten in der Hitze eines Deals zusammen. Das Ergebnis, Jahre später: ein Artikelstamm von rund 25.000 Artikeln, durchsetzt von Dubletten, und ein Lieferantenstamm im selben Zustand. Dasselbe physische Teil existiert mehrfach, unter verschiedenen Nummern, an verschiedenen Standorten.

Der Schaden ist still, aber kumulativ: Der Einkauf sieht sein echtes Volumen pro Lieferant nicht, Bestand liegt an einem Standort, während ein anderer dasselbe Teil nachbestellt, und jede Zahl auf Gruppenebene ist eine Aggregation von Datensätzen, die nie abgeglichen wurden. Dies in ein sauberes neues ERP zu migrieren, behebt es nicht - es importiert es.

Bruchstelle Nr. 2

Ein Teil, zwei legitime Wahrheiten

Selbst wo die Dubletten aufgelöst sind, bleibt ein subtileres Problem - und dieses lässt sich nicht wegputzen, weil niemand im Unrecht ist.

Das Problem in einem Bild
Nehmen wir ein Deckspaneel aus Verbundwerkstoff. Die Konstruktion klassifiziert es danach, was es ist: ein strukturelles Verbundbauteil, in einer technischen Familie neben Rümpfen und Schotten. Der Einkauf klassifiziert es danach, wie es beschafft wird: es landet unter Deckbeschlägen, mit der Lieferanten- und Warengruppenlogik, die diese Kategorie impliziert. Beide Klassifikationen sind korrekt - für ihren Zweck. Eine Abteilung zu zwingen, die Logik der anderen zu übernehmen, zerstört eine davon. Also wird eine zweite, parallele Hierarchie von Hand aufgebaut und gepflegt, für immer.

Das ist die Falle der Standardisierung: sich auf die eine richtige Klassifikation einigen zu wollen, wenn die eigentliche Anforderung lautet, dass mehrere korrekte Sichten auf dasselbe Objekt nebeneinander bestehen - aufeinander abgebildet, nicht ineinander plattgedrückt. Harmonisierung statt Standardisierung. Die meisten Stammdatenprojekte scheitern genau daran, dass sie das Plattdrücken versuchen.

Konstruktion und Einkauf haben beide recht. Die Architektur muss das zulassen.

Bruchstelle Nr. 3

Ein einziger schmaler Konnektor - und eine Decke, durch die man nicht anpassen kann

Zwischen PLM und ERP saß genau eine Integration: ein fest verdrahteter Konnektor, der Artikel, Stücklisten und Arbeitspläne in eine Richtung transportierte. Notwendig - und bei Weitem nicht ausreichend. Das Unternehmen brauchte Flüsse, die der Konnektor schlicht nicht abdeckt:

• Daten, die zurückfließen. Echte Einkaufspreise und Live-Bestände gehören vor die Augen der Ingenieure im PLM - Konstruktionsentscheidungen werden gegen Zielpreise getroffen, die die Beschaffungsrealität längst überholt hat. Der Konnektor fließt nur in die andere Richtung.
• Jede angrenzende Domäne, ihre eigene Schnittstelle. Zeitwirtschaft, Instandhaltung, Produktionsrückmeldungen, Lagerstatus - jede braucht ihre eigene Punkt-zu-Punkt-Verbindung, jede mit eigener Logik, jede bei jedem Upgrade neu getestet. Konnektor-Wildwuchs, eine gut gemeinte Schnittstelle nach der anderen.
• Eine Fertigung, die um ihre eigenen Werkzeuge herumarbeitet. Die vom Integrator gebauten Schnittstellen für die Produktionsrückmeldung waren so umständlich, dass die Menschen, die sie nutzen sollten, sie mieden - und die Datenqualität zeigte es.

Der klassische Ausweg ist per Design versperrt: ein Public-Cloud-ERP begrenzt bewusst tiefe Anpassungen. Das ist die richtige Entscheidung - sie hält Upgrades sicher - aber sie bedeutet, dass die Lücken nicht innerhalb des ERP geflickt werden können. Also wurden sie am einzig verbliebenen Ort geflickt: Excel. KPIs wurden durch manuelle Extraktion und Makros zusammengestellt - langsam, fragil, undokumentiert und abhängig von der Handvoll Menschen, die wissen, wie die Makros funktionieren. Das Reporting der Gruppe lief auf kritischer Infrastruktur, die in Tabellen lebte.

Die Landschaft mit dem schmalen Konnektor: ein gesteuerter Fluss, und alles andere drumherum improvisiert.

Ein moderner Kern sauber gehalten - und die Komplexität verschwand nicht. Sie verlagerte sich in die Lücken zwischen den Systemen.

Der Ausweg

Kein größerer Konnektor. Eine Schicht zwischen allem.

Keines dieser Probleme wird innerhalb des ERP oder des PLM gelöst - sie alle leben zwischen den Systemen. Deshalb ist die Antwort kein breiterer Konnektor, mehr Schnittstellen oder ein Data Lake voller Kopien. Es ist eine einzige Integrationsschicht oberhalb der Systeme, die fünf Aufgaben auf einmal erfüllt:

• Die Dubletten auflösen - schrittweise, in der Schicht. Die 25.000 Artikel werden gegen eine harmonisierte Referenz abgeglichen: der Großteil automatisch, der Rest durch geführte Prüfung. Die Standorte behalten ihre lokalen Nummern; die Gruppe gewinnt eine Identität pro Teil und pro Lieferant - keine Big-Bang-Bereinigung, keine erzwungene Neucodierung.
• Beide Wahrheiten nebeneinander bestehen lassen. Die technischen Familien der Konstruktion und die Warengruppenlogik des Einkaufs werden zu zwei gesteuerten Sichten, die auf dieselben Objekte abgebildet sind - einmal an einer Stelle gepflegt, statt als parallele, von Hand gepflegte Hierarchien.
• Flüsse bidirektional und gesteuert machen. Stücklisten fließen ins ERP; echte Preise und Bestände fließen zurück zur Konstruktion. Richtung, Zuständigkeit und Konfliktregeln sind explizit - Daten bleiben in ihrem Stammsystem, genau wie es das gruppeneigene Prinzip der digitalen Durchgängigkeit verlangt.
• Die Logik aus den Tabellen herausnehmen - ohne sie ins ERP zu legen. Die in Excel-Makros lebende KPI- und Integrationslogik wandert in die Schicht: dokumentiert, reproduzierbar, nicht länger an den Release-Zyklus des ERP oder an die drei Menschen gebunden, die die Makros verstehen. Das Cloud-ERP bleibt Standard - was der Sinn der Sache war.
• Der Fertigung Schnittstellen geben, die die Menschen tatsächlich nutzen. Aufgabenorientierte Apps auf Tablet, Smartphone oder Terminal sitzen auf der Schicht und schreiben in das richtige darunterliegende Kernsystem zurück - die UX von den Systems of Record entkoppelt.

Und die nächste Akquisition - es wird eine geben - ist keine Datenkrise mehr: Die Systeme des neuen Unternehmens werden einmal mit der Schicht verbunden und auf dieselbe harmonisierte Referenz abgebildet, statt der Halde weitere tausend Dubletten hinzuzufügen.

Die Lektion lässt sich übertragen

Das Paradox des sauberen Kerns

Hier kommt der Teil, der weit über den Bootsbau hinaus verallgemeinerbar ist: Je disziplinierter Sie Ihre Kernsysteme im Standard halten, desto mehr brauchen Sie einen eigenen Ort für alles, was nicht hineinpasst. Systemübergreifende Identitäten, koexistierende Klassifikationen, bidirektionale Flüsse, gruppenweite KPIs, Fertigungs-UX - nichts davon gehört in ein Standard-ERP, und es dennoch hineinzuzwingen ist, wie technische Schulden entstehen.

Die Warnsignale, nach denen Sie in Ihrer eigenen Landschaft suchen sollten: ein durch Akquisitionen aufgeblähter Artikel- oder Lieferantenstamm; parallele, von Hand gepflegte Klassifikationshierarchien; ein einziger fester Konnektor, der nur einen Bruchteil dessen transportiert, was tatsächlich fließen muss; und Excel-Makros, die still und leise zu kritischer Infrastruktur geworden sind. Jedes davon ist eine Lücke zwischen Systemen - und eine Schicht zwischen den Systemen ist das, was sie schließt. Genau dafür ist die boTec DataBridge gebaut.