Muster erkennen wo andere Chaos sehen
Der Produktentstehungsprozess tritt in den Optimierungsfokus
Optimierung und operative Gestaltung der Produktion sind heute selbstverständlich. Das Engineering im Produktentstehungsprozess (PEP) wurde jedoch aufgrund seiner Komplexität lange Zeit von der Optimierung ausgenommen. Dies hat sich auch mit der Diskussion um Product Lifecycle Management (PLM) nur wenig geändert. PLM ist in der aktuellen Diskussion häufig auf ein IT-Thema beschränkt. Effekte, die im operativen Umgang mit den im PEP erzeugten Informationen entstehen – im Weiteren als Lebenszykluseffekte bezeichnet -, werden zumeist als nichtexistent abgetan. Oft wird von PLM-Lösungen gefordert, dass alle von den Anwendern als negativ wahrgenommene Folgen dieser Effekte durch die Installation einer Software aufzulösen sind. Lebenszykluseffekte sind jedoch immanente Bestandteile des PEP, deren Durchdringung, Verständnis und geeignete Handhabung eine notwendige Voraussetzung für ein erfolgreiches Engineering darstellen. Lebenszykluseffekte zeigen sich durch Muster in Lifecycle Maps. Ist ein solches Muster gefunden, dann kann auch eine passende organisatorische Lösung für dieses konzipiert und unterstützt durch ein PLM-System umgesetzt werden.
Wechselwirkungen im Produkt-Lebenszyklus
Um die Effekte, die im operativen Umgang zwischen den im PEP erzeugten Informationen auftreten zu verstehen ist es notwendig, sich die heutige Produktentwicklung vor Augen zu führen. Inzwischen werden alle wesentlichen Produkt- und Produktionsaspekte mit Rechnermodellen vorab untersucht. Das bedeutet, dass im Tagesgeschäft des PEP an verschiedensten Produktmodellen in einer Vielzahl unterschiedlicher Applikationen und Systemen simultan gearbeitet wird. Da alle diese Modelle Aspekte desselben Produkts abbilden, haben sie eine hohe Redundanz. Erkenntnisse zum Produkt aus einem Modell beeinflussen demzufolge viele der abhängigen Modelle. Bei einer modularen, auf Wiederverwendung gleicher Komponenten in unterschiedlichen Produkten beruhenden Entwicklung, verstärkt sich die Abhängigkeitsproblematik noch.
Um sich dies zu verdeutlichen, ist nachfolgende Analogie hilfreich. Jedes Modell, das vom Produkt in einer Applikation (sei es ein CAD-System, Simulation, Excel, PLM-System etc.) abgebildet wird, ist mit einer Kiste, in der sich Bälle befinden, vergleichbar. Die Bälle in den Kisten stehen für die modellspezifischen Informationen (z.B. die Teile, Baugruppen oder Komponenten des Produkts). Die Bälle innerhalb einer Kiste sind explizit strukturiert und vernetzt. Diese Vernetzung ist damit sicht- und handhabbar. Zwischen den Bällen bestehen Kistenübergreifend Abhängigkeiten, d.h. sie sind durch „unsichtbare“ Schnüre implizit vernetzt (siehe Bild 1). Zieht man an einen Ball, dann zieht man -oft unwissend- auch an einer unsichtbaren Schnur und beeinflusst Bälle in den anderen Kisten. Übersieht man nur eine solche Auswirkung entstehen schnell hohe Kosten. So wurde bei einem Automobilzulieferer eine vom Kunden geforderte Konstruktionsänderung in den Konstruktionsmodellen angepasst, jedoch nicht in den Modellen der Qualitätssicherung. Gutteile wurden über mehrere Tage aufgrund veralteter Unterlagen der Qualitätssicherung als Ausschuss deklariert und verschrottet. Der entstandene Schaden ging in die Millionen. Dokumentiert werden solche Fälle selten. Sie erreichen, wenn es sich vermeiden lässt, auch das Management im eigenen Unternehmen nicht.
Bild 1: Die Analogie von Kisten die durch unsichtbare Schnüre verbunden sind
Lebenszykluseffekte zu verstehen und mit diesen organisatorisch geeignet umzugehen hat demnach hohe Priorität. Sie sind jedoch den meisten Akteuren im PEP nicht bewusst. Oft erfolgt -wenn die Probleme zu groß werden- der Ruf nach neuen, noch mächtigeren Softwaremodellen, die dann zusätzlich zu handhaben sind und das Problem letztendlich verschärfen. Bisher werden bei PLM-Projekten die Auswirkungen der Lebenszykluseffekte i.d.R. nicht erkannt und daher oft nicht berücksichtigt. Ursache hierfür ist die Vorbereitung von PLM-Systemen in Testumgebungen der IT-Abteilungen. An den dort vorhandenen Testdaten wird nicht operative gearbeitet. Somit treten die Lebenszyklusaspekte dort auch nicht auf.
Lifecycle Mapping
Mit dem Lifecycle Mapping der Do(PLM)Con Methode [1,2] können Landkarten des zeitabhängigen Informationsflusses zwischen den Modellen des PEP erstellt werden. Mit ihrer Hilfe lassen sich Muster wiederkehrender Lebenszykluseffekte lokalisieren, verstehen und entsprechend der individuellen Unternehmensanforderungen gestalten. Dabei lässt sich oft feststellen, dass in unterschiedlichen Domänen ein vergleichbares Verhalten innerhalb des Lebenszyklus auftritt.
Muster erkennen wo andere Chaos sehen – Beispiele für Lebenszykluseffekte
In Bild 2 sind Beispielhaft die Lifecycle Maps zweier typischer Lebenszykluseffekte aufgezeigt (für weitere Beispiele siehe [3]). Der Lebenszykluseffekt 1, die nebenläufige Fortentwicklung (Concurrent Progression), beschreibt den Fall eines Nachfolgeumfangs auf Basis der Informationen, die aus einem Vorgängerumfang abgeleitet werden. Daraus ergeben sich zwei parallele Lebenszyklen mit zu Beginn sehr ähnlichen oder deckungsgleichen Informationen, die sich über den Zeitverlauf mehr und mehr voneinander trennen. Nebenläufige Fortentwicklung lässt sich am Beispiel von Produktstrukturen gut erläutern (Bild 2, Detail 1). Das Produkt 0814 ist der Vorgänger von Produkt 0815. Die Produktstruktur 0815 wird aus der Struktur des Produkts 0814 abgeleitet. Beide teilen sich gemeinsame Baugruppen. Die Übereinstimmung dieser gemeinsamen Baugruppen nimmt jedoch über die Zeit durch produktspezifische Anpassungen ab. Je mehr Zeit vergeht und je stärker die Auswirkung produktspezifischer Anpassungen ausfallen, desto schwieriger wird es, die Veränderungen in den separierten Lebenszyklen konsistent zu halten. Im geschilderten Beispiel lassen sich die Verbesserungen des Vorgängerprodukts 0814, die beispielweise durch Rückmeldungen des Services angestoßen wurden, nur mit zusätzlichem Aufwand in der Produktstruktur 0815 zu übernehmen.
Bild 2: Beispiele für Lebenszykluseffekte
Der Lebenszykluseffekt 2, die Lifecycle Sandbox beschreibt den Fall in dem ein Umfang von Informationen in einem entkoppelten Planungsbereich entstehet und nach Erreichen eines gewissen Reifegrads in einen formalisierten Bestand integriert bzw. mit einem vorhandenen Bestand abgeglichen werden muss. Lifecycle Sanboxes sind ein typischer Lebenszykluseffekt im PEP, da sie beim Einsatz von Insellösungen von selbst entstehen. Ein einfaches Beispiel für Lifcycle Sanboxes sind Excellisten, die sich Mitarbeiter als Exporte aus den PDM- oder ERP-Systemen generieren, um dann eine Zeitlang auf Basis dieser Listen offline weiterzuarbeiten. Solchen Sandboxes liegt dann ein hohes Gefahrenpotenzial zugrunde, wenn sie von den entsprechenden Mitarbeitern nicht hinreichend mit dem gültigen Datenbestand im PDM-System synchronisiert werden. In den letzten Jahren wurde, zumeist unter dem Motto „keine redundanten Datenhaltung“ versucht, Lifecycle Sandboxes mittels einer geeigneten PLM-Strategie zu vermeiden. Oft unerkannt blieb dabei, dass es notwendige Lifecycle Sandboxes gibt d.h. Sandboxes, die aus Prozesssicht unverzichtbar sind.
Ein Beispiel einer notwendigen Sandbox (Bild 2, Detail 2) kommt aus der Fahrzeugelektronik. Steuergeräte kommunizieren mit Hilfe von Signale über den CAN-BUS eines Fahrzeugs. Um die Gefahr der Doppelnutzung von Signal-ID’s im Fahrzeug zu verhindern, brauchen Automobilunternehmen ein Signalmanagement d.h. einen Datenbestand der gültigen Signale sowie einen formalen Beantragungsprozess für eine Signal-ID.
In der frühen Phase des PEP muss die Planung der Elektronik schnell erfolgen können. Demnach ist es für den Planer notwendig, Signale ad hoc ohne formale Hürden erstellen zu können. Für diesen Fall eignet sich der Einsatz einer Lifecycle Sandbox. Zu Beginn der Arbeit befüllt der Planer die Sandbox mit ihm bekannten Signalen der Signaldatenbank. Neue Signale lassen sich vom Planer in der Sandbox frei definieren. Hat die planerische Arbeit eine entsprechende Reife erlangt, erfolgt ein formaler Abgleich der Plandaten in der Sandbox mit den Signalen im zentralen Datenbestand. Für jedes vom Planer neu angelegte Signal wird nun nach einem vergleichbaren, u.U. bereits vorhandenen und somit auch nutzbaren Äquivalent gesucht. Wurden keine Übereinstimmungen gefunden, wird für das als neu eingestufte Signal eine entsprechende Bereitstellung beantragt.
In fachlich unterschiedlichen Domänen tauchen häufig gleiche oder ähnliche Lebenszykluseffekte auf. Sie lassen sich -vorausgesetzt sie werden als ähnlich erkannt- auch mit den gleichen PLM-Lösungskonzepten optimieren. Ein solches PLM-Lösungskonzept besteht dabei aus einem organisatorischen Konzept und einer gestalteten Datensemantik. Als technische Grundlage zur Realisierung des Konzeptes dienen geeignete Funktionen eines PLM-Systems.
Um ein erfolgreich etabliertes PLM-Lösungskonzept tatsächlich mehrfach einsetzen zu können ist es notwendig, die relevanten Einsatzorte im PEP für diese zu lokalisieren. Damit ist Lokalisierung relevanter Einsatzorte die Voraussetzung, vergleichbare Lebenszykluseffekte in den verschiedenen Domänen des PEP erkennen zu können. An dieser Stelle sind Lifecycle Maps (LIF-Maps) ein geeignetes Werkzeug. Nachfolgend ist die Lokalisierung von Lebenszykluseffekten Beispielhaft an einer LIF-Map für den Use Case „Lastenheft Austausch“ erläutert (Bild 3). Darin wird gezeigt, welche der oben beschriebenen Lebenszykluseffekte auch in der Domäne Anforderungsmanagement auftreten.
Der Use Case „Lastenheftaustausch“ im Anforderungsmanagement
Der Use Case „Lastenheft Austausch“ findet zwischen OEM und Tier 1 Suppliern statt. Im gezeigten Falle handelt es sich beim Tier 1 Supplier um einen Getriebehersteller.
Bild 3: Die Lifecycle Maps des Use Case „Lastenheftaustausch“
Im Rahmen einer Ausschreibung für ein Getriebe werden die Anforderungen des OEM an den Tier 1 Supplier übergeben (Bild 3, Detail A). Um die übergebenen Anforderungen im jeweils gültigen Stand verwalten zu können, werden sie beim Tier 1 Supplier in einem eigenen Modell vorgehalten (Bild 3, übergebene Kundenanforderungen). Die Kundenanforderungen werden in einem nächsten Schritt vom Tier 1 Supplier bewertet. Die Bewertung wird in einem getrennten, sich im Zeitverlauf parallel entwickelnden Modell dokumentiert. Die Anforderungen in den beiden Modelle werden dabei entsprechend verlinkt (Bild 3, Detail B). Eine Bewertung erfolgt auf Basis des Datenbestandes bereits erfüllter Anforderungen von ähnlichen Getrieben. Die relevanten Anforderungen werden ausgewählt und ins Modell der bewerteten Kundenforderungen übernommen (Bild 3, Detail C). Im Verlauf der Anfrage werden regelmäßig veränderte Anforderungen des OEM’s an den Tier 1 Supplier übergeben (dargestellt in Bild 3, Detail D). Sind alle Anforderungen bewertet, werden odiese an den OEM zurückgespielt (Bild 3, Detail E). In der Folge finden Vertragsverhandlungen statt. Sind diese erfolgreich, werden zwischen OEM und Tier 1 Supplier die für das Projekt gültigen Anforderungen festgelegt, welche sich aus einem Abgleich der bewerteten Anforderungen mit den Anforderungen des OEM ergeben (Bild 3, Detail F). Die gültigen Projektanforderungen unterliegen ab diesem Zeitpunkt einem formalen Änderungsmanagement (im Bild 3 nicht vermerkt).
Lokalisierung von Lebenszykluseffekten im Use Case „Lastenheftaustausch“
In der diskutierten Lifecycle Map (Bild 3) lassen sich Muster erkennen, die den in Bild 2 gezeigten Lebenszykluseffekten ähnlich sind.
Der Austausch des Lastenheft zwischen OEM und Supplier ist der Cuncurrent Progression ähnlich. Die Anforderungen des OEM’s entwickeln sich im Vergleich zu den bewerteten Anforderungen in zwei getrennten aber synchronisierten Lebenszyklen. Dies entspricht einer Concurrent Progression. Diese setzt jedoch auch eine Anpassung bezogen auf den Kontext (z.B. Bezug zwischen zwei verschiedenen, aber ähnlichen Produkten) voraus. Ist dies nicht der Fall, ist keine hinreichende Übereinstimmung gegeben.
Bild 4: Die Lebenzykluseffekte im Use Case „Lastenheftaustausch“
Das Muster, das sich zwischen dem Datenbestand der bereits erfüllten Anforderungen, der bewerteten Anforderungen und der übergebenen Kundenanforderungen zeigt, ist interessanter. Es handelt sich hierbei um eine notwendige Lifecycle Sandbox. In Bild 4 wird dies durch die zusammengefasste Darstellung der Kundenanforderungsmodelle noch deutlicher. Der Datenbestand der erfüllten Anforderungen ist der formalisierte Bestand. Die übergebenen Anforderungen und deren Bewertung werden in der Sandbox verwaltet. Die Sandbox wird mit vergleichbaren, bereits erfüllten Anforderungen initialisiert. Ab diesem Zeitpunkt wird in der Sandbox gearbeitet. Die Anforderungen können nun problemlos verändert werden, ohne dass dies Auswirkungen auf den formalisierten Bestand hat. Sind die Anforderungen für das Projekt festgelegt (Bild 4, gültige Anforderungen im Projekt), kann die Sandbox mit dem formalisierten Bestand abgeglichen werden. Dabei lassen sich drei Fälle unterscheiden. Im ersten Fall entspricht die Anforderung der Sandbox einer bereits erfüllten Anforderung. Im zweiten Fall handelt es sich um eine neue Anforderung. Diese kann, sobald sie gelöst ist, in den formalisierten Bestand übernommen werden. Im dritten Fall ist die Anforderung einer vorhandenen ähnlich aber nicht gleich. Demnach muss entschieden werden, ob die Erweiterung einer bereits im Bestand vorhandenen Anforderung ausreichend ist oder eine neue angelegt werden soll.
Fazit und Ausblick
Das oben erläuterte Beispiel zeigt, dass Lebenszykluseffekte in verschiedenen Anwendungsfällen und Domänen ähnlich auftreten. Gelingt eine Lokalisierung derartiger Muster in verschiedenen Domänen und Anwendungsbereichen, lassen sich zwei wesentliche Vorteile ableiten.
Zum einen haben damit PLM anwendende Unternehmen die Möglichkeit, ein organisatorisches Konzept für einen Effekt zu konzipieren und dieses mehrfach zu nutzen. Zum andern können Lösungsanbieter generische PLM-Funktionalität für die bekannten Effekte anbieten. Diese müssen dann nur einmal pro Effekt und nicht für jede Anwendung und jeden Kunden neu implementiert werden.
Originalquelle:
FISCHER, Jörg W.; Dietrich Ute:
Muster erkennen wo andere Chaos sehen.
Warum das „L“ im Product Lifecycle Management oft vergessen wird
In: ProduktDatenJournal,
Darmstadt, 21(2014)1, S.66-69.
(ISSN: 1436-0403)
Quellen:
- FISCHER, Jörg W.; LAMMEL Bernhard; HOSENFELD Dirk; BAWACHKAR Deodatt; BRINKMEIER Bernd: Do(PLM)Con: An Instrument for Systematic Design of Integrated PLM-Architectures. In: Smart Product Engineering.Hrsg.: ABRAMOVICI, Michael and STARK, Rainer. Heidelberg: Springer 2013. S. 211-220
- FISCHER, Jörg W.; REBEL, Martin; LAMMEL, Bernhard; GRUBER, Jürgen: Systematic optimization of the Product Development Process with PLM-ML. In: ProductDataJournal, Darmstadt, 19(2013)1, S.48-52.
- FISCHER, Jörg W.; STOWASSER, Sascha: Industrial Engineering und Lean Product Development. In: Industrial Engineering, Fachzeitschrift des REFA-Bundesverbandes, Darmstadt, 66(2013)2, S.20-27.
