Anatomie einer Datenkrise: 27 Systeme, ein Freitextfeld.

Ein europäischer Obst- und Gemüseexporteur ließ uns seine Datenlandschaft vor einem geplanten ERP-Wechsel kartieren. Was wir dabei vorfanden, ist es wert, geteilt zu werden - denn dieselbe Architektur, mit denselben Schwachstellen, steckt heute in den meisten mittelständischen Industrieunternehmen.

Ein ehrgeiziges Ziel auf brüchigem Fundament

Das Unternehmen ist ein erfolgreicher Exporteur frischer Erzeugnisse, mit einem Umsatz in Höhe von mehreren Hundert Millionen, beliefert von einem Netz aus Partnergenossenschaften. Die Führung hatte ein klares Ziel gesetzt - zuverlässige Echtzeitdaten, die das Geschäft bis 2030 steuern - und ein neues ERP war als Teil dieses Wegs geplant.

Doch bevor irgendein System geändert wurde, war die nützlichere Frage: Wie sieht die Landschaft heute eigentlich aus? Die Antwort: rund 27 separate Anwendungen, zusammengehalten von einer stetig wachsenden Excel-Schicht. Und im Zentrum, mit einer Aufgabe, für die es nie ausgelegt war, ein PLM-System als faktischer Produktdaten-Hub - per handgebauter ETL-Pipelines befüllt und entleert.

Schwachstelle Nr. 1

Der Artikelstamm: eine Datenbank in einem Textfeld

Das mit Abstand teuerste Problem der gesamten Landschaft war zugleich das unscheinbarste: die Produktstammdaten. Es gab keinen strukturierten Artikelcode. Alles, was ein Produkt definiert - Sorte, Kaliber, Kategorie, Herkunft, Verpackung - war in einem einzigen Freitext-Bezeichnungsfeld zusammengefasst, von Menschen eingetippt, von anderen Menschen interpretiert.

Die Folgen ziehen sich kaskadenartig durch alles Nachgelagerte. Sie können keine Marge je Sorte berechnen, wenn es „Sorte“ als Feld nicht gibt. Sie können die Lieferzeile einer Genossenschaft nicht mit Ihrem eigenen Bestand abgleichen, wenn die Artikelzeichenfolgen nicht übereinstimmen. Sie können nicht entduplizieren, was Sie nicht parsen können. Ein einziges unstrukturiertes Feld am Boden des Stapels macht jede Analyse an seiner Spitze klammheimlich ungültig.

Ein einziges Freitextfeld am Boden des Stapels macht jede Analyse an seiner Spitze ungültig.

Schwachstelle Nr. 2

Ein PLM in der Rolle eines Daten-Hubs, mit ETL als Klebstoff

Da es kein echtes Datenrückgrat gab, war das PLM-System in diese Rolle abgedriftet: Es hielt die Produktdaten, und handgebaute ETL-Pipelines schaufelten Kopien davon in das jeweils nächste System, das sie brauchte. Diese Architektur scheitert auf drei vorhersehbare Weisen:

• Jede Kopie beginnt im Moment ihrer Erstellung zu altern. ETL läuft in Batches; zwischen den Läufen arbeiten die Systeme mit den Daten von gestern. Abweichungen zwischen Systemen sind hier kein Versehen - sie sind in das Design eingebaut.
• Jedes neue System bedeutet neue Pipelines. Jede Anwendung verbindet sich Punkt-zu-Punkt mit mehreren anderen - das klassische n×m-Problem. Bei ~27 Anwendungen wächst die Zahl der Pipelines, und die Wartungsrechnung, schneller als die Landschaft selbst.
• Der Hub wird unersetzbar. Das PLM lässt sich nicht anfassen, ohne die daran hängenden Pipelines zu zerbrechen - genau jene Abhängigkeit, die Unternehmen von einer Plattform fürchten, hier versehentlich dadurch entstanden, dass es keine gibt.

Und überall dort, wo die Pipelines nicht hinreichten, tat es Excel. Am kritischsten am Rand des Unternehmens: Partnergenossenschaften lieferten ihre Daten als manuell erstellte Excel-Dateien - neu erfasst, neu formatiert, fehleranfällig, verspätet. Die Beschaffungsseite eines Geschäfts von mehreren Hundert Millionen Euro gelangte über Anhänge in dessen Systeme.

Was es kostet

Die Rechnung kommt im Bestand, in den Margen, in den Ruhestandsabgängen

Nichts davon bleibt ein IT-Problem. Es taucht als betriebswirtschaftliche Zahlen auf:

