Product Lifecycle Management beherrschen: Ein Anwenderhandbuch für den Mittelstand

Volker Arnold · Hendrik Dettmering · Torsten Engel · Andreas Karcher

Product Lifecycle Management beherrschen

Volker Arnold · Hendrik Dettmering · Torsten Engel · Andreas Karcher

Product Lifecycle Management beherrschen Ein Anwenderhandbuch für den Mittelstand

Mit 88 Abbildungen

13

Dipl.-Ing. Volker Arnold FZI Forschungszentrum Informatik an der Universität Karlsruhe Abt. Prozess- und Datenmanagement im Engineering (PDE) Haid-und-Neu-Str. 10-14 76131 Karlsruhe, Germany [email protected]

Dipl.-Ing. Hendrik Dettmering Technische Universität München Lehrstuhl f. Informationstechnik im MW Boltzmannstr. 15 85748 Garching, Germany [email protected]

Dipl.-Inform.Torsten Engel Forschungszentrum Informatik an der Universität Karlsruhe Abt. Prozess- und Datenmanagement im Engineering (PDE) Haid-und-Neu-Str. 10-14 76131 Karlsruhe, Germany [email protected]

Prof. Dr.-Ing. Andreas Karcher Universität der Bundeswehr München Fakultät für Informatik Werner-Heisenberg-Weg 39 85577 Neubiberg, Germany [email protected]

isbn 10 3-540-22997-3 Berlin Heidelberg New York isbn 13 978-3-540-22997-1 Berlin Heidelberg New York Bibliografische Information der Deutschen Bibliothek Die Deutsche Bibliothek verzeichnet diese Publikation in der Deutschen Nationalbibliografie; detaillierte bibliografische Daten sind im Internet über http://dnb.ddb.de abrufbar. 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 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. Springer ist ein Unternehmen von Springer Science+Business Media springer.de © Springer-Verlag Berlin Heidelberg 2005 Printed in Germany Die Wiedergabe von Gebrauchsnamen, Handelsnamen, Warenbezeichnungen usw. in diesem Buch berechtigt auch ohne besondere Kennzeichnung nicht zu der Annahme, dass solche Namen im Sinne der Warenzeichen- und Markenschutz-Gesetzgebung als frei zu betrachten wären und daher von jedermann benutzt werden dürften. Sollte in diesem Werk direkt oder indirekt auf Gesetze, Vorschriften oder Richtlinien (z. B. din, vdi, vde) Bezug genommen oder aus ihnen zitiert worden sein, so kann der Verlag keine Gewähr für die Richtigkeit, Vollständigkeit oder Aktualität übernehmen. Es empfiehlt sich, gegebenenfalls für die eigenen Arbeiten die vollständigen Vorschriften oder Richtlinien in der jeweils gültigen Fassung hinzuzuziehen. Umschlaggestaltung: medionet AG, Berlin Satz: Digitale Druckvorlage des Autors Gedruckt auf säurefreiem Papier

68/3020/M

-543210

Vorwort

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

VI

Vorwort

Bestand haben müssen. Deshalb gilt es, das 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

Prof. Bender

Prof. Grabowski

Inhaltsverzeichnis

1

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

7 8 9 10

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

13 13 16 17 19 19 21 22 24 25 26 27

3

Basiskonzepte eines PLM-Manifests 3.1 Das integrierte Produktmodell 3.1.1 Bestandteile des integrierten Produktmodells 3.1.2 Aufbau eines integrierten Produktmodells 3.2 Das Prozessmodell

29 32 33 35 36

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

39 40 41 43 44 45 46 47 48 50

VI

Inhaltsverzeichnis

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.4.3 Vertragsabschluss 4.5 Phase „Implementation & Integration“ 4.5.1 Implementierung 4.5.2 Customizing 4.5.3 Test 4.5.4 Inbetriebnahme 4.5.5 Review 5

Leithefte zu PLM-Aspekten 5.1 Evolution der Produkte organisieren 5.1.1 Konfigurationsmanagement 5.1.2 Versionen- und Variantenmanagement 5.1.3 Versionierung von Produkten 5.1.4 Konfigurationsmanagement als zentrale Funktion 5.1.5 Umsetzung von 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 Technologieabhängige Sichten 5.2.5 Einführung eines Sichtenmanagements 5.3 Dokumente sicher verfügbar machen 5.3.1 Dokumentenmanagement 5.3.2 Typen von Dokumenten 5.3.3 Anforderungen an das Dokumentenmanagement 5.3.4 Strukturierung von Dokumenten 5.3.5 Beziehung zwischen Dokument und Artikel 5.3.6 Dokumente systemunterstützt verwalten 5.3.7 Umsetzung von Dokumentenmanagement 5.4 Produktdaten archivieren 5.4.1 Digitale Produktdatenarchivierung 5.4.2 Realisierung einer digitalen Produktdatenarchivierung 5.5 Nummernvergabe automatisieren 5.5.1 Nummernsystematik

54 55 56 57 58 59 60 61 62 62 62 63 64 65 65 67 68 69 70 72 74 75 78 79 80 81 81 82 84 85 86 87 88 90 92 94 98 99 100 102 103

Inhaltsverzeichnis

VII

5.5.2 Vorraussetzung für ein IT-konformes Nummernsystem 104 5.5.3 Aufbau von Nummernsystemen 104 5.5.4 Einführung/Restrukturierung des Nummernsystems 107 5.6 Finden statt Suchen 109 5.6.1 Produktklassifizierung 110 5.6.2 Klassifikation 111 5.6.3 Voraussetzungen für die Klassifikation 115 5.6.4 Aufbau von Klassifikationssystemen 117 5.6.5 Klassifikation im Product Lifecycle Management 120 5.6.6 Umsetzung der Klassifikation 121 5.7 Prozesse gestalten und steuern 123 5.7.1 Prozess- und Organisationsmanagement 124 5.7.2 Unterstützung von Prozessen und Organisation 125 5.7.3 Kenntnis von Prozess- und Organisationsstrukturen 126 5.7.4 Workflowmanagement mit Modellen 128 5.7.5 Prozessmanagement als Basis der Systemanpassung 132 5.7.6 Erstellen eines Unternehmensmodells 133 5.8 Transparente Änderungen gewährleisten 141 5.8.1 Änderungsmanagement 142 5.8.2 Potential im Änderungsmanagement 143 5.8.3 Änderungsmanagement im Mittelstand 143 5.8.4 Der Änderungsprozess im PLM 145 5.8.5 Einführung eines Änderungsmanagements 147 5.9 Produktzentrierte Projektabwicklung 151 5.9.1 Projektmanagement 152 5.9.2 Planung und Steuerung des Engineering 153 5.9.3 Hilfsmittel für das Projektmanagement 153 5.9.4 Projektmanagement im Engineering 155 5.9.5 Projektmanagement im PLM 156 5.9.6 Umsetzung von Projetktmanagement-Konzepten 159 5.10 Auf Standardsystemen aufbauen 161 5.10.1 Klassifizierung der Systemtypen 162 5.10.2 Architektur von Standardsoftwaresystemen 163 5.10.3 Anpassung von Standardsoftwaresystemen 166 5.10.4 Durchführung von Anpassungen und Systempflege 168 5.11 Systeme kommunizieren lassen 171 5.11.1 Applikationsintegration und Datenaustausch 172 5.11.2 Optimiertes PLM durch Applikationsintegration 173 5.11.3 Voraussetzung für Applikationsintegration 174 5.11.4 Implementierung von Schnittstellen 175 5.11.5 Informationsintegration im PLM 178 5.11.6 Umsetzung von Integrationslösungen 181

VIII

6

Inhaltsverzeichnis

5.12 Externe Dienstleister einbinden 5.12.1 Auftragsvergabe 5.12.2 PLM als Managementaufgabe 5.12.3 Projektspezifikation 5.12.4 Lastenhefterstellung 5.12.5 Ausschreibung 5.12.6 Lieferantenauswahl 5.12.7 Pflichtenhefterstellung 5.12.8 Realisierung 5.12.9 Implementierung 5.12.10Inbetriebnahme 5.12.11Außerbetriebsetzung 5.13 Mitarbeiter für PLM motivieren 5.13.1 Akzeptanzmanagement 5.13.2 Wissenschaftliche Ansätze zur Mitarbeitermotivation 5.13.3 PLM-Erfolg durch Mitarbeiterakzeptanz

183 183 184 185 186 187 188 189 190 191 191 192 193 194 194 196

Technische und methodische Grundlagen 6.1 Produktkonfiguration 6.1.1 Versionen 6.1.2 Gültigkeiten 6.1.3 Varianten 6.1.4 Sichten 6.1.5 Konfiguration 6.2 Standardteile und Baukästen 6.2.1 Standard- und Normteile 6.2.2 Baukästen 6.3 Nummernsysteme 6.3.1 Aufbau von Nummernsystemen 6.3.2 Formen von Nummernsystemen 6.4 Klassifikation und Sachmerkmalleisten 6.4.1 Sachmerkmalleisten 6.4.2 Klassifikationsschlüssel nach Opitz 6.4.3 Klassifikationsschlüssel nach Wiehndahl 6.4.4 Klassifikationsschlüssel eClass 6.5 Vorgehensmodelle 6.5.1 VDI-Richtlinie 2219 6.5.2 CSC Catalyst 6.5.3 Nutzenorientierte Einführung 6.6 Pflichtenheft und modellbasierte Dokumentation 6.6.1 Inhalt eines Pflichtenheftes 6.6.2 Anforderungen für den Software-Entwurf

205 205 205 207 207 209 209 210 211 211 212 214 217 219 219 221 222 223 224 224 227 229 231 232 234

Inhaltsverzeichnis

6.7 Systemevaluation 6.7.1 Nutzwertanalyse 6.7.2 Benchmarks 6.7.3 Systemtests 6.8 Betriebwirtschaftliche PLM-Aspekte 6.8.1 Definition der Wirtschaftlichkeit von PLM 6.8.2 Nutzenanalyse 6.8.3 Wirtschaftlichkeitsanalyse eines Integrationssystems 6.9 Modellierung 6.9.1 Grundlagen der Unternehmensmodellierung 6.9.2 Grundlagen der Datenmodellierung 6.10 Methoden und Tools 6.10.1 Unternehmensmodellierungswerkzeuge 6.10.2 CASE-Tools 6.10.3 Systemspezifische Werkzeuge 6.11 Informationstechnologie 6.11.1 Architektur von Informationssystemen 6.11.2 Rechnernetze 6.11.3 Grundlegende Informationstechnologien 6.11.4 Schnittstellenstandards

IX

236 236 237 238 238 239 242 244 246 247 248 253 253 257 257 258 258 260 262 265

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

269 269

Literaturverzeichnis

299

Stichwortverzeichnis

305

282 285

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), die in diesem Buch mittelständischen Unternehmen dargestellt wird. Product Lifecycle Management beginnt mit Eigenleistung (Schöttner 2002). Für Unternehmen gilt, entsprechendes Know-how aufzubauen, zu pflegen und Informationsmanagement im Produktlebenszyklus als zentrale, kontinuierliche Aufgabe im Unternehmen zu verankern. Das vorliegende Anwenderhandbuch soll die Durchführung dieser Aufgabe unterstützen und als Hilfestellung bzw. Nachschlagewerk für konkrete Teilaspekte des Product Lifecycle Managements dienen. Anforderungen und die damit verbundenen PLM-Konzepte in den unterschiedlichen Unternehmen sind viel zu individuell, um eine schrittweise Anleitung zur Verfügung stellen zu können. Das kann daher nicht Ziel des Anwenderhandbuches sein. Vielmehr soll Ihnen eine Arbeitsgrundlage zur Verfügung gestellt werden, die sie in die Lage versetzen soll, Ihren Weg zu einer eigen PLM-Umsetzung zu finden. So soll das Anwenderhandbuch ein Instrument zur durchgängigen Information sein, um PLM nachhaltig in Ihrem Unternehmen zu gestalten. Damit richtet sich dieses Buch primär an alle, die direkt oder indirekt vom Thema PLM im Unternehmen betroffen sind, wie die Entscheidungsträger, die einen entsprechenden Rahmen und Rückhalt für die PLMProjekte bieten müssen, das IT-Team für die Umsetzung sowie alle Anwender wie beispielsweise die Konstruktion und Fertigung.

8

1.1

1 Einleitung

PLM-Historie

In den letzten 15 Jahren hat die Informationstechnik nicht nur Einzug in die Produkte sondern auch in den Entwicklungsprozess von Produkten erhalten. So hat sich in diesem Zeitraum die Produktentwicklung enorm verändert. Während noch vor 20 Jahren ausschließlich an Zeichenbrettern konstruiert und entwickelt wurde, hielt nach und nach Computer Aided Design (CAD) Einzug in die Unternehmen. Die ersten CAD-Systeme waren 2D-CAD-Systeme, die ein reines Pendant zum Zeichenbrett 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 entstehen neue Möglichkeiten für die Entwicklungsmethodik. Produkte werden nicht mehr von zweidimensionalen Zeichnungen sondern von dreidimensionalen Modellen repräsentiert. Dadurch wird eine neue Entwicklungsmethodik unterstützt, eine modellbasierte Methodik, die an der späteren Fertigung angelehnt ist. Diese Modelle sind ein ganzheitliches rechnerinternes Abbild der verkörperten Geometrien. So enthalten sie wesentlich mehr Informationen als herkömmliche Zeichnungen. Dies ermöglicht eine Weiterverwendung der Modelle über die Konstruktion hinaus beispielsweise in Simulation und Fertigung. Eine solche Veränderung schlägt sich auch auf die Ablage der Entwicklungsergebnisse durch. Während Zeichnungen und 2D-CAD-Plotts in Archiven – als Medium dient Papier bzw. Mikrofiche – abgelegt werden, ist mit den 2D-CAD-Systemen die Möglichkeit der digitalen Dokumentenverwaltung beispielsweise mit einem Dokumenten-ManagementSystemen 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. Daher wird mit der Einführung von 3DCAD-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 ganzheitlich in PLM-Konzepten Anwendung finden. Spätestens mit dieser Entwicklung hat ein Paradigmenwechsel begonnen, der die Produktentstehung nachhaltig verändern wird.

1.2 Entstehungsgeschichte des Buches

9

Wie wird Ihr Unternehmen mit diesem Paradigmenwechsel umgehen? Ist Ihr Unternehmen reif für ein durchgängiges PLM? Dieses Buch, das sich primär an Unternehmen aus dem produzierenden Umfeld richtet, die sich selbst als kleinere und mittlere Unternehmen (KMU) sehen, stellt eine Möglichkeit der Herangehensweise an ein kontinuierliches Product Lifecycle Management mit der zentralen Aussage vor, dass PLM eine strategische Aufgabe ist, die als solche etabliert und verstanden werden muss. Denn auf Standardsoftware-Systemen basierende IT-Lösungen können die Unternehmensabläufe und -arbeitsweisen entscheidend positiv verändern. Sie sind noch lange kein Garant dafür, dass alle PLM-Potentiale eines Unternehmens effektiv erschlossen werden, bieten aber optimale Basiskonzepte zur Umsetzung der eigenen Anforderungen an PLM. Mit einem fundierten PLM-Ansatz wird auch Ihr Unternehmen für zukünftige Weiterentwicklung der IT im Produktentstehungsprozess gewappnet sein.

1.2

Entstehungsgeschichte des Buches

Dieses Anwenderhandbuch ist das Resultat eines zweijährigen Forschungsprojektes verbunden mit aktuellen Erkenntnissen aus Wissenschaft und Forschung. Die Forschungseinrichtungen „Lehrstuhl für Informationstechnik im Maschinenwesen der TU München“ (itm) und das „Forschungszentrum Informatik an der Universität Karlsruhe (TH)“ (fzi) haben diesen Trend und dessen Bedeutung für mittelständische Unternehmen schon im Jahr 2001 erkannt und starteten im Jahr 2002 das vom Bundesministerium für Wirtschaft und Arbeit geförderte Verbundprojekt, „Vorgehensmodell für ein kontinuierliches Product Lifecycle Informationsmanagement für KMU“ (PLM4KMU) im Rahmen des Programms „Förderung von innovativen Netzwerken“ (InnoNet). Projektträger war „VDI/ VDE Innovation und Technik GmbH“. Projektbeteiligte waren neben den zwei Forschungseinrichtungen neun mittelständische Unternehmen aus unterschiedlichen Branchen, KMU-Pioniere im Bereich Product Lifecycle Management. Ziel des Projektes war es, die Integration von PLM bei KMU durch die Entwicklung eines generischen Vorgehensmodells zu unterstützen. Unter einem generischen Vorgehensmodell wird ein abstraktes Vorgehensmuster verstanden, das nach Bedarf an ein Unternehmen angepasst werden kann und so zum individuellen Vorgehensmodell ausgestaltet wird. Dieser Vorgang wird durch die Methodik, die in diesem Anwenderhandbuch vermittelt wird, unterstützt. In den zwei Projektjahren sind Erkenntnisse über Nutzen und Anforderungen für mittelständische Unternehmen in

10

1 Einleitung

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

1.3

Aufbau und Anwendung des Handbuches

Das Handbuch umfasst sechs Kapitel. Nach dieser Einführung wird im Kapitel 2 Product Lifecycle Management in einem Gesamtabriss als kontinuierliche Aufgabe motiviert und auf die Komplexität des Themas eingegangen. So richtet sich dieses Kapitel primär an die Geschäftsführung und dient sowohl der Entscheidungsfindung als auch der organisatorischen und strategischen Einordnung. Das Kapitel 3 dient der Begriffsklärung der Grundmodelle des PLM-Paradigmas und beschreibt den Umgang mit diesen. Die hier angesprochenen Grundmodelle sind essentielle Basis für das in diesem Handlungsleitfaden vermittelte Verständnis von PLM. Hierauf folgt der Kern des Handlungsleitfaden, ein systematischer Ansatz für den Umgang mit PLM, der im Folgenden als Leitwerk bezeichnet wird, beschrieben in den Kapiteln 4 bis 6. Jedes Unternehmen braucht seine individuelle PLM-Lösung abhängig von den spezifischen Gegebenheiten des Unternehmens. Zu diesen Faktoren gehören beispielsweise Produktkomplexität, Unternehmenscharakteristik, Unternehmensumfeld oder gesetzliche Rahmenbedingungen. Im Einzelnen wird auf diese Faktoren in der ersten Phase des evolutionären PLM-Vorgehensmodells, der Phase der PLM-Readiness, eingegangen. Eine weitere Anforderung an das Leitwerk resultiert – wie schon erwähnt – aus der anhaltenden Bedeutung von PLM im Unternehmen. PLM wird ein immerwährendes Thema in einem Unternehmen sein, das niemals vollständig abgeschlossen sein wird. Dementsprechend ist das Thema PLM für jedes KMU individuell und fortwährend zu gestalten und dies ist vom Leitwerk zu unterstützen. So war es nicht möglich, eine Anleitung zur Einführung von PLM zu erstellen, die sequentiell abgearbeitet werden kann. Vielmehr musste ein Leitwerk erstellt werden, dass abhängig von den Facetten des Unternehmens ausgestaltet werden kann. Um diesen Anspruch gerecht zu werden, ist das Leitwerk in drei Ebenen aufgebaut, die untereinander interaktiv, abhängig von den eigenen Anforderungen, verknüpft werden.

1.3 Aufbau und Anwendung des Handbuches

11

Vorgehensmodell PLM-Stab -Vision PLM

1. PLM Readiness a. Bewertung/Zielsetzung

d 4.

1. 2. PLM Requirement Management b. Leistungsbeschreibung

PLMManifest

c

a 3. PLM Solution Design c. Pflichtenheft

2.

3.

4. PLM Implementation & Integration d. Umsetzung

b

1.

2.

Start eines TeilPLM-Unterprojekts projektiert nehmensbewervom PLM-Stab tung und Projektzielsetzung erstellt

3.

4.

Leistungsbeschreibung erstellt

Pflichtenheft erstellt

Umsetzung erfolgt, getestet und abgenommen

Leithefte Produktstruktur

Klassifikation

Sichtenkonzept

Nachschlagwerk Technische und methodische Grundlagen

Abb. 1-1: Aufbau des Leitwerks

PLMLexikon

.........

12

1 Einleitung

Das Grundgerüst zeigt Abb. 1-1. In der ersten Ebene wird ein allgemeingültiges Vorgehensmodell dargestellt, das auf einem Spiralmodell basiert und in dessen Mittelpunkt ein generisches PLM-Manifest steht. Auf das PLM-Manifest wird im folgenden Kapitel näher eingegangen. Das Spiralmodell handelt iterativ die thematisch zusammenhängenden PLMAspekte ab, wobei der PLM-Stab und die PLM-Vision die Verträglichkeit der einzelnen Themen untereinander und die Gesamtzielsetzung sicherstellen. Die betreffenden Themen werden situativ und anforderungsspezifisch in das Vorgehensmodell eingebunden. Sie werden in Form von Leitheften zur Verfügung gestellt, die in der zweiten Ebene aufgeführt sind. Jedes Leitheft behandelt einen PLM-Aspekt ausführlich. Aufgebaut ist jedes Leitheft zur leichteren Orientierung nach einem einheitlichen Schema. Nach einem einseitigen Abriss findet eine Einordnung des Themas in den PLM-Kontext statt. Im Kern eines Leitheftes wird die PLM-Relevanz des Themas diskutiert, ein Grundverständnis vermittelt sowie eine Umsetzung besprochen. 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 morphologischen Kasten für PLM dar und spiegeln den heutigen Stand der Technik wieder. Hierbei greifen die Leithefte wiederum auf Basiswissen zurück, das in der dritten Ebene des Leitwerkes vermittelt wird. Somit spiegelt das Handbuch den aktuellen Stand aus Forschung und Technik wieder. Weiterentwicklungen und Erkenntnisse wird es in zukünftigen Auflagen in neuen Leitheften zu integrieren gelten. Dieser Aufbau ermöglicht je nach Beweggründen 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 das Kapitel zwei und drei zu lesen. Durch die Leithefte 1 bis 3 („Evolution der Produkte organisieren“, „Produkte kontextabhängig darstellen“, „Dokumente sicher verfügbar machen“ s. Abschnitt 5.1, 5.2 und 5.3) und den Abstracts weiterer Leithefte kann zudem schnell ein umfassender Überblick über Funktionen der einzelnen PLM-Aspekte gewonnen werden. Soll der Handlungsleitfaden zur Realisierung einer durchgängigen PLM-Lösung herangezogen werden, ist das Kapitel 4 als zentrales Kapitel bezüglich des Vorgehensmodells zu lesen. Während der Umsetzung werden schließlich die Leithefte aus Kapitel 5 sukzessiv mit einbezogen. Das Nachschlagwerk des letzten Kapitels dient zum Aufbau eines Grundverständnisses und kann bei Bedarf in das Studieren des Handbuches mit einbezogen werden.

2 PLM – eine kontinuierliche Aufgabe

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

2.1

Begriffsklärung

Im gesamten Produktlebenszyklus (engl.: product lifecycle), das heißt von der Idee über Entwicklung und Konstruktion, Produktion sowie Vertrieb und Service bis zur Außerbetriebnahme eines Produktes entstehen große Mengen an verschiedensten Daten, Dokumenten und Informationen. Die technische Entwicklung der Werkzeuge zur Erzeugung und Verwaltung dieser Informationen hat sich im Laufe der Zeit stark gewandelt, wie etwa bei der Erstellung von technischen Zeichnungen vom Zeichenbrett über 2D-CAD-Systeme zu 3D-CAD-Systemen oder bei der Verwaltung vom Papierarchiv hin zu PDM-Systemen. Das Product Lifecycle Management (Abk.: PLM) ist ein integrierendes Konzept zur IT-gestützten Organisation aller Informationen über Produkte und deren Entstehungsprozesse über den gesamten Produktlebenszyklus hinweg, so dass die Information immer aktuell an den relevanten Stellen im Unternehmen zur Verfügung stehen. Die Summe aller unterstützenden

14

2 PLM – eine kontinuierliche Aufgabe

Lieferung

Rechnungswesen

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

Projektierung

Qualitätssicherung Entwicklung Konstruktion

Fertigung Dokumentation

Arbeitsvorbereitung

Montage

CAD CAM

FEM Papierdokumente ......

CAQ

Auftragssteuerung

Vertrieb Verkauf

Einkauf

Absatzplanung

Abb. 2-1: Konzept des Product Lifecycle Managements

Produktionsplanung

Product Lifecycle Management

Enterprise Ressource Planning

Projektsteuerung

Wartung Verschrottung Betrieb ReService cycling

2.1 Begriffsklärung

15

Eine zusammenfassende Definition für PLM bieten beispielsweise die Liebensteiner Thesen des sendler/circle (Sendler, 2004): • Product Lifecycle Management (PLM) ist ein Konzept, keine (in sich abgeschlossene) Lösung. • Zur Umsetzung/Realisierung eines PLM-Konzeptes werden Lösungskomponenten benötigt. Dazu zählen CAD, CAE, CAM, VR, PDM und andere Applikationen für den Produktentstehungsprozess. • Auch Schnittstellen zu anderen Anwendungsbereichen wie ERP, SCM oder CRM sind Komponenten eines PLM-Konzeptes. • PLM-Anbieter offerieren Komponenten und/oder Dienstleistung zur Umsetzung von PLM-Konzepten. Eine Aussage von John Stark verdeutlicht den Unterschied zwischen PDM und PLM nochmals: „PDM – An essential enabler for PLM“ (Stark 2005). Für ihn ist das PDM-System die essentielle Basis, die technologische Integrationsplattform, die PLM ermöglicht. Andere sehen PLM als Erweiterung von PDM mit spezifischen Funktionen. Vertreter dieses Ansatzes sind häufig bei Softwarehäusern zu finden, die ihre Systeme „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 informatonsverarbeitenden Prozesse über den gesamten Lebenszyklus hinweg. Product Lifecycle Management subsumiert hierfür eine Fülle von Einzelaspekten. Wird PLM als eine Gesamtsicht unter Einbezug aller integrierenden ITSysteme verstanden, bleibt jedoch ein ständiger Wandel des PLMs nicht aus. Veränderungen 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. Ein Unternehmen sollte sich vor dieser immerwährenden Aufgabe PLM nicht verschließen, sondern sich der neuen Herausforderung bewusst werden und PLM als kontinuierliche Aufgabe mit strategischer Bedeutung im Unternehmen verankern.

16

2.2

2 PLM – eine kontinuierliche Aufgabe

Vorgehen bei der PLM-Umsetzung

Zu Beginn eines Vorgehens steht immer eine Vision. In dem Moment, in dem man sich mit einem Thema auseinandersetzt, wird eine gewisse Erwartungshaltung an das Thema geweckt. Mit wachsendem Interesse und Informationen konkretisieren sich schließlich die Erwartungen. So verhält es sich auch mit dem Product Lifecycle Management. Auch dieses Handbuch wird seinen Beitrag zu Ihren Erwartungen an PLM beitragen. Ab einer gewissen Erwartungshaltung lassen sie sich zu einer Vision formulieren, mit der sich das Thema im Unternehmen kommunizieren lässt. Dies sollte sich ein Unternehmen zu nutzen machen und diese Vision mit Unterstützung der Unternehmensführung verbindlich festhalten. Die Vielzahl der Teilaspekte, die eng ineinander verzahnt ganzheitlich PLM darstellen, gestalten PLM zu komplex, um alle Aspekte in einem Projekt umsetzen zu können. Daher stellt dieses Buch ein iteratives Abhandeln von thematisch zusammenhängenden PLM-Aspekten in einzelnen Teilprojekten vor, die mit überschaubarem finanziellem und zeitlichem Aufwand abgewickelt werden können. Die Einführung und die Weiterentwicklung finden stufenweise in einzelnen Teilprojekten statt, um ein risikobehaftetes allumfassendes „PLM-Projekt“ zu vermeiden. Eine ähnliche Herausforderung muss bei großen Softwareprojekten gemeistert werden, bei denen sich das Boehmer-Spiralmodell als geeignetes Vorgehensmodell etabliert hat. Angelehnt an dieses Spiralmodell, erweitert um spezifische PLM-Komponenten, steht das evolutionäre PLMVorgehensmodell im Zentrum dieses Buches, mit dem in Schleifen ein ständiger Näherungsprozess an die optimale unternehmensspezifische PLM-Lösung, die PLM-Vision, stattfindet. Daher kommt es auf das richtige Vorgehen an. Ein methodisches Vorgehen auf Basis eines Vorgehensmodells, eine Schablone bzw. Muster für ein Vorgehen, ist unabdingbar. Unterstützende Handlungsleitfäden stellt dieses Buch in Rahmen eines kontinuierlichen Vorgehensmodells zur Verfügung. Dies kann jedoch nur mit einer systematischen Vorgehensweise und einer durchgängigen, möglichst formalen Dokumentation zielführend sein. Ähnlich wie bei anderen Ingenieurstätigkeiten, beispielsweise einer Bauzeichnung für ein Haus, bietet sich auch im PLM eine grafische Beschreibung mit fest definierten Elementen an, einem Modell. Ein gut strukturiertes Modell ist die beste Möglichkeit, die Komplexität des PLMs greifbar zu machen.

2.3 Komplexität dauerhaft beherrschen

2.3

17

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 im PLM Prozesse und Produktstrukturen verwaltet werden, die zu den Kernkompetenzen jedes Unternehmens zuzuzählen sind. Hierin ist die Komplexität des PLMs auch begründet. Je komplexer Produkte, Prozesse und die dazugehörigen Dokumente sind, desto komplexer gestaltet sich ein integriertes PLM. Für einzelne Aufgaben versprechen unterschiedliche ITSysteme eine Lösung. Jedoch wird kein Unternehmen ein System finden, das alle geforderten Aufgaben bewältigen kann. Lediglich einzelne Aufgabenstellungen werden mit gewissen IT-Systemen abgefangen. Wird das gesamte Unternehmen mit allen eingesetzten Tools betrachtet, wird man feststellen müssen, dass die Systeme sich teilweise ergänzen, teilweise überschneidende Funktionen haben oder sich sogar widersprechen. Nicht alle Aufgaben werden systemtechnisch unterstützt. Die Datenflüsse haben typischerweise mehrere Brüche und der Mensch dient als Puffer, um diese abzufangen. Ein systemtechnisch unterstütztes PLM soll diese Problematik angehen. So können heute grundsätzlich mehrere Ansätze zur Integration von PLM diskutiert werden. Ein föderaler Ansatz sieht eine Vielzahl von Systemen zur Aufgabenbewältigung vor. Während in diesem Ansatz die Komplexität in der Vernetzung der Systeme liegt, könnte ein anderer zentraler Ansatz ein umfangreiches Einzelsystem priorisieren, das sich auf Grund von Funktionsumfängen und unternehmensspezifischen Anpassung komplex darstellen wird. Eine allgemeingültige Antwort auf die Frage, welcher Ansatz zu bevorzugen ist, gibt es nicht. Der Ansatz dieses Anwenderhandbuchs ist es, PLM zunächst losgelöst von Systemen auf konzeptioneller Ebene zu betrachten, um einen Weg zur besten Lösung für das eigene Unternehmen zu finden. Daher ist eine Einteilung in unterschiedliche Ebenen sinnvoll. Die hier vorgestellte Unterteilung sieht drei Stufen vor, in denen jeweils die Organisation, die Prozesse, die Produkte sowie alle zugehörigen Daten betrachtet werden. 1. Das Fachkonzept ist losgelöst von sämtlichen Systemen. Auf dieser Ebene wird einzig ein Konzept für PLM betrachtet. Durch die Loslösung von Systemen zeichnet sich das Fachkonzept durch Beständigkeit über System-, Release- und Technologie-Wechsel hinaus aus. In diesem Konzept ist das gesamte Know-how über den eigenen Produktlebenszyklus festgehalten. Daher gehört zu den elementaren Ansätzen dieses Handlungsleitfadens, dass jedes Unternehmen selbst für das Fachkon-

18

2 PLM – eine kontinuierliche Aufgabe

zept verantwortlich ist. Eine Fremdvergabe an Dienstleistungsunternehmen ist nach Möglichkeit zu vermeiden! Lediglich Unterstützung zur Erstellung des Fachkonzeptes kann zugekauft werden. Eine möglichst formale Beschreibung dieses PLM-Konzepts ist für den Erhalt dieses Know-hows dringend empfehlenswert. Im Folgenden werden hierfür modellbasierte Methoden vorgestellt. 2. Das DV-Konzept bildet die zweite Stufe dieser Unterteilung. In dieser Ebene wird das Fachkonzept auf der IT-Infrastruktur abgebildet. Das heißt, dass hier die einzusetzenden Systeme erstmals mit betrachtet 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 IT-technische Umsetzung definiert. Nur wenn ein Unternehmen in der Lage ist, seine Anforderungen präzise zu formulieren, kann ein Systemlieferant die entsprechende 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. 3. Die Implementierung, die in der Regel ein aufwendiges Anpassen einer Standard-Software darstellt, stellt die unterste Ebene dieser Betrachtung dar. Alle notwendigen Eingriffe in die Systeme bis hin zu 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 in der Regel von externen Unternehmen eingekauft. Trotzdem sollte das eigene Unternehmen im Besitz dieser Unterlagen sein, um unabhängig vom umsetzenden Unternehmen zu sein. Dies wird sich spätestens bei bevorstehenden Änderungen positiv auswirken. Aber nicht nur konzeptionelle Gedanken sondern alle getätigten und geplanten Aktivitäten sollten formal in den drei Ebenen der Modellierung beschrieben sein. Mit dieser Aussage kommt noch ein zeitlicher Aspekt in die Modellierung. Hier wird im Allgemeinen zwischen Ist- und SollModellen unterschieden. Teilweise wird sogar noch eine dritte zeitliche Stufe, die Plan-Modelle, für einen mittelfristigen Zeithorizont eingeführt. Nur so kann ein Unternehmen gelassen auf den Wandel im Umfeld reagieren. Im Fokus des Unternehmens sollte jedoch das Fachkonzept stehen. Auf einem hohen Abstraktionsgrad müssen alle Produktinformationen und deren zugehörigen Abläufe aus unterschiedlichen Sichten und über mehre Hierarchieebenen in einem Modell beschrieben sein. Dieses „Integrierte Produktmodell“ ist Basis für Diskussion und Kommunikation. Es repräsentiert einen wesentlichen Teil der PLM-Kompetenz des Unternehmens.

2.4 Nutzen und Aufwendungen

19

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

2.4

Nutzen und Aufwendungen

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

Chancen durch Veränderung

Das Product Lifecycle Management betrifft alle Bereiche eines 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 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 konzeptionelle Vorarbeit, um die Erfordernisse des eigenen Unternehmens erfolgreich umsetzen zu können. Dies fängt mit einem Überdenken der Geschäftsabläufe an. Durch das Verwirklichen eines durchgängigen PLM-Konzeptes unter Einsatz entsprechender IT eröffnen sich neue Möglichkeiten für unterstützte Prozesse, die genutzt werden sollten. Als Beispiel sei hier die Parallelisierung von Prozessen mit dem Ziel, das Konzept des Concurrent Simultaneous Engineering (CSE) umzusetzen, genannt. Die Veränderung der Prozesse wirkt sich unweigerlich auf die Arbeitsweise jedes Mitarbeiters aus. Daher spielt die Einbeziehung der Mitarbeiter eine große Rolle, da diese die neuen Unternehmens-

20

2 PLM – eine kontinuierliche Aufgabe

