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 <= 3 A/C > 4

spezifisch

9

8

3

mit Abweichung L/D <= 2

A/B <= 3 A/C < 4

2

L/D >3

7

1

0,5 < L/D <=3

A/B > 3

0

L/D <= 0,5

Teileklasse

9

8

Bewegungsgewinde

sonstige

7

Funktionskonus

6

4

ohne Formelemente

Funktionseinstich

3

Funktionseinstich

5

2

Gewinde

Gewinde

1

0

ohne Formelemente

Außenform Formelemente außen glatt ohne Formelemente

2. Stelle

o. glatt

0

Rotationsteile

Nichtrotationsteile

einseitig steigend

mehrfach steigend

3. Stelle

3 4

Funktionseinstich ohne Formelemente

sonstige

Bewegungsgewinde

Funktionskonus

Funktionseinstich

9

8

7

6

5

2

Gewinde

Gewinde

1

0

ohne Formelemente

Innenform Formelemente innen ohne Bohrung ohne Durchbruch

einseitig steigend mehrfach steigend

1. Stelle

5

ebene Flächen, u./o. Nut, Schlitz, Vielkeil außen

9

8

Vielkeil, Nut u./o. Schlitz innen und außen sonstige

7

Vielkeil (Polygon), innen

6

4

Vielkeil (Polygon), außen

ebene Fläche u./o. Nut innen

3

2

1

0

Nut und oder Schlitz, außen

ohne Flächenbearbeitung ebene u./o. in einer Richtung gekrümmte Fläche außen Flächen, d. zueinander i. e. Teilungsver. stehen, außen

Flächenbearbeitung

4. Stelle

ohne Verzahnung mit Verzahnung

5. Stelle

sonstige

andere Verzahnung

Kegelverzahnung

Stirnverzahnung

axial u./o. radial u./o. sonstige Richtung axial u./o. radial mit Teilung u./o. sonstige Richtung

radial mit Teilung

axial mit Teilung

axial ohne Teilung

Hilfsbohrung und Verzahnung ohne Hilfsbohrung

112 5 Leithefte zu PLM-Aspekten

5.6 Finden statt Suchen

113

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

A B

Einheit

Referenzhinweis

.......... ..........

..........

SachSachBezeich- Fräsermerkmalnummer nung durchbenennung messer

Kennbuchstabe

..........

Anzahl der Schneiden

D F

G

H

..........

..........

..........

..........

Schneid- Besfesti- Einstell- Grundrichtung gung der winkel form der WSP WSP

E

Charakteristische Merkmale

..........

Fräsertyp

C

Identifizierung und Feinklassifizierung

Sachmerkmalleiste DIN 4000-...

Parallelschlüssel

- Klassifizierung - Benennung - Norm-Nummer

Gegenstandsgruppe

Grobklassifizierung

114 5 Leithefte zu PLM-Aspekten

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

5.6 Finden statt Suchen

115

Abb. 5-22 stellt den Aufbau einer SML an einem Beispiel dar. Es zeigt sich allerdings, dass die charakteristischen Merkmale oftmals zusätzlich in einer Skizze definiert werden müssen, um ein einheitliches Verständnis der Merkmale zu gewährleisten. Dies zeigt jedoch gleichzeitig einen Weg auf, wie aus Informationen eines CAD-Modells bzw. einer Zeichnung Sachmerkmale automatisch gewonnen und in eine SML überführt werden können. Betrachtet man verschiedene CAD-Modelle bzw. Zeichnungen lassen sich darin gleichartige geometrische Strukturen identifiziert, aus denen sich charakteristische Merkmale herausfiltern lassen. eClass ist ein vom „Institut für deutsche Wirtschaft Köln“ zur Materialklassifizierung und Warengruppenbildung initiiertes Klassifizierungssystem, das vor allem im elektronischen Handel Verbreitung findet. Es handelt sich bei eClass um ein hierarchisches Klassifizierungssystem, das in 4 Ebenen unterteilt ist: Sachgebiete, Hauptgruppen, Gruppen und Untergruppen. Die erste Hierarchieebene ist dabei in 22 Sachgebiete gegliedert. eClass eignet sich für die Klassifizierung von Produkten, Dienstleistungen, Waren und Materialien. Mittels Merkmalleisten lassen sich Materialien und Dienstleistungen beschreiben. Diese stehen als Zusammenfassung der spezifischen Produktmerkmale an den hierarchischen Endpunkten der Klassifizierung (z. B. „27-20-02-01: Handthermometer“). Die Merkmalleisten, die in eClass verwendet werden, bauen auf Vorgaben der DIN EN 61360 sowie der Normenreihe ISO 13584 auf. Einsatzgebiete von eClass sind neben einem branchenübergreifenden internationalen MaterialgruppenManagement, Online-Kataloge sowie Online-Ausschreibungen. Das System befindet sich in der Entwicklung unter stetiger Einarbeitung von Anforderungen aus der Industrie. 5.6.3

Voraussetzungen für die Klassifikation

Klassifikationssysteme entstanden aus der Notwendigkeit heraus, Sachverhalte möglichst kurz zu beschreiben. Dazu werden aufgrund ausgewählter Eigenschaften Klassen gebildet und Beziehungen zwischen diesen definiert. Eine Klasse dient der Beschreibung einer Menge von Elementen oder Objekten mit mindestens einer gemeinsamen Eigenschaft. In der Regel werden geometrische oder physikalische Eigenschaften, so genannte Attribute, beschrieben (z. B. hat eine Schraube die Attribute Länge und Gewindedurchmesser). Klassen können strukturiert und die ihnen zugeordneten Attribute an Unterklassen weitervererbt werden. Die Attribute für ein Klassifizierungssystem werden zentral im Attribute-Pool angelegt und verwaltet.

116

5 Leithefte zu PLM-Aspekten

Bei der Zuordnung der Attribute zu den definierten Klassen können diese Attribute aus dem Pool ausgewählt werden. Den Attributen werden bei der Instantiierung der Klasse so genannte Attribut-Werte zugeordnet, welche exakte Werte, "Bereichswerte" (Maximum-Minimum-Wert) oder Formeln sein können. Die Instantiierung einer Klasse (Ausprägung eines Objektes) bedeutet dabei, dass ein konkretes Objekt, das allgemeingültig durch die Klasse beschrieben wird, mit seinen spezifischen AttributWerten beschrieben wird. Bei der Wertangabe wird deren Gültigkeit für das entsprechende Attribut überprüft. Beispiele für Attribute der Klasse Bauteil sind Funktionsbeschreibungen, Gestalt, Material, Freigabedatum, Version etc. Klassifizierte Objekte lassen sich durch eine Suche über die Attribute oder durch absuchen der Klassifizierungshierarchie identifizieren. Beispiele für Klassifizierungshierarchien sind öffentliche (z. B. DIN-) Normen, Werksnormen etc. Wichtig sind Kriterien, nach denen man Objekte gruppieren kann. Im Beispiel in Abb. 5-23 wird gezeigt, dass eine Menge von Objekten nach drei verschiedenen Gesichtspunkten klassifiziert werden kann: Menge von Objekten

Klassifikation

Generalisierung

Spezialisierung kleine Kreise

große Kreise

kleine Dreiecke

Abb. 5-23: Klassifikationsbeispiel

große kleine Dreiecke Vierecke

große Vierecke

5.6 Finden statt Suchen

117

• nach geometrischer Form – Kreis, Dreieck oder Viereck • nach der Größe – kleine und große Figuren und • nach der Farbe – schwarze, weiße und graue Figuren Wenn man eine Gruppe von Objekten wiederum nach bestimmten Eigenschaften aufteilt, können so genannte Teilmengenhierarchien oder Klassifikationsbäume aufgebaut werden. Im Beispiel ist die Gruppe Kreise in zwei weitere Gruppen unterteilt – große und kleine Kreise. In heutigen Unternehmen ändern sich sie Anforderungen an Produkte sehr schnell und die Produktpalette muss ständig erneuert und erweitert werden. Diesbezüglich muss sich auch das Klassifikationssystem dynamisch ändern. Wenn man aus einer Gruppe eine Teilgruppe von Elementen spaltet und neue Unterteilgruppen bildet spricht man vom Spezialisieren und umgekehrt, wenn man zwei oder mehrere Teilgruppen in eine zusammenfügt, dann generalisiert man diese Gruppen. 5.6.4

Aufbau von Klassifikationssystemen

Allgemein lassen sich Klassifikationssysteme in hierarchische, nichthierarchische und hybride Systeme einteilen. Ein Klassifikationssystem wird aus Klassen aufgebaut, die jeweils mit einer Codierung (Schlüssel) versehen werden. Ein zu klassifizierendes Objekt kann einer oder mehreren Klassen des Klassifizierungssystems zugeordnet werden. Im Folgenden werden die einzelnen Systemarten vorgestellt. Nicht-hierarchische Klassifikationssysteme

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

118

5 Leithefte zu PLM-Aspekten Schlüssel: Gewicht Schwer Schweres_Teil 0

Fertigungsart Eigen Eigengefertigtes_Teil

0

Leicht

Fremd Fremdgefertigtes_Teil

1

Fremd Normteil

2

Leichtes_Teil

1

Klassenbezeichnung

definierende Eigenschaft

Codierung

Abb. 5-24: Nicht-hierarchische Klassifikationssysteme Schlüssel: Teiletyp Welle

Welle

0

Zahnrad

Zahnrad

1

Fertigungsart Eigen Eigengefertigtes_Teil

0

Fremd Fremdgefertigtes_Teil

1

Teiletyp

Fremd Normteil

2

Gehäuse Gehäuse

0

Kugellager Kugellager

1

Legende: Oberklasse

Subklassen

Teiletyp Schraube Schraube

0

Abb. 5-25: Hierarchisches Klassifikationssystem Hierarchische Klassifikationssysteme

Im Gegensatz zu den nicht-hierarchischen Systemen sind bei den hierarchischen Klassifikationssystemen die Stellen des Schlüssels voneinander abhängig, d. h. die Bedeutung einer Codierung an einer Stelle hängt von der Codierung einer anderen Stelle ab. Die Abb. 5-25 zeigt ein Beispiel für ein hierarchisches Klassifikationssystem. Bei dem dargestellten Klassifikationssystem handelt es sich ebenfalls um einen zweistelligen Klassifikationsschlüssel. Im Gegensatz zu nichthierarchischen Klassifikationssystemen ist jedoch die Bedeutung der Codierung der zweiten Stelle abhängig von der Codierung der ersten

5.6 Finden statt Suchen

119

Stelle. Eine Codierung von „1“ an der zweiten Stelle kann sowohl ein Zahnrad als auch ein Kugellager auszeichnen. Der Schlüssel „0-1“ entspricht einem eigengefertigten Zahnrad. Der Schlüssel „1-1“ bedeutet hingegen, dass es sich um ein fremdgefertigtes Kugellager handelt. Hybride Klassifikationssysteme

Neben den rein hierarchischen und den rein nicht-hierarchischen Klassifikationssystemen gibt es auch Mischformen, sog. hybride Klassifikationssysteme. Die Stellen eines solchen hybriden Klassifikationssystems sind teilweise voneinander unabhängig, teilweise hängt die Bedeutung einer Codierung von einer anderen Stelle ab. Abb. 5-26 zeigt ein Beispiel für ein hybrides Klassifikationssystem. Die Bedeutung der Codierung der zweiten Stelle des dargestellten dreistelligen Klassifikationsschlüssels ist abhängig von der ersten Stelle. Die Codierung der dritten Stelle (Farbe) hat immer die gleiche Bedeutung. Codierung klassifizierter Datensätze Datensatz 1: Codierung

0 2

b

Datensatz 2: Codierung

0 0

r

.. ..

..

.. ..

..

...

...

Datensatz n : Codierung

Hierarchie 1

Einzelteil

Rotationsteil kurz

Nicht-Rotationsteil

0 0

DS 2

mittel 1 lang

2

Formatstring X-X

DS 1

Abb. 5-26: Hybrides Klassifikationssystem

1

Farbe rot

r

grün

g

blau

b

DS 2

DS 1

120

5 Leithefte zu PLM-Aspekten

Klassifikationstiefe

Bei hierarchischen Klassifikationssystemen ist der Begriff der Klassifikationstiefe von besonderer Bedeutung. Die Klassifikationstiefe beschreibt die Anzahl der Hierarchieebenen, in die ein hierarchisches Klassifikationssystem unterteilt wird. Der Vorteil einer hohen Klassifikationstiefe liegt in der exakteren Beschreibung der zu klassifizierenden Objekte durch den Klassifikationsschlüssel, d.h. die Aussagekraft des Schlüssels nimmt zu. Darüber hinaus ist die Anzahl der Objekte mit gleichen Eigenschaften relativ klein und damit für eine Auswahl schneller überschaubar. Nachteilig ist dagegen der erhöhte Aufwand für die Vergabe des Schlüssels und die Pflege des Klassifikationssystems. 5.6.5

Klassifikation im Product Lifecycle Management

Der Vorteil für das Auffinden von Informationen durch die Anwendung eines Klassifizierungssystems kann erheblich sein, was sich jedoch erst in einem mittel- bis langfristigen Zeitraum auszahlt. Für die Klassifizierung ist allerdings auch ein Mehraufwand zu leisten, da jede Baugruppe bzw. jedes Bauteil zu klassifizieren ist. Die wesentlichen Anwendungsfälle der Klassifikation sind: • • • • •

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

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

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

5.6 Finden statt Suchen 5.6.6

121

Umsetzung der Klassifikation

Die Einführung eines Klassifikationssystems umfasst im Allgemeinen die folgenden Schritte: • Analyse der produktbeschreibenden Datenbestände eines Unternehmens • Erarbeitung der klassifikationsrelevanten Merkmale • Strukturierung der Merkmale und Aufbau eines angepassten Klassifikationssystems. Da die Zahl der produktbeschreibenden Eigenschaften sehr groß sein kann, sollte die Zahl der Merkmale auf die relevanten reduziert werden. Oft sind klassifikationsrelevanten Produkteigenschaften nicht explizit verfügbar. Um diese zur Verfügung zu Stellen sind die beschreibenden Datensätze um Attribute für dieses Merkmal zu ergänzen. • Einordnen der produktbeschreibenden Datenbestände in das Klassifikationssystem. Die richtige Anwendung der Klassifikation setzt Richtlinien für die genaue Interpretation der Merkmale voraus. Da auf viele Besonderheiten Rücksicht genommen werden muss, sind die Richtlinien meist umfangreicher als die Klassifizierung selbst. Weiterführende Literatur

Hans Grabowski, Ralf-Stefan Lossack, Jörg Weißkopf: Datenmanagement in der Produktentwicklung; Fachbuchverlag Leipzig, 2001; ISBN: 3446216987 Normen und Standards

• DIN 4000: Teil 1 enthält die Begriffe und Grundsätze zu Sachmerkmal-Leisten. Alle weiteren Teile enthalten genormte Sachmerkmalleisten bestimmter Bauteilklassen, z.B. Schrauben, Muttern, Scheiben und Ringe usw. • DIN EN 61360: Genormte Datenelementtypen mit Klassifikationsschema für elektrische Bauteile. Teil 1 enthält Definitionen, Regeln und Methoden. • ISO 13584: Industrielle Automatisierungssysteme und Integration Teilebibliothek Teile 1 der Norm beinhaltet einen Überblick und Grundlagen und Teil 42 die Methodik für die Strukturierung von Teilefamilien. • EAN (European Article Numbering) System, EAN International Assoc.: Produktnummernsystem für das Barcoding und die Materialwirtschaft. Internet: http://www.ean-int.org

122

5 Leithefte zu PLM-Aspekten

• UPC (Universal Product Code), Uniform Code Council, Inc.: Produktnummernsystem. UPC ist das Gegenstück von EAN in den USA und Kanada Internet: http://www.uc-council.org • SIC (Standard Industry Classification), U.S. Department of Labor: Der SIC ist ein vierstelliges Klassifikationssystem von Industrien für statistische Zwecke. SIC wurde 1987 erstellt. Internet: http://www.osha.gov/pls/imis/sic_manual.html • NAICS (North American Industry Classification System), U.S. Census Bureau: sechsstellige Erweiterung des SIC-Systems um weitere Industrien. NAICS ist 1997 in den USA eingeführt worden. Internet: http://www.census.gov/epcd/www/naicscod.htm • UNSPSC (United Nations Standard Products and Services Code): Der UNSPSC stellt einen offenes, globales branchenübergreifenden Standard für die Klassifikation von Produkten and Dienstleistungen dar. Internet: http://www.unspsc.org • The Thomas Register: Das Thomas Register unterhält ein umfassendes privates Produktklassifikationsschema. Alle Produkte der Mitglieder sind dort kategorisiert und verzeichnet. Internet: http://www.thomasregister.com

5.7 Prozesse gestalten und steuern

5.7

123

Prozesse gestalten und steuern

Æ Freigabe- und Änderungswesen Æ Applikationsintegration

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

124 5.7.1

5 Leithefte zu PLM-Aspekten Prozess- und Organisationsmanagement

Das Prozess- und Organisationsmanagement beinhaltet die Gestaltung der Abläufe und Strukturen eines Unternehmens. Das Workflowmanagement als Teil des Prozess- und Organisationsmanagements unterstützt allgemein die Steuerung von betrieblichen Abläufen. Weitere spezielle Abläufe mit erhöhten Anforderungen an die Managementaufgaben sind das Freigabeund Änderungsmanagement, Prüfabläufe, Statusmanagement und die kollaborative Produktentwicklung (s. Abb. 5-27).

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-27: Prozess- und Organisationsmanagement im PLM

5.7 Prozesse gestalten und steuern 5.7.2

125

Unterstützung von Prozessen und Organisation

Die Informationslandschaft eines Unternehmens wird von Prozessen, dem Fluss von Dokumenten durch die Unternehmensbereiche und den verwendeten Hilfsmitteln sowie der organisatorischen Struktur der Gruppen, Abteilungen und Bereiche geprägt und stellt ein Abbild des Unternehmens dar. Aber nur eine ganzheitliche Sicht auf das Unternehmen ermöglicht es, zusammenhängende Prozesse zu erkennen, zu optimieren und durch geeignete Informationssysteme zu unterstützen. Für die Dokumentation und Analyse von Geschäftsprozessen und Organisationsstrukturen werden deshalb Unternehmensmodelle erstellt, mit deren Hilfe die komplexen Zusammenhänge übersichtlich beschrieben werden können. Der Entwicklungsfortschritt und die Verwendung jeder Produktkomponente und jedes produktbeschreibenden Dokumentes wird im Produktlebenszyklus durch bestimmte Aktivitäten beschrieben, welche die Freigaben, die Änderungen oder die Status eines Dokuments festlegen. Die Verknüpfungen einzelner Aktivitäten miteinander bilden Prozesse, an denen verschiedenste Personen aus unterschiedlichen Abteilungen beteiligt sind. Die Weitergabe von Informationen, meist in Form von Dokumenten, von einer Abteilungen oder einem Mitarbeiter an die nächste Organisationseinheit des Unternehmens wird Informationsfluss genannt. Betrachtet man die Prozesse aus einer mit einer auf ein Dokument zentrierten Sichtweise, so bilden die mit dem Dokument verknüpften Aktivitäten und die mit diesem Aktivitäten einhergehenden Änderungen der Status des Dokuments die so genannten Statusnetze. Zur informationstechnischen Unterstützung von Geschäftsprozessen werden Workflow-Managementsysteme eingesetzt, in denen die Prozesse abgebildet werden. Der vom Informationssystem gesteuerte Prozess mit seinen Prozessschritten verknüpft mit den zuständigen Ressourcen bzw. Personen, bildet den so genannten Workflow. WorkflowManagementsysteme können sowohl eigenständige Systeme als auch Module von Integrationssystemen sein. Die Grundidee eines WorkflowManagementsystems besteht in der Trennung der administrativen Tätigkeiten Planung, Steuerung und Kontrolle von Prozessen, die vom System unterstützt werden, von der eigentlichen Aufgabendurchführung. Ein Workflow-Managementsystem steuert die Bearbeitung eines Prozesses indem es die einzelnen Aktivitäten mit den benötigten Ressourcen (Mitarbeiter und Werkzeuge) verbindet und entsprechend der Verkettung der Aktivitäten deren Durchführung überwacht und protokolliert. Ein Benachrichtigungsdienst stellt sicher, dass ein betroffener Nutzer in einfacher Weise die Information erhält, dass er bestimmte Aufgaben durchführen soll. Gleichzeitig mit den Informationen zur Aufgabenstellung

126

5 Leithefte zu PLM-Aspekten

erhält der Bearbeiter auch Informationen über alle betroffenen Dokumente und den Zugriff auf diese. Der Benachrichtigungsdienst kann im Workflow-Managementsystem integriert sein, in den meisten Fällen wird er an externe Mailing-Systeme angebunden. Nach Abschluss einer Aktivität erfolgt eine Rückmeldung im System, wodurch die folgende Aktivität angestoßen wird. Zusätzlich kann für eine Aktivität ein Fertigstellungstermin oder Bearbeitungszeitraum festgelegt werden, nach dessen Überschreiten das Workflow-Managementsystem weitere Personen, wie den Vorgesetzten des zuständigen Mitarbeiters oder einen Projektverantwortlichen, automatisch über die Terminüberschreitung informiert. Die im Prozess verarbeiteten Informationen sind üblicherweise Artikel und/oder Dokumente. Alle zu einem Workflow gehörenden Artikel und Dokumente können zur einfacheren Handhabung in einer so genannten Mappe zusammengefasst werden. Eine Mappe ist ein Objekt von Integrationssystemen, das verschiedene Objekte (Artikel, Dokumente etc.) aufnehmen kann. Da eine Mappe eine Nummer und einen Namen besitzt, ist sie viel leichter zu handhaben, als die Menge der einzelnen Dokumente. Eine derartige Mappe kann im Laufe der Bearbeitung auch jederzeit weitere Objekte aufnehmen. Zudem erleichtert eine Mappe die Ausführung bestimmter Methoden für alle enthaltenen Objekte. So können z. B. bei der Abarbeitung des Änderungsauftrags alle betroffenen Objekte, die in der Mappe enthalten sind, in den Status „in Änderung“ überführt werden. 5.7.3

Kenntnis von Prozess- und Organisationsstrukturen

Für die Gestaltung von Informationssystemen zur Unterstützung der Geschäftsprozesse und Organisation hat sich die Unternehmensmodellierung als geeignetes Werkzeug erwiesen. Im Rahmen der Modellierung analysierte und gegebenenfalls neu strukturierte Unternehmensprozesse bilden die Basis für die Konzeption und Implementierung von Integrationssystemen zur Unterstützung der betrieblichen Abläufe im Produktlebenszyklus. Zudem unterstützt die Unternehmensmodellierung die Bildung einer unternehmensweit einheitlichen Begriffswelt. Dadurch ermöglicht ein Unternehmensmodell eine engere Zusammenarbeit von Prozessverantwortlichen und Systementwicklern, da Unternehmensabläufe die Betrachtungsweisen von im Prozess stehenden Personen und Systementwicklern zusammenbringen. Sie ermöglichen einerseits die Beurteilung der Effizienz von Abläufen, ihrer Zielausrichtung und der Aufgaben einzelner Mitarbeiter durch den Prozessverantwortlichen. Andererseits stellen sie eine Art Lastenheft für die Entwickler von Informationssystemen dar.

5.7 Prozesse gestalten und steuern

127

Unternehmensmodell

Planung Unternehmensstrukturierung Planung von IT-Systemen Bewertung und Auswahl von Software

Dokumentation

Anwendungen

IST-Analyse zur Entscheidungsvorbereitung

Nutzung als betriebliches Informationssystem

Dokumentation von QM-Systemen

Anpassen von IT-Systemen

Simulation von Abläufen Planung von Qualitätsmanagementsystemen

Abb. 5-28: Anwendungsmöglichkeiten von Unternehmensmodellen

Anforderungen können direkt aus den durch Software zu unterstützende Unternehmensabläufen abgeleitet werden. Dies ermöglicht die individuelle Anpassung der zu entwickelnden Software an die Bedürfnisse der Anwender. Voraussetzung hierfür ist jedoch ein sowohl informatives und für Ungeübte verständliches als auch präzises Unternehmensmodell, welches das Zusammenspiel von Prozessen, Tätigkeiten, Informationen, Mitarbeitern und unterstützender Informationstechnologie geeignet beschreibt (Weber 1997). Unternehmensmodelle können für unterschiedlichste Zwecke verwendet werden. Grundsätzlich lassen sich, wie in Abb. 5-28 dargestellt, die Anwendungsmöglichkeiten von Unternehmensmodellen in Planung, Dokumentation und Anwendungen einteilen. Unternehmensmodelle stellen somit eine enorme Wissensbasis in Bezug auf die Unternehmensorganisation und -abläufe dar und es lässt sich folgender Nutzen aus ihnen ziehen (Milde 1997): • Die prozessorientierte Betrachtung des Zusammenwirkens von betrieblichen und überbetrieblichen Organisationseinheiten wird ermöglicht. • Eine rasche Anpassung an sich ändernden Randbedingungen kann erfolgen.

