Das lange PLM-Interim: ein Bauteil, zwei führende Systeme, kein Stichtag

Ein europäischer Mechatronik-Konzern löst das System ab, das seit zwei Jahrzehnten seine Entwicklungsdaten verwaltet - und der schwierigste Teil ist nicht die neue Plattform. Es sind die Jahre, in denen beide Plattformen gleichzeitig live sind. Die Gruppe hat das Programm nach Lehrbuch vorbereitet und ist trotzdem hineingetappt. Fast jeder, der Entwicklungsdaten migriert, tut das.

Eine Plattform, mehrere Entwicklungskulturen und ein Bibliothekar, den niemand abschalten kann

Die Gruppe vereint mehrere Industrieaktivitäten mit historisch gewachsenen, unterschiedlichen Entwicklungskulturen, Prozessen und spezialisierten Werkzeugen. Jede hat ihre eigenen Konstruktionsmethoden, ihre eigene CAD-Umgebung und ihre eigenen Referenzdaten entwickelt. Jahrelang wurden die Produktdaten in einem hauseigenen PDM-System gehalten, das neben SAP lief und faktisch als technischer Bibliothekar für CAD-Modelle und Zeichnungen fungierte.

Das Unternehmen führt nun eine einheitliche, hochflexible PLM-Plattform ein, um das Produktdatenmanagement über das gesamte Geschäft hinweg zu standardisieren. Das Ziel ist der vollständige V-Zyklus: Kunden- und Produktanforderungen, Systemarchitektur, Verifizierung und Validierung, Entwicklungs- und Fertigungsstücklisten sowie eine saubere Schnittstelle zum ERP. Die Governance ist vorbildlich - eine unabhängige Beratung für Engineering-Systeme wurde frühzeitig hinzugezogen, um die Anforderungen zu hinterfragen und die Zielarchitektur festzulegen, ein spezialisierter Integrator für die Konfiguration, agile Sprints mit gemessener Velocity und ein Business-Referent für jede Entwicklungsgemeinschaft, damit keine vom gemeinsamen Modell abweicht. Ein erstes Release steht wenige Wochen bevor.

Das Programm funktioniert. Was es jedoch ebenfalls offenbart hat, ist der Teil der Landkarte, den niemand gezeichnet hat: der Zustand, in dem das Unternehmen die nächsten Jahre tatsächlich leben wird.

Schwachstelle #1

Man kann eine Entwicklungsdaten-Migration nicht per Big Bang durchführen

Eine ERP-Umstellung kann an einem langen Wochenende erledigt werden. Am Freitag die Transaktionen einfrieren, den neuen Kern laden, am Montag eröffnen und zwei holprige Wochen durchstehen. Entwicklungsdaten verhalten sich nicht so. Ein Bauteil ist keine Zeile - es ist ein natives CAD-Modell mit Revisionen, Verknüpfungen zu anderen Modellen, einer Zeichnung, einer Änderungshistorie und einem Platz in Baugruppen, die heute noch gebaut und verkauft werden. Das Volumen und die technische Tiefe dieser Daten machen einen sauberen Schnitt unmöglich.

Die Gruppe tut also das, was jede Entwicklungsorganisation am Ende tut: Sie betreibt eine bidirektionale Master-Slave-Replikation zwischen dem alten PDM und dem neuen PLM und verschiebt Produktreihen eine nach der anderen. Nicht für ein Wochenende. Für Monate, die sich zu Jahren ausweiten.

Das macht den Übergangszustand schleichend zur eigentlichen Architektur. In ihr wird die Autorschaft über ein Objekt durch ein Datum bestimmt. Ein Bauteil, das vor dem Umzug seiner Produktreihe erstellt wurde, wird im alten PDM verwaltet und in das PLM repliziert. Ein Bauteil, das danach erstellt wurde, wird im PLM verwaltet und zurückrepliziert. Beide Aussagen sind korrekt. Die Regel, die entscheidet, welche Aussage gilt, existiert in keinem System.

Der Moment, in dem das zum Problem wird, ist die Wiederverwendung - und Wiederverwendung ist der eigentliche Zweck eines PLM. Eine neue Baugruppe greift auf eine Komponente zurück, die vor zehn Jahren konstruiert wurde. Diese Komponente liegt auf der Alt-Seite; die Baugruppe wird auf der neuen Seite aufgebaut. Welche Revision ist die richtige? Welcher Änderungsprozess gilt dafür? Die falsche Antwort führt dazu, dass ein Produkt auf Basis einer veralteten Definition freigegeben wird. Fragt man beide Kataloge, antworten beide mit voller Überzeugung.

