Systematische Optimierung des Produktentwicklungsprozesses mit PLM-ML

Abstract

Die Steigerung der Produktivität, getrieben durch den Kosten- und Konkurrenzdruck, ist Kern jeder Strategie global agierender Unternehmen. Produzierende Unternehmen verfolgen dieses Ziel, von der kontinuierlichen Verbesserung der Produktionsprozesse bis zur Optimierung globaler Lieferketten. Der Optimierungsgedanke wird zunehmend auch auf den Produktentwicklungs­prozess (PEP) angewendet und unter dem Schlagwort Product Lifecycle Management (PLM) diskutiert. Konträr dazu fokussieren PLM-Projekte im Wesentlichen auf IT-Einführung. Häufig geht dabei der Optimierungsgedanke verloren. Ein Grund hierfür ist in der Komplexität des PEP zu suchen. Dieser lässt sich mit vorhandenen Modellierungsmethoden nur schwer erfassen und optimieren. Vor diesem Hintergrund wurde von den Autoren die PLM-ML als Instrument entwickelt mit der sich der PEP einfach erfassen und optimieren lässt. Der Artikel erläutert die PLM-ML und zeigt an einem Beispiel wie sich der PEP damit optimieren lässt.

Der Optimierungsgedanke bei der Einführung von PLM

Um im Konkurrenzdruck des globalen Wettbewerbs auch zukünftig bestehen zu können stehen produzierende Unternehmen vor der Herausforderung ihre Produktivität kontinuierlich zu steigern. Dabei erzielen sie große Erfolge z.B. durch die Optimierung von Arbeitsabläufen, die Verbesserung von Organisationsstrukturen sowie den Einsatz neuer Produktions- und Fertigungstechnologien. Der Optimierungsgedanke wird aktuell zunehmend auf den Produktentwicklungsprozess (PEP) angewendet da die Erkenntnis wächst, dass im PEP noch viele -bisher ungenutzte- Potenziale insbesondere auch für dessen Folgeprozesse liegen.

Diese Diskussionen werden vornehmlich unter dem Schlagwort Product Lifecycle Management (PLM) geführt. Da PLM eng mit der Einführung von Informationstechnologie verflochten ist, hat sich die gängige Sicht entwickelt, PLM als IT-Umsetzungsprojekt in IT-Abteilungen anzusiedeln. Häufig geht dabei der eigentliche Optimierungsgedanke verloren. Ein offensichtlicher Grund hierfür liegt in der stark ausgeprägten Fokussierung auf Informationstechnik. Es existiert jedoch ein weiteres Problem das zumeist im „Nebel“ des IT-Projekts untergeht und das bisher zu wenig Beachtung beigemessen bekommt. Der PEP ist außergewöhnlich komplex. Mit den vorhandenen Modellierungsmethoden ist es kaum möglich ihn adäquat zu beschreiben. Für eine darüber hinaus gehende Optimierungsdiskussion fehlen bisher die entsprechenden Modellierungswerkzeuge.

Vor diesem Hintergrund wurde im Rahmen der Entwicklung der Do(PLM)Con Methodik die PLM Modelling Language (PLM-ML) als ein Werkzeug entwickelt das den PEP für eine Optimierungsdiskussion zugänglich macht.

Ein neuer Ansatz zur Betrachtung des PEP

Die PLM-ML nahm ihren Ursprung in Fachdiskussionen von PLM Architekten zur Definition von „Industry Best Practice“ für PLM. Bei im Rahmen dieser Diskussionen durchgeführten Analysen industrieller Anwendungsfälle zeigten sich erhebliche Schwächen in vorhandenen Modellierungsinstrumenten wie z.B. Funktionsanalysen, Prozesskettendarstellungen oder IT-System Landkarten. Die daraus resultierenden Darstellungen wurden in der Anwendung zu schnell zu komplex. Darüber hinaus ließen sich wesentliche PLM-Aspekte mit diesen gar nicht abbilden.

Bild 1: Ein neuer Ansatz zur Betrachtung des Produktentwicklungsprozess (PEP)

