Product Data Backbone

Ähnlich dem Rückgrat eines Menschen versorgt das Product Data Backbone die einzelnen Abteilungen und Standorte eines Unternehmens über eine digitale Plattform permanent und ohne Medienbrüche mit den Informationen aus dem Product Lifecycle. Wichtig ist, dass alle für die Produktentstehung und Produktmanagement relevanten Informationen digital in Beziehung gesetzt und Abhängigkeiten dargestellt werden. Nur so lassen sich Abläufe digital initiieren. Beispielsweise kann der Konstrukteur über einen gescheiterten Test der von ihm erstellten Baugruppe, informiert werden oder der technische Redakteur wird über die Notwendigkeit einer Änderung der Dokumentation durch die Änderung eines Bauteils informiert.

Die am Arbeitsprozess beteiligten Personen müssen sich ihre Dokumente nicht aus mehreren Quellen zusammensuchen, sondern werden über die Beziehungsinformation des Product Data Backbones automatisch mit vollständigen und gültigen Informationen versorgt.

Mit einer PDM/PLM-Software für Product Lifecycle Management lässt sich ein Product Data Backbone im Unternehmen aufbauen. CAD (z.B. AutoCAD, Autodesk Inventor, Creo, Solid Edge oder Solidworks) und Produktdatenmanagement-System (PDM-System) bilden darin mit einem technischen Dokumentenmanagementsystem (DMS^tec) eine durchgängig digitale Plattform, die auf unternehmensübergreifende Zusammenarbeit ausgelegt und als PDM/PLM-System unternehmensweit eingesetzt wird.

Die Produktentstehung ist der Start des Lebenszyklus‘ der Produkte – egal ob es sich um Pumpen, Motoren, Komponenten einer Sondermaschine oder eine komplette technische Großanlage handelt. Zum Alltag vieler technischer Unternehmen gehören die Anpassung und Erweiterung bestehender und bewährter Grundkomponenten eines Produktes an die spezifischen Anforderungen des Kunden. Hier kommt es darauf an, auf Vorlagen zurückzugreifen, die bereits an anderer Stelle erstellt wurden. Um die Abläufe in der Produktentstehung zu verbessern, muss unter anderem das Zusammenspiel der Disziplinen Mechanik, Elektrotechnik, Elektronik und Softwareentwicklung optimiert werden. Benötigt wird also ein durchgängiges Beziehungswissen der vorhandenen Informationen, repräsentiert in den vielen Informationen, die rund um das Produkt und in angrenzenden administrativen Bereichen entstehen, und deren Zusammenhang. Dies ist ein erster Schritt in Richtung ‚Digital Product Engineering‘.

Der Service im Betrieb wird zunehmend Teil des Produktes selbst. Je individueller Produkte werden, umso wichtiger ist es, dass der Hersteller alle Informationen und Dokumente zu seinen Produkten mit einem Griff zur Hand hat. Hier spricht man heute vom Digitalen Produktmanagement und dem Digitalen Informationszwilling. PDM/PLM- und DMS^tec-Lösungen bringen diese Informationen zusammen, strukturieren sie und repräsentieren sie über die technischen Strukturen wie beispielsweise eine Anlagenstruktur und die darin verbauten Baugruppen und Teile. Ist ein Motor mehrfach in einer Anlage oder mehreren Anlagen verbaut, so ist die mit dem Motor verknüpfte Leistungsbeschreibung auch gleichzeitig mit den verbauten Motoren in den Anlagen verknüpft.

Mitarbeitende im kaufmännischen Bereich haben im produzierenden Gewerbe die Nase vorn – zumindest was das ganzheitliche Arbeiten in den ihnen zur Verfügung stehenden Softwarelösungen angeht. In ihrem ERP-System greifen sie von zentraler Stelle auf Informationen zu allen Komponenten zu, seien sie aus der Mechanik, der Elektronik oder seien es Softwarebausteine. Sie können jederzeit einen Bezug zwischen den Komponenten herstellen.

Genau dieser Bezug fehlt aber in der Konstruktion/Entwicklung, zumindest dort, wo noch kein PDM/PLM-System im Einsatz ist. Der Grund: Alle Informationen liegen in verschiedenen Systemen, M-CAD-, E-CAD-Konstrukteure und Softwareentwickler verwalten ihre Informationen weitgehend selbst. Wenn jedoch Mechanik, Elektronik und Softwareentwicklung nicht miteinander sprechen, entstehen keine digitalen Produkte. Deshalb ist ein digitaler Informationszusammenhang nötig.