Eine ERP-Migration ist ein Wochenende. Eine Entwicklungsdaten-Migration ist eine Epoche.

Schwachstelle #2

Wenn ein Datenfluss bricht, geht es zuerst darum herauszufinden, wem er gehört

Zählen Sie die Beteiligten entlang der technischen Kette zwischen einem CAD-Modell und einem ERP-Material: der Plattformhersteller, der Anbieter der Drittanbieter-CAD-Konnektoren, der Integrator für die Konfiguration, die Beratung für die Zielarchitektur, die interne IT und die Business-Referenten auf operativer Seite. Sechs Organisationen, jede kompetent, jede verantwortlich für ihren eigenen Baustein.

Unterbrechen Sie nun einen Fluss. Liegt der Fehler im PLM-Kern, im CAD-Konnektor, im Konfigurationsmodell oder im internen Setup? Anhand des Symptoms kann das niemand sagen. Die Diagnose erfolgt also durch Ausschlussverfahren über Organisationsgrenzen hinweg, und jede Grenze hat ihr eigenes Ticketsystem - ein internes Tool auf der einen Seite, ein Lieferantenportal auf der anderen, kein gemeinsamer Status, keine gemeinsame Uhr. Die Bearbeitungszeit eines Fehlers verstreicht größtenteils damit, dass er hin und her geschoben wird.

Das ist kein Versagen eines einzelnen Lieferanten. Es ist strukturell bedingt und sollte klar beim Namen genannt werden: In einer Landschaft, die Projekt für Projekt zusammengebaut wurde, besitzt jede Partei eine Box, aber niemand besitzt das, was zwischen den Boxen läuft. Integration wird als Nebenprodukt des Projekts behandelt, das sie zuletzt benötigte - sie hat also keinen Eigentümer, keine Roadmap, keine Testsuite und keinen eigenen Lebenszyklus.

Jeder Lieferant besitzt eine Box. Niemand besitzt die Pfeile.

Schwachstelle #3

Konfigurierbar ist nicht dasselbe wie architekturiert

Die Plattform wurde wegen ihrer Offenheit gewählt, und genau das liefert sie auch. Der Preis eines leeren Blattes Papier ist jedoch, dass man es füllen muss. Jeder Objektstatus, jeder Übergang, jedes Genehmigungsschema, jeder Lebenszyklus - das Leben einer Anforderung, die Anatomie einer Änderung - muss von Grund auf in einem Unternehmen spezifiziert werden, das diese Regeln noch nie zuvor aufschreiben musste. Das eigene Wort des Teams dafür ist das Gefühl, etwas neu zu erfinden, das eigentlich zum Standard gehören sollte. Funktionen, die von außen trivial wirken, erfordern monatelange Konfiguration und Tests.

Am schmerzhaftesten zeigt sich dies bei den Zugriffsrechten. Mehrere Entwicklungsgemeinschaften, Standorte in Europa und Asien sowie divisionsübergreifende Projekte: vier bis fünf Sicherheitsebenen, rund zwanzig Rollen und zusätzliche bedingte Regeln - ein Bauteil, das einem divisionsübergreifenden Projekt zugeordnet ist, setzt die Einschränkungen außer Kraft, die sonst gelten würden. Die Modellierung verbrauchte weit mehr Stunden und Tests als prognostiziert und führt bei der Erstellung neuer Objekte immer noch zu Fehlern.

Nichts von diesem Aufwand ist verschwendet - die Entscheidung, wie Ihr Unternehmen ein Bauteil, eine Änderung und eine Freigabe definiert, ist echte intellektuelle Arbeit und übersteht Versions-Upgrades besser als individueller Code. Aber achten Sie darauf, wo es aufgeschrieben wird. Das Datenmodell des Unternehmens wird als Konfiguration der Plattform eines einzelnen Anbieters codiert. Es kann auf der ERP-Seite nicht wiederverwendet werden, es kann das Legacy-PDM während der Übergangsphase nicht steuern und es wandert nicht mit zu dem, was danach kommt.

Was das Zielbild tatsächlich verlangt

Zehn Preise, und nur einer davon ist hier nützlich

Das Zielbild ist klar und in dieser Branche nicht ungewöhnlich: ein durchgängiger digitaler Faden von der Kundenanforderung bis zur finalen Validierung; eine automatisierte, zweiseitige Verknüpfung zwischen dem PLM, das Produkt und Prozess definiert, dem ERP, das Einkauf, Logistik und Kosten steuert, und dem MES, das die Fertigung leitet; mechanische, elektronische und eingebettete Software-Entwicklung an einem Ort; und nützlicher Kontext für den Entwickler - was ein Bauteil tatsächlich kostet, ob sein Qualifikationstest bestanden wurde - , ohne dass ein einziges zusätzliches Feld manuell ausgefüllt werden muss.

