Product Data Backbone

Die unterbrechungsfreie digitale Weiternutzung von Informationen ist in vielen Unternehmen noch nicht Realität. Stücklisten werden von Hand abgetippt und manuell in ERP-Systeme eingegeben. Anders bei Einsatz eines Product Data Backbone, das Daten und Dokumente aus allen Abteilungen und Systemen (CAD, ERP, PDM/PLM) in einer zentralen Datenbasis zusammenführt. In ihm fließen Produktdaten und Dokumente in digitaler Form zusammen und werden miteinander in Verbindung gebracht. Alle Bereiche werden zusammenhängend über den gesamten Product Lifecycle betrachtet. Abhängigkeiten bei Änderungen lassen sich steuern, direkte und funktionale Zusammenhänge werden sichtbar. So wird das Product Data Backbone zum Rückgrat aller produktrelevanten digitalen Informationen. Es stellt die notwendige Voraussetzung dar, damit ein Unternehmen Digitalisierung betreiben und in der Fertigung durchgehend digitale Abläufe aufsetzen kann.

3.1 Durchgängige Plattform

Mit PRO.FILE als Software für „Collaborative Product Lifecycle Management“ lässt sich ein solches Product Data Backbone aufbauen. CAD und Produktdatenmanagement (PDM) bilden darin mit einem technischen Dokumenten-Management-System (DMStec) eine durchgängige Plattform, die auf unternehmensübergreifende Zusammenarbeit ausgelegt und in das ERP integriert ist.

Wie die Anforderungen an ein PDM/PLM-System später aussehen, kann ein Maschinen- und Anlagenbauer oft nicht sofort abschätzen. Der Regelfall ist, dass sie im Laufe der Zeit steigen. Hier gibt es mehrere Handlungsalternativen: Man setzt zunächst ein vom CAD-Anbieter mitgeliefertes Produkt oder eine einfache CAD/ERP Interface-Lösung ein. Dies führt aber, wenn später die Anforderungen an die Funktionalität steigen, schnell in eine Sackgasse.

Die andere Möglichkeit sind PLM-Suiten, die aber oft funktionell überladen sind und umfangreich implementiert sowie später aufwändig angepasst werden müssen. Dies führt dazu, dass nur ein sehr kleiner Teil der zur Verfügung stehenden Funktionen genutzt wird. Anpassungen werden nicht durchgeführt, weil sie zu teuer wären. Das Ergebnis: 80% des Budgets gehen für die Softwareimplementierung verloren und nur 20% verbleiben für die Realisierung des eigentlichen Ziels. Daher sollte es genau umgekehrt sein.

Einen Ausweg aus diesem Dilemma bietet PRO.FILE als skalierbare Lösung. Sie erlaubt einen einfachen Einstieg mit minimalen Anforderungen und lässt sich Schritt für Schritt zur vollständigen Collaborative-PLM-Suite erweitern. Damit wird dem Anwender die Last der Entscheidung zwischen großer PLM-Suite und einfacher Interface-Lösung abgenommen. Er startet vielmehr mit den jetzigen Anforderungen und baut das System dann sukzessive weiter aus.

Konfiguration statt Customizing mit ISI.CON

Das Konzept dahinter lässt sich mit „Konfigurieren statt Customizing“ beschreiben. Änderungen kann der Projektleiter (oder Kunde) selbst direkt im System vorgenehmen, ohne über Programmierkenntnisse verfügen zu müssen. Es ermöglicht den Anwendern von Beginn an die Nutzung eines später ausbaubaren großen PDM/PLM-Systems zu Mittelstandspreisen.

3.2 Digitaler Informationszusammenhang

Mitarbeiter/innen 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 PLM 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.

Kein Bezug, das heißt: Abhängigkeiten können nicht dargestellt werden. 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, zumindest keins, was bis an die Ohren der Konstrukteure oder des Produktmanagements gelangt. Sondern der Service behebt Störungen einzeln und ad-hoc.

Dieser Dialog fehlt aber, wenn jeder nur in „seinem“ System arbeitet und dort solche Änderungen durchführt. Ein Rückfluss findet nicht statt und es existiert auch kein Plan, wie man Reklamationen den sie betreffenden Teilen zuordnet und einen Bezug herstellt (damit die Reklamation richtig ausgewertet werden kann). Dabei wäre 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 immer wieder kaputt geht 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, bei 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 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 beinhaltete – 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 muss es 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.

Digital Thread verbindet laufenden Betrieb mit der Entwicklung

Reklamationen vermeiden und Produktqualität erhöhen kann man, indem ein Bezug zwischen Konstruktionsteilen und Reklamationen hergestellt wird. Ein Digital Thread verbindet den laufenden Betrieb mit der Entwicklung und ermöglicht auf diese Weise eine Auswertbarkeit der Artikel/Teile. PLM-Software ist das geeignete System, über welches sich der Bezug von Reklamationen zum sie betreffenden Teil herstellen lässt. Es geht also nicht allein um den Bezug zum Kunden (der im CRM-System stattfindet), denn dieser hilft nur dem Support. Sondern es ist auch der Konstrukteur, der sofort wissen muss, wenn sich bei einem bestimmten Teil die Reklamationen häufen, um den Fehler in der eigenen Arbeit sofort zu berücksichtigen. Erfährt er es nicht, verbaut er das gleiche Teil wider besseren Wissen ein ums andere Mal. Für den Service heißt das: ein und dieselbe Reparatur immer wieder durchführen.

In der PLM-Software sollte auch ein Bezug zwischen Konstruktionsteilen und Kaufteilen im ERP-System 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 besorgen. Deshalb braucht das 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. 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. Die SLAs können höher angesetzt sowie leichter eingehalten werden und die Produktqualität steigt, weil es weniger defekter Teile gibt.

Product Data Backbone

Lösung: das Product Data Backbone

Eine gemeinsame Sprache finden können Mechanik, Elektronik und Softwareentwicklung durch die Nutzung eines zentralen Product Data Backbone, welches Produktdaten und produktrelevante Informationen aus allen bestehenden Gewerken (M-CAD, E-CAD, Softwareentwicklung) zusammenführt und logisch miteinander verbindet. So lässt sich ein digitaler Informationszusammenhang herstellen. Durch eine Verknüpfung wird der gewünschte Bezug zwischen allen Komponenten erzeugt, 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.

Die bisherigen Datensilos werden damit aufgebrochen. Im nächsten Schritt ist eine Integration in das ERP-System erforderlich. So werden dem Product Data Backbone (PDB) auch die kaufmännischen Informationen hinzugefügt. Das bedeutet, dass bereits in der Konstruktionsphase auf Vorzugsteile (lagerhaltig, günstiger, schneller Lieferant) zugegriffen werden kann. 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 wird den beschriebenen digitalen Informationszusammenhang künftig immer stärker einfordern. Umso wichtiger ist es, ein 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.