128

5 Leithefte zu PLM-Aspekten

• Eine stärkere Kundenorientierung des Unternehmens wird unterstützt • Eine leicht verständliche und präzise grafische Darstellung von Prozessen unterstützt die Diskussion des Ist-Zustandes und der Auswirkungen möglicher Optimierungen. • Ein Unternehmensmodell dient als Grundlage für den Aufbau von Qualitätsmanagementsystemen. • Ein Unternehmensmodell ist Basis für die Auswahl, Anpassung und Einführung von Informationssystemen. • Die automatisierte Verteilung von Informationen auf Basis der SollProzesse eines Unternehmensmodells verhindert unnötige Prozessverzögerungen und die Produktivität kann durch eine kürzere Durchlaufzeit angehoben werden. • Die Mitarbeiterzufriedenheit wird durch die Transparenz und das Verständnis für die unternehmensweiten Abläufe erhöht. 5.7.4

Workflowmanagement mit Modellen

Das Workflowmanagement koordiniert und kontrolliert den Informationsfluss innerhalb eines Prozesses zwischen den beteiligten Mitarbeitern. Ein Informationssystem kann hierbei die Koordination von Systembenutzern, Daten und Ressourcen unterstützen und kontrolliert, dass die jeweiligen Verantwortlichen für einen Prozessschritt die von ihnen geforderten Arbeitsanteile leisten. Routinetätigkeiten werden vom System automatisch ausgeführt. Im Sinne eines verzögerungsfreien Ablaufs stellt die Dokumentenverteilung im Zusammenhang mit dem Workflowmanagement sicher, dass zu einem definierten Zeitpunkt (z. B. nach einem Wechsel des Status) die Dokumente automatisch an die relevanten Personen weitergegeben werden. Eng mit dem Workflowmanagement verknüpft ist die Rechteverwaltung, die regelt, welche Person zu einem bestimmten Zeitpunkt welche Tätigkeit ausführen darf, ob sie beispielsweise auf Dokumente zugreifen oder Dokumente neu erzeugen oder ändern darf. Die Art des Zugriffs auf ein Dokument ist dabei von der Aufgabe (z.B. Ändern, Prüfen) und dem Status (z.B. in Bearbeitung, Freigegeben) abhängig. Entsprechende Regeln werden im Prozess festgelegt. Zur Unterstützung der Definition der Workflows im Informationssystem hat es sich als hilfreich erwiesen zunächst ein entsprechendes Unternehmensmodell der Ist- bzw. Soll-Zustände zu erstellen. Hierzu können verschiedenste Werkzeuge herangezogen werden (s. Abschnitt 6.10) (Bullinger u. Schreiner 2001). Grundsätzlich sollte ein geeignetes Modell jedoch die folgenden Elemente übersichtlich darstellen und zueinander in Beziehung setzen:

5.7 Prozesse gestalten und steuern

129

• Prozess, Teilprozess, Aktivität Ein Prozess ist eine Menge von verknüpften Aktivitäten, also Prozessschritten die nicht weiter zerlegt werden können. Um einen Prozess übersichtlicher beschreiben zu können werden zusammengehörige Mengen von Aktivitäten zu Teilprozessen verknüpft, die wiederum miteinander verknüpft den Gesamtprozess bilden. Auf diese Weise wird eine hierarchische Prozessstruktur aufgebaut. In der Literatur wird der Prozess in einem Unternehmen auch als „Geschäftsprozess“, „Unternehmensprozess“ oder „business process“ bezeichnet. • Eingangs-/Ausgangsinformationsflüsse Der Prozess wird durch ein Startereignis ausgelöst, wobei seine Aktivitäten in geregelter Abfolge mit Hilfe festgelegter Ressourcen Eingangsinformationsflüsse verarbeiten und als Ergebnis Ausgangsinformationsflüsse liefern. Zur Übermittlung des Eingangsinformationflusses und zur Auslösung des Prozesses ist zumindest eine Quelle notwendig, sowie ein Ziel, das die Ausgangsinformationsflüsse abnimmt. • Ereignisse Ereignisse dienen der Beschreibung von Zuständen, die nach Ausführung von Aktivitäten eintreten oder Vorbedingung für die Ausführung von Aktivitäten sind. Beispiele für Ereignisse sind „Dringendes Problem aufgetreten“, „Änderungsauftrag liegt vor“ oder zeitliche Bedingungen wie „Jeden Dienstag 9 Uhr“. • Zuständigkeiten Für die Gestaltung, Ausführung und ständige Verbesserung des Prozesses wird eine Organisationseinheit in jedem Prozess bzw. für jede Aktivität festgelegt. Sie kann eine Abteilung, eine Gruppe, eine Stelle oder eine einzelne Person sein. • Werkzeuge/Ressourcen Zur Ausführung des Prozesses werden Hilfsmittel benötigt, die bestimmte Tätigkeiten innerhalb des Prozesses unterstützen, um die Ziele eines Prozesses zu erreichen. Dies kann Räumlichkeiten, Maschinen, Anlagen oder Softwaresysteme beinhalten. Neben der Möglichkeit Unternehmensstrukturen und Prozesse in einfachen Diagrammen auf Papier oder digital darzustellen, bieten spezialisierte Software-Werkzeuge mit integrierten Unternehmensmodellen Vorteile bei der Erstellung und Nutzung des Modells. Ein Diagramm stellt dabei eine bestimmte Sicht auf das Unternehmensmodell dar, wie beispielsweise die Aufbauorganisationssicht oder die Prozesssicht. Bei der Erstellung von weiteren Diagrammen können bereits vorhandene Elemente in anderem Zusammenhang dargestellt werden. Bei Änderungen muss auf diese Weise nur das jeweilige Element des Modells geändert werden, so dass die

130

5 Leithefte zu PLM-Aspekten

Sichten in denen das Element vorhanden ist, durch eine Aktualisierung der Darstellung die Änderungen übernommen werden. Ein weiterer Vorteil ist die Möglichkeit mancher Werkzeuge Prozesse oder Informationsflüsse zu simulieren, so dass auf diese Weise Optierungsmöglichkeiten oder Hemmnisse ermittelt werden können. Einige Werkzeuge erlauben auch die Nutzung des Unternehmensmodells zur Anpassung von IT-Systemen, da sie über spezielle Schnittstellen zu den Modellierungswerkzeugen verfügen. Abb. 5-30 zeigt ein Beispiel einer Sicht auf einen Prozessablauf. In der Mitte sind die einzelnen Prozessschritte mit ihren Abhängigkeiten zu Ressourcen, Zuständigkeiten und Informationsflüssen dargestellt. Für die Beschreibung des Ablaufs werden neben der Reihenfolge der einzelnen Tätigkeiten auch Ereignisse und Verzweigungselemente benötigt. Auf der linken Seite werden die Zuständigkeiten und Ressourcen beschrieben, die für die Durchführung der einzelnen Prozessschritte verantwortlich sind bzw. für sie benötigt werden. Auf der rechten Seite sind die Informationsflüsse dargestellt, die in die einzelnen Prozessschritte als Eingangsinformation eingehen bzw. als Ausgangsinformation erzeugt werden. Leitet man aus der auf die Tätigkeit zentrierten Prozesssicht eine auf ein Dokument zentrierte Sicht ab, erhält man als Darstellung ein so genanntes Statusnetz. In Abb. 5-29 ist das Statusnetz des Informationsobjekts „Entwurf“ dargestellt, das die Sicht auf die verschiedenen Status einer Information mit den statusändernden Prozessschritten beschreibt. in Bearbeitung

Entwurf nacharbeiten

zur Prüfung schicken

Entwurf prüfen

zur Prüfung

geprüft

Abb. 5-29: Statusnetz des Informationsobjektes „Entwurf“ in Merge Notation

5.7 Prozesse gestalten und steuern Start

Entwicklungsauftrag (freigegeben) Lastenheft (freigegeben)

Produkt entwerfen

Pflichtenheft (freigegeben)

Adler GmbH Entwicklung Team 1 Mitarbeiter

Zur Prüfung schicken Entwurf (in Bearbeitung)

O

CAD

Entwurf (zur Prüfung)

Naß, A. [1010010]

Entwurf prüfen

O Entwurf (in Bearbeitung) PDM/PLM nicht OK

OK Entwurf (geprüft) Ende

Adler GmbH Entwicklung Team 1 Mitarbeiter

Entwurf nacharbeiten

Entwurf (zur Prüfung)

Legende Entwurf (in Bearbeitung)

Informationsobjekt (Status)

Zur Prüfung schicken

Entwurf prüfen

Prozessschritt O

Prüfschritt CAD

Werkzeug/Ressource

Naß, A. [1010010]

Stelle/Mitarbeiter

Adler GmbH Entwicklung Team 1 Mitarbeiter

Organisation

Abb. 5-30: Beispiel Prozessdarstellung in Merge-Notation

131

132 5.7.5

5 Leithefte zu PLM-Aspekten Prozessmanagement als Basis der Systemanpassung

Um die Geschäftsprozesse eines Unternehmens mit IT-Systemen zu unterstützen und Teilprozesse zu automatisieren, müssen diese Systeme an die speziellen Anforderungen dieses Unternehmens angepasst werden und die benötigten Funktionen zur Verfügung stellen. In Abbildung Abb. 5-31 ist die Anwendung des Unternehmensmodells zur Systemanpassung dargestellt. Das Unternehmensmodell stellt die zur Anpassung des ITSystems benötigten Informationen wie Organisationsstruktur, Statusnetze, Prozesse Ressourcen und Zuständigkeiten zur Verfügung. Anhand dieser Informationen werden die systeminternen Abläufe des Informationssystems gestaltet. Umgekehrt stellt das Unternehmensmodell eine Möglichkeit dar, Änderungen am IT-System zu dokumentieren. Datenmodell

Statusnetz

Berechtigungsmodell

IT-System

Prozesssicht Ressourcensicht Unternehmensmodell Tätigkeits-/ Informationsflusssicht

Integrierte Sicht

Objektsicht

Organisationssicht

Abb. 5-31: Anwendung des Unternehmensmodells zur Systemanpassung

5.7 Prozesse gestalten und steuern

133

Insbesondere PDM- und Workflow-Managementsysteme müssen Aufgrund ihrer Funktionen der Unterstützung und Automatisierung von Prozessen sehr intensiv an individuelle Unternehmensgegebenheiten angepasst werden. Die Anpassung eines Informationssystems an das Unternehmen kann durch individuell programmierte Systeme erfolgen, wobei dies aufgrund des Aufwandes für Implementierung und Wartung nur noch selten geschieht. In der Regel werden stattdessen Standardsoftwaresysteme eingesetzt, die den Anforderungen entsprechend angepasst oder erweitert werden (s. Leitheft „Auf Standardsystemen aufbauen“ Abschnitt 5.10). Die Nutzung eines Unternehmensmodells im Rahmen des Anpassungsprozesses ist in Abb. 5-32 schematisiert dargestellt (Adamietz 2001). Das Unternehmensmodell ist ein Teil des generischen PLM-Manifests (s. Abschnitt 4.1.3) im evolutionären Vorgehensmodell und es entsteht während der Phasen „PLM-Requirement-Management“ (s. Abschnitt 4.3), „PLM-Solution-Design“ (siehe Abschnitt 4.4) und „Implemenatation & Integration“ (s. Abschnitt 4.5). Das Unternehmensmodell enthält den ermittelten Ist-Zustand der Prozesse und Organisation des Unternehmens. Darauf aufbauend wird das Soll-Konzept entwickelt, das festlegt wie und welche Prozesse zukünftig von einem Informationssystem unterstützten oder automatisiert werden. In der nachfolgenden Anpassungs-Phase wird das Soll-Konzept im System implementiert und nach einer Testphase in den produktiven Zustand überführt. 5.7.6

Erstellen eines Unternehmensmodells

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

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

134

5 Leithefte zu PLM-Aspekten

IST-Zustand

Soll-Konzept

Anpassung

Systemzustand (produktiv)

Dokumentenmanagement

Workflowmanagement

Abb. 5-32: Schematische Darstellung der Systemanpassung Abbildung von Informationen und Informationsträgern

Die Beschreibung der Informationen bei der Unternehmensmodellierung nimmt einen großen Stellenwert ein, da die Informationsverwaltung den Hauptzweck des Systemeinsatzes darstellt. Deshalb sollte eine differenzierte Beschreibung von Informationsobjekten erfolgen. Daraus sollte u. a. ersichtlich sein, welche Zustände ein Informationsobjekt annehmen kann, welche Daten es enthält und wie es gespeichert und übermittelt wird. Zur Beschreibung der Informationsträger und Informationen mit ihren Attribu-

5.7 Prozesse gestalten und steuern

135

ten ist ein Datenmodell erforderlich, das detailliert die Zusammenhänge zwischen den einzelnen Objekten beschreibt. Da der papierlose Datenaustausch in vielen Bereichen eines Unternehmens noch nicht realisiert ist und der Informationsaustausch mittels physischer Medien (wie Papier, Disketten usw.) in absehbarer Zeit auch nicht vollständig durch elektronische Informationswege ersetzt werden wird, sollten diese Informationsträger bei der Systemanpassung mit berücksichtigt werden. Allerdings sollten geprüft werden, ob eine Optimierung möglich ist. Abbildung von Datenstrukturen

Eng verknüpft mit der Abbildung der Informationsträger ist die Abbildung der Datenstrukturen, aus denen die Informationen aufgebaut sind. Beispielsweise wird die Information „Produktstruktur“ aus verknüpften Elementen des Datenobjekts „Artikel“ aufgebaut. Gängige Modellierungsmethoden sind hier die Unified Modelling Language (UML) oder EXPRESS im Produktdatenbereich (siehe Abschnitt 6.9.2) Abbildung von Prozessschritten

Zur Abbildung der Prozesse ist es erforderlich, Informationsobjekte, Aktivitäten und Zuständigkeiten zusammenzuführen. Dies bedeutet, dass die Aktivitäten in Systemfunktionen, die Mitarbeiter aus dem Organisationsmodell als Benutzer in das Berechtigungsmodell und die Informationen und Informationsträger in das Datenmodell abzubilden sind. Die Prozesse sollten realitätsnah abgebildet werden um eine möglichst ideale Prozessunterstützung zu gewährleisten. Das heißt, dass der Prozess den im Unternehmen gelebten Prozess abbildet und dieser akzeptiert ist, so dass das ITSystem nicht wegen zu komplizierter Bedienung oder Unhandlichkeit des implementierten Prozesses umgangen wird. Bei der Konzeption der Soll-Prozesse vor der Implementierung sollten die Prozesse noch auf mögliche Optimierungsmöglichkeiten geprüft werden. Beispielsweise könnten Papierformulare durch elektronische Formulare ersetzt werden und eventuell können in diesem Fall Prozessschritte eingespart werden. Es bietet sich auch an die Informationsflüsse der wichtigsten Dokumente durch die Organisationsstruktur zu verfolgen und so unnötige Wege einzusparen bzw. „Engpass“-Stellen aufzudecken.

136

5 Leithefte zu PLM-Aspekten

Adler GmbH

Geschäftsführer Qualitätssicherung

EDV

Leiter Müller, R.

Leiter Walter, V.

Materialwirtschaft

Leiter Tischler, T.

Konstruktion

Produktion

Leiter Zimmermann, S.

Leiter Bauer, K.

Leiter Schneider, T.

Vertrieb

Arbeitsvorbereitung

Leiter Schlachter, R.

Leiter Schumacher, B.

Leiter Materialwirtschaft Mitarbeiter Zwing, E.

Leiter Materialwirtschaft Leiter Bauer, K.

Entwicklung Team I Leiter Konstruktion Mitarbeiter Naß, A.

Marketing Leiter Vertrieb Leiter Schlachter, R.

Technische Unterstützung Leiter Vertrieb Mitarbeiter Hermann, G.

Fertigung II

Fertigung I

Einkauf

Sachbearbeitung

Leiter Produktion Leiter Schneider, T.

Leiter Produktion Mitarbeiter Lang, S.

Entwicklung Team II

Normung Leiter Konstruktion Leiter Zimmermann, S.

Leiter Konstruktion Mitarbeiter Weber, H.

Arbeitsplanung

Arbeitsmittel

Leiter Arbeitsvorbereitung Mitarbeiter Graf, J.

Leiter Arbeitsvorbereitung Mitarbeiter Dietrich, K.

Abb. 5-33: Organigramm der fiktiven Adler GmbH

5.7 Prozesse gestalten und steuern

137

Überprüfung der Systemanforderungen

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

Die Implementierung von Prozessen als System-Workflows kann zum einen als einfache Benachrichtigung der zuständigen Personen ausgeführt werden. So können für eine Bearbeitung einer Aufgabe (teilweise) ausgefüllte Vorlagen mit gesendet werden. Eine weitere Automatisierungsmöglichkeit besteht hier in der Integration von weiteren Systemfunktionen in den Workflow. Beispielsweise kann ein Programm, das zur Bearbeitung eines Prozessschrittes benötigt wird, automatisch mit den zugehörigen Daten gestartet werden oder Datenelemente eines Dokumentes werden automatisch in Datenfelder eines andern Informationssystems, wie zum Beispiel eines PDM-Systems, übernommen. Die Dokumentation dieser Anpassungen, die in der Regel von den Softwarehäusern durchgeführt wird, spielt eine wichtige Rolle für eventuelle Software-Releasewechsel oder beim Wechsel des Dienstleisters. Das folgende Beispiel zeigt einige Beispiel der fiktiven Firma „Adler GmbH“ für einzelne Sichten auf das Unternehmensmodell der Firma. Das Organigramm in Abb. 5-33 zeigt die Firma mit der Geschäftsführung und den Stababteilungen EDV und Qualitätssicherung sowie den einzelnen Abteilungen. Als weitere Elemente der Organisationsstruktur sind unter den Abteilungen noch Teams zugeordnet. In der Abb. 5-34 ist der Prozess zur Durchführung von „Änderungen“ in diesem Unternehmen dargestellt. Da die Bearbeitung einer Änderung wegen der Austauschbarkeit des Änderungsobjektes sich unterscheidet, werden die ersetzbare und unersetzbare Änderung als zwei Prozessmodule beschrieben, die nochmals genauer modelliert werden.

138

5 Leithefte zu PLM-Aspekten

Start

Änderungsantrag (neu)

Änderungsantrag prüfen

Änderungsantrag (genehmigt)

O

Änderungsantrag (storniert)

Naß, A. [1010010] genehmigt

abgelehnt

CAD

Ende Austauschbarkeit prüfen

Änderungsantrag (beauftragt)

PDM/ PLM O Adler GmbH

austauschbar

Änderungsantrag (erledigt)

nicht austauschbar

Entwicklung Team 1 Mitarbeiter

unersetzbare Änderung Änderungsantrag (storniert)

ersetzbare Änderung

Änderungsantrag (erledigt)

U

inaktive Informationen ablegen

Änderungsantrag (storniert)

Stückliste Ende

CAD-Modell Zeichnungen Datenblatt archiviert

Abb. 5-34: Beispiel eines Änderungsprozesses

PDE-KONPRF

PDE-KONNOR

PDE-KONKON

PDE-AVBPRF

PDE-AVBPLN

PDE-AVBKON r r r r w

r r r r r

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

r

w r

r r w

r r r

w r w

r r w

r r o d

PLUDERW

SCHNEIDERT

WEBERH SIEGELS

WANGM CHANGJ

WEISG LEEJ

ZIMMERMANNS

GRAFJ KRAFTM GREENR

MUELLERR SCHUHMACHERB DIETRICHK BACHERG KUEHNS

User-Name

o SCHLACHTERR w r SCHLOSSERS w HERMANNG r SCHILLINGA w X ARNOLDR w WALTERV SINGERT

w r

w w

X X X X X

r

w

o o d o d w X r X

r

w

r r

w r

w r r

r r

w w r

r r

w r

X o o w w w o X w r r w wX r d X r d X r X d w w r X r r X r r X d w w r X r r X r r w w o X w r r o X w d X d X o X d X r w w w r r r w r r

r r

r r

w r

r r

w r

r r

r r

o o X o w o X d w r r d X r d X r r d X r r d o X w r w w wX r r d X r r d X r w w w o r r r w r r r r r r w w r o d d w w r o d d w w w r r w r r

Z D Z D Z D Z D Z D Z D Z D Z D Z D Z D

PDE-PRODUK

PDE-AL-ARBEITSVOR PDE-TL-ARBEITSMITT PDE-PROGRAMMIERER PDE-KONSTRUKTEUR PDE-KONSTRUKTEUR PDE-TL-ARBEITSPLAN PDE-PR-ARBEITSVOR PDE-ARBEITSPLANER PDE-ARBEITSPLANER PDE-AL-KONSTRUKTION PDE-TL-NORMEN PDE-PR-KONSTRUKTION PDE-NORMENSTELLER PDE-NORMENSTELLER PDE-TL-KONSTRUKTION PDE-KONSTRUKTEUR PDE-KONSTRUKTEUR PDE-TL-KONSTRUKTION PDE-KONSTRUKTEUR PDE-KONSTRUKTEUR PDE-AL-PRODUKTION PDE-TL-FERTIGUNG PDE-FERTIGUNGMT PDE-FERTIGUNGMT PDE-TL-FERTIGUNG PDE-FERTIGUNGMT PDE-AL-VERTRIEB PDE-TL-MARKETING PDE-VERKAEUFER PDE-TL-SUPPORT PDE-SUPPORTER PDE-PR-VERTRIEB PDE-TL-QUALITAETS PDE-QMARBEITER

Rolle

PDE-QUSICH

PDE-AV-ALEITER PDE-AM-TLEITER PDE-AM-PROG-01 Arbeitsmittel PDE-AM-KONS-01 Arbeitsvorbereitun PDE-AM-KONS-… PDE-AP-TLEITER PDE-AV-PRUEFER Arbeitsplan PDE-AP-PLAN-01 PDE-AP-PLAN-… Abteilungsleiter PDE-KT-ALEITER PDE-NM-TLEITER PDE-KT-PRUEFER Normen PDE-NM-BEAR-01 PDE-NM-BEAR-… Konstruktion PDE-K1-TLEITER Team I PDE-KT-KONS-01 PDE-KT-KONS-… PDE-K2-TLEITER Team II PDE-KT-KONS-02 PDE-KT-KONS-… Abteilungsleiter PDE-PG-ALEITER PDE-F1-TLEITER Fertigung I PDE-PG-FERT-01 Produktion PDE-PG-FERT-… PDE-F2-TLEITER Fertigung II PDE-PG-FERT-02 Abteilungsleiter PDE-VB-ALEITER PDE-MT-TLEITER Marketing PDE-MT-VERK-01 Vertrieb PDE-TU-TLEITER Technische PDE-TU-SUPP-01 Unterstützung PDE-VB-PRUEFER PDE-QM-TLEITER Qualitätssicherung (Stababteilung) PDE-QM-ZUST-01

Position

PDE-VRTIEB

Abteilungsleiter

Team

PDE-VRTPRF

Geschäftsführer

Abteilung

Gruppen

5.7 Prozesse gestalten und steuern 139

140

5 Leithefte zu PLM-Aspekten

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

• Adamietz, Peter: Adaption von Standardsoftwaresystemen; Aachen: Shaker Verlag, 2001 • Pfitzinger, E.: Geschäftsprozess-Management, Steuerung und Optimierung von Geschäftsprozessen; Herausgeber: DIN; Berlin: Beuth Verlag, 2003 • Scheer, A.-W.: ARIS - vom Geschäftsprozess zum Anwendungssystem/ August-Wilhelm Scheer. - 4., durchges. Aufl.. - Berlin ; Heidelberg ; New York ; Barcelona ; Hongkong ; London : Springer, 2002 Normen und Standards

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

5.8 Transparente Änderungen gewährleisten

5.8

141

Transparente Änderungen gewährleisten

Change Management(engl.) Æ Dokumentenmgnt., Qualitätsmanagement Das Änderungsmanagement beinhaltet die Organisation, Durchführung und Dokumentation eines Änderungsvorgangs, der Summe aller Änderungsmaßnahmen im Rahmen des Änderungsvorlaufes und der Änderungsdurchführung (DIN 199-4). Product Lifecycle Management ist ein Instrument zur IT-seitigen integrierten Unterstützung des Änderungsprozesses. Es hilft die Komplexität des Änderungsprozesses zu beherrschen, Durchlaufzeiten des Änderungsprozesses zu optimieren, Änderungen zu dokumentieren und zu archivieren. Der formalisierte Änderungsprozess von PLM trägt zudem zum Qualitätsmanagement bei und kann somit zur ISO 9000 Zertifizierung verwendet werden. Das PLM übernimmt die Steuerung des Prozesses und erzwingt dadurch die Einhaltung desselben. Diese Steuerung verbunden mit der Grundfunktionalität eines Integ rationssystems, dem Dokumentenmanagement und der digitalen Unterschrift ersetzt den trägen, papiergestützten Änderungsablauf und trägt damit unmittelbar zu kürzeren Prozesszeiten, Transparenz und Durchgängigkeit bei. Der zweite große Nutzen des Einsatzes von PLM für den Änderungsprozesses liegt in der Verwaltung der Dokumente im Projektkontext. Das System steuert die Gültigkeit eines Artikels, ermöglicht die Sperrung bestimmter Artikel bei gravierenden Änderungsgründen oder übernimmt die Kennzeichnung, dass sich ein Artikel in Änderung befindet. Trotzdem bleibt jedem Anwender die Möglichkeit, alle betroffenen Daten jederzeit zu betrachten und sich so über den Änderungsfortschritt zu informieren. Das gleiche gilt zu Recherchezwecken für Artikel, die auf Grund durchgeführter Änderungen gesperrt sind. Auch diese können noch eingesehen, jedoch nicht weiter bearbeitet werden. Die Dokumentation der Änderung verbunden mit der Stammdatenarchivierung, ermöglicht eine dauerhafte Rückverfolgung aller Änderungen.