• Die Bestandsführung lief über manuelle Prozesse - und das Unternehmen selbst bezifferte die daraus resultierenden Fehlbestände und die ineffiziente Logistik auf rund 3 Millionen Euro pro Jahr.
• Die Führung konnte keine zuverlässigen KPIs gewinnen - Marge je Verkauf und Bestandsniveaus ließen sich nicht systemübergreifend konsistent erzeugen, sodass strategische Entscheidungen aus dem Bauch heraus getroffen wurden.
• Kritisches Wissen steckte in wenigen Köpfen. Die undokumentierte Logik, die die Landschaft überhaupt funktionieren ließ - welche Zeichenfolge welchen Artikel meint, welche Datei wohin gehört - lag bei einer Handvoll langjähriger Mitarbeiter kurz vor dem Ruhestand.

Das Problem in einem Bild

Das Problem in einem Bild
Fragen Sie drei Abteilungen nach dem Kaliber desselben Apfels, und Sie können drei verschiedene Antworten erhalten - der Einkauf stuft ihn zum Kaufen ein, die Produktion sortiert ihn, um die Linie zu fahren, der Vertrieb beschreibt ihn zum Verkaufen. Keine ist falsch; jede misst für ihren eigenen Zweck, in ihrem eigenen System. Der Apfel hat sich nie verändert. Die gemeinsame Definition gab es nie.

Der Reflex, und warum er scheitert

„Das neue ERP wird das in Ordnung bringen“

Da ein ERP-Wechsel bereits geplant ist, lautet die verlockende Schlussfolgerung, die Migration werde die Daten unterwegs reparieren. Wird sie nicht - und diese Landschaft zeigt genau, warum. Das neue ERP würde dieselben nicht parsbaren Artikelzeichenfolgen erben, dieselben nicht abgeglichenen Genossenschaftsdaten, dieselbe verwaiste ETL-Logik. Die Migration wird schwieriger, denn die Inkonsistenzen aus 27 Systemen auf einen neuen Kern abzubilden, ist genau die Arbeit, die noch niemand erledigt hat. Und danach gehört das Datenmodell des Unternehmens dem neuen Anbieter.

Die richtige Reihenfolge ist umgekehrt. Zuerst das Datenfundament bauen - oberhalb der Systeme, im Besitz des Unternehmens:

• Beginnen Sie mit dem Artikelstamm. Definieren Sie einen strukturierten Artikelcode mit expliziten Attributen - Sorte, Kaliber, Kategorie, Herkunft - und einen Governance-Workflow zum Anlegen und Ändern von Artikeln. Das ist bewusst der erste Schritt: Es ist die Wurzel, aus der sich jede andere Kennzahl ableitet.
• Ersetzen Sie den zufälligen Hub. Eine einzige Integrationsschicht übernimmt die Rolle, die das PLM und die ETL-Pipelines mit Mühe zu spielen versuchten: Jedes System verbindet sich einmal, und Daten werden an ihrer Quelle verknüpft, nicht kopiert - so altert nichts zwischen Batch-Läufen, und Abweichungen sind nicht länger eingebaut.
• Holen Sie die Genossenschaften ins Modell. Partnerdaten werden bei ihrem Eintreffen auf dieselben strukturierten Definitionen abgebildet, statt aus Tabellenkalkulationen neu erfasst zu werden.
• Kodieren Sie das informelle Wissen. Die Zuordnungslogik, die in den Köpfen der Menschen lebt, wird Teil des Modells - und überdauert die Ruhestandsabgänge.
• Migrieren Sie dann das ERP - in Ruhe. Das neue System dockt an ein Fundament an, das die Wahrheit bereits hält. Die darüberliegenden Geschäftsprozesse bewegen sich nicht. Und die nächste Migration nach dieser wird billiger, nicht schwieriger.

Ein neues ERP erbt Ihre Datenprobleme. Ein Datenfundament macht das ERP austauschbar.

Die Lehre lässt sich übertragen

Prüfen Sie Ihre eigene Landschaft auf diese vier Anzeichen

Die Details stammen hier aus dem Frischwarenbereich, doch die Architektur findet sich überall - in Chemie, Pharma, Maschinenbau, Energie. Nach denselben vier Anzeichen lohnt es sich, in Ihrer eigenen Landschaft zu suchen: ein kritisches Attribut, das in einem Freitextfeld steckt; ein System in der Rolle eines Daten-Hubs, das nie dafür ausgelegt war; Excel, das Daten über eine Organisationsgrenze hinweg trägt; and eine geplante Migration, von der erwartet wird, dass sie „die Daten unterwegs repariert“. Jedes Einzelne davon ist eine Warnung. Alle vier zusammen sind dieser Artikel.

Sie zu beheben ist kein Werkzeugkauf, und es muss nicht auf das nächste große Programm warten. Es beginnt mit einer strukturierten Definition eines kritischen Objekts - und einem Fundament oberhalb Ihrer Systeme, das jede spätere Änderung billiger macht. Genau dafür ist die boTec DataBridge gebaut.