Volker Arnold · Hendrik Dettmering · Torsten Engel · Andreas Karcher

Product Lifecycle Management beherrschen

Product Lifecycle Management beherrschen

13

Volker Arnold · Hendrik Dettmering · Torsten Engel · Andreas Karcher

Mit 88 Abbildungen

Ein Anwenderhandbuch für den Mittelstand

Dipl.-Ing. Volker Arnold FZI Forschungszentrum Informatik an der Universität KarlsruheAbt. Prozess- und Datenmanagementim Engineering (PDE)Haid-und-Neu-Str. 10-1476131 Karlsruhe, Germanyvolker.arnold@fzi.de

Dipl.-Inform.Torsten EngelForschungszentrum Informatik an der Universität KarlsruheAbt. Prozess- und Datenmanagementim Engineering (PDE)Haid-und-Neu-Str. 10-1476131 Karlsruhe, Germanytorsten.engel@fzi.de

isbn 10 3-540-22997-3 Berlin Heidelberg New Yorkisbn 13 978-3-540-22997-1 Berlin Heidelberg New York

Dieses Werk ist urheberrechtlich geschützt. Die dadurch begründeten Rechte, insbesondere die der Übersetzung, des Nachdrucks, des Vortrags, der Entnahme von Abbildungen und Tabellen, der Funk-sendung, der Mikroverfi lmung oder Vervielfältigung auf anderen Wegen und der Speicherung in Datenverarbeitungsanlagen, bleiben, auch bei nur auszugsweiser Verwertung, vorbehalten. Eine Ver-vielfältigung dieses Werkes oder von Teilen dieses Werkes ist auch im Einzelfall nur in den Grenzen der gesetzlichen Bestimmungen des Urheberrechtsgesetzes der Bundesrepublik Deutschland vom 9. September 1965 in der jeweils geltenden Fassung zulässig. Sie ist grundsätzlich vergütungspfl ichtig. Zuwiderhandlungen unterliegen den Strafbestimmungen des Urheberrechtsgesetzes.

Springer ist ein Unternehmen von Springer Science+Business Media

springer.de

© Springer-Verlag Berlin Heidelberg 2005Printed in Germany

Die Wiedergabe von Gebrauchsnamen, Handelsnamen, Warenbezeichnungen usw. in diesem Buch berechtigt auch ohne besondere Kennzeichnung nicht zu der Annahme, dass solche Namen im Sinne der Warenzeichen- und Markenschutz-Gesetzgebung als frei zu betrachten wären und daher von je-dermann benutzt werden dürften. Sollte in diesem Werk direkt oder indirekt auf Gesetze, Vorschrif-ten oder Richtlinien (z. B. din, vdi, vde) Bezug genommen oder aus ihnen zitiert worden sein, so kann der Verlag keine Gewähr für die Richtigkeit, Vollständigkeit oder Aktualität übernehmen. Es empfi ehlt sich, gegebenenfalls für die eigenen Arbeiten die vollständigen Vorschriften oder Richtlini-en in der jeweils gültigen Fassung hinzuzuziehen.

Umschlaggestaltung: medionet AG, BerlinSatz: Digitale Druckvorlage des Autors

Gedruckt auf säurefreiem Papier 68/3020/M - 5 4 3 2 1 0

Bibliografi sche Information der Deutschen BibliothekDie Deutsche Bibliothek verzeichnet diese Publikation in der Deutschen Nationalbibliografi e; detaillierte bibliografi sche Daten sind im Internet über http://dnb.ddb.de abrufbar.

Prof. Dr.-Ing. Andreas KarcherUniversität der Bundeswehr MünchenFakultät für InformatikWerner-Heisenberg-Weg 3985577 Neubiberg, Germanyandreas.karcher@unibw.de

Dipl.-Ing. Hendrik DettmeringTechnische Universität MünchenLehrstuhl f. Informationstechnik im MWBoltzmannstr. 1585748 Garching, Germanydettmering@itm.tum.de

Vorwort

Kaum ein Thema im IT-Umfeld findet bei Anwendern, Anbietern und Beratern derzeit mehr Beachtung als das Product Lifecycle Management (PLM). Nach einer stark ausgeprägten Phase der Prozessorientierung und des Business Process Reengineering in den 90er Jahren, hat in letzter Zeit bei produzierenden Unternehmen eine Rückbesinnung auf ihre Produkte und die damit einhergehenden Entwicklungs- und Lebenszyklusprozesse stattgefunden. Neue Technologien und Systemlösungen einerseits und die ständig steigenden Anforderungen an optimale IT-Lösungen zur Unterstüt-zung der Produktlebenszyklen andererseits sorgen für eine zunehmende Beachtung auch bei den Entscheidungsträgern.

Große Firmen insbesondere im Automobil- sowie im Luft- und Raum-fahrtbereich haben die strategische Bedeutung von PLM erkannt und aus der Not schwer beherrschbarer Produktlebenszyklusprozesse eine Tugend gemacht. Dort werden sehr große Summen in entsprechende IT-Lösungen investiert und PLM als kontinuierliche Aufgabenstellung auf der strategi-schen Managementebene installiert.

Insbesondere für kleine und mittlere Unternehmen (KMU) stellt IT-gestütztes PLM jedoch eine besonders große Herausforderung dar. Als Zulieferer oder Entwicklungspartner größerer Unternehmen sind KMU immer stärker auch IT-technisch gefordert, die eigenen Prozesse integrati-onsfähig zu machen. Allerdings verfügen KMU heute oft (noch) nicht über das erforderliche PLM-Know-how und die technischen und finanziellen Möglichkeiten. So stecken KMU in dem Dilemma, PLM als strategisches Konzept im Unternehmen aufbauen, verankern und kontinuierlich weiter-entwickeln zu müssen, dies aber nicht mit großer Durchschlagskraft und hohen Aufwendungen in einem Schritt bewältigen zu können.

Der Weg aus diesem Dilemma kann nur ein schrittweises Vorgehen sein, das es den Unternehmen ermöglicht, kontinuierlich und an ihr jewei-liges Anforderungsprofil angepasst PLM-Potentiale zu erschließen und mit geeigneten IT-Lösungen umzusetzen. Der wichtigste Aspekt hierbei ist, dass das dabei entstehende Know-how ganz zentral die PLM-Prozesse und damit die Kernprozesse des Unternehmens betrifft. Das wesentliche Ziel muss somit sein, das wertvolle PLM-Know-how im Unternehmen aufzu-bauen und zu sichern, da PLM-Prozesse und Strategien längerfristig

VI Vorwort

Bestand haben müssen. Deshalb gilt es, das PLM im Unternehmen weitge-hend technologie- und systemneutral aufzubauen, um nicht in zu starke Abhängigkeiten von Softwareanbietern oder Systemhäusern zu gelangen.

Vor diesem Hintergrund ist im Rahmen des vom Bundesministerium für Wirtschaft geförderten Programms „Innovative Netzwerke (InnoNet)“ im Jahr 2002 ein Projekt gestartet worden, das genau diese Problematik in einem Verbund mit Anwendern, Beratern, Systemhäusern und unseren beiden Forschungsinstituten an der TU München und am FZI in Karlsruhe bearbeitet. Um die Ergebnisse und Erfahrungen aus diesem Projekt „Vor-gehensmodell für ein kontinuierliches Product Lifecycle Informationsma-nagement für KMU (PLM4KMU, siehe auch www.plm4kmu.de)“ mög-lichst vielen Anwendern und Interessierten zur Verfügung stellen zu können, haben die Projektleiter Herr Engel und Herr Prof. Karcher sowie die beiden wissenschaftlichen Mitarbeiter Herr Dettmering und Herr Arnold dieses PLM-Buch verfasst, das sich speziell an Anwender und Entscheidungsträger in den Unternehmen richtet. Mit diesem Buch steht erstmals PLM-Anwendern ein Werk zur Verfügung, das als Handlungsleit-faden ganz besonders den Zugang zu dieser komplexen Materie erleichtert.

Unser Dank gilt in erster Linie den vier Autoren, die dieses Projekt von der wissenschaftlichen Seite her so erfolgreich vorangetrieben und die Ergebnisse zusammengetragen und für dieses Buch aufbereitet haben. Ein ganz besonderer Dank gilt den beiden Projektpartnern Herrn Dr. Greindl und Herrn Dr. Rech, die uns nicht nur während der Projektbearbeitungszeit mit ihrer industriellen Erfahrung zur Seite standen, sondern auch wesentli-che Beiträge für dieses Buch eingebracht haben. Ferner gilt unser Dank allen Projektpartnern, die zum Erfolg unseres gemeinsamen Forschungs-vorhabens beigetragen und damit auch dieses Buch ermöglicht haben.

Nun wünschen wir Ihnen, liebe Leser, dass Sie an unseren Erfahrungen partizipieren und aus diesem Buch möglichst viel an wertvollen Hinweisen und Erfahrungen auf Ihrem Weg zu einem erfolgreichen Product Lifecycle Management gewinnen werden. München und Karlsruhe im Januar 2005