Nach einiger Zeit intensiver Diskussionen kristallisierte sich eine neue Sicht basierend auf einem systemischen Modellierungselement heraus, dessen Signifikanz zuvor übersehen wurde. Um ein Produkt zu entwickeln und zu produzieren denken Ingenieure das Produkt und dessen Herstellung voraus. Dafür nutzen sie Modelle. Jede Anwendungsdisziplin (z.B. Anforderungsmanagement, mechanische und mechatronische Konstruktion, Dokumentation etc.) verwendet i.d.R. eigene Modelle. Diese Modelle bilden Teilaspekte des zukünftigen Produkts für die jeweilige Anwendungsdisziplin hinreichend genau ab. Damit ist jedes dieser Modelle ein (Teil-)Produktmodell (kurz Teilmodell) des späteren Produkts.

Aufbauend auf dieser Überlegung wurde der in Bild 1 dargestellte Modellierungsansatz entwickelt. Dieser verbindet die prozessorientierte Sicht mit der Idee des systemischen Modellierungselements „Teilmodell“. Die Prozesse des PEP werden dabei in drei verschiedene Klassen eingeteilt. Management Prozesse steuern den PEP (Bild 1, oben). Sie werden methodisch i.d.R. über Meilensteinpläne abgewickelt. Die täglichen Arbeitsprozesse im PEP werden vergleichbar mit einem Trigger durch den Managementprozess angestoßen oder finden ihr Ende an dessen Meilensteinen. Untergliedern lassen sie sich in langfristig stabile Prozesse (gemeint sind z.B. Freigabe- und Änderungsprozesse vgl. Eigner 2012, S. 21) und in die täglichen Engineering Prozesse. Stabile Prozesse werden im Gegensatz zu den täglichen Engineering Prozessen explizit definiert und i.d.R. über Workflows in Datenmanagementsystemen gesteuert. Sämtliche tägliche Arbeitsprozesse im PEP erzeugen, nutzen, verändern oder entnehmen Informationen in oder aus Teilmodellen. Demzufolge sind Teilmodelle die Kristallisationskeime der Prozesse des PEP’s (siehe Bild 2).

Bild 2: (Teil-)Produktmodelle als Kristallisationskeime der PEP Prozesse

Der Nutzen der in Bild 1 und Bild 2 vorgestellten Sicht liegt in der damit erzielten Vereinfachung. Diesem Ansatz folgend kann der PEP über seine Teilmodelle erfasst werden. Da die Anzahl der Teilmodelle im Vergleich zu den Prozessen im PEP viel geringer ist, sie sich im Detaillierungsgrad besser vereinheitlichen und sich darüber hinaus auch einfacher lokalisieren lassen ergibt sich ein entscheidender Modellierungsvorteil.

Einige wesentliche Eigenschaften von Teilmodellen lassen sich wie folgt beschrieben. Ein Teilmodell ist immer eine Instanz eines Teilmodelltyps. In Bild 3 sind beispielhaft Instanzen verschiedener Teilmodelltypen für die Produktlinie „Muldenkipper“ (Bild 3, oben) und „Bagger“ (Bild 3, unten) gezeigt. Teilmodellinstanzen des gleichen Typs weisen oft Kommunalität auf. Also die gemeinsame Verwendung von Komponenten mit ggf. unterschiedlicher Ausprägung im Kontext der jeweiligen Produktlinie (Bild 3, gemeinsame Komponente „Fahrwerk“).

Unterschiedliche Teilmodelltypen (Beispielfall Bild 3, unten die Modelltypen der Produktlinie Bagger von links nach rechts) enthalten oft redundante Informationen und ähnliche Modellelemente da sie Abbildungen derselben realen Entität sind. Eine Verwendungsstelle im Verwendungsmodell (z.B. Reifen) hat eine Entsprechung im Stücklistenmodell (die für diese Verwendung kaufbaren Reifen mit unterschiedlichen Profilierungen und definierten Gummimischungen) und eine Entsprechung im virtuellen Prototyp. Der Gültigkeitsrahmen und die Bedeutung in den Modelltypen ist jedoch unterschiedlich, z.B. wird nicht für jede Gummimischung ein CAD-Modell konstruiert. Um unterschiedliche Modelltypen desselben Produkts zusammenzuführen ist demnach ein Abgleich des Bedeutungsrahmens der Elemente der Modelltypen notwendig was eine Anpassung der Semantik und damit eine veränderte Arbeitsweise in zumindest einem der beiden Modelltypen nach sich zieht.