Entscheidet zum Beispiel der Entwickler in der Elektronik-Konstruktion, dass eine Platine fünf Zentimeter breiter sein muss, sollte automatisch der mechanische Konstrukteur darüber informiert werden, um das Gehäuse anzupassen. Konstruktionsabteilungen entwerfen komplexe Produkte, erfahren aber in der Regel nie, wie das Produkt später beim Kunden ankommt und ob es funktioniert wie geplant. Feedback gibt es kaum, und es gelangt selten zu den Konstrukteuren oder Produktmanagern. Üblicherweise behebt der Service Störungen einzeln und adhoc.

Der fehlende Bezug verhindert einen Rückfluss der Informationen

Dieser Dialog fehlt, wenn jeder nur in „seinem“ System arbeitet und dort solche Änderungen durchführt. Ein Rückfluss findet nicht statt und es existiert kein Plan, wie man Reklamationen den betreffenden Teilen zuordnet und einen Bezug herstellt (damit die Reklamation richtig ausgewertet werden kann). Dabei ist genau dieser Rückfluss immens wichtig, damit mögliche Konstruktionsfehler so schnell wie möglich behoben werden. Etwa ein zu enger Einbau von Komponenten, der dafür sorgt, dass der Kondensator regelmäßig zu heiß wird. Oder ein Teil, das wiederholt defekt ist und daher von Grund auf anders konstruiert werden muss.

Eine weitere Folge fehlender Absprachen sind unnötige Doppelentwicklungen. Sie geschehen oft dann, wenn Zuständigkeiten nicht klar abgesteckt sind, typischerweise bei Teilen, die sich von ihrer Funktion her mehreren Gewerken zuordnen lassen. Daraus resultieren Probleme in der Arbeitsvorbereitung, in der dann später entschieden werden muss, welches Teil zum Einsatz kommen soll. Rückfragen und nachträgliche Abstimmung verzögern den Fertigungsprozess. Bleibt der Fehler unbemerkt, wird im schlimmsten Fall doppelt oder falsch produziert.

Zusätzlich zur Versionierung von Teilen einer Maschine wird es immer wichtiger, diese auch mit den Versionen der Maschinensoftware zu verbinden. Das ist aber heute oft nicht der Fall – was daran liegt, dass die Software bislang einen relativ geringen Anteil an der Konstruktion hat. Durch die Digitalisierung in technischen Unternehmen ist dieser bereits jetzt stark ansteigend; die Anteile der Value Proposition eines Produktes verschieben sich immer weiter in Richtung Software. So läuft eine heute ausgelieferte Maschine im Vergleich zum Modell von vor zehn Jahren oft mit einer völlig neuen Software, die mit jener von damals nur noch wenig gemein hat. Der Anlagenhersteller muss also wissen, welche wann ausgelieferte Maschine welche Software beinhaltet – anderenfalls kann er eine Wartung kaum durchführen. Auch kann er auf einen alten Softwarestand nicht einfach die neueste Version aufsetzen.

Ein Fertigungsunternehmen sollte wissen, bei welchen Komponenten seiner Produkte häufiger Defekte auftreten als bei anderen. Es sollte auswerten können, wie Komponenten einfach repariert und ersetzt werden und auf welche Art Entwicklung und Produktmanagement Defekte präventiv verhindern. Wer diese Informationen rechtzeitig an die zuständige Stelle übermittelt, kann seinen Service richtig planen und erlangt allein dadurch einen Wettbewerbsvorteil. Ziel sollte sein, ein strategisches Instandhaltungsmanagement aufzubauen, bei dem bereits im Vorfeld das betreffende Teil in allen Maschinen, die beim Kunden im Einsatz sind, ausgetauscht wird – noch bevor es zu spät ist. So hält der Hersteller seine Service Level Agreements ein und minimiert Garantiefälle.