Prof. Bender Prof. Grabowski

Inhaltsverzeichnis

1 Einleitung 71.1 PLM-Historie 81.2 Entstehungsgeschichte des Buches 91.3 Aufbau und Anwendung des Handbuches 10

2 PLM – eine kontinuierliche Aufgabe 132.1 Begriffsklärung 132.2 Vorgehen bei der PLM-Umsetzung 162.3 Komplexität dauerhaft beherrschen 172.4 Nutzen und Aufwendungen 19

2.4.1 Chancen durch Veränderung 192.4.2 Strategische Betrachtung 212.4.3 Wirtschaftliche Betrachtung 22

2.5 Eingliederung ins Unternehmen 242.5.1 Akzeptanz für PLM schaffen 252.5.2 Betroffene im Unternehmen 262.5.3 Synergien zwischen PLM und Qualitätsmanagement 27

3 Basiskonzepte eines PLM-Manifests 293.1 Das integrierte Produktmodell 32

3.1.1 Bestandteile des integrierten Produktmodells 333.1.2 Aufbau eines integrierten Produktmodells 35

3.2 Das Prozessmodell 36

4 Evolutionäres Vorgehensmodell 394.1 PLM als Paradigma im Unternehmen 40

4.1.1 PLM-Stab 414.1.2 PLM-Vision 434.1.3 Generisches PLM-Manifest 44

4.2 Phase „PLM-Readiness“ 454.2.1 Maturity-Modell 464.2.2 Zielsetzung des Maturity-Modells 474.2.3 Abhängigkeiten der PLM-Funktionsblöcke 484.2.4 Anwendung des Maturity-Modells 50

VI Inhaltsverzeichnis

4.2.5 Formulierung der Zielsetzung 544.3 Phase „PLM-Requirement-Management” 55

4.3.1 Analyse zur Leistungsbeschreibung 564.3.2 Planung der Ressourcen 574.3.3 Erstellung der Leistungsbeschreibung 58

4.4 Phase „PLM-Solution-Design“ 594.4.1 Anforderungen an das Pflichtenheft 604.4.2 Lieferantenauswahl 614.4.3 Vertragsabschluss 62

4.5 Phase „Implementation & Integration“ 624.5.1 Implementierung 624.5.2 Customizing 634.5.3 Test 644.5.4 Inbetriebnahme 654.5.5 Review 65

5 Leithefte zu PLM-Aspekten 675.1 Evolution der Produkte organisieren 68

5.1.1 Konfigurationsmanagement 695.1.2 Versionen- und Variantenmanagement 705.1.3 Versionierung von Produkten 725.1.4 Konfigurationsmanagement als zentrale Funktion 745.1.5 Umsetzung von Konfigurationsmanagement 75

5.2 Produkte kontextabhängig darstellen 785.2.1 Sichtenmanagement 795.2.2 Strukturierungsprinzipien des Sichtenmanagements 805.2.3 Produktphasenbezogene Sichten 815.2.4 Technologieabhängige Sichten 815.2.5 Einführung eines Sichtenmanagements 82

5.3 Dokumente sicher verfügbar machen 845.3.1 Dokumentenmanagement 855.3.2 Typen von Dokumenten 865.3.3 Anforderungen an das Dokumentenmanagement 875.3.4 Strukturierung von Dokumenten 885.3.5 Beziehung zwischen Dokument und Artikel 905.3.6 Dokumente systemunterstützt verwalten 925.3.7 Umsetzung von Dokumentenmanagement 94

5.4 Produktdaten archivieren 985.4.1 Digitale Produktdatenarchivierung 995.4.2 Realisierung einer digitalen Produktdatenarchivierung 100

5.5 Nummernvergabe automatisieren 1025.5.1 Nummernsystematik 103

Inhaltsverzeichnis VII

5.5.2 Vorraussetzung für ein IT-konformes Nummernsystem 1045.5.3 Aufbau von Nummernsystemen 1045.5.4 Einführung/Restrukturierung des Nummernsystems 107

5.6 Finden statt Suchen 1095.6.1 Produktklassifizierung 1105.6.2 Klassifikation 1115.6.3 Voraussetzungen für die Klassifikation 1155.6.4 Aufbau von Klassifikationssystemen 1175.6.5 Klassifikation im Product Lifecycle Management 1205.6.6 Umsetzung der Klassifikation 121

5.7 Prozesse gestalten und steuern 1235.7.1 Prozess- und Organisationsmanagement 1245.7.2 Unterstützung von Prozessen und Organisation 1255.7.3 Kenntnis von Prozess- und Organisationsstrukturen 1265.7.4 Workflowmanagement mit Modellen 1285.7.5 Prozessmanagement als Basis der Systemanpassung 1325.7.6 Erstellen eines Unternehmensmodells 133

5.8 Transparente Änderungen gewährleisten 1415.8.1 Änderungsmanagement 1425.8.2 Potential im Änderungsmanagement 1435.8.3 Änderungsmanagement im Mittelstand 1435.8.4 Der Änderungsprozess im PLM 1455.8.5 Einführung eines Änderungsmanagements 147

5.9 Produktzentrierte Projektabwicklung 1515.9.1 Projektmanagement 1525.9.2 Planung und Steuerung des Engineering 1535.9.3 Hilfsmittel für das Projektmanagement 1535.9.4 Projektmanagement im Engineering 1555.9.5 Projektmanagement im PLM 1565.9.6 Umsetzung von Projetktmanagement-Konzepten 159

5.10 Auf Standardsystemen aufbauen 1615.10.1 Klassifizierung der Systemtypen 1625.10.2 Architektur von Standardsoftwaresystemen 1635.10.3 Anpassung von Standardsoftwaresystemen 1665.10.4 Durchführung von Anpassungen und Systempflege 168

5.11 Systeme kommunizieren lassen 1715.11.1 Applikationsintegration und Datenaustausch 1725.11.2 Optimiertes PLM durch Applikationsintegration 1735.11.3 Voraussetzung für Applikationsintegration 1745.11.4 Implementierung von Schnittstellen 1755.11.5 Informationsintegration im PLM 1785.11.6 Umsetzung von Integrationslösungen 181

VIII Inhaltsverzeichnis

5.12 Externe Dienstleister einbinden 1835.12.1 Auftragsvergabe 1835.12.2 PLM als Managementaufgabe 1845.12.3 Projektspezifikation 1855.12.4 Lastenhefterstellung 1865.12.5 Ausschreibung 1875.12.6 Lieferantenauswahl 1885.12.7 Pflichtenhefterstellung 1895.12.8 Realisierung 1905.12.9 Implementierung 1915.12.10Inbetriebnahme 1915.12.11Außerbetriebsetzung 192

5.13 Mitarbeiter für PLM motivieren 1935.13.1 Akzeptanzmanagement 1945.13.2 Wissenschaftliche Ansätze zur Mitarbeitermotivation 1945.13.3 PLM-Erfolg durch Mitarbeiterakzeptanz 196

6 Technische und methodische Grundlagen 2056.1 Produktkonfiguration 205

6.1.1 Versionen 2056.1.2 Gültigkeiten 2076.1.3 Varianten 2076.1.4 Sichten 2096.1.5 Konfiguration 209

6.2 Standardteile und Baukästen 2106.2.1 Standard- und Normteile 2116.2.2 Baukästen 211

6.3 Nummernsysteme 2126.3.1 Aufbau von Nummernsystemen 2146.3.2 Formen von Nummernsystemen 217

6.4 Klassifikation und Sachmerkmalleisten 2196.4.1 Sachmerkmalleisten 2196.4.2 Klassifikationsschlüssel nach Opitz 2216.4.3 Klassifikationsschlüssel nach Wiehndahl 2226.4.4 Klassifikationsschlüssel eClass 223

6.5 Vorgehensmodelle 2246.5.1 VDI-Richtlinie 2219 2246.5.2 CSC Catalyst 2276.5.3 Nutzenorientierte Einführung 229

6.6 Pflichtenheft und modellbasierte Dokumentation 2316.6.1 Inhalt eines Pflichtenheftes 2326.6.2 Anforderungen für den Software-Entwurf 234

Inhaltsverzeichnis IX

6.7 Systemevaluation 2366.7.1 Nutzwertanalyse 2366.7.2 Benchmarks 2376.7.3 Systemtests 238

6.8 Betriebwirtschaftliche PLM-Aspekte 2386.8.1 Definition der Wirtschaftlichkeit von PLM 2396.8.2 Nutzenanalyse 2426.8.3 Wirtschaftlichkeitsanalyse eines Integrationssystems 244

6.9 Modellierung 2466.9.1 Grundlagen der Unternehmensmodellierung 2476.9.2 Grundlagen der Datenmodellierung 248

6.10 Methoden und Tools 2536.10.1 Unternehmensmodellierungswerkzeuge 2536.10.2 CASE-Tools 2576.10.3 Systemspezifische Werkzeuge 257