Bild 3: Aspekte von (Teil-)Produktmodellen

PLM-ML als Instrument zur Modellierung und Optimierung des PEP

Um den Nutzen der zuvor entwickelten theoretischen Sicht in die Praxis übertragen zu können wurde die PLM-ML im Rahmen der Do(PLM)Con Methodik (Fischer u.A. 2011) entworfen. Die PLM-ML ist eine semiformale grafische Modellierungssprache mit der sich unternehmensindividuelle Ausprägungen des PEP analysieren und optimieren lassen. Die PLM-ML nutzt das Teilmodell als zentrales Modellierungselement. Sie ist vom Wertstromdesign inspiriert und übernimmt z.B. die Idee der Ausrichtung am Mehrwert sowie die Idee einer eingängigen, wenig starr definierte Symbolik. Auch die konsequente Trennung zwischen Ist-Zustand (Current State) und dem zu entwickelnden Soll-Zustands (Future State) wird übernommen. Die PLM-ML stellt verschiedene Diagrammtypen bereit welche in nachfolgende Gruppen gegliedert sind:

• Partial Model Landscape
• Partial Model to Process
• Partial Model Detail
• Partial Model Interaction

Mit den Diagrammen der Gruppe „Partial Model Landscape“ können Landkarten der Teilmodelle des PEP dargestellt und deren Vernetzung im Zeitverlauf analysiert werden. Auf diesen Landkarten lassen sich Bereiche mit Optimierungspotenzial einfach lokalisieren. Solche Bereiche werden nachfolgend mit den Diagrammen der anderen Gruppen detailliert um so die Analysearbeit auf wesentliche Schwerpunkte zu fokussieren. Die Gruppe „Partial Model to Process“ verbindet das Teilmodellkonzept mit der Prozessicht. Das in dieser Gruppe enthaltene „Partial Model/Process Chain“ Diagramm basiert beispielsweise auf den ereignisgesteuerten Prozessketten (vgl. Keller, G.; Nüttgens, M.; Scheer 1992, S. 13), ersetzt jedoch das dort verwendete Informationsobjekt durch das Modellierungselement „Teilmodell“. Die Gruppen „Partial Model Detail“ und „Partial Model Interaction“ fokussieren auf die Teilmodelle an sich. Mit ihnen lassen sich statische Struktur (Semantic), zeitliches Verhalten (Progression) sowie die Integration unterschiedlicher Teilmodelle analysieren.

Analyse und Optimierung des PEPs eines mittelständischen Maschinebauunternehmens

Nachfolgend wird die Anwendung der PLM-ML am Beispiel eines typischen Maschinenbauunternehmens aufgezeigt. Der Fall ist anonymisiert und vereinfacht. Das Unternehmen stellt Maschinen mit weit über 1000 Teilen pro Maschine in Einzel- oder Kleinserie her. Es bietet seinen Kunden eine offene Variantenkonfiguration an, d.h. der Kunde kann individuelle Varianten bestellen die für ihn konstruiert und produziert werden. Im Rahmen einer Schwachstellendiskussion wurden zwei zentrale Probleme als wesentlich angesprochen. Es gelingt dem Unternehmen nicht die Stücklisten und Konstruktionsdaten synchron zu halten. Dadurch werden im Prototypenbau und Produktionsanlauf häufig falsche Teile bereitgestellt was hohe Folgekosten verursacht. Ein weiteres Problem sind lange Durchlaufzeiten bei Aufträgen mit hohem Neuentwicklungsanteil. Die Konkurrenz kann oft schneller liefern, wodurch wichtige Aufträge verloren gehen.