abläufe tragen und leben müssen. In diesem Zusammenhang ist darauf zu achten, dass man sich nicht ein zu enges und zu starres Korsett durch zu restriktiv wirkende Systeme anlegt, um schnell und flexibel auf das sich fortlaufend ändernde Unternehmensumfeld reagieren zu können. Prinzipiell lässt sich der wirtschaftliche Nutzen auf die Verbesserung der drei, sich gegenseitig beeinflussenden Erfolgsfaktoren Durchlaufzeit, Kosten und Qualität zurückführen. Durch die Unterstützung der Parallelisierung von Prozessen und der nicht zur Wertschöpfung beitragenden Tätigkeiten wie z. B. Informationsbeschaffung, Datenaufbereitung, Änderungen, können Auftragsdurchlaufzeiten reduziert werden. Durch die Verwendung von Standardsystemen zur ganzheitlichen Prozess-/ Datenintegration kann eine zeitgleiche, unternehmensweite Bereitstellung relevanter Daten sowie ein transparenter, geregelter Zugriff (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 Betriebmittelbaus rechtzeitig eingeleitet werden. Ein weiterer wichtiger Aspekt zur Zeitverkürzung ist die Reduzierung von vermeidbaren Änderungen. Nicht-PLM-basierte Informationsstrukturen lassen ausschließlich klassische, sequentielle und arbeitsteilige Produktentstehung zu. Fehler und Mängel bleiben über weite Strecken unentdeckt, da ein Informationsabgleich entlang des Produktentstehungsprozesses meist nur durch aufwendige Abstimmungspunkte erfolgt. Unstimmigkeit haben schließlich zeit- und kostenintensive Änderungsprozesse zur Folge, die selbst auch noch eine gewisse Zeit in Anspruch nehmen, gerade wenn diese noch papiergestützt sind. Beispielsweise durch die Einführung eines Workflow-Managementsystem im Rahmen einer PLM-Umsetzung können Änderungsaufträge um ein vielfaches beschleunigt werden, da alle betroffenen Stellen im Unternehmen frühzeitig mit aktuellen Informationen versorgt werden. Die Änderungszeit wird drastisch reduziert und darüber hinaus ist sichergestellt, dass kein von der Änderung betroffenes Dokument vergessen wird. Dadurch wird die Konsistenz des Datenbestandes erheblich verbessert und eine redundante Modelldatenhaltung nahezu 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. Durch die wiederholte Datenaufbereitung resultieren redundante, inkonsistente und

2.4 Nutzen und Aufwendungen

21

meist fehlerhafte Datenbestände, deren Bezug zwischen den verteilten Unterlagen und dem aktuellen Produktstatus verloren geht. Durch eine PLM-Umsetzung wird die Suche und Verteilung von Daten, Dokumenten und Informationen effizienter gestaltet. Der größte Erfolgsfaktor der Kostensenkung resultiert aus der Reduzierung von Doppelarbeit. Die für ein Produkt entstehenden Kosten werden entscheidend in der Konstruktionsphase festgelegt. So stellt jedes wiederholt konstruierte Bauteil aufgrund fehlender, unübersichtlicher oder falscher Information für das Unternehmen eine Fehlinvestition dar. Jedes noch so kleine, mehrfach konstruierte und erzeugte Bauteil verursacht neben den Konstruktionskosten vermeidbare Ausgaben in Arbeitsplanung, NC-Programmierung, Werkzeug- und Betriebsmittelbau, Disposition etc. Deshalb verfügt ein ganzheitliches PLM über Klassifizierungssysteme und Sachmerkmalleisten, die die Wiederverwendung von Bauteilen in neu zu entwickelnden Produkten erleichtern. Durch diese Wiederverwendung und das daraus resultierende kleinere Teilespektrum werden Potentiale geweckt, die sich beispielsweise bis zu einer Reduktion des Lagerplatzes und damit einhergehend auf die Kapitalbindungskosten auswirken. Auf Grund der Komplexität der Eingriffe in ein Unternehmen in 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 zwischen strategischem und wirtschaftlichem Aspekt unterschieden, um Anhaltspunkte für eine Aufwand-/Nutzen-Analyse zu geben. 2.4.2

Strategische Betrachtung

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

22

2 PLM – eine kontinuierliche Aufgabe

So lässt sich der strategische Aspekt weiter unterteilen. Zum einen können aus PLM resultierende Daten als Produkt verkauft werden. Im obigen Beispiel verlangt Opel als OEM dies sogar. Dieser Aspekt ist vor allem bei Unternehmen von entscheidender Bedeutung, die im Sinne einer „verlä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:2000 aus (s. Abschnitt 2.5.3). Der strategische Nutzen von PLM lässt sich nicht allgemein quantifizieren. Wie die oben aufgeführten Argumente in eine Aufwand-/Nutzen-Analyse eingehen, bleibt dem jeweiligen Unternehmen belassen. 2.4.3

Wirtschaftliche Betrachtung

Neben dem strategischen Aspekt bringt PLM auch messbare, finanziell quantifizierbare Verbesserungen mit sich, den wirtschaftlichen Aspekt. Jedoch ist dieser Aspekt auch nicht wesentlich leichter zu ermitteln. Statistische Erhebungen, wie sie beispielsweise in der VDI 2219 über Zeitersparnis durch den Einsatz von PDM vorliegen, können als 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 diese Prozesse mit einem integrierten PLM-Konzept aussehen würden. Doppelarbeit, fehlende Schnittstellen, zeitversetzte oder unvollständige Weitergabe von Dokumenten und Informationen verursachen Zusatzkosten durch Verzögerung in der Fertigung, durch mangelhafte Qualität oder gar Ausschuss. Das kann bewertet werden. Es gibt darüber hinaus auch noch die Möglichkeit einer Zurückverfolgung, an welchen Stellen der 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 schon deutlich schwieriger. Diese wirtschaftliche Betrachtung bezog sich auf den Prozess. Aber auch die Möglichkeiten, die sich für das Produkt ergeben, wirken sich positiv auf eine Wirtschaftlichkeitsbetrachtung aus. Produktvarianten erfahren eine immer größere Bedeutung. Mit marginalen Mehrkosten in

2.4 Nutzen und Aufwendungen

23

der Entwicklung und der Fertigung erhält die Produktreihe einen Mehrwert. In der Prozesskette bedeutet dies, dass Varianten- und Konfigurations-Management ohne IT-Unterstützung der PLM-Systematik nur sehr aufwendig und meistens fehlerhaft gehandhabt wird. Als Beispiel sei eine Leiterplatte und Software mit verschiedenen Varianten zu einer Motorsteuerung genannt. Unterschiedliche Versionen der Leiterplatte und unterschiedliche Versionen der Software können für einen Bearbeiter und einen Benutzer zum Alptraum werden. Die Qualitätssicherung weist hierbei Mängel auf. Ein Verwendungsnachweis ist mitunter auch schwierig. Das kann dann besonders der Fall sein, wenn im Fertigungsprozess ein Austausch von Komponenten durch Alternativkomponenten erfolgt ist, der aber nicht ausreichend dokumentiert wurde. Das Resultat sind in jedem Fall höhere Kosten. Je eher diese Fehlerbehebung oder Schließung der Lücken der produktbezogenen Prozesskette erfolgt, desto größer ist die wirtschaftliche Auswirkung. Man geht davon aus, dass die Fehlerbehebung in der Entwicklungsphase mit Kosten von 1,- €, Kosten in den Folgephasen von mehr als 1.000,- € vermeidet. Natürlich müssen diesen Potentialen auch Kosten gegenüber gestellt werden. Auf den ersten Blick erscheint PLM als reines IT-Thema, was es aber nicht ist. Zugegeben, IT spielt eine wichtige Rolle, noch wichtiger jedoch sind die kurz- und langfristigen strategischen Ziele der organisatorischen und informationstechnischen Vernetzung über Abteilungsgrenzen, Bereichs- und Geschäftsfeldgrenzen sowie über Unternehmensgrenzen hinweg. Das Wissen steckt in den eigenen Köpfen. Die Lösung muss moderiert, vereinbart, strukturiert, dokumentiert und verabschiedet werden. Eine Umsetzung geht nur Schritt für Schritt. Der PLM-Ansatz ist ein gedanklicher Weg zur Effizienz-, Produkt-, Anwendungs- und Entsorgungsverbesserung, der vom Management gelebt werden muss. Der Weg ist das Ziel. Eine universelle PLM-Lösung gibt es nicht. Für jedes Unternehmen ist, auch unter Einbeziehung von Lieferanten und Kunden ein individueller Ansatz zu erarbeiten. Dies ist kein Widerspruch zu einer Realisierung mit so genannten Standard-Softwarekomponenten. Dies sagt jedoch nur, dass es kein fertiges Integrationssystem gibt, das gekauft werden kann. Die zu tätigenden Investitionen gehen darüber hinaus. Die Softwarekosten für ein PLM-Projekt werden erfahrungsgemäß lediglich zwischen 20% und 30% der Gesamtkosten liegen. Aus den angeführten Gedanken dieses Kapitels muss jedes Unternehmen seinen individuellen Nutzen im PLM ermitteln. Zuletzt zählt jedoch nur der langfristig quantifizierbare Produkt- und Kundennutzen. Eine detaillierte Wirtschaftlichkeitsanalyse sollte mit Hilfe des Abschnitts 6.8 „Betriebwirtschaftliche PLM-Aspekte“ erstellt werden.

24

2.5

2 PLM – eine kontinuierliche Aufgabe

Eingliederung ins Unternehmen

Viele wollen es, nur wenige haben es, das vollständig daten- und produktintegrierende PLM. In Abschnitt 2.4 „Nutzen und Aufwendungen“ wurde ausgeführt, dass es keine allgemeingültige IT-Lösung gibt. 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“. Ansätze sind aus den jeweiligen wirtschaftlichen Quellen der ITUnternehmen erklärbar; CAx, ERP, PDM, CRM, SCM etc. Die zumeist erforderliche Individualität der funktionsoptimalen Software sucht häufig nach Integration über die Erweiterung der eigenen Funktionalität unter Beibehaltung der eigenen Datenmodelle (s. Abb. 2-2). Finden in einem Unternehmen mehrere Systeme dieser Art Anwendung, wovon auszugehen ist, entsteht ein Interessenskonflikt, welches Datenmodell Basis für eine Erweiterung sein kann. Der Ansatz des PLMs integriert all diese Systeme in einem Konzept zu einem übergreifenden Modell. Wichtiger als die IT-technische Integration von PLM ist jedoch die organisatorische Etablierung. Betroffen von PLM ist jeder im Unternehmen, das Management, das PLM tragen muss, die Anwender, die PLM leben müssen und ein IT-Team, die PLM umsetzen müssen. Dessen muss sich jeder bewusst werden, der PLM in seinem Unternehmen einführen muss. Um rechtzeitig eventuell auftretenden Problemen entgegenzuwirken zu können, empfiehlt es sich, eine Zuständigkeit in der Organisation 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.

2.5 Eingliederung ins Unternehmen

Konstruktion

Recycling Verschrottung

AV

Entwicklung

Qualitätssicherung

Design

Fertigung

25

Vertrieb Marketing

Einkauf Logistik

Kundendienst

Versand Logistik

Standorte

Entwicklung

lokal national global

intern extern

Aufheben der Abteilungsgrenzen durch vertikale und horizontale Kommunikation

Abb. 2-2: PLM-Umfeld 2.5.1

Akzeptanz für PLM schaffen

Die meisten Ansätze beziehen sich lediglich auf den eingeschränkten Bereich des Produktdaten-Managements im Kontext des Engineering, häufig nur im Bereich der Produktentwicklung. Außen vor bleiben meistens 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. Aus diesem Grund soll das vorliegende Handbuch das Management eines Unternehmens in die Lage versetzen, die betriebswirtschaftliche Richtigkeit eines eingeschränkten, im Sinne der Definition, oder eines weit reichenden PLM-Ansatzes in die Planung, Entscheidung und Realisierung aufzunehmen. Die Definition des Ansatzes kann nur aus der Notwendigkeit und den Interessen des Unternehmens selbst erfolgen. Die Unterstüt-

26

2 PLM – eine kontinuierliche Aufgabe

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

Betroffene im Unternehmen

Alle Führungskräfte sind betroffen nicht nur Anwender und zwar ohne Ausnahme. Das gilt besonders für die konzeptionelle Gesamtsicht und für die Einführung, auch in Teilschritten. Die stärker betroffenen Abteilungen benötigen die Unterstützung der weniger tangierten Bereiche des 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 PLM-Systematik hat folgende Aspekte: • Geschäftsführung Kostensenkung im Gesamtprozess d. h. ein höherer Ertrag. Das kann aber zur Folge haben, dass größere Kosten in der Produktentwicklung auftreten und eine signifikante Kostenreduzierung in den anderen Bereichen, vor allem in der Fertigung eintritt. • Produktentwicklung eine größere Transparenz und Verfügbarkeit der Unterlagen. Dies ist ein wichtiger Aspekt bei verteilter Produktentwicklung auf verschiedene Standorte. • Qualitätsmanagement Zugriff auf die notwendigen Unterlagen und verbesserte Kontrolle von Freigaben. • Arbeitsvorbereitung, Fertigung, Kundendienst und Recycling Zugriff auf aktuelle Unterlagen und Rückführung aus der Operation bedingter Änderungen. Dadurch wird eine leichte Verlagerung der operativen Tätigkeiten an andere Standorte zur Kapazitätsauslastung, Unterstützung von Verbundfertigung oder lediglich zur Kostensenkung möglich.

2.5 Eingliederung ins Unternehmen 2.5.3

27

Synergien zwischen PLM und Qualitätsmanagement

Betrachtet man die grundsätzliche Struktur eines prozessorientierten Qualitätsmanagement-Systems, nach DIN ISO 9000:2000, 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 ein QM-System, nach DIN ISO 9000:2000, häufig nur auf den Herstellungsprozess konzentriert entsprechend der integrativen Notwendigkeit des jeweiligen Unternehmens. 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 überschreitender 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 Untenehmen vom Qualitätsmanagement profitieren sondern auch umgekehrt. Eine Zertifizierung nach ISO 9000:2000 ist prozessorientiert aufgebaut und verlangt nach formal beschriebenen Prozessen. Der Prozessmodellierungsgedanke und die Workflowmanagement-Module (s. Leitheft „Prozesse gestalten und “ Abschnitt 5.7) von PLM können maßgeblich zur Erfüllung der Anforderungen beitragen. So kann durch ein durchgängiges PLM die Zertifizierung nach DIN ISO 9000:2000 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 Basiskonzepte eines PLM-Manifests

In Abschnitt 2.3 wurde eine möglichst formale Beschreibung des Fachkonzepts und eine umfassende Dokumentation aller Vorgänge rund um das PLM gefordert, um ein zielorientiertes, zukunftsweisendes Konzept erstellen zu können. Hierfür sieht das Leitwerk ein eigenes Instrument vor, das generische PLM-Manifest. Das PLM-Manifest archiviert alle Dokumente rund um die PLM-Umsetzung. Hierzu gehören neben Sitzungsprotokolle, Schriftverkehr, Pflichten- und Lastenhefte, Verträge etc. vor allem formale Konzeptbeschreibungen der PLM-Lösung, die u.a. Grundlage für die zuvor genannten Dokumente bieten. Diese Konzepte und Dokumente unterliegen einer ständigen Weiterentwicklung und sollten entsprechend IT-gestützt verwaltet werden. Folglich wird das PLM-Manifest nach und nach mit Informationen angereichert. So wird es mit allen Aktivitäten fortgeschrieben, die das PLM betreffen. Daher ist es zum einen ein Manifest, eine gefestigte Dokumentation, und zum anderen wird diese Dokumentation immer weiter entwickelt. Das ist der generische Aspekt des Manifestes. 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 die Konzeptbeschreibungen aufsetzen (s. Abb. 3-1). Eine in dieser Form fortzuschreibende Dokumentation, die ständig Änderungen und Erweiterungen unterliegt, bedarf entsprechender Pflege und dieser wird nur dann Ziel führend nachgegangen, wenn für das PLMManifest eine eindeutige Verantwortlichkeit festgelegt wird. Das Leitwerk sieht für diese Funktion den im Folgenden eingeführten Beauftragten für PLM vor, den PLM-Stab. Der Einsatz von gängigen Methoden zur Dokumentation von Projekten ist 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 die formale Konzeptbeschreibung fokussiert werden. Ziel der Konzeptbeschreibung innerhalb des PLM-Manifests ist eine Kommunikationsbasis insbesondere als Elemente für Dokumente wie beispielsweise Lastenhefte und die zukunftssichere Konzeptdokumentation, die über Systeme hinweg Bestand haben muss.

30

3 Basiskonzepte eines PLM-Manifests

ot Pr ok

Produktmodell

olle

Ver trä ge

mentation Doku

ft he

ich ten he fte

ten Las

Prozessmodell

e

l Pf

etc.

Abb. 3-1: PLM-Manifest

Bevor auf die Konzeptbeschreibung näher eingegangen wird, muss der Gegenstand, der beschrieben werden soll, definiert werden. Hierzu soll noch einmal kurz das Ziel der PLM-Einführung vor Augen geführt werden. Im Mittelpunkt des Produktlebenszyklus stehen das Produkt und der zum Produkt zugehörigen Prozesse. Beide Elemente sollen mit entsprechenden Engineering-Werkzeugen in ihrer Ganzheit verwaltet werden, gleichwohl ob es sich bei den Produkten des 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, so dass durch Abstraktion ein Grundmuster für alle Produkte und Prozesse entsteht. Es soll so eine gewisse Transparenz geschaffen werden. Dieses Credo ist Basis für einen durchgängigen IT-gestützten Lifecycle. Um dies zu erreichen, müssen alle Produkte, alle Prozesse, alle Daten und die gesamte Organisation in der Beschreibung berücksichtigt 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. Dass heißt, es muss eine eigene Logik zum Abbilden bzw. Abstrahieren der realen „Welt“ erarbeitet werden. In diesem Anwenderhandbuch werden grundsätzliche Methoden zur Erstel-

3 Basiskonzepte eines PLM-Manifests

31

lung 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 Manifests darstellt. Die Abbildungslogik besteht aus komplexen Informationen, die nicht mehr ausreichend formal verbal beschrieben werden können. In anderen Fachrichtungen haben sich Experten schon sehr früh Gedanken über das Abbilden komplexer Informationen gemacht. Die frühste abstrakte Beschreibung für ein geplantes Objekt dürfte aus der Architektur stammen. Jeder Hausbau beginnt mit einem Plan. Dieser Plan ist ein Abbild, ein Modell, des zukünftig entstehenden Hauses. Niemand käme auf die Idee, ein geplantes Haus ausschließlich textuell zu beschreiben. Jedoch können auch solche Modelle sehr schnell recht umfangreich und dadurch komplex werden. Hier bieten Modelle den Vorteil, dass sie abstrahiert und strukturiert werden können. In einzelnen Modellen werden Detailinformationen beschrieben und ein weiteres Modell eines höheren Abstraktionsniveaus fasst mit reduzierten Detaillierungsgrad diese Modelle zu einem Gesamtbild zusammen. Ein Beispiel hierfür ist eine Baugruppenzeichnung, die durch Einzelteilzeichnungen ergänzt wird. 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 CADModell 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 großen Anzahl von Einzelteilen, die eine gewisse Abhängigkeit besitzen, verkörpert durch die Produktstruktur. In der Produktstruktur werden Einzelteile in Baugruppen zusammengefasst und mit Beziehungen hinterlegt. So entsteht eine spezielle Sicht auf ein Produkt. Für einen ganzheitlichen IT-technischen Ansatz ist dies jedoch nicht ausreichend. Die Struktur muss abhängig von Sichten dynamisch generiert 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. Eventuell kann es sogar nötig sein, organisatorische Einheiten mit dem Produkt in Beziehung zu setzen.

32

3 Basiskonzepte eines PLM-Manifests

Hierzu ist eine entsprechende Beschreibung der Organisation zur Definition von Rechten, Aktivitäten und Zugehörigkeiten notwendig. Während Zugehörigkeiten direkt zu Personen, Abteilungen und/oder Projekten erstellt werden können, sollten Rechte und Aktivitäten über so genannte Rollen definiert werden. Genauere Informationen zu diesem Konzept finden sich im Leitheft „Prozesse gestalten und steuern“ (s. Abschnitt 5.7). Für die modellhafte Beschreibung von Organisationen haben sich allgemein Organigramme bewährt, die jeder kennt. Für das Rollenkonzept lässt sich ein ähnlicher Strukturbaum aufstellen, der mit dem Organigramm verknüpft werden muss. Hilfsmittel zur Prozessbeschreibung liefert die Informatik, Wirtschaftslehren und insbesondere die Wirtschaftinformatik, an die man sich anlehnen kann. Die formale Beschreibung der ganzheitlichen Produktmodellierung disziplinübergreifend ist eine besondere Methode aus dem PLMUmfeld. Hier hat sich das so genante integrierte Produktmodell etabliert. Das Integrierte Produktmodell verfolgt nach H. Grabowski drei Ansätze und erfüllt somit die Anforderungen an die produktzentrische Beschreibung: „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 darauf folgend gesagt: „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)

3.1

Das integrierte Produktmodell

Abgebildet wird dieser ganzheitliche Ansatz in dem integrierten Produktmodell. Das integrierte Produktmodell ist nach VDI 2219: „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 interessierenden Aspekte des Produktes über den gesamten Lebenszyklus hinweg anfallen. Zur Menge der relevanten Daten

3.1 Das integrierte Produktmodell

33

gehören organisatorische, technische und technologische Daten, mit denen das Informationsbedürfnis aller am Product Life Cycle beteiligten Abteilungen und Bearbeiter abgedeckt werden kann. Produkte werden ganz nach der oben vorgestellten Definition in verschiedenen Erzeugersystemen mit spezifischen Zielen beschrieben. Jedes Modell dieser Art ist ein Partialmodell des integrierten Produktmodells. 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 gesamten Produktmodell zusammen und ergänzt zusätzlich Struktur- und Stammdaten. Als Rückgrat des integrierten Produktmodells fungiert ein Produktstrukturmodell. Das integrierte Produktmodell ist das zentrale Instrument im PLM. Es stellt den Kern des in Kapitel 4 beschriebenen Vorgehensmodells dar. Notwenig ist die Beschreibung des integrierten Produktmodells, da alle gängigen PDM-Systeme und standardisierte Austauschformate auf diesem Konzept aufsetzen, wie beispielsweise auch der STEP-Standard, ein normiertes Austauschformat, das sich im PLM-Umfeld etabliert hat. Auf diesen Standard wird noch des Öfteren im Leitwerk eingegangen. Ein Überblick über STEP bietet Abschnitt 6.11.4. Das integrierte Produktmodell wird letztlich ein Schema für alle Produkte liefern, die wiederum eine Instanz des integrierten Produktmodells sind. Für die in diesem Buch verwendeten Modelle werden im folgenden Klassen-, bzw. Objektdiagramme der Unified Modeling Language (UML) als Notation für das integrierte Produktmodell verwendet, eine Modellierungssprache der objektorientierten Softwareentwicklung (s. Abschnitt 6.9.2). 3.1.1

Bestandteile des integrierten Produktmodells

In der UML wird zwischen Klassen und Objekten unterschieden. Eine Klasse stellt ein abstraktes Element dar, ein Muster für Objekte. Objekte sind konkrete Elemente. In diesem Zusammenhang spricht man auch von einem Objekt als einer Instanz einer Klasse (s. Abschnitt 6.9.2). Übertragen auf PLM und insbesondere auf Produkte bedeutet dies, aus jedem abzubildenden Produktelement wird im Modell ein Objekt einer bestimmten Klasse. Beispielsweise wird aus einem CAD-Modell, das ein Getriebe beschreibt, ein Objekt „CAD-Modell des Getriebes XY“ der Klasse CADDateien und aus dem Getriebe selbst ein Objekt Getriebe der Klasse Baugruppe. Die Objekte werden durch Stammdaten und durch Strukturdaten beschrieben.

34

3 Basiskonzepte eines PLM-Manifests

Stammdaten sind Daten, die ein Objekt näher beschreiben und identifizieren. Sie sind selbstständig, ohne Beziehung zu anderen Daten aussagefähig und existenzberechtigt (s. Abschnitt 5.3.5). Strukturdaten sind Daten, die unter Berücksichtigung von Bedingungen Beziehungen zwischen den Ausprägungen von Stammdaten herstellen. Beispiele für Produktstrukturdaten sind: • • • • • •

„besteht aus“ „ist verbaut in“ „enthält“ (z. B. Ordner) „wird beschrieben durch“ „ist abhängig von“ „ist Vorgänger/Nachfolger von“

Diese Produktstrukturdaten können mit Bedingungen 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“ (s. Abschnitt 5.1) und „Produkte kontextabhängig darstellen“ (s. Abschnitt 5.2) beschrieben.

Produkt gültig ab 1.1.04

Baugruppe

Bauteil 1a

Baugruppe

Bauteil 2

Baugruppe

Baugruppe

Bauteil 1b

Bauteil 3 I Version

Bauteil 4

Bauteil 3 II Anforderungen Variante/Alternative

CAD-Dokument

Beschreibende Dokumente

Abb. 3-2: Integriertes Produktmodell

3.1 Das integrierte Produktmodell 3.1.2

35

Aufbau eines integrierten Produktmodells

Kern des integrierten Produktmodells ist die Produktstruktur, die einer Baumstruktur ähnelt. Ein Produkt wird über Baugruppen und Einzelteile aufgeschlüsselt. Jeder Strukturzweig endet an einem Bauteil, einem Einzelteil. Die Struktur terminiert am Einzelteil. Ein Einzelteil liegt immer dann vor, wenn das betrachtete Teil aus Sicht des Betrachters nicht weiter zerlegbar ist. 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 Struktur. Durch dynamisches Einbinden der betroffenen Elemente an die gemeinsamen übergeordneten Strukturelemente (Baugruppen) werden 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 und im Nachschlagwerk im Abschnitt 6.1 näher eingegangen. Durch das Hinzufügen produktbeschreibender Daten, insbesondere von Dokumenten, den Partialmodellen, wird aus der Produktstruktur das integrierte Produktmodell. Hierzu werden an einem Bauteil bzw. an einer Baugruppe alle beschreibenden Dokumente mittels eines logischen Elements angehängt, das wiederum auf das entsprechende Dokument verweist. Ob sich eine Versionierung oder Variantenbildung auf die übergeordnete Baugruppe auswirkt, wird über das Kriterium Form-Fit-Function ermittelt. Ist Art, Bauraum oder die Funktion betroffen, muss aus der übergeordneten Baugruppe ebenfalls eine Variante gebildet werden. 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 Prä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 und Sicht (s. Abschnitt 6.1.4 und 6.1.5).

36

3.2

3 Basiskonzepte eines PLM-Manifests

Das Prozessmodell

„Produktdaten entstehen nicht in einem luftleeren Raum, sondern werden immer im Kontext von Prozessen erzeugt“ (Schichtel 2002). 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. : Kundenauftrag

: Artikel

: Vertrieb

Bearbeiten()

Steuerung IstBestellbar() Eingabedaten

verabeiten zu

Mechanismus (Prozesor)

[bestellbar] & [fertig bearbeitet]

UML-Sequenzdiagramm

SA/DT

Kundenauftrag eingetroffen Vertrieb

Auftragsbearbeitung

Auftrag angenommen

Ausgabedaten

Artikel

Kundenauftrag

ARIS: eEPK

Abb. 3-3: Methoden der Prozessmodellierung

3.2 Das Prozessmodell

37

Die Prozessmodelle ergänzen die Produktmodelle zum unternehmensspezifischen PLM-Manifest, dem Kern des Vorgehensmodells aus Kapitel 4. Der Beschreibung der zugehörigen Modellierungsmethodiken 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“ (s. Abschnitt 5.7) nachgeholt. An dieser Stelle sollen als Ausblick auf drei etablierte Methoden gegeben werden (s. Abb. 3-3): • Das EPK der „Architektur integrierter Informationssysteme (House of ARIS)“ • Das Sequenzdiagramm der „Unified Modeling Language (UML)” • Structured Analysis and Design Technique (SA/DT) Die Modelle haben eine unterschiedlich detaillierte Aussage und eignen sich daher für unterschiedliche Abstraktionsebenen. Beispielsweise zeigt das EPK in der Abbildung den so wichtigen Bezug zu einem Artikel, der auch im integrierten Produktmodell zu finden sein sollte. Auch Dokumente können und sollten in eine Prozessbeschreibung berücksichtigt werden. 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 initiiert 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 die Prozesse für eine PLM-Einführung zu beschreiben, besteht bei der Prozessbeschreibung eine große Synergie zwischen PLM und Qualitätsmanagement. Spätestens durch die ISO 9000:2000 Zertifizierung wird auch im Qualitätsmanagement eine Prozessbeschreibung gefordert, so dass hier die beiden Interessensgruppen voneinander profitieren können.

4 Evolutionäres Vorgehensmodell

Negative Schlagzeilen zu gescheiterten oder überteuerten PLMEinführungen füllen ebenso wie Erfolgsstorys über die Notwendigkeit von PLM die Fachpresse. Das hier vorgestellte Vorgehensmodell soll den bekannten Negativfaktoren entgegenwirken, um die eigene PLMEinführung zu einer Erfolgsgeschichte werden zu lassen. Jedoch soll zunächst einmal auf ausgewählte Negativfaktoren eingegangen werden, um daraus die Elemente 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 entsteht eine Divergenz in der Ressourcenplanung. 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. Viel mehr noch tun sich Unternehmen mit Innovatoren solcher vorbeugenden Maßnahmen zur langfristigen Absicherung der Produktentwicklungen verbunden mit entsprechenden Investitionen, die sich schlecht rechnen lassen, sogar oft schwer, diese von den Entscheidungsträgern billigen zu lassen. Ein Ausgliedern von Ressourcen aus dem aktuellen Tagesgeschäft fällt der mittleren Führungsebene in der Regel sehr schwer, 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 schwer mit dem Zeithorizont einer PLM-Einführung in Einklang zu bringen. Die Übernahme der Verantwortung für die PLMEinführung ist im ersten Augenblick somit kein Thema, mit dem man sich profilieren kann. Um dem entgegen zu wirken, entzerrt unsere Lösung 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 werden. PLM wird nicht als ein Projekt sondern als eine im Unternehmen

40

4 Evolutionäres Vorgehensmodell