Reklamationen vermeiden und Produktqualität erhöhen kann man, indem ein Bezug zwischen Konstruktionsteilen und Reklamationen hergestellt wird. Ein Digital Thread verbindet Informationen aus dem laufenden Betrieb mit der Entwicklung und ermöglicht auf diese Weise eine Auswertbarkeit der Artikel/Teile. Ein Product Data Backbone ist dringend nötig, um den Bezug von Reklamationen zum betreffenden Teil herstellen zu können. Es geht also nicht allein um den Bezug zum Kunden (der im CRM-System stattfindet), denn dieser hilft nur dem Support. Auch der Konstrukteur muss sofort wissen, wenn sich bei einem bestimmten Teil die Reklamationen häufen, um den Fehler in Entwicklungs- und Fertigungsdokumenten sofort zu berücksichtigen. Erfährt er es nicht, verbaut er das gleiche Teil wider besseren Wissens weitere Male. Für den Service heißt das: dieselbe Reparatur immer wieder durchführen.

In einer PDM/PLM-Software sollte somit zum ERP-System auch ein Bezug zwischen Konstruktionsteilen und Kaufteilen hergestellt werden – für den Fall, dass Kaufteile störanfällig sind und häufig ausgetauscht werden müssen. In der Konstruktion tauchen diese naturgemäß nicht auf; trotzdem sollten Konstrukteure über mögliche Qualitätsprobleme informiert sein. Denn dann können sie ein passendes Ersatzteil konstruieren oder anregen, ein anderes Kaufteil zu beschaffen. Deshalb braucht das PDM/PLM-System eine bidirektionale Schnittstelle zum ERP-System. Sie ermöglicht den wechselseitigen Informationsfluss und die Herstellung der gewünschten Bezüge.

Damit Serviceleistungen pro Artikel ausgewertet werden können, ist es ratsam, zudem einen gesteuerten Änderungs- bzw. Verbesserungsprozess im Unternehmen zu etablieren. Diese Maßnahme wird – in Verbindung mit der Herstellung von Bezügen zwischen Konstruktions-, Kaufteilen und Reklamationen – zum Digital Thread im Unternehmen. Dieser Digital Thread verbindet Informationen aus dem laufenden Betrieb mit der Entwicklung. Die Einhaltung des digitalen Pfades führt rasch zu einer signifikanten Verringerung von Serviceeinsätzen. An die Stelle von ad-hoc-Services treten planbare Präventivmaßnahmen (Wartung). Die SLAs können höher angesetzt sowie leichter eingehalten werden und die Produktqualität steigt, weil es weniger defekte Teile gibt.

Mit Nutzung eines Product Data Backbones finden Mechanik, Elektronik und Softwareentwicklung eine gemeinsame Sprache. Durch Verknüpfung produktrelevanter Daten und Dokumente wird ein digitaler Informationszusammenhang hergestellt – ein Bezug zwischen allen Komponenten entsteht, unabhängig von ihrer Herkunft aus Mechanik, Elektronik oder Software. Es ist ersichtlich, wann welches Teil in welcher Version und in welchem Projekt verbaut und wiederverwendet wurde. Ist diese Eindeutigkeit hergestellt und sind die Zuständigkeiten zwischen den Gewerken klar geregelt, minimiert sich das Risiko, Teile doppelt zu konstruieren und zu fertigen.

Durch die Einbeziehung kaufmännischer Informationen aus dem ERP-System im Product Data Backbone kann bereits in der Konstruktionsphase auf Vorzugsteile (lagerhaltig, günstiger, schneller Lieferant) zugegriffen werden. PDM/PLM und ERP tauschen ihre Informationen bidirektional untereinander aus und stellen den Bezug der Komponenten untereinander sowie mit Projekten her.

Erst auf der Basis eindeutiger Informationen im Entwicklungsprozess kann sich eine enge Kollaboration zwischen den einzelnen Gewerken entfalten. Bei eindeutiger Markierung weiß jeder, was er zu tun hat. Er erkennt, welche Teile in der mechatronischen Struktur bereits vorhanden sind, wer sie erstellt hat und was es für Auswirkungen hat, wenn er etwas ändert. So verkürzt sich die Abstimmung, die Zusammenarbeit vereinfacht sich und man kommt schnell und fehlerfrei von der Konstruktion über die Fertigung bis zur Auslieferung.

Die fortschreitende Digitalisierung im Mittelstand, vor allem in technischen Unternehmen, wird den beschriebenen digitalen Informationszusammenhang künftig immer stärker einfordern. Umso wichtiger ist es, ein PDM/PLM-System als Product Data Backbone einzusetzen. Es ermöglicht Mechanik, Elektronik und Softwareentwicklung, miteinander zu sprechen und schafft damit die Voraussetzung für digitale Produkte.