Integration von verschiedenen ERP-Systemen – aber wie?

Von den explodierenden Takata-Airbags und der entsprechenden Rückruf Aktion haben Sie wahrscheinlich schon gehört. Vielleicht fragen Sie sich, ob Sie nicht auch die ganze Zeit mit einem Takata-Airbag unterwegs sind.

Wie kam es eigentlich zu der Takata-Airbags Rückrufaktion? Tatsächlich führte eine einzige Unterkomponente in den vorderen Airbags zu dem, was die NHTSA als „den größten und komplexesten Sicherheitsrückruf in der Geschichte der USA“ bezeichnet.

Was Takata als globales Unternehmen zum Verhängnis wurde, war die Tatsache, dass weder Lieferanten noch Vertriebspartner sicher wussten, in welchen Airbags die fehlerhafte Komponente verbaut worden war. Öl ins Feuer schüttete dann noch einer der Mitbewerber von Takata, ein Hersteller von Sicherheitsausstattung für Fahrzeuge, mit dem „gut gemeintem“ Tipp, doch die gesamte Supply Chain mit über zehn verschiedenen ERP-Systemen richtig zu integrierten. Noch komplizierter wurde die Situation dadurch, dass das Unternehmen Material für Baugruppen herstellt, die dann zu anderen Baugruppen hinzugefügt werden – alles an unterschiedlichen Standorten. Diese Komponenten werden zudem von weiteren Herstellern verbaut.

Das folgende Sicherheits-Szenario soll den Umfang und die Reichweite dieses Problems verdeutlichen. Nehmen wir einmal an, bei einer Charge Chemikalien oder bei der Lieferung von Drahtspulen wird festgestellt, dass die Spezifikationen nicht erfüllt wurden und dass dies zu einem Fehler bei der fertigen Baugruppe führt. Materialien wie diese können potenziell für hunderttausende von Endprodukten verwendet werden. Dazu kommt, dass das Unternehmen sowohl Lieferant als auch Abnehmer der Unterbaugruppen ist, die zur Fertigung der Endprodukte (wie Seiten-Airbags) benötigt werden. Das bedeutet, dass das fragliche Material mehrere weltweite Fertigungsstandorte durchlaufen haben könnte und bereits an Endkunden geliefert wurde.

Um dieses Szenario umgehend in den Griff zu bekommen, müsste das Unternehmen schnell jede Unter- und Oberbaugruppe sowie alle Endprodukte, für die das verdächtige Material verwendet wurde, identifizieren können. Es müsste dann die betroffenen Komponenten weltweit ausfindig machen, um sie so lange aus der Supply Chain zu nehmen, bis ihre Qualität überprüft wurde. Dies ist heutzutage fast ein Ding der Unmöglichkeit, da Bauteile und Materialien anhand von E-Mails und Excel-Tabellen nachverfolgt werden. Dieses „Verfahren“ ist nicht nur fehleranfällig, sondern kann sich über Wochen hinziehen – und ob es am Ende zu irgendeinem Ergebnis führt, sei dahingestellt. Einfacher wäre dieser Prozess, wenn die ERP-Systemdaten integriert worden wären.

Fertigungsdaten lassen sich nicht einfach integrieren

Wie bei den meisten Herstellern erfasst jeder Standort eines Unternehmens umfassende Informationen über die Produktion und den Zusammenbau jeder Komponente bei jedem Schritt des Fertigungsprozesses. Die Daten variieren stark – von bestimmten Chargennummern der Chemikalien in einem Airbag-Auslöser, der Stromstärke beim Zusammenschweißen zweier Metallplatten und der Liste bestimmter Unterbaugruppen, die ein Endprodukt enthalten, bis hin zu den Containern, in denen der Versand erfolgte. All diese Informationen müssen sich nachverfolgen lassen, um die fraglichen Komponenten an jeder Stelle der Supply Chain in mehreren ERP-Systemen zu finden.

Unser Autohersteller erkannte, dass es nur wenige oder gar keine Möglichkeiten gab, Informationen schnell zwischen den verschiedenen Standorten auszutauschen, da die einzelnen Standorte oft Kennungen für Lagerkomponenten nach eigenen Katalogisierungsstandards speicherten. Der Hersteller einer Komponente könnte diese z. B. als „ABC-123“ katalogisieren, während der Abnehmer die gleiche Komponente (für die Montage) in seinem Katalog mit der Kennung „R79-P9777-Q“ einträgt. Um eine Komponente erfolgreich in der gesamten Supply Chain verfolgen zu können, müssten die Kennungen jedes Standorts übergreifend zuordenbar sein.

Das gesamte ERP-Warenwirtschaftssystem war betroffen

Dieses Problem wurde durch die Tatsache verschärft, dass die Standorte nach dem „Just-in-Time“-Prinzip fertigten. In keiner Anlage wurden die Produktionsanforderungen länger als drei Tage gespeichert, da Teile und Materialien ständig bewegt werden. Wenn die Zusammenstellung einer vollständigen Übersicht über die Komponenten-Historie länger als drei Tage dauert, dürfte diese zum Zeitpunkt der Fertigstellung bereits veraltet sein.