Um die Ursachen zu analysieren wurde der unternehmensindividuelle PEP mittels des Lifecycle Map der PLM-ML (Bild 4 und 5) analysiert. Dieses gibt eine Übersicht der interagierenden Teilmodelle im chronologischen Verlauf des PEPs. Rechtecke stehen für Teilmodelle. Die Pfeile/Linien zwischen den Teilmodellen sowie die zugeordneten Symbole haben eine spezifische Bedeutung hinsichtlich der Vernetzung der Teilmodelle. Auf der Zeitachse werden wesentliche Meilensteine oder Ereignisse des PEPs dokumentiert. Wolken stehen für Bereiche die zur Vereinfachung der Analyse nicht betrachtet werden.

Bild 4: Lifecycle Map „Current State“

Das Diagramm in Bild 4 zeigt den vorgefundenen „Current State“ des PEP. Mit Eingang eines Auftrags stellt ein Produktingenieur die notwendigen Baugruppen für den Auftrag auf Basis seiner Erfahrung zusammen. Wesentliche Informationen für diese Vor-Produkt-Stückliste gewinnt er aus den im Team Data Management (TDM) System (Bild 4, CAD-Cluster) strukturlos gespeicherten CAD-Baugruppen. Von dort leitet er die in den Baugruppen enthaltenen Teileinformationen semiautomatisch in mehrere Excel Dateien aus und detailliert damit die von ihm gepflegte Vor-Produkt-Stückliste (Bild 4, Vor-Produkt-Stückliste). Mit den Baugruppenkonstrukteuren diskutiert er in Meetings und per Telefon die notwendigen kundenspezifischen Anpassungen und dokumentiert auch diese in der Vor-Produkt-Stückliste. Danach klärt er mit den ERP-Spezialisten telefonisch die Materialentsprechungen für angepasste Teile (Bild 4, Materialstamm). Vor Abschluss der Konstruktionsphase initiiert er die Erstellung der Stamm-Stückliste (Bild 4, Stamm-Stückliste) auf Basis der von ihm gepflegten Vor-Produkt-Stückliste.

In der PEP Analyse wurden die Bereiche A & B (in Bild 4 umkreist) als wesentliche Verursacher der Probleme identifiziert. Der Bereich A betrifft die mechanische Konstruktion. Im TDM-System werden die CAD-Daten zwar verwaltet und freigeben, es wird aber nicht zwischen Entwicklungs- und Produktkomponente unterschieden. Entwicklungen finden i.d.R. lediglich im Rahmen von Aufträgen statt. Dabei werden vorhandene Komponenten von Altprodukten übernommen und für das jeweilige Produkt angepasst. Die Verwendung gleicher Module zwischen verschiedenen Produktlinien, so dass über den Lebenszyklus Verbesserungen einer Komponente in alle Produkte einfließen, ist nicht möglich.

Da das Unternehmen aufgrund des vorliegenden Informationsmanagements enorme Schwierigkeiten hat aktuelle Daten für Komponenten zusammenzustellen und weiterzugeben ist eine Zusammenarbeit mit Technologiepartnern nur mit großem Aufwand möglich und wird daher zumeist vermieden. Der Bereich B betrifft das Zusammenspiel zwischen dem Produktingenieur und dem Einkauf. Der Materialstamm und die Vor-Produkt-Stückliste sind weder informationstechnisch noch semantisch verknüpft. Dies hat zur Folge, dass der Einkauf nicht weiß welche Materialien für die Entwicklung neuer Produkte relevant sind. Über Änderungen im Materialstamm wird der Produktingenieur daher i.d.R. nicht informiert. Desweiteren werden dadurch oft ungeeignete Komponenten bestellt die dann berichtigt und neu bestellt werden müssen. Das führt zu verlängerten Lieferzeiten und unnötigen Zusatzkosten. Verschärft wird die Lage durch den Versuch des Einkaufs mit Hilfe von Einkaufsstrategien Kosten zu reduzieren. Dies verursacht weitere Veränderungen des Materialstamms und in der Folge nicht kalkulierbare Auswirkungen auf die in Entwicklung befindlichen Aufträge.