6.11 Informationstechnologie 2586.11.1 Architektur von Informationssystemen 2586.11.2 Rechnernetze 2606.11.3 Grundlegende Informationstechnologien 2626.11.4 Schnittstellenstandards 265

PLM zum Nachschlagen 269Abkürzungen 269Glossar 271Persönlichkeiten und Kompetenzzentren 282Fachliteratur 285

Literaturverzeichnis 299

Stichwortverzeichnis 305

1 Einleitung

IT-Unterstützung wird immer mehr zum strategischen Wettbewerbsfaktor. Unternehmen sehen sich zunehmend der Herausforderung gegenüber, die informationstechnische Beherrschung des Produktlebenszyklus als Kern-kompetenz zu begreifen. Der entscheidende Faktor hierbei ist die Integra-tion aller Daten, Prozesse, Dokumente und Applikationen. Einen durch-gängigen Ansatz für diese Methode bietet das Paradigma des Product Lifecycle Managements (PLM), die in diesem Buch mittelständischen Unternehmen dargestellt wird.

Product Lifecycle Management beginnt mit Eigenleistung (Schöttner 2002). Für Unternehmen gilt, entsprechendes Know-how aufzubauen, zu pflegen und Informationsmanagement im Produktlebenszyklus als zentra-le, kontinuierliche Aufgabe im Unternehmen zu verankern. Das vorliegen-de Anwenderhandbuch soll die Durchführung dieser Aufgabe unterstützen und als Hilfestellung bzw. Nachschlagewerk für konkrete Teilaspekte des Product Lifecycle Managements dienen.

Anforderungen und die damit verbundenen PLM-Konzepte in den un-terschiedlichen Unternehmen sind viel zu individuell, um eine schrittweise Anleitung zur Verfügung stellen zu können. Das kann daher nicht Ziel des Anwenderhandbuches sein. Vielmehr soll Ihnen eine Arbeitsgrundlage zur Verfügung gestellt werden, die sie in die Lage versetzen soll, Ihren Weg zu einer eigen PLM-Umsetzung zu finden. So soll das Anwenderhandbuch ein Instrument zur durchgängigen Information sein, um PLM nachhaltig in Ihrem Unternehmen zu gestalten.

Damit richtet sich dieses Buch primär an alle, die direkt oder indirekt vom Thema PLM im Unternehmen betroffen sind, wie die Entscheidungs-träger, die einen entsprechenden Rahmen und Rückhalt für die PLM-Projekte bieten müssen, das IT-Team für die Umsetzung sowie alle An-wender wie beispielsweise die Konstruktion und Fertigung.

8 1 Einleitung

1.1 PLM-Historie

In den letzten 15 Jahren hat die Informationstechnik nicht nur Einzug in die Produkte sondern auch in den Entwicklungsprozess von Produkten erhalten. So hat sich in diesem Zeitraum die Produktentwicklung enorm verändert. Während noch vor 20 Jahren ausschließlich an Zeichenbrettern konstruiert und entwickelt wurde, hielt nach und nach Computer Aided Design (CAD) Einzug in die Unternehmen. Die ersten CAD-Systeme waren 2D-CAD-Systeme, die ein reines Pendant zum Zeichenbrett dar-stellten. Dieser Wandel wirkte sich zunächst nicht auf die Arbeitsmethodik aus. Es änderte sich lediglich das Medium, auf dem konstruiert wurde. Die Vorteile des neuen Mediums lagen in der Handhabbarkeit der Konstrukti-onen.

Nicht zuletzt durch leistungsfähigere und kostengünstigere Rechner konnten die CAD-Systeme zu 3D-CAD-Systemen weiterentwickelt wer-den, auf die heute viele Unternehmen umstellen oder schon umgestellt haben. Mit der Konstruktion im dreidimensionalen Raum entstehen neue Möglichkeiten für die Entwicklungsmethodik. Produkte werden nicht mehr von zweidimensionalen Zeichnungen sondern von dreidimensionalen Modellen repräsentiert. Dadurch wird eine neue Entwicklungsmethodik unterstützt, eine modellbasierte Methodik, die an der späteren Fertigung angelehnt ist. Diese Modelle sind ein ganzheitliches rechnerinternes Abbild der verkörperten Geometrien. So enthalten sie wesentlich mehr Informationen als herkömmliche Zeichnungen. Dies ermöglicht eine Weiterverwendung der Modelle über die Konstruktion hinaus beispiels-weise in Simulation und Fertigung.

Eine solche Veränderung schlägt sich auch auf die Ablage der Entwick-lungsergebnisse durch. Während Zeichnungen und 2D-CAD-Plotts in Archiven – als Medium dient Papier bzw. Mikrofiche – abgelegt werden, ist mit den 2D-CAD-Systemen die Möglichkeit der digitalen Dokumen-tenverwaltung beispielsweise mit einem Dokumenten-Management-Systemen hinzugekommen. Die Erfahrung zeigt jedoch, dass die wenigs-ten Unternehmen hiervon soweit Gebrauch machen, dass sie die herkömm-lichen Zeichnungsarchive ersetzen. 3D-Modelle können hingegen sinnvoll nur digital verwaltet werden. Daher wird mit der Einführung von 3D-CAD-Systemen ein Umdenken notwendig. In diesem Anwendungsspekt-rum haben sich in den letzten Jahren Engineering Data Management(EDM) bzw. Produktdaten-Management (PDM) mit entsprechenden Systemen etabliert, die inzwischen ganzheitlich in PLM-Konzepten An-wendung finden. Spätestens mit dieser Entwicklung hat ein Paradigmen-wechsel begonnen, der die Produktentstehung nachhaltig verändern wird.

1.2 Entstehungsgeschichte des Buches 9

Wie wird Ihr Unternehmen mit diesem Paradigmenwechsel umgehen? Ist Ihr Unternehmen reif für ein durchgängiges PLM? Dieses Buch, das sich primär an Unternehmen aus dem produzierenden Umfeld richtet, die sich selbst als kleinere und mittlere Unternehmen (KMU) sehen, stellt eine Möglichkeit der Herangehensweise an ein kontinuierliches Product Life-cycle Management mit der zentralen Aussage vor, dass PLM eine strategi-sche Aufgabe ist, die als solche etabliert und verstanden werden muss.

Denn auf Standardsoftware-Systemen basierende IT-Lösungen können die Unternehmensabläufe und -arbeitsweisen entscheidend positiv verän-dern. Sie sind noch lange kein Garant dafür, dass alle PLM-Potentiale eines Unternehmens effektiv erschlossen werden, bieten aber optimale Basiskonzepte zur Umsetzung der eigenen Anforderungen an PLM. Mit einem fundierten PLM-Ansatz wird auch Ihr Unternehmen für zukünftige Weiterentwicklung der IT im Produktentstehungsprozess gewappnet sein.

1.2 Entstehungsgeschichte des Buches

Dieses Anwenderhandbuch ist das Resultat eines zweijährigen For-schungsprojektes verbunden mit aktuellen Erkenntnissen aus Wissenschaft und Forschung. Die Forschungseinrichtungen „Lehrstuhl für Informations-technik im Maschinenwesen der TU München“ (itm) und das „For-schungszentrum Informatik an der Universität Karlsruhe (TH)“ (fzi) haben diesen Trend und dessen Bedeutung für mittelständische Unternehmen schon im Jahr 2001 erkannt und starteten im Jahr 2002 das vom Bundes-ministerium für Wirtschaft und Arbeit geförderte Verbundprojekt, „Vor-gehensmodell für ein kontinuierliches Product Lifecycle Informationsma-nagement für KMU“ (PLM4KMU) im Rahmen des Programms „Förde-rung von innovativen Netzwerken“ (InnoNet). Projektträger war „VDI/VDE Innovation und Technik GmbH“. Projektbeteiligte waren neben den zwei Forschungseinrichtungen neun mittelständische Unternehmen aus unterschiedlichen Branchen, KMU-Pioniere im Bereich Product Lifecycle Management.

Ziel des Projektes war es, die Integration von PLM bei KMU durch die Entwicklung eines generischen Vorgehensmodells zu unterstützen. Unter einem generischen Vorgehensmodell wird ein abstraktes Vorgehensmuster verstanden, das nach Bedarf an ein Unternehmen angepasst werden kann und so zum individuellen Vorgehensmodell ausgestaltet wird. Dieser Vorgang wird durch die Methodik, die in diesem Anwenderhandbuch vermittelt wird, unterstützt. In den zwei Projektjahren sind Erkenntnisse über Nutzen und Anforderungen für mittelständische Unternehmen in

10 1 Einleitung

diesem Bereich gereift. Mit dem Anspruch diese Erkenntnisse über den Kreis unseren Parterfirmen hinaus produzierenden Unternehmen zugäng-lich zu machen, haben wir uns entschlossen, das Wissen in diesem An-wenderhandbuch zusammenzufassen. In drei Detaillierungsebenen haben Sie die Möglichkeit, unterschiedlich tief in die Thematik einzusteigen. Der daraus resultierende dreistufige Aufbau wird in dem folgenden Abschnitt vorgestellt.

