Lifecycle Mapping – PLM verstehen und gestalten – gezeigt an einem Praxisbeispiel des Anforderungsmanagements
1. Warum die Informationsentwicklung im PEP gestaltet werden muss
Die Gestaltung schlanker Produktionssysteme und Optimierung globaler Lieferketten zur Steigerung der Produktivität ist heute Kern jeder Unternehmensstrategie. Der Fokus der Optimierung wendet sich zunehmend dem Produktentstehungsprozess zu, da die Erkenntnis wächst, dass dessen geeignete Gestaltung eine zentrale Voraussetzung ist, um auch zukünftig erfolgreich am Markt zu agieren.
Durch die drastischen Veränderungen der Produktentstehung wird dies aktuell immer dringlicher. Zum einen werden Produkte durch Integration intelligenter Komponenten und steigender Variantenvielfalt komplexer, zum anderen nehmen die simultan durchzuführenden Tätigkeiten in der Produktentstehung durch Vorverlagerung von Aufgabenbereichen zu. Viele der heute in frühen Entwicklungsphasen stattfindenden Tätigkeiten wurden vor wenigen Jahren später in der Entwicklung mit physikalischen Prototypen durchgeführt. Wo früher Modelle mit Hilfe von Zeichnungen auf Papier erstellt wurden, werden heute Modelle in IT-Applikationen modelliert (z.B. CAx, Digitale Fabrik, Systems Engineering etc.). Aktuell erleben wir eine geradezu explosionsartige Zunahme der verwendeten, modellbasierten Applikationen im PEP (siehe Bild 1).
Da alle im PEP erstellten Modelle Abstraktionen der zu entwickelnden Produkten sind, haben sie vielfältige Redundanzen. Weil Modelle im Zeitverlauf des PEP häufig simultan erstellt werden, entstehen Wechselwirkungen zwischen den Modellen, so dass ihre Informationen kontinuierlich abgeglichen werden müssen.
Dies ist den meisten Akteuren im PEP nicht bewusst. Oft erfolgt – wenn die daraus resultierenden Probleme zu groß werden – der Ruf nach neuen, noch mächtigeren Modellen, die dann zusätzlich zu handhaben sind. In der Folge wird der PEP noch komplexer.
Bild 1: Die Modellexplosion im ProduktentstehungsprozessDie aktuelle Situation rund um PEP und PLM ist vergleichbar mit der Diskussion im Produktionsmanagement Anfang der 80’er Jahre des letzten Jahrhunderts. Die Automatisierung hatte sich weitgehend durchgesetzt. Auf dieser Basis konnte sich dann die Diskussion um Lean Management entwickeln. Nachdem durch erfolgreiche Einführung von PLM-Komponenten viele Routineprozesse des PEP heute erfolgreich automatisiert wurden, wächst auch in der PLM Diskussion die Überzeugung, dass eine konsequente Gestaltung der Informationsentwicklung im PEP ein nächster Schritt zum Erfolg von PLM sein wird.
2. Die Idee des Lifecycle Mappings
Lifecycle Mapping nahm seinen Ursprung in Diskussionen erfahrener PLM Solution Architekten. Bei den von ihnen betrachteten Anwendungsfällen verschiedener Branchen und Unternehmen zeigte sich, dass das operative Zusammenwirken der Produktinformationen in der Vergangenheit nicht diskutiert wurde. Aus diesem Grund werden bei der Planung von PLM-Projekten wesentliche Aspekte oft nicht berücksichtigt. Dies gefährdet mitunter PLM-Projekte, da das gemeinsame Verständnis von Anbieter, Projektteam und den Endanwendern nicht geschaffen wird.
Lifecycle Mapping ermöglicht es, die operative Informationsentwicklung im PEP zu analysieren. Fokus der Modellierung liegt dabei auf den tatsächlich in den IT-Systemen lebenden Modelle des PEP’s. Um die Modellierung einfach zu machen, setzt Lifecycle Mapping auf eine IT-neutrale Symbolik, die der Denkweise des Wertstromdesign verwandt ist.
Mit Hilfe von Lifecycle Maps (LIF-Map’s) können Landkarten des PEP dargestellt werden. Diese dienen als zentrales Kommunikations- und Optimierungsinstrument in PLM-Projekten und tragen wesentlich dazu bei „über das gleiche zu sprechen“.
3. Lifecycle Maps erstellen
In der Anwendung werden LIF-Map`s vom vorliegenden Current State sowie einem oder mehreren zu entwickelnden Future States angefertigt. In PLM-Projekten hat es sich als geeignet erwiesen, gemeinsam mit allen Beteiligten zum Start des Projekts die LIF-Map des Current State zu entwickeln und sich die Zeit zu nehmen, diese ausführlich zu besprechen. Dadurch entsteht ein gemeinsames Verständnis, was im PEP geschieht. In einer weiteren Diskussion können in der Current State LIF-Map Bereiche mit Optimierungspotenzial eingezeichnet werden. Ist dies erfolgt, werden mögliche Optimierungsszenarien anhand von Future States LIF-Map’s entwickelt.
Bild 2: Lifecycle Map eines einfachen Current StateNachfolgend wird das Vorgehen beim Lifecycle Mapping am Beispiel eines einfachen Current State erläutert (Bild 2). Basis der Lifecycle Map ist die Zeitachse. Auf ihr werden die für die Betrachtung, wesentlichen Meilensteine des PEP’s notiert. Im nächsten Schritt werden die lebenden Teilmodelle als Rechtecke in die LIF-Map eingezeichnet. Hier ist es sinnvoll, sich auf Teilmodelle eines Produkts bzw. einer Produktfamilie zu konzentrieren. Die Rechtecke beginnen zu dem Zeitpunkt, an dem sie im PEP erstmalig initiiert werden. Ihre Länge über den Zeitstrahl symbolisiert ihre zeitliche Entwicklung. Strenggenommen endet ein Teilmodell nicht, da die Daten über den Produktentstehungsprozess hinaus vorgehalten und auch „fertige“ Teilmodelle oft zu einem späteren Zeitpunkt noch geändert werden. Das Rechteck in der Lifecycle Map endet daher zu dem Zeitpunkt, an dem die Arbeit am Teilmodell im Wesentlichen abgeschlossen ist. Falls es notwendig ist, den Aspekt des „Weiterlebens“ darzustellen, wird ein verkleinertes, gefülltes Rechteck und/oder eine über den Zeitstrahl weiterführende Linie verwendet. Die geringere Breite steht für die geringere Arbeitsintensität am Teilmodell (Bild 2, Darstellung der Modellierungsintensität). Bei der Analyse von LIF-Map’s ist es wichtig, vorab einen Fokus zu definieren und diesen einzuhalten. Droht die Fachdiskussionen dennoch über diesen Fokus hinauszugehen, kann dies mit der „Out of Scope-Wolke“ (Bild 2) verhindert werden. Mit ihr lassen sich Aspekte außerhalb des Fokus in der LIF-Map verzeichnen. Damit ist in der Diskussion jederzeit klar, dass es diesen Bereich gibt, er aber nicht in der aktuell zu erstellenden Landkarte mitdiskutiert wird.
Bei der Analyse des PEP mit Hilfe von Teilmodellen ergeben sich zwei wesentliche Betrachtungsaspekte, zum einen die Entwicklung des Teilmodells an sich (d.h. was innerhalb der gezeichneten Rechtecke geschieht) und zum andern die Interaktion zwischen den Teilmodellen über den zeitlichen Verlauf des PEP. LIF-Map`s bilden den zweiten Aspekt, die Interaktion zwischen Teilmodellen ab. Der erste Aspekt wird mit Hilfe anderer Do(PLM)Con Diagramme untersucht und ist nicht Gegenstand dieses Artikels. Zur Darstellung der Interaktion von Teilmodellen werden in der LIF-Map unterschiedliche Verbindungslinien (Linien, Pfeile, gestrichelte Pfeile etc.) sowie diesen zugeordnete Übergangssymboliken genutzt. Die Verbindungslinien beschreiben, wie die Informationen zueinander in Beziehung stehen bzw. gesetzt werden (Bild 2, Verknüpfung vs. Ausleitung). Die Übergangssymbolik zeigt, wie die Verknüpfung organisiert wird. Die in Bild 2 dargestellten Übergangssymbole bedeuten beispielweise, dass die Verbindung zwischen den Modellen von einer verantwortlichen Person aufrechterhalten wird und dass an der Stelle eine semantische Integration der Daten durchgeführt wird. Wie dies genau geschieht kann z.B. mit Hilfe der PLM-ML Semantic Map im Detail analysiert werden. Für weitere Symboliken sei auf das unten beschriebene Beispiel verwiesen.
4. Abgrenzung von Teilmodellen
Ein wichtiger Aspekt beim Lifecycle Mapping ist die Identifikation und geeignete Abgrenzung der relevanten Teilmodelle. Nachfolgend wird diese näher betrachtet. In LIF-Map`s werden die für die Betrachtung relevanten lebenden Teilmodelle, d.h. konkret Teilmodellinstanzen eingezeichnet. Eine Teilmodellinstanz ist z.B. die Produktstruktur mit geometrischen CAD-Daten des Produkts A (siehe Bild 3, die Teilmodellinstanz Geometriemodell Produkt A), eine weitere wäre z.B. die des Produkts B. Zur Instanz gibt es wie in der Informatik den Teilmodelltyp, also „Produktstruktur mit CAD Daten“. Dabei ist zu beachten, dass sich die Begriffe Instanz und Typ bei Teilmodellen des PEP nicht in der Eindeutigkeit verwenden lassen, die in der Informatik üblich ist.
Die Abgrenzung von Teilmodellen ist der Abgrenzung von Teilvorgängen in der Montage ähnlich. Ein Teilvorgang wird in einer für den Analysefall hinreichenden Granularität gebildet. Wird im Verlauf der Planung die Notwendigkeit erkannt, den Teilvorgang feingranularer abzugrenzen, kann dies problemlos erfolgen. Die Planung beginnt z.B. mit dem Teilvorgang Schraube befestigen. Dieser kann -falls notwendig- zu den Teilvorgängen Schraube aufnehmen, Schraubenschlüssel nehmen, Schraubenschlüssel ansetzen etc. detailliert werden.
Analog ist das Vorgehen bei der Abgrenzung von Teilmodellen. Im ersten Schritt einer Analyse können als Teilmodelle die in den vorhandenen IT-Systemen lebenden Produktstrukturen angenommen werden (Bild 3, die drei Modelle auf der linken Seite). Zeigt sich während der Modellierung, dass eine als Teilmodell angenommene Struktur mehrere relevante Teilmodelle enthält, die getrennt betrachtet werden sollten, kann für jedes ein eigenes Rechteck in der LIF-Map modelliert werden.
Bild 3: Abgrenzung von TeilmodellenZum Verständnis einige konkrete Beispiele: Über den Zeitverlauf des PEP werden von Produktstrukturen oft sog. Baselines abgeleitet. Eine Baseline friert einen zeitlichen Zustand der Struktur ein. Je nach Modellierungsfall kann die Baseline als integrierter Bestandteil des Teilmodells „Produktstruktur“ oder als eigenes Teilmodell „Baseline“ gesehen werden. Ein zweites Beispiel sind Variantenoptionen. Oft werden diese in IT-Systemen an logistischen Produktstrukturen gepflegt. Es entsteht dann der Eindruck, es läge ein Teilmodell „Produktstruktur incl. Variantenoptionen“ vor. Dies ist jedoch nicht der Fall. Die Produktstrukturinstanz enthält aus einer Gesamtmenge von möglichen Optionen die in ihrem Kontext gültigen. Es muss also ein Teilmodell „Gesamtmenge an Optionen“ existieren. Die in der Produktstruktur enthaltenen Optionen sind demnach aus dem Teilmodell „Gesamtmenge“ als Teilmenge extrahiert und werden dann z.B. als Kopie oder Link in die Produktstruktur eingebracht.
Die Abgrenzung von Teilmodellen klingt in der theoretischen Beschreibung schwierig. Die praktische Erfahrung zeigt jedoch, dass die Abgrenzung einfach, fast intuitiv ausgeführt werden kann. Das liegt daran, dass die Teilmodelle Abstraktionen dessen sind, womit die am PEP Beteiligten täglich arbeiten. Hilfreich zur Abgrenzung ist die in Bild 3 genannte Leitlinie: Die Informationen in einem Teilmodell sind inhaltlich zusammenhängend, besitzen eine starke Konnektivität und haben ein ähnliches Zeitverhalten.
5. Erstellung einer Lifecycle Map für das Anforderungsmanagement
Nachfolgend wird beispielhaft eine LIF-Map für den Use Case „Lastenheft Austausch“ erläutert (siehe Bild 4, Detail A-F). Dieser Use Case findet häufig zwischen OEM und Tier 1 Supplier statt. Abgebildet ist der geplante Future State. Die Anforderungen des OEM (Bild 4) werden vom OEM an den Tier 1 Supplier übergeben (Bild 4, Detail A). Die Übergabe erfolgt durch ein elektronisches Dokument und wird manuell zumeist über E-Mail mit Vorankündigung per Telefon abgewickelt. Dies ist Vorgabe des OEM’s. Wie das OEM seine Anforderungen intern verwaltet, ist für die Betrachtung nicht relevant und daher mit der Out of Scope Wolke gekennzeichnet. Um die gestellten Anforderungen im jeweils gültigen Stand verwalten zu können, werden sie beim Tier 1 Supplier in einem eigenen Teilmodell eingepflegt und verwaltetet (Bild 4, Kundenanforderungen). Dabei findet eine Transformation des elektronischen Dokuments in das Format des beim Supplier verwendeten Datenmanagementsystems statt, die von einem Mitarbeiter abgewickelt wird (Bild 4, Detail A Überganssymbolik). Die Kundenanforderungen werden nun vom Tier 1 Supplier bewertet. Die Bewertung wird in einem getrennten, sich im Zeitverlauf parallel entwickelnden Modell vorgenommen, das mit dem Kundenanforderungsmodell verlinkt wird (Bild 4, Kommentierte Kundenanforderungen). Es enthält die Bewertung und Kommentare des Tier 1 Supplier zu den Kundenanforderungen des OEM. Es wird auch geprüft ob Kundenanforderungen bereits von anderen Produkten aus dem Portfolio des Suppliers erfüllt wurden. Dazu werden die kommentierten Kundenanforderungen mit intern definierten Anforderungen vergleichbarer Produkte des Supplier vernetzt, um damit die Anforderungen zu kennzeichnen, für die bereits Lösungen vorliegen (Bild 4, Detail B).
Bild 4: Die Lifecycle Maps des Use Case „Lastenheftaustausch“
Zu zuvor bestimmten Zeitpunkten werden Teilmengen der kommentierten Kundenanforderungen an den OEM zurückgespielt (Bild 4, Event auf Zeitleiste „Antwort an OEM senden“). Die Symbolik ist folgendermaßen zu lesen (Bild 4, Symbole am Pfeil im Detail C): Das „Teilmengensymbol“ steht für die Auswahl einer Teilmenge der Anforderungen, die auszuleiten sind. Das „Zahnrad-Symbol“ deutet an, dass dies automatisiert durch das IT-System geschieht. Das Symbol „Quadrat zu Dreieck“ steht für eine Konvertierung der Daten, das Symbol „beschriebenes Papier“ definiert, dass es sich um ein lesbares Standardformat handelt. Das OEM nimmt die Kommentare auf, passt ggf. seine Anforderungen an und sendet diese angepassten sowie ggf. neu entstandenen Anforderungen zurück (Bild 4, Detail D). Das Vorgehen ist analog der initialen Übergabe der Anforderungen. Der beschriebene Ablauf wiederholt sich mehrfach bis die Anforderungsdiskussionen einen Reifegrad erhalten haben, an dem sie freigegeben werden können und damit abgestimmte Anforderungen vorliegen.
Ist dies geschehen, können Vertragsverhandlungen geführt werden. Diese sind in der LIF-Map lediglich vermerkt. Führen diese zu einem Kundenprojektauftrag, werden die abgestimmten Anforderungen freigegeben und mit einem Freigabestatus versehen (Bild 4, Detail E). Die Anforderungen gehen in der Folge in das Modell Projektanforderungen über, welches die für das Projekt gültigen Anforderungen enthält. An dieser Stelle setzt das Änderungsmanagement ein. Dies wird durch ein Teilmodell abgewickelt, in dem alle Änderungen verzeichnet sind. Gibt es nun Änderungéb der Anforderung seitens des OEM’s, werden diese über einen formalen Änderungsantrag ins Projekt aufgenommen. Die Änderungen und deren Auswirkungen werden dabei im Änderungsmodell detailliert protokolliert und mit den von der Änderung betroffenen Anforderungen im Anforderungsmodell verknüpft.
6 Fazit und Ausblick
LIF-Maps stellen eine einfache Sprache bereit, die es erstmals ermöglicht, über die operative Informationsentwicklung im PEP diskutieren zu können. Alle am PEP beteiligten Personen können diese Sprache mit etwas Übung ohne besondere IT-Kenntnisse verstehen. Mit LIF-Maps können bereits vor einer PLM Einführung organisatorische Aspekte und spezifisches Lebenszyklusverhalten formuliert werden, die sich bei herkömmlichen PLM-Einführung erst beim RampUp des bereits eingeführten PLM-Systems zeigen. Damit wird es möglich, eine echte Optimierungsdiskussion sowohl mit den ausführenden Fachabteilungen, den IT-Abteilungen sowie dem Systemanbieter zu führen.
Das gezeigte Beispiel ist ein Konzept eines Future State, den das betreffende Unternehmen mittels eines PLM-Systems implementieren möchte. Für die Implementierung stellt die Do(PLM)Con weitere Landkarten zur Verfügung, die den Übergang von der LIF-Map zu einem detaillierten IT-Konzept ermöglichen.
Quellenangabe
- Fischer, Jörg W.; Rebel, Martin; Lammel, Bernhard; Gruber, Jürgen: Systematische Optimierung des Produktentwicklungsprozesses mit PLM-ML. In: ProduktDatenJournal, Darmstadt, 19(2013)1, S.58-62.
- 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.: Abramovci, Michael; Stark, Rainer. Heidelberg: Springer 2013. S. 211-220 (Lecture Notes in Production Engineering, Volume 5.)
- 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
Weitere Artikel
- PLM ERP CRM CPQ MES, RIM LinkedIn
- RIM Insights