Diese letzte Anforderung wirft die Frage auf, die über die gesamte Architektur entscheidet. SAP hält etwa zehn verschiedene Preistypen für ein Bauteil bereit. Welcher davon gehört ins PLM? Standardkosten? Letzter Einkaufspreis? Geplanter Preis für die kommende Periode? Jede Antwort ist für eine Abteilung richtig und für eine andere irreführend - und jede Antwort, die das Kopieren der Zahl beinhaltet, ist am nächsten Tag wieder falsch.

Die gleiche Frage stellt sich erneut für den Teststatus in einer internen Qualifikationsdatenbank und wiederum für Änderungen: Der Änderungsprozess im PLM und die Änderungsaufträge im ERP müssen übereinstimmen, und heute ist die Brücke dazwischen teilweise immer noch ein Mensch.

Das Problem in einem Bild
Eine Bibliothek, die Regal für Regal über Jahre hinweg in ein neues Gebäude umzieht. Beide Gebäude sind geöffnet. Beide Kataloge sind für ihre eigenen Regale korrekt und für die des anderen falsch. Ob sich ein Buch im alten oder im neuen Flügel befindet, hängt davon ab, wann es angekommen ist - und diese Regel wurde nie in einen der Kataloge geschrieben. Sie lebt in den Köpfen der Umzugshelfer. Fragt man den Katalog, erhält man eine selbstbewusste Antwort. Fragt man den Leser, der zum falschen Gebäude gelaufen ist, erfährt man die Wahrheit.

Der Ausweg

Nicht eine bessere Brücke zwischen zwei Systemen - eine Schicht über beiden

Der erste Reflex ist, die Replikation zwischen dem alten PDM und dem neuen PLM zu verstärken, dann das Gateway zum ERP zu härten und schließlich ein gutes Gateway zum MES zu bauen, wenn dieses eintrifft. Das ist das klassische n×m-Problem, neu aufgebaut Projekt für Projekt: Jedes neue System vervielfacht die Verkabelung, jedes Plattform-Upgrade gefährdet sie, und wenn das alte PDM schließlich abgeschaltet wird, werden die für den Übergang gebauten Brücken mit ihm weggeworfen. Jahrelange Arbeit, bewusst auf Einweg ausgelegt.

Die Alternative besteht darin, eine Integrationsschicht über die Systeme zu legen, die vom Fachbereich und nicht von einem einzelnen Projekt besessen wird und fünf Aufgaben erfüllt:

• Eine Definition des Bauteils, oberhalb beider führender Systeme. Das Alt-PDM behält seine Codes, das neue PLM behält seine eigenen, und die Schicht mappt sie auf eine einzige fachliche Definition. Die Datumsregel hört auf, Stammeswissen zu sein, und wird Teil des Modells - lesbar, testbar und für alle gleich.
• Verlinken, nicht kopieren. Die zehn Preise bleiben in SAP. Die Schicht verweist live auf den Preis, der in diesem Kontext Bedeutung hat, genau in dem Moment, in dem der Entwickler ihn ansieht. Nichts wird in das PLM repliziert, sodass nichts veraltet. Die Frage ändert sich von „Welchen Preis kopieren wir?“ zu „Welchen Preis meinen wir hier?“.
• Zeit als eigene Dimension behandeln. Eine Landschaft mitten in der Migration ist eine Landschaft, deren Strukturen sich ständig ändern. Die Aufzeichnung, wann sich eine Definition, ein Master oder eine Hierarchie geändert hat, ermöglicht es, dass eine Baugruppe von vor zehn Jahren immer noch gegen die Strukturen von vor zehn Jahren gelesen werden kann - anstatt stillschweigend durch das heutige Modell uminterpretiert zu werden.
• Einmal verbinden, nicht n×m. CAD, das Alt-PDM, das PLM, SAP und die Testdatenbank verbinden sich jeweils einmal mit der Schicht, nicht untereinander. Wenn das MES hinzukommt, schließt es sich dem Modell an und nicht der Verkabelung - und die Übergangsverbindungen sind keine Einwegarbeit mehr.
• Dem Datenfluss einen Eigentümer geben. Integration wird zu etwas mit einem eigenen Lebenszyklus - versioniert, getestet, dokumentiert, verwaltet - statt ein Nebenprodukt des letzten Projekts zu sein, das sie benötigte. Verantwortung, die um den Fluss herum gezogen wird und nicht um die Boxen, beendet das Hin- und Herschieben.