1.3 Aufbau und Anwendung des Handbuches

Das Handbuch umfasst sechs Kapitel. Nach dieser Einführung wird im Kapitel 2 Product Lifecycle Management in einem Gesamtabriss als kontinuierliche Aufgabe motiviert und auf die Komplexität des Themas eingegangen. So richtet sich dieses Kapitel primär an die Geschäftsführung und dient sowohl der Entscheidungsfindung als auch der organisatorischen und strategischen Einordnung. Das Kapitel 3 dient der Begriffsklärung der Grundmodelle des PLM-Paradigmas und beschreibt den Umgang mit diesen. Die hier angesprochenen Grundmodelle sind essentielle Basis für das in diesem Handlungsleitfaden vermittelte Verständnis von PLM. Hierauf folgt der Kern des Handlungsleitfaden, ein systematischer Ansatz für den Umgang mit PLM, der im Folgenden als Leitwerk bezeichnet wird, beschrieben in den Kapiteln 4 bis 6.

Jedes Unternehmen braucht seine individuelle PLM-Lösung abhängig von den spezifischen Gegebenheiten des Unternehmens. Zu diesen Fakto-ren gehören beispielsweise Produktkomplexität, Unternehmenscharakteris-tik, Unternehmensumfeld oder gesetzliche Rahmenbedingungen. Im Einzelnen wird auf diese Faktoren in der ersten Phase des evolutionären PLM-Vorgehensmodells, der Phase der PLM-Readiness, eingegangen. Eine weitere Anforderung an das Leitwerk resultiert – wie schon erwähnt – aus der anhaltenden Bedeutung von PLM im Unternehmen. PLM wird ein immerwährendes Thema in einem Unternehmen sein, das niemals voll-ständig abgeschlossen sein wird. Dementsprechend ist das Thema PLM für jedes KMU individuell und fortwährend zu gestalten und dies ist vom Leitwerk zu unterstützen. So war es nicht möglich, eine Anleitung zur Einführung von PLM zu erstellen, die sequentiell abgearbeitet werden kann. Vielmehr musste ein Leitwerk erstellt werden, dass abhängig von den Facetten des Unternehmens ausgestaltet werden kann. Um diesen Anspruch gerecht zu werden, ist das Leitwerk in drei Ebenen aufgebaut, die untereinander interaktiv, abhängig von den eigenen Anforderungen, verknüpft werden.

1.3 Aufbau und Anwendung des Handbuches 11

Klassifi-kation

Sichten-konzept

.........

Vorgehensmodell

Leithefte

Nachschlagwerk

PLM-Stab

PLM-Manifest

PLM-Vision

a

b

c

1.

2.3.

4.

d 1. PLM Readiness a. Bewertung/Zielsetzung

2. PLM Requirement Management b. Leistungsbeschreibung

3. PLM Solution Design c. Pflichtenheft

4. PLM Implementation & Integration d. Umsetzung

1. 2. 3. 4.Start eines Teil-

projekts projektiertvom PLM-Stab

Leistungs-beschreibung

erstellt

Pflichtenhefterstellt

Umsetzung erfolgt,getestet und

abgenommen

PLM-Unter-nehmensbewer-tung und Projekt-

zielsetzung erstellt

Produkt-struktur

Technische undmethodischeGrundlagen

PLM-Lexikon

Abb. 1-1: Aufbau des Leitwerks

12 1 Einleitung

Das Grundgerüst zeigt Abb. 1-1. In der ersten Ebene wird ein allge-meingültiges Vorgehensmodell dargestellt, das auf einem Spiralmodell basiert und in dessen Mittelpunkt ein generisches PLM-Manifest steht. Auf das PLM-Manifest wird im folgenden Kapitel näher eingegangen. Das Spiralmodell handelt iterativ die thematisch zusammenhängenden PLM-Aspekte ab, wobei der PLM-Stab und die PLM-Vision die Verträglichkeit der einzelnen Themen untereinander und die Gesamtzielsetzung sicherstel-len. Die betreffenden Themen werden situativ und anforderungsspezifisch in das Vorgehensmodell eingebunden. Sie werden in Form von Leitheften zur Verfügung gestellt, die in der zweiten Ebene aufgeführt sind.

Jedes Leitheft behandelt einen PLM-Aspekt ausführlich. Aufgebaut ist jedes Leitheft zur leichteren Orientierung nach einem einheitlichen Sche-ma. Nach einem einseitigen Abriss findet eine Einordnung des Themas in den PLM-Kontext statt. Im Kern eines Leitheftes wird die PLM-Relevanz des Themas diskutiert, ein Grundverständnis vermittelt sowie eine Umset-zung besprochen. Abgeschlossen wird ein Leitheft durch Arbeitsmateria-lien ergänzt durch Beispiele, Normen, Standards und weiterführende Literatur.

Somit stellen die Leithefte in ihrer Gesamtheit eine Art morphologi-schen Kasten für PLM dar und spiegeln den heutigen Stand der Technik wieder. Hierbei greifen die Leithefte wiederum auf Basiswissen zurück, das in der dritten Ebene des Leitwerkes vermittelt wird. Somit spiegelt das Handbuch den aktuellen Stand aus Forschung und Technik wieder. Wei-terentwicklungen und Erkenntnisse wird es in zukünftigen Auflagen in neuen Leitheften zu integrieren gelten.

Dieser Aufbau ermöglicht je nach Beweggründen des Lesers unter-schiedliche Leseströme. Möchten Sie sich einen schnellen Überblick über PLM und den Nutzen für Ihr Unternehmen verschaffen, empfiehlt es sich das Kapitel zwei und drei zu lesen. Durch die Leithefte 1 bis 3 („Evolution der Produkte organisieren“, „Produkte kontextabhängig darstellen“, „Dokumente sicher verfügbar machen“ s. Abschnitt 5.1, 5.2 und 5.3) und den Abstracts weiterer Leithefte kann zudem schnell ein umfassender Überblick über Funktionen der einzelnen PLM-Aspekte gewonnen wer-den. Soll der Handlungsleitfaden zur Realisierung einer durchgängigen PLM-Lösung herangezogen werden, ist das Kapitel 4 als zentrales Kapitel bezüglich des Vorgehensmodells zu lesen. Während der Umsetzung werden schließlich die Leithefte aus Kapitel 5 sukzessiv mit einbezogen. Das Nachschlagwerk des letzten Kapitels dient zum Aufbau eines Grund-verständnisses und kann bei Bedarf in das Studieren des Handbuches mit einbezogen werden.

2 PLM – eine kontinuierliche Aufgabe

Der Einsatz von Informationstechnologie wird zunehmend zu einem entscheidenden Wettbewerbsfaktor auch oder gerade bei produzierenden Unternehmen. Es spielt nicht mehr nur die Qualität und der Preis eines Produktes eine Rolle, sondern auch in welcher Zeit dieses Produkt entwi-ckelt, produziert und geliefert werden kann – also der Qualität der Unter-nehmensprozesse. Diese Faktoren können durch sinnvolle Nutzung von Informationstechnologien enorm verbessert werden. PLM ist dennoch nicht primär ein IT-Thema sondern vielmehr eine semantische, logische Aufgabenstellung, die nur durch eine intensive fachliche Auseinanderset-zung im eigenen Unternehmen nachhaltig umgesetzt werden kann. Dieses Anwenderhandbuch stellt im Folgenden einen Ansatz zur Diskussion, dessen Kernaussage besteht darin, dass die Umsetzung des PLM-Paradigmas ein Vorgehensschema benötigt, das aus dem in diesem Buch beschriebenen Metaschema gewonnen werden kann.

2.1 Begriffsklärung

Im gesamten Produktlebenszyklus (engl.: product lifecycle), das heißt von der Idee über Entwicklung und Konstruktion, Produktion sowie Vertrieb und Service bis zur Außerbetriebnahme eines Produktes entstehen große Mengen an verschiedensten Daten, Dokumenten und Informationen. Die technische Entwicklung der Werkzeuge zur Erzeugung und Verwaltung dieser Informationen hat sich im Laufe der Zeit stark gewandelt, wie etwa bei der Erstellung von technischen Zeichnungen vom Zeichenbrett über 2D-CAD-Systeme zu 3D-CAD-Systemen oder bei der Verwaltung vom Papierarchiv hin zu PDM-Systemen.

Das Product Lifecycle Management (Abk.: PLM) ist ein integrierendes Konzept zur IT-gestützten Organisation aller Informationen über Produkte und deren Entstehungsprozesse über den gesamten Produktlebenszyklus hinweg, so dass die Information immer aktuell an den relevanten Stellen im Unternehmen zur Verfügung stehen. Die Summe aller unterstützenden

14 2 PLM – eine kontinuierliche Aufgabe

