PROJEKTMANAGEMENT AKTUELL
pm
2941-0878
2941-0886
UVK Verlag Tübingen
121
2006
174
GPM Deutsche Gesellschaft für Projektmanagement e. V.Ganzheitliches Product Lifecycle Management (PLM)
121
2006
Andreas Karcher
Product Lifecycle Management rückt immer mehr in den Mittelpunkt der Diskussion, wenn es um die IT-Unterstützung komplexer Produktentwicklungs- und Lifecycle-Prozesse geht. Der Beitrag ordnet zunächst den sehr unterschiedlich verstandenen Begriff des Product Lifecycle Management in die verschiedenen unternehmensspezifischen Perspektiven ein und zeichnet die Entwicklungslinie nach. Den Spannungsbogen zwischen Produktzentrierung und eher ressourcenorientiertem PLM-Verständnis sowie zwischen Nutzenpotenzialen auf der einen und der sich aus einer IT-Unterstützung zusätzlich ergebenden Komplexität auf der anderen Seite zeigt der zweite Teil des Beitrags auf. Basis für ein ganzheitliches, IT-gestütztes PLM ist immer ein detailliertes und möglichst formal beschriebenes integriertes Produktmodell, das die heute immer noch dominierende Dokumentenzentrierung ein Stück weit aufweichen muss und dessen Grundidee in Abschnitt 3 ausführlich dargestellt wird, bevor dann auf Architektur und Kernfunktionen von Standardlösungen eingegangen wird. Den Abschluss bildet die inhärente Grundproblematik, dass PLM als strategisches Thema verstanden und umgesetzt werden sollte, was im Umkehrschluss zur Frage führt, wie diese
kontinuierliche Aufgabe systematisch bewältigt werden kann.
pm1740032
3 projekt M A N A G E M E NT 4/ 20 0 6 aktuell ACTANO - Wir vernetzen Menschen, Projekte und Unternehmen www.actano.de • info@actano.de Warum noch länger warten? Steigern Sie die Ergebnisqualität Ihrer Projekte mit RPlan und der Methodik des Kooperativen Projektmanagements. Mehr unter www.actano.de • info@actano.de Nächste Veranstaltung: 9. ACTANO Gesprächskreis am 9. / 10. November 2006 in München Anzeige ment (PLM) - Vom notwendigen Übel bis zum strategischen Erfolgsfaktor. In diesem Heft [3] Geckler, D.: Die Stückliste ist die Mutter aller Daten - Produktdatenmanagement in der Anwendung. In diesem Heft [4] Jungkunz, R. M.: PDM-basierte Überwachung komplexer Entwicklungsprojekte. In diesem Heft [5] Saynisch, M.: Projekt- und Produktlebenszyklus-Management - Teil I: Projekt-, Konfigurations- und Collaboration Management - Die Prozess- und Anwendungswelt. In: Rackelmann, G.; Schelle, H. (Hrsg): Best Practice im Projektmanagement - 21. Internationales Deutsches PM Forum 2004. Nürnberg 2005 [6] Saynisch, M.; Trapp, Th.; Schäfer, W.: Neue Konzepte des Projekt- und Konfigurationsmanagements für die kooperative Produktentwicklung. In: GPM (Hrsg.): Project Management for Winners. 18. internationales Deutsches PM Forum, VisionWorks Congress,. Berlin 2001 [7] Saynisch, M.; Schäfer, W.: Software in technischen Produkten - Eine neue Qualität im Projektmanagement: Die Schlüsselrolle von Konfigurationsmanagement. In: VDI-GSP „Projektmanagement Praxis“. VDI Bericht 1578, Düsseldorf 2000, S. 143-155 [8] Saynisch, M.: Schlüsselfaktor Konfigurationsmanagement (KM) - Lebensfähigkeit in dynamischen, globalen Märkten bei steigender Produkt-Komplexität. In: Saynisch, M.; Lange, D. (Hrsg.): Änderungsmanagement mit System - Schlüsselfaktor Konfigurationsmanagement. 3. Fachtagung Konfigurationsmanagement, Nürnberg 1999, S. 100-127. Info zur Beschaffung des Buches: info@spmconsult.de [9] PMI (Ed.): A Guide to the Project Management Body of Knowledge (PMBoK). Upper Darby, USA, 1996-2000 [10] IPMA: ICB-IPMA Competence Baseline. Bremen 1999 [11] Saynisch, M.: Was ist Konfigurationsmanagement? In: ProjektManagement 2/ 99, Köln 1999, S. 12-25 [12] INCOSE: Systems Engineering Handbook, Vers. 2.0. INCOSE central office, Seattle 2002 [13] Saynisch, M.: Neue Prozesse und IT-Systeme zur Produktentwicklung in dynamischen Märkten - Projekt-, Konfigurations- und Systems-Management. In: Frick, A., et al. (Hrsg.): Konferenz zur Zukunft des Projektmanagements „InterPM 2004“. Nürnberg 2004 [14] Saynisch, M.: Was ist Konfigurationsmanagement? In: HMD - Praxis der Wirtschaftsinformatik, Heft 202, Heidelberg 1998, S. 7-26 [15] Saynisch, M.; Mekelburg, G: Neue Schlüsselfaktoren im Projektmanagement: Projekt-Prozesse-Differenzierung - Projekt-Systeme - Projekt-Office. VDI-Bericht 1578 „Projektmanagement-Praxis“, Düsseldorf 2000, S. 157-168 [16] Hab, G.; Wagner, R.: Projektmanagement in der Automobilindustrie. Wiesbaden 2004 [17] DIN EN ISO 10007: Leitfaden für Konfigurationsmanagement. Berlin 1996 [18] Saynisch, M.; Bürgers, H.: Konfigurations- und Änderungsmanagement. In: GPM (Hrsg.): Projektmanagement- Fachmann PMF III. GPM/ RKW, Eschborn 1998 [19] Saynisch, M.: Die Projektkostenrechnung und ihre Integration mit dem betrieblichen Rechnungswesen. In: Saynisch, M., u. a.(Hrsg.): Projektmanagement - Konzepte, Verfahren, Anwendungen. München-Wien 1979 Schlagwörter Cross Company Collaboration, erzeugnisschaffende Prozesse, Konfigurationsmanagement, Kopplung von Projektservern, Produktdatenmanagement, Produktzentrierte Fortschrittsüberwachung (PZF), Produktzentriertes Projektmanagement, Systems Engineering Autor Die Kurzbiographie des Autors Dipl.-Ing. Manfred Saynisch können Sie am Ende seines ersten Beitrags auf Seite 22 in diesem Heft nachlesen. Anschrift SPM-CONSULT Systeme und Service im Projektmanagement Düppeler Str. 19 D-81929 München Tel.: 0 89/ 93 93 09 51 Fax: 0 89/ 93 93 09 52 E-Mail: saynisch@spm-consult.de PM_4_06.indd 31 26.09.2006 16: 08: 01 Uhr 32 SCHWERPUNKT SCHWERPUNKT aktuell projekt M A N A G E M E NT 4/ 20 0 6 PLM - viel diskutiert, aber noch wenig verstanden Kaum ein Themenkomplex hat in den letzten Jahren gleichzeitig für so viel Aufmerksamkeit, aber auch für so viel babylonische Begriffsverwirrung und Unsicherheit bezüglich Relevanz und Vorgehensweise - insbesondere bei den potenziellen Anwendern - gesorgt wie das Thema Product Lifecycle Management. Dass sich Unternehmen zunehmend der Herausforderung gegenübersehen, die informationstechnische Beherrschung und Optimierung des Produktlebenszyklus als Kernkompetenz zu begreifen, und IT-Unterstützung im Product Lifecycle immer mehr zum strategischen Wettbewerbsfaktor auch und gerade für kleinere und mittlere Unternehmen werden wird, ist mittlerweile akzeptiert und auch durch verschiedene Studien belegt [1]: „Product Lifecycle Management wird in den kommenden Jahren zu einem zentralen Thema im Unternehmen werden.“ (Jack Maynard, Aberdeen Group) Allerdings wird man bereits auf die Frage, was denn PLM nun konkret bedeutet, was sich dahinter genau verbirgt, wie man dieses Thema im Unternehmen „installiert“ und erfolgreich verankert, bereits ganz unterschiedliche Antworten bekommen. Eine sehr allgemeine Definition von PLM ist die der Gartner Group: „Guiding products from concept through retirement to deliver the greatest business value to an enterprise and its trading partners.“ Ein Themenkomplex mit vielen unterschiedlichen Facetten Je nach Blickwinkel, aus dem man PLM betrachtet, ergeben sich ganz unterschiedliche Perspektiven, und das im Kern Zentrale und Schwierigste an der PLM-Thematik ist die Integration all dieser Sichten und Perspektiven zu einem ganzheitlichen strategischen Konzept, umgesetzt auf ganz unterschiedlichen Ebenen. Hier zunächst ein kleiner Ausschnitt an unterschiedlichen PLM-Perspektiven: o CAx-orientiert o Dokumenten-orientiert o Daten-orientiert o EDM/ PDM-orientiert o Geschäftsprozess-orientiert o Projekt-orientiert o Standardsoftware-orientiert o Strategisch/ Management-orientiert o etc. Auch wenn wir hier nicht alle Sichten und Perspektiven in der Ausführlichkeit darstellen können, die zu einem tieferen Verständnis sicherlich erforderlich wäre, wollen wir doch den Versuch wagen, ein wenig Klarheit in das „PLM-Dunkel“ zu bringen. Die technische Perspektive von PLM Aus der Ingenieursicht spielt heute die „Digitalisierung der Produktentwicklung“, das heißt die komplette Beschreibung aller Produkteigenschaften in einem „Integrierten Produktmodell“ sowie die damit mögliche früh- Ganzheitliches Product Lifecycle Management (PLM) Vom notwendigen Übel zum strategischen Erfolgsfaktor Andreas Karcher Product Lifecycle Management rückt immer mehr in den Mittelpunkt der Diskussion, wenn es um die IT-Unterstützung komplexer Produktentwicklungs- und Lifecycle-Prozesse geht. Der Beitrag ordnet zunächst den sehr unterschiedlich verstandenen Begriff des Product Lifecycle Management in die verschiedenen unternehmensspezifischen Perspektiven ein und zeichnet die Entwicklungslinie nach. Den Spannungsbogen zwischen Produktzentrierung und eher ressourcenorientiertem PLM-Verständnis sowie zwischen Nutzenpotenzialen auf der einen und der sich aus einer IT-Unterstützung zusätzlich ergebenden Komplexität auf der anderen Seite zeigt der zweite Teil des Beitrags auf. Basis für ein ganzheitliches, ITgestütztes PLM ist immer ein detailliertes und möglichst formal beschriebenes integriertes Produktmodell, das die heute immer noch dominierende Dokumentenzentrierung ein Stück weit aufweichen muss und dessen Grundidee in Abschnitt 3 ausführlich dargestellt wird, bevor dann auf Architektur und Kernfunktionen von Standardlösungen eingegangen wird. Den Abschluss bildet die inhärente Grundproblematik, dass PLM als strategisches Thema verstanden und umgesetzt werden sollte, was im Umkehrschluss zur Frage führt, wie diese kontinuierliche Aufgabe systematisch bewältigt werden kann. PM_4_06.indd 32 26.09.2006 16: 08: 01 Uhr 33 projekt M A N A G E M E NT 4/ 20 0 6 aktuell zeitige Absicherung von Eigenschaften, die zentrale Rolle, wenn es darum geht, Produkte schneller, kostengünstiger, mit höherem Wiederverwendungsgrad und abgesicherten Qualitätseigenschaften zu entwickeln und über den kompletten Lebenszyklus hinweg informationstechnisch zu begleiten. Stichworte sind hier beispielsweise der Digitale Zusammenbau (Digital Mock-up) kompletter Produkte aus den geometrischen Beschreibungsdaten (CAD) mit der Möglichkeit, im Rechnermodell Kollisionen zu erkennen bzw. zu vermeiden. Mit den verschiedensten modellbasierten Verfahren wie beispielsweise der Finiten Elemente Methode (FEM) können darauf aufsetzend Eigenschaften wie zum Beispiel Festigkeit oder kinematische Eigenschaften „gerechnet“ und optimiert werden. Modellbasierte Simulation ist immer mehr das Mittel der Wahl, wenn es darum geht, in frühen Phasen des Produktlebenszyklus Erkenntnisse über Eigenschaften von Produkten zu gewinnen, wenn diese physikalisch noch nicht zur Verfügung stehen. Dies alles führt im Kontext zunehmend verteilter Entwicklungsprozesse einerseits zu einer Explosion der Datenvolumina und andererseits zu immer höheren Anforderungen bezüglich eines integrierten Managements all der - teilweise sehr heterogenen - Daten und Werkzeuge, das heißt der konfliktfreien Bearbeitung, Speicherung und Bereitstellung der entsprechenden Daten, und zwar über Abteilungs- und zunehmend auch Unternehmensgrenzen hinweg. Nimmt man die Aspekte der Versions- und Variantenbildung, des Sichten- und Gültigkeitsmanagements, sprich des Konfigurationsmanagements (siehe Teil 1 der Beitragsreihe [12]), mit hinzu, so kann man PLM relativ ausschließlich als die Integrationsschicht dieser primär an den CAx-Modellen und -Werkzeugen ausgerichteten produktzentrischen Sicht verstehen. Produktzentrische Sicht In Abb. 1 wäre diese Sicht in der horizontalen Achse unterhalb der Phasen Forschung & Entwicklung bis Arbeitsvorbereitung einzuordnen. Produktdatenmanagementsysteme (PDM) sind genau aus diesem Bedarf heraus entstanden und bilden heute den Kern eines stark am Produkt und dessen kompletter Beschreibung ausgerichteten PLM-Verständnisses, auf das wir weiter unten noch genauer eingehen werden. 2 PLM im Spagat zwischen Produkt und Ressourcen Gewissermaßen parallel zu den produktzentrierten Ansätzen haben sich aus den ursprünglichen Materialbewirtschaftungs- und Produktionsplanungssystemen (PPS) heraus ganzheitliche Enterprise-Resource-Managementsysteme (ERP) entwickelt, die es erlauben, alle für die Herstellung, den Vertrieb und die Kundenbetreuung notwendigen Ressourcen, Daten und Informationen zu verwalten und zu optimieren (siehe vertikale Achse in Abb. 1). Auch diese Kategorie von Integrationssystemen hat im Kern den Produktbezug, wobei der Aspekt der Planungsoptimierung im Sinne quantitativer Optimierungsverfahren des Operation Research in den heutigen Standardlösungen eher noch rudimentär ausgeprägt ist. Insofern müsste man statt von ERP eigentlich eher von ERM, also Enterprise Resource Management, sprechen. Von dieser Problematik abgesehen, stellt die Ressourcenzentrierung aber eine weitere Sicht auf das Produktlebenszyklusmanagement dar. Beide „Welten“ - die stark produktzentrierte und die eher ressourcenorientierte - sind heute zumindest IT-technisch noch relativ stark getrennt. Hier ist bezüglich Integration von Ressourcen- und Produktsicht noch relativ großer Forschungsbedarf, der aus unserer Sicht mittelfristig zu einem Integrierten Product Lifecycle Resource Management (PLRM) führen wird. Die neuen Möglichkeiten, die speziell das Internet und die es umgebenden Technologien wie beispielsweise die Extensible Markup Language XML eröffnen, haben dazu geführt, dass das explizite und gezielte Management von Kundenbeziehungen einerseits und die tiefere Einbindung von Zulieferern andererseits ebenfalls neue, auf diese speziellen Anforderungen angepasste SW-Lösungen hervorgebracht haben: das Customer Relationship Management (CRM) sowie das Supply Chain Management (SCM). Beide Ansätze stellen heute ebenfalls sehr wichtige Bereiche dar, die allerdings nicht völlig getrennt von PLM gesehen werden sollten, wie dies momentan noch eher der Fall ist. Beide Aspekte gilt es vielmehr entsprechend in eine integrierte PLRM-Vision mit einzubinden. Sowohl SCM als auch CRM sind heute als eigenständige Lösungen genauso am Markt verfügbar wie als Module innerhalb klassischer Standardsysteme - primär im Bereich ERP, aber noch nicht ausreichend mit der produktzentrischen Sicht integriert. In der Überschneidung dieser Ebenen und Sichten liegt zentral aber immer das Produkt selbst, das klassisch in Form von Stücklisteninformationen und den zugehörigen Zeichnungen von „der Konstruktion“ an „die Produktion“ in Form von sogenannten variablen Stücklisten, das heißt in sich geschlossenen Dokumenten, über- Abb. 1: Der Product Lifecycle in der Überschneidung von Produkt- und Ressourcensicht PM_4_06.indd 33 26.09.2006 16: 08: 04 Uhr 34 SCHWERPUNKT SCHWERPUNKT aktuell projekt M A N A G E M E NT 4/ 20 0 6 geben wird (siehe dazu Teil 3 dieser Beitragsreihe [4]). Diese heute in der Regel noch weitestgehend unidirektionale und zugleich statisch ausgelegte Schnittstelle wird aus mehreren Gründen den zukünftigen Anforderungen eines integrierten Product-Lifecycle-Managements immer weniger gerecht. Der wohl wichtigste Faktor hierbei ist die Tatsache, dass die Produkte selbst auch nach Herstellung und Auslieferung an den Kunden aus Sicht der Gesamtkonfiguration „weiterleben“ und die kunden- und betriebsnahen Phasen ebenfalls mit erfasst und datentechnisch abgebildet werden müssen. Beispiele hierfür sind die spätere Ausbzw. Umrüstung eines Produktes auf neue und/ oder sich verändernde Kundenanforderungen. Bei einem Flugzeug sind dies beispielsweise spezielle, an die jeweiligen nationalen Anforderungen angepasste Flugleit- oder Waffensysteme. Aber auch Produkte aus dem Consumer-Bereich unterliegen zunehmend dieser Problematik beispielsweise durch die Möglichkeit, die Funktionalität des Produktes durch nachträgliche Softwaredownloads zu erweitern. Eine solche Erweiterung bedeutet aus Sicht des Konfigurationsmanagements das Erzeugen und Verwalten von neuen Produktkonfigurationen zu einem Zeitpunkt, an dem das individuelle Kundenprodukt bereits deutlich außerhalb des „Konstruktionsprozesses“ liegt. In diesem Zusammenhang stellt die integrierte Abbildung von Mechanik, Elektronik und Software im Sinne eines geschlossenen, interdisziplinären Konfigurationsmanagements eine der größten Herausforderungen im PLC dar. Bezüglich einer genaueren Darstellung dieser Problematik sei auf den ersten Teil dieser Beitragsreihe [12] sowie eine ausführlichere Behandlung der Softwareintegration in [6] verwiesen. Unternehmensübergreifende Prozesse und kollaboratives Projektmanagement Eine ähnliche Problematik besteht beispielsweise auch bei Reklamationen oder Änderungsanforderungen, die sich in der Betriebsphase ergeben. Auch hier muss der datentechnische Rückfluss mit der Zuordnung zur Produktkonfiguration innerhalb der entsprechenden Datensysteme möglich sein. Darüber hinaus kommt an dieser Stelle die Fragestellung mit ins Spiel, wie solche Prozessketten zum einen innerhalb des Unternehmens, zunehmend aber auch über Unternehmensgrenzen hinweg organisatorisch strukturiert und prozess- und vor allem auch projektspezifisch koordiniert und in den korrelierenden IT-Systemen umgesetzt sind. Sind in den sich immer stärker ausprägenden sogenannten Virtuellen Entwicklungsverbünden Partnerunternehmen bereits sehr früh mit entsprechender Tiefe in den Gesamtprozess integriert, ergeben sich komplett neue Anforderungen an „spontane Integrationslösungen“ und damit gekoppelt ein unternehmensübergreifendes „Virtuelles Projektmanagement“ 1 . Auch hier ist die Automobilindustrie treibende Kraft, vergibt sie doch heute schon wesentliche Entwicklungsanteile, teilweise bereits komplette Produkte an Partnerunternehmen. Eine derzeit laufende Projektinitiative bearbeitet aus diesem Grund intensiv die Problematik eines sich über Unternehmensgrenzen hinweg erstreckenden kollaborativen Projektmanagements in komplexen Product-Lifecycle-Prozessen [11]. Integrationsansätze über Product Lifecycle hinweg Alle heute vorherrschenden Integrationsansätze über den kompletten Product Lifecycle hinweg müssen eher noch als „a priori“ eingestuft werden, was bedeutet, dass dem klassischen Softwareentwicklungsansatz folgend bei Bedarf zunächst eine Integrationsarchitektur entworfen und dann in der Regel schrittweise umgesetzt wird, wobei in den großen Teilbereichen die dortigen Systeme beibehalten werden und dann entsprechende Datenaustauschprozesse gewissermaßen als Brückenglieder dazwischengeschaltet sind. Basis hierfür sind jedoch sehr genau abgestimmte und für bestimmte Anwendungsdomänen wie beispielsweise den Automobilbau oder die Verfahrenstechnik standardisierte Datenstrukturen und Austauschformate. Abschnitt 4 wird dies noch ein wenig näher beleuchten. Insofern ist das heute vorherrschende Prinzip noch eher produkt-/ ressourcendatengetrieben und von den entsprechenden Standardsystemen dominiert. Middleware- und Service-Orientierung als neuer Trend bei der Integration Neuere Ansätze aus der Informatik, die unter den Überbegriff „Middleware“ zusammengefasst werden, zielen auf eine stärkere Entkopplung von Anwendungsfunktionen von den sie zur Verfügung stellenden Systemen und Plattformen. Ein bestimmter Dienst wie zum Beispiel „Exploriere die Produktstruktur von Produkt xy bis zur Tiefe n“ wird allgemein definiert und als abstrakte Schnittstelle zur Verfügung gestellt. Dieser Dienst kann dann - vorausgesetzt die entsprechenden Rechte liegen vor - zur Laufzeit, das heißt bei Integrationsbedarf quasi spontan, benutzt und in die bestehende Systemlösung eingebunden werden. Der zurzeit am stärksten diskutierte Ansatz ist gewissermaßen die radikalste Variante dieser Idee, die als Service Oriented Architecture (SOA) bezeichnet wird. Prozesse werden zur Laufzeit auch unternehmensübergreifend aus einzelnen Dienstefunktionen zusammengefügt (man spricht hier von der sogenannten Orchestrierung). Die einzelnen Dienste selbst werden durch unterschiedlichste Standardsysteme und proprietäre Lösungen bereitgestellt, bleiben aber in ihrer internen Realisierung transparent. Eine unter der Ägide der Object Management Group (OMG) laufende und im Wesentlichen von der Automobilindustrie vorangetriebene PLM-Initiative basiert auf diesem Ansatz und versucht, die typischen PLM-Funktionen - angelehnt an Ausschnitte aus der STEP-Norm (siehe nächster Abschnitt) - allgemein als Dienste zu beschreiben und zu standardisieren, die sogenannten PLM 1 „Virtuell“ soll hier zum Ausdruck bringen, dass es sich aus Sicht eines OEM um ein in sich geschlossenes Gesamtprojekt handelt, das sich aber gewissermaßen erst zur Laufzeit im Zusammenspiel mit unterschiedlichen Partnerprojekten ergibt. Insofern ist das sich jeweils konkret ergebende Projekt sehr real - dieser Gebrauch des Begriffes „Virtualität“ hat sich inzwischen jedoch etabliert. PM_4_06.indd 34 26.09.2006 16: 08: 05 Uhr 35 projekt M A N A G E M E NT 4/ 20 0 6 aktuell Services [10]. Es ist davon auszugehen, dass dieses Paradigma in Zukunft sehr stark an Bedeutung gewinnen wird. Allerdings sind wir heute von einer den gesamten Product Lifecycle abdeckenden integrierten Diensteorientierung noch sehr weit entfernt. Das IT-Paradoxon im Product Lifecycle Management Doch zurück zu den PLM-Sichten und dem Dilemma der IT-Unterstützung im Product Lifecycle. Stark zugespitzt könnte man von einem IT-Paradoxon sprechen, das in seiner Ursprungsform sehr weit zurückreicht. Der Wirtschaftswissenschaftler und spätere Nobelpreisträger Robert M. Solow hat in den 1980er Jahren den Satz geprägt: „I see computers everywhere except in the productivity statistics.“ Und obwohl wir enorme Technologiesprünge verzeichnen können - das Moore’sche Gesetz von 1965 [9], wonach sich die Integrationsdichte und damit die Prozessorleistung alle 18 Monate verdoppeln wird, gilt zum Erstaunen vieler Experten bis in die heutige Zeit - und deutlich verbesserte methodische Ansätze, Werkzeuge und Bewertungsverfahren zur Verfügung stehen, stellen die Einführung und Beherrschung von ITgestützten PLM-Prozessen für viele Anwender „gefühlt“ immer noch eher ein notwendiges Übel als ein strategisches Schlüsselelement dar. Dies, obwohl Studien längst belegen, dass Produktivitätssteigerungen proportional zu IT-Investitionen stehen … können! Die Frage ist eben, wie dieses Ziel erreicht werden kann, wie PLM zu einem strategischen Erfolgsfaktor entwickelt werden kann. Und damit haben wir einen Schlenker gemacht zu der Sicht des Managements und der strategischen Ebene. Hier sind heute sicherlich noch die größten Defizite zu verzeichnen. PLM wird in Zukunft noch viel stärker als bisher als Managementinstrumentarium den „Business Value“ darstellen müssen (siehe Definition der Gartner Group in Abschnitt 1), um aus dieser Umklammerung herauszukommen. Hier beißt sich die Katze allerdings auch wieder ein wenig in den Schwanz, denn dazu muss zunächst deutlich mehr Verständnis in den Führungsebenen der Anwenderunternehmen aufgebaut werden. Diese sehen PLM aber in der Regel als „Einführung einer Standardsoftware“, das heißt als ein einmaliges Projekt, ähnlich wie beispielsweise die Einführung von 3D- CAD-Systemen. Und dieses Grundverständnis steht für eine weitere typische Sicht auf PLM - die der Standardsoftware-Orientierung. PLM ist jedoch keine fertige Softwarelösung, die man sich auf dem Markt kaufen und dann im Unternehmen einsetzen kann. Ähnlich wie Projektmanagement oder Konfigurationsmanagement handelt es sich bei PLM jedoch vielmehr um eine ganzheitliche Managementaufgabe, die allerdings im Vergleich zu den eben genannten Beispielen bei Weitem noch nicht so etabliert und standardisiert ist. Auch hier liegt gerade ein großer Unterschied: PLM ist immer sehr unternehmensspezifisch zu konzipieren und umzusetzen, spiegelt es doch gewissermaßen die produktnahen Kernprozesse und damit auch die Kernkompetenzen der Unternehmen wider. Hier würde eine komplette Standardisierung im Extremfall gar keine Differenzierung mehr erlauben, alle PLM-Prozesse sozusagen gleichmachen - ein Widerspruch zur These, dass gerade PLM Wettbewerbsvorteile ermöglichen können will und muss. PM PM- -Know Know- -how how auf Knopfdruck auf Knopfdruck Mit dem Online-Archiv auf www.pmaktuell.org Abstracts und Leseproben aus projektMANAGEMENT aktuell finden Sie in übersichtlicher Form und vielfältig recherchierbar im Internet. GPM-Mitglieder können mit einem persönlichen Zugangscode alle Beiträge kostenfrei als PDF-Datei downloaden. Anzeige Hauptsache: Projektmanagement Haupt Verlag verlag@haupt.ch • www.haupt.ch Stephen Rietiker Der neunte Schlüssel Vom Projektmanagement zum projektbewussten Management Stephen Rietikers systemischer Zugang schiebt die Perspektive der Gesamtorganisation in den Vordergrund. Eine echte Alternative zum dominierenden Projektmanagementverständnis. 312 S., 30 Abb., geb., EUR 45.-/ CHF 68.- ISBN 3-258-07044-X Kurt Schori, Andrea Roch, Marlotte Faoro-Stampfli Innovationsmanagement für KMU Ein erheblicher Teil von Innovationen geht heute auf das Konto kleiner und mittlerer Unternehmen. Mit Hilfe dieser Anleitung und der Tools kann Innovationsmanagement für KMU einfach, klar und effizient gelebt werden. 122 S., 64 Abbildungen, kart., EUR 24.90/ CHF 38.- ISBN 3-258-07093-8 Anzeige PM_4_06.indd 35 26.09.2006 16: 08: 07 Uhr 36 SCHWERPUNKT SCHWERPUNKT aktuell projekt M A N A G E M E NT 4/ 20 0 6 Ein weiterer wichtiger Aspekt, der sich daraus ableitet, ist die Frage eines kompletten Outsourcings der PLM- Thematik, wie sie momentan bei einigen Unternehmen aufgrund der teilweise sehr angespannten wirtschaftlichen Situation zu beobachten ist, die wir aus dem oben dargestellten Grund jedoch für sehr kritisch halten. Zumindest der „Bebauungsplan“, das heißt die PLM-Konzeption, sollte von einem entsprechenden PLM-Stab, der bei kleinen Unternehmen auch aus einem Mitarbeiter bestehen kann, unternehmensintern verantwortet und begleitet werden, um einerseits selbst die PLM-Potenziale für das eigene Unternehmen kontinuierlich weiter ausschöpfen zu können und um andererseits nicht in eine totale Abhängigkeit von Softwareanbietern oder IT-Dienstleistern zu geraten. Outsourcing der PLM-Thematik 3 Von der Dokumentenzentrierung zum Produktmodell Voraussetzung für eine IT-Unterstützung der in den vorhergehenden Abschnitten dargestellten, zunehmend komplexeren Integrationsbeziehungen ist ein detailliertes und abgestimmtes Verständnis aller dem Product Lifecycle zugrunde liegenden produktbeschreibenden Daten und Informationen. STEP und das Integrierte Produktmodell Die in den Anfängen der Rechnernutzung begründete ursprüngliche Fokussierung auf die Geometrie - sprich die CAD-Modelle - hat bereits in den 1980er Jahren zu einer seinerzeit stark von der Automobilindustrie getriebenen Initiative geführt, produktbeschreibende Geometriedaten zu standardisieren und so die Voraussetzung für einen elektronischen Austausch von CAD-Daten zu ermöglichen. Dieser mittlerweile international genormte „Standard for the Exchange of Product Model Data STEP“ [2] erlebte dann Mitte der 1990er Jahre mit der Ausdehnung der CAx-Technologien sozusagen eine Renaissance, weil hier die Basis für ein Integriertes Produktmodell bereits gelegt war. STEP wurde entsprechend erweitert und bildet heute eine wichtige Grundlage für CAx-basierte PLM-Integration, wenn es um die Erstellung eines Integrierten Produktmodells geht, das die unabdingbare Voraussetzung für eine tiefe, das heißt an den detaillierten Produktdetails ausgerichtete Integration sowie einen entsprechenden Datenaustausch in verteilten Lifecycle-Prozessen ist. Damit sind wir bereits bei einer der vielen „Kehrseiten“ der PLM-Thematik angelangt. Eine „wirkliche“ produktmodellbasierte, tiefe Integration verlangt ein entsprechend tiefes Modellverständnis, was wiederum zu relativ hoher Komplexität führen kann. Umgekehrt garantiert ein marktgängiges Standard-PDM-System, das im Kern genau diese Perspektive fokussiert, per se noch keine tiefe Integration, sondern stellt lediglich eine an die unternehmensspezifischen Anforderungen anzupassende Plattform zur Verfügung. Je nach Komplexität der Produkte und der Lifecycle-Prozesse kann diese Anpassung von Standardsoftware - das sogenannte Customizing - eine sehr große Herausforderung darstellen. Für kleinere und mittelständische Unternehmen verstärkt sich dieser Effekt, stehen hierfür in der Regel eben weder die entsprechenden Experten noch die finanziellen Mittel zur Verfügung, wie dies bei den „Großen“ im Bereich Automotive und Luft- und Raumfahrt meist der Fall ist. Wir werden im letzten Teil dieses Beitrages noch einmal auf diese Problematik zu sprechen kommen und einen Vorschlag für ein entsprechendes Vorgehensmodell darstellen. Die heute noch weitgehend vorherrschende Dokumentenzentrierung Eine weitere relativ enge, aber gleichermaßen wichtige Sicht auf PLM ist die der Dokumentenzentrierung. Dahinter verbirgt sich ein gewisses Paradigma, das Produktentwicklung im Kern als Kette von Einzelschritten begreift, an deren Schnittstelle jeweils ein Dokument bzw. ein Satz von Dokumenten von einem Bearbeitungsschritt zum jeweils nächsten übergeben wird. Dieses Prinzip führte, nachdem immer mehr „digitale Dokumente“ auf immer mehr zunehmend verteilten Rechnerplattformen anfielen und bei ortsverteiltem Zugriff über mehrere Benutzer konsistent verwaltet werden mussten, zu entsprechend konzipierten Engineering Document Management System (EDM). Ähnlich wie bei allgemeinen Dokumentenmanagement-Standardsoftwarelösungen werden in einem gemeinsamen sog. Repository die Informationen über die eigentlichen Dokumente getrennt von den eigentlichen Daten, sprich Dokumenten, gespeichert (man spricht in diesem Zusammenhang auch von Metadaten) und der Zugriff über entsprechende Check-in-/ Check-out-Mechanismen geregelt. Das bedeutet, dass einmal in den sogenannten Daten-Vault „eingecheckte“ Dokumente nicht mehr ohne Weiteres verändert werden können und bei erforderlichen Änderungen/ Überarbeitungen entsprechende Zugriffskontroll- und Versionierungsmechanismen greifen können. Nachteile einer Dokumentenzentrierung Die Dokumentenzentrierung steht jedoch einer wirklich tiefen, produktmodellbasierten PLM-Integration dann sogar im Wege, wenn nach diesem Prinzip komplette „Dokumentenstämme“ in Form von „Stücklistendokumenten“ mit den jeweils verknüpften „Zeichnungen“ als geschlossene Dokumente verwaltet werden. Produktstrukturinformationen sind dann komplett in den Dokumenten gekapselt („Black-Box-Prinzip“), strukturelle Änderungen im Kontext eines integrierten Konfigurationsmanagements (siehe Teil 1 der Beitragsreihe) können dann nicht voll integriert und systemgestützt begleitetet werden. Damit wäre im schlechtesten Fall eines der wesentlichen Potenziale des Integrierten Produktmodells völlig verwirkt, was kurz an einem kleinen Beispiel etwas ausführlicher dargestellt werden soll. Beispiel eines Integrierten Produktmodells Abb. 2 zeigt einen Beispielausschnitt aus einem Produktmodell. Eine Baugruppe 1 mit ihrer ersten Hauptrevi- PM_4_06.indd 36 26.09.2006 16: 08: 07 Uhr 37 projekt M A N A G E M E NT 4/ 20 0 6 aktuell sion A ist die derzeit gültig gesetzte, wobei auf der zweiten Stufe der Iteration der Stand 1 mit einem Spezifikationsdokument (Getriebe Spez. #4711/ 01 mit zugehöriger Datei getriebspez1.txt) sowie einem CAD-Modell (Getriebe Modell 08111/ 01 mit zugehörigem CAD-Modell getr_a1.cad) den aktuell gültigen Stand widerspiegelt. Die Spezifikation dieses Getriebes ist offensichtlich bereits in Überarbeitung, was durch eine Iteration zum Metaelement #4711/ 02 und zu der damit verbundenen Datei getriebespez2.txt angedeutet ist. Dieses auf den ersten Blick vielleicht etwas kompliziert anmutende Prinzip hat den entscheidenden Vorteil, dass nur so ein komplett systemgesteuertes und -überwachtes Konfigurationsmanagement über alle das Produkt beschreibenden Aspekte hinweg möglich wird. Eine Stückliste wird in dieser Philosophie eben nicht mehr explizit als Dokument verstanden und gespeichert, sondern stellt zu einem Zeitpunkt und unter einem bestimmten Blickwinkel - beispielsweise dem einer „Fertigungsstückliste“ - eine spezielle Ausprägung des aktuellen Produktstrukturbaumes dar. Das Sichtenkonzept und die Softwareintegration In einer weiteren Ebene, die der Einfachheit halber in Abb. 2 nicht einbezogen wurde, können dann zusätzlich Sichtenzuordnungen vorgenommen und so die Zugehörigkeit eines Elementes zu einer oder mehreren Lifcycle Views (beispielsweise „as-designed“ oder „as-shipped“) flexibel im Produktmodell festgelegt und von entsprechenden Systemen verwaltet und ausgeprägt werden. Dies ist ein Beispiel dafür, dass bei der Umsetzung von typischen produktzentrierten Integrationsstrategien die Vision des Integrierten Produktmodells auch dann zumindest konzeptionell bereits angelegt sein muss, wenn, wie sehr häufig, bei der ersten Stufe von PDM-Einführungsprojekten zunächst die Verwaltung der produktrelevanten Dokumente umgesetzt wird. Diese statische, das heißt eine die Daten, Dokumente, ihre beschreibenden Informationen sowie ihre komplexen Beziehungsstrukturen ausdrückende Perspektive liegt für die produktspezifischen Anteile - zumindest die der klassischen „mechanischen Produktsicht“ - heute bereits sehr detailliert beschrieben und standardisiert vor. Der Standard STEP mit seiner generischen Architektur bietet hierzu auf der Basis von Grundbausteinen, den sogenannten Integrated Resources, sowie mit bereits anwendungs-/ domänenspezifischen „vorgefertigten“ Modellausprägungen, den sogenannten Anwendungsprotokollen, eine sehr gute Ausgangsbasis [2]. Allerdings ist der Umgang mit dieser sehr abstrakten und komplexen Materie insbesondere für Endanwender kaum beherrschbar, sodass man sich hier meist an die in Standardsystemen vorgegebenen Strukturen hält. Dies wird in vielen Fällen zu guten Lösungen führen, in komplexeren Anwendungsfeldern, in denen beispielsweise mechatronische Aspekte dominieren, kann jedoch eine spezifische Anpassung bzw. Erweiterung des Produktmodells erforderlich werden. Insbesondere die tiefe Integration der Softwarekonfigurationsproblematik mit ihrer im Kern relativ spezifischen und vom klassischen Konfigurationsparadigma in einigen Aspekten abweichenden Systematik ist heute noch Gegenstand der Forschung. In Abb. 2 ist eine heute verbreitete Form der Softwareeinbindung angedeutet, die ein komplettes Softwarerelease als geschlossenes „Dokument“ in den Produktbaum einbindet und so die Relation zur Softwareseite herstellt. Der Trend geht dahin, Softwaremodule und -komponenten als integrale Bestandteile komplexer mechatronischer Produkte ebenfalls feingranularer und produktstrukturbezogen zuzuordnen, um so eine entsprechend tiefere Verankerung in die Managementstruktur eines IT-Systems zu ermöglichen. Allerdings stehen diesem Bemühen recht grundsätzliche Unterschiede in der Philosophie des PLM-gestützten Managements von Konfigurationen entgegen. Zum einen fokussieren die heutigen Lösungsansätze der Softwareintegrationen immer noch primär die zu verwaltenden Dokumente im Sinne von Softwaredateien. Hier ist zumindest in bestimmten Bereichen eine feinere Auflö- PROZESS- U N D PROJ E KTORI E NTI E RU NG IM U NTE RN E HME N! Die Handbücher für ... Projektauftraggeber, Projekt- und Programmmanager Manager prozess- und projektorientierter Unternehmen Prozesseigentümer - N E U E TH E O R I E N - M O D E LLE - B E ST P R ACTI C E S - FA LLSTU D I E N Kontakt ROLAND GAREIS CONSULTING susanne.locker@rgc.at Prozesse & Projekte 1. Auflage ’06 (deutsch) ab Herbst ’06 auch in englisch Happy Projects! 2. Auflage ’04 (deutsch, englisch + rumänisch) Die Praxis zum ... Optimieren von Prozessen und Projekten Management des prozess- und projektorientierten Unternehmens www.rgc.at Bestellung bei MANZ Verlag per Tel. +43-1-531 61-100, Fax +43-1-531 61-455 oder E-mail: bestellen@manz.at! Anzeige Abb. 2: Beispielausschnitt „Integriertes Produktmodell“ PM_4_06.indd 37 26.09.2006 16: 08: 10 Uhr 38 SCHWERPUNKT SCHWERPUNKT aktuell projekt M A N A G E M E NT 4/ 20 0 6 sung zum Beispiel bis hinein in Funktionsblöcke oder Module notwendig. Einen zweiten noch größeren Hemmschuh stellen die grundlegenden Konflikte bezüglich der zugrunde liegenden Managementprinzipien dar. Während das PDM-/ PLM-Prinzip wie oben ausgeführt von einer zumindest logisch zentral verantworteten Metastruktur ausgeht, basieren Softwarekonfigurationsansätze in der Regel auf einem verteilten Peer-to-Peer-Prinzip, bei dem einzelne Softwarezweige zunächst völlig unabhängig und parallel von unterschiedlichen Entwicklern bearbeitet werden und aus Sicht einer Gesamtkonfiguration betrachtet somit gewissermaßen auseinanderlaufen. Erst zur sogenannten „Built-Time“ werden die einzelnen Stränge dann nach gewissen Rahmenbedingungen und unter Einbezug von systemtechnischen Parametern zu einem Gesamtsystem zusammengefügt („Branche&Merge“). Dies widerspricht jedoch der Grundidee des PDM-gestützten Konfigurationsmanagements, wo bei jeder Änderung auf Bauteil-/ Baugruppenebene immer sofort entsprechende Versionen angelegt und referenziert werden und diese Änderungen dann auch umgehend für alle weiteren Entwicklungsschritte sichtbar und damit verbindlich werden. Bezüglich einer genaueren Ausführung dieser Problematik sei auf [6] verwiesen. Abbildung von Produkt- und Ressourcenbeziehungen Ein weiterer wichtiger Aspekt im Kontext des Integrierten Modells ist die Abbildung von Relationen zum Ressourcenbereich. Beispielsweise wäre es für ein Bauteil oder eine Baugruppe sinnvoll, einen Verweis auf die „Lagerperspektive“ mitzuführen, um so in der Entwicklungsphase dem Ingenieur an entsprechender Stelle Hinweise liefern zu können, ob eine zum Einbau beabsichtigte Baugruppe derzeit am Lager verfügbar ist, und ggf. baugleiche Varianten anzubieten, die bezüglich Verfügbarkeit, Lieferfähigkeit oder auch Beschaffungspreis aus Ressourcensicht Vorteile böten. Dies wird u. a. auch vom Autor derzeit weiter bearbeitet mit dem Ziel, die Basisarchitektur für ein Integriertes Produkt-/ Ressourcenmodell zu entwickeln, das im Sinne eines alle Sichten umfassenden Product Lifecycle Resource Management (PLRM) aus unserer Sicht eine wichtige Voraussetzung darstellt. 4 Architektur und Funktionsspektrum von PDM-Systemlösungen Den in Abschnitt 1 kurz umrissenen EDM-Lösungen folgten als nächste Ausbaustufe der PLM-Standardsysteme Lösungsansätze, die bezüglich der Abbildbarkeit eines Integrierten Produktmodells die im letzten Abschnitt dargestellte Systematik adaptieren und so durch entsprechende Funktionen ein tiefes produktmodellbasiertes Management aller Produktstruktur- und Stammdaten ermöglichen. In ihrer ersten Generation waren diese noch sehr stark an den CAD-Modellen ausgerichtet und wurden in diesem Kontext zunächst auch noch als Engineering-Data-Management-Systeme bezeichnet. Mit zunehmender Ausweitung über die reine Geometrie- und Abb. 3: Typische Architektur und Funktionsbereiche von PDM-Systemlösungen PM_4_06.indd 38 26.09.2006 16: 08: 13 Uhr 39 projekt M A N A G E M E NT 4/ 20 0 6 aktuell Strukturmodellierung hinaus ist aus ihnen dann die heute im produktzentrischen Kontext im Mittelpunkt stehende Kategorie der sog. Product-Data-Management- Systeme (PDM) entstanden. Sie stellen heute die dominierende Plattform für ein über den kompletten Lebenszyklus greifendes, am Produkt ausgerichtetes PLM-Verständnis dar und ermöglichen so ein an der Idee des Integrierten Produktmodells ausgerichtetes ganzheitliches PLM - allerdings heute noch weitestgehend ohne die explizite Berücksichtigung von Ressourcen (siehe PLRM in Abschnitt 2). Product-Data-Management-Systeme (PDM) als dominierende Plattform Die Basis bildet immer der im vorigen Abschnitt bereits umrissene Vault (Abb. 3) mit seinem Metadatenstrukturbereich und den hierin referenzierten Nutzdaten. Im Kernbereich setzt dann das integrierte Produktstrukturmanagement auf diesem Vault auf und bildet so im Zusammenspiel mit einem unter Umständen zu ergänzenden Klassifizierungs- und Sachmerkmalleistenmodul die Grundfunktion des Systems. Wie im obigen Beispiel kurz umrissen, würde dann beispielsweise das Daten- und Dokumentenmanagement mit dem durch eine entsprechende Zugriffsverwaltung gesteuerten Vaulting-Prinzip auf dieser Grundfunktion aufsetzen. Weitere produktzentrierte Ausbaustufen ergeben sich dann durch Versions- und Variantenmanagement, das wiederum auf der obersten Ebene zu einem integrierten Konfigurationsmanagement ausgebaut werden kann. Bislang konzentrierten sich unsere Ausführungen primär auf die produktzentrischen Funktionen, die auch bei den Systemen anfangs im Mittelpunkt standen. Heutige Lösungen können aber auch die Prozesse dahin gehend unterstützen, dass über sog. Workflows typische, immer wiederkehrende Ablaufmuster im System vorgegeben und damit in der Nutzung systemgestützt abgearbeitet werden können (Abb. 4). Dabei wird ein einzelnes Element, das vom System verwaltet wird - ein sogenanntes „Manageable Item“, das heißt ein allgemeines Datenobjekt oder ein Dokument -, selbst einem Lebenszyklus 2 unterworfen, bestehend aus Zuständen und Übergängen. Sowohl in den Zuständen als auch in den Übergängen ist dann typischerweise über Workflows beschreibbar, welche einzelnen Bearbeitungsschritte jeweils durchlaufen werden müssen. Hier erfolgt dann gleichzeitig die Zuordnung zu Projekten, Teams und Rollen, womit beim einzelnen konkreten Durchlauf vom System dafür gesorgt werden kann, dass die erforderlichen bzw. berechtigten Personen die einzelnen Schritte im Eingangskorb ihres „Elektronischen Schreibtisches“ vorgelegt bekommen. Hiermit lässt sich beispielsweise ein komplettes Änderungs- und Freigabemanagement aufbauen und systemtechnisch von „weich“, das heißt mit gewissen Freiheitsgraden der Bearbeiter, bis hin zu „hart“, das heißt, keine noch so kleine Änderung geschieht ohne entsprechenden Änderungsprozess, unterstützen. An dieser Stelle blitzt auch die Korrelation zur projektspezifischen Perspektive von PLM durch, auf die der letzte Teil der Beitragsreihe noch einmal kurz eingeht. 5 PLM als kontinuierliche Aufgabenstellung Nach den bisherigen Ausführungen wird klar, das PLM eine relativ weit gefächerte und je nach Anwendungsumfeld mehr oder weniger komplexe Gesamtproblematik darstellt. IT-Unterstützung im Product Lifecylce bedeutet für ein Unternehmen somit, die den dargestellten PLM-Grundkonzepten zugrunde liegenden Systemfunktionen von Standardsoftwaretools je nach Produkt-/ Prozessanforderung des Unternehmens unterschiedlich tief und je nach Integrations- und Vernetzungsgrad über Abteilungsbzw. Unternehmensgrenzen hinweg auch unterschiedlich weit zu implementieren. Nicht jede Funktion ist in jeder möglichen Ausbaustufe für jedes Unternehmen mit seinen jeweiligen spezifischen Anforderungen und Randbedingungen gleich relevant. Mit anderen Worten: Nicht jede Funktion ist immer sinnvoll und nicht alles, was prinzipiell möglich ist, ist auch wirtschaftlich sinnvoll. Hier kommt nun abschließend noch die strategische Perspektive von PLM mit ins Spiel. Gilt es doch, wie in den einführenden Betrachtungen bereits angedeutet, PLM zunehmend als strategischen Faktor zu begreifen, was allerdings entsprechende Vorgehens- und vor allem Bewertungsmodelle erforderlich macht. Da PLM nicht als einmaliges Einführungsprojekt einer Standardsoftware verstanden werden sollte, stellt sich insbesondere für kleine und mittelständische Unternehmen die Frage, wie ein kontinuierliches Vorgehensmodell aufgebaut und im Unternehmen verankert werden kann. Abb. 5 zeigt einen entsprechenden Ansatz, der nun als Workflows Projekt/ Team Objekt/ Dokument Lifecycle Workflow-Rollen Abb. 4: Prozessmanagement auf der Basis von Lifcycle und Workflow; angelehnt an: PTC Windehill 2 Hier besteht wiederum ein wenig Begriffsverwirrung insofern, als man einerseits im Sinne der PLM-Definition aus Abschnitt 1 vom gesamten Produktlebenszyklus spricht. Andererseits ist mit Lifecycle aber auch das Prinzip gemeint, dass ein einzelnes Element innerhalb des gesamten PLM selbst wiederum über gewisse, ihm eigene Zustände verfügt und abhängig von bestimmten Bedingungen in den nächsten Zustand überführt werden kann, womit sich ein eigener Lebenszyklus ergibt. Dieses Prinzip bildet die Grundlage für das Prozessmanagement-Grundkonzept heutiger PDM-Lösungen. PM_4_06.indd 39 26.09.2006 16: 08: 15 Uhr 40 SCHWERPUNKT SCHWERPUNKT aktuell projekt M A N A G E M E NT 4/ 20 0 6 Abrundung dieses Beitrages kurz umrissen werden soll (Näheres dazu siehe [7, 8]). Product Lifecycle Management als kontinuierliche Aufgabenstellung muss innerhalb des Unternehmens als Vision formuliert und von einer entsprechenden Instanz getragen und vorangetrieben werden, die hier mit PLM- Stab bezeichnet ist. Zu Beginn und nach jedem Ausbauschritt wird auf der Basis der bis zu diesem Zeitpunkt erarbeiteten, im sogenannten PL(R)M-Manifest beschriebenen und teilweise bereits umgesetzten Stufe ein neuerlicher Einordnungsprozess angestoßen, der den aktuell erreichten Stand gegen die noch erreichbaren Potenziale spiegelt und so den Umfang für die nächste anzustrebende Ausbaustufe festlegt. Auf dieser Grundlage kann dann der nächste Durchlauf detailgeplant und umgesetzt werden. Abb. 5: Kontinuierliches Vorgehensmodell Abb. 6: Beispielauswertung eines PLM-Reifegrades PM_4_06.indd 40 26.09.2006 16: 08: 20 Uhr