In Bild 5 ist der verbesserte und bereits erfolgreich implementierte „Future State“ zu sehen. Das unstrukturierte CAD-Cluster wurde durch eine CAD-Produktstruktur die für jeden Auftrag ausgeprägt wird ersetzt (Bild 5, CAD-Struktur). Sie ersetzt ebenfalls die Vor-Produkt-Stückliste. Weiterhin wurde ein explizites Standardteilemodell eingeführt das mit dem Materialstamm synchronisiert ist. Um die Basis für einen von der Auftragsentwicklung entkoppelten Forschungs- und Entwicklungsprozess zu legen wird ein CAD-Cluster für Forschungs- & Entwicklungskomponenten (Bild 5, F&E CAD-Modell) angelegt und durch sog. „Cross Model Based On Clone“ mit der CAD-Produktstruktur verknüpft. Vom F&E Modell in die CAD-Produktstruktur übernommene Module werden somit kopiert, behalten jedoch einen Link zur ihrem Ursprung. Damit sind sie einerseits entkoppelt können aber informationstechnisch auf ihren Ursprung zugreifen. Dadurch ist technisch gewährleistet, dass Neuerungen im F&E Modell einfach ins CAD-Produktmodell fließen können.

Organisatorisch wird dies über „Owner“ der Module umgesetzt die über Aufträge hinweg für ein jeweiliges Modul verantwortlich sind. Dieses Konzept gibt dem Unternehmen die Flexibilität Module unabhängig vom konkreten Kundenauftrag früher zu planen und diese auch besser gemeinsam in verschiedenen Produkten zu nutzen.

Kern des neuen Konzepts ist die Implementierung eines automatisierten Prozesses zwischen CAD-Struktur, Stamm-Stückliste und Materialstamm. Die CAD-Struktur wird als das führende Modell definiert. Ein neu angelegtes CAD-Modell erzeugt automatisch eine Entsprechung im Materialstamm. Damit wird das Problem der bisher nicht synchronisierbaren Stücklisten und Konstruktionsdaten behoben und es wird möglich jederzeit aus der Produktstruktur eine Stammstückliste automatisiert abzuleiten. Um diesen Ansatz umzusetzen musste das Informationsmanagement sowie die bisherige Arbeitsweise umgestellt werden.

Bild 5: Lifecycle Map „Future State“

Die Modelle wurden derart semantisch verändert, dass die Elemente in der CAD-Produktstruktur eindeutige Entsprechungen in den anderen Teilmodellen haben (Bild 5, Detail 1, Model Type Alignment). Dabei wurde die ursprünglich funktionale Struktursemantik der CAD-Produktstruktur in eine logistisch orientierte Semantik überführt. Um die Eindeutigkeit jederzeit zu gewährleisten wurden relevante Zuordnungsfälle zwischen den Modellen herausgearbeitet und jeweils eine spezifische Lösung definiert. Als ein Zuordnungsfall seien beispielhaft Profilstangen genannt. Diese werden in unterschiedlichen Längen verbaut. In der CAD-Produktstruktur werden die tatsächlich verbauten Längen modelliert. Im Materialstamm sind lediglich kaufbare Standardlängen verzeichnet. Um eine eindeutige Zuordnung zwischen den Modellen zu ermöglichen musste für Stangen in der CAD-Produktstruktur die Möglichkeit geschaffen werden die Teillängen für aus der CAD-Produktstruktur folgende zu disponierenden Profilstangen zu definieren.

Erst mit den Lösungen für die Zuordnungsfälle wurde es möglich die Versorgungsrichtung umzukehren und sowohl den Materialstamm als auch die Strukturstückliste von der CAD-Produktstruktur aus zu steuern. Der umgekehrte Fall, dass Änderungen vom Materialstamm initiiert werden, wird grundsätzlich ausgeschlossen. Durch die Umstellung der Struktursemantik der CAD-Produktstruktur hin zu einer logistischen Ausrichtung wird darüber hinaus die Ausleitung eines logistisch orientierten 3D-Modells (im Diagramm nicht dargestellt) möglich, das in dieser Form als Basis für Montage und Reparaturen der Servicemitarbeiter vor Ort beim Kunden eingesetzt werden kann.