IT-Systeme, die bei der Umsetzung des PLM-Konzeptes Verwendung finden, wird im Folgenden als Integrationssysteme bezeichnet.

Die Umsetzung von Product Lifecycle Management sollte als ein Ge-samtkonzept für die Wertschöpfung in die Unternehmensabläufe integriert werden. Dieses Konzept darf nicht als Einführung bzw. Betrieb eines weiteren IT-Systems wie z.B. Produktdatenmanagement (PDM) oder Enterprise Ressource Planning (ERP) gesehen werden, sondern es integ-riert einzelne Systeme als Teilkonzepte zu einer Gesamtlösung für das Informationsmanagement im Unternehmen. Die folgende Abbildung soll diesen Ansatz grafisch verdeutlichen. In einem Unternehmen werden 2 Kernprozesse mit gewissen Überschneidungen gesehen. Das Product Lifecycle Management fokussiert die Produkte mit ihren Entstehungspro-zessen, während orthogonal dazu das Enterprise Ressource Planningvorrangig die Produktion adressiert. Die Schnittstelle zwischen den zwei Prozessen wird dem PLM zugerechnet. Unterschiedliche Software-Systeme, Methoden und Informationen realisieren gesamtheitlich die IT-Unterstützung dieser Prozesse (siehe Abb. 2-1).

Pro

jekt

ieru

ng

Qualitätssicherung

Entwicklung

Konstruktion

Dokumen-tation

Arbeits-vorbereitung

Fertigung

Montage

Lief

erun

g

Rec

hnun

gs-

wes

en

Product Lifecycle Management

Projektsteuerung

Auftrags-steuerung

Einkauf

Pro

dukt

ions

-pl

anun

g

Absatz-planung

Vertrieb

Verkauf

CAD

CAMFEM

CAQ......

Papier-dokumente

Ent

erpr

ise

Res

sour

ce P

lann

ing

Wartung

Betrieb

Service

Verschrot-tung

Re-cycling

Abb. 2-1: Konzept des Product Lifecycle Managements

2.1 Begriffsklärung 15

Eine zusammenfassende Definition für PLM bieten beispielsweise die Liebensteiner Thesen des sendler/circle (Sendler, 2004):

• Product Lifecycle Management (PLM) ist ein Konzept, keine (in sich abgeschlossene) Lösung.

• Zur Umsetzung/Realisierung eines PLM-Konzeptes werden Lösungs-komponenten benötigt. Dazu zählen CAD, CAE, CAM, VR, PDM und andere Applikationen für den Produktentstehungsprozess.

• Auch Schnittstellen zu anderen Anwendungsbereichen wie ERP, SCM oder CRM sind Komponenten eines PLM-Konzeptes.

• PLM-Anbieter offerieren Komponenten und/oder Dienstleistung zur Umsetzung von PLM-Konzepten.

Eine Aussage von John Stark verdeutlicht den Unterschied zwischen PDM und PLM nochmals: „PDM – An essential enabler for PLM“ (Stark 2005). Für ihn ist das PDM-System die essentielle Basis, die technologische Integrationsplattform, die PLM ermöglicht. Andere sehen PLM als Erwei-terung von PDM mit spezifischen Funktionen. Vertreter dieses Ansatzes sind häufig bei Softwarehäusern zu finden, die ihre Systeme „PLM-Systeme“ nennen (Corban 2004). In diesem Anwenderhandbuch wird PLM als ein Konzept verstanden, das auf integral wirkenden IT-Lösungen basiert. Das Konzept ermöglicht eine produktzentrische Sicht auf alle produktbeschreibenden Daten und Informationen unter Berücksichtigung der informatonsverarbeitenden Prozesse über den gesamten Lebenszyklus hinweg. Product Lifecycle Management subsumiert hierfür eine Fülle von Einzelaspekten.

Wird PLM als eine Gesamtsicht unter Einbezug aller integrierenden IT-Systeme verstanden, bleibt jedoch ein ständiger Wandel des PLMs nicht aus. Veränderungen im Unternehmensumfeld, der verwendeten Technolo-gien, Veränderungen in der IT-Infrastruktur oder strukturelle Veränderun-gen in der Organisation bzw. in den Abläufen und nicht zuletzt Verände-rungen in der Produktpalette wirken sich auf die Ziele bzw. die Umsetzung von PLM aus. Folglich entwickelt sich PLM im Unternehmen ständig weiter. Es wird niemals die endgültige PLM-Lösung geben. Vielmehr muss von einer ständigen Weiterentwicklung des PLMs im Unternehmen ausgegangen werden. Ein Unternehmen sollte sich vor dieser immerwäh-renden Aufgabe PLM nicht verschließen, sondern sich der neuen Heraus-forderung bewusst werden und PLM als kontinuierliche Aufgabe mit strategischer Bedeutung im Unternehmen verankern.

16 2 PLM – eine kontinuierliche Aufgabe

2.2 Vorgehen bei der PLM-Umsetzung

Zu Beginn eines Vorgehens steht immer eine Vision. In dem Moment, in dem man sich mit einem Thema auseinandersetzt, wird eine gewisse Erwartungshaltung an das Thema geweckt. Mit wachsendem Interesse und Informationen konkretisieren sich schließlich die Erwartungen. So verhält es sich auch mit dem Product Lifecycle Management. Auch dieses Hand-buch wird seinen Beitrag zu Ihren Erwartungen an PLM beitragen. Ab einer gewissen Erwartungshaltung lassen sie sich zu einer Vision formulie-ren, mit der sich das Thema im Unternehmen kommunizieren lässt. Dies sollte sich ein Unternehmen zu nutzen machen und diese Vision mit Unterstützung der Unternehmensführung verbindlich festhalten. Die Vielzahl der Teilaspekte, die eng ineinander verzahnt ganzheitlich PLM darstellen, gestalten PLM zu komplex, um alle Aspekte in einem Projekt umsetzen zu können. Daher stellt dieses Buch ein iteratives Abhandeln von thematisch zusammenhängenden PLM-Aspekten in einzelnen Teilprojek-ten vor, die mit überschaubarem finanziellem und zeitlichem Aufwand abgewickelt werden können. Die Einführung und die Weiterentwicklung finden stufenweise in einzelnen Teilprojekten statt, um ein risikobehaftetes allumfassendes „PLM-Projekt“ zu vermeiden.

Eine ähnliche Herausforderung muss bei großen Softwareprojekten ge-meistert werden, bei denen sich das Boehmer-Spiralmodell als geeignetes Vorgehensmodell etabliert hat. Angelehnt an dieses Spiralmodell, erweitert um spezifische PLM-Komponenten, steht das evolutionäre PLM-Vorgehensmodell im Zentrum dieses Buches, mit dem in Schleifen ein ständiger Näherungsprozess an die optimale unternehmensspezifische PLM-Lösung, die PLM-Vision, stattfindet. Daher kommt es auf das richtige Vorgehen an. Ein methodisches Vorgehen auf Basis eines Vorge-hensmodells, eine Schablone bzw. Muster für ein Vorgehen, ist unabding-bar. Unterstützende Handlungsleitfäden stellt dieses Buch in Rahmen eines kontinuierlichen Vorgehensmodells zur Verfügung. Dies kann jedoch nur mit einer systematischen Vorgehensweise und einer durchgängigen, möglichst formalen Dokumentation zielführend sein. Ähnlich wie bei anderen Ingenieurstätigkeiten, beispielsweise einer Bauzeichnung für ein Haus, bietet sich auch im PLM eine grafische Beschreibung mit fest definierten Elementen an, einem Modell. Ein gut strukturiertes Modell ist die beste Möglichkeit, die Komplexität des PLMs greifbar zu machen.

2.3 Komplexität dauerhaft beherrschen 17

2.3 Komplexität dauerhaft beherrschen

Ein wesentlicher Erfolgsfaktor bei der Einführung von PLM ist die Durch-dringung der Komplexität des Themas. Die Komplexität muss bis zu einem gewissen Grad vom Unternehmen selbst beherrscht werden, da im PLM Prozesse und Produktstrukturen verwaltet werden, die zu den Kern-kompetenzen jedes Unternehmens zuzuzählen sind. Hierin ist die Komple-xität des PLMs auch begründet. Je komplexer Produkte, Prozesse und die dazugehörigen Dokumente sind, desto komplexer gestaltet sich ein integ-riertes PLM. Für einzelne Aufgaben versprechen unterschiedliche IT-Systeme eine Lösung. Jedoch wird kein Unternehmen ein System finden, das alle geforderten Aufgaben bewältigen kann. Lediglich einzelne Aufga-benstellungen werden mit gewissen IT-Systemen abgefangen. Wird das gesamte Unternehmen mit allen eingesetzten Tools betrachtet, wird man feststellen müssen, dass die Systeme sich teilweise ergänzen, teilweise überschneidende Funktionen haben oder sich sogar widersprechen. Nicht alle Aufgaben werden systemtechnisch unterstützt. Die Datenflüsse haben typischerweise mehrere Brüche und der Mensch dient als Puffer, um diese abzufangen. Ein systemtechnisch unterstütztes PLM soll diese Problematik angehen.