Nichts hier ersetzt das PLM-Programm und nichts wird migriert, damit es funktioniert. Die Systeme bleiben genau dort, wo sie sind; die Schicht sitzt darüber und beginnt klein - ein Objekt, das Bauteil, und ein Fluss. Der Rest wächst nach Bedarf.

Was es verändert

Halbierung der Laufzeit und ein nutzbarer Umfang in Monaten

Der Unterschied liegt nicht in der architektonischen Eleganz. Es ist die Kalenderzeit. Systeme Projekt für Projekt miteinander zu verkabeln, ist genau das, was die Integration in ein Jahrzehnt der Arbeit verwandelt: Jedes neue System vervielfacht die Verbindungen, jedes Plattform-Upgrade gefährdet sie, und die für den Übergang gebauten Brücken werden weggeworfen, wenn das Altsystem schließlich abgeschaltet wird. Jedes System einmal mit einer Schicht zu verbinden, die das Modell hält, eliminiert den Großteil dieser Arbeit, bevor sie überhaupt entsteht.

In vergleichbaren Landschaften ist das Muster konsistent: Eine Integrations-Roadmap, die ansonsten fast ein Jahrzehnt laufen würde, verkürzt sich auf etwa die Hälfte - und ein erster nutzbarer Umfang geht in Monaten live, statt der zwei bis drei Jahre, die ein plattformweiser Aufbau benötigt, bevor irgendetwas nutzbar ist. Der Grund ist nicht die Liefergeschwindigkeit, sondern die Reihenfolge: Das erste Objekt, das Sie modellieren, ist für sich genommen nützlich, noch bevor das zweite System verbunden ist. Dies sind Größenordnungen aus ähnlichen Programmen, keine Prognose für eine bestimmte Landschaft.

Das ist die Arbeit, die boTec leistet. Dreißig Jahre in der Prozess- und Fertigungsindustrie, mehr als einhundert vorgefertigte Konnektoren und eine Zusammenarbeit, die mit Ihrem Geschäftsmodell beginnt und nicht mit unserer Software: Der DataBridge ist die Schicht, und das Projekt besteht darin, das Modell darauf gemeinsam mit Ihren Mitarbeitern aufzubauen. Ihr PLM-Programm läuft weiter. Ihr ERP bleibt, wo es ist. Nichts wird migriert, damit das Fundament funktioniert - und sowohl die Daten als auch das Modell bleiben exportierbar, sodass das Fundament niemals zur nächsten Abhängigkeit wird, in der Sie gefangen sind.

Der Übergangszustand ist keine Phase, die man ertragen muss. Für mehrere Jahre ist er die Architektur, mit der Sie tatsächlich arbeiten.

Die Lektion gilt überall

Vier Anzeichen dafür, dass Ihr Übergangszustand stillschweigend dauerhaft geworden ist

Die Details hier stammen aus der Mechatronik, aber das Muster ist überall dasselbe, wo ein Kernsystem ersetzt wird - Chemie, Pharma, Energie, Maschinenbau, Lebensmittel und Getränke. Wann immer das Objekt zu schwer ist, um an einem Wochenende bewegt zu werden, folgt eine lange Koexistenz, und es zeigen sich dieselben vier Anzeichen:

• Zwei führende Systeme für dasselbe Objekt, wobei die Zuständigkeit durch ein Datum statt durch eine für jeden lesbare Regel bestimmt wird.
• Unterbrochene Datenflüsse, die im Ausschlussverfahren über drei oder mehr Lieferanten in drei oder mehr Ticketsystemen diagnostiziert werden.
• Integrationslogik, die nur innerhalb der Konfiguration einer einzelnen Plattform existiert - und daher weder das System steuern kann, das Sie verlassen, noch das, welches Sie als Nächstes kaufen werden.
• Eine Zielarchitektur ohne Zeichnung des Übergangszustands - der Zustand, in dem Sie am längsten leben werden, ist derjenige, den niemand entworfen hat.

Der Weg nach vorne besteht nicht darin, den Übergangszustand künstlich zu verkürzen. Er besteht darin, aufzuhören, ihn als vorübergehendes Ärgernis zu behandeln, und ihm ein Modell zu geben: eine Definition eines kritischen Objekts, gehalten über den Systemen, die es speichern, sodass das alte System ohne großes Tamtam abgeschaltet und das neue eines Tages ohne Drama ersetzt werden kann. Ein Fundament, das die darunter liegenden Plattformen überdauert, ist genau das, wofür der boTec DataBridge gebaut wurde.