Angesichts der großen Zahl unabhängiger Anwendungen, die diese Informationen unternehmensweit verwalten, würde das Erstellen eines Berichts mindestens eine Woche dauern. Dafür müssten dann wahrscheinlich CSV-Dateien aus relationalen Datenbankanwendungen exportiert und Tabellen von einem Standort zum nächsten geschickt werden.

Um dieses Problem zu lösen, hätte das Unternehmen ein typisches Data-Warehouse-System implementieren können, das auf den vorhandenen relationalen Datenbanken basiert. Doch der damit verbundene unternehmensweite Koordinierungsaufwand, die Definition von Standardmodellen und die Implementierung der erforderlichen ETL-Funktionen führte dazu, dass man schließlich nach Alternativen suchte. Zudem verlangen Aufsichtsbehörden die Aufbewahrung der Daten für 20 Jahre, womit auch die langfristige Speicherung ein Thema war.

Dass MarkLogic Multi-Modell-Datenbanken unterstützt, war von Anfang an ein großer Pluspunkt. Der Kunde konnte so schnell mit dem Extrahieren der Daten aus relationalen Datenbanken beginnen und den Inhalt direkt in MarkLogic laden. Innerhalb von Wochen flossen in die erste MarkLogic-Anwendung Daten aus fünf Standorten, wobei pro Tag über 100.000 Dokumente eingelesen wurden. Beim Laden der Daten in eine Multi-Modell-Datenbank konnten wir Entitäten identifizieren. Als Entitäten werden für gewöhnlich erkennbare Konzepte wie Personen, Orte, Dinge oder Ereignisse bezeichnet, die für unser Geschäft und die Daten in einer Datenbank relevant sind. Die Daten werden ohne irgendeine Änderung in die Datenbank geladen – ohne per Shredding auf mehrere Tabellen verteilt zu werden, um sie bei Abfragen wieder zusammensetzen zu müssen.

Kontrolle über den Benutzerzugriff war entscheidend

Da die erfassten Daten größtenteils interne – geschützte Daten sind, musste die Anwendung einen sicheren Zugriff bieten. Zwar bietet MarkLogic eine robuste Funktion für die Benutzer-Authentifizierung und -Autorisierung, doch die Lösung der Wahl war dann die LDAP-Unterstützung von MarkLogic, um die Active-Directory-Datenbank des Kunden einzubinden. Auf diese Weise konnte der Kunde den Benutzerzugriff weiterhin mit dem vorhandenen IT-Team und bisherigen definierten Prozessen regeln.

Der Universal-Index von MarkLogic bot sofort eine Volltextsuche für die Dokumente. Kurz darauf wurde die Suche aber genau an die Kundenwünsche angepasst, um eine spezifischere Suche nach Teilenummern, Chargennummern, Dokumententypen u. ä. zu unterstützen.

Neben der Arbeit an der Suchfunktion entwickelten die Mitarbeiter des Kunden gemeinsam mit den Beratern von MarkLogic und eine dreistufige Anwendung, um auch Suchabfragen in AngularJS und Node.js, navigierbare Teilediagramme, die Berichterstellung und Datenexporte in andere Formate zu unterstützen. Dank der neuen Berichtfunktion kann jetzt auch die Frage „Wo ist diese Komponente?“ in Sekunden statt Wochen geklärt werden.

In der nächsten Phase will das Unternehmen die Verwendung von semantischen Triples testen, um wichtige Beziehungen herzustellen, die sich mit relationalen Systemen nur schwer – wenn überhaupt – herstellen lassen. Beispielsweise kann das Resource Description Framework (RDF)dazu dienen, Teile, Lieferanten, Standorte, Testausrüstung, Tests usw. verknüpfen, um die Beziehungen in der Praxis als Modell nachzubilden (z. B. als „enthaltenIn“, „verbautVon“, „geliefertVon“, „getestetAm“). Dies erlaubt ein wesentlich flexibleres Datenmodell (als eines RDBMS). Mit RDF können Sie interessante Fragen stellen, die die Multi-Modell-Funktionen von MarkLogic verwenden (Durchsuchen von Dokumenten während semantischer Abfragen und dem Verwenden von Interferenzen mit SPARQL).

Ein simpler Materialfehler breitete sich wie ein Virus weltweit aus – und Takata konnte ihn nicht nachverfolgen. Als Konsequenz hat der Automobilzulieferer ein System entwickelt, mit dem Mitarbeiter jede Komponente anhand der vollständigen Historie innerhalb der gesamten Supply Chain finden können, sollte irgendein Standort eine Warnung herausgeben.

Weitere Informationen

Building on Multi-Model Databases,(110 Seiten, Englisch) ist ein unverzichtbares Buch über Multi-Modell-Datenbanken, ihren sinnvollen Einsatz und inwiefern Unternehmen davon profitieren können.