So können heute grundsätzlich mehrere Ansätze zur Integration von PLM diskutiert werden. Ein föderaler Ansatz sieht eine Vielzahl von Systemen zur Aufgabenbewältigung vor. Während in diesem Ansatz die Komplexität in der Vernetzung der Systeme liegt, könnte ein anderer zentraler Ansatz ein umfangreiches Einzelsystem priorisieren, das sich auf Grund von Funktionsumfängen und unternehmensspezifischen Anpassung komplex darstellen wird. Eine allgemeingültige Antwort auf die Frage, welcher Ansatz zu bevorzugen ist, gibt es nicht. Der Ansatz dieses An-wenderhandbuchs ist es, PLM zunächst losgelöst von Systemen auf kon-zeptioneller Ebene zu betrachten, um einen Weg zur besten Lösung für das eigene Unternehmen zu finden. Daher ist eine Einteilung in unterschiedli-che Ebenen sinnvoll. Die hier vorgestellte Unterteilung sieht drei Stufen vor, in denen jeweils die Organisation, die Prozesse, die Produkte sowie alle zugehörigen Daten betrachtet werden.

1. Das Fachkonzept ist losgelöst von sämtlichen Systemen. Auf dieser Ebene wird einzig ein Konzept für PLM betrachtet. Durch die Loslö-sung von Systemen zeichnet sich das Fachkonzept durch Beständigkeit über System-, Release- und Technologie-Wechsel hinaus aus. In diesem Konzept ist das gesamte Know-how über den eigenen Produktlebens-zyklus festgehalten. Daher gehört zu den elementaren Ansätzen dieses Handlungsleitfadens, dass jedes Unternehmen selbst für das Fachkon-

18 2 PLM – eine kontinuierliche Aufgabe

zept verantwortlich ist. Eine Fremdvergabe an Dienstleistungsunter-nehmen ist nach Möglichkeit zu vermeiden! Lediglich Unterstützung zur Erstellung des Fachkonzeptes kann zugekauft werden. Eine mög-lichst formale Beschreibung dieses PLM-Konzepts ist für den Erhalt dieses Know-hows dringend empfehlenswert. Im Folgenden werden hierfür modellbasierte Methoden vorgestellt.

2. Das DV-Konzept bildet die zweite Stufe dieser Unterteilung. In dieser Ebene wird das Fachkonzept auf der IT-Infrastruktur abgebildet. Das heißt, dass hier die einzusetzenden Systeme erstmals mit betrachtet wer-den. Es muss festgelegt werden, welches IT-System welche Aufgaben des Fachkonzeptes übernimmt und wie diese durch Schnittstellen oder Integrationsmethoden gekoppelt werden sollen. So wird in dieser Ebene die IT-technische Umsetzung definiert. Nur wenn ein Unternehmen in der Lage ist, seine Anforderungen präzise zu formulieren, kann ein Sys-temlieferant die entsprechende Systemlösung liefern. Auch diese Ebene sollte vom Unternehmen selbst verantwortet werden. Jedoch ist ein stär-kerer Einbezug von externen Dienstleistungsunternehmen möglich und durchaus sinnvoll.

3. Die Implementierung, die in der Regel ein aufwendiges Anpassen einer Standard-Software darstellt, stellt die unterste Ebene dieser Betrachtung dar. Alle notwendigen Eingriffe in die Systeme bis hin zu administrati-ven Tätigkeiten werden in dieser Ebene beschrieben. Hierzu zählen bei-spielsweise auch kommentierte Quellcodes von Schnittstellen oder ei-genen Tools. Die Implementierung wird gerade bei mittelständischen Unternehmen in der Regel von externen Unternehmen eingekauft. Trotzdem sollte das eigene Unternehmen im Besitz dieser Unterlagen sein, um unabhängig vom umsetzenden Unternehmen zu sein. Dies wird sich spätestens bei bevorstehenden Änderungen positiv auswirken.

Aber nicht nur konzeptionelle Gedanken sondern alle getätigten und geplanten Aktivitäten sollten formal in den drei Ebenen der Modellierung beschrieben sein. Mit dieser Aussage kommt noch ein zeitlicher Aspekt in die Modellierung. Hier wird im Allgemeinen zwischen Ist- und Soll-Modellen unterschieden. Teilweise wird sogar noch eine dritte zeitliche Stufe, die Plan-Modelle, für einen mittelfristigen Zeithorizont eingeführt. Nur so kann ein Unternehmen gelassen auf den Wandel im Umfeld reagie-ren. Im Fokus des Unternehmens sollte jedoch das Fachkonzept stehen. Auf einem hohen Abstraktionsgrad müssen alle Produktinformationen und deren zugehörigen Abläufe aus unterschiedlichen Sichten und über mehre Hierarchieebenen in einem Modell beschrieben sein. Dieses „Integrierte Produktmodell“ ist Basis für Diskussion und Kommunikation. Es repräsen-tiert einen wesentlichen Teil der PLM-Kompetenz des Unternehmens.

2.4 Nutzen und Aufwendungen 19

Empfehlenswert ist es, die Verantwortung dieses Modells in eine eigens geschaffene Organisationseinheit zu legen, die nicht aus Anwendern besteht, da diese erfahrungsgemäß für diesen Abstraktionsgrad aus dem eigenen Aufgabenbereich zu vorbelastet sind. Vergleichbar eines Quali-tätsbeauftragten sollte es auch einen Beauftragten für PLM geben, der in diesem Buch als PLM-Stab bezeichnet wird. Er sollte mit dem Freiraum einer Stabsstelle ausgestattet sein, so dass er den PLM-Akteuren die notwendige Rückendeckung geben kann.

2.4 Nutzen und Aufwendungen

Ein viel diskutiertes Thema bei der PLM-Einführung ist die Frage nach der Rentabilität. Was kostet PLM, was wird durch PLM eingespart? Pauschal-antworten auf diese Fragen gibt es nicht. Dieses Kapitel versucht vielmehr, Anhaltspunkte und Kriterien für eine unternehmenseigene Bewertung zu vermitteln.

2.4.1 Chancen durch Veränderung

Das Product Lifecycle Management betrifft alle Bereiche eines Unterneh-mens und bietet somit ein großes Potenzial für die Optimierung der Ge-schäftsabläufe und damit einhergehend eine Verbesserung der Produktqua-lität. Produkte können schneller und kostengünstiger entwickelt werden. Informationen zum Produkt selbst und zu archivierten Entwicklungsstän-den bis hin zu Vorgängerprodukten stehen jederzeit im aktuellen oder einem anderen gewünschten Zustand dem gesamten Unternehmen zur Verfügung. Mit PLM wird der Grundstein für einen durchgängigen organi-sationsübergreifenden Informationsfluss für den Produktentstehungspro-zess gelegt.

Allerdings erfordert die effiziente Nutzung von PLM ein großes Maß an Planung und konzeptionelle Vorarbeit, um die Erfordernisse des eigenen Unternehmens erfolgreich umsetzen zu können. Dies fängt mit einem Überdenken der Geschäftsabläufe an. Durch das Verwirklichen eines durchgängigen PLM-Konzeptes unter Einsatz entsprechender IT eröffnen sich neue Möglichkeiten für unterstützte Prozesse, die genutzt werden sollten. Als Beispiel sei hier die Parallelisierung von Prozessen mit dem Ziel, das Konzept des Concurrent Simultaneous Engineering (CSE) umzusetzen, genannt. Die Veränderung der Prozesse wirkt sich unweiger-lich auf die Arbeitsweise jedes Mitarbeiters aus. Daher spielt die Einbezie-hung der Mitarbeiter eine große Rolle, da diese die neuen Unternehmens-

20 2 PLM – eine kontinuierliche Aufgabe

abläufe tragen und leben müssen. In diesem Zusammenhang ist darauf zu achten, dass man sich nicht ein zu enges und zu starres Korsett durch zu restriktiv wirkende Systeme anlegt, um schnell und flexibel auf das sich fortlaufend ändernde Unternehmensumfeld reagieren zu können.

Prinzipiell lässt sich der wirtschaftliche Nutzen auf die Verbesserungder drei, sich gegenseitig beeinflussenden Erfolgsfaktoren Durchlaufzeit, Kosten und Qualität zurückführen. Durch die Unterstützung der Paralleli-sierung von Prozessen und der nicht zur Wertschöpfung beitragenden Tätigkeiten wie z. B. Informationsbeschaffung, Datenaufbereitung, Ände-rungen, können Auftragsdurchlaufzeiten reduziert werden. Durch die Verwendung von Standardsystemen zur ganzheitlichen Prozess-/Datenintegration kann eine zeitgleiche, unternehmensweite Bereitstellung relevanter Daten sowie ein transparenter, geregelter Zugriff (Sperrmecha-nismen) ermöglicht werden. Somit können beispielsweise parallel zur Produktentwicklung Montage- und Fertigungsabläufe durch entsprechende Vorfreigaben konzipiert oder zeitkritische Beschaffungsvorgänge des Werkzeug- und Betriebmittelbaus rechtzeitig eingeleitet werden.