142 5.8.1

5 Leithefte zu PLM-Aspekten Änderungsmanagement

Die Abb. 5-36 zeigt, dass für die Einführung des Änderungsmanagements durch ein Integrationssystem das Statusmanagement und ein Workflowmanagement zur prozessseitigen Unterstützung, ein Dokumenten- und Datenmanagement zur Dokumentation und Historienverwaltung und ein Versionen-, Varianten- und Alternativenmanagement zur produktstrukturseitigen Unterstützung erforderlich ist.

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-36: Änderungsmanagement im PLM

5.8 Transparente Änderungen gewährleisten 5.8.2

143

Potential im Änderungsmanagement

Ein Änderungsprozess ist ein Kernprozess jedes Unternehmens. Er ist meist in unternehmensspezifischen Verfahrensanweisungen oder Normen verbindlich festgelegt (Conrat 1998). Defizite beim Änderungsprozess liegen in langen Durchlaufzeiten, bestehende Änderungsprozesse bieten häufig wenig Raum für kreative Ideen. Nicht selten benötigt ein Änderungsprozess 15-20 Unterschriften (Clark u. Fujimoto 1992. Zudem sind angewandte Prozesse wenig transparent und nicht durchgängig. Das Ziel sollte es sein, einen ganzheitlichen Ansatz von technischen und organisatorischen Ansätzen zu verfolgen. Dazu benötigt es die entsprechende IT-Unterstützung eines integrierenden Systems. Standardsysteme im PLM liefern meist diese Funktionalität. Es verwaltet das integrierte Produktmodell mit allen Dokumenten, das um entsprechende Elemente erweitert werden muss. Zudem unterstützt es Workflowmanagement in der Produktentwicklung. 5.8.3

Änderungsmanagement im Mittelstand

Änderungen bedeuten für ein Produkt Innovation und Fortschritt. Der Änderungsprozess betrifft alle organisatorischen Einheiten eines Unternehmens (Konstruktion, Verkauf, Einkauf, und Fertigung/AV). Um die Komplexität dieses Prozesses greifbar zu machen sollte er in mehrere Hierarchieebenen eingeteilt werden. Innerhalb des Prozesses zwischen den Ebenen und von dem Prozess nach außen sind alle Schnittstellen eindeutig zu definieren. So hat jeder Prozess einen definierten Anfang und ein definiertes Ende. Die zunächst festgelegt werden müssen. Beispielsweise beginnt nach DIN 199-4 der Prozess mit dem Stellen des Änderungsantrages. Lindemann und Reichwald gehen weiter und bieten so ein anderes Extrembeispiel. Sie beginnen den Prozess mit der Idee der Änderung. Gleiches gilt für das Ende des Prozesses. Nach Lindemann und Reichwald ist der Änderungsprozess erst mit einer lernorientierten Auswertung abgeschlossen. In der DIN 199-4 endet der Prozess mit der Verteilung der Änderungsunterlagen (s. Abb. 5-37). Schnittstellen, die der Prozess nach außen bietet, sind zum einen Eingänge, also die Prozessauslöser. Dies könnte die Konstruktion bei innovativen Änderungen, der Einkauf auf Grund einer geänderten Marktsituation von Zukaufteilen, der Vertrieb wegen Kundenanforderungen oder die Fertigung bzw. AV als Reaktion auf Fertigungsschwierigkeiten sein. Zum anderen gibt es Ausgänge zum Prozessende. Dabei sind zwei Möglichkeiten zu unterscheiden je nachdem, ob die Änderung durchgeführt oder abgebrochen wurde.

144

5 Leithefte zu PLM-Aspekten Änderungsantrag schreiben

Änderungsvorlauf

Änderungsantrag

Änderungsbeschreibung

Antrag prüfen

Ablehnung Änderung Nein durchführen?

abgelehnter Änderungsantrag

Ablehnung begründen

Ja

Zeichnungs- und Stücklistenwesen

Änderungsdurchführung

Änderungsvorgang

Änderungsauftrag schreiben

Änderungsauftrag

Änderungsbeschreibung

Zeichnungen, Stücklisten ändern Stückliste

Änderungsbeschreibung

Zeichnung

Legende: ggf. erforderliche erforderliche

Änderungsdienst: verteilen von geänderten Zeichnungen, Stücklisten usw.

Änderungsunterlagen

Änderungsmaßnahmen

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

5.8 Transparente Änderungen gewährleisten

145

In beiden Fällen muss das Ergebnis im Unternehmen kommuniziert werden. Der Änderungsprozess selbst muss individuell entsprechend der Arbeitsweise erstellt werden. Die wichtigsten Phasen, die jeder Änderungsprozess enthalten sollte sind folgende: • Änderungsauslöser Auf Grund einer begründeten Idee wird ein Änderungsantrag gestellt. • Antragsentscheidungsphase Über den Antrag muss entschieden werden. • Änderungsdurchführung • Freigabe eventuelle Wiederholung der Durchführungsphase • Kommunikation • Abbruchvorgang Auch ein Abbruch oder ein Ablehnen einer Änderung muss einen formalen Prozess durchlaufen. Beispielsweise ist zu klären, ob der Antrag ganz oder teilweise abgelehnt wird, ob eine Alternative zwingend erforderlich ist etc. Ebenso ist zu definieren, wie mit dem Thema der pauschalen Freigabe umgegangen werden soll. Eine pauschale Freigabe ist eine dokumentierte Schnellfreigabe, bei der der Änderungsprozess nicht eingehalten wird. Diese Art der Freigabe darf nur von bestimmten Personen ausgeführt werden. Eine entsprechende Vergabe der Rechte ist zwingend erforderlich. 5.8.4

Der Änderungsprozess im PLM

Der Änderungsprozess ist ein Workflow besonderer Bedeutung. Somit gelten für den Änderungsprozess alle Regeln und Hinweise aus dem Leitheft „Prozesse steuern und gestalten“ (Abschnitt 5.7). Der Änderungsprozess muss entsprechend jedes Workflows formal im Prozessmodell des PLM-Manifests unabhängig vom Grad der Unterstützung des eingesetzten Tools beschrieben werden. Die formale Änderungsprozessbeschreibung besteht aus zwei Arten von Diagrammen. Zum einen wird der Prozess, also die Tätigkeit und zum anderen die Zustände, die ein Artikel oder ein Dokument während des Prozesses annehmen kann (Status), modelliert. Der Status sagt aus, in welcher Product-Lifecycle-Phase sich der Artikel befindet. Nähere Informationen zu diesem Thema stellt das Leitheft „Dokumente sicher verfügbar machen“ (s. Abschnitt 5.3) bereit. Je nach Ausmaß der Änderung muss festgelegt werden, welchen Status der Artikel während des Änderungsprozesses erhält. Beispielsweise „gesperrt“ oder „wird geändert“. So wird jedem Anwender kenntlich

146

5 Leithefte zu PLM-Aspekten

gemacht, dass ein Artikel in absehbarer Zeit verändert wird. Gängige Status sind: • • • •

in Arbeit freigegeben in Änderung gesperrt

Diese Status sind in der Regel die Mindestanforderung. Mit jedem Statuswechsel wechselt in der Regel auch die Verantwortliche Stelle bzw. Person von dem Teil. Entsprechend ist das integrierte Produktmodell um Änderungsdokumente und Versionen zu erweitern. Ein definierter Änderungsprozess ist Voraussetzung für ein Qualitätsmanagement. Informationstechnische Grundlagen zum Änderungsmanagement

Aus informationstechnischer Sicht gibt es analog zu jedem Workflow im Idealfall eine Klasse, die den Musterprozess repräsentiert. Soll ein Teil geändert werden, wird durch die Instanziierung dieser Klasse ein Änderungsprozess angestoßen (s. Kapitel 3). Zur Initialisierung erhält das Objekt eine eindeutige Nummer zur Identifikation der Änderung. Durch den Aufruf der Änderungsklasse von einem Teilobjekt wird der Bezug zum Teil gesichert. Dieses Änderungsobjekt enthält entsprechend Objekte zur Dokumentation. Einfachere Standardsysteme im PLM ermöglichen dagegen nur eine Statusvergabe, die einem Zustandsdiagramm gleich kommt. Änderungsdokumentation

Alle Änderungen sind nachzuhalten. So sind alle Versionsstände auch nach einer Änderung verfügbar, gearbeitet wird jeweils mit dem neuesten Stand (s. Leitheft „Evolution der Produkte organisieren“ Abschnitt 5.1). Dies ist wichtig, um Konfigurationsstände älterer Produkte jederzeit abrufen zu können und um den Konstrukteuren für Recherchezwecke die Möglichkeit zu geben, die Entwicklungshistorie eines Produktes nachzusehen. Mit jedem formal durchlaufenden Änderungsprozess wird eine neue Version eines bestehenden Artikels oder ein neuer Artikel erzeugt. Jede Änderung hat Stammdaten, die den Versionsständen zuzuordnen sind. Hierzu zählen beispielsweise: Betreffende Artikel, Name des Initiators, Datum der Initiation, Datum der Fertigstellung der Änderung, Datum des Geltungsbeginns der Änderung, Gesperrte Artikel ab Änderungsbeginn, Bearbeiter etc. Neben den Dokumentenständen und den Stammdaten der

5.8 Transparente Änderungen gewährleisten

147

Änderung sollte die Änderungsdokumentation archiviert werden. Zur Änderungsdokumentation gehören: • Änderungsantrag • Änderungsbegründung (zum Beispiel Zeichnungen mit Bemerkungen) • Wirtschaftlichkeitsanalysen Bezug zum PLM-Modell: • Einordnung zum „integrierten Produktmodell“ • Prozessmodell • Organigramm Änderungsstände (Versionen) gehören zu den Elementen, die mit im integrierten Produktmodell berücksichtigt werden müssen. Wie Versionen dort eingeordnet werden, ist im Kapitel 3 ausführlich beschrieben. 5.8.5

Einführung eines Änderungsmanagements

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

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

148

5 Leithefte zu PLM-Aspekten

Ist-Analyse

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

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

Änderungserkennung

Auswirkungserfassung und Änderungsplanung

Gesamtheitliche wirtschaftliche Bewertung und Entscheidung Problem- und Ursachenanalyse Effiziente Abwicklung von Änderungen

Strategien zum Entwickeln von Lösungsalternativen

Lernorientierte Auswertung von Änderungen

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

5.8 Transparente Änderungen gewährleisten

149

Neben den Anforderungen an den Prozess ergeben sich Anforderungen an die Dokumentenstatus, die in einem Zustandsdiagramm beschrieben werden können. Zur eindeutigen Identifizierung einer Änderung sollte zudem jede Änderung eine Nummer haben. Dazu sind die Anforderungen an ein Nummernsystem entsprechend zu identifizieren (s. Leitheft „Nummernvergabe automatisieren“ Abschnitt 5.5). Modellbasierter Sollprozess und Konzept

Aus den Anforderungen angewandt auf den Ist-Prozess wird formal ein Soll-Prozess beschrieben. Eventuell ist das Funktionsspektrum des eingesetzten Systems mit zu berücksichtigen. Das Änderungsmanagement muss mit Versions- und Variantenmanagement koordiniert sein. Implementierung

Die Implementierung ist abhängig von der Customizing-Funktionalität des Tools. Hochwertigere Systeme bieten eine grafische Prozessmodellierung und eine modellbasierte Statusvergabe. Bei einfachen Systemen werden Scripte zum Customizing verwendet. Die Prozesspflege ist dementsprechend aufwendiger und kann nur von geschulten Mitarbeitern durchgeführt werden. Von Systemen, die Prozesse fest im Systemcode integrieren, ist dringend abzuraten, da hierdurch eine Prozesspflege sehr aufwendig und somit kostspielig wird. Checkliste

• • • • • • • • •

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

150

5 Leithefte zu PLM-Aspekten

Normen und Standards

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

5.9 Produktzentrierte Projektabwicklung

5.9

151

Produktzentrierte Projektabwicklung

Æ Prozess- und Organisationsmanagement Æ Applikationsintegration

Product Lifecycle Management organisiert die Informationen und Prozesse über den gesamten Lebenszyklus eines Produktes. Die Aufgabe der Entwicklung eines neuen Produktes beziehungsweise der Verbesserung oder Anpassung eines bestehenden Produktes wird dabei in Projekten durchgeführt, die durch das Projektmanagement geplant, überwacht und gesteuert werden. Dabei ist das Projektmanagement eng mit den Prozessen und Abläufen der Produktentwicklung und -herstellung verbunden. Die Zielsetzung ist dabei stets die Entwicklungsaufgabe kosten- und termingerecht mit der geforderten Qualität abzuschließen. Aus diesem Grund ist es nahe liegend das Projektmanagement als organisatorische Komponente in das Product Lifecycle Management zu integrieren. Die Methoden des Projektmanagements bieten dabei Hilfestellung bei der Planung von Entwicklungsaufgaben durch die Verknüpfung mit Terminen und Ressourcen. Mit steigender Komplexität von Produkten und zunehmender Verteilung von Entwicklungsprozessen mit entsprechender Aufgabenteilung besteht eine Schwierigkeit darin, Abhängigkeiten von Aufgaben und Arbeitspaketen sowie den damit verbundenen Terminen und Zuständigkeiten zu überblicken. Dies erschwert zum einen die Kontrolle des Projektfortschritts und zum anderen die Ermittlung der mit der Entwicklung verbundenen Kosten für ein Produkt. Zur Unterstützung des Projektmanagements werden in der Produktentwicklung ebenso wie in den übrigen Bereichen, die mit der Projektabwicklung betraut sind, deshalb spezialisierte Softwarewerkzeuge zur Projektplanung und -kontrolle eingesetzt. Viele der für das Projektmanagement benötigten Informationen sind bereits in den Integrationssystemen vorhanden oder können mit den dort verwalteten Daten ermittelt werden. Im Zuge einer optimierten informationstechnischen Unterstützung des Product Lifecycle Management werden deshalb vorhandenen Funktionalitäten der Integrationssysteme für das Projektmanagement genutzt, Projektmanagementsoftware mit diesen Systemen gekoppelt und in zunehmendem Maße Projektmanagementfunktionalität in die Integrationssysteme integriert.

152 5.9.1

5 Leithefte zu PLM-Aspekten Projektmanagement

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

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-39: Projektmanagement im PLM

5.9 Produktzentrierte Projektabwicklung 5.9.2

153

Planung und Steuerung des Engineering

Im Kontext des Product Lifecycle Managements sind bei Entwicklungsaufgaben neben der Qualität des Produktes Kosten- und Termintreue in zunehmendem Maße zu wichtigen Faktoren geworden. Bei der Entwicklung neuer Produkte oder der Verbesserung existierender Produkte wird ein Entwicklungsvorhaben dabei im Allgemeinen als Projekt bezeichnet. Die DIN 69901 definiert ein Projekt als „Vorhaben, das im Wesentlichen durch Einmaligkeit der Bedingungen in ihrer Gesamtheit gekennzeichnet ist, wie z. B. durch Zielvorgaben, zeitlichen, finanziellen, personellen oder anderen Begrenzungen, die Abgrenzung gegenüber anderen Vorhaben und einer projektspezifischen Organisation“. Die organisatorischen und administrativen Tätigkeiten, die zur Realisierung eines Projektes notwendig sind, werden im Projektmanagement durchgeführt. Das Projektmanagement verknüpft Kosten, Termine, Kapazitäten und Aufgaben miteinander und unterstützt die Planung, Steuerung und Überwachung von Projekten. Mit steigendem Umfang und einer zunehmenden Anzahl an Aufgaben, Projektmitarbeitern und Terminen innerhalb eines Projektes gestaltet sich die Organisation und Administration zunehmend schwieriger. Zusätzliche Anforderungen an das Projektmanagement ergeben sich aus der Tendenz zur verteilten Produktentwicklung mit einer Vielzahl an Partnerunternehmen und Standorten. Um diese komplexen Anforderungen an das Projektmanagement im Entwicklungsprozess besser beherrschen zu können, werden Softwarewerkzeuge zur Unterstützung herangezogen. Diese Softwarewerkzeuge wurden zunächst als eigenständige Lösungen entwickelt. Die Verknüpfung von Ressourcen und Kapazitäten mit Produktstrukturen und -informationen im Product Lifecycle Management legt es allerdings nahe, Projektmanagement als integrierten Bestandteil zu betrachten. Integrationssysteme wie beispielsweise PDM-Systeme bieten bereits teilweise Projektmanagementfunktionalität an. 5.9.3

Hilfsmittel für das Projektmanagement

Zur Unterstützung des Projektmanagements werden vor allem GantDiagramme und die Netzplantechnik als Hilfsmittel eingesetzt. GantDiagrammen verbinden den zeitlichen Ablauf von Projekten mit den Aufgaben und Aktivitäten und stellen diesen einfach und übersichtlich dar (s. Abb. 5-40). Dabei werden die einzelnen Teilaufgaben über einem Zeitstrahl dargestellt.

5 Leithefte zu PLM-Aspekten

AP1 AP2

Phase 2

Phase 1

154

AP3

Phase 3

AP4 AP5 AP6 I

II

III

IV

V

VI

VII

VIII

1.1.2004 1.5.2004 31.8.2004 Arbeitspakete (AP) AP 1: Aufnahme der Kundenanforderungen AP 4: Montage der Analagenkomponenten AP 2: Erarbeitung des Anlagenkonzepts AP 5: Anpassung der Steuerungssoftware AP 3: Ausführen der Anpassungskonstruktionen AP 6: Koordination und Projektmanagement

Abb. 5-40: Gant-Diagramm mit Arbeitspaketen

Gant-Diagramme haben allerdings den Nachteil, dass die Abhängigkeiten der einzelnen Aufgaben kaum zu erkennen sind und so Auswirkungen von Terminverschiebungen kaum festzustellen sind (Altrogge 1996). Mit Hilfe der Netzplantechnik (DIN 69900) sind Abhängigkeiten zwischen den Aufgaben einfach abzubilden und somit die Auswirkungen von Terminverschiebungen leicht zu erkennen. Die Netzplantechnik basiert auf Verfahren der Graphentheorie und wurde zur Strukturierung, Planung, Steuerung und Kontrolle speziell von umfangreichen Projekten entwickelt. Der Vorteil der Netzplantechnik gegenüber Gant-Diagrammen liegt in der Trennung von Projektstrukturierung und Zeitplanung, was besonders bei der Überwachung von Projekten zum tragen kommt (Altrogge 1996). Durch die gute Möglichkeit der Rechnerunterstützung ist eine laufende Überprüfung von Ist-Zeiten und eine kontinuierliche Verbesserung der Planzeiten durchführbar. Durch die Zuordnung von Mitarbeitern oder Werkzeugen (z. B. Berechnungssoftware) zu Aktivitäten, in der Netzplantechnik Vorgang genannt, können Kapazitäten und Kosten ermittelt werden. In Abb. 5-41 ist ein Beispiel eines Netzplanes dargestellt. Softwarewerkzeuge für das Projektmanagement unterstützen in der Regel die automatische Ableitung von Gant-Diagrammen bzw. Netzplänen aus Aktivitäts- und Termindaten und Verfügen über grafische Editoren zur Erstellung und Änderung der Diagramme bzw. Pläne.

5.9 Produktzentrierte Projektabwicklung

155

Legende AP1

TP 7523

5

AP2

10

TP 7523

System-Konzeption

Ist-Analyse

Vorg.-Nr. Projektnr MIND Vorgangsbezeichnung

12.10.04

4

17.10.04

17.10.04

4

27.10.04

FAZ

GP

FEZ

14.10.04

6

19.10.04

19.10.04

11

29.10.04

SAZ

HD

SEZ

AP3

13

TP 7523

Dokumentation 14.10.04

2

27.10.04

14.10.04

15

29.10.04

MIND = minimale Dauer FAZ = frühester Anfangszeitpunkt SAZ = spätester Anfangszeitpunkt GP = gesamte Pufferzeit HD = häufigste Dauer FEZ = frühster Endzeitpunkt SEZ = spätester Endzeitpunkt

Abb. 5-41: Darstellungsbeispiel eines Netzplanes 5.9.4

Projektmanagement im Engineering

Die Verwaltung und Planung von Arbeitsabläufen und Ressourcen ist in der Produktion wesentlich ausgeprägter und detaillierter als im Bereich der Produktentwicklung. Dies liegt vor allem daran, dass sich Fertigungs- oder Montagetätigkeiten klar voneinander abgrenzen lassen, also deterministische Tätigkeiten sind, und dass sich die Bedingungen unter denen die Tätigkeit ausgeführt werden, in der Regel gut vorausbestimmen lassen. Tätigkeiten in der Entwicklung sind dagegen eher nicht-deterministisch und weisen eine hohe Dynamik im Bezug auf die einzelnen Entwicklungsaufgaben auf, da sich ihre Fortschritte häufig und schnell ändern können. Entwicklungstätigkeiten sind Aufgrund des hohen Anteils an Informationsverarbeitung und Kreativität zudem nur sehr schwer planbar, da sich Kreativität nur fördern, aber nicht erzeugen lässt (Kurz 1998). Die Forderung nach kurzen Durchlaufzeiten bedeutet für den Entwicklungsbereich allerdings die Notwendigkeit einer verstärkte Planung und Kontrolle der Entwicklungszeiten, da sich Verzögerungen entsprechend auf die Produktionsplanung auswirken. Zur Erleichterung der Planung und zur Qualitätssicherung wird der Entwicklungsprozess deshalb in Abschnitte unterteilt, an deren Übergang zuvor definierte Ergebnisse erreicht sein müssen. Diese Punkte werden als Meilensteine oder Quality Gates bezeichnet, und sind unter Umständen auch mit Abbruchkriterien für die Weiterführung des Projekts verbunden.

156 5.9.5

5 Leithefte zu PLM-Aspekten Projektmanagement im PLM

Der wesentliche Punkt der Anwendung von Projektmanagement im Product Lifecycle Management ist die Verknüpfung von Projekten mit den Produkten. Das Ziel Kosten zu senken und Entwicklungsaufgaben mit hoher Qualität schneller abzuschließen, wird durch eine hohe Wiederverwendungsrate von Bauteile und Baugruppen und Zusammenführung und Abstimmung von Entwicklungsaufgaben für Komponenten in verschiedenen Projekten unterstützt werden, was eine Vernetzung von Projekten bzw. Projektaufgaben erfordert. Zur Reduzierung der Komplexität eines Projektes kann dieses in einzelne Teilprojekte unterteilt werden, so dass eine hierarchische Projektstruktur entsteht, deren Teilprojekte allerdings in verschiedene Projekte eingehen können. Den zentralen Einstiegspunkt für das Projektmanagement im PLM stellt die Projektmappe dar. In einer Projektmappe werden sämtliche Dokumente und Informationen zu Produktstruktur, Artikeln, Aufgaben, Prozessen, Aktivitäten, Kalender und Mitarbeiter gesammelt. Durch die Projektmappe kann eine Verknüpfung zwischen der Projektstruktur, dem integrierten Produktmodell und den Unternehmensprozessen hergestellt werden. Beispielsweise kann ein Endprodukt mit einem Gesamtprojekt verknüpft wird. Komponenten oder Baugruppen können entsprechenden Teilprojekten zugeordnet und in diesen entwickelt werden (s. Abb. 5-42). Projekt EP 0423011 Minivan

Produkt P190

K193-18 Projekt TP 0423011-1 Karosserie

K193-12 Projekt TP 0423011-2 Antrieb

K196-1 T1

T3

T4

Projekt TP 0423011-4 Motor Projekt TP 0423011-3 Antriebsstrang

K193-23

Abb. 5-42: Mögliche Beziehung zwischen Produkt- und Projektstruktur

5.9 Produktzentrierte Projektabwicklung

157

Prozess:

Projekt Minivan

Bauteilentwurf durchführen

Teilprojekt Antriebsstrang

Aufgabe 1 Motorenentwurf

Aktivitäten

Motor entwerfen Motor zur Prüfung schicken Motorenentwurf prüfen

Abb. 5-43: Zusammenhang zwischen Projekt und Prozess

Die Entwicklung der jeweiligen Komponenten ist als Aufgabe der Teilprojekte zu verstehen, so dass die Gesamtaufgabe des Projektes erfüllt wird. Die Teilprojekte beinhalten wiederum die Arbeitspakete, die in dem jeweiligen Teilprojekt zu bearbeiten sind. Ein Arbeitspaket beschreibt dabei die einzelnen Arbeitsschritte (Aktivitäten), die ausgeführt werden müssen, um die Aufgabe des Teilprojekts erfolgreich zu bearbeiten (s. Abb. 5-43). Der Beginn der Durchführung des Projektes startet bestimmte Geschäftprozesse im Unternehmen, die durch den Ablauf einzelner Prozessschritte beschrieben werden und in denen auch die Zuständigkeiten der Mitarbeiter und zu benutzenden Werkzeuge (Applikationen, wie z. B. CAD) definiert sind. Aktivitäten im Projektmanagement entsprechen in der Regel Prozessschritten in Unternehmensabläufen, so dass beim Projektmanagement im Integrationssystem auf die für das Workflowmanagement definierten Abläufe zurückgegriffen werden kann (Schöttner 1999). Die Integration von Projektmanagementfunktionen mit der Workflow-, Produktstruktur- und Dokumentenmanagement-Funktionalität beispielsweise von PDM-Systemen wird eine transparente Planung, Steuerung und Kontrolle von Entwicklungsaufgaben ermöglicht (s. Abb. 5-44). In Integrationssystemen existieren zur Verwaltung eines Projektes Projektmappen als Datenobjekt, in welchem die notwendigen Systemobjekte, wie Produktstruktur, Artikel, Aufgaben, Prozesse, Aktivitäten, Kalender und Mitarbeiter gesammelt werden.

158

5 Leithefte zu PLM-Aspekten

Projekt

Projektteam Kalender

Produktstruktur Aufgabe 1

Aufgabe 2

Aufgabe 3

Aufgabe 4

Team A

Ergebnis von Aufgabe 2

User 1

Aktivität 1

Aktivität 2

Kalender Applikation3 Prozess CAD-Modell

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

Auf Basis dieses integrierten Ansatzes von Projekt-, Prozess- und Datenmanagement im PLM mit einer Projektmappe ergeben sich besonders für Steuerung und Kontrolle eines Projektes unter anderem folgende Möglichkeiten: • Teilweise Automatisierung von Abläufen, z. B. das Versenden von Dokumenten zum nächsten Bearbeiter. • Vorgabe von Applikationen, die für eine Aktivität verwendet werden sollen. Beispielsweise verlangen Automobilhersteller von ihren Lieferanten, dass die Geometriedaten im CAD-System eines bestimmten Herstellers modelliert werden. • Benachrichtigung von Projekt- oder Teamleiter bei Überschreitung des Termins einer Aktivität oder Aufgabe. • Benachrichtigung von Projekt- oder Teamleiter bei Fertigstellung einer Aktivität oder Aufgabe. • Übersichten über den aktuellen Status und Fortschritt von Aufgaben oder Aktivitäten. • Dokumentenmanagementfunktion gestattet die Verwaltung von Projektdokumenten, wie Besprechungsprotokollen oder Meilensteinberichten, so dass diese Dokumente den Projektbearbeitern in der gleichen Form zur Verfügung stehen, wie die restlichen produktrelevanten Dokumente.

5.9 Produktzentrierte Projektabwicklung 5.9.6

159

Umsetzung von Projetktmanagement-Konzepten

Die informationstechnische Unterstützung des Projektmanagement stellt nach wie vor noch eine große Herausforderung dar, die noch nicht vollständig gelöst ist. Üblicherweise ist das Projektmanagement eher im betriebswirtschaftlichen Umfeld zu sehen in dem Planung und Kontrolle von Auftragabwicklung, Kosten und Ressourcen im Vordergrund stehen. Damit wurde Projektmanagement, neben eigenständiger Projektmanagementsoftware, zunächst durch ERP-Systeme unterstütz. Die Notwendigkeit zur Verkürzung von Produktentwicklungszeiten und Kostenreduzierung macht eine informtionstechnische Unterstützung der des Projektmanagements durch Integrationssysteme jedoch zwingend erforderlich, so dass die Informationssysteme im Entwicklungsbereich zunehmend mit Projektmanagementfunktionalitäten erweitert werden. Effizientes Projektmanagement ist jedoch nur möglich, wenn sowohl Entwicklung wie auch Produktion im Projektmanagement berücksichtigt werde. Somit bestehen prinzipiell drei Möglichkeiten mit verschiedenen Vor- und Nachteilen Projektmanagement durch Informationssysteme zu unterstützen: • Das Projektmanagement mit ERP-Systemen bietet den Vorteil die umfangreichen Funktionen für die Verwaltung, Planung und Steuerung von Terminen, Personal- und Maschinenkapazitäten sowie Kosten dieser Systeme Nutzen zu können. Für die Erfassung von Projektinformationen aus dem Entwicklungsbereich müssen diese Systeme entsprechend erweitert werden und mit Schnittstellen versehen werden oder manuell mit Daten beschickt werden. • In Integrationssysteme integrierte Projektmanagement-Komponenten bieten vor allem den Vorteil einer einheitlichen Datenhaltung im Entwicklungsbereich. Allerdings verfügen diese Systeme nur über geringe Funktionalität zur Kostenermittlung oder Kapaziätsplanung. Entsprechend zum ERP können Projektinformationen aus der Produktion nur durch geeignete Schnittstellen oder manuelle Erfassung berücksichtigt werden. • Weiterhin sind für das Projektmanagement eigenständige Softwarewerkzeuge auf dem Markt verfügbar, die meist auch einen größeren Funktionsumfang besitzen oder einfacher zu bedienen sind, als Projektmanagement-Komponenten von ERP- oder PDM-Systemen. Nachteilig ist jedoch zu sehen, dass Projektinformationen sowohl aus ERP- wie auch aus Integrationssystemen gewonnen werden müssen. Besondere Berücksichtigung müssen die Aktualität der Projektinformationen und die Dynamik der Prozesse im Projektmanagement bei der Auswahl oder Implementierung von unterstützenden Informationssystemen

160

5 Leithefte zu PLM-Aspekten

erfahren. Zum einen erfordern die häufigen Änderungen von Projektfortschritten, das Auftreten von Hindernissen und damit verbundenen Änderungen von Aufgaben oder Zeitplänen eine einfache und möglichst automatische Aktualisierung von Daten. Zum anderen müssen die Informationssysteme mit wachsenden Projekt- und Produktstrukturen umgehen können, da in der Regel zu Beginn eines Projektes diese Strukturen nicht vollständig bekannt sind, sondern im Laufe der Zeit immer mehr detailliert werden. Weiterführende Literatur

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

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

5.10 Auf Standardsystemen aufbauen

161

5.10 Auf Standardsystemen aufbauen Æ Applikationsintegration

Bei der Umsetzung einer Softwarelösung, die die speziellen Bedürfnisse eines Unternehmens erfüllen muss, stellt sich häufig die Frage, ob eine Standardsoftware verwendet werden kann oder eine Individualsoftware implementiert werden soll. Heutige Standardsoftwaresysteme geben nicht nur vom Funktionsumfang eine Basis für fast alle Anforderungen, die an sie gestellt werden, sondern sie Unterstützen zugleich auch in hohem Maße ihre individuelle Anpassbarkeit (s. Abb. 5-45). Diese Konfigurierbarkeit ermöglicht es Standardsoftwaresysteme einzusetzen, die den individuellen Bedürfnissen eines Unternehmens angepasst werden, so dass der Einsatz von Individualsoftware nur selten einen Mehrwert bringt und daher tunlichst vermieden werden sollte. Der Vorteil bei der Anpassung der Standardsoftware, das so genannte Customizing (engl.: an Wünsche anpassen), liegt darin, dass auf einer breiten Basis von Funktionalitäten aufgesetzt werden kann, während diese Funktionalitäten bei Individualsoftware ebenfalls implementiert werden müssen. So rechnet sich die Implementierung einer Individuallösung nur für sehr spezielle Problemstellungen, da der qualitativ besseren Abbildung der unternehmensspezifischen Anforderungen bei Individualsoftware ein höherer Investitionspreis und höhere Wartungskosten entgegenstehen. Der zeitliche und finanzielle Aufwand für die individuelle Anpassung von Standardsoftwaresystemen ist dennoch relativ hoch und zudem schwer abzuschätzen (Abramovici 1999). Zu berücksichtigen ist ebenfalls der erhöhte Aufwand für die Wartung eines angepassten Standardsoftwaresystems, da z. B. beim Wechsel der Softwareversion (Releasewechsel) die Anpassungsarbeiten eventuell wiederholt werden müssen. Aus diesem Grund kann ein höherer Systempreis für ein wenig anzupassendes System langfristig kostengünstiger sein als ein System mit niederem Basispreis und umfangreichen Anpassungen.

162

5 Leithefte zu PLM-Aspekten

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-45: Applikationsintegration und Datentausch im PLM-Umfeld 5.10.1 Klassifizierung der Systemtypen

Auf dem Markt für PLM-Systemlösungen sind viele Anbieter mit vielen unterschiedlichen Standardsoftwaresystemen vertreten. Diese Systeme unterscheiden sich dabei erheblich in der verwendeten Technologie, im funktionalen Umfang, in ihren Konfigurationsmöglichkeiten und im Preis. Im Wesentlichen können diese Systeme jedoch entsprechend der VDI-

5.10 Auf Standardsystemen aufbauen

163

Richtlinie 2219 den folgenden drei Systemklassen zugeordnet werden (VDI 2219): • Erzeugersystemorientierte Systeme Die erzeugersystemorientierten Systeme sind entweder Teil eines Erzeugersystems (CAD-Systems) oder werden als Zusatzmodule zu diesen angeboten und mit diesen integriert. Sie erweitern das Erzeugersystem um Funktionen zur Verwaltung der erzeugten Informationen. Der Vorteil dieser Systeme liegt in der engen Systemintegration auf Basis einer gemeinsamen Datenstruktur und einheitlichen Funktionsaufrufen. • Funktionsorientierte erzeugersystemübergreifende Systeme Erzeugersystemübergreifende Systeme sind Systeme deren Funktionsumfang Lösungen für das Management bestimmter einzelner PLMAspekte abdeckt, beispielsweise für Dokumentenmanagement, Workflowmanagement oder Archivierung. Sie sind nicht an spezielle Erzeugersysteme gebunden, so dass beim Wechsel des Erzeugersystems keine Notwendigkeit besteht ebenfalls das Managementsystem zu wechseln. • Integrierte und übergreifende Systeme Integrierte und übergreifende Systeme unterstützen mit ihrem Funktionsumfang mehrere PLM-Aspekte über den gesamten Product Lifecycle. Sie sind erzeugersystemunabhängig und vereinen beispielsweise Dokumenten-, Produktstruktur-, Konfigurations- und Workflowmanagement. Dies ist die wichtigste Systemklasse deren Anbieter die Systeme als PDM- bzw. PLM-Systeme vermarkten. 5.10.2 Architektur von Standardsoftwaresystemen

Die Architektur von Softwaresystemen spielt bei der Auswahl eines Softwaresystems insofern eine Rolle, dass sie den Aufwand und die Möglichkeiten für die Integration in die vorhandene informationstechnische Infrastruktur und auch die Nachhaltigkeit der Investition für spätere Erweiterungen wesentlich mitbestimmt. Im Engineering-Bereich werden unter anderem Workflowmanagement-, CAx-, Berechnungssoftware-, PDM- und andere IT-Systeme zur Umsetzung des PLM-Konzepts eingesetzt, die in Summe die Integrationssysteme bilden. Die VDI-Richtlinie 2219 definiert PDM-Systeme als technische Datenbank- und Kommunikationssysteme, die dazu dienen, Informationen über Produkte und deren Entstehungsprozesse bzw. Lebenszyklen konsistent zu speichern, zu verwalten und allen relevanten Bereichen eines Unternehmens bereitzustellen (VDI 2219). PDM-Systeme bilden somit

164

5 Leithefte zu PLM-Aspekten

eine Basis für Integrationssysteme, um alle über den Produktentwicklungsprozess benötigten Applikationssysteme (z. B. CAx-Systeme, OfficeProgramme, NC-Tools) über Schnittstellen zu einem Gesamtsystem zu verbinden. Aus technischer Sicht betrachtet sind häufig moderne Systeme, wie die meisten PDM-Systeme oder andere Systeme zum Informations- und Prozessmanagements mit so genannten Client-Server-Architekturen realisiert, während datenerzeugende Systeme, wie CAD-Systeme, monolithische Architekturen besitzen. Prinzipiell lässt sich ein Softwaresystem unabhängig von der Architektur durch die drei Schichten Präsentations-, Applikations- und Datenschicht beschreiben. In der Literatur werden auch Architekturen mit einer größeren Anzahl Schichten beschrieben. Diese enthalten lediglich eine detaillierte Beschreibung dieser drei Schichten durch eine Aufteilung einer Schicht in weitere Schichten. Die Präsentationsschicht übernimmt dabei die Aufgabe der Visualisierung der Daten und die Kommunikation mit dem Anwender. Die Applikationsschicht stellt die Anwendungsfunktionen zur Verfügung und die Datenschicht übernimmt die Speicherung und Verwaltung der Informationen. Monolithische Softwaresysteme vereinigen die drei Schichten in einer Applikation, die als Ganzes auf einem Rechner ausgeführt wird. Client-Server-Systeme implementieren Präsentationsschicht, Applikations- und Datenschicht in getrennten Softwarekomponenten, die auch auf verschiedenen Rechnern laufen können und über Schnittstellen miteinander kommunizieren (s. Abb. 5-46). Je nach technischer Umsetzung von Client-Server-Systemen können die Funktionen der verschiedenen Schichten in unterschiedlichem Umfang auf Client und Server aufgeteilt sein (siehe Abschnitt 6.11). Üblicherweise implementiert der Client die Funktionen der Präsentationsschicht und der Server die Funktionen der Applikations- und Datenschicht. Enthält die Serverkomponente des Softwaresystems Applikations- und Datenschicht, spricht man von einer „two tier architecture“, bei einer Trennung der Komponenten in Applikationsserver und Datenbankserver von einer „three tier architecture“. Komplexe Standardsoftwaresysteme, wie PDM-Systeme, bestehen in der Regel aus einem Basismodul und ergänzenden Modulen, die Funktionen eines bestimmten Bereichs beispielsweise Workflowmanagement, Dokumentenmanagement oder Konfigurationsmanagement bei PDMSystemen, vollständig abdecken. Dies erlaubt dem Anwender ein System mit dem Funktionsumfang zu erwerben, den er benötigt, und im Bedarfsfall zu einem späteren Zeitpunkt um weitere Funktionalität zu ergänzen.

Datenbank

ERPSchnittstelle

ClientSchnittstelle

ERPApplikation DatenbankSchnittstelle

e

PDMApplikation

ERP-Rechner

CADSchnittstelle

DatenbankSchnittstelle

CADSystem

ERPClient

WebBrowser We Schn bitstell

ClientSchnittstelle

PDMClient

PDM-Rechner

Applikationsschicht Datenschicht

165

Mitarbeiter Rechner

Web lle ittste Schn

Präsentationsschicht

5.10 Auf Standardsystemen aufbauen

Datenbank

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

Das neuere Konzept der so genannten „serviceorientierten Architektur“ (service-oriented architecture, SOA) verfolgte eine noch stärkeren Modularisierung im Vergleich zur prozessgetriebenen Architektur herkömmlicher Softwaresystem. Bei diesem Konzept werden die einzelnen Funktionen des Softwaresystems durch eine Kollektion von einfach aufgebauten Diensten (Services) bereitgestellt, die miteinander kommunizieren. Dabei können die Dienste auf verschiedenen Rechnern ausgeführt werden. Diese Möglichkeit ist besonders bei der verteilten Zusammenarbeit zwischen Firmen von Vorteil, da diese Rechner über Dienste Informationen aus den jeweiligen Firmen sicher bereitstellen können. Beispielsweise kann die Abfrage einer Baugruppe, durch eine Kollektion von Diensten zum Zusammenstellen der Baugruppeninformationen, Diensten zum Bereitstellen der Bauteilinformationen aus den jeweiligen Firmen und Diensten zur Authentifizierung der Anwender durchgeführt werden.

166

5 Leithefte zu PLM-Aspekten

5.10.3 Anpassung von Standardsoftwaresystemen

Für die Anpassung von Standardsoftwaresystemen werden teilweise auch die Begriffe Adaption oder Customizing verwendet. Diese Begriffe bezeichnen im Allgemeinen die Anpassung eines Systems an die kundenbzw. unternehmensspezifischen Anforderungen. Standardsoftwaresysteme können an die unternehmensspezifischen Anforderungen dabei in unterschiedlicher Art angepasst werden (Adamietz 2001): • Parametrisierung Bei der Parametrisierung erfolgt die unternehmensspezifische Anpassung durch eine Auswahl von vorgegebenen Funktionen, Prozessen und Formaten, beispielsweise durch das Einstellen der Sprache. Eine Anpassung über diese vom System vorgegebenen Möglichkeiten besteht bei der Parametrisierung jedoch nicht. Da sich die Anpassung in einem vordefinierten Rahmen bewegt, können auf Weise Probleme bei der Wartung des Softwaresystems, z. B. Einspielen von Software-Updates vermieden werden. • Anpassung bzw. Erweiterung von Referenzmodellen Eine umfangreichere Art der Anpassung ist durch die Anpassung der internen Datenmodelle, welche die Softwaresysteme verwenden, möglich. Dabei werden diese Referenzmodelle, wie z. B. Daten- oder Prozessmodelle, durch Modellierung angepasst bzw. erweitert. Somit ist auch eine Erweiterung über den vom System vorgegebenen Rahmen hinaus möglich. Diese Art der der Anpassung ist beispielsweise bei PDM-Systemen weit verbreitet. • Ergänzungsprogrammierung Als weitere Art der Anpassung von Standardsoftwaresystemen kann die so genannte Ergänzungsprogrammierung angesehen werden. Durch sie kann ein Standardsoftwaresystem beliebig angepasst bzw. um beliebige Funktionalität erweitert werden, da das System mittels einer systemeigenen Skriptsprache oder einer beliebigen Programmiersprachen durch Programmierung erweitert bzw. angepasst wird. Durch umfangreiche Ergänzungsprogrammierung kann ein Standardsoftwaresystem quasi zur Individualsoftware werden, was z. B. bei Releasewechseln zu Problemen führen kann. Neben den Möglichkeiten zur Anpassung eines Standardsoftwaresystems ist jedoch auch dessen Nutzungsmöglichkeit im Basiszustand bei Lieferung von Bedeutung. Je größer der Anpassungsaufwand ist, desto höher sind die damit verbundenen Kosten und desto länger ist der Zeitraum bis zur Produktivschaltung des Systems. Am Beispiel der PDM-Systeme teilt

5.10 Auf Standardsystemen aufbauen

167

Schöttner (Schöttner 1999) die Systeme nach ihrer nutzbaren Funktionalität in die folgenden Systemklassen ein: • Turnkey-Lösungen Eine Turnkey-Lösung bietet sofort nutzbare Anwendungsfunktionalität über konfigurierbarer Anwendungsmodule sowie Werkzeuge zur weiteren Anpassung des Systems. • Toolbox-Ansätze Ein Toolbox-System ist eine Entwicklungsumgebung zur Realisierung von kundenspezifischen (PDM-)Lösungen, die jedoch keine oder kaum Anwendungsfuntionaltät enthält. • Toolbox-basierende Turnkey-Lösungen Toolbox-basierende Turnkey-Lösungen enthalten zusätzlich zur Entwicklungsumgebung bereits fertig implementierte Basisfunktionen. Funktional besteht kein Unterschied zur Turnkey-Lösung. Der Unterschied besteht darin, dass die Basisfunktionaltät von einem anderen Softwareunternehmen entwickelt wird als die Entwicklungsumgebung. Für die Anpassung von Standardsoftwaresystemen spielen die unternehmensspezifischen Prozesse und Organisationsstrukturen eine erhebliche Rolle, da sie durch den Einsatz der Software unterstützt bzw. optimiert werden sollen. Je nachdem, ob die Organisation oder die Technik geändert wird, wird bei der Anpassung von Standardsoftwaresystemen zwischen Prozessanpassung und Softwareanpassung unterschieden (Adamietz 2001). Bei der Softwareanpassung wird ein Standardsoftwaresystem entsprechend der Prozesse und Organisationsstrukturen eines Unternehmens angepasst. Auf diese Weise erhält man ein Softwaresystem, das eine optimale Unterstützung bietet, aber auch entsprechend hohen Aufwand an Kosten und Zeit für die Anpassung erfordert sowie technisch hohe Anforderungen an die Flexibilität des Systems stellt. Werden die Geschäftsprozesse eines Unternehmens an die Funktionalität des Standardsoftwaresystems angepasst, spricht man von Prozessanpassung, wobei dies in der Regel nicht zu einer für das Unternehmen optimalen Prozessunterstützung führt. Der Vorteil der Prozessanpassung liegt in den geringeren Kosten für die Softwareeinführung und dem geringeren Aufwand für die Systempflege gegenüber der Softwareanpassung. Im Normalfall wird bei der Anpassung von Standardsoftwaresystemen weder eine reine Softwareanpassung noch eine reine Prozessanpassung durchgeführt, sondern es wird ein Mittelweg zwischen beiden Möglichkeiten gewählt. Standardsoftwaresysteme im Product Lifecycle Management, insbesondere PDM-Systeme, verlangen in hohem Maß nach unternehmensspezifischen Anpassungen, um den oft sehr speziellen Anforderungen vor allem

168

5 Leithefte zu PLM-Aspekten

in Entwicklung und Konstruktion die optimale Unterstützung zu bieten. Bei diesen Anpassungen stehen deshalb vor allem die folgenden Gesichtspunkte im Vordergrund: • die formale Beschreibung der Prozesse (z. B. Freigabe- und Änderungsabläufe) • die Vergabe von Benutzerberechtigungen • die Festlegung der Daten- bzw. Objektmodelle • die unternehmensspezifische Gestaltung der Benutzungsoberflächen Deshalb sollte neben der Anpassbarkeit als solche bei den Anpassungsmöglichkeiten von Standardsoftwaresystemen ebenfalls die Unterstützung durch die Systemhersteller und Verfügbarkeit von geeigneten Werkzeugen zur Anpassung beachtet werden. 5.10.4 Durchführung von Anpassungen und Systempflege

Die Grundlage der Systemanpassung sollte eine umfangreiche Ist-Analyse des Unternehmens bilden, mit deren Ergebnissen ein Soll-Konzept erarbeitet wird, welches dann im System umgesetzt wird (vgl. Abschnitt 5.7). Die technische Umsetzung der Anpassung wird im Falle der Anpassung bzw. Erweiterung von Referenzmodellen und der Ergänzungsprogrammierung über Änderungen bzw. Ergänzung des Datenmodells des Systems vollzogen. Dabei werden Klassen verändert, indem Attribute und Methoden geändert, gelöscht oder hinzugefügt werden. Stehen diese Klassen in Beziehung zu weiteren Klassen müssen dort ebenfalls korrespondierende Anpassungen durchgeführt werden. Bei der Parametrisierung werden dagegen bestimmte Attributwerte gesetzt, die auf vordefinierte Objekte (Instanzen von Klassen) verweisen. Abb. 5-47 zeigt ein Beispiel der Parametrisierung und Ergänzung eines Datenmodells. Mit der Einführung eines Softwaresystems sind die Arbeiten an diesem System in der Regel nicht beendet. Vielmehr muss eine kontinuierliche Pflege und Wartung des Systems erfolgen, die bei individuell angepassten Softwaresystemen in einigen Fällen Schwierigkeiten bereitet. Zum einen machen Änderungen von Geschäftsprozessen oder Organisationsstrukturen eine erneute Anpassung eines Systems notwendig, und es treten Probleme auf, da die Anpassungen des Systems nicht oder nur ungenügend dokumentiert wurden. Aus diesem Grund sollte entsprechend dem evolutionären Vorgehensmodell eine Dokumentation aller Anpassungsarbeiten im PLM-Manifest erfolgen.

5.10 Auf Standardsystemen aufbauen Parametrisierung menu_sprache sprache formular_label1 formular_label1 formular_label1 Methoden()

<> sprache=„deutsch” formular_label1 =„Artikelnummer“ ... Methoden()

169

Anpassung/Erweiterung Formular_Artikel artikelNr artikelName menu_sprache konstrukteur

Neues Attribut

get_artikelNr() set_artikelNr() get_artikelName() set_artikelName() get_menu_sprache() get_konstrukteur() set_konstrukteur()

Objekt für deutsche Sprache

Neue Methode

Artikel artikelNr artikelName get_artikelNr() set_artikelNr() get_artikelName() set_artikelName() Konstrukteur mitarbeiter abteilung get_mitarbeiter() set_mitarbeiter() get_abteilung() set_abteilung()

Abteilung Attribute Mitarbeiter Methoden() Attribute Methoden()

Neue Klasse

Abb. 5-47: Anpassung eines typischen Referenzmodells

Zum anderen stellen Updates oder Releasewechsel des Softwaresystems den Nutzer vor ein Problem, wenn sie aufgrund der Anpassungen des Systems nicht durchgeführt werden können. Updates ersetzen einzelne Komponenten des Softwaresystems, um Fehler zu beseitigen oder die Funktionalität in geringem Umfang zu erweitern. Ein Update verursacht demnach nur dann ein Problem, wenn es Teile der Software ersetzt, die angepasst wurden. Zur Lösung des Problems muss im ungünstigsten Fall der ursprüngliche Zustand der Komponente wiederhergestellt werden, andernfalls ersetzt das Update einfach die betreffende Komponente. In beiden Fällen muss jedoch eine erneute Anpassung der betroffenen Komponente des Softwaresystems vorgenommen werden. Eine neue Version eines Softwaresystems wird als Release (engl.: Freigabe) bezeichnet, die in der Regel neben beseitigten Fehlern einen erweiterte und verbesserte Funktionalität zur Verfügung stellt. Diese erweiterte Funktionalität beinhaltet jedoch unter Umständen umfangreiche Änderungen am Datenmodell des Softwaresystems, so dass Anpassungen nicht von der Vorgängerversion übernommen werden können. Ein Releasewechsel kann prinzipiell als ein Update aller Systemkomponenten durchgeführt werden, allerdings treten in diesem Fall die gleichen Probleme zutage, wie beim Update einzelner Komponenten. Aufgrund dessen werden Releasewechsel in der Regel als Neuinstallationen des Softwaresystems, meist in Verbindung mit leistungsfähigerer, neuer Rechnerhardware, ausgeführt. Soweit die Möglichkeit besteht werden Anpassungen des Vorgängersystems übernommen und dessen Daten in das neue System überführt.

170

5 Leithefte zu PLM-Aspekten

Weiterführende Literatur

• Abramovici, M.: EDM/PDM-Einführungsstrategien – Erfahrungen und Perspektiven; in: Informationsverarbeitung in der Konstruktion ´99 – Beschleunigung der Produktentwicklung durch EDM/PDM- und Feature-Technologie, S.209 – 226; Düsseldorf: VDI Verlag, 1999 • Adamietz, Peter: Adaption von Standardsoftwaresystemen; Aachen: Shaker Verlag, 2001 • Schöttner, J.: Produktdatenmanagement in der Fertigungsindustrie. Prinzip, Konzepte, Strategien.; München, Wien: Hanser Verlag, 1999 • Vajna, S.: Die neue Richtlinie VDI 2219: Praxiserprobte Hinweise zu Einführungsstrategien und Wirtschaftlichkeit von EDM/PDM-Systemen in: Informationsverarbeitung in der Konstruktion ´99 – Beschleunigung der Produktentwicklung durch EDM/PDM- und Feature Technologie, S.25 – 42, Düsseldorf: VDI-Verlag, 1999 • VDI-Richtlinie 2219: Einführungsstrategien und Wirtschaftlichkeit von EDM/PDM-Systemen (Reihe Datenverarbeitung in der Konstruktion); Düsseldorf: VDI-Gesellschaft Entwicklung Konstruktion Vertrieb, 1999

5.11 Systeme kommunizieren lassen

171

5.11 Systeme kommunizieren lassen Æ Prozess- und Organisationsmanagement

Grundsätzlich ist davon auszugehen, dass die Erledigung jeglicher Art von Aufgaben in einem Unternehmen Informationen voraussetzt. Der gesamte Produktions- und Dienstleistungsprozess ist von Informationsflüssen begleitet. Diese Informationsflüsse sind Grundlage für Entscheidungen und für die Durchführung von Prozessen in den Abteilungen eines Unternehmens. Die Informationen werden dabei in der Regel in verschiedensten Informationssystemen und aufgabenspezifischen Applikationen, beispielsweise ERP-, PPS-, CAD-Systemen oder Office-Anwendungen, erzeugt und verwaltet. Um möglichst effiziente Informationsflüsse zu erhalten ist die Verbindung dieser verschiedenen Systeme und Applikationen nötig. Zunehmend wird Datenaustausch und Applikationsintegration über die Grenzen des eigenen Unternehmens hinweg immer mehr zum Thema, da durch die Globalisierung Produktion und Entwicklung weltweit auf verschiedene Standorte oder Unternehmen in immer stärkerem Maße verteilt werden. Die heutigen Informationssysteme bieten hier durch den Einsatz modernster Informations- und Kommunikationstechnologien viele verschiedene Möglichkeiten der technischen Umsetzung für Datenaustausch und Applikationsintegration. Bei der Applikationsintegration werden verschiedene Systeme so gekoppelt, dass neben den Daten auch die Funktionen des einen Systems über einen Aufruf aus dem anderen System genutzt werden können. An die Stelle manueller Verarbeitung, Speicherung und Übermittlung von Information sind computergestützte Formen getreten. Mit dieser Automation verbunden ist eine starke Individualisierung, Flexibilisierung und Beschleunigung der Informationsflüsse, wodurch auch der Grad der Aktualität der Information erheblich gesteigert wird. Im günstigsten Fall steht somit Information problembezogen aufbereitet sofort und jederzeit zur Verfügung. Dies ist jedoch meist mit hohem Aufwand für die Planung, Umsetzung und Wartung der jeweiligen Integrationslösungen verbunden.

172

5 Leithefte zu PLM-Aspekten

5.11.1 Applikationsintegration und Datenaustausch

Die nachfolgende Abbildung (s. Abb. 5-48) stellt einen Überblick über die wesentlichen Teilgebiete des Product Lifecycle Managements und deren Verbindungen untereinander dar. Applikationsintegration, Schnittstellen und Datenaustausch bilden einen grundlegenden PLM-Aspekt, der durch alle übrigen PLM-Aspekte angesprochen wird, sobald PLM als Integrationsplattform für Informationen und Prozesse zum Tragen kommt.

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-48: Applikationsintegration und Datentausch im PLM-Umfeld

5.11 Systeme kommunizieren lassen

173

5.11.2 Optimiertes PLM durch Applikationsintegration

Die verschiedenen Abteilungen und Bereiche eines Unternehmens verwenden zur Bearbeitung Ihrer Aufgaben häufig verschiedenste Softwaresysteme, deren Daten sich in vielen Fällen inhaltlich überschneiden, d. h. redundant verwaltet werden. Die Daten müssen oft mehrfach manuell in die Systeme eingepflegt werden und sind deshalb häufig in den verschiedenen Systemen nicht konsistent. Zudem sind Unternehmen heute oft über verschiedene Standorte verteilt oder mit anderen Unternehmen über vielfältige Allianzen verbunden. Für die Unterstützung verteilter Produktentwicklungsprozesse werden grundsätzlich die gleichen Funktionen der Integrationssysteme herangezogen wie bei konventionellen Prozessen, hinsichtlich der verwendeten Technologie und der Datenhaltung sind einige Besonderheiten zu beachten. Spezielle Anforderungen sind z. B. die Möglichkeit der verteilten Datenhaltung mit kontrollierter Redundanz, schnelle Übertragungsraten bzw. kurze Antwortzeiten bei standortübergreifenden Aktionen, die Gewährleistung der Datensicherheit bei der Übertragung etc. Die Integration verschiedener Anwendungssysteme bietet dabei mögliche Vorteile bei • der Automatisierung von Prozessen, • der Vereinfachung der Datenpflege durch Vermeidung von Eingabeoder Übertragungsfehlern und • der Vereinheitlichung der einzelnen Anwendungen durch den Start der Anwendung über ein zentrales System wie beispielsweise ein PDMSystem. Je nach dem welche Informationen integriert werden sollen, wird zunächst zwischen den Integrationszielen mit Schwerpunkt auf Standortintegration oder Systemintegration unterschieden. In den verschiedenen Standorten eines Unternehmens müssen gemeinsame Produktdaten verwaltet werden. Gemeinsame Geschäftsprozesse erfordern die gemeinsame Nutzung dieser Daten. Das bedeutet, dass bei der Standortintegration eher gleichartige Systeme, beispielsweise mehrere PDM-Systeme, miteinander verbunden werden. Wenn in mehreren Standorten gleiche Systeme benutzt werden, bedeutet das nicht automatisch, dass der Datenaustausch problemlos stattfinden kann. Oft ist die Aufgabe der Datenintegration nicht einfacher als bei verschiedenen Systemen, da wegen spezifischer Anpassungen der Systeme die auszutauschenden Daten in verschiedenen Formaten vorliegen, wie zum Beispiel verschiedene Längen von Textfeldern oder unterschiedliche Formatierungen, beispielsweise von Telefonnummern.

174

5 Leithefte zu PLM-Aspekten

Produktdaten werden von verschiedenen IT-Systemen genutzt, bearbeitet oder verwaltet. Die Nutzung derselben Produktinformationen in verschiedenen Systemen ist mit der Integration der Daten und Prozessen verbunden. Das Ziel einer Systemintegration ist somit in der Integration verschiedenartiger Systeme, wie PDM und CAD oder PDM und ERP, zu sehen. 5.11.3 Voraussetzung für Applikationsintegration

Die in den einzelnen Funktions- und Unternehmensbereichen eingesetzten Applikationen (Anwendungssysteme) wurden ursprünglich entweder völlig isoliert (Insellösungen) betrachtet oder sind nur wenig aufeinander abgestimmt. Um den Informationsaustausch zu optimieren und redundante Eingabe und Verwaltung von Daten zu vermeiden, wird zusehends nach einer Integration dieser Informationsinseln verlangt. Die Integration der Teilsysteme ist aber nicht nur durch die Historie der Informationssysteme bedingt, sondern ist eine sich immer wieder stellende Aufgabe, sobald Informationssysteme geändert, ersetzt oder neu eingeführt werden. Um die Integration der Anwendungssysteme durchzuführen, muss zunächst festgelegt werden, in welchem Umfang die Integration erfolgen soll, da dies einen erheblichen Unterschied im Umfang der Implementierungsarbeiten bedeutet. Man unterscheidet dabei im Allgemeinen zwischen Datenintegration und Funktionsintegration. Ziel der Datenintegration ist, eine mehrfache Erfassung und Datenhaltung zu vermeiden und inkonsistente Datenbestände zu verhindern. Datenintegration liegt vor, wenn eine Anwendung Daten an eine andere Anwendung zur Verarbeitung weitergibt und dabei eines der beiden folgenden Konzepte verwendet: • Der Austausch von Daten zwischen den Systemen erfolgt durch Kopplungsprozeduren. • Die zu integrierenden Anwendungen greifen auf eine gemeinsame Datenbank zu. Ziel der Funktionsintegration ist es redundante Funktionen und inhaltliche Redundanzen zu beseitigen. Bei der Funktionsintegration greifen die Funktionen verschiedener Anwendungssysteme ineinander. Die Integration besteht darin, die Funktionen verschiedener Anwendungssysteme unter einer einheitlichen Benutzeroberfläche zusammenzufassen oder zumindest die zweite Applikation zusammen mit der Übergabe der zu bearbeiteten Daten zu starten. Ein Beispiel hierfür ist ein im PDM-System verwaltetes CAD-Modell, das zur Bearbeitung aus dem CAD-System geöffnet wurde.

5.11 Systeme kommunizieren lassen

D

A

B

Standardschnittstelle

C

D

A

B

C

2*n Schnittstellen

175

n*(n-1) Direktschnittstellen

Abb. 5-49: Standard- und Systemschnittstellen

Für den zeitlichen Verlauf beim Austausch von Daten wird zwischen synchronen und asynchronen Datenaustausch unterschieden. Beim synchronen Datenaustausch wird auf die Produktdaten direkt zugegriffen. Im Gegensatz dazu werden beim asynchronen Datenaustausch die Produktdaten nach bestimmten Zeitabstände, z. B. täglich in der Nacht, abgeglichen. Wenn zwei Informationssysteme direkt miteinander kommunizieren, spricht man von Direktschnittstellen. Bei der Kommunikation über Standarddatenformat wird von Datenaustausch durch Standardschnittstellen gesprochen. Die Abb. 5-49 verdeutlicht die Vorteile einer Standardschnittstelle im Vergleich zu einer Direktschnittstelle. Der Aufwand hängt zwar immer von der Anzahl der beteiligten Systeme (A, B, C, D) ab, jedoch steigt er ja nach Anzahl der Schnittstellen (n) im einen Fall linear und im anderen quadratisch. Bei der direkten Kommunikation muss man für jedes Paar von angekoppelten Systemen zwei Schnittstellen implementieren – eine für die Ausgangs- und eine für die Eingangsdaten. Damit alle Systeme miteinander kommunizieren können, müssen solche Paare von Schnittstellen zwischen allen Systemen realisiert werden. Beim Datenaustausch über eine Standardschnittstelle werden nur zwei Schnittstellen pro IT-System implementiert, die die Konvertierung der Daten von und zum Standarddatenformat gewährleisten. 5.11.4 Implementierung von Schnittstellen

Auf der systemtechnischen Ebene lässt sich eine Integration von Informationssystemen durch verschiedene Technologien realisieren. Für die technische Umsetzung einer Integrationslösung bieten die Applikationssysteme meist spezielle Programmierschnittstellen, so genannte Application Programming Interfaces (API) an. Diese APIs beinhalten standardisierte Softwareroutinen, Protokolle und Schnittstellenbeschreibungen, die den Zugriff auf die Daten und technischen Funktionen einer Applikation für

176

5 Leithefte zu PLM-Aspekten

andere Applikationen zugänglich machen und für Softwareentwickler dokumentieren. Technisch sehr umfangreiche Integrationsmöglichkeiten bieten sich durch so genannte Middleware-Software. Middleware bezeichnet Software, die Informationen zwischen mehreren, verteilten und verschiedenen Applikationen vermittelt und die Kommunikation und den Datentransfer steuert und kontrolliert. Eine weit verbreitete Anwendung besteht darin, dass ein Programm, das den Zugriff auf eine bestimmte Applikation ermöglicht, mit Hilfe von Middleware auch Zugriff auf andere Applikationen erhält. Vorteile des Einsatzes von Middleware sind: • Kommunikationsprotokolle Protokolliert wird der Datenfluss und zu statistischen Zwecken ausgewertet. Werden beispielsweise Produktdatenblätter von einem Integrationssystem über einen Webserver für potentielle Kunden zu Verfügung gestellt, besteht die Möglichkeit zu erfassen aus welchem Land sich Kunden, wie oft für ein bestimmtes Produkt interessieren. • Sicherheit Sicherheit wird durch die Implementierung von Zugriffskontrollen von System-Benutzern auf die Datenbestände gegeben. • Portierung Falls Applikationen unterschiedliche Datenformate nutzen, konvertiert Middleware die Ausgangsdaten in ein Datenformat, das dem der Zielanwendung entspricht. • Synchronisationssicherheit Greifen mehrere Applikationen gleichzeitig auf den gleichen Datenbestand zu, werden Mechanismen zur Verhinderung von Inkonsistenzen genutzt, so dass die verschiedenen Datenbestände vor jedem Zugriff einer Applikation wieder synchronisiert sind. • Transaktionssicherheit Middleware verfügt üblicherweise über Warteschlangenmechanismen, in die sich die eingehenden Kommunikationsaufträge einreihen müssen und die erst weitergegeben werden, wenn die gewünschte ServerAnwendung tatsächlich verfügbar ist. Sollte dies nicht der Fall sein, wird der Kommunikationsauftrag so lange zwischengespeichert, bis dies der Fall ist. Auf diese Art wird eine Abarbeitung des Kommunikationsauftrags in jedem Fall gewährleistet und er geht nicht verloren, wenn die Zielanwendung nicht verfügbar sein sollte. Dies gilt auch für Fälle, in denen mehrere Server-Anwendungen verfügbar sind, zwischen denen die Last gleichmäßig verteilt werden soll.

5.11 Systeme kommunizieren lassen

177

Im Vergleich zu herkömmlichen Architekturen zur Integration von ITSystemen wird durch die Verwendung von Middleware noch eine zusätzliche Softwareschicht in die Kommunikation eingezogen. Dies lohnt sich üblicherweise dann, wenn eine große Anzahl von Informationssystemen integriert werden muss, die sehr umfangreich und unübersichtlich oder inhomogen sind. Dies ist z. B. bei verteilten Datenbanksystemen der Fall, in denen Daten an verschiedenen Orten konsistent gehalten werden müssen. Nachteilig ist in einigen Fällen die Verlangsamung von Transaktionen durch Middleware und vor allem der höhere Implementierungs- und Managementaufwand. Ein zentrales Problem im Engineering-Bereich stellen beim Austausch von Produktmodellen die unterschiedlichen Datenformate und -strukturen für die Produktstrukturen und Geometrieinformationen dar. Mit dem Standard for the Exchange of Product Model Data (STEP) wurde eine standardisierte Basis für den Datenaustausch von Produktdaten geschaffen, die so eine einfachere Integration von individuellen Produktmodellen verschiedenster Applikationen erlaubt. STEP ist eine internationale Norm, die ein Produktmodellschema, Übertragungs- und Archivierungsformat definiert, das alle im Produktlebenszyklus entstehenden Informationen beinhaltet. Im Rahmen der STEP-Entwicklung wurde neben dem Produktmodell eine formale, objektorientierte Sprache zur Modellspezifikation, verschiedene Austausch- und Archivierungsformate sowie Methoden zum Test der Konformität von Implementierungen entwickelt. Eine weitere Spezifikation für die Implementierung von Daten- und Funktionsschnittstellen wird durch die Product Data Management Enablers (PDM Enablers) der Object Management Group beschrieben. Weitere Informationen zu den vorgestellten Standardschnittstellen sind im Abschnitt 6.11.4 zusammengefasst. Diese Spezifikation (Product Data Management Enablers Specification 2000) stellt Standardschnittstellen für Produkt- und Prozessinformationen aus Entwicklung und Konstruktion mit dem Ziel der Integration von Integrationssysteme und Fertigungssoftwaresysteme zur Verfügung. Die Schnittstellenspezifikation beinhaltet Grundgerüste für die Implementierung und Schnittstellendefinitionen für die Interoperabilität von Systemen und Client-Software, die Produktinformationen verwalten, nutzen oder zur Verfügung stellen. PDM Enablers stellen nicht zwingend alle Schnittstellen für die gesamte Funktionalität zur Implementierung der Benutzerfunktionen von Integrationssystemen bereit.

178

5 Leithefte zu PLM-Aspekten

5.11.5 Informationsintegration im PLM

Das wesentliche Ziel des Product Lifecycle Managements ist die Verwaltung und Bereitstellung der aktuellen Produktdaten. Aus diesem Grund spielt die Integration von Applikationen und der Datenaustausch eine wesentliche Rolle, da sie die Voraussetzungen für eine an das jeweilige Unternehmen angepasste Form des Produktdatenmanagements bildet: Durch die Integration der verschiedenen Applikationen und Informationssysteme können die Produktinformationen an den geeigneten Stellen zentral oder verteilt gehalten und bereitgestellt werden. Je nach Art der Datenhaltung muss eine geeignete Integrationslösung umgesetzt werden (s. Abb. 5-50). Bei der zentralen Datenhaltung greifen alle Systeme auf einen gemeinsamen Datenbestand zu, was in der Praxis jedoch in den seltensten Fällen zu realisieren ist. Stattdessen sind häufig replizierte Datenbestände vorzufinden, bei denen die Daten redundant, d.h. gleichzeitlich an mehr als einem Ort aufbewahrt werden. Über Replikationsmechanismen wird dann gewährleistet, dass bei Änderungen in einem Datenbestand die entsprechenden verteilten Datensätze, meist zeitversetzt, ebenfalls aktualisiert werden. Standort 2 Produkte: C, D

Standort 1 Produkte: A, B

Standort 1 Produkte: A, B, C

Metadaten

Metadaten

Metadaten

Produkt A, B, C, D

Produkt A, B, C, D

Produkt A, B, C, D

Nutzdaten

Nutzdaten

Nutzdaten

Produkt A, B

Produkt C, D

Produkt A, B, C

Replikation

Standort 1 Produkte: A, B, C

Standort 2 Produkte: D Metadaten

Metadaten

Produkt A, B, C, D

Produkt A, B, C, D

Produkt A, B, C, D

Replikation

Metadaten Replikation

Nutzdaten

Nutzdaten

Produkt A, B, C, D

Produkt A, B, C

Abb. 5-50: Möglichkeiten der Datenverteilung

Produkt A, B, C, D

Nutzdaten Replikation

Standort 1 Produkte: A, B, C

Metadaten

Standort 2 Produkte: C, D

Produkt C, D

Standort 2 Produkte: D

Nutzdaten Replikation

Produkt D

5.11 Systeme kommunizieren lassen

179

Bei solchen Lösungen ist hauptsächlich Performanz durch örtlich nahe Datenzugriffe zu gewinnen. Der Aufwand für die Replikation kann in speziellen Fällen verringert werden, in denen vorhergesagt werden kann, dass bestimmte Daten nur an bestimmten Orten genutzt werden. In diesen Fällen werden Integrationsmechanismen angewendet, die die Daten nur auf diese jeweiligen Orte verteilen, aber nicht redundant an allen Orten halten. Man spricht in diesem Fall von fragmentierter Datenhaltung. Bei fragmentierten Datenbeständen werden diese geteilt und jeweils dort gehalten, wo sie entstehen oder am häufigsten verwendet werden (Eigner u. Stelzer 2001). Die Abb. 5-50 zeigt verschiedene Möglichkeiten der Datenverteilung. Bei verteiltem Management von Produktdaten befinden sich entweder die Metadaten (beschreibende Zusatzinformationen – programmiertechnische Objekte mit Attributen) oder die Nutzdaten (Dokumente: CADModelle, Office-Dokumente, Zeichnungen etc.) auf räumlich getrennten Servern. Für örtlich verteiltes Produktdatenmanagement reicht es in der Regel nicht aus, an den räumlich entfernten Standorten einzelne ClientAnwendungen der IT-Systeme zu installieren, die auf einen zentralen Server zugreifen, da besonders für Übertragung von Nutzdaten hohe Bandbreiten für die Datenverbindung erforderlich sind. Dies ist lediglich bei geringen Datenvolumen sinnvoll. CAD-Integration

Die Funktionalität einer CAD-Schnittstelle beinhaltet mehr Funktionalität als das ein- bzw. auschecken von Dateien und die Regelung des Zugriffs. Der Zweck einer CAD-Schnittstelle zu einem Integrationssystem oder Dokumentenmanagementsystem besteht darin, die im CAD-System vorhandenen nichtgeometrischen Informationen automatisch in das integrierende System zu übernehmen und dort zu verwalten. Dies beinhaltet in erster Linie die Baugruppen- bzw. die Produktstrukturen sowie die stücklistenrelevanten Informationen. Zudem werden ebenfalls die Informationen des Verwaltungssystems in das CAD-System übernommen, beispielsweise Artikelnummer und Bezeichnung beim Erzeugen eines neuen CADModells. Die Schwierigkeit bei der Implementierung einer CAD-Schnittstelle besteht darin, dass die Zusammenbaustrukturen in jedem CAD-System etwas anders gehandhabt werden. Einige Systeme verwalten die Informationen in separaten Strukturdateien, andere verweisen auf die absoluten Pfade der Einzelteilmodelle und wiederum andere integrierten Strukturen und Geometrien im Modell, so dass ein Schnittstellen-Entwickler sehr tiefen Einblick in das CAD-System besitzen muss (Wendenburg 2001).

180

5 Leithefte zu PLM-Aspekten

Somit muss die Schnittstelle die Strukturinformationen und weitere Metadaten, wie die Artikelnummer, im CAD-Datenmodell und im unternehmensspezifisch angepassten Datenmodell eines Integrations- oder Dokumentenmanagementsystems aufeinander abbilden. Daraus ergibt sich ein mit der Integrationstiefe stark ansteigender Zeit- und Kostenaufwand für die Implementierung. ERP-Integration

Die Integration von PLM und ERP ist weit mehr als die bloße Integration zweier Software-Applikationen, sondern betrifft teilweise grundlegende Geschäftsprozesse eines Unternehmens. ERP-Systeme bedienen dabei üblicherweise die betriebswirtschaftlichen Aufgaben während Integrationssysteme eher die technischen Belange im Fokus haben. Da allerdings beide Systeme die Aufgabe haben Geschäftsprozesse informationstechnisch zu unterstützen, ergeben sich zwangsläufig Überschneidungen in der Funktionalität und vor allem bei den gespeicherten Informationen. Aus diesem Grund lassen sich die Anforderungen an die Integration von PLM und ERP auch bis zu jedem beliebigen Umfang definieren, so dass hier der Nutzen ganz besonders vor der technischen Machbarkeit im Vordergrund stehen sollte. Es muss auch festgelegt werden, welches System führend bei der Verwaltung bestimmter Daten ist, d. h. welches System die höhere Priorität für die Geschäftsabläufe im Unternehmen besitzt. Grundsätzlich sollten jedoch die folgenden Problemstellungen mit einer PLM-ERPIntegration bewältigt werden: • Grunddaten wie Stücklisten und Materialstammdaten neu konstruierter Teile entstehen während des Konstruktionsprozesses und werden in Integrationssystemen abgelegt. Da es für neue Teile keine Einträge im ERP-System gibt, müssen diese Grunddaten nach Produktionsfreigabe in dieses übertragen werden. Gleiches gilt für Auftragsdaten, Dokumente, Dokumentenstrukturen und das Änderungswesen. • Der Zugriff auf im ERP-System gespeicherte Informationen, die im Konstruktionsprozess benötigt werden, sollte erleichtert werden. Der Aufwand für die Erfassung von Informationen soll vermindert werden, d. h. Daten werden nur einmalig erfasst. Durch eine entsprechende Automatisierung werden Inkonsistenzen in den Datenbeständen verhindert, da immer nur die gerade aktuellen Informationen in beiden Systemen abrufbar sind. Weiterhin wird auch die Auftragsabwicklung durch den schnelleren Informationsaustausch beschleunigt.

5.11 Systeme kommunizieren lassen

181

5.11.6 Umsetzung von Integrationslösungen

Die Applikationsintegration und Datenaustausch bieten viele Möglichkeiten der Verbesserung von Informationsverwaltung und Geschäftsprozessen, erfordern aber gleichzeitig auch einen hohen Aufwand an Zeit und Wissen über die technischen Details der zu integrierenden Systeme. Aus diesem Grund sollten die folgenden Punkte bei Integrationsbestrebungen beachtet werden: • Art und Umfang der Integration sollten sehr genau überlegt werden und mit den Randbedingungen des eigenen Unternehmens übereinstimmen. Es sollten auch mittel- oder langfristige Erwägungen mit einbezogen werden, wie die Durchführung von Releasewechseln oder der Wechsel von Applikationen. • Ein großer Nachteil bei der Integration von Applikationen in unternehmensspezifisch angepasste Standardsoftware ist, dass mit zunehmender Integrationstiefe entsprechende Anpassungen und Erweiterungen nachgezogen werden müssen, die von der Standardapplikation abweichen. Bei einem Releasewechsel der Applikationen können diese Anpassungen unter Umständen nicht übernommen werden und müssen erneut implementiert werden. • Für die Implementierung einer Integrationslösung ist ein sehr umfangreiches Wissen über systeminterne Spezifikationen, APIs und Datenmodelle notwendig. Dieses Wissen muss entsprechend aufgebaut bzw. als Dienstleistung eingeholt werden. • Durch die Einbeziehung eines externen Dienstleisters ergibt sich wiederum Abhängigkeit von dessen Wissen und den durchgeführten Implementierungsarbeiten. Deshalb sollte in jedem Fall eine ausführliche Dokumentation der Anpassungsarbeiten vorhanden sein, um im Bedarfsfall den Dienstleister wechseln zu können. Weiterführende Literatur

• Anderl, R., Trippner, D., STEP. Standard for the Exchange of Product Model Data; Wiesbaden: Teubner Verlag, 2000 • Martin Eigner, Ralph Stelzer, Produktdatenmanagement-Systeme, Ein Leitfaden für Product Development und Life Cycle Management; Berlin, Heidelberg: Springer-Verlag, 2001 • Schöttner, J., Produktdatenmanagement in der Fertigungsindustrie. Prinzip, Konzepte, Strategien.; München, Wien: Hanser Verlag, 1999

182

5 Leithefte zu PLM-Aspekten

Normen und Standards

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

5.12 Externe Dienstleister einbinden

183

5.12 Externe Dienstleister einbinden Æ Prozess- und Organisationsmanagement Æ Standardsoftwaresysteme

Der Einbezug externer Dienstleister ist ein heikles Thema bei einer PLMUmsetzung. Einerseits muss das unternehmensspezifische PLM-Wissen im Unternehmen selbst gehalten und erarbeitet werden, andererseits kann auf das Fach-Know-how und den Erfahrungen von Dienstleistern nicht verzichtet werden. Daher soll dieses Leitheft Hinweise zur Projektdurchführung mit externen Dienstleistern geben. 5.12.1 Auftragsvergabe

Das Know-how der heutigen Prozesse, inklusive ihrer langjährigen spezifischen Optimierungen, liegt heute normalerweise im Unternehmen. Die an die Unternehmensführung gerichtete Herausforderung bei der Umsetzung der unternehmensspezifischen PLM-Vision ist es, das Know-how zum Management der zukünftigen Kernprozesse im Unternehmen zu halten und aufzubauen. Der nachhaltige Garant für eine ganzheitliche Sicht auf Prozesse, Organisation und Information, wie es das PLM fordert, kann nur das Unternehmen selbst sein. Die mittel- und langfristigen Unternehmensziele und deren dynamischen Ableitungen in den Fachabteilungen stellen das Grundgerüst für die individuelle Entwicklung des eigenen PLM-Manifests dar. Eine maximale Funktionalität für die Fachabteilungen sowie eindeutige Datenintegrität und Datenaktualität aller Produktdaten, in Kombination mit einer permanenten Verfügbarkeit für die jeweiligen Funktionen, sind die grundsätzlichen Anforderungen an die Organisation und die Informationstechnik. Projekte, wie die Einführung und Umsetzung einer PLM-Vison, sind ohne die Regeln des Projektmanagements nicht erfolgreich umsetzbar. Entsprechende PLM-Projekte benötigten klare Ziele, eindeutige Zuordnung der Verantwortungen und durchführbare Zeitpläne. Aus den Zielen und dem erwarteten Zeitraster ergeben sich der Ressourcenbedarf und damit die zu erwartenden Kosten. Allerdings ist fast jedes Unternehmen heute mit der Umsetzung seiner individuellen PLM-Vision personell und kapazitiv überfordert, so das externe Dienstleister zur Unterstützung herangezogen werden müssen. Bei der Einbeziehung externer Leistungen sind drei wesentliche Ziele in den Fokus zu stellen: • Kapazitäts-/Zeitgewinn mit den daraus resultierenden Kostenvorteilen • Know-how-Transfer in das eigene Unternehmen • Reduzierung der Betriebsblindheit in der Konzeptionsphase

184

5 Leithefte zu PLM-Aspekten

Dieses Leitheft widmet sich dem operativen Prozess der Umsetzung einer PLM-Vision in diesbezügliche Projekte. Die Grundregeln des Projektmanagements werden dabei jedoch nicht vertieft. Aufbauend auf der Hierarchie der Unternehmensziele und der Dokumentation der Ist-Prozesse, die häufig schon in der Qualitätsmanagement-Dokumentation nach ISO 9000:2000 verfügbar sind, werden die geplanten, PLM-relevanten Prozesse definiert und in einer Spezifikation bzw. in einem Lastenheft als Teil des PLM-Manifests dokumentiert. Das Lastenheft selbst dient als Plattform für die Ausschreibung und die Lieferantenauswahl. Es ist das Grundwerk des Liefervertrages, das im Wesentlichen die Beschreibung der Prozesse und Funktionen enthält, welche vom gelieferten Produkt, in diesem Fall vom Informationssystem, erfüllt werden sollen. Die Dokumentation der „Einigung zwischen den Partnern“, dem Kunden und dem/den Lieferanten stellt das Pflichtenheft für eine spezifische Organisations- und IT-Lösung dar. Das Pflichtenheft kann demzufolge nur mit dem/den Lieferanten erarbeitet werden. Auf Basis des Pflichtenheftes wird die Realisierung oder Anpassung in Richtung auf das geplante System, die Datenstrukturen, die Arbeitsweisen, die Schulung etc. vorgenommen. Es dient weiterhin als Grundlage für die Implementierung, Schulung und Abnahme, die Inbetriebnahme, den Betrieb und gegebenenfalls der Außerbetriebsetzung. Betriebsanleitungen für das neue System, Arbeitsanweisungen, Prozessdokumentationen etc. werden für den Betrieb und die Anwendernutzung normalerweise aus dem Pflichtenheft gelöst und als selbständige Dokumente weitergeführt. Es bleibt dem Auftrag gebenden Unternehmen überlassen für die Informationskonsistenz über die PLMProzesskette Sorge zu tragen. 5.12.2 PLM als Managementaufgabe

Die Ausrichtung bei der Umsetzung der PLM-Vision richtet sich nach den längerfristigen Zielen des Unternehmens. Entsprechend müssen von der Unternehmensführung zur Initialisierung eines PLM-Projektes einige Rahmenbedingungen und Vorgaben entsprechend dieser Ziele festgelegt werden. Hierfür können folgende Checkfragen herangezogen werden: • Welcher PLM-Integrationsgrad ist zukünftig für die spezifische Produktreihe bzw. für das spezifische Produkt erforderlich und betriebswirtschaftlich relevant? Welchen Nutzen zieht das Unternehmen daraus? • Welches Geschäftsführungsmitglied ist als Mitglied des PLM-Stabs für PLM-Projekte verantwortlich? Aus Gründen der Ausgewogenheit und

5.12 Externe Dienstleister einbinden

185

besserer Kontrolle („check and balance“) sollte die PLM-Verantwortung nicht bei Qualitätsmanagement liegen! • Welches Budget ist heute und in den Folgejahren für PLM-Projekte minimal und maximal möglich? • Welche Stufen der Integration bieten sich an oder sind gesetzlich bzw. vom Kunden gefordert? Die Beantwortung dieser Fragen ist Managementaufgabe und beeinflusst die Projektdefinition ausschlaggebend. 5.12.3 Projektspezifikation

In der Praxis empfiehlt es sich die Phase „PLM-RequirementManagement“ stark auf die Unternehmens- und Funktionsziele zu konzentrieren. Die Phase „PLM-Requirement-Management“ beinhaltet den Managementauftrag zur PLM-Projektbildung und schließt die ausführliche Beschreibung der Leistungen ein, die erforderlich sind die Ziele eines Projektes zu erreichen. Die Durchführung eines Projektes ist ein Schritt zur „Realisierung der PLM-Vision“. Es ist zu empfehlen, die nachfolgenden Titel der Unterkapitel als einzeln zu bewertende Punkte in den Projektphasen zu definieren. In diesen Punkten sind der Anteil der Eigenleistung aus dem Unternehmen, inklusive der erforderlichen Schulungen, sowie die nötigen Fremdleistungen zu fixieren. Als Grundsteine für den Erfolg eines PLM-Projektes können folgende Grundaussagen gelten: • Projektmanagement gehört zu den gelebten Elementen des Unternehmens. • Rückhalt und Unterstützung des Projektes durch alle Unternehmensebenen. • Zielkonformität der Projektziele mit dem „Zielbaum“ des Unternehmens. • sichtbare Bereitstellung von Ressourcen für das Projekt mit Routineberichterstattung vor dem obersten Management • zeitlicher Rahmen und Ressourcen entsprechen der Machbarkeit und der Erreichbarkeit der gesteckten Ziele • Motivation der Mitarbeiter ist immer ein Spiegel der Einstellung des Managements. Bei allen Themen im Product Lifecycle Management, besonders aber der Integration der Unternehmensbereiche, ist in erster Linie das Management gefordert, die Ziele und Rahmenbedingungen zu fixieren. Da alle Organisationseinheiten durch das Product Lifecycle Management tangiert werden,

186

5 Leithefte zu PLM-Aspekten

sind alle Führungskräfte gefordert PLM-Projekte zu unterstützen, wobei Widerstände zu eliminieren sind. 5.12.4 Lastenhefterstellung

Die erste Aufgabe eines Projektteams nach der Projektdefinition und dem Projektstart ist die Erarbeitung eines Lastenheftes (Statement of Work). Dieses beinhaltet die Dokumentation aller Forderungen der Anwender einschließlich aller Randbedingungen, die das zukünftige System zu leisten hat. Darüber hinaus lassen sich der Inhalt und die Funktion eines Lastenheftes über die folgenden Leitsätze bestimmen: • Das Lastenheft stellt die Gesamtheit der Forderungen des Auftraggebers zu einem PLM-Projekt dar, bezogen auf ein Produkt, eine Produktgruppe oder die Produktpalette; es enthält unter anderem den Produktstrukturplan/die Produktstrukturpläne. • Die Forderungen sind quantifizierbar und vor allem prüfbar darzulegen, mit den Schwerpunkten bei Forderungen hinsichtlich zu erwartender Ergebnisse. • Im Lastenheft werden die heutigen und zukünftigen Funktionen und Aufgaben definiert und wie diese in den Geschäftsprozessen umgesetzt werden. • Es repräsentiert die wirtschaftlichen, technischen und organisatorischen Erwartungen des Auftraggebers bezüglich PLM. • Arbeitsmethodiken und die der dazugehörenden Beschreibungen der Prozesselemente werden in Arbeitsanweisungen oder Anwenderhandbüchern/Projekthandbüchern fixiert. • Arbeitsanweisungen, Anwenderhandbücher/Projekthandbücher und Lastenheft ergänzen einander. • Das PLM-Lastenheft ist Dokumentation der formalen Auseinandersetzung mit der Ist-Situation und der geplanten, in Stufen zu realisierenden, zukünftigen PLM-Vision als Teil des PLM-Manifests. • Das Lastenheft präsentiert keine Lösungswege in einer neuen Technik, sondern folgt den Denkmustern und Denkmodellen der bestehenden und/oder der geplanten Organisation des Auftraggebers. • Das Lastenheft ist die Grundlage für die Ausschreibung und Vergabe eines PLM-Projektes. • Das Lastenheft ist Bestandteil des Liefervertrages und die Basis der Pflichtenhefterstellung

5.12 Externe Dienstleister einbinden

187

Die Herausforderung bei der Erstellung des Lastenheftes ist, die analytische Durchdringung der heutigen Realität im derzeitigen Product Lifecycle Management, gepaart mit der Vision für zukünftige Notwendigkeiten aus sachlichen und wirtschaftlichen Aspekten. Es ist keine Lösungsdiskussion im Sinne der Organisation oder im Sinne einer IT-Lösung erforderlich. „Lastenträger und Inputgeber“ sind die Know-how-Träger des Unternehmens. Externe Unterstützung ist hier lediglich für die Analyse und Dokumentation durch einen Know-how starken Interviewer mit integrativer und koordinativer Kompetenz sowie ganzheitlicher und unternehmerischer Sichtweise möglich. 5.12.5 Ausschreibung

Ein großes Problem bei der Lastenhefterstellung ist der kapazitive Aufwand aus den Reihen der an sich schon überlasteten Führungskräfte und Know-how-Träger des Unternehmens. Hieraus resultiert häufig die Entscheidung sich auf das Know-how der Lieferanten zu verlassen und die eigenen Wünsche und Zielsetzungen mangelhaft zu beschreiben, nach dem Motto „Der Lieferant wird’s schon richten“. Allerdings besteht das Interesse des Lieferanten in der Regel nicht in der optimalen Problemlösung für den Kunden sondern im Verkauf seines Produktes. Soll ein Dienstleister engagiert werden, ist bei der Lastenhefterstellung unbedingt darauf zu achten, dass dieser Dienstleister keine Produkte im Sinne einer späteren IT-Lösung verkauft oder anderen vorzieht. Ein strikt neutral erstelltes Lastenheft ist auch der Garant für eine echte Vergleichbarkeit der eingeholten Angebote. Eine Ausschreibung basierend auf dem Lastenheft sollte nicht erfolgen bevor sich nicht der PLM-Stab Lösungen in der Praxis angesehen hat, die mit den eigenen Intentionen entsprechend des Lastenhefts weitestgehend übereinstimmen. Die Erfahrungen Anderer können an dieser Stelle von sehr hohem Wert sein. Es ist im Allgemeinen, vor dem Hintergrund der notwendigen Vergleiche, nicht zu empfehlen mehr als drei Bieter pro Ausschreibung zu einem Angebot aufzufordern (VDI 2219). In der Phase der Informationsgewinnung und Ausschreibung ist eine externe Dienstleistung eines dritten Dienstleistungsunternehmens mit entsprechendem Know-how häufig von Vorteil. Jedoch sollte seine Neutralität gegenüber dem Unternehmen und den angebotenen Systemen gewährleistet sein.

188

5 Leithefte zu PLM-Aspekten

5.12.6 Lieferantenauswahl

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

5.12 Externe Dienstleister einbinden

189

5.12.7 Pflichtenhefterstellung

In der Angebotsphase können aus Zeit- und Aufwandsgründen nicht alle Details endgültig geklärt werden. Grund dafür sind auch mehrere Bieter mit teilweise unterschiedlichen technischen Ansätzen und unterschiedlichen Strukturen. Das Pflichtenheft wird vom Auftraggeber und Auftragnehmer gemeinsam erarbeitet. Es beschreibt letztlich die Umsetzung des vom Auftraggeber vorgegebenen Lastenheftes mit den Mitteln des Auftragnehmers. Hier wird fixiert was wie realisiert wird und was der Anwender in den einzelnen Funktionsbereichen zur Lösung beizutragen hat. Es ist dringend zu empfehlen die Pflichtenhefterstellung gesondert zeitlich zu bewerten und eigene Kosten sowie Fremdkosten dafür einzuplanen. Zur Erstellung des Pflichtenheftes können folgende Leitsätzen herangezogen werden: • Das Pflichtenheft enthält die vom Auftragnehmer verbindlichen und gegengezeichneten Vorgaben, die bei der Implementierung und in der Testphase, geprüft und abgenommen werden. • Es beinhaltet die Beschreibung wie der Auftragnehmer die geforderte Leistung erbringen will. • Es enthält die Strukturpläne zu Produkten, Hardware und Software. • Es stellt den vollständigen Projektplan mit Kosten, Terminen und Ressourcen dar. • Das Pflichtenheft und die Erfüllung der dort beschriebenen Leistungen ist Vertragsbestandteil des Auftrages. • Es ist zumindest in einen rechtlichen, einen organisatorischen und einen technisch-fachlichen Teil gegliedert. • Bei Großprojekten werden Lasten- und Pflichtenheft notariell hinterlegt. Diese Aufgabe der Pflichtenhefterstellung kann nicht vollständig extern vergeben werden, obwohl entsprechende fachliche Unterstützung sehr wohl zukaufbar ist. So liegt in dem Zukauf externer Dienstleistung, im Sinne eines Coach für das eigene Team oder als Moderator der Pflichtenhefterstellung, unabhängig vom Lieferanten, die Chance die Bestlösung in der jeweiligen Auftraggeber bzw. Auftragnehmersituation zu finden. Die Neutralität eines externen Dienstleisters ist auch für die Phase wünschenswert, um ein optimales Ergebnis zu erreichen.

190

5 Leithefte zu PLM-Aspekten

5.12.8 Realisierung

Die Systemrealisierung erfolgt auf Basis des vereinbarten Pflichtenheftes weitgehend beim Auftragnehmer unabhängig vom Auftraggeber. Letzterer wird nur in kritischen Einzelsituationen zur Klärung spezifischer Fragen hinzugezogen. Besondere Vorsicht ist bei Abweichungen vom Pflichtenheft geboten. Jede Abweichung, das heißt jede noch so schön verpackte Änderung, sollte zu einer Ablehnung der Systemabnahme führen bzw. durch Nachlässe ausgeglichen werden. Jeder Auftragnehmer wird in diesem Fall versuchen, seine Nachlässe wieder zu beschaffen. Die Kostenklärung sollte also immer vor dem Einverständnis und der Unterschrift des Auftraggebers stehen. Dabei ist zu Beachten, dass jeder Zusatzwunsch der Anwender zusätzlich Geld kostet und deshalb zur Kostensicherheit vom Management gebremst werden sollte. Aus diesen Gründen leitet sich auch die Wichtigkeit des frühzeitigen Aufwandes für die Erstellung das Pflichtenheft ab. Am Ende der Realisierung, je nach Projekt auch bei Zwischenschritten, werden Abnahmen beim Auftragnehmer fällig. Aus Sicht des Auftraggebers sollte dies zumindest in monatlichen Schritten erfolgen um den Projektfortschritt zu erkennen. Bei diesen Abnahmen sind die Leistungen zu prüfen, die im Pflichtenheft, für den jeweiligen Schritt, vereinbart wurden, quasi als eine Art Vorabnahme. Zu diesem Zeitpunkt werden im Allgemeinen die Schulungsunterlagen oder ein spezifisches Schulungssystem für den Anwender bereitgestellt. Sollte dies aus technischen Gründen nicht möglich sein, so ist ein entsprechender Aufgabenpunkt bei der Implementierung vorzusehen. Beim Auftraggeber werden die Vorbereitungen zur Implementierung parallel zu den Arbeiten beim Auftragnehmer in Angriff genommen. Die Arbeiten konzentrieren sich dabei auf die Punkte: • Hardwarebeschaffung und Beschaffung von Softwarezusätzen, speziell Schnittstellensoftware für bestehende und bleibende Systeme oder Komponenten • Datenbereinigung von Nomenklatur, Kennungssysteme, lebende und „tote“ Artikel, Bestände etc. • Sicherung der Datenkonsistenz und Redundanzfreiheit • Datenvorbereitung und Datenerfassung für die Testimplementierung • Schulung der Anwender der Testimplementierung Gerade diese Arbeiten sind kapazitätsintensiv und werden gerne unterschätzt. Sie sind aber ausschlaggebend für eine schnelle Einführung.

5.12 Externe Dienstleister einbinden

191

5.12.9 Implementierung

Die so genannte „grüne Wiese“ ist so selten, dass man generell von der Implementierung in drei Stufen ausgehen sollte: • Testimplementierung in einer reinen Testumgebung • Parallellauf und Check der Betriebsfunktionalität und • Echtbetrieb unter Anleitung des Auftragnehmers Am Ende des Echtbetriebes unter Anleitung erfolgt die Übergabe an den Auftraggeber und die Inbetriebnahme unter der Verantwortung des Auftraggebers. Die Schulung der Anwender ist zu diesem Zeitpunkt abgeschlossen. Der Übergabezeitpunkt ist somit auch der Abnahmezeitpunkt, womit die letzte Marge, ohne Garantievorbehalt, fällig wird. Dies ist der Beginn der Garantiezeit. 5.12.10 Inbetriebnahme

Am Anfang steht die Übernahme des Systems in der Eigenverantwortung des Auftraggebers. Der Auftragnehmer sollte seine Aufgabe „zur vollen Kundenzufriedenheit“ erfüllt haben. In dieser Phase zeigt sich die Geduld und Leidensfähigkeit und Unterstützungsfähigkeit des Managements, denn ab diesem Augenblick treten alle Arten von kleinen und großen Problemen auf und kein Mitarbeiter des Lieferanten kann die Ursachen oder Folgen schnell und/oder unauffällig beseitigen. Die eigenen Mitarbeiter sind überarbeitet und erschöpft und trotz aller Schulung noch sehr unsicher und machen noch Fehler. Sollte sich die Situation anders darstellen hat man Glück gehabt oder sehr viel Zeit und Geld im Vorfeld investiert. In dieser Lage helfen nur die Geduld und das Vertrauen des Managements weiter. Je nach Projektdauer ist ein „Stillhalteabkommen“ über eine gewisse Zeitdauer, idealerweise über ein Quartal, ein probates Mittel Zeit für das Ausräumen von Problemen zu schaffen. Dies gilt auch für größere Teilschritte im Rahmen der Umsetzung der PLM-Vision. In dem genannten Quartal sollte auch die Aktualisierung der Dokumentationen zum Abschluss kommen, inklusive Benutzerhandbücher etc. Eine externe Vergabe von Aufgaben, außer bestimmte Dokumentationen ist, bezogen auf das neue System, nicht möglich oder zu empfehlen. Auf Grund des erhöhten Personalbedarfs in der Anlaufphase gilt es jedoch die Möglichkeit zu prüfen Aushilfen oder ehemalige Mitarbeiter für die Restlaufzeit oder Außerbetriebsetzung des Altsystems einzusetzen.

192

5 Leithefte zu PLM-Aspekten

5.12.11 Außerbetriebsetzung

Ein oft wenig beachteter Punkt bei der Einführung von neuen Informationssystemen oder Systematiken ist die Außerbetriebsetzung der Altsysteme. Altsysteme, im Sinne von Informationssystemen und auch manuellen Systemen, die durch die neue Systematik oder Systeme abgelöst werden, müssen gezielt zu einem bestimmten Termin außer Betrieb gesetzt werden, da sonst der Parallelbetrieb nie eingestellt wird. Das gilt besonders für KMU deren Organisation bisher weitestgehend in den Köpfen der Mitarbeiter oder in einzelnen Word oder Excel Dokumenten an den Arbeitsplätzen steckt. Auch dieses Thema ist letztlich eine Führungsaufgabe und eine Frage der Mitarbeitermotivation (siehe Abschnitt 5.13). Zu diesem Zeitpunkt ist die Durchführung eines Vollzugs-Review durch einen externen Dienstleister zu leisten. Generell ist zu sagen, dass alle Review und Coaching Funktionen, auch im Sinne der Neutralität in der Projektkommunikation, nach extern delegierbar sind. Normen und Standards

• VDI/VDE 2519: Vorgehensweisen bei der Erstellung von Lasten-/ Pflichtenheften In dieser Richtlinie wird die Vorgehensweise bei der Erstellung von Lasten- und Pflichtenheften für Materialflusssysteme und zugehörige Automatisierungssysteme erläutert. • VDI/VDE 3694: Lastenheft/Pflichtenheft für den Einsatz von Automatisierungssytemen

5.13 Mitarbeiter für PLM motivieren

193

5.13 Mitarbeiter für PLM motivieren Æ Projektmanagement

Die Einführung des PLM ist eine Änderung im Führungssystem in den betroffenen Bereichen. Je nach Umfang der Änderung kommt der Mitarbeiter nicht umhin, sich eine Meinung dazu zu bilden: wer potentiell stark davon betroffen ist, kann dem PLM nicht gleichgültig gegenüber stehen. Entweder wird das PLM und die Erstellung und Einführung seiner Systeme unterstützt oder aus Furcht vor möglichen negativen Konsequenzen behindert. Die tendenziell geringe Anzahl aktiver Unterstützer der PLMEinführung werden sich unterschiedlichen Widerständen gegenübersehen, während die große Anzahl der Betroffenen im Unternehmen durch ihre Ambivalenz sich eher passiv verhalten werden. Insgesamt haben PLM, die Erstellung von Integrationssystemen und deren Einführung in einem Unternehmen einen Einfluss auf die Motivation der Mitarbeiter, ob positiv oder negativ. Grundsätzlich enthalten die von PLM4KMU vorgeschlagenen Organisationselemente und Werkzeuge ein motivierendes Potential. Die explizite Forderung nach einer PLM-Vision ist ein guter, motivierend wirkender Aspekt, die Öffnung der Einführungsprojekte für möglichst viele Mitarbeiter des Unternehmens ist ein anderer. Auch das PLM im Allgemeinen kann Mitarbeiter aktivieren und einen zusätzlichen Motivationsschub darstellen. Allerdings ist so etwas durch persönliche Anlagen bestimmt und kann nicht erzwungen werden. Die vorgestellten Motivationsmodelle zeigen einige Wege auf, wie Frustration verhindert und Unterstützung gewonnen werden kann. Welches Modell das passende für eine Situation ist, kann pauschal nicht gesagt werden. Eine Pauschalaussage über die Motivation ist, dass gerade das Motivieren von Menschen im betrieblichen Umfeld hoch individuell ist und viel Aufmerksamkeit benötigt. Eines sollte angemerkt werden: das PLM als Führungsinstrument ist nicht von sich aus „gut“ oder „schlecht“. PLM ist eine Methode, ein Werkzeug, und jeder Angehörige eines Unternehmens kann eine eigene Meinung darüber haben, ob es als Werkzeug vorteilhaft ist oder nicht: Erst die Implementation im konkreten Fall lässt die Eignung des PLM für ein Unternehmen zeigen. Die Motivierung der Mitarbeiter ist ein Querschnittsthema bei PLM. Es betrifft jeden einzelnen PLM-Aspekt. Je stärker die Arbeitsweise eines Mitarbeiters betroffen ist, umso größer ist der Bedarf an Motivierung. Eine genaue Zuordnung erübrigt sich daher.

194

5 Leithefte zu PLM-Aspekten

5.13.1 Akzeptanzmanagement

Das vorliegende Leitheft behandelt das querschnittliche Thema Akzeptanzmanagement und „Motivierung“, es gibt Hilfestellung für die Einführung jeder Teilfunktion. Die Notwendigkeit der Behandlung des Themas „Motivation“ ist u. a. abhängig von der Intensität der Veränderungen, die mit der PLM-Einführung einhergehen. Die größten Veränderungen der Arbeitsweise werden bei der Einführung prozessorientierter Anwendungsfunktionen bewirkt, so dass für diesen Fall das Thema „Motivation“ einen hohen Stellenwert hat. 5.13.2 Wissenschaftliche Ansätze zur Mitarbeitermotivation

Das Motiv ist ein möglicher Beweggrund. Es ist ein innerer Zustand, der antreibt, aktiviert, bewegt, das Verhalten auf Ziele richtet und kanalisiert. Ein Motiv hat im Wesentlichen zwei Aspekte: • Den Energieaspekt Das Motiv aktiviert Handeln im Menschen, je nachdem wie stark es wirkt, setzt es verschieden intensiv Handlungen in Gang. • Den Zielaspekt Der Zielaspekt des Motivs richtet das Verhalten des Motivierten in eine bestimmte Richtung, das Verhalten strebt danach, das Bedürfnis, das dem Motiv zugrunde liegt, zu befriedigen. Das Motiv ist ein möglicher Beweggrund. Motivation ist hingegen, das tatsächlich aktuell wirkende Zusammenspiel der Motive, die ein konkretes Verhalten hervorrufen. Motivation ist also in diesem Sinne etwas, was sich nur innerhalb einer Person abspielt, und nichts, was von außen hinein gegeben werden kann. Die Tätigkeit, bei der mögliche Motive angeboten werden, um eine bestimmte Motivation bei einer Person zu erzielen, haben wir in Abgrenzung zu den o. g. Begriffen motivieren genannt. Bedürfnispyramide von Maslow

Maslow behauptet, dass die Bedürfnisse bzw. wirkende Motive streng hierarchisch wirken. Er ordnet die Bedürfnisse in eine Pyramide ein: erst, wenn die Bedürfnisse der untersten Stufe befriedigt sind, werden die Bedürfnisse einer höheren Stufe als Motive wirksam (s. Abb. 5-51). Auf die unterste Stufe seiner Pyramide stellt er die physiologischen Grundbedürfnisse, also Hunger, Schlaf, Durst etc. Die Bedürfnisse steigen stetig in ihrem Anspruch, bis sie schließlich im Bedürfnis der Selbstverwirklichung gipfeln. Das Bedürfnis „Selbstverwirklichung“ ist das einzige Bedürfnis,

5.13 Mitarbeiter für PLM motivieren

195

das nicht gestillt werden kann, die anderen sind so genannte Defizitbedürfnisse, d. h. sie können mit unterschiedlichem Aufwand gestillt werden. Diese Theorie wurde nicht ausdrücklich für das Arbeitsumfeld entwickelt, sondern sollte ein allgemeiner Erklärungsansatz für psychologische Probleme sein. Arbeitszufriedenheit (Herzberg)

Herzbergs Untersuchungen behandelten die Arbeitszufriedenheit, durch die letztlich Motivation entstehen soll. Seine Behauptung ist, dass es Umstände im Arbeitsumfeld gibt, die Arbeitszufriedenheit fördern, und dass es Umstände gibt, die Arbeitsunzufriedenheit fördern. Das Gegenteil von Arbeitsunzufriedenheit ist nicht Zufriedenheit mit dem Arbeitsplatz, sondern die Abwesenheit von Arbeitsunzufriedenheit. Wenn also vieles getan wird, das die Unzufriedenheit von Mitarbeitern senken soll, wird damit die Zufriedenheit nicht gehoben. Um diesen Umstand griffig auszudrücken, unterscheidet Herzberg zwischen Motivatoren und Hygienefaktoren.

Physiologische Bedürfnisse (Hunger, Durst, Atmung, Schlafen, ...) Abb. 5-51: Bedürfnispyramide von Maslow

Defizitmotive

Ich-Motive (Anerkennung, Status, Prestige, Achtung) Soziale Motive (Kontakt, Liebe, Zugehörigkeit) Sicherheitsmotive (Schutz, Vorsorge, Angstfreiheit)

Wachstumsmotive

Selbstverwirklichung

196

5 Leithefte zu PLM-Aspekten

Tabelle 1. Motivatoren und Hygienefaktoren nach Herzberg Motivatoren

Hygienefaktoren

Leistungserfolg Anerkennung Arbeitsinhalt Verantwortung Aufstieg Entfaltungsmöglichkeiten usw.

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

Die Motivatoren erhöhen die Arbeitszufriedenheit und somit die Motivation. Die Hygienefaktoren bekämpfen die Unzufriedenheit mit der Arbeitssituation und somit die Frustration. Herzberg schlägt folgende Aspekte vor, die motivieren oder frustrieren (s. Tabelle 1). Ein weiterer grundlegender Aspekt der Theorie Herzbergs ist, dass die Hygienefaktoren einen Mangel beseitigen wollen und somit nur begrenzt wirksam sind. Die Motivatoren sind ähnlich wie bei Maslow auch Wachstumsbedürfnisse bezogen, sie wirken also prinzipiell unbegrenzt. Nach den beiden gängigen Inhaltstheorien sollte noch auf die Unterscheidung von intrinsischer und extrinsischer Motivation hingewiesen werden. Unter extrinsischer Motivation werden die wirksamen Motive verstanden, die von außerhalb an eine Person herangetragen. Damit sind im wesentlichen Lob, Strafe und Belohnung gemeint, im Sinne eines Handels – wenn Du Dich so verhältst, bekommst du dies und jenes. Intrinsische Motivation bedeutet alles das, was rein aus der Person kommt: Spaß an der Arbeit, Pflichtbewusstsein, Interesse an einem Arbeitsinhalt. Extrinsische Motivation wirkt in der Regel über die Befriedigung eines Defizitmotivs, während intrinsische Motivation in der Regel die Befriedigung eines Wachstumsbedürfnisses darstellt. Anerkennung als Motiv, das auch prinzipiell nicht stillbar ist, muss deshalb von mal zu mal gesteigert werden. Deshalb ist es erstrebenswert, die intrinsische Motivation der Mitarbeiter anzusprechen. 5.13.3 PLM-Erfolg durch Mitarbeiterakzeptanz

Die Einführung von PLM und Integrationssystemen kann je nach Intensität mit einer Reorganisation des Unternehmens verglichen werden. Reorganisationen sind im unternehmerischen Umfeld immer mit Risiken verbunden und können Unmut hervorrufen, wodurch der Erfolg dieser Reorganisation wiederum bedroht wird. Der Anfang einer solchen Veränderung ist sehr wichtig für den späteren Erfolg der Reorganisation. In Abb. 5-52 ist eine idealisierte Übersicht über die möglichen Reaktionen auf eine grundlegen-

5.13 Mitarbeiter für PLM motivieren

197

de Reorganisation skizziert. Ein PLM-Projekt, das tatsächlich eine grundlegende Reorganisation darstellt, wird ähnlich aufgenommen werden. Die Ausgangssituation ist dadurch gekennzeichnet, dass man mit ihr vertraut ist und sich in der gegenwärtigen Organisationsform auskennt. Auch wenn Reibungspunkte auftreten, so gibt es individuelle informelle Strategien, damit umzugehen. Die Notwendigkeit, die gegenwärtige Situation zu ändern, wird so nicht gesehen, oder sie wird gesehen, aber für den persönlichen Arbeitsplatz als nicht dringlich angesehen. Die Bekanntgabe, dass PLM eingeführt werden soll und somit ein tiefer Eingriff in die tägliche Arbeitsweise vorgenommen werden soll, wird unterschiedlich aufgenommen: Eine Reaktion wäre die Unterstützung der Einführung, da • Product Lifecycle Management als Chance erkannt wird, gegenwärtige Missstände zu beheben • im Rahmen eines Einführungsprojekts außergewöhnliche Aufgaben anfallen und somit außergewöhnliche Leistungen erbracht werden können. Unterstützung wird ein Einführungsprojekt vor allem von Mitarbeitern erfahren, die durch Leistungen motiviert werden, und deren Sicherheitsbedürfnis entweder nicht so stark ausgeprägt oder befriedigt ist. Die potentiell größte Gruppe wird die der Unentschlossenen sein. Sie können PLM aufgrund fehlenden Wissens nicht einordnen, oder sie erkennen nicht die Notwendigkeit, etwas ändern zu müssen. Sie können aber das PLM auch als ein Mittel ansehen, mit dem etwas bezweckt werden soll, und unschlüssig sein, welche zukünftige Situation herbeigeführt werden soll. Die dritte Gruppe empfindet Ablehnung gegenüber dem Vorhaben, PLM einzuführen. Sie sehen ihre bekannte Umgebung bedroht oder fürchten Überforderung. Ihr Sicherheitsbedürfnis ist stark ausgeprägt. PLM ist eine Form der Rationalisierung: wird dieser Aspekt in den Vordergrund gestellt, so kann zusätzlich die Furcht um den eigenen Arbeitsplatz zur Ablehnung gegenüber PLM führen. Aber auch weniger grundlegende Bedrohungen können von PLM-Systemen ausgehen: so zwingen Zugriffsrechte, Nummernvergabesysteme und Funktionen wie Vaulting den Benutzer Arbeitsweisen auf, die er lieber selbst wählen und beeinflussen würde. Diese Fremdbestimmung und die Aussicht, keinen Einfluss auf das Ergebnis der PLM-Einführung zu haben, läuft dem Bedürfnis entgegen, als eigenständige Person mit freiem Willen zu wirken.

198

5 Leithefte zu PLM-Aspekten Die Ausgangssituation wird allgemein anerkannt, die Mitarbeiter kennen sich mit der Situation und der gegenwärtigen Organisation aus, einige Unannehmlichkeiten werden in Kauf genommen und informell umgangen. Die Notwendigkeit einer Änderung wird nicht unbedingt allgemein gesehen .

Ausgangssituation

Mitarbeiter können PLM nicht einordnen, sei es aus fachlicher Unkenntnis oder Zweifel über die Aussichten.

Bekanntgabe Einführung PLM

Unentschlossenheit Beeinfl

Beeinfl

Ein Teil der Mitarbeiter fühlt sich durch die Einführung von PLM bedroht, sie fürchten: Einschränkungen persönlicher Freiheiten, Überlastung, negative Veränderung des Umfeldes, Verlust des Arbeitsplatzes.

ussung

ussung

Die Gruppe der Unentschlossenen wird durch Fakten, Gerüchte und Beeinflussungsversuche im Fortschritt des Einführungsprozesses eine Meinung zum PLM bilden. Ein Teil der Mitarbeiter sieht im PLM und der Einführung Chancen, Leistung zu erbringen

Ablehnung Au

fkl

g, an Zw nung loh Be

äru ng

Aufklärung

Zeit

Durch Kundenforderungen oder eigene Überlegungen wird PLM als mögliches Mittel der Reorganisation gesehen. Es wird mitgeteilt, dass ein PLM installiert wird. Die konkreten Ausführungen bleiben vage.

Fachpromotor

Machtpromotor

Widerstand gegen PLM-Einführung

Zielsituation

Abb. 5-52: Einführungsprozess

Unterstützung

5.13 Mitarbeiter für PLM motivieren

199

Eine Kernaussage der Grafik (Abb. 5-52) ist, dass die Unentschlossenen über kurz oder lang entweder zu Gegnern oder zu Befürwortern der PLMEinführung werden. Dabei muss die PLM-Einführung aber als grundlegende Veränderung der betrieblichen Abläufe wahrgenommen werden. Einer veränderten Form der Nummernvergabe kann man noch gleichgültig gegenüberstehen, je mehr aber die Änderungen die tägliche Arbeit beeinflussen, umso mehr polarisiert dies und zwingt zur Stellungnahme. Die Unentschlossenen werden dabei von zwei Seiten beeinflusst: sowohl durch die Befürworter der Änderung wie von deren Gegnern. Hierbei hilft den Gegnern sehr, wenn die Maßnahmen der PLM-Einführung im Ungefähren bleiben. Barrieren und Widerstand

Bei der Ablehnung von Neuerungen werden zwei unterschiedliche Barrieren unterschieden: die Wissensbarrieren und die Willensbarrieren. Wissensbarrieren beruhen auf Unverständnis der PLM-Einführung, Willensbarrieren in der Regel auf der Furcht vor Verlust von Einfluss oder Sicherheit. Beide Barrieren führen zu Widerstand, d. h. in diesem Falle aktiver Ablehnung der PLM-Einführung. Zur Verringerung des Widerstands werden sogenannte „Promotoren“ eingesetzt, und zwar Fachpromotoren, um die Wissensbarrieren abzubauen, und Machtpromotoren, um die Willensbarrieren abzubauen. Der Fachpromotor klärt über die fachlichen Aspekte der PLMEinführung auf. Er kann Ängste dadurch abbauen, indem er Irrtümer aufdeckt und die Vorteile des PLM für den einzelnen darstellt. Er muss das eventuell in Gerüchten übertriebene Verhältnis Aufwand zu Nutzen geraderücken und somit die Akzeptanz durch Vernunft fördern. Der Machtpromotor muss mit formaler Macht ausgestattet sein, um Widerstand überwinden zu können. Machtpromotoren sind weisungsbefugt und können mittels Ressourcenverteilung Einfluss nehmen. Ihre Funktion sollte sich dabei nicht auf die alleinige Nutzung von Zwangsmaßnahmen stützen: ihre demonstrative Unterstützung der PLM-Einführung wertet diese durch die Stellung des Machtpromotors wiederum. Wer kann die Aufgabe der Promotoren übernehmen? Der Fachpromotor wird sicherlich aus dem Umfeld PLM-Stab oder den ersten Teilprojekten kommen müssen. Der Kreis an ausreichend informierten Personen wird zu diesem frühen Zeitpunkt der Einführung noch überschaubar sein. Der Machtpromotor muss über ausreichende formale Durchsetzungsfähigkeit verfügen, so dass hier nur jemand infrage kommt, der in der Unternehmenshierarchie ausreichend hochgestellt ist.

200

5 Leithefte zu PLM-Aspekten

Beiträge des Machtpromotors Freigabe von Ressourcen

Zielbildung

Sicherung des strategischen Fit

Überwindung von Opposition

Initiative Gemeinsame Beiträge (Prozesspromotion) Zerlegung des Gesamtprozesses in Teilprozesse, Bestimmung von Reihenfolgen und Terminen

Test auf Betroffensein, Problemdefinition

Zusammenführung der Teilprozesse, Zieldetailierung, Konfliktmanagement

Motivation, Erklärung, Instruktion, Werbung

Initiative Eigentliche Problemlösung

Alternativgenerierung

Endgültige Realisierung

Beiträge des Fachpromotors Prozessablauf

Abb. 5-53: Aufgaben der Promotoren im Zeitablauf

In der Abb. 5-53 wurden die Aufgaben der Promotoren im zeitlichen Ablauf eines Einführungsprojekts zusammengefasst. Der Begriff der Prozesspromotion taucht hier zusätzlich auf: teilweise wird in der Literatur empfohlen, einen zusätzlichen Prozesspromotor zu benennen, auch Kommunikationspromotoren wurden erdacht. Belasten die genannten Aufgaben die Fach- und Machtpromotoren zu sehr, ist diese Hilfestellung sinnvoll. Der Prozess der PLM-Einführung sollte aber auch von beiden gemeinsam vorangetrieben werden können. Die Tabelle 2 zeigt Beispiele für Verhaltensweisen des Widerstandes nach Schirmer (Schirmer 2000)

5.13 Mitarbeiter für PLM motivieren

201

Tabelle 2. Merkmale destruktiven Widerstands Verhaltensweise typische Formulierung mangelnde Kompromissbereitschaft Festhalten an Totalforderungen Ausweichen auf andere Begründungen nach dem Ausräumen bisheriger Kritikpunkte wiederholte Rückkehr zu bereits verlassenen Argumentationspositionen

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

„Wir müssen noch einmal auf ... zu sprechen kommen“

Feststellen betroffener Organisationseinheiten

Im Vorfeld der Einführung von PLM oder einzelner PLM-Funktionen ist eine wesentliche Information, welche Organisationseinheiten durch die PLM-Funktion beeinflusst werden. Eine Beeinflussungsmatrix kann helfen, kritische Bereiche im Vorfeld zu erkennen. Die Matrix stellt die konkreten PLM-Funktionen den Organisationseinheiten gegenüber (s. Abb. 5-54). Es wird getrennt erfasst, wie stark die Belastung durch Systemeingaben und wie groß die Entlastung ist, die die PLM-Funktionen den Organisationseinheiten bringen. Neben den absoluten Werten der Be- und Entlastung kann das Input-Output-Verhältnis ermittelt werden. Ein Wert von 1,0 bedeutet, dass die Integrationssysteme für die konkrete Organisationseinheit neutral wirken, d. h. eine Entlastung wird durch die zusätzliche Belastung kompensiert. Werte nahe Null sind kritisch: die Systeme wirken ausschließlich belastend. Erstrebenswert sind Werte größer 1, da hier die Organisationseinheit entlastet wird. Die Verhältniszahl lässt auch voraussagen, ob einzelne Organisationseinheiten anderen gegenüber benachteiligt sind: Streuen die Input-OutputVerhältnisse sehr stark? Dann kann es sein, dass die Organisationseinheiten mit sehr kleiner Verhältniszahl keine Akzeptanz für die Systeme zeigen und sie wenig bis gar nicht nutzen. Die Systeme sollten dann angepasst werden, so dass die Verhältniszahl der Organisationseinheit steigt: entweder durch Verlagerung der Eingaben in andere Organisationseinheiten oder durch Steigerung des Nutzens.

202

5 Leithefte zu PLM-Aspekten

Belastungsmatrix Entwickl. & Konstr.

Arbeitsvorbereitung

Einkauf

Techn. Vertrieb

Personal

Nummernvergabe

9

3

6

0

3

3

44%

Variantenverwalt.

9

0

1

3

0

6

35%

Versionenverwalt.

9

0

6

3

0

3

39%

Zugriffsrechte

1

0

0

0

3

0

7%

Konfiguration

6

3

3

6

0

1

35%

Input

34

6

16

12

6

13

Maximum

45

45

45

45

45

45

76%

13%

36%

27%

13%

29%

PLM Funktion

Belastungsgrad

Qualitätssi- Belastungscherung grad

Nutzungsmatrix Nummernvergabe

9

9

3

3

0

9

61%

Variantenverwalt.

9

3

6

3

0

0

39%

Versionenverwalt.

9

3

3

3

0

0

33%

Zugriffsrechte

6

3

6

1

0

1

31%

Konfiguration

0

6

9

9

0

3

50%

Input

33

24

27

19

0

13

45

45

45

45

45

45

Belastungsgrad

73%

53%

60%

42%

0%

29%

Input/ Output

0,97

4,00

1,69

1,58

0,00

1,00

3

6

Maximum

Skala: Häufigkeiten

0

1

Nie

Selten

9

Monatlich Wöchentlich Täglich

Abb. 5-54: Beispiel einer Belastungsmatrix Wirksame PLM-Vision

Die PLM-Vision ist im Vorgehensmodell als der Rahmen eingezeichnet, in dem sich das Einführungsprojekt bewegt. Sie soll als Klammer wirken und so das PLM-Projekt und seine Maßnahmen zusammenhalten und auf ein visionäres Fernziel koordinieren. Die PLM-Vision sollte früh im Ablauf des evolutionären Vorgehensmodells gefunden werden, damit sie eine Leuchtturmfunktion entfalten kann. Als spezielle Vision zum Thema PLM wird ein Mindestmaß an Kenntnis des Themas voraussetzt, wodurch einiger Vorlauf zu durchlaufen ist, bevor eine Vision formuliert werden kann. Die Vision ist allerdings nicht dogmatisch: bei besseren Wissen kann sie geändert werden. Allerdings sollte dies nicht zu oft geschehen, da sonst der Eindruck der Beliebigkeit der Vision entstehen kann. Die motivierenden Aspekte der PLM-Vision sind:

5.13 Mitarbeiter für PLM motivieren

203

• die (mögliche) Mitarbeit bei der Entwicklung der PLM-Vision • Jeder soll PLM-Vision verstehen können und so Erfolge erkennen und beurteilen können: Da sich die PLM-Vision an jeden richtet und Grundlegendes beschreiben will, wird jeder einzelne über die Integrationssysteme informiert. • Das außergewöhnliche Fernziel ist ein Leistungsanreiz • Vision schafft Sicherheit in schnelllebiger Umwelt: Als allgemein lösungsneutral formuliertes Fernziel stellt sie einen Maßstab für neue Entwicklungen dar. • PLM-Vision als „Gretchenfrage“: Zur Vision muss der Mitarbeiter Stellung beziehen. Je einfacher, sinnvoller, anregender und herausfordernder die Vision ist, desto größere unternehmerische Veränderungen bewirkt sie. Je mehr sie das Herz und den Verstand der Führungskräfte anspricht und in der Unternehmenskultur verankert ist, desto wirksamer findet sie ihren Niederschlag in der Unternehmenspolitik, in den Strategien und Direktiven und desto effizienter wird deren Umsetzung. Die PLM-Vision ist der Vorschlag eines Motivs, sie soll Energien wecken und eine Richtung aufzeigen.

6 Technische und methodische Grundlagen

Das folgende Kapitel beinhaltet Themen zu technischen und methodischen Grundlagen, die im Zusammenhang mit Informationssystemen, Infrastruktur oder dem Vorgehen bei der Umsetzung des PLM-Paradigmas stehen. Das Kapitel ist als Nachschlagewerk zu sehen, das zum einen wichtige Punkte aus dem Kapitel 5 an dieser Stelle bereit stellt und das zum anderen weitergehende Hintergrundinformationen zu Themen liefert, die im Rahmen einer individuellen Vorgehensweise für den Leser von Interesse sein können.

6.1

Produktkonfiguration

Für das Produkt, seine Verwaltung und Darstellung sind im Product Lifecycle Management die Begriffe und die damit verbundenen Konzepte der Versionen, Gültigkeiten, Varianten, Sichten und Konfigurationen von großer Bedeutung. Um den Gebrauch des Buches zu erleichtern, werden diese Begriffe aus den verschiedenen Leitheften an dieser Stelle zusammengefasst dargestellt. 6.1.1

Versionen

Im Sprachgebrauch des Product Lifecycle Management sind Versionen zeitlich nacheinander entstehende Arbeitsergebnisse bzw. Entwicklungsstufen einer Aufgabe oder eines Erzeugnisses. Eine neuere Version ersetzt meistens eine ältere Version, geht durch Veränderung oder Weiterentwicklung aus dieser hervor und stellt in der Regel eine Verbesserung dar. Im täglichen Gebrauch wird der Begriff „Version“ Synonym mit den Begriffen Änderungsstand, Revison oder Iteration verwendet, wobei dies besondere Fälle der Versionierung sind. Eine Revison ist eine Versionierung mit fortlaufend steigender Versionsnummer und bei einer Iteration werden in der Regel nur minimale Änderungen durchgeführt. Häufig wird auch eine Variante eines Produktes fälschlich als „Version“ bezeichnet.

206

6 Technische und methodische Grundlagen

Eine Version ist ein definierter Änderungszustand während des Lebenszyklus eines Produktes, einer Produktkomponente oder eines Dokumentes, der mit einer Versionsnummer oder mit einem Index eindeutig identifiziert wird. Versionen sind an einen Zeitstrahl gebunden, wodurch die zeitliche Abfolge von Versionen, die man als Versions- oder Entwicklungshistorie bezeichnet, festgelegt ist. Es bestehen zwischen Versionen immer „Vorgänger-Nachfolger“ Beziehungen. Zu einem bestimmten Zeitpunkt kann sich allerdings die Entwicklungshistorie aufspalten. Damit wird ein neuer Entwicklungspfad eröffnet. Typischerweise entstehen in diesem Fall aus einer Vorgängerversion zwei Nachfolgeversionen. Im Zuge dessen kann es auch vorkommen, dass zwei Entwicklungspfade wieder zusammengeführt werden. Versionen können an Gültigkeiten gebunden sein, die eine Aussage darüber treffen, welche Randbedingungen gegeben sein müssen oder sollen, wie z. B. Zeitraum der Gültigkeit oder eine Produktionsstandort. Veröffentlichungen von Versionen werden immer dann notwendig, wenn beispielsweise andere am Entwicklungsprojekt Beteiligte einen Stand begutachten sollen oder ein Synchronisationszeitpunkt erreicht wird. Einzelne Versionen können verschiedene Zustände durchlaufen, wie z. B. die „Freigabe für Produktion“ (Schichtel 2001). In Produktstrukturen ist das Kriterium „Form-Fit-Function“ ausschlaggebend für die Versionierung von übergeordneten Baugruppen, um entscheiden zu können, ob diese ebenfalls überarbeitet und eine neue Versionsnummer erhalten muss. Es ist sehr wichtig zu beachten, dass sich „Form“ und „Function“ auf die Produktspezifikation beziehen, während sich „Fit“ auf die Abmaße und Toleranzen der Zeichnung bezieht. Eine neue Versionsnummer der übergeordneten Baugruppe wird erst dann notwendig, wenn mindestens eine der folgenden Fragen mit Nein beantwortet wird (Eigner u. Stelzer 2001): • Form Entsprechen Erscheinungsbild und Aussehen der neuen Version des Bauteils bezogen auf die alte Version der Produktspezifikation? • Fit Passt die neue Version des Bauteils bezüglich Abmaße und Toleranzen zu ihren benachbarten Teilen? • Function Erfüllt die neue Version des Bauteils bezogen auf die alte Version alle funktionellen Anforderungen und Produktspezifikationen? Soll der Änderungsstand zweistufig dokumentiert werden, wird zwischen Haupt- und Nebenänderungen (Major und Minor Version) unterschieden.

6.1 Produktkonfiguration 6.1.2

207

Gültigkeiten

Gültigkeit, auch Effektivität (engl.: effectivity) genannt, ist eine Angabe, die Änderungen oder die Verwendung von Varianten (und Versionen) in einem konkreten Produkt/Erzeugnis für einen bestimmten Zeitbereich oder Anwendungsfall erlaubt bzw. einschränkt. Gültigkeiten können durch einen Zeitpunkt oder Zeitraum, ein Ereignis oder einen speziellen Produktnummernbereich (Seriennummernbereiche, Losnummernbereiche, Fertigungslokalitäten) definiert werden. Gültigkeiten sollten bei allen Versionen, Revisionen, Varianten und Alternativen angegeben und im integrierten Produktmodell vermerkt werden. Beispiele für Gültigkeiten sind: • Versionen und Revisionen V1 ist gültig vom 01.01.03 bis zum 31.12.03, V2 ist gültig ab 01.01.04. (Zeitraum). V1 ist gültig bei Los 1 – 450, V2 ist gültig von Los 451 (bezogen auf Losnummernbereich). • Varianten Variante A ist gültig für Europa, Variante B ist gültig für USA. 6.1.3

Varianten

Nach DIN 199 (DIN 199-4) sind Varianten „Gegenstände ähnlicher Form und/oder mit einem in der Regel hohen Anteil an identischen Baugruppen“. Die Varianten eines Produktes sind zeitlich parallel existierende, vergleichbare Ausprägungen ein und desselben Erzeugnisses bzw. Ergebnisses, die sich anhand definierter Merkmalen voneinander unterscheiden. Eine Alternative ist eine Variante, die von einem konkreten Anwendungsfall abhängt (Schichtel 2001). Varianten werden durch ein oder mehrere Merkmale, die mit einem Wert belegt sind, charakterisiert. Anstatt „Merkmal/Merkmalausprägung“ werden auch „Merkmalskategorie/ Merkmal“, in der internationalen Produktdatennorm STEP „Specification Category/Specification“ oder in einigen Integrationssystemenen „Option/ Option Value“ verwendet. Produkte oder Produktkomponenten werden zunächst variantenunabhängig entwickelt. Erst wenn eine Unterscheidung zwingend notwendig wird, findet eine Abspaltung eines Entwicklungspfades statt. Man kann also eine Variante immer einem Entwicklungspfad zuordnen. Daher besteht immer ein enger Zusammenhang zwischen Variante und Version. Oft werden in der täglichen Praxis Lösungen, d. h. Versionen selbst als Variante bezeichnet. Man sollte sehr genau zwischen Variante im Sinn der

208

6 Technische und methodische Grundlagen

Aufgabenstellung und im Sinn einer Lösung zu einer Aufgabenstellung unterscheiden (Schichtel 2001). Produkte bestehen häufig auf der Teile- und Baugruppenebene aus mehreren Varianten. Dies ist für die Verwaltung und Disposition von erheblicher Bedeutung, da die Anzahl möglicher Varianten sehr hoch sein kann. Es lassen sich zwei Arten von Varianten unterscheiden. Die Strukturvariante entsteht dadurch, dass in einer Stückliste verschiedene Positionen variieren können. So kann z. B. in einer Stückliste „Antrieb“ entweder ein „Motor“ A oder B vorkommen. Um diesen Sachverhalt eindeutig zu beschreiben, müssten zwei Stücklisten nur für die unterschiedlichen Motoren existieren. Die zweite Variantenart sind die Teilevarianten, die sich auf ein Teil beziehen, das in verschiedenen Ausprägungen auftreten kann, wie z. B. ein Uhrenarmband, das sich nur in der Farbe oder im aufgedruckten Design unterscheidet. Dieses Teil wird eindeutig über die Vergabe einer Sachnummer für jede einzelne Ausprägung identifiziert. Die Problematik Produktvarianten strukturell darzustellen wird mit Hilfe der Variantenstückliste gelöst. DIN 199-4 definiert die Variantenstückliste folgendermaßen: Die Variantenstückliste ist eine Zusammenfassung mehrerer Stücklisten auf einem Vordruck, um verschiedene Gegenstände mit einem in der Regel hohen Anteil identischer Bestandteile gemeinsam aufführen zu können. Klassifizierung von Varianten könnten sein (keine abgeschlossene Liste): • Landesspezifische Variante linksgelenkte Autos für den deutschen Markt, rechtsgelenkte Autos für den britischen Markt. • Kundenspezifische Variante z. B. Farbe des Autos oder die Innenausstattung wie z. B. Ledersitze, Stoffsitze, Velourssitze • Gesetzesspezifische Variante H4 Lampen sind für PKW mit 60/55 Watt und für LKW mit 75/70 Watt Leistung ausgestattet Beispiele für weitere Arten von Varianten sind: • Form der Karosserie Cabrio, Limousine, Coupé • Motorisierung Benzin-, Diesel-, Erdgas-, Elektro-, Wasserstoff-, Hybrid-Antrieb • Antriebsart Allrad, Front-, Hecktrieb

6.1 Produktkonfiguration 6.1.4

209

Sichten

Abhängig von der Produktphase oder der Disziplin kann ein Produkt unterschiedlich strukturiert werden. Sichten ermöglichen die Darstellung unterschiedlicher Strukturen des gleichen Produktes zur zielgerichteten Unterstützung von bestimmten Prozessen oder Aufgaben. Basis für die Erzeugung einer Sicht ist dabei eine Gesamtstruktur in der die Zusammenhänge im jeweiligen Kontext der Sicht beschrieben sind. Zur Darstellung einer bestimmten Sicht auf diese Struktur werden diese Abhängigkeiten im Kontext der Sicht herangezogen. Sichten können beispielsweise entsprechend der verschiedenen Disziplinen Mechanik, Elektrik, Hydraulik etc. in der Entwicklung eines Produktes gebildet werden. Im Produktlebenszyklus können die verschieden Phasen ebenfalls verschiedene Sichten auf das Produkt erfordern. Typische Phasen mit der jeweiligen Sicht sind hier: • • • • • • •

Entwicklung (as developed) Angebotserstellung (as bid) Konstruktion (as designed) Fertigung (as planned) Montage (as built) Vertrieb (as shipped) Betrieb und Service (as maintained)

Da das Verwalten von Sichten sehr komplex ist und somit ihre Pflege im Integrationssystem entsprechend aufwendig ist, sollten nur die notwendigsten Sichten eingeführt werden. Die Strukturbeziehungen eines Strukturelementes multiplizieren sich mit der Anzahl der verwendeten Sichten. 6.1.5

Konfiguration

Die DIN ISO 10007 definiert den Begriff Konfiguration als „die funktionellen und physischen Merkmale eines Produkts, wie sie in seinen technischen Dokumenten beschrieben und im Produkt selbst umgesetzt sind.“ Die Konfiguration eines Produktes definiert damit aus der Fülle der möglichen Produktvarianten und Bauteilversionen ein Produkt in einer konkreten Zusammenstellung zu einem bestimmten Zeitpunkt. Bei der Produktspezifikation legt der Kunde für jedes unabhängige Merkmal eine Ausprägung und damit auch die gewünschte Produktvariante fest. Ist die Produktspezifikation vollständig erfolgt, so kann die Variante Produktstruktur ausgewertet werde, in dem jede abstrakte Komponente durch die jeweils richtige konkrete Komponente ersetzt wird.

210

6 Technische und methodische Grundlagen

Aus der Sicht der Geschäftsbeziehung zwischen Anbieter und Kunde stellen die Spezifikation und die Konfiguration eines Produktes die Bestandteile des Dialoges zwischen diesen beiden dar, um die Grundlage des Geschäftes zu legen. Die Spezifikation eines Produktes liegt also in der Verantwortung des Kunden, dessen Konfiguration in der des Anbieters. Vor allem bei lange im Markt befindlichen Produkten oder solchen mit langer Nutzungsdauer kommt bei der Konfiguration noch ein zeitlicher Aspekt hinzu. In diesen Fällen definiert die Konfiguration, die zu einem bestimmten Zeitpunkt bzw. während einer Zeitspanne verbauten Komponenten in diesem Produkt.

6.2

Standardteile und Baukästen

Zur Einsparung von Kosten versuchen Unternehmen die Anzahl an unterschiedlichen Teilen in der Produktpalette möglichst gering zu halten. Aus diesem Grund wird versucht nach Möglichkeit auf standardisierte Teile des Unternehmens oder Normteile bei der Entwicklung eines Produktes zurückzugreifen. Eine weitere Option zur Reduzierung der Teilezahl bietet die Vorgehensweise ein Produkt aus einzelnen Modulen zusammenzusetzen. Damit diese Möglichkeiten effizient eingesetzt werden können ist es jedoch notwendig nach Teilen anhand von bestimmten Attributen und Merkmalen suchen zu können, um ein passendes Teil schnell zu finden. Für Aufgabe der Verwaltung und des Auffindens sind Integrationssysteme bestens geeignet sofern Baukästen, Standard- bzw. Normteile mit Hilfe geeigneter Klassifikationssystem, beispielsweise nach DIN-4000 erfasst sind. Ein Vorteil der Verwendung von Standard-, Normteilen und Baukästen ist, dass bei der Bearbeitung eines Auftrages entsprechende Dokumente, wie CAD-Dateien, Zeichnungen oder Arbeitspläne, durch die Vervollständigung weniger Parameter generieren lassen bzw. sich mit geringem Aufwand in eine konstruktive Lösung integrieren lassen. Allerdings ist es dafür erforderlich, dass diese Dokumentvorlagen bzw. Templates fehlerfrei vorliegen und intensiv auf ihre Verwendung und die Wechselwirkungen der Bauteile in allen möglichen Konfigurationen geprüft wurden. Sind jedoch Änderungen an einem Standardteil oder Baukasten notwendig geworden, muss wiederum bei der Durchführung der Änderung die Auswirkung auf alle Produktvarianten erneut einer ausführlichen Untersuchung unterzogen werden.

6.2 Standardteile und Baukästen 6.2.1

211

Standard- und Normteile

Normteilebibliotheken mit parametrisierten CAD-Modellen werden inzwischen von CAD-Herstellern bzw. Dienstleistern in großem Umfang angeboten. Um die CAD-Modelle jedoch über ein PDM- oder Dokumentenmanagementsystem verfügbar zu machen, müssen diese Normteile noch erfasst werden und an das Klassifikationsschema des Unternehmens angepasst werden (Zwicker 1999). Standardteile werden in der Regel vom Unternehmen selbst erstellt und gepflegt und sind in Form von Wiederholteilbibliotheken für die Konstrukteure verfügbar. Änderungen an diesen Standardteilen erfordern jedoch einen erhöhten Pflegeaufwand, da alle Produktkonfigurationen in den das Bauteil verwendet wird, auf die Verträglichkeit der Änderung hin überprüft werden müssen. Hierfür ist eine Systemunterstützung für die Erstellung von Verwendungsnachweise des Bauteils sinnvoll. Durch die Möglichkeit parametrische CAD-Modelle zu erstellen, können Standardteile über die Eingabe von Parameterwerten, z. B. Bemaßungslängen, an die konstruktiven Anforderungen angepasst werden. Sollen die Parameter des CAD-Modells ebenfalls durch das PDM- oder Dokumentenmanagementsystem gesetzt werden können, ist hierfür eine tiefgehende Integration des CAD-Systems notwenig, wenn beispielsweise eine Schraube einer Normreihe mit einem bestimmten Durchmesser und Länge verwendet werden soll. Viele Lieferanten von Standard- oder Normteilen sind schon dazu übergegangen ihre Produktkataloge in digitaler Form über das Internet bereit zu stellen, so dass CAD-Modelle und Datenblätter online abrufbar sind. Integrationssysteme können über entsprechende Schnittstellen diese Informationen zur Verfügung stellen bzw. die jeweiligen Quellen referenzieren. 6.2.2

Baukästen

Ein Baukasten ist nach (Beitz et al. 2001) eine Maschine, Baugruppe oder Einzelteile, die als Bausteine mit oft unterschiedlichen Lösungen durch Kombination entstehen und verschiedene Gesamtfunktionen erfüllen. Die Gesamtfunktion eines Baukastensystems setzt sich dabei aus den verschiedenen Funktionen der einzelnen Bausteine zusammen (s. Abb. 6-1). Durch eine Parametrisierung der Bausteine lassen sich Baureihen mit unterschiedlichen Größenstufungen definieren, die über diese Parameter konfigurierbar sind. Die Verwaltung der Strukturen dieser Baukästen werden als variante Produktstrukturen geführt (Schöttner 1999).

212

6 Technische und methodische Grundlagen

Baukastensystem

Mischsystem

Gesamtfunktion Varianten

Grundfunktionen

Hilfsfunktionen

Sonderfunktionen

Anpassfunktionen

grundlegend, immer wiederkehrend, allgemein

verbindend, anschließend

besonders, ergänzend, erweiternd

nicht genau in allen Teilen festlegbar

Grundbaustein

Hilfsbaustein

Sonderbaustein

Anpassbaustein

Auftragsspezifische Funktionen nicht vorhersehbar

Nichtbaustein

Ausführung Varianten

Abb. 6-1: Funktions- und Bausteinarten bei Baukastensystemen (Quelle: Dubbel, Taschenbuch für den Maschinenbau 2001)

Damit wird für die Verwaltung von Baukastensystemen mit Hilfe von Integrationssystemen ein entsprechender Funktionsumfang des Systems für das Varianten- und Konfigurationsmanagement benötigt. Organisatorisch ergibt sich bei der Definition der Variantenstrukturen die Schwierigkeit alle notwendigen und sinnvollen Konfigurationen bzw. Kombinationsmöglichkeiten zu erfassen und in einer Variantenstruktur mit den Variantenplatzhaltern abzubilden.

6.3

Nummernsysteme

Unter Nummerung wird das Bilden, Erteilen, Verwalten und Anwenden von Nummern für die Nummerungsobjekte verstanden (DIN 6763). Die Nummer ist eine festgelegte Folge von Zeichen, dabei werden Ziffern, Buchstaben und Sonderzeichen unterschieden. Kurzbezeichnungen wurden schon lange vor dem Einsatz von IT-Systemen zur eindeutigen Beschreibung von Objekten in der betrieblichen Praxis eingesetzt. Solche Objekte können z. B. sein: Gegenstände (Teile, Gruppen, Enderzeugnisse, Betriebsmittel usw.), Datenträger (Zeichnungen, Pläne, Vorschriften, Belege usw.), Personen (Belegschaftsangehörige, Kunden, Lieferanten usw.) und Sachverhalte (Ereignisse oder Vorgänge in Netzplänen usw.). Derartige Bezeichnungen treten als eine Folge von Ziffern, Buchstaben und Sonder-

6.3 Nummernsysteme

213

zeichen auf. Bildet man sie nach einer bestimmten Systematik, so liegt ein Nummernsystem vor. Synonym werden auch die Begriffe Nummerungsschlüssel, Schlüssel, Code und Codesystem verwendet (Eigner u. Stelzer 2001). Durch den Einsatz von Nummernsystemen werden folgende Ziele verfolgt: • • • • • • •

Vereinfachung der Informationsverarbeitung Vereinfachung der Ablauforganisation Verbesserung der Kommunikation zwischen Bereichswesen Verbesserung des Ordnungswesens Reduzierung von Personalkosten Reduzierung von Änderungen Verbesserung technischer Einrichtungen

Somit fallen dem Nummernsystem unterschiedliche Aufgaben zu, die in einer Nummer oder in mehreren, für ein Objekt parallel existierende, Nummern umgesetzt werden können. Zu diesen Aufgaben gehört das Identifizieren, Klassifizieren (s. Abschnitt 6.4), Informieren und Kontrollieren. Die Identifikationsnummer ist eine eindeutige, unverwechselbare Festlegung bzw. Erkennung eines Elementes, z. B. des Teilestammes 4712. Die Identifizierung kann sich auf ein einzelnes Element oder eine Gruppe von Elementen beziehen. Beim Aufbau einer Identifikationsnummer sind einige wichtige Grundsätze zu beachten. Diese sind: • Vollständigkeit der Nummernvergabe • Eindeutigkeit der Nummer und • Unveränderlichkeit während ihrer gesamten Lebensdauer Informationsnummern enthalten eine direkte Aussage aufgrund unverschlüsselter Merkmale. Die Informationsnummern geben ohne Verwendung eines Nummernplans/Schlüsselverzeichnisses unmittelbar Auskunft über Eigenschaften des verschlüsselten Elements, z. B. DIN-Nummern für Werkstoffe und Papierformate. Eine Kontrollnummer liegt vor, wenn durch diese Nummer die Erkennung einer richtigen Person, Sache oder eines Sachverhaltes gewährleistet werden soll. Eine zusätzliche Kontrollnummer zu einer Identifizierung- oder Klassifizierungsnummer ist nur dann sinnvoll, wenn wegen einer möglichen Verwechslungsgefahr auf die Auswahl der richtigen Nummer besonders große Bedeutung gelegt wird.

214

6 Technische und methodische Grundlagen

6.3.1

Aufbau von Nummernsystemen

Ein identifiziertes Nummerungsobjekt kann auch eine Gruppe von Nummerungsobjekten umfassen, die innerhalb einer festgelegten Toleranz gleich und somit austauschbar sind (Schrauben, Unterlegscheiben, Elektromotoren usw.). Sollen in diesem Sinne identische Objekte voneinander unterschieden werden, z. B. einzelne Kfz-Motoren derselben Serie, so müssen gesonderte Nummern vergeben werden, z. B. Fabriknummer, Inventarnummer oder Seriennummer. Dies geschieht meist in Verbindung mit einem Typenschild (Eigner u. Stelzer 2001). Innerhalb eines Standardsystems wie beispielsweise bei klassischen PDM-Systemen hat das Nummernsystem die Aufgabe, alle Objekte, d. h. Unterlagen, Artikel und Projekte, eindeutig zu identifizieren und bestimmten Eigenschaften zu klassifizieren Bei einer Einführung sollte daher sehr gewissenhaft auf ein funktionsfähiges Nummernsystem geachtet werden. Energie übertragen und verändern

1. Stelle

1. und 2. Stelle

0 Anlagen und Gerätebau

00 Metallerzeugung

01 Metallverarbeitung

02 Verfahrenstechnik

03 Fördertechnik

04 Stahlbau

07 Werkzeugmaschinen

1 spezifische Baugruppen

10 Metallerzeugung

11 Metallverarbeitung

12 Verfahrenstechnik

13 Fördertechnik

14 Stahlbau

17 Werkzeugmaschinen

2 allgemeine Baugruppen

20 statische Funktion

21 Energie liefern

22 23 Energie thermische übertragen u. Funktion verändern

24 Mess, Steuer-, Regelfkt.

25 Betriebs- u. Wartungsfunktion

3 Einzelteile

30 Maschinenbaueinzelteile

31 Genauformeinzelteile

32 Stahlbaueinzelteile

33 Genaublecheinzelteile

34 Schweißeinzelteile

35 statische Funktion

41 Gussrohteile

42 Halbzeug

43

44

45

4 40 Schmiede u. SchiedeGussrohteile, rohteile Halbzeuge

Abb. 6-2: Prinzip der hierarchischen Strukturierung

6.3 Nummernsysteme

215

Ist das Nummernsystem nicht auf die betrieblichen Anforderungen abgestimmt, muss es später mit hohem Aufwand reorganisiert werden oder es kann nicht im ursprünglich geplanten Umfang genutzt werden. Die Abstimmung mit schon existierenden Nummernsystemen, die historisch gewachsen oder aus ERP-Einführung resultieren, kann sich eventuell problematisch darstellen. Hier treffen die konkurrierenden Anforderungen verschiedener Informationssysteme aufeinander. Für die PLM-Einführung oder anderen entwicklungsseitigen Integrationssystemen ergibt sich somit häufig die Konsequenz, dass die Benummerung der Artikelstämme des ERP-Systems übernommen werden muss. Die Freiheitsgrade der Konzeption liegen in diesem Fall nur noch in den vom PDM-System verwalteten Objekten, z. B. den Dokumenten. Der Aufbau von Nummern richtet sich nach folgenden Grundsätzen bezüglich ihres Schemas: • Nach dem Prinzip der hierarchischen Strukturierung bzw. der verzweigten Gliederung (Baumstruktur) • Nach dem Prinzip der unabhängigen Strukturierung bzw. der unverzweigten Gliederung (Listenstruktur) Bei einem hierarchischen Nummernaufbau ist ein Nummernteil von dem links vor ihm stehenden Nummernteil funktional abhängig (siehe Abb. 6-2). Ein Nummernteil (Hierarchiestufe) kann dabei aus einer oder mehreren Stellen bestehen. Demnach kann ein Nummernteil nicht selbstständig, sondern nur im Zusammenhang mit dem über ihn übergeordneten Oberbegriffen ausgewertet werden. 1. Stelle Zeichnungsgröße

2. Stelle Papierqualität

3. Stelle Aufbewahrungsart

1

DIN A1

1

Transparent

1

gerollt

2

DIN A2

2

Karton > 80 g/m²

2

hängend

3

DIN A3

3

Karton < 80 g/m²

3

liegend

4

DIN A4

4

auf Transparent gepaust

4

in Ordner geheftet

5

DIN A5

5

auf Karton gepaust

5

frei

6

DIN A6

6

frei

6

in Lochkarte montiert

7

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