Weiterführende Optimierung

Der Future State in Bild 5 dient aktuell als Grundlage weiterer Optimierung. Er wurde damit zum Ist-Zustand aus dem ein neuer Soll-Zustand abgeleitet wird. Potenziale liegen u.A. in einer noch genaueren Klärung des Zusammenwirkens des F&E Modells mit der CAD-Produktstruktur (Bild 5, Detail 2). Aktuell werden die Modelle fachlich von einer Person zusammengehalten und die Module mit Verweis auf ihren Ursprung kopiert. Hier kann eine Verbesserung vorgenommen werden wenn es gelingt dieselben Module zu verwenden und diese jeweils kontextspezifisch anzupassen. Darüber hinaus liegt noch erhebliches Einsparungspotenzial in der noch konsequenteren Nutzung dieser Module über Produkte und Produktlinien hinweg. Zur Umsetzung ist aber vorab eine genauere Analyse des Produktspektrums notwendig um zu definieren welche Informationen in den jeweiligen Modulen kontextabhängig, also für das jeweilige Produkt, angepasst werden müssen und welche generisch gehalten werden können.

Fazit und Ausblick

Am beschriebenen Beispiel ist erkennbar, dass sich die Optimierung der Produktion grundsätzlich von der Optimierung des PEP unterscheidet. In der Produktion fokussiert Optimierung wesentlich auf dem Einsparen personeller Kapazitäten. Im PEP fokussiert Optimierung auf einer intelligenten, kontext- und zeitbezogenen Vernetzung der Informationen. Die Optimierung gelingt dabei durch die Paarung informationstechnisch verbesserter Informationsflüsse in Kombination mit einer organisatorischen Klärung von Verantwortlichkeiten der im PEP entstehenden Informationen entlang ihres Lebenszyklus.

Der Einsatz der PLM-ML ermöglicht es den PEP einer Optimierungsdiskussion zugänglich zu machen. Ihre Diagramme sind unabhängig von ggf. später einzusetzenden IT-Systemen so dass die Diskussion anbieterneutral und systemunabhängig geführt werden kann. Im Rahmen des Do(PLM)Con Beratungsansatzes kann die PLM-ML einen weiteren Vorteil ausspielen. Da mit ihr über die rein funktionelle Sicht hinaus auch Semantik und zeitliche Entwicklung der relevanten Informationen des PEP abgebildet werden kann lässt sich mit ihrer Hilfe die Einführung geeigneter IT-Systeme viel präziser und systematischer planen als es aktuell möglich ist (vgl. Fischer, Brinkmeier 2012).

Referenzen

Fischer, Jörg W. u.a.: Implementierung domänenintegrierender PLM-Lösungen. Do(PLM)Con – ein Ansatz zur Konzeption und Realisierung domänenintegrierender PLM-Lösungen. In: Industrie Management, Berlin, 27(2011)5, S. 17-21.

Fischer, J.W., Brinkmeier, B.: Do(PLM)Con – Proposal of a taxonomy for the development of PLM-Architectures. In: ProductDataJournal, (2012)1, S. 24-28

Eigner, M.: PLM versus PPS: Zukünftige Lösungen für ein durchgängiges Produkt- und Prozessmanagement, In: eDM Report; electronic Data Management, Hoppenstedt Publishing, Darmstadt, (2012) 1, S. 20-23.

Keller, G.; Nüttgens, M.; Scheer, A.-W.: Semantische Prozeßmodellierung auf der Grundlage „Ereignisgesteuerter Prozeßketten (EPK)“, in: Scheer, A.-W. (Hrsg.): Veröffentlichungen des Instituts für Wirtschaftsinformatik, Heft 89, Saarbrücken 1992. (http://www.iwi.uni-sb.de/iwi-hefte/heft089.pdf)