Ein weiterer wichtiger Aspekt zur Zeitverkürzung ist die Reduzierung von vermeidbaren Änderungen. Nicht-PLM-basierte Informationsstruktu-ren lassen ausschließlich klassische, sequentielle und arbeitsteilige Pro-duktentstehung zu. Fehler und Mängel bleiben über weite Strecken unent-deckt, da ein Informationsabgleich entlang des Produktentstehungsprozes-ses meist nur durch aufwendige Abstimmungspunkte erfolgt. Unstimmig-keit haben schließlich zeit- und kostenintensive Änderungsprozesse zur Folge, die selbst auch noch eine gewisse Zeit in Anspruch nehmen, gerade wenn diese noch papiergestützt sind. Beispielsweise durch die Einführung eines Workflow-Managementsystem im Rahmen einer PLM-Umsetzung können Änderungsaufträge um ein vielfaches beschleunigt werden, da alle betroffenen Stellen im Unternehmen frühzeitig mit aktuellen Informatio-nen versorgt werden. Die Änderungszeit wird drastisch reduziert und darüber hinaus ist sichergestellt, dass kein von der Änderung betroffenes Dokument vergessen wird. Dadurch wird die Konsistenz des Datenbestan-des erheblich verbessert und eine redundante Modelldatenhaltung nahezu vermieden.

Des Weiteren trägt die Reduzierung von Such- und Kommunikations-zeiten erheblich zur Durchlaufzeitverkürzung bei. Durch die traditionell arbeitsteilige Aufgabenbearbeitung, in welcher jeder Funktionsbereich seinen eigenen Datenbestand als Arbeitsgrundlage aus Informationen des vorherigen Bereiches aufbaut, folgt, dass Produktinformationen (z. B. Lagerbestände, Betriebsmittel usw.) mehrfach und meist unabhängig voneinander an vielen Stellen gespeichert und gepflegt werden. Durch die wiederholte Datenaufbereitung resultieren redundante, inkonsistente und

2.4 Nutzen und Aufwendungen 21

meist fehlerhafte Datenbestände, deren Bezug zwischen den verteilten Unterlagen und dem aktuellen Produktstatus verloren geht. Durch eine PLM-Umsetzung wird die Suche und Verteilung von Daten, Dokumenten und Informationen effizienter gestaltet.

Der größte Erfolgsfaktor der Kostensenkung resultiert aus der Reduzie-rung von Doppelarbeit. Die für ein Produkt entstehenden Kosten werden entscheidend in der Konstruktionsphase festgelegt. So stellt jedes wieder-holt konstruierte Bauteil aufgrund fehlender, unübersichtlicher oder falscher Information für das Unternehmen eine Fehlinvestition dar. Jedes noch so kleine, mehrfach konstruierte und erzeugte Bauteil verursacht neben den Konstruktionskosten vermeidbare Ausgaben in Arbeitsplanung, NC-Programmierung, Werkzeug- und Betriebsmittelbau, Disposition etc. Deshalb verfügt ein ganzheitliches PLM über Klassifizierungssysteme und Sachmerkmalleisten, die die Wiederverwendung von Bauteilen in neu zu entwickelnden Produkten erleichtern. Durch diese Wiederverwendung und das daraus resultierende kleinere Teilespektrum werden Potentiale ge-weckt, die sich beispielsweise bis zu einer Reduktion des Lagerplatzes und damit einhergehend auf die Kapitalbindungskosten auswirken.

Auf Grund der Komplexität der Eingriffe in ein Unternehmen in Prozes-se und Produkte bis hin zur Organisation ist es äußert schwierig, verlässli-che Aussagen zu einem quantifizierbaren Nutzen zu treffen. Gleichfalls ist eine genaue Zuordnung von Kosten nicht einfacher. In den folgenden Abschnitten wird zwischen strategischem und wirtschaftlichem Aspekt unterschieden, um Anhaltspunkte für eine Aufwand-/Nutzen-Analyse zu geben.

2.4.2 Strategische Betrachtung

Ist ein Unternehmen in der Lage, das eigene Product Lifecycle Manage-ment über das Unternehmen hinaus in den Markt zu tragen, wird vom strategischen Nutzen von PLM gesprochen. Heutiges PLM ermöglicht und unterstützt die Abbildung von strukturierten konfigurierbaren Produkten in Bezug auf die gesamte Ablauforganisation eines Unternehmens einschließ-lich der Änderungs- und Freigabeprozesse und einer Dokumentation, die langfristig archiviert werden kann. Eine Gewährleistung dieser Punkte bietet neue Möglichkeiten in virtuellen Entwicklungsverbünden. Für einen Original Equipment Manufacture (OEM) kann dies sogar ein Kriterium zur Wahl seines Zulieferers sein. So schreibt beispielsweise der Automo-bilhersteller Opel seinen Zulieferern die Einbindung aller Engineering-Daten von Geometriedateien über Produktstrukturen bis hin zu Ferti-gungsdaten im Opel-spezifischen PDM-System vor (Obermann 2003).

22 2 PLM – eine kontinuierliche Aufgabe

So lässt sich der strategische Aspekt weiter unterteilen. Zum einen kön-nen aus PLM resultierende Daten als Produkt verkauft werden. Im obigen Beispiel verlangt Opel als OEM dies sogar. Dieser Aspekt ist vor allem bei Unternehmen von entscheidender Bedeutung, die im Sinne einer „verlän-gerten Werkbank“ in Prozesse eines anderen Unternehmens eingebunden sind. Zum anderen kann PLM zum Marketingargument werden. Abgesi-cherte und automatisierte Abläufe und eine qualitativ hochwertige Doku-mentation sichern eine hohe Qualität der Unternehmensprozesse. Dies wirkt sich selbstverständlich auch positiv auf eine Unternehmenszertifizie-rung beispielsweise nach ISO 9000:2000 aus (s. Abschnitt 2.5.3). Der strategische Nutzen von PLM lässt sich nicht allgemein quantifizieren. Wie die oben aufgeführten Argumente in eine Aufwand-/Nutzen-Analyse eingehen, bleibt dem jeweiligen Unternehmen belassen.

2.4.3 Wirtschaftliche Betrachtung

Neben dem strategischen Aspekt bringt PLM auch messbare, finanziell quantifizierbare Verbesserungen mit sich, den wirtschaftlichen Aspekt. Jedoch ist dieser Aspekt auch nicht wesentlich leichter zu ermitteln. Statistische Erhebungen, wie sie beispielsweise in der VDI 2219 über Zeitersparnis durch den Einsatz von PDM vorliegen, können als Erfah-rungswerte und Anhaltspunkte für die Aufstellung von Kalkulationen herangezogen werden.

Der wirtschaftliche Aspekt wird sichtbar, wenn in einem Unternehmen die produktbezogene Prozesskette bzw. die dazugehörigen Geschäftspro-zesse untersucht werden und dem gegenüber ein Szenario aufgestellt wird, wie diese Prozesse mit einem integrierten PLM-Konzept aussehen würden. Doppelarbeit, fehlende Schnittstellen, zeitversetzte oder unvollständige Weitergabe von Dokumenten und Informationen verursachen Zusatzkosten durch Verzögerung in der Fertigung, durch mangelhafte Qualität oder gar Ausschuss. Das kann bewertet werden. Es gibt darüber hinaus auch noch die Möglichkeit einer Zurückverfolgung, an welchen Stellen der Prozess-kette signifikante Fehler oder Mehrarbeiten aufgetreten sind. Verzögerun-gen führen zu Imageverlusten und können Konventionalstrafen oder Marktverluste zur Folge haben. Dies kann bis zum Verlust von Folgeauf-trägen führen. Eine Bewertung dieses Potentials ist schon deutlich schwie-riger.

Diese wirtschaftliche Betrachtung bezog sich auf den Prozess. Aber auch die Möglichkeiten, die sich für das Produkt ergeben, wirken sich positiv auf eine Wirtschaftlichkeitsbetrachtung aus. Produktvarianten erfahren eine immer größere Bedeutung. Mit marginalen Mehrkosten in

2.4 Nutzen und Aufwendungen 23

der Entwicklung und der Fertigung erhält die Produktreihe einen Mehr-wert. In der Prozesskette bedeutet dies, dass Varianten- und Konfigurati-ons-Management ohne IT-Unterstützung der PLM-Systematik nur sehr aufwendig und meistens fehlerhaft gehandhabt wird.