fest installierte Kompetenz gesehen. Wie schon in vorhergehenden Kapiteln erwähnt, ist PLM ein andauerndes lebendiges Vorgehen. Das hier beschriebene Vorgehensmodell ist ein Schema für den Umgang mit PLM, ein Meta-Vorgehehensmodell. 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 (Kapitel 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 (s. Abb. 4-1) ist ein Spiralmodell, in dessen Kern das PLM-Manifest steht (s. 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 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 ist (s. Abschnitt 4.1.1). Eine Definition dieser Begriffe folgt in den nächsten Abschnitten. Die Integration von PLM im Unternehmen wird auf Grund des thematischen und zeitlichen Umfangs in mehrere Projekte eingeteilt. Der PLM-Stab initialisiert 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 der 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 PLM-Stab -Vision PLM

1. PLM Readiness a. Bewertung/Zielsetzung

d 4.

41

1. 2. PLM Requirement Management b. Leistungsbeschreibung

PLMManifest

c

a 3. PLM Solution Design c. Pflichtenheft

2.

3.

4. PLM Implementation & Integration d. Umsetzung

b

1.

2.

Start eines TeilPLM-Unterprojekts projektiert nehmensbewervom PLM-Stab tung und Projektzielsetzung erstellt

3.

4.

Leistungsbeschreibung erstellt

Pflichtenheft erstellt

Umsetzung erfolgt, getestet und abgenommen

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 Abhängigkeiten der PLM-Aspekte untereinander ein, so dass parallele Aktivitäten sinnvoll sind oder auch einfach auf Grund des zeitlichen Aspekts. Zu bevorzugen ist dennoch in der Regel, 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 Vorleistungen, die das Unternehmen eingehen muss. So sollen alle Voraussetzungen für eine erfolgreiche PLM-Etablierung im Unternehmen geschaffen werden. 4.1.1

PLM-Stab

Mittelständische Unternehmen sollten dem Trend der Großunternehmen folgen und PLM als Kompetenz eines 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 empfiehlt es sich für KMU eine organisatorische Stelle vergleichbar mit einem Quali-

42

4 Evolutionäres Vorgehensmodell

tätsverantwortlichen einzurichten, die unabhängig vom operativen Tagesgeschäft ihren Aufgaben nachgehen kann. In einer Stab-Linienorganisation 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 PLMStab kein operatives Geschäft sondern befasst sich strategisch mit dem abteilungsübergreifenden Querschnittsthema PLM und übernimmt hierfür die Controlling-Aufgaben. 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 und eine vorausschauende Beobachtung der Marktentwicklungen und der Entwicklung unterstützender ITWerkzeuge. 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 eine reine 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 Nebentätigkeit. 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 im Einzelnen vom PLM-Stab akquirierten Projekten umgesetzt 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 zu achten. Insbesondere ist der PLM-Stab für die Konsistenz der dokumentierten Modelle verantwortlich (s. Abschnitt 4.2.1). Nicht zuletzt verantwortet der PLM-Stab die unternehmensinterne Motivation des Themas PLM, ein häufig unterschätztes Thema, auf das im Leitheft „Mitarbeiter für PLM motivieren“ (s. Abschnitt 5.13) näher eingegangen wird.

4.1 PLM als Paradigma im Unternehmen

4.1.2

43

PLM-Vision

Angelehnt an eine Unternehmensvision sollte ein Unternehmen auch eine PLM-Vision verfassen. Die PLM-Vision ist ein Hilfsmittel, ein Leuchtturm, der den eher ideal zu verstehenden Endzustand der PLM-Umsetzung beschreibt. Die PLM-Vision als allgemein verständlich formulierter Endzustand erlaubt es jedem Betroffenen, den Stand des PLM-Projektes mit seinem Fernziel zu vergleichen und es daran zu messen. Die PLM-Vision beschreibt die langfristigen Ziele verbal, die das Unternehmen mit PLM verfolgt. So wird das strategische Ziel, das 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 ein 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 die auch für das eigene Unternehmen von Vorteil sein können, rechtzeitig zu erkennen. Zu Beginn der Kompetenzinstallation 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, so dass die Vision mit den einzelnen Projekten mit lebt. 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, so dass ein hohes Abstraktionsniveau gefordert ist. So wird die PLM-Vision ständig in Frage gestellt und mit Erkenntnissen und Anregungen aus den Teilprojekten aktualisiert. Ferner ist auf Grund der Langjährigkeit 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 bleibenden Personaleinsatz eine größere Produktvielfalt auch in neuen Märkten anbieten zu können…“

44 4.1.3

4 Evolutionäres Vorgehensmodell Generisches PLM-Manifest

In diesem Leitwerk wird der Ansatz einer modellbasierten Dokumentation verfolgt. Das Unternehmen, die Produkte und die Prozesse sowie die ITSystemlandschaft werden in Modellen auf unterschiedlichen Ebenen beschrieben und verbal kommentiert. Das Ziel dieser Vorgehensweise ist, ein vollständiges formales Modell 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, in verschieden Detaillierungsebenen. Diese 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 Kapitel 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 Modellierungssoftware kann der Modellierungsprozess unterstützt und die Konsistenz der einzelnen Modelle gewährleistet werden. Daher ist der Einsatz von solchen Werkzeugen empfehlenswert. Jedoch kann nicht verallgemeinert gesagt werden, welche Modellierungsmethodik bzw. welches Werkzeug zu bevorzugen ist. Im Leitwerk finden bevorzugt die Modelle der UML Anwendung. Diese und weitere Modelle und Werkzeuge werden in den Abschnitten 6.9 und 6.10 vorgestellt. Die Modelle entwickeln sich im Laufe der Projekte weiter. Sie werden ständig auf Grund von Veränderungen im Unternehmen oder anderen Kriterien, die sich auf die Zielsetzung auswirken, nachgezogen und mit der Reife der Projekte detailliert. Für das Vorgehensmodell bedeutet dies, dass das PLM-Modell mit jedem Zyklus verfeinert wird. So ist stets auf eine ständige Aktualität zu achten. Die Modellierung soll in erster Linie der Konzeption dienen und keine nachgezogene Dokumentation sein. Modelliert wird neben dem Ist-Stand der Soll-Stand. Im Idealfall wird dementsprechend der Soll-Stand auf Dauer zum Ist-Stand. Zudem empfiehlt es sich unterschiedliche Modelle für unterschiedliche Ebenen im Hinblick auf die jeweilige Verwendung einzuführen. Angelehnt an die Informatik könnten das ein Fachkonzept, ein DV-Konzept und die Implementierung sein, wie es schon in Abschnitt 2.3 vorgestellt wurde. Diese Ebenen des Modells werden in den Phasen 2 – 4 erstellt. Nähere Informationen hierzu befinden sich in der Beschreibung der Phasen. Neben dem PLM-Modell des Unternehmens sollten alle weiteren relevanten Dokumente im Zusammenhang mit PLM zentral mit dem Modell verwaltet werden. So ergeben die Modelle zusammen mit weiteren Doku-

4.2 Phase „PLM-Readiness“

45

menten das PLM-Manifest. Hierzu zählen unter anderem alle Lasten- und Pflichtenhefte, alle Protokolle, Schulungsunterlagen etc. Da die Modellierung der Prozesse die Basis einer durchgängigen Prozessbeschreibung darstellt, ist zu prüfen, ob die Prozessmodelle nicht gleichzeitig als Basis für eine Zertifizierung nach DIN ISO 9000 ff. verwendet werden können, und so mit geringem Aufwand zu einem Qualitätsmanagement-Handbuch erweiterbar ist (VDI 2219).

4.2

Phase „PLM-Readiness“

Product Lifecycle Management bietet viele Möglichkeiten, die Produktentstehung durch effiziente Nutzung moderner Software-Werkzeuge zu optimieren. Ein Unternehmen, das sich motiviert durch positive Erfahrungen anderer Unternehmen oder auf Grund bekannter Brüche bei internen Abläufen mit PLM erstmalig auseinandersetzt, hat häufig noch keine oder nur vage Vorstellungen einer PLM-Lösung. Dieses Kapitel soll Unternehmen zur Konkretisierung der Anforderungen an PLM dienen bzw. beim Verifizieren der vagen Anforderungen helfen. Am Anfang jedes PLMProjektes sollte die heutige Situation bezüglich PLM im Unternehmen bewertet werden, um später aus dieser Bewertung Potentiale aufzeigen zu können. Verbunden mit einer Kosten-/Nutzenanalyse für dieses Potential wird eine Zielsetzung für das jeweilige Projekt formuliert. Dies ist die erste Phase ist im evolutionären Vorgehensmodel (s. Abb. 4-2) Hierfür bietet es sich an, auf gängige Bewertungsmethoden zurück zu greifen. Auf dem Markt befinden sich unterschiedliche Dienstleister, die eine solche Bewertung anbieten und Literatur zur Eigenbewertung. In diesem Anwenderhandbuch wird ein Tool zur Bewertung vorgestellt, das im Projekt PLM4KMU entwickelt wurde. Dieses Werkzeug erlaubt mit geringem Zeitaufwand schnell eine Aussage zur „PLM-Reife“ des Unternehmens. Daher ist sowohl eine vollständige aber auch eine teilweise Wiederholung der Bewertung nach einem gewissen zeitlichen Abstand möglich, um erzielte Verbesserungen bewerten zu können. Informationen zu diesem Thema sind über die Internetseite www.plm4kmu.de verfügbar. Sollen andere Bewertungsmethoden eingesetzt werden, ist dies gleichfalls möglich. Es sollte lediglich auf Übereinstimmung der wesentlichen Elemente geachtet werden.

46

4 Evolutionäres Vorgehensmodell

PLM-Stab -Vision PLM

d 4.

1. PLMManifest

c

a 2.

3. b

Abb. 4-2: PLM-Readiness 4.2.1

Maturity-Modell

Ziel des Maturity-Modells soll es sein, dass ein Unternehmen individuell unter Berücksichtigung der Unternehmenscharakteristik den eigenen Status bewerten, Nutzenpotentiale entdecken und notwendige Voraussetzungen prüfen kann. Hierzu wird für einzelne PLM-Aspekte eine zweistufige Reifegradbestimmung eingeführt, die eine ganzheitliche PLMBewertung zulässt. Ist-Werte geben Auskunft über den derzeitigen Status und entsprechende Soll-Werte zeigen einen zu erreichenden Zielwert auf. Der Sollwert ergibt sich in Abhängigkeit aus Unternehmensstruktur, den zugehörigen Prozessen und der Beschaffenheit der Produkte. Das Spannungsfeld zwischen den Ist- und den Soll-Werten verdeutlichen das Potential für das eine Unternehmen im Bereich PLM.

4.2 Phase „PLM-Readiness“

47

Die Zusammenhänge zwischen den einzelnen Thematiken in Kombination mit einer Kategorisierung von Unternehmen sollen es nicht nur Beratern, sondern auch und gerade Unternehmensangehörigen ermöglichen, eine Bewertung eines Unternehmens durchzuführen. Es ist nicht 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: • 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. • 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 sind. So ist eine absolute Bewertung eines Unternehmens oder gar ein Ranking mehrerer Unternehmen mit dem PLM-Maturity-Modell nicht möglich. Es soll lediglich den größtmöglichen Nutzen für die nächsten Schritte zur Verbesserung des PLM-Konzepts und -Anwendung individuell ermitteln. Die somit bestimmten möglichen Schritte 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 und vorhandene Nutzenpotentiale aufdecken. Zudem sind für manche PLM-Themen gewisse Voraussetzungen notwendig. Auch dies wird durch das Maturity-Modell überprüft.

48

4 Evolutionäres Vorgehensmodell

Das Ergebnis des Maturity-Modells ist ein Reifegrad-Ist-Zustand und ein Reifegrad-Bedeutungsgrad (Soll) für einzelne PLM-Thematiken. 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 derzeitigen 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/-Anwendung ermittelt werden. Das PLM-MaturityModell ist kein Referenzmodell für den „richtigen“ Einsatz von PLM, d. h. es macht keine Vorgaben wie und in welchem Umfang PLM eingesetzt 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 Maturity-Modell hilft 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 fälschlicherweise zu einer isolierten Betrachtung einzelner PLM-Aspekte führen. Bestehende Abhängigkeiten zwischen einzelnen PLM-Aspekten, wie es die Abb. 4-3 verdeutlicht, müssen beachtet werden. So sollte bei der Umsetzung einzelner PLM-Aspekte stets auf die Erfüllung vorausgesetzter Aspekte geprüft werden. Voraussetzung für alle Kategorien stellt ein funktionierendes Klassifizierungs- und Benennungssystem und ein valides Strukturmanagement dar. Darauf aufbauend ist zur konsistenten Verwaltung aller Dokumente ein Dokumentenmanagementsystem unabdingbar und damit auch Zugriffsregelungen und Sperren. Auf höherer Ebene befinden sich die Funktionen, die bereits eine semantische Verwaltung der entstehenden Dokumente 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 Erstellung und Änderung, Workflow-Management sowie das Statusmanagement.

4.2 Phase „PLM-Readiness“

Anwenderfunktion Prozessorientiert

Produktorientiert

49

Dienstfunktion Systemorientiert

Premium

Kommunikation, Notifizierung Archivierung

Viewing, Redlining

LifecyleManagement

Freigabemgnt.

Änderungsmgnt.

Datentransport (Schnittstellen)

Sichtenmanagement

Kollaborative Produktentwicklung Projektmanagement

Erweitert

Datentransformation

Konfigurationsmanagement

Versionen-/ Varianten-/ Alternativenmanagement

Applikationsspezifische Funktionen Toolintegration

Workflow-/ StatusPrüfProzessabläufe mgnt. mgnt.

Vaulting

Daten-/ Dokumentenmanagement

Basis

Zugriffsverwaltung

Systemadministration

Grundfunktion Klassifizierung und Benennung (SML)

Produktstrukturmanagement

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

Die höchste Kategorie stellt auf Prozessseite die Verbindung mehrer 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 in der Kategorie der Dienstfunktionen werden Mechanismen zum Datenaustausch verschiedener (Anwendungs-)Systeme implementiert. Dazu gehört neben der Kon-

50

4 Evolutionäres Vorgehensmodell

vertierung in Austauschformate der Datentransport zwischen diesen Systemen. Zu beinahe jedem PLM-Aspekt findet sich in Kapitel 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, wobei die Fragen der letztgenannten Phasen individuell auf Grund der Ergebnisse aus der Unternehmenseinordnung zusammengestellt werden. Die Fragen der jeweiligen Phasen der Befragung zeichnen sich durch einfach zu beantwortende Multiple-ChoiceFragen aus, die in ihrer Kombination indirekt Informationen zum Unternehmen und zum PLM-Stand abfragen. Dadurch soll ein voreingenommenes Beantworten der Fragen abgefangen werden.

PLM Maturity Modell

PLM Maturity Status

Fragenkatalog Funktionsblöcke

Produktstrukturierung

Klassifikation

Kriterien Funktionsblöcke Fragen

Produktstrukturierung

Fragen

Dokumentenmanagement

Dokumentenmanagement

Fragen

Klassifikation

Abhängigkeiten

Abb. 4-4: Maturity-Modell

Fragen

4.2 Phase „PLM-Readiness“

51

Anhand dieser Fragen werden die einzelnen Funktionsblöcke abgefragt und ein Reifegrad bestimmt, wie es schematisch die 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 untergliedert 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 der 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 schon eine solche Position im Unternehmen vorhanden ist. Zu Beginn des ersten Hauptprozesses ordnet der Durchführende zunächst die Charakteristik des Unternehmens anhand des ersten Teils des Fragebogens selbst oder mit Hilfe von Unternehmensangehörigen ein. 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.

52

4 Evolutionäres Vorgehensmodell

Start Checkliste Unternehemen klassifizieren Komplexitätseinordnung Relevante Kriterien ermitteln

Kriterienkatalog (angepasst)

Durchführender Ermitteln der Solllinie

Sollwerte Kontaktpersonen bestimmen

Mitarbeiter

Istwerte Interview der Mitarbeiter

Ermitteln der Potentiale

Manager

Zuordnung der Potentiale zu PLMFunktionsblöcken

Interpretation der Ergebnisse

Abb. 4-5: Prozess der Reifegradbestimmung

PLMPotentiale

4.2 Phase „PLM-Readiness“

53

Faktoren zur Ermittlung der Unternehmenscharakteristik sind: • • • • •

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) • Anzahl unterschiedlicher Disziplinen (Software, Elektrik/Elektronik) • 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 auf Grund 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 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 unvermeidbare Streubreite besitzen. Im letzten Hauptprozessschritt werden die Ergebnisse der vorigen Phasen aufbereitet und interpretiert. Hierzu werden die Kategorien auf klassische PLM Gebiete abgebildet und unterschieden nach Kern-PLM-Gebieten und 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

54

4 Evolutionäres Vorgehensmodell

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 eventuell für diese Potentiale Voraussetzungen auf Grund 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 viel versprechensten Potentialen sollte im nächsten Schritt eine Kosten-/Nutzenanalyse gemäß Abschnitt 6.8 durchgeführt werden. Zeigen dennoch mehrere Bereiche gleichwertige, wirtschaftliche Potentiale auf, sollte sich dennoch ein Unternehmen auf einen Bereich fixieren. Auf Grund dieser Untersuchungen kann nun die Zielsetzung für den jeweiligen Zyklus des Vorgehensmodells formuliert werden 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. Das PLM-Manifest und insbesondere die PLM-Vision als übergeordnetes Dokument sollen hier als Instrumente der Koordination dienen. Ansätze hierzu enthält das Leitheft „Systeme kommunizieren lassen“ (s. 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.

4.3 Phase „PLM-Requirement-Management”

Fragenkataloge

Daten und DokumentenmanagementKollaborative Produktentwicklung Workflowmanagement Applikationsspezifische Funktionen Konfigurationsmanagement Freigabe und Änderungsmanagement Zugriffsverwaltung Varianten und Alternativenmanagement Produktstrukturmanagement Projektmanagement

55

Größtes Nutzenpotential Daten- und DokumentenKriterien management nicht erfüllt Kriterien nicht erfüllt Produktstrukturmanagement

Produktklassifizierung und -benennung Kriterien erfüllt

Freigabe- und Änderungsmanagement Kriterien erfüllt

PLM-Funktionsblöcke

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

4.3

Phase „PLM-Requirement-Management”

Die Phase des PLM-Requirements wird mit dem Ziel durchgeführt, die Anforderungen an den jeweiligen PLM-Aspekt formal festzuhalten. Grundlage hierfür ist die Zielsetzung aus der PLM-Readiness-Phase und die Leithefte der jeweiligen PLM-Themen. Ausgehend von den formulierten Zielen der Phase 1 wird ein Lastenheft erstellt, das die Anforderungen der PLM-Zielsetzung unternehmensintern konkretisiert, zur Angebotseinholung (Ausschreibung) verwendet wird und später als Vertragsbestand dient. Das Lastenheft stellt in den ersten Spiraldurchläufen ein Lösungsund Tool-neutrales Dokument unter Berücksichtigung der unternehmenseigenen Randbedingungen und Ressourcen dar, das die Anforderungen des Unternehmens an ein Produkt aufzeigt. In späteren Zyklen müssen die schon beschlossenen oder sogar schon eingesetzten Tools zu diesen Randbedingungen gezählt werden. Das Lastenheft ist das unternehmenseigene Pendant zum Pflichtenheft, das jedoch im Gegensatz zum Lastenheft vom Systemlieferanten erstellt wird. Es beinhaltet die Gesamtheit der Forderungen des Auftragsgebers und beschreibt neben dem heutigen Stand auch zukünftige Ziele in Bezug

56

4 Evolutionäres Vorgehensmodell

auf technische, wirtschaftliche und organisatorische Erwartungen. Hierbei sind quantifizierbare und prüfbare Forderungen für die Erstellung eines Lastenhefts von Vorteil, können jedoch auch noch vom Systemlieferanten detailliert oder quantifiziert werden. Es ist darauf zu achten, dass das Lastenheft produktneutral geschrieben wird, das heißt, dass nicht ein Produkt die Anforderungen eines Unternehmens beeinflussen sollte. Dasselbe gilt für den Einbezug eines externen Dienstleisters. Das Hinzuziehen von externen Dienstleistern kann durchaus sinnvoll sein, um auf Erfahrungen dieser aufbauen zu können. Jedoch ist darauf zu achten, dass sie neutral sind und nicht von einem Systemlieferanten stammen. Weitere Informationen zum Thema Einbezug von externen Dienstleistern enthält das Leitheft „Externe Dienstleister einbinden“ (s. Abschnitt 5.12). 4.3.1

Analyse zur Leistungsbeschreibung

Um dem Ziel einer Leistungsbeschreibung näher zu kommen, sind die oben genannten Inhalte zu erstellen. Bevor hiermit angefangen wird, ist es durchaus sinnvoll nochmals zu prüfen, ob die Voraussetzungen, die in den jeweiligen Leitheften gefordert werden, für das entsprechende Thema erfüllt sind. Die Vorraussetzungen werden im ersten Unterkapitel jedes Leitheftes erörtert. Auch das schematische Übersichtbild in dem jeweiligen Kapitel verschafft einen schnellen Überblick über die Abhängigkeiten und Querbezüge der PLM-Aspekte. Dies ist unter Berücksichtigung der PLMVision notwendig, um widersprechende Anforderungen unterschiedlicher PLM-Aspekte rechtzeitig zu erkennen. Sind alle geforderten Vorraussetzungen abgesichert, ist mit der Beschreibung des heutigen Standes im Rahmen der PLM-Aspekte anzufangen, die laut Maturity-Modell untersucht werden sollen. Wie detailliert die Beschreibungen des Ist-Standes 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 und im Gegenzug mit neuen bzw. aktualisierten Manifest zu diesem Zeitpunkt ergänzt wird. Mit den Ist-Modellen wird der heutige Stand durchleuchtet werden. Dadurch fällt es leichter, die Gunst der Stunde zu nutzen und die bestehenden Prozesse zu restrukturieren. Dieses Reengineering stellt sich jedoch häufig sehr problematisch dar, weil die mit dem Reengineering beauftragten Mitarbeiter häufig keine ausreichende Kenntnis über die Möglichkeiten von PLM haben.

4.3 Phase „PLM-Requirement-Management”

57

Auch der Einbezug von Externen, nicht „Betriebsblinden“, zur Analyse und Optimierung kann sinnvoll sein. Es ist jedoch unbedingt darauf zu achten, dass intern im Unternehmen PLM-Wissen aufgebaut 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 vertiefen. 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, Mitarbeiter, die IT-Infrastruktur sowie feststehende IT-Tools und das immer unter Berücksichtigung des zeitlichen Horizonts. Die benötigten Ressourcen lassen sich in 2 verschiedenen Kategorien einteilen: • 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öglichkeiten aus unterschiedlichen Fachdisziplinen hervorgeht. Es muss eine IT-Infrastruktur aufgebaut werden. Lizenzen müssen erworben werden. Schulungen müssen finanziert werden. Störungen im betrieblichen Ablauf während der Einführung müssen berücksichtigt werden. Eventuell muss externe Dienstleistung finanziert werden. • Laufender Bedarf Zu den Betriebskosten zählen alle Kosten, die nach der Inbetriebnahme anfallen. Hierzu zählen Betriebskosten, Wartungskosten, Kosten für Verwaltung, Pflege und Backup. Konkrete Informationen zum Benötigten finden sich in der Regel in den letzten Kapiteln der Leithefte sofern das Leitheft über ein Kapitel zur Einführung verfügt. Werden dem aufgeführten Bedarf beider Kategorien, die Einsparung, die der jeweilige PLM-Aspekt bringen wird, gegenübergesellt, erhält man eine Wirtschaftlichkeitsbetrachtung. Um die Einsparungen zu ermitteln, werden alle Kosten, die ohne PLM anfallen würden, aufgeführt und den erwarteten Kosten mit PLM gegenübergestellt. Jedoch wird mit dieser Vorgehensweise jeder PLM-Aspekt einzeln betrachtet. Querbeziehungen zu anderen PLM-Aspekten und indirekter Nutzen bleiben unberücksichtigt. Stellt sich bei der Ressourcenplanung raus, dass nicht ausreichend Ressourcen verfügbar sind und ist dies nicht zu ändern, muss die Zielsetzung entsprechend an den Ressourcen ange-

58

4 Evolutionäres Vorgehensmodell

passt werden. Eine detaillierte Erläuterung zu einer Kosten-, Nutzenanalyse findet sich im Abschnitt 6.8 „Betriebwirtschaftliche PLM-Aspekte“. 4.3.3

Erstellung der Leistungsbeschreibung

Das Lastenheft ist Grundlage zur Projektvergabe 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 besprochen, wird der Projektpartner ein externes Unternehmen sein. Für das prinzipielle Vorgehen ist dies jedoch nicht von Relevanz. 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 formal mit Modellen beschrieben werden. Zu beschreiben sind alle Ergebnisse des PLM-RequirementManagements. Diese können in fünf Kategorien eingeteilt werden. Die Einteilung ist an die VDI 2219 angelehnt, die die Einführung eines PDMSystems beschreibt. Die VDI 2219 kategorisiert Anforderungen wie folgt: • • • • •

strategische Anforderungen, funktionsbezogene Anforderungen, technisch-organisatorische Anforderungen, mengenbezogene Anforderungen und 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 Sachmerkmalsleisten entsprechend der DIN 4000 zu nennen, aber auch Aspekte zur langfristigen Bindung an einen Systemlieferanten sind dieser Kategorie zuzuschreiben. Der Kern des Lastenhefts bilden die funktionsbezogene Anforderungen. Hier wird ein Großteil der Ergebnisse der Konzeptphase festgehalten. Das Motto, Modelle sagen mehr als 1000 Worte, gilt in dieser Kategorie wieder ganz besonders. Beschrieben werden alle Datenmodelle, Abläufe, Projektstrukturen und Prozesse. Zu den technisch-organisatorischen Anforderungen gehören allgemeine Anforderungen zur Anzahl erwarteter User, Lizenzen sowie beispielsweise Anforderungen an Antwortzeiten. Auch die Eingliederung der neuen Software in die Unternehmens-IT und vorgeschriebenen Hardwareplattformen und andere Rahmenanforderungen, wie beispielsweise die Infra-

4.4 Phase „PLM-Solution-Design“

59

struktur, eine bevorzugte Architektur (z.B. Client-Server-Architektur) oder schon im PLM-Manifest festgeschriebene Software 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 auch schon der gewünschte 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 das Lastenheft zur Angebotseinholung an verschiedene Lieferanten, die in Frage kommen, versendet werden. Auf Basis des Lastenheftes wird der Lieferant ein Angebot mit einem Pflichtenheft erstellen. Diese Dokumente sind alle dem PLM-Manifest zuzuführen, wobei das Lastenheft in der Regel vorwiegend der Ebene des Fachkonzepts zuzuschreiben ist, wohingegen das Pflichtenheft auch schon Lösungen beinhalten kann, die dem DV-Konzept zuzuordnen sind. 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“

Ziel dieser Phase ist die Abstimmung zwischen dem Unternehmen als Auftraggeber und einem Projektpartner, dem Auftragnehmer. Dies wird in den meisten Fällen ein Systemlieferant oder ein internes Team 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 (s. Leitheft „Externe Dienstleister einbinden“ Abschnitt 5.12). Das Unternehmen sollte sich auf Basis des Lastenheftes von mehreren potentiellen Projektpartnern Pflichtenhefte erstellen lassen, um auf Basis des Pflichtenheftes den zukünftigen Projektpartner zu bestimmen. Dieser Punkt entfällt, wenn gegebenenfalls eine Systementscheidung schon vorangegangen ist. Dies ist beispielsweise dann der Fall, wenn ein bestehendes System ausgebaut werden soll. Hier muss dann nur der entsprechende Systemlieferant das Pflichtenheft erstellen.

60 4.4.1

4 Evolutionäres Vorgehensmodell Anforderungen an das Pflichtenheft

Die Erstellung des Pflichtenhefts obliegt ausschließlich dem Auftragnehmer und ist die Antwort aufs Lastenheft. Es sollte Lösungen für alle Anforderungen aufzeigen. Das auftraggebende Unternehmen sollte jedoch klare Vorstellungen vom 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 in 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 erlangt 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. Dies ist üblich, weil umfangreiche Pflichtenhefte kostenpflichtig sein können. Anderenfalls kann es schnell dazu kommen, dass der Systemlieferant ausschließlich eigene standardisierte Pflichtenhefte auf Basis unzureichender Fragebögen erstellt. Solche Pflichtenhefte haben oft nicht viel mit der Ausschreibung gemeinsam. Individuelle Anforderungen, die jedes Unternehmen hat, bleiben unberücksichtigt. Das Pflichtenheft sollte hingegen folgende Kriterien erfüllen: • Beschreibung der Unternehmenscharakteristik Es sollte die Unternehmenscharakteristik beschrieben sein. Dies ist wichtig, um zu erkennen, wie der Systemlieferant das eigene Unternehmen sieht. • Ist-Zustand des geplanten Einsatzgebietes Der zukünftige Auftragnehmer sollte im Pflichtenheft schildern, wie er auf Basis seines Wissens das Unternehmen heute sieht. • Zielsetzung Im Weiteren sollte der Systemlieferant nochmals seine Auffassung der Zielsetzung ausformulieren. • Pflichtenheft 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“

61

• 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. • Sonstiges Sind mit diesen Punkten nicht alle Anforderungen aus dem Lastenheft beantwortet worden, ist dies noch unabhängig von der obigen Einteilung zu tun. Enthält das ins Auge gefasste System standardmäßig 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 ins Gesamtkonzept aufgenommen werden und gegebenenfalls auf Überschneidungen mit anderen PLM-Aspekten überprüft werden. 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 werde, dass es von unterschiedlichen Fachleuten geschrieben wird. Das verabschiedete Pflichtenheft ist Teil des DV-Konzepts und wird somit im PLM-Manifest verwaltet. 4.4.2

Lieferantenauswahl

Zur Lieferantenauswahl wird das Lastenheft an unterschiedliche Systemlieferanten verschickt und ein oben beschriebenes Pflichtenheft, eventuell aufgeteilt in mehrere Detaillierungsphasen, verlangt. Hierzu wird eine erste Vorauswahl von Systemlieferanten mit Hilfe der Systemevaluation (Abschnitt 6.7), Internetrecherche und Fachzeitschriften durch das Unternehmen durchgeführt. Dieser Punkt kann auch von erfahrenen Unternehmensberatern vollständig durchgeführt oder die Durchführung durch solche Experten unterstützt werden. Sollte ein Systemlieferant auf Grund von vorhergehenden Projekte schon vor ausgewählt sein, 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 wird vor ausgewählt. Die Prüfung der Pflichtenhefte kann wiederum mit Unterstützung eines Unternehmensberaters erfolgen. Dieser Lieferant wird zu einer Detaillierung des Pflich-

62

4 Evolutionäres Vorgehensmodell

tenheftes aufgefordert. Bei dieser Vorauswahl ist zu beachten, dass sich das Unternehmen in der Regel lange an den Systemlieferanten bindet und daher sollte das Unternehmensportfolio des zukünftigen Auftragnehmers mitberücksichtigt werden. Es müssen Fragen zur Zukunftsperspektive des Systemhauses geklärt sein. Beispielsweise sollte das Unternehmen groß genug sein, um Engpässe überstehen zu können. Ist ein Pflichtenheft zur Zufriedenheit des Auftraggebers erstellt, kann ein Vertragsabschluss vorgenommen werden. 4.4.3

Vertragsabschluss

Das Pflichtenheft enthält vom Auftraggeber verbindliche und gegengezeichnete Vorgaben und Beschreibung der Leistung, die der Systemanbieter erbringen will. 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 ist auf eine Vollständigkeit des Pflichtenheftes zu achten. An dieser Stelle sei nochmals an das Leitheft „Externe Dienstleister einbeziehen“ verwiesen (s. Abschnitt 5.12).

4.5

Phase „Implementation & Integration“

Mit dieser Phase wird eine Umsetzung im Unternehmen implementiert und in Betrieb genommen. Somit ist dies die kritische Phase des PLMVorgehensmodells. Diesem kann nur durch einer peniblen Durchführung der ersten Phasen entgegen gewirkt werden. Die Implementierung erfolgt strikt nach dem Pflichtenheft. Auf eine Einhaltung sollte das Unternehmen schon während der Phase achten. Sämtliche Abweichungen zum Pflichtenheft sind kostenpflichtig. Die Implementierungsphase lässt sich wiederum in fünf Teilschritte einteilen, die im Folgenden beschrieben sind. 4.5.1

Implementierung

Bei der Implementierung sind zwei Seiten zu unterscheiden. Liegt eine Systemeinführung an, setzt der Systemanbieter die Anforderungen des Auftraggebers um und passt die Schnittstellen an die Unternehmens-IT an. Dies erfolgt in der Regel nicht auf einer grünen Wiese sondern erfordert ein Hineinwachsen in die bestehenden Strukturen. Die Implementierungs-

4.5 Phase „Implementation & Integration“

63

aufgaben erfolgen üblicherweise extern. Soll ein Konzept verwirklicht werden, muss das Konzept des PLM-Aspekts im Unternehmen implementiert werden. Handelt es sich beispielsweise um einen Eingriff in bestehende Prozessabläufe und in die Arbeitsweise, können sie den Betriebsrat betreffen. Weitere Maßnahmen zur Implementierung sind die rechtzeitige Information und Schulung der Mitarbeiter. Ein weiteres Thema der Implementierung ist die Übernahme von Altdaten (Migrieren) mit den Fragen, welche Daten migriert und wie sie übernommen werden sollen. 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 Daten beschränken, deren Wahrscheinlichkeit der Wiederverwendung hoch einzustufen ist. Erfahrungswerte liegen bei ca. 15-20% der Altdaten. Diese Problematik wird noch einmal im Leitheft „Dokumente sicher verfügbar machen“ aufgegriffen (s. Abschnitt 5.3). Die Implementierung ist wiederum genau zu dokumentieren. Es ist nicht damit getan, dass der Quellcode unkommentiert hinterlegt wird. Gerade für die Dokumentation der Implementierung bietet die Softwareentwicklung unterschiedliche Modelle an. Diese fließen dann in die Implementierungsebene des PLM-Manifests ein. 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. Unterschieden werden unterschiedliche Stufen des Customizing: • administrative Ebene • logische Ebene • 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, Sachmerkmalleiste, Regeln, Nummernlogik etc. angelegt werden können. Hierfür sollte die Software nach Möglichkeit grafische Werkzeuge bereitstellen. Eine andere Möglichkeit sind Scriptsprachen. Sie sind nicht so anwenderfreundlich, aber durchaus üblich.

64

4 Evolutionäres Vorgehensmodell

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 den Quellcode der Software einher. Dies sollte weitgehend vermieden werden. Wünschenswerter sind Systeme, die von Haus aus ausgeprägtes Customizing auf der logischen Ebene vorsehen, so dass ein ausgeprägtes Customizing systemgestützt erfolgen kann. Dies geschieht in der Regel mit eigenen Skriptsprachen. Der Grund für diese Forderung liegt in der verminderten Releasefähigkeit von Systemen, die auf dieser Ebene customized werden. Hinzu kommt, dass ein Customizing auf dieser Ebene sehr teuer ist. Wichtig ist hier wieder die Frage, was sollte das Unternehmen selbst machen können und was wird extern vergeben. Bei einer externen Vergabe besteht immer das Risiko, dass nachträgliche Änderungen nur durch Fremdaufträge durchgeführt werden können und dies ist in Anbetracht eines lebenden Unternehmens mit häufigeren Änderungen nicht wünschenswert. Empfehlenswert ist, dass zumindest die administrative und logische Ebene durch das Unternehmen customized werden können. Entsprechendes Know-how muss dafür aufgebaut werden. Nur die Erstanpassung sollte zusammen mit dem Softwarehaus erfolgen. Eine entsprechende Dokumentation ist wiederum erforderlich. 4.5.3

Test

Ist die Implementierung und das Customizing abgeschlossen folgt eine umfangreiche Testphase im Unternehmen. Diese Phase ist das effektivste Mittel um späteren Beanstandungen und Todzeiten vorzubeugen. Beanstandungen nach der Abnahme sind wesentlich schwieriger durchzusetzen. Zuvor ist zudem auf umfangreiche Systemtests seitens des Systemhauses zu bestehen. Für die Testphase empfiehlt es sich zunächst eine eigene Testumgebung einzurichten, um den laufenden Betrieb nicht unnötig zu stören. Später sollte die Testphase jedoch 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, Fehlereingaben etc. Ausgedehnt auf das gesamte Unternehmen wird schließlich noch die Belastung des Systems getestet und das System einem Langzeittest unterzogen.

4.5 Phase „Implementation & Integration“ 4.5.4

65

Inbetriebnahme

Der Testphase folgt die Inbetriebnahme. Mit der Inbetriebnahme werden die bisherigen Systeme und die bisherige Arbeitsweise mit einer vereinbarten Übergangszeit abgelöst. Diese Übergangszeit dient zugleich als erweiterte Testphase. Auch die Übergangszeit kann in verschiedenen Phasen erfolgen. Gibt es besonders engagierte und dem neuen Konzept aufgeschlossene Mitarbeiter, sollte bei diesen mit der Umsetzung in Form einer Pilotanwendung begonnen werden. 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. Es empfiehlt sich die endgültige Abnahme erst hinter dieser Übergangszeit durchzuführen. Mit Ende der Übergangszeit werden alle alten Systeme, die im Rahmen des neuen PLMs keine Anwendung finden außer Betrieb genommen bzw. zumindest gesperrt. Denn nur so wird eine konsequente Umstellung auf ein neues System erreicht. Mit der Inbetriebnahme sollten weitere Mitarbeiterschulungen durchgeführt werden und die Kommunikation nicht abreißen. 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, so dass ein Fortschrittsprotokoll für das ganze Projekt entsteht. Auch findet nun nochmals explizit ein Abgleich bzw. eine Erweiterung der PLM-Vision statt. Hierzu bietet eventuell das Maturity-Modell das entsprechende Werkzeug. Das Feedback der Mitarbeiter ist an dieser Stelle nicht zu unterschätzen. Genügend PLM-Projekte, auch von Großunternehmen, sind schon an der fehlenden Akzeptanz gescheitert.

5 Leithefte zu PLM-Aspekten

Produktstruktur

Klassifikation

Sichtenkonzept

.........

Abb. 5-1: Leithefte

Dieses Kapitel beinhaltet einzelne Leithefte, in den die Grundlegenden PLM-Aspekte diskutiert werden (s. Abb. 5-1). Sie sind bei Bedarf an den entsprechenden Punkten im Ablauf des evolutionären Vorgehensmodells einzubeziehen. Die Orientierung innerhalb der Leithefte wird durch einen vereinheitlichen Aufbau vereinfacht. Jedes Leitheft beginnt mit einer einseitigen Zusammenfassung, die gebündelt den Inhalt des jeweiligen Themas motiviert. Es soll zugleich für unternehmensinterne Präsentationen als Management-Abstract dienen. Dem Abstract folgt eine Einordnung in das gesamte PLM-Umfeld. Dieser Einordnung sind Abhängigkeiten zwischen den einzelnen Thematiken und Voraussetzungen für die jeweilige Thematik zu entnehmen. Hierauf folgt der Kern des Leitheftes nach Bedarf aufgeteilt in weitere Unterkapitel. Viele, der vorgestellten Themen stehen nicht nur im PLMKontext, daher werden im folgenden Unterkapitel der Bezug zum PLM bei mittelständischen Unternehmen hergestellt. In den nächsten Abschnitten wird nun ein allgemeiner Überblick über die Thematik und PLMspezifische Hinweise gegeben. Abgeschlossen wird der inhaltliche Teil mit Hinweisen zur Einführung des Themas. Abschließend werden Beispiele, Arbeitsmaterialien, Normen und Standards, Checklisten und weiterführende Literatur zur Verfügung gestellt.

68

5.1

5 Leithefte zu PLM-Aspekten

Evolution der Produkte organisieren

Configmgnt. (engl.) Æ Sichtenmgnt. Æ Dokumentenmgnt. Ein Produkt ist in der Regel kein starres Gebilde, sondern es ist während seines Produktlebenszyklus Änderungen unterworfen und es muss schnell und flexibel an die Bedürfnisse des Marktes oder von Kunden anpassbar sein. Entsprechend diesen Anforderungen werden deshalb viele Produkte nicht nur in einer Variante, sondern in mehreren Varianten angeboten, zudem wird einem Kunden zunehmend die Möglichkeit geboten, ein Produkt speziell für seine Anforderungen zu konfigurieren. Diese Varianten des Produktes besitzen ähnliche Strukturen, die sich nur in einigen Bauteilen unterscheiden. Je mehr unterschiedliche Varianten eines Produktes vorhanden sind und je individueller ein Produkt an die Anforderungen des Nutzers angepasst wird, desto aufwändiger ist die Verwaltung der Informationen über die Varianten des Produkts. Hinzu kommt, dass Bauteile oder Baugruppen eines Produkts während seiner Zeit im Markt geändert werden, um Fehler zu beheben oder das Produkt zu verbessern. Die Nachverfolgung, welche Einzelteilen zu einem bestimmten Zeitpunkt in einem Produkt verbaut wurden, stellt eine weitere Aufgabe bei der Verwaltung der Produktinformationen dar. Die Aufgabe der Verwaltung von Versionen, Varianten und Konfigurationen eines Produktes wird mit Hilfe des Variantenmanagements und des Konfigurationsmanagements gelöst. 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 und stellt so eine Transparenz der Informationen her.

5.1 Evolution der Produkte organisieren 5.1.1

69

Konfigurationsmanagement

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

Anwenderfunktion Prozessorientiert

Produktorientiert

Dienstfunktion Systemorientiert

Premium

Kommunikation, Notifizierung Archivierung

Viewing, Redlining

LifecyleManagement

Freigabemgnt.

Änderungsmgnt.

Datentransport (Schnittstellen)

Sichtenmanagement

Kollaborative Produktentwicklung Projektmanagement

Erweitert

Datentransformation

Konfigurationsmanagement

Versionen-/ Varianten-/ Alternativenmanagement

Applikationsspezifische Funktionen Toolintegration

Workflow-/ StatusPrüfProzessabläufe mgnt. mgnt.

Vaulting

Daten-/ Dokumentenmanagement

Basis

Zugriffsverwaltung

Systemadministration

Grundfunktion Klassifizierung und Benennung (SML)

Produktstrukturmanagement

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

70 5.1.2

5 Leithefte zu PLM-Aspekten Versionen- und Variantenmanagement

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 Merkmale charakterisiert, die mit einem Wert belegt sind. Die Varianten lassen sich nach dem Grund der Entstehung kategorisieren: • Kundenvarianten, d. h. Varianten die vom Kunden gewählt bzw. auf dem Markt alternativ angeboten werden (z. B. Modellvarianten bei Fahrzeugen) • 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) • Mengen-Varianten, d. h. in Abhängigkeit von bestimmten Parametern kann sich auch die Menge eines Teils oder einer Baugruppen (Vorkommensfaktor) in der Struktur ändern. Ebenso lassen sich Varianten nach den Unterschieden in ihrer Produktstruktur unterscheiden (Martin Eigner u. Ralph 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 Komponenten aus denen eine Variantenstruktur aufgebaut wird, lassen sich dabei wie folgt beschreiben: • Muss-Komponenten, d. h. alternative Teile und Baugruppen, von denen immer eine Alternative gewählt werden muss • Kann-Komponenten, d. h. sog. Optionsbaugruppen, die in der Struktur ausgewählt werden können • Festkomponenten, d. h. Teile und Baugruppen, die immer in allen Variantenstrukturen vorkommen und damit festgeschrieben sind. An einer Stelle in der Produktstruktur können mehrere Ausführungen einer Produktkomponente einsetzbar sein. Ein Konzept zur Umsetzung, auf das wir uns an dieser Stelle beschränken wollen, sieht den Einsatz

5.1 Evolution der Produkte organisieren

71

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 spricht man, 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. Im Zuge der Verwaltung von Varianten lassen sich die Abhängigkeiten zwischen den Bauteilen der Varianten eines Produktes definieren und verwalten. 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 erzeugen 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 obigen Beispiel (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. Die einzelnen Bauteile einer Variantenausprägung stehen miteinander oft in einem Zusammenhang. Integrationssysteme können solche 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.

72

5 Leithefte zu PLM-Aspekten auftragsbezogene Ausprägung

P1 B2

B1 B1

T1

T2

V1

T1

T3

B4

T3

T6

T5

T4

B5

T7

T4

T8

T4

Legende: P1 Produkt

Tn Bauteil

Tn optionales Teil

Vn

Bn

Baugruppe

Variantenplatzhalter

Abb. 5-3: Struktur einer Produktvariante 5.1.3

Versionierung von Produkten

Oft werden Produktausführungen in der Umgangssprache 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. 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. 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 (s. Abb. 5-4) (Schichtel 2002): • Revisionierung: Versionen in sequenzieller Folge • Hierarchische Versionierung

5.1 Evolution der Produkte organisieren

Version 1

Version 2 25. Sept.

73

Version 3 10. Okt.

03. Nov.

Revisionierung

V1

V2

V 1.1

V3

V 2.1

V 1.2 V 1.3

V 3.1

V 2.2 V 2.3

V 3.2 V 3.3

Historische Versionierung Abb. 5-4: Revisionierung und historische 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 so genannten Zwischenversionen festgehalten, während umfangreichere Änderungen als Hauptversionen, so genannten „Major Releases“, versioniert werden. Man spricht auch oft von offenen und geschlossenen Versionen, um besser zwischen solchen Versionen zu unterscheiden, an denen noch gearbeitet wird (offene Versionen) und solchen, die nicht mehr verändert werden bzw. werden sollen (geschlossene Versionen). Die Neuanlage einer Version verlangt das Schließen der offenen Vorgängerversion.

74

5 Leithefte zu PLM-Aspekten

5.1.4

Konfigurationsmanagement als zentrale Funktion

Konfigurationsmanagement ist ein Verfahren zur Herbeiführung und ständiger Sicherstellung der Übereinstimmung der Leistungs-, Funktionsund 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 Produktlebenszyklus (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 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. P1 Version 2

P1 Version 1

Auftragsspezifische Konfiguration

T1

B3

T1 Version 1

B4

T3

T4

T7

T6

T1

T4

B3

T1 Version 2

B4

T3

T4

T7

P1 Version 1

T1 Version 1

B3

T1

T3

T4

Variantenstruktur

T6

T4

T4

P1 Version 2

V1

T8

T1 Version 2

B3

T1

B5

B4

T7

T6

T3

T4

Historische Konfiguration

Abb. 5-5: Konfiguration eines Produktes

T4

T6

V1

B5

B4

T7

T4

T8

T4

5.1 Evolution der Produkte organisieren

75

Die Konfiguration eines Produktes beschreibt die zu einem bestimmten Zeitpunkt oder für einen bestimmten Auftrag gültige Struktur des Produktes anhand der zu diesem Zeitpunkt gültigen Versionen der jeweiligen Einzelteile. Die Protokollierung der Änderungen am Produkt und den daraus entstehenden unterschiedlichen Versionen wird auch als Historie (engl. history) eines Produktes bezeichnet, die somit den zeitlichen Verlauf der Konfiguration berücksichtigt (s. Abb. 5-5). Ein weiteres Ziel des Konfigurationsmanagements ist, dass jeder am Projekt Beteiligte zu jeder Zeit des Produktlebenszyklus die richtige und zutreffende Dokumentation verwendet. Methoden des Konfigurationsmanagement sind nach DIN ISO 10007: • Konfigurationsidentifizierung Festlegung der Produktstruktur, Auswahl von Konfigurationseinheiten (KE), Dokumentation der physischen und funktionellen Merkmale einschließlich der Schnittstellen und späterer Änderungen • Konfigurationsüberwachung Überwachung von Änderungen an einer Konfigurationseinheit, nachdem erstmals die Konfigurationsdokumente formell erstellt wurden • Konfigurationsbuchführung die formalisierte Dokumentation und Berichterstattung bezüglich der geltenden Konfigurationsdokumente, des Standes laufender Änderungsanträge und des Durchführungsstandes der genehmigten Änderungen • Konfigurationsauditierung formale Prüfung des Ausführungsstandes einer Konfigurationseinheit auf Übereinstimmung mit ihren geltenden Konfigurationsdokumenten 5.1.5

Umsetzung von Konfigurationsmanagement

Die wesentliche Voraussetzung bei der Umsetzung des Konfigurationsmanagements ist die Definition der Produktstrukturen. Das heißt, dass die 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. Anhand solcher Produktstrukturen können 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. Zur Unterstützung der Identifikation von Gleichteilen kann die Durchführung der Klassifikation der im Unternehmen vorhandenen Bauteile hilfreich sein.

76

5 Leithefte zu PLM-Aspekten

Als weiterer Schritt können die Abhängigkeiten zwischen Bauteilen einer Variantenausprägung festgelegt werden. Darauf aufbauend lässt sich ein entsprechendes Regelwerk definieren, um diese Abhängigkeiten abzubilden. Mit Hilfe dieser Regeln wird die Bildung und Prüfung der Konfiguration einer Variantenausprägung beschleunigt und mit Softwareunterstützung eventuell sogar automatisiert. 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 noch Gegenstand der Forschung. Ein erster Lösungsansatz besteht jedoch darin, die Softwarekomponente einer mechatronischen Baugruppe als „black box“ unter einer Artikelnummer als Bauteil dieser mechatronischen Baugruppe in einem PDM-System oder einem vergleichbaren IT-System zu verwalten und zu versionieren. Die Konfiguration der einzelnen Softwaremodule kann in so einem System auf diese Weise nicht erfasst werden und muss getrennt beispielsweise im Software Configuration Management verwaltet werden. Weiterführende Literatur

• Josef Schöttner: Produktdatenmanagement in der Fertigungsindustrie, Prinzip – Konzepte – Strategien; Fachbuchverlag Leipzig, 1999 • Martin Eigner, Ralph Stelzer: Produktdatenmanagement-Systeme, Ein Leitfaden für Product Development und Life Cycle Management; Springer-Verlag, 2001 • Markus Schichtel: Produktdatenmodellierung in der Praxis; Fachbuchverlag Leipzig, 2002

5.1 Evolution der Produkte organisieren

77

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

78

5.2

5 Leithefte zu PLM-Aspekten

Produkte kontextabhängig darstellen

Views (engl.) Æ Daten- und Dokumentenmgnt Æ Konfigurationsmgnt. Im vorherigen Leitheft wird über Produktstrukturen gesprochen. Jedoch bleibt offen, nach welchen Gesichtspunkten Produkte strukturiert werden sollen. Je nach Hintergrund des Strukturerstellers wird die Struktur unterschiedlich ausfallen. Es ist generell nicht möglich zu sagen, welche Struktur die richtige ist. Anforderungen an eine Produktstruktur könnten sich abhängig von Prozessphasen verändern. So hat ein Konstrukteur ein funktions- oder systemorientiertes Verständnis einer Produktstruktur oder ein Monteur eine zusammenbauabhängige Vorstellung des Produktes. Ebenso wird eine Struktur aufgrund der technologischen Herkunft unterschiedlich umgesetzt sein. Auch unterschiedliche Erzeugersysteme können Strukturierungsmodelle hinterlegt sein, die im PLM abgeglichen werden müssen. Werden Komponenten von Zulieferern entwickelt bzw. verbaut und sollen die entsprechenden Daten mit in das PLM aufgenommen werden, verhält es sich entsprechend. Folglich sind unterschiedliche Prinzipien der Strukturierung denkbar. Die Produktstruktur ist somit kontextabhängig, ein Sachverhalt, dem auch schon in der konventionellen Produktentwicklung Rechnung getragen wurde. Das analoge Konzept hierzu ist der Einsatz unterschiedlicher Stücklisten. Da im PLM die Stückliste nur noch eine Ausleitung aus der Produktstruktur darstellen soll, 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, so dass mehrere Produktstrukturen nach Bedarf 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.

5.2 Produkte kontextabhängig darstellen 5.2.1

79

Sichtenmanagement

Das Sichtenmanagement baut auf das Daten- und Dokumentenmanagement auf (s. Abb. 5-6). Zudem besteht ein Querbezug zum Konfigurationsmanagement. Das Sichtenmanagement selbst wird für keine weiteren Funktionsbausteine benötigt.

Anwenderfunktion Prozessorientiert

Produktorientiert

Dienstfunktion Systemorientiert

Premium

Kommunikation, Notifizierung Archivierung

Viewing, Redlining

LifecyleManagement

Freigabemgnt.

Änderungsmgnt.

Datentransport (Schnittstellen)

Sichtenmanagement

Kollaborative Produktentwicklung Projektmanagement

Erweitert

Datentransformation

Konfigurationsmanagement

Versionen-/ Varianten-/ Alternativenmanagement

Applikationsspezifische Funktionen Toolintegration

Workflow-/ StatusPrüfProzessabläufe mgnt. mgnt.

Vaulting

Daten-/ Dokumentenmanagement

Basis

Zugriffsverwaltung

Systemadministration

Grundfunktion Klassifizierung und Benennung (SML)

Produktstrukturmanagement

Abb. 5-6: Sichtenmanagement im PLM-Umfeld

80

5 Leithefte zu PLM-Aspekten

5.2.2

Strukturierungsprinzipien des Sichtenmanagements

Eine Sicht beschreibt jeweils einen kontextbezogenen Zusammenbau eines Produktes, die eine zielgerichtete Arbeitsweise unterstützt. Gängige Strukturierungsprinzipien sind: • • • • •

Produktphasenbezogen Technologieabhängig System-/funktionsorientiert Ortsbezogen Erzeugersystem- oder lieferantenabhängig

Typischerweise werden in allen Sichten dieselben Elemente verbaut. Baugruppen, die in der Regel Strukturierungselmente 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.

Produkt

1

2

3

4

5

6

Sicht A

Sicht B

Produkt A 1

2

A

B C

4

Produkt

5

3 6

Abb. 5-7: Sichten auf ein Produkt

1

2

6 3

D 4

5

5.2 Produkte kontextabhängig darstellen 5.2.3

81

Produktphasenbezogene Sichten

Der klassische Ansatz von Produktsichten sieht eine produktphasenbezogene Einteilung der Sichten vor. Mit jedem Phasenwechsel eines Produktes im Produktlebenszyklus ändern sich die Zuständigkeiten und somit auch die Sichtweise auf ein Produkt. • Wird eine erste Struktur schon während der Angebotsphase erstellt, wird diese funktional geprägt sein (as bid). • In der Entwicklung herrscht eine systemorientierte Denkweise vor (as developed). • Die Konstruktion kann eine detailliertere Sichtweise auf das Produkt haben (as designed). • Die Fertigung strukturiert ein Produkt eventuell anhand von Fertigungsprozessen oder Maschinenbelegungen. (as planned) • Die Montage wird auf Grund der Zusammenbaureihenfolge strukturieren (as built). • Gerade bei großen Produkten wird der Vertrieb eine Möglichkeit fordern, die Produkte anhand von Verpackungseinheiten zu strukturieren (as shipped). Selbstverständlich sind auch 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 auch schon heute verwendet werden. Dies könnte beispielsweise eine abweichende Fertigungsstückliste sein, die nun automatisch aus einer speziellen Fertigungs-Sicht der Produktstruktur generiert wird. 5.2.4

Technologieabhängige Sichten

Der Umgang mit unterschiedlichen Technologien vereint in einem integrierten Produktmodell ist weiterhin ein Thema der Forschung. Ein möglicher Ansatz, dem derzeit nachgegangen wird, sieht die Verwendung des Sichtenmanagements vor. Zu jeder Technologie wird eine eigene Sicht geschaffen, in der technologiespezifische Elemente verbaut werden. Technologieübergreifende Elemente sind in mehreren Sichten integriert. 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.

82

5 Leithefte zu PLM-Aspekten

Produkt

Mechaniksicht

Elektriksicht

Abb. 5-8: Technologieabhängige Sichten

Der Vorteil dieser Vorgehensweise liegt in der Verwendung der Standardfunktion des Sichtenmanagements einer Standardsoftware. Die Umsetzung ist nun wieder ein rein konzeptionelles Problem. Gerade wenn zusätzliche phasenbezogene Sichten verwendet werden sollen, multipliziert sich die Anzahl an Sichten rasch. 5.2.5

Einführung eines Sichtenmanagements

Wiederum liegt der Kern der Herausforderung, ein effizientes Sichtenmanagement einzuführen, nicht in der technischen Unsetzung sondern im konzeptionellen Ansatz. Wie im vorherigen Abschnitt erläutert, wird das Thema von den meisten auf dem Markt befindlichen Standard-Systemen abgedeckt. Zunächst sollten sinnvolle Sichten identifiziert und validiert werden. Die Anzahl der verwendeten Sichten wirkt sich auf die Beherrschbarkeit der Sichten aus. Zu viele Sichten können zu Dateninkonsistenzen und zu Intransparenz der Prozesse führen. Dem entstehenden Verwaltungsaufwand kann durch definierten Prozessen entgegen gewirkt werden, die sich in manchen Fällen sogar mit automatisieren lassen.

5.2 Produkte kontextabhängig darstellen

83

Voraussetzung hierfür sind Algorithmen, die der Überführung zwischen den Sichten hinterlegt sind. Ferner sollte eine Verantwortung für die Administration der Sichten benannt werden. Dieser allein obliegt das Einführen neuer Sichten, die immer mit einer neuen Prozessdefinition einhergehen sollte. Wie schon in Kapitel 3 angedeutet, dient wiederum die Modellierung der Produktstruktur als Werkzeug zur Konzepterstellung. Dementsprechend sind die Modelle in das Manifest aufzunehmen.

84

5.3

5 Leithefte zu PLM-Aspekten

Dokumente sicher verfügbar machen

Æ KlassifizierungÆ Änderungsmanagement

Das Dokumentenmanagement stellt den Teil des Product Lifecycle Management dar, der der Verwaltung aller Unterlagen dient, die im Verlauf der Lebensdauer eines Produktes entstehen oder verwendet werden. Grundlegendes Konzept des Dokumentenmanagements ist es dabei eine Verknüpfung zwischen den Bauteilen und Baugruppen eines Produktes und der zugehörigen Dokumente herzustellen. Bis heute hat sich in Unternehmen ein grundlegender Wechsel von der manuellen Bearbeitung von Dokumenten hin zur Nutzung von Computern für die Erstellung und den Austausch von Informationen vollzogen, 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 (Metadaten) verwalten, 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: • effizientes Ablegen und Wiederfinden von Dokumenten • schnelle und direkte Weitergabe von Informationen und deren Änderungen • Zugriff auf Wissen aller Art von existierenden Produkten und aus früheren Projekten • Verbesserung der bereichsübergreifenden Zusammenarbeit im Engineering. Das Dokumentenmanagement stellt somit einen zentralen Bestandteil für die kontinuierliche, effiziente Informationsverwaltung im Product Lifecycle Management dar.

5.3 Dokumente sicher verfügbar machen 5.3.1

85

Dokumentenmanagement

Das Dokumentenmanagement ist einer der zentralen und grundlegenden PLM-Aspekte, da seine Aufgabe in der Verwaltung und Organisation der produktbeschreibenden Informationen besteht (s. Abb. 5-9).

Anwenderfunktion Prozessorientiert

Produktorientiert

Dienstfunktion Systemorientiert

Premium

Kommunikation, Notifizierung Archivierung

Viewing, Redlining

LifecyleManagement

Freigabemgnt.

Änderungsmgnt.

Datentransport (Schnittstellen)

Sichtenmanagement

Kollaborative Produktentwicklung Projektmanagement

Erweitert

Datentransformation

Konfigurationsmanagement

Versionen-/ Varianten-/ Alternativenmanagement

Applikationsspezifische Funktionen Toolintegration

Workflow-/ StatusPrüfProzessabläufe mgnt. mgnt.

Vaulting

Daten-/ Dokumentenmanagement

Basis

Zugriffsverwaltung

Systemadministration

Grundfunktion Klassifizierung und Benennung (SML)

Produktstrukturmanagement

Abb. 5-9: Dokumentenmanagement im PLM-Umfeld

86 5.3.2

5 Leithefte zu PLM-Aspekten Typen von Dokumenten

Das Dokumentenmanagement ist eines der Basiselemente des Product Lifecycle Management. Es dient dazu, die Dokumente so zu organisieren, dass das richtige Dokument zur richtigen Zeit in der richtigen Qualität am richtigen Ort für authentifizierte Personen verfügbar ist. „Ein Dokument ist eine festgelegte strukturierte Menge an Informationen, die als Einheit verwaltet werden und zwischen Anwendern und Systemen ausgetauscht werden“ (DIN EN 82045). Diese Informationen können entweder auf Papier oder digital in Form einer Datei abgebildet sein. Produktinformationen lassen sich in technische, kommerzielle und Qualitätsinformationen unterteilen (s. Abb. 5-10). 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 beispielsweise Normen oder Richtlinien.

Produktdokumentation

Technische Informationen

Kommerzielle Informationen

Qualitätsinformationen

Primär - technische Zeichnungen - CAD-Modelle - Produktspezifikationen - Lasten- und Pflichtenhefte

- Kundenanfragen - Gutachten - Abnahmeprotokolle

- Qualitätshandbücher - Prüfberichte

Sekundär - Prüf- und Arbeitspläne - Einrichtblätter - NC-Modelle - Werkzeugzeichnungen

Tertiär - Bedienungshandbücher - Ersatzteilkataloge - Wartungs- und Betriebsanweisungen - Recyclingberichte

Produktneutrale Informationen

- Normen - Richtlinien - Formulare - Vordrucke

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

5.3 Dokumente sicher verfügbar machen 5.3.3

87

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. • 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. • Die Versionierung und Statuswechsel von Dokumenten hängen eng mit den Abläufen im Unternehmen zusammen. Es muss festgelegt werden, welche Status ein Dokument durchläuft und wann ein Status gewechselt wird. Dies wird in so genannten Statusdiagrammen darstellt (Abb. 5-11). neu

in Bearbeitung

Zeichnung freigeben

CAD-Modell freigeben

Änderungsauftrag prüfen genehmigt

freigeben

Zeichnung sperren

Ersetzbarkeit prüfen

Änderung stornieren

in Ausführung gesperrt Zeichnung prüfen

Zeichnung freigeben

archiviert

storniert

Zeichnung freigeben

erledigt

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

88 5.3.4

5 Leithefte zu PLM-Aspekten Strukturierung von Dokumenten

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 werden und Beziehungen zwischen Dokumenten abgebildet werden. Dokumentenstammdaten

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 in diesem Fall als Dokumentenstammdaten oder Metadaten bezeichnet.

Dokumentenstammsatz Meta-Daten charakterisieren die Datei

Identifizierende Attribute Dokumentennummer (ID) Blattnummer Änderungsindex Versionsnummer

Beschreibende Attribute Dokumententyp Benennung Status, Reifegrad Ersteller, Erstelldatum

Sonstige Attribute Hängen vom Dokumententyp ab z. B. Einbaupositionen bei CAD-Daten

Abb. 5-12: Dokumentenstammsatz mit Beispielen von Metadaten

5.3 Dokumente sicher verfügbar machen Einzelnes Dokument Zeichnung (Dokument)

89

Zusammengesetztes Dokument

Metadaten

Prüfbericht (Dokument)

Metadaten fasst zusammen

Metadaten sind einem Dokument zugeordnet

Prüftext (Dokument)

Messwerte (Dokument)

Dokumentensatz

Sammeldokument optional Wartungskit (Dokument)

Metadaten

Metadaten

Metadaten

Metadaten

Einbauanleitung (Dokument)

Zeichnung (Dokument)

Zeichnung (Dokument)

Stückliste (Dokumentensatz)

Metadaten

Metadaten

Metadaten

Bauteilmodell (Dokument)

Bauteilmodell (Dokument)

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

Die in einem Dokumentenstammsatz enthaltenen Attribute können in identifizierende Attribute und beschreibende Attribute unterteilt werden (s. 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.

90

5 Leithefte zu PLM-Aspekten

Anwendung von Metadaten für Dokumente

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 (s. Abb. 5-13): • Einzelne Dokumente, bei denen jedem Dokument Metadaten zugeordnet werden. • Zusammengesetzte Dokumente werden aus mehreren Dokumenten, auch unterschiedlicher Typen, erstellt. • Sammeldokumente verknüpfen für sich abgeschlossene Dokumente über Metadaten miteinander. • Dokumentensätze listen die enthaltenen Dokumente auf. Die Metadaten beschreiben den Zweck eines Dokumentensatzes. 5.3.5

Beziehung zwischen Dokument und Artikel

Die Verwaltung von Artikeln und den zugehörigen Dokumenten kann auf unterschiedliche Arten realisiert werden. Das Product Lifecycle Management strukturiert die Artikel und Dokumente und stellt die Beziehungen zwischen ihnen her. Beziehung zwischen Artikelstruktur und Dokumentenstruktur

Ein wesentlicher Punkt des Product Lifecycle Managements ist die Verknüpfung von Dokument und Artikel. Artikel und Dokumente werden im Idealfall zunächst als völlig unabhängige Objekte bzw. Informationseinheiten betrachtet, und die Strukturen von Artikeln und Dokumenten werden getrennt verwaltet. Im Produktstrukturmanagement werden die Artikel und ihre Beziehungen zueinander organisiert, während das Dokumentenmanagement die entsprechenden Dokumentenstrukturen verwaltet. Darauf aufbauend werden die Beziehungen zwischen Dokument und Artikel hergestellt. Diese Beziehungen zwischen Artikel und Dokument lassen sich wie folgt beschreiben (Martin Eigner u. Ralph Stelzer 2001): • Zuordnung eines Artikels zu einem Dokument (1:1) Dieser Fall ist einfach zu handhaben, dürfte aber in der Praxis eher die Ausnahme sein, da ein Artikel in der Regel mehr als ein beschreibendes Dokument benötigt. • Zuordnung mehrerer Dokumente zu einem Artikel (1:n) Ein typisches Beispiel für diesen Fall sind Artikel, denen mehrere Un-

5.3 Dokumente sicher verfügbar machen

91

terlagen zugeordnet sind, beispielsweise 3D-Modell, 2D-Zeichnung, Arbeitsplan und NC-Programme. • Zuordnung mehrerer Artikel zu einem Dokument (n:1) Eine direkte Zuordnung einer technischen Unterlage, die direkt mehrfach an Artikelstämme gebunden ist, wie z. B. Basiszeichnungen für mehrere Artikelstämme oder Montageanweisungen für eine Produktfamilie. • Keine Zuordnung eines Artikels zu einem Dokument (0:1) Diese Dokumente sind im Allgemeinen übergeordnete Dokumente mit allgemeingültigen Informationen, wie Formulare, Normen und Richtlinien oder allgemeine Anweisungen. Dokumentenstruktur

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 des Datenvolumens. Hierbei kann es sich um zwei verschiedene Arten von Beziehungen handeln: • einfache Zuordnungen und • hierarchische Strukturen. 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 solche Dokumentgruppen zu Gruppen höherer Ordnung zusammengefasst und damit hierarchisch strukturiert (s. Abb. 5-14). Für diese Strukturierung sollten verschiedene Aspekte in Betracht gezogen werden: • flexible Informationsanforderungen in unterschiedlichen Phasen des Product Lifcycle, wie z.B. Engineering, Montage, Instandhaltung. • zweckmäßige Struktur, die der funktionsbezogenen und/oder ortsbezogenen Struktur (Zusammenbaulage) eines Artikels/Produktes folgt. • zentrale und/oder dezentrale Verfügbarkeit.

92

5 Leithefte zu PLM-Aspekten

Deckblatt Hauptliste

Deckblatt 1 Gruppenliste 1

Gruppenliste 11

Dokumentenliste 111

Dokument 1211

Deckblatt 2 Gruppenliste 2

Gruppenliste 12

Dokumentenliste 121

Dokumentenliste 122

Dokument 1212

Dokument 1221

Dokument 131

Dokument 133

Dokument 1222

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

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. 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ähr-

5.3 Dokumente sicher verfügbar machen

93

leisten, regeln Informationssysteme sowohl 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, dem so genannten electronic Vault. Ein solcher elektronischer Tresor besteht aus speziell geschützten Speicherbereichen, welche auf dem von den Informationssystemen genutzten Speichermedium reserviert sind. Ein Dokumentenstammsatz im System enthält einen Verweis auf die physische Datei. Der electronic Vault ist der Eigentümer von geschützten Dateien und Benutzer können auf die Daten nur über das Informationssystem zugreifen. Für das Ablegen und Holen von Dateien aus den geschützten Bereichen werden dem Anwender von den PDM- und Dokumentenmanagementsystemen folgende Funktionen zur Verfügung gestellt: • Check-Out-Funktion Die so genannte Check-Out-Funktion dient dem Holen von Dateien aus dem geschützten Speicherbereich. Mit dieser Funktion werden alle einer bestimmten Unterlage zugeordneten Dateien in den Arbeitsbereich des Benutzers, d. h. auf den Rechnern an dem er arbeitet, kopiert. Werden die Dateien zur weiteren Bearbeitung geholt, so werden sie von datenhaltenden Integrationssystemen zur Vermeidung von Inkonsistenzen für andere Anwender gesperrt. Dies ist nicht der Fall, wenn die Dateien nur zu Informationszwecken, d. h. zum Lesen, benutzt werden. • Check-In-Funktion Als Check-In-Funktion wird die Übergabe von neuen oder geänderten Dateien an den geschützten Speicherbereich beispielsweise eines PDModer 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 weiterhin in den Informationssystemen verwaltet und bleiben somit erhalten. Diese sind über die Historie des Dokuments abrufbar.

94 5.3.7

5 Leithefte zu PLM-Aspekten Umsetzung von Dokumentenmanagement

Eine grundsätzliche Vorgehensweise für die Einführung oder Optimierung des Dokumentenmanagements lässt sich in den folgenden Punkten zusammenfassen: 1. 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. 2. 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. 3. Aufbau der Dokumentenstruktur Zur Verbesserung der Übersichtlichkeit sollten die Dokumente in Gruppen zusammengefasst werden. Hierfür muss der jeweilige Verwendungszweck bestimmt werden und daraus die entsprechenden Dokumentenstrukturen abgeleitet werden. 4. Festlegen des Status und 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 Dokumentenmanagement sollte deshalb mit der Analyse der Prozesse verknüpft werden, wobei insbesondere die Abläufe des Änderungswesens (s. Abschnitt 5.8) zu berücksichtigen sind. 5. 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

5.3 Dokumente sicher verfügbar machen

95

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. Ein Beispiel für Zugriffsberechtigungen ist in Abschnitt 5.7.6 (Abb. 5-35) beschrieben. 6. 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, so dass alle Mitarbeiter auf denselben Datenbestand zugreifen. Ist eine zentrale Dokumenthaltung 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. Ein wichtiges Kriterium ist die Performanz, also Geschwindigkeit des Informationszugriffs, der jeweiligen Lösung (s. Abschnitt 6.7). 7. Datenübernahme Ein PDM- oder Dokumentenmanagementsystem lässt sich nur sinnvoll einsetzen, wenn es auch die benötigten Informationen zur Verfügung stellen kann. Allerdings darf Aufwand zum Einpflegen der Informationen nicht unterschätzt werden. Sind die Informationen in einem ITSystem vorhanden, können die Daten meist über Schnittstellen oder spezielle Konvertierungswerkzeuge übernommen werden. Liegen die Informationen auf Papier oder anderen Medien vor, können die Dokumente einerseits zur digitalen Bereitstellung gescannt werden oder andererseits im IT-System mit dem Standort des Dokuments referenziert werden. Als Entscheidungsgrundlage sollte der KostenNutzenaufwand 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-CADModells 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 FEZR-S05000-0012 und FEM-Berechnungsergebnis FR-ZR-S05000-0012

96

5 Leithefte zu PLM-Aspekten

verknüpft, denen die Dateien des FEM-Modells bzw. der Detailergebnisse zugeordnet sind. 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.3 Dokumente sicher verfügbar machen

97

Dokument

Datei

CAD-ZR-S05000-0012 Typ: CAD-Dokument

CAD-Zeichnung ZR-S0500v0-0012.DRW

Artikel 3D-CAD-Modell ZR-S05000-0012.MDL

ZR-S05000-0012 Zahnrad, geradeverzahnt

BR-ZR-S05000-0012 Typ: Festigkeitsnachweis

Berechnungsreport ZR-S05000-012.DOC

FE-ZR-S05000-0012 Typ: FEM-Modell

FEM-Modell ZR-S05000-0012.FEM

FE-ZR-S05000-0012 Typ: FEM-Ergebnis

FEM-Ergebnis ZR-S05000-0012.BIN

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

98

5.4

5 Leithefte zu PLM-Aspekten

Produktdaten archivieren

Æ Daten- und Dokumentenmanagement

Anforderungen an eine digitale Produktdatenarchivierung können auf unterschiedlichen Hintergründen basieren. Gemeinsam haben sie jedoch meinst die Ablösung der teuren und langsamen herkömmlichen Archive. Die Hintergründe können anwenderorientiert, technologiebasiert oder begründet auf Vorschriften motiviert sein. Um die Widerverwendung zu erleichtern und schnell auf archivierte Dokumente zugreifen zu können, sollen Dokumente im PLM von jedem Arbeitsplatz zugänglich sein und dies möglichst in einem neutralen Format. Eine solche Anforderung ist anwenderorientiert. Werden herkömmliche Dokumente in Papierform oder abgelichtet auf Microfiche 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. Auf Grund 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. Heute werden zu diesem Zweck archivierte Papierdokumente bei sicherheitskritischen Konstruktionen sogar teilweise vakuumverpackt. Beispielsweise besteht die Nachweispflicht in der militärischen Flugzeugindustrie weit über die Betriebszeit hinaus, die schon mal bei 50 Jahren liegen kann. Soll eine solche Entwicklung folglich digital archiviert werden, muss das Unternehmen garantieren, dass die archivierten Formate noch in 50 Jahren lesbar sind. Eine solche digitale Langzeitarchivierung stellt eine besondere Herausforderung dar. Einen hoffnungsvollen Ansatz für dieses Problem bietet der STEP-Standard der in der Normreihe ISO 10303 festgelegt ist, da es sich hierbei um eine textbasierte Beschreibung handelt. Für eine mittelfristige Archivierung ist ein standardisiertes Grafikformat anerkannt (TIFF), bei der man von einem zehnjährigen Zeitraum ausgeht. Bei einer Archivierung bis zu fünf Jahren wird von einer kurzfristigen Archivierung gesprochen. Hier können bekannte Formate verwendet werden, die sich etabliert haben. Als Beispiel sei hier das PDF-Format der Firma Adobe genannt.

5.4 Produktdaten archivieren 5.4.1

99

Digitale Produktdatenarchivierung

Die digitale Produktdatenarchivierung setzt auf dem Funktionsblock „Vaulting“ auf und damit indirekt auf das Daten- und Dokumentenmanagement. Die Archivierung selbst wird für keine weiteren Funktionsbausteine benötigt (s. Abb. 5-16).

Anwenderfunktion Prozessorientiert

Produktorientiert

Dienstfunktion Systemorientiert

Premium

Kommunikation, Notifizierung Archivierung

Viewing, Redlining

LifecyleManagement

Freigabemgnt.

Änderungsmgnt.

Datentransport (Schnittstellen)

Sichtenmanagement

Kollaborative Produktentwicklung Projektmanagement

Erweitert

Datentransformation

Konfigurationsmanagement

Versionen-/ Varianten-/ Alternativenmanagement

Applikationsspezifische Funktionen Toolintegration

Workflow-/ StatusPrüfProzessabläufe mgnt. mgnt.

Vaulting

Daten-/ Dokumentenmanagement

Basis

Zugriffsverwaltung

Systemadministration

Grundfunktion Klassifizierung und Benennung (SML)

Produktstrukturmanagement

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

100 5.4.2

5 Leithefte zu PLM-Aspekten Realisierung einer digitalen Produktdatenarchivierung

Zunächst sollten die Anforderungen an eine Archivierung geklärt werden. 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, Zweck der Archivierung und gesetzliche Rahmenbedingungen. Hierzu muss geklärt werden, welche Dokumente zu welchem Zweck archiviert werden. Grundsätzlich kann zwischen zwei Gründen der 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, legen die Anforderungen die Anwender fest, die über eine gewisse Zeit schnellen Zugriff auf die Dokumente haben sollen. Dieser Zugriff findet analog zu den im Leitheft „Dokumente sicher verfügbar machen“ (s. Abschnitt 5.3) vorgestellten Methoden statt. Für eine längerfristige Archivierung und für einen breiteren Zugriff bei speziellen Erzeugersystemen kann die Verwendung von Dokumenten in Alternativformaten von Vorteil sein. Soll eine digitale Archivierung neu eingeführt werden, sollten bestehende Daten mit in das Archiv aufgenommen werden. Dies kann grundsätzlich über drei Arten erfolgen. Zum einen können sie digital abgelegt werden, wenn noch Zugriff auf die Quelldateien besteht. Bei Dokumenten mit einem hohen Zugriff kann sogar eine nachträgliche Digitalisierung sinnvoll sein. Eine zweite Möglichkeit besteht im Abscannen vorhandener Dokumente. Dadurch ist zwar ein schneller Zugriff auf die Dokumente gewährleistet, jedoch ist eine digitale Weiterverarbeitung nicht möglich. Die dritte und letzte Möglichkeit besteht in der Aufnahme von Metadaten von Dokumenten, die weiterhin in einem herkömmlichen Archiv verwaltet werden. Im digitalen Archiv wird dann lediglich der Lagerort referenziert. 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. Ist die Archivierung für die Einhaltung einer Nachweispflicht bestimmt, muss auf vertragliche Abmachungen bzw. gesetzliche Vorschriften geachtet werden. In den meisten Fällen dürfen dann nur bestimmte Formate verwendet werden. Ist sogar eine Langzeitarchivierung von 3DGeometrien notwendig, soll an dieser Stelle auf das Lothar-Projekt des ProStepiVip-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.

5.4 Produktdaten archivieren

101

Auf Grund der ständigen Fortschritte in Forschung sollte auf Kongressbänder und auf das Internet mit ständig aktuellen Ergebnissen der Forschung verwiesen werden. Bei kurz- und mittelfristigen Archivierungen können Standards und Quasistandards wie beispielsweise PDF, IGES, DXF oder TIFF verwendet werden. Ein großer Vorteil bei der Verwendung des STEP-Standards liegt in der Fähigkeit 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. Weiterführende Literatur

Bernhard Malle: Ein Beitrag zur Langzeitarchivierung von Produktdaten, Verlag Dr. Kovac, Hamburg, 1997

102

5 Leithefte zu PLM-Aspekten

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 muss im Maschinenbau eindeutig identifiziert werden können. Hierzu werden unternehmenseigene Nummernsystematiken verwendet, die über die Identifikation hinaus die benummerten Objekte klassifizieren. Bei Anbetracht der Menge der zu berücksichtigten Objekte ist dies nicht ein gerade einfaches Unterfangen. Normen beschreiben verschiedene Grundmodelle für Systematiken von Nummernsystemen, die unterschiedliche Vor- und Nachteile mit sich bringen. Mit der Einführung einer PLM-Lösung ändern sich die Anforderungen an das unternehmenseigene Nummernsystem 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. Ziel des Leitheftes ist es, verschiedene Nummernsystematiken vorzustellen und einen Überblick über Anforderungen und Chancen, die mit PLM an ein Nummernsystem geknüpft sind, vorzustellen und weitere Problematiken, wie beispielsweise die Aufwendigkeit einer Reorganisation oder das Parallelexistieren verschiedener Nummern (Konstruktionsnummer, Vertriebsnummer, externe Nummern), zu sensibilisieren.

5.5 Nummernvergabe automatisieren 5.5.1

103

Nummernsystematik

Nummernsysteme sind organisatorische und methodische Voraussetzung für das IT-gestützte PLM (s. Abb. 5-17). Um Elemente IT-technisch verarbeiten zu können, müssen sie eindeutig identifiziert werden können. Dies ist nur mit entsprechenden Nummernsystemen möglich. Zudem ermöglicht ein PLM die Referenzierung des internen Nummernsystems zu anderen Nummernsystemen, wie z. B. zu Vertriebsnummern, externer Nummernsysteme von Zulieferern bzw. OEMs oder normierten Teilen.

Anwenderfunktion Prozessorientiert

Produktorientiert

Dienstfunktion Systemorientiert

Premium

Kommunikation, Notifizierung Archivierung

Viewing, Redlining

LifecyleManagement

Freigabemgnt.

Änderungsmgnt.

Datentransport (Schnittstellen)

Sichtenmanagement

Kollaborative Produktentwicklung Projektmanagement

Erweitert

Datentransformation

Konfigurationsmanagement

Versionen-/ Varianten-/ Alternativenmanagement

Applikationsspezifische Funktionen Toolintegration

Workflow-/ StatusPrüfProzessabläufe mgnt. mgnt.

Vaulting

Daten-/ Dokumentenmanagement

Basis

Zugriffsverwaltung

Systemadministration

Grundfunktion Klassifizierung und Benennung (SML)

Produktstrukturmanagement

Abb. 5-17: Nummernsystematik im PLM-Umfeld

104 5.5.2

5 Leithefte zu PLM-Aspekten Vorraussetzung für ein IT-konformes Nummernsystem

Vorraussetzung zur Einführung eines IT verträglichen Nummernsystems ist die systematische Klassifizierung aller verwendeten Objekte, die verwaltet werden sollen. Zu diesen Objekten gehören neben den Einzelzeilen auch Artikel, Baugruppen, ganze Produkte, Dokumente insbesondere Zeichnungen und Modelle, die direkt mit dem Produkt oder mit dem Entwicklungsprozess in Verbindung stehen, oder Rohmaterialien, Halbzeuge, Maschinen, Anlagen, Vorrichtungen, Werkzeuge und sonstige Betriebsmittel sowie Hilfs- und Betriebsstoffe (s. Leitheft „Finden statt Suchen“ Abschnitt 5.6). 5.5.3

Aufbau von Nummernsystemen

Eine Nummer berücksichtigt die zwei Aspekte der Identifikation und Klassifizierung. Der Identifizierungsaspekt dient der eindeutigen unverwechselbaren Festlegung bzw. Kennung eines Elementes. Dazu muss die Nummer eindeutig und unveränderlich in ihrer gesamten Lebensdauer sein. Der Klassifizierungsaspekt dient der Ordnung von Elementen nach vorgegebenen Merkmalen in bestimmte Klassen oder Gruppen. Der klassifizierende Anteil einer Nummer sollte hierarchisch aufgebaut sein. Mit zunehmender Stellenzahl verfeinert sich Klasse. Dieser Nummernanteil ist selbstsprechend. Eine Nummer kann aus Zahlen, Buchstaben und Sonderzeichen bestehen. Es muss 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. Im Folgenden wird die Verbund- und die Parallelnummer vorgestellt.

Identifizierung Klassifizierung

Abb. 5-18: Aufbau einer Verbundnummer

Zählnummer

5.5 Nummernvergabe automatisieren

105

Verbundnummer

Verbundnummern werden traditionell häufig im Bereich des Maschinenwesens eingesetzt. Sie verbinden Klassifikation mit einer Zählnummer und ergeben so im Verbund die Identifikation (s. Abb. 5-18). Verbundnummern haben folgende Charakteristika: Vorteile: • „halbsprechende Nummer“ Ein Mitarbeiter erkennt am hierarchischen Aufbau der Klassifikation das Objekt. • dezentrale Nummernvergabe: Objekte können dezentral vergeben werden, wenn Klassifikation mit Lokalität in Zusammenhang steht. • relativ geringe Stellenzahl Die Nummern sind sehr kompakt. Nachteile: • Grenzen schnell erreicht Der Zahlenraum ist durch feste Stellenzuordnung schnell ausgeschöpft. • 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 zuordbar. • 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 von der Klassifizierung. Die Parallelnummer besteht also aus zwei Nummern, die unabhängig von einander aussagekräftig sind (s. Abb. 5-19), jedoch nur in Kombination den Anspruch an ein Nummernsystem nach DIN 6763 erfüllen. Die Identifikationsnummer ist eine laufende Nummer über alle Klassen hinweg. Die Parallelnummern zeichnen folgende Charakteristika aus:

106

5 Leithefte zu PLM-Aspekten

Identifizierung Zählnummer

Klassifizierung Grobklassifizierung

Feinklassifizierung

Abb. 5-19: Aufbau einer Parallelnummer

Vorteile: • Kurze Identifizierungsnummer Die Identifizierungsnummer ist bei der Parallelnummer im Vergleich zur Verbundnummer kürzer, weil sie eine fortlaufende Nummer ohne Freistellen ist. • 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 • Zählnummer eindeutig Allein die Zählnummer ist eindeutig. • 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 Querverweise in Dokumenten davon betroffen ist. Nachteile • Einführungsaufwand Gerade ein nachträglicher Einführungsaufwand ist teilweise sehr hoch. • 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.

5.5 Nummernvergabe automatisieren 5.5.4

107

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. Üblicherweise beziehen sich eine Menge von Dokumenten mittels der Nummern auf bestimmte Artikel. Zunächst muss die Wahl auf eine bestimmte Nummernsystematik fallen. 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 zu berücksichtigen. Eventuell ist es sinnvoll, bestehende Nummernsysteme, wie beispielsweise externe Nummern, Vertriebsnummern oder DIN-Nummern in die Auswahl mit einzubeziehen. Ist die Wahl auf ein Nummernsystem gefallen, sind die Nummernräume festzulegen und die Stellen des Klassifikationsanteils zuzuordnen. Ist dies geschehen, ist der Aufbau des Nummernsystems festgelegt. Zur Nummernvergabe bieten sich unterschiedliche Systeme an. Grundsätzlich stehen sich hier die betriebswirtschaftlichen und die Systeme aus der Entwicklung gegenüber. Es sind sowohl Konzepte denkbar, in denen beide Systeme Nummern vergeben dürfen, beispielsweise über Nummernräume geregelt, wie auch Konzepte bei denen ein System das Mastersystem ist. Jeder, der im Unternehmen Teile anlegen darf, muss auf den für ihn relevanten Nummernraum zugreifen können. Zudem muss Konsistenzsicherung gewährleistet sein. Abschließend erfolgt eventuell eine Überführung der alten Nummern in die neue Systematik.

108

5 Leithefte zu PLM-Aspekten

Checkliste

• • • • •

Alle Objekte berücksichtigt? Nummernraum auch zukünftig ausreichend? Auch ausreichend für eventuelle Geschäftsfelderweiterung? Klassifikation durchgängig? Vertriebsnummern und externe Nummern berücksichtigt?

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.

5.6 Finden statt Suchen

5.6

109

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 noch in traditioneller Weise, in einer NormblattSammlung 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 Suchen nach wieder verwendbaren 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 Möglichkeiten für das Suchen und Finden von verschiedenen Eigenschaften eines Bauteiles zur Verfügung gestellt werden. Klassifikationssysteme sollen somit die folgenden Aufgaben zu unterstützen: • • • •

Strukturierung von großen Datenmengen umfangreiche Suchmöglichkeiten zur Verfügung zu stellen 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 bestimmten Eigenschaften dieser Gegenstände. Bei entsprechendem Aufbau des Klassifikationssystems bieten Informationssysteme weit reichende Möglichkeiten die Suche nach Gegenständen oder bestimmten Eigenschaften dieser Gegenstände zu erleichtern und die Zeit für das Auffinden von Informationen zu verkürzen.

110 5.6.1

5 Leithefte zu PLM-Aspekten Produktklassifizierung

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

Anwenderfunktion Prozessorientiert

Produktorientiert

Dienstfunktion Systemorientiert

Premium

Kommunikation, Notifizierung Archivierung

Viewing, Redlining

LifecyleManagement

Freigabemgnt.

Änderungsmgnt.

Datentransport (Schnittstellen)

Sichtenmanagement

Kollaborative Produktentwicklung Projektmanagement

Erweitert

Datentransformation

Konfigurationsmanagement

Versionen-/ Varianten-/ Alternativenmanagement

Applikationsspezifische Funktionen Toolintegration

Workflow-/ StatusPrüfProzessabläufe mgnt. mgnt.

Vaulting

Daten-/ Dokumentenmanagement

Basis

Zugriffsverwaltung

Systemadministration

Grundfunktion Klassifizierung und Benennung (SML)

Produktstrukturmanagement

Abb. 5-20: Produktklassifizierung im PLM

5.6 Finden statt Suchen 5.6.2

111

Klassifikation

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 verschiedenen 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, Sachmerkmalleisten und eClass, die im Folgenden beschrieben werden. Das EinzelteilVerschlü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 Wergzeugmaschinenfabriken (VDW) in einer größeren Anzahl von Betrieben durchgeführte 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 ist ein rein numerisches, kombiniertes System, welches sich aus hierarchischen und nichthierarchischen Anteilen zusammensetzt. Im Formenschlüssel (s. Abb. 5-21) werden die Werkstücke entsprechend ihrer Grundform zunächst in die Gruppen Rotationsoder Nichtrotationsteile eingeordnet; innerhalb dieser Gruppen wird nach Abmessungsverhältnissen unterschieden. Zur weiteren Einteilung dienen Außenform, Innenform und Flächenmerkmale. Ein Ergänzungsschlüssel kann zusätzliche für die Klassifizierung notwendige Angaben wie Werkstoff und Genauigkeitsgrade enthalten. Er ist als Vorschlag gedacht und wird betriebsspezifisch aufgebaut. Schwerpunkt des Systems liegt in der Beschreibung üblicher Maschinenbauteile d. h. Teile des allgemeinen Maschinenbaus wie Wellen, Scheiben, Zahnräder. Rotationsteile werden bevorzugt, da sie nach vorgenannten Untersuchungen die größte Verbreitung im Maschinenbau haben. Der Schlüssel ist durch einen klaren und übersichtlichen Aufbau gekennzeichnet.

Abb. 5-21: Klassifikationsschlüssel nach Opitz

9

8

7

6

5

4

3

2

1

4

5

6

mit Abweichung L/D > 2

spezifisch

A/B 4

spezifisch

9

8

3

mit Abweichung L/D A0

7

auf Mikrofilm

7

in Klarsichttasche

8

Sonderformat < A0

8

frei

8

frei

9

frei

9

frei

9

frei

0

DIN A0

0

frei

0

frei

Abb. 6-3: Prinzip der unabhängigen Strukturierung

216

6 Technische und methodische Grundlagen

Eine hierarchisch aufgebaute Nummer kann bei Bedarf durch eine Nummernverlängerung verfeinert werden. Typische Vorteile des hierarchischen Nummernaufbaus sind: • kompaktere Darstellungsform der verschlüsselten Merkmale gegenüber einem unabhängigen Nummernaufbau • eventuell geringere Stellenanzahl als bei Nummern mit einem unabhängigen Aufbau • in größeren Unternehmen einfacherer Aufbau eines Nummernschlüssels, da eine dezentrale Belegung in Abhängigkeit eines Vergabebereiches erfolgen kann 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. 6-3). Jeder einzelne Nummernteil lässt sich daher selbstständig auswerten. Eine Umklassifizierung kann somit ohne Auswirkung auf andere Nummernteile erfolgen. 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): • Nummern sollten so kurz wie möglich sein. Darstellungsprobleme gibt es hauptsächlich bei langen Nummern. • Anzeige von verschlüsselten Angaben auf Masken und Listen nur dort, wo dies unbedingt erforderlich ist • Angebot zusätzlicher optionaler Informationsmasken mit den Informationen über den Nummernplan und Nummernaufbau • Alphabetische oder alphanumerische Schlüssel sind oft leichter merkbar und aussagekräftiger als rein numerische Schlüssel. • Gliederung langer Nummern in leicht merkbare kurze Nummernblöcke unter Verwendung von Gliederungszeichen Der Aufbau eines Nummernsystems ist von folgenden Faktoren abhängig: • Art der Objekte und deren Merkmale; Vorangestellt wird eine Analyse der Zielsetzungen, Benutzer, Datenträger, Bearbeitungsvorgänge etc. • 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 • Verknüpfung der Merkmale untereinander oder nicht • Lebensdauer des Nummernsystems (abhängig von der Lebensdauer der Objekte, Veränderung des Unternehmens).

6.3 Nummernsysteme 6.3.2

217

Formen von Nummernsystemen

Nummernsysteme werden mit Hilfe von Nummernschemas in Form von Symbolen entworfen. Eine gebräuchliche Darstellungsform zeigt Abb. 6-4. Pro Stelle einer Nummer wird ein Kästchen verwendet. Die Zeichen können folgende sein: Buchstabe (B), Ziffern (Z) oder Sonderzeichen (z. B. /, -, . --). Bezügliche des Nummernaufbaus unterscheidet man zwischen Verbundnummern- und Parallelnummernsystem. Die Verbundnummer besteht aus einem klassifizierenden Teil und einer laufenden Zählernummer, welche zusammen zur Identifikation dienen (s. Abb. 6-5).

einstellig

B

Buchstabe

Z

Ziffer

S

Sonderzeichen

mehrstellig

verzweigt einstufiges System parallel

mehrstufiges System

Abb. 6-4: Nummernsysteme

Identifizierung Klassifizierung

Abb. 6-5: Darstellung eines Verbundnummernsystems

Zählnummer

218

6 Technische und methodische Grundlagen

Beim Parallelnummernsystem dient nur die Zählernummer der Identifikation. In einer zweiten Nummer wird die Klassifikation gepflegt (s. Abb. 6-6). Allgemein kann festgestellt werden, dass sich in der industriellen Praxis bei EDV-gestützter Teileverwaltung die Parallelverschlüsselung mit den Vorteilen einer unabhängigen Identifizierung und Klassifizierung bei Artikeln durchgesetzt hat. Nummeriert werden jedoch nicht nur Artikel sondern beispielsweise auch Aufträge. Die Auftragsnummer wird meist nach den Anforderungen des Rechnungswesens festgelegt. Ein Beispiel zeigt die Abb. 6-7. Die sechsstellige Identnummer identifiziert die Gesamtaufträge. Auch hier ist es u. U. zweckmäßig, Vergabebereiche zu bilden. Unteraufträge werden vergeben, wenn z. B. für wichtige Gruppen deren Kosten und Termine gesondert ermittelt werden sollen. Die Unterauftragnummer ist bei diesem Beispiel eine dreistellige Zählernummer.

Identifizierung Zählnummer

Klassifizierung Grobklassifizierung

Feinklassifizierung

Abb. 6-6: Darstellung eines Parallelnummernsystems

Identnummer Gesamtauftrag

Klassifizierungsnummer Auftrag

1 2 3 4 1 2 0 0 0

1 2 3 1 2 3 1 2

Zählnummer Vergabebereichsnummer

Auftragsart Kostenart Fertigungsbereich

Abb. 6-7: Beispiel einer Auftragsnummer

6.4 Klassifikation und Sachmerkmalleisten

6.4

219

Klassifikation und Sachmerkmalleisten

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 eine 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. Unter Klassenbildung von Objekten versteht man ihre Einordnung nach vorgegebenen Merkmalen in bestimmte Klassen, Familien oder Gruppe. Elemente mit derselben Klassifizierung sind nur gleich in Bezug auf die ausgewählte, beschriebene Eigenschaft. Die Klassifizierungsnummern sollten den Aufbau der Klassifikation wieder spiegeln und somit folgende Eigenschaften erfüllen: • Eindeutigkeit innerhalb eines Klassifizierungssystems • ausreichende Ausbaufähigkeit der zugrunde gelegten Begriffssysteme • Beschränkung auf eindimensionale Aussagen in einer Klassifizierungsnummer bzw. im gleichen Nummernteil • Verwendung sinnvoller, sprechender (mnemotischer) Schlüssel 6.4.1

Sachmerkmalleisten

Durch den hierarchischen Aufbau von Sachmerkmalleisten (SML) 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 (s. Abb. 6-8). Sachmerkmalleisten bringen vor allem dann Vorteile, wenn viele Gruppen von Objekten (Gegenstandsgruppen) mit sehr unterschiedlichen Eigenschaften zu beschreiben sind. Die Vorraussetzung dafür ist, dass jeder Gegenstandsgruppe individuelle Merkmale zugeordnet werden können, welche andere Gruppen nicht zwangsläufig auch belegen müssen. Eine Aufnahme in den Stammsatz scheidet damit von vornherein aus. Vielmehr wird eine neue Objektklasse für Gegenstandsgruppen eingeführt. Diese beschreiben jeweils eine Gruppe ähnlicher Objekte, die sich durch gleiche Attribute auszeichnen. Jede Gruppe wird mit Gruppenname, dem Klassencode und einer Reihe weiterer Eigenschaften beschrieben. Zusätzlich ist es möglich, jeder Gruppe beliebig viele Attributdefinitionen (Sachmerkmale) zuzuordnen.

220

6 Technische und methodische Grundlagen Zahnrad

Bezeichnung

D

d

005 75 264 3 005 75 264 7

Stirnrad 40x20 Stirnrad 60x15

40 60

20 15

Kegelrad D1

D2

d

Kegelrad 60x40x20 40 Kegelrad 60x30x15 60

20 15

20 15

Sachnummer Bezeichnung 005 76 260 8 005 76 260 9

Generalisierung

Spezialisierung

Stirnrad Sachnummer

Schrägverzahntes Strinrad Sachnummer Bezeichnung 005 75 265 1 005 75 265 1

D

Schr.-Stirnrad A50x5x45 50 Schr.-Strinrad A50x15x30 50

d

α

5 15

45 30

Sachmerkmalleiste

Abb. 6-8: Vererbungshierarchie von Sachmerkmalleisten

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 „…die formalisierte Zusammenstellung und Anordnung von relevanten Sachmerkmalen einer Gegenstandsgruppe“ (DIN 4000): • Merkmale sind bestimmte Eigenschaften, die zum Beschreiben und Unterscheiden von Gegenständen dienen. • Sachmerkmal ist ein Merkmal, das Gegenstände unabhängig vom Umfeld (z. B. Herkunft, Verwendung) beschreibt. • Sachmerkmalname ist die Identifikation eines Einzelmerkmals innerhalb einer Sachmerkmalleiste, z. B. Durchmesser, Länge etc. DIN 4000 verwendet als Identifikator einen Sachmerkmalkennbuchstaben. • Sachmerkmalausprägung ist je nach Art des Sachmerkmal ein Größenwert oder eine textuelle Information (z. B. eine attributive Angabe). Sachmerkmalausprägungen beschreiben die Eigenschaften von Objekten.

6.4 Klassifikation und Sachmerkmalleisten

221

• Sachmerkmalleiste ist die Zusammenfassung aller relevanten Sachmerkmale einer Gruppe von Objekten/Gegenständen. • Gegenstandsgruppe ist eine durch gemeinsame Sachmerkmale bestimmte Gruppe artverwandter Objekte/Gegenstände z. B. Wellen, Platten, Spiralbohrer. Eine Gegenstandsgruppe besitzt eine Sachmerkmalleiste. Die Merkmale werden für jedes Objekt mit Werten bzw. Ausprägungen versehen. Einzelne Gegenstände sind durch ihre Ausprägungen eindeutig unterscheidbar. Die SML ist ein dynamisches Instrument der Wiederhollösungssuche, da durch die sukzessive Festlegung von Merkmalen die Menge der infrage kommenden Objekte gezielt eingegrenzt werden kann. 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. Sachmerkmalsleisten greifen auf Stufe 3, den Teilefamilien, und beschreiben alle Mitglieder einer Teilefamilie durch Attribute und Attributwerte. 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. 6.4.2

Klassifikationsschlüssel nach Opitz

Der Opitz-Schlüssel ist ein hybrides Klassifikationssystem, dessen Schwerpunkt in der Beschreibung üblicher, häufig vorkommender Einzelteile des allgemeinen Maschinenbaus (Wellen, Zahnräder, Scheiben etc.) liegt. Er wurde am Laboratorium für Werkzeugmaschinen und Betriebslehre der RWTH Aachen entwickelt, zum Zweck der erleichterten Wiederholteilfindung und Teilfamilienbildung. Für die Klassifizierung werden Formmerkmale als Leitmerkmale herangezogen. Der Opitz-Schlüssel setzt sich aus hierarchischen und nichthierarchischen Merkmalen zusammen. Im Formenschlüssel werden die Werkstücke entsprechend ihrer Grundform grob in Gruppen Rotationsund Nichtrotationsteile eingeordnet; innerhalb dieser Gruppen wird nach Abmessungsverhältnissen unterschieden. Zur weiteren Einteilung dienen Außenform, Innenform und Flächenmerkmale. Der Ergänzungsschlüssel enthält zusätzliche für die Klassifizierung notwendige Angabe wie Werkstoff und Genauigkeitsgrade. Er ist als Vorschlag gedacht und wird betriebsspezifisch aufgebaut.

222

6 Technische und methodische Grundlagen

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 jedoch 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, breites Anwendungsfeld und ist im produzierenden Gewerbe weit verbreitet. 6.4.3

Klassifikationsschlüssel nach Wiehndahl

Der Wiehndahl-Schlüssel ist ein hybrides Klassifikationssystem zur Verschlüsselung allgemeiner Baugruppen. Die kurzfristige Zielsetzung der Baugruppenklassifizierung ist: • eine Rationalisierung der Auftragsabwicklung durch wieder verwenden vorhandener Unterlagen • eine Rationalisierung der Fertigung und Montage durch Zusammenführen ähnlicher Teile und Gruppen Die langfristige Zielsetzung zeichnet sich wie folgt aus: • Erhöhung der Wiederverwendungsrate und Verbesserung der Produkte durch Standardisierung Entwicklung von Baukastensystemen und Wertanalysen • Synthese neuer Produkte mit Hilfe von morphologischen Methoden • Erstellung von Planungsdaten für Baugruppen • Entwicklung von Standard-, Arbeits- und Montageplänen • Teilefamilienfertigung • Errichtung von Sonderfertigungsstätten • Bildung von Montagefamilien Wie der Opitz-Schlüssel ist der Wiehndahl-Schlüssel ein rein numerisches Ordnungssystem. Das primäre Kriterium für die Einteilung einer allgemeinen Baugruppe ist die Funktion dieser. 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

6.4 Klassifikation und Sachmerkmalleisten

223

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 Wiehndahlschlü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 (Eingner u. Stelzer 2001) (Grabowski et al. 2002) (Schichtel 2001). 6.4.4

Klassifikationsschlüssel eClass

eClass ist ein vierstufiges, hierarchisches Klassifikationssystem, das schwerpunktmäßig im Bereich der Betriebsmittelklassifikation eingesetzt wird. Es wurde von führenden deutschen Unternehmen erarbeitet mit dem Ziel ein einheitliches Nummernsystem für die Klassifizierung von Betriebsmitteln zur Vereinfachung des elektronischen Handels zu definieren. eClass dient als gemeinsame „Sprache“ zwischen dem Einkäufer und dem Lieferanten. Klassifikation

Beschreibung

23-11

Schraube, Mutter [s]

23-11-01

Schraube (mit Kopf) [s]

23-11-01-01 SML

Schraube, flach aufliegend, Außenantrieb [s]

23-11-01-02 SML

Schraube, flach aufliegend, Innenantrieb [s]

23-11-01-03 SML

Senkkopfschraube, Innenantrieb [s]

23-11-01-04 SML

Schraube mit Rechteckskopf [s]

23-11-01-06 SML

Schraube, selbstarretiernd [s]

23-11-01-10

SML

Sonderschraube [s]

23-11-01-11

SML

Holzschraube [s]

Abb. 6-9: Beispiel für Klassifizierung nach eClass

224

6 Technische und methodische Grundlagen

eClass ist gekennzeichnet einen vierstufigen hierarchischen Klassifikationsschlüssel mit einem 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 (s. Abb. 6-9). 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 (s. Abb. 6-8), die in Abhängigkeit vom Produkt oder 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.

6.5

Vorgehensmodelle

Es existieren bereits einige Vorgehensmodelle von Gremien und Beratungsfirmen zur Einführung von Standardsoftwaresystemen bzw. PDMSysteme. Diese stehen nicht im Gegensatz zu dem in Kapitel 4 vorgestellten evolutionären Vorgehensmodell, sondern können dieses bei der Durchführung einzelner Teilprojekte durchaus unterstützen. 6.5.1

VDI-Richtlinie 2219

Die VDI-Richtlinie 2219 hat das Ziel, bewährte Vorgehensweisen sowie Wissen und Erfahrungen von Unternehmen und Institutionen bei der Einführung von PDM-Systemen zur Verfügung zu stellen. Damit soll ein Wissenstransfer sichergestellt und interessierten Unternehmen ein praxisorientierter Leitfaden an die Hand gegeben werden. Zusätzlich zu diesem Leitfaden erläutert die Richtlinie die Bedeutung und Notwendigkeit des Einsatzes eines PDM-Systems, bietet Hilfe bei der Ermittlung der Wirtschaftlichkeit, beschreibt die Maßnahmen zum Anpassen des ausgewählten Systems an die betrieblichen Gegebenheiten und stellt ein umfangreiches Glossar zur Verfügung (Vajna 1999).

6.5 Vorgehensmodelle Projektdefinition, Zusammenstellen des Projektteams

Ist-Analyse

SollKonzeption

Systemauswahl

Einführung und Betrieb

225

Ausweitung der Anwendung

Abb. 6-10: Schritte bei der Einführung eines PDM-Systems nach der VDIRichtlinie 2219

Bei der Einführung eines PDM-Systems wird eine Gliederung in die in Abb. 6-10 dargestellten sechs Schritten vorgeschlagen. Zu Beginn eines PDM-Projektes stehen die Projektdefinition und Zusammenstellung des verantwortlichen Projektteams. In dieser Phase werden unter Berücksichtigung der Gesamtstrategie des Unternehmens der Umfang des Projektes, die zu erreichenden Ziele und die Verantwortlichkeiten definiert. Zu diesem Zeitpunkt sollte schon geprüft werden, ob das Projektteam um externe Berater erweitert werden kann, damit eine unabhängige Sicht auf die Problemstellung möglich ist. In der Analysephase werden die Organisation und die IT-Infrastruktur der relevanten Bereiche erfasst. Dazu gehören auch die Geschäftsprozesse der Entwicklungsbereiche. Informationsflüsse müssen in geeigneter Form abgebildet werden. In dieser Phase ergibt sich die Möglichkeit, generell die Abläufe zu überprüfen und zu überarbeiten. Diese Tätigkeit wird empfohlen, da nur mit optimierten Prozessen das gesamte Potential einer PDM-Anwendung ausgeschöpft werden kann. Des Weiteren wird verhindert, dass ineffiziente Prozesse durch die Rechnerunterstützung fixiert werden. Im Soll-Konzept werden technische und organisatorische Rahmenbedingungen festgelegt. Parallel hierzu ist eine detaillierte Marktanalyse vorzunehmen, um die Leistungsfähigkeit und Funktionalität der PDM-Systeme vergleichen zu können. Die Gesamtheit dieser Ergebnisse ergibt die Grobspezifikation, die in allgemeinster Form enthält, welche Funktionen auf welche Art und Weise und von welchen Modulen zu erfüllen sind. Mit den Angaben aus der Grobspezifikation erfolgt anhand von Ausschlusskriterien eine Systemvorauswahl von bis zu drei Systemen, von deren Herstellern Angebote eingeholt werden und die einer genaueren Untersuchung unterzogen werden. Sind alle vorzubereitenden Maßnahmen getroffen, erfolgt vor Ort beim Interessenten ein Systemtest in einer abgegrenzten Testumgebung, dem Benchmark. Hier wird die Systemimplementierung anhand verschiedener Kriterien geprüft. Besonderer Schwerpunkt liegt dabei auf der sorgfältigen Überprüfung hinsichtlich der Berücksichtigung der Benutzeranforderungen, um von vornherein eine möglichst große Akzeptanz zu schaffen. Am Ende der Bewertungsphase

226

6 Technische und methodische Grundlagen

steht die Auswahl eines PDM-Systems aus der Vorauswahl unter Berücksichtigung des Lastenheftes und der durchgeführten Benchmarktests. Nach der Auswahl erfolgen Implementierung und Anpassung des Systems an die unternehmensspezifischen Gegebenheiten. Dafür wird ein stufenweises Vorgehen empfohlen. Zum Zeitpunkt der Einführung muss ein Erweiterungskonzept erarbeitet werden, welches die künftigen Ausbauschritte festlegt. So bleibt der anfängliche Aufwand geringer, der Ausbau könne sich an den finanziellen und kapazitiven Möglichkeiten des Unternehmens orientieren und eine mögliche Funktionsüberschneidung mit einem eventuell bereits vorhandenem PPS-System könne so gering wie möglich gehalten werden. Sind alle vorbereitenden Maßnahmen getroffen, erfolgt ein Systemtest in einer abgegrenzten Testumgebung. Sind die Tests erfolgreich abgeschlossen, erfolgt der schrittweise Transfer in die organisatorischen Einheiten. Um den Änderungen in den Anforderungen und den eventuell daraus folgenden Ausweitungen der Anwendung an die Dienste der Systeme gerecht zu werden, schlägt die VDI-Richtlinie zwei Lösungswege vor: • Erweiterung der systemspezifischen Funktionalitäten, möglichst auf Basis einer offenen Systemarchitektur in Anlehnung an ein Referenzmodell oder • Einbindung von PDM-Systemen in einen unternehmensübergreifenden Verbund. Bei einer Funktionserweiterung werden systemspezifische Objekte des Systems über ein Application Programming Interface (API) verändert oder neu erstellt. Dabei kann zwischen Funktionserweiterungen und Datenmodellerweiterungen unterschieden werden. Funktionserweiterungen werden durch Programme realisiert, die in das PDM-System integriert werden. Eine Datenmodellerweiterung bedeutet die Einführung neuer Objekte und Strukturrelationen, die immer von vorhandenen Objektklassen und Relationen abgeleitet werden. Die VDI-Richtlinie bietet ein hilfreiches Rahmenwerk für die Einführung von PDM-Systemen. Die allgemeine Vorgehensweise lässt sich sicherlich auf eine allgemeine Einführung von Standardsoftwaresystemen übertragen. Die detaillierteren Ausführungen beziehen sich allerdings sehr deutlich auf PDM-Systeme. Sehr hilfreich ist das Glossar und die damit verbundene Festlegung der Bedeutung von oft sehr unterschiedlich benutzten Begriffen.

6.5 Vorgehensmodelle 6.5.2

227

CSC Catalyst

CSC Catalyst (CSC Catalyst 2000) ist die Methode von CSC Ploenzke zur Initiierung, Begründung, Gestaltung, Ausführung und Koordination von Veränderungsprozessen in Organisationen. Es hat sich sowohl bei Großunternehmen als auch bei kleinen und mittelständischen Unternehmen bewährt. Die Projekte werden beim CSC Catalyst in die in Abb. 6-11 dargestellten Phasen gegliedert. Begleitet werden die Phasen von Entwicklungskoordination, Projekt- und Programm-Management (Jungfermann 1999) Die Phase Vision und Strategy beginnt in der Regel mit der Beschreibung der auf das Produktdatenmanagement bezogenen Vision. Anhand der Projektzielsetzung lässt sich der so genannte Fingerprint des Projektes erstellen. Dies ist eine Gewichtung der in Abb. 6-11 dargestellten sog. Domänen des Wandels.

Lifecycle

Management

Project Oriented

Integration

Service Oriented

Deployment

Operational Services

Abb. 6-11: Phasen bei der Einführung von Standardsoftware mit dem CSC Catalyst

Program Management

Development

Development Coordination

Architecture

Project Management Service Management

Vision & Strategy

228

6 Technische und methodische Grundlagen

• Geschäftsprozesse beschäftigen sich mit dem, was das Unternehmen tut, wie es dies tut, in welcher Sequenz es dies tut, welchen Regeln es folgt, und welche Art von Ergebnissen es erhält. • Die Domäne Organisation und Personal behandelt die Mitarbeiterstrukturen des Unternehmens, ihre Kultur, ihre Fähigkeiten, ihre Rollen, ihre Team-Strukturen und ihre organisatorischen Einheiten. • Bei den Standorten werden sowohl der Standorttyp als auch die physischen Einrichtungen des Standortes betrachtet. • Die Datendomäne beschäftigt sich mit dem Inhalt, der Struktur, den Beziehungen und den Regeln der Informationen, die das Unternehmen ständig nutzt und verarbeitet. • Die Technologie betrachtet die Hardware, die System-Software und die Kommunikationskomponenten, die zur Unterstützung des Unternehmens genutzt werden. • Die Domäne der Applikation schließlich behandelt den Leistungsumfang, die Struktur und die Anwendungsschnittstelle der Software, die dem Nutzer zur Verfügung steht. Der nächste Schritt in der Phase Vision und Strategie ist die Durchführung einer Machbarkeitsstudie. Diese beginnt mit dem Aufstellen einer Zieldefinition. Zum Erreichen einer abgestimmten Zielsetzung des Projektes wird zunächst analysiert, welche Problemkreise sich heute im Unternehmen zeigen. Sind die tangierten Prozesse identifiziert, so erfolgt eine Erhebung der im Einsatz befindlichen Applikationen. Damit ist eine erste Beurteilung des Integrationsbedarfes und gegebenenfalls der Integrationstiefe möglich. Das Ergebnis der Machbarkeitsstudie ist die Entscheidungsvorlage. Ein wichtiger Bestandteil davon ist die Wirtschaftlichkeitsprognose, da damit bereits zum jetzigen Zeitpunkt Projektkosten auf Grund der vorliegenden groben Planung abgeschätzt werden können. Den Abschluss dieser Phase bildet die auf den Projektantrag gestützte Projektfreigabe. In der darauf folgenden Architekturphase wird als erste Aktivität eine Anforderungsanalyse durchgeführt. Die in der Machbarkeitsstudie identifizierten Prozesse werden dabei genauer analysiert und gegebenenfalls dokumentiert. Aus den Anforderungen wird das Soll-Konzept abgeleitet. Es gilt aus den in der Analyse gewonnenen Erkenntnissen das Ziel abzuleiten. Hierbei sind nicht nur die Daten und Funktionen des Systems festzulegen, sondern es stehen die neuen, modifizierten Prozesse im Vordergrund. Als Basis für die Verträge und des Benchmarks zur Systemauswahl wird das Soll-Konzept in das Lastenheft überführt. Die Systemauswahl basiert auf einer auf K.O.-Kritieren basierenden Systemvorauswahl. Als letzte Aktivität in dieser Phase erfolgt die Umsetzungs- und Einführungs-

6.5 Vorgehensmodelle

229

planung. In diese Planung fließen die Roll-Out-Zeitpunkte als auch der stufenweise Ausbau der Funktionalität mit ein. Auf die Phase Architektur folgt die Entwicklungsphase. Vor der Umsetzung der zahlreichen Anforderungen werden zunächst die Funktionen in Basisfunktionen und darauf aufbauende fachbereichsspezifische Funktionen gegliedert. Unter Basisfunktionen sind dabei Funktionen zu verstehen, welche für alle Anwender notwendig sind und die im Sinne der Transparenz einheitlich sein sollten. In der anschließenden Integrationsphase kommt die Aufgabe des strukturierten Testens sowohl durch das Projektteam selbst als auch durch ausgewählte Anwender als Aufgabe hinzu. In der letzten Phase schließlich erfolgt Einführung und Betrieb des Systems. Nach der Fertigstellung der Basisfunktionalität wird der Roll-Out schrittweise vollzogen. Dabei wird eine ein kombinierter fachbereichsweiser und teilprojektbezogener Roll-Out durchgeführt. Im Gegensatz zur nutzenorientierten Einführung ist beim CSC Catalyst der Benchmark verbunden mit der Systemauswahl ein wichtiger Punkt der Vorgehensweise. Durch eine Werkzeugunterstützung könnten hier Zeit- und damit Kosteneinsparungen erzielt werden. Sehr große Bedeutung neben der technischen Einführung legt das Verfahren auf die Motivation des Umfeldes der Einführung. Durch den Einsatz in Groß- als auch in kleinen und mittelständischen Unternehmen bietet sich für dieses Verfahren ein breites Anwendungsgebiet. 6.5.3

Nutzenorientierte Einführung

Die KPMG Consulting hat ein eigenes Konzept zur Einführung von PDMSystemen entwickelt. Die Devise dieses Verfahrens lautet „Konzentration auf das Wesentliche“ (Produkt-Daten-Management 2000), d. h. „(sich) nicht auf das technisch Machbaren zu konzentrieren, sondern das wirtschaftlich Sinnvolle anstreben“. Ziel ist, kurze Einführungszeiten schnelle Amortisationszeiten und einen hohen Return on Investment (ROI) zu erzielen. Man versucht 80 Prozent des Nutzens mit 20 Prozent des Aufwandes zu realisieren. Dazu wird die Einführung von Funktionalitäten an deren Nutzenpotentialen ausgerichtet und die Systemauswahl beschleunigt (Krzepinski 1999). Die nutzenorientierte Einführung verläuft in zwei Schritten. Zunächst wird analysiert, welche Nutzenpotentiale durch die verschiedenen Einführungsmaßnahmen ausschöpfbar sind und anschließend werden diese priorisiert. Dabei können drei typische PDM-Nutzenpotentiale unterschieden werden:

230

6 Technische und methodische Grundlagen

• direkte Kosteneinsparungen, • Produktivitätssteigerungen und • Zeiteinsparungen Der erste Schritt besteht darin, die Ursache- und Wirkungs-Beziehungen zu untersuchen und ausgehend von der vorliegenden Wettbewerbsstrategie zu gewichten. Jedes Potential nimmt in unterschiedlicher Stärke Einfluss auf die kritischen Erfolgsfaktoren Kosten, Zeit und Qualität (s. Abb. 6-12). Aus der relativen Gewichtung der Nutzenpotentiale zueinander werden im zweiten Schritt die Prioritäten für den Implementierungsplan abgeleitet. Dem Zeitpunkt, an dem man die wichtigsten Basisfunktionalitäten einer möglichst großen Anwenderzahl bereitstellt, wird der größte Effekt auf die Wirtschaftlichkeit eines PDM-Projektes beigemessen. Zunächst stellt man mit Hilfe der Quality Function Deployment (QFD) Methode die PDMspezifischen Anforderungen hinsichtlich ihres Einflusses auf die Nutzenpotentialerfüllung gegenüber. Dadurch ist sichergestellt, dass das Wesentliche im Mittelpunkt steht. Für jeden Anforderungsbereich wird dabei die Stärke der Einflussnahme auf jedes einzelne Nutzenpotential diskutiert und bewertet. Die Anforderungsprioritäten ergeben sich anschließend aus der Multiplikation der Einflussfaktoren mit den Prioritäten der Nutzenpotentiale, die sich aus den relativen Gewichtungen der Nutzen ableiten lassen. Teilprojekte/ Maßnahmen Konfigurationsmanagement

Nutzenpotentiale/ Projektziele

Wettbewerbsfaktoren

Ergebnis

Aufwand Info.suche/Zugriff Preis

Dokumentenmanagement

Qualität Teilewiederverwendung Umsatz

Änderungsmanagement Änderungshäufigkeit CAxIntegration

ERPIntegration

Zeit Menge

Sachkosten Archiv/Repro Gewinn Kosten

...

...

6.6 Pflichtenheft und modellbasierte Dokumentation

231

Abb. 6-12: Ursache-Wirkungs-Beziehung als Grundlage für die NutzenPotentialrechnung und Priorisierung

Die Einführung wird in drei aufeinander aufbauende zeitliche und ressourcenbegrenzte Leistungsstufen aufgeteilt. Jede Leistungsstufe sollte innerhalb von drei bis sechs Monaten implementiert und produktiv gesetzt werden. Dabei wird darauf geachtet, dass mit jeder abgeschlossenen Leistungsstufe definierte Ziele erreicht werden. Während des Projektes wachsen die Anforderungen üblicherweise im Laufe der Zeit. Um keine Chance zu verbauen, wird darauf geachtet, flexibel reagieren zu können. Aber auch hier heißt die Leitlinie: „Konzentration auf das wirtschaftlich Sinnvolle und nicht auf das technisch machbare“. Einen weiteren Punkt für Einsparungen bei der Einführung eines PDMSystems sieht die KPMG bei der Systemauswahl. Man versucht den Vorgang durch „Prototyping statt Benchmarking“ zu beschleunigen. Als Grund, eine Auswahl nicht auf der Basis eines Benchmarks durchzuführen, wird die Unvorhersehbarkeit aller Anforderungen genannt. Statt des Erstellens eines detaillierten Anforderungskatalogs und BenchmarkingUnterlagen empfiehlt die KPMG, sich bei einer System-Demonstration vorwiegend ein Bild über die Flexibilität, Erweiterbarkeit, Offenheit und Anwenderfreundlichkeit der Software zu machen. Durch ein Prototyping des Anbieters sollte sich der Kunde zeigen lassen, wie schnell das System im Hinblick auf die wichtigsten Prioritäten angepasst werden kann. Die nutzenorientierte Einführung ist ein an den wirtschaftlichen Bedürfnissen ausgerichtetes Verfahren. Der Schwerpunkt liegt bei der Anforderungsanalyse und der tatsächlichen Umsetzung der Anforderungen. Durch Selektion der Anforderungspunkte, welche einen hohen Return on Investment bzw. kurze Amortisation versprechen, versucht man eine hohe Wirtschaftlichkeit der Einführung zu erreichen. Über konkrete Techniken zur Einführung eines PDM-Systems nach der Anforderungsanalyse wird jedoch nichts erwähnt. Es kann dadurch allerdings für die Einführung von Standardsoftwaresystemen im Allgemeinen angepasst werden.

6.6

Pflichtenheft und modellbasierte Dokumentation

Eine wichtige Tätigkeit innerhalb des Software-Entwicklungsprozesses bzw. Systemeinführungsprozesses stellt das Definieren der Anforderungen an ein Informationssystem dar (Balzert 1992). Bevor innerhalb der Systemeinführung mit der Konzeption begonnen wird, müssen zunächst die Anforderungen an das einzuführende System ermittelt, festgelegt, beschrieben, analysiert und verabschiedet werden.

232

6 Technische und methodische Grundlagen

Die Methoden, Beschreibungshilfsmittel und Werkzeuge zur Erhebung, Formulierung und Analyse der Benutzeranforderungen werden unter dem Oberbegriff Anforderungsermittlung oder Requirements-Engineering zusammengefasst. Im Einzelnen gehören hierzu die Techniken zur Erhebung der Benutzerwünsche, Hilfsmittel zur Formulierung und Beschreibung der Anforderungen sowie Verfahren zur Überprüfung der SollKonzepte hinsichtlich der Erfüllung der Anforderungen. Nach diesen Tätigkeiten wird ein schriftlicher Katalog aller Leistungsanforderungen zusammengestellt. Dieser Katalog wird als Lastenheft bezeichnet, aus dem in der nächsten Phase des Einführungsprozesses das Pflichtenheft entsteht. Nach der VDI/VDE-Richtlinie 3694 wird ein Pflichtenheft als Beschreibung aller Anforderungen des Lastenheftes definiert (VDI/VDE 3694). In ihm werden die Anwendervorgaben detailliert, die im Lastenheft zusammengestellt wurden, und die Realisierungsanforderungen beschreiben. Das Lastenheft enthält alle Anforderungen aus Anwendersicht einschließlich aller Randbedingungen. 6.6.1

Inhalt eines Pflichtenheftes

Der Inhalt eines Pflichtenheftes zur Beschaffung von Informatikmitteln sollte im Wesentlichen aus folgenden Punkten bestehen (Schreiber 1994) (Grupp 2003): • Darstellung der gegenwärtigen Situation, d. h. des Ist-Zustandes mit den bestehenden Abläufen und den eingesetzten Hilfsmitteln sowie den Problemen und Schwachstellen • Formulierung der Ziele, die mit der Beschaffung erreicht werden sollen • Beschreibung der zu lösenden Aufgaben mit ihren spezifischen Anforderungen (Anforderungsprofil) • Aufstellung eines Mengengerüstes der Datenbewegungen und Datenbestände bzw. Zahl und Häufigkeit der Geschäftsvorfälle • Vorgaben für die Struktur des Angebots durch den Anbieter ergänzt um die bei anderen Beschaffungsvorhaben üblichen Punkte wie z. B.: • Ausgangslage des Nutzers oder Anwenders, • Angaben zu administrativen Belangen und • einen Fragenkatalog. • Anforderungen an den Lieferanten und zeitlicher Rahmen Eine Standardgliederung eines Pflichtenheftes zur Softwarebeschaffung kann den folgenden Inhalt haben (s. Tabelle 3 u. Tabelle 4) (Grupp 2003):

6.6 Pflichtenheft und modellbasierte Dokumentation

233

Tabelle 3. Standardgliederung eines Pflichtenheftes 1

Vorbemerkung zum gewünschten Angebot

2 2.1 2.2 3 3.1 3.2 3.3 4 4.1 4.2 4.5 4.6 5 5.1 5.2 6 6.1 6.2 7 8 9 10 11 11.1 11.2 11.3

Unternehmenscharakteristik Branche, Produktgruppe, Dienstleistungen Unternehmensgröße, Wachstumsrate Ist-Zustand der Arbeitsgebiete Bisherige Verfahren und Hilfsmittel Unternehmensspezifische Besonderheiten Bewertung des Ist-Zustandes Zielsetzung Quantifizierbarer Nutzen Qualitative Nutzenpotentiale Werkstattrobustheit Erreichbare Qualität der hergestellten Werkstücke Mengengerüst Stamm- und Grunddaten Bestands- und Bewegungsdaten Fachliche Anforderungen Funktionsüberblick und Prozessbeschreibung Detaillierte Anforderungen an die Arbeitsgebiete Hardware- und systemtechnische Anforderungen Mitarbeiter für die Umstellung Anforderungen an die Lieferfirma Zeitlicher Realisierungsrahmen Angebotsinhalt und -aufbau Angebotsaufbau Preise und Vertragsbedingungen Abgabetermin des Angebots Anlagen zum Pflichtenheft

Die nachfolgende Tabelle (s. Tabelle 4) enthält die inhaltlichen Punkte eines Pflichtenhefts nach VDI/VDE Richtlinie 3694 für den Einsatz von Automatisierungssystemen (VDI/VDE 3694). Diese Richtlinie bezieht sich nicht ausschließlich auf Informationssysteme, kann aber als Anhaltspunkt für die Erstellung eines Pflichtenheftes herangezogen werden.

234

6 Technische und methodische Grundlagen

Tabelle 4. Anhaltspunkte für die Erstellung eines Pflichtenheftes 1

Einführung in das Projekt

2 Beschreibung der Ausgangssituation 3 Aufgabenstellung 4 Schnittstellen 5 Anforderungen an die Systemtechnik 6 Anforderungen an die Inbetriebnahme und den Einsatz 7 Anforderungen an die Qualität 8 Anforderungen an die Projektabwicklung Das Pflichtenheft für Automatisierungssysteme enthält zusätzlich zu den 8 Elementen des Lastenheftes die beiden weiteren Gliederungspunkte 9 Systemtechnische Lösung 10 Systemtechnik (Ausprägung) Ferner einen Anhang mit folgenden Punkten: 1 Begriffe und Definitionen 2 Abkürzungen 3 Nomenklatur Gesetzte, Normen, Richtlinien 6.6.2

Anforderungen für den Software-Entwurf

Bei der Formulierung der Anforderungen an ein Informationssystem steht in der Regel die Applikationssoftware mit ihren funktionalen und datenspezifischen Aspekten im Vordergrund. Auf Basis der Geschäftsprozesse, der Daten, die durch die einzelnen Organisationseinheiten fließen und der benötigten Unterstützungsfunktionen sind Applikationen zu bilden. Eine Applikation stellt in der Regel eine komplexe Aufgabenstellung dar, weshalb sie bei der Beschreibung der Anforderungen in immer besser überschaubare Teile zerlegt wird. Für diese Applikationen sind die Anforderungen an den Funktionsumfang, an die Daten und die übrigen Softwarequalitätsmerkmale wie Wartbarkeit, Effizienz, Benutzbarkeit usw. zu stellen (Schreiber 1994).

6.6 Pflichtenheft und modellbasierte Dokumentation

Geschäftsprozess z. B. Vertriebsabwicklung

Applikation „was“

Teilapplikation 1

Teilapplikation 2

Aufgabe 1

Teilaufgabe 1

Teilapplikation 3

Aufgabe n

Teilaufgabe 2

235

Teilaufgabe 3

Teilprozess z. B. Offertabwicklung, Auftragsabwicklung, Retourenbehandlung

Aufgabe z. B. Auftragserfassung, Pflege der Kundendateien

Teilaufgabe z. B. Telefonverkauf, Lagerverkauf Terminaufträgev

Abb. 6-13: Beispiel für die Strukturierung administrativer Applikationen Anforderungen an Funktionen und Daten

Eine Applikation kann unterschiedlich tief strukturiert werden. Deshalb ist es zweckmäßig, die Anforderungen auf zwei bis fünf Ebenen zu strukturieren, um eine Vergleichbarkeit zwischen Anforderungsprofil und Leistungsprofil zu gewährleisten. So kann eine Applikation beispielsweise in Teilapplikationen, Aufgaben und Teilaufgaben gegliedert werden (s. Abb. 6-13). Die Anforderungen an die einzelnen Aufgaben und Teilaufgaben müssen durch eine geeignete Methodik beschrieben werden. Dies geschieht am zweckmäßigsten durch die Darstellung oder Beschreibung: • der Eingangsdaten, • der Aufgabe/Teilaufgabe selbst mit ihren relevanten Funktionen und Daten, • des Ausgangsdaten und • der Verknüpfungen nach außen oder zu anderen Aufgaben oder Applikationen. Da diese Beschreibungsformen teilweise bei CASE-Umgebungen anzutreffen sind, können diese zur Beschreibung der Anforderungen eingesetzt werden.

236

6 Technische und methodische Grundlagen

Übrige Softwarequalitätsmerkmale

Meist ist es ausreichend, die übrigen Softwarequalitätsmerkmale pro Applikation lediglich einmal zu beschreiben. Hierzu zählen: • • • • • •

Effizienz und Leistung, Zuverlässigkeit und Robustheit, Benutzungsfreundlichkeit, Datenschutz/Sicherheit, Wartbarkeit und Anpassungsfähigkeit sowie Systemunabhängigkeit und Offenheit

6.7

Systemevaluation

Die Bewertung bzw. Evaluation eines Integrationssystems der Umsetzung der Systemlösung kann an zwei Stellen in einem Spiralzyklus des Vorgehensmodells erfolgen. Vor der Systemauswahl wird die Bewertung anhand so genannter Benchmarks durchgeführt und nach der vollständigen Implementierung wird die Funktionsfähigkeit durch Systemtests geprüft. 6.7.1

Nutzwertanalyse

Die Nutzwertanalyse stellt eine in der Praxis seit langem bewährte Methode für den Vergleich von Handlungsalternativen oder Systemen dar. Das Ergebnis der Analyse ergibt für jede der Alternativen eine Zahl, die den Nutzwert der Alternative darstellt. Die am besten geeignete Lösung erhält dabei den höchsten Nutzwert. Bei der Bewertung können die Alternativen vor allem auch an solchen Kriterien gemessen werden, die nicht in Geldeinheiten ausgedrückt werden können. Hierdurch stellt die Nutzwertanalyse eine Ergänzung zu den Verfahren der Wirtschaftlichkeitsrechnung dar. Die methodischen Arbeitsschritte sind (Nutzwertanlyse): • bestimmen von Bewertungskriterien, anhand derer die Alternativen verglichen werden sollen • festschreiben der Bedeutung der Bewertungskriterien nach den Präferenzen des Entscheidungsträgers • bewerten der Kriterienerfüllung durch Vergabe von Erfüllungsgraden • ermitteln der Gesamtnutzwerte der einzelnen Alternativen: Für jedes Bewertungskriterium den Gewichtungsfaktor mit der „Güte“ der Zielerfüllung multiplizieren, die „Teilnutzwerte“ über alle Bewertungskriterien zu einem Gesamtnutzwert der Alternative addieren.

6.7 Systemevaluation 6.7.2

237

Benchmarks

Die übliche Vorgehensweise für den Vergleich von Software-Systemen ist die Durchführung von Benchmarks. Dabei werden für das Unternehmen typische Referenzszenarien definiert, an Hand derer die Systemanbieter ihre ganz spezielle Produkteignung bzw. Lösungskompetenz demonstrieren. Die jeweiligen Systemanbieter werden an Hand von Kriterienkatalogen oder Referenzkunden ermittelt. Da die unterschiedlichen Anforderungen der Unternehmen an ein Integrationssystem meist umfangreiche Anpassungen an die unternehmensspezifischen Prozesse und eine enge Verzahnung mit anderen IT-Systemen erfordern, kann ein optimal geeignetes Integrationssystem nicht durch das Testen der vollständigen Lösung evaluiert werden. Je individueller der Einsatz eines solchen Systems erfolgen soll, umso weniger können die funktionalen technischen Details der Systeme im Benchmark getestet werden, sondern es stehen verstärkt die Anpassungsmöglichkeiten und -aufwände des Systems in das Unternehmen im Vordergrund. In der Regel werden deshalb bestimmte unternehmenstypische, wichtige Szenarien ausgewählt, an Hand derer die Benchmarks durchgeführt werden. Typische Referenzszenarien für Benchmarks könnten beispielsweise folgende Aspekte beinhalten (Kahlert 2001): • Integration bereits vorhandener Standard- und Individualsoftware, • Anbindung an das unternehmensweite Enterprise Ressource Planning, • Kooperative Zusammenarbeit heterogener Integrationssysteme innerhalb derselben Firma und zwischen deren Geschäftspartnern, • Migrationsmöglichkeit von Altdatenbeständen, • Unterstützung firmeninterner Standards und Richtlinien sowie • Eignung zum Einsatz innerhalb aktuell laufender bzw. geplanter Projekte. Bei der Auswahl der Benchmarkszenarien kann auf das Unternehmensmodell mit den aufgenommenen Ist- bzw. Soll-Prozesse zurückgegriffen werden. Die dort erstellten Diagramme erleichtern unter anderem die Verständigung zwischen den beteiligten Parteien und eine klare Definition der Szenarien. Zur Auswertung des Benchmarks eignet sich die Nutzwertanalyse, bei der über Zielwertgewichtung die benutzerspezifischen Schwerpunkte mit dem jeweiligen Erfüllungsgrad ins Verhältnis gesetzt werden. Die durch den Benchmark ermittelte Bewertung der Systeme sollte rein technisch sein. Der endgültige Systemvorschlag wird dann durch zusätzliche wirtschaftliche und strategische Untersuchungen ergänzt.

238 6.7.3

6 Technische und methodische Grundlagen Systemtests

In der PLM-Implementierungsphase wird die geforderte Funktionalität direkt am Softwaresystem überprüft. Zunächst werden dabei so genannte Integrationstests durchgeführt, die das Zusammenwirken von einzelnen Softwaremodulen oder Applikationen überprüfen. Am Ende der Implementierungsphase wird die Funktionalität des Gesamtsystems in der Einsatzumgebung, d. h. auf der vorgesehenen Hardware und Infrastruktur, getestet. Man bezeichnet diesen Test, der noch vom Softwarehersteller durchgeführt wird, als Systemtest. Der Abnahmetest erfolgt im Anschluss beim Auftraggeber mit dessen Daten, in der Regel als Probebetrieb des Integrationssystems. Werden bei diesen Tests Fehler festgestellt, müssen diese behoben werden. Kleinere Änderungen oder Fehlerbehebungen werden dabei direkt am Integrationssystem durchgeführt. Wenn in einer der Testphasen Fehler festgestellt oder Änderungen durchgeführt wurden, wird eine neue Iteration gestartet. Bei größeren Mängeln kann unter Umständen die Phase der Systemkonzeption erneut angestoßen werden. Änderungen, die in der Testphase isoliert direkt am System durchgeführt wurden, müssen in dem Modell zum Systemkonzept dokumentiert werden. Dadurch wird sichergestellt, dass die planerische Ebene im Unternehmensmodell und die produktive Ebene in Form der Systeme zu jedem Zeitpunkt konsistent sind. Falls keine weitern Änderungen mehr notwendig sind, kann das System in Betrieb genommen werden.

6.8

Betriebwirtschaftliche PLM-Aspekte

Aufgrund der unternehmensweiten Einführung und den damit verbundenen Zeit- und Kostenaufwand muss die Wirtschaftlichkeit einer PLMInvestition sowohl im Vorfeld als auch im laufenden Betrieb hinreichend bewertet werden. Ziel der wirtschaftlichen Bewertung der PLM-Investition ist es, jeden durch den Einsatz entstandenen Nutzen zu erfassen und mit Hilfe betriebswirtschaftlicher Verfahren mit den Kosten in Relation zu bringen. Die Wirtschaftlichkeitsanalyse eines Integrationssystems wird zu zwei verschiedenen Zeitpunkten durchgeführt: • bei der Einführung als Abschätzung (prospektive oder ex-ante Betrachtung) • 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

6.8 Betriebwirtschaftliche PLM-Aspekte

239

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 Investition tatsächlich lohnend ist und dient als Grundlage zur Kontrolle des Investitionserfolges. 6.8.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.

W =

¦ zukünftige bzw. erbrachte Leistungen ¦ geplante bzw. erbrachte Kosten

Der Nutzen wird aus allen erbrachten Leistungen, welche die Anwendung bewirkt, bestimmt. 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 lassen sich in einmalige und laufende Kosten unterteilen. Eine Möglichkeit zur Gliederung der Kosten ist, dass die einmaligen Kosten den verschiedenen Phasen der PLMEinführung und die laufenden Kosten ihrer Entstehungsursache zugeordnet werden (Schreuder u. Fuest 1998). 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.

240

6 Technische und methodische Grundlagen

Einmalige Kosten

Die einmaligen Kosten fallen bei der Einführung sowie beim späteren Ausbau von PLM an und werden über die Nutzungsdauer abgeschrieben. Zur Abschreibung mit den Laufzeiten von etwa drei Jahren lässt sich eine lineare oder degressive Methode verwenden, wobei das degressive Verfahren aufgrund des raschen technologischen Fortschritts bevorzugt wird. Laut VDI-Richtlinie 2219 (VDI 2219) sollte heute die Abschreibungsdauer für IT-Systeme nicht länger als drei Jahre betragen. Zu den einmaligen Kosten zählen Kosten für Planungen der PLM-Investition, Systembeschaffungskosten sowie Systemeinführungskosten, zu denen im Folgenden einige Kostenpunkte aufgezählt werden: Planungskosten:

• Reorganisationsmaßnahmen • Ist-Analyse • Konzepterarbeitung • Machbarkeitsstudien • Entscheidungsfindung • Systemauswahl • Informationsveranstaltungen (Messe, Kongresse, Workshop etc.) • Externe Dienstleistungen Systembeschaffungskosten:

• Hardware • Server (Datenbank und Anwendung) • PC • Backup-System • Netzwerk • Software • Server- und Client-Lizenzen der PLM-Software • Client-Lizenzen der Netzwerksoftware • Lizenzen der ergänzenden Software (Datenbanken, Konvertierung usw.) Systemeinführungskosten

• System-Installation • Software-Implementierung (Systemanpassung)

6.8 Betriebwirtschaftliche PLM-Aspekte

• • • • • •

241

Implementierung der Schnittstellen Integration von Applikationen Systemtest Altdatenübernahme Support und Beratung Schulung

Laufende Kosten

Die laufenden Kosten der PLM-Investition lassen sich in direkte und indirekte Betriebskosten sowie Gemeinkosten unterteilen. Im Folgenden werden einige der wesentlichen laufenden Kosten der PLM-Investition aufgelistet: Direkte Betriebskosten

• Personalkosten für Systemanwendung • Materialkosten (Nutzung von Datenträgern, Papier, Formularen, sonstige Verbrauchsmaterialien) Indirekte Betriebskosten

• • • • •

Wartung der Hardware und Software Administration von PLM und ergänzender Software laufende Anpassung von Geschäftsprozessen laufende Anpassung des Integrationssystems laufende Integration mit internen und externen Anwendung (Entwicklung geeigneter Schnittstellen) • laufende Weiterbildung der Anwender • sonstige Kosten • Teilnahme an PLM-Konferenzen und Anwendergruppen • Opportunitätskosten (Systemausfall oder Systemfehler) Gemeinkosten

• • • • • •

Zinsen Mieten Versicherungen Energiekosten Raumkosten Verbrauchsmaterial

242

6 Technische und methodische Grundlagen

Andere Kosten und Einsparungen

Neben den oben genannten Kostenarten sind noch Kosten von Interesse, 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 VDI-Richtlinie (VDI 2219) angeführt: • • • • •

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

6.8.2

Nutzenanalyse

Der Einsatz eines Integrationssystems im Unternehmen bringt viele Vorteile, die aber in der Regel 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 Systemseinsatzes sowie von der Akzeptanz- und Lernkurve der Anwender abhängig. Oft wird der Nutzen sich erst mit zunehmender Betriebsdauer steigern und sich mittelbis langfristig vorteilhaft für das Unternehmen auswirken. Demnach lassen sich die Nutzenaspekte eines PLM-Einsatzes nach den folgenden Gesichtspunkten beschreiben: • nicht strategischer Nutzen Ist der Nutzen, der durch Verbesserung der innerbetrieblichen Abläufe entsteht, wie z.B. Produktivitätssteigerungen, direkte Kosteneinsparungen, Qualitätsverbesserungen und Zeiteinsparungen. • 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 IT-System immer mehr an Bedeutung.

6.8 Betriebwirtschaftliche PLM-Aspekte

243

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 aber weiterhin als Mittel zur Planung und Kontrolle von Sachverhalten. Beispielsweise wird bei 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): • Die Werte müssen auf einer eindeutigen Definition basieren. • Es ist nicht ausreichend nur z. B. von Verfügbarkeit zu sprechen. Es bedarf hier einer Präzisierung nach System, Anwendung, Benutzer, Betriebssystem usw. • Kennzahlen müssen messbar sein. • Die Quellen der Ermittlung dürfen nicht unterschiedlich sein. • 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 (Wertgröße, Mengengröße) Strukturen, nach Planungsgesichtpunkten (SollKennzahlen, Ist-Kennzahlen) und nach statisch-methodischen Gesichtpunkten. Nach dem letzten Merkmal lassen sich die Kennzahlen in absolute Zahlen und Verhältniszahlen einteilen. Schwierigkeiten bei der Nutzenerfassung

Zur Beurteilung der Wirtschaftlichkeit von Product Lifecycle Management muss der gesamte Nutzen den gesamten 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 dann in der Dimension „Geldeinheit“ zu bewerten. Zur Erfassung des Nutzens stehen im Controlling verschiedene Quantifizierungsmethoden, wie beispielsweise die Bewertung der Zeitvorteile, zur Verfügung. Aufgrund der Vielfalt und Vielzahl möglicher Nutzenaspekte kann es hier keine allgemeingültigen Verfahren geben. Vielmehr

244

6 Technische und methodische Grundlagen

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 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 oft nur schwieriger durchzuführen. 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 direkt 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 indem auch die Kosten entstehen. Da jede Abteilung in der Regel eine eigene Kostenstelle hat, führt dies zum Problem, dass die Kosten einer Kostenstelle nicht immer mit den Nutzen kompensiert werden können, die an einer anderen Kostenstelle entstanden sind. 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 die Kosten für den PLM-Einsatz als Gemeinkosten auf alle Unternehmensbereiche zu verteilen. 6.8.3

Wirtschaftlichkeitsanalyse eines Integrationssystems

Für den Nachweis der Wirtschaftlichkeit von Investitionsobjekten hinsichtlich quantifizierbarer Unternehmensziele (Gewinn, Rentabilität usw.) stehen in der Betriebswirtschaftlehre verschiedene mathematische Methoden zur Verfügung, mit deren Hilfe 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 wird. Die Wirtschaftlichkeitsberechnungsverfahren oder Investitionsrechnungsverfahren lassen

6.8 Betriebwirtschaftliche PLM-Aspekte

245

sich in die zwei Hauptgruppen der statischen und der dynamischen Verfahren einteilen. In den folgenden beiden Tabellen (Tabelle 5 und

Tabelle 6) werden einige der Methoden sowie deren Vorteile und Nachteile bezüglich der PLM-Thematik in Stichpunkten genannt. Tabelle 5. Spezifische Vor- und Nachteile der statischen Methode 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. Vergleich von realisierten mit nicht realisierten Gewinnen

Rentabilitätsrechnung

Amortisationsrechnung (ohne Berücksichtigung von Zinsen)

Nur Aussage über die Ertragskraft einer PLMInvestition bis zum Wiedergewinnungszeitpunkt des Kapitals.

246

6 Technische und methodische Grundlagen

Tabelle 6. 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. 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

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.

6.9

Modellierung

Unter Modellierung versteht man im Allgemeinen die Abstraktion eines Elementes, das real oder gedacht ist, durch Erstellung einer Repräsentation. Für das Product Lifecycle Management und dessen informationstechnische Unterstützung sind in diesem Zusammenhang vor allem Modelle zur Beschreibung eines Unternehmens, dessen Prozessen und Organisationsstrukturen sowie Modelle zur Beschreibung von Daten und deren Verknüpfungen im Informationssystem von Bedeutung.

6.9 Modellierung 6.9.1

247

Grundlagen der Unternehmensmodellierung

Zur Reduzierung der Komplexität der Unternehmensmodellierung wurden zahlreiche Methoden entwickelt. Etabliert haben sich u.a. Methoden von Scheer und Milde (Scheer 1991), (Milde 1997). Sie basieren überwiegend auf graphischen Darstellungstechniken unterschiedlicher Sachverhalte. Einige dieser Methoden führten zur Entwicklung rechnerunterstützter Werkzeuge. Existierende Methoden und Werkzeuge zur Unternehmensmodellierung unterscheiden sich vor allem durch: • deren Zielsetzung, • das enthaltene Vorgehensmodell, • den Grad der Unterstützung während der einzelnen Modellierungsphasen von der Analyse über die Gestaltung bis hin zu planerischen, dokumentarischen und operativen Anwendungsbereichen, • den angewandten Modellierungstechniken, • den Umfang der Beschreibungselemente und • den Grad der Integration des zugrunde liegenden Modellschemas. Der steigende Wettbewerbsdruck zwingt die Unternehmen zu einer permanenten Überprüfung und Optimierung ihrer organisatorischen Strukturen und Abläufe. Dazu ist ein umfassender Überblick über die Geschäftsprozesse des Unternehmens eine notwendige Voraussetzung. Die Unternehmensmodellierung ist lediglich ein Ansatz, um den wachsenden Anforderungen an Flexibilität, Reaktionsschnelligkeit und Kundenorientierung gerecht zu werden, indem die im Rahmen der Geschäftsprozessgestaltung entwickelten Modelle schnell in Informationssystemen realisiert werden. Geschäftsprozesse bieten dabei einen geeigneten Ansatzpunkt für die Unternehmensmodellierung, da über sie die Verbindung zwischen Wettbewerb, Unternehmenszielen und Gestaltungsmaßnahmen hergestellt werden kann (Bullinger u. Schreiner 2001). Der wesentliche Anreiz der heutigen Unternehmensmodellierung liegt weniger in der isolierten Erstellung von Modellen für einzelne Anwendungsbereiche, sondern vielmehr in der Integration vieler Teilmodelle zu einem anwendungsübergreifenden Gesamtmodell. Auf diese Weise wird die gemeinsame Nutzung von Daten effizient gefördert. Der Ursprung der Unternehmensmodellierung liegt in den Modellierungs- und Analysetechniken der späten 60er und frühen 70er Jahre. Für die Beschreibung von informationsverarbeitenden Prozessen wurde eine grafische Notation benötigt (Reithofer 1997). Es entstanden Darstellungsmethoden wie Datenflussdiagramme (DFD), Hierarchy plus Input Process Output (HIPO), Structured Analysis (SA), Structured Design (SD), Structured Analysis and Design Technique (SADT) und Entity-

248

6 Technische und methodische Grundlagen

Relationship-Modell (ERM). Für die Beschreibung paralleler oder nebenläufiger Prozesse eigneten sich am besten Petri-Netze. Auf Basis dieser und einiger anderer Darstellungsmethoden wurden Ansätze für Unternehmensmodelle entwickelt, die sich hauptsächlich dadurch unterscheiden, dass sie je nach Anwendungsbereich unterschiedliche Methoden zu deren Darstellung kombinieren. Einige wichtige Ansätze sind: • Computer Integrated Manufacturing – Open System Architecture (CIMOSA), entwickelt im Rahmen verschiedener europäischer Forschungsprojekte (DIN V ENV 40003). • Architektur integrierter Informationssysteme (ARIS), entwickelt am Institut für Wirtschaftsinformatik der Universität des Saarlandes (Scheer 1991). • MERGE, entwickelt am Forschungsbereich Prozess- und Datenmanagement im Engineering (PDE) des Forschungszentrums Informatik (FZI) in Karlsruhe (Forschungszentrum Informatik Karlsruhe 2001). Der Ansatz CIM-OSA hat bisher auf dem kommerziellen Markt für Unternehmensmodellierungssoftware keine Bedeutung erlangt. Im Gegensatz dazu ist die auf dem ARIS-Ansatz basierende Werkzeugfamilie ARISToolset Marktführer und hat damit eine dementsprechende Bedeutung erlangt. MERGE wird im kommerziellen Umfeld vor allem für das Customizing von PDM-Systemen eingesetzt. 6.9.2

Grundlagen der Datenmodellierung

Datenmodelle sind ein wichtiges Hilfsmittel zur Gestaltung von Datenbanken und zur Entwicklung von Software. Sie ermöglichen es, grundlegende Zusammenhänge zu erkennen, zu strukturieren und zu dokumentieren. Unified Modelling Languaguage (UML)

UML ist eine objektorientierte Modellierungssprache zur Erstellung, Spezifikation, Visualisierung und Dokumentation objektorientierter Softwaresysteme. Der Grundgedanke bei der UML bestand darin, eine einheitliche Notation für möglichst viele Einsatzgebiete zu haben. Die UML stellt für Modellierungsaufgaben verschiedene Diagramme mit unterschiedlichen Darstellungsarten bereit:

6.9 Modellierung

249

• Anwendungsfälle, Use Case Modelle • Statische Modelle • Klassen- und Instanzdiagramme • Dynamische Modelle • Interaktionsdiagramme: Sequenz- und Kollaborationsdiagramme • Zustandsdiagramme Dabei stellen Klassen- und Instanzdiagramme für die Beschreibung eines Datenmodells die wichtigsten Diagrammtypen dar. Klassendiagramme stellen die graphische Notation und die Semantik für die Modellierung von Klassen und ihre Beziehungen zueinander dar. Eine Klasse beschreibt eine Gruppe von Objekten mit: • • • •

ähnlichen Eigenschaften (Attributen), gemeinsamen Verhalten (Operationen), gemeinsamen Beziehungen zu anderen Objekten und gemeinsamer Semantik.

Instanzdiagramme werden für die Beschreibung von Testfällen oder Beispielen verwendet, da sie konkrete Ausprägungen von Klassen darstellen. Assoziation Aggregation Rechteck Position Größe Farbe verschieben löschen Größe_ändern Farbe_ändern

Klassenname

Komposition

Attribute

oder

Vererbung Navigations fähigkeit

Operationen

Kardinalitäten 1

0..1

1: 0,1

1

*

1: n, n>=0

m

n

m: n

Abb. 6-14: Elemente eines Klassendiagramms in der UML-Notation

250

6 Technische und methodische Grundlagen

Eine Klasse wird in UML als Rechteck dargestellt. Ein Attribut ist ein Datenwert (z. B. X-Koordinate, Y-Koordinate), den die Objekte einer Klasse besitzen. Eine Operation (verschieben, löschen) ist eine Funktion oder Transformation, die auf Objekte einer Klasse angewendet werden kann. Eine Methode ist die Implementierung einer Operation für eine bestimmte Klasse. Die Benennung einer Klasse sollte aus dem Sprachgebrauch des Anwendungsgebietes abgeleitet werden und sollte ein einzelnes Objekt der Klasse beschreiben. Auch die Benennungen von Attributen und Methoden sollte dem Anwendungsgebiet entstammen. Weitere Elemente eines Klassendiagramms sind in Abb. 6-14 dargestellt. Eine Assoziation beschreibt eine Beziehung zwischen den Objekten zweier Klassen. Assoziationen haben einen bidirektionalen Zugriffspfad. In der Entwurfsphase müssen jedoch nicht beide Richtungen implementiert werden. Die Kardinalität einer Assoziation spezifiziert, wie viele Objekte einer Klasse mit einem Objekt einer assoziierten Klasse verknüpft sein können und begrenzt die Anzahl der beteiligten Objekte. Eine Aggregation ist eine gerichtete Assoziation zwischen zwei Klassen. Die Aggregation ist somit ein Spezialfall der Assoziation. Sie liegt vor, wenn zwischen den beteiligten Klassen eine Rangordnung gilt, die mit den Worten „ist Teil von“, „besteht aus“ oder „hat“ geschrieben werden kann. Eine Komposition ist ein Spezialfall der Aggregation, bei der die Teile vom Ganzen existenzabhängig sind.

TechnischeZeichnung Zeichnungsname: String Status: String

1 besteht aus

* Linie Linienname: String

1..* wird begrenzt durch

2

Eckpunkt Eckpunktname: String

Linienart: String

x-Wert: Float

Linienbreite: Float

y-Wert: Float

Abb. 6-15: Vereinfachtes Datenmodell einer technischen Zeichnung als UML Klassendiagramm

6.9 Modellierung

251

Eine Generalisierung (Vererbung) ist eine „ist ein“-Beziehung, um Ähnlichkeiten und Unterschiede zwischen Klassen zu modellieren. Die Oberklasse (Basisklasse) besitzt die gemeinsamen Attribute und Operationen. Jede Unterklasse (abgeleitete Klasse) fügt weitere individuelle Attribute und Operationen hinzu. Dabei erbt eine Unterklasse alle Attribute, Operationen und Beziehungen ihrer Oberklasse. Eine Unterklasse kann aber die Implementierung einer Operation neu definieren (überschreiben). Die Anwendung von Klassendiagrammen wird in Abb. 6-15 am Beispiel des vereinfachten Modells einer technischen Zeichnung demonstriert. Ein Anwendungsdiagramm ist die graphische Darstellung der Interaktion zwischen einem Anwender (Akteur) und einem Softwaresystem. Anwendungsdiagramme dienen im Wesentlichen zur Verdeutlichung der Anwendungsfälle des Softwaresystems, um so Anforderungen genauer spezifizieren zu können. Die dynamischen Modelle werden zur Beschreibung von Interaktionen und Kommunikation zwischen Objekten genutzt. In Sequenzdiagramme wird der zeitliche Verlauf der Interaktion zwischen Objekten dargestellt. Ein Kollaborationsdiagramm zeigt die Kommunikation zwischen einer Menge ausgewählter Objekte in einer bestimmten begrenzten Situation (in der Regel für einen Use Case). Zustandsdiagramme beschreiben eine Folge von Zuständen, die ein Objekt im Laufe seines Lebens einnehmen kann und aufgrund welcher Ereignisse Zustandsänderungen stattfinden. EXPRESS

EXPRESS (ISO 10303-11) ist eine objektorientierte Datenmodellierungssprache, die im Rahmen der STEP-Entwicklung von der ISO entwickelt und genormt wurde. Neben der Möglichkeit der textuellen Repräsentation von Modellen ist ebenfalls die grafische Notation EXPRESS-G (s. Abb. 6-16) entwickelt worden. Ziel bei der Entwicklung dieser Modellierungssprache ist 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. 6-17 zeigt beispielhaft wie ein Datenmodell einer technischen Zeichnung in EXPRESS-G modelliert werden kann.

252

6 Technische und methodische Grundlagen

Schema-Symbole

Entity-Symbol

einfache Typen-Symbole

Schema

BINARY

BOOLEAN

STRING

REAL

INTEGER

NUMBER

Entity

Typ-Symbole TYPE NAME

ENUMERATION LOGICAL

SELECT

Beziehunssymbole

Referenz-Symbole

optional

page#, ref# name

schema. def alias

Subtyp

Abb. 6-16: Grafische Symbole in EXPRESS-G nach ISO 10303 Zeichnungsname

Technische_Zeichnung

Linienname

Linie

Linienart Linienbreite

Eckpunktname

Eckpunkt

x_Wert y_Wert

Status

STRING Zeichnungs_Status

STRING Linien_Typ REAL

STRING REAL REAL

Abb. 6-17: Darstellungsbeispiel einer technischen Zeichnung in EXPRESS-G

6.10 Methoden und Tools

253

6.10 Methoden und Tools Zur Unterstützung bei der Implementierung und der Anpassung von Standardsoftwaresystemen existieren zahlreiche Methoden und SoftwareWerkzeuge, die allgemein in die folgenden drei Kategorien unterteilt werden können: • Unternehmensmodellierungswerkzeuge unterstützen den Anwender bei der Modellierung der betriebswirtschaftlichen Abläufe und Prozesse. Diese Werkzeuge sind im Allgemeinen nicht auf bestimmte Systeme ausgerichtet. Die Modellierung erfolgt in der Sprache des Anwendungsumfeldes und abstrahiert von der Implementierung des Systems. • CASE-Tools unterstützen den Entwickler bei der Implementierung des Systems. Ein typisches Merkmal dieser Werkzeuge ist eine Funktion zur (teil-) automatischen Code-Generierung. Die Modellierungssprache orientiert sich im Allgemeinen an den Ausdrücken und Eigenschaften der Programmiersprache. • Systemspezifische Werkzeuge bilden einen Mittelweg zwischen Unternehmensmodellierungswerkzeugen und CASE-Tools. Sie unterstützen den Modellierungsprozess in der Sprache des Benutzungsumfeldes. Der große Vorteil von systemspezifischen Werkzeugen ist die Funktionalität zur (halb-)automatischen Implementierung eines Modells im System. Diese Werkzeuge sind allerdings im Allgemeinen auf ein spezielles Standardsoftwaresystem abgestimmt und auf dessen Anforderungen und Eigenheiten angepasst. Eine systemunabhängige Modellierung ist daher nicht möglich. 6.10.1 Unternehmensmodellierungswerkzeuge

Im Folgenden werden einige Beispiel für die verschiedenen Toolklassen vorgestellt. Eine ausführliche Studie der verschiedenen Werkzeuge wurde in einer Studie des Fraunhoferinstituts Arbeitswissenschaft und Organisation (Bullinger u. Schreiner 2001) durchgeführt. ARIS Toolset

Das ARIS Toolset basiert auf der von Prof. Scheer entwickelten Architektur integrierter Informationssysteme ARIS (Scheer 1991). Es zielt vornehmlich auf die Gestaltung und Dokumentation betrieblicher Informationssysteme. Die Architektur sieht vier Hauptaufgaben für ein Informationssystem vor:

254

6 Technische und methodische Grundlagen

• Organisation Beschreibung und Optimierung der Geschäftsprozessstruktur • kapazitäts-, zeit-, und kostenoptimale Planung der laufenden Geschäftsprozesse • Steuerung Steuerung der einzelnen Geschäftsvorfälle • Bearbeitung der einzelnen Funktionen. Diese Aufgaben sind den Ebenen eines Vier-Ebenenmodells zugeordnet, dem „ARIS – House of Business Engineering“. Auf der 1. Ebene „Prozessoptimierung“ werden die Geschäftsprozesse analog einer Arbeitsplanung in der Fertigung beschrieben. Aus der Sicht des „Business Process Owner“ werden auf der 2. Ebene „Prozessmanagement“ die laufenden Geschäftsprozesse eines Zeitraums geplant und verfolgt. Die Verantwortung für die gesamte Ablaufsteuerung liegt in einer eigenen Systemebene, der 3. Ebene „Workflow“. Auf dieser Ebene werden die zu bearbeitenden Objekte von Arbeitsplatz zu Arbeitsplatz transportiert. Bearbeitet werden diese Objekte respektive Dokumente auf der 4. Ebene „Bearbeitung“. Die vier Ebenen sind durch Regelkreise miteinander verknüpft (Scheer 2001). Zur Unternehmensmodellierung werden in ARIS die folgenden Beschreibungssichten benutzt (Keller 1999): • Funktionssicht Innerhalb der Funktionssicht wird das Informationssystem bezüglich Ablauffolge und Hierarchiebildung von Funktionen in Form von Funktionsbäumen untersucht. • Datensicht In der Datensicht wird eine logische Datenbasis des Anwendungsbereiches entworfen, die in den nachfolgenden Phasen in die konkrete Implementierung eines Datenbanksystems überführt wird. • Organisationssicht Die Darstellung der Organisation eines Unternehmens erfolgt in der Organisationssicht. • Steuerungssicht Die Steuerungssicht als zentrale Komponente definiert eine Verbindung der getrennt modellierten Daten, Funktionen und Organisationseinheiten. In dieser Sicht werden die Beziehungen zwischen den Teilsichten wiederhergestellt. Der ARIS Process Plattform liegt ein alle Sichten und Ebenen umfassendes Repository zugrunde. Geschäftsprozesse lassen sich modellieren, analysieren und optimieren respektive reorganisieren, um daraus zum Beispiel ein Soll-Konzept für die Einführung eines Standardsoftwaresys-

6.10 Methoden und Tools

255

tems zu generieren. Über die Analysekomponente hat der Benutzer die Möglichkeit, seine Modelle mit den Referenzmodellen eines Systemanbieters abzugleichen. Ist ein Standardsoftwaresystem eingeführt, kann die ARIS Process Plattform als Dokumentationssystem genutzt werden. Die Modellierung und die anschließende automatisierte Anpassung mehrerer Standardsoftwaresysteme sind mit der ARIS Process Plattform einige gängige ERP- und Middleware-Systeme möglich. MERGE-Tool

Das MERGE-Tool ist ein am Forschungszentrum Informatik (FZI) Karlsruhe im Forschungsbereich Prozess- und Datenmanagement im Engineering (PDE) entwickeltes Werkzeug zur Unternehmensmodellierung. Es basiert auf dem integrierten, objektorientierten Unternehmensmodell MERGE (Milde 1997). Das Modellschema von MERGE zur Abbildung von Unternehmen ist in aufeinander aufbauende Partialmodelle aufgeteilt. Dabei werden die einzelnen Unternehmensobjekte (Mitarbeiter, Informationen, Prozessschritte, Ressourcen etc.) eindeutig einem Partialmodell zugeordnet, so dass Beziehungen zwischen Unternehmensobjekten innerhalb eines Partialmodells sehr komplex und zwischen Partialmodellen relativ einfach sind. Die Beschreibung der Zusammenhänge erfolgt durch entsprechende Relationen. Das integrierte Unternehmensmodell von MERGE besteht aus folgenden Partialmodellen: • Aufbauorganisationsmodell: Die Beziehungen der organisatorischen Einheiten eines Unternehmens beschreibt das Aufbauorganisationsmodell. Eine Organisation steckt den Rahmen und die Regeln ab, mit denen das Personal zum Erreichen eines gemeinsamen Zieles effektiv zusammenarbeiten kann. Sie bestimmt Aufgaben, Verantwortlichkeiten und Weisungsstrukturen. • Ressourcenmodell: Das Ressourcenmodell beinhaltet die betrieblichen Ressourcen, wie beispielsweise Betriebsmittel, Hard- und Software, Standorte und auch die Mitarbeiter des Unternehmens. • Tätigkeitsmodell: Das Tätigkeitsmodell beschreibt die zur Erfüllung der Unternehmensziele auszuführenden Tätigkeiten. Diese sind hierarchisch strukturiert und soweit zerlegbar, bis sie einen nicht weiter sinnvoll aufteilbaren Vorgang darstellen. Eine Tätigkeit kann Informationen benötigen, erzeugen und transformieren. • Prozessmodell: Das Zusammenspiel von Tätigkeiten in Form von Prozessschritten beschreibt das Prozessmodell. Der dazu notwendige Steuerungsfluss wird mit Hilfe einer definierten Ablauflogik mit se-

256

6 Technische und methodische Grundlagen

quentiellen, parallelen, alternativen und zusammenführenden Strukturen abgebildet. Es können auch Rückkopplungen und Entscheidungen modelliert werden. • Objektflussmodell: Fast jede Ausführung einer Tätigkeit bedarf eines informatorischen Inputs. Der dadurch entstehende Informationsfluss und die möglichen Statusübergänge eines Informationsobjektes beschreibt das Objektflussmodell. • Datenmodell: Das Datenmodell dient der detaillierten Beschreibung von Objektklassen hinsichtlich ihrer internen Struktur und deren Beziehungen zu anderen Objektklassen. Ein Dokument kann beispielsweise eindeutig einer Abteilung zugeordnet sein, umgekehrt können in einer Abteilung mehrere Dokumente vorkommen. Solche betriebswirtschaftlichen Beziehungen werden in den Datenmodellen abgelegt. Die Verwendung eines objektorientierten Ansatzes für die Modellierung des Unternehmens gewährleistet die Integrität des Gesamtmodells. Damit die Übersicht bei der Modellerstellung und Modifikation gesichert ist, existieren verschiedene Projektionen bzw. Sichten auf einen festgelegten Teil des Unternehmensmodells. Eine Sicht kann Unternehmensobjekte aus verschiedenen Partialmodellen besitzen, es werden jedoch nur die für diese Sicht relevanten Beziehungen und Objekte in einem grafischen Editor visualisiert. Dadurch wird für den Anwender die Komplexität des Modellierungsprozesses reduziert. In Abb. 6-18 ist das Sichtenkonzept dargestellt, das sich an den einzelnen Partialmodellen orientiert. Das Sichtenkonzept ermöglicht das Hinzufügen von beliebigen Sichten, ohne das Unternehmensmodellschema modifizieren zu müssen.

Prozesssicht Ressourcensicht Unternehmensmodell Tätigkeits-/ Informationsflusssicht

Integrierte Sicht

Objektsicht

Oraganisationssicht

Abb. 6-18: Sichten auf das integrierte Unternehmensmodell MERGE

6.10 Methoden und Tools

257

Für die Modellierung von Geschäftsprozessen ist die wichtigste Sicht auf das Unternehmensmodell die Prozess-Sicht. Zur Bearbeitung des Unternehmensmodells stellt das MERGE-Tool grafische Editoren zur Verfügung. 6.10.2 CASE-Tools

CASE-Tools haben ihren Ursprung in der Modellierung von Softwareanwendungen. Sie bieten Unterstützung bei der Visualisierung des einer Anwendung zugrunde liegenden Entwurfs. Einige Standardsoftwaresysteme nutzen diese Werkzeuge, um ihre Unternehmensmodelle zu visualisieren und grafisch anzupassen. Sie orientieren sich stärker an der Umsetzung eines Modells in Programmcode als an der allgemeinen Modellierung von Geschäftsprozessen. Für Anwender ohne Programmiererfahrung sind sie daher häufig schwerer zu erlernen und die mit ihnen visualisierten Modelle schwerer zu verstehen als Modelle von Unternehmensmodellierungswerkzeugen. Die Modellierung mit CASE-Tools erfolgt heute in der Regel in der Unified Modelling Language (UML). Für jede Diagrammart der UML bieten solche Werkzeuge entsprechende grafische Editoren. Ziel von CASE-Tools ist die Bereitstellung eines visuellen Modellierungswerkzeuges für die Entwicklung von robusten, effizienten Lösungen für Anforderungen aus Client/Server-, verteilten Unternehmens- und Echtzeitsystemumgebungen. Sie sollen den Zugang zur Modellierung für Nichtprogrammierer, die Prozesse modellieren wollen, ebenso ermöglichen wie für Programmierer, welche die Logik einer Anwendung modellieren möchten. CASE-Tools bieten die Möglichkeit, ein Modell automatisch in Programmcode zu übersetzen. Dabei werden verschiedene Programmiersprachen wie beispielsweise Java und C++ unterstützt. Ein typisches Beispiel eines CASE-Tools ist Rational Rose der Firma IBM. 6.10.3 Systemspezifische Werkzeuge

Einige Hersteller sind dazu übergegangen, Werkzeuge für die Modellierung und Anpassung ihrer eigenen Standardsoftwaresysteme mitzuliefern oder optional anzubieten. Diese Werkzeuge sind meist auf die speziellen Anforderungen und Besonderheiten der Systeme zugeschnitten. Dies hat zum einen den Vorteil, dass Beschreibungssprache und Bezeichnungen im Informationssystem und dem Modellierungswerkzeug übereinstimmen. Zum anderen ist im Allgemeinen eine konsistente (halb-)automatische Abbildung des Modells durch das Werkzeug im Rahmen des Customizing

258

6 Technische und methodische Grundlagen

möglich. Durch die Spezialisierung auf ein bestimmtes Standardsoftwaresystem ist es bei den meisten proprietären Werkzeugen nur schwer möglich andere Softwaresysteme in die Modellierung zu integrieren. Beispiele für derartige Werkzeuge sind einerseits ARIS P2A – Processes to Application und eMatrix Accelerator für das eMatrix PDM-System. Das ARIS A2P ist ein Werkzeug für die prozessorientierte Anpassung von Informationssystemen im Umfeld von ERP- und Middleware-Systemen. Der eMatrix Accelerator ist eine Weiterentwicklung des MERGE-Tools zur Anpassung des eMatrix PDM-Systems.

6.11 Informationstechnologie Die Informationstechnologien umfasst ein weites Themenfeld unterschiedlichster Inhalte. Eine Entscheidung für die Beschaffung eines Informationssystems basiert in der Regel nicht nur auf den Funktionalitäten des jeweiligen Systems. Vielmehr spielen Infrastruktur und Anwendungsmöglichkeiten von Technologien ebenfalls eine Rolle. Im folgenden Abschnitt werden Themenbereiche aufgeführt, die grundlegende Technologien und Lösungen beschreiben, und die somit als Hintergrundinformationen zur Auswahl von informationstechnischen Lösungen herangezogen werden können. 6.11.1 Architektur von Informationssystemen

Die systemtechnische Gestaltung und Auslegung computergestützter Informationssysteme wird sehr stark durch informationstechnische Neuerungen bestimmt. Dies zeigt sich deutlich in der Abkehr von zentralen Lösungen hin zu dezentralen und verteilten Systemen und den stark erweiterten Kommunikationsmöglichkeiten. Zentralrechnerbasierte Informationssysteme

Zentralrechnerbasierte Informationssysteme sind sozusagen die Weiterführung einer nach klassischen Strukturen aufgebauter Datenverarbeitung. Sie sind gekennzeichnet durch eine starke Belastung des Zentralrechners und einer traditionellen Vernachlässigung individueller Bedürfnisse der Benutzer. Die Kommunikation zwischen Benutzer und Applikation erfolgt als Transaktion. Der Zugriff auf eine Zentralanwendung findet über einen PC mittels einer speziellen Software statt, die ein Terminal emuliert.

6.11 Informationstechnologie

259

Obwohl das Zentralrechnerprinzip stark zurückgedrängt worden ist, sollten die systemtechnischen Vorteile nicht übersehen werden. Es gibt Bestrebungen zum so genannten Rehosting: Da ein Zentralrechner mit virtuellem Betriebssystem andere Systeme emulieren kann, ist es möglich, jedem Benutzer auf dem Host (Zentralrechner) einen virtuellen Rechner z. B. mit Linux-Betriebsystem zur Verfügung zu stellen. Verteilte Informationssysteme

Bei den verteilten Informationssystemen sind die einzelnen Anwendungen und Datenbestände über das Netz auf verschiedene Rechner verteilt. Der Zugang zu diesen Anwendungen und Datenbeständen erfolgt über die Arbeitsplatzrechner der Benutzer. Die auf der Systemebene entstehende komplexe Abhängigkeit der einzelnen Systemteile bleibt dem Benutzer verborgen. Der Vorteil jedoch gegenüber einer zentralisierten Lösung ist eine größere Flexibilität auf der gesamtbetrieblichen Ebene und eine in nahezu unbegrenzt beliebigen Schritten mögliche Skalierbarkeit durch Zusammenschalten mehrer Rechner (Clustering). Zentralrechnerbasiertes Informationssystem

ZentralRechner

NetworkSwitch

Verteiltes Informationssystem

DatenbankServer

AnwendungsServer

Network-Switch

PCs mit Terminalemulation Client

Präsentation Applikation Datenzugriff

Client PCs

Zentralrechner

Client Server Server

Abb. 6-19: Aufgabenverteilungen bei Informationssystemen

Client

Server

260

6 Technische und methodische Grundlagen

Verteilte Informationssysteme basieren meist auf dem Konzept des Client/Server-Modells (s. Abb. 6-19). Das Client/Server Modell beruht auf einer Aufteilung der Verarbeitungsprozesse in: • Client Prozess und Server Prozess und • der Kooperation dieser Prozesse. Server und Client Prozess können sich auf demselben Rechner befinden. Das Ziel der Server/Client Konzeption ist jedoch die Verteilung der einzelnen Prozesse auf verschiedene Rechner. Welche Dienste ein Server für die Clients erbringt, hängt von der Konfiguration des Anwendungssystems ab. Es sind folgende Aufgabenteilungen denkbar: • Präsentation: Benutzungsoberfläche, gesamte Handhabung der Ein-/ Ausgabe • Applikation: Anwendungsspezifische Verarbeitungslogik • Datenzugriff: realisiert den Zugriff mittels DB-Schnittstelle auf die Datenbank. Es sind auch nichtlineare (parallele) Anordnungen im Netz möglich. Wie viele Stufen man wählt, hängt davon ab, wie die Verteilung der Verarbeitungslast sein soll. Abb. 6-19 zeigt einen Vergleich der Aufgabenverteilung bei zentralrechnerbassierten und verteilten Informationssystemen. 6.11.2 Rechnernetze

Nicht jede Verbindung von Informationssystemen stellt ein Rechnernetz dar. Ein Rechnernetz erfüllt folgende Anforderungen: • Es ist primär ein Transport bzw. Übertragungssystem für den Austausch von Daten zuständig. • Es beinhaltet eine Vermittlungsfunktion damit die von einem Teilnehmerknoten übergebenen Daten den gewünschten Kommunikationspartnern zugestellt werden können. • Es besteht aus Teilnehmern, den Netzknoten. Üblicherweise unterscheidet man zwischen unternehmensinternen Netzen (Intranet) und dem externen Netz (Internet). Zur Vernetzung von mehreren internen Netzen über das Internet werden so genannte virtuelle private Netzwerke eingerichtet (VPN = Virtual Private Network), die die Daten verschlüsselt zwischen den Netzwerken übertragen.

6.11 Informationstechnologie

261

Zielsetzung der Rechnervernetzung

Die klassischen Zielsetzungen der Rechnervernetzung sind: • Datenverbund: logische Koppelung getrennter Datenbestände z. B. verteilte Datenbanken. • Funktionsverbund: Zugriff auf spezielle Funktionen anderer Systeme z. B. Printserver, Mailserver oder beliebige Anwendungen. • Lastenverbund: Entlastung eines Systems durch Verteilung von Aufträgen auf andere, weniger belastete Systeme. • Leistungsverbund: Parallelisierung einer Anwendung durch Zusammenschluss mehrerer Rechner z. B. verteiltes Rechnen. • Verfügungsverbund: Beim Ausfall eines Systems springt ein Ersatzsystem ein (Recovery). Betrieb von Rechnernetzen

Grundsätzlich können Rechnernetze auf zwei Arten betrieben werden, als Peer to Peer Netz oder als Client Server Netz: Peer to Peer Netz

In einem Peer to Peer Netz ist jeder Rechner gleichberechtigt. Jeder Rechner kann Client, Server oder beides sein und jeder Rechner kann mit jedem anderen Rechner im Netz kommunizieren. Peer to Peer Netz eignet sich für kleinere Netze. Ein im Netz angeschlossener Drucker kann z. B. von jedem Rechner aus angesteuert werden. Man spart sich ein umfangreiches Netzmanagement. Client Server Netz

In einem Client Server Netz werden die einzelnen Clients von einem Server aus verwaltet. Das ganze Benutzeraccounting wird zentral gesteuert, ebenso zentrale Dienste bis hin zur zentral gesteuerten Softwareinstallation. Die für den Server/Client Betrieb erforderliche Software gibt es entweder als eigenständiges Betriebssystem oder als Betriebssystemzusatz. Das Workgroup Computing ist ein Client Server Netz für eine Arbeitsgruppe, Fachabteilung, begrenzte Datenhaltung oder andere Zwecke. Die Gleichartigkeit einer solchen logischen Gruppe bedingt den Einsatz begrenzter Datenhaltung, auch die Applikationssoftware wird nur für diese funktionale Informationsverarbeitungsinseln eingesetzt. Die Verbindung zu anderen Gruppen ist z. B. über Fileserver möglich.

262

6 Technische und methodische Grundlagen

Thin Client Netz

Für Umgebungen mit homogener Anwendung ohne 3D Graphikausgabe sind Thin Client Netzwerke geeignet. Ein Thin Client übernimmt wie ein Terminal die Präsentation einer Anwendung. Die Anwendung läuft vollständig auf einem Server, der für eine begrenzte Anzahl gleichzeitig arbeitende Benutzer ausgelegt ist. Die Verbindung Server/Client erfordert wegen der hohen Transferleistung ein geeignetes Netz. Ein Thin Client Netzwerk ist einfach zu administrieren, da der Thin Client nahezu keine Administration benötigt. Thin Clients sind vor allem im Zusammenhang mit der zunehmenden Verbreitung von „Browser-Oberflächen“ zu sehen. Die Prozesslogik von Internet-/Intranet-Applikationen wird hauptsächlich auf der Serverseite ausgeführt, während die Datenpräsentation in einem Web-Browser stattfindet. Dies macht die Applikationen nahezu unabhängig vom Betriebssystem des Clients, so dass auf dem Thin Client lediglich ein geeigneter Browser verfügbar sein muss. 6.11.3 Grundlegende Informationstechnologien

Bei der Beschaffung von Integrationssystemen entscheiden häufig Technologien, wie Datenbanksysteme und Vaulting oder Aspekte der Anwendung und Vorgehensweise, welches System verwendet wird. Datenbanksysteme

Umfangreiche Datenmengen erfordern effiziente Systeme zu ihrer Verwaltung und Organisation. Zusammengehörende Daten werden deshalb in einer Datenbank, die üblicherweise von einem Datenbankverwaltungssystem (DBMS) verwaltet wird, gespeichert. Es gibt hierarchische, relationale, multidimensionale und objektorientierte Datenbanken, wobei heute in der Regel relationale Datenbanken zum Einsatz kommen. Ein DBMS zusammen mit einer oder mehreren Datenbanken nennt man Datenbanksystem (DBS). Datenbanksysteme sind von der eigentlichen Anwendungssoftware unabhängig, so dass eine Anwendung verschiedene Datenbanksysteme zur Datenspeicherung nutzen kann. In der Praxis ist ein Anwendungssystem allerdings auf wenige bestimmte Datenbanken festgelegt, da die Datenbank-Schnittstellen vordefiniert sind. Die Funktionalität und Qualität einer Datenbank ist neben der logischen und physischen Datenunabhängigkeit gekennzeichnet durch:

6.11 Informationstechnologie

263

• Datenkonsistenz: Bei Änderung eines Datensatzes werden alle Beziehungen zu anderen Daten mit berücksichtigt. • Datensicherheit: Schutz der Daten vor Zerstörung durch System- oder Anwendungsfehler. • Datenschutz: Datenschutzmechanismen stellen sicher, dass nur autorisierte Personen Zugriff auf bestimmte Daten haben. • Synchronisation: Ein Datenbanksystem muss im Mehrbenutzerbetrieb geeignete Synchronisationsmaßnahmen für den Zugriff auf die Daten zur Verfügung stellen. • Transaktionsmechanismen: Eine Transaktion ist eine Folge von Operationen (z. B. Daten suchen oder löschen), die eine Datenbank von einem konsistenten Zustand wieder in einem neuen konsistenten Zustand überführt. Vaulting

PDM- und Dokumentenmanagementsysteme speichern Dokumente nicht in der Datenbank in der die beschreibenden Verwaltungsdaten (Metadaten) gespeichert werden, sondern im Dateisystem eines Rechners und verweisen auf diesen Speicherort. Dokumente, die im Dateisystem eines Rechners gespeichert werden, sind für Benutzer oder Benutzergruppen mit definierten Zugriffsrechten versehen, so das diese Benutzer die Dokumente je nach Berechtigung lesen, schreiben oder ändern dürfen. Um den direkten Zugriff von Benutzern zu verhindern, werden die Dokumente deshalb in einem gesonderten Bereich des Dateisystems gespeichert, dem so genannten electronic Vault Für diesen electronic Vault wird ein eigenständiger Benutzer angelegt, der im Dateisystem als Eigentümer dieses Speicherbereichs registriert ist. Andere Benutzer können auf die Dokumente nur über das Informationssystem zugreifen. Für das Ablegen und Holen von Dateien aus den geschützten Bereichen werden dem Anwender von den PDM- und Dokumentenmanagementsystemen Eingabe- (Check-in) und Ausgabefunktionen (Check-out) zur Verfügung gestellt. Plattformen

Die Entscheidung über die richtige Plattform einer Anwendungsentwicklung kann erst nach der Analyse der Rahmenbedingungen erfolgen. Dazu sind im Wesentlichen die nachfolgend genannten Aspekte zu betrachten. Je nach Situation sind diese verschieden zu bewerten und zu gewichten.

264

6 Technische und methodische Grundlagen

• Betriebsart: Hier reicht das Spektrum von reiner Publikation (z. B. Webserver) über dialog-orientierte Systeme (z. B. PDM- oder CADSystem) bis hin zu Echtzeitsystemen (Steuerungssysteme z. B. zur Anlagensteuerung) • Last und Lastverteilung: Allein die zu bewältigende Last führt teilweise zu Vorentscheidungen. Bei der Lastverteilung ist eine Entscheidung zu treffen zwischen Terminal/Host- und Client/Server-Systemen. • technische Integration: Diese führt teilweise zu einer sehr restriktiven Einengung des Entscheidungsspielraums. • Kosten und Nutzen: Neben den vergleichsweise leicht bestimmbaren Kosten der Beschaffung sind die Kosten der Wartung und vor allem die Lebensdauer von Anwendungen ungleich schwerer zu bestimmen. Letzteres ist jedoch ein entscheidender Faktor für die Prognose einer Kosten-/Nutzenanalyse. Migration

Migration (lat. Wanderung) bedeutet für eine Organisation - allgemein formuliert – die Überführung von einem Ist-Zustand in einen geplanten neuen Zustand. Voraussetzung für diesen Prozess ist die Bestimmung des „wo befinden wir uns?“ sowie des „wo wollen wir hin?“. Ziel ist die schrittweise Annäherung an das Optimum: Jeder Schritt bedeutet den Weg vom Ist-Zustand zu dem Soll-Zustand, der sich als Schnittmenge aus dem aktuell Machbaren und dem Gewünschten ergibt. Dies bedeutet für die Migration von Informationssystemen zunächst meist den parallelen Betrieb des alten und des neuen Informationssystems, was auch vermehrten Kosten- und Personalaufwand bedeutet. Dadurch können am neuen System die notwendigen Anpassungen und Tests durchgeführt werden, während das alte System für den produktiven Betrieb verwendet wird. Im Anschluss daran erfolgt in der Regel die Übernahme der Daten vom alten in das neue System und die Außerbetriebsetzung des alten Systems. Applikation Service Providing

Application Service Providing (ASP) bedeutet, dass Anwendungen und Programmfunktionalitäten gemietet werden. Beim Application Service Providing (ASP) wird ein Informationssystem oder einzelne Applikationen auf der Hardware eines Dienstleisters betrieben. Ein Kunde nutzt die angebotene Applikation über öffentliche Netze oder Punkt zu Punkt Verbindungen. Der Dienstleister sorgt für die gesamte Administration der Applikationen wie Backup oder das Einspielen von Patches usw.

6.11 Informationstechnologie

265

Der Dienstleister stellt Applikationen in aktuellen bzw. den benötigten Versionen bereit, wobei die Abrechnung mit jedem Unternehmen in einem nutzungsabhängigen Mietmodell erfolgt, zumeist nach der Anzahl bzw. der Intensität der getätigten Transaktionen, nach Anzahl der Benutzer oder Nutzungsdauer. Auf diese Weise kann ein Unternehmen Kosten einsparen, da es auf Personal zur Administration der Informationssysteme verzichten oder selten genutzte Software nicht kaufen muss. 6.11.4 Schnittstellenstandards

Im Bereich des Product Lifecycle Management haben sich zwei Schnittstellenstandards etabliert, STEP und die auf CORBA aufbauenden PDM Enablers. Beide Standards sind sehr umfangreich und erfordern deshalb einen entsprechend hohen Implementierungsaufwand. CORBA

Bei heterogenen Plattformen (Hardware, Betriebssystem und Programmiersprachen) erfordern die Schnittstellen zwischen Applikationen oder Server- und Clientprozessen eine jeweils spezifische Programmierung. Die Common Object Request Broker Architecture (CORBA) (The Common Object Request Broker 2000) ist eine objektorientierte MiddlewareSpezifikation, welche die Implementierung verteilter Objekte unabhängig von Rechnerarchitektur, Betriebssystem und Programmiersprache ermöglicht. In CORBA besteht eine Trennung zwischen der Schnittstellendefinition eines Objekts und der Implementierung. Die Schnittstelle eines Objekts wird mittels einer implementierungsunabhängigen Beschreibungssprache, der Interface Definition Language (IDL), definiert. In einem zweiten Schritt wird diese Definition für die jeweiligen Applikationen, Clients und Server ausprogrammiert. Bereits bestehende Anwendungen können durch Kapselung ebenfalls in CORBA Objekte überführt werden. Zentrale Ausführungskomponente von CORBA sind die Objekt Request Broker (ORB). Sie stellen die Dienste für das Auffinden der Zielobjekte und die Übermittlung von Methodenaufrufen und Resultaten bereit. STEP

Der Standard for the Exchange of Product Data (STEP) bildet eine standardisierte Basis für den Datenaustausch von Produktdaten, der in der internationale Norm ISO 10303 veröffentlicht wurde. Die einzelnen

266

6 Technische und methodische Grundlagen

Dokumente von STEP (Parts) lassen sich in die Bereiche Modelle zur Beschreibung von Produktdaten, Beschreibungsmethoden, Implementierungsmethoden und Methoden zum Konformitätstest unterteilen (Step Portal). Die Beschreibungsmethoden (10er-Reihe, ISO 10303-1x) beinhalten die Beschreibung der Datenmodellierungssprache EXPRESS zur Spezifikation von Datenmodellen. Die Implementierungsmethoden (20er-Reihe, ISO 10303-2x) beinhalten Spezifikationen für Dateiformate und Schnittstellenimplementierung, beispielsweise für die Programmiersprachen Java oder C++. Die Integrated Resources Basismodelle (40/50er-Reihe, ISO 10303-4x, -5x) bilden die Grundlage für alle weiteren, in mehreren Stufen darauf aufbauenden Datenmodelle. Die Basismodelle beschreiben Grundelemente für: • • • • • • • • • •

Produktidentifikation und -konfiguration Geometrie- und Topologiebeschreibung Darstellungsstrukturen Produktstruktur und -konfiguration Material visuelle Darstellung Toleranzen Prozessstruktur und -eigenschaften mathematische Konstrukte und Beschreibungen

Zunächst sind dies Anwendungsmodelle mit allgemein gültiger (100erReihe, ISO 10303-1xx) und anwendungsbezogenem Inhalt (500er-Reihe, ISO 10303-5xx). Die allgemeingültigen Anwendungsmodelle beschreiben Modelle für Zeichnungen, Finite Elemente Methode oder Kinematik. Anwendungsbezogene Anwendungsmodelle, die so genannten AICs (Application Interpreted Construct), beinhalten verschiedene geometrische Beschreibungsmethoden vom kantenorientierten Drahtgitter- bis zum Volumenmodell. Die oberste Stufe der Datenmodelle sind die so genannten Anwendungsprotokolle AP (200er-Reihe, ISO 10303-2xx), die die Grundlage für Implementierungen darstellen, beispielsweise „Configuration Controlled Design“ (AP203), „Electrotechnical Design and Installation“ (AP212) oder „Core Data for Automotive Mechanical Design and Processes“ (AP214).

6.11 Informationstechnologie

267

PDM Enablers

Product Data Management Enablers (PDM Enablers) stellen eine Spezifikation für die Implementierung von Daten- und Funktionsschnittstellen für Produkt- und Prozessinformationen dar (Product Data Management Enablers Specification 2000). Die Spezifikation stellt ein Grundgerüst für die Implementierung von Schnittstellendefinitionen auf Basis von CORBA zur Verfügung. Die Implementierung eines PDM Enablers erfolgt anhand von zwölf Modulen die in der Spezifikation durch die Interface Definition Language (IDL) beschrieben werden: • • • • • • • • • • • •

PdmResponsibility PdmFoundation PdmFramework PdmBaseline PdmViews PdmDocumentManagement PdmProductStructureDefinition PdmEffectivity PdmChangeManagement PdmManufacturingImplementation PdmConfigurationManagement PdmSTEP

Die drei Module PdmResponsibility, PdmFoundation und PdmFramework bilden die Basis für konzeptionelle „PDM Services“, die diese „PDM Funktionen“ auf CORBA-Funktionen übertragen. Die anderen neuen Definieren PDM Services die durch eine Applikation für spezifische PDMFunktionalitäten, wie den Aufruf von Dokumenten oder die Darstellung von Produktstrukturen genutzt werden können.

PLM zum Nachschlagen

Die nachfolgenden Zusammenstellungen beinhalten wichtige oder im Buch verwendete Begriffe, Abkürzungen und Literaturstellen. Zudem werden Persönlichkeiten, Institutionen, Zeitschriften, Bücher und Internetseiten im Themenfeld des Product Lifecycle Management aufgelistet, wobei diese Listen keinen Anspruch auf Vollständigkeit erheben. Sie sollen dem Leser jedoch als Anhaltpunkt dienen, weitere Informationsquellen für PLM ausfindig zu machen.

Abkürzungen ALE API ARIS ASP BAPI BC Sets BoM CAD CAM CAO CAQ CASE CDIF COM CORBA CPC CPDM CRM CMS DPD

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 Common Object Model Common Object Request Broker Architecture Collaborative Product Commerce Collaborative Product Definition Management Customer Relationship Management Content Management System Digital Product Definition

270

PLM zum Nachschlagen

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

Desktop Publishing Datenverarbeitung Engineering Database Engineering Data Managament, Engineering-DatenManagement erweiterte 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-DatenManagement Product Data Management System, Produkt-DatenManagement-System Product Knowledge Management Product Lifecycle Management Produktionsplanung und –steuerung Quality Function Deployment Supply Chain Management Standard for Exchange of Product Data Unified Modelling Language Verein Deutscher Ingenieure Virtual Product Development Management World Wide Web Consortium Workflow Management Coalition Workflow Management System XML Metadata Interchange Extensible Markup Language Extensible Stylesheet Language Transformations

Glossar

271

Glossar Änderung

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

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 Anwendugen 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 Call-Routinen (Abruf-Routinen), die in ein anderes Programm eingebaut werden kann, um Funktionen aufzurufen.

Artikelstamm

Beschreibende und klassifizierende Attribute zu einem Artikel 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: Geschäftsprozess im E-Commerce, über den Unternehmen ihre Waren und Dienstleistungen anbieten und vertreiben können.

BoM

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

BREP

Boundary Representation, topologische-geometrisches Strukturmodell

CAx-Systeme

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

272

PLM zum Nachschlagen

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 Aussehen und Inhalt.

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: Informationssystem zur optimierten Verwaltung von Informationen über Kunden und Lieferanten eines Unternehmens.

CSCW

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

Glossar

273

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 zur 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

Eine 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 (Datenbankmanagmentsystem, 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. Entity-Relationship-Modell, das unabhängig von einer konkreten Anwendung ist. Die Mehrzahl der Datenbanken basiert auf einem der folgenden drei Modelle: Hierarchisches Datenmodell, 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.

274

PLM zum Nachschlagen

Digital Prototype

Repräsentation eins Produktes durch seine Produktmerkmale, in denen neben der Produktstruktur und geometrie auch physikalische und logische Merkmale abgebildet sind. Ziele sind beispielsweise, durch Simulation des Produktverhaltens Optimierung durchzuführen und mit Hilfe digitaler Prototypen die Begutachtung (design review) sowie Freigabe von Produktentwicklungsergebnissen zu unterstützen.

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 Managament: 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.

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

Glossar

275

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.

IGES

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

Informationsinfrastruktur

Die Gesamtheit der in einem Unternehmen vorhandenen Hardware, Netze, Betriebssoftware und weitere betriebsnaher Software (der sog. Middleware), die für den Betrieb der unterschiedlichen Anwendungssysteme erforderlich ist.

276

PLM zum Nachschlagen

Informationsmanagement

Die Gesamtheit der Aufgaben, Methoden und Werkzeuge zum Aufbau, Verwaltung und Nutzung der Informationsinfrastruktur, die sowohl auf Rechnersystemen selbst, auf anderen Medien (Papier, Zeichenfolie) als auch latent vorhanden ist

Informationssystem

Ein strukturiertes (Rechner-) System aus Geräten (Hardware) 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 System, 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 Produkt- und Prozessmodell

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

Java

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

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 ReleaseWechsel oder bei jeder Migration vermieden werden.

Glossar

277

Mapping

Abbildung, Beschreibung der Abbildung der Anwendungselemente (ARM-Entities) auf Ressourcekonstrukte 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 eine anderes (unter Beibehaltung von wesentlichen Teilen des Programmcodes) oder die Einführung eines Nachfolgesystems für ein existierendes System 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.

278

PLM zum Nachschlagen

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.

Organisation

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 Entwicklung- und Konstruktion im ganzen Unternehmen. PDM-Systeme bilden eine wichtige Basis für das Product Lifecycle Management.

PDM-Enabler

Definition der OMG für eine CORBA-basierte Schnittstelle zum Informationsaustausch zwischen EDM/PDMSystemen, um einheitlich den direkten Zugriff auf bestimmte Objekte und Funktionen (beispielsweise Workflow, Klassifizierung) in einem EDM/PDM-System zu ermöglichen.

PDT

Produkt Data Technology, Produktdatentechnologie

persistent

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 eine 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.

Glossar

279

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.

Produktentwicklungsprozess

Folge von Aktivitäten, die zur Entwicklung eines Produkts von der ersten Idee bis zur Freigabe für die Fertigung notwendig sind.

Produktmodell

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

Produktstruktur

Beziehung der einzelnen Artikel eines Produktes

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 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

280

PLM zum Nachschlagen

Sachmerkmalleiste (SML)

Alle kennzeichnenden Parameter eines Gegenstandes 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

Supply Chain Management: Abstimmung aller logistischen Vorgänge und Funktionen innerhalb der Lieferkette vom Lieferanten bis zum Verbraucher mit der Zielsetzung, die Informationen in dieser Kette für alle Beteiligte transparent zu machen. SCM-Systeme verzahnen die externe Wertschöpfungskette vom Rohmaterial Lieferanten bis hin zum Endkunden, indem alle relevanten Daten zwischen den Gliedern der Kette ausgetauscht werden.

SGML

Standard Generalized Markup Langugage (genormt in ISO 8879)

Simultaneous Engineering

Vorgehensweise in Entwicklung, Konstruktion, Arbeitsvorbereitung (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 Ergebnis des betrachteten Prozesses einigermaßen abgesichert vorliegt, so dass es von den nachfolgenden Prozessen verwendet werden kann. Simultaneous Engineering bedingt mindestens ein Arbeiten (üblicherweise interdisziplinären) Team.

Stammdaten

Alle Daten des Artikelstamms werden in den Stammdaten zusammengefasst

Glossar

281

STEP

Standard for the Exchange of Product Data: STEP ist ein eine internationale Norm zur Beschreibung und zum Austausch von Produktinformationen. STEP wird in der ISO-Normenreihe 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.

Vault

elektronic Vault: geschützter Speicherbereich eines PDM-Systems. 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.

282

PLM zum Nachschlagen

Persönlichkeiten und Kompetenzzentren Prof. Dr.-Ing. Michael Abramovici

Ruhr Universität Bochum Der Lehrstuhl für Maschinenbauinformatik (ITM) wurde 1994 gegründet und gehört zum Institut für Konstruktionstechnik der Fakultät für Maschinenbau an der Ruhr Universität Bochum. Nach zehnjähriger Industrietätigkeit in den Bereichen der Konstruktion in der Werkzeugmaschinenindustrie und der IT- und Management-Beratung wurde Michael Abramovici Leiter dieses Lehrstuhls. Er ist ebenfalls Mitglied des Direktoriums des Institutes für Unternehmensführung (IFU) und des Rechenzentrums der Ruhr-Universität Bochum. Prof. Dr.-Ing. Reiner Anderl

Technische Universität Darmstadt Im April 1993 wurde Reiner Anderl als Professor an die Technische Universität Darmstadt berufen und ist hier Leiter des Fachgebietes Datenverarbeitung in der Konstruktion. Seit mehreren Jahren ist er an den Entwicklungs- und Normungsarbeiten im internationalen und nationalen Bereich beteiligt. Prof. Dr.-Ing. Klaus Bender

Technische Universität München Klaus Bender nahm 1979 den Ruf der Fakultät für Informatik der Universität Karlsruhe an, wo er bis 1992 in der Technischen Informatik tätig war. Zusammen mit sechs weiteren Kollegen gründete Prof. Bender 1985 das Forschungszentrum Informatik FZI in Karlsruhe und war von 1985 bis 1992 dessen Vorstand. Im Jahre 1992 folgte Prof. Bender dem Ruf an die Technische Universität München und leitet seither den Lehrstuhl für Informationstechnik im Maschinenwesen. Prof. Bender ist seit 1985 Mitglied des Vorstandes und Beirats der VDI/VDE-Gesellschaft für Meß- und Automatisierungstechnik (GMA) ferner seit 1987 Kurator der Fraunhofergesellschaft am Institut für graphische Datenverarbeitung in Darmstadt. Er war maßgeblich an der Entwicklung der deutschen Feldbustechnik (PROFIBUS und ASI) beteiligt und ist Mitglied des Vorstands der PROFIBUS-Nutzerorganisation seit 1989 und der Interkama seit 1996.

Persönlichkeiten und Kompetenzzentren

283

Prof. Dr.-Ing. Martin Eigner

Technische Universität Kaiserslautern Martin Eigner ist Gründer und war Vorstandsvorsitzender der EIGNER + PARTNER AG, die 1985 der erste Anbieter einer EDM-Lösung war. Seit Oktober 2004 ist er Professor im Fachbereich Maschinenbau und Verfahrenstechnik am Lehrstuhl für Virtuelle Produktentwicklung der Technischen Universität Kaiserslautern. o. Prof. Em. Dr.-Ing. Prof. E.h. Dr. H.c. Hans Grabowski

Universität Karlsruhe (TH) 1975 wurde an der Technischen Universität Karlsruhe in der Fakultät Maschinenbau der Lehrstuhl für Angewandte Informatik gegründet. Hans Grabowski wird als ordentlicher Professor berufen. 1977 wurde unter Leitung von Hans Grabowski das Institut für Rechneranwendung in Planung und Konstruktion (RPK) gegründet. Seit der Gründung des Forschungszentrums Informatik im Jahre 1985 war Hans Grabowski Leiter des Fachbereichs CAD/CAM-Technologie. Der Name Fachbereichs wurde 2001 in „Prozess- und Datenmanagement im Engineering (PDE)“ geändert. Professor Grabowski emeritierte 2003. Prof. Dr. Dr.-Ing. Jivka Ovtcharova

Universität Karlsruhe (TH) Frau Jivka Ovtcharova hat zum 1. Oktober 2003 die Professur für »Rechneranwendung in Planung und Konstruktion« an der Fakultät Maschinenbau der Universität Karlsruhe übernommen, die bisher Prof. Hans Grabowski inne hatte. Seit Januar 2004 ist sie ebenfalls Direktorin des Forschungsbereiches Prozess- und Datenmanagement im Engineering des Forschungszentrum Informatik an der Universität Karlsruhe (TH). Vor Ihrer Berufung an die Universität Karlsruhe war Jivka Ovtcharova mehrere Jahre in verschiedenen Industrieunternehmen, unter anderem der Adam Opel AG, tätig.

Dipl.-Ing Josef Schöttner

SICON Josef Schöttner Industrie-Consultant Josef Schöttner ist freier Unternehmensberater, Referent und Autor mit langjähriger Erfahrung im Bereich Informationsmanagement in IndustrieUnternehmen, insbesondere auf dem Gebiet von PDM/PLM.

284

PLM zum Nachschlagen

John Stark

John Stark Associates John Stark Associates wurde 1991 gegründet und ist einer der führenden Dienstleister im Product Lifecycle Management Markt. John Stark ist Präsident von John Stark Associates sowie Autor vieler Artikel und Bücher im Themenfeld PLM, PDM, CAD und Informations in Manufacturing. John Stark erhielt seine Doktorgrade vom Imperial College, London. Prof. Dr.-Ing Ralph Stelzer

Technische Universität Dresden Nach mehrjähriger Industrietätigkeit im Bereich der CAx-Anwendungen war Ralph Stelzer zwischen 1990 und Ende 2000 Mitarbeiter der Karlsruher Firma EIGNER+PARTNER AG, zuletzt als Vorstand für Forschung und Entwicklung. Im Januar 2001 wurde er als Professor an die Technische Universität Dresden berufen und ist dort Leiter des Lehrstuhles für Konstruktionstechnik/CAD. Prof. Dr.-Ing. Eckart Uhlmann

Technische Universität Berlin Im September 1997 wurde Prof. Dr.-Ing. Eckart Uhlmann zum Professor für das Fachgebiet Werkzeugmaschinen und Fertigungstechnik am Institut für Werkzeugmaschinen und Fabrikbetrieb (IWF) der Technischen Universität Berlin berufen. Zugleich übertrug ihm die Fraunhofer-Gesellschaft die Leitung des Instituts für Produktionsanlagen und Konstruktionstechnik (IPK). Seit April 2003 ist er in der Nachfolge von Prof. Dr.-Ing. Günther Seliger auch Geschäftsführender Direktor des IWF. Prof. Dr.-Ing. Prof. h.c. Sándor Vajna

Universität Magdeburg In den Jahren 1982 bis 1994 war Sándor Vajna bei Carl Freudenberg in Weinheim, ABB-Konzernforschung in Heidelberg und Braun AG in Kronberg auf den Gebieten Produkt-, Prozessentwicklung und organisation, CAD/CAM-Anwendungen und Produktdatenverarbeitung leitend tätig. Seit August 1994 ist er Inhaber des Lehrstuhls für Maschinenbauinformatik an der Otto-von-Guericke Universität Magdeburg.

Fachliteratur

285

Fachliteratur Fachbücher

Adaption von Standardsoftwaresystemen, Ein Beitrag zur unternehmensmodellbasierten Integration von Information und Organisation; Peter Adamietz; Shaker Verlag, 2002 ISBN/ISSN: 3-8322-0057-6 Austausch von Produktdaten zwischen CAD-Modelliersystemen am Beispiel schiffbaulicher Stahlstrukturbeschreibungen; Thomas Koch; VDI-Verlag, 1991 ISBN/ISSN: 3-18-145420-6 Authentisierung von Produktdaten unter besonderer Berücksichtigung von STEP; Martin Momberg; Shaker Verlag, 1999 ISBN: 3-82-656352-2 Beschleunigung der Produktentwicklung durch EDM-PDM- und Feature-Technologie; Informationsverarbeitung in der Konstruktion '99; Tagung München; 19. und 20. Oktober 1999; VDI-Verlag, 1999 ISBN/ISSN: 3-18-091497-1 Das IT-Pflichtenheft zur optimalen Softwarebeschaffung; Bruno Grupp; mitp-Verlag, 2003 ISBN/ISSN: 3-8266-1301-5 Das virtuelle Produkt; Management der CAD- Technik; Günter Spur, Frank-Lothar Krause; Verlag Leipzig, 1997 ISBN/ISSN: 3-44-619176-3 Datenmanagement in der Produktentwicklung; Hans Grabowski, RalfStefan Lossak, Jörg Weißkopf; Hanser Verlag, 2002 ISBN/ISSN: 3-446-21698-7 Datenmodelle in der Produktion; Wolfgang Adam; VDI-Verlag, 2003 ISBN/ISSN: 3-18-363302-7 Dokumentenmanagement; Jürgen Gulbins, Markus Seyfried, Hans Strack-Zimmermann; Springer Verlag, Berlin, 2002, ISBN: 3-540-43577-8

286

PLM zum Nachschlagen

EDM/PDM-Systeme als Rückgrat der Integrierten Produktentwicklung; ein modulares Einführungs- und Intergrationskonzept; Andreas Karcher, Florian Fischer, M Viertlböck; VDI Verlag GmbH, 1999 Ein Beitrag zur Langzeitarchivierung von Produktdaten;Bernhard Malle; Verlag Dr. Kovac,Hamburg, 1997 Ein interaktiver Modellierer für evolutionäre Produktmodelle; Winfried Kowalczyk; Dissertation, Technische Universität München, 1997 Ein Referenzmodell zur integrationsgerechten Konzeption von Produktdatenmanagement; Jörg Wirtz; Utz Verlag, 2001 ISBN/ISSN: 3-8316-0051-1 Ein Visualisierungs- und Navigationsassistent für Produktstrukturen in der Produktentwicklung; Christoph Marian Leszinski; Shaker Verlag, 2001 ISBN/ISSN: 3-8265-8888-6 Elektronisches Produktdaten- und Katalogmanagement; Manfred Mucha, Holger Kett, Thomas Renner; Irb-Verlag, 2002 ISBN: 3816762123 Engineering Data Management, Erfahrungsberichte und Trends; Joachim Milberg, Gunther Reinhart; Utz Verlag, 1998 ISBN/ISSN: 3-931327-31-0 Entwicklung von Werkzeugmaschinen auf der Basis eines integrierten Produktmodells; Christian Sanft; Hanser Verlag, 1995 ISBN/ISSN: 3-446-18109-1 Entwicklung und Wiederverwendung wissensbasierter Produktmodelle auf der Grundlage formaler Ontologien; Georg Strobl; Utz Verlag, 1997 ISBN/ISSN: 3-89675-404-1 Erweiterung der PDM-Technologie zur Unterstützung verteilter kooperativer Produktentwicklungsprozesse; Detlef Gerhard; Shaker Verlag, 2000 ISBN: 3826582314

Fachliteratur

287

Fertigungsfamilienbildung mit feature-basierten Produktmodelldaten; Jochen Deuse; Shaker Verlag, 1998 ISBN/ISSN: 3-8265-4252-5 Globales Produktdatenmanagement zur Verbesserung der Produktentwicklung, Matthias Doblies; IPK-Verlag, 1998 ISBN/ISSN: 3-8167-5224-1 Informationssystem für die Zuverlässigkeitsverbesserung komplexer technischer Serienprodukte, Martin Mutz; Shaker Verlag, 2001 ISBN/ISSN: 3-8265-9497-5 Integration elektromechanischer CA-Anwendungssysteme über einem STEP-Produktmodell; Thomas Krebs, Hrsg. von Klaus Feldmann; Meisenbach Verlag, 1996 ISBN/ISSN: 3-87525-081-8 Integration multidisziplinärer Simulations- und Berechnungsmodelle in PDM-Systeme; Marcus Krastel; Shaker Verlag, 2002 ISBN: 3832202811 Integriertes Produktdaten- und Prozeßmanagement in virtuellen Fabriken; Stefan Brandner; Utz Verlag, 2000 ISBN 3-89675-715-6 Integriertes Produktmodell; Hans Grabowski, Reiner Anderl, Adam Polly; Beuth Verlag, 1993 ISBN/ISSN: 3-410-12920-0 Integriertes Simulationsdatenmanagement für Maschinenentwicklung und Anlagenplanung; Wolfgang Schlögl; Meisenbach Verlag, 2000 ISBN/ISSN: 3-87525-137-7 Konfiguration und Rekonfiguration mittels constraint-basierter Modellierung; Ulrich John; Aka Verlag, 2002 ISBN/ISSN: 3-89838-255-9 Konzeption eines webbasierten Beratungs-Unterstützungs-Systems am Fallbeispiel einer PDM-Systemauswahl; T. Kahlert; Produktionstechnisches Zentrum Berlin (PTZ); IPK Berlin, 2000 ISBN/ISSN: 3-8167-5569-0

288

PLM zum Nachschlagen

Methode zur Aufbereitung und durchgängigen Anwendung von parametrischen feature-basierten 3D-Produktmodellen; Ines Gubsch; Dissertation, Technische Universität Dresden, 2001 Methode zur Bewertung des strategischen Nutzens von integriertem Produktdaten-Management (PDM); C. Höfener; Shaker Verlag, 1999 ISBN/ISSN: 3-8265-6518-5 Methode zur Implementierung von integriertem Produktdatenmanagement (PDM); Jens Krause; Gito Verlag, 2002 ISBN/ISSN: 3936771073 Methodik zur parametrischen Konstruktion, ein Beitrag zur integrierten Produkt- und Prozeßgestaltung; Franz-Bernd Schenke; Shaker Verlag; 2001 ISBN/ISSN: 3-8265-8517-8 Methodik zur Verbesserung der Bereitstellung von gestalt- und funktionsbezogenen Informationen für den Produktentwicklungsprozess; Olaf Plümer; VDI-Verlag, 2000 ISBN/ISSN: 3-18-312116-6 Modell einer durchgängig rechnerbasierten Produktentwicklung; Andreas Dyla; 2002; Technische Universität München; Internetdokument: http://tumb1.biblio.tu-muenchen.de/publ/diss/mw/2002/dyla.html Moderne Konstruktionsmethoden im Maschinenbau; Peter Köhler; Vogel Verlag; Würzburg, 2002 ISBN/ISSN: 3-8023-1823-4 mySAP Product Lifecycle Management; Ulrich Eisert; Galileo Press Verlag, 2001 ISBN/ISSN: 3-934358-60-8 Nutzenorientierte Einführung eines ProduktdatenmanagementSystems; Pamela Wehlitz; Dissertation, Technische Universität München, 2000 PDM-basiertes Entwicklungsmonitoring; Frank Jenne; Shaker Verlag, 2001 ISBN/ISSN: 3-8265-9029-5

Fachliteratur

289

Personalplanung und -entwicklung in einem integrierten Vorgehensmodell zur Einführung von PDM-Systemen; Rainer Pusch, Jürgen Gausemeier; Universität-Gesamthochschule-Paderborn, 2003 ISBN/ISSN: 3935433271 Product Life Cycle Management; 21st Century Paradigm for Product Realisation; John Stark; Springer-Verlag, 2004 ISBN: 1-85233-810-5 Product Lifecycle Management mit mySAP.com, Strategie, Technologie, Implementierung; Kerstin Geiger, Helmut Ruf, Stephan Schindewolf Verlag Galileo Press, 2000 ISBN: 3934358608 Produktdatenmanagement-Systeme ein Leitfaden für Product Development und Life-Cycle-Management; Martin Eigner, Ralph Stelzer; Springer Verlag, 2001 ISBN/ISSN: 3-540-66870-5 Produkte entwickeln im realen Umfeld; Was bringen neue Werkzeuge wie 3D-CAD/CAM, EDM/PDM und Virtualisierung? ; Tagung München, 9. und 10. November 2000, VDI-Gesellschaft Entwicklung, Konstruktion, Vertrieb; VDI-Verlag, 2000 ISBN/ISSN: 3-18-091569-2 Product Lifecycle Management, Antti Saaksvuori, Anselmi Immonen; Springer-Verlag, 2004 ISBN: 3-540-40373-6 Produktdatenmodellierung in der Praxis, Markus Schichtel; Hanser Verlag, 2002 ISBN/ISSN: 3-446-21857-2 Produktdatenmanagement in der Fertigungsindustrie, Prinzip – Konzepte – Strategien, Josef Schöttner; Hanser Verlag, 1999 ISBN/ISSN: 3-446-21152-7 Realisierung eines systemtechnischen Produktmodells, Einsatz in der PKW-Entwicklung; Eckhard Steinmeier, 1997, München, Techn. Univ., Diss., 1998

290

PLM zum Nachschlagen

Rechnerunterstützung des Entwurfsprozesses durch funktionaltechnische Objektmodellierung; Torsten Zetzsche; Dissertation, Technische Universität Dresden, 2000, Internet-Dokument: http://deposit.ddb.de/cgi-bin/dokserv?idn=963565990 Semantische Funktionsmodellierung als Basis für effizientes ProductLife-Cycle-Management; Werner Puri; VDI-Verlag, 2003 ISBN/ISSN: 3-18-316016-1 Simulationsintegration in allen Phasen des Produktentwicklungsprozesses bei dynamisch/hybriden Problemstellungen; Thorsten Schlacht; 2001, Universität Essen, Dissertation, 2001, Internet-Dokument: http://deposit.ddb.de/cgi-bin/dokserv?idn=962869201 STEP, standard for the exchange of product data; eine Einführung in die Entwicklung, Implementierung und industrielle Nutzung der Normenreihe ISO 10303 (STEP), Reiner Anderl, Stuttgart, Teubner Verlag, 2000 ISBN/ISSN: 3-519-06377-8 Vom Zulieferer zur Zulieferkomponente, gezielte Informationsbereitstellung in der Produktentwicklung durch virtuellen Marktplatz CompoNET; Ingo Keutgen; VDI-Verlag, 2002 ISBN/ISSN: 3-18-331920-9 Vorgehensmodell zum Management von Produktdaten in komplexen und dynamischen Produktentwicklungsprozessen; Dietmar Trippner; Shaker Verlag, 2002 ISBN/ISSN: 3-8322-0280-3

Normen und Richtlinien DIN 199-1

Technische Produktdokumentation DIN 199-4

Begriffsdefinition und Beschreibung an Grundanforderungen für einen Änderungsprozess

Fachliteratur

291

DIN 199-5

Begriffe im Zeichnungs- und Stücklistenwesen DIN 223

Qualitätsmanagement und Statistik - Begriffe DIN 226

Qualitätsmanagement - Verfahren DIN 351

Dokumentationswesen DIN 1463

Erstellung und Weiterentwicklung von Thesauri DIN 2330

Begriffe und Benennungen DIN 4000-1

Sachmerkmal-Leisten DIN 6771

Schriftfelder für Zeichnungen, Pläne und Stücklisten. DIN 6789-1

Dokumentationssystematik - Teil 1: Aufbau Technischer Produktdokumentationen DIN 6789-2

Dokumentationssystematik - Teil 2: Dokumentensätze Technischer Produktdokumentationen

292

PLM zum Nachschlagen

DIN 6789-3

Dokumentationssystematik - Teil 3: Änderung von Dokumenten und Gegenständen - Allgemeine Anforderungen DIN 6789-4

Dokumentationssystematik - Teil 4: Inhaltliche Gliederung Technischen Produktdokumentation DIN 6789-5

Dokumentationssystematik - Teil 5: Freigabe in der Technischen Produktdokumentation DIN 6789-6

Dokumentationssystematik - Teil 6: Verfälschungssicherheit digitaler technischer Dokumentation DIN EN ISO 9001

Qualitätsmanagementsysteme - Anforderungen DIN EN ISO 10007

Qualitätsmanagement - Leitfaden für Konfigurationsmanagement DIN ISO 10013

Leitfaden für das Erstellen von Qualitätsmanagement-Handbüchern DIN EN ISO 10303

Industrielle Automatisierungssysteme und Integration DIN ISO 11442-1

Technische Produktdokumentation - Rechnerunterstützte Handhabung von technischen Dokumenten - Teil 1

Fachliteratur

293

DIN ISO 11442-2

Technische Produktdokumentation - Rechnerunterstützte Handhabung von technischen Dokumenten - Teil 2 DIN ISO 11442-3

Technische Produktdokumentation - Rechnerunterstützte Handhabung von technischen Dokumenten - Teil 3 DIN ISO 11442-4

Technische Produktdokumentation - Rechnerunterstützte Handhabung von technischen Dokumenten - Teil 4 DIN/ISO 13399-1

Werkzeugdatenaustausch - Teil 1: Überblick, fundamentale Prinzipien und all-gemeines Informationsmodell DIN ISO 15226

Technische Produktdokumentation - Lebenszyklusmodell und Zuordnung von Dokumenten DIN ISO 16016

Technische Produktdokumentation - Schutzvermerk zur Beschränkung der Nutzung von Dokumenten und Produkten DIN 19246

Abwicklung von Projekten - Begriffe DIN EN 61355

Klassifikation und Kennzeichnung von Dokumenten für Anlagen, Systeme und Einrichtungen DIN EN 82045-1

Dokumentenmanagement - Teil 1: Prinzipien und Methoden

294

PLM zum Nachschlagen

DIN EN 82045-2

Dokumentenmanagement - Teil 2: Referenzsammlung von Metadaten und Referenzmodelle 92/59/EWG

Richtlinie über die allgemeine Produktsicherheit VDI 2211 Blatt 2

Informationsverarbeitung in der Produktentwicklung - Berechnungen in der Konstruktion VDI 2216

Datenverarbeitung in der Konstruktion - Einführungsstrategien und Wirtschaftlichkeit von CAD-Systemen VDI 2217

Datenverarbeitung in der Konstruktion - Begriffserläuterungen VDI 2218

Informationsverarbeitung Technologie

in

der

Produktentwicklung

-

Feature-

VDI 2219

Informationsverarbeitung in der Produktentwicklung - Einführung und Wirtschaftlichkeit von EDM/PDM-Systemen VDI 2220

Produktplanung; Ablauf, Begriffe und Organisation VDI 2223

Methodisches Entwerfen technischer Produkte

Fachliteratur

295

VDI 2249

Informationsverarbeitung in der Produktentwicklung - CAD-Benutzungsfunktionen Zeitschriften AUTOCAD Magazin

Fachzeitschrift für AutoCAD-Anwender IWT Magazin Verlags-GmbH CADCAM

Zeitschrift für Computer-Anwendungen in der Entwicklung Konstruktion, Planung und Fertigung mit EDM-Magazin Verlag für Computergrafik GmbH CAD CAM - Magazin für Computer-Anwendungenin Design und Engineering

CAD CAM, das Fachmagazin für technische Entscheider, berichtet in sieben Ausgaben pro Jahr über Trends, Technologien und Erfahrungen mit modernen CAD-, CAE-, CAM- und PLM-Lösungen. Carl Hanser Verlag CAD/CAM-Report

berichtet herstellerungebunden und neutral über die mit der CAD/CAM-, CAE-Technologie verbundener Automation. Dressler-Verlag CAD-News

Das unabhängige Magazin für professionelle CAD-Anwender; regelmäßig auch mit EDM/PDM-Beiträgen up2media AG CADplus

Fachzeitschrift für Visualisierung und Engineering Göller-Verlag

296

PLM zum Nachschlagen

Computer-Graphics-Markt

Die fortschreitende Konzentration am Markt macht den Überblick über die CAx-Branche nicht leichter. Einen hilfreichen Leitfaden durch die CTechnologien bietet daher die aktuelle Ausgabe des Computer-GraphikMarktes. Das Jahrbuch zeigt in fundierten Marktstudien die Entwicklung in Deutschland, in England und in den USA auf und präsentiert in Firmenprofilen und Marktübersichten die verschiedenen Anbieter mit ihren Produkten und Dienstleistungen. Dressler-Verlag eDM-Report

regelmäßig erscheinende Publikation zum Thema Engineering respektive Product Data Management im deutschsprachigen Raum Dressler-Verlag Digital Engineering Magazin

Das DIGITAL ENGINEERING Magazin ist das Management-Magazin im Engineering-Umfeld. Die Zeitschrift berichtet über aktuelle Entwicklungen auf den Gebieten CAD, CAM, CAE, Digital Engineering und Digital Mockup (DMU), Datenmanagement (EDM/PDM, ERP), Product Lifecycle Management und Virtual Reality Industrielle Informationstechnik

Fachzeitschrift für Software, Organisation und Prozessengineering, die vor allem über IT-Trends, Branchenlösungen und betriebswirtschaftliche Strategien informiert. Carl Hanser Verlag Industrie-Management

Zeitschrift für Strategien, Organisation und Informationssysteme GITO-Verlag it & it select - Industrielle Informationstechnik

it Industrielle Informationstechnik erscheint seit November 2003 als fester Sonderteil der ebenfalls im Carl Hanser Verlag erscheinenden ZWF – Zeitschrift für wirtschaftlichen Fabrikbetrieb. Herausgegeben von Prof. Dr.-Ing. (mult.) Günter Spur, Technische Universität Berlin, vermittelt die

Fachliteratur

297

ZWF in zehn Ausgaben pro Jahr neue Erkenntnisse in der Produktionstechnik und aktuelles Wissen über industrielle Leistungserstellungsprozesse. Carl Hanser Verlag SCOPE

Industriemagazin für Fach- und Führungskräfte der Bereiche Entwicklung und Konstruktion Verlag Hoppenstedt GmbH Zeitschrift für wirtschaftlichen Fabrikbetrieb (ZWF)

ZWF behandelt ein breites Spektrum von Fragestellungen bezüglich einer wirtschaftlichen Fertigung im Umfeld der Kernthemen Unternehmensführung, Produktentwicklung und Produktion. Carl Hanser Verlag Internetseiten Nicht kommerzielle Internetseiten http://www.fzi.de/pde/

Prozess- und Datenmanagement im Engineering, Abteilung des Forschungszentrum Informatik an der Universität Karlsruhe (TH) http://www.itm.ruhr-uni-bochum.de

Internetseite des Lehrstuhls für Maschinenbauinformatik der RuhrUniversität Bochum http://www.itm.tum.de/

Internetseite des Lehrstuhls für Informationstechnik im Maschinenwesen der Technischen Universität München http://www.ipk.fhg.de

Internetportal des Fraunhofer Instituts für Produktionsanlagen und Konstruktionstechnik (IPK)

298

PLM zum Nachschlagen

http://www.plm4kmu.de

Webseite des Forschungsprojektes „Vorgehensmodell für ein kontinuierliches Product Lifecycle Informationsmanagement für kleine und mittlere Unternehmen (PLM4KMU)“ aus dem das vorliegende Buch hervorging. http://www.prostep.org/de/

Interessensgemeinschaft von 200 international führenden Unternehmen aus der Automobilindustrie, der Luft- und Raumfahrtindustrie, des Anlagenbaus und verwandter Industriebranchen http://www.plmportal.de

Umfangreiche Informationen über PLM und PDM, Internetseite vor allem für Einsteiger ohne Vorwissen geeignet. http://wwwhni.uni-paderborn.de/index.php3

Fachgruppe für rechnerintegrierte Produktion des Heins Nixdorf Instituts der Universität Paderborn Kommerzielle Internetseiten http://www.johnstark.com/

Beratungsfirma für PLM http://www.pdm-infoshop.de

Josef Schöttner – Industrial Consultant, PLM-Berater http://www.prostep.de/de/services/managementconsulting

PROSTEP AG Dienstleister im Bereich PLM http://www.sendlercircle.com

Ulrich Sendler 1995 CADcircle als Interessengemeinschaft der Anbieter von Engineering Software gegründet, welches nun mit erweitertem Themengebiet im sendler\circle it-forum seine Fortsetzung findet.

Literaturverzeichnis

Monographien

Altrogge G (1996) Netzplantechnik. Oldenbourg Verlag München Wien Balzert H (1992) Die Entwicklung von Software-Systemen. BI- Wissenschaftsverlag 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 EN 82045 (2001) Dokumentenmanagement. Beuth Verlag Berlin Wien Zürich DIN ISO 10007 (2004) Qualitätsmanagement – Leitfaden für Konfigurationsmanagement. Beuth Verlag Berlin Wien Zürich

300

Literaturverzeichnis

DIN V ENV 40003 (1991) Rechnerintegrierte Fertigung (CIM), System Architektur, Rahmenwerk für Unternehmensmodellierung. Beuth Verlag Berlin Wien Zürich 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. Springer-Verlag Berlin Heidelberg Eigner M, Stelzer R (2001) Produktdatenmanagement-Systeme – Ein Leitfaden für Product Development und Life Cycle Management. Springer-Verlag Berlin Heidelberg 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 EXPRESS 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 Änderungsmanagement. Springer Berlin Heidelberg Nagel K (1990) Nutzen der Informationsverarbeitung – Methoden zur Bewertung von strategischen Wettbewerbsvorteilen, Produktivitätsverbesserungen und Kosteneinsparungen. R. Oldenbourg Verlag München, Wien Opitz H (1971) Die richtige Sachnummer im Fertigungsbetrieb. Eine Basis für Rationalisierungsmaßnahmen im Rahmen der Auftragsabwicklung 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 Scheer A-W (1991) Architektur integrierter Informationssysteme. Springer Berlin, Heidelberg

Literaturverzeichnis

301

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 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 Bauer F (1995) Prozessorientierte Wirtschaftlichkeitsbetrachtung von CA-Technologien. Europäische Hochschulschriften Reihe V, Volksund Betriebswirtschaft 1813 Corban M (2004) PLM ist ein Thema für den Mittelstand. Industrieanzeiger 40: 42 f. 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

302

Literaturverzeichnis

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: 340 ff 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 Karcher A (2004) Projekt- und Produktlebenszyklus-Management – Chancen, Nutzenpotenziale und Anforderungen von Produktdatenmanagement (PDM) und Product Lifecycle Management (PLM). Kongressbeitrag: 21. Projektmanagement Forum 2004, Nürnberg, 4. – 7. Oktober 2004 Gesellschaft für Projektmananagement (GPM) 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) Zwicker E (1999) Unterstützung der unternehmensübergreifenden Produktentwicklung durch den Einsatz moderner Informationstechnologien Fortschritt-Berichte VDI Reihe 20 Internet

eClass; Institut der deutschen Wirtschaft Köln http://www.eclass.de/ STEP Portal; ProSTEP iViP Verein e.V. 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

Literaturverzeichnis

303

Kahlert T, EDM/PDM-Systemauswahl Teil I: Technische Aspekte; in: EDMPDM-Newsletter Ausgabe 2/2001 http://www.edmpdm.de/edmpdm_fachartikel/systemauswahl_technik. htm Nutzwertanalyse; Wikipedia Online Lexikon http://de.wikipedia.org/wiki/Nutzwertanalyse

Stichwortverzeichnis

integriertes Produktmodell 36 Akzeptanzmanagement 198 Änderung 147, 209 Änderungsmanagement 145 API 179 ARIS 252 ASP 268 CASE-Tools 257, 261 Check-In 97 Check-Out 97 CORBA 269 CSC Catalyst 231 Customizing 67, 165 Datenbank 266 Datenmodelle 252 Dokumentenmanagement 88, 90

Klassifikationssysteme 121 Komponenten 74 Konfiguration 80, 213 Konfigurationsmanagement 78 Langzeitarchivierung 102 Lastenheft 33, 190, 236 Major Releases 77 Maturity-Modell 50 Metadaten 94 Middleware 269 Migration 268 Nummernsysteme 107, 216 Opitz-Schlüssel 225

eClass 119, 227 ERP 175 EXPRESS 255 EXPRESS-G 255

Historie 79

Parallelnummer 109 PDM Enabler 271 Pflichtenheft 59, 193, 236 PLM 17 PLM-Stab 46 PLM-Vision 47 Produktdaten 36, 80 Produktstruktur 72, 213, 270 Projektmanagement 156, 160 Prozess 133 Prozessmodell 41

Implementierun 66 Inbetriebnahme 69

Repository 258 Revisionierung 76

Form-Fit-Function 74, 210 Freigabe 127, 172, 173 Gant 158 Gültigkeit 211

306

Stichwortverzeichnis

top-down-Methode 151

Varianten 74, 211 Variantenplatzhalter 75 Variantenstücklisten 75 Vault 97, 267 VDI 2219 228 Verbundnummer 109 Version 76 Versionen 209

UML 252 Unternehmensmodelle 131 Unternehmensmodellierung 251

Wiehndahl-Schlüssel 226 Wirtschaftlichkeit 243 Workflow 130

Sachmerkmal 117 Sachmerkmalleiste 117, 223 Sachnummer 112 Sichten 83, 213 STEP 269 Systemintegration 177