Product Lifecycle Management beherrschen: Ein Anwenderhandbuch für den Mittelstand, 2. Auflage

Product Lifecycle Management beherrschen

Volker Arnold · Hendrik Dettmering · Torsten Engel · Andreas Karcher

Product Lifecycle Management beherrschen Ein Anwenderhandbuch für den Mittelstand 2., neu bearbeitete Auflage

123

Dipl.Ing. Volker Arnold Dr. Fritz Faulhaber GmbH & Co. KG Daimlerstraße 23/25 71101 Schönaich Deutschland [email protected]

Dr.-Ing. Hendrik Dettmering Prozesswerk GmbH Lichtenbergstraße 8 85748 Garching Deutschland [email protected]

Torsten Engel EnBW Trading GmbH Durlacher Allee 93 76131 Karlsruhe Deutschland [email protected]

Prof. Dr.-Ing. Andreas Karcher Universität der Bundeswehr München Institut für Angewandte Informatik Professur für Softwarewerkzeuge und Methoden für Integrierte Anwendungen Werner-Heisenberg-Weg 39 85577 Neubiberg Deutschland [email protected]

ISBN 978-3-642-21812-5 e-ISBN 978-3-642-21813-2 DOI 10.1007/978-3-642-21813-2 Springer Heidelberg Dordrecht London New York Die Deutsche Nationalbibliothek verzeichnet diese Publikation in der Deutschen Nationalbibliografie; detaillierte bibliografische Daten sind im Internet über http://dnb.d-nb.de abrufbar. c Springer-Verlag Berlin Heidelberg 2005, 2011  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 Funksendung, der Mikroverfilmung oder der Vervielfältigung auf anderen Wegen und der Speicherung in Datenverarbeitungsanlagen, bleiben, auch bei nur auszugsweiser Verwertung, vorbehalten. Eine Vervielfä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ütungspflichtig. Zuwiderhandlungen unterliegen den Strafbestimmungen des Urheberrechtsgesetzes. Die Wiedergabe von Gebrauchsnamen, Handelsnamen, Warenbezeichnungen usw. in diesem Werk 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 jedermann benutzt werden dürften. Einbandentwurf: WMXDesign GmbH, Heidelberg Gedruckt auf säurefreiem Papier Springer ist Teil der Fachverlagsgruppe Springer Science+Business Media (www.springer.com)

Geleitwort zur 2. Auflage

Fast sechs Jahre sind vergangen, seit die Autoren mit der ersten Auflage des vorliegenden Praxis-Buches die Initiative ergriffen haben, Product Lifecycle Management (PLM) für Anwender und verantwortliche ITManager in seiner Gesamtheit aus einem praxisorientierten Blickwinkel darzustellen und die Einbettung eines kontinuierlichen PLM in die strategische Ebene zu motivieren. Die hohe Nachfrage nach der ersten Auflage einerseits, aber auch die inzwischen stark in den Fokus gerückte Problematik einer fundierten und nachhaltigen Beherrschung und Weiterentwicklung von IT-Lösungen im Unternehmen andererseits – heute mit dem Begriff IT-Governance zusammengefasst – zeigen, dass die Autoren bereits sehr früh die Dimension und Tragweite dieser Thematik erkannt und aufgegriffen haben. Heute könnte man das vorliegende Werk auch mit „PLMGovernance“ betiteln, steht doch die kontinuierliche Weiterentwicklung von IT-Lösungsbausteinen zur Verbesserung des Product Lifecycle Managements nach wie vor im Mittelpunkt. Die Thematik PLM ist zwar beherrschbarer geworden, beherrscht ist sie heute bei weitem nicht. Vielleicht wird sie es nie vollständig und allumfassend sein können. Dies ist mehreren Umständen geschuldet. Ein ganz zentraler Faktor bleibt, dass die aus den Dimensionen Produkt-, Prozess- und Technologiekomplexität resultierenden Anforderungen an ein ganzheitliches PLM sich permanent erweitern, dass wir es also mit einer „Moving Target Problematik“ zu tun haben. Ein weiterer Faktor ist sicherlich die immer stärkere Durchdringung der Produkte und Systeme mit Software, so dass das komplette SW-Engineering Bestandteil von PLM wird. Zwangsläufig prallen hier an einigen Stellen wie dem Konfigurationsmanagement ganz unterschiedliche Paradigmen aufeinander. Zudem erweitert sich das eigentliche Produkt um die für den Betrieb und die Nutzung notwendigen umgebenden Systeme und IT-Komponenten, die es ebenfalls zu integrieren gilt. Ein dritter wesentlicher Punkt ist die vor allem durch die Web-Technologien beschleunigte unternehmensübergreifende Kooperation von Zulieferern und Entwicklungspartnern. Hier prallen unterschiedliche Entwicklungskulturen und damit verbunden auch sehr vielgestaltige IT-Landschaften aufeinander, die nur in seltenen Fällen zu einer homogenen Gesamtinfrastruktur verschmolzen werden können.

VI

Geleitwort zur 2. Auflage

Soviel zu den gestiegenen Anforderungen und zur Komplexität von PLM. Was hat sich auf der anderen Seite in den vergangenen Jahren bezüglich Konzepten und Lösungsbausteinen getan? Hersteller von PLM-Lösungen arbeiten nach wie vor daran, ihre Systeme an diese neuen Anforderungen anzupassen. Die Entwicklungs- und Anpassungsgeschwindigkeit kann aber nicht mit der hohen Dynamik der PLM-Prozesse mithalten. Oft kaufen die größeren Anbieter kleine, innovative Lösungen auf und vermarkten sie unter ihrem Label, ohne eine wirkliche Systemintegration durchzuführen, da diese in vielen Fällen zu aufwändig wäre. Das heißt, hier lohnt ein sehr genauer Blick „unter die Motorhaube“. Die ganz großen, integrierten „All-in-One-Lösungen“ werden im PLM-Kontext heute aus den oben umrissenen Gründen kaum noch angestrebt. Der Trend geht eher zu „Rightsizing“ und zur Vernetzung von Teillösungen über neue Web-basierte Konzepte und Technologien. Hier sind Standards wie beispielsweise die PLM Services oder STEP wichtige Bausteine, allerdings wurden bei weitem noch nicht alle PLM-Aspekte heute in Standards adressiert. Auch stellt die Adaption und Umsetzung von Standards in IT-Plattformen insbesondere für kleine und mittlere Unternehmen nach wie vor eine große Hürde dar. Zugammengefasst wird deutlich, dass fortschreitende Technologien, Tools und Methoden für sich alleine noch kein Garant für die Erschließung neuer zusätzlicher Potenziale sind. Vielmehr liegt der Schlüssel zum Erfolg immer noch und heute vielleicht mehr als noch vor fünf oder zehn Jahren darin, die konzeptionellen Grundlagen von PLM im Unternehmen zu verankern und auf der Basis der verfügbaren Komponenten und Ansätze einen individuellen, unternehmensspezifischen Weg im Umgang mit dieser komplexen und anspruchsvollen Thematik zu finden. Die erste Auflage des vorliegenden Werkes ist vor gut sechs Jahren bereits mit genau dieser Intension entstanden. Die Entwicklungen in der jüngsten Vergangenheit haben der Grundthese Recht gegeben. Die vier Autoren, die sich nach wie vor alle im akademischen und. im industriellen Umfeld mit PLM beschäftigen, haben das Werk gründlich überarbeitet und neuere Entwicklungen adaptiert, sind ihrem Grundanspruch jedoch treu geblieben: ein praxisnaher und konzeptuell ausgerichteter PLM-Leitfaden. Ich wünsche dem Buch in dieser zweiten Auflage ebenso viel Erfolg wie der Erstveröffentlichung und bin gespannt, wie sich PLM weiterentwickeln wird. Ein These würde ich aber jetzt schon wagen: auch in einigen Jahren wird PLM immer ein herausforderndes Themenfeld sein.

München, im April 2011

Prof. Dr.-Ing. Klaus Bender

Vorwort zur 1. Auflage

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ützung der Produktlebenszyklen andererseits sorgen für eine zunehmende Beachtung auch bei den Entscheidungsträgern. Große Firmen insbesondere im Automobil- sowie im Luft- und Raumfahrtbereich 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 strategischen Managementebene installiert. Insbesondere für kleine und mittlere Unternehmen (KMU) stellt ITgestü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 integrationsfä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 weiterentwickeln 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 jeweiliges 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 aufzubauen und zu sichern, da PLM-Prozesse und Strategien längerfristig Be-

VIII Vorwort zut 1. Auflage

stand haben müssen. Deshalb gilt es, PLM im Unternehmen weitgehend 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 „Vorgehensmodell für ein kontinuierliches Product Lifecycle Informationsmanagement für KMU (PLM4KMU, (siehe auch www.plm4kmu.de)“ möglichst 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 Handlungsleitfaden 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 wesentliche Beiträge für dieses Buch eingebracht haben. Ferner gilt unser Dank allen Projektpartnern, die zum Erfolg unseres gemeinsamen Forschungsvorhabens 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

Inhalt

1

Einleitung 1.1 PLM-Historie 1.2 Entstehungsgeschichte des Buches 1.3 Aufbau und Anwendung des Handbuches

2

PLM – eine kontinuierliche Aufgabe 2.1 Begriffsklärung 2.2 Vorgehen bei der PLM-Umsetzung 2.3 Komplexität dauerhaft beherrschen 2.4 Nutzen und Aufwendungen 2.4.1 Chancen durch Veränderung 2.4.2 Strategische Betrachtung 2.4.3 Wirtschaftliche Betrachtung 2.5 Eingliederung ins Unternehmen 2.5.1 Akzeptanz für PLM schaffen 2.5.2 Betroffene im Unternehmen 2.5.3 Synergien zwischen PLM und Qualitätsmanagement

9 9 12 14 16 16 18 19 21 23 23

Modelle – Änderungen und Ergebnisse konsistent verwalten 3.1 Die Motivation des Modellierens 3.2 Modelle strukturieren 3.2.1 Ebenen eines Modells 3.2.2 Sichten eines Modells 3.2.3 Zustände eines Modells 3.3 Zentrale Modelle des PLM 3.3.1 Das integrierte Produktmodell 3.3.2 Bestandteile des integrierten Produktmodells 3.3.3 Aufbau eines integrierten Produktmodells 3.3.4 Das Prozessmodell 3.4 Weitere Modelltypen 3.5 Referenzmodelle 3.6 Modelle als Kern des PLM: Das PLM Manifest

27 27 30 30 32 33 34 36 37 39 40 42 43 45

3

1 2 3 4

24

X

Inhalt

4

Evolutionäres Vorgehensmodell 4.1 PLM als Paradigma im Unternehmen 4.1.1 PLM-Stab 4.1.2 PLM-Vision 4.1.3 Generisches PLM-Manifest 4.2 Phase „PLM Readiness“ 4.2.1 Maturity-Modell 4.2.2 Zielsetzung des Maturity-Modells 4.2.3 Abhängigkeiten der PLM-Funktionsblöcke 4.2.4 Anwendung des Maturity-Modells 4.2.5 Formulierung der Zielsetzung 4.3 Phase „PLM Requirement Management” 4.3.1 Analyse zur Leistungsbeschreibung 4.3.2 Planung der Ressourcen 4.3.3 Erstellung der Leistungsbeschreibung 4.4 Phase „PLM Solution Design“ 4.4.1 Anforderungen an das Pflichtenheft 4.4.2 Lieferantenauswahl 4.5 Phase „Implementation & Integration“ 4.5.1 Realisierung 4.5.2 Customizing 4.5.3 Verifizieren 4.5.4 Umsetzung 4.5.5 Review

49 50 51 53 54 55 57 58 58 60 64 66 67 68 69 71 72 73 75 76 77 78 79 80

5

Leithefte zu PLM-Aspekten 5.1 Evolution der Produkte organisieren 5.1.1 Konfigurationsmanagement 5.1.2 Management von Produktvarianten 5.1.3 Management von Produktversionen 5.1.4 Konfigurationsmanagement als zentrale Funktion 5.1.5 Umsetzung vom Konfigurationsmanagement 5.2 Produkte kontextabhängig darstellen 5.2.1 Sichtenmanagement 5.2.2 Strukturierungsprinzipien des Sichtenmanagements 5.2.3 Produktphasenbezogene Sichten 5.2.4 Disziplinabhängige Sichten 5.2.5 Einführung eines Sichtenmanagements 5.3 Dokumente sicher verfügbar machen 5.3.1 Dokumentenmanagement

81 82 83 84 87 90 93 95 96 97 98 99 100 102 103

Inhalt XI

5.4

5.5

5.6

5.7

5.8

5.9

5.3.2 Anforderungen an das Dokumentenmanagement 5.3.3 Strukturierung von Dokumenten 5.3.4 Beziehung zwischen Dokument und Produkt 5.3.5 Dokumente systemunterstützt verwalten 5.3.6 Umsetzung von Dokumentenmanagement Produktdaten archivieren 5.4.1 Digitale Produktdatenarchivierung 5.4.2 Realisierung einer digitalen Produktdatenarchivierung Nummernvergabe automatisieren 5.5.1 Nummernsystematik 5.5.2 Formen von Nummernsystemen 5.5.3 Aufbau von Nummernsystemen 5.5.4 Vorraussetzung für ein IT-konformes Nummernsystem 5.5.5 Einführung/Restrukturierung des Nummernsystems 5.5.6 Checkliste Finden statt Suchen 5.6.1 Produktklassifizierung 5.6.2 Aufbau von Klassifikationssystemen 5.6.3 Klassifikationskonzepte aus der Literatur 5.6.4 Voraussetzungen für die Klassifikation 5.6.5 Klassifikation im Product Lifecycle Management 5.6.6 Umsetzung der Klassifikation Prozesse gestalten und steuern 5.7.1 Prozess- und Organisationsmanagement 5.7.2 Unterstützung von Prozessen und Organisation 5.7.3 Kenntnis von Prozess- und Organisationsstrukturen 5.7.4 Workflow-Management mit Modellen 5.7.5 Prozessmanagement als Basis der Systemanpassung 5.7.6 Erstellen eines Unternehmensmodells Transparente Änderungen gewährleisten 5.8.1 Änderungsmanagement 5.8.2 Potential im Änderungsmanagement 5.8.3 Änderungsmanagement im Mittelstand 5.8.4 Der Änderungsprozess im PLM 5.8.5 Einführung eines Änderungsmanagements Produktzentrierte Projektabwicklung

104 105 108 110 112 117 118 119 121 122 123 124 129 130 133 134 135 136 139 148 149 150 153 154 155 157 159 164 167 175 175 177 177 179 182 185

XII

Inhalt

5.9.1 Projektmanagement 5.9.2 Hilfsmittel für das Projektmanagement 5.9.3 Projektmanagement im Engineering 5.9.4 Projektmanagement im PLM 5.9.5 Umsetzung von Projektmanagement-Konzepten 5.10 Auf Standardsystemen aufbauen 5.10.1 Produkt- und Ressourcenzentrierte integrierte Ansätze im PLM 5.10.2 Klassifizierung der Systemtypen 5.10.3 Architektur von Standardsoftwaresystemen 5.10.4 Anpassung von Standardsoftwaresystemen 5.10.5 Durchführung von Anpassungen und Systempflege 5.11 Systeme kommunizieren lassen 5.11.1 Applikationsintegration und Datenaustausch 5.11.2 Optimiertes PLM durch Applikationsintegration 5.11.3 Voraussetzung für Applikationsintegration 5.11.4 Standardschnittstellen 5.11.5 Systemtechnische Sicht – APIs und Middleware 5.11.6 Informationsintegration im PLM 5.11.7 Umsetzung von Integrationslösungen 5.12 Software in Produktstrukturen 5.12.1 Herausforderungen einer SW-Struktur 5.12.2 Strukturelemente 5.12.3 Kommunikative Abhängigkeiten 5.12.4 Einführung eines Software-PDM 5.13 Interdisziplinäres Datenmanagement 5.13.1 Optimale Prozessunterstützung 5.13.2 Klassifikation unterschiedlicher mechatronischer Entwicklungsprozesse 5.13.3 Umsetzung 5.14 Externe Dienstleister einbinden 5.14.1 Interne Klärung des Einsatzes von Dienstleistern 5.14.2 Einsatz externer Dienstleister 5.14.3 PLM als Managementaufgabe 5.14.4 Projektspezifikation 5.14.5 Lastenhefterstellung für Systemlieferantenauswahl 5.14.6 Ausschreibung 5.14.7 Lieferantenauswahl 5.14.8 Pflichtenhefterstellung 5.14.9 Realisierung

186 187 188 190 193 196 198 199 200 204 207 210 211 212 213 215 218 221 225 227 228 230 231 232 233 234 237 241 243 243 244 246 246 247 249 250 251 252

Inhalt XIII

5.14.10 Implementierung 5.14.11 Inbetriebnahme 5.14.12 Außerbetriebsetzung 5.15 Betriebswirtschaftlichen Erfolg der PLM-Einführung nachweisen 5.15.1 Definition der Wirtschaftlichkeit von PLM 5.15.2 Einmalige Kosten 5.15.3 Laufende Kosten 5.15.4 Nutzenanalyse 5.15.5 Wirtschaftlichkeitsanalyse eines Integrationssystems 5.16 Mitarbeiter für PLM motivieren 5.16.1 Akzeptanzmanagement 5.16.2 Wissenschaftliche Ansätze zur Mitarbeitermotivation 5.16.3 PLM-Erfolg durch Mitarbeiterakzeptanz 5.17 Trends und Ausblick 5.17.1 Wissens- und Innovationsmanagement 5.17.2 Business Intelligence 5.17.3 Anforderungen an Softwareanbieter und Wissenschaft

253 253 254 256 257 257 258 259 262 265 266 266 269 278 280 284 287

PLM zum Nachschlagen

291

Literatur

305

Stichwortverzeichnis

311

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 Kernkompetenz zu begreifen. Der entscheidende Faktor hierbei ist die Integration aller Daten, Prozesse, Dokumente und Applikationen. Einen durchgängigen Ansatz für diese Methode bietet das Paradigma des Product Lifecycle Managements (PLM), das in diesem Buch für mittelständische Unternehmen aufbereitet 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 zentrale, kontinuierliche Aufgabe im Unternehmen zu verankern. Das vorliegende Anwenderhandbuch soll die Durchführung dieser Aufgabe der Verankerung mit einer kontinuierlichen Pflege des Informationsmanagements im Produktlebenszyklus 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 unterschiedlichen Unternehmen sind jedoch viel zu individuell, um eine allgemeingültige schrittweise Anleitung hierfür zur Verfügung stellen zu können. Das kann daher nicht Ziel des Anwenderhandbuches sein. Vielmehr soll dem Leser eine Arbeitsgrundlage zur Verfügung gestellt werden, die ihn in die Lage versetzen soll, einen Weg zu einer eigenen, individuellen PLM-Umsetzung zu finden. So soll das Anwenderhandbuch ein Instrument zur durchgängigen Information sein, um PLM nachhaltig im Unternehmen zu gestalten. Damit richtet sich dieses Buch an alle, die direkt oder indirekt vom Thema PLM im Unternehmen betroffen sind, wie die Entscheidungsträ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 Endanwender beispielsweise in der Konstruktion und Fertigung.

V. Arnold et al., Product Lifecycle Management beherrschen, 2. Aufl., DOI 10.1007/978-3-642-21813-2_1, © Springer-Verlag Berlin Heidelberg 2011

2

1.1

1 Einleitung

PLM-Historie

In den letzten 20 Jahren hat die Informationstechnik nicht nur Einzug in die Produkte sondern auch in den Entwicklungsprozess von Produkten gehalten. So hat sich in diesem Zeitraum die Produktentwicklung enorm verändert. Während noch vor 30 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 darstellten. 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 Konstruktionen. Nicht zuletzt durch leistungsfähigere und kostengünstigere Rechner konnten die CAD-Systeme zu 3D-CAD-Systemen weiterentwickelt werden, auf die heute viele Unternehmen umstellen oder schon umgestellt haben. Mit der Konstruktion im dreidimensionalen Raum konnten neue Möglichkeiten für die Entwicklungsmethodik erschlossen werden. 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 beispielsweise in der Simulation, der Fertigung oder dem Service. Eine solche Veränderung beeinflusst elementar die Ablage der Entwicklungsergebnisse mit zwingenden Veränderungen in der gesamten Unternehmens-IT. Während Zeichnungen und 2D-CAD-Plots in Archiven – als Medium dient Papier bzw. Mikrofiche – abgelegt werden, ist mit den 2D-CAD-Systemen die Möglichkeit der digitalen Dokumentenverwaltung beispielsweise mit einem Dokumenten-Management-System hinzugekommen. Die Erfahrung zeigt jedoch, dass die wenigsten Unternehmen hiervon soweit Gebrauch machen, dass sie die herkömmlichen Zeichnungsarchive ersetzen. 3D-Modelle können hingegen sinnvoll nur digital verwaltet werden, da diese Modelle sich nun nicht mehr auf Zweidimensionale Dokumente ohne Informationsverlust projektieren lassen. Daher wird mit der Einführung von 3D-CAD-Systemen ein Umdenken notwendig. In diesem Anwendungsspektrum haben sich in den letzten Jahren Engineering Data Management (EDM) bzw. Produktdaten-Management (PDM) mit entsprechenden Systemen etabliert, die inzwischen ganzheit-

1.2 Entstehungsgeschichte des Buches 3

lich in PLM-Konzepten Anwendung finden. Spätestens mit dieser Entwicklung hat ein Paradigmenwechsel begonnen, der die Produktlebensphasen nachhaltig verändern wird. 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 Lifecycle Management mit der zentralen Aussage vor, dass PLM eine strategische Aufgabe ist, die als solche verstanden und etabliert werden muss. Denn auf Standardsoftwaresystemen basierende IT-Lösungen können die Unternehmensabläufe und -arbeitsweisen entscheidend positiv verändern. Sie sind jedoch per se 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 Weiterentwicklungen der IT im Produktentstehungsprozess gewappnet sein.

1.2

Entstehungsgeschichte des Buches

Die vorliegende zweite Auflage des Anwenderhandbuchs ist ursprünglich als Resultat eines zweijährigen Forschungsprojektes entstanden und nun in einer überarbeiten Fassung, in der insbesondere die Erfahrungen aus einer Vielzahl von Anwenderprojekten des hier publizierten Vorgehensmodells eingeflossen sind, vorliegend. Das bewährte zentrale Vorgehensmodell wurde von den Forschungseinrichtungen „Lehrstuhl für Informationstechnik im Maschinenwesen der TU München“ (itm) und „Forschungszentrum Informatik an der Universität Karlsruhe (TH)“ (fzi) entwickelt, die den Bedarf und die Bedeutung von PLM für mittelständische Unternehmen schon im Jahr 2001 erkannt haben und dieser Feststellung im Jahr 2002 mit dem Start des vom Bundesministerium für Wirtschaft und Arbeit geförderten Verbundprojekts „Vorgehensmodell für ein kontinuierliches Product Lifecycle Informationsmanagement für KMU“ (PLM4KMU) im Rahmen des Programms „Förderung von innovativen Netzwerken“ (InnoNet) nachkamen. Projektträger war seinerzeit „VDI/VDE Innovation und Technik GmbH“. Zum Projekt gehörten neben den beiden genannten Forschungseinrichtungen neun mittelständische Unternehmen aus unterschiedlichen Branchen, KMU-Pioniere im Bereich Product Lifecycle Management.

4

1 Einleitung

Ziel des Projektes war es, die Einführung und Integration von PLM bei KMU durch die Entwicklung eines generischen Vorgehensmodells zu unterstützen. Unter einem generischen Vorgehensmodell wird ein abstraktes, allgemeingültiges Vorgehensmuster verstanden, das je nach Bedarf an ein Unternehmen angepasst und so zum individuellen Vorgehensmodell ausgestaltet werden kann. Dieser Vorgang wird durch die Methodik unterstützt, die in diesem Anwenderhandbuch ausgeführt wird. In den zwei Projektjahren selbst und der Zeit, die seit der Einführung und Umsetzung der Methodik vergangen ist, sind wertvolle Erkenntnisse über Nutzen und Anforderungen von PLM für mittelständische Unternehmen in diesem Bereich gereift. Mit dem Anspruch, diese Erkenntnisse über den Kreis unseren Partnerfirmen hinaus produzierenden Unternehmen zugänglich zu machen, hatten die Autoren sich nach Projektabschluss im Jahr 2005 entschlossen, das Wissen in diesem Anwenderhandbuch zusammenzufassen. Vier Jahre später wird dieses Buch – angereichert um die Erfahrungsberichte unserer Leser, ergänzt um neue PLM-spezifische Erkenntnisse und auf den neuesten Stand der Autoren und Forschung gebracht – ein zweites Mal aufgelegt. In zwei Konkretisierungsstufen bietet das Buch je nach Vorkenntnis und Anforderungsprofil die Möglichkeit, auf unterschiedlichen Wegen in die Thematik einzusteigen. Der daraus resultierende zweistufige Aufbau wird in dem folgenden Abschnitt vorgestellt.

1.3

Aufbau und Anwendung des Handbuches

Die zweite Auflage des Handbuchs fasst die komplexe Thematik der Beherrschung von PLM in insgesamt fünf Kernkapiteln zusammen. Nach dieser Einführung wird im Kap. 2 Product Lifecycle Management zunächst in einem Gesamtabriss als kontinuierliche Aufgabe motiviert und auf die Komplexität des Themas als integrale und strategische Aufgabenstellung 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 Kap. 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 zweistufige Kern des Handlungsleitfadens, ein systematischer Ansatz für den Umgang mit PLM, der im Folgenden als Leitwerk bezeichnet wird, beschrieben in den Kap. 4 und 5.

1.3 Aufbau und Anwendung des Handbuches 5

Um den Aufbau des zweistufigen Leitwerks erläutern zu können, soll die anfängliche Motivation des Anwenderhandbuchs noch einmal in Erinnerung gerufen werden. Da es kein Patentrezept für eine PLM-Lösung aller mittelständischen Unternehmen geben kann, die eine einheitliche sequentielle Abarbeitung der einzelnen PLM-Aufgabenfelder vorschreibt, verfolgen die Autoren den Anspruch, das Vorgehen zu individuellen Lösungen abhängig von den spezifischen Gegebenheiten des Unternehmens zu formalisieren. Produktkomplexität, Unternehmenscharakteristik, Unternehmensumfeld oder gesetzliche Rahmenbedingungen sind hier beispielsweise zu nennen. Da PLM zudem als kontinuierliche Aufgabenstellung immerwährend in jedem Unternehmen verankert werden muss, die zu keinem Zeitpunkt einer Unternehmenshistorie jemals vollständig abgeschlossen sein wird, gliedert sich das Leitwerk dementsprechend einerseits in ein in Kap. 4 beschriebenes generisches Vorgehensmodell und anderseits in die Erläuterung und detaillierte Ausführung der einzelnen PLM-Aspekte in Kap. 5. Die PLM-Aspekte in Kap. 5 sind nach einer einheitlichen Vorlage beschrieben. Somit können die einzelnen Themen individuell in das Vorgehensmodell aus Kap. 4 eingebunden werden und haben so einen gewissen leitenden und zielführenden Charakter, weshalb sie als PLM-Leitheft bezeichnet werden. Somit stellt jedes Unterkapitel in Kap. 5 ein in sich geschlossenes Leitheft dar, das jeweils wie folgt strukturiert ist: Nach einem einseitigen Abriss findet zunächst eine Einordnung des Themas in den PLM-Kontext statt. Im Kern eines Leitheftes wird dann die PLM-Relevanz des Themas diskutiert, ein Grundverständnis vermittelt sowie eine Umsetzung dargestellt. Abgeschlossen wird ein Leitheft durch Arbeitsmaterialien, ergänzt durch Beispiele, Normen, Standards und weiterführende Literatur. Somit stellen die Leithefte in ihrer Gesamtheit eine Art morphologischer Kasten für PLM dar.

6

1 Einleitung

Abb. 1-1: Aufbau des Leitwerks

1.3 Aufbau und Anwendung des Handbuches 7

Die Abb. 1-1 verdeutlicht diese im Folgenden detailliert beschriebene Zweistufigkeit des Leitwerks. In der ersten Stufe ist das allgemeingültige Vorgehensmodell dargestellt. Dieses basiert auf einem Spiralmodell in dessen Mittelpunkt das sog. generische PLM-Manifest steht, das alle im Laufe der unternehmensspezifischen entstehenden beschreibenden Dokumente, Modelle und Methoden als den zentralen Know-how-Kern abbildet. Auf das PLM-Manifest wird in den folgenden Kapiteln noch näher eingegangen. Das Spiralmodell handelt iterativ die thematisch zusammenhängenden PLM-Aspekte ab, wobei ein im Unternehmen mit der kontinuierlichen Weiterentwicklung einer PLM-Vision betrauter PLM-Stab die Verträglichkeit der einzelnen Themen untereinander und die Gesamtzielsetzung sicherstellt. Die betreffenden Themen werden situativ und anforderungsspezifisch aus den zuvor eingeführten Leitheften in das Vorgehensmodell eingebunden. Während in der ersten Auflage des Handbuchs PLM-Grundlagen in einem separaten Kap. 6 gesondert diskutiert wurden, sind diese in der neuen Auflage in die PLM-Leithefte eingegangen, um so zu einer noch besseren Integration beizutragen. Dieser Aufbau ermöglicht je nach Ausgangsstand und Zielsetzung des Lesers unterschiedliche Leseströme. Möchten Sie sich einen schnellen Überblick über PLM und den Nutzen für Ihr Unternehmen verschaffen, empfiehlt es sich, die Kap. 2 und 3 zu lesen. Durch die Leithefte 1 bis 3 („Evolution der Produkte organisieren“, „Produkte kontextabhängig darstellen“, „Dokumente sicher verfügbar machen“, (siehe Abschnitt 5.1, 5.2 und 5.3) und die Abstracts weiterer Leithefte kann zudem schnell ein umfassender Überblick über Kernfunktionen der einzelnen PLM-Aspekte gewonnen werden. Soll der Handlungsleitfaden zur Realisierung einer durchgängigen PLM-Lösung herangezogen werden, stellt Kap. 4 das zentrale Kapitel bezüglich des Vorgehensmodells dar. Während der Umsetzung können schließlich sukzessiv die Leithefte aus Kap. 5 mit in eine vertiefte Auseinandersetzung mit PLM 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 immer mehr auch in welchem Zeitrahmen und mit welcher Qualität dieses Produkt konzipiert, entwickelt, produziert und geliefert werden kann – also der Qualität der produktnahen Unternehmensprozesse insgesamt. Diese Faktoren können durch sinnvolle Nutzung von Informationstechnologien enorm verbessert werden. Product Lifecycle Management (PLM) ist dennoch nicht primär ein IT-Thema sondern vielmehr eine konzeptionelle Aufgabenstellung, die nur durch eine intensive fachliche Auseinandersetzung im eigenen Unternehmen nachhaltig umgesetzt werden kann. Dieses Anwenderhandbuch stellt im Folgenden einen Ansatz zur Diskussion, dessen Kernaussage darin besteht, dass die Umsetzung des PLM-Paradigmas ein unternehmensspezifisches Vorgehensschema benötigt, das aus dem in diesem Buch beschriebenen allgemeinen Vorgehensstrukturmodell (Metaschema) abgeleitet und umgesetzt 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 von produktbeschreibenden Daten und Informationen vom Papierarchiv hin zu integrierten, standortübergreifenden Produktdatenmanagement-Systemen (PDM-Systemen).

V. Arnold et al., Product Lifecycle Management beherrschen, 2. Aufl., DOI 10.1007/978-3-642-21813-2_2, © Springer-Verlag Berlin Heidelberg 2011

10

2 PLM – eine kontinuierliche Aufgabe

Das Product Lifecycle Management ist ein integrierendes Konzept zur IT-gestützten Organisation und Verwaltung aller Informationen über Produkte und deren Entstehungsprozesse über den gesamten Produktlebenszyklus hinweg, sodass die richtige Information zum richtigen Zeitpunkt in der richtigen Form an der richtigen Stelle zur Verfügung steht. Der dazu notwendige Verbund an unterstützenden IT-Systemen, die bei der Umsetzung des PLM-Konzeptes Verwendung finden, wird im Folgenden als Integrationssystem bezeichnet. Die Umsetzung und kontinuierliche Verbesserung von Product Lifecycle Management sollte somit als ein Gesamtkonzept zur Verbesserung der produktnahen Wertschöpfungsketten in die Unternehmensabläufe integriert werden. Dieses Konzept darf also nicht als Einführung bzw. Betrieb eines einzelnen IT-Systems wie z.B. Produktdatenmanagement (PDM) oder Enterprise Ressource Planning (ERP) gesehen werden, sondern es integriert einzelne Systeme als Teilkonzepte zu einer Gesamtlösung für das Informationsmanagement im Unternehmen.

Abb. 2-1: Konzept des Product Lifecycle Managements

2.1 Begriffsklärung 11

Die Abb. 2-1 soll diesen Ansatz grafisch verdeutlichen. In einem Unternehmen werden zwei Kernprozesse mit gewissen Überschneidungen gesehen. Das Product Lifecycle Management fokussiert die Produkte mit ihren Entstehungsprozessen, während orthogonal dazu das Enterprise Ressource Planning vorrangig die Unternehmensressourcen und die damit realisierte Produktion adressiert. Die produktdatenspezifische Schnittstelle zwischen den beiden Kernprozessen wird dem PLM zugerechnet. Unterschiedliche Software-Systeme, Methoden und Informationen realisieren gesamtheitlich die IT-Unterstützung dieser beiden Prozessketten. Da PLM je nach Betrachtungswinkel und Hintergrund der Betrachter auf unterschiedliche Art und Weise eingeordnet werden kann, existiert auch heute noch eine Vielzahl an Definitionen oder Umschreibungen des Begriffes. Jedoch findet sich nur an wenigen Stellen eine einigermaßen exakte Begriffsklärung. Beispielsweise umschreiben die Liebensteiner Thesen des sendler/circle PLM wie folgt (Sendler 2004): x Product Lifecycle Management (PLM) ist ein Konzept, keine (in sich abgeschlossene) Lösung. x Zur Umsetzung/Realisierung eines PLM-Konzeptes werden Lösungskomponenten benötigt. Dazu zählen CAD, CAE, CAM, VR, PDM und andere Applikationen für den Produktentstehungsprozess. x Auch Schnittstellen zu anderen Anwendungsbereichen wie ERP, SCM oder CRM sind Komponenten eines ganzheitlichen PLM-Konzeptes. x PLM-Anbieter offerieren Komponenten und/oder Dienstleistungen zur Umsetzung von PLM-Konzepten. Eine Aussage von John Stark verdeutlicht den Unterschied zwischen PDM und PLM: „PDM – An essential enabler for PLM“ (Stark 2005). Für Stark ist das PDM-System die essentielle Basis, die technologische Integrationsplattform, die PLM ermöglicht. Andere sehen PLM als Erweiterung von PDM mit spezifischen Funktionen. Vertreter dieses Ansatzes sind häufig bei Softwarehäusern zu finden, die ihre Systeme mittlerweile „PLMSysteme“ 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 informationsverarbeitenden 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 ITSysteme verstanden, bleibt jedoch eine ständige Erweiterung und Anpassung des Einzugs- bzw. Abdeckungsbereiches von PLM nicht aus. Verän-

12

2 PLM – eine kontinuierliche Aufgabe

derungen im Unternehmensumfeld, der verwendeten Technologien, Veränderungen in der IT-Infrastruktur oder strukturelle Veränderungen in der Organisation bzw. in den Abläufen und nicht zuletzt Veränderungen 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. Dies mag auf den ersten Blick betrachtet ein wenig nach „Fass ohne Boden“ klingen und in der Tat stellt die erfolgreiche Einführung und kontinuierliche Weiterentwicklung eine herausfordernde und anspruchsvolle Aufgabenstellung dar, der sich ein Unternehmen aber keinesfalls verschließen sollte. Vielmehr gilt es, sich dieser neuen Herausforderung bewusst zu werden und PLM als kontinuierliche Aufgabe mit strategischer Bedeutung im Unternehmen entsprechend zu verankern, um die enormen Potenziale zukunftsgerichtet erschließen zu können. Hierzu möchte der in diesem Buch vorgestellte Ansatz einen konstruktiven und anwendergerechten Beitrag leisten.

2.2

Vorgehen bei der PLM-Umsetzung

Einer IT-Umsetzung steht zu Beginn immer eine Vision, eine an den Unternehmenszielen orientierte und möglichst genau formulierte Beschreibung der aktuellen Situation und der erwarteten Mehrwerte voran. Mit dem ersten Moment der Auseinandersetzung mit einem neuen Thema wird eine gewisse Erwartungshaltung an dieses Thema geweckt, die es zu formulieren, zu präziseren und ständig zu hinterfragen gilt. Mit wachsendem Interesse, vertiefter Auseinandersetzung mit der Thematik und mehr und mehr Erfahrungen und Informationen konkretisieren sich schließlich die Erwartungen. Entsprechend verhält es sich mit dem Themenkomplex Product Lifecycle Management. So wird auch dieses Handbuch zunächst seinen Beitrag zu Ihren Erwartungen an PLM leisten. Ab einer gewissen Eindringtiefe und Konkretisierungsstufe gilt es, PLM als Vision zu formulieren und die Erwartungshaltung auf der Managementebene festzuhalten. Das verbindliche Festschreiben Ihrer PLM-Vision unter Einbezug der Unternehmensführung ist somit der erste Schritt in der erfolgreichen Umsetzung unseres Vorgehensmodells. Aus dieser Vision lassen sich später die in einer Umsetzungsphase zu bearbeitenden PLM-Aspekte ableiten. Die Vielzahl aller Teilaspekte, die eng ineinander verzahnt ganzheitlich PLM darstellen, gestalten PLM zu komplex, um alle Aspekte in einem einzelnen

2.2 Vorgehen bei der PLM-Umsetzung 13

Projekt umsetzen und erfolgreich in die Wertschöpfungsketten integrieren zu können. Aus diesem Grund stellt dieses Buch ein iteratives Modell vor, das ein Abhandeln von thematisch zusammenhängenden PLM-Aspekten in einzelnen Teilprojekten möglich macht, die jeweils mit überschaubarem finanziellem und zeitlichem Aufwand und Risiko umgesetzt werden können. PLM-Einführung und -Weiterentwicklung finden so stufenweise in einzelnen Teilprojekten statt, um ein risikobehaftetes allumfassendes „BigBang-Projekt“ zu vermeiden. Diese Vorgehensweise ist im Grunde nicht neu. Eine ähnliche Herausforderung muss beispielsweise auch bei großen Softwareprojekten gemeistert werden, bei denen sich das Spiralmodell nach Boehm (Boehm 1988) als geeignetes Vorgehensmodell bewährt hat. Angelehnt an dieses Spiralmodell, angepasst an die speziellen Anforderungen und erweitert um spezifische PLM-Komponenten, steht das evolutionäre PLMVorgehensmodell im Zentrum dieses Buches, mit dem in Schleifen ein ständiger Näherungsprozess an eine optimale unternehmensspezifische PLM-Lösung stattfindet, die in der PLM-Vision festgeschrieben ist und ebenfalls ständig weiterentwickelt wird. Ein methodisches Vorgehen auf Basis des hier vorgestellten allgemeinen Vorgehensmodells ist unabdingbare Voraussetzung für ein erfolgreiches IT-gestütztes PLM. So ist das beschriebene Vorgehensmodell als Muster für die eigene Herangehensweise zu verstehen. Die für die einzelnen PLM-Aspekte in Form von Leitheften konzipierten und beschriebenen Bausteine gilt es nun sukzessive, dem allgemeinen Vorgehensmodell folgend und an die eigenen unternehmensspezifischen Anforderungen angepasst, in ein individuelles PLMVorgehensmodell und einzelne Umsetzungsprojekte zu überführen. Dieses Vorgehen kann jedoch nur mit einer systematischen, durchgängigen und möglichst formalen Beschreibung und Dokumentation aller Zusammenhänge, Strukturen und Dokumente 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 in Form eines Integrierten PLM-Modelles an. Eine gut strukturierte, modellbasierte Beschreibung aller PLM-Aspekte in einem solchen Modell ist die beste Möglichkeit, die Komplexität von PLM handhabbar und beherrschbarer zu machen. Der Gedanke der Komplexitätsbeherrschung durch modellhafte Beschreibungen wird im folgenden Abschnitt noch einmal motiviert und im Kap. 3 dann näher ausgeführt.

14

2.3

2 PLM – eine kontinuierliche Aufgabe

Komplexität dauerhaft beherrschen

Ein wesentlicher Erfolgsfaktor bei der Einführung von PLM ist die Durchdringung der Komplexität des Themas. Die Komplexität muss bis zu einem gewissen Grad vom Unternehmen selbst beherrscht werden, da mit PLM die produktnahen Prozesse und das Management aller produktspezifischen Daten und Dokumente und somit die Kernkompetenzen eines jeden Unternehmens abgebildet werden. Hierin ist die Komplexität von PLM begründet. Je komplexer Produkte, Prozesse und die dazugehörigen Daten und Dokumente sind, desto komplexer gestaltet sich ein integriertes Produktlebenszyklusmanagement. Für einzelne Aufgaben und Aspekte von PLM bieten unterschiedliche IT-Systeme entsprechende Lösungsbausteine. Jedoch wird kein Unternehmen ein „ideales“ PLM-System finden, das alle geforderten Funktionen zu 100% bewältigen kann. Vielmehr decken die am Markt verfügbaren Lösungen lediglich einzelne Teilbereiche und Funktionsspektren ab. Aufgrund von Randparameter wie beispielsweise die Betriebssystemplattform oder Architektur und Offenheit eines Systems müssen zudem manche am Markt verfügbaren Systeme von vornherein von einer möglichen Einführung ausgeschlossen werden, wodurch sich die Anzahl potentieller Systeme nochmals verringert. Zur unternehmensspezifischen Anpassung sind für jedes System immer mehr oder weniger große Anpassungen – das so genannte Customizing – erforderlich, das seinerseits ein konzeptionelles Fundament und einen entsprechenden Bauplan erforderlich macht. Wird das gesamte Unternehmen mit allen eingesetzten Engineering-Tools betrachtet, wird man feststellen müssen, dass die Systeme sich hinsichtlich der zur Verfügung gestellten Funktionen teilweise ergänzen, teilweise überschneidende Funktionen haben oder sich sogar funktional widersprechen. Umgekehrt können aber auch heute noch nicht alle produktnahen Aufgabenbereiche vollständig systemtechnisch durch entsprechende Werkzeuge unterstützt werden. Die Daten- und Informationsflüsse zwischen den Systemen weisen zudem Brüche auf und der Mensch dient immer noch als Puffer und Vermittler, um diese Informationsbrüche abzufangen. Ein integriertes, ganzheitliches PLM bewältigt diese Problematik schrittweise und bietet eine Basis zur Einbindung zukünftiger Systeme, die durch ständige Weiterentwicklung immer neue Möglichkeiten der IT-Unterstützung mit neuen Funktionen ermöglichen. Product Lifecycle Management ist daher eher eine fortwährende Managementaufgabe als eine einmalige SW-Einführung. Damit aus diesem so wichtigen, zentralen und immer stärker werdenden strategischen Themenkomplex aber kein „Fass ohne Boden“ wird, ist ein systematisches Vorgehensmodell unabdingbar. Dieses Buch setzt genau hier an.

2.3 Komplexität dauerhaft beherrschen 15

So können heute ganze unterschiedliche Grundansätze zur Integration von PLM diskutiert werden. Ein föderaler Ansatz sieht eine Vielzahl von einzelnen Systemen zur Aufgabenbewältigung entlang der Produktenstehungskette vor. Während in diesem Ansatz die Komplexität primär in der Vernetzung der Systeme liegt, könnte ein anderer eher zentraler Ansatz ein umfangreiches integriertes Gesamtsystem priorisieren, das sich aufgrund von Funktionsumfängen und unternehmensspezifischen Anpassungen jedoch ebenfalls als komplex darstellen wird. Eine allgemeingültige Antwort auf die Frage, welcher Ansatz zu bevorzugen ist, gibt es nicht. Der Ansatz dieses Anwenderhandbuchs ist es, PLM zunächst losgelöst von Systemen auf einer Fachkonzeptebene zu betrachten, um einen individuellen Weg zur besten Lösung für das eigene Unternehmen zu finden. Hierbei gilt es, die unterschiedlichen PLM-Konzepte in geeigneter Art und Weise zu strukturieren und zwar nach fachlichen Aspekten, nach Detaillierungsgraden und nach zeitlichen Aspekten (getätigte und geplante Aktivitäten). In Kap. 3 werden hierzu die entsprechende Strukturierungsmethoden vorgestellt. Einhergehend mit der Strukturierung der Konzepte ist eine Aufteilung der dabei entstehenden Arbeiten und Ergebnisse. Gleichzeitig ist es wichtig, dass die Einzelaktivitäten konsistent zueinander erfolgen. Mit dem in Kap. 4 vorgestellten PLM-Manifest soll diesem Umstand Rechnung getragen werden. Insbesondere durch das sog. Integrierte Produktmodell (siehe Abschnitt 3.3.1) werden im PLM-Manifest die Ergebnisse der PLMAktivitäten entlang der Zeitachse, der verschiedenen fachlichen Aspekte und der Detaillierungsgrade konsistent zusammengeführt. Dieses Integrierte Produktmodell ist Basis für die Konzeption, Diskussion und Kommunikation von PLM-spezifischen Ansätzen und Lösungsbausteinen. Es repräsentiert somit den wesentlichen Kern der PLM-Kompetenz eines jeden Unternehmens und sollte nicht vollständig in fremde Hände gelegt werden. Empfehlenswert ist es, die Verantwortung dieses Modells in eine eigens geschaffene Organisationseinheit zu legen, die jedoch nicht primär aus Anwendern bestehen sollte, da diese erfahrungsgemäß für den erforderlichen Abstraktionsgrad und vor dem eigenen Erfahrungshintergrund tendenziell dazu neigen, die alten Strukturen in ein IT-System zu zementieren, anstatt neue Möglichkeiten auszuloten. Vergleichbar mit dem Qualitätsbeauftragten sollte es in der Schnittstelle zwischen Unternehmensführung und PLM-Umsetzung zudem die Rolle eines Hauptbeauftragten für PLM geben, die in diesem Buch als PLM-Stab bezeichnet wird. Er sollte mit dem Freiraum einer Stabsstelle ausgestattet sein, die neues Denken möglich macht und den PLM-Akteuren die notwendige Rückendeckung geben kann.

16

2.4

2 PLM – eine kontinuierliche Aufgabe

Nutzen und Aufwendungen

Ein viel diskutiertes Thema bei der PLM-Umsetzung ist die Frage nach der Rentabilität. Was kostet PLM, was wird durch PLM eingespart? Pauschalantworten auf diese Fragen gibt es nicht. Dieses Kapitel versucht vielmehr, Anhaltspunkte und Kriterien für eine unternehmensindividuelle Bewertung zu vermitteln. 2.4.1 Chancen durch Veränderung Das Product Lifecycle Management betrifft alle Bereiche eines Unternehmens und bietet somit ein großes Potenzial für die Optimierung der Geschäftsabläufe und damit einhergehend eine Verbesserung der Produktqualität. Produkte können schneller und kostengünstiger entwickelt werden. Informationen zum Produkt selbst und zu archivierten Entwicklungsständen bis hin zu Vorgängerprodukten stehen jederzeit im aktuellen oder einem anderen gewünschten Zustand dem gesamten Unternehmen und sofern gewünscht auch Entwicklungspartnern zur Verfügung. Mit PLM wird der Grundstein für einen durchgängigen organisationsübergreifenden Informationsfluss für den Produktentstehungsprozess gelegt. Allerdings erfordert die effiziente Nutzung von PLM ein großes Maß an Planung und konzeptioneller 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 genannt, das Konzept des Concurrent and Simultaneous Engineering (CSE) umzusetzen. Die Veränderung der Prozesse wirkt sich unweigerlich auf die Arbeitsweise jedes Mitarbeiters aus. Daher spielt die Einbeziehung der Mitarbeiter eine große Rolle, da diese die neuen Unternehmensablä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 Verbesserung der drei sich gegenseitig beeinflussenden Erfolgsfaktoren Durchlaufzeit, Kosten und Qualität zurückführen. Durch das Ermöglichen der Prozessparallelisierung und der Unterstützung nicht unmittelbar zur Wertschöpfung beitragenden Tätigkeiten wie z.B. Informationsbeschaffung, Datenaufbe-

2.4 Nutzen und Aufwendungen 17

reitung, Änderungen können Auftragsdurchlaufzeiten reduziert werden. Durch die Verwendung von Standardsystemen zur ganzheitlichen Prozessunterstützung kann eine zeitgleiche, unternehmensweite Bereitstellung relevanter Daten und Dokumente sowie ein transparenter, geregelter Zugriff (z.B. über Sperrmechanismen) 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 Betriebsmittelbaus rechtzeitig eingeleitet werden. Ein weiterer wichtiger Aspekt zur Zeitverkürzung ist die Reduzierung von vermeidbaren Änderungen. Nicht-PLM-integrierte Informationsstrukturen lassen ausschließlich eine klassische d.h. sequentielle und arbeitsteilige Produktentstehung zu. Fehler und Mängel bleiben so über weite Strecken unentdeckt, da ein Informationsabgleich entlang des Produktentstehungsprozesses meist nur durch aufwendige Abstimmungspunkte erfolgt. Unstimmigkeiten haben schließlich zeit- und kostenintensive Änderungsprozesse zur Folge, die selbst auch wieder eine gewisse Zeit in Anspruch nehmen, gerade wenn diese noch papiergestützt sind. Beispielsweise können durch die Einführung eines Workflow-Managementsystems im Rahmen einer PLM-Umsetzung Änderungsaufträge um ein vielfaches beschleunigt werden, da alle betroffenen Stellen im Unternehmen frühzeitig mit aktuellen Informationen versorgt werden. Die Änderungszeit wird drastisch reduziert, und darüber hinaus ist sichergestellt, dass kein von der Änderung betroffenes Dokument übersehen werden kann. Dadurch wird die Konsistenz des Datenbestandes erheblich verbessert und eine redundante (Modell-)Datenhaltung weitestgehend vermieden. Des Weiteren trägt die Reduzierung von Such- und Kommunikationszeiten 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. Aus der wiederholten Datenaufbereitung resultieren redundante, inkonsistente und meist fehlerhafte Datenbestände, deren Bezug zwischen den verteilten Unterlagen und dem aktuellen Produktstatus verloren geht. Durch eine integrierte PLM-Umsetzung wird die Suche und Verteilung von Daten, Dokumenten und Informationen effizienter gestaltet. Der größte Erfolgsfaktor der Kostensenkung resultiert aus der Reduzierung von Doppelarbeit. Die für ein Produkt entstehenden Kosten werden entscheidend in der Konstruktionsphase festgelegt. So stellt jedes wieder-

18

2 PLM – eine kontinuierliche Aufgabe

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 beispielsweise über Klassifizierungssysteme und Sachmerkmal-Leisten, die die Wiederverwendung von Bauteilen in neu zu entwickelnden Produkten erleichtern. Durch diese Wiederverwendung und das daraus resultierende kleinere Teilespektrum werden Potentiale erschlossen, die sich beispielsweise bis zu einer Reduktion des Lagerplatzes und damit einhergehend auf die Kapitalbindungskosten auswirken. Aufgrund der Komplexität der mit PLM verbundenen Eingriffe in ein Unternehmen bezüglich Prozesse und Produkte bis hin zur Organisation ist es äußert schwierig, verlässliche Aussagen zu einem quantifizierbaren Nutzen zu treffen. Gleichfalls ist eine genaue Zuordnung von Kosten nicht einfacher. In den folgenden Abschnitten wird daher 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, am Markt durch das interne Product Lifecycle Management zu profitieren, 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 Änderungsund Freigabeprozesse und einer Dokumentation, die langfristig archiviert werden kann. Eine entsprechend geeignete Umsetzung und ITUnterstützung dieser Punkte bietet neue Möglichkeiten beispielsweise bezüglich der Einbindung in virtuellen Entwicklungsverbünden. Für einen Original Equipment Manufacturer (OEM) kann dies sogar ein entscheidendes Kriterium zur Wahl seines Zulieferers sein. Der Automobilhersteller Opel nahm beispielsweise schon sehr früh eine Vorreiterrolle bei der Einbindung seiner Lieferanten ein, in dem Opel schon seit 2002 alle Engineering-Daten von Geometriedateien über Produktstrukturen bis hin zu Fertigungsdaten von seinen Zulieferern im Opel-spezifischen PDMSystem einpflegen lässt (Obermann 2003). So lässt sich der strategische Aspekt weiter unterteilen. Zum einen können aus PLM resultierende Daten das Produkt aufwertend vermarktet

2.4 Nutzen und Aufwendungen 19

werden. Im obigen Beispiel verlangt Opel als OEM dies sogar von seinen Zulieferern. Dieser Aspekt ist vor allem bei Unternehmen von entscheidender Bedeutung, die im Sinne einer „verlängerten Werkbank“ in Prozesse eines anderen Unternehmens eingebunden sind. Zum anderen kann PLM zum Marketingargument werden. Abgesicherte und automatisierte Abläufe und eine qualitativ hochwertige Dokumentation sichern eine hohe Qualität der Unternehmensprozesse. Dies wirkt sich selbstverständlich auch positiv auf eine Unternehmenszertifizierung beispielsweise nach ISO 9000:2008 aus (siehe Abschnitt 2.5.3). Diese Beispiele zeigen, dass sich der strategische Nutzen von PLM nicht allgemein quantifizieren lässt. Wie die oben aufgeführten Argumente in eine Aufwand-/Nutzen-Analyse eingehen, hängt davon ab, welchen Stellenwert das jeweilige Unternehmen diesen Aspekten beimisst. 2.4.3 Wirtschaftliche Betrachtung Neben dem strategischen Aspekt bringt PLM messbare, finanziell quantifizierbare Verbesserungen mit sich, die den wirtschaftlichen Aspekt der Betrachtung des Nutzens ausmacht. Jedoch ist diese wirtschaftliche Bewertung nicht wesentlich leichter zu vollziehen. Statistische Erhebungen, wie sie beispielsweise in der VDI 2219 (VDI 2219) über Zeitersparnis durch den Einsatz von PDM vorliegen, können als Erfahrungswerte 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äftsprozesse untersucht werden und dem gegenüber ein Szenario aufgestellt wird, wie sich diese Prozesse im Sinne des Business Process Reengineering (BPR) in ein ganzheitliches PLM-Konzept zusammenführen und optimieren ließen. 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. Dies alles kann bewertet werden. Es gibt darüber hinaus die Möglichkeit einer Zurückverfolgung, an welchen Stellen der Prozesskette signifikante Fehler oder Mehrarbeiten aufgetreten sind. Verzögerungen führen zu Imageverlusten und können Konventionalstrafen oder Marktverluste zur Folge haben. Dies kann bis zum Verlust von Folgeaufträgen führen. Eine Bewertung dieses Potentials ist hingegen deutlich schwieriger. Die bisherigen Argumente einer wirtschaftlichen Betrachtung bezogen sich auf den Prozess. Gleichermaßen existieren Optimierungsmöglichkei-

20

2 PLM – eine kontinuierliche Aufgabe

ten, die sich für das Produkt ergeben und sich positiv auf eine Wirtschaftlichkeitsbetrachtung auswirken. Produktvarianten erfahren eine immer größere Bedeutung. Mit marginalen Mehrkosten in der Entwicklung und der Fertigung erhält die Produktreihe einen Mehrwert. In der Prozesskette bedeutet dies, dass Varianten- und Konfigurationsmanagement ohne geeignete IT-Unterstützung im Rahmen einer PLM-Systematik nur sehr aufwendig und meistens fehlerhaft umgesetzt werden kann. Als Beispiel sei eine Leiterplatte samt zugehöriger Software mit verschiedenen Varianten zu einer Motorsteuerung (Motorsteuergerät) genannt. Unterschiedliche Versionen der Leiterplatte und unterschiedliche Versionen der Software können für einen Entwickler genauso zum Alptraum werden, wie für den Nutzer dieses Gerätes, der den Einbaukontext und die Gesamtfunktion innerhalb eines größeren Produktes wie beispielsweise eines Flugzeuges oder einer Werkzeugmaschine verantwortet. Die Qualitätssicherung ist hier oftmals nicht mehr in der Lage, Mängel zuverlässig zu erkennen. Ein Verwendungsnachweis ist mitunter nicht mehr möglich. Das kann besonders dann der Fall sein, wenn im Fertigungsprozess ein Austausch von Komponenten durch Alternativkomponenten erfolgt ist, der aber nicht ausreichend durchgängig 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 mag PLM als reines IT-Thema erscheinen, was es aber nicht ist. IT spielt zwar eine wichtige Rolle, noch wichtiger jedoch sind die kurz- und langfristigen strategischen Mehrwerte einer organisatorischen und informationstechnischen Vernetzung über Abteilungen und Geschäftsfeldgrenzen sowie zunehmend auch über Unternehmensgrenzen hinweg. Das Wissen und Know-how steckt in den Köpfen der Ingenieure und Mitarbeiter. Eine ganzheitliche PLM-Lösung muss entsprechend moderiert, vereinbart, strukturiert, dokumentiert, verabschiedet und begleitet werden. Eine Umsetzung kann nur Schritt für Schritt entlang der unternehmensspezifischen Anforderungsstruktur erfolgen. Der PLMAnsatz ist somit ein konzeptueller Weg zur Effizienz-, Produkt-, Anwendungs- und Entsorgungsverbesserung, der vom Management vorgezeichnet und gelebt werden muss – oder um es ein wenig philosophischer auszudrücken: Der Weg ist das Ziel!

2.5 Eingliederung ins Unternehmen 21

Eine universelle PLM-Lösung gibt es somit – wie eingangs bereits allgemein ausgeführt – nicht. Für jedes Unternehmen ist, auch unter Einbeziehung von Lieferanten und Kunden, ein individueller Ansatz zu erarbeiten, sukzessive umzusetzen und immer wieder kritisch zu hinterfragen. Dies ist kein Widerspruch zu einer Realisierung mit so genannten Standard-Softwarekomponenten. Dies sagt lediglich aus, dass kein „Out-of-theBox-Integrationssystem“ existiert, das angeschafft, installiert und geringfügig angepasst werden kann. Die zu tätigenden Investitionen gehen vielmehr weit darüber hinaus. Die Softwarekosten für ein PLM-Projekt werden erfahrungsgemäß lediglich zwischen 20% und 30% der Gesamtkosten ausmachen. Der weitaus größere Teil der Kosten wird durch Prozessanpassungen und die damit verbundene Systemanpassung sowie Datenaufbereitungsmaßnahmen verursacht. Aus den angeführten Gedanken dieses Kapitels folgend muss jedes Unternehmen somit 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 5.15.5 erstellt werden.

2.5

Eingliederung ins Unternehmen

Viele wollen es, nur wenige haben es wirklich, das vollständig daten- und produktintegrierende PLM. In Abschnitt 2.4 wurde ausgeführt, dass es keine allgemeingültige IT-Lösung geben kann. Jede Umsetzung 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“. Wenn PLM dem übergreifenden Anspruch gerecht werden soll, sind damit viele weitere zentrale Bereiche und Funktionen im Unternehmen berührt, welche heute als Standardlösungen auf dem Markt verfügbar sind: 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 jeweiligen Datenmodelle (siehe Abb. 2-2). Finden in einem Unternehmen mehrere Systeme dieser Art Anwendung, wovon auszugehen ist, entsteht ein gewisser Interessenskonflikt, welches Datenmodell das führende für eine Erweiterung bzw. Integration sein kann. PLM impliziert somit immer auch die informationstechnische Integration aller Systeme hin zu einem übergreifenden Modell – eine schwierige und komplexe Aufgabenstellung.

22

2 PLM – eine kontinuierliche Aufgabe

Mindestens so wichtig wie die IT-technische Integration von PLM ist jedoch die organisatorische Etablierung. Berührt von PLM sind alle Unternehmensbereiche, angefangen vom Management, das PLM protegieren und verantworten muss, die Anwender, die PLM entlang der Wertschöpfungsketten leben müssen sowie die IT, die für eine erfolgreiche technische Einführung und ständige Weiterentwicklung verantwortlich ist. Dessen muss sich jeder bewusst werden, der PLM in seinem Unternehmen einführen möchte. Um rechtzeitig eventuell auftretenden Problemen entgegenzuwirken zu können, empfiehlt es sich, eine Zuständigkeit in der Organisation festzulegen, über die alle Betroffenen informiert und im Zweifelsfall motiviert werden. Das Anwenderhandbuch sieht auch diese Tätigkeit in der Verantwortung des PLM-Stabs, der in Abschnitt 4.1.1 näher eingeführt wird.

Abb. 2-2: PLM-Umfeld

2.5 Eingliederung ins Unternehmen 23

2.5.1 Akzeptanz für PLM schaffen Die Wurzeln von PLM liegen in der mit der Einführung von CADSystemen einhergehenden Digitalisierung produktbeschreibenden Daten – ursprünglich rein die Geometrie betreffend (sog. CAD-Modelle). Mit der rasanten Weiterentwicklung sind immer mehr produktspezifische Aspekte dazugekommen, und so liegen heute nahezu 100% aller produktbeschreibenden und die Entwicklung begleitenden Daten und Dokumente in digitaler Form vor. Dementsprechend konzentrieren sich die meisten Ansätze zur Einführung von PLM zunächst auf den eingeschränkten Bereich des Produktdaten-Managements im Kontext des Engineering, häufig auf den Bereich der Produktentwicklung beschränkt. Außen vor bleiben zunächst typischerweise die Anforderungen des Herstellungsprozesses, des Betriebes, der Wartung, des Kundendienstes und der Rückführung/Entsorgung. Unterschiedliche Datenmodelle für den Entwicklungsprozess, das Testlabor, den Herstellungsprozess, den Kundendienst, die Mängelerfassung etc. bei einem Produkt sind heute noch die Regel. Hier entfaltet ein ganzheitliches PLM seine wahre Stärke. Aus diesem Grund soll das vorliegende Handbuch das Management eines Unternehmens in die Lage versetzen, die betriebswirtschaftliche Richtigkeit der unterschiedlichen PLM-Ansätze zu bewerten. Die Definition des Ansatzes kann nur aus der Notwendigkeit und den Interessen des Unternehmens selbst erfolgen. Die Unterstützung durch externe Kompetenz, die nicht unter dem Zwang von Verkaufsinteressen steht, ist häufig sehr hilfreich bei der Formulierung von eigenen und von Kundenanforderungen. Für die Festlegung des individuellen PLM-Ansatzes gilt die Aussage „Struktur folgt der Strategie“ 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 für die Führungskräfte. Das Thema Motivation wird noch einmal im Leitheft „Mitarbeiter für PLM motivieren“ im Abschnitt 5.16 aufgegriffen. 2.5.2 Betroffene im Unternehmen Neben den Anwendern sind ebenfalls alle Führungskräfte betroffen, und zwar ohne Ausnahme. Das gilt besonders für die konzeptionelle Gesamtsicht und für die Einführung von Lösungsbausteinen, auch in Teilschritten. Die stärker betroffenen Abteilungen benötigen die Unterstützung der we-

24

2 PLM – eine kontinuierliche Aufgabe

niger tangierten Bereiche des Unternehmens 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 Betroffenen für die Einführung einer PLMSystematik hat folgende Aspekte: x Geschäftsführung: verfolgt Kostensenkung im Gesamtprozess zur Ertragssteigerung. Das kann jedoch zur Folge haben, dass größere Kosten in der Produktentwicklung auftreten und eine signifikante Kostenreduzierung in den anderen Bereichen, vor allem in der Fertigung eintritt. x Produktentwicklung: verfolgt eine größere Transparenz und Verfügbarkeit aller Unterlagen. Dies ist ein wichtiger Aspekt bei verteilter Produktentwicklung an verschiedenen Standorten. x Qualitätsmanagement: wünscht sich Zugriff auf die notwendigen Unterlagen und verbesserte Kontrolle von Freigaben. x Arbeitsvorbereitung, Fertigung, Kundendienst und Recycling: erstreben Zugriff auf aktuelle Unterlagen und Rückführung aus der Operation bedingter Änderungen. Dadurch wird eine leichte Verlagerung der operativen Tätigkeiten an andere Standorte zur Kapazitätsauslastung, Unterstützung von Verbundfertigung oder lediglich zur Kostensenkung möglich. 2.5.3 Synergien zwischen PLM und Qualitätsmanagement Betrachtet man die grundsätzliche Struktur eines prozessorientierten Qualitätsmanagement-Systems nach DIN ISO 9000:2008 als kontinuierliche Verbesserung des Systems im Spannungsfeld zwischen Kundenanforderungen und der erreichten Kundenzufriedenheit, so ist eine Analogie mit PLM nicht zu übersehen. Bei PLM stehen die Produktdaten und deren Integrität durch alle Kern- und Führungsprozesse im Fokus der Betrachtung. Hier können Synergien nutzbar gemacht werden, die vor allem bei der schon verfügbaren prozessorientierten Denkweise des Personals und der Dokumentation zu sehen ist. Auch das Management kennt die Diskussionen „pro und contra Bürokratismus“ aus der Entwicklung des Qualitätsmanagement-Systems. Einschränkend darf nicht unerwähnt bleiben, dass sich das QM-System, nach DIN ISO 9000:2008, häufig nur auf den Herstellungsprozess konzentriert entsprechend der integrativen Notwendigkeit des jeweiligen Unternehmens.

2.5 Eingliederung ins Unternehmen 25

Erste Erfahrungen zeigen aber, dass die Erweiterung der qualitätsrelevanten Prozesse auf spätere Schritte im jeweiligen Produktlebenszyklus (z.B. Update/Upgrade, Rückführung/Recycling/Verschrottung) vergleichsweise einfach zu realisieren ist. Der Schwenk auf die in den jeweiligen Prozessen relevanten Produkt- und Prozessdaten und die Dringlichkeit von deren prozessübergreifender Integrität ist dann nur der konsequente zweite Schritt. Ziel ist hierbei, das Syndrom eines „nicht genutzten Datensilos“ zu vermeiden. Die folgenden Schritte der Auswahl/Anpassung einer optimalen IT-Unterstützung für die definierten Prozesse mit den dafür erforderlichen Daten und Datenstrukturen sind, wie mehrfach erwähnt, entsprechend den individuellen Bedürfnissen des Unternehmens vorzunehmen. Jedoch kann nicht nur die Realisierung von PLM im Unternehmen vom Qualitätsmanagement profitieren sondern auch umgekehrt. Eine Zertifizierung nach ISO 9000:2008 schreibt einen prozessorientierten Aufbau vor und verlangt nach formal beschriebenen Prozessen. Der Prozessmodellierungsgedanke und die Workflowmanagement-Module von PLM können maßgeblich zur Erfüllung der Anforderungen beitragen (siehe Leitheft „Prozesse gestalten und steuern“, Abschnitt 5.7). So kann durch ein durchgängiges PLM die Zertifizierung nach DIN ISO 9000:2008 deutlich erleichtert werden und die Realisierung von PLM von der Dokumentation und dem Wandel in der Denkweise hin zur prozessorientierten Sicht resultierend aus dem Qualitätsmanagement profitieren.

3 Modelle – Änderungen und Ergebnisse konsistent verwalten

Auf einer abstrakten Ebene lässt sich sagen, dass durch konsequentes Product Lifecycle Management Engineering-Prozesse optimiert werden sollen, indem Informationsflüsse an tatsächlich bestehenden Erfordernissen ausgerichtet und konsistente Informationsstrukturen im Unternehmen aufgebaut werden. In Kap. 2 wurde bereits auf die Komplexität hingewiesen, die sich hieraus bei einer Einführung von PLM und dessen kontinuierlicher Weiterentwicklung ergibt. Die wesentlichen Dimensionen, die zur Steigerung der Komplexität beitragen, sind dabei x die Komplexität der Produktlandschaft (Anzahl Produkte, Produktvarianz, Änderungshäufigkeit, Produktkomplexität), x die Prozessvielfalt, insbesondere im Kontext von immer stärker unternehmensübergreifenden Schnittstellen, x die Anzahl der am Produktentstehungsprozess beteiligten Stakeholder sowie x die rasante Veränderung der IT-Basistechnik (Plattformen, Middleware, Standard-Software usw.)

3.1

Die Motivation des Modellierens

Der wesentliche Hebel zur Beherrschung dieser Gesamtkomplexität ist die Modellbasierung d.h. die Modellierung aller Informationsstrukturen und Prozesse, die im Product Lifecycle zur Anwendung kommen. Der Nutzen des Einsatzes von Modellen soll nachfolgend durch einen Vergleich des Einsatzes von Modellen beim Hausbau verdeutlicht werden. Hier ist der Einsatz von Modellen in Form von Bebauungsplänen, Bauplänen bis hin zu 3D-Darstellungen unumstritten. Die Modelle beim Hausbau dienen als Kommunikationsbasis auf der einen Seite zwischen Bauherr und Architekt und auf der anderen Seite zwischen Architekt und Handwerkern. Obwohl der Bauherr im Allgemeinen bezogen auf das Bauvorhaben einen geringeren Sachverstand als der

V. Arnold et al., Product Lifecycle Management beherrschen, 2. Aufl., DOI 10.1007/978-3-642-21813-2_3, © Springer-Verlag Berlin Heidelberg 2011

28

3 Modelle – Änderungen und Ergebnisse konsistent verwalten

Architekt hat, helfen die Modelle – die Baupläne oder sogar eine darauf basierende 3D-Darstellung – die zentralen Ideen des Architekten zu verstehen. Er hat damit die Möglichkeit vor Ausführung der Bautätigkeit korrigierend einzugreifen, sodass auch tatsächlich seinen Bedürfnissen und Wünschen entsprochen wird. Zum anderen spezifizieren sie für die Experten – die Handwerker – exakt und eindeutig die wesentlichen und zentralen Eigenschaften wie z.B. die Länge, Höhe und Stärke einer Wand. Im Fall des Product Lifecycle Managements helfen analog Modelle, um z.B. die durch ein Informationssystem zu unterstützenden Prozesse und die zu verwaltenden Datenstrukturen in einer Form zu beschreiben, die es auch dem Fachbereich ermöglicht, zu erkennen, ob die fachlichen Anforderungen korrekt abgebildet wurden. Zum anderen geben die Modelle bereits die wesentlichen Anforderungen für die IT-Teams vor, die diese im jeweiligen Informationssystem umzusetzen haben. Ein weiterer Nutzen für den Architekten ergibt sich in der Koordination der verschiedenen Gewerke. Mit Hilfe des Bauplans besteht eine Grundlage für jedes Gewerk, auf dessen Basis spezialisierte Planungen durchgeführt werden können. So kann z.B. der Elektriker die Lage von Steckdosen und weiteren Anschlüssen eintragen und benutzt dabei eine Sicht auf das Bauvorhaben, die mit der Sicht z.B. des Installateurs konsistent ist. Er hat allerdings die Möglichkeit, in seiner eigenen Notation (z.B. Steckdosensymbol) die für ihn relevanten Informationen zu ergänzen. Analog bietet der Einsatz von Modellen im PLM die Möglichkeit, Produktinformationen konsistent zu verwalten, die um spezialisierte Informationen für verschiedene Abteilungen ergänzt werden. So kann ein Produktmodell für die Fertigung um spezielle, fertigungsspezifische Eigenschaften ergänzt werden, die ausschließlich von der Fertigung genutzt werden. Das grundlegende Produktmodell aber ist über die Abteilungen hinweg konsistent. Werden die Modellinformationen der einzelnen Gewerke konsistent in einem Modell gepflegt, so lassen sich vor Baubeginn schon Qualitätsmaßnahmen im Sinne von Auswertungen oder Überprüfungen durchführen. Beispielsweise lässt sich erkennen, ob sich Stromleitungen und Wasserleitungen kreuzen. Analog hierzu lassen sich im PLM-Kontext Montageinformationen bereits in der Produktentwicklung verwenden, um die Montagefähigkeit einer Entwicklung zu überprüfen. Nach Ende des Bauvorhabens können die Modelle später bei Renovierungs- oder Erweiterungsarbeiten genutzt werden, um das Risiko unvorhergesehener Situation zu reduzieren, beispielsweise Wasserleitungen in einer Wand, die entfernt werden soll. Des Weiteren lässt sich vor jeder Baumaßnahme ein Vermessen des Bauobjekts einsparen, da auf die vorhandenen Unterlagen zurückgegriffen werden kann. Voraussetzung ist al-

3.1 Die Motivation des Modellierens 29

lerdings, dass das Modell, d.h. der Bauplan auch über längere Zeit gepflegt wird. Aufgrund nicht vorhandener oder nicht kompatibler Werkzeuge ist dies allerdings im privaten Bausektor eher selten ausgeprägt. Im PLMKontext lassen sich Modelle nutzen, um auf bestehenden Lösungen aufzubauen. Bereits formal erfasste Sachverhalte müssen so nicht bei jedem Projekt neu analysiert und auf Datenstrukturen abgebildet werden. Vor allem lässt sich aber das Risiko vermindern, dass Ergebnisse aus zwei auf den ersten Blick voneinander unabhängigen Projekten sich widersprechen z.B. widersprüchliche prozessuale Lösungen. Neben dem Bauplan für ein Bauvorhaben findet sich auf einer höheren Abstraktionsebene eine weitere Form von Modellen: Bebauungspläne. Die Bebauungspläne geben Randbedingungen vor, die im Bauplan eingehalten werden müssen und dafür sorgen, dass, obwohl das Bauobjekt exakt nach den Bauplänen realisiert wurde, nicht den gewünschten Nutzen erzielt. Beispiele hierfür sind eine Fabrik, die eine unzureichende Verkehrsanbindung besitzt oder die Ansiedlung mehrerer Einkaufszentren für die kein ausreichender Kundenbedarf vorhanden ist. Analog bedarf es im PLMKontext einer der Modellierung der fachlichen Prozess- und Informationsstrukturen, die über mehrerer (idealerweise alle) Informationssysteme hinweg Gültigkeit haben und damit die Integrationsfähigkeit der Informationssysteme erhöht. Man spricht hier auch vom kanonischen Modell. Üblicherweise besitzt dieses Modell einen höheren Abstraktionsgrad als systemspezifische Modelle. Für die Unterstützung der Modellierung von Prozessen und Informationsstrukturen gibt es am Markt eine Vielzahl von methodischen Ansätzen und Produkten. An dieser Stelle soll jedoch nicht auf die unterschiedlichen Eigenschaften der Werkzeuge eingegangen werden, sondern auf das grundlegende „Rüstzeug“ zur Modellierung. In Abschnitt 3.2 werden zunächst die Vorgehensweisen zur Strukturierung eines Modells vorgestellt. Bedingt durch die in Kap. 2 beschriebene Komplexität, können Modelle, die im PLM entstehen, sehr umfangreich werden. Die Strukturierung ist daher unablässig, um eine Handhabbarkeit der Modelle zu gewährleisten. In Abschnitt 3.6 wird die Modellierung bzw. die Ausprägung und Nutzung von Modellen als zentraler Bestandteil des evolutionären Vorgehensmodells eingeführt. Die wesentlichen, zentralen Modelltypen des PLM werden in Abschnitt 3.3 vorgestellt. Im nachfolgenden Abschnitt 3.4 wird ein Überblick über weitere Modelltypen, die oft im PLM-Umfeld eingesetzt werden, vorgestellt. Abschließend werden im Abschnitt 3.5 mit den Referenzmodellen STEP sowie PLMEnablers zwei etablierte und ausgereifte Standards vorgestellt. Diese Referenzmodelle bieten zum einen die Möglichkeit, Branchen-Erfahrungswissen einsetzen zu können, und zum ande-

30

3 Modelle – Änderungen und Ergebnisse konsistent verwalten

ren durch den Einsatz eines Standards den Datenaustausch über Unternehmensgrenzen hinweg zu erleichtern und damit die Einbindung in unternehmensübergreifende Wertschöpfungsketten zu ermöglichen.

3.2

Modelle strukturieren

Die Beispiele zu Beginn des Kapitels haben gezeigt, dass vor allem dann ein Nutzen aus der Modellierung entsteht, wenn ein integriertes, konsistentes und umfassendes Modell aufgebaut und gepflegt wird. So lassen sich Abhängigkeiten und daraus entstehende Nebenwirkungen von Änderungen erkennen, die aus einer reinen Sichtweise auf einen eingeschränkten Bereich nicht zu erkennen sind. Allerdings entsteht daraus wiederum eine hohe Komplexität im Modell selbst, der durch die nachfolgenden Strukturierungsmaßnahmen begegnet werden kann: x Die Modellierungsebenen gliedern Modelle nach Abstraktions- bzw. Detaillierungsgraden. Die Ebenen sprechen demzufolge unterschiedliche Rollen innerhalb eines Unternehmens an. x Sichten ermöglichen eine Individualisierung des Modells für bestimmte Bereiche eines Unternehmens (z.B. Entwicklung oder Fertigung) oder Rollen (z.B. Test-Ingenieur), ohne dass redundante Kopien eines Modells gebildet werden müssen. x Die Zustände eines Modells unterstützen schließlich die zielgerichtete Weiterentwicklung des Modells und damit der PLM-Umsetzung in ihrem Unternehmen. Diese drei Maßnahmen werden im Folgenden nun kurz beschrieben. 3.2.1 Ebenen eines Modells „IT follows business“ ist eine häufig anzutreffende Anforderung an die IT, die besagt, dass in der IT (ausschließlich) die vom Fachbereich geforderten Werkzeuge zur Prozessverbesserung erstellt werden. Es soll verhindert werden, dass IT-Lösungen aus reinem Selbstzweck erstellt werden und dass eine Priorisierung von IT-Maßnahmen anhand von Prioritäten des Fachbereichs erfolgt. Um dies zu erreichen, müssen die Anforderungen und Prioritäten des Fachbereichs auch bekannt sein. Während die fachlichen detaillierten Anforderungen üblicherweise direkt aus den Fachbereichen kommen, so ist die Priorisierung im Allgemeinen durch die Unternehmensleitung vorgegeben, d.h. durch die von der Unternehmensleitung

3.2 Modelle strukturieren 31

vorgegebenen Ziele und deren Priorisierung. Entsprechend dieser Randbedingungen empfiehlt es sich, drei Ebenen zu unterscheiden, in denen jeweils die Organisation, die Prozesse, die Produkte sowie alle zugehörigen Daten betrachtet werden: x Auf der Management-Ebene werden die Vision und daraus abgeleitete Ziele des Unternehmens beschrieben. Diese Beschreibungen sind üblicherweise nicht in einer streng formalen Notation, sondern in textueller Form festgehalten. Nichts desto trotz sollten in den Fachkonzepten auf die Ziele des Unternehmens verwiesen werden, um darstellen zu können, dass durch ein Fachkonzept die Ziele eines Unternehmens verfolgt werden. x Orientiert an den Unternehmenszielen wird auf der nächsten Ebene, der Ebene des Fachkonzepts, das eigentliche Konzept für ein PLM betrachtet. Sie stellt daher auch die zentrale Ebene für die Gestaltung des PLM dar. Das Fachkonzept ist losgelöst von sämtlichen Systemen. 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 Produktlebenszyklus festgehalten. Daher gehört zu den elementaren Ansätzen des in diesem Buch beschriebenen Handlungsleitfadens, dass jedes Unternehmen selbst für das Fachkonzept verantwortlich ist. Eine vollständige Fremdvergabe dieser Aufgabe an externe Dienstleistungsunternehmen ist nach Möglichkeit zu vermeiden. Allerdings sollte durchaus auf Beratung und Unterstützung z.B. durch systemneutrale Beratungshäuser oder Institute zurückgegriffen werden. Eine möglichst formale Beschreibung des PLM-Konzepts in Form von Modellen ist für die Verankerung dieses Know-hows im Unternehmen dringend empfehlenswert. x In der Ebene DV-Konzept wird das Fachkonzept auf die ITInfrastruktur abgebildet. Das heißt, dass hier die einzusetzenden Systeme erstmals mit betrachtet werden. 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 informationstechnische Umsetzung definiert. Nur wenn ein Unternehmen in der Lage ist, seine Anforderungen präzise zu formulieren, kann ein Systemlieferant die entsprechende „passende“ Systemlösung liefern. Auch diese Ebene sollte vom Unternehmen selbst verantwortet werden. Jedoch ist ein stärkerer Einbezug von externen Dienstleistungsunternehmen möglich und durchaus sinnvoll. Elemente des DV-Konzepts sollten auf jeden Fall auf Elemente des Fachkonzepts verweisen, um zum einen darzulegen, dass fachli-

32

3 Modelle – Änderungen und Ergebnisse konsistent verwalten

che Anforderungen umgesetzt werden (und keine technikgetriebenen) und zum anderen zur Auswertung der Abhängigkeiten. Diese Abhängigkeiten dienen zum einen zum frühzeitigen Erkennen des Aufwands einer Änderung im Fachkonzept in der IT („Welche Informationssysteme und Schnittstellen muss ich anpassen?“) und zum anderen zum Erkennen der Bedeutung einzelner IT-Komponenten („Welche Prozesse können nicht mehr ausgeführt werden, wenn Komponente X nicht zur Verfügung steht?“). Häufig wird in der Literatur als eine vierte Ebene noch die Implementierung genannt. Sie stellt in der Regel ein mehr oder weniger aufwendiges Anpassen einer Standard-Software dar. Alle notwendigen Eingriffe in die Systeme bis hin zu administrativen Tätigkeiten werden in dieser Ebene beschrieben. Hierzu zählen beispielsweise auch kommentierte Quellcodes von Schnittstellen oder eigenen Tools. Die Implementierung wird gerade bei mittelständischen Unternehmen meist von externen Dienstleistern übernommen. Trotzdem sollte das eigene Unternehmen im Besitz aller Unterlagen und Spezifikationen sein, um möglichst unabhängig von externen Partnern zu bleiben. Dies wird sich spätestens bei bevorstehenden Systemwechseln oder Technologiesprüngen positiv auswirken. Auch hier ist wieder darauf zu achten, dass Implementierungen immer im Bezug zu Teilen des DV-Konzepts stehen. Dies verhindert zum einen, dass Geld für Implementierungen ausgegeben wird, die keinen Nutzen erzielen da kein fachlicher Anforderer vorhanden ist, und zum anderen eine „Schatten-ITLandschaft“ entsteht, die nur schwer zu beherrschen ist (z.B. durch nicht vorhersehbare Auswirkungen von Änderungen). In der Implementierungsebene werden üblicherweise Standardmethoden der Informatik eingesetzt, die keine speziellen PLM-Merkmale aufweisen. Aus diesem Grund wird die Ebene Implementierung in diesem Werk nicht weiter behandelt. 3.2.2 Sichten eines Modells Eine Sicht auf ein Modell stellt einen speziellen Ausschnitt auf ein Modell dar. Sichten bieten eine für Rollen spezialisierte Darstellung von Informationen des Modells. So können z.B. spezielle Attribute zu einem Bauteiltyp für Mitarbeiter der Arbeitsvorbereitung dargestellt werden, die für Mitarbeiter der Entwicklung nicht von Interesse sind. Änderungen an gemeinsam genutzten Attributen werden allerdings direkt auch für Mitarbeiter der Entwicklungsabteilung sichtbar, da man auf dem gemeinsamen Modell arbeitet.

3.2 Modelle strukturieren 33

Der Zweck der Einführung von Sichten verhindert eine Informationsflut für Mitarbeiter, die mit den Modellen arbeiten müssen. Durch die Einschränkung auf Sichten können sie sich auf ihren Kompetenzbereich fokussieren. Da man trotzdem auf dem gleichen Modell arbeitet, ist das Risiko geringer, dass unterschiedliche Kompetenzbereiche divergierende Lösungen entwickeln. Gerade in größeren Unternehmen wird das Prinzip der Sichten auch eingesetzt, um den Zugang zu vertraulichen Informationen auf den notwendigen Kreis einzuschränken. Man erreicht dies, indem man vertrauliche Informationen nur in bestimmten Sichten darstellt. Für diese Sichten bekommen nur die notwendigen Mitarbeiter entsprechende Aufruf- bzw. Bearbeitungsrechte. In anderen Sichten werden die vertraulichen Informationen herausgefiltert. Man sollte bedenken, dass die PLM-Konzepte, die in einem Modell dargestellt sind, einen nicht unwesentlichen Teil des Unternehmenswissens darstellen. Vor dem Hintergrund einer steigenden Industriespionage ist dies ein nicht zu unterschätzender Aspekt und daher sollte einem geeigneten und feingranularen Sichtenkonzept ein entsprechender Stellenwert eingeräumt werden. 3.2.3 Zustände eines Modells PLM ist ein kontinuierlicher Prozess der Anpassung und Weiterentwicklung geeigneter unternehmensspezifischer IT-Unterstützung im produktnahen Bereich (siehe Kap. 2). Daher ist eine permanente Änderung der Modelle und Dokumentationen des PLM nicht nur eine notwendige Konsequenz, sondern vielmehr als zentraler und integraler Bestandteil von PLM zu verstehen und umzusetzen. Das Prinzip der Modellierung wird dabei sowohl für die Beschreibung der aktuellen Organisation, Prozesse und Produkte als auch für die Definition der zukünftigen Anforderungen und deren Umsetzung in geeignete PLM-Konzepte verwendet. Man unterscheidet daher auf der Modellebene in Ist- und Soll-Modelle. Letztere bilden somit die mit PLM angestrebte Vision ab und werden in einer entfernteren Ausbaustufe, die noch relativ weit weg vom aktuellen Stand ist, auch als Visionsmodelle bezeichnet. Ein Ist-Modell beschreibt die aktuelle Umsetzung des PLMGedankens. Das Ist-Modell stellt also eine Dokumentation der aktuellen Organisation, der Prozesse und Produkte dar. Für zukünftige Veränderung ist das Ist-Modell der Ausgangspunkt, um Veränderungspunkte zu identifizieren. Ebenso dient das Ist-Modell dazu, die aktuelle Situation zu analysieren und Optimierungspotenziale zu identifizieren.

34

3 Modelle – Änderungen und Ergebnisse konsistent verwalten

In einem Soll-Modell wird der Zustand beschrieben, der zu einem bestimmten Zeitpunkt erreicht werden soll. Üblicherweise werden die Umsetzungen der Änderungen zwischen dem Ist-Modell und einem SollModell in Form eines Projektes durchgeführt. Das Soll-Modell sollte relativ stabil sein, um das Projektrisiko möglichst gering zu halten. Es empfiehlt sich daher nicht, ein zu visionäres Soll-Modell mit einer zu hohen Abweichung vom Ist-Modell zu entwickeln, sodass das jeweilige Umsetzungsprojekt eine überschaubare und handhabbare Laufzeit und Komplexität besitzt. Nach Ende eines Umsetzungsprojekts wird das Soll-Modell – bedingt durch die sich in der Umsetzung typischwerweise noch ergebenden Anpassungen – zum neuen aktuellen Ist-Modell. Das Visionsmodell ist im Allgemeinen grob granularer als ein Ist- oder Soll-Modell. Das Visionsmodell stellt einen Zustand dar, der in der langfristigen Zukunft erreicht werden soll. Ein Soll-Modell stellt einen Zwischenschritt auf dem Weg zur Umsetzung des Visionsmodells dar. Das Visionsmodell dient dazu, dass bei der Entwicklung eines Soll-Modells trotz des bewusst eingeschränkten Fokus nicht der Gesamtblick verloren geht und die Ziele eines Projekts an den langfristigen Zielen des Unternehmens ausgerichtet werden. Ebenso unterstützt es dabei zu erkennen, ob angedachte Lösungen, die sich kurzfristig schnell umsetzen lassen, in der Zukunft neue Probleme aufwerfen könnten, indem sie beispielsweise in bestimmten Punkten der Unternehmensvision entgegenwirken. Das Visionsmodell sollte also eine gewisse Stabilität und Kontinuität besitzen. Nichts desto trotz wird das Visionsmodell üblicherweise niemals vollständig umgesetzt werden können, da bedingt durch den langfristigen Fokus von PLM z.B. Marktveränderungen oder Technologieinnovationen immer wieder zu veränderten Unternehmenszielen führen.

3.3

Zentrale Modelle des PLM

Im Mittelpunkt des Produktlebenszyklus stehen das Produkt und die zum Produkt zugehörigen Prozesse. Beide Elemente sollen mit entsprechenden Engineering-Werkzeugen in ihrer Ganzheit verwaltet werden, unabhängig davon ob es sich bei den Produkten eines Unternehmens um sehr komplexe Sonderanfertigungen oder um Serienprodukte handelt. Repräsentative Produkte und Prozesse sollen vollständig mit allen zugehörigen Daten, Beschreibungen und Informationen abgebildet werden, sodass durch Abstraktion und Verallgemeinerung Grundmuster und Standardabläufe für alle Produkte und Prozesse definiert und umgesetzt werden können. Es soll so

3.3 Zentrale Modelle des PLM 35

eine höhere Transparenz geschaffen werden. Dies ist Basis für einen durchgängigen IT-gestützten Lifecycle. Um dies zu erreichen, müssen alle Produkte, Prozesse, Daten sowie die gesamte Organisation in der Beschreibung durch Modellkonstrukte berücksichtigt und geeignet abgebildet werden. Wie gut dieses gelingt, ist nicht zuletzt von der zugrunde gelegten Abbildungslogik abhängig, mit der die zuvor genannten realen Elemente in Modelle überführt werden. Das heißt, es muss eine eigene Logik zum Abbilden bzw. Abstrahieren der realen „Welt“ erarbeitet werden. In diesem Anwenderhandbuch werden grundsätzliche Methoden zur Erstellung einer Abbildungslogik vorgestellt. Da sie unternehmensspezifisch ist, kann sie von keinem System und keiner Literatur „geliefert“ werden. So muss jedes Unternehmen seine eigene Abbildungslogik erstellen, deren Beschreibung den konzeptionellen Ansatz des PLM-Manifests (siehe Abschnitt 3.6) darstellt. Für die Produktdaten bedeuten die Anforderungen an PLM, dass sie für jeden, der im Unternehmen Bezug zum Produkt hat, unter Berücksichtigung seiner Bedürfnisse eindeutig beschrieben sein müssen. Dazu ist es notwendig, dass das Produkt aus informationstechnischer Sicht, abhängig von den Beteiligten, der Produktlebensphase und dem Anwendungsbezug, unterschiedliche Facetten annehmen kann, obwohl es sich um ein und dasselbe Produkt handelt. Beispielsweise könnte das Abbild eines mechatronischen Produkts aus Sicht eines Elektroingenieurs ein Schaltplan und aus Sicht eines Maschinenbauingenieurs ein CAD-Modell sein. Aber auch innerhalb einer Disziplin kann es zu unterschiedlichen Sichten auf ein Produkt kommen z.B. Funktionssicht, Montagesicht etc. Ein Produkt besteht letztendlich immer aus einer mehr oder weniger großen Anzahl von Einzelteilen, die eine gewisse Abhängigkeit besitzen, verkörpert im Kern durch die Produktstruktur. In der Produktstruktur werden Einzelteile in Baugruppen zusammengefasst und mit Beziehungen hinterlegt. So entsteht eine spezielle Sicht auf ein Produkt, die heute typischerweise als Stücklisten-orientierte, starre Sicht dominiert. Für einen ganzheitlichen informationstechnischen Ansatz ist dies jedoch nicht ausreichend. Die Struktur muss abhängig von Sichten dynamisch generiert und angepasst werden, die produktrelevanten Daten – insbesondere die produktbeschreibenden Daten – müssen mit den entsprechenden Teilen verknüpft werden, Varianten und Alternativen müssen Berücksichtigung finden und die Historie muss nachvollziehbar sein. Diese formale Beschreibung der ganzheitlichen, disziplinübergreifenden Produktmodellierung ist eine besondere und zentrale Methode aus dem PLM-Umfeld. Hierfür hat sich der Begriff des integrierten Produktmodells etabliert. Das integrierte Produktmodell verfolgt nach Grabowski drei we-

36

3 Modelle – Änderungen und Ergebnisse konsistent verwalten

sentliche Aspekte: „Abbildung von Produktinformationen aus allen Phasen des Produktlebenszyklus, Vereinigung von verschiedenen physikalischen Produkteigenschaften und Berücksichtigung der Sichtweise eines Anwendungsgebietes.“ Zum Ziel der Beschreibung wird im Weiteren dazu ausgeführt: „Die Informationen aus dem integrierten Produktmodell werden in unterschiedlichen Strukturen und Darstellungsformaten gebraucht. Das integrierte Produktmodell muss daher so spezifiziert (festgelegt und beschrieben) werden, dass es alle Funktionen der Produktverarbeitung unterstützt. Zu diesen Funktionen zählen z.B. Produktdatenaustausch, Produktdatenspeicherung, Produktdatenarchivierung, Produktdatentransformation.“ (Grabowski et al. 2003) „Produktdaten entstehen nicht in einem luftleeren Raum, sondern werden immer im Kontext von Prozessen erzeugt“ (Schichtel 2002). Produktdaten werden in Prozessen erzeugt und konsumiert. Nur im Kontext einer Prozessbeschreibung lässt sich der Bedarf an Produktdaten erkennen und der Lebenszyklus von Produktdaten analysieren und definieren. Prozessbeschreibungen ergänzen die „statischen“ Produktdaten somit um eine dynamische Sicht auf die mit dem Produkt verbundenen Veränderungen. Die formalisierte Form einer Prozessbeschreibung, das Prozessmodell, stellt den zweiten zentralen Modelltyp im PLM dar. In den nachfolgenden Kapiteln werden diese beiden zentralen Modelle des PLM, das integrierte Produktmodell und das korrespondierende Prozessmodell, näher ausgeführt. Für tiefergehende Beschreibungen sei an dieser Stelle auf die einschlägige Literatur verwiesen. Ein Ansatzpunkt für die effiziente Erstellung eines eigenen Produkt- und Prozessmodells bilden Referenzmodelle, welche inzwischen einen hohen Reifegrad und breite Anerkennung in der Industrie gefunden haben. Zwei der zentralen Referenzmodelle werden in Abschnitt 3.5 beschrieben. 3.3.1 Das integrierte Produktmodell Das integrierte Produktmodell wurde in der VDI-Richtlinie 2219 spezifiziert. In dieser Richtlinie wird es definiert als „… die formale Beschreibung aller Informationen zu einem Produkt über alle Phasen des Produktlebenszyklus hinweg in einem Modell.“ Daraus folgt, dass das integrierte Produktmodell eine zentrale informationstechnische Sammlung aller relevanten Daten und Informationen über ein Produkt ist, die bei der Beschreibung aller wesentlichen Aspekte des Produktes über den gesamten Lebenszyklus hinweg anfallen. Zur Menge der relevanten Daten gehören organisatorische, technische und technologische Daten, mit denen das In-

3.3 Zentrale Modelle des PLM 37

formationsbedürfnis aller am Product Life Cycle beteiligten Abteilungen und Bearbeiter abgedeckt werden kann. Produkte werden nach der oben vorgestellten Definition in verschiedenen Erzeugersystemen mit spezifischen Zielen beschrieben. Jedes Modell dieser Art stellt ein sog. Partialmodell des integrierten Produktmodells dar. Partialmodelle können einzelne Produktsegmente oder ganze Produkte fokussiert auf eine Disziplin sein, wie zum Beispiel Geometrie, Elektrik, Pneumatik, Hydraulik, Elektronik, Mechanik. Das integrierte Produktmodell führt diese Partialmodelle zu einem Gesamtmodell zusammen und ergänzt zusätzlich Struktur- und Stammdaten. Als Rückgrat des integrierten Produktmodells fungiert ein Produktstrukturmodell. Notwendig ist die Beschreibung des integrierten Produktmodells nicht zuletzt, da alle gängigen PDM-Systeme und standardisierte Austauschformate auf diesem Konzept aufsetzen. Zur Beschreibung verwenden einige Referenzmodelle eigene Notationen. Allerdings gewinnt die im Kontext der Softwareentwicklung entstandene Unified Modeling Language (UML) auch als Notation für das integrierte Produktmodell zunehmend an Bedeutung. Die UML verfügt über eine Vielzahl von Diagrammtypen. Für die Beschreibung von Datenmodellen, wie es das integrierte Produktmodell darstellt, werden typischerweise Klassen- bzw. Objektdiagramme verwendet. Für die in diesem Buch dargestellten Modelle werden ebenfalls diese Diagrammtypen verwendet. 3.3.2 Bestandteile des integrierten Produktmodells In der UML wird zwischen Klassen und Objekten unterschieden. Eine Klasse stellt ein abstraktes Element dar, eine Schablone für Objekte. Objekte sind konkrete Elemente. In diesem Zusammenhang spricht man auch von einem Objekt als eine Instanz einer Klasse. Die Anwendung dieser Vorgehensweise sei an dem nachfolgenden Beispiel dargestellt: Physisch existiere ein Getriebe. Dieses konkrete Getriebe wird durch Daten in einem Informationssystem beschrieben. Diese Daten sind die (datentechnischen) Objekte, die das Getriebe beschreiben. Die Datenelemente, die allgemein ein Getriebe des gleichen Typs beschreiben, sind in Form einer Klasse spezifiziert. Objekte werden durch Stammdaten und durch Strukturdaten beschrieben. Stammdaten sind Daten, die ein Objekt näher beschreiben und identifizieren. Sie sind selbstständig, ohne Beziehung zu anderen Daten aussagefähig und existenzberechtigt. Beispiele für Produktstrukturdaten zeigt die nachfolgende Abb. 3-1. Diese Produktstrukturdaten können mit Bedingun-

38

3 Modelle – Änderungen und Ergebnisse konsistent verwalten

gen wie z.B. Gültigkeiten bei Versionen und Varianten, Alternativbedingungen bei Alternativen und Angaben zu Sichten versehen werden. Diese Themen werden detailliert in den Leitheften „Evolution der Produkte organisieren“ (siehe Abschnitt 5.1) und „Produkte kontextabhängig darstellen“ (siehe Abschnitt 5.2) beschrieben.

Abb. 3-1: Beispiele für Produktstrukturdaten

3.3 Zentrale Modelle des PLM 39

3.3.3 Aufbau eines integrierten Produktmodells Den Kern des integrierten Produktmodells bildet die Produktstruktur, die einer Baumstruktur ähnelt. Ein Produkt wird ausgehend vom Gesamtprodukt als Wurzelknoten über Hauptbaugruppen, Baugruppen bis zur elementaren Ebene von Einzelteilen aufgeschlüsselt. Jeder Strukturzweig endet an einem Bauteil, einem Einzelteil. Die Struktur terminiert am Einzelteil. Ein Einzelteil liegt immer dann vor, wenn das betrachtete Element aus Sicht des Betrachters nicht weiter zerlegt werden muss. Unterschiedliche Ausprägungen eines Produktes, die sich nur im Detail unterscheiden, wie beispielsweise Versionen, Varianten und Alternativen führen nicht mehr zu einer vollständigen Kopie der jeweiligen Elemente. Vielmehr werden durch dynamisches Einbinden der betroffenen Elemente an die gemeinsamen übergeordneten Strukturelemente (Baugruppen) die unterschiedlichen Ausprägungen aus einer Struktur generiert. In den Modellen werden diese Elemente mit entsprechender Kennzeichnung parallel geführt. Auf Versionen, Varianten und Alternativen wird im Leitwerk im Abschnitt 5.1.2 näher eingegangen.

Abb. 3-2: Integriertes Produktmodell

40

3 Modelle – Änderungen und Ergebnisse konsistent verwalten

Auch die Struktur eines Produktes selbst ist keinesfalls eindeutig. Je nach Standpunkt und Herkunft des Betrachters sind unterschiedliche Strukturen sinnvoll. Beispielsweise wird bei montagespezifischen "Zusammenbaustrukturen" den spezifischen Anforderungen der Montage Rechnung getragen. Dies kann durch das Hinzufügen weiterer Montagebaugruppen erfolgen. Um auch dieser Anforderung gerecht zu werden, lässt das integrierte Produktmodell unterschiedliche strukturelle Sichtweisen auf ein Produkt zu (Sichtenkonzept, siehe Abschnitt 3.2.2). Durch das Hinzufügen aller produktbeschreibenden Daten, insbesondere von Dokumenten und Partialmodellen an den jeweiligen Produktkontext wird aus dem Kernmodell der Produktstruktur so sukzessive das integrierte Produktmodell. Hierzu werden an einem Bauteil bzw. an einer Baugruppe alle beschreibenden Dokumente mittels eines informationstechnischen Zwischenelements („Container“) angehängt, welcher wiederum auf die entsprechenden Dokumente verweist. Die Abb. 3-2 verdeutlicht dieses Konzept grafisch. Ein weiterer Begriff im Rahmen des integrierten Produktmodells ist die Konfiguration. Eine Konfiguration stellt eine präzise Ausprägung eines Produktes aus dem Produktmodell dar. Das bedeutet, dass alle Versionen, Varianten und Alternativen ausgeblendet werden, die in dieser speziellen Produktausprägung nicht verwendet werden. Eine Stückliste ist nunmehr nur noch eine Ausleitung aus dem integrierten Produktmodell unter Angabe einer Konfiguration bzw. einer Sicht (siehe Leitheft „Evolution der Produkte organisieren“, Abschnitt 5.1). 3.3.4 Das Prozessmodell Product Lifecycle Management dient nicht nur zur Verwaltung aller produktrelevanten Daten, sondern steuert auch alle produktbezogenen Prozesse. Typische Prozesse im PLM sind beispielsweise Freigabe- und Änderungsprozesse. Um eine IT-unterstützte Prozesssteuerung zu ermöglichen, müssen Prozessmuster formal unter Berücksichtigung des Informationsflusses und der Verantwortlichkeit, gegebenenfalls auch unter Berücksichtigung der benötigten Ressourcen, festgeschrieben werden. Wiederum soll, ähnlich wie beim Produktmodell, in erster Linie Transparenz für eine formale Beschreibung geschaffen werden, die sowohl zur Optimierung wie auch zur Kommunikation verwendet werden kann. Die Prozessmodelle ergänzen die Produktmodelle zum konzeptionellen Anteil des unternehmensspezifischen PLM-Manifests, dem Kern des Vorgehensmodells aus Abschnitt 3.6. Der Beschreibung der zugehörigen Mo-

3.3 Zentrale Modelle des PLM 41

dellierungsmethodiken für Prozesse soll hier noch nicht vorgegriffen werden, da diese aus anderen Fachrichtungen übernommen werden können. Dies wird im Leitheft „Prozesse gestalten und steuern“ (siehe Abschnitt 5.7) ausführlich dargestellt. An dieser Stelle sollen als Ausblick nur drei der etablierten Methoden kurz aufgeführt werden (siehe Abb. 3-3): x Die erweiterte ereignisgesteuerte Prozesskette (eEPK) der „Architektur integrierter Informationssysteme (House of ARIS)“ x Das Sequenzdiagramm der „Unified Modeling Language (UML)” x Structured Analysis and Design Technique (SA/DT) Die Modelle haben eine unterschiedlich detaillierte Aussagekraft und eignen sich daher für unterschiedliche Abstraktionsebenen. Beispielsweise zeigt die EPK in der Abbildung den wichtigen Bezug, dass in dem Prozessschritt „Auftragsbearbeitung“ Informationen zu einem Objekt der Klasse „Artikel“ benötigt wird.

Abb. 3-3: Methoden der Prozessmodellierung

42

3 Modelle – Änderungen und Ergebnisse konsistent verwalten

Die Klasse Artikel sollte demzufolge auch im integrierten Produktmodell zu finden sein. Auch Dokumente können und sollten in einer Prozessbeschreibung berücksichtigt werden. Hier ist in der Abbildung beispielhaft ein Dokument „Kundenauftrag“ aufgeführt. Ganz nach dem Gedanken der Objektorientierung und analog zum Vorgehen bei Produkten werden wiederum Objekte bzw. Instanzen und Klassen unterschieden. Eine Prozessklasse bildet ein Prozessmuster, eine Prozessvorlage, die bei Bedarf instanziiert – d.h. zu einem konkreten Prozess ausgeprägt – werden kann, wenn ein tatsächlicher Prozess angestoßen wird. Das heißt, dass das Prozessmuster in einer bestimmten Ausprägung zu einem konkreten Prozess wird. Neben der Notwendigkeit Prozesse im Rahmen einer PLM-Einführung und -Weiterentwicklung zu beschreiben, besteht bei der Prozessbeschreibung eine große Synergie zwischen PLM und Qualitätsmanagement. Spätestens durch die ISO 9000:2008 Zertifizierung wird auch im Qualitätsmanagement eine Prozessbeschreibung gefordert, sodass hier die beiden Interessengruppen voneinander profitieren können (siehe Abschnitt 2.5.3).

3.4

Weitere Modelltypen

In Ergänzung oder parallel zu Produkt- und Prozessmodellen werden weitere Modelltypen eingesetzt, um Produkt- und Prozessinformationen mit allgemeinen Unternehmensinformationen in Verbindung zu setzen. Beispiele solcher Informationen sind Organisationseinheiten eines Unternehmens, Rollen, die im Unternehmen ausgeprägt sind aber auch Informationen zur Systemlandschaft des Unternehmens. Liegt der Schwerpunkt eher auf der Aufbauorganisation eines Unternehmens, so spricht man bei der Integration der verschiedenen Modelltypen vom Unternehmensmodell. Die Aufbauorganisation wird dabei z.B. mit Hilfe von Organigrammen abgebildet, Rollen mit Hilfe von hierarchisch strukturierten Rollenmodellen. Bei einem integrierten Unternehmensmodell lassen sich Organisationseinheiten, die in einem Organigramm erfasst wurden z B. mit Produkten oder Prozessschritten verknüpfen, um ihre Zuständigkeit hierfür darzustellen. Durch die zentrale Erfassung und die damit einhergehende Herstellung der Eindeutigkeit der Bezeichnung z.B. von Abteilungen, lassen sich über das Modell werkzeugunterstützt Abfragen realisieren wie z.B. „Für welche Produkte ist Abteilung XYZ zuständig?“. Organigramme und insbesondere Rollenmodelle stellen eine außerordentlich hilfreiche Grundlage dar, um Berechtigungskonzepte

3.5 Referenzmodelle 43

für Informationssysteme zu konzipieren. Ein Berechtigungskonzept, das auf Organigrammen und Rollenmodellen aufbaut, ermöglicht es später im Betrieb, Berechtigungen für einen Benutzer aufgrund seines Arbeitsbereichs und seiner Tätigkeiten zu vergeben (Berechtigungsschemata), statt individuell für jeden Benutzer herausfinden zu müssen, welche Einzelberechtigungen er benötigt. Betrachtet man ein Unternehmen aus der IT-Sicht, so ist stärker von Interesse, welche IT-Systeme im Unternehmen im Einsatz sind und welche (Teil-)Prozesse sie unterstützen. Werden Prozesse, IT-Systeme und Daten miteinander verknüpft, so wird häufig von Enterprise Architecture Management (Abk. EAM) gesprochen. Die Verknüpfung von Applikationen mit Prozessen ermöglicht die Kritikalität von Informationssystemen oder Optimierungspotenziale zu identifizieren z.B. häufige Wechsel der Informationssysteme innerhalb eines Prozesses, welches zu PerformanceVerlusten und Schnittstellenrisiken führen kann. Aus der Verknüpfung von Systemen und Daten lassen sich z.B. unkontrollierte Datenredundanzen identifizieren, welche der Grund für Prozessinstabilitäten sein können.

3.5

Referenzmodelle

Referenzmodelle erleichtern wesentlich den Aufbau eigener, individueller Produkt- und Prozessmodelle: Statt auf dem „leeren Blatt Papier“ beginnen zu müssen, kann man sich an den Erfahrungen anderer und an Industriebest-practices orientieren. Hierbei sind vor allem die Strukturierungsprinzipien und die Verwendung von abstrakten, nicht konkreten Modellobjekten hilfreich, um ein Verständnis für die Vorgehensweise bei der Modellierung zu gewinnen. Allerdings ist von ebenso großer Bedeutung, dass die informationstechnische, unternehmensinterne und -übergreifende Kommunikation deutlich erleichtert wird, wenn anerkannte und weit verbreitete Standards eingesetzt werden. In den folgenden drei Abschnitten werden drei Standards vorgestellt, die Referenzmodelle für Produkt- und Prozessmodelle im Engineering darstellen. Hierbei lassen sich zwei Arten von Referenzmodellen unterscheiden: Zum einen sind hier Referenzmodelle zu nennen, die auf eine Datensicht fokussieren. Ein Beispiel hierfür ist der im nachfolgenden Abschnitt vorgestellte STEP-Standard. Einen darüber hinaus gehenden Ansatz verfolgen Referenzmodelle, die auch den funktionalen Aspekt des Datenaustauschs berücksichtigen. In diesem Fall werden nicht nur die auszutauschenden Daten berücksichtigt, sondern auch noch der Kontext, in dem

44

3 Modelle – Änderungen und Ergebnisse konsistent verwalten

diese Daten ausgetauscht werden. Nachfolgend werden die beiden Standards PDMEnablers und OMG PLM Services vorgestellt, welche Vertreter der funktionalen Sicht sind. Da diese Standards recht umfangreich sind, würde ihre detaillierte Darstellung den Umfang dieses Buchs sprengen. An dieser Stelle sei auf die gedruckten und online verfügbaren Quellen verwiesen. Die nachfolgenden Beschreibungen sollen einen groben Überblick über Zweck, Aufbaustruktur und Inhalt der Standards vermitteln. Der „Standard for the Exchange of Product Model Data“ (Abk.: STEP, (siehe Abschnitt 5.4 sowie Abschnitt 5.8.4) wurde in der internationalen Norm ISO 10303 „Industrial automation systems and integration Product data representation and exchange“ veröffentlicht. Er ging aus der Arbeit des ProSTEP iViP Vereins (siehe www.prostep.org) hervor. Nach Darstellung des Vereins ist STEP „eine rechner-interpretierbare Definition von physikalischen und funktionalen Merkmalen eines Produktes – den Produktdaten – während seines kompletten Lebenszyklus“ (siehe http://www.prostep.org/de/standards-amp-infos/was-ist-step.html). Darüber hinaus ist STEP „eine Methode, die ihre Anwendung für den schnellen und sicheren Austausch und die gemeinsame Nutzung von Daten zwischen Partnern (z.B. Herstellern und Zulieferern, hausintern und weltweit), die verschiedene Rechner- und Anwendungssysteme einsetzen, nachgewiesen hat“. Die Product Data Management Enablers (PDM-Enablers) stellen eine am objektorientierten Middleware-Konzept ausgerichtete Spezifikation für die Implementierung von Daten- und Funktionsschnittstellen für Produktund Prozessinformationen dar (Product Data Management Enablers Specification 2000). Die Spezifikation ist ein Standard der Object Management Group (Abk.: OMG). Die OMG ist ein internationales, offenes, nonprofit Konsortium aus der IT-Industrie, dessen Arbeitsgruppen Standards für Unternehmensintegrationslösungen für ein breites Technologiespektrum entwickeln (vgl. www.omg.org). Zu den bekanntesten Standards gehören zum Beispiel die Modellierungssprache Unified Modelling Language (Abk.: UML) oder die Common Object Request Broker Architecture (Abk.: CORBA). Ziel der PDM-Enablers Spezifikation ist es, mittels robuster Schnittstellen die Interoperabilität zwischen PDM-Systemen und einer Vielzahl weiterer Softwaresysteme zu ermöglichen. Hierzu wird ein Rahmenwerk für Schnittstellen von PDM-Systemen spezifiziert, die von PDMTechnologieanbietern, dritten Softwareanbietern oder vom Endanwender angepasst und erweitert werden können. Typische Schnittstellenfunktionen sind zum Beispiel der Aufruf von Dokumenten und die Darstellung von

3.6 Modelle als Kern des PLM: Das PLM Manifest 45

Produktstrukturen. Die PDM-Enablers Spezifikation erhebt den Anspruch, dass die spezifizierten Schnittstellen auf der einen Seite ausreichend einfach und allgemein gehalten werden, um in einem weiten Spektrum von Applikationen genutzt werden zu können, und auf der anderen Seite komplex und spezifisch genug sind, um ausreichend bedeutsam und vollständig zu sein (siehe http://mantis.omg.org/mfgadopted.htm#PDM). Der Standard wurde Ende der 90er Jahre entwickelt, die aktuelle Version 1.3 datiert aus dem Jahr 2000. Inzwischen wird er von der Manufacturing Technology & Industrial Systems Task Force (Abk.: ManTIS), einer Arbeitsgruppe der OMG, betreut (siehe http://mantis.omg.org). Der Standard OMG PLM Services wurde von dem ProSTEP iViP Verein entwickelt und von der OMG standardisiert. Der Standard verknüpft STEP-Datenmodelle mit XML- und Web Services Technologien als technologische Grundlage für die Datenübertragung und Kommunikation. Ähnlich dem PDM Enablers Standard spezifizieren die OMG PLM Services Standard-Schnittstellen für grundlegende PDM-Funktionen. Der Standard zielt darauf ab, unternehmens-, domänen-, system- und technologieübergreifende Zusammenarbeit zu ermöglichen (vgl. http://www.prostep.org/de/standards-amp-infos/omg-plm-services.html). Typische Szenarien, die unterstützt werden, sind zum Beispiel das Durchsuchen von verteilten Produktdatenstrukturen, design-in-context oder Produktdatenvisualisierung.

3.6

Modelle als Kern des PLM: Das PLM Manifest

In Abschnitt 2.3 wurde eine möglichst formale, modellbasierte Beschreibung des Fachkonzepts und eine umfassende Dokumentation aller Vorgänge rund um das PLM gefordert, um einen zielorientierten, nachhaltigen und zukunftsweisenden Gesamtrahmen für eine PLM-Realisierung zu erhalten. Um der Bedeutung dieses Konzeptes als umfassendes Beschreibungselement einen entsprechend hohen Stellenwert zu verleihen, haben wir in dem in diesem Buch ausgeführten Leitwerk den Begriff des generischen PLM-Manifestes eingeführt. Das PLM-Manifest protokolliert und archiviert alle Ergebnisse rund um die PLM-Umsetzung. Hierzu gehören neben Pflichten- und Lastenheften, Verträgen etc. vor allem formale Konzeptbeschreibungen der PLM-Lösung, und hier insbesondere die zuvor beschriebenen Produkt- und Prozessmodelle. Diese Konzepte und Dokumente unterliegen einer ständigen Weiterentwicklung.

46

3 Modelle – Änderungen und Ergebnisse konsistent verwalten

Abb. 3-4: PLM-Manifest

Das PLM-Manifest wird daher schritthaltend mit allen Aktivitäten rund um den „Dombau PLM“ fortgeschrieben, und mit Informationen angereichert. So entsteht nach und nach ein „Wissens-Kompendium“ mit allen unternehmensspezifischen PLM-relevanten Daten, Dokumenten, Modellbausteinen und den korrelierenden Veränderungsschritten – ganz in dem Sinne: „Systeme, Werkzeuge, Technologien und Methoden kommen und gehen, unser PLM-Manifest bleibt“. Das Konzept des PLM-Manifests soll die folgende Abbildung noch einmal verdeutlichen. Im Mittelpunkt stehen Modelle, die das Konzept repräsentieren, eingerahmt von Dokumenten, die auf den Konzeptbeschreibungen aufsetzen (siehe Abb. 3-4). Aus Effizienzgründen sollte das Manifest IT-gestützt verwaltet werden. Hier bieten sich Modellierungswerkzeuge verbunden mit Dokumentenmanagementsystemen an. Ein in letzter Zeit in Mode gekommener und in diesem Kontext als sehr vielversprechend anzusehender Ansatz wäre beispielsweise der Aufbau eines geeigneten PLM-Wikis. Eine in dieser Form fortzuschreibende Dokumentation, die ständig Änderungen und Erweiterungen unterliegt, bedarf entsprechender Pflege. Dieser wird nur dann zielführend nachgegangen, wenn für das PLMManifest eine eindeutige Verantwortlichkeit festgelegt wird. Das Leitwerk

3.6 Modelle als Kern des PLM: Das PLM Manifest 47

sieht für diese Funktion eine spezielle Instanz vor, den PLM-Stab, dessen Funktion im Folgenden konkretisiert wird. Der Einsatz von gängigen Methoden zur Dokumentation von Projekten ist hierbei ratsam. Da für die oben genannten Dokumente das PLM-Manifest als Archivierungsrahmen fungiert, wird im Folgenden nicht weiter auf die Ablage dieser Dokumente eingegangen. Vielmehr soll im Weiteren die formale Konzeptbeschreibung im Mittelpunkt stehen.

4 Evolutionäres Vorgehensmodell

Negative Schlagzeilen zu gescheiterten oder überteuerten PLM-Einführungen füllen ebenso wie Erfolgsstorys über die Notwendigkeit von PLM die Fachpresse. Das hier vorgestellte Vorgehensmodell soll den bekannten Risikofaktoren entgegenwirken, um die eigene PLM-Einführung zu einer Erfolgsgeschichte werden zu lassen. Jedoch soll zunächst einmal auf ausgewählte Negativfaktoren eingegangen werden, um daraus die Notwendigkeit der Bestandteile des Vorgehensmodells zu motivieren. Häufig wird als Grund für das Scheitern von PLM-Einführungen die Dauer der Einführung und die damit einhergehende langfristige Bindung von Ressourcen insbesondere von Personen angegeben. Hier entstehen häufig Divergenzen in der Ressourcenzuordnung. Die mittlere Führungsebene hat auf eine störungsfreie Gewährleistung des laufenden Geschäfts zu achten und benötigt hierzu möglichst alle Ressourcen, da sie in der Regel an den Ergebnissen des aktuellen Geschäfts gemessen wird. Die Wirtschaftlichkeit von PLM ist schwer nachzuweisen. Beispielsweise lassen sich Maßahmen zur langfristigen Absicherung der Produktentwicklung nur schwer quantifizieren. Entscheidungsträger tun sich daher schwer, eine vollumfängliche PLM-Einführung mit entsprechend hohen Investitionen zu genehmigen. Ein Ausgliedern von Ressourcen aus dem aktuellen Tagesgeschäft ist für die mittlere Führungsebene in der Regel kaum vorstellbar, ist aber für ein erfolgreiches PLM unabdingbar. Hinzu kommt häufig ein persönlicher Interessenskonflikt bei den Verantwortlichen der PLM-Einführung. Die persönlichen zeitlichen Ziele sind oft schwer mit dem Zeithorizont einer PLM-Einführung in Einklang zu bringen. Die Übernahme der Verantwortung für die PLM-Einführung ist auf den ersten Blick somit kein Thema, das zur persönlichen Profilierung im Unternehmen beiträgt. Um dem entgegenzuwirken, entzerrt der vorgestellte Ansatz die Einführung von PLM durch das vorgeschlagene Vorgehensmodell in mehrere, in sich abgeschlossene Projekte bzw. Teilprojekte, die überschaubar sind, und schafft so erreichbare Zwischenziele. Soll PLM im Unternehmen als eine neue Strategie aufgebaut werden, muss für dieses Vorhaben ein Team mit entsprechendem Know-how bereitgestellt und Kompetenz aufgebaut werden und dies kann nur von einer entsprechenden Position angestoßen V. Arnold et al., Product Lifecycle Management beherrschen, 2. Aufl., DOI 10.1007/978-3-642-21813-2_4, © Springer-Verlag Berlin Heidelberg 2011

50

4 Evolutionäres Vorgehensmodell

werden. PLM wird nicht als ein Projekt, sondern als eine im Unternehmen fest installierte Kompetenz gesehen. Wie schon in vorhergehenden Kapiteln erwähnt, ist PLM ein kontinuierlicher Prozess im Unternehmen. Das hier beschriebene Vorgehensmodell ist ein Schema für den Umgang mit PLM, ein Meta-Vorgehensmodell. Zunächst enthält es keine konkreten Handlungsschritte zur Einführung, sondern soll vielmehr das generelle Vorgehen mit unterschiedlichen, bewährten Hilfsmitteln darlegen. Um konkrete Handlungsschritte zu erhalten, muss das Schema mit entsprechenden Inhalten aus den Leitheften (Kap. 5) ergänzt werden. So soll dem Anspruch eines generischen, auf ein Unternehmen anpassbaren, Vorgehensmodells Rechnung getragen werden.

4.1

PLM als Paradigma im Unternehmen

Basis des evolutionären Vorgehensmodells (siehe Abb. 4-1) ist ein Spiralmodell, in dessen Kern das PLM-Manifest steht (siehe Abschnitt 4.1.3). Der Grundgedanke des Vorgehensmodells ist dem Boehmschen Spiralmodell der Softwareentwicklung entliehen, das dort für komplexe Softwareprojekte ein etabliertes Vorgehensmodell ist. Eine ähnlich komplexe Aufgabe stellt die Integration von PLM im Unternehmen dar. So wurde auf Basis des Spiralmodells das evolutionäre Vorgehensmodell entwickelt, um von den Erfahrungen aus der Softwareentwicklung zu profitieren, angereichert an PLM-spezifischen Elementen. Neben dem in vier Phasen eingeteilten dynamischen Element, der Spirale, enthält das evolutionäre PLM-Vorgehensmodell drei beständige Elemente: Den PLM-Stab, die PLM-Vision und das PLM-Manifest, die über die einzelnen Projekte hinaus ständig im Unternehmen integriert werden. Hierbei ist der PLM-Stab für die PLM-Vision und das PLM-Manifest verantwortlich (siehe Abschnitt 4.1.1). Eine Definition dieser Begriffe folgt in den nächsten Abschnitten. Die Integration von PLM im Unternehmen wird aufgrund des thematischen und zeitlichen Umfangs in mehrere Projekte eingeteilt. Der PLM-Stab initiiert diese PLM-Projekte und übernimmt in diesen Controlling-Aufgaben. Die einzelnen Projekte entsprechen jeweils einem Spiralzyklus aus dem Vorgehensmodell, eingeteilt in vier Phasen, so wie es in Abb. 4-1 mit dem linearen Fortschrittspfeil dargestellt ist. Die einzelnen Phasen werden ab Abschnitt 4.2 näher erörtert. So sieht das Vorgehensmodell ein sequentielles Abhandeln einzelner PLM-Aspekte vor.

4.1 PLM als Paradigma im Unternehmen 51

Abb. 4-1: Evolutionäres Vorgehensmodell

Dies ist jedoch ein idealisiertes Vorgehensmuster. In der praktischen Umsetzung kann es aus unterschiedlichen Gründen durchaus zu einer Überschneidung einzelner Projekte kommen. Beispielsweise tritt ein solcher Fall begründet durch gegenseitige Abhängigkeiten der PLM-Aspekte ein, sodass parallele Aktivitäten sinnvoll oder auch einfach aufgrund des zeitlichen Aspekts erforderlich sind. Zu bevorzugen ist in der Regel dennoch ein sequentielles Bearbeiten der PLM-Themen. Ziel dieser Vorgehensweise ist es, die Komplexität der gesamten PLM-Thematik schrittweise in den Griff zu bekommen und die eingesetzten Ressourcen nicht übermäßig zu belasten. Zwischenergebnisse motivieren die Einführung und verringern die Entwicklungsleistungen, welche das Unternehmen eingehen muss. So sollen alle Voraussetzungen für eine erfolgreiche PLMEtablierung im Unternehmen geschaffen werden. 4.1.1 PLM-Stab Mittelständische Unternehmen sollten dem Trend der Großunternehmen folgen und PLM als Kernkompetenz ihres Unternehmens betrachten. Großunternehmen richten hierfür eigene Abteilungen für die Planung und Bearbeitung von PLM-Projekten sowie den Betrieb ein – eine Vorgehensweise, die für mittelständische Unternehmen nicht in Frage kommt. Hier

52

4 Evolutionäres Vorgehensmodell

empfiehlt es sich für KMU, eine organisatorische Stelle vergleichbar mit einem Qualitätsverantwortlichen einzurichten, die unabhängig vom operativen Tagesgeschäft ihren Aufgaben nachgehen kann. In einer StabLinienorganisation könnte dies eine Stabsstelle sein. Daher wird im Folgenden der Begriff PLM-Stab eingeführt. Die Mitarbeiterstärke dieses PLM-Stabs ist von der Größe des Unternehmens abhängig. Angelehnt an die Funktion eines Stabes einer klassischen Stab-Linien-Organisation verfolgt auch der PLM-Stab kein operatives Geschäft, sondern befasst sich strategisch mit dem abteilungsübergreifenden Querschnittsthema PLM. So sichert er einerseits die Nachhaltigkeit und treibt andererseits das Thema fachlich sowie unternehmenspolitisch weiter voran. Durch diese Stellung soll dem PLM-Stab die Rückendeckung der Geschäftsführung gesichert und ein gewisser Freiraum eingeräumt werden. Dies ist die Grundvoraussetzung für die organisatorische Integration von PLM. Zu den strategischen Aufgaben des PLMs gehören alle langfristigen ITZiele im Produktentstehungsprozess sowie eine vorausschauende Beobachtung der Marktentwicklungen und der Entwicklung unterstützender IT-Werkzeuge. Es ist darauf zu achten, dass diese Aufgabe losgelöst vom allgemeinen Tagesgeschäft aber auch von operativen IT-Tätigkeiten sein sollte. Somit ist der PLM-Stab primär eine Planungs-, Kontroll- und Steuerungsinstanz. Bei kleineren Firmen wird diese Stabsstelle keine volle Stelle beanspruchen und ist mit anderen Tätigkeiten zu verbinden. Jedoch ist bei der Einbindung von ohnehin schon überlasteten Führungskräften Vorsicht geboten. Diese Stabsstelle ist keine zusätzliche Nebentätigkeit, die einem Mitarbeiter auferlegt werden kann. Festgehalten werden die strategischen Ziele und Erwartungen an PLM in der „PLM-Vision“, die im folgenden Abschnitt näher beschrieben wird. Aus den strategischen IT-Zielen werden mittels des PLM-MaturityModells (Abschnitt 4.2.1) operative PLM-Ziele abgeleitet, die in einzelnen Projekten umgesetzt werden, die vom PLM-Stab initiiert werden. In den einzelnen Projekten übernimmt der PLM-Stab eine Controlling-Funktion. Er ist für die Konsistenz der Projekte und der Vision verantwortlich und hat auf eine ausführliche Dokumentation im Sinne des PLM-Manifests zu achten. Insbesondere bezieht sich dies auf die Konsistenz der dokumentierten Modelle (siehe Abschnitt 4.2.1). Nicht zuletzt verantwortet der PLMStab die unternehmensinterne Motivation des Themas PLM, ein häufig unterschätzter PLM-Aspekt, auf den im Leitheft „Mitarbeiter für PLM motivieren“ (siehe Abschnitt 5.16) näher eingegangen wird.

4.1 PLM als Paradigma im Unternehmen 53

4.1.2 PLM-Vision Angelehnt an eine Unternehmensvision sollte ein Unternehmen eine PLMVision verfassen. Die PLM-Vision ist ein Hilfsmittel, gewissermaßen ein Leuchtturm, der den angestrebten – eher als ideal zu verstehenden – Endzustand der PLM-Umsetzung beschreibt. Die PLM-Vision als allgemein verständlich formulierter Endzustand erlaubt es allen Involvierten, den jeweiligen Stand des PLM-Projektes mit seinem Fernziel zu vergleichen und es daran zu messen. Die PLM-Vision beschreibt die langfristigen Ziele, die das Unternehmen mit PLM verfolgt. So wird die strategische Zielsetzung, die mittels PLM erreicht werden soll, festgehalten. Mit der PLM-Vision sollen drei Ziele verfolgt werden. Erstens dient die PLM-Vision als Kontrollinstrument zur Überprüfung des Fokus der einzelnen PLM-Projekte und zum Zweiten soll mit der PLM-Vision die PLM-Ziele allen Beteiligten verdeutlicht werden. Sie ist somit eines der wesentlichen zentralen Kommunikationsmittel. Drittens soll anhand der PLM-Vision die Aktualität der eigenen Zielsetzung ständig durch Infragestellen derselben kontrolliert werden. Hierzu ist eine Beobachtung der allgemeinen Markt- und Technologieentwicklungen im IT-Umfeld durch den PLM-Stab notwendig, um Trends rechtzeitig zu erkennen, die auch für das eigene Unternehmen von Vorteil sein können. Zu Beginn des Kompetenzaufbaus im Unternehmen wird die Vision in wenigen Sätzen die Erwartungen unter Berücksichtigung der unternehmenseigenen Arbeitsweise an PLM festhalten. Erweitert und abgeglichen wird die PLM-Vision am Ende der PLM-Readiness-Phase jedes Vorgehenszyklus, sodass die Vision mit den einzelnen Projekten mitlebt. So kann entsprechend auch auf running targets im Bereich PLM reagiert werden. Durch die Aufnahme der Zielsetzung des anstehenden Zyklus und durch die Aufnahme der erwarteten Zielsetzungen für Folgeprojekte entsteht eine Art übergeordneter Masterplan. Hierbei ist zwischen langfristiger Ausrichtung und Aktualität abzuwägen, sodass ein hohes Abstraktionsniveau gefordert ist. So wird die PLM-Vision immer wieder in Frage gestellt und mit Erkenntnissen und Anregungen aus den Teilprojekten aktualisiert. Ferner ist aufgrund der Langfristigkeit des Kompetenzaufbaus von PLM dem Interessenskonflikt mit persönlichen Zielen der PLMVerantwortlichen mit der PLM-Vision vorzubeugen. Beispielsweise könnte ein erster Wurf einer PLM-Vision wie folgt aussehen: „PLM soll die internationale Wettbewerbsfähigkeit unseres Unternehmens nachhaltig sichern. Dazu muss uns PLM in die Lage versetzen, mit gleich bleibendem

54

4 Evolutionäres Vorgehensmodell

Personaleinsatz eine größere Produktvielfalt auch in neuen Märkten anbieten zu können…“ 4.1.3 Generisches PLM-Manifest Im vorgestellten Leitwerk wird der Ansatz einer modellbasierten Dokumentation verfolgt. Das Unternehmen, die Produkte und die Prozesse sowie die IT-Systemlandschaft werden in Modellen auf den unterschiedlichen Ebenen, Managementkonzept, Fachkonzept und DV-Konzept, beschrieben und verbal kommentiert. Diese werden folgend PLM-Modelle genannt (siehe Abschnitt 3.2.1). Das Ziel dieser Vorgehensweise ist es, ein möglichst vollständiges formales Abbild aller PLM-relevanten Aspekte eines Unternehmens zu hinterlegen, bestehend aus einer Vielzahl von Partialmodellen aus den drei oben genannten Bereichen und den Dimensionen der modellbasierten Dokumentation und zwar in verschieden Detaillierungsebenen. Diese PLM-Modelle bilden eine Grundlage zur Kommunikation mit internen und externen Projektpartnern sowie zur späteren Systemimplementierung. Sie stellen den Kern des PLM-Manifests dar. Die wesentlichen Elemente des Manifests wurden bereits in Kap. 3 beschrieben. In den letzten Jahren haben sich mehrere Modellierungsmethoden aus der Wirtschaftsinformatik und aus der Softwareentwicklung mit unterschiedlichen Vor- und Nachteilen etabliert. Durch den Einsatz entsprechender Modellierungswerkzeuge kann der Modellierungsprozess unterstützt und die Konsistenz der einzelnen PLM-Modelle gewährleistet werden. Daher ist der Einsatz von solchen Tools empfehlenswert. Jedoch kann nicht verallgemeinert gesagt werden, welche Modellierungsmethodik bzw. welches Werkzeug zu bevorzugen ist. Im Leitwerk finden in erster Linie die Modelle der UML Anwendung. Die PLM-Modelle entwickeln sich im Laufe der Anwendung des kontinuierlichen PLM-Vorgehensmodells mit jedem PLM-Projekt weiter. Sie werden ständig aufgrund von Veränderungen im Unternehmen oder anderen Kriterien, die sich auf die Zielsetzung auswirken, nachgezogen und mit der Reife der PLM-Projekte detailliert. Für das Vorgehensmodell bedeutet dies, dass die PLM-Modelle mit jedem Zyklus des evolutionären Vorgehensmodells verfeinert werden. So ist stets auf Aktualität zu achten. Die Modellierung soll in erster Linie der Konzeption dienen und keine verspätete Dokumentation der stattgefundenen Implementierungen sein. Neben der nachhaltigen Beschreibung der Konzepte, wird jedoch die Implementierung anhand der Konzeptmodelle in Umsetzungsmodellen geplant. Ge-

4.2 Phase „PLM Readiness“ 55

gebenenfalls müssen bei Abweichungen von der Planung nach erfolgter Implementierung diese entsprechend in der Dokumentation nachgetragen werden. So wird zunächst der Ist-Stand, anschließend ein Soll-Stand und abschließend der neue Ist-Stand modelliert. Hierdurch soll die zeitnahe Dokumentation aller Planungen und Realisierungen motiviert werden. Ferner wird eine Anwendung einführend erwähnter Modellierungsebenen mit jeweils eigenständigen Modellen empfohlen. Aus der Wirtschaftsinformatik stammt hierfür ein Ansatz, der eine Dreistufigkeit vorschlägt. Angelehnt an dieser 3-Ebenen-Methodik existieren für jeden Aspekt (Produkt, Prozess, IT) einzelne Modelle für Managementkonzepte, Fachkonzepte und DV-Konzepte, wie es im Abschnitt 3.2.1 vorgestellt wurde. Diese Ebenen des Modells werden in den Phasen 2– 4 des evolutionären PLM-Vorgehensmodells erstellt. Nähere Informationen hierzu befinden sich in der Beschreibung der Phasen. Hieraus ergeben sich drei Dimensionen für das PLM-Manifest. Die erste beschriebene Dimension fokussiert die Aspekte des PLMs. Die zweite, angesprochene Dimension bezieht sich auf die zeitliche Veränderung des PLM-Zustands. Schließlich beschreibt die dritte Dimension die Konkretisierungsstufe. Neben diesen PLM-Modellen des Unternehmens sollten alle weiteren relevanten Dokumente im Zusammenhang mit PLM zentral mit Relationen zu diesen Modellen verwaltet werden. Explizite Abhängigkeiten der Modelle untereinander erlauben es, von dem einen PLM-Modell zu sprechen. Das um die beschreibenden und ergänzenden Dokumente erweitere PLMModell ergibt in seiner Gesamtheit das PLM-Manifest. Zu den ergänzenden Dokumenten zählen unter anderem alle Lasten- und Pflichtenhefte, alle Protokolle, Schulungsunterlagen, Software-Spezifikationen etc. Gelingt ein vollständiges, konsistentes, modellhaftes Abbild eines Unternehmens, dessen Nachhaltigkeit durch Anwendung von Modellierungswerkzeugen sichergestellt werden kann, ist zugleich eine Basis für ein Qualitätsmanagement geschaffen. Die Modellierung der Prozesse bietet Grundlage für eine durchgängige Prozessbeschreibung, die für eine Zertifizierung nach DIN ISO 9000 ff. verwendet werden kann, da sich die dokumentierten Prozessbeschreibungen mit geringem Aufwand zu einem Qualitätsmanagement-Handbuch erweitern lassen (VDI 2219).

4.2

Phase „PLM Readiness“

Product Lifecycle Management bietet viele Möglichkeiten, die Produktentstehung durch effiziente Nutzung moderner Software-Werkzeuge zu opti-

56

4 Evolutionäres Vorgehensmodell

mieren. Ein Unternehmen, das sich – motiviert durch positive Erfahrungen anderer Unternehmen oder aufgrund bekannter Brüche bei internen Abläufen – erstmalig mit PLM auseinandersetzt, hat häufig noch keine oder nur vage Vorstellungen einer PLM-Lösung. Dieser Abschnitt soll Anhaltspunkte zur Konkretisierung der Anforderungen an PLM liefern und beim Validieren der unklaren Anforderungen helfen. Am Anfang jedes PLMProjektes gilt es, die aktuelle Situation bezüglich PLM im Unternehmen zu bewerten, um später aus dieser Bewertung Potentiale ableiten zu können. Verbunden mit einer Kosten-/Nutzenanalyse für diese Potentiale wird eine Zielsetzung für das jeweilige Projekt formuliert. Dies ist Inhalt der ersten Phase im evolutionären Vorgehensmodel (siehe Abb. 4-2) Hierfür bietet es sich an, auf gängige Bewertungsmethoden zurück zu greifen. In diesem Anwenderhandbuch wird ein Tool-unterstützter Ansatz zur Bewertung vorgestellt, der im Forschungsprojekt PLM4KMU entwickelt wurde. Dieses Werkzeug erlaubt mit geringem Zeitaufwand schnell eine qualitative Aussage zur „PLM-Reife“ des Unternehmens zu treffen. Damit wird sowohl eine vollständige als auch eine teilweise Wiederholung der Bewertung in gewissen zeitlichen Abständen möglich, um erzielte Verbesserungen bewerten zu können. Sollen andere Bewertungsmethoden eingesetzt werden, ist dies gleichfalls möglich. Es sollte lediglich auf Übereinstimmung der wesentlichen Elemente geachtet werden. Das PLMMaturity-Modell aus dem Forschungsprojekt kann über die Autoren des Buches bezogen werden (www.prozesswerk.eu).

Abb. 4-2: PLM-Readiness

4.2 Phase „PLM Readiness“ 57

4.2.1 Maturity-Modell Ziel des Maturity-Modells soll es sein, dass ein Unternehmen individuell unter Berücksichtigung der Unternehmenscharakteristik bezüglich PLM den eigenen Status quo bewerten, Nutzenpotentiale entdecken und notwendige Voraussetzungen prüfen kann. Hierzu wird für einzelne PLMAspekte eine zweistufige Reifegradbestimmung eingeführt, die eine ganzheitliche PLM-Bewertung zulässt. Ist-Werte geben Auskunft über den derzeitigen PLM-Status des Unternehmens und entsprechende Soll-Werte zeigen einen zu erreichenden Zielwert auf. Der Soll-Wert ergibt sich in Abhängigkeit aus der Unternehmensstruktur, den zugehörigen Prozessen und der Beschaffenheit der Produkte. Das Spannungsfeld zwischen den Ist- und den Soll-Werten verdeutlicht das Potential für das jeweilige Unternehmen im Bereich PLM. Die Zusammenhänge zwischen den einzelnen Thematiken in Kombination mit einer Kategorisierung von Unternehmen sollen es nicht nur Beratern, sondern auch und gerade Angehörigen des Unternehmens selbst ermöglichen, eine Bewertung des Unternehmens durchzuführen. Es ist kein Ziel, mögliche Handlungsanweisungen in algorithmischer Art zu generieren. Auf Basis des Ergebnisses ist jedoch zu erwarten, dass mit der Thematik Vertraute besser in der Lage sein werden, eine Einschätzung und Planung des weiteren Vorgehens durchführen zu können. Die Idee, die dem PLM-Maturity-Modell (engl.: maturity = Reife) zugrunde liegt, leitet sich aus Modellen ab, die aus dem Bereich der Softwareentwicklung stammen und dort für die Bewertung der Qualität und Produktivität des Softwareentwicklungsprozesses dienen. Hierzu zählen u.a.: x Capability Maturity Model (CMM): Es entstand als Fragebogen zur Bewertung von Softwarelieferanten und wurde zu einem Referenzmodell ausgebaut. Hieraus entwickelte sich ein normierter Maßstab für den Vergleich von Unternehmen. x Software Process Improvement and Capability Determination (SPICE): SPICE integriert und vereinheitlicht vorhandene Ansätze aus CMM und ISO 9000 und ist in der ISO-Norm 15504 festgelegt. Das PLM-Maturity-Modell ist kein Referenzmodell für den richtigen Einsatz von PLM, wie es andere Maturity-Modelle teilweise vorgeben. So ist eine absolute Bewertung eines Unternehmens oder gar ein Ranking mehrerer Unternehmen mit dem PLM-Maturity-Modell nicht das Ziel. Es soll lediglich der größtmögliche Nutzen für die nächsten Schritte zur Verbesserung des PLM-Konzepts und der PLM-Anwendung individuell ermittelt

58

4 Evolutionäres Vorgehensmodell

werden. Die so bestimmten möglichen Ansatzpunkte können durch eine unternehmensindividuelle Interpretation in eine Entscheidungsgrundlage für das weitere Vorgehen des Unternehmens überführt werden. 4.2.2 Zielsetzung des Maturity-Modells Das Ziel des Maturity-Modells ist die Ermittlung des aktuellen Entwicklungsstandes des Themenbereichs PLM in einem Unternehmen. Das Unternehmen soll mit Hilfe dieses Modells selbst in der Lage sein, den eigenen Status in Bezug auf PLM zu bewerten, um vorhandene Nutzenpotentiale aufzudecken. Zudem sind für manche PLM-Themen gewisse Voraussetzungen notwendig. Auch dies wird durch das Maturity-Modell überprüft. Das Resultat der Reifegradbewertung gemäß dem Maturity-Modell sind zwei Werte für jedes PLM-Thema. Das ist einerseits ein Wert, der den aktuellen Ist-Stand bemisst und andererseits ein Wert, der den Bedeutungsgrad des jewiligen Themas für das Unternehmen angibt. Der Bedeutungsgrad ist abhängig von der Unternehmenscharakteristik und gibt einen individuellen Status des Nutzwertes dieses Themas in Abhängigkeit von Unternehmensstruktur, ihren Prozessen und der Produktbeschaffenheit. Der Ist-Zustand ergibt sich aus einer Grobanalyse zum aktuellen Zeitpunkt. So soll anhand der Differenz zwischen den jeweiligen Reifegradepaaren der größtmögliche Nutzen für die nächsten Schritte zur Verbesserung des PLM-Konzeptes und der daraus folgenden PLM-Anwendung ermittelt werden. Das PLM-Maturity-Modell ist kein Referenzmodell für den „richtigen“ Einsatz von PLM, d.h. es macht keine Vorgaben wie und in welchem Umfang PLM umgesetzt werden muss. Die Idealvorstellung eines „digitalen Unternehmens“, das alle Prozesse IT-technisch unterstützt oder sogar automatisiert und alle Informationen über ein IT-System vollständig verfügbar hat, ist heute in der Praxis kaum vorstellbar. Das MaturityModell hilft jedoch, den individuellen Weg für PLM im Unternehmen festzulegen. 4.2.3 Abhängigkeiten der PLM-Funktionsblöcke Die Trennung der PLM-Einführung auf einzelne Projekte in Abhängigkeit von Funktionsblöcken ist einerseits ein bewährtes Instrument, um die Komplexität der PLM-Thematik beherrschen zu können, andererseits kann ein solches Vorgehen aber auch zu einer nicht gewünschten isolierten Be-

4.2 Phase „PLM Readiness“ 59

trachtung einzelner PLM-Aspekte führen. Bestehende Abhängigkeiten zwischen einzelnen PLM-Aspekten, wie es Abb. 4-3 verdeutlicht, müssen deshalb berücksichtigt werden. So sollte bei der Umsetzung einzelner PLM-Aspekte stets auf die Erfüllung vorausgesetzter Aspekte geprüft werden.

Abb. 4-3: Abhängigkeiten der PLM-Funktionsblöcke

60

4 Evolutionäres Vorgehensmodell

Voraussetzung für alle Kategorien stellt ein Klassifizierungs- und Benennungssystem sowie ein valides Strukturmanagement dar (siehe Abb. 4-3, 1. Ebene). Darauf aufbauend ist zur konsistenten Verwaltung aller Dokumente ein Dokumentenmanagement unabdingbar, welches u.a. Zugriffsregelungen und Sperrmechanismen beinhaltet. Auf der 2. Ebene befinden sich Funktionen, die bereits eine integrierte Verwaltung von Dokumenten durch das Managen von Versionen, Varianten und Alternativen sowie die Behandlung dieser mittels definierter Prozesse und die Verzahnung der verwendeten Tools im Sinne der applikationsspezifischen Funktionen ermöglichen. Zu den Prozessen gehören u.a. Freigabe-, Änderung- und Workflow-Management sowie das Statusmanagement. Die höchste Ebene stellt auf Prozessseite die Verbindung mehrerer Anwender, das Projektmanagement sowie das Lifecycle-Management und die in Teilen unternehmensübergreifende Kommunikation dar. Im Bereich der produktzentrierten Sicht werden mit der Verwaltung der Konfigurationen zur Sichtendarstellung und zur Langzeitarchivierung Voraussetzungen zum Umgang mit komplexen Produktstrukturen in strategischen (langfristigen) Zeitrahmen geschaffen. Auf dieser Ebene werden in der Kategorie der Dienstfunktionen Mechanismen zum Datenaustausch verschiedener (Anwendungs-)Systeme eingeordnet. Dazu gehört neben der Konvertierung in Austauschformate der Datentransport zwischen diesen Systemen. Zu beinahe jedem PLM-Aspekt findet sich in Kap. 5 ein eigenes Leitheft mit umfassenden Informationen. 4.2.4 Anwendung des Maturity-Modells Das Tool zum PLM-Maturity-Modell basiert im Wesentlichen auf Fragebögen, unterteilt in drei Stufen der Bewertung: Unternehmenseinordnung, Status- und Zielwerterfassung. Die Fragen der letztgenannten Phasen werden individuell aufgrund der Ergebnisse aus der Unternehmenseinordnung zusammengestellt. Die Fragen der jeweiligen Phasen der Befragung basieren auf einem einfachen Multiple-Choice-Prinzip. Dadurch soll das Beantworten der Fragen vereinfacht werden. Sie fragen in ihrer Kombination indirekt Informationen zum Unternehmen und zum PLM-Stand ab. Anhand dieser Fragen werden die einzelnen Funktionsblöcke abgefragt und ein Reifegrad bestimmt, wie es schematisch Abb. 4-4 für die Betrachtung der PLM-Themen Produkt-Klassifizierung und Benennung, Produktstrukturmanagement, Zugriffsverwaltung sowie Daten- und Dokumentenmanagement zeigt. Der Prozess der Reifegradbestimmung unter-

4.2 Phase „PLM Readiness“ 61

gliedert sich in eine Vorbereitungsphase und in vier Hauptprozesse: Komplexitätsbestimmung, Soll-Profilerstellung, Ist-Profilbestimmung (Status) und abschließend die Interpretation des Ergebnisses. Hierbei werden keine konkreten Kategorien oder Fragen beschrieben, sondern ausschließlich der Ablauf einer Bewertung vorgestellt. Der Prozess zur Bewertung eines Unternehmens wird in Abb. 4-5 dargestellt. Der mit der Untersuchung Beauftragte, im Folgenden auch Durchführender genannt, muss zunächst die Befragung vorbereiten. Im Mittelpunkt dieser Vorbereitung sollte die Auswahl der Gesprächspartner stehen. Das Maturity-Modell sieht eine Personengruppe vor, bestehend aus jeweils einem Vertreter der Unternehmensführung, dem IT-Bereich, der Konstruktion und einem PLM-Verantwortlichen, wenn bereits eine solche Position im Unternehmen vorhanden ist.

Abb. 4-4: Maturity-Modell

62

4 Evolutionäres Vorgehensmodell

Abb. 4-5: Prozess der Reifegradbestimmung

4.2 Phase „PLM Readiness“ 63

Zu Beginn des ersten Hauptprozesses bestimmt der Durchführende zunächst die Charakteristik des Unternehmens anhand des ersten Teils des Fragebogens bzw. mit Hilfe von Unternehmensangehörigen. Diese Einordnung hat direkte Auswirkungen auf den später verwendeten Kriterienkatalog, da Interdependenzen zwischen den Wertebelegungen der Checkliste und den sichtbaren Fragestelllungen des Kriterienkataloges bestehen. Aufgrund der Zuordnung der gewonnenen Unternehmensklasse wird eine Einschränkung des Fragekataloges auf die relevanten Fragen durchgeführt. Als Ergebnis des ersten Prozessschrittes liegt demnach die Unternehmensklasse und der individualisierte Kriterienkatalog vor. Als Feedback für den Nutzer wird das Unternehmensprofil im Sinne der vorliegenden Komplexität nach Abarbeitung der Checkliste im Tool visualisiert, um das Verständnis für das Profil des Fragenkataloges zu fördern. Faktoren zur Ermittlung der Unternehmenscharakteristik sind: x x x x x

Größe des Unternehmens (Komplexität der Strukturen) Komplexität der Produkte Zulieferaspekt OEM-Natur Konstruktionsanteil des Unternehmens (Schwerpunkt der Tätigkeit auf Entwicklung oder Fertigung) x Anzahl unterschiedlicher Disziplinen (Software, Elektrik/Elektronik) x Vorliegende Systemlandschaft Im zweiten Schritt wird aus den Daten der Unternehmensklassifizierung ein Teil des Soll-Profils abgeleitet und so ein erstes Rahmenprofil erzeugt. Ein individuelles Anpassen des Rahmenprofils aufgrund von Erfahrungen des Durchführenden ist im Tool möglich. Der Rest der Soll-Werte wird während der Befragung ermittelt. Diese Trennung wird vorgenommen, um eine zu starke Detaillierung der Unternehmensklassifizierung zu vermeiden. Im dritten Hauptprozess wird die momentane Lage des Unternehmens unter Verwendung des individualisierten Fragebogens durch Befragung des ausgewählten Personenkreises erfasst. Ergebnis hierbei ist das IstProfil. Daraus werden durch Abgleich mit den Werten des Soll-Profils die PLM-Potentiale im Sinne einer Differenz aus Soll und Ist ermittelt. Sie beziehen sich auf die einzelnen Kategorien des Fragebogens und ergeben von sich aus keine Einzelkennzahl, sondern lediglich eine Sammlung von zusammengefassten Einzelwerten, die eine gewisse Streubreite besitzen. Im letzten Hauptprozessschritt werden die Ergebnisse der vorigen Phasen aufbereitet und interpretiert. Hierzu werden die Kategorien auf klassische PLM-Gebiete abgebildet und unterscheiden nach Kern-PLM-Gebieten und

64

4 Evolutionäres Vorgehensmodell

allgemeinen Rahmenbedingungen gruppiert. Die Interpretation der Ergebnisse erfolgt in Zusammenarbeit des Durchführenden mit einem PLMVerantwortlichen oder einem Manager des Unternehmens. Ein hohes Potential versprechen alle Themen, die eine große Differenz zwischen Istund Sollwerten haben. Zudem ist besondere Aufmerksamkeit auf Bereiche mit einer hohen Streubreite bei den Ist-Werten zu legen. In diesem Fall sollten Einzelpunkte innerhalb der vom Tool zusammengefassten Kategorien genauer untersucht werden, da Einzelaspekte dieser Kategorie unterschiedlich weit abgedeckt sind. Dem beurteilten Unternehmen werden anhand seines Potentialprofils Szenarien aufgezeigt, wie sich Anstrengungen des Unternehmens auf die zukünftige Situation auswirken können. Als Ergebnis liegt nun eine gewertete Menge der problematischen Themengebiete des Unternehmens vor, die in den Folgephasen des evolutionären Vorgehensmodells bearbeitet wird. 4.2.5 Formulierung der Zielsetzung Nach der durchgeführten Reifegradbestimmung muss zum Abschluss der ersten Phase des Vorgehensmodells eine Zielsetzung für einen Spiralzyklus auf Basis des Ergebnisses des Maturity-Modells erstellt werden. In der Interpretation des Maturity-Modells identifizierte Potentiale bieten hierfür den Ausgangspunkt. Zu prüfen ist nun, ob für diese Potentiale zunächst Voraussetzungen aufgrund der im Abschnitt 4.2.3 aufgezeigten Abhängigkeiten geschaffen werden müssen. Die Abb. 4-6 zeigt ein Beispiel, in dem zwar das Daten- und Dokumentenmanagement den größten Nutzen verspricht, jedoch zuvor das Produktstrukturmanagement erfüllt sein muss. Für die Bereiche mit den vielversprechendsten Potentialen sollte im nächsten Schritt eine Kosten-/Nutzenanalyse gemäß Abschnitt 5.15.4 durchgeführt werden. Zeigen dennoch mehrere Bereiche gleichwertige wirtschaftliche Potentiale auf, sollte sich das Unternehmen zunächst auf einen Bereich fixieren.

4.3 Phase „PLM Requirement Management” 65

Abb. 4-6: Beispiel zu Abhängigkeiten von PLM-Aspekten

Aufgrund dieser Untersuchungen kann nun die Zielsetzung für den jeweiligen Zyklus des Vorgehensmodells formuliert und mit der PLMVision abgeglichen werden. Besondere Sorgfalt ist bei der Festsetzung der Ziele in Hinsicht auf Querbeziehungen zu zukünftig anzugehenden Projekten zu legen. Mit der Fixierung auf ein PLM-Projekt dürfen nicht nachfolgende Projekte behindert werden. Besondere Vorsicht ist geboten, wenn eine Zielerreichung auf Basis von Systemfunktionen erfolgen soll. Das PLM-Manifest und insbesondere die PLM-Vision als übergeordnetes Dokument können hier als Instrumente der Koordination dienen. Ansätze hierzu enthält das Leitheft „Systeme kommunizieren lassen“ (siehe Abschnitt 5.11). Die ausformulierte Zielsetzung geht in das PLM-Manifest ein und stellt die Basis für die zweite Phase „PLM Requirement Management“ dar, in der die Zielsetzungen zu konkreten Anforderungen weiter entwickelt werden.

66

4.3

4 Evolutionäres Vorgehensmodell

Phase „PLM Requirement Management”

Die Phase des PLM-Requirements wird mit dem Ziel durchgeführt, die Anforderungen an den jeweiligen PLM-Aspekt formal festzuhalten (siehe Abb. 4-7). Grundlage hierfür sind die Zielsetzung aus der PLMReadiness-Phase und die Leithefte der jeweiligen PLM-Themen. Ausgehend von den formulierten Zielen der ersten Phase wird ein Lastenheft erstellt, das die Anforderungen der PLM-Zielsetzung unternehmensintern konkretisiert. Dieses Lastenheft wird zur Angebotseinholung (Ausschreibung) verwendet und dient später bei Einbezug von externen Systemlieferanten als Vertragsbestandteil. Es stellt in den ersten Spiraldurchläufen ein Lösungs- und Tool-neutrales Dokument unter Berücksichtigung der unternehmenseigenen Randbedingungen und Ressourcen dar, das die Anforderungen des Unternehmens an eine IT-Lösung aufzeigt. In späteren Zyklen müssen die zu diesem Zeitpunkt beschlossenen oder bereits realisierten ITSysteme und integrierten Lösungen zu eben jenen Randbedingungen gezählt werden. Das Lastenheft ist das unternehmenseigene Pendant zum Pflichtenheft. Letzteres wird im Gegensatz zum Lastenheft vom potentiellen Auftragnehmer – dies werden in der Regel Systemlieferanten sein – erstellt. Das Lastenheft beinhaltet die Gesamtheit der Forderungen des Auftraggebers und beschreibt neben dem heutigen Stand auch zukünftige Ziele in Bezug auf technische, wirtschaftliche und organisatorische Erwartungen.

Abb. 4-7: PLM-Requirement Management

4.3 Phase „PLM Requirement Management” 67

Schon bei der Erstellung eines Lastenhefts sind quantifizierbare und prüfbare Forderungen von Vorteil, andernfalls können diese vom Systemlieferanten im Pflichtenheft detailliert oder quantifiziert werden. Dieses letztgenannte Vorgehen kann – um innovative Lösungsvorschläge vom Lieferanten einzuholen – ein gewolltes Verfahren sein. In der Regel sollte der Auftraggeber jedoch darauf achten, dass das Lastenheft eindeutig, aber produktneutral geschrieben wird, das heißt, dass nicht ein spezielles Software-Paket die Anforderungen eines Unternehmens prägen sollte. Dasselbe gilt für den Einbezug eines externen Dienstleisters. Das Hinzuziehen externer Dienstleister kann durchaus sinnvoll sein, um auf Erfahrungen dieser aufbauen zu können. Jedoch ist darauf zu achten, dass sie neutral ohne Fixierung auf eine bestimmte IT-Lösung ausgerichtet sind. Weitere Informationen zum Thema Einbezug externer Dienstleister enthält das Leitheft „Externe Dienstleister einbinden“ (siehe Abschnitt 5.14). 4.3.1 Analyse zur Leistungsbeschreibung Um dem Ziel einer Leistungsbeschreibung näher zu kommen, sind die im Abschnitt zuvor genannten Inhalte durch die Hinweise aus den Leitheften zu erstellen. Bevor hiermit begonnen werden kann, ist es durchaus sinnvoll, zu prüfen, ob die Voraussetzungen, die in den jeweiligen Leitheften gefordert werden, für das entsprechende Thema erfüllt sind. Die Voraussetzungen werden im ersten Unterkapitel jedes Leitheftes erörtert. Zudem verschafft das schematische Übersichtsbild in dem jeweiligen Leitheft einen schnellen Überblick über die Abhängigkeiten und Querbezüge der PLM-Aspekte. Dies ist unter Berücksichtigung der PLM-Vision notwendig, um widersprechende Anforderungen unterschiedlicher PLM-Aspekte rechtzeitig zu erkennen. Sind alle geforderten Vorraussetzungen abgesichert, kann mit der Beschreibung des heutigen Standes im Rahmen der PLM-Aspekte begonnen werden, die laut Maturity-Modell untersucht werden sollen. Wie detailliert die Beschreibungen zum Ist-Stande ausfallen sollten, wird in den Abschnitten „Vorgehensweise“ in den jeweiligen Pflichtenheften erörtert. Mit der Anzahl der Durchläufe des Vorgehensmodells entwickelt sich ein immer detaillierteres Unternehmensmodell im PLM-Manifest, das als Grundlage zur Beschreibung des Ist-Standes herangezogen wird. Im Gegenzug wird das PLM-Manifest wiederum um neue bzw. aktualisierte Konzepte ergänzt. Mit den Ist-Modellen wird der aktuelle Stand durchleuchtet. Hierdurch wird eine Restrukturierung der bestehenden Prozesse unter Einbezug der neuen, durch das PLM entstandenen, Potentiale erleichtert. Dieses

68

4 Evolutionäres Vorgehensmodell

Reengineering stellt sich häufig sehr problematisch dar, weil die mit dem Reengineering beauftragten Mitarbeiter in der Regel keine ausreichend detaillierte Kenntnis über die Möglichkeiten von PLM haben. Der Einbezug von Externen, nicht „Betriebsblinden“ wie beispielsweise Beratern und anderen Experten, zur Analyse und Optimierung ist häufig unausweichlich. Es ist jedoch unbedingt darauf zu achten, dass im Unternehmen PLM-Wissen aufgebaut und gepflegt wird. Die zielgerichteten Anforderungen der jeweiligen PLM-Aspekte werden in den Mittelteilen der Leithefte beschrieben. Zudem wird in den Leitheften im hinteren Teil weiterführende Literatur aufgeführt, die das angesprochene Thema weiter zu vertiefen erlaubt. 4.3.2 Planung der Ressourcen Ein wesentlicher Aspekt des PLM-Requirements sind die zur Verfügung stehenden Ressourcen. Zu diesen zählen neben Sachmitteln und Mitarbeitern, die IT-Infrastruktur sowie feststehende IT-Tools und zwar immer unter Berücksichtigung des zeitlichen Horizonts. Die benötigten Ressourcen lassen sich in zwei verschiedene Kategorien einteilen: x Einmaliger Bedarf: Hierzu zählen Aufwendungen für die Einführung und Planung. Es muss für das jeweilige Teilprojekt ein Projektteam gebildet werden, das nach Möglichkeit aus unterschiedlichen Fachdisziplinen zusammengesetzt ist. Es muss eine IT-Infrastruktur aufgebaut werden. Dazu müssen die erforderlichen Lizenzen erworben und Schulungen finanziert werden. Störungen im betrieblichen Ablauf während der Einführung müssen ebenfalls berücksichtigt werden. Eventuell muss zusätzlich externe Dienstleistung finanziert werden. x Laufender Bedarf: Zu den Betriebskosten zählen alle Kosten, die nach der Inbetriebnahme anfallen. Hierzu zählen u.a. Betriebskosten, Wartungskosten, Kosten für Verwaltung, Pflege und Backup. Informationen zu den benötigten Ressourcen finden sich nach Möglichkeit in den letzten Abschnitten der Leithefte, sofern das entsprechende Leitheft über ein Abschnitt zur Einführung verfügt. Wird dem aufgeführten Bedarf beider Kategorien die Einsparung, die der jeweilige PLM-Aspekt bringen wird, gegenübergestellt, kann eine Wirtschaftlichkeitsbetrachtung aufgestellt werden. Um die Einsparungen zu ermitteln, werden alle Kosten, die

4.3 Phase „PLM Requirement Management” 69

ohne PLM anfallen würden, aufgeführt und den erwarteten Kosten mit PLM gegenübergestellt. Mit dieser Vorgehensweise wird jeder PLM-Aspekt zunächst einzeln betrachtet. Querbeziehungen zu anderen PLM-Aspekten und indirekter Nutzen bleiben unberücksichtigt. Stellt sich bei der Planung heraus, dass nicht ausreichend Ressourcen verfügbar sind und dies nicht zu ändern ist, muss die Zielsetzung entsprechend an die Ressourcenlage angepasst werden. Eine detaillierte Erläuterung zu einer Kosten-/Nutzenanalyse findet sich im Abschnitt 5.15 „Betriebswirtschaftlichen Erfolg der PLMEinführung nachweisen“. 4.3.3 Erstellung der Leistungsbeschreibung Das Lastenheft ist Grundlage zur Projektvergabe und zwar unabhängig davon, ob der potentielle Auftragsempfänger ein internes Team oder ein externer Lieferant ist. Werden in dem zu behandelnden Lastenheft konzeptionelle Aufgaben verfolgt, wird der Auftragsempfänger in einem internen Team zu finden sein. Wird im aktuellen Lastenheft eine Systemeinführung fokussiert, wird der Projektpartner ein externes Unternehmen sein. Für das prinzipielle Vorgehen ist dies jedoch nicht weiter von Bedeutung. Mit dem Lastenheft wird beschrieben, was das Unternehmen will und nicht wie dies umgesetzt wird. Das Lastenheft beschreibt ein Konzept und ist nicht an eine Software angelehnt und ist dementsprechend zu strukturieren. Alle Vorgänge und Strukturen sollten möglichst formal mit Modellen beschrieben werden. Zu beschreiben sind alle Ergebnisse des PLMRequirement-Managements. Diese können grob in fünf Kategorien eingeteilt werden. Die Einteilung ist an die VDI 2219 angelehnt, die die Einführung eines PDM-Systems beschreibt. Die VDI 2219 kategorisiert Anforderungen wie folgt: x x x x x

strategische Anforderungen funktionsbezogene Anforderungen technisch-organisatorische Anforderungen mengenbezogene Anforderungen ergonomische Anforderungen

Die strategischen Anforderungen beschreiben Ziele, denen implizit mit der Auftragsvergabe näher gekommen werden soll. Hier sind beispielsweise die ISO 9000-Zertifizierung oder Sachmerkmalleisten entsprechend der DIN 4000 zu nennen, aber auch Aspekte zur langfristigen Bindung an einen Systemlieferanten sind dieser Kategorie zuzuordnen. Den Kern des

70

4 Evolutionäres Vorgehensmodell

Lastenhefts bilden die funktionsbezogenen Anforderungen. Hier wird ein Großteil der Ergebnisse der Konzeptphase festgehalten. Das Motto „Modelle sagen mehr als 1000 Worte“ gilt in dieser Kategorie ganz besonders. Beschrieben werden alle Datenmodelle, Abläufe, Projektstrukturen und Prozesse. Zu den technisch-organisatorischen Anforderungen gehören allgemeine Aussagen zur Anzahl erwarteter User und Lizenzen sowie beispielsweise Anforderungen an Antwortzeiten. Auch die Eingliederung der neuen Software in die Unternehmens-IT, vorgeschriebene Hardwareplattformen und andere Rahmenanforderungen, wie beispielsweise die Infrastruktur, eine bevorzugte Architektur (z.B. Client-Server-Architektur) oder im PLMManifest bereits festgeschriebene Softwaresysteme sind dieser Kategorie zuzuordnen. Die mengenbezogenen Anforderungen beinhalten alle übrigen eindeutig quantifizierbaren Anforderungen, wie zum Beispiel zu erwartende Datenmengen. Zu den ergonomischen Anforderungen gehören Anforderungen zur Gestaltung der Benutzeroberfläche. Des Weiteren wird im Lastenheft der angestrebte Projektverlauf mit einem zeitlichen Horizont geschildert. Hierunter fällt beispielsweise die Forderung nach einem Pflichtenheft. Ist das Lastenheft erstellt und richtet es sich an externe Anbieter, sollte es zur Angebotseinholung an verschiedene, in Frage kommenden Anbietern versendet werden. Die VDI 2219 schlägt vor, dieses auf drei Anbieter zu beschränken. Auf Basis des Lastenheftes wird der Lieferant ein Angebot in Form eines Pflichtenhefts erstellen. Diese Dokumente sind alle dem PLM-Manifest zuzuführen und in dessen Ebenen einzuordnen. Das Lastenheft ist in der Regel vorwiegend der Ebene des Fachkonzepts zuzuschreiben, wohingegen das Pflichtenheft bereits Lösungen beinhalten kann, die dem DV-Konzept zuzuordnen sind (siehe Abschnitt 3.2.1). Bei der Systemauswahl ist zu beachten, dass das Unternehmen mit einem Systementscheid in der Regel eine langfristige Bindung mit einem Systemlieferanten eingeht.

4.4 Phase „PLM Solution Design“ 71

4.4

Phase „PLM Solution Design“

Ziel dieser Phase ist die Abstimmung zwischen dem Unternehmen als Auftraggeber und einem Projektpartner, dem Auftragnehmer (siehe Abb. 4-8). Dies wird in den meisten Fällen ein Systemlieferant oder eine interne ITAbteilung sein. Dokumentiert wird diese Abstimmung durch ein Pflichtenheft, das alle Leistungen beschreibt, die aus Sicht des Auftragnehmers erbracht werden müssen. Das gelieferte Produkt wird später an den Angaben aus dem Pflichtenheft gemessen (siehe Leitheft „Externe Dienstleister einbinden“, Abschnitt 5.14). Das Unternehmen sollte sich auf Basis des Lastenheftes von mehreren potentiellen Projektpartnern Pflichtenhefte erstellen lassen, um auf deren Basis den zukünftigen Projektpartner zu bestimmen. Dieser Punkt entfällt, wenn gegebenenfalls eine Systementscheidung schon vorausgegangen ist. Beispielsweise ist dies dann der Fall, wenn ein bestehendes System ausgebaut wird. Hier muss der entsprechende Systemlieferant ein erweitertes Pflichtenheft – abgestimmt auf die neuen Anforderungen – erstellen.

Abb. 4-8: PLM Solution Design

72

4 Evolutionäres Vorgehensmodell

4.4.1 Anforderungen an das Pflichtenheft Die Erstellung des Pflichtenhefts obliegt ausschließlich dem Auftragnehmer und stellt die Antwort auf das Lastenheft dar. Es sollte Lösungen für alle Anforderungen aufzeigen. Das auftraggebende Unternehmen sollte jedoch klare Vorstellungen von Inhalt und Struktur des Pflichtenheftes haben und diese bei der Ausschreibung zum Ausdruck bringen. Nur so können die unterschiedlichen Pflichtenhefte objektiv beurteilt werden. Schon während der Pflichtenhefterstellung sollte es zu einer engen Zusammenarbeit zwischen Unternehmen und potentiellen Auftragnehmern kommen. Nur durch diese enge Zusammenarbeit beispielsweise in Form von Workshops, kann eine hohe Qualität des Pflichtenheftes erreicht werden. Es ist durchaus möglich, das Pflichtenheft in verschiedenen Phasen mit unterschiedlichen Detaillierungsstufen erstellen zu lassen, um nach jeder Phase die Menge der potentiellen Systemlieferanten einzugrenzen. Dieses Vorgehen wird gewählt, wenn die Erstellung umfangreicher Pflichtenhefte mit Kosten verbunden ist. Wird nicht auf ein individuell erstelltes Pflichtenheft Wert gelegt oder ist das Unternehmen nicht bereit, Kosten für die Pflichtenhefterstellung zu tragen, kann es schnell dazu kommen, dass der Systemlieferant ausschließlich eigene standardisierte Pflichtenhefte auf Basis unzureichender Fragebögen erstellt. Solche Pflichtenhefte haben oft nur wenig mit der Ausschreibung gemeinsam. Individuelle Anforderungen, die jedes Unternehmen hat, bleiben oftmals unberücksichtigt. Das Pflichtenheft sollte dagegen folgende Bereiche abdecken: x Beschreibung der Unternehmenscharakteristik: Hier muss die Unternehmenscharakteristik beschrieben sein. Dies ist wichtig, um zu erkennen, wie der Systemlieferant das jeweilige Unternehmen sieht. x Ist-Zustand des geplanten Einsatzgebietes: Der zukünftige Auftragnehmer sollte im Pflichtenheft schildern, wie er auf Basis seines Wissens das Unternehmen bezüglich PLM einstuft. x Zielsetzung: Im Weiteren sollte der Systemlieferant nochmals seine Auffassung der Zielsetzung präzisieren und darstellen. x Fachkonzept: Im fachlichen Bereich zeigt der Auftragnehmer, wie er die aufgeführten Anforderungen lösen wird. Es wird beschrieben, wie der Anwender zukünftig durch das System unterstützt wird. Dies ist der Schwerpunkt des Pflichtenheftes.

4.4 Phase „PLM Solution Design“ 73

x Technische Lösungen: Die technischen Lösungen gehen auf die Anforderungen der ITAbteilungen ein. Hier werden Ausfallsicherheiten, Zugriffsschutz etc. gewährleistet. Der Systemlieferant macht Angaben zur benötigten ITInfrastruktur (Hardware) und sichert eine Form der Lizenzvergabe mit einer entsprechenden Anzahl von Lizenzen zu. x Sonstiges: Sind mit diesen Punkten nicht alle Anforderungen aus dem Lastenheft beantwortet worden, ist dies noch unabhängig von der obigen Einteilung zu tun. Enthalten die in engere Auswahl kommenden IT-Systeme ihrerseits Funktionen, die für das Unternehmen sinnvoll sein können, bisher jedoch nicht berücksichtigt wurden, sollten diese mit ins Pflichtenheft aufgenommen werden. Hier ist jedoch auch darauf zu achten, dass diese Funktionen zudem ins Gesamtkonzept übernommen werden und gegebenenfalls auf Überschneidungen mit anderen PLM-Aspekten überprüft werden. So ergänzen sich hierdurch die prozessualen Anforderungen des Auftraggebers mit den Stärken und Erfahrungen der Systemanbieter. Jedoch ist an dieser Stelle unbedingt darauf zu achten, dass das Unternehmen die Richtung vorgibt und nicht die Unternehmensabläufe an die Werkzeuge der Systemanbieter angepasst werden. Dieses aus dem ERP-Umfeld bekannte Vorgehen wird sich nicht in das PLM-Umfeld übertragen lassen, da die Entwicklungsabläufe der Unternehmen in Abhängigkeit von den Endprodukten eine viel höhere Individualität als betriebswirtschaftliche Abläufe aufweisen. Mit dem Pflichtenheft müssen zudem Verpflichtungen zum Einführungsprojekt geregelt werden. Hierzu zählt ein zeitlicher Rahmen, Ortsgebundenheit, Angaben zur Einführung mit Tests und die Verpflichtung einer umfangreichen Dokumentation. Um das Pflichtenheft nicht zu einseitig zu gestalten, sollte darauf geachtet werden, dass es von unterschiedlichen Fachleuten geschrieben wird. Das verabschiedete Pflichtenheft ist Teil des DV-Konzepts und wird somit ins PLM-Manifest eingebunden. 4.4.2 Lieferantenauswahl Eine Lieferantenauswahl findet in mehreren Schritten statt. Wie schon in vorigen Abschnitten angesprochen, soll das Lastenheft unterschiedlichen Systemlieferanten zur Verfügung gestellt werden, die auf Basis des Lastenhefts ein oben beschriebenes Pflichtenheft erstellen. Mehrere Detaillierungsphasen sollten im Pflichtenheft zur Nachvollziehbarkeit des Ange-

74

4 Evolutionäres Vorgehensmodell

bots gefordert werden. Der vorangegangene Auswahlprozess – wie schon erwähnt – sollte sich auf maximal drei potentielle Systemlieferanten beschränken. Eine erste Vorauswahl von Systemlieferanten kann mit Hilfe der Systemevaluation (siehe Abschnitt 5.10), Internetrecherchen oder mit einschlägigen Fachzeitschriften, in denen jährlich bekannte Systeme mit ihren Stärken und Schwächen verglichen werden, durch das Unternehmen durchgeführt werden. Dieser Punkt kann u.a. auch vollständig von erfahrenen Unternehmensberatern durchgeführt werden oder die Durchführung wird durch solche Experten unterstützt. Sollte der Systemlieferant aufgrund von vorhergehenden Projekten bereits feststehen, wird dennoch zunächst gleich verfahren. Dadurch wird eine größere Unabhängigkeit des Unternehmens vom Systemlieferanten erreicht. Nach Empfang der Pflichtenhefte der ersten Phase werden die Dokumente gesichtet und ein Systemlieferant aufgrund des Überdeckungsgrades der geforderten Anforderungen und betriebswirtschaftlicher Kriterien priorisiert (siehe Abschnitt 5.15.5). Die Prüfung der Pflichtenhefte kann wiederum mit Unterstützung eines Unternehmensberaters erfolgen. Dieser Lieferant wird dann in der Regel zu einer weiteren Detaillierung des Pflichtenheftes aufgefordert. Bei dieser Vorauswahl ist zu beachten, dass sich das Unternehmen in der Regel lange an den Systemlieferanten bindet. Daher sollte das Unternehmensportfolio des zukünftigen Auftragnehmers mitberücksichtigt werden. Es müssen Fragen zur Zukunftsperspektive des Systemlieferanten geklärt sein. Beispielsweise sollte das Unternehmen groß genug sein, um Engpässe wirtschaftlich überstehen zu können. Die Entwicklungsabteilung des Anbieters sollte in der Lage sein, neue Technologien in zukünftigen Softwareständen zu berücksichtigen. Ist ein Pflichtenheft zur Zufriedenheit des Auftraggebers erstellt, kann ein Vertragsabschluss vorgenommen werden. Das Pflichtenheft enthält vom Auftraggeber verbindliche und gegengezeichnete Vorgaben und eine Beschreibung aller Leistungen, die der Systemanbieter erbringen muss. So ist das Pflichtenheft Vertragsbestandteil, an dem das gelieferte Produkt gemessen wird. Werden später Nachbesserungen verlangt, die nicht mit dem Pflichtenheft begründbar sind, entstehen entsprechende Zusatzkosten. Daher kommt der Vollständigkeit des Pflichtenheftes eine sehr große Bedeutung zu. An dieser Stelle sei nochmals an das Leitheft „Externe Dienstleister einbinden“ verwiesen (siehe Abschnitt 5.14).

4.5 Phase „Implementation & Integration“ 75

4.5

Phase „Implementation & Integration“

Mit der Phase „Implementation & Integration“ erfolgt eine Umsetzung der in den vorigen Phasen erarbeiteten Zielsetzung eines Spiraldurchlaufes (siehe Abb. 4-9). Je nach Inhalt der Zielsetzung kann sich die Umsetzung verschieden darstellen. Das Spannungsfeld reicht von einzelnen Analysetätigkeiten, Vorarbeiten für spätere Spiraldurchläufe, bis hin zu Systemumsetzungen. Jedoch bleiben trotz der unterschiedlichen Zielsetzungen die elementaren Vorgehensschritte in dieser Phase die Selben. Nach der eigentlichen Realisierung einer PLM-Lösung, muss diese gegebenenfalls an das Unternehmen angepasst werden. Bevor nun die eigentliche Umsetzung stattfinden kann, ist durch eine ausgeprägte Phase des Verifizierens die Erfüllung aller Anforderungen in ausreichender Qualität sicherzustellen. Ein abschließendes Review darf nicht fehlen. Diese fünf Schritte werden im Folgenden näher vorgestellt. Der Fokus in diesen Abschnitten wird primär auf eine Umsetzung in Form einer System-Einführung liegen. Gleichwohl lassen sich diese Konzepte auf andere Zielsetzungen übertragen. Mit der Umsetzung wird sich die angestrebte Lösung erstmals im Unternehmen beweisen müssen. Vom Erfolg der Umsetzung hängt die Zukunft des PLMs im Unternehmen ab. Daher ist dies die kritische Phase des PLM-Vorgehensmodells. Dem Risiko dieser Phase kann nur durch eine möglichst sorgfältige und systematische Durchführung der ersten Phasen entgegengewirkt werden.

Abb. 4-9: „Implementation & Integration“

76

4 Evolutionäres Vorgehensmodell

Die Umsetzung erfolgt strikt nach den Vorgaben aus dem Pflichtenheft, auf dessen Einhaltung das Unternehmen kontinuierlich achten sollte. Eine Prüfung nach abgeschlossener Einführung ist in vielen Fällen zu spät. Sämtliche Abweichungen zum Pflichtenheft sind in der Regel mit einer exponentiellen Kostenexplosion verbunden. 4.5.1 Realisierung Der erste Schritt zur Zielerreichung ist die Realisierung meist in Form einer technischen Ausarbeitung. Für eine effiziente und zielführende Vorgehensweise während der Realisierung müssen zunächst einige Umstände geklärt werden. Zum einen spielt das im vorigen Abschnitt angesprochene Spannungsfeld eine wichtige Rolle, zum anderen die Aufgabenverteilung während der Realisierung, die nicht seltenen von externen Unternehmen durchgeführt wird. Dies wird vor allem dann der Fall sein, wenn die Zielsetzung mit einer Systemeinführung auf Basis einer StandardsoftwareLösung erreicht werden soll. In sämtlichen Fällen ist jedoch das Ziel dieser Phase eine technische Realisierung der Anforderungen der vorherigen Phasen. Hierbei sind insbesondere die bestehenden Strukturen zu berücksichtigen, da eine Realisierung in der Regel nicht auf „einer grünen Wiese“ erfolgt. Spätestens nach einem zweiten Spiraldurchlauf kann dies nicht mehr der Fall sein. Liegen schon entsprechende Dokumentationen im PLM-Manifest vor, erleichtert dies die Berücksichtigung ungemein. Elementar für eine erfolgreiche Realisierung, gerade auch in Hinblick auf den späteren Validierungsschritt, ist eine eindeutige Rollenverteilung während der Realisierung. Analog zur vorigen Phase wird in der Herangehensweise nicht unterschieden, ob der Auftragnehmer einer Interner oder Externer ist. Findet die Realisierung im eigenen Unternehmen statt, liegt diese Rolle in der Hand der operativen IT-Organisationseinheiten, den Pflichtenhefterstellern. In der Regel wird dies jedoch ein externes Unternehmen sein. Dem gegenüber steht der Auftraggeber, der im PLM-Stab zu finden ist. Die eindeutige Trennung der Rollen ist aufgrund einer klaren Differenzierung zwischen anforderungsstellenden und erfüllenden Aufgaben wichtig, um später das System anhand der Anforderungen validieren zu können. Parallel zu der reinen Realisierung treten weitere Nebentätigkeiten auf, die Fragen zur Einbindung in das Unternehmen betreffen. An dieser Stelle sollen nur drei Beispiele genannt werden, um das Bewusstsein für dieses Thema zu schärfen. Als erstes Beispiel soll die Frage zur Übernahme von Altdaten (Migrieren) genannt werden. Welche Daten sollen in ein neues

4.5 Phase „Implementation & Integration“ 77

System übernommen werden? Eine pauschale Übernahme aller Daten rentiert sich in der Regel nicht. Gerade in Anbetracht der Tatsache, dass häufig ein Großteil der Daten noch nicht digital vorliegt, wird eine Übernahme von Altdaten häufig sehr teuer. Daher sollte sich ein Unternehmen auf die Daten beschränken, für die die Wahrscheinlichkeit der Wiederverwendung als hoch einzustufen ist. Erfahrungswerte liegen hier bei ca. 15- 20% der Altdaten. Diese Problematik wird noch einmal im Leitheft „Dokumente sicher verfügbar machen“ aufgegriffen (siehe Abschnitt 5.3). Ein weiteres Problem könnten Eingriffe in bestehende Prozessabläufe und in die Arbeitsweise mit sich bringen, wenn diese unter Umständen vom Betriebsrat genehmigungspflichtig sind. Daher sollte hier ein Einbezug rechtzeitig stattfinden. Und nicht zuletzt sollte als Beispiel die Berücksichtigung der späteren Anwender genannt werden, die auf die Umstellung durch ausreichende Informationen und umfangreiche Schulungen rechtzeitig vorbereitet werden sollten. Die Realisierung ist wiederum genau zu dokumentieren und dem PLMManifest zuzuführen. Es ist nicht damit getan, dass beispielsweise der Quellcode unkommentiert hinterlegt wird. Um in einer gewissen Weise unabhängig von den Systemlieferanten zu bleiben, muss zumindest eine Dokumentation in der Ebene DV-Konzept nach dem eingeführten drei stufigen Modellierungskonzept des PLM-Manifests – wie sie im Abschnitt 3.2.1 beschrieben wurden – berücksichtigt werden. Nur so kann einem problembehafteten Veralten der PLM-Lösung entgegen gewirkt werden. Hinweise in den jeweiligen Leitheften sollten berücksichtigt werden. 4.5.2 Customizing Unter Customizing wird das Anpassen einer Standard-Software an die spezifischen Gegebenheiten eines Unternehmens verstanden. Demnach ist dieser Abschnitt nur für Zielerreichungen notwendig, die sich auf SystemLösungen beziehen. Unterschieden werden verschiedene Stufen des Customizing: x administrative Ebene x logische Ebene x funktionale Ebene Zur administrativen Ebene gehören alle Einstellungen, die im Programm zur Benutzerverwaltung und -organisation verwendet werden und alle grundlegenden Einstellungen. In der logischen Ebene sollten Prozessmuster, Metamodelle für Produkte, Status, Sachmerkmalleisten, Regeln,

78

4 Evolutionäres Vorgehensmodell

Nummernlogik etc. angelegt werden können. Hierfür sollte die Software nach Möglichkeit grafische Werkzeuge oder übersichtliche Eingabemasken bereitstellen. Eine andere Möglichkeit sind Scriptsprachen. Sie sind nicht so anwenderfreundlich, jedoch durchaus üblich. Unter der funktionalen Ebene werden Eingriffe in die Systemfunktionen verstanden, mit der gewünschte Zusatzfunktionalität realisiert oder bestehende Funktionen abgewandelt werden. Die funktionale Ebene geht häufig mit einem Eingriff in das Datenmodell des Systems und den Quellcode der Software einher. Dies stellt ein komplexes und kompliziertes Unterfangen dar und sollte – wenn möglich – vermieden werden. Anzustreben sind Lösungen und Systeme, die von Haus aus anwendernahes Customizing auf der logischen Ebene vorsehen, sodass ein ausgeprägtes Customizing systemgestützt erfolgen kann. Der Grund für diese Forderung liegt in der eingeschränkten Releasefähigkeit von Systemen, die auf Basis eines Code-Eingriffes angepasst werden. Hinzu kommt, dass ein Customizing auf dieser Ebene in der Regel sehr aufwendig und somit teuer ist. Wichtig ist wiederum die Frage, was sollte das Unternehmen selbst bewerkstelligen können bzw. sollen und was sollte an externe Partner vergeben werden. Bei einer externen Vergabe besteht das Risiko, dass nachträgliche Änderungen nur durch Fremdaufträge durchgeführt werden können, und dies ist in Anbetracht eines dynamischen Unternehmens mit häufigeren Änderungen nicht wünschenswert. Empfehlenswert ist, dass zumindest die administrative und logische Ebene durch das Unternehmen selbst im System angepasst werden können. Hierfür gilt es, entsprechendes Know-how im Unternehmen aufzubauen. Nur die Erstanpassung sollte zusammen mit dem Softwarehaus erfolgen. Auch für das Customizing ist eine ausführliche und möglichst formale Dokumentation aller Anpassungen zwingend erforderlich und in das PLM-Manifest zu integrieren (siehe Abschnitt 5.10.4). 4.5.3 Verifizieren Ist die Realisierung einschließlich des Customizings abgeschlossen, folgt in mehreren Schritten eine umfangreiche Überprüfung, ob die erarbeitete Lösung den Anforderungen entspricht. Damit ist dieser Schritt das effektivste Mittel, um späteren Beanstandungen und Todzeiten vorzubeugen. Beanstandungen nach der Abnahme sind wesentlich schwieriger durchzusetzen. Die Durchführung dieses Schrittes ist unabhängig von der Art der Lösung. Eine Analyse kann genauso wie eine Systemimplementierung auf-

4.5 Phase „Implementation & Integration“ 79

grund der gestellten Anforderungen verifiziert werden. In beiden Fällen sind die gleichen grundsätzlichen Regeln zu beachten. Beispielsweise darf ein Test bzw. eine Überprüfung nicht von den gleichen Personen ausgeführt werden, die für die Umsetzung verantwortlich waren. Handelt es sich bei der PLM-Lösung um eine Systemeinführung einer Standardsoftware-Lösung, sollte das Unternehmen schon auf umfangreiche Tests beim Systemlieferanten mit entsprechender Dokumentation bestehen, um die Grundfunktionalität abzusichern. Ist die Grundfunktionalität abgesichert, sollte eine weitere Testphase im Unternehmen selbst durchgeführt werden. Für die Testphase empfiehlt es sich, zunächst eine geeignete Testumgebung mit entsprechenden Testdaten anstelle der Produktivumgebung einzurichten, um den laufenden Betrieb nicht unnötig zu stören. Erst im zweiten Schritt sollte die Testphase auf den gesamten Betrieb ausgebaut werden. In verschiedenen Anwendungs- und Fehlerszenarien wird die Stabilität der Implementierung auf die Probe gestellt. Zu den Szenarien zählen beispielsweise Ausfälle bestimmter Systeme oder des Netzwerkes, Fehleingaben etc. Ausgedehnt auf das gesamte Unternehmen wird schließlich noch die Belastung des Systems getestet und das System einem Langzeittest unterzogen. 4.5.4 Umsetzung Ist die PLM-Lösung ausreichend verifiziert, kann mit der Umsetzung begonnen werden. Wiederum am Beispiel einer System-Implementierung bedeutet dies eine Inbetriebnahme des Systems in seiner produktiven Umgebung. Mit der Inbetriebnahme werden die bisherigen Systeme und die bisherige Arbeitsweise mit einer vereinbarten Übergangszeit abgelöst. Diese Übergangszeit dient zugleich als erweiterte Testphase. Die Übergangszeit kann in verschiedenen Phasen erfolgen. Für eine erste Aufbaustufe gilt es, besonders engagierte und dem neuen Konzept aufgeschlossene Mitarbeiter in die Umsetzung in Form einer Pilotanwendung einzubeziehen. Dies fördert die Akzeptanz im Unternehmen und die Erfahrungen der Mitarbeiter können zu diesem Zeitpunkt noch in die Umsetzung aufgenommen werden. Hierzu sind auch umfangreiche Schulungen der Mitarbeiter notwendig, die bereits parallel zur Entwicklung der Lösung stattfinden sollten. Es empfiehlt sich die endgültige Abnahme erst nach dieser Übergangszeit durchzuführen. Mit Ende der Übergangszeit werden alle alten Systeme, die im Rahmen der neuen PLM-Lösung keine Anwendung mehr finden, außer Betrieb genommen bzw. zumindest gesperrt. Denn nur so wird

80

4 Evolutionäres Vorgehensmodell

eine konsequente Umstellung auf ein neues System erreicht. Mit der Inbetriebnahme sollten erweiterte Mitarbeiterschulungen durchgeführt werden und der Anwenderkreis systematisch erweitert werden. 4.5.5 Review Abgeschlossen wird die Implementierungsphase und somit das ganze Projekt mit einem Review. Verglichen und dokumentiert werden die Ergebnisse der einzelnen Phasen, sodass ein Fortschrittsprotokoll für das ganze Projekt entsteht. Auch findet nun nochmals explizit ein Abgleich bzw. eine Erweiterung der PLM-Vision statt. Hierzu bietet sich die erneute Bewertung auf Basis des Maturity-Modells an. Das Feedback der Mitarbeiter ist an dieser Stelle nicht zu unterschätzen. Viele PLM-Projekte, auch von Großunternehmen, sind schon an der fehlenden Akzeptanz gescheitert.

5 Leithefte zu PLM-Aspekten

Abb. 5-1: Leithefte

Dieses Kapitel beinhaltet die einzelnen Leithefte, in denen die grundlegenden PLM-Aspekte diskutiert werden (siehe Abb. 5-1). Sie sind bei Bedarf an den entsprechenden Punkten in den Ablauf des evolutionären Vorgehensmodells einzubeziehen. Die Orientierung innerhalb der Leithefte wird durch einen vereinheitlichten Aufbau unterstützt. Jedes Leitheft beginnt mit einer einseitigen Zusammenfassung, die gebündelt den Inhalt des jeweiligen Themas motiviert. Es soll zugleich für unternehmensinterne Präsentations- und Diskussionszwecke als Management-Abstract dienen. Dem Abstract folgt eine Einordnung des Leitheftthemas in den gesamten PLM-Themenkomplex. Dieser Einordnung sind Abhängigkeiten zwischen den einzelnen Themenfeldern einerseits und Voraussetzungen für die jeweilige Thematik andererseits zu entnehmen. Hierauf folgt der Kern des Leitheftes, je nach Komplexitätsgrad gegebenenfalls aufgeteilt in weitere Unterkapitel. Der Kern des Leithefts beginnt üblicherweise mit dem Bezug des jeweiligen Themas zu PLM bei mittelständischen Unternehmen, da viele der vorgestellten Themen nicht ausschließlich im PLM-Kontext zur Anwendung kommen. In den nächsten Abschnitten wird dann ein allgemeiner Überblick über die Thematik gegeben und auf die Besonderheiten im PLM-Kontext hingewiesen. Ergänzt wird der inhaltliche Teil mit Tipps zur Vorgehensweise bei der Einführung der Thematik. Abschließend werden Beispiele, Arbeitsmaterialien, Normen und Standards, Checklisten und weiterführende Literatur aufgeführt.

V. Arnold et al., Product Lifecycle Management beherrschen, 2. Aufl., DOI 10.1007/978-3-642-21813-2_5, © Springer-Verlag Berlin Heidelberg 2011

82

5.1

5 Leithefte zu PLM-Aspekten

Evolution der Produkte organisieren

Configmgnt. (engl.) Æ Sichtenmgnt. Æ Dokumentenmgnt. Ein Produkt ist in der Regel kein starres Gebilde. Ganz im Gegenteil ist es während seines Produktlebenszykluses mannigfaltigen Änderungen unterworfen oder muss schnell und flexibel an die Bedürfnisse des Marktes oder der Kunden anpassbar sein. Entsprechend diesen Anforderungen werden viele Produkte nicht nur in einer, sondern in mehreren Varianten angeboten. Im Extremfall verlangt der Markt, dass dem Kunden die Möglichkeit geboten wird, Produkte speziell für seine Anforderungen zu konfigurieren. Diese Varianten des Produktes besitzen ähnliche Strukturen, die sich lediglich in einigen Baugruppen oder Bauteilen unterscheiden. So sind – im Gegensatz zu den Versionen – Varianten zeitlich parallel gültige Produktbestandteile. Je mehr unterschiedliche Varianten eines Produktes vorhanden sind und je individueller ein Produkt an die Anforderungen des Nutzers angepasst werden kann, desto aufwendiger wird die Verwaltung der Informationen über diese Produktvariationen. Gleichfalls sind die Entwicklungen eines Produktes aufgrund von änderungsbasierten Überarbeitungen nachzuhalten, die zur Behebung von Schwächen des Produkts, Anpassung an neue Marktbedürfnisse oder zur Integration von Innovationen während der gesamten Lebensdauer eines Produktes durchgeführt werden. Die Vorhaltung der Informationen zu den im Laufe des Produktlebenszyklus (Abk. PLC) entstehenden Versionen bedeutet ebenfalls einen hohen Verwaltungsaufwand. Schlussendlich gilt es zu dokumentieren, welche Variationsmöglichkeit einem tatsächlich produzierten Produkt zu Grunde liegt und auf welcher Produktversion es basiert. Das Vorhalten dieser Konfigurationen führt zu einer weiteren Steigerung der Komplexität in der Verwaltung der Produktinformationen. Prinzipien und informationstechnische Lösungen zur Verwaltung von Versionen, Varianten und Konfigurationen eines Produktes werden üblicherweise im Kontext des Product Lifecycle Managements unter den Begriffen Versions-/Variantenmanagement oder. Konfigurationsmanagements zusammengefasst. Dabei wird im Variantenmanagement der Aufbau von auftragsneutralen Produktstrukturen mit den entsprechenden Variationsmöglichkeiten der Produkte organisiert. Mit Hilfe des Konfigurationsmanagements werden Produktbeschreibungen und Produktstrukturen verwaltet. Das Konfigurationsmanagement überwacht die Eigenschaften und Änderungen eines Produktes während seiner gesamten Lebensdauer bezogen auf die Versionen und Varianten. So stellt es die Transparenz und Konsistenz der Produktinformationen über den gesamten PLC hinweg her.

5.1 Evolution der Produkte organisieren 83

5.1.1 Konfigurationsmanagement Die nachfolgende Abbildung stellt einen Überblick über die wesentlichen Teilgebiete des Product Lifecycle Managements und deren Verbindungen untereinander dar (siehe Abb. 5-2). Das Versions- und Variantenmanagement sowie das Konfigurationsmanagement bauen auf dem Produktstrukturmanagement als Grundlage auf. Das Versionsmanagement ist zudem stark mit dem Freigabe- und Änderungsmanagement verbunden.

Abb. 5-2: Versionen-, Varianten- und Konfigurationsmanagement im PLM

84

5 Leithefte zu PLM-Aspekten

5.1.2 Management von Produktvarianten Varianten sind zeitlich parallel existierende, vergleichbare Ausprägungen des gleichen Erzeugnisses bzw. Ergebnisses und damit potentiell gegeneinander austauschbar. Nach DIN 199-1 sind Varianten „Gegenstände ähnlicher Form und/oder mit einem in der Regel hohen Anteil an identischen Baugruppen“. Eine Variante wird durch ein oder mehrere definierte Merkmale charakterisiert, die mit einem Wert belegt sind, der Merkmalsausprägung. Alternativ zu den Begriffen „Merkmal/Merkmalausprägung“ werden auch „Merkmalskategorie/Merkmal“, in der internationalen Produktdatennorm STEP „Specification Category/Specification“ oder in einigen Integrationssystemen „Option/Option Value“ verwendet. DIN 199-4 kategorisiert die Varianten nach dem Grund der Entstehung: x Kundenvarianten: d.h. Varianten, die vom Kunden gewählt bzw. auf dem Markt alternativ angeboten werden (z.B. Modellvarianten bei Fahrzeugen) x Herstellungsvarianten: d.h. Varianten von Bauteilen oder Baugruppen, die hinsichtlich Abmessungen, Einbaulage und Funktion (Form-Fit-Function) als gleichwertig anzusehen sind, jedoch alternativ verbaut werden können. (z.B. Motoren verschiedener Hersteller). Daher werden diese auch als Alternativen bezeichnet. Schichtel definiert die Alternative, die von keinem konkreten Anwendungsfall abhängt (Schichtel 2001) x Landesspezifische Variante: linksgelenkte Autos für den deutschen Markt, rechtsgelenkte Autos für den britischen Markt x Gesetzesspezifische Variante: H4 Lampen sind für PKW mit 60/55 Watt und für LKW mit 75/70 Watt Leistung ausgestattet x Mengenvarianten: d.h. in Abhängigkeit von bestimmten Parametern kann sich auch die Menge eines Teils oder einer Baugruppe (Vorkommensfaktor) in der Struktur ändern Besitzt ein Produkt mehrere Varianten, so lassen sich die Produktbestandteile nach ihrer unterschieden Verwendung in Sinne von optionalem, variablen oder notwendigen Einsatz in der Produktstruktur unterscheiden (Eigner u. Stelzer 2001). Bei einer Teilevariante sind ein oder mehrere Einzelteile in verschiedenen Ausprägungen vorhanden, die Produktstruktur ändert sich jedoch nicht. Im Gegensatz dazu unterscheiden sich Strukturvarianten in den Positionen der Einzelteile in der Produktstruktur. Die

5.1 Evolution der Produkte organisieren 85

Komponenten, aus denen eine Variantenstruktur aufgebaut wird, lassen sich dabei wie folgt beschreiben: x Muss-Komponenten: d.h. alternative Teile und Baugruppen, von denen immer eine Alternative gewählt werden muss x Kann-Komponenten: d.h. sog. Optionsbaugruppen, die in der Struktur ausgewählt werden können x Fest-Komponenten: d.h. Teile und Baugruppen, die immer in allen Variantenstrukturen vorkommen und damit festgeschrieben sind. Um Produktvarianten strukturell darzustellen, werden sog. Variantenstücklisten eingesetzt. Die Variantenstückliste ist eine Zusammenfassung mehrerer Stücklisten auf einem Vordruck, um verschiedene Gegenstände mit einem in der Regel hohen Anteil identischer Bestandteile gemeinsam aufführen zu können. Die Besonderheit in einer Variantenstückliste gegenüber einer herkömmlichen Strukturstückliste ist, dass an einer Stelle in der Produktstruktur mehrere Ausführungen einer Produktkomponente einsetzbar sein können. Ein mögliches Konzept zur Umsetzung, auf das an dieser Stelle verwiesen sei, sieht den Einsatz eines speziellen Elements vor, den Variantenplatzhalter, der in die Produktstruktur eingefügt wird. Der Variantenplatzhalter verweist auf eine Variantenliste mit möglichen alternativen Produktkomponenten, die diesen Platzhalter in einem konkreten Produkt ersetzen können. Von Variantenstücklisten wird daher gesprochen, wenn die Stückliste Variantenplatzhalter enthält. Für die Durchführung eines konkreten Produktions- oder Kundenauftrages werden dann aus der Variantenliste die benötigten Komponenten ausgewählt, um so das Produkt entsprechend den Anforderungen zu konfigurieren. Produkte oder Produktkomponenten werden zunächst variantenunabhängig entwickelt. Erst wenn eine Unterscheidung zwingend notwendig wird, findet eine Abspaltung eines Entwicklungspfades statt. Folglich lässt sich eine Variante immer einem Entwicklungspfad zuordnen. Hieraus folgt ein enger Zusammenhang zwischen Variante und Version. Oft werden in der täglichen Praxis Lösungen, d.h. Versionen selbst als Variante bezeichnet. Eine Unterscheidung zwischen Variante im Sinne der Aufgabenstellung und im Sinne einer Lösung zu einer Aufgabenstellung ist daher äußerst empfehlenswert (Schichtel 2001). Im Zuge der Verwaltung von Varianten lassen sich die Abhängigkeiten zwischen den Bauteilen der Varianten eines Produktes definieren und ver-

86

5 Leithefte zu PLM-Aspekten

walten. Mit Hilfe entsprechender Regeln lässt sich daraus die Konfiguration einer bestimmten Produktvariante einfacher und mit einem informationstechnisch unterstützten Regelwerk sogar automatisch bestimmen. Die Konfiguration beschreibt nach DIN 82045 die „Anordnung der Elemente eines Systems“ und repräsentiert damit eine konkrete, auftragsbezogene Produktbeschreibung, die durch die Auswahl der Komponenten der verschiedenen Varianten oder Versionen eines Produktes getroffen wurde. Bei einem konkreten Auftrag kann aus einer Produktstruktur mit Varianten die sog. Variantenausprägung erzeugt werden. Die Variantenausprägung ist immer auf einen Auftrag bezogen und stellt eine Struktur dar, in der alle Variantenplatzhalter durch konkrete Ausführungen (Komponenten) ersetzt sind. Im nachfolgenden Beispiel (siehe Abb. 5-3) kann der Variantenplatzhalter V1 durch die Baugruppen B4 und B5 ersetzt werden. Zusätzlich kann man entscheiden, ob das optionale Teil T4 in der konkreten Konfiguration verwendet werden soll. Die auftragsbezogene Ausprägung dieser Variantenstruktur enthält somit beispielsweise die Baugruppe B4 statt des Variantenplatzhalters und kein optionales Teil T4.

Abb. 5-3: Struktur einer Produktvariante

5.1 Evolution der Produkte organisieren 87

Die einzelnen Bauteile einer Variantenausprägung stehen miteinander oft in einem Zusammenhang. Integrationssysteme können solch eine regelbasierte Konfiguration unterstützen, indem ein Regelwerk mit Kombinationsverboten oder Kombinationszwängen definiert wird. Auf diese Weise werden unzulässige Kombinationen zwischen den Variantenausprägungen vermieden und zusätzlich wird der Konfigurationsaufwand verringert. 5.1.3 Management von Produktversionen Eine Version ist ein definierter Änderungszustand während des Lebenszykluses eines Produktes, einer Produktkomponente oder eines Dokumentes, der mit einer Versionsnummer oder mit einem Index eindeutig identifiziert wird. Versionen sind an einen Zeitstrahl gebunden, wodurch die zeitliche Abfolge von Versionen festgelegt ist, die als Versions- oder Entwicklungshistorie bezeichnet werden. So bestehen zwischen Versionen immer „Vorgänger-Nachfolger“ Beziehungen. Diese repräsentieren eine kontinuierliche Weiterentwicklung eines Produktes, basierend auf Verbesserungen oder erkannten Mängeln. Gerade in frühen Phasen der Produktentwicklung kann es zudem sinnvoll sein, mehrere Entwicklungsalternativen zu verfolgen, diese zu einem späteren Zeitpunkt zu bewerten und die höher bewertete Alternative schlussendlich zu verfolgen. Existiert ein solcher Entwicklungsprozess, bedeutet dies für die Verwaltung der Produkthistorie, dass zu einem bestimmten Zeitpunkt sich die Entwicklungshistorie aufspalten wird. Damit wird ein neuer Entwicklungspfad für die Alternativentwicklung eröffnet. Typischerweise entstehen in diesem Fall aus einer Vorgängerversion zwei Nachfolgeversionen. Im Zuge dessen kann es vorkommen, dass zwei Entwicklungspfade wieder zusammengeführt werden müssen. Denn selbst wenn eine Entwicklungsalternative sich als unzureichend herausstellt und nicht weiter verfolgt wird, muss die Historie diese Entwicklungen und die daraus gewonnen Erfahrungen mit einschließen. An dieser Stelle soll noch einmal ausdrücklich auf den Unterschied der beiden Begriffe Version und Variante hingewiesen werden. Oft werden unterschiedliche Produktausführungen im praktischen Sprachgebrauch als Versionen bezeichnet. Im Engineering wird unter einer Version etwas anderes verstanden. Hier ist eine Version mit der zeitlichen Entstehung eines Produktes, einer Baugruppe oder eines Bauteils verbunden. Und wird daher gleichbedeutend mit den Begriffen Änderungsstand, Revision oder Iteration verwendet. Diese Definitionen werden teilweise wie folgt unter-

88

5 Leithefte zu PLM-Aspekten

schieden: Im Sprachgebrauch des Product Lifecycle Managements bezeichnet die Version zeitlich nacheinander entstehende Arbeitsergebnisse bzw. Entwicklungsstufen einer Aufgabe oder eines Erzeugnisses. Eine neuere Version ersetzt meistens eine ältere Version, geht durch Veränderung oder Weiterentwicklung aus dieser hervor und stellt in der Regel eine Verbesserung dar. Bei Revisionen handelt es sich um Versionsnummern in sequenzieller Reihenfolge. Beispielsweise besteht in Integrationssystemen die Möglichkeit, von Artikeln, Dokumenten oder Projekten automatisch neue Versionen anzulegen, nachdem eine Änderung vorgenommen wurde. Es werden zwei Typen von Versionierung unterschieden (siehe Abb. 5-4) (Schichtel 2002): x Revisionierung: Versionen in sequenzieller Folge x Hierarchische Versionierung Besonders in der Softwareindustrie hat sich die hierarchische Versionierung als Verfahrensweise durchgesetzt, indem nach dem Umfang der Änderungen zur Vorgängerversion unterschieden wird. Kleinere Änderungen werden in sog. Zwischenversionen festgehalten, während umfangreichere Änderungen als Hauptversionen – so genannten „Major Releases“ – versioniert werden. Hierbei wird zwischen offenen und geschlossenen Versionen differenziert, um stärker herausstellen zu können, an welchen Versionen im Moment gearbeitet wird (offene Versionen) und welchen, die nicht mehr verändert werden bzw. werden sollen (geschlossene Versionen). Die Neuanlage einer Version verlangt das Schließen der offenen Vorgängerversion. Es sei denn, es soll explizit eine Alternativentwicklung stattfinden. Versionen können an Gültigkeiten gebunden sein, die eine Aussage darüber treffen, welche Randbedingungen gegeben sein müssen oder sollen, wie z.B. Zeitraum der Gültigkeit oder ein Produktionsstandort. Veröffentlichungen von Versionen werden immer dann notwendig, wenn beispielsweise andere am Entwicklungsprojekt Beteiligte einen Stand begutachten sollen oder ein Synchronisationszeitpunkt erreicht wird. Einzelne Versionen können verschiedene Zustände durchlaufen, wie z.B. die „Freigabe für Produktion“ (Schichtel 2001).

5.1 Evolution der Produkte organisieren 89

Abb. 5-4: Revisionierung und historische Versionierung

Gültigkeit, auch Effektivität (engl.: effectivity) genannt, ist eine Angabe, die Änderungen oder die Verwendung von Varianten (und Versionen) in einem konkreten Produkt/Erzeugnis für einen bestimmten Zeitbereich oder Anwendungsfall erlaubt bzw. einschränkt. Gültigkeiten können durch einen Zeitpunkt oder Zeitraum, ein Ereignis oder einen speziellen Produktnummernbereich (Seriennummernbereiche, Losnummernbereiche, Fertigungslokalitäten) definiert werden. Gültigkeiten sollten bei allen Versionen, Revisionen, Varianten und Alternativen angegeben und im integrierten Produktmodell vermerkt werden. Beispiele für Gültigkeiten sind:

90

5 Leithefte zu PLM-Aspekten

x Versionen und Revisionen: V1 ist gültig vom 01.01.03 bis zum 31.12.03, V2 ist gültig ab 01.01.04. (Zeitraum). V1 ist gültig bei Los 1 – 450, V2 ist gültig von Los 451 (bezogen auf Losnummernbereich). x Varianten: Variante A ist gültig für Europa, Variante B ist gültig für USA. In Produktstrukturen ist das Kriterium „Form-Fit-Function“ ausschlaggebend für die Versionierung von übergeordneten Baugruppen, um entscheiden zu können, ob diese ebenfalls überarbeitet und eine neue Versionsnummer erhalten muss. Es ist sehr wichtig zu beachten, dass sich „Form“ und „Function“ auf die Produktspezifikation beziehen, während sich „Fit“ auf die Abmaße und Toleranzen der Zeichnung bezieht. Eine neue Versionsnummer der übergeordneten Baugruppe wird erst dann notwendig, wenn mindestens eine der folgenden Fragen mit Nein beantwortet wird (Eigner u. Stelzer 2001): x Form: Entsprechen Erscheinungsbild und Aussehen der neuen Version des Bauteils bezogen auf die alte Version der Produktspezifikation? x Fit: Passt die neue Version des Bauteils bezüglich Abmaße und Toleranzen zu ihren benachbarten Teilen? x Function: Erfüllt die neue Version des Bauteils bezogen auf die alte Version alle funktionellen Anforderungen und Produktspezifikationen? 5.1.4 Konfigurationsmanagement als zentrale Funktion Konfigurationsmanagement ist ein Verfahren zur Herbeiführung und ständigen Sicherstellung der Übereinstimmung der Leistungs-, Funktions- und physischen Charakteristiken eines Produkts mit den zugehörigen Anforderungen, den Ausführungen, den Ausführungsunterlagen und den für den Betrieb erforderlichen Informationen während des gesamten Produktlebenszykluses (EIA-649-A). Das bedeutet, dass Änderungen einzelner Komponenten, also der verschiedenen Versionen der Komponente, zu den Änderungszeitpunkten erfasst werden. Das Konfigurationsmanagement dient somit zur Erzeugung oder Rekonstruktion einer Produktbeschreibung zu einem bestimmten Zeitpunkt oder mit einer bestimmten Seriennummer. Konfigurationsmanagement ist auf Hardware, Software und die zugehörige

5.1 Evolution der Produkte organisieren 91

Dokumentation gleichermaßen anwendbar. Hauptziel des Konfigurationsmanagements ist, die gegenwärtige Konfiguration eines Produktes sowie den Stand der Erfüllung seiner physischen und funktionellen Forderungen zu dokumentieren und volle Transparenz herzustellen. Die DIN ISO 10007 definiert den Begriff Konfiguration als „die funktionellen und physischen Merkmale eines Produkts, wie sie in seinen technischen Dokumenten beschrieben und im Produkt selbst umgesetzt sind.“ Die Konfiguration eines Produktes definiert damit aus der Fülle der möglichen Produktvarianten und Bauteilversionen ein Produkt in einer konkreten Zusammenstellung zu einem bestimmten Zeitpunkt anhand der zu diesem Zeitpunkt gültigen Versionen und ausgewählten Varianten der jeweiligen Einzelteile. Bei der Produktspezifikation legt der Kunde für jedes unabhängige Merkmal eine Ausprägung und damit auch die gewünschte Produktvariante fest. Ist die Produktspezifikation vollständig erfolgt, so kann die Varianten-Produktstruktur ausgewertet werden, in dem jede abstrakte Komponente durch die jeweils richtige konkrete Komponente ersetzt wird.

Abb. 5-5: Konfiguration eines Produktes

92

5 Leithefte zu PLM-Aspekten

Die Protokollierung der Änderungen am Produkt und die daraus entstehenden unterschiedlichen Versionen wird auch als Historie (engl.: history) eines Produktes bezeichnet, die somit den zeitlichen Verlauf der Konfiguration berücksichtigt (siehe Abb. 5-5). Ein weiteres Ziel des Konfigurationsmanagements ist es, dass jeder am Projekt Beteiligte zu jeder Zeit des Produktlebenszykluses die richtige und zutreffende Dokumentation verwendet. Methoden des Konfigurationsmanagements sind nach DIN ISO 10007: x Konfigurationsidentifizierung: Festlegung der Produktstruktur, Auswahl von Konfigurationseinheiten (KE), Dokumentation der physischen und funktionellen Merkmale einschließlich der Schnittstellen und späterer Änderungen x Konfigurationsüberwachung: Überwachung von Änderungen an einer Konfigurationseinheit, nachdem erstmals die Konfigurationsdokumente formell erstellt wurden x Konfigurationsbuchführung: die formalisierte Dokumentation und Berichterstattung bezüglich der geltenden Konfigurationsdokumente, des Standes laufender Änderungsanträge und des Durchführungsstandes der genehmigten Änderungen x Konfigurationsauditierung: formale Prüfung des Ausführungsstandes einer Konfigurationseinheit auf Übereinstimmung mit ihren geltenden Konfigurationsdokumenten Aus der Sicht der Geschäftsbeziehung zwischen Anbieter und Kunde stellen die Spezifikation und die Konfiguration eines Produktes die Bestandteile des Dialoges zwischen diesen beiden dar, um die Grundlage des Geschäftes zu legen. Die Spezifikation eines Produktes liegt also in der Verantwortung des Kunden, dessen Konfiguration in der des Anbieters. Vor allem bei lange im Markt befindlichen Produkten oder solchen mit langer Nutzungsdauer kommen bei der Konfiguration erhebliche zeitliche Aspekte hinzu. In diesen Fällen definiert die Konfiguration die zu einem bestimmten Zeitpunkt bzw. während einer Zeitspanne verbauten Komponenten in diesem Produkt. Für das Produkt, seine Verwaltung und Darstellung sind im Product Lifecycle Management die Begriffe und die damit verbundenen Konzepte der Versionen, Gültigkeiten, Varianten, Sichten und Konfigurationen von großer Bedeutung. Um den Gebrauch des Buches zu erleichtern, werden diese Begriffe aus den verschiedenen Leitheften an dieser Stelle zusammengefasst dargestellt.

5.1 Evolution der Produkte organisieren 93

5.1.5 Umsetzung vom Konfigurationsmanagement Die wesentliche Voraussetzung bei der Umsetzung des Konfigurationsmanagements ist die Definition der Produktstrukturen. Das heißt, dass Baugruppen und Einzelteile in einer hierarchisch aufgebauten Struktur miteinander in Beziehung stehen und anhand einer Teilenummer identifiziert werden können. Hierzu gehören ebenfalls die Identifikation der jeweiligen Version sowie deren Gültigkeitsdauer. Alle am Markt befindlichen integrierenden Systeme wie z.B. PDM-Systeme bieten zumindest Funktionen für die Verwaltung von Versionsständen und deren Gültigkeitsdauer. Die für die Umsetzung interessanten Fragen sind vielmehr die Handhabbarkeit der Versionsverwaltung und Festlegung der Gültigkeitsdauer. Beispielsweise, ob die Gültigkeit automatisch durch Freigabeprozesse definiert wird, wie der Anwender nach gültigen Ständen zu bestimmten Seriennummern oder Datum recherchieren kann und gegebenenfalls CADModelle dieser Stände problemlos öffnen kann. Die Verwaltung paralleler Varianten ist in der Regel ein zusätzliches Modul zum PLM-Basissystem, das neben der Verwaltung der Varianten auch deren Erstellung mit Hilfe von Variantenregeln erleichtert. Dies kann sogar bis zur Integration eines CAD-Systems zur Modellanpassung ausgebaut werden. Als ersten Schritt für die Einführung eines solchen Variantenverwaltungsmoduls sollten gleichartige bzw. verschiedenartige Teile in den Produktstrukturen identifiziert und entsprechend zu einer gemeinsamen Produktstruktur zusammengefasst werden, die Platzhalter für die Variantenbaugruppen bzw. Variantenteile enthält. Ein weiteres Hilfsmittel für die Identifikation von Varianten kann die Ermittlung von Gleichteilen mittels Klassifikation der im Unternehmen vorhandenen Bauteile sein. Hier sind bereits ergänzende Softwarewerkzeuge zu PLM- und CAD-Systemen auf dem Markt, die Ähnlichkeiten von vorhandenen Datenbeständen über die Bauteilgeometrie oder Identifikationsmuster in den Metadaten erkennen und die korrespondierenden Teile entsprechend klassifizieren. Als weiterer Schritt können die Abhängigkeiten zwischen Bauteilen einer Variantenausprägung festgelegt werden. Darauf aufbauend lässt sich ein entsprechendes Regelwerk definieren, in dem diese Abhängigkeiten abgebildet werden. Mit Hilfe dieser Regeln wird die Bildung und Prüfung der Konfiguration einer Variantenausprägung beschleunigt und mit Softwareunterstützung eventuell teilautomatisiert. Gängige Beispiele für die Anwendung solcher Regelwerke sind die Konfiguratoren auf den Webseiten von Automobilherstellern, bei denen je nach Motorisierung nur be-

94

5 Leithefte zu PLM-Aspekten

stimmte Radabmessungen gewählt werden können oder nur bestimmte Ausstattungsmerkmale miteinander kombiniert werden können. Durch die zunehmende Verbreitung von mechatronischen Komponenten in allen Arten von Produkten ergibt sich im Konfigurationsmanagement neben der Versionsverwaltung der mechanischen und elektronischen Produktdaten auch die Problematik der Versionsverwaltung der Softwarequellcodes dieser Komponenten. Systeme zum Softwarekonfigurationsmanagement arbeiten im Gegensatz zu PDM-Systemen nicht mit getrennten Metadaten und Verweisen auf die Datendateien, sondern direkt auf der Ebene der Sourcecode-Dateien (Karcher 2004). Softwareprogramme werden heute in der Regel aus einzelnen Modulen zusammengefügt, die in eigenständigen Zweigen (Branches) entwickelt und versioniert werden. Das Softwarekonfigurationsmanagment unterstützt die Verwaltung, welche Modulversionen für die Implementierung einer bestimmten Softwareversion verwendet wurden. Aufgrund der konzeptuellen Unterschiede zwischen Softwarekonfigurationsmanagement und dem Konfigurationsmanagement von Produktdaten sind Lösungen für ein integriertes Konfigurationsmanagement der Bestandteile von mechatronischen Komponenten gerade erst im Übergang aus der Forschung in die Praxis. Da die Verwaltung mechatronischer Entwicklungen in starker Abhängigkeit zur Wertigkeit der Disziplinen und Komplexität der Produkte stehen, wird diese Thematik in einem separaten Leitheft (siehe Abschnitt 5.13) behandelt. Weiterführende Literatur

Eigner M, Stelzer R (2001) Produktdatenmanagement-Systeme – Ein Leitfaden für Product Development und Life Cycle Management. Springer Verlag, Berlin Heidelberg Schichtel M (2002) Produktdatenmodellierung in der Praxis. Fachbuchverlag, Leipzig Schöttner J (1999) Produktdatenmanagement in der Fertigungsindustrie, Prinzip – Konzepte – Strategien. Fachbuchverlag, Leipzig Normen und Standards

DIN ISO 10007 (Norm-Entwurf), Ausgabe: 2004-03: Qualitätsmanagement – Leitfaden für Konfigurationsmanagement DIN EN ISO 10007, Ausgabe: 1996-12: Qualitätsmanagement –Leitfaden für Konfigurationsmanagement

5.2 Produkte kontextabhängig darstellen 95

5.2

Produkte kontextabhängig darstellen

Views (engl.) Æ Daten- und Dokumentenmgnt. Æ Konfigurationsmgnt. Das vorherige Leitheft behandelte das Thema Produktstrukturen hinsichtlich Strukturierungselemente. Offen blieb bei dieser Abhandlung jedoch, nach welchen Gesichtspunkten diese Strukturierung der Produkte stattfinden soll. Eindeutig ist eine Produktstruktur keinesfalls. Je nach Hintergrund des Strukturerstellers wird die Struktur unterschiedlich ausfallen. Welche Strukturierungsform die „richtige“ ist, kann generell nicht gesagt werden. Beispielsweise können sich Anforderungen an eine Produktstruktur abhängig von Prozessphasen verändern. So hat ein Konstrukteur ein funktions- oder systemorientiertes Verständnis einer Produktstruktur während für einen Monteur eine zusammenbauabhängige Vorstellung des Produktes im Vordergrund steht. Ebenso wird eine Struktur aufgrund der technologieorientierten Herkunft unterschiedlich umgesetzt sein. Ebenfalls erzeugen unterschiedliche Erzeugersysteme anders geartete Produktstrukturen, die mit den PLM-Systemen synchronisiert werden müssen. Werden Komponenten von Zulieferern entwickelt bzw. verbaut und sollen die entsprechenden Daten inklusive Strukturen mit in das PLM aufgenommen werden, verhält es sich entsprechend. Ein Lieferant wird eigene Strukturierungskriterien angewandt haben. Folglich sind unterschiedliche Prinzipien der Strukturierung denkbar. Die Produktstruktur ist somit kontextabhängig, ein Sachverhalt, dem schon in der konventionellen Produktentwicklung Rechnung getragen wurde. Das analoge Konzept hierzu ist der Einsatz unterschiedlicher Stücklisten. Da im PLM die Stückliste nicht mehr als Dokument gespeichert wird, sondern eine Ausleitung aus der Produktstruktur darstellt, muss dieses Konzept im Produktstrukturmanagement aufgegriffen werden. Im PLM erfüllt das Sichtenmanagement diese Aufgabe. Die hierarchischen Beziehungen in einer Produktstruktur eines integrierten Produktmodells werden mit dem Sichtenmanagement in Abhängigkeit des Kontextes gebracht, sodass je nach Bedarf mehrere Produktstrukturen generiert werden können. Durch dieses Vorgehen sollen bestimmte Prozesse und Aufgaben im Product Lifecycle zielgerichtet unterstützt werden. Jedoch ist mit dem Umgang von Sichten besondere Vorsicht geboten, da jede neue Sicht die Produktstruktur und damit die Verwaltung des Produktes komplexer macht. Ein Patentrezept wie viele Sichten benötigt werden, gibt es nicht. Es gilt das Motto: So wenig Sichten wie möglich, so viele wie nötig.

96

5 Leithefte zu PLM-Aspekten

5.2.1 Sichtenmanagement Das Sichtenmanagement in Abb. 5-6 baut auf dem Daten- und Dokumentenmanagement auf (siehe Abschnitt 5.3.1 „Dokumentenmanagement“103). Zudem besteht ein Querbezug zum Konfigurationsmanagement. Das Sichtenmanagement selbst wird für keine weiteren Funktionsbausteine benötigt.

Abb. 5-6: Sichtenmanagement im PLM-Umfeld

5.2 Produkte kontextabhängig darstellen 97

5.2.2 Strukturierungsprinzipien des Sichtenmanagements In der Informationstechnik wird unter einer Sicht allgemein eine kontextabhänge Darstellung verstanden, die aus einer vordefinierten Datenstruktur abgeleitet wird. Im PLM ist diese Datenstruktur die Produktstruktur, und die abgeleiteten Sichten beziehen sich auf unterschiedliche Darstellungen, die zielgerichtete Arbeitsweisen unterstützen. Gängige Strukturierungsprinzipien sind: x x x x x

Produktphasenbezogen Technologieabhängig System-/Funktionsorientiert Ortsbezogen Erzeugersystem- oder Lieferantenabhängig

Sichten können prinzipiell auf zwei kombinierbare Arten erzeugt werden: x Kennzeichenbezogene Filtermechanismen: Der einfachste Fall, eine Sicht zu definieren, erfolgt über Attribute, die in der Produktstruktur die Darstellung von gewissen Strukturelementen in Abhängigkeit der gewählten Sicht ein- oder ausschalten. Für eine modular aufgebaute Verpackungsmaschine bestehend aus Produktzuführung, Verpackungszuführung, Maschinenbasismodul und Beschriftungsmodul kann beispielsweise für Vertrieb, Entwicklung und Produktion jeweils ein Kenner definiert werden (Vertriebs-, Entwicklungs-, Produktionssicht). Die Produktstruktur bildet vollständig die Entwicklungssicht ab, sodass der Kenner Entwicklungssicht über die gesamte Produktstruktur gesetzt ist. Im Unterschied dazu sind bei der Produktionssicht keine Kenner bei Unterkomponenten von Zulieferbaugruppen gesetzt und für Vertriebssicht sind die Kenner nur auf Modulebene gesetzt. Damit sehen Vertrieb bzw. Produktion nur für sie relevante Teile. x Unterschiedliche Stücklistenstrukturen: Soll die Produktstruktur eines Produktes je nach Sicht vollständig unterschiedlich aufgebaut sein, müssen die Relationen der Strukturen unabhängig voneinander definiert werden. Systemtechnisch wird für jede Sicht eine Stücklistenstruktur erzeugt, bei der die Komponenten im jeweiligen Kontext unterschiedlich verknüpft werden. Folgen diese Strukturen einem definierten Regelwerk können die verschiedenen Stücklisten auch voneinander automatisiert abgleitet werden. Beispielsweise könnte der Bremshebel bei einem Fahrrad in der Montagesicht zur Baugruppe Lenker gehören, während in der Systemsicht derselbe Bremshebel zur Baugruppe Vorderradbremse gehört.

98

5 Leithefte zu PLM-Aspekten

Abb. 5-7: Sichten auf ein Produkt

Typischerweise werden in allen Sichten dieselben Elemente verbaut, wobei auch Elemente entfallen können. Baugruppen, die in der Regel Strukturierungselemente darstellen, können sich hingegen in den Sichten unterscheiden. Die Abb. 5-7 zeigt ein Beispiel, in dem ein Produkt sechs Einzelteile hat, die in der Sicht a über drei Ebenen mit den Baugruppen A, B und C strukturiert sind und in der Sicht b über zwei Ebenen mit den Baugruppen A und D (Schichtel 2002). In den folgenden Abschnitten soll auf die zwei gebräuchlichsten Strukturierungsprinzipien näher eingegangen werden. 5.2.3 Produktphasenbezogene Sichten Der klassische Ansatz von Produktsichten sieht eine produktphasenbezogene Einteilung vor. Mit jedem Phasenwechsel eines Produktes im Produktlebenszyklus ändern sich die Zuständigkeiten und somit die Sichtweisen auf ein Produkt.

5.2 Produkte kontextabhängig darstellen 99

x Wird eine erste Struktur schon während der Angebotsphase erstellt, wird diese funktional geprägt sein (as bid). x In der Entwicklung herrscht eine systemorientierte Denkweise vor (as developed). x Die Konstruktion kann eine detailliertere Sichtweise auf das Produkt haben (as designed). x Die Fertigung strukturiert ein Produkt eventuell anhand von Fertigungsprozessen oder Maschinenbelegungen (as planned). x Die Montage wird aufgrund der Zusammenbaureihenfolge strukturieren (as built). x Gerade bei großen Produkten wird der Vertrieb eine Möglichkeit fordern, die Produkte anhand von Verpackungseinheiten zu strukturieren (as shipped). Selbstverständlich sind neben den aufgeführten weitere Typen von Sichten im Bereich der Prozessphasen denkbar und in der Literatur zu finden. Diese Sichten ermöglichen das Ausleiten spezifischer Stücklisten, wie sie schon heute in einem Unternehmen verwendet werden. Dies könnte beispielsweise eine abweichende Fertigungsstückliste sein, die nun automatisch aus einer speziellen Fertigungssicht der Produktstruktur generiert wird. 5.2.4 Disziplinabhängige Sichten Der Umgang mit unterschiedlichen Disziplinen (Mechanik, Elektrik, …) vereint in einem integrierten Produktmodell ist weiterhin ein aktuelles Thema im Übergang von der Forschung in die Praxis. Ein möglicher Ansatz sieht die Verwendung des Sichtenmanagements vor. Zu jeder Disziplin wird eine eigene Sicht geschaffen, in der technologiespezifische Elemente integriert werden. Disziplinübergreifende Elemente sind in mehreren Sichten vorhanden. Die Abb. 5-8 zeigt ein Beispiel mit einer mechanischen und einer elektrischen Sicht. Mechatronische Elemente gehören beiden Sichten an. Weitere Strukturierungen könnten zum Beispiel aus der Software und aus der Hydraulik stammen. Der Vorteil dieser Vorgehensweise liegt in der Verwendung der Standardfunktion des Sichtenmanagements einer Standardsoftware. Die Umsetzung ist jedoch wieder ein konzeptionelles Problem und wird unternehmensspezifisch ganz unterschiedlich ausfallen.

100

5 Leithefte zu PLM-Aspekten

Abb. 5-8: Technologieabhängige Sichten

Gerade wenn zusätzliche, phasenbezogene Sichten verwendet werden sollen, multipliziert sich die Anzahl an Sichten rasch. Daher kann dieser Ansatz lediglich bei geringeren Produktumfängen eingesetzt werden. Weitere Ansätze zur integrierten Verwaltung von Produkten mit Bestandteilen aus unterschiedlichen Disziplinen finden sich im Leitheft „Interdisziplinäres Datenmanagement“ im Abschnitt 5.13. 5.2.5 Einführung eines Sichtenmanagements Der Kern der Herausforderung, ein effizientes Sichtenmanagement einzuführen, liegt wiederum nicht in der technischen Umsetzung sondern im konzeptionellen Ansatz. Wie im vorherigen Abschnitt erläutert, wird das Sichtenmanagement von den meisten auf dem Markt befindlichen Standardsystemen prinzipiell erfüllt. Die Einführung des Sichtenmanagements erfolgt wiederum schrittweise.

5.3 Dokumente sicher verfügbar machen 101

Zunächst gilt es, die Anzahl der Sichten aufgrund des resultierenden Verwaltungsaufwands angemessen zu halten. Daher sind sinnvolle Sichten zu identifizieren und deren Notwendigkeit zu validieren. Folgende Überlegungen sollen hierbei helfen. Mit wachsender Komplexität eines Produkts wächst der Wunsch für die jeweilige Arbeitsaufgabe eine angepasste, übersichtliche Sicht zur Verfügung zu haben. Dies steht jedoch im Widerspruch zum Verwaltungsaufwand der verschiedenen Sichten. Eine zu große Anzahl führt mit sehr hoher Wahrscheinlichkeit zu Dateninkonsistenzen und zur Intransparenz der Prozesse. Dem entstehenden Verwaltungsaufwand muss entsprechend durch definierte Prozesse entgegengewirkt werden, die sich in manchen Fällen sogar (teil-)automatisieren lassen. Voraussetzung hierfür sind Regeln und Algorithmen, die der Überführung zwischen den Sichten hinterlegt sind. Eine allgemeingültige Empfehlung für die Anzahl von Sichten kann aufgrund der unterschiedlichen Produktstrukturen und organisatorischen Anforderungen nicht ausgesprochen werden. Generell gilt jedoch, dass kennzeichenbezogene Filter einfacher und in größerer Anzahl handzuhaben sind, als unterschiedliche Stücklistenstrukturen. Es werden deshalb im wesentlichen Entwicklungs- und Fertigungsstücklisten als Struktur aufgebaut, die wiederum über Filter für Disposition oder Vertrieb eingeschränkt werden können, sodass die Hauptbereiche jedes Unternehmens – Entwicklung, Vertrieb, Beschaffung, Produktion – mit einer zwar nicht idealen, aber handhabbaren Sicht auf die Produkte ausgestattet sind. Es sollte auf jeden Fall versucht werden, die Steuerung der Sichten soweit wie möglich zu automatisieren. Falls die Regeln zu komplex sind, um diese in Systeme zu implementieren, sollten diese Regeln zumindest in Handlungsleitfäden dokumentiert werden. Bei hohem Komplexitätsgrad für die Überführung verschiedener Produktstrukturen empfiehlt es sich, speziell geschulte Mitarbeiter als „Produktstrukturmanager“ zu definieren. Ferner sollte das Einführen neuer Sichten immer mit einer entsprechenden Prozessdefinition einhergehen. Wie in Kap. 3 angedeutet, dient die Modellierung der Produktstruktur zur Konzepterstellung. Entsprechend sind die Modelle zur Sichtensteuerung in das PLM-Manifest aufzunehmen.

102

5.3

5 Leithefte zu PLM-Aspekten

Dokumente sicher verfügbar machen

Æ Klassifizierung Æ Änderungsmanagement Das Dokumentenmanagement stellt den Teil des Product Lifecycle Managements dar, der der Verwaltung aller Unterlagen dient, die im Verlauf der Lebensdauer eines Produktes entstehen oder verwendet werden. Grundlegendes Konzept des Dokumentenmanagements ist es, eine Verknüpfung zwischen Bauteilen und Baugruppen eines Produktes und zugehöriger Dokumente herzustellen, diese zu versionieren und mittels Metadaten auffindbar zu machen. Bis heute vollzieht sich in Unternehmen ein grundlegender Wandel von der manuellen Bearbeitung von Dokumenten hin zur Nutzung von Computern für die Erstellung und den Austausch von Informationen, wodurch die Menge an Informationen beträchtlich zugenommen hat und noch weiter zunimmt. Um diese Informationsmenge beherrschen zu können, nimmt die Notwendigkeit zu, diese Informationen mittels geeigneter Informationssysteme zu verwalten. Diese Informationssysteme können große Mengen von Dokumenten mit ihren zugehörigen beschreibenden Daten, den Metadaten, handhaben, wobei die Bandbreite des Funktionsumfangs von einfachen Zeichnungs-/Dokumentenverwaltungssystemen bis zu umfangreichen, prozessunterstützenden Produktdatenmanagementsystemen reicht. Das wesentliche Ziel des Dokumentenmanagements ist es jedoch immer, das richtige Dokument zur richtigen Zeit am richtigen Ort zur Verfügung zu stellen. Kostenreduktion und Qualitätsverbesserung sind unmittelbare Anreize für das Dokumentenmanagement und den Einsatz unterstützender Informationssysteme. Dies zeigt sich vor allem im potentiellen Nutzen der Anwendung solcher Systeme: x effizientes Ablegen und Wiederfinden von Dokumenten x schnelle und direkte Weitergabe von Informationen und Änderungen x Zugriff auf Wissen aller Art z.B. über existierende Produkte und Zusammenhänge zu früheren Projekten x Verbesserung bereichsübergreifender Zusammenarbeit im Engineering. Das Dokumentenmanagement stellt somit einen zentralen Bestandteil für die kontinuierliche, effiziente Informationsverwaltung im Product Lifecycle Management dar. Über das Product Lifecycle Management hinaus zeigt sich die Bedeutung des Dokumentenmanagements auch daran, dass im Zusammenhang mit dem Qualitätsmanagement der ISO 9000 der Lenkung von Dokumenten ein hoher Stellenwert beigemessen wird.

5.3 Dokumente sicher verfügbar machen 103

5.3.1 Dokumentenmanagement Wie in Abb. 5-9 zu erkennen ist, gehört das Dokumentenmanagement zu den Basis-Funktionalitäten im Product Lifecycle Management. Ohne die Verwaltung und Organisation von produktbeschreibenden Informationen als bindende Spezifikation des Produkts lassen sich die erweiterten Bereich des Product Lifecycle Managements nicht realisieren.

Abb. 5-9: Dokumentenmanagement im PLM-Umfeld

104

5 Leithefte zu PLM-Aspekten

5.3.2 Anforderungen an das Dokumentenmanagement Das Dokumentenmanagement ist sehr eng mit den Geschäftsprozessen und den Organisationsstrukturen eines Unternehmens verbunden. Die genaue Kenntnis der Geschäftsprozesse und Produktstrukturen erleichtert die Einführung oder Optimierung des Dokumentenmanagements erheblich, da auf deren Basis Strategien und Konzepte für Zugriffsberechtigungen, Versionierung, Statuswechsel und Archivierung festzulegen sind. x Zugriffsrechte werden benötigt, um das Lesen, Anlegen und Ändern von Dokumenten zu regeln. Bei der Verwendung eines IT-Systems müssen diese Zugriffsberechtigungen vor der Produktivsetzung des Systems festgelegt werden. x Aus den Abläufen im Unternehmen lässt sich der Statuswechsel von Dokumenten identifizieren. Es kann festgelegt werden, welchen Status ein Dokument annehmen kann, wann (d.h. durch welche Aktion) ein Status gewechselt wird und wer diese Statuswechsel veranlassen kann sowie wer zustimmen muss. Dies wird in so genannten Statusdiagrammen dargestellt (siehe Abb. 5-10).

Abb. 5-10: Beispiele für Statusdiagramme einer Zeichnung (links) und einem Änderungsantrag (rechts)

5.3 Dokumente sicher verfügbar machen 105

5.3.3 Strukturierung von Dokumenten Nach DIN EN 82045 ist ein Dokument „eine festgelegte strukturierte Menge an Informationen, die als Einheit verwaltet und zwischen Anwendern und Systemen ausgetauscht werden“. Diese Informationen können entweder auf Papier oder in digitaler Form abgebildet sein. Produktinformationen lassen sich in technische, kommerzielle und Qualitätsinformationen unterteilen (siehe Abb. 5-11). Die technischen Informationen lassen sich weiterhin noch nach dem Zeitpunkt ihrer Entstehung bzw. Nutzung in primäre, sekundäre und tertiäre Informationen unterteilen. Produktneutrale Informationen beinhalten allgemeine Informationen, die für mehrere Produkte relevant sind, wie z.B. Normen oder Richtlinien.

Abb. 5-11: Informationsarten im Product Lifecycle (DIN 6789)

106

5 Leithefte zu PLM-Aspekten

Um Informationen effektiv verwalten zu können, ist es notwendig, geeignete Strukturen aufzubauen, in denen diese nach bestimmten Kriterien oder Zusammenhängen miteinander in Verbindung gesetzt werden können. Ähnlich wie bei den Artikeln in der Produktstruktur, müssen Dokumente mit beschreibenden Informationen versehen und Beziehungen zwischen Dokumenten abgebildet werden. Dokumente, die durch ein PDM- oder Dokumentenmanagementsystem erfasst sind, werden üblicherweise mit zweckbezogenen und für das Unternehmen wichtigen beschreibenden Merkmalen (Attributen) gespeichert und verwaltet. Die einem Dokument zugewiesenen Attribute werden als Dokumentenstammdaten oder Metadaten bezeichnet.

Abb. 5-12: Dokumentenstammsatz mit Beispielen und Metadaten

5.3 Dokumente sicher verfügbar machen 107

Abb. 5-13: Formen von Dokumenten nach DIN EN 82045

Die in einem Dokumentenstammsatz enthaltenen Attribute können in identifizierende und beschreibende Attribute unterteilt werden (siehe Abb. 5-12). Die identifizierenden Attribute dienen zur eindeutigen Identifikation eines Dokumentes, wodurch Zuordnungen zu Produkten bzw. Artikeln definiert werden können. Mit diesen Attributen lässt sich ebenfalls eine Klassifizierung – also eine Einteilung der Dokumente in bestimmte Gruppen – vornehmen. Die beschreibenden Attribute dienen zur verständlichen allgemeinen Beschreibung der Informationen, die durch das Dokument repräsentiert werden. Unterstützende Informationssysteme bieten üblicherweise Funktionen, mit deren Hilfe ein Dokument anhand von Attributwerten gesucht werden können. Die Spezifikation geeigneter Attribute zur Beschreibung von Dokumenten in der Phase „PLM-RequirementManagement“ ist daher von hoher Bedeutung: Die Qualität der Spezifikation beeinflusst später im täglichen Geschäft die Effizienz der Dokumentensuche.

108

5 Leithefte zu PLM-Aspekten

Dokumente können in verschiedenen Erscheinungsformen auftreten, je nachdem wie die Dokumente und die zugehörigen Metadaten miteinander verknüpft werden. Die DIN EN 82045 unterscheidet dabei wie folgt (siehe Abb. 5-13). x Einzelne Dokumente, bei denen jedem Dokument Metadaten zugeordnet werden x Zusammengesetzte Dokumente werden aus mehreren Dokumenten – auch unterschiedlicher Typen – erstellt x Sammeldokumente verknüpfen für sich abgeschlossene Dokumente über Metadaten miteinander x Dokumentensätze listen die enthaltenen Dokumente auf. Die Metadaten beschreiben den Zweck eines Dokumentensatzes 5.3.4 Beziehung zwischen Dokument und Produkt Die Verwaltung von Produkten und den zugehörigen Dokumenten kann auf unterschiedliche Arten realisiert werden. Das Konzept vom Product Lifecycle Management strukturiert Produkte und Dokumente separat und stellt die Beziehungen zwischen ihnen her. Ein wesentlicher Punkt im Product Lifecycle Management ist die Verknüpfung von Dokument und Produkt. Produkte und Dokumente werden im Idealfall zunächst als völlig unabhängige Objekte bzw. Informationseinheiten betrachtet, und die Strukturen von Produkten und Dokumenten werden getrennt verwaltet. Im Produktstrukturmanagement werden die Produkte und ihre Beziehungen zueinander organisiert, während das Dokumentenmanagement die entsprechenden Dokumentenstrukturen verwaltet. Darauf aufbauend werden die Beziehungen zwischen Dokument und Produkt hergestellt, welche sich wie folgt beschreiben lassen (Eigner u. Stelzer 2001): x Zuordnung eines Produkts zu einem Dokument (1:1) : Dieser Fall ist einfach zu handhaben, dürfte aber in der Praxis eher die Ausnahme sein, da ein Produkt in der Regel mehr als ein beschreibendes Dokument benötigt. x Zuordnung mehrerer Dokumente zu einem Produkt (1:n): Ein typisches Beispiel für diesen Fall sind Produkte, denen mehrere Unterlagen zugeordnet sind, beispielsweise 3D-Modell, 2D-Zeichnung, Arbeitsplan und NC-Programme. x Zuordnung mehrerer Produkte zu einem Dokument (n:1): Eine direkte Zuordnung einer technischen Unterlage, die direkt mehr-

5.3 Dokumente sicher verfügbar machen 109

fach an Produktstämme gebunden ist, wie z.B. Basiszeichnungen für mehrere Produktstämme oder Montageanweisungen für eine Produktfamilie. x Keine Zuordnung eines Produkts zu einem Dokument (0:1): Diese Dokumente sind im Allgemeinen übergeordnete Dokumente mit allgemeingültigen Informationen, wie Formulare, Normen und Richtlinien oder allgemeine Anweisungen. Informationssysteme zur Unterstützung der Dokumentenverwaltung erlauben beim Dokumentenmanagement neben der Speicherung und Verwaltung von Stammdaten den Aufbau von Strukturen und Beziehungen zwischen einzelnen Dokumentenstammsätzen zur Strukturierung der Dokumentenmenge. Zwei verschiedene Beziehungsarten werden unterschieden: x Einfache Zuordnungen oder x Hierarchische Strukturen

Abb. 5-14: Strukturierung von Dokumenten nach DIN 6789 Teil 1

110

5 Leithefte zu PLM-Aspekten

Jede technische Dokumentation sollte zwecks besserer Übersichtlichkeit logisch gegliedert werden (DIN 6789-4, DIN EN 61355, DIN ISO 11442-4). Dazu werden im Regelfall die zu einer Dokumentation gehörenden Dokumente in mehrere Dokumentgruppen und mehrere Dokumentgruppen wiederum zu Gruppen höherer Ordnung zusammengefasst und damit hierarchisch strukturiert (siehe Abb. 5-14). Für diese Strukturierung sollten verschiedene Aspekte in Betracht gezogen werden: x Flexible Informationsanforderungen in unterschiedlichen Phasen des Product Lifcycle, wie z.B. Engineering, Montage, Instandhaltung x Zweckmäßige Struktur, die der funktionsbezogenen und/oder ortsbezogenen Struktur (Zusammenbaulage) eines Artikels/Produktes folgt x Zentrale und/oder dezentrale Verfügbarkeit 5.3.5 Dokumente systemunterstützt verwalten Die meisten Dokumente werden heute am Rechner erzeugt, und es liegt daher nahe, diese Dokumente auch digital zu speichern. Prinzipiell lassen sich diese Dokumente zwar in einer Verzeichnisstruktur organisiert ablegen, aber mit zunehmender Datenmenge wird es immer aufwendiger Informationen zu finden oder die Daten konsistent zu halten. Suchen und Finden von bestimmten Informationen erfordert vom jeweiligen Mitarbeiter ein umfangreiches implizites Wissen in welchem Dokument die Information enthalten sind und an welchem Ort des Dateisystems dieses Dokument gespeichert ist. Mit Hilfe eines Informationssystems kann jedes Dokument mit Metadaten versehen werden, welche das Suchen und Finden von Informationen erleichtern. Darüber hinaus bieten viele Systeme auch eine Inhaltssuche an (vergleichbar mit einer Suchmaschine im Internet). Gegenüber einer Suche mit Hilfe von Metadaten liefert diese Form der Suche im Allgemeinen jedoch unschärfere Ergebnisse. Noch wichtiger beim Dokumentenmanagement ist es jedoch, die aktuelle und sichere Verfügbarkeit von Information zu gewährleisten. Der Nutzer muss sicher sein, dass er die jeweils aktuellste Version eines Dokumentes abruft, und es muss sichergestellt sein, dass nicht mehrere Nutzer gleichzeitig Dokumente ändern. Um die Integrität der verwalteten Daten zu gewährleisten, regeln Informationssysteme den Zugriff auf die verwalteten Daten über die jeweilige Anwendung und verhindern den Zugriff über Standard-Betriebssystemfunktionen. Aus diesem Grund arbeiten viele PDM- und Dokumentenmanagementsysteme mit elektronischen Tresoren, den so genannten electronic Vaults. Ein solcher elektronischer Tresor be-

5.3 Dokumente sicher verfügbar machen 111

steht aus speziell geschützten Speicherbereichen, welche auf dem, von den Informationssystemen genutzten, Speichermedium reserviert sind. Technisch kann nur das Dokumentenmanagementsystem als einziger zugangsberechtigter Benutzer des electronic Vault Dateien aus diesem Speicherbereich auslesen oder schreiben (geändert wird eine Datei im Allgemeinen nicht, stattdessen wird bei einer Änderung eine neue Version des Dokuments angelegt – (siehe Abschnitt 5.1). Ein Dokumentenstammsatz in der Datenbank des Dokumentenmanagementsystems enthält einen Verweis auf den Ablageort der physischen Datei im electronic Vault. Der electronic Vault ist der Eigentümer von geschützten Dateien. Benutzer greifen auf die Daten von nun an ausschließlich über das dem Vault angeschlossene Informationssystem zu. Die entsprechenden Zugriffsrechte, die regeln, wer generell lesenden oder schreibenden Zugriff auf Dokumente hat, werden im Rahmen der Spezifikation (Phase „PLM-Solution-Design“) festgelegt. Darüber hinaus steuert das Dokumentenmanagementsystem, ob zum aktuellen Zeitpunkt ein lesender oder schreibender Zugriff auf ein Dokument möglich ist. Hierzu stehen üblicherweise folgende Funktionen zur Verfügung: x Check-Out-Funktion: Die so genannte Check-Out-Funktion dient dem Reservieren von Dokumenten aus dem geschützten Speicherbereich zur Bearbeitung. Mit dieser Funktion werden alle einem bestimmten Dokument zugeordneten Dateien in den Arbeitsbereich des Benutzers, d.h. auf den Rechner, an dem er arbeitet, kopiert. Von diesem Zeitpunkt an ist das Dokument zur weiteren Bearbeitung für andere Anwender im Dokumentenmanagementsystem gesperrt. Auf diese Weise werden Inkonsistenzen durch eine parallele Bearbeitung von Dokumenten vermieden. Möchte ein Anwender ein Dokument nur lesen, kann dieser natürlich auf das Dokument lesend zugreifen, ohne vorher die Check-Out-Funktion ausführen zu müssen. x Check-In-Funktion: Als Check-In-Funktion wird die Übergabe von neuen oder geänderten Dateien eines Dokuments an den geschützten Speicherbereich beispielsweise eines PDM- oder Dokumentenmanagementsystems bezeichnet. Mit dieser Funktion werden die im Arbeitsbereich des Anwenders befindlichen Dateien in den electronic Vault der Systeme übertragen. Handelt es sich bei der abzulegenden Datei um Daten, die zur Änderung reserviert und kopiert wurden, so wird beim Zurückschreiben der aus der Reservierung resultierende Sperrvermerk zurückgesetzt und eine neue Version der Datei angelegt. Ältere Dateiversionen werden

112

5 Leithefte zu PLM-Aspekten

weiterhin in den Informationssystemen verwaltet und bleiben somit erhalten. Diese sind über die Historie des Dokuments abrufbar. 5.3.6 Umsetzung von Dokumentenmanagement Eine grundsätzliche Vorgehensweise für die Einführung oder Optimierung des Dokumentenmanagements lässt sich in den folgenden Punkten zusammenfassen: x Bestimmen der Dokumenttypen: Als erster Schritt wird festgelegt, welche Dokumenttypen durch das Dokumentenmanagement erfasst werden sollen. Durch die Einbeziehung von Mitarbeitern aller Abteilungen bei dieser Entscheidung wird erfasst, welche Informationen an welcher Stelle benötigt werden. Außerdem wird die Akzeptanz des Dokumentenmanagementsystems bei den Mitarbeitern wesentlich erhöht, da jeder seine Informationen im System findet. Dies kann auch als Gelegenheit genutzt werden die Anzahl an unterschiedlichen Dokumenten zu reduzieren, indem Dokumente mit inhaltlichen Überschneidungen oder sich ergänzende Dokumente eines Prozesses zusammengefasst werden. x Festlegen der Metadaten der Dokumenttypen: Es werden die beschreibenden Informationen der Dokumenttypen definiert, welche die Informationen über den Inhalt des Dokuments zusammenfassen. Diese Informationen dienen dann insbesondere als Suchkriterien zum Auffinden von Informationen. Es sollten auch Regeln für die Benennung von Dokumenten aufgestellt werden, die die Suche nach Informationen vereinfachen, da alle Mitarbeiter die gleichen Begriffe verwenden. Gängige Merkmale sind Artikelnummer, Dokumentenstatus, Dokumentenversion oder der anlegende Unternehmensbereich. x Aufbau der Dokumentenstruktur: Zur Verbesserung der Übersichtlichkeit sollten die Dokumente in Gruppen zusammengefasst werden. Hierfür muss der jeweilige Verwendungszweck bestimmt und daraus die entsprechenden Dokumentenstrukturen abgeleitet werden. x Festlegen des Status und des Statuswechsels: Die verschiedenen Status eines Dokumententyps und die Tätigkeiten, die zu den entsprechenden Statuswechseln führen, sind sehr eng mit den Geschäftsabläufen und Organisationsstrukturen des Unternehmens verbunden. Die Planung des Dokumentenmanagements sollte deshalb mit der Analyse der Prozesse verknüpft werden, wobei insbesondere

5.3 Dokumente sicher verfügbar machen 113

die Abläufe des Änderungswesens, der Auftragsabwicklung und des Porjektmanagements zu berücksichtigen sind (siehe Abschnitt 5.9.1). x Festlegen der Zugriffsberechtigungen: Dieser Punkt ist für die Sicherheit der Informationen von besonderer Bedeutung, allerdings auch für den produktiven Nutzen und die Akzeptanz des Informationssystems. Der Nutzer muss die Informationen so handhaben können, wie seine Aufgabe es verlangt. Das bedeutet, dass die Zugriffsberechtigung auch vom Status eines Dokuments abhängen kann. Wie stark die Einschränkung der Rechte der jeweiligen Benutzer ist, hängt davon ab, wie flexibel Informationszugriffe gehandhabt werden sollen. Grundsätzlich sollten mit zunehmender Zahl der Benutzer die Berechtigungen strikter vergeben werden. Allerdings wird es im Wesentlichen um die Festelegung gehen wer ein Dokument anlegen und ändern darf. Der lesende Zugriff sollte zumindest für Dokumente von Serienteilen allen Mitarbeitern gestattet sein, um PLM als zentrale Plattform für Produktinformationen nutzen zu können. Einhergehend mit den Rechten sind auch die Organisationsstrukturen im System abzubilden, wofür die IT-Systeme in der Regel detaillierte Funktionsstrukturen zur Gruppen- und Rollendefinition zur Verfügung stellen. Ein Beispiel für Zugriffsberechtigungen ist in Abschnitt 5.7.6 beschrieben (siehe Abb. 5-41). x Zentrale oder dezentrale Speicherung: Das Dokumentenmanagement soll die Konsistenz und Aktualität der Informationen gewährleisten. Die einfachste Lösung ist eine zentrale Haltung von Dokumenten, sodass alle Mitarbeiter auf denselben Datenbestand zugreifen. Ist eine zentrale Dokumentenhaltung nicht möglich oder sinnvoll, z.B. aufgrund verschiedener Standorte, muss die Verteilung oder Replikation der Daten als zusätzlicher Schritt im Änderungsablauf mit berücksichtigt werden. Alle größeren PLM-Systemanbieter haben in Ihren Lösungsportfolios entsprechende Funktionalitäten im Angebot, allerdings muss die Eignung für den jeweiligen unternehmensspezifischen Anwendungsfall geprüft werden. Wichtige Kriterien sind folgende Punkte: x Auszutauschende Datenmenge: Wenn ein direkter Zugriff aufgrund der zur Verfügung stehenden Leitungskapazität nicht möglich ist, werden die Daten in der Regel repliziert, um die Daten an den jeweiligen Zugriffpunkten lokal vorzuhalten und dem Anwender ein zügiges Arbeiten zu erlauben. Allerdings ist dabei zu beachten, dass die Daten, wenn auch zeitversetzt, dennoch übertragen werden müssen.

114

5 Leithefte zu PLM-Aspekten

x Zugriffszeiten: Besonders bei Datenbankabfragen spielen die Antwortzeiten eine wichtige Rolle. In der Kommunikation zwischen Datenbank und der Anwendungssoftware dürfen die Zeiten zwischen Anfrage und Antwort nicht zu hoch sein, da sonst die Anfrage verworfen wird. Neben der Leitungsqualität und der Anzahl der Rechnerknoten, über den die Verbindung läuft, spielt hier auch die Entfernung der beiden Verbindungspunkte aufgrund der physikalischen Grenzen für die Geschwindigkeit der Übertragung eine Rolle. x Datenübernahme: Ein PDM- oder Dokumentenmanagementsystem lässt sich nur sinnvoll einsetzen, wenn es auch die tatsächlich benötigten Informationen zur Verfügung stellen kann. Allerdings darf der Aufwand zum Einpflegen des Dokumentenbestands nicht unterschätzt werden. Sind die Dokumente in einem IT-System vorhanden, können die Altdaten meist über Schnittstellen oder spezielle Konvertierungswerkzeuge übernommen werden. Allerdings muss auch die Qualität der Daten mit berücksichtigt werden. Sollen bei der Einführung eines PLM-Systems die CAD-Daten und die ERP-Daten zusammengeführt werden, stellt sich zwangsläufig die Frage wie gut die Indexstände im ERP-System gepflegt sind oder ob beim Zusammenführen von CAD- und ERP-Stückliste die Strukturen identisch sind. Es ist sehr genau zu überlegen wie viel Aufwand in Pflegemaßnahmen der Altdaten investiert werden soll. Zum einen bedeutet eine Nachpflege meist einen hohen Aufwand an Zeit und Personalkapazität. Zum Anderen ist die Datenqualität im PLM-System ein wichtiger Garant dafür, dass die Ziele der PLM-Einführung erreicht werden können. Auch die Anwenderakzeptanz steht und fällt damit, ob die richtigen Daten im „neuen“ System besser gefunden werden als mit der althergebrachten Arbeitsweise. Liegen die Dokumente auf Papier oder anderen Medien vor, können sie entweder zur digitalen Bereitstellung gescannt oder im IT-System mit dem physischen Standort (z.B. „Raum XY, Schrank ABC, Ordner DEF“) des Dokuments referenziert werden. Als Entscheidungsgrundlage sollte der Kosten-/Nutzenaufwand für die digitale Bereitstellung betrachtet werden. Beispiele

In Abb. 5-15 ist ein Beispiel für die Verknüpfung eines Zahnrades mit der Artikelnummer ZR-S05000-0012 mit einigen der beschreibenden Dokumente dargestellt. Das Dokument CAD-ZR-S05000-0012 ist ein zusammengesetztes Dokument, das die physikalischen Dateien des 3D-CAD-

5.3 Dokumente sicher verfügbar machen 115

Modells und der daraus abgeleiteten 2D-Zeichnung enthält. Das Dokument BR-ZR-S05000-0012 ist ein Sammeldokument für den Festigkeitsnachweis des Zahnrades. Dem Festigkeitsnachweis ist direkt eine Textdatei des Berechnungsreports mit den Berechnungsparametern und einer Ergebniszusammenfassung zugeordnet. Mit dem Dokument des Festigkeitsnachweises sind zudem die untergeordneten Dokumente des FEM-Modells FE-ZR-S05000-0012 und FEM-Berechnungsergebnis FR-ZR-S050000012 verknüpft, denen die Dateien des FEM-Modells bzw. der Detailergebnisse zugeordnet sind.

Abb. 5-15: Beispiele für Dokumentenstrukturen eines Zahnrades

116

5 Leithefte zu PLM-Aspekten

Normen und Standards

DIN 199 - Teil 1: Technische Produktdokumentation – CAD-Modelle, Zeichnungen und Stücklisten Diese Norm ist ein Lexikon der Begriffe für ausgewählte feste Benennungen und Dokumentarten aus den Bereichen CAD-Modelle, Zeichnungen und Stücklisten. DIN 199 - Teil 3: Begriffe im Zeichnungs- und Stücklistenwesen Diese Norm definiert die Begriffe für den Aufbau und die Anwendung von Schlüsselnummern. DIN 6771: Schriftfelder für Zeichnungen, Pläne und Stücklisten In dieser Norm werden Aufbau und Bezeichnung der Felder für Zeichnungen, Pläne und Stücklisten festgelegt. DIN 6789: Dokumentationssystematik In den sechs Teilen dieser Norm wird der Aufbau, die Struktur, Änderungen und Freigaben von technischen Produktdokumentationen behandelt. DIN EN 61355: Klassifikation und Kennzeichnung von Dokumenten für Anlagen, Systeme und Einrichtungen. Diese Norm dient als Grundlage zur Erstellung einer strukturierten Dokumentation durch Regeln und Richtlinien zur Klassifikation und Kennzeichnung von Dokumenten. DIN EN 82045: Dokumentenmanagement Diese Norm legt Prinzipien und Methoden fest, um Metadaten für das Management von Dokumenten über den gesamten Lebenszyklus eines Objektes zu definieren. DIN ISO 11442: Rechnerunterstützte Handhabung von technischen Daten Diese vierteilige Normenreihe behandelt die Sicherheitsanforderungen, die Handhabung von Originaldokumentation, die Arbeitsschritte bei der Entwicklung von Produktdaten sowie die Datenverwaltung u. -recherche. DIN ISO 15226: Lebenszyklusmodell und Zuordnung von Dokumenten Diese Norm dient zur Erstellung eines flexiblen Lebenszyklusmodells, das die Handhabung von technischen Dokumenten erleichtert. DIN ISO 16016: Schutzvermerke Diese Norm legt Schutzvermerke für Dokumente und Produkte fest, deren Nutzung beschränkt und deren missbräuchlicher Nutzung vorgebeugt werden soll.

5.4 Produktdaten archivieren 117

5.4

Produktdaten archivieren

Æ Daten- und Dokumentenmanagement Im Gegensatz zur „üblichen“ Datenhaltung in Informationssystemen liegt der Fokus bei der Produktdatenarchivierung weniger auf der zeitnahen Bereitstellung von Informationen zu einem Produkt, sondern auf Aufbewahrung über einen langen Zeitraum und der Möglichkeit die Produktdaten nach einer langen Zeit wieder bereitstellen zu können. Dabei müssen die Daten nicht zwingend im Zustand aufbewahrt werden, wie sie im operativen Geschäft eines Unternehmens genutzt werden, da die Beweggründe für die lange Aufbewahrung von Produktinformationen andere sind als das operative Vorhalten von Produktinformationen. Werden herkömmliche Dokumente in Papierform oder abgelichtet auf Mikrofiche archiviert, stellt der technologische Wandel der CAD-Systeme von 2D auf 3D neue Anforderungen an die Archivierung. Dreidimensionale Dokumente lassen sich nicht mehr auf herkömmlichen Medien abbilden und müssen daher digital archiviert werden – eine technologiebasierte Motivation. Aufgrund von Gesetzen und anderen Vorschriften – beispielsweise zur Nachweispflicht – sind Firmen häufig verpflichtet, ihre Entwicklungen über einen bestimmten Zeitraum zu archivieren, und dies ist über Jahre zu garantieren. Beispielsweise besteht die Nachweispflicht in der militärischen Flugzeugindustrie weit über die Betriebszeit hinaus, die durchaus bis zu 50 Jahren liegen kann. Soll ein solches Produkt folglich digital archiviert werden, muss das Unternehmen garantieren, dass die archivierten Formate auch noch in 50- 100 Jahren lesbar sind, wenn das Produkt 50 Jahre angeboten und weitere 50 Jahre betrieben wird. Herkömmlicherweise werden Dokumente in Papierform oder abgelichtet auf Mikrofiche archiviert. Bei sicherheitskritischen Konstruktionen wurden die archivierten Papierdokumente teilweise vakuumverpack eingelagert. Unabhängig vom hohen Kostenaufwand ist dies mit dreidimensionalen Produktmodellen nicht mehr durchführbar. Die notwendige digitale Langzeitarchivierung stellt somit eine besondere Herausforderung dar. Einen grundlegenden Ansatz für dieses Problem bietet der STEP-Standard, der in der Normreihe ISO 10303 festgelegt ist. Da es sich beim STEPStandard um eine textbasierte Beschreibung handelt, ist die Wahrscheinlichkeit recht hoch, dass sich ein Produktmodell auch nach Jahren wiederherstellen lässt. Ist statt des digitalen Produktmodells ein grafisches Modell für eine mittelfristige Archivierung ausreichend, ist ein standardisiertes Grafikformat anerkannt (TIFF), bei der ein Archivierungszeitraum von bis zu zehn Jahren akzeptiert werden kann. Bei Archivierungen bis zu fünf Jahren wird von einer kurzfristigen Archivierung gesprochen. Hier können

118

5 Leithefte zu PLM-Aspekten

bekannte Formate verwendet werden, die sich etabliert haben. Als Beispiel sei hier das PDF-Format genannt, das ursprünglich von der Firma Adobe entwickelt wurde und inzwischen insbesondere zur besseren Verwendung bei der Langzeitarchivierung als PDF/A in der ISO 19005:2005 standardisiert wurde. 5.4.1 Digitale Produktdatenarchivierung

Abb. 5-16: Digitale Produktdatenarchivierung im PLM-Umfeld

5.4 Produktdaten archivieren 119

Die digitale Produktdatenarchivierung setzt auf dem Funktionsblock „Vaulting“ und damit indirekt auf dem Daten- und Dokumentenmanagement auf. Die Archivierung selbst wird für keine weiteren Funktionsbausteine benötigt (siehe Abb. 5-16). 5.4.2 Realisierung einer digitalen Produktdatenarchivierung Zunächst sind die Anforderungen an eine Archivierung zu klären. Zu den Faktoren, die letztendlich für die Art und Weise der verwendeten Archivierung ausschlaggebend sind, gehören die Dauer der Archivierung, die Datenmenge, die Form des Quellformats und gesetzliche Rahmenbedingungen. Hierzu muss klargestellt werden, welche Dokumente zu welchem Zweck archiviert werden. Grundsätzlich kann zwischen zwei Motiven für eine Archivierung unterschieden werden. Zum einen sollen archivierte Dokumente die Wiederverwendung von Lösungen motivieren, zum anderen soll der Nachweispflicht Rechnung getragen werden. Liegt der Anspruch der Archivierung in der Wiederverwendung begründet, resultieren die Anforderungen aus den Anwenderbedürfnissen. Ein schneller und unproblematischer Datenzugriff hat hierbei die oberste Priorität. Dieser Zugriff muss selbstverständlichen den vorgestellten Methoden aus dem Leitheft „Dokumente sicher verfügbar machen“ (siehe Abschnitt 5.3) genügen. Für eine längerfristige Archivierung oder für ein unternehmensweites Bereitstellen insbesondere bei Dokumenten spezieller Erzeugersysteme, die entsprechend seltene Dokumentformate besitzen, kann die Verwendung von Dokumenten in Alternativformaten von Vorteil sein. Wird eine digitale Archivierung neu in einem Unternehmen eingeführt, die bestehende herkömmliche Archive vollständig oder zumindest teilweise ablöst, ist der Umgang mit den Dokumenten und Daten aus bestehenden Archiven zu regeln. Ob und in welcher Form diese Dokumente in das neue Archiv übernommen werden, hängt letztendlich von der zu erwartenden Zugriffshäufigkeit ab. Um die Anwenderakzeptanz zu erhöhen, sollte der Endanwender jedoch lediglich auf ein einziges Archiv zugreifen müssen. Herkömmliche Archive sollten für den direkten Zugriff unnötig werden. Die Überführung von Papierdokumenten aus bestehenden Archiven in ein neues, digitales Archiv kann über drei verschiedene Wege erfolgen. x Ist der Zugriff auf die Quelldateien zu den Papierdokumenten erhalten geblieben, so werden die Quelldateien in das digitale Archiv überführt. Papierdokumente, von denen keine Quelldateien mehr existieren, verbleiben im herkömmlichen Archiv. Bei Dokumenten, von denen ledig-

120

5 Leithefte zu PLM-Aspekten

lich Papierauszüge existieren, die jedoch im hohen Zugriff stehen, kann eine nachträgliche Digitalisierung sinnvoll sein. x Eine zweite Möglichkeit besteht im Abscannen vorhandener Papierdokumente. Dadurch ist zwar ein schneller Zugriff auf die Dokumente gewährleistet, jedoch verhindert dies eine digitale Weiterverarbeitung. x Die dritte und letzte Möglichkeit besteht im Anlegen von Metadaten zu diesen Papierdokumenten, die weiterhin in einem herkömmlichen Archiv verwaltet werden. Diese Metadaten stehen über der gleichen Oberfläche zur Verfügung, in der auch die Metadaten der digitalen Produktarchive bereitgestellt werden. Die Metadaten im digitalen Archiv informieren den Benutzer über die Existenz des Dokuments. Ein Verweis auf den Lagerplatz im herkömmlichen Archiv erleichtert das Auffinden desselben. Die Arten der Archivierung sind beliebig kombinierbar. Laut Erfahrungswerten werden lediglich 15– 20% der Dokumente wieder verwendet. Daher sollte genau geprüft werden, für welche Dokumente sich ein kostspieliges Scannen oder sogar eine noch teurere Nachdigitalisierung lohnt. Wird die Archivierung zur Nachweispflicht durchgeführt, müssen vertragliche Abmachungen bzw. gesetzliche Vorschriften eingehalten werden. In diesen Fällen ist die Menge der möglichen Dokumentenformate erheblich eingeschränkt, die verwendet werden können. Nur die wenigsten Formate genügen den Ansprüchen einer sicheren Langzeitarchivierung. Ist eine Langzeitarchivierung von 3D-Geometrien notwendig, soll an dieser Stelle auf das Lothar-Projekt des ProSTEP iVip-Vereins verwiesen werden. Von einer Langzeitarchivierung wird ab einer Archivierungszeit von 10 Jahren gesprochen. Das Projekt verwendet den STEP-Standard zur Gewährleistung der Datensicherheit. Aufgrund der ständigen Fortschritte in der Forschung sollte auf Kongressbände und auf das Internet mit ständig aktuellen Ergebnissen der Forschung verwiesen werden. Bei kurz- und mittelfristigen Archivierungen können Standards und sogenannte Quasistandards wie beispielsweise die angesprochenen Formate PDF, IGES, DXF oder TIFF verwendet werden. Ein großer Vorteil beispielsweise bei der Verwendung des STEPStandards liegt in der Möglichkeit, Geometrien sowohl in 2D als auch in 3D mit Zusatzinformationen abzubilden. Probleme bereiten dagegen Fragen zum Umgang mit der Codierung der Genauigkeit von CAD-Systemen. Mit der Zeit gewinnen CAD-Systeme an Genauigkeit und diese führt zu Darstellungsveränderungen, da geometrische Informationen von alten CAD-Systemen in Neueren anders interpretiert werden.

5.5 Nummernvergabe automatisieren 121

5.5

Nummernvergabe automatisieren

Æ Produktklassifizierung Æ Dokumentenmgnt., Nummerungsschlüssel Jedes am Produktenstehungsprozess beteiligte Teil und Dokument sowie alle verwendeten Ressourcen, wie z.B. Rohmaterial oder Werkzeug, müssen eindeutig identifiziert werden können. Hierzu werden in der Regel unternehmenseigene Nummernsystematiken verwendet, die über die Identifikation hinaus die benummerten Objekte gleichzeitig klassifizieren. Normen mit verschiedenen Grundmodellen zur Systematik von Nummernsystemen, die unterschiedliche Vor- und Nachteile mit sich bringen, bieten die Basis zum Aufbau eines eigenen Nummernsystems. Die Praxis zeigt, dass in den meisten Unternehmen gleich mehrere Nummernsysteme für die Verwaltung von Teilen, Dokumenten und weiteren Ressourcen verwendet werden. Diese sind für bestimmte Anwendungsfälle und deren Anforderungen ausgelegt worden und oft historisch mit dem Unternehmen gewachsen oder durch Zukäufe von Unternehmensbereichen hinzugekommen. Die logische Konsequenz schlägt sich im unverhältnismäßig hohen Zeitaufwand für die Vergabe neuer Nummern nieder. Ist das gleiche Teil unter mehreren Nummern angelegt oder müssen für die Suche nach Teilen mehrere Nummernkreise oder unterschiedliche ITSysteme verwendet werden, werden zum einen für die Suche nach Teilen unnötig Kosten generiert und zum anderen erhöht es die Gemeinkosten durch zusätzlichen Verwaltungsaufwand oder durch kleinere Bestell-/ Fertigungslose. Unabhängig von der Einführung einer informationstechnischen PLMLösung ist eine Konsolidierung dieser Problemstellungen zumindest zu analysieren. Mit der Einführung einer PLM-Lösung ändern sich zusätzlich auch die Anforderungen an die unternehmenseigenen Nummernsysteme und somit verändert sich der Bewertungsmaßstab für die Auswahl einer bestimmten Nummernsystematik. War bisher beispielsweise der selbstsprechende Aspekt einer Nummer ein wichtiges Kriterium, spielt im PLM die IT-Verträglichkeit, die Flexibilität und Erweiterbarkeit eine große Rolle. Eventuell notwendige Änderungen an der Nummernsystematik sind in Anbetracht der Menge der zu berücksichtigten Objekte und der Tragweite dieser Änderungen ein nicht gerade einfaches Unterfangen. Ziel dieses Leitheftes ist es, verschiedene Nummernsystematiken vorzustellen und einen Überblick über Anforderungen und Chancen zu geben, die mit PLM an ein Nummernsystem geknüpft sind, sowie den Lesern für weitere Herausforderungen zu sensibilisieren, wie beispielsweise der Aufwand einer Reorganisation oder die Existenz von verschiedenen parallel existierenden Nummern (Konstruktions-Nr., Vertriebs-Nr, externe Nr.).

122

5 Leithefte zu PLM-Aspekten

5.5.1 Nummernsystematik Nummernsysteme sind organisatorische und methodische Voraussetzung für PLM als grundlegendes Element der Benennung und Klassifizierung von Produkten für das Produktstrukturmanagement (siehe Abb. 5-17). Zur informationstechnischen Verarbeitung müssen Elemente eindeutig mit entsprechenden Nummernsystemen identifiziert werden. PLM unterstützt die Referenzierung internen sowie zu anderen Systemen, z.B. zu Lieferanten.

Abb. 5-17: Nummernsystematik im PLM-Umfeld

5.5 Nummernvergabe automatisieren 123

5.5.2 Formen von Nummernsystemen Unter Benummerung wird das Bilden, Erteilen, Verwalten und Anwenden von Nummern für die Nummerungsobjekte verstanden (DIN 6763). Kurzbezeichnungen wurden schon lange vor dem Einsatz von IT-Systemen zur eindeutigen Beschreibung von Objekten in der betrieblichen Praxis eingesetzt. Solche Objekte können z.B. sein: Gegenstände (Einzelteile, Baugruppen, Enderzeugnisse, Betriebsmittel usw.), Datenträger (Zeichnungen, Pläne, Vorschriften, Belege usw.), Personen (Mitarbeiter, Kunden, Lieferanten usw.) und Sachverhalte (Ereignisse oder Vorgänge in Netzplänen usw.). Derartige Bezeichnungen treten als eine Folge von Ziffern, Buchstaben und Sonderzeichen auf. Werden sie nach einer bestimmten Systematik gebildet, so liegt ein Nummernsystem vor. Synonym werden auch die Begriffe Nummerungsschlüssel, Schlüssel, Code und Codesystem verwendet (Eigner u. Stelzer 2001). Durch den Einsatz von Nummernsystemen werden folgende Ziele verfolgt: x Vereinfachung der Informationsverarbeitung x Vereinfachung der Ablauforganisation x Verbesserung der Kommunikation zwischen Unternehmensbereichen, Kunden und Lieferanten x Verbesserung des Ordnungswesens x Reduzierung von Personalkosten x Reduzierung von Änderungen x Verbesserung technischer Einrichtungen Somit fallen dem Nummernsystem unterschiedliche Aufgaben zu, die in einer Nummer oder in mehreren für ein Objekt parallel existierenden Nummern umgesetzt werden können. Zu diesen Aufgaben gehört x x x x

Identifizieren, Klassifizieren (siehe Abschnitt 5.6.1), Informieren und Kontrollieren.

Die Identifikationsnummer ist eine eindeutige, unverwechselbare Festlegung bzw. Erkennung eines Elementes, z.B. des Teilestammes. Die Identifizierung kann sich auf ein einzelnes Element oder eine Gruppe von Elementen beziehen wie z.B. Teilestammsatz, Zeichnung oder Arbeitsplan. Beim Aufbau einer Identifikationsnummer sind einige wichtige Grundsätze zu beachten. Diese sind:

124

5 Leithefte zu PLM-Aspekten

x Vollständigkeit der Nummernvergabe x Eindeutigkeit der Nummer x Unveränderlichkeit während ihrer gesamten Lebensdauer Die Klassifikationsnummer ordnet ein Element nach vorgegebenen Merkmalen in bestimmte Klassen oder Gruppen ein. Üblicherweise wird eine Klassifikationsnummer hierarchisch aufgebaut. Dabei verfeinert sich die referenzierte Klasse oder Gruppe mit zunehmender Stellenzahl. Informationsnummern enthalten eine direkte Aussage aufgrund unverschlüsselter Merkmale oder gebräuchlicher Begriffe. Die Informationsnummern geben ohne Verwendung eines Nummernplans/Schlüsselverzeichnisses unmittelbar Auskunft über Eigenschaften des Elements z.B. DIN-Nummern für Papierformate oder Abteilungskürzel des Unternehmens. Eine Kontrollnummer liegt vor, wenn durch diese Nummer die Erkennung einer richtigen Person, Sache oder eines Sachverhaltes gewährleistet werden soll. Eine zusätzliche Kontrollnummer zu einer Identifizierungoder Klassifizierungsnummer ist nur dann sinnvoll, wenn wegen einer möglichen Verwechslungsgefahr auf die Auswahl der richtigen Nummer besonders große Bedeutung gelegt wird. Eine Identifikationsnummer kann eine Gruppe von Nummerungsobjekten umfassen, die innerhalb einer festgelegten Toleranz gleich und somit austauschbar sind (Schrauben, Unterlegscheiben usw.). Sollen in diesem Sinne identische Objekte voneinander unterschieden werden, z.B. einzelne Kfz-Motoren derselben Serie, so sollten gesonderte Kontrollnummern vergeben werden z.B. Seriennummer, Inventarnummer oder Fabriknummer. Dies kann in Verbindung mit einem Typenschild realisiert werden (Eigner u. Stelzer 2001). 5.5.3 Aufbau von Nummernsystemen Eine Nummer kann aus Zahlen, Buchstaben und Sonderzeichen bestehen. Nummernsysteme werden mit Hilfe von Nummernschemata in Form von Symbolen entworfen. Eine gebräuchliche Darstellungsform zeigt Abb. 5-198. Pro Stelle einer Nummer wird ein Kästchen verwendet. Die Zeichen können folgende sein: Buchstabe (B), Ziffern (Z) oder Sonderzeichen (S) (z.B. /, -, . --) (siehe Abb. 5-19).

5.5 Nummernvergabe automatisieren 125

Abb. 5-18: Nummernsysteme

Abb. 5-19: Aufbau einer Verbundnummer

Eine Nummer sollte einem systematischen Aufbau gerecht werden, eindeutig und einprägsam sein. Weitere Anforderungen sind: Aussagefähigkeit, Handlichkeit und geringe Fehleranfälligkeit sowie eine gewisse Erweiterungsfähigkeit des zunächst beschränkten Nummernraums. Es gibt im Wesentlichen zwei Ansätze der Umsetzung dieser Aspekte, nämlich Verbund- und Parallelnummer, die im Folgenden vorgestellt werden. Verbundnummer

Verbundnummern werden traditionell häufig im Bereich des Maschinenund Anlagenbaus eingesetzt. Sie verbinden Klassifikation mit einer Zählnummer und ergeben so im Verbund die Identifikation Die Charakteristika der Verbundnummern ist in Abb. 5-19 zu sehen.

126

5 Leithefte zu PLM-Aspekten

Vorteile: x „Halbsprechende Nummer“: Ein Mitarbeiter erkennt am hierarchischen Aufbau der Klassifikation das Objekt. x Dezentrale Nummernvergabe : Objekte können dezentral vergeben werden, wenn Klassifikation mit Lokalität in Zusammenhang steht. x Relativ geringe Stellenzahl: Die Nummern sind sehr kompakt. Nachteile: x Grenzen schnell erreicht: Der Zahlenraum ist durch feste Stellenzuordnung schnell ausgeschöpft. x Flexibilität eingeschränkt: Soll die Klassifikation eines Objektes nachträglich geändert werden, ändert sich auch die Identifikation. Querverweise beispielsweise in alten Zeichnungen sind nicht mehr zuordenbar. x Erweiterbarkeit eingeschränkt: Eine Erweiterung der Nummer ist aufgrund der direkten Zuordnung der einzelnen Stellen zu der Systematik nicht ohne weiteres möglich. Fazit: Verbundnummern sind bevorzugt bei manueller Datenverarbeitung einzusetzen. Parallelnummer

Die Parallelnummer trennt die Identifikation konsequent von der Klassifizierung. Die Parallelnummer besteht also aus zwei Nummern, die unabhängig voneinander aussagekräftig sind, jedoch nur in Kombination den Anspruch an ein Nummernsystem nach DIN 6763 erfüllen.

Abb. 5-20: Aufbau einer Parallelnummer

5.5 Nummernvergabe automatisieren 127

Die Identifikationsnummer ist eine laufende Nummer über alle Klassen hinweg. Die Charakteristika der Parallelnummern zeigt Abb. 5-20. Vorteile: x Kurze Identifizierungsnummer: Die Identifizierungsnummer ist bei der Parallelnummer im Vergleich zur Verbundnummer kürzer, weil sie eine fortlaufende Nummer ohne Freistellen ist. x Erweiterbarkeit: Die laufende Nummer kann beliebig groß werden. Dadurch ist der Zahlenraum nicht eingeschränkt. Dagegen ist eine Veränderung der Klassifikation genauso aufwendig, wie bei der Verbundnummer. x Zählnummer eindeutig: Allein die Zählnummer ist eindeutig. x Klassifikation entkoppelt: Die Klassifikation ist von der Identifikation entkoppelt. Dadurch kann ein Objekt nachträglich klassifiziert werden oder die Klassifikation kann verändert werden, ohne dass die Identifikation und somit die Zuordnung insbesondere von Querverweise in Dokumenten davon betroffen ist. Nachteile: x Einführungsaufwand: Gerade ein nachträglicher Einführungsaufwand ist teilweise sehr hoch. x Stellenanzahl: Die Stellenanzahl ist bei Parallelnummer größer als bei der Verbundnummer Fazit: Parallelnummern eignen sich besonders bei der elektronischen Datenverarbeitung. Der Zahlenraum ist durch die Systematik nicht eingeschränkt. Der klassifizierende Teil einer Nummer kann, unabhängig von Stellenzahl oder Art der Zeichen, nach dem schematischen Aufbau unterschieden werden. Eine Möglichkeit für den Aufbau nach dem Prinzip der hierarchischen Strukturierung bzw. der verzweigten Gliederung. Dieser Aufbau entspricht einer Baumstruktur, die sich mit zunehmender Stellenzahl immer stärker verzweigt und gleichzeitig die Klassifizierung weiter detailliert. Bei diesem hierarchischen Nummernaufbau ist ein Nummernteil von dem links vor ihm stehenden Nummernteil funktional abhängig (siehe Abb. 5-21). Ein Nummernteil (Hierarchiestufe) kann dabei aus einer oder mehreren Stellen bestehen. Demnach kann ein Nummernteil nicht selbstständig, sondern nur im Zusammenhang mit dem jeweiligen übergeordne-

128

5 Leithefte zu PLM-Aspekten

ten Oberbegriffen ausgewertet werden. Eine hierarchisch aufgebaute Nummer kann bei Bedarf durch eine Nummernverlängerung verfeinert werden. Typische Vorteile des hierarchischen Nummernaufbaus gegenüber einer unabhängigen Strukturierung sind: x Kompaktere Darstellungsform der verschlüsselten Merkmale x Geringere Stellenanzahl x In größeren Unternehmen einfacherer Aufbau eines Nummernschlüssels, da eine dezentrale Belegung in Abhängigkeit eines Vergabebereiches erfolgen kann Die zweite Möglichkeit des Aufbaus des klassifizierenden Nummernteils kann nach dem Prinzip der unabhängigen Strukturierung bzw. der unverzweigten Gliederung erfolgen. Die Darstellung entspricht einer Listenstruktur. Bei einem unabhängigen Aufbau hat jeder Nummernteil innerhalb einer Nummer eine generell festgelegte Bedeutung und ist nicht von anderen Nummernteilen abhängig (siehe Abb. 5-22). Jeder einzelne Nummernteil lässt sich daher selbstständig auswerten. Eine Umklassifizierung kann somit ohne Auswirkung auf andere Nummernteile erfolgen.

Abb. 5-21: Prinzip der hierarchischen Strukturierung

5.5 Nummernvergabe automatisieren 129

Abb. 5-22: Prinzip der unabhängigen Strukturierung

5.5.4 Vorraussetzung für ein IT-konformes Nummernsystem Voraussetzung für die Umsetzung eines IT-verträglichen Nummernsystems ist die Auflistung, Klassifikation und Strukturierung aller verwendeten Objekte, die es zu verwalten gilt. Zu diesen Objekten gehören neben den Einzelteilen, Baugruppen und Produkten auch Dokumente, die direkt mit dem Produkt oder mit dem Entwicklungsprozess in Verbindung stehen, insbesondere Zeichnungen, CAD-Modelle, Arbeits- und Prüfpläne. Weiterhin können Rohmaterialien, Halbzeuge, Maschinen, Anlagen, Vorrichtungen, Werkzeuge und sonstige Betriebsmittel sowie Hilfs- und Betriebsstoffe betroffen sein. Ist diese Voraussetzung erfüllt, können die Anforderungen an das IT-System zur Verwaltung dieser Objekte beschrieben werden. Dabei sind eventuell vorhandene Nummernsysteme und die technischen Verwaltungsstrukturen des IT-Systems zu berücksichtigen (siehe 5.5.5). Innerhalb klassischer PDM-Systeme hat das Nummernsystem die Aufgabe, alle Objekte, d.h. Unterlagen, Artikel und Projekte, eindeutig zu identifizieren und bestimmte Eigenschaften dieser Objekte zu klassifizieren. Bei einer Einführung sollte daher sehr gewissenhaft auf ein funktionsfähiges Nummernsystem geachtet werden. Ist das Nummernsystem nicht auf die betrieblichen Anforderungen abgestimmt, muss es später mit hohem Aufwand reorganisiert werden oder es kann nicht im ursprünglich geplanten Umfang genutzt werden. Die Abstimmung mit schon existierenden Nummernsystemen, die historisch gewachsen sind oder aus einer ERP-Einführung resultieren, kann sich even-

130

5 Leithefte zu PLM-Aspekten

tuell problematisch darstellen. Hier treffen die konkurrierenden Anforderungen verschiedener Informationssysteme oder Verwaltungsstrukturen aufeinander. Für PDM-Systeme oder andere entwicklungsseitigen Integrationssysteme ergibt sich somit häufig die Konsequenz, dass die Benummerung der Artikelstämme des ERP-Systems übernommen werden muss. Die Freiheitsgrade der Konzeption liegen in diesem Fall lediglich in den vom PDM-System verwalteten Objekten, z.B. den Dokumenten. Im Folgenden werden einige allgemeine Grundsätze für die Darstellungsform von Nummern aufgezeigt, wie sie sich besonders für den Einsatz in der Datenverarbeitung bewährt haben (Eigner u. Stelzer 2001): x Nummern sollten so kurz wie möglich sein. Darstellungsprobleme gibt es hauptsächlich bei langen Nummern. x Anzeige von verschlüsselten Angaben auf Masken und Listen nur dort, wo dies unbedingt erforderlich ist. x Angebot zusätzlicher optionaler Informationsmasken mit den Informationen über den Nummernplan und Nummernaufbau. x Alphabetische oder alphanumerische Schlüssel sind oft leichter merkbar und aussagekräftiger als rein numerische Schlüssel. x Gliederung langer Nummern in leicht merkbare kurze Nummernblöcke unter Verwendung von Gliederungszeichen. Der Aufbau eines Nummernsystems ist von folgenden Faktoren abhängig: x Art der Objekte und deren Merkmale; vorangestellt wird eine Analyse der Zielsetzungen, Benutzer, Datenträger, Bearbeitungsvorgänge etc. x Anzahl von Klassen eines Merkmales, d.h. die Genauigkeit der Abstufung z.B. von 0 bis 9 Æ 10 Klassen, von 0 bis 99 Æ 100 Klassen x Verknüpfung oder Unabhängigkeit der Merkmale untereinander x Erweiterbarkeit des Nummernsystems x Lebensdauer des Nummernsystems (abhängig von der Lebensdauer der Objekte, Veränderung des Unternehmens). x Technische Möglichkeiten des IT-Systems 5.5.5 Einführung/Restrukturierung des Nummernsystems Eine Reorganisation eines bestehenden Nummernsystems ist sehr aufwendig. Wird eine Reorganisation notwendig, ist auf einen kontrollierten Umgang mit alten Nummern zu achten. Es ist abzuwägen, inwieweit betroffene Nummern z.B. von Artikeln durch ein neues Nummernsystem ersetzt

5.5 Nummernvergabe automatisieren 131

werden können. Beispielsweise kann ein neues Nummernsystem für Bauteile die Systematik und Zuordnung von nachfolgenden Prozessen wie Arbeits- und Prüfplanung oder Lagerhaltung stark beeinflussen. Auch kleinere Hilfsmittel wie Auswertungstabellen in Tabellenkalkulationen oder Automatisierungsskripte können betroffen sein, wobei die Auswirkungen häufig erst nach Einführung des neuen Nummernsystems auffallen. Weiterhin muss berücksichtigt werden, dass Kosten nicht nur aus organisatorischem Aufwand entstehen. Bei Aufbringung der Nummer auf das Bauteil können auch Werkzeugkosten entstehen, eventuell sind ferner Dokumente wie Betriebs- oder Bedienungsanleitungen oder Ersatzteilkataloge anzupassen. Ist die Entscheidung für ein neues Nummernsystem getroffen, muss zunächst die Wahl auf eine bestimmte Nummernsystematik fallen. Wie im vorherigen Kapitel erwähnt, hat sich für Nummernsysteme die informationstechnisch behandelt werden, die Parallelnummernsystematik durchgesetzt. Dazu ist die zuvor erarbeitete Produktklassifizierung, die abgeschätzte Menge der zukünftig zu nummerierenden Objekte, die Vor- und Nachteile der jeweiligen Systematiken abgeglichen mit den Unternehmensanforderungen und die Zukunftssicherheit berücksichtigt. Für die Klassifizierung kann beispielsweise der Unternehmensbereich mit der Hoheit für Nummernvergabe, die Bauteileklasse (Produkt, Rohteil, Baugruppe) oder das Produktionswerk herangezogen werden. Grundsätzlich wird es mit steigender Komplexität des klassifizierenden Teils der Nummer schwieriger, eine automatisierte Nummernvergabe zu realisieren.

Abb. 5-23: Beispiel einer Auftragsnummer

132

5 Leithefte zu PLM-Aspekten

Ist die Wahl auf ein Nummernsystem gefallen, sind die Nummernräume festzulegen und die Stellen entsprechend der vorausgegangenen Überlegungen dem Klassifikationsanteil zuzuordnen. Hieraus resultiert nun der grunsätzliche Aufbau des Nummernsystems. Nun verbleibt eine entscheidene technische Frage mit weitreichenden Auswirkungen auf den Umgang mit der Nummernvergabe: Welches ITSystem hat die Hoheit über die Nummernvergabe. Grundsätzlich stehen sich hier die betriebswirtschaftlichen und die Systeme aus der Entwicklung gegenüber. Es sind sowohl Konzepte denkbar, in denen beide Systemwelten Nummern vergeben dürfen, beispielsweise über Nummernräume geregelt, wie auch Konzepte, bei denen ein System das führende System ist (sog. „Mastersystem“). Eine Nummernvergabe im gleichen Nummernkreis über beide Systeme setzt eine bidirektionale Integration beider Systeme voraus (siehe Abb. 5-23). Welcher Ansatz für das jeweilige Unternehmen der richtige ist, kann nicht einheitlich beantwortet werden. Dies hängt von verschiedenen Kriterien ab. Beispielsweise kann das Verhältnis zwischen eigenentwickelten Teilen und Zukaufsteilen entscheidend sein. Überwiegen die Eigenentwicklungen bietet sich eher die Nummernvergabe im PLM an. Andernfalls sollte eine Vergabe in den betriebswirtschaftlich orientierten ERP-Systemen präferiert werden. Schlussendlich muss jedoch jeder im Unternehmen Zugriff auf das entsprechende System haben, der im Unternehmen neue Teile anlegen darf. Eine Aufgabe der IT ist es anschließend, Konsitenz zwischen allen System zu gewährleisten, die Nummern vergeben aber auch zu den Systemen die Nummern verwenden, d.h. dass keine Nummern doppelt, mit unterschiedlichem Produktbezug vergeben werden können oder das Produktnummern aufgrund von Korrekturen durch zeitlich verzögerte Aktualisierungen in den Systemen verschieden sind. Ist ein neues Nummernsystem konzipiert und ist der informationstechnische Umgang definiert, muss der neue Nummernraum mit Inhaltengefüllt werden. Ein Nummernsystem kann nur mit einer kritischen Masse an Inhalten erfolgreich eingeführt werden. Hierzu ist eine teilweise oder sogar vollständige Überführung der alten Nummern in den neuen Nummernraum notwendig. Als populäre Beispiele aus der näheren Vergangenheit jedoch aus anderen Branchen, bei denen eine Neustrukturierung von Nummernräumen notwenig wurde, können die Umstellung der ISBN von 9 auf 13 Stellen oder die Umstellung der IP-Adressen vom v4 auf v6 genannt werden.

5.5 Nummernvergabe automatisieren 133

5.5.6 Checkliste x x x x x x x x x

Sind alle Objekte berücksichtigt? Wie wird die Eindeutigkeit einer Identifikationsnummer gewährleistet? Welche Auswirkungen hat die Änderung der Nummer dieser Objekte? Wie hoch ist der organisatorische und monetäre Aufwand bei Änderungen? Ist der Nummernraum auch zukünftig ausreichend? Ist der Nummernraum auch ausreichend für eventuelle Geschäftsfelderweiterungen? Ist die Klassifikation durchgängig und wie können sich Klassifikationsänderungen auswirken? Sind Vertriebsnummern und externe Nummern berücksichtigt worden? Welche Personen legen Nummern in welchem System an?

Normen und Standards

DIN 6763 Nach DIN 6763 dient eine Nummer zur Identifikation eines Objektes, d.h. dessen eindeutige und unverwechselbare Erkennung innerhalb eines Geltungsbereichs z.B. Sachnummern wird gewährleistet. Darüber hinaus hat sie die Aufgabe, ein Objekt zu klassifizieren d.h. dessen Einordnung in nach bestimmten Gesichtspunkten gebildeten Gruppen z.B. Produktart.

134

5 Leithefte zu PLM-Aspekten

5.6

Finden statt Suchen

Æ Nummernsystematik „Einen großen Teil der Arbeitszeit verbringen Konstrukteure mit der Recherche nach Standardbauteilen, Baugruppen und Lösungen. Häufig wird diese Recherche in traditioneller Weise, in einer Normblatt-Sammlung oder in Papierkatalogen bzw. per Telefon und Fax durchgeführt“ (Weißkopf 2002). Um den Konstrukteur bei diesen Recherchetätigkeiten zu unterstützen, werden Klassifikationssysteme eingesetzt, die das Suchen nach wiederverwendbaren Zukaufteilen, Normteilen und Standardbauteilen vereinfachen. Durch die Klassifikation können große Datenmengen strukturiert, konsistent und redundanzfrei verwaltet werden, und es können zusätzliche Funktionen mit unterschiedlichen Algorithmen für das Suchen und Finden von verschiedenen Eigenschaften eines Bauteiles zur Verfügung gestellt werden. Klassifikationssysteme sollen somit die folgenden Aufgaben unterstützen: x x x x

Strukturierung von großen Datenmengen Bereitstellung umfangreicher Suchmöglichkeiten Standardisierung der Beschreibung von Gegenständen Reduzierung der Teilevielfalt

Im Rahmen der Klassifikation werden Sachen und Sachverhalte nach bestimmten Gesichtspunkten geordnet. Ein Klassifizierungssystem beschreibt dabei Gegenstände, beispielsweise Artikel oder Dokumente, auf der Basis von festgelegten Eigenschaften dieser Gegenstände. Bei entsprechendem Aufbau des Klassifikationssystems bieten Informationssysteme weitreichende Möglichkeiten, die die Suche nach Gegenständen oder den definierten Eigenschaften dieser Gegenstände erleichtern, sodass die zeitliche Dauer für das Auffinden von Informationen deutlich verkürzt wird. Jedoch bedingt der Aufbau eines Klassifizierungssystems einer enormen Systematik. Die Klassifikation ist so zukunftsweisend aufzubauen, dass sie möglichst lange einsetzbar bleibt. Hierfür sind entsprechende Verantwortlichkeiten zwingend festzulegen, die für die Nachhaltigkeit der Klassifizierung Sorge tragen. Dieses Leitheft befasst sich ausschließlich mit der Klassifizierung von mechanischen Bauteilen. Für Software oder sogar mechatronische Produkte werden zukünftig ähnliche Klassifikationen aufzubauen sein. Das Leitheft „Interdisziplinäres Datenmanagement“ im Abschnitt 5.13 gibt einen Ausblick hierauf.

5.6 Finden statt Suchen 135

5.6.1 Produktklassifizierung Die nachfolgende Abb. 5-24 stellt einen Überblick über die wesentlichen Teilgebiete des Product Lifecycle Managements und deren Verbindungen untereinander dar. Die Produktklassifizierung baut auf der Nummernsystematik auf und hat das Ziel, das Auffinden von Informationen zu erleichtern.

Abb. 5-24: Produktklassifizierung im PLM

136

5 Leithefte zu PLM-Aspekten

5.6.2 Aufbau von Klassifikationssystemen Eine Klassifizierung ist eine Sortierung von Merkmalen aller Produkte und Artikeln, um Elemente mit ähnlicher Charakteristik wieder finden zu können. So ist ein Zahnrad z.B. durch mehrere Durchmesser, mindestens einer Breite, die Anzahl der Zähne, den Werkstoff und ein übertragbares Drehmoment klassifizierbar. Die Klassifikation von Artikeln wird informationstechnisch durch Klassifikationsnummern unterstützt. Eine Klassifikationsnummer dient im Gegensatz zu den Identifizierungsnummern nicht dazu, Elemente zu identifizieren. Die Klassifikationsnummer codiert hingegen den Artikel in Hinblick auf die Klassenzugehörigkeit. Unter Klassenbildung von Objekten wird ihre Einordnung nach vorgegebenen Merkmalen in bestimmte Klassen, Familien oder Gruppen verstanden. Elemente mit derselben Klassifizierung sind nur gleich in Bezug auf die ausgewählte, beschriebene Eigenschaft. Die Klassifizierungsnummern sollten den Aufbau der Klassifikation wiederspiegeln und somit folgende Eigenschaften erfüllen: x Eindeutigkeit innerhalb eines Klassifizierungssystems x ausreichende Ausbaufähigkeit der zugrunde gelegten Begriffssysteme x Beschränkung auf eindimensionale Aussagen in einer Klassifizierungsnummer bzw. im gleichen Nummernteil x Verwendung sinnvoller, sprechender (mnemonischer) Schlüssel Ein Klassifikationssystem wird aus Klassen aufgebaut, die jeweils mit einer Codierung (Schlüssel) zur Identifikation der Klassifikation versehen werden. Ein zu klassifizierendes Objekt kann einer oder mehreren Klassen zugeordnet werden. Allgemein lassen sich Klassifikationssysteme in hierarchische, nicht-hierarchische und hybride Systeme einteilen. Im Folgenden werden die einzelnen Systemarten vorgestellt. Nicht-hierarchische Klassifikationssysteme

Bei nicht-hierarchischen Klassifizierungssystemen sind die einzelnen Stellen des Klassifizierungsschlüssels voneinander unabhängig. Im Beispiel aus Abb. 5-25 wird jedem zu klassifizierenden Objekt ein zweistelliger Schlüssel zugeordnet. Dieser beschreibt ein Objekt bezüglich seines Gewichtes und seiner Fertigungsart. Da die Stellen des Schlüssels voneinander unabhängig sind, bedeutet eine Codierung „2“ an der zweiten Stelle des Schlüssels immer, dass es sich um ein Normteil handelt. Dies ist unabhängig davon, ob es sich um ein leichtes oder ein schweres Teil handelt.

5.6 Finden statt Suchen 137

Abb. 5-25: Nicht-hierarchisches Klassifikationssystem Hierarchische Klassifikationssysteme

Im Gegensatz zu den nicht-hierarchischen Systemen sind bei den hierarchischen Klassifikationssystemen die Stellen des Schlüssels voneinander abhängig, d.h. die Bedeutung einer Codierung an einer Stelle hängt von der Codierung einer anderen Stelle ab. Die Abb. 5-26 zeigt ein Beispiel für ein hierarchisches Klassifikationssystem.

Abb. 5-26: Hierarchisches Klassifikationssystem

138

5 Leithefte zu PLM-Aspekten

Bei dem dargestellten Klassifikationssystem handelt es sich ebenfalls um einen zweistelligen Klassifikationsschlüssel. Im Gegensatz zu nichthierarchischen Klassifikationssystemen ist jedoch die Bedeutung der Codierung der zweiten Stelle abhängig von der Codierung der ersten Stelle. Eine Codierung „1“ an der zweiten Stelle kann sowohl ein Zahnrad als auch ein Kugellager auszeichnen. Der Schlüssel „0-1“ entspricht einem eigengefertigten Zahnrad. Der Schlüssel „1-1“ bedeutet hingegen, dass es sich um ein fremdgefertigtes Kugellager handelt. Hybride Klassifikationssysteme

Neben den rein hierarchischen und den rein nicht-hierarchischen Klassifikationssystemen gibt es zudem Mischformen, sog. hybride Klassifikationssysteme.

Abb. 5-27: Hybrides Klassifkationssystem

5.6 Finden statt Suchen 139

Die Stellen eines solchen hybriden Klassifikationssystems sind teilweise voneinander unabhängig, teilweise hängt die Bedeutung einer Codierung von einer anderen Stelle ab. Die Abb. 5-27 zeigt ein Beispiel für ein hybrides Klassifikationssystem. Die Bedeutung der Codierung der zweiten Stelle des dargestellten dreistelligen Klassifikationsschlüssels ist abhängig von der ersten Stelle. Die Codierung der dritten Stelle (Farbe) hat immer die gleiche Bedeutung. Klassifikationstiefe

Bei hierarchischen Klassifikationssystemen ist der Begriff der Klassifikationstiefe von besonderer Bedeutung. Die Klassifikationstiefe beschreibt die Anzahl der Hierarchieebenen, in die ein hierarchisches Klassifikationssystem unterteilt wird. Der Vorteil einer hohen Klassifikationstiefe liegt in der exakteren Beschreibung der zu klassifizierenden Objekte durch den Klassifikationsschlüssel, d.h. die Aussagekraft des Schlüssels nimmt zu. Darüber hinaus ist die Anzahl der Objekte mit gleichen Eigenschaften relativ klein und damit für eine Auswahl schneller überschaubar. Nachteilig ist dagegen der erhöhte Aufwand für die Vergabe des Schlüssels und die Pflege des Klassifikationssystems. 5.6.3 Klassifikationskonzepte aus der Literatur Die allgemeine Zielsetzung von Klassifizierungssystemen ist das Zusammenführen von Objekten mit ähnlichen Merkmalen z.B. das Erkennen von konstruktiven und fertigungstechnischen Ähnlichkeiten von Produkten und deren Komponenten. Somit lässt sich das Auffinden gleicher oder ähnlicher Teile und Baugruppen optimieren, um Neukonstruktionen zu vermeiden und die Wiederverwendung mit oder ohne Anpassungskonstruktion zu unterstützen. Aufgrund der unterschiedlichen Anforderungen der zu klassifizierenden Sachverhalte sind verschiedene Klassifikationssysteme entwickelt worden. Einige im Product Lifecycle Management häufig verwendete Systeme sind das Einzelteil-Verschlüsselungssystem von Opitz, Sachmerkmal-Leisten oder die Klassifikationsschlüssel nach Wiendahl und eClass, die im Folgenden beschrieben werden.

140

5 Leithefte zu PLM-Aspekten

Einzelteil-Verschlüsselungssystem von Opitz

Das Einzelteil-Verschlüsselungssystem von Opitz (Opitz 1971) stützt sich auf die im Laboratorium für Werkzeugmaschinen und Betriebslehre der Technischen Hochschule Aachen (WZL) mit Unterstützung des Vereins Deutscher Werkzeugmaschinenfabriken (VDW) in einer größeren Anzahl von Betrieben durchgeführten Untersuchungen ab. Seine Hauptzielsetzungen sind die Wiederholteilfindung und Teilefamilienbildung. Es soll damit sowohl die Anforderungen des Konstruktions- und Normenbereichs als auch die des Arbeitsvorbereitungs- und Fertigungsbereichs erfüllen. Als Leitmerkmale für die Klassifizierung werden Formmerkmale herangezogen. Sie werden systematisch unter Berücksichtigung statistischer Zusammenhänge bestimmt und gegliedert. Der Klassifizierungsschlüssel nach Opitz ist ein rein numerisches, kombiniertes System, welches sich aus hierarchischen und nichthierarchischen Anteilen zusammensetzt – folglich ein hybrides System. Im Formenschlüssel (siehe Abb. 5-28) werden die Werkstücke entsprechend ihrer Grundform zunächst in die Gruppen Rotations- oder Nichtrotationsteile eingeordnet; innerhalb dieser Gruppen wird nach Abmessungsverhältnissen unterschieden. Rotationsteile werden bevorzugt, da sie nach vorgenannten Untersuchungen die größte Verbreitung im Maschinenbau haben. Zur weiteren Einteilung dienen Außenform, Innenform und Flächenmerkmale. Der Ergänzungsschlüssel enthält zusätzliche für die Klassifizierung notwendige Angaben wie Werkstoff und Genauigkeitsgrade. Die Charakterisierung der Nichtrotationsteile geschieht wie bei den Rotationsteilen nach Endform der Teile. Bei ihnen wird jedoch auch die Ausgangsform des Rohteils mit beachtet, da die bearbeiteten Flächen alleine zur Beschreibung der Werkstücke dieser Teileklassen nicht ausreichen. Allerdings ist eine Zusammenfassung von Teilen mit gleichen Fertigungsverfahren oder Arbeitsvorgangsfolgen mit diesem Klassifikationssystem nicht möglich. Der Opitz-Schlüssel besitzt einen klaren und übersichtlichen Aufbau, ein breites Anwendungsfeld und ist im produzierenden Gewerbe weit verbreitet. Der Schlüssel ist durch einen klaren und übersichtlichen Aufbau gekennzeichnet. Zur weiteren Einteilung dienen Außenform, Innenform und Flächenmerkmale. Der Klassifikationsschlüssel ist als Vorschlag gedacht und wird betriebsspezifisch aufgebaut.

5.6 Finden statt Suchen 141

Abb. 5-28: Klassifikationsschlüssel nach Opitz

142

5 Leithefte zu PLM-Aspekten

Sachmerkmalleiste nach DIN 4000

Die Sachmerkmalleiste nach DIN 4000 ist ein Verschlüsselungsprinzip zur direkten Umsetzung von charakteristischen Merkmalen bzw. Daten in eine von Suchalgorithmen verarbeitbare tabellarische Form. Die Gesamtmenge der Objekte wird in Klassen (sog. Gegenstandsgruppen) gruppiert, was z.B. über einen Grobklassifizierungsschlüssel geschehen kann. Die Klassen beinhalten Objekte wie z.B. Bauteile gleicher oder ähnlicher Funktion, Gestalt oder Werkstoff. Typische Begriffe der Sachmerkmalleisten (SML) sind: x Merkmal: Merkmale sind bestimmte Eigenschaften, die zum Beschreiben und Unterscheiden von Gegenständen dienen. x Sachmerkmal : Ein Sachmerkmal ist ein Merkmal, das Gegenstände unabhängig vom Umfeld (z.B. Herkunft, Verwendung) beschreibt. x Sachmerkmalname: Ein Sachmerkmalname ist die Identifikation eines Einzelmerkmals innerhalb einer Sachmerkmalleiste z.B. DURCHMESSER, LÄNGE etc. DIN 4000 verwendet als Identifikator einen Sachmerkmalkennbuchstaben. x Sachmerkmalausprägung: Eine Sachmerkmalausprägung ist je nach Art des Sachmerkmals ein Größenwert oder eine textuelle Information (z.B. eine attributive Angabe). Sachmerkmalausprägungen beschreiben die Eigenschaften von Objekten. x Sachmerkmalleiste: Eine Sachmerkmalleiste ist die Zusammenfassung aller relevanten Sachmerkmale einer Gruppe von Objekten/Gegenständen. x Gegenstandsgruppe: Eine Gegenstandsgruppe ist eine durch gemeinsame Sachmerkmale bestimmte Gruppe artverwandter Objekte/Gegenstände z.B. Wellen, Platten, Spiralbohrer. Eine Gegenstandsgruppe besitzt eine Sachmerkmalleiste.

5.6 Finden statt Suchen 143

Abb. 5-29: Sachmerkmalleiste mit Parallelverschlüsselung am Beispiel eines Fräsers

144

5 Leithefte zu PLM-Aspekten

Abb. 5-30: Vererbungshierarchie von Sachmerkmalleisten

Die Abb. 5-29 stellt den Aufbau einer SML an einem Beispiel dar. Es zeigt sich allerdings, dass die charakteristischen Merkmale oftmals zusätzlich in einer Skizze definiert werden müssen, um ein einheitliches Verständnis der Merkmale zu gewährleisten. Dies zeigt jedoch gleichzeitig einen Weg auf, wie aus Informationen eines CAD-Modells bzw. einer Zeichnung Sachmerkmale automatisch gewonnen und in eine SML überführt werden können. Betrachtet man verschiedene CAD-Modelle bzw. Zeichnungen, lassen sich darin gleichartige geometrische Strukturen identifizieren, aus denen sich charakteristische Merkmale herausfiltern lassen. Durch den hierarchischen Aufbau von Sachmerkmalleisten wird eine flexible Klassenbildung ermöglicht (Grabowski et al. 2002). So können SML übernommen und durch weitere Merkmale ergänzt werden. Diese Methode wird auch Vererbung genannt (siehe Abb. 5-30). Sachmerkmalleisten bringen vor allem dann Vorteile, wenn viele Gruppen von Objekten (Gegenstandsgruppen) mit sehr unterschiedlichen Eigenschaften zu beschreiben sind. Die Voraussetzung dafür ist, dass jeder Gegenstandsgruppe individuelle Merkmale zugeordnet werden können, welche anderen Gruppen nicht zwangsläufig auch belegen müssen. Eine Aufnahme in den Stammsatz scheidet damit von vornherein aus. Vielmehr wird eine neue Objektklasse

5.6 Finden statt Suchen 145

für Gegenstandsgruppen eingeführt. Diese beschreiben jeweils eine Gruppe ähnlicher Objekte, die sich durch gleiche Attribute auszeichnen. Jede Gruppe wird mit Gruppennamen, dem Klassencode und einer Reihe weiterer Eigenschaften beschrieben. Zusätzlich ist es möglich, jeder Gruppe beliebig viele Attributdefinitionen (Sachmerkmale) zuzuordnen. Dies sind Sachmerkmale, welche alle Mitglieder der jeweiligen Gruppe besitzen. Sie sind neben einer Identifikation (Kennbuchstabe) und einer Benennung auch durch den Datentyp (z.B. numerisches oder alphanumerisches Attribut) festgelegt (Eigner u. Stelzer 2001). Eine SML nach DIN 4000 ist „…die formalisierte Zusammenstellung und Anordnung von relevanten Sachmerkmalen einer Gegenstandsgruppe“ (DIN 4000). Nach DIN 4000 besteht die vierstufige Hierarchie von der Wurzel bis zu den Blättern des Klassifikationsbaums aus der Klassifikation selbst (Stufe 1), den Gegenstandsgruppen (Stufe 2), den Teilefamilien (Stufe 3) und schließlich aus den Teilen (Stufe 4). Ferner besitzt jeder Knoten innerhalb der vierstufigen Hierarchie einen Schlüssel, über den der Knoten im Rahmen der Klassifikation nach DIN 4000 eindeutig identifizierbar ist. Sachmerkmalleisten greifen auf Stufe 3, den Teilefamilien, und beschreiben alle Mitglieder einer Teilefamilie durch Attribute und Attributwerte. Eine SML kann als ein spezieller zweistufiger, attributierter Klassifikationsbaum – gerechnet ab der Stufe 3 des Klassifikationsbaumes nach DIN 4000 – aufgefasst werden. Die Stufen 1 und 2 sind dagegen nicht mit Attributen versehen. eClass

eClass ist ein vom „Institut für deutsche Wirtschaft Köln“ zur Materialklassifizierung und Warengruppenbildung initiiertes Klassifizierungssystem, das vor allem im elektronischen Handel Verbreitung findet. Es handelt sich bei eClass um ein hierarchisches Klassifizierungssystem, das in vier Ebenen unterteilt ist: Sachgebiete, Hauptgruppen, Gruppen und Untergruppen. Die erste Hierarchieebene ist dabei in 22 Sachgebiete gegliedert. Es eignet sich für die Klassifizierung von Produkten, Dienstleistungen, Waren und Materialien. eClass dient als gemeinsame „Sprache“ zwischen dem Einkäufer und dem Lieferanten. Der vierstufige, hierarchische Klassifikationsschlüssel von eClass besitzt ein aus ca. 14.000 Begriffen bestehenden Schlagwortregister. Unter den eClass-Hierarchiestufen sind Sachgebiete, Hauptgruppen, Gruppen und Untergruppen zu verstehen. Für jede der vier Stufen stehen zwei Stellen zur Verfügung, somit sind pro Klasse 99 Ebenen denkbar (siehe Abb. 5-31).

146

5 Leithefte zu PLM-Aspekten

Abb. 5-31: Beispiel für Klassifizierung nach eClass

Mittels Merkmalleisten lassen sich Materialien und Dienstleistungen beschreiben. Diese stehen als Zusammenfassung der spezifischen Produktmerkmale an den hierarchischen Endpunkten der Klassifizierung (z.B. „27-20-02-01: Handthermometer“). Die Merkmalleisten, die in eClass verwendet werden, bauen auf Vorgaben der DIN EN 61360 sowie der Normenreihe ISO 13584 auf. Einsatzgebiete von eClass sind neben einem branchenübergreifenden, internationalen Materialgruppen-Management, Online-Kataloge sowie Online-Ausschreibungen. Das System befindet sich in der Entwicklung unter stetiger Einarbeitung von Anforderungen aus der Industrie. Beim Aufbau der eClass-Klassenhierarchie wurden sowohl technische Zusammenhänge als auch kaufmännische Aspekte berücksichtigt. Das heißt, die oberen Ebenen (Sachgebiet, Hauptgruppe, Gruppe) bilden neben technischen Zusammenhängen auch Beschaffungsmärkte ab. Daher kann eClass eingesetzt werden, um auf Grundlagen der Klassifikation Warengruppen zu definieren. Zu vielen achtstelligen Klassifikationsnummern sind SachmerkmalLeisten nach DIN 4000 angefügt, die in Abhängigkeit vom Produkt oder von der Dienstleistung mit einem unterschiedlichen Feinheitsgrad detailliert werden können. Durch den Zugang über Klassenhierarchie oder Schlagworte kann sowohl der Experte als auch der gelegentliche Nutzer in der Klassifikation navigieren. Besonders hervorzuheben ist die Integration von Materialien und Dienstleistungen. Klassifikationsschlüssel nach Wiendahl

5.6 Finden statt Suchen 147

Der Wiendahl-Schlüssel ist ein hybrides Klassifikationssystem zur Verschlüsselung allgemeiner Baugruppen. Die kurzfristige Zielsetzung der Baugruppenklassifizierung ist: x Eine Rationalisierung der Auftragsabwicklung durch Wiederverwenden vorhandener Unterlagen x Eine Rationalisierung der Fertigung und Montage durch Zusammenführen ähnlicher Teile und Gruppen Die langfristige Zielsetzung zeichnet sich wie folgt aus: x Erhöhung der Wiederverwendungsrate und Verbesserung der Produkte durch Standardisierung sowie Entwicklung von Baukastensystemen und Wertanalysen x Synthese neuer Produkte mit Hilfe von morphologischen Methoden x Erstellung von Planungsdaten für Baugruppen x Entwicklung von Standard-, Arbeits- und Montageplänen x Teilefamilienfertigung x Errichtung von Sonderfertigungsstätten x Bildung von Montagefamilien Wie der Opitz-Schlüssel ist der Wiendahl-Schlüssel ein rein numerisches Ordnungssystem. Das primäre Kriterium für die Einteilung einer allgemeinen Baugruppe ist deren Funktion. Sie gliedert sich in eine Hauptfunktion (Funktionsoberbegriff) und eine Grundfunktion. Als Funktionsbezeichnung werden einheitliche Funktionsbegriffe eingeführt, wobei sechs Hauptfunktionen und 33 Grundfunktionen definiert werden können. Im Anschluss an die Funktionsbeschreibung wird die Baugruppe selbst mit einem allgemeinen Gruppenbegriff (zugehörige Funktionsgruppe) angesprochen. Daran schließen sich dann Beschreibungsmerkmale (charakteristische Daten) an, die für jede Grundfunktion verschieden sind. Der so genannte Ergänzungsschlüssel mit Informationen über „größte Abmessung“, „Anzahl der Hauptteile“ (d.h. Anzahl der verschiedenen Teile ohne Verbindungselemente, wie z.B. Schrauben, Stifte, Scheiben etc.) und „Fertiggewicht“ beschließt die Klassifizierung. Die Vorteile des Opitz- und Wiendahl-Schlüssels können erheblich sein. Für die Klassifizierung selbst ist jedoch ein erheblicher Mehraufwand erforderlich, da jedes Objekt von fachkundigem Personal zu verschlüsseln ist. Die richtige Anwendung setzt Richtlinien für die genaue Interpretation der Merkmale voraus. Da viele Besonderheiten berücksichtigt werden müssen, sind die Richtlinien im Allgemeinen umfangreicher als die Klassifikation selbst (Eigner u. Stelzer 2001) (Grabowski et al. 2002) (Schichtel 2001).

148

5 Leithefte zu PLM-Aspekten

5.6.4 Voraussetzungen für die Klassifikation Klassifikationssysteme entstanden aus der Notwendigkeit heraus, Sachverhalte möglichst kurz zu beschreiben. Dazu werden aufgrund ausgewählter Eigenschaften Klassen gebildet und Beziehungen zwischen diesen definiert. Eine Klasse dient der Beschreibung einer Menge von Elementen oder Objekten mit mindestens einer gemeinsamen Eigenschaft. In der Regel werden geometrische oder physikalische Eigenschaften, so genannte Attribute, beschrieben (z.B. hat eine Schraube die Attribute Länge und Gewindedurchmesser). Klassen können strukturiert und die ihnen zugeordneten Attribute an Unterklassen weitervererbt werden. Die Attribute für ein Klassifizierungssystem werden zentral im Attribute-Pool angelegt und verwaltet. Bei der Zuordnung der Attribute zu den definierten Klassen können diese Attribute aus dem Pool ausgewählt werden. Den Attributen werden bei der Instantiierung der Klasse so genannte Attributwerte zugeordnet, welche exakte Werte, "Bereichswerte" (Maximum-Minimum-Wert) oder Formeln sein können. Die Instantiierung einer Klasse (Ausprägung eines Objektes) bedeutet dabei, dass ein konkretes Objekt, das allgemeingültig durch die Klasse beschrieben wird, mit seinen individuellen Attributwerten spezifiziert wird. Bei der Wertangabe wird deren Gültigkeit für das entsprechende Attribut überprüft. Beispiele für Attribute der Klasse Bauteil sind Funktionsbeschreibungen, Gestalt, Material, Freigabedatum, Version etc. Klassifizierte Objekte lassen sich durch eine Suche über die Attribute oder durch absuchen der Klassifizierungshierarchie identifizieren. Beispiele für Klassifizierungshierarchien sind öffentliche (z.B. DIN-)Normen, Werksnormen etc. Wichtig sind Kriterien, nach denen man Objekte gruppieren kann. Im Beispiel in Abb. 5-32 wird gezeigt, dass eine Menge von Objekten nach drei verschiedenen Gesichtspunkten klassifiziert werden kann: x Nach geometrischer Form – Kreis, Dreieck oder Viereck x Nach der Größe – kleine und große Figuren x Nach der Farbe – schwarze, weiße und graue Figuren

5.6 Finden statt Suchen 149

Abb. 5-32: Klassifikationsbeispiel

Wenn eine Gruppe von Objekten wiederum nach bestimmten Eigenschaften aufteilt wird, können so genannte Teilmengenhierarchien oder Klassifikationsbäume aufgebaut werden. Im Beispiel ist die Gruppe Kreise in zwei weitere Gruppen unterteilt – große und kleine Kreise. In heutigen Unternehmen ändern sich die Anforderungen an Produkte sehr schnell, und die Produktpalette muss ständig erneuert und erweitert werden. Diesbezüglich muss sich auch das Klassifikationssystem dynamisch ändern. Wenn aus einer Gruppe eine Teilgruppe von Elementen abspaltet und neue Unterteilgruppen gebildet wird, wird vom Spezialisieren gesprochen und umgekehrt, wenn zwei oder mehrere Teilgruppen in eine zusammenfügt wird, dann wird diese Gruppen generalisiert. 5.6.5 Klassifikation im Product Lifecycle Management Der Vorteil für das Auffinden von Informationen durch die Anwendung eines Klassifizierungssystems kann erheblich sein, was sich jedoch erst in

150

5 Leithefte zu PLM-Aspekten

einem mittel- bis langfristigen Zeitraum auszahlt. Für die Klassifizierung ist allerdings auch ein Mehraufwand zu leisten, da jede Baugruppe bzw. jedes Bauteil zu klassifizieren ist. Die wesentlichen Anwendungsfälle der Klassifikation sind: x x x x x

Aufbereitung von Grunddaten Strukturierung von Daten Vermeidung von Dubletten eine Anbindung an Produktkataloge der Zulieferer oder DIN-Blätter Klassifikation eines Bauteils nach Abschluss der Konstruktion

Die meisten Integrationssysteme wie beispielsweise PDM-Systeme verfügen über Funktionen zur Unterstützung der Klassifikation. Inzwischen gibt es auf dem Markt Systeme zur automatischen Klassifikation von Produktdaten, die diese Systeme um entsprechende Funktionen ergänzen. Die methodischen Vorteile, die sich durch den Einsatz von automatischer Klassifikation ergeben sind (Weißkopf 2002): x x x x

Klassifikation über Applikationsgrenzen hinweg Minimierung des Klassifikationsaufwandes Sicherstellung von fehlerfreien Klassifikationsergebnissen Mehrfachklassifikation von Bauteilen

5.6.6 Umsetzung der Klassifikation Die Einführung eines Klassifizierungssystems dient dem Zweck den Mitarbeitern das Auffinden von Informationen zu erleichtern. Aus diesem Grund muss das Klassifizierungssystem so definiert werden, dass es im Rahmen der Möglichkeiten des verwendeten PLM-Systems genau diesen Zweck erfüllt. Damit besteht der erste Schritt darin, die zu klassifizierenden Informationen zu analysieren. Ziel der Analyse ist die Identifikation von Bauteilen mit ähnlichen Eigenschaften. Am Beispiel von Getrieben wird im Folgenden ein exemplarisches Klassifikationssystem aufgebaut. Die Systemvoraussetzungen des verwendeten PDM-Systems erlauben beispielsweise eine beliebige Hierarchietiefe für die Klassifikationsstruktur, Merkmale bis 48 Zeichen Länge mit max. 10 unterschiedlichen Werten pro Merkmalsinstanz mit der Möglichkeit, Vorgaben für Merkmalswerte zu definieren. Zudem erlaubt dieses System eine beliebige Hierarchietiefe für die Klassifikationsstruktur, Merkmale bis 255 Zeichen Länge ebenfalls mit der Möglichkeit, Vorgaben für Merkmalswerte zu definieren.

5.6 Finden statt Suchen 151

Abb. 5-33: Beispielhafte Klassifikationsstruktur für Getriebe

Die Klassenstruktur sollen sowohl die Getriebe als die wichtigsten Einzelteile aufnehmen können. 1. Stufe: Abstrakte Klassen „Getriebeteile“ und „Getriebe“: Diese beiden Klassen enthalten alle Merkmale die in den jeweiligen Unterklassen ebenfalls vorkommen, und an diese vererbt werden. Es können keine Bauteile diesen Klasse direkt zugeordnet werden, sondern nur in den Klassen der 2. Stufe. 2. Stufe: Klassen „Schneckengetriebe“ „Kegelradetriebe“, „Stirnradgetriebe“ und „Planetengetriebe“, sowie „Zahnrad“ und „Welle“: Diese Klassen erben die Merkmale der übergeordneten Klassen. Die Merkmalsdefinitionen in Abb. 5-33 zeigen die Klassenstruktur und Merkmale mit deren Datentypen und erlaubten Merkmalswerten.

152

5 Leithefte zu PLM-Aspekten

Weiterführende Literatur

Grabowski H, Lossack R-S, Weißkopf J (2001) Datenmanagement in der Produktentwicklung. Fachbuchverlag, Leipzig Normen und Standards

DIN 4000 Teil 1 enthält die Begriffe und Grundsätze zu Sachmerkmal-Leisten. Alle weiteren Teile enthalten genormte Sachmerkmal-Leisten bestimmter Bauteilklassen, z.B. Schrauben, Muttern, Scheiben und Ringe usw. DIN EN 61360 Genormte Datenelementtypen mit Klassifikationsschema für elektrische Bauteile. Teil 1 enthält Definitionen, Regeln und Methoden. ISO 13584 Industrielle Automatisierungssysteme und Integration - Teilebibliothek Teil 1 der Norm beinhaltet einen Überblick und Grundlagen und Teil 42 die Methodik für die Strukturierung von Teilefamilien. EAN (European Article Numbering) System, EAN International Assoc. Produktnummernsystem für das Barcoding und die Materialwirtschaft. Internet: http://www.ean-int.org UPC (Universal Product Code), Uniform Code Council, Inc.: Produktnummernsystem. UPC ist das Gegenstück von EAN in den USA und Kanada Internet: http://www.uc-council.org SIC (Standard Industry Classification), U.S. Department of Labor: Der SIC ist ein vierstelliges Klassifikationssystem von Industrien für statistische Zwecke. SIC wurde 1987 erstellt. Internet: http://www.osha.gov/pls/imis/sic_manual.html NAICS (North American Industry Classification System), U.S. Census Bureau: sechsstellige Erweiterung des SIC-Systems um weitere Industrien. NAICS ist 1997 in den USA eingeführt worden. Internet: http://www.census.gov/epcd/www/naicscod.htm UNSPSC (United Nations Standard Products and Services Code): Der UNSPSC stellt einen offenen, globalen branchenübergreifenden Standard für die Klassifikation von Produkten and Dienstleistungen dar. Internet: http://www.unspsc.org The Thomas Register: Das Thomas Register unterhält ein umfassendes privates Produktklassifikationsschema. Alle Produkte der Mitglieder sind dort kategorisiert und verzeichnet. Internet: http://www.thomasregister.com

5.7 Prozesse gestalten und steuern 153

5.7

Prozesse gestalten und steuern

Æ Freigabe- und Änderungswesen Æ Applikationsintegration Durch die zunehmende Komplexität der Abläufe und Informationsbeziehungen sind Unternehmensprozesse oft nicht mehr genügend transparent, um sie effizient planen, steuern und überwachen zu können. Konzepte zur Parallelisierung und Verteilung von Entwicklungsaufgaben zur Verkürzung der Entwicklungsdauer, wie Concurrent and Simultaneous Engineering, stellen zusätzliche Anforderungen an die Organisation der Entwicklungsprozesse. Die Beherrschung der Unternehmensabläufe beeinflusst somit wesentlich die Wettbewerbsfähigkeit eines Unternehmens. Zur Optimierung von Prozessen und Organisation muss die Planung der Informationsverarbeitung und die Automatisierung von Prozessen als Bestandteil der strategischen Unternehmensführung berücksichtigt werden. Dies gilt insbesondere für Prozesse, die mit der Entwicklung, Produktion bis hin zu Vertrieb und Wartung von Produkten über deren gesamten Lebenszyklus in Verbindung stehen, da alle Bereiche eines Unternehmens daran beteiligt sind und meist außerdem Kunden und Lieferanten mit einbezogen werden müssen. Für die optimale Gestaltung der Prozesse und Strukturen des Product Lifecycle Managements ist daher eine umfassende Betrachtung der Organisationsstrukturen und Prozesse im Unternehmen sowie der Beziehungen zu externen Unternehmen erforderlich. Da heute in der Regel Informationssysteme eingesetzt werden, um eine Optimierung von Prozessen zu erreichen, ist es besonders wichtig, dass diese Informationssysteme speziell die spezifischen Prozesse eines Unternehmens unterstützen und entsprechend angepasst werden können. Die verantwortlichen Mitarbeiter in den Unternehmen stehen daher vor der Aufgabe, Unternehmensprozesse zu analysieren, zu dokumentieren und im Bedarfsfall darüber hinaus zu optimieren. Hierfür haben sich die Unternehmensmodellierung und der Einsatz unterstützender Softwarewerkzeuge bewährt, da sie helfen, eine konsistente, formale Beschreibung des Unternehmens zu erstellen. Basierend auf diesem formalen Prozessmodell lassen sich unterschiedliche Sichtweisen darstellen, die durch eine Fokussierung auf Teilaspekte des Unternehmensmodells die Übersichtlichkeit und das Verständnis von Prozessen und Organisation verbessern. Eine Dokumentation der Unternehmensprozesse mit Hilfe eines Unternehmensmodells kann darüber hinaus für die Zertifizierung der Qualitätssicherung nach DIN ISO 9000 genutzt werden.

154

5 Leithefte zu PLM-Aspekten

5.7.1

Prozess- und Organisationsmanagement

Das Prozess- und Organisationsmanagement umfasst die konzeptionelle Gestaltung der Abläufe und Strukturen eines Unternehmens. Häufig wird hierfür – insbesondere von Systemanbietern – auch der Begriff WorkflowManagement verwendet.

Abb. 5-34: Prozess- und Organisationsmanagement im PLM

5.7 Prozesse gestalten und steuern 155

In diesem Buch wird der Begriff Workflow-Management als Teil des Prozess- und Organisationsmanagements gesehen und umfasst die informationstechnisch unterstützte Steuerung von betrieblichen Abläufen. Typische Prozesse bzw. Workflows, die recht häufig im Rahmen eines Product Lifecycle Managements überarbeitet und optimiert werden, sind das Freigabe- und Änderungsmanagement, Prüfabläufe, Statusmanagement und die kollaborative Produktentwicklung (siehe Abb. 5-34). In diesem Leitheft liegt jedoch der Schwerpunkt auf die allgemeine Betrachtung des Prozess- und Organisationsmanagements. 5.7.2

Unterstützung von Prozessen und Organisation

Die gewachsene Informationslandschaft eines Unternehmens ist geprägt von den aktuell gelebten Prozessen, dem Fluss von sowohl physischen als auch digitalen Dokumenten durch die Unternehmensbereiche und den verwendeten Hilfsmitteln sowie der organisatorischen Struktur des Unternehmens (Gruppen, Abteilungen und Bereiche). Grundlage einer Optimierung der Informationslandschaft kann daher nur eine ganzheitliche Sicht auf das Unternehmen sein, um zusammenhängende Prozesse zu erkennen, zu optimieren und durch geeignete Informationssysteme zu unterstützen. Für die Dokumentation und Analyse von Geschäftsprozessen und Organisationsstrukturen werden Unternehmensmodelle erstellt, mit deren Hilfe die komplexen Zusammenhänge übersichtlich beschrieben werden können. Werkzeuge zur Unternehmensmodellierung unterstützen verschiedene Sichten (siehe Kap. 3) auf das Unternehmen, wie z.B. Datensicht, Organisationssicht, Prozesssicht, konsistent nebeneinander zu erstellen und weiterzuentwickeln. Der Entwicklungsfortschritt und die Verwendung jeder Produktkomponente und jedes produktbeschreibenden Dokumentes wird im Produktlebenszyklus durch bestimmte Aktivitäten beschrieben, welche die Freigaben, die Änderungen oder die Status eines Dokuments festlegen. Die Verknüpfungen einzelner Aktivitäten miteinander in Form von Vorgängerund Nachfolgerbeziehungen bilden Prozesse, an denen verschiedenste Personen aus unterschiedlichen Abteilungen beteiligt sind. Für die Darstellung von Prozessen werden üblicherweise Aktivitätsdiagramme genutzt. Im Mittelpunkt hierbei steht die (gegebenenfalls verzweigende) Abfolge von Aktivitäten. Darüber hinaus können die Aktivitäten verknüpft werden mit Organisationseinheiten, die für die Ausführung der Aktivität verantwortlich ist, mit unterstützenden IT-Systemen und mit Informationen, die als Eingang benötigt werden und als Ausgang erzeugt werden.

156

5 Leithefte zu PLM-Aspekten

Eine andere Möglichkeit der Prozessbetrachtung ist eine dokumentenzentrierte Sichtweise oder allgemeiner eine Betrachtung des Informationsflusses. Hierbei wird die Weitergabe einer bestimmten Information – meist in Form von Dokumenten – von einer Abteilung oder einem Mitarbeiter an die nächste Organisationseinheit betrachtet. Die Weitergabe von Informationen zu einer anderen Organisationseinheit führt üblicherweise zu einem Wechsel des Status des Dokuments. Zur Dokumentation dieser Sichtweise werden daher häufig sog. Statusnetze eingesetzt. Der Übergang zwischen zwei Status wird durch eine Aktivität ausgelöst, z.B. wird der Status einer Konstruktionszeichnung vom Status „in Prüfung“ in den Status „freigegeben“ durch die Aktivität „Zeichnung freigeben“ überführt. Durch die Zuordnung von Aktivitäten zu Statusübergang entsteht eine Verknüpfung zwischen Statusdiagrammen und Aktivitätsdiagrammen. Zur informationstechnischen Unterstützung von Geschäftsprozessen können Workflow-Managementsysteme eingesetzt werden, in denen die Prozesse abgebildet werden. Der vom Workflow-Managementsystem gesteuerte Prozess mit seinen Prozessschritten, verknüpft mit den zuständigen Ressourcen bzw. Personen, bildet den so genannten Workflow. Workflow-Managementsysteme können sowohl eigenständige Systeme als auch Module von Integrationssystemen sein. Die Grundidee eines WorkflowManagementsystems besteht in der Trennung der administrativen Tätigkeiten Planung, Steuerung und Kontrolle von Prozessen, die vom System unterstützt werden, von der eigentlichen Aufgabendurchführung. Ein Workflow-Managementsystem steuert die Bearbeitung eines Prozesses, indem es die einzelnen Aktivitäten mit den benötigten Ressourcen (Mitarbeiter und Werkzeuge) verbindet und entsprechend der Verkettung der Aktivitäten deren Durchführung überwacht und protokolliert. Ein Benachrichtigungsdienst stellt sicher, dass ein betroffener Nutzer in einfacher Weise die Information erhält, dass er bestimmte Aufgaben durchzuführen hat. Gleichzeitig mit den Informationen zur Aufgabenstellung erhält der Bearbeiter auch Informationen über alle betroffenen Dokumente und den Zugriff auf diese. Der Benachrichtigungsdienst kann im WorkflowManagementsystem integriert sein. In den meisten Fällen wird er jedoch an externe Mailing-Systeme angebunden sein. Nach Abschluss einer Aktivität erfolgt eine Rückmeldung im System, wodurch die nachfolgende Aktivität angestoßen wird. Zusätzlich kann für eine Aktivität ein Fertigstellungstermin oder Bearbeitungszeitraum festgelegt werden, nach dessen Überschreiten das Workflow-Managementsystem weitere Personen, wie den Vorgesetzten des zuständigen Mitarbeiters oder einen Projektverantwortlichen, automatisch über die Terminüberschreitung informiert.

5.7 Prozesse gestalten und steuern 157

Die im Prozess verarbeiteten Informationen sind üblicherweise Artikel und/oder Dokumente. Alle zu einem Workflow gehörenden Artikel und Dokumente können zur einfacheren Handhabung in einer so genannten Mappe zusammengefasst werden. Eine Mappe ist ein Informationsobjekt, das Referenzen auf andere Objekte (Artikel, Dokumente etc.) speichert. Eine Mappe lässt sich durch eine eindeutige ID – eine eindeutigen Nummer oder einen eindeutigen Namen identifizieren. Innerhalb eines Workflows kann nun die Mappe zwischen den einzelnen Arbeitsschritten weitergereicht werden. Entlang des Workflows haben hierdurch die Bearbeiter immer die Information, mit welchen Dokumenten und/oder Artikeln die Kollegen vorher gearbeitet haben. Darüber hinaus können sie weitere Dokumente und/oder Artikeln hinzufügen. Das Prinzip der Mappe bietet folgende Vorteile: Zunächst bietet die Mappe den Vorteil, dass alle für einen bestimmten Prozess relevanten Objekte beschrieben sind und damit in nachfolgenden Schritten vermieden wird, dass mit den falschen Dokumenten und/oder Artikeln gearbeitet wird oder Dokumente/Artikel übersehen werden, die eine Relevanz besitzen. Zudem lässt sich die Ausführung bestimmter Methoden gemeinsam auf alle Objekte ausführen statt auf alle Objekte einzeln (verbunden mit der Gefahr, die Ausführung bei einem Objekt zu vergessen). Ein Beispiel für eine solche Methode ist bei der Abarbeitung eines Änderungsauftrags die Überführung aller betroffenen Objekte, die in der Mappe enthalten sind, in den Status „in Änderung“. Schließlich bietet eine Mappe den Vorteil, dass in jedem Arbeitsschritt mit aktuellen Informationen gearbeitet wird. Da in der Mappe nur Referenzen gespeichert sind, nicht jedoch die eigentlichen Objekte selbst, werden Aktualitätsprobleme vermieden, die bei der Weitergabe von Dokumenten z.B. per E-Mail entstehen. Ein typische Beispiel eines solchen Aktualitätsproblem ist folgendes: Ein Bearbeiter bekommt per E-Mail ein Dokument, das er Weiterbearbeiten soll. Er kommt nicht sofort dazu, dies zu tun, sondern erledigt zuvor andere offene Aufgaben. Inzwischen hat ein anderer Kollege parallel an dem Dokument weitere Änderungen vorgenommen. Öffnet der Bearbeiter nun das Dokument, das er per E-Mail bekommen hat, beginnt er seine Arbeit auf einem nicht mehr aktuellen Stand. 5.7.3

Kenntnis von Prozess- und Organisationsstrukturen

Für die Gestaltung von Informationssystemen zur Unterstützung der Geschäftsprozesse und Organisation hat sich die Unternehmensmodellierung als geeignetes Werkzeug erwiesen. Im Rahmen der Modellierung analy-

158

5 Leithefte zu PLM-Aspekten

sierte und gegebenenfalls neu strukturierte Unternehmensprozesse bilden die Basis für die Konzeption und Implementierung von Integrationssystemen zur Unterstützung der betrieblichen Abläufe im Produktlebenszyklus. Zudem unterstützt die Unternehmensmodellierung die Bildung einer unternehmensweit einheitlichen Begriffswelt. Dadurch ermöglicht ein Unternehmensmodell eine engere Zusammenarbeit von Prozessverantwortlichen und Systementwicklern, da Unternehmensabläufe die Betrachtungsweisen von im Prozess stehenden Personen und Systementwicklern zusammenbringen. Sie ermöglichen einerseits die Beurteilung der Effizienz von Abläufen, ihrer Zielausrichtung und der Aufgaben einzelner Mitarbeiter durch den Prozessverantwortlichen. Die Beschreibung von zukünftigen Prozessen (Sollprozessen) stellt darüber hinaus eine zentrale Information dar, die in keinem Lastenheft für ein zu entwickelndes oder anzupassendes Informationssystem fehlen darf. Anforderungen können direkt aus den durch Software zu unterstützenden Unternehmensabläufen abgeleitet werden. Dies ermöglicht die individuelle Anpassung der zu entwickelnden Software an die Bedürfnisse der Anwender.

Abb. 5-35: Anwendungsmöglichkeiten von Unternehmensmodellen

5.7 Prozesse gestalten und steuern 159

Voraussetzung hierfür ist jedoch ein sowohl informatives und für Ungeübte verständliches als auch präzises Unternehmensmodell, welches das Zusammenspiel von Prozessen, Tätigkeiten, Informationen, Mitarbeitern und unterstützender Informationstechnologie geeignet beschreibt (Weber 1997). Unternehmensmodelle können für unterschiedlichste Zwecke verwendet werden. Grundsätzlich lassen sich, wie in Abb. 5-35 dargestellt, die Anwendungsmöglichkeiten von Unternehmensmodellen in Planung, Dokumentation und Anwendungen einteilen. Unternehmensmodelle stellen somit eine enorme Wissensbasis in Bezug auf die Unternehmensorganisation und -abläufe dar, und es lässt sich folgender Nutzen aus ihnen ziehen (Milde 1997): x Die prozessorientierte Betrachtung des Zusammenwirkens von betrieblichen und überbetrieblichen Organisationseinheiten wird ermöglicht. x Eine rasche Anpassung an sich ändernde Randbedingungen kann erfolgen. x Eine stärkere Kundenorientierung des Unternehmens wird unterstützt. x Eine leicht verständliche und präzise grafische Darstellung von Prozessen unterstützt die Diskussion des Ist-Zustandes und der Auswirkungen möglicher Optimierungen. x Ein Unternehmensmodell dient als Grundlage für den Aufbau von Qualitätsmanagementsystemen. x Ein Unternehmensmodell ist Basis für die Auswahl, Anpassung und Einführung von Informationssystemen. x Die automatisierte Verteilung von Informationen auf Basis der SollProzesse eines Unternehmensmodells verhindert unnötige Prozessverzögerungen, und die Produktivität kann durch eine kürzere Durchlaufzeit angehoben werden. x Die Mitarbeiterzufriedenheit wird durch die Transparenz und das Verständnis für die unternehmensweiten Abläufe erhöht. 5.7.4 Workflow-Management mit Modellen Das Workflow-Management beschreibt die informationstechnisch unterstützte Ausführung von Prozessen. Hierzu muss der Informationsfluss innerhalb eines Prozesses zwischen den beteiligten Mitarbeitern koordiniert und kontrolliert werden. Ein Workflow-Management-System übernimmt die Aufgabe, Mitarbeiter über anstehende Aufgaben zu informieren und ihnen entsprechende (informatorische) Ressourcen zur Verfügung zu stel-

160

5 Leithefte zu PLM-Aspekten

len. Ergänzend kann ein Workflow-Management-System über MonitoringFunktionalitäten verfügen, mit deren Hilfe Verspätungen im Prozess frühzeitig erkannt und damit korrigierende Maßnahmen eingeleitet werden können. Zudem können automatisierbare Routinetätigkeiten vom System ausgeführt werden. Im Sinne eines verzögerungsfreien Ablaufs stellt die Dokumentenbereitstellung im Zusammenhang mit dem WorkflowManagement sicher, dass zu einem definierten Zeitpunkt (z.B. nach einem Wechsel des Status) die relevanten Personen über die Änderung informiert werden. Eng mit dem Workflow-Management verknüpft ist die Rechteverwaltung, die regelt, welche Person zu einem bestimmten Zeitpunkt welche Tätigkeit ausführen darf, ob sie beispielsweise auf Dokumente zugreifen oder Dokumente neu erzeugen oder ändern darf. Die Art des Zugriffs auf ein Dokument ist dabei von der Aufgabe (z.B. Ändern, Prüfen) und dem Status (z.B. in Bearbeitung, Freigegeben) abhängig. Entsprechende Regeln werden im Prozess festgelegt. Zur Unterstützung der Definition von Workflows hat es sich als hilfreich erwiesen, zunächst ein entsprechendes Unternehmensmodell der Istbzw. Soll-Zustände der entsprechenden Prozesse zu erstellen. Hierzu können verschiedenste Werkzeuge herangezogen werden (siehe Abschnitt 3.2) (Bullinger u. Schreiner 2001). Grundsätzlich sollte ein geeignetes Modell jedoch die folgenden Elemente übersichtlich darstellen und zueinander in Beziehung setzen: x Prozess, Teilprozess, Aktivität: Ein Prozess ist eine Menge von verknüpften Aktivitäten, also Prozessschritten die nicht weiter zerlegt werden können. Um einen Prozess übersichtlicher beschreiben zu können, werden zusammengehörige Mengen von Aktivitäten zu Teilprozessen verknüpft, die wiederum miteinander verknüpft den Gesamtprozess bilden. Auf diese Weise wird eine hierarchische Prozessstruktur aufgebaut. In der Literatur wird der Prozess in einem Unternehmen auch als „Geschäftsprozess“, „Unternehmensprozess“ oder „business process“ bezeichnet. x Eingangs-/Ausgangsinformationsflüsse: Der Prozess wird durch ein Startereignis ausgelöst, wobei seine Aktivitäten in geregelter Abfolge mit Hilfe festgelegter Ressourcen Eingangsinformationsflüsse verarbeiten und als Ergebnis Ausgangsinformationsflüsse liefern. Zur Übermittlung des Eingangsinformationsflusses und zur Auslösung des Prozesses sind zumindest eine Quelle notwendig, sowie ein Ziel, das die Ausgangsinformationsflüsse abnimmt. x Ereignisse: Ereignisse dienen der Beschreibung von Zuständen, die nach Ausführung von Aktivitäten eintreten oder Vorbedingungen für die Ausfüh-

5.7 Prozesse gestalten und steuern 161

rung von Aktivitäten sind. Beispiele für Ereignisse sind „Dringendes Problem aufgetreten“, „Änderungsauftrag liegt vor“ oder zeitliche Bedingungen wie „Jeden Dienstag 9 Uhr“. x Zuständigkeiten: Für die Gestaltung, Ausführung und ständige Verbesserung des Prozesses wird in jedem Prozess bzw. für jede Aktivität eine Organisationseinheit festgelegt. Sie kann eine Abteilung, eine Gruppe, eine Stelle oder eine einzelne Person sein. x Werkzeuge/Ressourcen: Zur Ausführung des Prozesses werden Hilfsmittel benötigt, die bestimmte Tätigkeiten innerhalb des Prozesses unterstützen, um die Ziele eines Prozesses zu erreichen. Dies kann Räumlichkeiten, Maschinen, Anlagen oder Softwaresysteme beinhalten. Neben der Möglichkeit, Unternehmensstrukturen und Prozesse in einfachen Diagrammen auf Papier oder digital in Zeichenwerkzeugen darzustellen, bieten spezialisierte Software-Werkzeuge mit integrierten Unternehmensmodellen Vorteile bei der Erstellung und Nutzung des Modells. Der Unterschied von Modellierungswerkzeugen zu Zeichenwerkzeugen besteht darin, dass Modellierungswerkzeuge tatsächliche Entitäten (Modellobjekte, z.B. eine Organisationseinheit) speichern (üblicherweise in Datenbanken), und diese in Diagrammen grafisch darstellen. Während eine Entität in der Datenbank genau einmal vorkommt und dort auch über seine Attribute beschrieben ist und identifiziert wird, kann es grafisch in mehreren Diagrammen repräsentiert werden. Auf diese Weise lassen verschiedene Diagramme konsistent erstellen.

Abb. 5-36: Sichten auf das integrierte Unternehmensmodell

162

5 Leithefte zu PLM-Aspekten

Ein Diagramm stellt dabei eine bestimmte Sicht auf das Unternehmensmodell dar, wie beispielsweise die Aufbauorganisationssicht oder eine Sicht auf einen bestimmten Prozess. Bei der Erstellung von weiteren Diagrammen können bereits in der Datenbank vorhandene Entitäten in anderem Zusammenhang dargestellt werden. Bei Änderungen muss auf diese Weise nur das jeweilige Element des Modells geändert werden, sodass in den Diagrammen bzw. Sichten, in denen die Entität ebenso vorhanden ist, die Änderungen automatisch übernommen werden (siehe Abb. 5-36). Ein weiterer Vorteil ist die Möglichkeit mancher Werkzeuge Prozesse oder Informationsflüsse zu simulieren, sodass auf diese Weise Optierungsmöglichkeiten oder Hemmnisse ermittelt werden können. Darüber hinaus bieten Modellierungswerkzeuge den Vorteil, dass Auswertungen durchgeführt werden können, z.B. „an welchen Prozessschritten ist Abteilung XYZ beteiligt?“. Einige Werkzeuge erlauben auch die Nutzung des Unternehmensmodells zur Anpassung von IT-Systemen, da sie über spezielle Schnittstellen zu den Modellierungswerkzeugen verfügen.

Abb. 5-37: Statusnetz des Informationsobjektes „Entwurf“

5.7 Prozesse gestalten und steuern 163

Abb. 5-38: Beispiel Prozessdarstellung

164

5 Leithefte zu PLM-Aspekten

Die Abb. 5-38 zeigt ein Beispiel einer Sicht auf einen Prozessablauf. In der Mitte sind die einzelnen Prozessschritte mit ihren Abhängigkeiten zu Ressourcen, Zuständigkeiten und Informationsflüssen dargestellt. Für die Beschreibung des Ablaufs werden neben der Reihenfolge der einzelnen Tätigkeiten auch Ereignisse und Verzweigungselemente benötigt. Auf der linken Seite werden die Zuständigkeiten und Ressourcen beschrieben, die für die Durchführung der einzelnen Prozessschritte verantwortlich sind bzw. für sie benötigt werden. Auf der rechten Seite sind die Informationsflüsse dargestellt, die in die einzelnen Prozessschritte als Eingangsinformation eingehen bzw. als Ausgangsinformation erzeugt werden. Leitet man aus der auf die Tätigkeit zentrierten Prozesssicht eine auf ein Dokument zentrierte Sicht ab, erhält man als Darstellung ein so genanntes Statusnetz. In Abb. 5-37 ist das Statusnetz des Informationsobjekts „Entwurf“ dargestellt, das die Sicht auf die verschiedenen Status einer Information mit den statusändernden Prozessschritten beschreibt. 5.7.5

Prozessmanagement als Basis der Systemanpassung

Um die Geschäftsprozesse eines Unternehmens mit IT-Systemen zu unterstützen und Teilprozesse zu automatisieren, müssen die hierfür verwendeten integrativen Systeme an die speziellen Anforderungen des jeweiligen Unternehmens angepasst sowie die benötigten Funktionen zur Verfügung gestellt werden. In Abb. 5-39 ist die Anwendung des Unternehmensmodells zur Systemanpassung skizziert. Das Unternehmensmodell stellt die zur Anpassung des IT-Systems benötigten Informationen wie Organisationsstruktur, Statusnetze, Prozesse, Ressourcen und Zuständigkeiten zur Verfügung. Anhand dieser Informationen werden die systeminternen Abläufe des Informationssystems gestaltet. Umgekehrt stellt das Unternehmensmodell gleichermaßen eine Möglichkeit dar, die in einem IT-System realisierte Funktionalität zu dokumentieren. Konsequenterweise sollte dementsprechend nachträglichen Änderungen eine Pflege des bereits bestehenden Unternehmensmodells vorausgehen. So wird das Unternehmensmodell ständig in einem iterativen Prozess im Wechsel zwischen konzeptueller Planung und Dokumentation der Realisierung fortgeschrieben. In Bezug auf das generische PLM-Manifest (siehe Abschnitt 4.1.3) im evolutionären Vorgehensmodell nimmt das Unternehmensmodell eine zentrale Stelle ein. Es entsteht während der Phasen „PLM Requirement Management“ (siehe Abschnitt 4.3) bzw. wird in den Phasen „PLM Solu-

5.7 Prozesse gestalten und steuern 165

tion Design“ (siehe Abschnitt 4.4) und „Implementation & Integration“ (siehe Abschnitt 4.5) fortgeschrieben. Insbesondere PDM- und Workflow-Managementsysteme müssen aufgrund ihrer Funktionen zur Unterstützung und Automatisierung von Prozessen sehr intensiv an individuelle Unternehmensgegebenheiten angepasst werden. Die Anpassung eines Informationssystems an das Unternehmen kann durch individuell programmierte Systeme erfolgen, wobei dies aufgrund des Aufwandes für Implementierung und Wartung heute nur noch selten geschieht. In der Regel werden stattdessen Standardsoftwaresysteme eingesetzt, die den Anforderungen entsprechend angepasst oder erweitert werden (siehe Leitheft „Auf Standardsystemen aufbauen“, Abschnitt 5.10).

Abb. 5-39: Anwendung des Unternehmensmodells zur Systemanpassung

166

5 Leithefte zu PLM-Aspekten

Die Nutzung eines Unternehmensmodells im Rahmen des Anpassungsprozesses ist in Abb. 5-40 schematisiert dargestellt (Adamietz 2001). Das Unternehmensmodell enthält den ermittelten Ist-Zustand der Prozesse und Organisation des Unternehmens. Darauf aufbauend wird das Soll-Konzept entwickelt, das festlegt, wie und welche Prozesse zukünftig von einem Informationssystem unterstützt oder automatisiert werden.

Abb. 5-40: Schematische Darstellung der Systemanpassung

5.7 Prozesse gestalten und steuern 167

Diese Darstellung ist zunächst technologie- und systemunabhängig und stellt lediglich die fachliche Wunschvorstellung dar (Lastenheft). Üblicherweise gibt es allerdings technische Beschränkungen, die eine exakte Umsetzung des Soll-Konzepts in einem IT-System verhindern. Darüber hinaus müssen für die Spezifikation der technischen Umsetzung oftmals noch technische Details in der Beschreibung ergänzt werden (z.B. Datenformate, Nachrichtenprotokolle etc.). Daher wird ein Anpassungs-Modell notwendig, das beschreibt, wie tatsächlich das Soll-Konzept im Informationssystem realisiert wird (Pflichtenheft). Schließlich wird das AnpassungModell in einem oder mehreren Informationssystemen verwirklicht. Dies geschieht durch Implementierung (Quellcodeerstellung durch einen Programmierer) oder durch Adaption, d.h. der automatischen Anpassung des Informationssystems anhand der der Informationen des Anpassungsmodells. In letzterem Fall kann dies durch das Modellierungswerkzeug erfolgen, das eine definierte Programmierschnittstelle (Application Programming Interface, Abk. API) des Informationssystems nutzt, oder durch das Informationssystem, indem es die Modellinformation in einem wohldefinierten Format aus dem Modellierungswerkzeug importiert und anschließend sich selbstständig anpasst. 5.7.6

Erstellen eines Unternehmensmodells

Damit die Aufgaben für die Anpassung des IT-Systems effektiv festgelegt werden können, sind bei der Erstellung des Unternehmensmodells die folgenden Abschnitte zur Abbildung der Randbedingungen und unternehmensspezifischen Anforderungen zu beachten (Weber 1997). Das Unternehmensmodell kann so als Grundlage für die Kommunikation mit externen Dienstleistern und Beratern für die Erstellung eines Lasten-/ Pflichtenheftes dienen. Abbildung von Zuständigkeiten

Zur Beschreibung der Benutzerrechte im Informationssystem ist ein Rollen- oder Gruppenmodell erforderlich, das an das Organisationsmodell gekoppelt ist. Diese Daten aus dem Rollenmodell dienen als Grundlage, die Benutzerrechte für Systemfunktionen aus Aktivitäten des Prozessmodells oder für Elemente einer Bildschirmmaske festzulegen.

168

5 Leithefte zu PLM-Aspekten

Abbildung von Informationen und Informationsträgern

Die Beschreibung der Informationen bei der Unternehmensmodellierung nimmt einen großen Stellenwert ein, da die Informationsverwaltung den Hauptzweck des Systemeinsatzes darstellt. Deshalb sollte eine differenzierte Beschreibung von Informationsobjekten erfolgen. Aus dieser sollte u.a. ersichtlich sein, welche Zustände ein Informationsobjekt annehmen kann, welche Daten es enthält und wie es gespeichert und übermittelt wird. Die Informationsobjekte beschreiben die im Unternehmen erzeugten und konsumierten Informationen aus fachlicher Sicht. Die Informationsobjekte werden um Beschreibungen zu Beziehungen zwischen den Informationsobjekten (z.B. „hat“, „ist ein“) und ggf. noch um Attribute der Informationsobjekte ergänzt. Für dieses Modell haben inzwischen auch die Begriffe Fachdatenmodell und Business Object Model eine weite Verbreitung gefunden. Für die Modellierung von Fachdatenmodellen werden üblicherweise Techniken der Datenmodellierung verwendet. Allerdings ist dies nicht mit der Modellierung der Datenstrukturen eines Informationssystems oder einer Datenbank zu verwechseln (siehe nächster Abschnitt). Hierfür werden zwar die gleichen Modellierungstechniken verwendet (z.B. EntityRelationship-Modelle oder UML Klassendiagramme), allerdings haben die Modelle einen anderen Inhalt: Sind beim Fachdatenmodell die Beschreibung fachlicher Informationen Inhalt des Modells, so sind beim Datenmodell für Informationssysteme oder Datenbank Datenstrukturen im Vordergrund, die programmiert werden. In komplexen IT-Landschaften kann es sich lohnen, Abbildungen zwischen diesen beiden Modellebenen zu beschreiben. Auf diese Weise kann die Integration von Informationssystemen erleichtert werden, da technische Felder mit der gleichen Semantik einfacher zu identifizieren sind. Da der papierlose Datenaustausch in vielen Bereichen eines Unternehmens noch nicht realisiert ist und der Informationsaustausch mittels physischer Medien (wie Papier, Disketten usw.) in absehbarer Zeit auch nicht vollständig durch elektronische Informationswege ersetzt sein wird, sollten diese Informationsträger bei der Systemanpassung mit berücksichtigt werden. Allerdings sollte geprüft werden, ob eine Optimierung möglich ist. Abbildung von Datenstrukturen

Eng verknüpft mit der Abbildung der Informationsträger ist die Abbildung der Datenstrukturen, aus denen die Informationen aufgebaut sind. Beispielsweise wird die Information „Produktstruktur“ aus verknüpften Elementen des Datenobjekts „Artikel“ aufgebaut.

5.7 Prozesse gestalten und steuern 169

Abb. 5-41: Elemente eines Klassendiagramms in der UML Notation

Gängige Modellierungsmethoden sind hier die Unified Modelling Language (UML Klassendiagramm), wie in Abb. 5-41 gezeigt oder EXPRESS im Produktdatenbereich. Abbildung von Prozessschritten

Zur Abbildung der Prozesse ist es erforderlich, Informationsobjekte, Aktivitäten und Zuständigkeiten zusammenzuführen. Dies bedeutet, dass die Aktivitäten in Systemfunktionen, die Mitarbeiter aus dem Organisationsmodell als Benutzer in das Berechtigungsmodell und die Informationen sowie Informationsträger in das Datenmodell abzubilden sind. Die Prozesse sollten realitätsnah abgebildet werden, um eine möglichst ideale Prozessunterstützung zu gewährleisten. Das heißt, dass der im System implementierte Prozess den im Unternehmen gelebten Prozess möglichst nah abbildet. So ist die Chance größer, dass dieser akzeptiert und nicht wegen zu komplizierter Bedienung oder Unhandlichkeit umgangen wird. Bei der Konzeption der Soll-Prozesse vor der Implementierung werden die Prozesse auf mögliche Optimierungsmöglichkeiten geprüft. Beispiels-

170

5 Leithefte zu PLM-Aspekten

weise könnten Papierformulare durch elektronische Formulare mit der Konsequenz ersetzt werden, dass manuelle Prozessschritte eingespart werden. Es bietet sich ferner an, die Informationsflüsse der wichtigsten Dokumente durch die Organisationsstruktur zu verfolgen und so unnötige Wege einzusparen bzw. „Engpass“-Stellen aufzudecken. Überprüfung der Systemanforderungen

Da die Geschäftsprozesse Grundlage für Anforderungen an die Funktionalität des zukünftigen Informationssystems bieten, ist bei der Auswahl eines IT-Systems genau zu prüfen, ob dieses System die konzipierte Prozessunterstützung möglichst umfangreich erfüllen kann. Je weniger Anpassungsarbeiten am System zur Umsetzung der Prozesse durchgeführt werden müssen, desto geringer sind zum einen der Einführungsaufwand und zum anderen der langfristige Wartungsaufwand. Weiterhin sollte die langfristige PLM-Vision mit bedacht werden, um sich Möglichkeiten bei der Erweiterbarkeit und Anpassbarkeit des Systems für zukünftige Anforderungen offen zu halten. Funktionsintegration

Die Implementierung von Prozessen als System-Workflows kann als einfache Benachrichtigung der zuständigen Personen ausgeführt werden. So können für eine Bearbeitung einer Aufgabe (teilweise) ausgefüllte Vorlagen mit gesendet werden. Eine weitere Automatisierungsmöglichkeit besteht hier in der Integration von weiteren Systemfunktionen in den Workflows. Beispielsweise kann ein Programm, das zur Bearbeitung eines Prozessschrittes benötigt wird, automatisch mit den zugehörigen Daten gestartet werden oder Datenelemente eines Dokumentes werden automatisch in Datenfelder eines anderen Informationssystems übernommen, wie zum Beispiel eines PDM-Systems. Die Dokumentation dieser Anpassungen, die in der Regel von den Softwarehäusern durchgeführt wird, spielt eine wichtige Rolle für eventuelle Software-Releasewechsel oder beim Wechsel des Dienstleisters. Im Folgenden werden einige Beispiele einer fiktiven Firma „Adler GmbH“ für einzelne Sichten auf das Unternehmensmodell der Firma gezeigt. Das Organigramm in Abb. 5-42 zeigt die Firma mit der Geschäftsführung und den Stababteilungen EDV und Qualitätssicherung sowie den einzelnen Abteilungen. Als weitere Elemente der Organisationsstruktur sind unter den Abteilungen Teams angeordnet.

5.7 Prozesse gestalten und steuern 171

Abb. 5-42: Organigramm der fiktiven Adler GmbH

172

5 Leithefte zu PLM-Aspekten

In Abb. 5-43 ist der Prozess zur Durchführung von „Änderungen“ in diesem Unternehmen dargestellt. Da die Bearbeitung einer Änderung sich wegen der Austauschbarkeit des Änderungsobjektes unterscheidet, werden die ersetzbare und unersetzbare Änderung als zwei Prozessmodule beschrieben, die nochmals genauer modelliert werden.

Abb. 5-43: Beispiel eines Änderungsprozesses

5.7 Prozesse gestalten und steuern 173

Abb. 5-44: Tabelle für die Umsetzung eines Berechtigungsmodells

174

5 Leithefte zu PLM-Aspekten

Auf der rechten Seite des Bildes ist der Informationsfluss des Änderungsantrags mit seinen jeweiligen Status zusehen. Links sind die Mitarbeiter und Teams, die für die Prozessschritte zuständig sind, sowie die verwendeten Werkzeuge wie CAD- und PDM-System dargestellt. Das Beispiel der Tabelle in Abb. 5-44 listet ein Berechtigungsmodell für die Implementierung in einem PDM-System auf. Aus der Tabelle kann beispielsweise aus der 2. Zeile entnommen werden, dass die Position des Abteilungsleiters Arbeitsvorbereitung (PDE-AV-LEITER) im PDM-System der Rolle des Abteilungsleiters Arbeitsvorbereitung (PDE-ALARBEITSVOR) zugeordnet ist. Diese Rolle ist wiederum in verschiedenen Gruppen mit unterschiedlichen Rechten zugeordnet. Schließlich ist auch zu erkennen, welcher Mitarbeiter (z.B. SCHUHMACHERB) diese Rolle bekleidet. Weiterführende Literatur

Adamietz P (2001) Adaption von Standardsoftwaresystemen. Shaker Verlag, Aachen Pfitzinger E (2003) Geschäftsprozess-Management, Steuerung und Optimierung von Geschäftsprozessen. Beuth Verlag, Berlin Scheer A-W (2002) ARIS - vom Geschäftsprozess zum Anwendungssystem. Springer Verlag, Berlin Heidelberg Normen und Standards

DIN EN ISO 9000, Ausgabe:2000-12 Qualitätsmanagementsysteme - Grundlagen und Begriffe DIN EN ISO 9000-3, Ausgabe:1998-08 Normen zum Qualitätsmanagement und zur Qualitätssicherung/QMDarlegung - Teil 3: Leitfaden für die Anwendung von ISO 9001:1994 auf Entwicklung, Lieferung, Installation und Wartung von ComputerSoftware (ISO 9000-3:1997); DIN EN ISO 9001, Ausgabe:2000-12 Qualitätsmanagementsysteme - Anforderungen (ISO 9001:2000-09); Dreisprachige Fassung EN ISO 9001:2000 ISO 9004, Ausgabe:2000-12 Qualitätsmanagementsysteme – Leitfaden zur Leistungsverbesserung

5.8 Transparente Änderungen gewährleisten 175

5.8

Transparente Änderungen gewährleisten

Change Management (engl.) Æ Dokumentenmgnt., Qualitätsmanagement Das Änderungsmanagement beinhaltet die Organisation, Durchführung und Dokumentation eines Änderungsvorgangs, der Summe aller Änderungsmaßnahmen im Rahmen des Änderungsvorlaufes und der Änderungsdurchführung (DIN 199-4). Im Rahmen des Product Lifecycle Management ist der Änderungsprozess häufig einer der zentralen Prozesse, der durch eine IT-basierte, integrierte Unterstützung verbessert werden soll. Ziele hierbei sind die Komplexität des Änderungsprozesses zu beherrschen, Durchlaufzeiten des Änderungsprozesses zu optimieren, Änderungen nachhaltig zu dokumentieren und zu archivieren. Die Formalisierung des Änderungsprozesses nach den Prinzipien des PLM trägt zudem zum Qualitätsmanagement bei und kann somit zur ISO 9000 Zertifizierung verwendet werden. Das PLM sieht vor, dass die Steuerung des Prozesses an einer Stelle zusammenläuft und damit die Einhaltung desselben erzwungen wird. Eine IT-Unterstützung oder gar –Automatisierung dieser Steuerung verbunden mit der Grundfunktionalität eines Integrationssystems, dem Dokumentenmanagement und ggf. der digitalen Unterschrift ersetzt den trägen, papiergestützten Änderungsablauf und trägt damit unmittelbar zu kürzeren Prozesszeiten, Transparenz und Durchgängigkeit bei. Der zweite große Nutzen des Einsatzes eines IT-Systems für die Unterstützung des Änderungsprozesses liegt in der Verwaltung von Dokumenten im Projektkontext. Das IT-System kann die Gültigkeit eines Artikels steuern, d.h. die Sperrung bestimmter Artikel bei gravierenden Änderungsgründen vornehmen oder die Kennzeichnung, dass sich ein Artikel in Änderung befindet, übernehmen. Trotzdem bleibt jedem Anwender die Möglichkeit, alle betroffenen Daten jederzeit zu betrachten und sich so über den Änderungsfortschritt zu informieren. Das gleiche gilt zu Recherchezwecken für Artikel, die aufgrund durchgeführter Änderungen gesperrt sind. Auch diese können noch eingesehen, jedoch nicht weiter bearbeitet werden. Die Dokumentation der Änderung, verbunden mit der Stammdatenarchivierung, ermöglicht eine dauerhafte Rückverfolgung aller Änderungen. 5.8.1

Änderungsmanagement

Die Abb. 5-45 zeigt, dass für die Einführung des Änderungsmanagements durch ein Integrationssystem das Statusmanagement und ein Workflow-

176

5 Leithefte zu PLM-Aspekten

Management zur prozessseitigen Unterstützung, ein Dokumenten- und Datenmanagement zur Dokumentation und Historienverwaltung sowie ein Versionen-, Varianten- und Alternativenmanagement zur produktstrukturseitigen Unterstützung eingeführt sein sollte.

Abb. 5-45: Änderungsmanagement im PLM

5.8 Transparente Änderungen gewährleisten 177

5.8.2

Potential im Änderungsmanagement

Der Änderungsprozess ist ein Kernprozess jedes produzierenden Unternehmens. Er ist meist in unternehmensspezifischen Verfahrensanweisungen oder Normen verbindlich festgelegt (Conrat 1998). Defizite beim Änderungsprozess liegen in langen Durchlaufzeiten. Bestehende Änderungsprozesse bieten häufig wenig Raum für kreative Ideen. Nicht selten benötigt ein Änderungsprozess 15- 20 Unterschriften (Clark u. Fujimoto 1992). Zudem sind angewandte Prozesse wenig transparent und nicht durchgängig. Das Ziel sollte es sein, einen ganzheitlichen Ansatz von technischen und organisatorischen Ansätzen zu verfolgen. Dazu wird die entsprechende IT-Unterstützung eines integrierenden Systems benötigt. Standardsysteme, die PLM-Konzepte implementiert haben, können meist diese Funktionalität liefern. Sie verwalteten das hierzu notwendige integrierte Produktmodell mit allen Dokumenten, deren Veränderungen zukünftig vom Änderungsmanagement verwaltet werden sollen. Das Integrierte Produktmodell wird hierzu üblicherweise um entsprechende Elemente erweitert. Als Beispiel seien hier entsprechende Status-Attribute genannt. 5.8.3

Änderungsmanagement im Mittelstand

Änderungen bedeuten für ein Produkt Innovation und Fortschritt. Der Änderungsprozess betrifft alle organisatorischen Einheiten eines Unternehmens, wie Konstruktion, Verkauf, Einkauf, und Fertigung/Arbeitsvorbereitung (Abk. AV). Um die Komplexität dieses Prozesses greifbar zu machen, sollte er in mehrere Hierarchieebenen eingeteilt werden. Innerhalb des Prozesses zwischen den Ebenen und vom Prozess nach außen sind alle Schnittstellen eindeutig zu definieren. So hat jeder Prozess einen definierten Anfang und ein definiertes Ende, die zunächst festgelegt werden müssen. Beispielsweise beginnt nach DIN 199-4 der Prozess mit dem Stellen des Änderungsantrages. Lindemann und Reichwald gehen weiter und bieten so ein anderes Extrembeispiel (Lindemann u. Reichwald 2001): Sie beginnen den Prozess mit der Idee der Änderung. Gleiches gilt für das Ende des Prozesses. Nach Lindemann und Reichwald ist der Änderungsprozess erst mit einer lernorientierten Auswertung abgeschlossen. In der DIN 199-4 endet der Prozess mit der Verteilung der Änderungsunterlagen (siehe Abb. 5-46).

178

5 Leithefte zu PLM-Aspekten

Abb. 5-46: Änderungsablauf nach DIN 199-4

5.8 Transparente Änderungen gewährleisten 179

Schnittstellen, die der Prozess nach außen bietet, sind zum einen Eingänge (die Prozessauslöser). Dies könnte die Konstruktion bei innovativen Änderungen, der Einkauf aufgrund einer geänderten Marktsituation von Zukaufteilen, der Vertrieb wegen Kundenanforderungen oder die Fertigung bzw. Arbeitsvorbereitung als Reaktion auf Fertigungsschwierigkeiten sein. Zum anderen gibt es Ausgänge (die Prozessenden). Dabei sind zwei Möglichkeiten zu unterscheiden je nachdem, ob die Änderung durchgeführt oder abgebrochen wurde. In beiden Fällen muss das Ergebnis im Unternehmen kommuniziert werden. Der Änderungsprozess selbst muss individuell entsprechend der Arbeitsweise erstellt werden. Die wichtigsten Phasen, die jeder Änderungsprozess enthalten sollte, sind folgende: x Änderungsauslöser Aufgrund einer begründeten Idee wird ein Änderungsantrag gestellt. x Antragsentscheidungsphase Über den Antrag muss entschieden werden. x Änderungsdurchführung x Freigabe eventuelle Wiederholung der Durchführungsphase x Kommunikation x Abbruchvorgang Auch ein Abbruch oder ein Ablehnen einer Änderung muss einen formalen Prozess durchlaufen. Beispielsweise ist zu klären, ob der Antrag ganz oder teilweise abgelehnt wird, ob eine Alternative zwingend erforderlich ist etc. Ebenso sollte nicht versäumt werden, nachhaltig zu dokumentieren, warum eine Änderung abgelehnt wurde, um mehrfache Prozessdurchläufe zu vermeiden. Darüber hinaus ist zu definieren, wie mit dem Thema der pauschalen Freigabe umgegangen werden soll. Eine pauschale Freigabe ist eine dokumentierte Schnellfreigabe, bei der der Änderungsprozess nicht eingehalten wird. Diese Art der Freigabe darf nur von bestimmten Personen ausgeführt werden. Eine entsprechende Vergabe der Rechte ist zwingend erforderlich. 5.8.4 Der Änderungsprozess im PLM Der Änderungsprozess ist ein Workflow besonderer Bedeutung. Somit gelten für den Änderungsprozess alle Regeln und Hinweise aus dem Leitheft „Prozesse steuern und gestalten“ (siehe Abschnitt 5.7). Der Änderungsprozess muss entsprechend jedes Workflows formal im Prozessmodell des PLM-Manifests unabhängig vom Grad der Unterstützung des ein-

180

5 Leithefte zu PLM-Aspekten

gesetzten Tools beschrieben werden. Die formale Änderungsprozessbeschreibung besteht aus zwei Arten von Diagrammen. Zum einen wird der Prozess, also die Tätigkeit und zum anderen die Zustände, die ein Artikel oder ein Dokument während des Prozesses annehmen kann (Status), modelliert. Der Status sagt aus, in welcher Product-Lifecycle-Phase sich der Artikel befindet. Nähere Informationen zu diesem Thema stellt das Leitheft „Dokumente sicher verfügbar machenDokumente sicher verfügbar machen“ (siehe Abschnitt 5.3) bereit. Je nach Ausmaß der Änderung muss festgelegt werden, welche Status der oder die zu ändernden Artikel während des Ablaufs des Änderungsprozesses erhalten, beispielsweise „gesperrt“ oder „wird geändert“. So wird jedem Anwender kenntlich gemacht, dass ein Artikel in absehbarer Zeit verändert wird. Gängige Status sind: x x x x

In Arbeit Freigegeben In Änderung Gesperrt

Diese Status sind in der Regel die Mindestanforderung. Mit jedem Statuswechsel wechselt in der Regel auch die für die (Weiter-)Bearbeitung der Änderung verantwortliche Rolle bzw. Person. Entsprechend ist das Integrierte Produktmodell um Änderungsdokumente und Versionen zu erweitern. Ein definierter Änderungsprozess ist Voraussetzung für ein Qualitätsmanagement. Im STEP-Umfeld hat eine Arbeitsgruppe des ProSTEP iVip-Vereins eine Empfehlung für Änderungsprozesse im Automobil-Bereich entwickelt (siehe www.prostep.org), welche gleichzeitig auch eine VDA-Empfehlung darstellen. Diese Empfehlung umfasst Referenzprozesse für das sog. Engineering Change Management (Abk.: ECM). Hierbei wird explizit unterschieden zwischen Prozessen für die Beantragung einer Änderung („Engineering Change Request“) und der Beauftragung einer Änderung („Engineering Change Order“). Informationstechnische Grundlagen zum Änderungsmanagement

Aus informationstechnischer Sicht gibt es eine Workflow-Klasse, die die Prozessschablone des unternehmensspezifischen Änderungsprozesses repräsentiert. Soll ein Teil geändert werden, wird durch die Instanziierung dieser Klasse ein Änderungsprozess angestoßen (siehe Kap. 3).Bei der Initialisierung erhält das Objekt eine eindeutige Nummer zur Identifikation des Änderungsvorgangs. Außerdem wird ein Bezug zu den zu ändernden

5.8 Transparente Änderungen gewährleisten 181

Teilen hergestellt. Auf diese Weise ist bei der (Weiter-)Delegation der Änderungsaufgabe eindeutig definiert, auf welche Teile sich die Änderung bezieht. Zum anderen lässt sich für ein Teil feststellen, dass es sich in Änderung befindet und in welcher Prozessinstanz die Änderung durchgeführt wird, um z.B. den derzeitigen Bearbeiter der Änderung zu identifizieren. Zu jeder Instanz eines Änderungsprozesses wird ein Änderungsobjekt angelegt, welches den Ablauf und die Ergebnisse der Änderung dokumentiert oder referenziert. Einfachere Standardsysteme im PLM ermöglichen oftmals nur eine Statusvergabe für Artikel, die einem Zustandsdiagramm gleich kommt. Änderungsdokumentation

Der Philosophie des integrierten PLMs folgend sind alle Änderungen nachzuhalten. So sind alle Versionsstände auch nach einer Änderung verfügbar, gearbeitet wird jeweils mit dem neuesten Stand (siehe Leitheft „Evolution der Produkte organisieren“, Abschnitt 5.15.1). Dies ist wichtig, um Konfigurationsstände älterer Produkte jederzeit abrufen zu können und um den Konstrukteuren für Recherchezwecke die Möglichkeit zu geben, die Entwicklungshistorie eines Produktes nachzuvollziehen. Mit jedem formal durchlaufenden Änderungsprozess wird eine neue Version eines bestehenden Artikels oder neuer Artikel erzeugt. Jede Änderung hat Stammdaten, die den Versionsständen zuzuordnen sind. Hierzu zählen beispielsweise: Betreffende Artikel, Name des Initiators, Datum der Initiation, Datum der Fertigstellung der Änderung, Datum des Geltungsbeginns der Änderung, gesperrte Artikel ab Änderungsbeginn, Bearbeiter etc. Neben den Dokumentenständen und den Stammdaten der Änderung sollte die Änderungsdokumentation selbst ebenfalls archiviert werden. Zur Änderungsdokumentation gehören: x Änderungsantrag x Änderungsbegründung (zum Beispiel Zeichnungen mit Bemerkungen) x Wirtschaftlichkeitsanalysen Bezug zum PLM-Modell: x Einordnung zum „Integrierten Produktmodell“ x Prozessmodell x Organigramm Änderungsstände (Versionen) gehören zu den Elementen, die mit im Integrierten Produktmodell berücksichtigt werden müssen. Wie Versionen dort eingeordnet werden, ist im Kap. 3 ausführlich beschrieben.

182

5 Leithefte zu PLM-Aspekten

5.8.5

Einführung eines Änderungsmanagements

Im folgenden Abschnitt wird die Einführung eines IT-gestützten Änderungsprozesses besprochen. Vorgehensweisen

Es gibt generell zwei mögliche Vorgehensweisen, die beide auf dem V-Modell basieren. Zu unterscheiden ist zwischen der „top down“ und der „bottom up“ Methode. Während die bottom-up-Methode zunächst den IstZustand analysiert, Anforderungen an einen integrierten Änderungsprozess aufstellt und daraus ein Sollzustand aufbaut, der zu einem Konzept führt, geht die top-down-Methode vom idealen Änderungsprozess aus. Es wird anhand einer Anforderungsanalyse ein idealer Änderungsprozess aufgestellt, der das Soll darstellt. Aus einem Abgleich mit dem Ist-Zustand resultiert das Konzept. Welche Vorgehensweise anzuwenden ist, hängt vom Unternehmen und der Reife des derzeit eingesetzten Prozesses ab. Die Akzeptanz aller Beteiligten bezüglich des Prozesses ist Voraussetzung für ein Einhalten und effektives Anwenden des Prozessablaufs. Deshalb sind alle Beteiligten frühzeitig in die Konzeption des Änderungsprozesses einzubeziehen und das Konzept mit allen Beteiligten gegenseitig zu prüfen. Ist-Analyse

Die Ist-Analyse findet nach gängigen Methoden des Leitwerks statt. Analysiert werden der bestehende Änderungsprozess, der Dokumentenfluss während des Prozesses, die beteiligten Dokumente mit deren Status und mögliche Schwachstellen. Zur Statusanalyse ist eine Analyse der beteiligten Rollen und ihrer Verantwortung hilfreich. Anforderungsanalyse

In der Anforderungsanalyse ist zu prüfen, ob mit den definierten Anforderungen alle denkbaren Aspekte und Einflussbereiche des Änderungswesens berücksichtigt werden. Hierzu sollte eine Checkliste erstellt werden. Die Abb. 5-47 zeigt als Beispiel die schon angesprochene Mustervorgehensweise nach Lindemann und Reichwald (Lindemann u. Reichwald 2001). Letztendlich ist darauf zu achten, dass für das Unternehmen Phasen identifiziert wurden und dass alle Aspekte durch das Konzept abgedeckt sind. Dazu gehören Tätigkeiten, Systeme, Rechte, Betroffene, Kennzeichnung, Verwaltung etc.

5.8 Transparente Änderungen gewährleisten 183

Abb. 5-47: Vorgehensweise für Änderungen nach Lindemann und Reichwald

Neben den Anforderungen an den Prozess ergeben sich Anforderungen an die Dokumentenstatus, die in einem Zustandsdiagramm beschrieben werden können. Zur eindeutigen Identifizierung einer Änderung sollte zudem jede Änderung eine Nummer haben. Dazu sind die Anforderungen an ein Nummernsystem entsprechend zu identifizieren (siehe Leitheft „Nummernvergabe automatisieren“, Abschnitt 5.5). Aus den Anforderungen wird formal ein Soll-Prozess beschrieben. Eventuell ist das Funktionsspektrum des eingesetzten Systems mit zu berücksichtigen. Das Änderungsmanagement muss mit Versions- und Variantenmanagement koordiniert sein. Implementierung

Die Implementierung ist abhängig von der Customizing-Funktionalität des Tools. Hochwertigere Systeme bieten eine grafische Prozessmodellierung und eine modellbasierte Statusvergabe. Bei einfachen Systemen werden Scriptsprachen zum Customizing verwendet. Die Prozesspflege ist dementsprechend aufwendiger und kann nur von geschulten Mitarbeitern durchgeführt werden. Von Standardsystemen, bei denen die Prozessumset-

184

5 Leithefte zu PLM-Aspekten

zung im Quellcode erfolgen muss, ist eher abzuraten, da hierdurch eine Prozesspflege sehr aufwendig und somit kostspielig wird. Checkliste

x x x x x x x x x

Phasen des Änderungsmanagement definiert? Mögliche Auslöser identifiziert? Abbruchworkflow festgelegt? Rechte berücksichtigt? Status festgelegt? Dokumentation berücksichtigt? Prozess modelliert? Statusdiagramm modelliert? Integriertes Produktmodell erweitert?

Normen und Standards

DIN 199-4: Änderungen Die DIN 199-4 dient der Begriffsdefinition und der Beschreibung von Grundanforderungen für einen Änderungsprozess. Sie teilt den Änderungsprozess in zwei Teile ein. Unterschieden wird zwischen dem Änderungsvorlauf und der Änderungsdurchführung. Der Änderungsvorlauf beschreibt den Teil der Änderung vom Stellen des Änderungsantrages bis zum Entscheid, ob die Änderung durchgeführt wird. Soll die Änderung durchgeführt werden, endet hier der Teil des Prozesses. Wird die Änderung abgelehnt, sieht die DIN einen Prozessschritt zur Ablehnung vor. Soll die Änderung durchgeführt werden, wird aus dem Änderungsantrag ein Änderungsauftrag erstellt und ggf. mit Beschreibungen ergänzt. Darauf werden Zeichnungen und Stücklisten geändert und die geänderten Dokumente verteilt. DIN 6789: Dokumentationssystematik In den sechs Teilen dieser Norm werden der Aufbau, die Struktur, Änderungen und Freigaben von technischen Produktdokumentationen behandelt. DIN 9000/9001 Diese DIN dient der Qualitätssicherung und beschäftigt sich mit den innerbetrieblichen Prozessen. Sie fordert u.a. eine durchgängige Dokumentation aller Prozesse.

5.9 Produktzentrierte Projektabwicklung 185

5.9

Produktzentrierte Projektabwicklung

Æ Prozess- und Organisationsmanagement Æ Applikationsintegration Product Lifecycle Management organisiert Informationen und Prozesse über den gesamten Lebenszyklus eines Produktes. Die Aufgabe der Entwicklung eines neuen Produktes beziehungsweise der umfangreichen Verbesserung oder Anpassung bestehender Produkte wird in Form von Projekten durchgeführt, die mittels Projektmanagement geplant, überwacht und gesteuert werden. Projektmanagement von Produktentwicklungsprojekten ist auf die Prozesse und Abläufe der Produktentwicklung, dem Betriebsmittelbau und der Arbeitsvorbereitung fokussiert, da hier die für den Projektverlauf entscheidenden Tätigkeiten und Beschlüsse anzusiedeln sind. Alle weiteren Unternehmensbereiche sind je nach Projektphase mehr oder weniger in den Projektablauf eingebunden. Die Zielsetzung eines Projekts ist dabei stets, die Entwicklungsaufgabe und die Herstellung des Produkts kosten- und termingerecht mit der geforderten Qualität abzuschließen. Das bedeutet auch, dass Änderungen des Projektmanagementablaufs im Rahmen des Product Lifecycle Mangements alle Unternehmensbereiche betreffen. Dies bedingt somit die Unterstützung des gesamten Unternehmensmanagements. Mit zunehmender Komplexität der Produkte, steigender Anzahl an Projektmitarbeitern und Projektpartnern gestalten sich Kapazitäts- und Terminplanungen sowie die Überwachung der Ist-Zustände zunehmend schwieriger. Zusätzlich sind die benötigten Information und Dokumente die in einem Projekt entstehen über viele Informationssysteme, Ablageorte und Medien verteilt. Greift man nun den Grundgedanken von PLM, die richtige Information zur richtigen Zeit am richtigen Ort, auf, bietet dieses Konzept eine große Chance das Projektmanagement von Produktentwicklungsaufgaben entscheidend zu verbessern. Die enge Verbindung zwischen Entwicklungsaufgaben, Entwicklungsdokumentation und organisatorischen Informationen bietet hohes Potential für mehr Transparenz und Steuerungsmöglichkeiten. Aus diesem Grund bieten alle Integrationssysteme Softwaremodule zur Unterstützung des Projektmanagements. Die Schwierigkeit bei der Implementierung einer Softwarelösung besteht nun darin eine sinnvolle Integration der Informationen und daran angelehnter Prozesse zu erreichen. Beispielsweise wird sich die Frage stellen, wie die Ermittlung der Projektkosten, normalerweise im ERP-System angesiedelt, mit der Verwaltung von Projektaufgaben inklusive Terminen und Mitarbeiterkapazität innerhalb eines PLM-Systems zusammenspielt.

186

5 Leithefte zu PLM-Aspekten

5.9.1 Projektmanagement Die nachfolgende Abbildung (Abb. 5-48) stellt einen Überblick über die wesentlichen Teilgebiete des Product Lifecycle Managements und deren Verbindungen untereinander dar. Aufbauend auf dem Workflowmanagement und dem Freigabe- und Änderungsmanagement unterstützt das Projektmanagement die Planung, Abwicklung und Kontrolle von Entwicklungsprojekten.

Abb. 5-48: Projektmanagement im PLM

5.9 Produktzentrierte Projektabwicklung 187

5.9.2 Hilfsmittel für das Projektmanagement Zur Unterstützung des Projektmanagements werden vor allem GanttDiagramme und die Netzplantechnik als Hilfsmittel eingesetzt. GanttDiagramme verbinden den zeitlichen Ablauf von Projekten mit den Aufgaben und Aktivitäten und stellen diesen einfach und übersichtlich dar (siehe Abb. 5-49). Dabei werden die einzelnen Teilaufgaben über einem Zeitstrahl dargestellt. Gantt-Diagramme haben allerdings den Nachteil, dass die Abhängigkeiten der einzelnen Aufgaben kaum zu erkennen und so Auswirkungen von Terminverschiebungen kaum festzustellen sind (Altrogge 1996). Mit Hilfe der Netzplantechnik (DIN 69900) sind Abhängigkeiten zwischen den Aufgaben einfach abzubilden und somit die Auswirkungen von Terminverschiebungen leicht zu erkennen. In Abb. 5-50 ist ein Beispiel eines Netzplanes dargestellt. Softwarewerkzeuge für das Projektmanagement unterstützen in der Regel die automatische Ableitung von Gantt-Diagrammen bzw. Netzplänen aus Aktivitäts- und Termindaten und Verfügen über grafische Editoren zur Erstellung und Änderung der Diagramme bzw. Pläne. Entscheidend für die sinnvolle Nutzung dieser Hilfsmittel ist, neben der Handhabung beim erstellen von Projektplänen, aber vor allem wie hoch der Aufwand ist, die Planung aktuell zu halten.

Abb. 5-49: Gant-Diagramm mit Arbeitspaketen

188

5 Leithefte zu PLM-Aspekten

Abb. 5-50: Darstellungsbeispiel eines Netzplanes

Genau an dieser Stelle müssen Softwarewerkzeuge Unterstützung bieten, da letztendlich auf Basis dieser Planung Entscheidungen über zukünftige Aufgaben, Termine, Kapazitäten und Aufwendungen im Projekt getroffen werden. Je besser Projektinformationen sind desto nachhaltiger sind die getroffenen Entscheidungen. 5.9.3 Projektmanagement im Engineering Im Kontext des Product Lifecycle Managements sind bei Entwicklungsaufgaben neben der Qualität des Produktes Kosten- und Termintreue in zunehmendem Maße zu wichtigen Faktoren geworden. Bei der Entwicklung neuer Produkte oder der Verbesserung existierender Produkte wird ein Entwicklungsvorhaben dabei im Allgemeinen als Projekt bezeichnet. Die DIN 69901 definiert ein Projekt als „Vorhaben, das im Wesentlichen durch Einmaligkeit der Bedingungen in ihrer Gesamtheit gekennzeichnet ist, wie z.B. durch Zielvorgaben, zeitlichen, finanziellen, personellen oder anderen Begrenzungen, die Abgrenzung gegenüber anderen Vorhaben und einer projektspezifischen Organisation“. Das Projektmanagement verknüpft Kosten, Termine, Kapazitäten und Aufgaben miteinander und unterstützt die Planung, Steuerung und Überwachung von Projekten. Mit steigendem Umfang und einer zunehmenden Anzahl an Aufgaben, Projektmitarbeitern und Terminen innerhalb eines Projektes gestaltet sich die Organisation und Administration zunehmend schwieriger. Zusätzliche Anforderungen an das Projektmanagement ergeben sich aus der Tendenz zur verteilten Produktentwicklung mit einer Vielzahl an Partnerunternehmen und Standorten.

5.9 Produktzentrierte Projektabwicklung 189

Die Verwaltung und Planung von Arbeitsabläufen und Ressourcen sind im Bereich der Produktentwicklung längst nicht so stark ausgeprägt und detailliert wie in der Produktion. Dies liegt vor allem daran, dass sich Fertigungs- oder Montagetätigkeiten klar voneinander abgrenzen lassen, also deterministische Tätigkeiten sind, und dass sich die Bedingungen, unter denen die Tätigkeit ausgeführt werden, in der Regel gut vorausbestimmen lassen. Tätigkeiten in der Entwicklung sind dagegen eher nichtdeterministisch und weisen eine hohe Dynamik im Bezug auf die einzelnen Entwicklungsaufgaben auf, da sich ihre Fortschritte häufig und schnell ändern können. Entwicklungstätigkeiten sind aufgrund des hohen Anteils an Informationsverarbeitung und Kreativität zudem nur sehr schwer planbar, da sich Kreativität nur fördern, aber nicht erzeugen lässt (Kurz 1998). Gerade diese Unwägbarkeit bei der Planung und die Forderung nach kurzen Durchlaufzeiten bedeutet für den Entwicklungsbereich allerdings die Notwendigkeit einer Planung mit verstärkter Kontrolle der Entwicklungszeiten, da sich Verzögerungen entsprechend auf die Produktionsplanung und damit auf den Endtermin auswirken. Um diese komplexen Anforderungen an das Projektmanagement im Entwicklungsprozess besser beherrschen zu können, werden Softwarewerkzeuge zur Unterstützung herangezogen. Im Wesentlichen lassen sich dabei die folgende Typen unterscheiden: x Eigenständige Software, einzelne Projekte: Diese Softwarewerkzeuge sind meist etwas einfacher handzuhaben und liegen bei den Lizenzkosten eher im unteren Bereich der Preisskala. Für das Management von Projekten mit wenigen Aufgaben und geringer Anzahl an Mitarbeitern werden häufig Tabellenkalkulationen verwendet. Ein großer Nachteil dabei ist jedoch der hohe manuelle Pflegeaufwand bei Änderungen und die fehlende Verknüpfung zu anderen Projekten, sodass Kapazitäts- oder Terminengpässe nur sehr schwer erkannt werden können. x Eigenständige Software, datenbankbasiert: Eigenständige, datenbankbasierte Systeme bieten den Vorteil, dass die Auswirkungen von Planungsänderungen vom System geprüft werden können und die damit verbundene Pflege der Daten teilweise automatisiert werden kann. Beispielsweise kann ein solches System bei der Durchführung einer Terminverschiebung überprüfen, ob die betroffenen Mitarbeiter in dem überarbeiteten Zeitraum noch Kapazitäten frei haben oder gegebenenfalls weitere Umplanungsmaßnahmen erforderlich werden. Nachteilig ist bei diesen Systemen der höhere Aufwand für IT-Infrastruktur, Lizenzen und Bedienbarkeit zu sehen.

190

5 Leithefte zu PLM-Aspekten

x Modul eines übergeordneten IT-Systems: Ein Projektmanagementmodul eines übergeordneten IT-System bietet neben den Vorteilen einer eigenständigen, datenbankbasierten Software noch die Möglichkeit die Projektmanagementinformationen mit weiteren Daten und Funktionen wie Kostenkalkulation oder Produktinformationen zu verknüpfen. Dieser Vorteil wird in der Regel mit Einschränkungen in der Flexibilität erkauft. Die Auswahl der geeigneten Software hängt wie so häufig von der Prozessen und Anforderungen des Unternehmens ab. Generell sollte jedoch eine datenbankbasierte Lösung bevorzugt werden, da durch die zentrale Datenhaltung die Informationen einfacher zu pflegen und damit auch konsistenter und aktueller sind als bei dateibasierten Lösungen. 5.9.4 Projektmanagement im PLM Der wesentliche Punkt der Anwendung von Projektmanagement im Product Lifecycle Management ist die Verknüpfung von Projekten mit den Produkten, genauer von Projektaufgaben mit den korrespondieren Entwicklungsaufgaben. Das Ziel, Kosten zu senken und Entwicklungsaufgaben mit hoher Qualität schneller abzuschließen, wird durch eine hohe Wiederverwendungsrate von Bauteilen und Baugruppen sowie durch Zusammenführung und Abstimmung von Entwicklungsaufgaben für Komponenten in verschiedenen Projekten unterstützt, was eine Vernetzung von Projekten bzw. Projektaufgaben erfordert. Zur Reduzierung der Komplexität eines Projektes kann dieses in einzelne Teilprojekte unterteilt werden, sodass eine hierarchische Projektstruktur entsteht, deren Teilprojekte und Projektaufgaben allerdings in verschiedene Projekte eingehen können. Den zentralen Einstiegspunkt für das Projektmanagement im PLM stellt die Projektmappe dar. Die Projektmappe stellt einen Knoten dar, mit dem sämtliche Dokumente und Informationen zu Produktstruktur, Artikeln, Aufgaben, Prozessen, Aktivitäten, Kalender und Mitarbeiter verknüpft werden. Auf diese Weise erhält man eine zentrale Stelle, von der aus alle für das Projekt relevante Informationen erreichbar sind. Durch die zentralen Datenhaltung und mit Hilfe der Checkin-/CheckoutMechanismen der Integrationssysteme (siehe „Dokumente systemunterstützt verwalten“, Abschnitt 5.3.5) wird sichergestellt das zu jeder Zeit alle Beteiligten auf die aktuellsten Informationen zugreifen bzw. diese bearbeiten. Über die Projektmappe entsteht eine Verknüpfung zwischen Projektstruktur, dem integrierten Produktmodell und den Unternehmensprozessen. Beispielsweise kann ein Endprodukt mit einem Gesamtprojekt verknüpft

5.9 Produktzentrierte Projektabwicklung 191

werden. Teilekomponenten oder Baugruppen können entsprechenden Teilprojekten zugeordnet und in diesen entwickelt werden. Damit ergibt sich eine Beziehung zwischen Produkt- und Projektstrukturen (siehe Abb. 5-51), wobei Produkt- und Projektstruktur nicht immer direkt korrespondieren müssen, ja üblicherweise nur in geringem Maße korrespondieren.

Abb. 5-51: Mögliche Bezeichnung zwischen Produkt- und Projektstruktur

Abb. 5-52: Zusammenhang zwischen Projekt und Prozess

192

5 Leithefte zu PLM-Aspekten

Die Entwicklung der jeweiligen Teilkomponenten ist als Aufgabe innerhalb der Teilprojekte zu verstehen, sodass die Gesamtaufgabe des Projektes erfüllt wird. Die Teilprojekte beinhalten wiederum die Arbeitspakete, die in dem jeweiligen Teilprojekt zu bearbeiten sind. Ein Arbeitspaket beschreibt dabei die einzelnen Arbeitsschritte (Aktivitäten), die ausgeführt werden müssen, um die Aufgabe des Teilprojekts erfolgreich zu bearbeiten (siehe Abb. 5-52). Der Beginn der Durchführung eines Projektes startet bestimmte Geschäftsprozesse im Unternehmen, die durch den Ablauf einzelner Prozessschritte beschrieben werden und in denen auch die Zuständigkeiten der Mitarbeiter und der zu benutzenden Werkzeuge (Applikationen wie z.B. CAD) definiert sind. Aktivitäten im Projekt entsprechen in der Regel Prozessschritten in Unternehmensabläufen, sodass bei der Unterstützung von Projektaktivitäten im Integrationssystem auf die für das WorkflowManagement definierten Abläufe zurückgegriffen werden kann (Schöttner 1999). Die Integration von Projektmanagementfunktionen mit der Workflow-, Produktstruktur- und Dokumentenmanagement-Funktionalität beispielsweise von PDM-Systemen wird durch eine transparente Planung, Steuerung und Kontrolle von Entwicklungsaufgaben ermöglicht (siehe Abb. 5-53).

Abb. 5-53: Integration von Projekt-, Prozess- und Datenmanagement

5.9 Produktzentrierte Projektabwicklung 193

In Integrationssystemen existieren zur Verwaltung von Projektunterlagen Projektmappen als Datenobjekte, die als datentechnischer Ankerpunkt mit den relevanten Objekten wie Produktstruktur, Artikel, Aufgaben, Prozesse, Aktivitäten, Kalender und Mitarbeiter verknüpft werden. Auf Basis dieses integrierten Ansatzes von Projekt-, Prozess- und Datenmanagement im PLM in Form einer Projektmappe ergeben sich besonders für Steuerung und Kontrolle eines Projektes unter anderem folgende Möglichkeiten: x Teilweise Automatisierung von Abläufen z.B. das Versenden von Dokumenten zum nächsten Bearbeiter x Vorgabe von Applikationen, die für eine Aktivität verwendet werden sollen. Beispielsweise verlangen Automobilhersteller von ihren Lieferanten, dass die Geometriedaten im CAD-System eines bestimmten Herstellers modelliert werden. x Benachrichtigung von Projekt- oder Teamleiter bei Überschreitung des Termins einer Aktivität oder Aufgabe x Benachrichtigung von Projekt- oder Teamleiter bei Fertigstellung einer Aktivität oder Aufgabe x Übersichten über den aktuellen Status und Fortschritt von Aufgaben oder Aktivitäten x Dokumentenmanagementfunktionen gestatten die Verwaltung von Projektdokumenten wie Besprechungsprotokollen oder Meilensteinberichten, sodass diese Dokumente den Projektbearbeitern in der gleichen Form zur Verfügung stehen, wie die restlichen produktrelevanten Dokumente. 5.9.5 Umsetzung von Projektmanagement-Konzepten Die informationstechnische Unterstützung des Projektmanagements stellt nach wie vor eine große Herausforderung dar, die noch nicht vollständig gelöst ist. Üblicherweise ist das Projektmanagement eher im betriebswirtschaftlichen Umfeld zu sehen, in dem Planung und Kontrolle von Auftragsabwicklung, Kosten und Ressourcen im Vordergrund stehen. Damit wurde Projektmanagement – neben eigenständiger Projektmanagementsoftware – zunächst durch ERP-Systeme unterstützt. Die Notwendigkeit zur Verkürzung von Produktentwicklungszeiten und Kostenreduzierung macht eine informationstechnische Unterstützung des Projektmanagements durch Integrationssysteme jedoch zwingend erforderlich, sodass die Informationssysteme im Entwicklungsbereich zunehmend mit Projektmanagementfunktionalitäten erweitert werden. Effizientes Projektmanagement ist jedoch nur möglich, wenn sowohl Entwicklung, Produktion und

194

5 Leithefte zu PLM-Aspekten

die kaufmännischen Bereiche im Projektmanagement berücksichtigt werden. Somit bestehen drei Möglichkeiten mit verschiedenen Vor- und Nachteilen, Projektmanagement durch Informationssysteme zu unterstützen: x Das Projektmanagement im ERP-System bietet den Vorteil, die umfangreichen Funktionen für die Verwaltung, Planung und Steuerung von Terminen, Personal- und Maschinenkapazitäten sowie Kosten dieser Systeme Nutzen zu können. Für die Erfassung von Projektinformationen aus dem Entwicklungsbereich müssen diese Systeme entweder manuell mit Daten beschickt oder entsprechend erweitert und mit Schnittstellen versehen werden. Diese können gegebenenfalls als bidirektionale Schnittstellen ausgeprägt werden, um die Projektinformationen im ERP als auch im Integrationssystem zur Verfügung zu stellen. x In Integrationssysteme integrierte Projektmanagement-Komponenten bieten vor allem den Vorteil einer einheitlichen Datenhaltung im Entwicklungsbereich. Allerdings verfügen diese Systeme derzeit noch über geringe Funktionalität zur Kostenermittlung oder Kapazitätsplanung. Entsprechend zum ERP können Projektinformationen aus der Produktion nur durch geeignete Schnittstellen oder manuelle Erfassung berücksichtigt werden. x Weiterhin sind für das Projektmanagement eigenständige Softwarewerkzeuge auf dem Markt verfügbar, die meist auch einen größeren Funktionsumfang besitzen oder einfacher zu bedienen sind, als Projektmanagement-Komponenten von ERP- oder PDM-Systemen. Nachteilig ist jedoch zu sehen, dass Projektinformationen sowohl aus ERPwie auch aus Integrationssystemen gewonnen werden müssen. Besonders müssen die Aktualität der Projektinformationen und die Dynamik der Prozesse im Projektmanagement bei der Auswahl oder Implementierung von unterstützenden Informationssystemen berücksichtigt werden. Zum einen erfordern häufige Änderungen des Projektfortschritts, das Auftreten von Hindernissen mit verbundenen Änderungen von Aufgaben oder Zeitplänen eine einfache und möglichst automatische Aktualisierung von Daten. Zum anderen müssen die Informationssysteme mit dynamischen Projekt- und Produktstrukturen umgehen können, da zu Beginn eines Projektes diese Strukturen nicht vollständig bekannt sein kann. Vielmehr wird sie im Laufe der Zeit geändert bzw. immer mehr detailliert. Aufgrund der Komplexität der Prozesszusammenhänge der verschiedenen Medien und Dokumente sowie den unterschiedlichen Anforderungen der Unternehmensbereiche wird eine Lösung in einem System nur schwer umsetzbar sein. Mit der zunehmenden Unterstützung der Softwarehersteller für das Konzept der Service-Oriented-Architecture (SOA) verbreiten

5.9 Produktzentrierte Projektabwicklung 195

sich verstärkt Lösungen, die eine Integration der Hauptsysteme, PLM und ERP, mit ergänzenden Werkzeugen, wie Email-Integration und Groupwarefunktionen wie Aufgaben-, Termin und Dokumentenverwaltung erlauben. Weiterführende Literatur

Altrogge G (1996) Netzplantechnik. Oldenbourg Verlag, München Wien Geiger K, Ruf H, Schindewolf S (2000) Product Lifecycle Management mit mySAP.com: Strategie, Technologie, Implementierung. Galileo Press, Bonn Jenne F (2001) PDM-basiertes Entwicklungsmonitoring. Shaker Verlag, Aachen Schöttner J (1999) Produktdatenmanagement in der Fertigungsindustrie. Prinzip, Konzepte, Strategien. Hanser Verlag, München Wien Winkelhofer G (1999) Methoden für Management und Projekte – Ein Arbeitsbuch für Unternehmensentwicklung, Organisation und EDV. Springer Verlag, Berlin Heidelberg Normen und Richtlinien

DIN 69900-1, Ausgabe:1987-08: Projektwirtschaft; Netzplantechnik; Begriffe DIN 69900-2, Ausgabe:1987-08: Projektwirtschaft; Netzplantechnik; Darstellungstechnik DIN 69901, Ausgabe:1987-08: Projektwirtschaft; Projektmanagement; Begriffe DIN 69902, Ausgabe:1987-08: Projektwirtschaft; Einsatzmittel; Begriffe DIN 69903, Ausgabe:1987-08: Projektwirtschaft; Kosten und Leistung, Finanzmittel; Begriffe DIN 69904, Ausgabe:2000-11: Projektwirtschaft - Projektmanagementsysteme – Elemente und Strukturen DIN 69905, Ausgabe:1997-05: Projektwirtschaft - Projektabwicklung – Begriffe

196

5 Leithefte zu PLM-Aspekten

5.10 Auf Standardsystemen aufbauen

Æ Applikationsintegration Bei der Umsetzung einer Softwarelösung, die die speziellen Bedürfnisse eines Unternehmens bzw. einer Anwendergruppe erfüllen muss, stellt sich im Allgemeinen die Frage, ob eine Standardsoftware eingeführt und an die individuellen Bedürfnisse angepasst werden kann, oder ob ggf. eine Individuallösung entwickelt werden muss. Die heute am Markt verfügbaren Standardsoftwaresysteme bieten nicht nur vom Funktionsumfang her eine solide Basis für die typischen Anforderungen, die im PLM-Kontext an die unterstützende Software gestellt werden, sondern sie bieten zugleich auch in hohem Maße eine individuelle Anpassbarkeit, die jedoch immer mit mehr oder weniger hohem Aufwand verbunden ist. Die Konfigurierbarkeit heutiger Standardlösungen ermöglicht die Anpassung an die individuellen, unternehmens- und prozessspezifischen Bedürfnisse eines Unternehmens, sodass der Einsatz von Individualsoftware nur noch in solchen Fällen gerechtfertigt sein kann, bei denen die Anforderungen sehr weit vom typischen Spektrum der PLM-Basisfunktionen abweichen. Der wesentliche Vorteil bei der Anpassung von Standardsoftware – das so genannte Customizing (engl.: an Wünsche anpassen) – liegt darin, dass auf einer breiten Basis ausgereifter und erprobter Grundfunktionen aufgesetzt werden kann. Hingegen müssen diese Funktionalitäten bei Individualsoftware von Grund auf verbunden mit sehr hohem Aufwand und sehr hohem Entwicklungsrisiko selbst implementiert werden. Hinzu kommt die rasante Weiterentwicklung der IT-Technologien und ITArchitekturkonzepte, die mit Individuallösungen kaum adaptiert werden können. So rechnet sich unter dem Strich die Implementierung von Individuallösungen nur für so spezielle Problemstellungen, bei denen die Anpassung einer Standardsoftware auch unter Berücksichtigung der zukünftig höheren Wartungs-, Weiterentwicklungs- sowie Anpassungsaufwande kein vergleichbares Kosten/Nutzen Verhältnis erreicht. Umgekehrt sind Standardlösungen per se aber auch kein Garant für eine erfolgreiche IT-basierte Umsetzung von PLM. Der zeitliche und finanzielle Aufwand und das damit verbundenen Risiko für die individuelle Anpassung einer Standardsoftwaresystem-Plattform ist ebenfalls relativ hoch und zudem schwer abzuschätzen (Abramovici 1999). Zu berücksichtigen ist insbesondere der Aufwand für die Wartung und Pflege eines angepassten Standardsoftwaresystems, da z.B. beim Wechsel der Softwareversion (Releasewechsel) die Anpassungsarbeiten eventuell wiederholt werden müssen. Aus diesem Grund kann ein höherer Systempreis für ein System, bei dem weniger Anpassungsaufwand anfällt, über einen längeren

5.10 Auf Standardsystemen aufbauen 197

Zeitraum gerechnet kostengünstiger sein als ein System mit niederem Basispreis und umfangreichen Anpassungen. Zusammengefasst lässt sich sagen, dass an Standardlösungen heute kaum noch ein Weg vorbeiführt, wenn es um die Erschließung der PLM-Potenziale auf der Basis von ITLösungen geht. Auswahl, Kosten-/Nutzen-optimiertes Customizing, Einführung, Pflege und ständige Weiterentwicklung solcher Standardsysteme erfordern ein hohes Maß an PLM-Expertise einerseits und strategisch langfristiger Ausrichtung der PLM-Aktivitäten andererseits (s. Abb. 5-54).

Abb. 5-54: Applikationsintegration und Datentausch im PLM-Umfeld

198

5 Leithefte zu PLM-Aspekten

5.10.1 Produkt- und Ressourcenzentrierte integrierte Ansätze im PLM Da PLM ein integrierender Gesamtansatz ist, der die zu entwickelnden Produkte gewissermaßen „von der Wiege bis zur Bahre“ begleitet, können die in diesem Kontext prinzipiell infrage kommenden integrierenden Systemansätze in zwei grundlegende Klassen unterschieden werden (Abb. 5-55): Systeme, bei denen die Unternehmensressourcen (Mitarbeiter, Produktionsmittel usw.) im Mittelpunkt der Integrationsbemühungen stehen (Enterprise Resource Planning ERP) und Systeme, bei denen die Produkte und alle sie beschreibenden Dokumente, Modelle und Daten das zentrale integrierende Moment darstellen (Produktdaten Management PDM). Beide Ansätze haben sich ursprünglich relativ unabhängig voneinander entwickelt und im Laufe der ständig gewachsenen Integrationsspannweite immer mehr genähert. So sind heute je nach Unternehmensdimension, Produktkomplexität und Verteilungsgrad der PLM-Prozesse unterschiedliche Umsetzungsszenarien anzutreffen.

Abb. 5-55: Konzept des Product Lifecycle Managements (Wdh.)

5.10 Auf Standardsystemen aufbauen 199

Die „Big Player“ zum Beispiel aus der Luft- und Raumfahrt- oder aus der Automobilindustrie haben typischerweise für beide Dimensionen eigenständige, integrierte, groß dimensionierte und aufwendig angepasste Standardsoftwaresystem im Einsatz, die über entsprechende Schnittstellenund Integrationsansätze (siehe Leitheft „Systeme kommunizieren lassen“, Abschnitt 5.11) miteinander verwoben sind. Auf der anderen Seite finden sich bei kleinen Unternehmen oft um das CAD-System herum angeordnete produktzentrische Verwaltungssysteme (Produktdaten Management Systeme PDM) mit einer relativ einfachen – oft unidirektionalen – Schnittstelle zur Übergabe der Stücklistedaten an ein parallel laufendes kleineres und in der Regel Branchen-spezifisches „MiniERP-System“. Zwischen diesen beiden Polen sind beliebig viele Abstufungen und Zwischenlösungen denk- und umsetzbar – mit anderen Worten – auch hier gibt es keine Patentlösung. Leiten lassen sollte man sich immer von den individuellen Rahmenbedingungen und den sich daraus ergebenden Anforderungen. Die Orientierung an dem in diesem Buch vorgestellten iterativen Vorgehensmodell soll genau dazu dienen, dieses unternehmensspezifische optimale Gesamtkonzept zu entwickeln und immer wieder anzupassen. 5.10.2 Klassifizierung der Systemtypen Auf dem Markt für PLM-Systemlösungen sind viele Anbieter mit vielen unterschiedlichen Standardsoftwaresystemen vertreten. Diese Systeme unterscheiden sich dabei erheblich in der verwendeten Technologie, im funktionalen Umfang, in ihren Konfigurationsmöglichkeiten und letztlich auch bezüglich Preis bzw. Kosten. Im Wesentlichen können diese Systeme gemäß der VDI-Richtlinie 2219 grob den folgenden drei Systemklassen zugeordnet werden (VDI 2219): x Erzeugersystemorientierte Systeme: Die erzeugersystemorientierten Systeme sind entweder Teil eines Erzeugersystems (typisch des CAD-Systems) oder werden als Zusatzmodule zu diesen angeboten und mit diesen integriert. Sie erweitern somit das Erzeugersystem um Funktionen zur übergreifenden und kontrollierten Verwaltung der erzeugten Daten und Modelle. Der Vorteil dieser Systeme liegt in der engen Systemintegration auf Basis einer gemeinsamen CAD-nahen Datenstruktur und einheitlichen Funktionsaufrufen. Diese Systeme werden ebenfalls als TDM-Systeme (Teamdatamanagement) bezeichnet.

200

5 Leithefte zu PLM-Aspekten

x Funktionsorientierte erzeugersystemübergreifende Systeme: Funktionsorientierte und erzeugersystemübergreifende Systeme sind Ansätze, deren Funktionsumfang Lösungen für das Management bestimmter einzelner PLM-Aspekte abdeckt wie beispielsweise für das Dokumentenmanagement, das Workflow-Management oder die Archivierung. Sie bieten standardisierte Schnittstellen zu den marktgängigen Erzeugersystemen und sind so nicht (hart) an spezielle Lösungen gebunden, sodass beim Wechsel des Erzeugersystems nicht zwingend die Notwendigkeit besteht, das Managementsystem ebenfalls zu wechseln, wenngleich in der Regel auch hier gewisse Anpassungen notwendig werden. x Integrierte und übergreifende Systeme: Integrierte und übergreifende Systeme unterstützen mit ihrem Funktionsumfang mehr oder weniger das gesamte Spektrum an PLMAspekten über den gesamten Product Lifecycle hinweg. Sie sind erzeugersystemunabhängig und vereinen beispielsweise Dokumenten-, Produktstruktur-, Konfigurations- und Workflow-Management. Dies ist die heute wichtigste Systemklasse zur Unterstützung eines integrierten, alle Phasen umspannenden PLM-Konzeptes. Deshalb werden solche Softwaresysteme heute gemeinhin auch als PLM-Systeme von den Anbietern am Markt positioniert. Sie sind gemäß den eingangs dargestellten beiden Dimensionen sowohl als eigenständige Lösungen anzutreffen oder sind auch als PLM-Module in ERP-Systeme integriert. 5.10.3 Architektur von Standardsoftwaresystemen Die Grundarchitektur von Softwaresystemen spielt bei der Auswahl von Standardlösungen insofern eine Rolle, als sie die grundsätzlichen Möglichkeiten der Integration in die vorhandene informationstechnische Infrastruktur und den mit Entwicklung und permanenter Erweiterung der Gesamtlösung verbundenen Aufwand wesentlich mitbestimmt. Im Engineering-Bereich werden typischerweise WorkflowManagement-, CAx-, Berechnungssoftware-, PDM- und andere Applikationen wie z.B. Tabellenkalkulationsprogramme zur IT-Unterstützung eines PLM-Konzepts eingesetzt, die in Summe und in ihrem Gesamtzusammenspiel dann die Integrationsplattform bilden. Die VDI-Richtlinie 2219 definiert PDM-Systeme – als wesentlicher Grundpfeiler – hierbei als technische Datenbank- und Kommunikationssysteme, die dazu dienen, Informationen über Produkte und deren Entstehungsprozesse bzw. Lebenszyklen konsistent zu speichern, zu verwalten und allen relevanten Bereichen eines

5.10 Auf Standardsystemen aufbauen 201

Unternehmens bereitzustellen (VDI 2219). PDM-Systeme stellen somit eine Basisplattform für integrierte PLM-Lösungen zur Verfügung, in die alle über den Produktentwicklungsprozess benötigten Applikationssysteme eingebunden werden, sei es über explizite Schnittstellen oder durch tiefere Integration (siehe dazu Leitheft „Systeme kommunizieren lassen“, Abschnitt 5.11). Die Hauptfunktionen größere Softwaresysteme mit integrierendem Charakter werden in so genannte Schichten aufgeteilt, wobei sich die Einteilung in die Schichten als so genanntes 3-Schichtenmodell (Three-TierArchitecture) etabliert hat: 1. Darstellung dem Anwender gegenüber (Präsentationsschicht), 2. Verarbeitungslogik (Verarbeitungs- oder Applikationsschicht) sowie 3. Datenhaltung bzw. Zugriff auf die Daten (Datenhaltungsschicht) In der Literatur werden auch Architekturen mit einer größeren Anzahl Schichten beschrieben. Diese stellen jedoch lediglich eine detaillierte Beschreibung dieser drei Schichten durch Aufteilung einer Schicht in weitere Unterschichten dar. Die Präsentationsschicht übernimmt dabei die Aufgabe der Visualisierung der Daten und die Kommunikation mit dem Anwender. Die Applikationsschicht stellt die Anwendungsfunktionen zur Verfügung und die Datenhaltungsschicht übernimmt die Speicherung und Verwaltung der Informationen und regelt den (verteilten) Zugriff. Wenn beispielsweise ein Zugriff auf das System über Web-Browser ermöglicht wird, kann die Präsentationsschicht in eine serverseitige http-Server-Schicht zur Aufbereitung der Darstellung und eine clientseitige Browser-Schicht zum endgültigen differenziert werden. Aus technischer Sicht betrachtet sind aktuelle Systeme, wie die meisten PDM-Systeme oder andere Systeme zum Informations- und Prozessmanagement mit so genannten Client-Server-Architekturen realisiert, während datenerzeugende Systeme wie CAD-Systeme typischerweise eher monolithische Architekturen aufweisen. Monolithische Softwaresysteme vereinigen diese drei Schichten typischerweise in einer geschlossenen Applikation, die als Ganzes auf einem Rechner gestartet und ausgeführt wird. Der Systemadministrator muss sich bei diesen Systemen das Schichtenkonzept nicht in der Hardwarestruktur abbilden. So ist zunächst der Ersteinsatz leichter zu realisieren. Diese Systeme haben jedoch u.a. den Nachteil, dass die Verwaltung größerer Datenmengen von der Software selbst durchgeführt wird. Solche Aufgaben werden jedoch besser an speziell dafür ausgelegte neutrale d h. anwen-

202

5 Leithefte zu PLM-Aspekten

dungsunabhängige Datenbank-Managementsysteme delegiert. Diese können die Datenhaltungsschicht für eine beliebige Applikation übernehmen. Damit stellt sich die Frage, wie eine Schicht bzw. Funktionen einer Schicht auf Funktionen einer anderen Schicht zugreifen können. Hier hat sich das so genannte Client-Server-Modell etabliert. Ein Server – ein Dienste-Erbringer – stellt seine Dienstleitung wie zum Beispiel die Fähigkeit große Datenmengen zu speichern über (standardisierte) Schnittstellen nach außen zur Verfügung. Möchte ein Dienste-Nutzer – der Client – seine Daten an das speichernde System der Datenhaltungsschicht übergeben, nutzt er dazu entsprechende Funktionsaufrufe wie etwa zum Setzen eines Stammdatums einer speziellen Baugruppe auf einen neuen Wert „Baugruppe-XY.Durchmesser.set=17,3175mm“. Um diesen Funktionsaufruf absetzen zu können, muss der Client wissen, wie er die Dienste des Servers findet und aufruft, er muss aber nicht wissen, wie diese Dienste im Inneren weder ausgeführt werden noch implementiert sind. Diese Aufteilung stellt einen sehr großen Vorteil hinsichtlich der deutlich strukturierteren und einfacheren Handhabbarkeit großer Anwendungspakete dar. Auf Client-Server-Strukturen basierende Standardsysteme implementieren Präsentationsschicht, Applikations- und Datenhaltungsschicht in getrennten Softwarekomponenten, die auch auf verschiedenen Rechnern laufen können und über Schnittstellen miteinander kommunizieren (siehe Abb. 5-56). Je nach technischer Umsetzung von Client-Server-Systemen können die Funktionen der verschiedenen Schichten in unterschiedlichem Umfang auf Client und Server aufgeteilt sein. Üblicherweise implementiert der Client die Funktionen der Präsentationsschicht und der Server die Funktionen der Applikations- und/oder der Datenhaltungsschicht. Enthält die Serverkomponente des Softwaresystems Applikations- und Datenhaltungsschicht, spricht man auch von einer „Two-Tier-Architecture“. Komplexe Standardsoftwaresysteme wie z.B. PDM-Systeme bestehen in der Regel aus einem Basismodul und ergänzenden Modulen, die Funktionen eines bestimmten Bereichs beispielsweise Workflow-Management, Dokumentenmanagement oder Konfigurationsmanagement vollständig abdecken. All diese Module sind heute typischerweise auf einem PDMServer lokalisiert, der die Anwendungslogik implementiert und – über entsprechende Zugriffs- und Lizenzrechte geregelt – für (theoretisch beliebig viele) Clients zugreifbar ist. Die Verbindung zwischen den Clients und den Server-Modulen erfolgt heute in der Regel über das Internet. Sind auf Client-Seite außer einem Web-Zugriffsprogramm (Browser) keinerlei spezifische Softwaremodule erforderlich d.h. ist die komplette Präsentationsschicht beim Client brow-

5.10 Auf Standardsystemen aufbauen 203

ser-basiert, spricht man von „Zero-Footprint-Application“. Bei (PLM-) Anwendungen mit Dutzenden bis zu Hunderten weltweit verteilter Clients, die im PLM-Prozess eingebunden sind, hat dies den großen Vorteil, dass bei Änderungen bzw. Weiterentwicklungen am Kern des Systems keinerlei Anpassungen bei den Clients notwendig werden. Dem stehen Überlegungen der Performanz, des Datendurchsatzes und nicht zuletzt auch der Datensicherheit und des Datenzugriffsschutzes entgegen. Erfolgt jeglicher Zugriff auf Produktdaten – z.B. auf relativ große CAD-Modelle – über das Web, kann dies unter Umständen zu inakzeptablen Zugriffs- bzw. Wartezeiten und damit zu Benutzerakzeptanzproblemen führen. Dann werden spezifische Clientprogramme erforderlich, die einen gewissen Anteil der Verarbeitungsleistung vor Ort beim jeweiligen Client-Rechner erledigen. Die Abb. 5-56 zeigt noch einmal den Unterschied zwischen monolithischen und geschichteten Anwendungssystemen am Beispiel von CAD-, PDM- und ERP-Systemen: Das Konzept der so genannten „Serviceorientierten Architektur“ (Service Oriented Architecture, SOA) verfolgt eine noch stärkere Modularisierung und ein noch stärkeres Abstrahieren von den Implementierungsdetails im Vergleich zur prozessgetriebenen Architektur herkömmlicher Softwaresysteme. Beim SOA-Ansatz werden die einzelnen Funktionen eines Softwaresystems durch eine Kollektion von einfach aufgebauten Diensten (Services) bereitgestellt, die miteinander kommunizieren. Dabei können die Dienste auf verschiedenen Rechnern ausgeführt und der gegenseitige Dienstaufruf über das Internet realisiert werden. Diese Möglichkeit ist besonders bei der verteilten Zusammenarbeit von Firmen von Vorteil, da diese Rechner Informationen aus den jeweiligen Firmen über Dienste sicher und transparent d.h. unabhängig von deren Implementierung bereitstellen können. Beispielsweise könnte die Abfrage einer kompletten Baugruppe durch eine Kollektion von Diensten zum Zusammenstellen der Baugruppeninformationen, Diensten zum Bereitstellen der einzelnen Bauteilinformationen aus den an der Baugruppe beteiligten Partnersystemen sowie Diensten zur Authentifizierung der Anwender durchgeführt werden. Der derzeit viel diskutierte SOA-Ansatz ist jedoch auf relativ grob granulare Dienste ausgerichtet und es stellt sich die Frage, wer einen bestimmten standardisierten Satz an PLM-spezifischen Diensten spezifiziert. Hier gibt es mit der PLM-Services-Spezifikation der Object Management Group (OMG 2008) erste Spezifikationen, die ihrerseits zum einen an der so genannten Modell-getriebenen Architektur (Model Driven Architetcure MDA) und zum anderen am Standard for the Exchange of Product Model Data (STEP, s. Abschnitt 3.5) ausgerichtet sind.

204

5 Leithefte zu PLM-Aspekten

Abb. 5-56: Standardsoftware im Bezug zum drei Schichtenmodell

Ein weiteres Fragezeichen bleibt offen, was die Herstellerunterstützung der SOA-Vision betrifft. Anbieter von PLM-Software sind in aller Regel nicht sonderlich an der konsequenten Umsetzung dieses Ansatzes interessiert, da sie die Gefahr sehen, dass ein Kunde sich Funktionen bei unterschiedlichen Diensteanbietern zukauft und somit nicht mehr so stark wie bisher an eine spezielle Softwareplattform gebunden werden kann. Es bleibt abzuwarten, wie stark sich dieser Trend im PLM-Bereich durchsetzen wird. Unabhängig von der Umsetzungsarchitektur bleibt jedoch die Notwendigkeit, die unternehmensspezifischen Anforderungen und PLMKonzepte möglichst abstrakt, modellbasiert und damit Technologie- und Standardsystem-unabhängig zu beschreiben, um bei Technologiesprüngen oder Anbieterwechsel weitestgehend rückwirkungsfrei zu bleiben und das PLM-Know-how langfristig und kontinuierlich aufbauen und sichern zu können. 5.10.4 Anpassung von Standardsoftwaresystemen Für die Anpassung von Standardsoftwaresystemen werden teilweise auch die Begriffe Adaption oder Customizing (siehe Abschnitt 4.5.2) verwendet.

5.10 Auf Standardsystemen aufbauen 205

Diese Begriffe bezeichnen im Allgemeinen die Anpassung eines Systems an die kunden- bzw. unternehmensspezifischen Anforderungen. Standardsoftwaresysteme können an die unternehmensspezifischen Anforderungen dabei in unterschiedlicher Art angepasst werden (Adamietz 2001): x Parametrisierung: Bei der Parametrisierung erfolgt die unternehmensspezifische Anpassung durch eine Auswahl von vorgegebenen Funktionen, Prozessen und Formaten, beispielsweise durch das Einstellen der Sprache. Eine Anpassung über diese vom System vorgegebenen Möglichkeiten besteht bei der Parametrisierung jedoch nicht. Da sich die Anpassung in einem vom Hersteller vordefinierten Rahmen bewegt, können auf diese Weise Probleme bei der Wartung des Softwaresystems z.B. beim Einspielen von Software-Updates vermieden werden. x Anpassung bzw. Erweiterung von Referenzmodellen: Eine umfangreichere Art der Anpassung ist durch die Anpassung der internen Datenmodelle möglich, welche die Softwaresysteme verwenden. Dabei werden diese Referenzmodelle, wie z.B. Daten- oder Prozessmodelle, durch entsprechende Eingriffe angepasst bzw. erweitert. Je nach System sind hierzu entweder bereits mitgelieferte oder zusätzlich zu beschaffenden Entwicklungs- bzw. Modellierungswerkzeuge erforderlich. Mit Anpassung bzw. Erweiterung der internen Modelle ist somit auch eine Systemerweiterung über den vom Hersteller vorgegebenen Rahmen hinaus möglich. Diese Art der der Anpassung ist beispielsweise bei PDM-Systemen weit verbreitet. x Ergänzungsprogrammierung: Als weitere Art der Anpassung von Standardsoftwaresystemen kann die so genannte Ergänzungsprogrammierung angesehen werden. Durch sie kann ein Standardsoftwaresystem nahezu beliebig angepasst bzw. um weitere Funktionalitäten ergänzt werden. Dies kann typischerweise entweder durch systemeigene, integrierte Skriptsprachen oder über spezielle Programmierumgebungen mit einer der üblichen Programmiersprachen wie C#, JAVA usw. erfolgen. Durch umfangreiche Ergänzungsprogrammierung kann ein Standardsoftwaresystem im Extremfall bis zu einer Individuallösung weiterentwickelt werden. Diese Art des Eingriff entbindet den Hersteller jedoch in der Regel von seinen Gewährleitungsverpflichtungen und kann insbesondere bei ReleaseWechsel der Standardsoftware zu erheblichen Problemen führen, da dann meist nicht mehr für die Funktionsfähigkeit des Kernsystems garantiert werden kann.

206

5 Leithefte zu PLM-Aspekten

Unabhängig von den grundsätzlichen Möglichkeiten zur Anpassung eines Standardsoftwaresystems sind dessen Nutzungsmöglichkeiten im Basisauslieferungszustand von großer Bedeutung. Je größer der erforderliche Anpassungsaufwand ist, der notwendig wird, um die geforderten Anforderungen abzudecken, desto höher sind die damit verbundenen Kosten und desto länger ist der Zeitraum von der Konzeption bis zur Produktivschaltung des Systems. Am Beispiel der PDM-Systeme teilt Schöttner (Schöttner 1999) die Systeme nach ihrer nutzbaren Funktionalität in die folgenden Systemklassen ein: x Turnkey-Lösungen: Eine Turnkey-Lösung bietet sofort nutzbare Anwendungsfunktionalität über konfigurierbare Anwendungsmodule sowie Werkzeuge zur weiteren Anpassung des Systems. x Toolbox-Ansätze: Ein Toolbox-System ist eine Entwicklungsumgebung zur Realisierung von kundenspezifischen (PDM-)Lösungen, die jedoch keine oder nur wenig Anwendungsfunktionalität „Out-of-the-Box“ enthält. x Toolbox-basierende Turnkey-Lösungen: Toolbox-basierende Turnkey-Lösungen enthalten zusätzlich zur Entwicklungsumgebung bereits fertig implementierte Basisfunktionen. Funktional besteht kein Unterschied zur Turnkey-Lösung. Der Unterschied besteht vielmehr darin, dass Basisfunktionalitäten von anderen Softwareunternehmen für das jeweilige Tollbox-System entwickelt und am Markt angeboten werden. Für die Anpassung von Standardsoftwaresystemen spielen die unternehmensspezifischen Prozesse und Organisationsstrukturen eine zentrale Rolle, da sie durch den Einsatz der Software unterstützt bzw. optimiert werden sollen. Je nachdem, ob die Organisation oder die technologische Plattform geändert wird, wird bei der Anpassung von Standardsoftwaresystemen zwischen Prozessanpassung und Softwareanpassung unterschieden (Adamietz 2001). Bei der Softwareanpassung wird ein Standardsoftwaresystem entsprechend der Prozesse und Organisationsstrukturen eines Unternehmens angepasst. Auf diese Weise erhält das Unternehmen ein Softwaresystem, das eine optimale Unterstützung bietet, aber auch entsprechend hohen Aufwand an Kosten und Zeit für die Anpassung erfordert sowie technisch hohe Anforderungen an die Flexibilität des Systems stellt. Werden die Geschäftsprozesse eines Unternehmens an die Funktionalität des Standardsoftwaresystems angepasst, wird von Prozessanpassung gesprochen, wobei dies in der Regel nicht zu einer für das Unternehmen optimalen Prozessunterstützung führt. Der Vorteil der Prozessanpassung

5.10 Auf Standardsystemen aufbauen 207

liegt in den geringeren Kosten für die Softwareeinführung und dem geringeren Aufwand für die Systempflege gegenüber einer Softwareanpassung. Im Normalfall wird bei der Anpassung von Standardsoftwaresystemen weder eine reine Softwareanpassung noch eine reine Prozessanpassung durchgeführt, sondern es wird ein Mittelweg zwischen beiden Möglichkeiten gewählt. Standardsoftwaresysteme im Product Lifecycle Management, insbesondere PDM-Systeme, verlangen in hohem Maße nach unternehmensspezifischen Anpassungen, um den oft sehr speziellen Anforderungen vor allem in Entwicklung und Konstruktion eine optimale Unterstützung bieten zu können. Bei diesen Anpassungen stehen deshalb vor allem die folgenden Gesichtspunkte im Vordergrund: x Die möglichst umfassende und formale Beschreibung der zugrunde liegenden Prozesse (z.B. Freigabe- und Änderungsabläufe) x Die Rollenzuteilung und Vergabe von Benutzerberechtigungen x Die Festlegung der Daten- bzw. Objektmodelle x Die unternehmensspezifische Gestaltung der Benutzungsoberflächen Deshalb sollte neben der grundsätzlichen Anpassbarkeit als solche bei den Anpassungsmöglichkeiten von Standardsoftwaresystemen ebenfalls die Unterstützung durch die Systemhersteller und Verfügbarkeit von geeigneten Werkzeugen zur Anpassung beachtet werden. 5.10.5 Durchführung von Anpassungen und Systempflege Die Grundlage der Systemanpassung bildet eine umfangreiche Ist-Analyse des Unternehmens, mit deren Ergebnissen ein Soll-Konzept erarbeitet wird, welches dann im System umgesetzt wird (siehe Abschnitt 5.7). Die technische Umsetzung der Anpassung wird im Falle der Anpassung bzw. Erweiterung von Referenzmodellen und der Ergänzungsprogrammierung über Änderungen bzw. Ergänzung des Datenmodells des Systems vollzogen. Dabei werden typischerweise Klassen – programmiersprachliche Konstrukte der sog. Objektorientierten Programmierwelt – verändert, indem Attribute und Methoden angepasst, gelöscht oder hinzugefügt werden. Stehen diese Klassen in Beziehung zu weiteren Klassen, müssen dort ebenfalls korrespondierende Anpassungen durchgeführt werden. Bei der Anpassung über Parametrisierung werden dagegen bestimmte Attributwerte gesetzt, die auf bereits vordefinierte Objekte (Instanzen von Klassen) verweisen. Die Abb. 5-57 zeigt ein Beispiel für Parametrisierung bzw. Ergänzung eines Datenmodells.

208

5 Leithefte zu PLM-Aspekten

Abb. 5-57: Anpassung eines typischen Referenzmodells

Mit der Einführung eines Softwaresystems sind die Arbeiten an diesem System in der Regel nicht beendet. Vielmehr muss eine kontinuierliche Pflege und Wartung des Systems erfolgen, die bei individuell angepassten Softwaresystemen in einigen Fällen auch größere Schwierigkeiten bereiten kann. Zum einen machen Änderungen von Geschäftsprozessen oder Organisationsstrukturen immer eine erneute Anpassung des Systems notwendig und sind dann nicht selten mit Problemen verbunden, da die Anpassungen des Systems häufig nicht oder nur ungenügend dokumentiert wurden. Nicht zuletzt aus diesem Grund sollte entsprechend dem hier vorgestellten evolutionären Vorgehensmodell eine kontinuierliche Dokumentation aller Anpassungsarbeiten im PLM-Manifest (siehe Abschnitt 3.6) erfolgen. Zum anderen stellen Updates oder Releasewechsel des Softwaresystems den Nutzer vor Probleme, wenn sie aufgrund der im System vorgenommenen Anpassungen nicht ohne weiteres durchgeführt werden können. Updates ersetzen einzelne Komponenten des Softwaresystems, beispielsweise um Fehler zu beseitigen oder die Funktionalität in geringem Umfang zu erweitern. Ein Update verursacht demnach nur dann ein Problem, das nicht der Systemanbieter zu vertreten hat, wenn es Teile der Software ersetzt, die zwischenzeitlich vom Nutzer angepasst wurden. Zur Lösung dieses Problems muss im ungünstigsten Fall der ursprüngliche Zustand der Komponente wiederhergestellt werden, andernfalls ersetzt das Update einfach die betreffende Komponente. In beiden Fällen muss jedoch eine erneute An-

5.10 Auf Standardsystemen aufbauen 209

passung der betroffenen Komponente des Softwaresystems vorgenommen werden. Eine neue Version eines Softwaresystems wird als Release (engl.: Freigabe) bezeichnet, die in der Regel neben beseitigten Fehlern eine erweiterte und verbesserte Funktionalität zur Verfügung stellt. Diese erweiterte Funktionalität beinhaltet jedoch unter Umständen umfangreiche Änderungen am Datenmodell des Softwaresystems, sodass erfolgte Anpassungen meist nicht ohne Wweiteres von der Vorgängerversion übernommen werden können. Ein Releasewechsel kann prinzipiell als ein Update aller Systemkomponenten durchgeführt werden, allerdings treten in diesem Fall die gleichen Probleme zutage, wie beim Update einzelner Komponenten. Aufgrund dessen werden Releasewechsel in der Regel als Neuinstallationen des Softwaresystems ausgeführt – meist in Verbindung mit leistungsfähigerer, neuer Rechnerhardware. Soweit die Möglichkeit besteht, werden Anpassungen des Vorgängersystems übernommen und dessen Daten in das neue System überführt. Weiterführende Literatur

Abramovici M (1999) EDM/PDM-Einführungsstrategien – Erfahrungen und Perspektiven. Informationsverarbeitung in der Konstruktion 99: 209 – 226 Adamietz P. (2001) Adaption von Standardsoftwaresystemen. Shaker Verlag, Aachen OMG (2008) Object Management Group - Product Lifecycle Management Services, V2.0 OMG Beta-2 Specification; www.omg.org Schöttner J (1999) Produktdatenmanagement in der Fertigungsindustrie, Prinzip, Konzepte, Strategien. Hanser Verlag, München Wien Vajna S (1999) Die neue Richtlinie VDI 2219: Praxiserprobte Hinweise zu Einführungsstrategien und Wirtschaftlichkeit von EDM/PDMSystemen.Informationsverarbeitung in der Konstruktion 99: 25 – 42 VDI-Richtlinie 2219 (2002) Einführungsstrategien und Wirtschaftlichkeit von EDM/PDM-Systemen (Reihe Datenverarbeitung in der Konstruktion). VDI-Gesellschaft Entwicklung Konstruktion Vertrieb, Düsseldorf

210

5 Leithefte zu PLM-Aspekten

5.11 Systeme kommunizieren lassen

Æ Prozess- und Organisationsmanagement An die Stelle manueller Verarbeitung, Speicherung und Übermittlung von Information sind computergestützte Formen getreten. Mit dieser Automation ist eine starke Individualisierung, Flexibilisierung und Beschleunigung der Informationsflüsse verbunden, wodurch insbesondere der Grad der Aktualität der Information erheblich gesteigert wird. Im günstigsten Fall steht somit jede benötigte Information problembezogen aufbereitet sofort, jederzeit und an jedem beliebigen Ort zur Verfügung. Dies ist jedoch meist mit hohem Aufwand für die Planung, Umsetzung und Wartung der jeweiligen Kommunikations- bzw. Integrationslösungen verbunden. Grundsätzlich ist davon auszugehen, dass das Erledigen jeglicher produktbezogener Art von Aufgaben in einem Unternehmen entsprechende Daten und Informationen voraussetzt. Der gesamte Produktions- und Dienstleistungsprozess ist somit vom Informationsfluss entlang der Wertschöpfungsketten begleitet. Solche Informationsflüsse sind Grundlage für Entscheidungen, wodurch hohe Anforderungen an die IT-Unterstützung von PLM-spezifischen Prozessen innerhalb von Abteilungen eines Unternehmens und zunehmend über Abteilungs- und auch Unternehmensgrenzen hinweg entstehen. Die zugrunde liegenden Daten werden in den unterschiedlichsten Informationssystemen und aufgabenspezifischen Applikationen wie beispielsweise PDM-, ERP-, PPS-, CAD-Systemen oder OfficeAnwendungen erzeugt, verwaltet, immer wieder geändert und so gemeinsam im Sinne des Concurrent and Simultanous Engineering entlang der Wertschöpfungsketten im PLM allen Beteiligten zugänglich gemacht. Um möglichst effiziente Informationsflüsse zu erhalten und die sich fortlaufend ändernden Bedürfnisse nach Informationsaustausch (Data Exchange) bzw. gemeinsamer Nutzung von Informationen (Data Sharing) befriedigen zu können, ist die Kopplung der verschiedenen Systeme und Applikationen nötig. Schwierig, aufwendig und komplex ist diese Aufgabenstellung deshalb, weil hier gleich drei Dimensionen der Komplexität aufeinander stoßen. Zum einen werden die mit dem Product Lifecycle Management verbundenen Daten ständig mehr und in sich selbst durch die immer stärkere Digitalisierung der Gesamtprozesse in der Produktentwicklung immer komplexer. Zum zweiten nimmt die Vielfalt an IT-Systemen und Tools im PLM und damit auch die Komplexität bezüglich deren Kopplung bzw. Integration ständig zu. Drittens ändern sich permanent softwaretechnische Basisansätzen zur Beherrschung von zunehmend verteilten (Entwicklungs-)Prozessen konfrontiert. Hier kursieren Ansätze wie verteilte Datenbanken, Middleware, Service Orientierte Architekturen und

5.11 Systeme kommunizieren lassen 211

vieles mehr. All dies Themenkomplexe, die jeder für sich schon äußerst schwer zu durchdringen sind, stellen in ihrem Zusammentreffen insbesondere für kleinere und mittlere Unternehmen sehr große Hürden dar. Deshalb ist der Wunsch nach „All-in-One-Lösungen“ zwar verständlich aber leider in den seltensten Fällen umsetzbar. 5.11.1 Applikationsintegration und Datenaustausch

Abb. 5-58: Applikationsintegration und Datentausch im PLM-Umfeld

212

5 Leithefte zu PLM-Aspekten

Die Kopplung von IT-Systemen kann im einfachsten Fall über eine explizite Schnittstelle erfolgen, die Daten aus einem System extrahiert, entsprechend „verpackt“, sie über geeignete Netzwerkstrukturen – z.B. über das Internet – versendet, um sie auf der Empfängerseite „auszupacken“ und in das vom empfangenden System geforderte Format zu übertragen. Eine ganz andere und von der technischen Seite her betrachtet ungleich aufwendigere und komplexere Art der Kopplung stellt die sog. Applikationsintegration dar, bei der die Systeme so miteinander „verschränkt“ sind, dass sie ihre Funktionen gegenseitig nutzen können. So kann bei entsprechend tiefer Integration der entsprechenden Systeme – die in der Regel nur durch die jeweiligen Systemexperten erfolgen kann – beispielsweise nach Fertigstellung einer Baugruppenausarbeitung im CAD mit dem dortigen „Speichern-Befehl“ unmittelbar das Einchecken aller Baugruppenspezifischen Daten in ein integrierendes PDM-Backbone-System erfolgen. Daher bieten Systeme mit Integrationscharakter wie PDM-, PLM- oder ERP-Systeme in ihrem Funktionsspektrum i.d.R. entsprechende Dienstefunktionen bereit, die es erlauben, entsprechende Schnittstellen bzw. Integrationslösungen zu implementieren (siehe Abb. 5-58). 5.11.2 Optimiertes PLM durch Applikationsintegration Für die Unterstützung verteilter Produktentwicklungsprozesse werden grundsätzlich die gleichen Funktionen der Integrationssysteme herangezogen wie bei konventionellen Prozessen. Hinsichtlich der verwendeten Technologie und der Datenhaltung sind jedoch einige Besonderheiten zu beachten. Spezielle Anforderungen sind z.B. die Möglichkeit einer verteilten Datenhaltung mit kontrollierter Redundanz, d.h. man nimmt aus Performance-Gründen einerseits bewusst eine (mehrfache) Datenhaltung in Kauf, muss dann aber andererseits durch entsprechende Mechanismen für deren gezielten Abgleich sorgen. Weitere Aspekte sind schnelle Übertragungsraten bzw. kurze Antwortzeiten bei standortübergreifenden Prozessen, die Gewährleistung der Datensicherheit und Datenschutz bei Übertragung etc. Eine entsprechend umgesetzte Integration verschiedener Anwendungssysteme bietet dabei potenzielle Vorteile bei x Der Beschleunigung von Prozessen durch Automatisierung, x Der Reduktion von Fehlern durch Vermeidung von Eingabe- oder Übertragungsfehlern bei Mehrfacheingaben (Datenkonsistenz über verschiedenen Applikationen hinweg),

5.11 Systeme kommunizieren lassen 213

x Der Reduktion von Kosten z.B. für die Stammdatenpflege in mehreren Applikationen und x Verbesserte Bedienergonomie durch Vereinheitlichung der einzelnen Anwendungen: Jeder Start der Anwendung erfolgt über ein zentrales System wie beispielsweise ein PDM-System. Je nach dem welche Informationen integriert werden sollen, wird zunächst zwischen den Integrationszielen mit Schwerpunkt auf Standortintegration oder Systemintegration unterschieden. In den verschiedenen Standorten eines Unternehmens müssen gemeinsame Produktdaten verwaltet werden. Gemeinsame Geschäftsprozesse erfordern die gemeinsame Nutzung dieser Daten. Das bedeutet, dass bei der Standortintegration typischerweise eher gleichartige Systeme – beispielsweise mehrere PDM-Systeme – miteinander verbunden werden. Dies hat noch lange nicht zur Folge, dass selbst wenn an mehreren Standorten einheitliche Basis-Softwaresysteme eines Herstellers benutzt werden, der Datenaustausch bzw. eine tiefere Integration problemlos umsetzbar sind. Oft ist die Aufgabe einer Datenintegration bei diesem Szenario nicht einfacher als bei Systemen unterschiedlicher Hersteller, beispielsweise wenn bei standortspezifisch unterschiedlicher Anpassungen der Systeme (Customizing) die auszutauschenden Daten in verschiedenen Formaten vorliegen. Im einfachsten Fall wären zum Beispiel verschiedene Längen von Textfeldern oder unterschiedliche Formatierungen von Telefonnummern die zu überbrückende Hürde. Noch schwieriger wird eine Kopplung bzw. Integration, wenn beispielsweise unterschiedlich tiefe Baugruppenstrukturen vorliegen. 5.11.3 Voraussetzung für Applikationsintegration Die seit Beginn der digitalen Produktentwicklung in den einzelnen Funktions- und Unternehmensbereichen sukzessive eingeführten Applikationen (Anwendungssysteme) sind ursprünglich isoliert voneinander betrachtet, entwickelt und eingeführt worden. So war im Grunde unvermeidbar, dass im Laufe der Zeit aus einzelnen Insellösungen integrierte Anwendungssystemlandschaften mit mehr oder weniger starker Vernetzung der Einzelsysteme entstanden sind. Um den Informationsaustausch zu optimieren und redundante Eingabe und Verwaltung von Daten möglichst zu vermeiden, wird die Integration dieser Informationsinseln zu einer immer wichtigeren aber aufgrund der Integrationstiefe, der zunehmenden Integrationsweite sowie der ständigen informationstechnischen Weiterentwicklung auch zu einer anspruchsvollen, permanenten Aufgabe.

214

5 Leithefte zu PLM-Aspekten

Um diese Integrationsaufgabe bewerkstelligen zu können, muss zunächst festgelegt werden, in welchem Umfang und in welcher fachlichen und systemtechnischen Tiefe die Integration erfolgen soll, da dies einen erheblichen Unterschied im Aufwand für die Implementierungsarbeiten bedeutet. Man unterscheidet dabei wie oben bereits kurz ausgeführt zwischen einer reinen Datenintegration und einer Funktionsintegration. Primäres Ziel der Datenintegration ist es, eine mehrfache Erfassung und Datenhaltung zu vermeiden und so inkonsistente und sich inhaltlich überlappende Datenbestände zu verhindern. Das Ziel der Datenintegration kann durch eines der beiden folgenden Konzepte erreicht werden: x Durch expliziten Austausch von Daten zwischen den Systemen, umgesetzt durch entsprechende Kopplungsprozeduren (Data Exchange). x Durch Zugriff der Anwendungen auf eine gemeinsame Datenhaltung (Data Sharing). Ziel der Funktionsintegration dagegen ist es, Funktionen einer Anwendung transparent innerhalb einer anderen zur Verfügung zu stellen, um so inhaltliche Redundanzen zu vermeiden. Bei der Funktionsintegration greifen somit Funktionen verschiedener Anwendungssysteme ineinander. Die Integrationsleistung besteht beispielsweise darin, die Funktionen verschiedener Anwendungssysteme unter einer einheitlichen Benutzeroberfläche zusammenzufassen oder die Partner-Applikation zusammen mit den zu bearbeiteten Daten zu starten. Ein Beispiel hierfür ist ein im PDM-System verwaltetes CAD-Modell, zu dessen erneuter Bearbeitung das mit diesem Modell verbundene CAD-Programm direkt durch „Doppelklick“ aus dem PDM-System heraus geöffnet und mit den Funktionen des CAD-Systems bearbeitet werden kann.

Abb. 5-59: Standard- und Systemschnittstellen

5.11 Systeme kommunizieren lassen 215

5.11.4 Standardschnittstellen Bezüglich des zeitlichen Verlaufs beim Austausch von Daten wird zwischen synchronem und asynchronem Datenaustausch unterschieden. Beim synchronen Datenaustausch koppelt sich das Zielsystem über einen entsprechenden Kanal – z.B. das Internet – an das Quellsystem an und die Daten werden dann online, d.h. zum Zeitpunkt übertragen, wenn sie im Zielsystem benötigt werden. Im Gegensatz dazu werden beim asynchronen Datenaustausch die Produktdaten vom Quellsystem zur Verfügung gestellt. Mit den nutzenden Zielsystemen werden die Daten in bestimmten Zeitabständen z.B. einmal täglich in der Nacht, oder sofort, nachdem die Daten im Quellsystem bereit stehen, abgeglichen. Wenn zwei Informationssysteme direkt miteinander kommunizieren sollen, muss für jede Richtung jeweils eine spezifische Schnittstelle entwickelt und implementiert werden. Bei dieser Form wird entsprechend von Direktschnittstellen gesprochen. Der Vorteil liegt darin, dass diese Direktschnittstellen jeweils sozusagen ohne Umwege und damit sehr effizient und schnell von einem Format ins andere konvertiert werden. Allerdings führt diese Philosophie wie in Abb. 5-59 dargestellt bei zunehmender Zahl der zu integrierenden Systeme zu einer Explosion der Schnittstellen (quadratisch mit der Anzahl der Systeme) und damit zu einer enormen Komplexität bezüglich der Beherrschung eines solchen „Schnittstellendschungels“. Bei Änderungen an einer Stelle in einem System müssen an entsprechend vielen Stellen die Schnittstellenprozeduren angepasst werden. Ausweg aus diesem Dilemma bietet gewissermaßen ein bewusst in Kauf genommener „Umweg“ über eine standardisierte Zwischenschicht – eine Standardschnittstelle. Alle Systeme konvertieren hier in das gemeinsame „Schnittstellen-Esperanto“ der Standardschnittstelle, wodurch sich die Anzahl der zu implementierenden Schnittstellen deutlich verringert (linear zur Anzahl der Systeme). Allerdings hat dieses Konzept seinen Preis. Die an einen solchen Standard anzuschließenden Systeme müssen sich gewissermaßen erst einmal auf diese gemeinsame Austauschsprache einigen. Um das oben angedeutete Beispiel eines BaugruppenDatenaustausches noch einmal zu bemühen, müssten sich alle Systemverantwortlichen auf ein gemeinsames Strukturformat beispielsweise für Baugruppen in dieser Schnittstellenebene einigen, damit schließlich jedes System seine Baugruppendaten auf dieses Strukturformat abbilden kann. Es stellt dann jedoch die Frage, wie ein solches gemeinsam abgestimmtes Standformat unter Berücksichtigung der Belange jedes einzelnenn entwickelt werden kann.

216

5 Leithefte zu PLM-Aspekten

Um hier nicht bei jedem Datenaustausch- bzw. -integrationsproblem das Rad neu zu erfinden, existieren heute Standards wie z.B. Standard for the Exchange of Product Model Data (STEP, (siehe Abschnitt 3.5), die es erlauben, auf der Basis vordefinierter Bausteine spezifische Austauschschnittstellen zu erzeugen. Mit STEP wurde eine standardisierte Basis für den Datenaustausch von Produktdaten geschaffen, die so eine einfachere Integration von individuellen Produktmodellen verschiedenster Applikationen erlaubt. STEP ist eine internationale Norm (DIN EN ISO 10303), die ein Produktmodellschema sowie ein Übertragungs- und Archivierungsformat definiert, das alle im Produktlebenszyklus entstehenden Informationen beinhaltet. Im Rahmen der STEP-Entwicklung wurden neben dem eigentlichen Produktmodell zusätzlich eine formale, objektorientierte Sprache zur Modellspezifikation, verschiedene Austausch- und Archivierungsformate sowie Methoden zum Test der Konformität von Implementierungen entwickelt. Dementsprechend lassen sich die einzelnen Modelle von STEP („Parts“) der Bereiche zur Beschreibung von Produktdaten, Beschreibungsmethoden, Implementierungsmethoden und Methoden zum Konformitätstest unterteilen (STEP, (siehe Abschnitt 3.5): Die Modelle zur Beschreibung von Produktdaten lassen sich wiederum in die sog. Integrated Resources und Anwendungsprotokolle unterteilen. Die Integrated Resources umfassen Basismodelle, die die Grundlage für alle weiteren, in mehreren Stufen darauf aufbauenden Datenmodelle bilden. Grundelemente, die hierzu gehören, sind zum Beispiel: Produktstruktur, Produktidentifikation, Produktkonfiguration, Material, etc. In einer ersten Stufe bauen darauf die Anwendungsmodelle auf, welche allgemeingültige Inhalte haben, wie zum Beispiel Zeichnungen, Finite Elemente Methode, Kinematik etc. Die oberste Stufe sind die Anwendungsprotokolle. Sie spezifizieren jene Datenmodelle, die die Grundlage für Implementierungen sind, zum Beispiel „Core Data for Automotive Mechanical Design and Processes“. Jede STEP-Implementierung (zum Beispiel ein Datenaustauschprozessor) ist die Implementierung eines Anwendungsprotokolls. Die Beschreibungsmethoden beinhalten die Beschreibung der Datenmodellierungssprache EXPRESS (ISO10303-11) zur Spezifikation von Datenmodellen. EXPRESS ist eine objektorientierte Datenmodellierungssprache. Neben der Möglichkeit der textuellen Repräsentation von Modellen ist ebenfalls die grafische Notation EXPRESS-G (siehe Abb. 5-60) entwickelt worden. Ziel bei der Entwicklung dieser Modellierungssprache war es, ein Werkzeug zur konzeptionellen Modellierung zur Verfügung zu stellen, das die rechnerunterstützte Weiterverarbeitung der mit EXPRESS formal spezifizierten Modelle erlaubt. Die Abb. 5-61 zeigt beispielhaft,

5.11 Systeme kommunizieren lassen 217

wie ein Datenmodell einer technischen Zeichnung in EXPRESS-G modelliert werden kann, Abb. 5-62 hingegen in UML-Notation.

Abb. 5-60: Grafische Symbole in EXPRESS-G nach ISO 10303

Abb. 5-61: Darstellungsbeispiel einer technischen Zeichnung in EXPRESS-G

218

5 Leithefte zu PLM-Aspekten

Abb. 5-62: Darstellungsbeispiel einer technischen Zeichnung als UML-Notation

Die Implementierungsmethoden beinhalten Spezifikationen für Dateiformate und Schnittstellenimplementierung, beispielsweise für die Programmiersprachen Java oder C++. Der traditionelle Datenaustausch mit STEP basiert auf einem sequentiellen Dateiformat (Step Physical File Format). Dabei handelt es sich um eine ASCII-Datei, die auf jedem Rechner eingelesen und somit auch interpretiert werden kann. 5.11.5 Systemtechnische Sicht – APIs und Middleware Auf der systemtechnischen Ebene lässt sich eine Integration von Informationssystemen durch verschiedene Technologien realisieren. Für die technische Umsetzung einer Integrationslösung bieten die Applikationssysteme meist spezielle Programmierschnittstellen, so genannte Application Programming Interfaces (API) an. Diese APIs beinhalten standardisierte Softwareroutinen, Protokolle und Schnittstellenbeschreibungen, die den Zugriff auf die Daten und technischen Funktionen einer Applikation für andere Applikationen dokumentieren und so für Softwareentwickler zugänglich machen. Ähnlich wie beim Datenaustausch über spezielle 1:1 Schnittstelen liegt das Problem einer spezifischen Systemkopplung über Programmierschnittstellen darin, dass Komplexität und Aufwand für die

5.11 Systeme kommunizieren lassen 219

ständige Anpassung und Weiterentwicklung solcher Lösungen schnell aus den Fugen geraten. Eine Alternative bieten technisch sehr umfangreiche, explizite Integrationsansätze, die eine Zwischenschicht zwischen alle zu integrierenden Systeme legen und so gewissermaßen eine „heile Welt“ vorgaukeln. Diese mit dem Begriff Middleware bezeichnete Klasse von Software, die Informationen zwischen mehreren, verteilten und verschiedenen Applikationen vermittelt und die Kommunikation und den Datentransfer steuert und kontrolliert, stellt den heutigen Stand der Integrationstechnik dar, die in verschiedenen Formen am Markt verfügbar bzw. zunehmend in PLMLösungen verfügbar ist. Middleware bezeichnet zunächst das allgemeine Abstraktionskonzept einer Softwareschicht, die zwischen heterogenen, auf unterschiedlichen Plattformen laufenden und über Netzwerke verbundenen Anwendungssystemen und Datenquellen vermittelt und so eine Integration zu unternehmens-/organisationsübergreifenden Anwendungen ermöglicht. Darüber hinaus wird ebenfalls die Klasse aller verfügbaren Software-Technologien, die in irgendeiner Form zur Erfüllung dieser Funktion beitragen, als Middleware bezeichnet. Middleware muss allgemein eine Reihe von Diensten und Schnittstellenfunktionen anbieten, die es verteilten Applikationen/Prozessen erlauben, über Netzwerkgrenzen hinweg zu interagieren und zu kooperieren. Wichtige Aspekte hierbei sind: x Bereitstellung lokaler Transparenz (Ortstransparenz) d.h. Verbergen der Verteilung sprich der Tatsache, dass die Gesamtanwendung aus mehreren verteilten Komponenten aufgebaut ist x Unabhängigkeit von den Details der Netzwerke und Kommunikationsprotokolle x Unabhängigkeit von den Details der Betriebssysteme sowie der Hardware x Interoperabilität unterschiedlicher Applikationen x Programmiersprachen-Unabhängigkeit x Bereitstellung eines einheitlichen, standardisierten Satzes von Schnittstellenfunktionen, die es Entwicklern und Integratoren ermöglichen, aus den verteilten Komponenten und Funktionen wieder verwendbare, portierbare und anpassbare Gesamtapplikationen zu generieren Da Middleware mehr für ein Abstraktionskonzept als für eine bestimmte Technologie steht, besteht keine völlig geschlossene und einheitliche Beschreibung und Eingrenzung der mit diesem Begriff bezeichneten Ansätze. Grundsätzliche Möglichkeiten der Unterscheidung von Middleware sind

220

5 Leithefte zu PLM-Aspekten

proprietäre gegenüber standardbasierten sowie asynchronen gegenüber synchronen Ansätzen. Darüber hinaus kann Middleware bezüglich des zugrunde liegenden Paradigmas der Integration in folgende Kategorien unterteilt werden. x Funktionsaufruforientiert/Remote Procedure Call (RPC)/Remote Method Invocation (RMI): Ermöglicht einer nutzenden Anwendung (Client) den Aufruf einer entfernten Funktion/Methode, die von einer anbietenden Anwendung (Server) über das Netzwerk zur Verfügung gestellt wird. x Nachrichtenorientiert/Message Broker: Lose Kopplung von Applikationen über den Austausch von Nachrichten (Publish/Subscribe). x Datenhaltungsorientiert/Remote Database Access: Anfragevermittlung an verteilte Datenhaltungssysteme/Datenbanken. x Transaktionsorientiert/Transaction Process (TP) Monitore: Koordiniert systemweit den Zugriff auf Ressourcen (primär Datenbanken und Dateien) über das Prinzip der Transaktion durch Einhaltung der ACID-Kriterien. x Objektorientiert/Object Request Broker: Erweiterung des objektorientierten Programmiermodells auf verteilte Objekte, die netzwerk- und teilweise programmiersprachenübergreifend Anwendungen verbinden (Verteilte Objektmodelle). x Komponentenorientiert: Setzen auf dem Verteilten Objektmodell auf und erweitern dies um die Vision einer zur Laufzeit erzeug- bzw. erweiterbaren Gesamtanwendung, die im Wesentlichen durch „Verdrahtung“ von frei am Markt verfügbaren Komponenten (Business Components) entsteht. x Service-orientiert: Das Zusammenspiel zwischen unterschiedlichen Anwendungen wird auf das gegenseitige zur Verfügungstellen von allgemein d.h. Technologie-neutral beschriebenen Diensten (Services) heruntergebrochen (Service Oriented Architecture SOA). Eine speziell für den Bereich des Produktdatenmanagements entwickelte und auf dem Prinzip der objektorientierten Middleware aufsetzende Spezifikation für die Implementierung von Daten- und Funktionsschnittstellen wird durch die Product Data Management Enablers (PDM Enablers) der Object Management Group beschrieben. Diese Spezifikation (Product Data Management Enablers Specification 2000) stellt Standardschnittstellen für Produkt- und Prozessinformationen aus Entwicklung und Konstruktion mit dem Ziel der Integration von Integrationssystemen und Fertigungs-

5.11 Systeme kommunizieren lassen 221

softwaresystemen zur Verfügung. Die Schnittstellenspezifikation beinhaltet Grundgerüste für die Implementierung und Schnittstellendefinitionen für die Interoperabilität von Systemen und Client-Software, die Produktinformationen verwalten, nutzen oder zur Verfügung stellen. PDM Enablers stellen nicht zwingend alle Schnittstellen für die gesamte Funktionalität zur Implementierung der Benutzerfunktionen von Integrationssystemen bereit. Zusammengefasst lässt sich sagen, dass sich je nach Aufwand mit Middleware eine deutlich höhere Integration erreichen lässt. Allerdings stellt Middleware selbst eine äußerst komplexe und aufwendig zu implementierende Technologie dar, die in der Regel nur von sehr erfahrenen Experten nutzbringend im Unternehmen eingesetzt werden kann. Ob der Einsatz einer auch aus Kostensicht typischerweise recht aufwendigen MiddlewareLösung in Betracht gezogen werden sollte, muss im Einzelfall unter Hinzuziehen von Experten geprüft werden. 5.11.6 Informationsintegration im PLM Das wesentliche Ziel des Product Lifecycle Managements ist die Verwaltung und Bereitstellung der aktuellen Produktdaten. Aus diesem Grund spielt die Integration von Applikationen und der Datenaustausch eine wesentliche Rolle, da sie die Voraussetzungen für eine an das jeweilige Unternehmen angepasste Form des Produktdatenmanagements bildet: Durch die Integration der verschiedenen Applikationen und Informationssysteme können die Produktinformationen an den geeigneten Stellen zentral oder verteilt gehalten und bereitgestellt werden. Je nach Art der Datenhaltung muss eine geeignete Integrationslösung umgesetzt. Bei der zentralen Datenhaltung greifen alle Systeme auf einen gemeinsamen Datenbestand zu, was in der Praxis jedoch in den seltensten Fällen zu realisieren ist. Stattdessen sind häufig replizierte Datenbestände vorzufinden, bei denen die Daten redundant, d.h. gleichzeitlich an mehr als einem Ort aufbewahrt werden. Über Replikationsmechanismen wird schließlich gewährleistet, dass bei Änderungen in einem Datenbestand die entsprechenden verteilten Datensätze, meist zeitversetzt, ebenfalls aktualisiert werden.

222

5 Leithefte zu PLM-Aspekten

Abb. 5-63: Möglichkeiten der Datenverteilung

Bei Lösungen mit bewusst angestrebter Mehrfachhaltung von Daten ist die durch örtlich nahe Zugriffe erzielbare bessere Performanz das wesentliche Ziel. Der Aufwand für die Replikation kann in speziellen Anwendungsszenarien verringert werden, in denen vorhergesagt werden kann, dass bestimmte Daten nur an bestimmten Orten genutzt werden. In diesen Fällen werden selektive Integrationsmechanismen angewendet, die die relevanten Datenanteile nur auf diese jeweiligen Orte verteilen, aber nicht alle Daten redundant an allen Orten halten. Man spricht in dabei von fragmentierter Datenhaltung. Bei fragmentierten Datenbeständen werden diese geteilt und jeweils dort gehalten, wo sie entstehen oder am häufigsten verwendet werden (Eigner u. Stelzer 2001). Die Abb. 5-63 zeigt verschiedene Möglichkeiten der Datenverteilung. Zusätzlich zu der eigentlichen Frage der Verteilung von Datenbeständen wird hierbei in zwei Kategorien von Daten unterschieden: die eigentlichen Nutzdaten wie beispielsweise CAD-Modelle oder Berechnungsdaten einer Baugruppe und die diese Nutzdaten beschreibenden Verwaltungsinformation wie beispielsweise Daten über den Bearbeitungs- oder Freigabestand eines CAD-Modells. Diese Art der beschreibenden Daten über Daten wird als Metadaten (siehe Abschnitt 5.3 und Abschnitt 5.4) bezeichnet. Bei verteiltem Management von Produktdaten befinden sich Metadaten

5.11 Systeme kommunizieren lassen 223

und/oder Nutzdaten auf getrennten Servern (siehe Abb. 5-63). Für örtlich verteiltes Produktdatenmanagement reicht es in der Regel nicht aus, an den räumlich entfernten Standorten einzelne Client-Anwendungen der ITSysteme zu installieren, die auf einen zentralen Server zugreifen, da besonders für Übertragung von Nutzdaten hohe Bandbreiten für die Datenverbindung erforderlich sind. Dies ist lediglich bei geringen Datenübertragungsanforderungen sinnvoll. In allen anderen Fällen gilt es, geeignete Verteilungsstrategien zu entwickeln und umzusetzen. CAD-Integration

Eine innerhalb des Product Lifecycle Managements zentrale Bedeutung kommt der Integration von CAD-Systemen bei. Im Gegensatz zu anderen Produktivsystemen muss eine geeignete CAD-Schnittstelle deutlich mehr Funktionalität als das reine Ein- bzw. Auschecken von Dateien und die Zugriffssteuerung auf diese bereitstellen. Die Integrationsanforderung zu einem integrierenden PDM-, ERP- oder Dokumentenmanagementsystem besteht darin, die im CAD-System vorhandenen Informationen automatisch in das umgebende System zu übernehmen, dort geeignet zu verwalten und zu Verfügung zu stellen. Dies beinhaltet in erster Linie die Baugruppen- bzw. die Produktstrukturen sowie alle stücklistenrelevanten Informationen. Zudem müssen umgekehrt zentral über das Verwaltungssystem verwaltete und gesteuerte Informationen wie beispielsweise die Artikelnummer oder die Bezeichnung beim Anlegen eines neuen CAD-Modells vom integrierenden System in das CAD-System übernommen werden. Die Schwierigkeit bei der Implementierung einer solchen „tiefen“ CAD-Schnittstelle besteht darin, dass die Zusammenbaustrukturen in jedem CAD-System unterschiedlich gehandhabt werden. Einige Systeme verwalten die Informationen in separaten Strukturdateien, andere verweisen auf die absoluten Pfade der Einzelteilmodelle und wiederum andere integrieren Strukturen und Geometrien im Modell, sodass die Schnittstellenentwicklung sehr tiefen Einblick in das CAD-System erforderlich macht (Wendenburg 2001). Somit muss die Schnittstelle die Strukturinformationen und weitere Metadaten wie z.B. die Artikelnummer im CADDatenmodell und im unternehmensspezifisch angepassten Datenmodell eines Integrations- oder Dokumentenmanagementsystems aufeinander abbilden. Daraus ergibt sich ein mit der Integrationstiefe stark ansteigender Zeit- und Kostenaufwand für die Implementierung von CADSchnittstellen.

224

5 Leithefte zu PLM-Aspekten

ERP-Integration

Eine weitere zentrale Schnittstellenproblematik im PLM betrifft die Berührung zwischen den produktzentrischen PDM-Systemen, in dem im Wesentlichen alle die Produkte beschreibenden Daten und Dokumente verwaltet werden, und den eher ressourcenorientierten Enterprise Ressource Planning-Systemen (ERP). Die Integration von PLM und ERP ist weit mehr als die bloße Integration zweier Software-Applikationen, sondern betrifft teilweise grundlegende Geschäftsprozesse eines Unternehmens (siehe Abschnitt 2.1 und Abschnitt 5.5). ERP-Systeme bedienen dabei üblicherweise die betriebswirtschaftlichen Aufgaben während PDM-Integrationssysteme eher die technischen Belange im Fokus haben. Da allerdings beide Systeme die Aufgabe haben, Geschäftsprozesse informationstechnisch zu unterstützen, ergeben sich zwangsläufig Überschneidungen in der Funktionalität und vor allem im Hinblick auf die gespeicherten Informationen. Aus diesem Grund lassen sich die Anforderungen an die Integration von PDM und ERP auch bis zu jedem beliebigen Umfang definieren, sodass hier der Nutzen ganz besonders vor der technischen Machbarkeit im Vordergrund stehen sollte. Es muss zudem festgelegt werden, welches System führend bei der Verwaltung bestimmter Daten ist, d.h. welches System die höhere Priorität für die produktrelevanten Geschäftsabläufe im Unternehmen besitzt. Grundsätzlich müssen die folgenden beiden Problemstellungen mit einer PDM-ERPIntegration adressiert werden: x Grunddaten wie Stücklisten und Materialstammdaten neu konstruierter Teile entstehen während des Konstruktionsprozesses und werden somit in den produktzentrischen Integrationssystemen abgelegt und verwaltet. Da es für neue Teile typischerweise zunächst keine Einträge im ERPSystem gibt, müssen die Grunddaten nach Produktionsfreigabe in dieses übertragen werden. Gleiches gilt für Projektdaten, Dokumente, Dokumentenstrukturen und das Änderungswesen. x Umgekehrt muss der Zugriff auf im ERP-System verwaltete bzw. gespeicherte zentrale Informationen wie beispielsweise die mit spezifischen Nummer- und Bezeichnungssystemen verbundenen Artikelbezeichner, durch möglichst offene Integrations- bzw. Schnittstellenlösungen dem Konstruktionsprozess zur Verfügung gestellt werden. Ebenfalls sind Kosteninformationen aus dem ERP-System für die Entwicklung interessant. Beispiele hierfür sind Herstellungs- und Entwicklungskosten.

5.11 Systeme kommunizieren lassen 225

5.11.7 Umsetzung von Integrationslösungen Applikationsintegration und Datenaustausch zwischen Systemen bieten viele Möglichkeiten der Verbesserung der Informationsverwaltung innerhalb von Geschäftsprozessen, erfordern jedoch gleichzeitig gleichfalls einen hohen Aufwand an Zeit und Wissen über die technischen Details der zu integrierenden Systeme. Aus diesem Grund sollten die folgenden Punkte bei Integrationsbestrebungen beachtet werden: x Art, Umfang und Tiefe der Integration bzw. Schnittstellenentwicklung müssen an den spezifischen Anforderungen des Unternehmens ausgerichtet werden, um ein möglichst ausgewogenes Verhältnis zwischen Aufwand und Nutzen zu erzielen. Hierbei müssen insbesondere mittelund langfristige Erwägungen mit einbezogen werden, wie beispielsweise die Frage der Auswirkungen von Releasewechseln oder Wechsel der Standardsoftware. x Ein relativ schwierig zu kalkulierendes Risiko bei Eingriff in Standardsoftware – und als ein solcher muss die Schnittstellenentwicklung bzw. die Systemintegration verstanden werden – ist, dass mit zunehmender Integrationstiefe entsprechende Anpassungen und Erweiterungen durchgeführt werden müssen, die mehr oder weniger tief in die Standardapplikation hineingreifen. Bei einem Releasewechsel der Applikationen können diese Anpassungen unter Umständen nicht übernommen werden und müssen angepasst oder gar neu implementiert werden. x Für die Implementierung einer Integrationslösung ist ein sehr umfangreiches Wissen über systeminterne Spezifikationen, APIs und Datenmodelle notwendig. Dieses Wissen muss entsprechend aufgebaut bzw. als Dienstleistung eingeholt und dann im Unternehmen dokumentiert und verankert werden. x Durch die Einbeziehung externer Dienstleister ergeben sich oft Abhängigkeit von deren Expertise und den durchgeführten Implementierungsarbeiten. Deshalb sollte in jedem Fall eine ausführliche Dokumentation der Anpassungsarbeiten eingefordert werden, um im Bedarfsfall den Partner wechseln zu können. Weiterführende Literatur

Anderl R, Trippner D (2000) STEP, Standard for the Exchange of Product Model Data. Teubner Verlag, Wiesbaden Eigner M, Stelzer R (2001) Produktdatenmanagement-Systeme – Ein Leitfaden für Product Development und Life Cycle Management; Springer Verlag, Berlin Heidelberg

226

5 Leithefte zu PLM-Aspekten

Henschke T. (2007): Konzeption und Entwicklung eines modellbasierten Rahmenwerks zur Anwendungsintegration im Product Lifecycle Resource Management; Dissertation, Universität der Bundeswehr München Schöttner J (1999) Produktdatenmanagement in der Fertigungsindustrie – Prinzip, Konzepte, Strategien. Hanser Verlag, München Wien Normen und Standards

ISO 10303: Standard for the Exchange of Product Data (STEP) ist in der Serie der ISO 10303–Normen verfügbar Die Norm ist in Beschreibungsmethoden (ISO 10303-1x), Implementierungsmethoden (ISO 10303-2x), Integrated Resources Basismodelle (ISO 10303-4x, -5x), Anwendungsmodelle mit allgemeingültigem Inhalt (ISO 10303-1xx) und Anwendungsprotokolle mit Datenmodellen für die Implementierung (ISO 10303-2xx) unterteilt. VDMA/VDA 66318 Ausgabe:1989-09: Industrielle Automation; Rechnerunterstütztes Konstruieren; Regeln für den CAD-Datenaustausch

5.12 Software in Produktstrukturen 227

5.12 Software in Produktstrukturen Die Software in den Produkten des klassischen Maschinenbaus gewinnt in den letzten Jahren zunehmend an Bedeutung. Beispielsweise 9 von 10 Innovationen im Automobilbau entstammen der Software (Göschel 2006). Dennoch wird die Software-Entwicklung heute in der Praxis eher als lästiges Muss empfunden, dass weder prozessual noch datentechnisch in den Produktentstehungsprozess eingebunden ist. Ein Wandel wird stattfinden müssen, sollen die Potentiale von Software im Maschinenbau unter hohen Qualitätsansprüchen zukünftig vermehrt ausgeschöpft werden. Dies betrifft insbesondere die Integration des Entwicklungsprozesses von Software. Werden heute in fortschrittlichen PDMImplementierungen immerhin abgeschlossene Software-Entwicklungen als Produktbestandteile verstanden, die durch Versehen von Teilenummern für ausführbare Software konfigurierbare Elemente im Kontext des übrigen Produktes werden. So versteht eben ein Maschinenbauer die Integration von Software: Software wird zu einem Teil. Jedoch ist selbst dieses Vorgehen nicht selbstverständlich, da Software typische Eigenschaften eines Bauteils fehlen. Zum Beispiel besitzt Software keine Masse. In diesem Leitheft soll die Frage behandelt werden, ob ein solches Vorgehen, das fertige Softwareentwicklungen als Teile eines mechanischen Produktes interpretiert, die Entwicklung von Software unterstützt. Wie die folgenden Ausführungen darlegen werden, ist diese Frage zu verneinen. Bei solchen Ansätzen kann lediglich fertig entwickelte Software im Rahmen von mechanischen Strukturen in das Konfigurations- und Produktstrukturmanagement einbezogen werden. Soll ein Produkt mechatronisch betrachtet werden und somit seine Entwicklung interdisziplinär unter Berücksichtigung aller beteiligten Disziplinen, reicht die Integration von Software in die Konfiguration mechanischer Produkte nicht aus. Software muss hierzu analog zur Mechanik über den gesamten Softwarelebenszyklus berücksichtigt werden. Dies bedingt aufbauend auf einer strukturellen Betrachtung von Software die Berücksichtigung aller definierenden Partialmodelle, die während der Softwareentwicklung aufgebaut werden. Diese beginnen mit Anforderungen über Spezifikationen, Architekturmodelle, Quellcode bis hin zur Dokumentation und schließlich der ausführbaren Software. So entstehen Software-Entwicklungen, deren Entwicklungen durch das PDM unterstützt werden und die wiederverwendbare Einheiten bilden. Werden alle zuvor aufgeführten Aspekte betrachtet, könnte angenommn werden, dass eine Rivalität zu Software-ConfigurationManagement- (SCM)-Systemen entsteht, die zur integrierten Entwicklung

228

5 Leithefte zu PLM-Aspekten

von Software heute typischerweise eingesetzt werden. Durch solche Überlegungen werden SCM-Systeme häufig als das Pendant der Software zu den PDM-Systemen in der Mechanik gewertet. Werden jedoch die zu unterstützenden Geschäftsprozesse verglichen, lässt sich eine differierende Integrationstiefe der Systeme in die jeweiligen Entwicklungsprozesse feststellen. Bietet SCM lediglich einen gemeinsamen dokumentenbasierten Work-Space für einzelne Entwicklungsprojekte, unterstützt es nicht die konzernweite, projektübergreifende Entwicklung – was der Zielsetzung eines PDM im Maschinenbau entspräche. Betrachtet werden hierbei ausschließlich Dokumente und keine weiteren alleinstehenden Daten, die durch eine Interpretation der Dokumente gewonnen werden könnten. Auch werden auf keine andere Weise beschreibende Daten zu den Entwicklungen erfasst. Folglich wird im SCM nicht zwischen Dokumenten und den beinhalteten Daten unterschieden. Die Strukturierung erfolgt entsprechend einem Filesystem, das durch die Ordnerstruktur der Entwicklungsumgebung vorgegeben wird. Die Stärken liegen hierbei auf der Versionierung und dem Zusammenführen von Änderungen bei verteilter Entwicklung. Wird folglich das Einsatzgebiet mit der Disziplin des Maschinenbaus verglichen, lässt sich feststellen, dass SCM nicht mit PDM sondern mit Teamdatamanagement-Systemen (TDM) für Teamentwicklungen vergleichbar ist. TDM-Systeme bieten teilweise ähnliche Funktionalität wie PDM-Systeme mit reduzierten Funktionsumfang und eingeschränkter Erzeugersystemunterstützung – meinst nur ein CAD-System desselben Herstellers. So bietet SCM unverzichtbare Funktionalität zur Entwicklung eines Software-Projekts im Team. Daher sollten beide Ansätze integriert werden. Das SCM-System soll für seine typische Funktionalität erhalten bleiben. Für die nachhaltige Verwaltung der Entwicklungen bietet das PDM das geeignete System. Dieses Leitheft zeigt einen Ansatz der ergänzend zu SCM-Funktionen PDM-Funktionalität in die SoftwareEntwicklung portiert (Dettmering 2008). Dieser Ansatz beschränkt sich zunächst auf die Verwaltung von Software losgelöst vom Produktkontext. Die Integration zu einem mechatronischen PDM wird im Leitheft „Interdisziplinäres Datenmanagement“ in Abschnitt 5.13 erläutert. 5.12.1 Herausforderungen einer SW-Struktur Wie einführend angedeutet, muss zur Unterstützung der Softwareentwicklung ein Integriertes Produktmodell der Software basierend auf einer Softwareproduktstruktur aufgebaut werden. Die Strukturierung wird sich erheblich von mechanischen Strukturen unterscheiden. Im Gegensatz zu den

5.12 Software in Produktstrukturen 229

Sichten einer Disziplin, ist diese neue Struktur jedoch nicht eindeutig in mechanische Strukturen überführbar. Vielmehr werden neue Strukturierungsaspekte herangezogen mit eigenen Strukturelementen. Das einfache Beispiel aus Abb. 5-64 verdeutlicht diesen Ansatz, in dem die mechanische Struktur eines Produktes mit der Softwarestruktur gegenübergestellt ist. Im oberen Teil der Abbildung ist die Strukturierung in der Mechanik angedeutet. Sie erfolgt bauteilorientiert entsprechend der physikalischen Ausprägung des Produktes. Unterschiedliche Denkweisen zur Strukturierung werden durch das Sichtenmanagement abgefangen.

Abb. 5-64: Strukturvergleich

230

5 Leithefte zu PLM-Aspekten

Im Gegensatz dazu wird Software ausschließlich auf Basis von Überlegungen und logischen Aspekten hierarchisch strukturiert. Funktionen und ihre Kompositionen sind nicht physisch vorhanden. Neben der logischen Dekomposition zeichnen sich SW-Architekturen durch kommunikative Relationen (Schnittstellen) aus, die in der Struktur mit berücksichtigt werden müssen. So entsteht eine zweidimensionale Struktur, zum einen eine logische Hierarchie, zum anderen eine vernetzte Kommunikation. Im Prozess des Softwaredesigns – von den Anforderungen bis zur Implementierung – werden solche Strukturen während der funktionalen Dekomposition eingesetzt. Insbesondere in der automobilen Softwareentwicklung folgt diesem Schritt eine Clusterbildung zur Identifikation ausführbarer Einheiten. Hier werden Softwareeinheiten wieder unter dem Aspekt der kleinsten geschlossenen Ausführeinheit aggregiert. So kann je nach Anzahl der Entwicklungsstufen der angewandten Entwicklungsmethoden die Zahl der Strukturen unterschiedlich ausfallen. 5.12.2 Strukturelemente Aus dem Abschnitt zuvor wird ersichtlich, dass zur Unterstützung der Entwicklung von Software Modifikationen am PDM-System vorzunehmen sind, wenn ein PDM-System als integrierendes System im SoftwareEntwicklungsprozess eingesetzt werden soll. Es gilt SoftwareEntwicklungen aus den SCM-Systemen zu übernehmen, die nach Möglichkeit zur Reduktion der Gesamtzahl an zu verwaltenden Elementen in größere Einheiten zusammengefasst werden. Diese Einheiten können nun von der Funktionalität eines PDM-Systems profitieren. Sie können durch beschreibende Meta-Daten ergänzt werden, sie können mit ihren Dokumenten verbunden werden, sie können projektneutral entwickelt und über eine Produktstruktur in einem Produktkontext „verbaut“ werden. Diese Einbindung von Software bedingt jedoch weitreichende Modifikationen am Metamodell des PDM-Systems. Neben Objekten für die Software müssen weitere Relationen für die unterschiedlichen Schnittstellen und Strukturinformationen eingerichtet werden. Zur Verdeutlich dieses Aspekts soll wiederum ein Vergleich zu mechanischen Strukturen bemüht werden. In den Knoten einer mechanischen Struktur sind Positionierungsinformationen in Form von Transformationsmatrizen hinterlegt. Geometrische Informationen werden bei Software nicht benötigt. Jedoch kann dieselbe Softwarefunktion mehrfach in einem Softwareprodukt mit unterschiedlichen Schnittstellaufrufen und somit mit einer unterschiedlichen Funktionserbringung Verwendung finden. Hier-

5.12 Software in Produktstrukturen 231

durch wird bei Mehrfachverwendung derselben Softwarefunktion eine exakte Identifikation jeder Ausprägung benötigt, um kommunikative Abhängigkeiten präzise zuordnen zu können. Daher müssen Occurences, die Elemente, die bisher die Transformationsinformationen einer Struktur beinhalteten und daher eindeutige Repräsentanten der Ausprägungen einer Entwicklung in einer Produktstruktur sind, nun so modifiziert werden, dass sie die kommunikativen Strukturinformationen tragen können. So sind die Occurences, die in den meisten PDM-Systemen implizit gebildet werden, explizit zugreifbar zu gestalten. Nur so können Software-Entwicklungen effizient wiederverwendet werden. 5.12.3 Kommunikative Abhängigkeiten Kommunikative Abhängigkeiten sind den Strukturinformationen zu zuordnen. Während die bisher bekannten Strukturinformationen den Aufbau eines Produktes repräsentieren und daher streng hierarchisch aufgebaut sind, handelt es sich bei kommunikativen Abhängigkeiten um vernetzte Beziehungen derselben Strukturebene. So werden die kommunikativen Relationen mit den Ausprägungen, den Occurences, einer Softwareentwicklung verbunden. Im Gegensatz zu mechanischen Strukturen, in denen alle produktstrukturspezifischen Relationen unterhalb einer Occurence aufgrund von relativen Koordinatensystemen immer gleich bleiben, wodurch die Wiederverwendung erleichtert wird, sind die kommunikativen Relationen in jedem Softwareprodukt neu zu setzen. Insbesondere wirkt sich diese Anpassung in Bezug auf Produktvarianten aus. So kann es vorkommen, dass mehrere kommunikative Abhängigkeiten auf dieselbe Schnittstelle variant zueinander in Abhängigkeit von der Konfiguration eines Kommunikationspartners sind. Während im klassischen Metamodell eines PDM-Systems folglich lediglich hierarchische Verbindungen mittels Gültigkeiten gesteuert werden – aus Perspektive des untergeordneten Strukturobjekts handelt es sich hierbei um genau eine Relation – müssen nach der Anpassung zusätzlich beliebig viele vernetzte Strukturverbindungen mit regelbasierten Gültigkeiten je nach Kommunikationspartner berücksichtigt werden. Um eine Produktkonfiguration aus einer generischen Produktstruktur festzulegen, müssen daher nun verwendete Versionen und Varianten sowie deren kommunikative Relationen identifiziert werden.

232

5 Leithefte zu PLM-Aspekten

5.12.4 Einführung eines Software-PDM Zur Einführung eines PDM-Systems zur Unterstützung einer Softwareentwicklung lassen sich zwei wesentliche Aufgaben unterscheiden. Zum einen ist ein IT-Bebauungskonzept aufzustellen, das einerseits die Schnittstelle zwischen PDM- und SCM-Systemen regelt und andererseits die ITSysteme mit ihren Daten und Schnittstellen auf die Prozesse und Aktivitäten abgebildet. Zum anderen sind die zuvor beschriebenen Modifikationen am Meta-Modell des PDM-Systems durchzuführen. Die Herausforderung der ersten Aufgabe liegt in der Kopplung zweier integrierender Systeme mit unterschiedlichen Ansätzen. Während ein PDM-System restriktiv den Zugang zu einer Entwicklung immer nur einem Entwickler ermöglicht, hat ein SCM-System das Ziel, die parallele Bearbeitung einer Entwicklung durch mehrere Entwickler zu unterstützen. Ein bewährtes Vorgehen ist daher, dem SCM-System eine Rolle im PDMSystem zuzuordnen. Somit erhält während der Bearbeitung das SCMSystem vom PDM-System die Zugriffsrechte und dadurch die Aufgabe der Konsistenzsicherung. Erst nachdem ein gewisser Reifestand im SCM erreicht ist, wird die Entwicklung wieder in das PDM-System zurück gespielt. Der Ein- und Auscheckvorgang spielt sich folglich nicht direkt zwischen Arbeitsumgebung des Entwicklers und PDM-Systems ab sondern lediglich zwischen dem PDM-System und dem SCM-System. Hat ein Benutzer eine Entwicklung aus dem PDM in das SCM ausgecheckt, kann er nun in seiner bisher gewohnten Umgebung unter Nutzung der SCMFunktionalität arbeiten. Er kann jedoch auch über das PDM-System auf sämtliche Softwareentwicklungen des Unternehmens über MetaInformationen zurückgreifen. Die zweite Aufgabe, die Modifikation des PDM-Systems, verlangen tiefe Eingriffe in das System. Daher sind nur PDM-Systeme zu empfehlen, die Anpassungen am Meta-Modell zulassen. Neben diesen datentechnischen Modifikationen, müssen die entsprechenden Funktionen zur Identifikation der Occurences und zum Aufbau kommunikativer Relationen aufgebaut werden.

5.13 Interdisziplinäres Datenmanagement 233

5.13 Interdisziplinäres Datenmanagement Das Leitheft zuvor (siehe Abschnitt 5.12) hat den Nutzen und die Verwendung von PDM im Bereich der Software mit dem Ergebnis eines SoftwarePDM aufgezeigt. Diese Umsetzung wurde ausschließlich für Software ohne Einbezug von zu verwaltenden mechanischen bzw. elektrischen/elektronischen Komponenten vorgenommen. Moderne Produkte des Maschinenbaus sind jedoch mechatronisch. Sie besitzen Bestandteile aus allen zuvor genannten Disziplinen. Die große Herausforderung bei diesen Produkten ist neben der Beherrschung jeder Disziplin für sich die Beherrschung der technischen und organisatorischen Schnittstelle zwischen den Disziplinen. Dieser Herausforderung kann durch ein PLM für mechatronische Entwicklungen begegnet werden, in dem alle drei Disziplinen Berücksichtigung finden. Dieses Leitheft wird nun den Ansatz eines interdisziplinären Datenmanagements unter Einbezug der klassischen Aspekte eines Produktdatenmanagements und des zuvor beschriebenen Software-PDM-Ansatzes vorstellen, das der Softwareentwicklung auf eine zur Mechanikentwicklung vergleichbaren unternehmensweiten integrierten Unterstützung bietet. Die Ausprägung dieser Unterstützung ist gemäß dem PLM-Paradigma maßgeblich von den eingesetzten disziplinübergreifenden Prozessen abhängig. Diese können aufgrund der großen Spanne mechatronischer Produkte sehr unterschiedlich gestaltet sein. Um daher für das jeweilige Unternehmen die zielführende integrierte Unterstützung zu konzipieren, werden zunächst drei Klassen an mechatronischen Entwicklungsprozessen in Abhängigkeit von der Produktkomplexität und der Disziplinverteilung unterschieden. Für diese Prozessklassen werden drei unterschiedliche IT-Konzepte vorgestellt. Diese reichen von einem IT-System, das alle Facetten der Mechatronik beinhaltet bis hin zu einem Ansatz der auf disziplinspezifische ITUnterstützung setzt, die gezielt Informationen austauschen. Insbesondere auf den letztgenannten Ansatz wird in der Beschreibung der Umsetzung eingegangen. Dieser schließt mehrere parallel existierende PDM-Installationen ein, die im Sinne einer IT-Bebauung gekoppelt werden müssen. Obwohl hierdurch ein Mehraufwand in der PLM-Umsetzung besteht, liegen die Vorteile auf der Hand. Die einzelnen PDMInstallationen bleiben einerseits schlank, andererseits sind die anwendernahen ausgereiften IT-Werkzeuge kaum betroffen, sodass die Anwender weiterhin mit ihren gewohnten Werkzeugen arbeiten können.

234

5 Leithefte zu PLM-Aspekten

5.13.1 Optimale Prozessunterstützung Zunächst muss die für das jeweilige Unternehmen relevante mechatronische Prozessform identifiziert werden, bevor ein PLM-Konzept aufgebaut werden kann. In den Disziplinen Maschinenbau, Elektrotechnik und Informationstechnik etablierten sich aufgrund differenzierender Randbedingungen unterschiedliche Methoden für Produktentstehungsprozesse mit eigenem Vokabular und eigenen Sichtweisen, die so nicht ohne weiteres kompatibel sind (Dettmering 2008). Zudem fordern mechatronische Produkte eine enge interdisziplinäre Zusammenarbeit der beteiligten Disziplinen. So werden die Anforderungen an einen mechatronischen Entwicklungsprozess in der Literatur wie folgt zusammengefasst (Bender 2005): x x x x x x x x x x x x

Unterstützung einer systematischen Vorgehensweise Frühzeitige Absicherung des Integrationsrisikos Verringerung der komplexen Abhängigkeiten zwischen den Disziplinen Unterstützung frühzeitiger Hardware-, Software- und Systemtests Abstimmung zwischen Mechanik, Hardware und Software Berücksichtigung qualitätsfördernder Vorgehensweisen Hohe Produktqualität durch hohe Prozessqualität Methodische Vorgehensweise Leichte Vermittelbarkeit des Entwicklungsprozesses Solide Basis für firmeninterne und -übergreifende Kommunikation Einbindung etablierter und qualitätsfördernder Arbeitsfolgen Integration bereits vorhandener und durch die Firmenphilosophie vorgegebener Teilprozesse (gelebte Prozesse sollen nicht ausgegrenzt werden, sondern mit möglichst geringen Veränderungen in den neuen multidisziplinären Entwicklungsprozess aufgenommen werden)

Wie diesen Ansätzen prozessual Rechnung getragen werden kann, verdeutlichen die folgenden zwei Ansätze zur integrierten Produktentwicklung, das 3-Ebenen-Vorgehensmodell und das Quality-Gate-Konzept. Das 3-Ebenen-Vorgehensmodell (siehe Abb. 5-65) beschreibt einen Meta-Prozess zur Integration der drei Disziplinen Mechanik, Hardware und Software einerseits durch Eingliederung etablierter Entwicklungsprozesse, andererseits durch übergeordnete Prozessschritte zur Dekomposition und Integration der mechatronischen Produkte.

5.13 Interdisziplinäres Datenmanagement 235

Abb. 5-65: 3-Ebenen-Vorgehensmodell

Angelehnt an das V-Modell 97 wird eine schrittweise Dekomposition des Systems auf dem linken Ast beschrieben bevor eine Integration auf der rechten Seite des V stattfindet. So ergibt sich ein Aufspreizen des gemeinsamen Entwicklungsprozesses im oberen Bereich des V in disziplinspezifische Entwicklungsaktivitäten im unteren Bereich. Des Weiteren gehören zum Vorgehensmodell Richtlinien zur Arbeitsweise in den einzelnen Prozessphasen. Diese fordern auf der Systemebene eine gemeinsame Definition der Anforderungen. Hierauf folgt eine Dekomposition des Produkts mit gleichzeitiger Festlegung der bearbeitenden Disziplinen. Diese können nun separat voneinander mit festgelegten Abstimmungspunkten entwickelt werden. Anschließend werden sie schrittweise abgesichert und integriert. Ein weiteres Vorgehensmodell ist das vierstufige Quality-GateKonzept (siehe Abb. 5-66) (Geisberger u. Schmidt 2004). Dieses Vorgehensmodell sieht die Integration der Disziplinen als Aufgabe eines interdisziplinären Projektmanagements unter besonderer Berücksichtigung der frühen, oft unscharfen Phasen des Entwicklungsprozesses. Dieser Prozess untergliedert die Produktentstehung in sieben Phasen mit vier Stufen, die jeweils mit einem Quality-Gate durch messbare Werte abgeschlossen sind.

236

5 Leithefte zu PLM-Aspekten

Abb. 5-66: Quality-Gate-Konzept

Ähnlich des 3-Ebenen-Vorgehensmodells werden die Disziplinen zwischen den Synchronisationspunkten aufgespalten, sodass ebenfalls arbeitsteilig entwickelt werden kann und kreative Freiräume entstehen. Bei Bedarf können für Iterationsschleifen in der Anforderungsanalyse oder für eine erste Integration der Mechanik und Elektrik in der Realisierungsphase weitere Synchronisationspunkte nach dem Muster der Baseline definiert werden. Die organisatorische Gestaltung und Absicherung des Entwicklungsprozesses ist eng mit inhaltlichen Fragestellungen im Projekt verzahnt. Hierzu gehören die Darstellung der Systemspezifikationen, der Umgang mit Änderungen der Spezifikation während des Projektverlaufes, die Bewertung des Projektfortschritts und ein systematischer Informationsaustausch im Projekt. Beiden Ansätzen gemeinsam ist die Systempartitionierung auf die disziplinspezifischen Entwicklungsstränge. Dennoch ist diese heute weder von Seiten der Methoden als auch von Werkzeugen ausreichend unterstützt. So bleibt offen, wie eine Dekomposition während der frühen Phase der Entwicklung und wie ein Informationsaustausch mit welchen Daten während der disziplinspezifischen Ausgestaltung auszusehen hat. Um diese Fragestellung beantworten zu können, werden im Folgenden drei Typen von mechatronischen Entwicklungsprozessen unterschieden.

5.13 Interdisziplinäres Datenmanagement 237

5.13.2 Klassifikation unterschiedlicher mechatronischer Entwicklungsprozesse Kern jedes Produktentstehungsprozesses (Abk.: PEP) sind Entwicklungsprozesse. Handelt es sich um einen Entwicklungsprozess für mechatronische Produkte, ist eine Zusammenarbeit der beteiligten Disziplinen obligatorisch. In welcher Form sich diese Zusammenarbeit gestaltet, hängt maßgeblich von Produkt- und Prozessbeschaffenheiten ab. Grundsätzlich lassen sich sequentielle und integrierende Prozessformen unterscheiden. Mit dem 3-Ebenen-Vorgehensmodell und dem Quality-Gate-Konzept wurden im Abschnitt zuvor zwei integrierende Ansätze vorgestellt, die funktionsorientierte Entwicklungsansätze verfolgen. Mit diesen Konzepten wird eine Gleichstellung der Disziplinen im Prozess angestrebt, wie sie für integrative mechatronische Entwicklungsprozesse gefordert werden. Heute existieren jedoch häufig sequentielle Prozesse, die ebenfalls Unterstützung finden müssen. Diese werden wie folgt unterschiedlich eingesetzt (Dettmering 2008). Dominiert in einem Produkt eine Disziplin, führt dies dazu, dass weitere Disziplinen lediglich als Funktionserbringer betrachtet werden. Dies kann auf einem unausgewogenen Verhältnis zwischen den Disziplinen oder beispielsweise in der Vorentwicklung eines zukünftigen Produktes auf dem Ideenursprung in einer Disziplin beruhen. In solchen Fällen kann die Prozesswahl auf sequentielle Abläufe fallen. Sequentielle Prozesse zeichnen sich durch strikte Trennung der Disziplinen aus, verbunden mit einer zeitlichen Abfolge. Erst nach abgeschlossener Produktdefinition nimmt die folgende Disziplin ihre Tätigkeit auf. Eine solche Trennung in Teilprozesse mit jeweils einer unidirektionalen Schnittstelle zwischen benachbarten Disziplinen führt zu einem gerichteten Informationsfluss. Datentechnische Rückkopplungen werden aufgrund der fehlenden Prozessvorgabe nicht benötigt. Da eine Disziplin ihre Tätigkeit bereits abgeschlossen hat, bevor die nächste ihre Arbeit aufnimmt, müssen lediglich vollständige fertiggestellte Datenstände an den nachfolgenden Prozess übergeben werden. Dies erleichtert das Datenmanagement erheblich. Es bieten sich für sequentielle Prozesse zwei Ansätze an. Eine Möglichkeit stellt die sukzessive Erweiterung des Integrierten Produktmodells beginnend mit einer Disziplin dar. Nach Fertigstellung der Produktdefinition einer Disziplin wird der vollständige Datenstand freigegeben und somit für ein weiteres Bearbeiten gesperrt. Die folgende Disziplin fügt ihre Definitionen diesem Modell ausschließlich an die für sie selbst relevanten Artefakte an. Da die Integration der Disziplinen in einem System erfolgt, wird dieser Ansatz Einsystemintegrators genannt. Die Diszip-

238

5 Leithefte zu PLM-Aspekten

linen können beispielsweise mittels Sichtenmanagement unterschieden werden. Vorteil dieser Lösung ist die zentrale Haltung aller Daten in einem System. Nachteilig ist, dass keine parallele Bearbeitung möglich ist. Aufgrund der einen gemeinsamen Produktstruktur und der zu verwalteten Datenmenge ist dieser Ansatz zudem nur bei kleinen Umfängen möglich. Eine weitere Möglichkeit stellt der Einsatz eines eigenen Datenmodells für jeden Teilprozess dar. Nach Fertigstellung einer Definitionsphase wird wiederum der freigegebene Datenstand über eine gerichtete Schnittstelle übermittelt. Jedoch werden nur relevante Artefakte in das Datenmodell der Folgephase übernommen. Produktübergreifende Zusammenhänge werden somit nicht abgebildet. Dieser Ansatz wird als Peer-to-Peer-Konzept mit Anspielung auf den Netzwerkbegriff bezeichnet. Vorrausetzung für dieses Konzept ist der Einsatz von datenverwaltenden Werkzeugen mit analogem Funktionsumfang in jeder Disziplin. Vorteil dieses Ansatzes ist die losgelöste Verarbeitung der Daten in den Disziplinen. So ist die Bearbeitung von größeren Umfängen möglich. Jedoch sind die Disziplinen noch stärker voneinander getrennt. Zudem sind sowohl der System- als auch der Schnittstellenaufbau nicht zu vernachlässigen. Besitzen mechatronische Produkte ein ausgeglichenes Verhältnis zwischen den Disziplinen, sollte integriert entwickelt werden. Jedoch ist bei integrierten Prozessen für die Wahl des Werkzeugkonzepts die Komplexität der Produkte entscheidend. Dieser Abschnitt beschreibt die Anwendung eines Konzeptes für Produkte niedriger Komplexität, in dem beispielhaft als ein solches Produkt ein Zusammenbau aus zehn Teilen unterstützt von zwölf Funktionen angeführt wurde. Integrierende Prozesse fordern einen ständigen, rollenbezogenen, disziplinübergreifenden Zugriff auf alle Produktdaten zum benötigten Zeitpunkt unter Berücksichtigung einer Gleichstellung der Disziplinen. Daher sollten die Daten für den Benutzer logisch an einem Ort abgelegt sein. Diese Forderung steht im Widerspruch zu den zuvor vorgestellten Ansätzen des Einsystemintegrators und des Peer-to-Peer-Konzepts. Somit sind sie für integrierende Prozesse auszuschließen. Die durch disziplinübergreifende Verflechtungen entstehende Komplexität mechatronischer Produkte kommt bei aus wenigen Bauteilen bestehenden Erzeugnissen nicht in einem solchen Maß zum Tragen, dass sie nicht beherrschbar wäre. Der Nutzen einer Werkzeugunterstützung wird daher weniger in der Transparenz von Produktstrukturen als vielmehr im Dokumentenmanagement und der Prozesssteuerung zu finden sein. So bietet sich der Einsatz eines einzigen Integrierten Produktmodells an, der als All-in-One-Konzept (Crnkovic et al., 2003) bezeichnet wird. Durch die

5.13 Interdisziplinäres Datenmanagement 239

geringe Anzahl an Artefakten bleibt die entstehende Struktur dennoch überschaubar. Um die Gleichstellung der Disziplinen im Modell zu erreichen, müssen bei diesem Ansatz Maßnahmen gefunden werden, das Ungleichgewicht zwischen Artefakten der Disziplinen – welches häufig mit dem Faktor fünf angegeben wird – auszugleichen. Da eine solche Differenz lediglich von der Granularität der Strukturbetrachtung abhängt, wird eine Angleichung möglich sein. Die Ausprägung einer Werkzeugunterstützung mittels Allin-One hängt nun in erster Linie von der zu erbringenden Funktionalität und nicht mehr von der Produktstrukturierung ab. Eine Basis könnten beispielsweise sowohl Dokumenten- oder Workflow-Managementsysteme bieten. Auch der Einsatz eines PDM-Systems zur Nutzung der Gesamtfunktionalität ist vorstellbar. Das All-in-One-Konzept eignet sich für Produkte mit geringer Anzahl von Einzelteilen. Werden Produkte größeren Umfangs betrachtet, kann die Produktstruktur und die mit ihr verbundene Komplexität nicht vernachlässigt werden, sodass ein anderer Lösungsansatz gefunden werden muss. Zudem sind bei diesen Produkten die Anforderungen durch verteilte Entwicklung und unterschiedliche Rollen im Prozess schwerwiegender. Aufgrund derselben Argumentation können die Ansätze Einsystemintegrator und Peer-to-Peer von vornherein ausgeschlossen werden. Das Allin-One-Konzept wird weder der Produktstrukturkomplexität – gegeben durch die Anzahl der Artefakte entsprechend der Summe der Elemente jeder Disziplin und die damit verbundene Anzahl an Relationen – gerecht, noch unterstützt es ein Rollenkonzept im geforderten Maß. Es wird eine weitere Integrationsform benötigt, bei der für jede Disziplin eine eigene Umsetzung zum Einsatz kommt, die über bidirektionale Schnittstellen verbunden sind. Dieser Ansatz wird als Best-in-ClassKonzept bezeichnet. Sowohl für jede Disziplin als auch für die mechatronische Sicht auf das Produkt werden eigene integrierte Produktmodelle aufgebaut (siehe Abb. 5-67). So entsteht einerseits kreativer Freiraum in den jeweiligen disziplinspezifischen Phasen der Produktdefinition, andererseits wird den Bedürfnissen unterschiedlicher Rollen mit der datentechnischen Trennung Rechnung getragen. Durch die Rückführung auf jede einzelne Disziplin wird zugleich der Komplexität des Gesamtproduktes entgegengewirkt. Diese ist somit auf einen Umfang beschränkt, der dem Stand der Technik entspricht. Mechatronische Aspekte werden außerhalb der Produktmodelle in den Schnittstellen zwischen den Datenmanagementsystemen gehalten. Folglich liegt die Herausforderung nun in der Schnittstellengestaltung zwischen den Einzellösungen.

240

5 Leithefte zu PLM-Aspekten

Abb. 5-67: PDM für integrierende Prozesse (Best-in-Class-Konzept)

Um einen Datenaustausch zu gewähren und disziplinübergreifende Prozesse zu unterstützen, muss ein entsprechendes Schnittstellenkonzept geschaffen werden. Wie zuvor angedeutet sollen nicht nur die Disziplinen sondern auch die Mechatronik eine eigene PDM-Systeminstanz erhalten. Durch die letztgenannte werden einerseits die Anforderungen aus den Vorgehensmodellen bezüglich interdisziplinärer Aufgaben wie beispielsweise Systemdekomposition oder interdisziplinäres Anforderungsmanagement unterstützt und andererseits das Schnittstellenkonzept realisiert. So beinhaltet diese Sicht eine grobgranulare dafür interdisziplinäre Produktstruktur, die an Verknüpfungen zu den disziplinspezifischen Strukturelementen terminiert, die in den entsprechenden disziplinspezifischen Systemen fortgeführt werden. Vorteil dieses Ansatzes ist durch die Schaffung einer eigenen mechatronischen Sicht auf das Produkt die optimale Unterstützung interdisziplinärer Entwicklungsmethoden. Jede Disziplin arbeitet weiterhin in den etablierten Umgebungen. Welche Informationen in welcher – für alle Betroffenen lesbaren – Form ausgetauscht werden, kann explizit festgelegt werden. So werden nur verständliche Informationen zwischen den Disziplinen verteilt. Nachteilig ist der hohe administrative Aufwand der entstehenden PDM-Bebauung (Dettmering 2008).

5.13 Interdisziplinäres Datenmanagement 241

5.13.3 Umsetzung Dieser Abschnitt soll sich auf die Umsetzung des interdisziplinären Informationsaustausches beschränken. Die Integration der Erzeugersysteme aller Disziplinen wird nicht angesprochen. In diesem Leitheft wurden je nach vorliegendem Prozess vier mögliche Umsetzungsformen unterschieden. Der Einsystemintegrator kann über eine Kombination aus Freigabemanagement und Sichtenmanagement (siehe Abschnitt 5.2.1) realisiert werden. Nach Abschluss der Entwicklung einer Disziplin können weitere Disziplinen ihre Sichten entsprechend aufbauen. Das Peer-to-Peer-Konzept benötigt zwei Installationen in gerichteter Reihenfolge. Unter Verwendung des Workflowmanagements (siehe Abschnitt 5.7.4) wird ein Prozess installiert, der die abgeschlossene Entwicklung nach Artefakten filtert, die für die folgenden Disziplinen relevant sind. Diese werden teilautomatisiert in ein neues Integriertes Produktmodell überführt. Das All-in-One-Konzept sieht hingegen die Verwendung eines Systems für die integrierte Entwicklung vor. Einzusetzen ist dieser Ansatz, wenn der Fokus auf der Verwaltung von Produktinformationen und weniger auf deren Strukturierung liegt. Realisiert wird der Ansatz lediglich mittels Sichtenkonzept und Verfahrensanweisungen, die teilweise systemtechnisch überprüft werden können. Das Best-in-Class-Konzept ist schließlich die komplexeste mechatronische PDM-Lösung für größere mechatronische Entwicklungen. Hierfür wird neben disziplinspezifischen Installationen eine weitere mechatronische Umsetzung benötigt. Für den Abgleich der Systeme ist sowohl das Workflowmanagement (siehe Abschnitt 5.7.4) als auch die Systemkopplung notwendig. Hieraus resultiert zum einen die Aufgabe des Aufbaus eines mechatronischen PDM-Backbone als auch der Aufbau von Synchronisationsmechanismen. Das Integrierte Produktmodell der mechatronischen Installation richtet sich hierbei nach der Systemdekomposition, wie sie von den Entwicklungsmethoden gefordert wurde. Produktdefinitionen von interdisziplinärem Interesse werden entsprechend als Partialmodelle ergänzt. Hierbei ist auf das Datenformat zu achten. Da diese Informationen nicht weiterentwickelt werden, sind neutrale Ersatzformate zu bevorzugen, die mit kostengünstigen Viewern zu lesen sind. Wird ein Produktstrukturartefakt sowohl in einer disziplinspezifischen als auch in der interdisziplinären Struktur geführt, ist es bei der Synchronisation zu berücksichtigen. Sowohl die Daten als auch die entsprechenden Dokumente sind zu berücksichtigen. Da die Entwicklungsmethoden bei

242

5 Leithefte zu PLM-Aspekten

der Systemdekomposition letztendlich eine verantwortliche Disziplin identifizieren, kann für jedes Artefakt immer ein Mastersystem festgelegt werden, dass seine Informationen mit dem mechatronischen PDM-Backbone austauscht. So wird während der Phase der Systemdekomposition die mechatronische Produktstruktur aufgebaut, für jedes Artefakt eine verantwortliche Disziplin identifiziert und die auszutauschenden Informationen festgelegt. Weiterführende Literatur

Crnkovic I, Asklund U., Dahlqvist A. P (2003) Implementing and Integrating Product Data Management and Software Configuration Management. Norwood: Artech House Geisberger E, Schmidt R (2004) Abschlussbericht des Projekts ProMis, VDMA Verlag

5.14 Externe Dienstleister einbinden 243

5.14 Externe Dienstleister einbinden

Æ Prozess- und Organisationsmanagement Æ Standardsoftwaresysteme In welchem Umfang und für welche Tätigkeiten externe Dienstleister bei einer PLM-Umsetzung einbezogen werden, ist eine heikle Fragestellung, die wohlüberlegt sein muss. Einerseits muss das unternehmensspezifische PLM-Wissen im Unternehmen selbst gehalten und erarbeitet werden, andererseits kann auf das Fach-Know-how und die Erfahrungen von Dienstleistern nicht verzichtet werden. Dieses Leitheft wird Hinweise zur Projektdurchführung mit externen Dienstleistern und deren Einbindung in das eEvolutionäres Vorgehensmodell geben. So unterscheidet sich der Aufbau dieses Leitheftes grundlegend von den übrigen Leitheften. Die Gliederung richtet sich vielmehr nach den einzelnen Phasen einer Zusammenarbeit zwischen Unternehmen als Auftraggeber, das PLM einführt, und einem erfahrenen Dienstleister als Auftragnehmer, der diese Einführung unterstützt. Mit der Einbindung eines Dienstleisters in die PLM-Konzeption müssen die Geschäftsbeziehungen einerseits zwischen den konzipierenden und unterstützenden Dienstleistern und andererseits zwischen den umsetzenden Systemhäusern differenziert werden. Zur besseren Unterscheidung soll nachfolgend für den ersten Fall vom „Dienstleister“ und im zweiten Fall vom „Systemhaus“ gesprochen werden. Beschrieben wird die Zusammenarbeit mit einem externen Dienstleister von der internen Klärung zum Einsatz eines Dienstleisters bis zur Projektumsetzung. 5.14.1 Interne Klärung des Einsatzes von Dienstleistern Das Know-how der heutigen Prozesse, inklusive ihrer langjährigen spezifischen Optimierungen, liegt heute normalerweise im Unternehmen selbst. Die an die Unternehmensführung gerichtete Herausforderung bei der Umsetzung der unternehmensspezifischen PLM-Vision ist es, das Know-how zum Management der zukünftigen Kernprozesse im Unternehmen zu halten und auszubauen. Der nachhaltige Garant für eine ganzheitliche Sicht auf Prozesse, Organisation und Information, wie es das PLM fordert, kann daher auch nur das Unternehmen selbst sein. Die mittel- und langfristigen Unternehmensziele und deren dynamischen Ableitungen in den Fachabteilungen stellen das Grundgerüst für die individuelle Entwicklung des eigenen PLM-Manifests dar. Eine im Sinne der wirtschaftlichen Nutzung optimale Funktionalität für die Fachabteilungen sowie ausreichend hohe Datenintegrität und Datenaktualität aller Pro-

244

5 Leithefte zu PLM-Aspekten

duktdaten, in Kombination mit einer permanenten Verfügbarkeit für die jeweiligen Funktionen, sind die grundsätzlichen Anforderungen an die Organisation und die Informationstechnik. Projekte, wie die Einführung und Umsetzung einer PLM-Vison, sind insbesondere unter Einbezug externer Experten ohne die Regeln des Projektmanagements nicht erfolgreich umsetzbar. Entsprechende PLMProjekte benötigten klare Ziele, eindeutige Zuordnung der Verantwortungen und durchführbare Zeitpläne. Aus den Zielen und dem erwarteten Zeitraster ergeben sich der Ressourcenbedarf und damit die zu erwartenden Kosten (siehe Abschnitt 5.15). Allerdings ist fast jedes Unternehmen heute mit der Umsetzung seiner individuellen PLM-Vision personell und kapazitiv überfordert, sodass externe Dienstleister zur Unterstützung herangezogen werden müssen. Zudem fehlt es an Erfahrung spezifischer Aufgaben im Rahmen einer Umsetzung. Bei der Einbeziehung externer Leistungen sind drei wesentliche Ziele in den Fokus zu stellen: x Kapazitäts-/Zeitgewinn mit den daraus resultierenden Kostenvorteilen x Know-how-Transfer in das eigene Unternehmen x Reduzierung der Betriebsblindheit in der Konzeptionsphase 5.14.2 Einsatz externer Dienstleister Die Sinnhaftigkeit der Trennung zwischen „Dienstleister“ und „Systemhaus“ zeigt sich bereits bei der Konzeptionsphase: Während die Erstellung des Lastenhefts durch einen Dienstleister unterstützt werden kann, ist die Erstellung des Pflichtenhefts Aufgabe des Systemhauses. Das Lastenheft ist das Grundwerk des Liefervertrages, das im Wesentlichen die Beschreibung der Prozesse und Funktionen enthält, welche vom gelieferten Produkt, in diesem Fall vom Informationssystem, erfüllt werden sollen. Aufbauend auf der Hierarchie der Unternehmensziele und der Dokumentation der Ist-Prozesse, die häufig schon in der Qualitätsmanagement-Dokumentation nach ISO 9000:2000 verfügbar sind, werden die geplanten, PLM-relevanten Prozesse definiert und in einer Spezifikation bzw. dem Lastenheft als Teil des PLM-Manifests dokumentiert, das an die potentiellen Dienstleister gerichtet ist. Dieses Lastenheft dient darüber hinaus als Plattform für die Ausschreibung und die Lieferantenauswahl. Es ist das Grundwerk des Liefervertrages, das im Wesentlichen die Beschreibung der Prozesse und Funktionen enthält, welche vom gelieferten Produkt, in diesem Fall vom Informationssystem, erfüllt werden sollen.

5.14 Externe Dienstleister einbinden 245

Abb. 5-68: V-Modell Dienstleister

Die Dokumentation der „Einigung zwischen den Partnern“, dem Kunden und den Lieferanten stellt das Pflichtenheft (Dienstleister) für eine spezifische Organisations- und IT-Lösung dar. So beschreibt das Pflichtenheft zusätzlich zu dem „was“, „wie“ die Leistung erbracht wird. Auf Basis des Pflichtenheftes wird die Realisierung oder Anpassung in Richtung auf das geplante System, die Datenstrukturen, die Arbeitsweisen, die Schulung etc. vorgenommen (siehe Abb. 5-68). Es dient weiterhin als Grundlage für die Implementierung, Schulung und Abnahme, die Inbetriebnahme, den Betrieb und gegebenenfalls die Außerbetriebsetzung. Betriebsanleitungen für das neue System, Arbeitsanweisungen, Prozessdokumentationen etc. werden für den Betrieb und die Anwendernutzung normalerweise aus dem Pflichtenheft gelöst und als selbständige Dokumente weitergeführt.

246

5 Leithefte zu PLM-Aspekten

5.14.3 PLM als Managementaufgabe Die Ausrichtung bei der Umsetzung der PLM-Vision richtet sich nach den längerfristigen Zielen des Unternehmens. Entsprechend müssen von der Unternehmensführung zur Initialisierung eines PLM-Projekts einige Rahmenbedingungen und Vorgaben entsprechend dieser Ziele festgelegt werden. Hierfür können folgende Prüffragen herangezogen werden: x Welcher Integrationstiefe des Product Lifecycle Managements ist zukünftig für die spezifische Produktreihe bzw. für das spezifische Produkt erforderlich und betriebswirtschaftlich relevant? Welchen Nutzen zieht das Unternehmen daraus? x Welches Geschäftsführungsmitglied ist als Mitglied des PLM-Stabs für PLM-Projekte verantwortlich? Aus Gründen der Ausgewogenheit und besserer Kontrolle („check and balance“) sollte die PLMVerantwortung nicht beim Qualitätsmanagement liegen! x Welches Budget ist heute und in den Folgejahren für PLM-Projekte minimal und maximal möglich? x Welche Integrationsschritte bieten sich an oder sind gesetzlich bzw. vom Kunden gefordert? Die Beantwortung dieser Fragen ist Managementaufgabe und beeinflusst die Projektdefinition ausschlaggebend. 5.14.4 Projektspezifikation Gemäß dem evolutionären PLM-Vorgehensmodell (siehe Kap. 4) bietet sich die Einbindung eines externen Dienstleisters spätestens zur 2. „Phase „PLM Requirement Management” an, nachdem eine interne Zielsetzung in der ersten Phase mit oder ohne Unterstützung definiert wurde. Die Aufgrund dieser Untersuchungen kann nun die Zielsetzung für den jeweiligen Zyklus des Vorgehensmodells formuliert und mit der PLM-Vision abgeglichen werden. Besondere Sorgfalt ist bei der Festsetzung der Ziele in Hinsicht auf Querbeziehungen zu zukünftig anzugehenden Projekten zu legen. Mit der Fixierung auf ein PLM-Projekt dürfen nicht nachfolgende Projekte behindert werden. Besondere Vorsicht ist geboten, wenn eine Zielerreichung auf Basis von Systemfunktionen erfolgen soll. Das PLMManifest und insbesondere die PLM-Vision als übergeordnetes Dokument können hier als Instrumente der Koordination dienen. Ansätze hierzu enthält das Leitheft „Systeme kommunizieren lassen“ (siehe Abschnitt 5.11). Die ausformulierte Zielsetzung geht in das PLM-Manifest ein und stellt die

5.14 Externe Dienstleister einbinden 247

Basis für die zweite Phase „PLM Requirement Management“ dar, in der die Zielsetzungen zu konkreten Anforderungen weiter entwickelt werden. Phase „PLM Requirement Management” beinhaltet den Managementauftrag zur Projektbildung zur Umsetzung der definierten Ziele eines Zyklus des Vorgehensmodells. Somit schließt die 2. Phase die ausführliche Beschreibung der Leistungen ein, die erforderlich sind, um die Ziele eines Projektes zu erreichen. Es ist zu empfehlen, die nachfolgenden Titel der Unterkapitel als einzeln zu bewertende Punkte in den Projektphasen zu definieren. In diesen Punkten sind der Anteil der Eigenleistung aus dem Unternehmen, inklusive der erforderlichen Schulungen, sowie die nötigen Fremdleistungen zu fixieren. Als Grundsteine für den Erfolg eines PLM-Projektes können folgende Grundaussagen gelten: x Projektmanagement gehört zu den gelebten Elementen des Unternehmens. x Rückhalt und Unterstützung des Projektes durch alle Unternehmensebenen x Zielkonformität der Projektziele mit dem „Zielbaum“ des Unternehmens x Sichtbare Bereitstellung von Ressourcen für das Projekt mit Routineberichterstattung vor dem obersten Management x Zeitlicher Rahmen und Ressourcen entsprechen der Machbarkeit und der Erreichbarkeit der gesteckten Ziele x Motivation der Mitarbeiter ist immer ein Spiegel der Einstellung des Managements Bei allen Themen im Product Lifecycle Management, besonders aber der Integration der Unternehmensbereiche, ist in erster Linie das Management gefordert, die Ziele und Rahmenbedingungen zu fixieren. Da alle Organisationseinheiten durch das Product Lifecycle Management tangiert werden, sind alle Führungskräfte gefordert PLM-Projekte zu unterstützen, wobei mit Widerständen zu rechnen ist und frühzeitig Gegenmaßnahmen eingeleitet werden sollten (siehe Leitheft „Mitarbeiter für PLM motivieren“ Abschnitt 5.16). 5.14.5 Lastenhefterstellung für Systemlieferantenauswahl Die erste Aufgabe eines Projektteams nach der Projektdefinition und dem Projektstart ist die Erarbeitung eines Lastenheftes (Statement of Work) für die potentiellen Systemlieferanten. Dieses beinhaltet die Dokumentation

248

5 Leithefte zu PLM-Aspekten

aller Forderungen der Anwender einschließlich aller Randbedingungen, die das zukünftige System zu leisten hat. Darüber hinaus lassen sich der Inhalt und die Funktion eines Lastenheftes über die folgenden Leitsätze bestimmen: x Das Lastenheft stellt die Gesamtheit der Forderungen des Auftraggebers zu einem PLM-Projekt dar, bezogen auf ein potentielles Softwareprodukt, eine Produktgruppe oder die Produktpalette; es enthält unter anderem den Produktstrukturplan bzw. die Produktstrukturpläne. x Die Forderungen sind quantifizierbar und vor allem prüfbar darzulegen, mit den Schwerpunkten bei Forderungen hinsichtlich zu erwartender Ergebnisse. x Im Lastenheft werden die heutigen und zukünftigen Funktionen und Aufgaben definiert und wie diese in den Geschäftsprozessen umgesetzt werden. x Es repräsentiert die wirtschaftlichen, technischen und organisatorischen Erwartungen des Auftraggebers bezüglich PLM. x Arbeitsmethodiken und die der dazugehörenden Beschreibungen der Prozesselemente werden in Arbeitsanweisungen oder Anwenderhandbüchern/Projekthandbüchern fixiert. x Arbeitsanweisungen, Anwenderhandbücher/Projekthandbücher und Lastenheft ergänzen einander. x Das Lastenheft ist Dokumentation der formalen Auseinandersetzung mit der Ist-Situation und der geplanten, in Stufen zu realisierenden, zukünftigen PLM-Vision als Teil des PLM-Manifests. x Das Lastenheft präsentiert keine Lösungswege in einer neuen Technik, sondern folgt den Denkmustern und Denkmodellen der bestehenden und/oder der geplanten Organisation des Auftraggebers. x Das Lastenheft ist die Grundlage für die Ausschreibung und Vergabe eines PLM-Projektes. x Das Lastenheft ist Bestandteil des Liefervertrages und die Basis der Pflichtenhefterstellung Die Herausforderung bei der Erstellung des Lastenheftes (Systemlieferant) ist die analytische Durchdringung der heutigen Realität im derzeitigen Product Lifecycle Management, gepaart mit der Vision für zukünftige Notwendigkeiten aus sachlichen und wirtschaftlichen Aspekten. Es ist keine Lösungsdiskussion im Sinne der Organisation oder im Sinne einer ITLösung erforderlich. „Lastenträger und Inputgeber“ sind die Know-howTräger des Unternehmens. Externe Unterstützung ist hier lediglich für die Analyse und Dokumentation durch einen Know-how starken Interviewer

5.14 Externe Dienstleister einbinden 249

mit integrativer und koordinativer Kompetenz sowie ganzheitlicher und unternehmerischer Sichtweise möglich. 5.14.6 Ausschreibung Ein großes Problem bei der Lastenhefterstellung ist der kapazitive Aufwand aus den Reihen der an sich schon überlasteten Führungskräfte und Know-how-Träger des Unternehmens. Hieraus resultiert häufig die Entscheidung, sich auf das Know-how der Lieferanten zu verlassen und die eigenen Wünsche und Zielsetzungen mangelhaft zu beschreiben, nach dem Motto „Der Lieferant wird’s schon richten“. Allerdings besteht das Interesse des Systemlieferanten in der Regel nicht primär in der optimalen Problemlösung für den Kunden sondern im Verkauf seines Produktes. Soll ein Dienstleister zur Unterstützung der PLM-Konzeption bis hin zur Systemlieferantenauswahl engagiert werden, ist bei der Beauftragung unbedingt darauf zu achten, dass sich der Dienstleister neutral verhält. Er sollte keine Produkte im Sinne einer späteren IT-Lösung im eigenen Portfolio haben oder in Abhängigkeit zu gewissen Lieferanten stehen. Nur ein strikt neutral erstelltes Lastenheft ist der Garant für eine echte Vergleichbarkeit der eingeholten Angebote. Eine Ausschreibung basierend auf dem Lastenheft sollte nicht erfolgen bevor sich nicht der PLM-Stab Lösungen in der Praxis angesehen hat, die mit den eigenen Intentionen entsprechend des Lastenhefts weitestgehend übereinstimmen. Bei einem Marktscreening werden üblicherweise recht viele potenziellen Anbieter identifiziert. Es ist im Allgemeinen vor dem Hintergrund der notwendigen Vergleiche jedoch nicht zu empfehlen, mehr als drei Bieter pro Ausschreibung zu einem Angebot aufzufordern (VDI 2219). Hier können die Erfahrungen von sehr hohem Wert sein, um von der „Long List“ (Ergebnis des Marktscreenings) zur „Short List“ (Liste der Anbieter für die Ausschreibung) zu kommen. Ebenso sollten sog. K.O.-Kriterien definiert werden. Ein K.O.-Kriterium ist eine Anforderung, die auf jeden Fall durch einen Anbieter erfüllt werden muss und die sich recht einfach überprüfen lässt. Ein Nichterfüllen eines K.O.-Kriteriums führt dazu, dass ein Anbieter gestrichen wird. Ein K.O.-Kriterium könnte z.B. sein, dass der Anbieter einen Standort und Ansprechpartner in Deutschland hat. In der Phase der Informationsgewinnung und Ausschreibung ist so wie zuvor angesprochen eine externe Dienstleistung eines Dienstleistungsunternehmens mit entsprechendem Know-how häufig von Vorteil.

250

5 Leithefte zu PLM-Aspekten

5.14.7 Lieferantenauswahl Ein System-Anbieter wird zunächst sein verfügbares Produkt mit der Intention der geringsten Veränderungen oder der minimalen Anpassungen an die Wunschprozesse des potenziellen Kunden anbieten. Jeder Anbieter wird versuchen, die individuellen Wünsche des Kunden als nicht relevant mit der Begründung darzustellen, bei anderen habe sich gerade diese Lösung als unpraktikabel herausgestellt. Allerdings ist auch eine rein individuelle Lösung, die an alle historisch gewachsenen Abläufe angepasst wird, die üblicherweise teuerste Lösung. Eine nachhaltige PLM-Lösung muss die technischen Notwendigkeiten von übermorgen strukturell einbeziehen, ansonsten wird morgen ein System von vorgestern realisiert. Hier liegt das eigentliche Spannungsfeld zwischen Kundenwunsch (Erwartung) und Liefererfüllung zur Kundenzufriedenheit. Angebote der Anbieter haben zunächst den Anschein, dass sie mit dem Lastenheft der Ausschreibung kaum identisch sind, da der Anbieter seine eigenen Vorlagen benutzt. In den Angebotsgesprächen lässt sich allerdings schnell klären, ob und unter welchen Bedingungen eine Annäherung möglich ist oder nicht. Der geeignete Partner zerlegt die Vorstellungen des potentiellen Auftraggebers nicht. In den Gesprächen zur Angebotsauswahl wird das „Geld verdient“. Hier ist eine Annäherung der Partner gefragt. Hat beispielsweise der Anbieter eine Lösung, die sich leicht in die eigene Organisation einfügen lässt, so kann das Geld sparen. Gleiches gilt für das Weglassen von Features die, aufgrund der eigenen Erhebungen, nicht benötigt werden. Dagegen ist Zusatzaufwand aufzubringen, wenn Prozesse oder Prozesselemente, die dringend benötigt werden und damit unverzichtbar sind, kein Pendant in der angebotenen Lösung finden. Durch Annäherung auf das Notwendige sind 10-30% der primären Angebotssummen einzusparen. Hier liegt neben dem erworbenen Know-how der direkte Nutzen der eigenen Vorarbeit, da bereits Klarheit über notwendige und gewünschte Funktionalität besteht. Eine hundertprozentige Sicherheit für die richtige Auswahl des Anbieters ist, auch aufgrund eines begrenzten Aufwandes, an diesem Punkt noch nicht erreichbar. Das Vertrauen in einen Anbieter wird durch Angebote zur Besichtigung von Lösungen bei anderen Kunden und die Möglichkeit mit diesen unabhängig sprechen zu können, sicher gestärkt. Die Lieferantenauswahl hat auf Basis des Lastenheftes zu erfolgen mit dem Vertrauen in die Aussagen und die gesehenen, in Betrieb befindlichen Lösungen des Bieters. Ein Restrisiko ist nicht zu vermeiden, weshalb eine Rücktrittsklausel bis nach der Pflichtenhefterstellung zu empfehlen ist.

5.14 Externe Dienstleister einbinden 251

Abgesehen von der rein technischen Sicht auf die Lösung eines Anbieters dürfen auch die „weichen“ Faktoren bei der Lieferantenauswahl nicht vergessen werden. So ist es für die langfristige Zusammenarbeit von Vorteil, wenn beispielsweise Kunde und Lieferant ähnliche Unternehmensphilosophien und Arbeitsmethoden besitzen. Weiterhin spielt auch die Unternehmensgröße des Lieferanten insoweit eine Rolle, dass dieser mit dem potentiellen Auftrag nicht überfordert ist, oder auch dass das eigene Unternehmen gegenüber dem Lieferanten nur als „kleiner“ Kunde betrachtet wird. Beides kann zu Kapazitätsengpässen bei der Projektumsetzung führen, da der Lieferant diese Kapazität entweder nicht zur Verfügung stellen kann oder möchte. 5.14.8 Pflichtenhefterstellung In der Angebotsphase können aus Zeit- und Aufwandsgründen nicht alle Details endgültig geklärt werden. Grund dafür sind auch mehrere Bieter mit teilweise unterschiedlichen technischen Ansätzen und unterschiedlichen Strukturen. Das Pflichtenheft (Systemlieferant) wird dem Auftraggeber oder dem ihn vertretenden Dienstleistungsunternehmen zur Abnahme vorgelegt. Eine enge gemeinsame Abstimmung im Vorfeld der Abnahme empfiehlt sich. Es beschreibt letztlich die Umsetzung des vom Auftraggeber vorgegebenen Lastenheftes mit den Mitteln des Auftragnehmers. Hier wird fixiert was wie realisiert wird und was der Anwender in den einzelnen Funktionsbereichen zur Lösung beizutragen hat. Es ist dringend zu empfehlen, die Pflichtenhefterstellung gesondert zeitlich zu bewerten und eigene Kosten sowie Fremdkosten dafür einzuplanen. Zur Erstellung des Pflichtenheftes (Systemlieferant) können folgende Leitsätzen herangezogen werden: x Das Pflichtenheft enthält die vom Auftragnehmer verbindlichen und gegengezeichneten Vorgaben, die bei der Implementierung und in der Testphase geprüft und abgenommen werden. x Es beinhaltet die Beschreibung, wie der Auftragnehmer die geforderte Leistung erbringen will. x Es enthält die Strukturpläne zu Produkten, Hardware und Software. x Es stellt den vollständigen Projektplan mit Kosten, Terminen und Ressourcen dar. x Das Pflichtenheft und die Erfüllung der dort beschriebenen Leistungen ist Vertragsbestandteil des Auftrages. x Es ist zumindest in einen rechtlichen, einen organisatorischen und einen technisch-fachlichen Teil gegliedert.

252

5 Leithefte zu PLM-Aspekten

x Bei Großprojekten werden Lasten- und Pflichtenheft notariell hinterlegt. Der Vorgang der Pflichtenhefterstellung und die hieraus resultierenden Aufgaben seitens des Auftraggebers können nicht vollständig extern vergeben werden, obwohl entsprechende fachliche Unterstützung sehr wohl zukaufbar ist. So liegt in dem Zukauf externer Dienstleistung im Sinne eines Coach für das eigene Team oder als Moderator der Pflichtenhefterstellung unabhängig vom Lieferanten, die Chance die Bestlösung in der jeweiligen Auftraggeber bzw. Auftragnehmersituation zu finden. Die Neutralität des externen Dienstleisters ist wiederum auch für die Phase notwendig, um ein optimales Ergebnis zu erreichen. 5.14.9 Realisierung Die Systemrealisierung erfolgt auf Basis des vereinbarten Pflichtenheftes weitgehend beim Auftragnehmer unabhängig vom Auftraggeber. Letzterer wird nur in kritischen Einzelsituationen zur Klärung spezifischer Fragen hinzugezogen. Besondere Vorsicht ist bei Abweichungen vom Pflichtenheft geboten. Jede Abweichung, das heißt jede noch so schön verpackte Änderung, sollte zu einer Ablehnung der Systemabnahme führen bzw. durch Nachlässe ausgeglichen werden. Jeder Auftragnehmer wird in diesem Fall versuchen, seine Nachlässe wieder zu beschaffen. Die Kostenklärung sollte also immer vor dem Einverständnis und der Unterschrift des Auftraggebers stehen. Dabei ist zu beachten, dass jeder Zusatzwunsch der Anwender zusätzlich Geld kostet und deshalb zur Kostensicherheit vom Management gebremst werden sollte. Aus diesen Gründen leitet sich die Notwendigkeit des frühzeitigen Aufwandes für die Erstellung des Pflichtenhefts ab. Am Ende der Realisierung, je nach Projekt auch bei Zwischenschritten, werden Abnahmen beim Auftragnehmer fällig. Aus Sicht des Auftraggebers kann dies nach Zeiteinheiten z.B. monatlich oder zumindest mit fortschreitendem Projekt besser nach realisierter Funktionalität erfolgen, um den Projektfortschritt zu erkennen. Bei diesen Abnahmen sind die Leistungen zu prüfen, die im Pflichtenheft für den jeweiligen Schritt vereinbart wurden, quasi als eine Art Vorabnahme. Zu diesem Zeitpunkt werden im Allgemeinen die Schulungsunterlagen oder ein spezifisches Schulungssystem für den Anwender bereitgestellt. Sollte dies aus technischen Gründen nicht möglich sein, so ist ein entsprechender Aufgabenpunkt bei der Implementierung vorzusehen. Beim Auftraggeber werden die Vorbereitungen zur Implementierung parallel zu den Arbeiten beim Auftragnehmer

5.14 Externe Dienstleister einbinden 253

in Angriff genommen. Die Arbeiten konzentrieren sich dabei auf die Punkte: x Hardwarebeschaffung und Beschaffung von Softwarezusätzen, speziell Schnittstellensoftware für bestehende und bleibende Systeme oder Komponenten x Datenbereinigung von Nomenklatur, Kennungssysteme, lebende und „tote“ Artikel, Bestände etc. x Sicherung der Datenkonsistenz und Redundanzfreiheit x Datenvorbereitung und Datenerfassung für die Testimplementierung x Schulung der Anwender der Testimplementierung Gerade diese Arbeiten sind kapazitätsintensiv und werden gerne unterschätzt. Sie sind aber ausschlaggebend für eine schnelle und erfolgreiche Einführung. 5.14.10 Implementierung Die so genannte „grüne Wiese“ ist so selten, dass man generell von der Implementierung in drei Stufen ausgehen sollte: x Testimplementierung in einer reinen Testumgebung x Parallellauf und Check der Betriebsfunktionalität und x Echtbetrieb unter Anleitung des Auftragnehmers Am Ende des Echtbetriebes unter Anleitung erfolgt die Übergabe an den Auftraggeber und die Inbetriebnahme unter der Verantwortung des Auftraggebers. Die Schulung der Anwender ist zu diesem Zeitpunkt abgeschlossen. Der Übergabezeitpunkt ist somit auch der Abnahmezeitpunkt, womit die letzte Marge, ohne Garantievorbehalt, fällig wird. Dies ist der Beginn der Garantiezeit. 5.14.11 Inbetriebnahme Am Anfang steht die Übernahme des Systems in der Eigenverantwortung des Auftraggebers. Der Auftragnehmer sollte seine Aufgabe „zur vollen Kundenzufriedenheit“ erfüllt haben. In dieser Phase zeigt sich die Geduld und Leidensfähigkeit und Unterstützungsfähigkeit des Managements, denn ab diesem Augenblick treten alle Arten von kleinen und großen Problemen auf, und kein Mitarbeiter des Lieferanten kann die Ursachen oder Folgen schnell und/oder unauffällig beseitigen. Die eigenen Mitarbeiter sind über-

254

5 Leithefte zu PLM-Aspekten

arbeitet und erschöpft und trotz aller Schulung noch sehr unsicher und machen noch Fehler. Sollte sich die Situation anders darstellen, hat man Glück gehabt oder sehr viel Zeit und Geld im Vorfeld investiert. In dieser Lage helfen nur die Geduld und das Vertrauen des Managements weiter. Je nach Projektdauer ist ein „Stillhalteabkommen“ über eine gewisse Zeitdauer, idealerweise über ein Quartal, ein probates Mittel, Zeit für das Ausräumen von Problemen zu schaffen. Dies gilt ebenfalls für größere Teilschritte im Rahmen der Umsetzung der PLM-Vision. In dem genannten Quartal sollte auch die Aktualisierung der Dokumentationen zum Abschluss kommen, inklusive Benutzerhandbücher etc. Eine externe Vergabe von Aufgaben, außer bestimmte Dokumentationen ist, bezogen auf das neue System, nicht möglich oder zu empfehlen. Aufgrund des erhöhten Personalbedarfs in der Anlaufphase gilt es jedoch die Möglichkeit zu prüfen, Aushilfen oder ehemalige Mitarbeiter für die Restlaufzeit oder Außerbetriebsetzung des Altsystems einzusetzen. 5.14.12 Außerbetriebsetzung Ein oft wenig beachteter Punkt bei der Einführung von neuen Informationssystemen oder Systematiken ist die Außerbetriebsetzung der Altsysteme. Altsysteme im Sinne von Informationssystemen und auch manuellen Systemen, die durch die neue Systematik oder Systeme abgelöst werden, müssen gezielt zu einem bestimmten Termin außer Betrieb gesetzt werden, da sonst der Parallelbetrieb nie eingestellt wird. Das gilt besonders für KMU, deren Organisation bisher weitestgehend in den Köpfen der Mitarbeiter oder in einzelnen Word- oder Excel-Dokumenten an den Arbeitsplätzen steckt. Auch dieses Thema ist letztlich eine Führungsaufgabe und eine Frage der Mitarbeitermotivation (siehe Abschnitt 5.16). Zu diesem Zeitpunkt ist die Durchführung eines Vollzugs-Review durch einen externen Dienstleister zu leisten. Generell ist zu sagen, dass alle Review- und Coaching-Funktionen, auch im Sinne der Neutralität in der Projektkommunikation, nach extern delegierbar sind. Weiterführende Literatur

Dettmering H (2008) Disziplinübergreifendes Datenmanagement, Sierke Verlag, ISBN 978-3-868-003-4 Geisberger E, Schmidt R (2004) Abschlussbericht des Projekts ProMis, VDMA Verlag

5.14 Externe Dienstleister einbinden 255

Normen und Standards

DIN EN ISO 9000:2008: Qualitätsmanagementsysteme - Grundlagen und Begriffe VDI/VDE 2519: Vorgehensweisen bei der Erstellung von Lasten-/ Pflichtenheften

256

5 Leithefte zu PLM-Aspekten

5.15 Betriebswirtschaftlichen nachweisen

Erfolg

der

PLM-Einführung

Das Ziel einer jeden PLM-Einführung ist ein betriebswirtschaftlicher Nutzen, und diesen gilt es, im Vorfeld der Einführung nachzuweisen. Betriebswirtschaftliche Rechnungen unternehmensweiter Optimierungsmaßnahen gestalten sich in der Praxis jedoch äußerst schwierig. Viele Unternehmen verlassen sich auf bekannte Erfolgsstorys. Andere versuchen für jede einzelne Maßnahme Kosten und Nutzen gegenüber zu stellen. Während die einzelnen Positionen auf der Kostenseite einfach zu identifizieren sind, gestaltet sich die Identifikation des Nutzens äußerst schwer. Einerseits sind Beiträge zum Nutzen in sämtlichen Unternehmensbereichen verteilt zu finden. Andererseits kann der Anteil der PLM-Umsetzung an erzielten Nutzen nicht eindeutig nachgewiesen werden. Persönliche Interessen erschweren dies zunehmend. Hat beispielsweise nach der PLMEinführung eine Neuentwicklung nur 90% des Budgets der Vorgängerentwicklung benötigt, wird der verantwortliche Entwicklungsprojektleiter dies als sein Verdienst aufgrund guten Projektmanagements und wachsender Erfahrung seiner Mitarbeiter sehen. Er wird die Lorbeeren nicht an den PLM-Projektleiter abtreten. Im Gegenzug wird dieser argumentieren, welche Vorteile durch die PLM-Einführung entstanden sind. Nachweisen wird keiner von beiden die jeweilige Argumentation. Viele Unternehmen kennen eine solche Problematik und haben aus vergleichbaren Projekten wie beispielsweise einer ERP-Einführung Erfahrungen gesammelt. Folgende Überlegungen sollen, ohne eine konkrete Empfehlung abzugeben, die Findungsphase unterstützen. Neben dem prospektiven Nutzennachweis ist ebenfalls nach einer gewissen verstrichenen Zeit ein erneuter Nachweis empfehlenswert. So sind grundsätzlich zwei Zeitpunkte zur Wirtschaftlichkeitsberechnung zu unterscheiden: x Vor der Einführung als Abschätzung (prospektive oder ex-ante Betrachtung) x Im Betrieb durch Berechnung (retrospektive oder ex-post Betrachtung) Bei der prospektiven Betrachtung werden die erwarteten Kosten- und Nutzengrößen als Ergebnisse aus Selbstschätzungen oder anhand von Erfahrungswerten ermittelt. Die Wirtschaftlichkeitsbewertung von PLM vor dem Einsatz sagt aus, inwieweit die PLM-Investition vorteilhaft ist und dient somit als Grundlage zur Entscheidungsfindung für oder gegen eine PLM-Investition. Bei der retrospektiven Betrachtung werden die tatsächlich angefallenen Kosten- und Nutzenwerte berechnet. Die Wirtschaftlichkeitsbewertung von PLM nach dem Einsatz drückt aus, inwieweit die In-

5.15 Betriebswirtschaftlichen Erfolg der PLM-Einführung nachweisen 257

vestition tatsächlich lohnend ist und dient als Grundlage zur Kontrolle des Investitionserfolges. Im Folgenden werden die Ansätze aus der VDI 2219 aufgegriffen. 5.15.1 Definition der Wirtschaftlichkeit von PLM Rechnerisch wird die Wirtschaftlichkeit W von PLM als der Quotient aus den zu erbringenden bzw. erbrachten Nutzen/Leistungen und den dafür aufzuwendenden bzw. angefallenen Kosten definiert. Der Nutzen wird aus allen erbrachten Leistungen bestimmt, welche die Anwendung bewirkt. Die Kosten entsprechen dem Wert aller in einer Periode verbrauchten Güter und Dienstleistungen, die für die Einführung und den Betrieb von PLM benötigt werden (VDI 2219). Ist der Quotient W größer 1, liegt eine absolute Wirtschaftlichkeit vor. Ist der Quotient größer Null, aber kleiner 1, dann leistet die Anwendung einen Deckungsbeitrag zur wirtschaftlichen Situation des Unternehmens, auch wenn sie nicht absolut wirtschaftlich ist. Die aus Personal- und Sachkostenanteilen bestehenden Kosten des PLM-Einsatzes sind in einmalige und laufende Kosten zu unterteilen. Insbesondere die laufenden Kosten werden häufig in den Kalkulationen unterschätzt. Zunächst empfiehlt es sich, die Kosten der PLM-Einführung in einmalige Kosten, Kosten der verschiedenen Phasen der PLM-Einführung und in laufende Kosten zu differenzieren (Schreuder u. Fuest 1998). Entsprechend sind die folgenden Abschnitte gegliedert. Bei der prospektiven Betrachtung gehen die zu erwartenden Kosten für Einführung und Anwendung des Integrationssystems als Schätz- oder als Erfahrungswerte ein. Während des laufenden Betriebes (retrospektive Sicht) werden die Kosten über die Kostenrechnung erfasst. 5.15.2 Einmalige Kosten Die einmaligen Kosten fallen bei der Einführung sowie bei späteren einmaligen Ausbaumaßnahmen von PLM an und werden über die Nutzungsdauer abgeschrieben. Zur Abschreibung über eine Laufzeit von etwa drei Jahren lässt sich eine lineare oder degressive Methode verwenden, wobei das degressive Verfahren aufgrund des raschen technologischen Fortschritts zu bevorzugen ist. Laut VDI-Richtlinie 2219 sollte heute die Abschreibungsdauer für IT-Systeme nicht länger als drei Jahre betragen. Jedoch kann diese in der VDI-Norm nicht näher begründete Angabe aufgrund der deutlich längeren Einsatzdauer von PLM kritisch hinterfragt werden.

258

5 Leithefte zu PLM-Aspekten

Zu den einmaligen Kosten zählen Kosten für Planungen der PLMInvestition, Systembeschaffungskosten sowie Systemeinführungskosten, zu denen im Folgenden einige Kostenpunkte aufgezählt werden: x Planungskosten: Zu den Planungskosten zählen zunächst Reorganisationsmaßnahmen wie Ist-Analyse, Konzepterarbeitung, Machbarkeitsstudien, Entscheidungsfindung, Systemauswahl. Des Weiteren sind Informationsveranstaltungen (Messen, Kongresse, Workshop etc.) einzubeziehen. Werden externe Dienstleistungen zur Konzeptfindung beauftragt, sind diese ebenfalls als einmalige Planungskosten zu sehen. x Systembeschaffungskosten: Den Systemanschaffungskosten wird häufig ein zu hoher Stellenwert zugemessen, da die Folgekosten einer Systemanschaffung in der Regel einen viel höheren Part einnehmen. Ebenfalls ist darauf zu achten, dass neben den Kosten für Software für Server- und Client-Lizenzen der PLM-Software, Client-Lizenzen der Netzwerksoftware oder Lizenzen der ergänzenden Software (Datenbanken, Konvertierung usw.) auch die Hardware im ausreichenden Maß berücksichtigt wird. In der Regel werden neue Server (Datenbank und Anwendung), PCs, BackupSysteme und ein Netzwerkausbau benötigt. x Systemeinführungskosten: Zur Systemeinführung gehören neben den direkten Installationsaufwänden Software-Implementierungen (Systemanpassung), Implementierung der Schnittstellen, die Integration von Applikationen aber auch der Systemtest, die Altdatenübernahme, Support und Beratung und Schulungen. 5.15.3 Laufende Kosten Neben den einmaligen Kosten müssen unbedingt laufende Kosten berücksichtigt werden. Häufig werden diese bei einer Entscheidung vernachlässigt. Im Folgenden sollen direkte und indirekte Betriebskosten sowie Gemeinkosten unterteilt werden: x Direkte Betriebskosten: Zu den direkten Betriebskosten zählen Personalkosten für Systemanwendung und Materialkosten (Nutzung von Datenträgern, Papier, Formularen, sonstige Verbrauchsmaterialien). x Indirekte Betriebskosten: Zu den indirekten Betriebskosten werden Aufwände gezählt, die für die

5.15 Betriebswirtschaftlichen Erfolg der PLM-Einführung nachweisen 259

Aufrechterhaltung des Systems benötigt werden. Hierzu gehören beispielsweise die Wartung der Hardware und Software, die Administration von PLM und ergänzender Software, laufende Anpassung von Geschäftsprozessen, laufende Anpassung des Integrationssystems, laufende Integration mit internen und externen Anwendungen (Entwicklung geeigneter Schnittstellen), laufende Weiterbildung der Anwender sowie sonstige Kosten. Hierzu könnten beispielsweise Teilnahme an PLMKonferenzen und Anwendergruppen oder Opportunitätskosten (Systemausfall oder Systemfehler) gezählt werden. x Gemeinkosten: Weitere Gemeinkosten sind Zinsen, Mieten, Versicherungen, Energiekosten, Raumkosten oder Verbrauchsmaterial. Einsparungen

Den oben genannten Kostenarten sind bestehende Kosten gegenüberzustellen, die durch den Einsatz eines Integrationssystems eingespart werden bzw. sogar entfallen können. Diese eingesparten Kosten gehen als Nutzen in die Wirtschaftlichkeitsrechnung ein, wie beispielsweise in der VDIRichtlinie (VDI 2219) angeführt: x x x x x

Bearbeitungskosten Qualitätskosten (besonders für Nacharbeiten) Kosten für die Einführung eines neuen Produktes Kosten für die Anpassung existierender Produkte Kundendienstkosten

5.15.4 Nutzenanalyse Der Nutzen einer PLM-Einführung sollte die im Abschnitt zuvor aufgeführten Einsparungen jedoch bei weiten übertreffen. Der Einsatz eines Integrationssystems im Unternehmen bringt darüber hinaus viele Vorteile, die in der Regel jedoch erst nach der Einführung im produktiven Betrieb des Systems vollständig nachgewiesen werden können. Der Nutzen eines Integrationssystems wird allerdings nicht sprunghaft eintreten, sondern ist von der Planung und Konzeption des Systemeinsatzes sowie von der Akzeptanz- und Lernkurve der Anwender abhängig. Oft steigert sich der Nutzen erst mit zunehmender Betriebsdauer oder wirkt sich erst mittel- bis langfristig für das Unternehmen im vollen Maße aus. Daher sollen folgende Gesichtspunkte des Nutzens unterschieden werden:

260

5 Leithefte zu PLM-Aspekten

x Nicht-strategischer Nutzen: Ist der Nutzen, der durch Verbesserung der innerbetrieblichen Abläufe entsteht, wie z.B. Produktivitätssteigerungen, direkte Kosteneinsparung, Qualitätsverbesserungen und Zeiteinsparungen. x Strategischer Nutzen: Ist der Nutzen, der durch Verbesserung der Beziehung bzw. Wechselwirkung zum Markt entsteht, z.B. Verbesserung der Wettbewerbsposition, Erhöhung der Kundenzufriedenheit usw. Der strategische Nutzen gewinnt heutzutage als Zielsetzung bei Investitionen in ITSysteme immer mehr an Bedeutung. Die Problematik bei der Erfassung des Nutzens ist das Ausweisen konkreter Zahlen. Während bei der Kostenaufstellung detaillierte Kostenarten angegeben werden können, ist dies auf der Nutzenseite nur bedingt möglich. Die Arbeit mit Kennzahlen, wie sie beispielsweise die VDI 2219 bereitstellt, hat sich hier bewährt. Nutzenbewertung mit Kennzahlen

Kennzahlen definieren Zahlen mit informativem Charakter, die quantitativ erfassbare Sachverhalte in konzentrierter Form erfassen. Als Instrumente der Unternehmensführung geben Kennzahlen dem Management unternehmensinterne und -externe Informationen zusammengefasst wieder und können somit betriebliche Entscheidungen erleichtern. Kennzahlen dienen weiterhin als Mittel zur Planung und Kontrolle von Sachverhalten. Beispielsweise wird bei einem Soll-Ist-Vergleich überprüft, ob Abweichungen von den Vorgabenwerten bestehen, deren Ursachen mit Hilfe der Kennzahlen analysiert werden können. Beim Einsatz in der Ermittlung des Nutzens sind folgende Anforderungen an Kennzahlen zu berücksichtigen (Nagel 1990): x Die Werte müssen auf einer eindeutigen Definition basieren. x Es ist nicht ausreichend nur z.B. von Verfügbarkeit zu sprechen. Es bedarf hier einer Präzisierung nach System, Anwendung, Benutzer, Betriebssystem usw. x Kennzahlen müssen messbar sein. x Die Quellen der Ermittlung dürfen sich nicht unterscheiden. x Eine Vergleichbarkeit setzt eine klare Analyse des spezifischen Umfeldes voraus. Eine Systematisierung von Kennzahlen kann nach verschiedenen Kriterien erfolgen, z.B. nach Funktionsbereichen, in denen sie eingesetzt werden, nach zeitlichen (Zeitpunktgröße, Zeitraumgröße) und inhaltlichen (Wert-

5.15 Betriebswirtschaftlichen Erfolg der PLM-Einführung nachweisen 261

größe, Mengengröße) Strukturen, nach Planungsgesichtspunkten (SollKennzahlen, Ist-Kennzahlen) und nach statisch-methodischen Gesichtspunkten. Nach dem letzten Merkmal lassen sich die Kennzahlen in absolute Zahlen und Verhältniszahlen einteilen. Anhaltspunkte zum Aufbau von Kennzahlen gibt die VDI 2219, auf die an dieser Stelle verwiesen sei. Jedoch sind die dort aufgeführten Werte ebenfalls kritisch zu hinterfragen und individuell zu erweitern. Schwierigkeiten bei der Nutzenerfassung

Zur Beurteilung der Wirtschaftlichkeit von Product Lifecycle Management muss der gesamte Nutzen den Kosten gegenübergestellt werden. Somit ist eine Wirtschaftlichkeitsrechnung nur dann durchzuführen, wenn es gelingt, die Vielzahl der Nutzenaspekte der Anwendung eines Integrationssystems zu quantifizieren und in der Dimension „Geldeinheit“ zu bewerten. Zur Erfassung des Nutzens stehen im Controlling verschiedene Quantifizierungsmethoden zur Verfügung, wie beispielsweise die Bewertung der Zeitvorteile. Aufgrund der Vielfalt und Vielzahl möglicher Nutzenaspekte kann es hier keine allgemeingültigen Verfahren geben. Vielmehr müssen bei jedem Quantifizierungsprozess die unternehmensspezifische Situation und die definierten Zielgrößen berücksichtigt werden (Bauer 1995). Allerdings sind nicht alle Nutzenaspekte einfach quantifizierbar. Zum Erfassen der nur schwer quantifizierbaren und der qualitativen Nutzen ist es zu empfehlen, während der Erstellung des Soll-Konzeptes realistische Vorgaben beispielsweise in der Form „Senken der Nacharbeit von Fertigungsunterlagen um mindestens 15%“ zu entwickeln, deren Einhaltung während des laufenden Betriebes geprüft werden kann. Während sich die Kosten der Einführung und des Betriebs eines Integrationssystems verhältnismäßig einfach bestimmen und monetär bewerten lassen, ist die Erfassung des Nutzens und dessen Bewertung in Geldeinheiten schwieriger. Dies liegt daran, dass die Auswirkungen von veränderten Geschäftsprozessen, durchgängigen Informationsflüssen oder „weichen“ Faktoren, wie Kundenzufriedenheit oder Produktqualität, sich nur sehr schwer ermitteln lassen. Durch die Anwendung von PLM entstehen neue Tätigkeiten und Arbeitstechniken, die im herkömmlichen Arbeitsablauf nicht gegeben sind. Daher sind sie nicht miteinander vergleichbar und eine direkte Nutzenermittlung ist nur schwer möglich (VDI 2219). Darüber hinaus ergibt sich der Nutzen auch nicht unbedingt in dem Unternehmensbereich, in dem auch die Kosten entstehen. Da jede Abteilung in der Regel eine eigene Kostenstelle hat, führt dies zu der Problematik, dass die Kosten einer Kostenstelle nicht immer mit dem Nutzen kompen-

262

5 Leithefte zu PLM-Aspekten

siert werden können, der an einer anderen Kostenstelle entstanden ist. Beispielsweise wirken sich höhere Kosten bei der ausführlicheren Dokumentation von Produktinformationen in der Konstruktion möglicherweise erst im Bereich der Reparatur und Wartung aus. Aus diesem Grund kann es erforderlich sein, die Kosten für den PLM-Einsatz als Gemeinkosten auf mehrere Unternehmensbereiche zu verteilen. 5.15.5 Wirtschaftlichkeitsanalyse eines Integrationssystems Für den Nachweis der Wirtschaftlichkeit von Investitionsobjekten hinsichtlich quantifizierbarer Unternehmensziele (Gewinn, Rentabilität usw.) stehen in der Betriebswirtschaftslehre verschiedene mathematische Methoden zur Verfügung. Mit deren Hilfe kann die Vorteilhaftigkeit einer PLMInvestition vor dem Entscheidungsprozess (prospektive oder ex-ante Betrachtung) abgeschätzt beziehungsweise während des PLM-Betriebes (retrospektive oder ex-post Betrachtung) kontrolliert werden. Die Wirtschaftlichkeitsberechnungsverfahren oder Investitionsrechnungsverfahren lassen sich in die zwei Hauptgruppen der statischen und der dynamischen Verfahren einteilen. In den folgenden beiden Tabellen (Tabelle 1 und Tabelle 2) werden einige der Methoden sowie deren Vor- und Nachteile bezüglich der PLM-Thematik in Stichpunkten genannt.

5.15 Betriebswirtschaftlichen Erfolg der PLM-Einführung nachweisen 263

Tabelle 1. Spezifische Vor- und Nachteile der statischen Methoden Statische Methoden

Vorteile

Nachteile

Kostenvergleichsrechnung

Teilkostenvergleich genügt

Gewinnvergleichsrechnung

auch geeignet, wenn der PLM-Einsatz eine Kapazitätsänderung zur Folge hat direkter Vergleich mit der geforderten Mindestrendite des Kapitaleinsatzes möglich Der unsichere Kalkulationszinssatz bleibt unberücksichtigt. Risikoanalyse, da Einengung des Planungshorizontes möglich.

Kostenvergleich kurzfristig, daraus keine Rückschlüsse über zukünftige Kosten und Erlösentwicklung, keine Aussage über die Verzinsung des eingesetzten Kapitals , Änderungen der Kosteneinflussgrößen und der Unternehmenserträge bleiben unberücksichtigt Vergleich von realisierten mit nicht realisierten Gewinnen.

Rentabilitätsrechnung

Amortisationsrechnung (ohne Berücksichtigung von Zinsen)

Vergleich von realisierten mit nicht realisierten Gewinnen Nur Aussage über die Ertragskraft einer PLMInvestition bis zum Wiedergewinnungszeitpunkt des Kapitals.

264

5 Leithefte zu PLM-Aspekten

Tabelle 2. Spezifische Vor- und Nachteile der dynamischen Methode Dynamische Methoden

Vorteile

Nachteile

Kapitalwertmethode

Betrachtung sämtlicher mit der Investition verbundenen Ein- und Ausgaben und ihre Auf- bzw. Abzinsung mit Kalkulationszinssatz Der Kalkulationszinssatz (Unsicherheitsfaktor) geht nicht in die Berechnung mit ein.

Es ist unrealistisch zu unterstellen, dass sich das freigesetzte Kapital zum Kalkulationszinsfuss verzinst.

Methode des internen Zinsfusses

Annuitätenmethode

Modifizierung der Kapitalwertmethode mit durch Rechnung mit durchschnittlichen Einnahmen und Ausgaben

Amortisationsrechnung (mit Berücksichtigung von Zinsen)

Eingrenzung des Planungshorizonts auf die Amortisationszeit. Es hat eine größere Sicherheit für den Planungszeitraum zur Folge.

Die Annahme, dass sich das freigesetzte Kapital zum internen Zinssatz verzinst, ist unrealistisch. Es werden Rentabilitäten, keine absoluten Gewinne ermittelt. Es werden nur die Überschüsse pro Jahr ermittelt. Es ist unrealistisch anzunehmen, dass sich das freigesetzte Kapital zum Kalkulationszinssatz verzinst. Nur Aussage über die Ertragskraft einer PLMInvestition bis zum Wiedergewinnungszeitpunkt des Kapitals

5.16 Mitarbeiter für PLM motivieren 265

5.16 Mitarbeiter für PLM motivieren

Æ Projektmanagement Die Einführung des PLMs bedeutet eine Änderung im Führungssystem der betroffenen Bereiche bezüglich der strategischen Ausrichtung – vergleichbar der Umsetzung einer ISO 9000 Zertifizierung. Je nach Umfang der Änderung kommen Mitarbeiter nicht umhin, sich eine eigene Meinung über die Veränderungen zu bilden: wer potentiell stark betroffen ist, kann dem PLM nicht gleichgültig gegenüber stehen. Entweder wird er das PLM und die Einführung seiner Systeme unterstützen oder es aus Furcht vor möglichen negativen Konsequenzen behindern. Die tendenziell geringe Anzahl aktiver Unterstützer der PLM-Einführung werden sich unterschiedlichen Widerständen gegenübersehen, während die große Anzahl der Betroffenen im Unternehmen durch ihre Ambivalenz sich eher passiv verhalten wird. Insgesamt haben PLM, die Erstellung von Integrationssystemen und deren Einführung in einem Unternehmen einen starken Einfluss auf die Motivation der Mitarbeiter, sowohl positiv als auch negativ. Letztendlich sind diese Systeme die Werkzeuge mit denen die Mitarbeiter ihre Arbeit verrichten müssen, und entsprechend positiv oder negativ ist die Akzeptanz für gute respektive schlechte Werkzeuge. Grundsätzlich enthalten die vorgeschlagenen Organisationselemente und Hilfsmittel ein motivierendes Potential. Die explizite Forderung nach einer PLM-Vision ist ein guter, motivierend wirkender Aspekt, die Öffnung der Einführungsprojekte für möglichst viele Mitarbeiter des Unternehmens ist ein anderer. Auch das PLM im Allgemeinen kann Mitarbeiter aktivieren und einen zusätzlichen Motivationsschub darstellen. Allerdings ist so etwas durch persönliche Anlagen bestimmt und kann nicht erzwungen werden. Die vorgestellten Motivationsmodelle zeigen einige Wege auf, wie Frustration verhindert und Unterstützung gewonnen werden können. Welches Modell das passende für eine Situation ist, kann nicht gesagt werden. Eine Pauschalaussage über die Motivation ist, dass gerade das Begeistern von Menschen im betrieblichen Umfeld hoch individuell ist und viel Aufmerksamkeit benötigt. Eines sollte angemerkt werden: Das PLM als Führungsinstrument ist nicht von sich aus „gut“ oder „schlecht“. PLM ist eine Methode unterstützt von Werkzeugen und jeder Angehörige eines Unternehmens kann eine eigene Meinung darüber haben, ob es als Unterstützung vorteilhaft ist oder nicht: Erst die Implementation im konkreten Fall lässt die Eignung des PLMs für ein Unternehmen zeigen. Die Motivierung der Mitarbeiter ist ein Querschnittthema bei PLM. Es betrifft jeden einzel-

266

5 Leithefte zu PLM-Aspekten

nen PLM-Aspekt. Je stärker die Arbeitsweise eines Mitarbeiters betroffen ist, umso größer ist der Bedarf an Motivierung. 5.16.1 Akzeptanzmanagement Das vorliegende Leitheft behandelt das querschnittliche Thema Akzeptanzmanagement und Motivieren. Es gibt Hilfestellung für die Einführung jeder Teilfunktion. Die Notwendigkeit der Behandlung des Themas „Motivation“ ist u.a. abhängig von der Intensität der Veränderungen, die mit der PLM-Einführung einhergehen. Die größten Veränderungen der Arbeitsweise werden bei der Einführung prozessorientierter Anwendungsfunktionen, beispielsweise Freigabeprozesse, bewirkt, sodass für diesen Fall das Thema „Motivation“ einen hohen Stellenwert hat. 5.16.2 Wissenschaftliche Ansätze zur Mitarbeitermotivation Das Motiv ist ein möglicher Beweggrund. Es ist ein innerer Zustand, der antreibt, aktiviert, bewegt, das Verhalten auf Ziele richtet und kanalisiert. Ein Motiv hat im Wesentlichen zwei Aspekte: x Den Energieaspekt: Das Motiv aktiviert Handeln im Menschen, je nachdem wie stark es wirkt, setzt es verschiedene intensive Handlungen in Gang. x Den Zielaspekt: Der Zielaspekt des Motivs richtet das Verhalten des Motivierten in eine bestimmte Richtung, das Verhalten strebt danach, das Bedürfnis, das dem Motiv zugrunde liegt, zu befriedigen. Das Motiv ist ein möglicher Beweggrund. Motivation ist hingegen das tatsächlich aktuell wirkende Zusammenspiel der Motive, die ein konkretes Verhalten hervorrufen. Motivation ist also in diesem Sinne etwas, was sich nur innerhalb einer Person abspielt. Im Umkehrschluss bedeutet dies, dass es nicht von außen hinein gegeben werden kann. Die Tätigkeit, bei der mögliche Motive angeboten werden, um eine bestimmte Motivation bei einer Person zu erzielen, werden in Abgrenzung zu den o.g. Begriffen motivieren genannt. Bedürfnispyramide von Maslow

Maslow sagt, dass Bedürfnisse bzw. wirkende Motive streng hierarchisch aufeinander aufgebaut sind. So ordnet er die Bedürfnisse in eine Pyramide

5.16 Mitarbeiter für PLM motivieren 267

ein: erst, wenn die Bedürfnisse der untersten Stufe befriedigt sind, werden die Bedürfnisse einer höheren Stufe als neue Motive wirksam (siehe Abb. 5-69). Auf die unterste Stufe seiner Pyramide stellt er die physiologischen Grundbedürfnisse, also Hunger, Schlaf, Durst etc. Die Bedürfnisse steigen stetig in ihrem Anspruch über Sicherheitsmotive (Schutz, Vorsorge oder Angstfreiheit), Soziale Motive (Kontakt Liebe oder Zugehörigkeit) und Ich-Motive (Anerkennung, Status, Prestige oder Achtung) bis sie schließlich im Bedürfnis der Selbstverwirklichung gipfeln. Das Bedürfnis „Selbstverwirklichung“ ist das einzige Bedürfnis, das nicht gestillt werden kann. Die anderen Bedürfnisse sind so genannte Defizitbedürfnisse, d.h. sie können mit unterschiedlichem Aufwand gestillt werden. Daher bleibt die Selbstverwirklichung das Wachstumsmotiv. Diese Theorie wurde nicht ausdrücklich für das Arbeitsumfeld entwickelt, sondern sollte ein allgemeiner Erklärungsansatz für psychologische Probleme sein.

Abb. 5-69: Bedürfnispyramide von Maslow

268

5 Leithefte zu PLM-Aspekten

Tabelle 3. Motivatoren und Hygienefaktoren nach Herzberg Motivatoren

Hygienefaktoren

Leistungserfolg Anerkennung Arbeitsinhalt Verantwortung Aufstieg Entfaltungsmöglichkeiten usw.

Bezahlung Interpersonelle Beziehungen Status und Ansehen Führungsstil Physische Arbeitsbedingungen Arbeitsplatzbedingungen usw.

Arbeitszufriedenheit (Herzberg)

Herzbergs Untersuchungen behandelten die Arbeitszufriedenheit, durch die letztlich Motivation entstehen soll. Seine Behauptung ist, dass es Umstände im Arbeitsumfeld gibt, die Arbeitszufriedenheit fördern, und dass es Umstände gibt, die Arbeitsunzufriedenheit fördern. Das Gegenteil von Arbeitsunzufriedenheit ist nicht Zufriedenheit mit dem Arbeitsplatz, sondern die Abwesenheit von Arbeitsunzufriedenheit. Wenn also vieles getan wird, das die Unzufriedenheit von Mitarbeitern senken soll, wird damit die Zufriedenheit nicht gehoben. Um diesen Umstand griffig auszudrücken, unterscheidet Herzberg zwischen Motivatoren und Hygienefaktoren. Die Motivatoren erhöhen die Arbeitszufriedenheit und somit die Motivation. Die Hygienefaktoren bekämpfen die Unzufriedenheit mit der Arbeitssituation und somit die Frustration. Herzberg schlägt folgende Aspekte vor, die motivieren oder frustrieren (siehe Tabelle 3). Ein weiterer grundlegender Aspekt der Theorie Herzbergs ist, dass die Hygienefaktoren einen Mangel beseitigen wollen und somit nur begrenzt wirksam sind. Die Motivatoren sind ähnlich wie bei Maslow auf Wachstumsbedürfnisse bezogen. Sie wirken also prinzipiell unbegrenzt. Nach den beiden gängigen Inhaltstheorien sollte noch auf die Unterscheidung von intrinsischer und extrinsischer Motivation hingewiesen werden. Unter extrinsischer Motivation werden die wirksamen Motive verstanden, die von außerhalb an eine Person herangetragen. Damit sind im wesentlichen Lob, Strafe und Belohnung gemeint, im Sinne eines Handels – wenn Du Dich so verhältst, bekommst Du dies und jenes. Intrinsische Motivation bedeutet alles das, was rein aus der Person kommt: Spaß an der Arbeit, Pflichtbewusstsein, Interesse an einem Arbeitsinhalt. Extrinsische Motivation wirkt in der Regel über die Befriedigung eines Defizitmotivs, während intrinsische Motivation in der Regel die Befriedigung eines Wachstumsbe-

5.16 Mitarbeiter für PLM motivieren 269

dürfnisses darstellt. Anerkennung als Motiv, das auch prinzipiell nicht stillbar ist, muss deshalb von Mal zu Mal gesteigert werden. Deshalb ist es erstrebenswert, die intrinsische Motivation der Mitarbeiter anzusprechen. 5.16.3 PLM-Erfolg durch Mitarbeiterakzeptanz Die Einführung von PLM und Integrationssystemen kann je nach Intensität mit einer Reorganisation des Unternehmens oder Teilbereichen verglichen werden. Reorganisationen sind im unternehmerischen Umfeld immer mit Risiken verbunden und können Unmut hervorrufen, wodurch der Erfolg dieser Reorganisation wiederum bedroht wird. Das Vorgehen in der Anfangsphase einer solchen Veränderung ist für den späteren Erfolg der Reorganisation sehr wichtig. In Abb. 5-70 ist eine idealisierte Übersicht über die möglichen Reaktionen auf eine grundlegende Reorganisation skizziert. Ein PLM-Projekt, das tatsächlich eine grundlegende Reorganisation darstellt, wird ähnlich aufgenommen werden. Die Ausgangssituation ist dadurch gekennzeichnet, dass man mit ihr vertraut ist und sich in der gegenwärtigen Organisationsform auskennt. Auch wenn Reibungspunkte auftreten, gibt es individuelle informelle Strategien, damit umzugehen. Die Notwendigkeit, die gegenwärtige Situation zu ändern, wird so nicht gesehen, oder sie wird gesehen, aber für den persönlichen Arbeitsplatz als nicht dringlich angesehen. Die Bekanntgabe, dass PLM eingeführt werden soll und somit ein tiefer Eingriff in die tägliche Arbeitsweise vorgenommen werden soll, wird unterschiedlich aufgenommen. Mit diesem Schritt wird eine vorhandene, wenn auch nur wenig detaillierte PLM-Vision wichtig. Sie dient vor allem dazu die Ziele der PLM-Einführung zu kommunizieren und Chancen aufzuzeigen und Ideen der Mitarbeiter und des Managements zu sammeln. Die gewünschte Reaktion ist die Unterstützung der Einführung, da x Product Lifecycle Management als Chance erkannt wird, gegenwärtige Missstände zu beheben, x im Rahmen eines Einführungsprojekts außergewöhnliche Aufgaben anfallen und somit außergewöhnliche Leistungen erbracht werden können. Unterstützung wird ein Einführungsprojekt vor allem von Mitarbeitern erfahren, die durch Leistungen motiviert werden, und deren Sicherheitsbedürfnis entweder nicht so stark ausgeprägt oder befriedigt ist. Werden die Mitarbeiter, die Missstände beheben möchten, frühzeitig mit eingebunden,

270

5 Leithefte zu PLM-Aspekten

werden diese die Einführung nicht nur unterstützen sondern aktiv voranbringen. Die potentiell größte Gruppe wird die der Unentschlossenen sein. Sie können PLM aufgrund fehlenden Wissens nicht einordnen, oder sie erkennen nicht die Notwendigkeit, etwas ändern zu müssen. Sie können aber das PLM auch als ein Mittel ansehen, mit dem etwas bezweckt werden soll, und unschlüssig sein, welche zukünftige Situation herbeigeführt werden soll. Mit einer offenen Kommunikation und ausreichender Information kann die Unterstützung dieser Mitarbeiter gewonnen werden. Hilfreich können hier die Durchführung von Informationsveranstaltungen oder Workshops sein. Die dritte Gruppe empfindet Ablehnung gegenüber dem Vorhaben PLM umzusetzen. Sie sehen ihre bekannte Umgebung bedroht oder fürchten Überforderung. Ihr Sicherheitsbedürfnis ist stark ausgeprägt. PLM ist eine Form der Rationalisierung: wird dieser Aspekt in den Vordergrund gestellt, so kann zusätzlich die Furcht um den eigenen Arbeitsplatz zur Ablehnung gegenüber PLM führen. Aber auch weniger grundlegende Bedrohungen können von PLM-Systemlösungen ausgehen: so zwingen Zugriffsrechte, Nummernvergabesysteme und Funktionen wie Vaulting dem Benutzer Arbeitsweisen auf, die er lieber selbst wählen und beeinflussen würde. Diese Fremdbestimmung und die Aussicht, keinen Einfluss auf das Ergebnis der PLM-Einführung zu haben, läuft dem Bedürfnis entgegen, als eigenständige Person mit freiem Willen zu wirken. Weiterhin werden gewohnte Arbeitsweisen und Abläufe nur ungern aufgegeben. Eine Kernaussage der Grafik (Abb. 5-70) ist, dass die Unentschlossenen über kurz oder lang entweder zu Gegnern oder zu Befürwortern der PLM-Lösung werden. Dabei muss die PLM-Einführung aber als grundlegende Veränderung der betrieblichen Abläufe wahrgenommen werden. Einer veränderten Form der Nummernvergabe kann man noch gleichgültig gegenüberstehen, je mehr aber die Änderungen die tägliche Arbeit beeinflussen, umso mehr polarisiert dies und zwingt zur Stellungnahme. Die Unentschlossenen werden dabei von zwei Seiten beeinflusst: sowohl durch die Befürworter der Änderung wie von deren Gegnern. Hierbei hilft den Gegnern sehr, wenn die Maßnahmen der PLM-Einführung im nicht klar hervortreten. Ein typisches Beispiel ist, dass durch die PLM-Einführung für die Konstrukteure Freiheiten wie die Ablage von Dateien und deren Revisionierung eingeschränkt werden. Außerdem können für sie Mehraufwand bei der Datenpflege entstehen. Diese negativen Aspekte können durch Vorteile wie höhere Datenqualität oder weniger Aufwand in anderen Unternehmensbereichen entkräftet werden, die entsprechend Vermittelt werden müssen.

5.16 Mitarbeiter für PLM motivieren 271

Abb. 5-70: Einführungsprozess

272

5 Leithefte zu PLM-Aspekten

Barrieren und Widerstand

Bei der Ablehnung von Neuerungen werden zwei unterschiedliche Barrieren unterschieden, die Wissensbarrieren und die Willensbarrieren: x Wissensbarrieren beruhen auf Unverständnis der PLM-Einführung: Was verbirgt sich hinter PLM, welche Vorteile bzw. Nachteile habe ich dadurch, Wie hilft mir PLM bei meiner Arbeit ... x Willensbarrieren in der Regel auf der Furcht vor Verlust von Einfluss oder Sicherheit: PLM schränkt meine Freiheit ein, das Arbeiten wird viel zu umständlich, ich brauche viel länger um meine Aufgaben zu erledigen Beide Barrieren führen zu Widerstand, d.h. in diesem Falle aktiver Ablehnung der PLM-Einführung. Zur Verringerung des Widerstands werden so genannte „Promotoren“ eingesetzt, und zwar Fachpromotoren, um die Wissensbarrieren abzubauen, und Machtpromotoren, um die Willensbarrieren abzubauen. Der Fachpromotor klärt über die fachlichen Aspekte der PLM-Lösung auf. In der initialen Phase bietet es sich an externe Berater als Fachpromotoren einzusetzen. Der Fachpromotor kann Ängste dadurch abbauen, indem er Irrtümer aufdeckt und die Vorteile des PLM für den einzelnen darstellt. Er muss das eventuell in Gerüchten übertrieben dargestellte Verhältnis Aufwand zu Nutzen geraderücken und somit die Akzeptanz durch Vernunft fördern. Die Fachpromotoren sind Mitglieder des PLM-Stabs oder diesem zumindest nahe gestellt. Der Machtpromotor muss mit formaler Macht ausgestattet sein, um Widerstand überwinden zu können. Machtpromotoren sind weisungsbefugt und können mittels Ressourcenverteilung Einfluss nehmen, also in der Regel Führungskräfte wie Team-, Abteilungs- oder Bereichsleiter. Damit ergibt sich setzt allerdings auch die Voraussetzung, dass die Machtpromotoren die PLM-Einführung voll unterstützen. Wird zum Beispiel ein Teamleiter gegen die PLM-Einführung arbeiten, werden in der Regel auch dessen Mitarbeiter Barrieren aufbauen. Die Maßnahmen des Machtpromotors dürfen sich dabei nicht auf die alleinige Nutzung von Zwangsmaßnahmen stützen, da dies die Widerstände nur Oberflächlich beseitigt. Vielmehr hilft die demonstrative Unterstützung der PLM-Einführung wertet diese durch die Stellung der Fachpromotoren auf. Zusammengefasst bedeutet dies für die Rollenverteilung der Promotoren:

5.16 Mitarbeiter für PLM motivieren 273

x Fachpromotoren sind externe Dienstleister wie Unternehmensberater, Mitarbeiter der Softwareanbieter oder wissenschaftlicher Einrichtungen, sowie interne Mitarbeiter der Fach- und IT-Abteilungen. x Machtpromotoren sind in den Reihen Führungskräfte des Unternehmens zu suchen. In Abb. 5-71 wurden die Aufgaben der Promotoren im zeitlichen Ablauf eines Einführungsprojekts zusammengefasst. Der Begriff der Prozesspromotion taucht hier zusätzlich auf: teilweise wird in der Literatur empfohlen, einen zusätzlichen Prozesspromotor zu benennen, auch Kommunikationspromotoren wurden erdacht. Belasten die genannten Aufgaben die Fach- und Machtpromotoren zu sehr, ist diese Hilfestellung sinnvoll.

Abb. 5-71: Aufgaben der Promotren im Zeitablauf

274

5 Leithefte zu PLM-Aspekten

Tabelle 4. Merkmale destruktiven Widerstands Verhaltensweise

typische Formulierung

mangelnde Kompromissbereitschaft Festhalten an Totalforderungen Ausweichen auf andere Begründungen nach dem Ausräumen bisheriger Kritikpunkte Wiederholte rückkehr zu bereits verlassenen Argumetationspositionen

„Ich muss darauf bestehen, dass…“ „So oder gar nicht!“ „Und dann ist da noch…“

Wir müssen noch einmal auf … zu sprechen kommen“

Letztendlich hängt es vom Aufgabenumfang der PLM-Einführung ab, in wie weit eine Aufteilung in diese unterschiedlichen Rollen notwendig und sinnvoll ist. Der Prozess der PLM-Umsetzung wird vom PLM-Stab vorangetrieben, der die Rollen Fach-, Prozess- und Kommunikationspromotor in sich vereint, um die Kommunikation mit den Mitarbeitern zu führen, deren Widerstände abzubauen und Unterstützung aufzugreifen und von dem Machtpromotor vor allem bei der Überwindung von Widerständen unterstützt wird. Tabelle 4 zeigt Beispiele für Verhaltensweisen des Widerstandes nach Schirmer (Schirmer 2000). Feststellen betroffener Organisationseinheiten

Im Vorfeld der Einführung von PLM bzw. einzelner PLM-Funktionen besteht eine wesentliche Information darin, welche Organisationseinheiten durch die PLM-Funktion beeinflusst werden. Detaillierte Informationen können anhand von Prozessanalysen ermittelt werden (siehe Abschnitt 5.7). Eine weniger aufwendige Möglichkeit besteht in der Erstellung einer Beeinflussungsmatrix, helfen kann, kritische Bereiche im Vorfeld zu erkennen. Die Matrix stellt die Häufigkeit der Nutzung von konkreten PLMFunktionen wie Nummernvergabe oder Variantenmanagement den Organisationseinheiten gegenüber (siehe Abb. 5-72). Es wird getrennt erfasst, wie stark die Belastung durch Systemeingaben und wie groß die Entlastung ist, die die PLM-Funktionen den Organisationseinheiten bringen. Neben den absoluten Werten der Be- und Entlastung kann das Input-OutputVerhältnis ermittelt werden. Ein Wert von 1,0 bedeutet, dass die Integrationssysteme für die konkrete Organisationseinheit neutral wirken, d.h. eine Entlastung wird durch die zusätzliche Belastung kompensiert. Werte nahe Null sind kritisch: die Systeme wirken ausschließlich belastend. Erstre-

5.16 Mitarbeiter für PLM motivieren 275

benswert sind Werte größer 1, da hier die Organisationseinheit entlastet wird. Die Verhältniszahl lässt auch voraussagen, ob einzelne Organisationseinheiten anderen gegenüber benachteiligt sind: Streuen die Input-OutputVerhältnisse sehr stark? Dann kann es sein, dass die Organisationseinheiten mit sehr kleiner Verhältniszahl keine Akzeptanz für die Systeme zeigen und sie wenig bis gar nicht nutzen. Die Systeme sollten dann angepasst werden, sodass die Verhältniszahl der Organisationseinheit steigt: entweder durch Verlagerung der Eingaben in andere Organisationseinheiten oder durch Steigerung des Nutzens.

Abb. 5-72: Beispiel einer Belastungsmatrix

276

5 Leithefte zu PLM-Aspekten

Wirksame PLM-Vision

Die PLM-Vision ist im Vorgehensmodell als der Rahmen eingezeichnet, in dem sich das Einführungsprojekt bewegt. Sie soll als Klammer wirken und so das PLM-Projekt und seine Maßnahmen zusammenhalten und auf ein visionäres Fernziel koordinieren. Die PLM-Vision sollte früh im Ablauf des evolutionären Vorgehensmodells gefunden werden, damit sie eine Leuchtturmfunktion entfalten kann. Als spezielle Vision zum Thema PLM wird ein Mindestmaß an Kenntnis des Themas voraussetzt, wodurch einiger Vorlauf zu durchlaufen ist, bevor eine Vision formuliert werden kann. Die Vision ist allerdings nicht dogmatisch: bei besserem Wissen kann und muss sie geändert werden. Allerdings sollte dies nicht zu oft geschehen, da sonst der Eindruck der Beliebigkeit der Vision entstehen kann. Die motivierenden Aspekte der PLM-Vision sind: x Die (mögliche) Mitarbeit bei der Entwicklung der PLM-Vision. x Jeder soll die PLM-Vision verstehen und so Erfolge erkennen und beurteilen können: Da sich die PLM-Vision an jeden richtet und Grundlegendes beschreiben will, wird jeder einzelne über die Integrationssysteme informiert. x Das außergewöhnliche Fernziel ist ein Leistungsanreiz. x Vision schafft Sicherheit in schnelllebiger Umwelt: Als allgemein lösungsneutral formuliertes Fernziel stellt sie einen Maßstab für neue Entwicklungen dar. x PLM-Vision als „Gretchenfrage“: Zur Vision muss der Mitarbeiter Stellung beziehen. Je einfacher, sinnvoller, anregender und herausfordernder die Vision ist, desto größere unternehmerische Veränderungen bewirkt sie. Je mehr sie das Herz und den Verstand der Führungskräfte anspricht und in der Unternehmenskultur verankert ist, desto wirksamer findet sie ihren Niederschlag in der Unternehmenspolitik, in den Strategien und Direktiven und desto effizienter wird deren Umsetzung. Die PLM-Vision ist der Vorschlag eines Motivs, sie soll Energien wecken und eine Richtung aufzeigen. Hilfreiche organisatorische Maßnahmen

Um eine PLM-Einführung erfolgreich umsetzen zu können, ist der Austausch von Informationen zur Förderung der Akzeptanz unerlässlich. Diese Kommunikation zwischen den beteiligten Stellen Unternehmensführung (Machtpromotoren) PLM-Stab (Fachpromotoren) und den Mitarbeitern kann durch einfache Maßnahmen gefördert werden:

5.16 Mitarbeiter für PLM motivieren 277

x Ernennung von PLM-„Key User“: Dies sind interessierte Mitarbeiter aus den Fachabteilungen, die dem PLM-Stab zuarbeiten und mit den Unternehmensabläufen und Integrationssystemen gut vertraut sind. Konstruktive Kritik hinsichtlich der PLM-Vision und deren Umsetzung ist von diesen Mitarbeitern wünschenswert. x Regelmäßige Informationsveranstaltungen und Weiterbildungen: Ziel ist zum einen den PLM-Stab auf dem aktuellen Wissenstand zu halten, um die PLM-Umsetzung bestmöglich durchzuführen. Zum anderen sollen die Mitarbeiter über Weiterentwicklungen der PLMUmsetzung auf dem aktuellen Stand gehalten werden. Es werden Änderungen von Prozessabläufen oder Bedienung der Integrationssysteme geschult. Zudem können an dieser Stelle Rückmeldungen der Mitarbeiter über Schwierigkeiten oder Verbesserungsmöglichkeiten durch den PLM-Stab entgegengenommen werden. x PLM-Visions-Workshops: Diese Workshops dienen vor allem der Überprüfung der Aktualität PLM-Vision und ob die aktuellen Implementierungstätigkeiten zielführend auf diese hinarbeiten. Teilnehmer sind hier der PLM-Stab mit internen und externen Mitgliedern sowie die Unternehmensleitung. x Mitarbeiterbefragungen: Verteilung von Fragebögen mit wenigen Fragen bezüglich PLM an die Mitarbeiter. Beispielsweise kann nach der Zufriedenheit mit der PLMImplementierung, der Geschwindigkeit oder Zuverlässigkeit der Integrationssysteme oder Verbesserungsvorschlägen gefragt werden. Dies dient vor allem dazu die Akzeptanz von PLM zu verbessern und alle Mitarbeiter in die Weiterentwicklung mit einzubinden.

278

5 Leithefte zu PLM-Aspekten

5.17 Trends und Ausblick Schaut man in die nunmehr gut zwanzigjährige Geschichte der PLMEntwicklung zurück (siehe Kap. 1), so hat sich auch dieser Einsatzbereich der IT immer wieder an den jeweils aktuellen technischen und organisatorischen Trends und Entwicklungen ausgerichtet. Mit großer Regelmäßigkeit sind die jeweils aktuellen technischen Entwicklungen und „Hypes“ auch von der PLM Community – zunächst von der wissenschaftlichen Seite und mit gewissem Abstand dann auch von den Systemanbietern und Softwarehäusern – aufgegriffen und adaptiert worden. Betrachtet man zunächst die Entwicklungslinie der PLMIntegrationslösungen, so waren in den Anfängen des CAD sehr bald relativ viele Anbieter am Markt vertreten, die mit ihren „Engineering Database“ Produkten die CAD-nahe Verwaltung von Produktdaten und -dokumenten ermöglichten. In den vergangenen Jahren war bei den Softwareanbietern von Engineering-Lösungen eine sehr ausgeprägte Marktkonsolidierung zu beobachten. Zum einen wurden kleinere Anbieter von größeren Konkurrenten übernommen, um die Markpositionen weiter auszubauen, und zum anderen wurden bei diesen Zusammenschlüssen von Anbietern ergänzender Produkte strategische Ziele hinsichtlich eines breitgefächerter Lösungsportfolios verfolgt. Große Unternehmen, die sich zunächst mit neutralen SW-Systemen wie beispielsweise Datenbanken, Betriebssystemen oder Middleware Produkten etabliert hatten, sind vermehrt auch in Anwendungsbereiche eingedrungen. So sind heute auch im PLM-Umfeld Anbieter am Markt, die neben ihren ursprünglichen Produkten wie Datenbanksystemen oder ERPLösungen nun auch PLM-Module anbieten. Diese strategischen Ausrichtungen weisen auf einen Trend zur Vernetzung der IT-Lösungen in den produzierenden Unternehmen hin. Gerade bei den Unternehmen des Mittelstands werden oft IT-Lösungen „aus einer Hand“ oder zumindest von möglichst wenigen Lieferanten bevorzugt. Dies begründet sich in der Tatsache, dass kleinen Unternehmen typischerweise weniger Ressourcen für den Aufbau und die Pflege komplexerer IT-Infrastrukturen zur Verfügung stehen als dies bei Großunternehmen der Fall ist – auch wenn hierdurch oftmals auf eine optimal auf die spezifischen PLM-Anforderungen zugeschnittene Lösung verzichtet werden muss. Aus diesem Grund konnte in diesem Umfeld auch die Ende der 1990er Jahre in Mode gekommene Welle von Enterprise Applikation Integration (EAI) -Lösungen nicht Fuß fassen, da der Einsatz dieser Systeme im PLM-Umfeld meist mit zu viel Zeitund Kostenaufwand verbunden war.

5.17 Trends und Ausblick 279

Es werden zunehmend immer mehr Fälle bekannt, wo kleinere Unternehmen zunächst auf die Strategie „Alles aus einer Hand“ gesetzt hatten, dann aber aufgrund zu hoher Gesamtkomplexität und/oder zu wenig differenzierter und maßgeschneiderter PLM-Funktionalität ein (meist kostspieliges) Aufbrechen und Re-Design durchführen mussten. Dies ist einmal mehr ein Plädoyer für die in diesem Leitfaden propagierte systematische Konzeption und schrittweise Weiterentwicklung einer passgenauen PLMLösung. Da es in der Praxis aufgrund der unterschiedlichen funktionalen Anforderungen nicht zu verhindern ist, dass weiterhin eine Vielzahl unterschiedlicher IT-Systeme eingesetzt werden und diese entsprechend zu integrieren sind, besteht vermehrt der Bedarf an möglichst „leichtfüßiger“ Vernetzung und Integration dieser Systeme. Mittel- bis langfristig wird im Mittelstand eine stärkere Vernetzung der im Unternehmen vorhandenen Informationssysteme einerseits und andererseits zunehmend die Vernetzung der eigenen Systeme mit denen der Kunden und PLM-Partnern stattfinden müssen, um im immer stärker vernetzten Zusammenspiel bestehen und weitere Optimierungspotentiale erschließen zu können. Allerdings muss diese Vernetzung auf Basis von einfach zu handhabenden und möglichst standardisierten Ansätzen und Modulen stattfinden. Damit wird dem Konzept der Service Oriented Architecture (SOA, siehe Kap 3) für PLM-Software zukünftig eine starke Bedeutung zukommen, da die im Rahmen des PLMKonzepts vorhandenen Informationen über eine zentrale Struktur im Unternehmen zur Verfügung stehen müssen (Abramovici 2005). Die Softwarehersteller haben diesen Trend aufgegriffen und sind dabei, die entsprechenden Konzepte in ihre Systemlösungen zu implementieren. Umso entscheidender ist an dieser Stelle der erneute Hinweis darauf, dass für eine Umsetzung von Service-Orientierung neben dazu grundsätzlich fähigen Basis-Systemen eine entsprechend harmonisierte und abgestimmte Modellebene erforderlich wird. Um einen entfernten PLM-spezifischen Service wie beispielsweise das Traversieren einer Baugruppenstruktur sinnvoll nutzen und in eine PLM-Prozesskette einbinden zu können, muss auf beiden Seiten – beim Anbieter wie beim Nutzer – ein abgestimmtes Modell der Informationen und der Service-Schnittstellen zugrunde liegen. Mit dem von der europäischen Automobilindustrie vorangetriebenen, auf STEP basierenden (siehe Abschnitt 5.4) und mittlerweile von der Object Management Group (OMG) zur Verfügung gestellten PLM-Services Standard (OMG 2008) liegt hier bereits eine solide Grundlage vor. Allerdings ist die Umsetzung in die IT-Ebene hinein derzeit noch nicht vollständig gelöst. Hier bleibt wie so oft abzuwarten, inwieweit sich ein Standard etab-

280

5 Leithefte zu PLM-Aspekten

lieren kann. Anwender sollten hier aber auf eine möglichst hohe StandardAdaption achten. Ein weiterer im Kontext der PLM-Softwarelandschaft zu beobachtender Aspekt ist, dass sich mittlerweile zwei große Produktlinien von PLMLösungen mit einem die komplette PLM-Bandbreite überspannenden Funktionsspektrum im Markt etabliert haben, die sich jeweils an einem der beiden heute dominierenden CAD-Systeme ausrichten. Beide Produktlinien sind aufgrund des hohen Integrationsanspruches sehr komplex und relativ schwer einführbar. Für kleinere Unternehmen sind solche Integrationsplattformen in der Regel überdimensioniert. Entgegen des eingangs kurz umrissenen allgemeinen Trends, dass die großen Anbieter mehr und mehr kleinere Lösungen „aufsaugen“, bietet sich für Nischenanbieter hier immer noch genügend Marktpotenzial. So ist beispielsweise ein kleinerer deutscher Anbieter einer Softwarelösung, die ursprünglich noch auf die ersten „Engineering Database“ Ansätze zurückreicht, derzeit wieder sehr erfolgreich speziell bei kleineren und mittleren Unternehmen. Neben den zuvor aufgeführten Trends des Product Lifecycle Managements werden in den folgenden Abschnitten darüber hinaus funktionale Entwicklungen betrachtet. Hier sind aktuell zwei weitere miteinander verwobene Schwerpunkte zu nennen, mit denen die Spannweite mit PLM erreichbarer Ziele nochmals anwächst: x Wissens- und Innovationsmanagement zur Sicherung und zum systematischen Ausbau des Erfahrungswissens x Business Intelligence zur Datenanalyse und -aufbereitung 5.17.1 Wissens- und Innovationsmanagement Ein Trend im Umfeld des Product Licecycle Managements ist die Aufbereitung und das systematische zur Verfügung stellen von Erfahrungswissen. Im PLM wird hierzu zunächst die Bereitstellung von produkt- und fertigungsrelevanten technischen Informationen angestrebt, die als konkrete Detaillösungen in der Form von CAD-Produktmodellen, Zeichnungen, Stücklisten, Fertigungsunterlagen oder Pflichten-/Lastenheften verwaltet werden. Darüber hinaus gilt es, das in diesen Unterlagen versteckte implizite Erfahrungswissen explizit zu machen und über geeignete Informationssysteme zur Verfügung zu stellen. Die geschieht beispielsweise, indem Merkmale von Bauteilen geeignet klassifiziert (siehe Abschnitt 5.6.5) und über Sachmerkmalleisten auffindbar bzw. zuordenbar gemacht werden oder generell als Datenbankfelder zur Verfügung gestellt werden.

5.17 Trends und Ausblick 281

Durch diese Form der Wissensbereitstellung ergibt sich allerdings die Einschränkung, dass nur nach bereits ausgeprägten Detaillösungen gesucht werden kann und so die Lösung für eine technische Problemstellung bereits bekannt sein muss. Dies ist für Produktentwicklungen mit geringem Neuheitsgrad sehr effektiv, setzt jedoch ein breites Erfahrungswissen der Mitarbeiter voraus. Geht es jedoch um die Entwicklung von innovativen Lösungen, die einen hohen Neuheitsgrad haben, muss zunächst die Problemstellung möglichst gut identifiziert und strukturiert werden, um dann mit geeigneten Methoden und Verfahren des Wissensmanagements nach passenden Lösungsmustern im Erfahrungsschatz des Unternehmens zu suchen. Hierbei stellt sich beispielsweise die Frage, wann und inwieweit eine Lösung auf eine neue Aufgabenstellung in einem ähnlichen Kontext übertragen bzw. angepasst werden kann. In der Forschung werden hierzu beispielsweise Ansätze aus dem Bereich der Künstlichen Intelligenz und des Semantic Web verfolgt. Letztere sind dazu geeignet, eine so genannte semantische d.h. sich auf die Bedeutung eines Wissenszusammenhanges beziehend Suche zu ermöglichen. Dies setzt jedoch wiederum eine streng formale – rechnerrepräsentierbare Modellierung der Zusammenhänge voraus, zum Beispiel in Form so genannter Ontologien. Wissensmanagement im übergeordneten Sinne einer umrahmenden Managementdisziplin muss zukünftig das klassische PLM ergänzen und sich daran ausrichten, wie das Wissen, das heute noch weitgehend in den Köpfen der Mitarbeiter vorhanden ist, allgemein und übergreifend im Unternehmen bereitgestellt werden kann. Prinzipiell kann die Weitergabe von Wissen über zwei unterschiedliche Wege erfolgen. Zum einen können Strukturen im Unternehmen geschaffen werden, die eine kommunikative, organisatorische Förderung von Erfahrungsaustausch von Mitarbeitern und Geschäftspartnern vorsieht. Beispiele, die häufig angewendet werden, sind die Zusammensetzung von interdisziplinären Projektteams mit erfahrenen und weniger erfahrenen Mitarbeitern oder die Einrichtung von „Kaffee-Ecken“ als Kommunikationstreffpunkte. Zum anderen wird eine Bereitstellung und Erarbeitung von Wissen über technische und methodische Werkzeuge erreicht, wie beispielsweise die Anwendung von Kreativitätstechniken bei Besprechungen oder die Implementierung von Informationssystemen. In (Dold et. al. 2006) werden entsprechende Gruppen von Konzepten und Methoden zur Wissensentwicklung vorgestellt, die in den folgenden Abschnitten kurz beschrieben werden. Für die Anwendung dieser Konzepte und Methoden stellt sich im Rahmen des Product Lifecycle Managements immer die Frage, wie die

282

5 Leithefte zu PLM-Aspekten

Ergebnisse genutzt und vor allem gespeichert und allgemein zur Verfügung gestellt werden können. x Intuitiv assoziative Kreativitätstechniken: Die intuitiv-assoziativen Techniken dienen dazu, kreative Denkansätze im Problemlösungsprozess anzuregen und zu verstärken. Dazu wird über wechselseitige Assoziationen, Stimulationen, Analogiebildung, Strukturübertragung sowie spontane Einfälle aus dem Unterbewusstsein die Ideengenerierung gefördert. Beispiele für diese Techniken sind: Brainstorming, Methode 635, Ideen-Delphi oder Checklisten zur Ideengewinnung. Die Ergebnisse dieser Kreativitätstechniken liegen meist in Papierform vor, sodass zwar für das aktuelle Problem eine Lösung gefunden wurde, aber alle weiteren Ideen in Vergessenheit geraten. Eine Digitalisierung z.B. durch Einscannen oder Fotografieren bei gleichzeitiger Indizierung in einem Informationssystem erleichtert das Wiederauffinden von Ideen bei ähnlichen Problemstellungen. x Systematisch analytische Kreativitätstechniken: Die systematisch-analytischen Techniken versuchen durch vorgegebene Lösungsschemata die Wahrscheinlichkeit zu steigern, eine relativ optimale Lösung zu finden. Die wesentliche Heuristik dieser Technik ist die systematische Analyse eines Problems. Dabei wird die Problemstellung zunächst in ihre Teilprobleme aufgespalten. Für diese Teilprobleme wird mit Hilfe des Lösungsschemas durch Kombination und Variation von Lösungsansätzen eine Gesamtlösung erarbeitet. Morphologischer Kasten, Problemlösungsbaum, Wertanalyse oder Funktionsanalyse sind Beispiele für diese Techniken. Die systematischen Strukturen dieser Techniken vereinfachen die Implementierung in Software, sodass beispielsweise Tabellenkalkulationsprogramme vorbereitet werden können oder bereits fertige Softwarelösungen existieren. x TRIZ: Zu den systematisch-analytischen Methoden kann auch TRIZ (russisch: Teoria reschenija isobretatjelskich sadatsch = Theorie des erfinderischen Problemlösens) gezählt werden (N.N. 2011). Die TRIZ-Methode basiert darauf, dass sie bereits existierendes Wissen für die Entwicklung innovativer Produkte verfügbar macht. TRIZ setzt auf einer sehr umfangreichen, multidisziplinären Wissensbasis auf, in der Problemlösungs-Wissen in verdichteter und verallgemeinerter Form abgespeichert ist. Die TRIZ-Methode kann damit die betriebliche Wissensbasis erweitern und liefert zusätzlich eine Vorgehensweise, um im Unternehmen im Rahmen des Innovationsmanagements neues Wissen auf Basis der TRIZ-Wissensbasen entwickeln zu können.

5.17 Trends und Ausblick 283

x Erfahrungsbasierte statistische Methoden: Diese Methoden basieren darauf Erfahrungswissen der Mitarbeiter und statistisch erfasste Daten anhand vorgegebener Bearbeitungsmethoden zu erfassen. In interdisziplinären Teams werden dabei Anforderungen und Problemstellungen aus Entwicklung, Fertigung und Marktinformationen erfasst, um Probleme im Vorfeld einer Produktneuentwicklung auszuräumen. Beispiele hierfür sind Quality Function Deployment (QFD) und Failure Mode and Effects Analysis (FMEA) x Szenariotechnik: Mit der Szenariotechnik werden Zukunftsmodelle entwickelt in die Expertenwissen und individuelles Wissen der am Modellierungsprozess Beteiligten einfließt. Aus den Szenarien dieser Modelle kann abgeleitet werden, welche Faktoren in der Zukunft relevant sein können und welche Entwicklungen zur Bewältigung der Zukunftsbilder notwendig sind. Ziel ist die Ableitung zukünftig relevanten Wissens. Darüber hinaus wird durch den Zukunftsbezug der Szenarien gegenwärtiges Wissen in einer veränderten Perspektive sichtbar (Gausemeier et. al. 2009). x Betriebliches Vorschlagswesen: Das betriebliche Vorschlagwesen stellt ein meist monetäres Anreizsystem dar, das die Mitarbeiter dazu ermutigen soll Verbesserungspotenzial aufzuzeigen. In der Regel sind gewonnene Informationen und Wissensbeiträge der Mitarbeiter Detaillösungen, die die Problemstellungen der täglichen Arbeitspraxis optimieren. Dieses Wissen kann sowohl Produkte, Organisations- und Fertigungsprozesse, aber auch die allgemeine Arbeitsumgebung betreffen. x Lernzentren/Unternehmensuniversitäten: Die Einrichtung von Lernzentren oder Unternehmensuniversitäten dient dazu das im Unternehmen vorhandene Wissen durch erfahrene Mitarbeiter an neue bzw. zukünftige Mitarbeiter weiter zu geben. Unternehmensuniversitäten sind dabei eher allgemeiner ausgerichtet, während Lernzentren mit geringerem Aufwand Wissen für bestimmte Problemstellungen entwickeln. x Denkfabriken: Eine Denkfabrik (engl. Think Tank) ist ein Forschungsinstitut oder eine informelle Gruppe, die gemeinsam nationale oder globale Konzepte bzw. Strategien im politischen, sozialen und wirtschaftlichen Umfeld entwickeln und entsprechende öffentliche Debatten fördern. Denkfabriken werden meistens von Unternehmensverbänden, privaten Stiftungen oder Einzelpersonen finanziert, um neue Ideen in Bereichen wie zum Beispiel Wirtschafts- und Sozialpolitik oder Zukunftstechnologien zu erarbeiten. Zu den bekannten Denkfabriken können unter anderem der

284

5 Leithefte zu PLM-Aspekten

Club of Rome, die RAND Corporation, die Bertelsmann Stiftung oder das Öko-Institut Freiburg – Darmstadt – Berlin gezählt werden (N.N. 2011). x Produktkliniken: Das Konzept der Produktklinik (Wildemann 1998) sieht vor, durch Analyse von Produkten und Prozessen anderer Markteilnehmer sowie Kundenanforderungen und -informationen das eigene Wissen zu erweitern. x Forschungsinstitute/Universitäten: Der Kontakt zu Forschungsinstituten oder Universitäten gewährleistet die Nähe zu neuen Technologien und Forschungsansätzen, die mittelbis langfristig die Innovationsfähigkeiten im Unternehmen verbessern können. Dieses Wissen kann gemeinsam im Rahmen von Forschungskooperationen oder in Form von Auftragsentwicklung durch das Forschungsinstitut entwickelt werden. Vor allem die letztgenannten Punkte sind nicht nur als einzelne Elemente von Wissensmanagement zu sehen, sondern dienen in weiterführenden Konzepten als Basis für die systematische Generierung von neuen Produktideen: dem Innovationsmanagement. Innovationsmanagement ist definiert als systematische Planung, Steuerung und Kontrolle von Innovationen (N.N. 2011) mit Hilfe eines strukturierten Prozesses, der allgemein aus den Schritten Ideengenerierung oder Ideensammlung, Ideenbewertung, Produktentwicklung, Produktevaluierung, Produktmarketing und Produktvertrieb besteht. Alle angesprochenen Methoden und Konzepte generieren somit Informationen, die langfristig die Grundlage für die Entwicklung neuer innovativer Produkte darstellen. Diese Informationen nachhaltig in den Produktentwicklungs- und Fertigungsprozess einzubringen, stellt eine neue Herausforderung für das Product Lifecycle Management dar. Allerdings wächst damit auch die Vielfalt und Menge der Informationen noch einmal deutlich, so dass auch hierfür geeignete IT-Ansätze und Werkzeuge benötigt werden, um dieses Wachstum beherrschen zu können. Diese Werkzeuge können unter dem Begriff Business Intelligence zusammengefasst werden. 5.17.2 Business Intelligence Die ständig wachsende Informationsflut, die gerade auch durch Wissensmanagement bewusst gefördert wird, stellt die Unternehmen vor eine neue Herausforderung. Einerseits werden Informationen schneller und einfacher zugreifbar, andererseits sind diese Informationen sehr umfangreich und

5.17 Trends und Ausblick 285

häufig über viele Quellen verteilt. Zur Bewältigung dieser Herausforderung werden Konzepte, Methoden und Technologien benötigt, die Informationen automatisiert strukturieren und aufbereiten können. Auf diesen Aspekt setzen Anwendungen der sogenannten Business Intelligence zur Datenanalyse und -neustrukturierung ihren Fokus. Der Begriff Business Intelligence (BI) wird teilweise sehr breit gefächert für das Thema der Datenanalyse verwendet, die dazu dient, Managementinformationen zu gewinnen. In (Kemper et. al. 2006) wird Business Intelligence als ein integrierter, unternehmensspezifischer, IT-basierter Gesamtansatz zur betrieblichen Entscheidungsunterstützung definiert. Die technische Umsetzung einer Business Intelligence -Anwendung lässt sich als (datenbankbasierte) Software zur Extraktion, Verdichtung und grafischen oder textuellen Aufbereitung von Daten aus unterschiedlichsten Informationssystemen beschreiben. In einer Untersuchung zur Abgrenzung des Begriffs Business Intelligence werden sieben verschiedene Varianten identifiziert (Mertens 1993): x BI als Filter in der Informationsflut x BI als Informations- und Wissensspeicher x BI als Fortsetzung der Daten- und Informationsverarbeitung für die Unternehmensleitung x BI als Management Informationssystem mit schneller und flexibler Auswertung x BI als Frühwarnsystem x BI als Datawarehouse x BI als Prozess bestehend aus Symptomerhebung, Diagnose, Therapie, Prognose, Therapiekontrolle Der Hauptaspekt aktueller Business Intelligence -Anwendungen liegt vornehmlich in der Verwendung als Management-Informationssystem für wirtschaftliche Unternehmensbelange z.B. für Absatzkennzahlen wie der Verteilung auf die jeweiligen Märkte, der Verteilung der jeweiligen Produktkategorien oder Wareneingangskennzahlen zu Fehlquoten von Zulieferteilen nach Lieferanten aufgeschlüsselt. Business Intelligence im Rahmen von PLM ist parallel zum Wissensmanagement zu sehen. Wissensmanagement fokussiert von der Grundidee her die Erhaltung und Weiterverbreitung von erarbeitetem Erfahrungswissen. In Erweiterung zu diesem Erfahrungswissen kann Business Intelligence dazu genutzt werden, für die Produktentwicklung relevante Informationen aus produktions- oder kundenorientierten Bereichen des Unternehmens zur Verfügung zu stellen. Eine Anwendung von Business Intelligence zur Gewinnung von Informa-

286

5 Leithefte zu PLM-Aspekten

tionen im Rahmen der Produktentwicklung lässt sich anhand folgender Beispiele exemplarisch verdeutlichen: x Auswertung von Qualitäts- und Serviceinformationen: Qualitäts- und Service-Informationen zu einzelnen Produkten bzw. Bauteilen lassen sich in der Regel relativ leicht ermitteln. Die für die Entwicklung relevanten Informationen ergeben sich jedoch erst aus einer breiter gefächerten Betrachtungsweise dieser Basisinformationen: x Nehmen Qualitätsbeanstandungen ab einem bestimmten Zeitpunkt zu oder ab, der mit einer technischen Produktänderung einhergeht? Die Antwort auf diese Frage lässt darauf schließen, ob Produktänderungen erfolgreich waren bzw. ob versehentlich ein Fehlerpotential nicht berücksichtigt wurde. x Sind Fehlerbilder oder technische Defekte nur bei einem Produkt aufgetreten oder treten diese ebenfalls bei ähnlichen Produkten auf? Beruhen diese Ähnlichkeiten auf ähnlichen Geometrien, Werkstoffen oder Beanspruchungsfällen? Anhand der Analyse solcher Informationen können Designverbesserungen für zukünftige Produkte abgeleitet werden. x Auswertung von Fertigungsinformationen: Vergleichbar zu den Qualitätsinformationen lassen sich auch aus in der Fertigung anfallenden Daten und Informationen für eine Verbesserung von Produktentwicklungen gewinnen. Beispielsweise könnten Informationen zu Montagezeiten gleichwertiger funktionaler Produktkomponenten mit verschiedenen technischen Umsetzungen aufbereitet werden, um damit montagefreundliche Lösungen zu identifizieren. Eine weitere Möglichkeit des Informationsgewinns stellen bauteilbezogene Auswertungen von Nacharbeitszeiten oder Ausschusshäufigkeiten dar. Business Intelligence bietet für das Product Lifecycle Management ein hohes Potential an Möglichkeiten des zusätzlichen Informationsgewinns. Allerdings darf der mit der Umsetzung verbundene Aufwand nicht unterschätzt werden. Insbesondere die Einführung von BI-Softwarelösungen erfordert zunächst einmal die Definition von Schnittstellen zu den vorhandenen Informationssystemen mit allen damit verbundenen Anforderungen und Aufwänden (siehe Abschnitt 5.11). Diese Schnittstellen erfordern eine Definition von Daten, die aus den verschiedenen Quellsystemen für die Aufbereitung benötigt werden. Damit ermöglichen sie den Zugriff auf die für die Auswertung relevanten Informationen der verschiedenen Systeme. Weitergehend ist es ebenso wichtig, wie diese Informationen aus den jeweiligen Systemen miteinander in Beziehung zu setzen sind, um den gewünschten Wissensgewinn zu erreichen. Damit bekommt das Thema Mo-

5.17 Trends und Ausblick 287

dellierung wiederum Relevanz, da Modelle helfen, die Informationsstrukturen mit den Informationsverbindungen zu verstehen. Des Weiteren dient ein solches Modell ebenfalls als Kommunikationsgrundlage mit den Projektbeteiligten bei der Implementierung einer Softwarelösung. 5.17.3 Anforderungen an Softwareanbieter und Wissenschaft Obwohl Hardware und Netzwerkinfrastrukturen deutliche Leistungssteigerungen verzeichnen und auch der Funktionsumfang und die Bedienungsfreundlichkeit von Software deutlich zugenommen haben, sind noch längst nicht alle Probleme gelöst, die Unternehmen im täglichen Umgang mit den Aufgaben des Product Lifecycle Managements haben. Insbesondere die verteilte Zusammenarbeit von Kunden und Lieferanten über verschiedene Standorte hinweg wird bisher nur ansatzweise unterstützt. Zwar sind alle Softwarelösungen mittlerweile „web-fähig“, Netzwerkkonzepte, Sicherheitsrichtlinien, Zugriffsrechte oder beispielsweise Übertragungsgeschwindigkeiten erlauben dennoch oft keinen vollständig ortsunabhängigen Zugriff. So bedeutet dies für den Anwender noch lange nicht, dass es keine Rolle spielt, an welchem Ort er mit bestimmten Daten arbeiten möchte oder dass ein Lieferant seine Entwicklungen problemlos in die entsprechenden Systeme einstellen kann. CAD-Daten oder Berechnungsmodelle eines technischen Produkts umfassen in der Regel eine Datenmenge von mehreren hundert Megabyte oder eventuell auch Gigabyte. Selbst in den gut ausgebauten internen Unternehmensnetzwerken sind diese Datenmengen nicht unproblematisch zu handhaben. Im Falle der kollaborativen Zusammenarbeit müssen zumindest große Teile dieser Datenmengen zwischen den Partnern ausgetauscht werden. Dies bedeutet aufgrund der nach wie vor eingeschränkten Bandbreitenkapazitäten in osteuropäischen, asiatischen oder afrikanischen Länder einen enormen Zeit- und Investitionsaufwand. Selbst in Deutschland sind in vielen ländlichen Industriegebieten Internetanschlüsse mit mehr als 2 Mbit noch eher die Ausnahme (Apel-Soetebeer et. al. 2009), und somit ist eine der Grundvoraussetzung von effizienten Kollaborationsszenarien nicht erfüllt. Leider kann dieser Mangel auch nur unzureichend durch andere technische Lösungen ausgeglichen werden. Zwar gibt es Ansätze, die vorhandenen Kapazitäten effizienter zu nutzen, indem beispielsweise Datenzwischenspeicher (Caches) eingesetzt werden. Jedoch erbringen diese nur in begrenzten Teilanwendungen den gewünschten Nutzen. Wird beispielsweise auf ein Dokument immer wieder lesend zugegriffen, ist das Zwischenspeichern dieses Dokuments mit

288

5 Leithefte zu PLM-Aspekten

sehr großem Nutzen verbunden. Wird das Dokument jedoch häufig geändert, muss der Zwischenspeicher immer wieder aktualisiert werden, so dass letztlich kein Zeitgewinn entsteht. Es fehlen immer noch produktiv einsetzbare, einfach handhabbare technische Lösungen, die durch intelligente Mechanismen verteilte Datenbestände ressourcenschonend übertragen und verwalten können. Bei dieser Problematik könnten zukünftige Forschungen und Entwicklungen im Kontext des derzeit stark diskutierten Themas Cloud Computing Abhilfe schaffen. Der Begriff Cloud Computing bezieht sich auf die typische Darstellung des Internet in Schaubildern, in denen es in der Regel als Wolke abgebildet wird. Somit lässt sich die Idee des Cloud Computing als „Rechnen im Internet“ bezeichnen d.h. typische Dienste und Funktionen, die klassisch entweder vor Ort auf dem jeweiligen Arbeitsplatzrechner laufen, oder über einen dezidierten Server zur Verfügung gestellt werden, wandern in die „anonyme Wolke“. Dieses Konzept bezieht sich sowohl auf Applikationen wie auch auf Hardware und Systeme, die als Service zur Verfügung gestellt werden (Armbrust et. al. 2009). Cloud Computing verfolgt im wesentlich den lange gehegten Wunsch, zu jedem beliebigen Zeitpunkt genau die aktuell benötigte Softwarefunktion samt der damit verbundenen Rechnerkapazität für eine gerade anstehende Aufgabe dynamisch zur Verfügung gestellt zu bekommen. Teure und komplexe ITWerkzeug und Integrationssysteme müssen nicht mehr vorgehalten werden, die Komplexität und damit auch die Kosten der gesamten SWLandschaft würden damit extrem sinken. Im PLM-Kontext stellt sich bei der Vision des Cloud Computing – mehr als in anderen Anwendungsfeldern – die Frage, wie mit den großen und vor allem auch sehr unternehmenskritischen Datenbeständen umgegangen wird. Datensicherheit, Datenschutz, Datenintegrität, Schutz vor unerlaubtem Zugriff bzw. vor unerwünschter Weitergabe, all dies sind speziell im PLM-Kontext äußerst sensible Punkte, für die die Cloud zumindest in der heutigen Realisierungsform noch keine befriedigenden Lösungen bietet. Auch die Netzperformance stößt hier noch an Grenzen. Entsprechend müssen mit der Verlagerung von Softwareanwendungen und der Datenhaltung in ein weltumspannendes Netzwerk Konzepte zu Verfügung stehen, wie ein Nutzer z.B. aus Deutschland umfangreiche Informationen ohne große Verzögerungen abrufen kann, die über den tausende von Kilometern übertragen werden müssen. Letztendlich ist dies aber eine Entwicklung, die das Product Lifecycle Management zentral betreffen und auch verändern wird. Die Entwicklung, die Fertigung und der Betrieb von Produkten werden bereits im globalen Maßstab durchgeführt, wobei noch lange nicht alle Probleme, wie bei-

5.17 Trends und Ausblick 289

spielsweise schnelle Kollaborationsanbahnung oder CAD-Datenaustausch, in der Praxis gelöst sind. Dennoch wird der Trend hin zu globalen Prozessen und weltweitem Informationstransfer weiter anhalten. Kunden, Lieferanten und Hersteller eines Produktes werden immer stärker weltweit agieren, die Kommunikation wird einfacher und noch schneller werden. Langfristig werden Produktinformationen aus weltweit verteilten Informationsbeständen von Entwicklungspartnern online ohne großen Zeitverzug abgerufen und bearbeitet werden können. Bis diese Vision verwirklicht ist, müssen jedoch innovative Technologien entwickelt und neue Konzepte erforscht werden. Product Lifecycle Managment als Kernkonzept, wie es im vorliegenden Werk verstanden und beschrieben ist, wird jedoch ein zentraler Baustein auf dem Weg zur vollständigen Umsetzung dieser Vision sein. Obwohl und gerade auch weil die technische Weiterentwicklung so rasend schnell verläuft und immer wieder neue Lösungsbausteine und Konzepte auf der IT-Ebene ins Spiel kommen, wird die Beherrschung des Product Lifecycle Managements im weiteren und integrierten Sinne auch in Zukunft eine Herausforderung bleiben. Die technischen Möglichkeiten können immer nur ein Hilfsmittel sein, das für ein Unternehmen geeignete, individuelle PLM-Konzept zu entwicken. Die schrittweise Umsetzung der jeweiligen PLM-Vision, die Konzeption geeigneter IT-Lösungen und deren Implementierung erfordern heute und auch zukünftig einen hohen Aufwand und viel Engagement von Mitarbeitern wie auch von der Unternehmensführung. Als lohnendes Ziel locken u.a. kürzere Produktentwicklungszeiten, höhere Prozess- und Produktqualität, nachhaltigere Wissensspeicherung oder auch die Dokumentation der Erfüllung gesetzlicher bzw. vertraglicher Vorgaben. Die mit PLM individuell verfolgte Zielsetzung wie auch das jeweils erreichbare Optimierungspotential sind so einzigartig wie jedes Unternehmen. Auch wenn es aus diesem Grund keine Patentrezepte und PLM-Blaupausen geben kann und der Weg in der Regel ein steiniger ist – die intensive und kontinuierliche Auseinandersetzung mit den Konzepten und Methoden des Product Lifecycle Managements lohnt sich! Weiterführende Literatur

Abramovici M (2005) Quo Vadis PLM?; CAD/CADM-Report Nr. 10 Apel-Soetebeer F, Rentmeister J (2009) Bundeswirtschaftsministerium; http://www.zukunft-breitband.de Armbrust M, Fox A, Griffith R, Joseph A, Katz R, Konwinski A, Lee G, Patterson D, Rabkin A, Stoica I, Zaharia M (2009) Above the Clouds:

290

5 Leithefte zu PLM-Aspekten

A Berkeley View of Cloud Computing; UC Berkeley Reliable Adaptive Distributed Systems Laboratory; http://radlab.cs.berkeley.edu/ Dold E, Gentsch P (2006) Innovation möglich machen; Symposion Publishing Gausemeier J, Plass C, Wenzelmann C (2009) Zukunftsorientierte Unternehmensgestaltung: Strategien, Geschäftsprozesse und IT-Systeme für die Produktion von morgen; Carl Hanser Verlag, München, ISBN 9783-446-41055-8 Kemper H, Mehann W, Unger C (2006) Business intelligence - Grundlagen und praktische Anwendungen: eine Einführung in die IT-basierte Managementunterstützung; Wiesbaden: Vieweg Mertens P (1993) Neuere Entwicklungen des Mensch-Computer-Dialogs in Berichts- und Beratungssystemen. Bereich Wirtschaftsinformatik I, Arbeitspapier, Nürnberg N.N. (2011) The European TRIZ Associaton; http://etria.net Wildemann H. (1998) Produktklinik- Wertgestaltung von Produkten und Prozessen. TCW, München N.N. (2011) Denkfabrik: http://de.wikipedia.org/wiki/Think_Tank N.N. (2011) Innovationsmanagement: http://de.wikipedia.org/wiki/Innovationsmanagement OMG (2008) Object Management Group - Product Lifecycle Management Services, V2.0 OMG Beta-2 Specification; www.omg.org ProSTEP iViP (2003) ProSTEP integrierte virtuelle Produktentstehung http://www.prostep.org/de/standards-amp-infos/omg-plm-services.html

PLM zum Nachschlagen

Die nachfolgenden Zusammenstellungen beinhalten wichtige oder im Buch verwendete Begriffe und Abkürzungen. Sie sollen dem geneigten Leser als Anhaltspunkt dienen Hintergründe zu erschließen und weitere Informationsquellen für PLM ausfindig zu machen. Abkürzungen

ALE API ARIS ASP BAPI BC Sets BoM CAD CAM CAO CAQ CASE CDIF CMS COM CORBA CPC CPDM CRM CSE DPD DTP DV EDB EDM

Application Link Enabling Application Programming Interface Architektur integrierter Informationssysteme Application Service Providing; auch Active Server Pages Business Application Programming Interface Business Configuration Sets Bill of Material, Stückliste Computer Aided Design Computer Aided Modeling, Computer Aided Manufacturing Computer Aided Office (Automation) Computer Aided Quality Computer Aided Software Engineering CASE Data Interchange Format Content Management System Common Object Model Common Object Request Broker Architecture Collaborative Product Commerce Collaborative Product Definition Management Customer Relationship Management Concurrent and Simultaneous Engineering Digital Product Definition Desktop Publishing Datenverarbeitung Engineering Database Engineering Data Management, Engineering-DatenManagement

V. Arnold et al., Product Lifecycle Management beherrschen, 2. Aufl., DOI 10.1007/978-3-642-21813-2, © Springer-Verlag Berlin Heidelberg 2011

292

PLM zum Nachschlagen

eEPK EAI EIA EJB ERP FEM HTML ISO IT MQL OMG PDM PDMS PKM PLC PLM PPS QFD SCM SCM SOA STEP UML VDI VPDM W3C WfMC WfMS XMI XML XSLT

erweitere Ereignisprozesskette Enterprise Applikation Integration Electronic Industries Association Enterprise JavaBeans Enterprise Resource Planning Finite Elemente Methode Hypertext Markup Language International Standardization Organization Informationstechnologie Matrix Query Language Object Management Group Product Data Management, Produkt-Daten-Management Product Data Management System, Produkt-DatenManagement-System Product Knowledge Management Product Lifecycle Product Lifecycle Management Produktionsplanung und –steuerung Quality Function Deployment Software Configuration Management Supply Chain Management Service Oriented Architecture Standard for Exchange of Product Data Unified Modelling Language Verein Deutsche Ingenieure Virutal Product Development Management World Wide Web Consortium Workflow Management Coalition Workflow Management System XML Metadata Interchange Extensible Markup Language Extensible Stylesheet Language Transformations

Glossar 293

Glossar

Änderung

Eine Änderung ist die vereinbarte Festlegung eines neuen anstelle des bisherigen Zustands.

AI

Applikation Integration: Dabei handelt es sich um die Konvertierung von Daten und Befehlen aus dem Format einer Anwendung in das einer anderen, um den Datenaustausch zwischen inkompatiblen Anwendungen zu ermöglichen.

ANSI

American National Standards Institute, amerikanische Normierungsbehörde

API

Application Programming Interface: Schnittstelle zu einer externen Applikation die Zugriff auf die Funktionalität und die Datenbank eines Informationssystems ermöglicht. Die Schnittstelle besteht zumeist aus einer Bibliothek mit CallRoutinen (Abruf-Routinen), die in ein anderes Programm eingebaut werden kann, um die Funktion aufzurufen.

Aritkelstamm Beschreibende und klassifizierende Attribute zu einem Aritkel bzw. Produkt ASP

Application Service Provider und Application Service Providing: Ein Application Service Provider ist ein Unternehmen, das Software-Anwendungen für Unternehmen über das Internet zur Verfügung stellt. Die Bereitstellung von Software wird als Application Service Providing bezeichnet.

B2B

Business to Business: Gecshäftsprozess im E-Commerce, über den Unternehmen ihre Waren und Dienstleistungen anbieten und vertreiben können.

BI

Business Intelligence

BoM

Bill of Material, Stückliste (im Sinne der Mengenübersichtsstückliste)

294

PLM zum Nachschlagen

BREP

Boundary Representaion, Strukturmodell

topologische-geometrisches

CAx-Systeme Zusammenfassende Bezeichnung für CAD-, CAM-, CAE-, FEM-, CAQ-, EDA-Systeme etc. CE

Concurrent Engineering ist ein ganzheitlicher Ansatz für die verteilte Entwicklung eines Produktes im Team, wobei die Zerlegung der Konstruktionsaufgabe in kleinere parallel zu bearbeitende Teilaufgaben sowie die integrierte Beschreibung der entwickelten Produktdaten im Vordergrund steht.

Check-In

Das Anlegen eines neuen Dokuments oder des Zurückspeichern eines veränderten Dokuments in den elektronischen Vault (Dabei kann ein Datenmanagement-Modul die Vorgängerversion beibehalten). Meist wird dabei automatisch ein vom Modul kontrollierter Überprüfungsprozess gestartet.

Check-Out

Das Herauslösen eines vom Datenmanagement-Modul verwalteten Dokuments aus dem elektronischen Vault. Dieser Zugriff ermöglicht die Einsicht oder die Nutzung in einem anderen Produkt oder Bearbeitungsschritt, ebenso wie die Veränderung des Designs.

CMS

Content-Management-System: Ein CMS ermöglicht die programmgestützte Verwaltung von Inhalten einer Webseite. Ein wesentliches Merkmal eines CMS ist die Trennung von Inhalt und Aussehen.

CORBA

Common Object Request Broker Architecture: Architektur für die Implementierung von verteilten, objektorientierten Applikationen, d.h. Daten und Funktionen einer Applikation können von unterschiedlichen Informationssystemen genutzt werden.

CRM

Customer Relationship Management: Informationsystem zur optimierten Verwaltung von Informationen über Kunden und Lieferanten eines Unternehmens.

Glossar 295

CSCW

Unter CSCW wird ein interdisziplinäres Forschungsgebiet aus Informatik, Soziologie, Psychologie, Arbeits- und Organisationswissenschaften, Anthtropologie, Ethnographie, Wirtschaftsinformatik, Wirtschaftswissenschaften, u.a. verstanden, dass sich mit Gruppenarbeit und die Gruppenarbeit unterstütztender Informations- und Kommunikationstechnologie befasst.

Customizing

Anpassen eines Standardsoftwaresystems oder Referenzmodells an unternehmensspezifische Anforderungen

Data Dictionary

Vollständiges Verzeichnis aller in einem Datenmodell bzw einer Datenbank vorkommender Objekte (Datenfelder, Dateien, etc.). Es dient der Verwaltung von Daten, der Benutzer und der Protokollierung von Verknüpfungen zwischen Daten und Programmen. Neben der Überprüfung der Vollständigkeit werden auch die logischen Abhängigkeiten im Data Dictionary verwaltet. Das Data Dictionary ist ein Teil des Repository.

DatenbankSystem

Ein Datenbanksystem (DBS) ist ein elektronisches Archiv für die strukturierte Aufbewahrung großer Mengen inhaltlich zusammengehöriger Daten, aus dem viele Anwender oder Programme gleichzeitig und mit kurzen Zugriffszeiten Daten abrufen können. Ein Datenbanksystem umfasst die aus den Primärdaten bestehende Datenbank (DB), eine Datenbankbeschreibung, die über Aufbau und Organisation der Datenbank informiert, und Datenbank-Programme, die die Datenbank steuern und verwalten (Datenbankmanagementsystem, DBMS).

Datenmodell

Datenmodelle werden auf der konzeptionellen und auf der externen Ebene zur formalen Beschreibung aller Daten und ihrer Beziehungen untereinander verwendet. Hierbei wird jedes einzelne Objekt (engl. Entity), seine Eigenschaften (Attribute) und seine Beziehungen zu anderen Objekten (engl. Relationship) angeführt. Dies führt zum sog. EntityRelationship-Modell, das unabhängig von einer konkreten Anwendung ist. Die Mehrzahl der Datenbanken basiert auf einem der folgenden drei Modelle: Hierarchisches Daten-

296

PLM zum Nachschlagen

modell, Netzwerkmodell, oder das relationale Datenmodell. DCOM

Distributed Component Object Model, Industriestandard der Firma Microsoft zum Handhaben von Daten aus verschiedenen Quellen.

Digital Mockup

Repräsentation der Produktstruktur mit Baugruppen und Einzelteilen und deren Geometrie mit dem Ziel, die Optimierung über Modifikation in der Baugruppenstruktur und Simulationen wie Ein- und Ausbauuntersuchungen durchzuführen.

DM

Dokumentenmanagement

Dokument

Ein Dokument ist eine als Einheit gehandhabte Zusammenfassung oder Zusammenstellung von (Produkt-) Informationen, die nicht-flüchtig auf einem Informationsträger gespeichert sind.

Dokumentation

Eine Dokumentation ist die Summe der für einen Zweck vollständig zusammengestellten Dokumenten.

EAI

Enterprise Application Integration: Integration von unterschiedlichen Softwaresystemen durch Konvertierung von Daten und Befehlen aus dem Format einer Anwendung in das einer anderen.

ECAD

CAD-System der Elektrotechnik

EDB

Engineering Database, anderer Begriff für EDM/PDM

EDM

Engineering Data Management: Vorläufer von PDM

Entität

siehe Objekt

ERP

Enterprise Resource Planning: Konzept für das Management der kaufmännischen und produktionsrelevanten Bereiche eines Unternehmens, wie Fertigung, Finanzen, Logistik, Personal, Projekt, Vertrieb u.a.

Glossar 297

Erzeugersystem

Systeme, die primär Daten erzeugen (wie beispielsweise CAx-Systeme), wobei die Daten von anderen Systemen verwaltet werden müssen.

EXPRESS

Bezeichnung der Spezifikationssprache zur Beschreibung von STEP-Produktdatenmodellen (ISO 10303-11)

EXPRESS-G

(G: graphics) graphische Notation zur Beschreibung von STEP-Produktdatenmodellen

EXPRESS-X

Erweiterung von EXPRESS zur Spezifikation von Sichten

FEM

Finite-Elemente-Methode: Berechnungsmethode für Auslegung und Simulation statischer oder dynamischer Belastungen von Bauteilen.

Form-FitFunction

Kriterium zur Variantenbildung. Ist die geometrische Form , die Funktion oder die Passung betroffen, wird die übergeordnete Baugruppe ebenfalls eine Variante

Freigabe

Die Freigabe ist eine bestimmten Anweisungen entsprechende Genehmigung nach abgeschlossener Prüfung. Freigaben können objekt- oder tätigkeitsbezogen sein, z.B. Zeichnungsfreigabe (Freigabe der fertig gestellten Zeichnung) oder Konstruktionsfreigabe (Freigabe zum Konstruieren)

Groupware

Oberbegriffe für Softwarewerkzeuge zur Unterstützung von CSCW

GUI

Graphical User Interface: Grafische Benutzeroberfläche ist eine Umgebung, die im Gegensatz zu rein textbasierten Oberflächen, Programme und Dateien mit Hilfe von Grafiken, Bildern und Symbolen auf dem Bildschirm darstellt.

Gültigkeit

(auch Effektivität, engl. Effectivity) ist eine Angabe, die Änderungen oder die Verwendung von Varianten (und Versionen) in einem konkreten Produkt/Erzeugnis für einen bestimmten Zielbereich/Anwendungsfall für gültig erklärt.

298

PLM zum Nachschlagen

IGES

Initial Graphics Exchange Specification, von ANSI genormtes Format zum Austausch von Geometriedaten zwischen unterschiedlichen CAx-Systemen, Vorstufe von STEP

Informations- Die Gesamtheit der in einem Unternehmen vorhandenen infrastrukutr Hardware, Netze, Betriebssoftware und weitere betriebsnaher Software (der sog. Middleware), die für den Betrieb der unterschiedlichen Anwendungssysteme erforderlich ist. Informations- Die Gesamtheit der Aufgaben, Methoden und Werkzeuge management zum Aufbau, Verwaltung und Nutzung der Informationsinfrastruktur, die sowohl auf Rechnersystemen selbst, auf anderen Medien (Papier, Zeichenfolie) als auch latent vorhanden ist. Informations- Ein strukturiertes (Rechner-)System aus Geräten (Hardsystem ware) und Programmen (Software) und Methoden zur Erfassung, Speicherung, Übertragung, Transformation und Bereitstellung von Informationen. Integration

Die Integration ist eine auf Dauer ausgelegte enge Verbindung mehrerer Systeme, die von einem Benutzer als Einheit empfunden werden. Die Integration erfolgt überwiegend über eine einheitliche Benutzeroberfläche und/oder über gemeinsame Datenbestände. Dagegen ist eine Kopplung eine jederzeit trennbare Verbindung mehrerer Systeme, die jederzeit als eigenständig identifiziert werden können.

Integriertes Ein durchgängig modelliertes produkt- und prozessspezProdukt- und ifisches Modell. Es entsteht aus einem Produktmodell und Prozessmodell einem Prozessmodell, die auf Schema- und Instanzebene eng miteinander verknüpft sind. Java

Objektorientierte Programmiersprache, die weitgehend unabhängig von Betriebssystemen ist.

Glossar 299

Konfiguration Die in den Konfigurationsdaten definierten funktionellen und physischen Eigenschaften eines Produkts beschreiben dessen Konfiguration. Konfigurationsmanagement

Laut Leitfaden für das KM der ISO 10007 ist eine Konfiguration gekennzeichnet durch die funktionellen und physischen Merkmale eines Produkts, wie sie in seinen technischen Dokumenten beschrieben und im Produkt verwirklicht sind.

LangzeitArchivierung

Verfahren zur möglichst verlustfreien Aufbewahrung von Daten auf dafür geeigneten Medien in einem RechnersysTem unter Nutzung von Standardformaten, da Archivinhalte in der Regel wesentlich länger existieren als die Systeme mit denen sie erstellt wurden. Mit diesem Verfahren kann das Konvertieren bei jedem Release-Wechsel oder bei jeder Migration vermieden werden.

Mapping

Abbildung, Beschreibung der Abbildung der Anwendungselemente (ARM-Entities) auf Ressourcenkonstrukte und deren Subtypen.

Metadaten

Beschreibende, klassifizierende bzw. attributive Informationen zur Verwaltung und Organisation von Dateien. Metadaten, die in Datenbanken verwaltet werden repräsentieren Informationen über Ersteller, Erstellungsdatum, Freigabestatus, Aufbewahrungsort etc. und verweisen auf die Dateien, welche die jeweiligen produktdefinierenden Dokumente bzw. Modelldaten, beispielsweise technische Zeichnungen, 3D-CAD-Modelle, Stücklisten, Textdateien etc. enthalten.

Middleware

Kommunikationssoftware zur Systemintegration, die Daten zwischen Systemen repliziert, synchronisiert, überwacht und verteilt.

Migration

Entweder das Umsetzen von Programmen von einem Rechnersystem in ein anderes (unter Beibehaltung von wesentlichen Teilen des Programmcodes) oder die Einführung eines Nachfolgesystems für ein existierendes System

300

PLM zum Nachschlagen

bei gleichzeitiger vollständiger Überführung aller Anwendungen und Datenbestände in das Nachfolgesystem. Modell

Eine vereinfachte Darstellung eines Teiles der vergangenen, gegenwärtigen oder zukünftigen Wirklichkeit, wobei sich das Modell entweder auf einen tatsächlichen oder idealen Zustand beziehen kann. Das Modell abstrahiert die Realität, d.h. Eigenschaften und Ausprägungen, die für die Betrachtung oder Aufgabenstellung nicht wesentlich sind, werden weggelassen.

Objekt

Ein real oder begrifflich existierender Gegenstand mit fester, bekannter Menge von Eigenschaften (Attributen). Ein Objekt wird auch als Entität bezeichnet. Gleichartige Objekte sind Ausprägungen (Instanzen) eines Objekttyps. Sie werden durch Werte der Attribute des zugehörigen Objekttyps beschrieben.

OEM

Original Equipment Manufacturer: Ein Unternehmen das gegenüber dem Endkunden als Hersteller eines Produktes auftritt, wobei das Unternehmen die Integration und Montage der Komponenten eines Produktes übernimmt. Die Komponenten werden alle oder zumindest zum großen Teil von Zulieferunternehmen entwickelt und produziert.

OMG

Object Management Group, definieren Standards im EDM/PDM-Umfeld, beispielsweise CORBA.

Organistaion

Ein Regelsystem, mit dem Zuständigkeiten, Verantwortlichkeiten und Rollen (Aufgaben, Funktionen) miteinander verbundener Personen festgelegt wird.

PDM

Produktdatenmanagement: PDM ist ein Konzept zur Verwaltung und Bereitstellung von Produktdaten aus den Bereichen Entwicklung und Konstruktion im ganzen Unternehmen. PDM-Systeme bilden eine wichtige Basis für das Product Lifecylce Management.

PDM-Enabler Definition der OMG für eine CORBA-basierte Schnittstelle zum Informationsaustausch zwischen EDM/PDMSystemen, um einheitlich den direkten Zugriff auf be-

Glossar 301

stimmte Objekte und Funktionen (beispielsweise Workflow, Klassifizierung) in einem EDM/PDM-System zu ermöglichen. PDT Persistent

Product Data Technology, Produktdatentechnologie Dauerhaft, Dauerhaftigkeit, Zusammenhang: Informationstechnik. Eine Information im RAM ist nicht persistent, denn sie überdauert einen Stromausfall nicht. Eine Information auf Festplatte ist persistent.

PLM

Product Lifecycle Management: PLM bezeichnet ein Paradigma, dass die ganzheitliche, strukturierte und konsistente Verwaltung und Organisation aller Informationen, Daten, Dokumente und Prozesse unterstützt, die bei der Entwicklung neuer oder der Modifizierung bestehender Produkte über den gesamten Produktlebenszyklus generiert, benötigt und weitergeleitet werden müssen.

PPS

Produktionsplanungs- und –steuerungssystem, ist eine Vorstufe von ERP, Logistik, Betriebswirtschaft

Produktdaten

Produktdaten sind Struktur- und Stammdaten eines Produktes.

Produktdefinition

Menge der administrativen und organisatorischen Produktdaten.

ProduktFolge von Aktivitäten, die zur Entwicklung eines Proentwicklungs- dukts von der ersten Idee bis zur Freigabe für die Fertiprozess gung notwendig sind. Produktmodell

Die formale Beschreibung aller Informationen zu einem Produkt über alle Phasen des Produktlebenszyklus hinweg in einem Modell.

Produktstruk- Beziehung der einzelnen Artikel eines Produktes. tur Prozess

Eine in ihrer Länge/Dauer nicht begrenzte Folge von Funktionen bzw. Aktivitäten, wobei eine Funktion/Aktivität durch ein oder mehrere Ereignisse gestartet

302

PLM zum Nachschlagen

wird und in einem oder mehreren Ereignissen endet. Die einzelnen Funktionen/Aktivitäten sind inhaltlich abgeschlossen, sie stehen in einem logischen Zusammenhang zueinander. Referenzmodell

Ein Basismodell, das aufgrund eines gewissen Grades an Allgemeingültigkeit potentiell für die Erstellung mehrerer spezifischer Modelle herangezogen werden kann.

Repository

Vollständiges Verzeichnis aller in einem Informationsmodell vorkommender Objekte. Es besteht aus einem Data Dictionary sowie Verzeichnissen über sonstige Informationen, wie Datenmodell, Funktions- und Prozessmodell, evtl. auch mit den dazugehörigen Masken.

ROI

Return on Investment: Kennzahl zur Analyse der Rentabilität einer Investition. Produkt aus Unternehmenserfolg und Umschlaghäufigkeit des investierten Kapitals.

SachmerkMale

klassifizierende Merkmale eines Artikels

Sachmerkmal- Alle kennzeichnenden Parameter eines Gegenstandes leiste (SML) bilden zusammen dessen SML. Sie ist charakteristisch für einen definitiven Gegenstandstyp. So ist ein Zahnrad z.B. durch mehrere Durchmesser, mindestens eine Breite, die Anzahl der Zähne, den Werkstoff und ein übertragbares Drehmoment klassifiziert. In der DIN 4000 sind SML für eine Reihe von Teilefamilien definiert. Sachnummer

Eindeutige Identifizierungsnummer eines Artikels

SADT

Structured Analysis and Design Technique: Bezeichnung einer Modellierungsmethode zur Aktivitätenmodellierung

SCM

Software Configuration Management: Software zur Verwaltung von Quellcode insbesondere bei Softwareentwicklungen im Team.

SCM

Supply Chain Management: Abstimmung aller logistischen Vorgänge und Funktionen innerhalb der Lieferkette

Glossar 303

vom Lieferanten bis zum Verbraucher mit der Zielsetzung, die Informationen in dieser Kette für alle Beteiligte transparent zu machen. SCM-Systeme verzahnen die externen Wertschöpfungskette vom Rohmaterial Lieferanten bis hin zum Endkunden, indem alle relevanten Daten zwischen den Gliedern der Kette ausgetauscht werden. SGML

Standard Generalized Markup Language (genormt in ISO 8879) Simultaneous Vorgehensweise in Entwicklung, Konstruktion, ArbeitsEngineering vorbereitung (auch über Unternehmensgrenzen hinweg), bei der entweder ein umfangreicher Prozess aufgeteilt und parallel bearbeitet wird oder nacheinander ablaufende Prozesse zeitlich weitgehend parallelisiert werden. Dabei werden die in einem Prozess folgenden Prozesse zum frühestmöglichen Zeitpunkt gestartet, lange bevor der betrachtete Prozess beendet ist. Dieser Zeitpunkt ist erreicht, wenn das erste Ereignis des betrachteten Prozesses einigermaßen abgesichert vorliegt, so dass es von den nachfolgenden Prozessen verwendet werden kann. Simultaneous Engineering bedingt mindestens ein (üblicherweise interdisziplinär) arbeitendes Team. Stammdaten

Alle Daten des Artikelstamms werden in den Stammdaten zusammengefasst

STEP

Standard for the Exchange of Product Data: STEP ist eine internationale Norm zur Beschreibung und zum Austausch von Produktinformationen. STEP wird in der ISONormenreihe 10303 beschrieben.

Strukturdaten Strukturdaten beinhalten alle Daten, die einzelne Artikel zu einem Produkt in Beziehung setzen. Varianten

Varianten sind zeitlich parallel existierende, vergleichbare Ausprägungen ein und desselben Erzeugnisses bzw. Ergebnisses und damit potentiell gegeneinander austauschbar. Die Verwendung der Alternativen hängt vom konkreten Anwendungsfall ab.

304

PLM zum Nachschlagen

Vault

electronic Vault: geschützter Speicherbereich eines PDMSystems. Der Zugriff auf die im elektronischen Vault gespeicherten Daten wird von Regeln und Abläufen des PDM-Systems kontrolliert.

Version

Versionen sind zeitlich nacheinander entstehende, vergleichbare Arbeitsergebnisse bzw. Entwicklungsstufen einer Aufgabe oder eines Erzeugnisses. Eine neuere Version ersetzt meistens eine ältere Version, geht durch Veränderung oder Weiterentwicklung aus dieser hervor und stellt in der Regel eine Verbesserung dar.

Workflow

(Teil-)automatisierte Abläufe mit einem Informationsfluss

XML

eXtensible Markup Language: XML ist eine Sprache zur Beschreibung von Inhalten und Strukturen von Daten. XML ist heute quasi das Standardformat für den (dateibasierten) Datenaustausch zwischen Applikationen.

Literatur

Monographien

Altrogge G (1996) Netzplantechnik. Oldenbourg Verlag, München Wien Balzert H (1992) Die Entwicklung von Software-Systemen. BI- Wisenschaftsverlag Mannheim, Leipzig Wien Zürich Balzert H (1998) Lehrbuch der Softwaretechnik – Software-Management, Software-Qualitätssicherung, Unternehmensmodellierung. Spektrum Akademischer Verlag Heidelberg Berlin Beitz W, Grote K-H (2001) Dubbel – Taschenbuch für den Maschinenbau. Springer-Verlag Berlin Heidelberg Bronner A (2001) Industrielle Planungstechniken Springer-Verlag Berlin Heidelberg Bullinger H-J, Schreiner P (2001) Business Process Management Tools – Eine evaluierende Marktstudie. Fraunhofer-Institut für Arbeitswissenschaft und Betriebsorganisation IAO Stuttgart Clark K, Fujimoto T (1992) Automobilentwicklung mit System – Strategie, Organisation und Management in Europa, Japan und USA. Campus Verlag Frankfurt/Main u.a. CSC Catalyst (2000) CSC Catalyst Overview CSC. Ploenzke Akademie Kiedrich DIN 199-4 (1981) Begriffe im Zeichnungs- und Stücklistenwesen, Änderungen. Beuth Verlag Berlin Wien Zürich DIN 4000 – Teil 1 (2004) Sachmerkmalleisten – Begriffe und Grundsätze. Beuth Verlag Berlin Wien Zürich DIN 69900-1 (1987) Projektwirtschaft – Netzplantechnik, Begriffe. Beuth Verlag Berlin Wien Zürich DIN EN 82045 (2001) Dokumentenmanagement. Beuth Verlag Berlin Wien Zürich DIN ISO 10007 (2004) Qualitätsmanagment – Leitfaden für Konfigurationsmanagement Beuth Verlag Berlin Wien Zürich DIN V ENV 40003 (1991) Rechnerintegrierte Fertigung (CIM), System Architektur, Rahmenwerk für Unternehmensmodellierung. Beuth Verlag Berlin Wien Zürich

306

Literatur

EIA-649-A (2004) National Consensus Standard for Configuration Management. Beuth Verlag Berlin Wien Zürich Eigner M, Stelzer R (2001) Produktdatenmanagement-Systeme. Ein Leitfaden für Product Development und Life Cycle Management. SpringerVerlag Berlin Heidelberg Gausemeier J, Plass C, Wenzelmann C (2009) Zukunftsorientierte Unternehmensgestaltung: Strategien, Geschäftsprozesse und IT-Systeme für die Produktion von morgen; Carl Hanser Verlag, München, ISBN 9783-446-41055-8 Grabowski H, Anderl R, Polly A (1993) Integriertes Produktmodell. Beuth Verlag Berlin Wien Zürich Grabowski H, Lossak R, Weißkopf J (2002) Datenmanagement in der Produktentwicklung. Carl Hanser Verlag München Wien Grupp B (2003) Das IT-Pflichtenheft zur optimalen Softwarebeschaffung. mitp-Verlag Bonn ISO 10303-11 (1992) The EXSPRESS Language Reference Manual, Product Data Representation and Exchange – Part 11. Beuth Verlag Berlin Wien Zürich Keller G (1999) SAP R/3 prozessorientiert anwenden. Addison-Wesley Bonn Lindemann U, Reichwald R (1998) Integriertes Änderungsmanagment. Springer Berlin Heidelberg Mertens P (1993) Neuere Entwicklungen des Mensch-Computer-Dialogs in Berichts- und Beratungssystemen. Bereich Wirtschaftsinformatik I, Arbeitspapier, Nürnberg Nagel K (1990) Nutzen der Informationsverarbeitung – Methoden zur Bewertung von strategischen Wettbewerbsvorteilen, Produktivitätsverbesserungen und Kosteneinsparungen. R. Oldenburg Verlag München, Wien Opitz H (1971) Die richtige Sachnummer im Fertigungsbetrieb. Eine Basis für Rationalsierungsmaßnahmen im Rahmen der Auftragbsabwicklung Girardet Essen Product Data Management Enablers Specification (2000) Version 1.3. Object Management Group (OMG) Produkt-Daten-Management (2002) KPMG Consulting Berlin Reithofer W (1997) Ein System für den modularen Entwurf und die Simulation von K-CIMOSA Unternehmensmodellen. VDI Verlag Düsseldorf Romerskirch (1975) Pflichtenheft – Interner Bericht. Ursprüngliche Quelle nicht nachvollziehbar

Literatur 307

Scheer A-W (1991) Architektur integrierter Informationssysteme. Springer Berlin, Heidelberg Scheer A-W (2000) ARIS – Business Process Modelling, Springer-Verlag Berlin, Heidelberg Schichtel M (2002) Produktdatenmodellierung in der Praxis, Fachbuchverlag Leipzig Schöttner J (1999) Produktdatenmanagement in der Fertigungsindustrie – Prinzip, Konzepte, Strategien. Hanser Verlag München Wien Schreiber J (1994) Beschaffung von Informatikmitteln: Pflichtenheft – Evaluation – Entscheidung. Haupt Verlag Bern Stuttgart Schreuder S, Fuest N (1988) CAD/CAM für mittelständische Unternehmen – Leitfaden zur Planung und wirtschaftlichen Beurteilung einer CAD/CAM-Einführung, Verlag TÜV Rheinland Köln Steinberg C (1994) Projektmanagement in der Praxis. VDI Verlag Düsseldorf The Common Object Request Broker (2000) Architecture and Specification – Version 2.3.1. Object Management Group (OMG) VDI/VDE-Richtlinie 3694 (1991) Lastenheft/Pflichtenheft für den Einsatz von Automatisierungssystemen. VDI-Gesellschaft Mess- und Automatisierungstechnik Düsseldorf VDI-Richtlinie 2219 (2002) Einführungsstrategien und Wirtschaftlichkeit von EDM/PDM-Systemen. VDI-Gesellschaft Entwicklung Konstruktion Vertrieb Düsseldorf Wendenburg M (2001) Nutzung und Nutzen des ProduktdatenManagements. Océ Deutschland Mühlheim a.d.Ruhr Wildemann H. (1998) Produktklinik- Wertgestaltung von Produkten und Prozessen. TCW, München DIN 6763 (1985) Nummerung – Grundbegriffe. Beuth Verlag Berlin Wien Zürich

Zeitschriftenbeiträge

Abramovici M (1999) EDM/PDM-Einführungsstrategien – Erfahrungen und Perspektiven. Informationsverarbeitung in der Konstruktion 99: 209-226 Abramovici M (2005) Quo Vadis PLM?; CAD/CADM-Report Nr. 10 Bauer F (1995) Prozessorientierte Wirtschaftlichkeitsbetrachtung von CATechnologien. Europäische Hochschulschriften Reihe V, Volks- und Betriebswirtschaft 1813

308

Literatur

Boehm B (1988): A Spiral Model of Software Development and Enhancement, IEEE Computer. Vol. 21, Ausg. 5, Mai 1988: 61-72 Corban M (2004) PLM ist ein Thema für den Mittelstand. Industrieanzeiger 40: 42f. Jungfermann W (1999) Einführung von PDM Systemen. Engineering, Vertrieb und Service 99: 579- 646 Krzepinski A (1999) Nutzenorientierung – zentraler Erfolgsfaktor in PDM-Projekten. CADWORLD 3: 66- 68 Obermann K (2003) Sehr Konsequent! EDS bei Opel. CAD CAM 3: 14 18 Rational Rose (2000) Produktbroschüre. Rational Software Corp. Schirmer A (2000) Widerstände gegen Innovation. Führung und Organisation 6/2000 : 340ff. Vajna S (1999) Die neue Richtlinie VDI 2219: Praxiserprobte Hinweise zu Einführungsstrategien und Wirtschaftlichkeit von EDM/PDMSystemen. Informationsverarbeitung in der Konstruktion 99: 25- 42

Sonderfälle (Dissertationen, Berichte)

Adamietz P (2001) Adaption von Standardsoftwaresystemen. Shaker Verlag Aachen Dettmering H (2008) Disziplinübergreifendes Datenmanagement, Sierke Verlag, ISBN 978-3-868-003-4 Karcher A (2004) Projekt- und Produktlebenszyklus-Management – chancen, Nutzenpotenziale und Anforderungen von Produktdatenmangement (PDM) und Product Lifecycle Management (PLM). Kongressbeitrag: 21. Projektmanagement Forum 2004, Nürnberg, 4. -7. Oktober 2004 Gesellschaft für Projektmanagement (GPM) Kemper H, Mehann W, Unger C (2006) Business intelligence - Grundlagen und praktische Anwendungen: eine Einführung in die IT-basierte Managementunterstützung; Wiesbaden: Vieweg Kurz A (1998) Rechnerunterstütztes Ideen-Management für die innovative Produktplanung. Shaker Verlag Aachen Milde P (1997) Ein Beitrag für den Aufbau und die Nutzung von integrierten Unternehmensmodellen. Dissertation, Universität Karlsruhe (TH) Weber U (1997) Entwurf von Informationssystemen auf der Basis integrierter Unternehmensmodelle. Dissertation Universität Karlsruhe (TH) Weißkopf J (2002) Automatische Produktdatenklassifikation in heterogenen Datenbeständen. Dissertation, Universität Karlsruhe (TH)

Literatur 309

Zwicker E (1999) Unterstützung der unternehmensübergreifenden Produktentwicklung durch den Einsatz moderner Informationstechnologien Fortschritt-Berichte VDI Reihe 20

Internet

Armbrust M, Fox A, Griffith R, Joseph A, Katz R, Konwinski A, Lee G, Patterson D, Rabkin A, Stoica I, Zaharia M (2009) Above the Clouds: A Berkeley View of Cloud Computing; UC Berkeley Reliable Adaptive Distributed Systems Laboratory; http://radlab.cs.berkeley.edu/ Apel-Soetebeer F, Rentmeister J (2009) Bundeswirtschaftsministerium; http://www.zukunft-breitband.de Dold E, Gentsch P (2006) Innovation möglich machen; Symposion Publishing eClass Institut der deutschen Wirtschaft Köln, http://www.eclass.de Kahlert T, EDM/PDM-Systemauswahl Teil I: Technische Aspekte in EDMPDM Newsletter Ausgabe 2/2001, http://www.edmpdm.de/edmpdm_fachartikel/systemauswahl_technik.ht m N.N. (2011) The European TRIZ Associaton; http://etria.net N.N. (2011) Denkfabrik: http://de.wikipedia.org/wiki/Think_Tank N.N. (2011) Innovationsmanagement: http://de.wikipedia.org/wiki/Innovationsmanagement OMG (2008) Object Management Group - Product Lifecycle Management Services, V2.0 OMG Beta-2 Specification; www.omg.org ProSTEP iViP (2003) ProSTEP http://www.prostep.org/de/stepportal Rösch Consulting, http://www.roesch.com/begr_omg.html Skriptum Produktionsplanung und –steuerung der FH Köln; Prof. Dr.-Ing. Helmut Abels, http://www.pt.fh-koeln.de/ptd/lehr/abels/anfang.htm

Stichwortverzeichnis

3-Ebenen-Vorgehensmodell 234 Akzeptanzmanagement 266 Änderung 177 Änderungsauslöser 179 Änderungsdokumentation 181 Änderungsmanagement 175 API 218 ARIS 41 Attributdefinitionen 145 Backbone-System 212, 241 Business Intelligence 285 CAD-Integration 223 CAD-System 201, 210 Check-In 111 Check-Out 111 Client-Server-Architektur 201 Cloud Computing 288 Concurrent and Simultaneous Engineering 16 CORBA 44 Customizing 77, 196 Datenbank 111 Datenmodelle 21 Denkfabrik 283 Dokumentenmanagement 102 eClass 145 Effectivity 89 Engineering Change Management 180 Enterprise Application Integration 278

Enterprise Architecture Management 43 ERP 10, 210 ERP-Integration 224 EXPRESS 169 EXPRESS-G 216 FMEA 283 Form-Fit-Function 84, 90 Freigabe 153, 207, 209 Gantt-Diagramm 187 Gegenstandsgruppe 142 Geschäftsprozess 19 Gültigkeit 89 Historie 92 Identifikationsnummer 127 Implementierung 32 Inbetriebnahme 79 integrierten Produktmodells 39 IT-Architekturkonzepte 196 Kapazitätsplanung 185 Klassifikation 127 Klassifikationssysteme 136 Komponenten 85 Konfiguration 40, 91, 93 Konfigurationsauditierung 92 Konfigurationsbuchführung 92 Konfigurationsidentifizierung 92 Konfigurationsmanagement 90 Konfigurationsüberwachung 92 Künstlichen Intelligenz 281 Langzeitarchivierung 117

312

Stichwortverzeichnis

Lastenheft 244, 248 Major Releases 88 Maturity-Modell 57 Mechatronik 233 Merkmal 142 Metadaten 108 Middleware 27, 44, 210 Motivation 265 Netzplan 187 Nummernsysteme 122, 123 Occurence 231 Opitz-Schlüssel 140 Parallelnummer 126 Partialmodell 37 PDF-Format 118 PDM-Enablers 44 Pflichtenheft 66, 245, 251 Platzhalter 85 PLM 9, 10 PLM Services 279 PLM-Stab 52 PLM-Vision 53 PPS 210 Product lifecycle 9 Produktdaten 36, 94 Produktklinik 284 Produktlebenszyklus 9 Produktstruktur 82, 91 Projektmanagement 186, 190 Prozess 160 Prozessauslöser 179 Prozessmodell 40 Quality-Gate 234 Releasewechsel 196 Revisionierung 88 Sachmerkmal 142

Sachmerkmalausprägung 142 Sachmerkmalleiste 142 Sachnummer 133 Service Oriented Architecture 194, 279 Short List 249 Sichten 96 Software 227 Software Configuration Management 227 Stammdaten 37 STEP 44 Strukturdaten 37 Systemintegration 213 Teilevielfalt 134 Terminplanung 185 TIFF 117 Toolbox-Ansatz 206 Top-down-Methode 182 TRIZ 282 Turnkey-Lösung 206 UML 37 Unternehmensmodelle 159 Unternehmensmodellierung 153 Varianten 84 Variantenplatzhalter 85 Variantenstücklisten 85 Vault 110 VDI 2219 19, 55 Verbundnummer 125 Version 87 Wiehndahl-Schlüssel 147 Wirtschaftlichkeit 257 Workflow 157 XML 45