Als Beispiel sei eine Leiterplatte und Software mit verschiedenen Vari-anten zu einer Motorsteuerung genannt. Unterschiedliche Versionen der Leiterplatte und unterschiedliche Versionen der Software können für einen Bearbeiter und einen Benutzer zum Alptraum werden. Die Qualitätssiche-rung weist hierbei Mängel auf. Ein Verwendungsnachweis ist mitunter auch schwierig. Das kann dann besonders der Fall sein, wenn im Ferti-gungsprozess ein Austausch von Komponenten durch Alternativkompo-nenten erfolgt ist, der aber nicht ausreichend dokumentiert wurde. Das Resultat sind in jedem Fall höhere Kosten. Je eher diese Fehlerbehebung oder Schließung der Lücken der produktbezogenen Prozesskette erfolgt, desto größer ist die wirtschaftliche Auswirkung. Man geht davon aus, dass die Fehlerbehebung in der Entwicklungsphase mit Kosten von 1,- €, Kosten in den Folgephasen von mehr als 1.000,- € vermeidet.

Natürlich müssen diesen Potentialen auch Kosten gegenüber gestellt werden. Auf den ersten Blick erscheint PLM als reines IT-Thema, was es aber nicht ist. Zugegeben, IT spielt eine wichtige Rolle, noch wichtiger jedoch sind die kurz- und langfristigen strategischen Ziele der organisato-rischen und informationstechnischen Vernetzung über Abteilungsgrenzen, Bereichs- und Geschäftsfeldgrenzen sowie über Unternehmensgrenzen hinweg. Das Wissen steckt in den eigenen Köpfen. Die Lösung muss moderiert, vereinbart, strukturiert, dokumentiert und verabschiedet wer-den. Eine Umsetzung geht nur Schritt für Schritt. Der PLM-Ansatz ist ein gedanklicher Weg zur Effizienz-, Produkt-, Anwendungs- und Entsor-gungsverbesserung, der vom Management gelebt werden muss. Der Weg ist das Ziel.

Eine universelle PLM-Lösung gibt es nicht. Für jedes Unternehmen ist, auch unter Einbeziehung von Lieferanten und Kunden ein individueller Ansatz zu erarbeiten. Dies ist kein Widerspruch zu einer Realisierung mit so genannten Standard-Softwarekomponenten. Dies sagt jedoch nur, dass es kein fertiges Integrationssystem gibt, das gekauft werden kann. Die zu tätigenden Investitionen gehen darüber hinaus. Die Softwarekosten für ein PLM-Projekt werden erfahrungsgemäß lediglich zwischen 20% und 30% der Gesamtkosten liegen.

Aus den angeführten Gedanken dieses Kapitels muss jedes Unterneh-men seinen individuellen Nutzen im PLM ermitteln. Zuletzt zählt jedoch nur der langfristig quantifizierbare Produkt- und Kundennutzen. Eine detaillierte Wirtschaftlichkeitsanalyse sollte mit Hilfe des Abschnitts 6.8 „Betriebwirtschaftliche PLM-Aspekte“ erstellt werden.

24 2 PLM – eine kontinuierliche Aufgabe

2.5 Eingliederung ins Unternehmen

Viele wollen es, nur wenige haben es, das vollständig daten- und produkt-integrierende PLM. In Abschnitt 2.4 „Nutzen und Aufwendungen“ wurde ausgeführt, dass es keine allgemeingültige IT-Lösung gibt. Jede Umset-zung muss individuell für jedes Unternehmen erarbeitet werden. Zur Cebit 2004 wurde dies aus der IT-Sicht so formuliert: „IT-Firmen suchen den Königsweg zum Product Lifecycle Management“.

Ansätze sind aus den jeweiligen wirtschaftlichen Quellen der IT-Unternehmen erklärbar; CAx, ERP, PDM, CRM, SCM etc. Die zumeist erforderliche Individualität der funktionsoptimalen Software sucht häufig nach Integration über die Erweiterung der eigenen Funktionalität unter Beibehaltung der eigenen Datenmodelle (s. Abb. 2-2). Finden in einem Unternehmen mehrere Systeme dieser Art Anwendung, wovon auszugehen ist, entsteht ein Interessenskonflikt, welches Datenmodell Basis für eine Erweiterung sein kann. Der Ansatz des PLMs integriert all diese Systeme in einem Konzept zu einem übergreifenden Modell.

Wichtiger als die IT-technische Integration von PLM ist jedoch die or-ganisatorische Etablierung. Betroffen von PLM ist jeder im Unternehmen, das Management, das PLM tragen muss, die Anwender, die PLM leben müssen und ein IT-Team, die PLM umsetzen müssen. Dessen muss sich jeder bewusst werden, der PLM in seinem Unternehmen einführen muss. Um rechtzeitig eventuell auftretenden Problemen entgegenzuwirken zu können, empfiehlt es sich, eine Zuständigkeit in der Organisation festzule-gen, über die alle Betroffenen informiert und im Zweifelsfall motiviert werden. Das Anwenderhandbuch sieht auch diese Tätigkeit in der Verant-wortung des PLM-Stabs, der in Abschnitt 4.1.1 näher eingeführt wird.

2.5 Eingliederung ins Unternehmen 25

RecyclingVerschrottung Kundendienst

Design

Konstruktion

AV

Entwicklung

Fertigung

Vertrieb Marketing

EinkaufLogistik

Versand Logistik

Qua

lität

ssic

heru

ng

Standortelokalnationalglobal

Entwicklunginternextern

Aufheben der Abteilungsgrenzen durch vertikale und horizontale Kommunikation

Abb. 2-2: PLM-Umfeld

2.5.1 Akzeptanz für PLM schaffen

Die meisten Ansätze beziehen sich lediglich auf den eingeschränkten Bereich des Produktdaten-Managements im Kontext des Engineering, häufig nur im Bereich der Produktentwicklung. Außen vor bleiben meis-tens die Anforderungen des Herstellungsprozesses, des Betriebes, der Wartung, des Kundendienstes und der Rückführung/Entsorgung. Unter-schiedliche Datenmodelle für den Entwicklungsprozess, das Testlabor, den Herstellungsprozess, den Kundendienst, die Mängelerfassung etc. bei einem Produkt sind heute noch die Regel.

Aus diesem Grund soll das vorliegende Handbuch das Management eines Unternehmens in die Lage versetzen, die betriebswirtschaftliche Richtigkeit eines eingeschränkten, im Sinne der Definition, oder eines weit reichenden PLM-Ansatzes in die Planung, Entscheidung und Realisierung aufzunehmen. Die Definition des Ansatzes kann nur aus der Notwendig-keit und den Interessen des Unternehmens selbst erfolgen. Die Unterstüt-

26 2 PLM – eine kontinuierliche Aufgabe

zung durch externe Kompetenz, die nicht unter dem Zwang von Verkaufs-interessen steht, ist häufig sehr hilfreich bei der Formulierung der eigenen und der Kundenanforderungen. Für die Festlegung des individuellen PLM-Ansatzes gilt die Aussage Structure follows Strategy in höchstem Maße. Veränderungen von Strukturen bedürfen dann eines klaren Kurses und eines „sichtbaren Weges“. „Die Betroffenen zu Beteiligten machen“ ist eine fast unabdingbare Forderung für die Einführung eines erfolgreichen Product Lifecycle Managements, hierin liegt die größte Herausforderung aller Führungskräfte. Das Thema Motivation wird noch einmal im Leitheft „Mitarbeiter für PLM motivieren“ 5.13 aufgegriffen.

2.5.2 Betroffene im Unternehmen

Alle Führungskräfte sind betroffen nicht nur Anwender und zwar ohne Ausnahme. Das gilt besonders für die konzeptionelle Gesamtsicht und für die Einführung, auch in Teilschritten. Die stärker betroffenen Abteilungen benötigen die Unterstützung der weniger tangierten Bereiche des Unter-nehmens bei dieser strategischen Aufgabe. Der kapazitive Aufwand, der für eine erfolgreiche und langfristige PLM-Umsetzung erforderlich ist, wird immer einem Kraftakt gleichkommen. Die Akzeptanz der Betroffe-nen für die Einführung einer PLM-Systematik hat folgende Aspekte:

• Geschäftsführung Kostensenkung im Gesamtprozess d. h. ein höherer Ertrag. Das kann aber zur Folge haben, dass größere Kosten in der Produktentwicklung auftreten und eine signifikante Kostenreduzierung in den anderen Berei-chen, vor allem in der Fertigung eintritt.

• Produktentwicklung eine größere Transparenz und Verfügbarkeit der Unterlagen. Dies ist ein wichtiger Aspekt bei verteilter Produktentwicklung auf verschiedene Standorte.

• Qualitätsmanagement Zugriff auf die notwendigen Unterlagen und verbesserte Kontrolle von Freigaben.

• Arbeitsvorbereitung, Fertigung, Kundendienst und Recycling Zugriff auf aktuelle Unterlagen und Rückführung aus der Operation bedingter Änderungen. Dadurch wird eine leichte Verlagerung der ope-rativen Tätigkeiten an andere Standorte zur Kapazitätsauslastung, Un-terstützung von Verbundfertigung oder lediglich zur Kostensenkung möglich.