Personalplanung und -entwicklung
in einem integrierten Vorgehensmodell
zur Einführung von Produktdatenmanagementsystemen
zur Erlangung des akademischen Grades eines
DOKTORS DER INGENIEURWISSENSCHAFTEN (Dr.-Ing.)
der Fakultät für Maschinenbau
der Universität Paderborn
genehmigte
DISSERTATION
von
Dipl.-Wirt.-Ing. Rainer Pusch
aus Celle
Tag des Kolloquiums: 19. Dezember 2002
Referent: Prof. Dr.-Ing. Jürgen Gausemeier
Korreferent: Prof. Dr.-Ing. Michael Abramovici
Vorwort
Die vorliegende Arbeit „Personalplanung und -entwicklung in einem integrierten
Vorgehensmodell zur Einführung von Produktdatenmanagementsystemen“ ent-
stand während meiner Forschungstätigkeit am Heinz Nixdorf Institut der Universi-
tät Paderborn. Sie fasst die Erfahrungen zusammen, die ich in zahlreichen
Forschungs- und Industrieprojekten zur Einführung von PDM-Systemen sammeln
und auswerten konnte.
Herrn Prof. Dr.-Ing. Jürgen Gausemeier danke ich für die Betreuung dieser Arbeit,
für die Vielfalt der mir vertrauensvoll übertragenen Aufgaben, sowie für die fachli-
chen Gespräche und die Zusammenarbeit, die mich sehr gut auf die Herausforde-
rungen meines weiteren beruflichen Werdegangs vorbereitet haben.
Bei Herrn Prof. Dr.-Ing. Michael Abramovici möchte ich mich für die Übernahme
des Korreferats bedanken. Ebenso danke ich dem Vorsitzenden der Prüfungskom-
mission Herrn Prof. Dr.-Ing. Roland Span sowie Herrn Prof. Dr.-Ing. Hans Albert
Richard für den Beisitz.
Zudem bedanke ich mich bei allen Kolleginnen und Kollegen, den studentischen
Hilfskräften sowie den Studien- und Diplomarbeitern, die mich während meiner
Zeit am Heinz Nixdorf Institut begleitet und unterstützt haben. Mein besonderer
Dank gilt Frau Rosemarie Selbach und Herrn Raimund Eckes für ihren tatkräftigen
Einsatz bei der redaktionellen Fertigstellung dieser Arbeit.
Großen Dank schulde ich meiner Familie, allen voran meinen Eltern für ihr Ver-
trauen in meine Fähigkeiten und die Unterstützung während der gesamten schuli-
schen und universitären Ausbildungszeit.
Zu guter Letzt danke ich meiner Freundin Ute und unserer Tochter Ida für den
Antrieb und die Energie, die sie mir gegeben haben.
Paderborn, im April 2003 Rainer Pusch
Inhalt Seite
1 Einleitung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.1 Problematik . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.2 Zielsetzung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.3 Vorgehensweise . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2 Einführung von PDM-Systemen . . . . . . . . . . . . . . . . . . . 9
2.1 Produktdatenmanagement . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.1.1 Strategische Bedeutung von PDM . . . . . . . . . . . . . . . . . . 11
2.1.1.1 Paradigmenwechsel durch Einsatz von PDM . . . . . . . . 11
2.1.1.2 PDM-Systeme als Integrationsdrehscheibe für den
Produktentstehungsprozess. . . . . . . . . . . . . . . . . . . . . . 18
2.1.1.3 Querverbindungen von PDM zu anderen strategischen IT-
Komponenten und strategischen Unternehmenszielen . 21
2.1.1.4 Nutzenpotentiale von PDM-Systemen . . . . . . . . . . . . . . 29
2.1.2 Produktdatenmanagement-Systeme . . . . . . . . . . . . . . . . 31
2.1.2.1 Grundfunktionen zur Verwaltung von Produktdaten. . . . 31
2.1.2.2 Grundfunktionen des Prozessmanagements. . . . . . . . . 34
2.1.2.3 Aufbau von PDM-Systemen. . . . . . . . . . . . . . . . . . . . . . 35
2.1.2.4 Stand der am Markt verfügbaren Systeme. . . . . . . . . . . 37
2.1.3 Schlussfolgerungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
2.2 Rahmenbedingungen von PDM-Einführungsprojekten . . . 39
2.2.1 Ausgangspunkt. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
2.2.2 Stakeholder . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
2.2.3 Beteiligung interner Mitarbeiter . . . . . . . . . . . . . . . . . . . . 41
2.2.4 Outsourcing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
2.2.5 Projektmanagement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
2.2.6 Methodeneinsatz . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
2.2.7 Standardsoftware und Customizing . . . . . . . . . . . . . . . . . 47
2.2.8 Betrieb des Systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
2.2.9 Schlussfolgerungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
2.3 Vorgehensmodelle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
2.3.1 Bestandteile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
2.3.2 Klassifizierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
2.3.3 Schlussfolgerungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
2.4 Personalplanung und -entwicklung. . . . . . . . . . . . . . . . . . . 56
2.4.1 Eingrenzung der Personalmanagementaufgaben im
Rahmen der PDM-Einführung . . . . . . . . . . . . . . . . . . . . . 57
2.4.1.1 Kurzfristige Aufgaben im Rahmen der Projektplanung . 58
Seite vi Inhalt
2.4.1.2 Mittelfristige Aufgaben im Rahmen der Projektdurch-
führung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
2.4.2 Schlussfolgerungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
2.5 Anforderungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
3 Stand der Technik . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
3.1 Vorgehensmodelle zur Einführung von PDM-Systemen. . . 63
3.1.1 Einführungsmodelle von Standardisierungsgremien und
Verbänden . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
3.1.1.1 VDI-Richtline 2219 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
3.1.1.2 STEP PDM Schema und OMG PDM Enablers . . . . . . . 65
3.1.2 Einführungsmodelle aus dem Bereich der Forschung . . . 66
3.1.2.1 EDM-Studie des Fraunhofer-Institut für Arbeitswirtschaft
und Organisation IAO . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
3.1.2.2 RapidPDM Implementation Methodology . . . . . . . . . . . . 67
3.1.2.3 Einführungstrategie für Engineering Data Management-
Systeme nach Eversheim. . . . . . . . . . . . . . . . . . . . . . . . 69
3.1.2.4 Nutzenorientierte Einführung von PDM-Systemen nach
Wehlitz . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
3.1.3 Einführungsmodelle mit industriellem Hintergrund . . . . . . 71
3.1.3.1 PDM-Einführung nach Eigner und Stelzer . . . . . . . . . . . 71
3.1.3.2 Einführung von Produktdatenmanagementsystemen
nach Strohmayer/Suhm . . . . . . . . . . . . . . . . . . . . . . . . . 72
3.1.3.3 Einführungstrategie für Produktdatenmanagement
nach Schöttner . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
3.1.4 Einführungsmodelle von PDM-Systemanbietern und
Beratungsunternehmen . . . . . . . . . . . . . . . . . . . . . . . . . . 74
3.2 Vorgehensmodelle der allgemeinen Softwareentwicklung . 76
3.2.1 V-Modell zur Planung und Durchführung von IT-Vorhaben
in der Bundesverwaltung . . . . . . . . . . . . . . . . . . . . . . . . . 76
3.2.2 Unified Software Development Process . . . . . . . . . . . . . . 79
3.3 Resümee und Handlungsbedarf . . . . . . . . . . . . . . . . . . . . . 82
4 Integriertes Vorgehensmodell zur Einführung von PDM-
Systemen. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
4.1 Überblick. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
4.2 Anstoß der PDM-Einführung. . . . . . . . . . . . . . . . . . . . . . . . 87
4.3 Vorstudie (P1) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
4.3.1 Phasen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
4.3.1.1 Strategiebindung (P1.1) . . . . . . . . . . . . . . . . . . . . . . . . . 89
4.3.1.2 Ist-Analyse (P1.2) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
4.3.1.3 Potentialanalyse (P1.3). . . . . . . . . . . . . . . . . . . . . . . . . . 97
4.3.1.4 Projektmanagement (P1.4). . . . . . . . . . . . . . . . . . . . . . . 100
Inhalt Seite vii
4.3.2 Projektorganisation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
4.4 Systemauswahl (P2). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102
4.4.1 Phasen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102
4.4.1.1 Grobkonzeption (P2.1). . . . . . . . . . . . . . . . . . . . . . . . . . 102
4.4.1.2 Systemvorauswahl (P2.2) . . . . . . . . . . . . . . . . . . . . . . . 106
4.4.1.3 Benchmark (P2.3) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108
4.4.1.4 Releaseplanung (P2.4) . . . . . . . . . . . . . . . . . . . . . . . . . 111
4.4.1.5 Projektmanagement (P2.5) . . . . . . . . . . . . . . . . . . . . . . 113
4.4.2 Projektorganisation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114
4.5 Systemeinführung (P3). . . . . . . . . . . . . . . . . . . . . . . . . . . . 115
4.5.1 Phasen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115
4.5.1.1 Feinspezifikation (P3.1) . . . . . . . . . . . . . . . . . . . . . . . . . 116
4.5.1.2 Systemanpassung (P3.2). . . . . . . . . . . . . . . . . . . . . . . . 121
4.5.1.3 Testen (P3.3) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121
4.5.1.4 Roll-Out(3.4). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124
4.5.1.5 Projektmanagement (P3.5) . . . . . . . . . . . . . . . . . . . . . . 128
4.5.2 Projektorganisation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132
4.6 Tätigkeiten nach der PDM-Einführung . . . . . . . . . . . . . . . . 133
4.6.1 Strategische Kontrolle . . . . . . . . . . . . . . . . . . . . . . . . . . . 133
4.6.2 Operativer Betrieb . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134
4.7 Methoden . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137
4.7.1 Objektorientierte Methode zur Geschäftsprozess-
modellierung und -analyse (OMEGA) . . . . . . . . . . . . . . . 138
4.7.2 Prototyping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140
4.7.3 Best Practices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142
4.7.4 Unified Software Development Process. . . . . . . . . . . . . . 142
4.7.5 Programmierschnittstellen . . . . . . . . . . . . . . . . . . . . . . . . 144
4.7.6 Weitere Methoden . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144
5 Personalplanung und -entwicklung . . . . . . . . . . . . . . . . 145
5.1 Ableitung von Rollen aus dem integrierten Vorgehensmodell145
5.1.1 Kompetenzen für die PDM-Einführung. . . . . . . . . . . . . . . 146
5.1.1.1 Humanorientierte Kompetenzen . . . . . . . . . . . . . . . . . . 146
5.1.1.2 Fach- und Methodenkompetenzen . . . . . . . . . . . . . . . . 147
5.1.2 Ermittlung der Rollen . . . . . . . . . . . . . . . . . . . . . . . . . . . . 149
5.2 Besetzung der Rollen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151
5.2.1 Auswahl interner Mitarbeiter. . . . . . . . . . . . . . . . . . . . . . . 154
5.2.2 Auswahl externer Mitarbeiter . . . . . . . . . . . . . . . . . . . . . . 157
5.2.3 Anwendung der Methode auf die mittelfristige Personal-
planung und -entwicklung. . . . . . . . . . . . . . . . . . . . . . . . . 159
5.3 Ausgleich von Qualifizierungsdefiziten. . . . . . . . . . . . . . . . 159
5.3.1 Qualifizierung für die Projektarbeit . . . . . . . . . . . . . . . . . . 159
5.3.2 Anwenderschulungen. . . . . . . . . . . . . . . . . . . . . . . . . . . . 160
Seite viii Inhalt
5.3.3 Berufliche Aus- und Weiterbildung . . . . . . . . . . . . . . . . . . 161
5.3.3.1 Einsatz eines PDM-Systems in der Lehre für Ingenieure 161
5.3.3.2 Studienwahlfach PDM. . . . . . . . . . . . . . . . . . . . . . . . . . . 162
5.3.3.3 Traineeprogramm für PDM-Berater und Implementierer 166
5.3.3.4 Intensivtraining . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169
5.3.3.5 Außeruniversitäre Berufsausbildung. . . . . . . . . . . . . . . . 169
6 Zusammenfassung und Ausblick . . . . . . . . . . . . . . . . . . 171
7 Literaturverzeichnis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173
Einleitung Seite 1
1 Einleitung
1.1 Problematik
Industrieunternehmen sind zunehmendem Innovationsdruck ausgesetzt. Dieser
wird ausgelöst durch den verstärkten, weltweiten Wettbewerb, die rasante Ent-
wicklung neuer Technologien und immer kürzer werdende Produktlebenszyklen.
Neue Produkte müssen daher in kürzerer Zeit, mit verbesserter Qualität und zu
niedrigeren Preisen auf den Markt gebracht werden.
Um dies zu erreichen, haben die Unternehmen in den letzten 20 Jahren erhebliche
Anstrengungen zur Rationalisierung vor allem in den Bereichen Fertigung und
Logistik unternommen. Dort sind die Verbesserungspotentiale inzwischen so weit
ausgenutzt, dass kaum noch Produktivitätssteigerungen zu erwarten sind [Cie96].
Deshalb rückt die Optimierung des Bereiches Produktentwicklung1 und die Ver-
besserung der bereichsübergreifenden Zusammenarbeit zunehmend als Lösungs-
ansatz in den Mittelpunkt [Sch98a].
Es ist allgemein anerkannt, dass die Informationstechnik2 (IT) nicht nur eine
wesentliche Rolle bei der Bewältigung dieser Herausforderungen spielt, sondern
mittlerweile aus der Produktentwicklung nicht mehr wegzudenken ist:
„Heute sind die Hilfsmittel und Methoden der Informationstech-
nik für den Konstruktionsprozess unentbehrlich geworden.“
[SK97a, S. 41]
Wie die Untersuchung „Neue Wege zur Produktentwicklung“ aufzeigt, ist der Ein-
satz von Informationstechnik in der Produktentwicklung aber noch mit großen Pro-
blemen behaftet [GG97, S. 51ff]. Als Hauptproblembereich werden dabei die Pro-
duktdatenmanagement (PDM3)-Systeme identifiziert (siehe Bild 1-1). Sie
verwalten alle relevanten Daten über ein Produkt und die Prozesse der Produktent-
wicklung. Sie dienen als Integrationsplattform sowohl für die CAE4-Systeme als
auch für die betriebswirtschaftliche Datenverarbeitung.
1. Sie erstreckt sich von der Produktidee bis zum erfolgreichen Markteintritt und umfasst die
Funktionsbereiche Produktplanung/Produktmarketing, Entwicklung/Konstruktion sowie Ferti-
gungsplanung/Fertigungsmittelbau [GF99, S. 406].
2. Darunter fallen alle rechnerunterstützten Arbeitsmittel, durch deren Anwendung Aufgaben der
Informationserfassung/-aufnahme, -verarbeitung, -speicherung sowie des Informationstrans-
ports bearbeitet werden. [GG97, S. 49]
3. Es finden sich in der Literatur weitere Begriffe und Abkürzungen wie TIM (Technisches Infor-
mationsmanagement [Eig96]), EDM (Engineering Data Management [AB93], [BHM96]), PLM
(Product Lifecycle Management [AGL97], [Ste00]), EDB (Engineering Database [Eig91]) und
CPC (Collaborative Product Commerce [Abe00]). Die französische Bezeichnung „Système de
Gestion des Donées Techniques (SGDT)“ bedeutet übersetzt „Verwaltungssystem für techni-
sche Daten“. Im Prinzip bezeichnen alle diese Begriffe das gleiche Konzept. Deshalb wird im
weiteren Verlauf der Begriff PDM stellvertretend verwendet.
Seite 2 Kapitel 1
PDM-Systeme sind die Grundvoraussetzung zur Umsetzung der ebenfalls in der
Befragung genannten Problembereiche Verteilte Produktentwicklung [AGL98],
[BH99], Simultaneous/Concurrent Engineering [Mut99], [Sch96], [Som98] und
Feature-Technologie [SR98]. Ein Großteil weiterer identifizierter Problembereiche
wie z.B. die Informationsbereitstellung oder das Prozessmanagement, sind eben-
falls eng mit dem Einsatz von PDM-Systemen verbunden.
Diese Verzahnung mit zahlreichen Problembereichen der Produktentwicklung
führt zu einer hohen Komplexität der Einführung von PDM-Systemen, da viele
dieser Bereiche gleichzeitig betrachtet und die entsprechenden Probleme gelöst
werden müssen.
„Die EDM/PDM-Einführung ist komplexer als die Einführung
operativer, funktionsorientierter IT-Systeme. Sie hat Ähnlichkeit
mit der Einführung anderer strategischer unternehmensüber-
greifender IT-Systeme, wie z.B. ERP/PPS5-Systeme.“ [Abr99]
Bestandteile einer PDM-Einführung sind immer auch strategische Betrachtungen,
Geschäftsprozessanalysen, Anpassungen von Organisationsstrukturen sowie eine
Neuordnung der IT-Landschaft eines Unternehmens. PDM-Einführungsprojekte
haben deshalb meist einen sehr langen Planungshorizont von fünf bis zehn Jahren
4. Computer Aided Engineering: Rechnerunterstützung für ingenieurmäßiges Arbeiten in der Pro-
duktentwicklung, der Projektierung u.ä.
Bild 1-1: Identifizierte Problembereiche beim Einsatz von Informationstechnik
in der Produktentwicklung [GG97, S. 52]
5. Enterprise Resource Planning / Produktionsplanung und -steuerung
0 2 4 6 8 10 12 14 16
Produktmodellierung, Produktdatenaustausch,
Engineering Data Management-Systeme
verteilte Produktentwicklung,
verteilte Infrastruktur
Feature-Technologie
Informationsbereitstellung
Simultaneous/Concurrent Engineering
Planung, Einführung und Bewertung
informationstechnischer Systeme
Prozess-, Produkt-, Workflowmanagement
Aufbau von Prozessketten
Berechnung, Simulation, CAE
System- und Softwareentwicklungsmethoden
Industrial Design/Virtual Reality
Rapid Prototyping
Anzahl der Nennungen (Mehrfachnennungen möglich)
Einleitung Seite 3
[AB93]. Ebenso sind die Kosten für eine PDM-Einführung sehr hoch und errei-
chen schon in kleineren Projekten schnell die Millionengrenze [Sei96].
Obwohl sich in der Literatur mittlerweile Berichte über erfolgreiche Einführungen
von PDM-Systemen finden lassen6, bringen die meisten Projekte nicht den erhoff-
ten Erfolg7. Eine Befragung unter 33 europäischen Unternehmen, die bereits
PDM-Systeme einsetzen, zeigt dies deutlich [IIC00]:
• Die erzielten Ergebnisse der PDM-Einführung weichen z.T. stark von den vorher
definierten Zielen ab. Die Abweichung beträgt jeweils bis zu 23% in der Funk-
tionalität und im Integrationsgrad.
• Die kalkulierten Projektkosten werden um bis zu 18% und die Projektzeiten
sogar um bis zu 68% überschritten.
Folgende Gründe können für die fehlende Erreichung der inhaltlichen Ziele in
Bezug auf die Funktionalität und den Integrationsgrad ausgemacht werden:
Mangelnde Managementunterstützung: Die angesprochene Tragweite des
PDM-Einsatzes erfordert abteilungsübergreifende Zusammenarbeit bei der Bewäl-
tigung der damit verbundenen Aufgaben. Die in der Industrie weit verbreiteten
dezentralen Strukturen mit Festlegung von abteilungsbezogenen Kostenzielen
hemmen diese, wenn die Unternehmensführung das Projekt nicht voll unterstützt
[Abr96a], [Fri96].
Fehlende Mitarbeiterakzeptanz: PDM-Systeme verändern den Arbeitsalltag
stark. Solche Veränderung erzeugt bei den meisten Mitarbeitern8 zunächst Wider-
stand, sei es aus Bequemlichkeit, aus Unsicherheit über die Art der Veränderung
oder aus Angst vor Verlust des Arbeitsplatzes [Sta91, S. 900ff], [Str00]. Neben
diesen psychologischen Faktoren führen aber auch Fehler in der Anwendung,
ungewohnte Benutzungsoberflächen und falsche Erwartungen an das
PDM-System dazu, dass Mitarbeiter dieses nicht ausreichend nutzen [LFH99].
Falsche Systemauswahl: Der Markt für PDM-Systeme ist sehr unübersichtlich.
Die meisten Systeme gleichen sich auf den ersten Blick stark. Erst bei genauerer
Betrachtung werden Unterschiede in den Stärken und Schwächen deutlich. Diese
sind zumeist durch die unterschiedliche Entwicklungsgeschichte der Systeme
begründet [FH96]. Die Bewertung der Systeme und die Entscheidung für das
6. U.a. [Bia98], [FW99], [HS97], [LK96], [WFG99]. Die Autoren bezeichnen durchweg die ver-
besserten Informationsflüsse im Unternehmen und den verbesserten Zugriff aller Unterneh-
mensbereiche auf die jetzt im PDM-System verwalteten Daten als den größten Nutzen.
7. Als Erfolg gilt hier die Erreichung vorher definierter Projektziele für die Einführung von
PDM-Systemen. Dazu zählen zum einen die Anwendbarkeit des Systems und die dadurch
erreichten Nutzenpotentiale und zum anderen die Einhaltung des festgelegten Zeit- und Kosten-
rahmens.
8. Im Folgenden wird nur wegen der besseren Lesbarkeit ausschliesslich die maskuline Form ver-
wendet.
Seite 4 Kapitel 1
„richtige“ System sind daher schwierig und sehr zeit- und kostenintensiv [Kah00,
S. 4].
Unzureichende Schulung: Die Ausbildung der Anwender beschränkt sich mei-
stens auf die Vermittlung der Bedienungsfunktionen des Systems anhand von stan-
dardisierten Schulungen der Systemanbieter. Die Schulung am angepassten
System mit konkreten Beispielen aus dem Arbeitsalltag der Anwender erfolgt sel-
ten. Die veränderten organisatorischen Rahmenbedingungen, z.B. neue Prozesse
oder Nummernsysteme, werden ebenfalls nicht vermittelt [Abr96a].
Fehlende Koordination mit anderen IT-Projekten: PDM-Systeme dienen als
Integrationsplattform für CAE-Systeme und die betriebswirtschaftliche Datenver-
arbeitung. Unzureichende Koordination mit IT-Projekten aus diesen Bereichen,
z.B. wegen einer fehlenden unternehmensweiten Gesamstrategie für den Einsatz
der Informationstechnik, führt zu einem unzureichenden Integrationsgrad [Fri96],
[KFV99].
Eine Befragung der Zeitschrift „Computer Aided Engineering“ deckt ergänzend
dazu die Gründe für das Verfehlen der Zeitziele und die damit verbundenen höhe-
ren Kosten einer PDM-Einführung auf (siehe Bild 1-2).
Neben der bereits erläuterten mangelnden Managementunterstützung und techni-
schen Schwierigkeiten treten dabei drei weitere Probleme zu Tage:
Ungenügende Planung/schlechtes Projektmanagement: Die Planung von
PDM-Projekten erfolgt zumeist ohne eine klare, von allen Anspruchsgruppen9
akzeptierte Vorstellung vom Ziel des Projektes [Fri96]. Sie erfolgt fokussiert auf
Bild 1-2: Gründe für Zeitverzögerungen in CAE/PDM-Einführungsprojekten
[CAE96]
9. Es lassen sich grob drei Anspruchsgruppen identifizieren: Endanwender, Management und
IT-Funktionsträger. [Dob98, S. 7]
Fehlende oder nicht
ausreichend qualifizierte Mitarbeiter
30%
Fehlende
Unterstützung
durch das
2%
Management Technische
Schwierigkeiten
16%
Ungenügende Planung/
schlechtes Projektmanagement
23%
Ungenügende Definition
der Anforderungen
29%
Einleitung Seite 5
die Implementierung des PDM-Systems [Mar99] und lässt wichtige Themen, z.B.
die Altdatenübernahme, die Schnittstellenentwicklung oder die Schulung der
Anwender außer Acht [PWC98]. Die Projektleiter sind zumeist nicht mit genügend
Entscheidungskompetenz ausgestattet, so dass bei unvorhergesehenen Änderungen
ein langwieriger Abstimmungsprozess den Projektverlauf verzögert [Mar99]. Die
verwendeten Werkzeuge für das Projektmanagement sind zumeist komplex und
nicht den Gegebenheiten einer PDM-Einführung angepasst [GK99].
Ungenügende Definition der Anforderungen: Ist ein gemeinsam akzeptiertes
Ziel nicht genau definiert (s.o.), weichen auch die gestellten Anforderungen aus
den Anspruchsgruppen stark voneinander ab und lassen sich schlecht koordinieren.
Anforderungen enthalten einen unzulässigen Interpretationsspielraum, wenn zum
einen die frühzeitige Klärung und Festlegung von Begrifflichkeiten nicht erfolgt
[Wen95-ol] und zum anderen die Dokumentation der Anforderungen nicht forma-
lisiert wird [KFV99]. Fehlt dem Anwender das grundsätzliche Verständnis für die
Möglichkeiten der neuen Technologie, kann er nur eingeschränkt Anforderungen
an diese formulieren [KW98].
Fehlende oder nicht ausreichend qualifizierte Mitarbeiter: Die Durchführung
von PDM-Einführungen erfolgt zumeist in Projektteams, die aus internen und
externen Mitarbeitern bestehen. Dabei fehlt den internen Mitarbeitern das entspre-
chende Wissen10 oder die notwendigen Zusatzqualifikationen11. Zudem sind sie
durch das Tagesgeschäft gebunden [LFH99]. Deshalb werden zur Unterstützung
externe Mitarbeiter von Beratungsunternehmen und Systemanbietern hinzugezo-
gen. Diese kennen allerdings das Unternehmen zu wenig [MMH97]. Zusätzlich
erfordert die Komplexität der PDM-Systeme Spezialisten für einzelne Module, die
nicht immer oder nur über einen begrenzten Zeitraum dem Projekt zur Verfügung
stehen.
Zusammenfassend lässt sich feststellen, dass bei fast allen angesprochenen Proble-
men im Kern das Defizit in unzureichender Qualifikation, Kommunikation und
Koordination der Beteiligten besteht. Hier gilt es anzusetzen, um mehr PDM-Ein-
führungsprojekte zum Erfolg zu führen.
„Ein Großteil der aufgezeigten Probleme kann ... durch gezielte
Aufklärungs-, Ausbildungs- und Organisationsmaßnahmen
gelöst werden.“ [Abr96a]
10. Laut einer Studie des Fraunhofer-Institutes für Arbeitswirtschaft und Organisation (IAO) verfü-
gen 65% der befragten 379 Unternehmen aus allen Bereichen der produzierenden Industrie über
ein unzureichendes Know-how im Bereich PDM. [MMH97]
11. Viele Autoren weisen darauf hin, dass für Projekte, die wie PDM-Einführungsprojekte mit
organisatorischen Veränderungen verbunden sind, die so genannten „weichen“ Schlüsselquali-
fikationen wie Motivation, Kommunikationsfähigkeit, Teamfähigkeit und Lernbereitschaft,
eine wichtige Rolle spielen [Bul92, S. 22ff], [SK97a, S. 695], [Wil90, S. 220ff].
Seite 6 Kapitel 1
Organisatorische Ansätze zur Verbesserung von PDM-Einführungsprojekten
bestehen bereits in Form von Vorgehensmodellen. Diese beschreiben jedoch die
Abfolge der Phasen12, in denen eine PDM-Einführung ablaufen soll, zumeist nur
grob und mit einem starken Schwerpunkt auf die Systemauswahl und die System-
einführung.
Sehr detaillierte Methoden zur systematischen Unterstützung einzelner Phasen
oder Subphasen sind ebenfalls bekannt. Eine Durchgängigkeit über die Phasen hin-
weg ist aber kaum gegeben. D.h. die Methoden bauen nicht aufeinander auf und
nutzen die Ergebnisse vorhergehender Phasen kaum. Der Aspekt der Personalpla-
nung und -entwicklung wird nur selten und unvollständig beachtet. Hier beschrän-
ken sich die bekannten Vorgehensmodelle auf die Erwähnung der Notwendigkeit
von Schulungen und das so genannte Akzeptanzmanagement für die späteren
Anwender. Die vorbereitende Qualifizierung der Mitarbeiter, die bereits im Ein-
führungsprojekt, z.B. bei der Definition von Anforderungen, benötigt werden, wird
vernachlässigt. So müssen Mitarbeiter Anforderungen an das Produktdatenmana-
gement definieren, obwohl sie noch gar nicht genau wissen, was alles damit ver-
bunden ist.
Unberücksichtigt bleibt in den Vorgehensmodellen auch, dass kaum ein PDM-Ein-
führungsprojekt ohne externe Dienstleistungen aus Beratungsunternehmen und
Systemhäusern durchgeführt wird13. Da der entsprechende Markt sehr fragmen-
tiert und unübersichtlich ist [AS01], besteht das Problem für die Unternehmen, die
Anbieter von Beratungs- und Implementierungskompetenz zu finden, die für die
spezifische Aufgabenstellung am tauglichsten sind [Spu96] bzw. die Qualifikati-
onslücken, die beim eigenen Personal bestehen, am besten füllen. Entsprechende
Hilfmittel für die Personalplanung und -entwicklung14 in PDM-Einführungspro-
jekten existieren nicht.
1.2 Zielsetzung
Ziel dieser Arbeit ist die Konzeption eines Vorgehensmodells für die Einführung
von PDM-Systemen mit folgenden Eigenschaften:
• Berücksichtigung aller Phasen von der Vorstudie bis zum Betrieb,
12. Als Phasen einer PDM-Einführung lassen sich in allen bestehenden Ansätzen allgemein die
Voranalyse, die Systemauswahl, die Systemeinführung und der Betrieb ausmachen. Es gibt
lediglich Unterschiede in der detaillierten Ausgestaltung der Subphasen und der Zuordnung von
einzelnen Tätigkeiten zu den Subphasen.
13. Dies wird deutlich, wenn man den Markt für PDM-Software näher beleuchtet: Mehr als die
Hälfte der Umsätze der PDM-Systemanbieter werden hier mittlerweile (bei seit Jahren steigen-
dem Anteil) nicht mit Lizenzen, sondern mit Dienstleistungen für die Einführung und Betreu-
ung der Software gemacht [Mur01]. Zusätzlich ist zu beobachten, dass klassische Beratungsun-
ternehmen zunehmend in den Markt für diese Dienstleistungen drängen [AS01].
14. Zur Definition und Einordnung des Begriffes siehe Kapitel 2.4.
Einleitung Seite 7
• Einsatz von aufeinander aufbauenden Methoden über alle Phasen,
• Integration einer Methode für die Personalplanung und -entwicklung bei der
PDM-Einführung.
Zusätzlich sollen eine Reihe von Qualifizierungsmaßnahmen beschrieben werden,
die den Qualifizierungsbedarf sowohl projektbegleitend in Form von Schulungen
als auch projektunabhängig in der beruflichen Aus- und Weiterbildung decken.
Ziel ist nicht, neue Methoden zur Unterstützung einer oder mehrerer Phasen zu
entwickeln. Die beschriebenen Methoden sind an anderer Stelle und nicht unbe-
dingt mit Blick auf die PDM-Einführung entwickelt worden. Sie haben allerdings
ihre Tauglichkeit sowohl in Bezug auf die Unterstützung der einzelnen Phasen als
auch in einer guten Durchgängigkeit über die Phasen in verschiedenen PDM-Ein-
führungsprojekten, an denen der Autor beteiligt war, bewiesen. Deshalb werden sie
jeweils in einer PDM-spezifischen Ausprägung vorgestellt. Die vollständige
inhaltliche Gestaltung der Qualifizierungsmaßnahmen, z.B. in Form von Schu-
lungs- oder Vorlesungsunterlagen, ist ebenfalls nicht Bestandteil der Arbeit.
1.3 Vorgehensweise
In Kapitel 2 soll die in Kapitel 1.1 beschriebene Problematik bei der Einführung
von PDM-Systemen genauer analysiert werden. Zunächst wird der Begriff „Pro-
duktdatenmanagement“ abgegrenzt sowie seine strategische Bedeutung und die
Funktionalität heutiger Systeme dargestellt. Eine detailliertere Analyse der in
Kapitel 1.1 angesprochenen Problemfelder sowie Erfahrungen aus bereits durchge-
führten PDM-Einführungen schliessen sich an. Abschließend muss eine theoreti-
sche Betrachtung der Begriffe „Vorgehensmodell“ und „Personalplanung und -ent-
wicklung“ erfolgen. Es ergibt sich ein Katalog von Anforderungen an ein
Vorgehensmodell und das integrierte Personalplanungsinstrument.
In Kapitel 3 werden zunächst bekannte Ansätze zur Einführung von PDM-Syste-
men den Anforderungen gegenübergestellt und hinsichtlich der Anforderungser-
füllung bewertet. Zusätzlich werden Vorgehensmodelle der allgemeinen Software-
entwicklung hinsichtlich ihrer Relevanz für die PDM-Einführung betrachtet.
Daraus resultiert ein Handlungsbedarf, der abschließend konkretisiert wird.
Kapitel 4 beschreibt das entwickelte allgemeine Vorgehensmodell für die
PDM-Einführung. Dabei werden ausgehend von den einzelnen Phasen des
Modells die durchzuführenden Tätigkeiten bestimmt und die zur Unterstützung
dieser Tätigkeiten anwendbaren Methoden beschrieben. Daraus ergeben sich die
notwendigen Kompetenzen der in den einzelnen Phasen der Einführung beteiligten
Rollen (siehe Bild 1-3).
In Kapitel 5 wird eine Methode zur Personalplanung in PDM-Einführungsprojek-
ten beschrieben, mit der Kompetenzprofile aufgenommen und verglichen werden
Seite 8 Kapitel 1
können. Bei der Besetzung der Rollen ergibt sich aus der Differenz zwischen den
notwendigen und vorhandenen Kompetenzen entweder ein Qualifizierungsbedarf
oder die Notwendigkeit der externen Beschaffung. Die Konzeption verschiedener
Maßnahmen der Personalentwicklung zur projektbegleitenden und allgemeinen
beruflichen Qualifizierung für Produktdatenmanagement bilden daher den
Abschluss der Wertschöpfung dieser Arbeit.
Eine Zusammenfassung der Arbeit und ein Ausblick auf weiteren Forschungsbe-
darf erfolgt in Kapitel 6.
Bild 1-3: Vorgehen in der Konzeption: Aus dem Vorgehensmodell ergeben sich
Kompetenzprofile, die als Basis für die Personalplanung und -entwick-
lung dienen
Phase
Phasen Tätigkeiten Methoden Personal-
planung
Kapitel 4
Vorgehensmodell
Kapitel 5
Personalplanung und -entwicklung
Kompetenz-
profile Qualifizierung
Einführung von PDM-Systemen Seite 9
2 Einführung von PDM-Systemen
Ziel dieses Kapitels ist die Erarbeitung der Anforderungen, die an ein Vorgehens-
modell, die Personalplanung und -entwicklung für PDM-Einführungsprojekte zu
stellen sind.
Die speziellen Probleme sind begründet zum einen in der Komplexität des Themas
Produktdatenmanagement an sich und zum anderen in den Rahmenbedingungen,
unter denen die Einführungssprojekte durchgeführt werden. Die Erarbeitung der
Anforderungen geschieht deshalb zunächst in einer detaillierten Analyse dieser
zwei Gebiete (Kapitel 2.1 und Kapitel 2.2).
Es zeigt sich, dass einem geplanten und methodisch unterstützten Vorgehen eine
hohe Bedeutung für den Erfolg zukommt. Ebenso muss der Faktor Mensch beson-
ders beachtet werden. Deshalb schließt sich zur Ableitung allgemeiner und Unter-
mauerung spezieller Anforderungen eine Betrachtung der Begriffe Vorgehensmo-
dell (Kapitel 2.3) sowie Personalplanung und -entwicklung (Kapitel 2.4) an.
Die sich ergebenden Anforderungen werden abschließend in einem Anforderungs-
katalog zusammengefasst (Kapitel 2.5).
2.1 Produktdatenmanagement
Die zunehmende Anzahl an Verfahren1 und dazugehörigen Systemen in der Pro-
duktentwicklung führt zu einem drastischen Anstieg der Informationsmenge, die
von den am Entwicklungsprozess beteiligten Funktionen bewältigt werden muss.
Die Informationen liegen zudem an verschiedenen Stellen im Unternehmen vor.
Die Informationsmenge ist nicht mehr überschaubar und der Zugriff nicht transpa-
rent, d.h. ein Entwickler muss genau wissen, wo die Informationen zu finden sind.
Dies führt dazu, dass in der Produktentwicklung bis zu 30% der Zeit für die Suche
nach den richtigen Informationen aufgewendet wird [Ehr95, S. 465f]. Dabei wird
auch oft auf falsche oder veraltete Daten zugegriffen, was zu Fehlern im Produkt
führen kann [Wen01a, S. 36f]. Darunter leidet nicht nur die Qualität des Produktes.
Langwierige Änderungsprozesse verlängern die Entwicklungszeit und verursachen
zusätzliche Kosten (siehe Bild 2-1).
Abhilfe schaffen hier Produktdatenmanagement (PDM)-Systeme. Sie verwalten
alle relevanten Daten über ein Produkt und die Prozesse der Produktentstehung.
Den Versuch einer exakten Begriffsbestimmung bzw. Definition für „Produktda-
tenmanagement“ unternehmen viele Quellen2. Diese schränken sich aber zumeist
1. Verfahren sind Methoden und Werkzeuge, die zur Unterstützung der Produktentwicklung die-
nen. Sie sind zu unterscheiden von Systemen, die eine Methode im Rechner abbilden oder
Werkzeuge rechnergestützt zur Verfügung stellen. Z.B. ist die Finite Elemente Methode (FEM)
zur Berechnung der Verformung von Bauteilen zunächst ein Verfahren, das allerdings aufgrund
seiner Rechenintensität nur mit Hilfe von Rechnersystemen durchgeführt werden kann.
Seite 10 Kapitel 2
durch eine reine Betrachtung des Begriffs „Produktdatenmanagement“ ein. Das
führt dazu, dass das dahinter stehende sehr umfassende Konzept wenig deutlich
wird. Eine Folge davon ist die Entstehung immer neuer Begriffe für die gleiche
Sache3. Diese ergeben sich auch aus der ständig voranschreitenden Entwicklung
der PDM-Systeme. Anbieter übertreffen sich aus Abgrenzungs- und Marketing-
gründen mit der Erfindung neuer Begriffe für das gleiche Konzept.
Die Funktionalität der PDM-Systeme hat sich in den letzten Jahren von der
CAD-Zeichnungs- bzw. Dokumentenverwaltung über die Lifecycle-Produktdaten-
verwaltung in Richtung eines integrierten Daten- und Prozessmanagements ent-
wickelt [AB93]. Das Ziel der heute angebotenen PDM-Systeme ist die Integration
aller Produktdaten und Dokumente sowie eine durchgehende Unterstützung der
Produkterstellungsprozesse. Dazu verbinden PDM-Systeme spezielle IT-Lösungen
wie digitale Archive, Workflow-Systeme, Stücklistenverwaltungssysteme, E-Mail
etc. konzeptionell und systemtechnisch zu einem abgestimmten Gesamtsystem. Sie
bieten eine umfassende Grundfunktionalität für die Verwaltung von Produktdaten
und Prozessen und integrieren die CAE-Systeme in eine Umgebung. Sie bilden
damit das Rückgrat der virtuellen Produktentwicklung4.
2. U.a. [BHM96, S. 13ff], [Hel99], [Höf99, S. 18ff], [Sch99, S. 91ff], [VDI99, S. 4ff]
Bild 2-1: Durch die zunehmende Datenflut entstehen Fehler im Produkt, die die
Entwicklungszeit verlängern und die Kosten erhöhen
3. Siehe dazu Fußnote 3 in Kapitel 1 und die ausführlichere Diskussion bei [Wen01a, S. 10ff]
4. Darunter wird die vollständige Abbildung und Überprüfung der Eigenschaften eines Produktes
in einem Rechnermodell, dem „Virtuellen Produkt“ verstanden. In der virtuellen Produktent-
wicklung werden Strategien der industriellen Produktentwicklung mit den Innovationen der
Informations- und Kommunikationstechnologien vereinigt. [SK97a, S. 399f]
CAD-Dateien
CAD-Datenbank
DTP-Datenbank FEM-Datenbank
DTP-Daten FEM-Daten
EMV-Dateien
EMV-Datenbank
EMV: Elektromagnetische Verträglichkeit
CAD: Domputer Aided Design
DTP: Desktop Publisher
FEM: Finite Elemente Methode
?
Entwickler
Qualität Zeit Kosten
Einführung von PDM-Systemen Seite 11
Daraus lässt sich folgende Begriffsbestimmung ableiten, die im Folgenden als
Arbeitsdefinition gelten soll:
Produktdatenmanagment ist die strukturierte, ganzheitliche und rechnerge-
stützte Verwaltung aller Produkt beschreibenden Daten sowie der damit ver-
bundenen Prozesse, Verfahren und Daten verarbeitenden Systeme über den
gesamten Produktlebenszyklus.
Entscheidend ist dabei, dass Produktdatenmanagement nicht nur als Technologie
oder „ein weiteres System“ betrachtet werden darf. Vielmehr bedarf es der
Erkenntnis, dass technische Produktdaten die Grundlage der industriellen Produk-
tion darstellen [Stü98]. Konsequentes Umsetzen der Möglichkeiten, die sich aus
dem Einsatz von Produktdatenmanagement ergeben, bedeutet, historisch gewach-
sene Aspekte im Unternehmen in Frage zu stellen [MMH97]. Neben der Neuord-
nung der Systemlandschaft müssen die Prozesse und die verwendeten Verfahren
überdacht und verbessert werden [SV96]. Das hat natürlich auch großen Einfluss
auf die Anforderungen, die an das Vorgehen zur PDM-Einführung zu stellen sind.
Deshalb wird im Weiteren zunächst auf diese strategische Bedeutung von Produkt-
datenmanagement eingegangen, bevor die PDM-Systeme näher betrachtet werden.
2.1.1 Strategische Bedeutung von PDM
Im Folgenden wird die strategische Bedeutung der Umsetzung von Produktdaten-
management in Unternehmen verdeutlicht. Sie ergibt sich aus:
• dem zu vollziehenden Wandel von Denkweisen (Kapitel 2.1.1.1),
• der zentralen Bedeutung der Integration durch PDM (Kapitel 2.1.1.2),
• der Querverbindung von PDM zu strategischen Unternehmenszielen und ande-
ren strategischen IT-Komponenten (Kapitel 2.1.1.3) sowie
• dem hohen erreichbaren aber zum Teil schwer nachweisbaren Nutzen von
PDM-Systemen (Kapitel 2.1.1.4).
Diese Punkte müssen während der Einführung besonders beachtet und vor allem
an alle Beteiligten kommuniziert werden.
2.1.1.1 Paradigmenwechsel durch Einsatz von PDM
Der Einsatz von PDM ist verbunden mit drei wichtigen Paradigmenwechseln5. Sie
erfordern im Umfeld der Einführung einen grundlegenden Wandel6 in den Unter-
nehmen, die noch nicht nach den neuen Denkweisen verfahren. Die damit verbun-
dene Innovation bedeutet für den Einzelnen, gewohnte und zum Teil abgesicherte
5. Ein Paradigma ist ein die Wissenschaft und die Umwelt prägendes Denkmuster. Unter einem
Paradigmenwechsel wird der Wechsel zu einer anderen Betrachtungsweise verstanden [Dud90,
S. 571].
Seite 12 Kapitel 2
Pfade zu verlassen [Gei00]. Daraus entsteht eine Unsicherheit bei den Mitarbei-
tern, die häufig im Zusammenhang mit Informationsdefiziten zu Angst und daraus
resultierend zu Veränderungswiderstand führt [Str00].
Die drei wichtigen Paradigmenwechsel durch den Einsatz von PDM sind der Wan-
del von den:
• Dokumenten- zur Teilezentrierung,
• Funktions- zur Prozessorientierung sowie
• Dokumenten- zur Nachrichtensteuerung.
Auf Grund ihrer Bedeutung und ihres Nutzens, die im Folgenden dargestellt wer-
den, müssen sie im Rahmen der PDM-Einführung schon frühzeitig vermittelt wer-
den.
Wandel von der Dokumenten- zur Teilezentrierung
Die traditionelle Art, Informationen über ein Produkt zu speichern, ist die Zeich-
nung7. Das technische Zeichnen, wie es noch heute verwandt wird, entstand im
Zuge der Industrialisierung. Mit der zunehmenden Leistungsfähigkeit der Rech-
nersysteme konnten zunächst elektronische Zeichenbretter, später Modellierungs-
systeme zur dreidimensionalen Darstellung von technischen Systemen8 entwickelt
werden. Die reine Darstellung der Gestalt ist dabei im Laufe der Entwicklung
durch weitere Typen von Dokumenten ergänzt worden. Abstrakte Funktionsschau-
bilder, elektrische Schaltpläne oder Listen aller zu einem Produkt gehörenden
Bestandteile (Stücklisten) sowie Ergebnisse der diversen Simulationsverfahren der
virtuellen Produktentwicklung9 vervollständigen heute die Dokumentation eines
Produktes.
Die Menge der zu verwaltenden Daten ist dabei enorm gewachsen. Mit Zeichnun-
gen und einer dokumentenorientierten Ablage der Produktinformationen erreicht
man schnell Grenzen, an denen die Menge der Daten nicht mehr handhabbar ist. Es
wird nahezu unmöglich, alle relevanten Dokumente einer Baugruppe zu ermitteln,
geschweige denn, die Abhängigkeiten zwischen den Dokumenten darzustellen
6. Staehle unterscheidet zwei Arten von Wandel. Im Wandel 1. Ordnung sind die Veränderungen
auf einzelne Aspekte beschränkt und Weiterentwicklungen finden im vorherrschenden Bezugs-
rahmen statt. Wandel 2. Ordnung hingegen sind gekennzeichnet durch mehrdimensionale Ver-
änderungen und Paradigmenwechsel [Sta91, S. 829f].
7. Schon die Urzeitmenschen verewigten ihre Erkenntnisse über das Rad oder Hebelmechanismen
in Skizzen auf Höhlenwänden. Aus allen Kulturen, von der Vorzeit über die Antike und das
Mittelalter bis hin zur Neuzeit, sind technische Errungenschaften über Zeichnungen überliefert.
8. Zur Entwicklung von der technische Zeichnung zum 3D-CAD siehe [GEK01, S. 377ff].
9. Z.B. die Mehrkörpersimulation (MKS), Strukturanalyse mit der Finiten Elemente Methode
(FEM) oder computergestützte Strömungsberechnung (Computational Fluid Dynamics, CFD).
Siehe hierzu auch Kapitel 2.1.1.2 sowie [GEK01, S. 419ff] und [SK97a, S. 274ff und S. 290ff].
Einführung von PDM-Systemen Seite 13
[KW99]. Der in den meisten Unternehmen vorherrschende Ansatz zur Dokumen-
tenverwaltung nach DIN6789 [DIN90] erschwert dies zusätzlich. Dabei werden
Dokumente erst dann in die Datenverwaltung eingestellt, wenn sie fertig erstellt
sind. Sie fungieren dann in der Datenverwaltung als „Black-Box“, auf deren innere
Strukturen und somit auf die enthaltenen Verbindungen zu anderen Dokumenten
nicht zugegriffen werden kann [Wir01, S. 28f].
Zudem werden in den Unternehmen die Dokumente abteilungsspezifisch in von-
einander isolierten Systemen verwaltet10 [SK97b].
Um diesem Problem Herr zu werden, wurde in den 80er Jahren eine zweistufige
Konzeption der Datenhaltung erarbeitet, die trotz der rasanten Entwicklung der
Computer- und Datenbanktechnik auch heute noch gilt [Gau87]. Danach wird eine
Trennung der Datenverwaltung in Metadaten- und Dateimanagement praktiziert
(Bild 2-2). Metadaten sind „Daten über Daten“ und Daten über deren Beziehungen
untereinander. Eine Teilenummer, der Name einer Baugruppe, der Dateiname
eines gespeicherten CAD-Modells und der Name des Erstellers eines Datenobjek-
tes sind z.B. Metadaten. Die Zuordnung eines CAD-Modells zu einem Bauteil ist
ein Beispiel für eine Beziehung im Sinne von Metadaten.
Die Metadaten sind in einem Metadatenmodell definiert. Es dient der Abbildung
von Produkt- bzw. Erzeugnisstrukturen11 sowie des Entwicklungsprozesses. Das
Metadatenmodell wird auch als Makro-Modell bezeichnet, weil es eine relativ
grobe Sicht auf das Produktmodell darstellt. Von den Attributen des
Makro-Modells gelangt man zu den so genannten Mikro-Modellen.
Mikro-Modelle sind z.B. 3D-CAD-Modelle, FEM-Rechenmodelle und
NC12-Steuerprogramme. Sie entsprechen den Dokumenten der klassischen Doku-
mentenzentrierung. Einen Vergleich von Metadaten und Dokumenten in Bezug auf
Datenmengen und -verwendung zeigt Tabelle 2-1.
Diese Art der Verwaltung erfordert eine Umstrukturierung des Datenbestandes und
eine Neuordnung der Kriterien, nach denen die Daten strukturiert werden. Das zen-
trale Verwaltungsobjekt ist nun das Teil, d.h. eine rechnerinterne Repräsentation
eines realen Produktbestandteils. Zu diesem sind alle zugehörigen Dokumente
zugeordnet. Dabei besteht keine eindeutige Beziehung zwischen den bisherigen
10. Die Bandbreite reicht von der Ablage der ausgedruckten Dokumente in Dokumentenschränken
oder Ordnern bis zu eigenen rechnergestützten Dokumentenmanagementsystemen (DMS).
11. Nach DIN 199 ist die Produktstruktur ein produktdarstellendes Modell, das die Gesamtheit der
nach bestimmten Gesichtspunkten (z.B. Fertigung, Montage, Funktion, Disposition, Kalkula-
tion) festgelegten Beziehungen zwischen Baugruppen und Einzelteilen eines Produktes
beschreibt. Sie schafft somit den logischen Zusammenhang zwischen dem Produkt und den
Bestandteilen, aus denen es sich zusammensetzt. [DIN77]
12. Numerical Control bzw. Numerische Steuerung bezeichnet die Steuerung von Werkzeugma-
schinen durch Zahlencodes. Ein Programm besteht aus einer Folge von Zahlencodes. Diese ste-
hen für Anweisungen, die von der Maschine durchzuführen sind. [Kie95, S. 270f]
Seite 14 Kapitel 2
Dokumenten und den Teilen, d.h. mehrere Dokumente gehören zu einem Teil bzw.
mehrere Teile können durch ein Dokument beschrieben werden.
Die bestehenden Nummernsysteme, in denen die Zeichnungsnummern zur Identi-
fizierung und Klassifizierung dienen13 und im Mittelpunkt der Datenrecherche ste-
hen, können daher meistens nicht mehr verwendet werden. Ein neues Nummernsy-
stem wiederum muss den neuen Möglichkeiten der Beschreibung, Klassifizierung
und Recherche durch Attribute in den Metadaten Rechnung tragen. Die Teilenum-
Bild 2-2: Metadaten- und Dateimanagement als Kern der Produktdatenverwal-
tung in PDM-Systemen [GEK01, S. 528]
Tabelle 2-1: Vergleich von Metadaten und Dokumenten [ES01, S. 86]
Kriterium Metadaten Dokumente
Speicherbedarf Gering
(Bytes bis wenige Kiloby-
tes)
Hoch bis sehr hoch
(Kilobytes bis zu vielen Me-
gabytes
Typische Codierung Alphanumerische und
Sonderzeichen
Binärfiles
Benutzung zur Selektion
der Dokumente
Ja Nein
Änderung im PDM-System Ja Nein
13. So genannte „sprechende“ Nummern, zur näheren Beschreibung siehe [DIN85] und [Sch99, S.
36ff]. Eine sehr detaillierte Auseinandersetzung mit der Problematik der Nummernsysteme fin-
det sich in [ES01, S. 29ff].
Erzeugersysteme
CAD NC ...
PDM-Datei-Management
CAD-Modelle NC-Programme ...
PDM-Metadatenmanagement
Datenbank
Mikro-Modelle
z.B.
CAD-Modelle
FEM-Rechenmodelle
NC-Programme
Arbeitspläne
...
Produktstrukturen
mit Sichten wie
- Funktionen
- vertriebl. Merkmale
- Montage
Attribute sind z.B.
- ID-Nr.
- Dateiname
- Ersteller
- Arbeitsplan-Nr.
Makro-Modell
Metadatenmodell
FEM-Modelle
FEM
Einführung von PDM-Systemen Seite 15
mer dient lediglich zur Identifizierung. Die Klassifikation geschieht durch die
Attribute im Metadatensatz des Teiles [Dri96] oder die Zuordnung zu einer spezi-
ellen Klassifikationsstruktur auf Basis von Sachmerkmalleisten (SML)14 nach
DIN 4000 [DIN92].
Wandel von der Funktions- zur Prozessorientierung
Die Organisation vieler Unternehmen entspricht heute noch der klassischen durch
Arbeitsteilung und tiefe Hierarchien geprägten Funktionsorientierung nach Taylor.
Im Vordergrund steht die Aufbauorganisation und nicht der eigentliche Leistungs-
erstellungsprozess. Damit sind die Unternehmen allerdings nicht in der Lage, auf
die veränderten Marktgegebenheiten zu reagieren15. Somit rückt eine durchgän-
gige Gestaltung der Gesamtabläufe in den Mittelpunkt der Betrachtung. Der Para-
digmenwechsel von der Funktionsorientierung hin zur Prozessorientierung ist in
Bild 2-3 dargestellt.
Zu den Aufgaben eines Mitarbeiters zählt in der Prozessorientierung nicht mehr
nur die reine Erfüllung einer funktional begrenzten Arbeit. Vielmehr wird die Ver-
antwortung des Einzelnen für den Gesamtprozess und dessen Ergebnis das vor-
herrschende Prinzip. In Zeiten, in denen Unternehmen die Fertigungs- und Ent-
wicklungstiefe reduzieren und sich mehr auf ihre Kernkompetenzen konzentrieren,
gilt dies nicht nur für unternehmensinterne, sondern auch für unternehmensüber-
greifende Prozesse, z.B. in der Zusammenarbeit mit Zulieferern. Dies erfordert
neue Kompetenzen bei den Mitarbeitern sowie veränderte Methoden und Werk-
zeuge [Gei00].
Der Informationstechnik, also auch den PDM-Systemen, kommt dabei eine
erhöhte Bedeutung zu. Erst sie ermöglicht die reibungslose prozessübergreifende
Zusammenarbeit [Bee95]. Somit ist die Einführung von PDM-Systemen eng mit
dem Gestaltungsfeld der Arbeitsorganisation und Prozesse verbunden. Dabei darf
der „Faktor Mensch“ nicht nur willkürlich einbezogen werden, sondern muss
bewusst Bestandteil der Einführung sein16.
14. Diese bilden die Grundlage für leistungsfähige Such- und Retrievalmechanismen in
PDM-Systemen [GEK01, S. 531f]. Neben der Klassifikation des eigengefertigten Teilespek-
trums eines Unternehmens ist es auf diese Weise auch möglich, Bibliotheken mit Normteilen
[SH97] oder Kataloge von Zulieferern [LLH00] in das PDM-System einzubinden und recher-
chierbar zu machen.
15. Z.B. führt eine den heutigen Käufermarkt prägende hohe Variantenvielfalt bei gegebener
Arbeitsteilung zu einem höheren Organisationsaufwand und damit zu höheren Kosten. [GF99,
S. 320f]
16. Siehe hierzu auch die umfangreiche Literatur über die Bedeutung der Ablauforganisation und
der Mitarbeiterqualifizierung bei der Umsetzung des CIM-Ansatzes (Computer Integrated
Manufacturing, z.B. [Bul92], [Spu94], [Wil90].
Seite 16 Kapitel 2
Wandel von der Dokumenten- zur Nachrichtensteuerung
Obwohl die Erstellung von Produktinformationen zum größten Teil mittlerweile
rechnergestützt erfolgt, werden zur Verteilung der Informationen die gleichen
Mechanismen wie zur Zeit der manuellen Zeichnungserstellung verwendet: Doku-
mente werden vervielfältigt und an alle betroffenen Abteilungen oder Partner
geschickt [Man95]. Empfangsbestätigungen sowie Abnahmen oder Zurückweisun-
gen von Änderungen werden über ein papiergestütztes Formularwesen abgewik-
kelt17 [Nor95]. Neben großen zeitlichen Verzögerungen18 entstehen dadurch
erhebliche Kosten19. Ein weiteres Problem entsteht durch die im Unternehmen
Bild 2-3: Paradigmenwechsel von der Funktionsorientierung zur Prozessorien-
tierung [GF99]
17. Ein Beispiel für einen solchen Änderungsschein findet sich in [ES01, S. 67].
18. In einem in Zusammmenarbeit mit dem Lehrstuhl Rechnerintegrierte Produktion durchgeführ-
ten PDM-Einführungsprojekt in der Luftfahrtindustrie betrug die durchschnittliche Verteilzeit
für ein Dokument innerhalb des internationalen Entwicklungskonsortiums ca. vier Wochen.
Arbeitsteilige Ablauforganisation
Paradigma der Funktionsorientierung
Im Vordergrund steht die
Aufbauorganisation
Paradigma der Prozessorientierung
Im Vordergrund steht der
Leistungserstellungsprozess
Durchlaufzeit
Reduzierte Durchlaufzeit
Status feststellen.
Klare Verein-
barungen treffen
und umsetzen.
Status feststellen.
Klare Verein-
barungen treffen
und umsetzen.
Status feststellen.
Klare Verein-
barungen treffen
und umsetzen.
Leistungserstellungsprozess als Einheit
Aufbauorganisation
als Grundordnung
Zielgerichtete enge
Zusammenarbeit als
Grundverständnis
Hohe Qualität des
Endresultats auf
Anhieb
Zeitreduktion
Ausgeprägte Arbeitsteilung
Lange Durchlaufzeiten
Geringe Qualität des Endresultates
im ersten Anlauf
Viele Rückkopplungen
Zufriedener
Kunde
Einführung von PDM-Systemen Seite 17
redundant verteilten Datenbestände [AB93]. Durch den Einsatz von PDM-Syste-
men wird hier ein entscheidender Wandel ermöglicht.
Da der elektronische Zugriff auf den jeweils aktuellen Datenbestand für alle Betei-
ligten durch das PDM-System gesichert ist, werden neue Dokumente und Ände-
rungen nicht mehr in Kopien verteilt, sondern lediglich durch Nachrichten an die
Betroffenen bekannt gemacht. Dies geschieht entweder durch im System integrier-
ten Benachrichtigungsfunktionen und Arbeitslisten oder durch Nutzung des unter-
nehmenseigenen E-Mail-Dienstes. Die Verteilzeit verkürzt sich dadurch auf Minu-
ten. Ist die Versendung von elektronischen Kopien, z.B. aus
Archivierungsgründen, notwendig, dauert auch dies für große CAD-Dateien im
Höchstfall nur einige Stunden.
Das papierbasierte Formularwesen kann durch elektronische Abwicklung ersetzt
werden. Aus Haftungsgründen ist die Verwendung einer digitalen Signatur, die
rechtsgültig eine Unterschrift ersetzen kann, hierfür wie auch für die elektronische
Archivierung eine Voraussetzung20.
Fazit Paradigmenwechsel
Es wird deutlich, dass die konsequente Umsetzung von PDM ein hohes Maß an
Veränderungsbereitschaft im Unternehmen erfordert. Alte Denk- und Handlungs-
weisen müssen überdacht und zum Teil radikal geändert werden. Dies kann zu gro-
ßen Widerständen führen, die bei der Einführungsplanung bedacht werden müssen.
Sie können das Projekt ansonsten sowohl zeitlich als auch in der Zielerreichung
zum Scheitern bringen. Wichtige Maßnahmen sind dabei im Allgemeinen eine
gute Informationspolitik aus dem Projekt heraus und die glaubhafte Vermittlung
des Nutzens, der sich aus der PDM-Einführung ergibt (siehe dazu auch Kapitel
2.1.1.4).
Zusätzlich ergeben sich einige wichtige Aktivitäten, die im Rahmen einer
PDM-Einführung durchzuführen sind. Dazu gehören die Konzeption des Metada-
tenmodells, die Definition einer neuen Prozessorganisation sowie daraus erwach-
send die Beschreibung und Vermittlung der neuen Aufgabenprofile für die Mitar-
beiter.
19. Während der Laufzeit der Dokumentverteilung wurden im o.g. Projekt die zu ändernden Bau-
gruppen weiter auf altem Stand produziert. Die Kosten für die Nachrüstung der Änderungen
bzw. teilweise Verschrottung der falsch gefertigten Baugruppen gingen in Millionenhöhe.
20. Laut eines Schreibens des Bundesfinanzministeriums vom 16. Juli 2001 mit dem Aktenzeichen
IV D2 S0316 - 136/1, den so genannten „Grundsätzen für den Datenzugriff und die Prüfung
digitaler Unterlagen (GDPdU)“, sind Unternehmen ab dem 01. Januar 2002 verpflichtet, alle
digital erstellten Unterlagen auch digital auf maschinenverwertbaren Datenträgern aufzubewah-
ren [Küh01]. Die digitale Signatur, eine Art an das Dokument angehängte digitalen Unter-
schrift, soll dabei für die notwendige Rechtssicherheit über die Authentizität (Echtheit) des
Dokumentes sorgen [Kle01].
Seite 18 Kapitel 2
2.1.1.2 PDM-Systeme als Integrationsdrehscheibe für den
Produktentstehungsprozess
PDM-Systeme bilden das Rückgrat der Informationsverarbeitung für die Produkt-
entwicklung oder branchenabhängig sogar für den gesamten Produktlebenszyklus
[Dri96], [Lin97], [SK97a, S. 255]. Bild 2-4 beschreibt beispielhaft ein derartiges
Szenario. Sämtliche Systeme, die im Rahmen des Produktentstehungsprozesses
verwendet werden, sind über das PDM-System verbunden. Dieses dient als zentra-
ler Zugriff auf die mit den Erzeugersystemen erstellten Daten und als einheitlicher
Startpunkt für die Arbeit mit diesen Systemen21.
Dabei ist für die Verwaltung von CAD-Daten ein zweistufiges Vorgehen erkenn-
bar. Die Daten aus den CAD-Systemen werden zunächst durch einen so genannten
Team Data Manager (TDM) verwaltet. Der TDM ist ein im Lieferumfang des
CAD-Systems zumeist vorhandenes, in der Funktionalität eingeschränktes und
stark auf das spezielle CAD-System ausgerichtetes PDM-System22. Er regelt den
dauernden Zugriff auf die aktuell in Bearbeitung befindlichen zum Teil sehr
Bild 2-4: Beispielszenario für den Einsatz eines PDM-Systems als Rückgrat der
Informationsverarbeitung im Produktentstehungsprozess
21. Dabei werden die Erzeugersysteme aus dem PDM-System heraus gestartet. Dies geschieht, ähn-
lich wie das Starten von Anwendungen im Microsoft Windows Explorer, durch Anklicken der
jeweiligen Datei im PDM-System. Allerdings laufen bei der Integration in ein PDM-System
nach dem Start erhebliche komplexere Abläufe zwischen PDM-System und Erzeugersystem ab,
als nur die Übergabe der entsprechenden Datei. Eine ausführliche Beschreibung der hier mögli-
chen Integrationsarten beschreibt [ES01, S. 178ff].
22. Man bezeichnet ein TDM auch als „lokales PDM“ (L-PDM). [ES01, S. 216]
Team Data Manager (TDM)
Computer Aided Design (CAD) Simulation
Digital
Mock-Up
Office
PlottenScannenLegacy
Viewer
Produktdatenmanagement
Technische
Dokumentation
Enterprise
Ressource
Planning
Daten-
austausch
Archivierung
Einführung von PDM-Systemen Seite 19
umfangreichen CAD-Daten. So können die Netzlast und damit die Zugriffszeiten
der zahlreichen anderen Systeme auf das PDM-System reduziert werden [Ste97].
Das PDM-System verwaltet, neben den freigegebenen Daten aus der CAD-Umge-
bung, die Daten aus den Office-Systemen23, z.B. Textverarbeitung oder Tabellen-
kalkulation, und aus so genannten Legacy-Systemen24. Zusätzlich steuert es
zumeist mit Hilfe von Zusatzmodulen den Zugriff von Ein- und Ausgabegeräten25
wie Scannern oder Plottern und die Archivierung [Hes99], [HM00a], [HM00b],
[Mal97a]. Dadurch ist es möglich, auch nur in Papierform vorliegende Daten in
das System zu migrieren26 [Mal97b], [Mül00b], [Sch98c].
Mit Hilfe plattformunabhängiger Betrachtungsprogramme (Viewer) können alle
Unternehmensbereiche Daten, auf die sie vorher aufgrund der fehlenden Software
nicht zugreifen konnten27, betrachten und über die integrierten Redlining-Funktio-
nen28 Änderungsvorschläge und andere Hinweise anbringen [Nik99], [Nik00].
Die Technische Dokumentation29 enthält viele Daten und Darstellungen, die in
vorgelagerten Entwicklungsbereichen erstellt werden. Ein Zugriff über das
PDM-System erlaubt einen hohen Grad an Wiederverwendung und garantiert aktu-
elle und freigegebene Daten.
Zur Absicherung der Produkteigenschaften werden in der virtuellen Produktent-
wicklung zunehmend rechnergestützte Simulations- und Berechnungsverfahren
verwendet30. Dazu gehören unter anderem die Mehrkörpersimulation (MKS)31
23. Hier konkurrieren PDM-Systeme mit den reinen Dokumentenmanagementsystemen (DMS).
Ein Vergleich vom PDMS und DMS zeigt, dass die Funktionen des DMS meistens vollständig
vom PDMS übernommen werden können. Im Gegensatz dazu werden die hohen Anforderungen
an die Verwaltung technischer Daten von den DMS nicht erfüllt. [Fis99]
24. Alte Systeme, z.B. auf Host-Rechnern, die nicht mehr weiterentwickelt werden, aber aus Renta-
bilitätsgründen noch im Einsatz sind. [Hub00]
25. Diese Funktionen werden auch als Input-/Outputmanagement bezeichnet. Siehe dazu auch
[ES01, S. 126ff].
26. Der Begriff Migration stammt ursprünglich aus der Biologie und Soziologie. Er bezeichnet dort
den Wirtswechsel niederer Lebewesen von einer Pflanzengattung zur nächsten bzw. die Wande-
rung oder Bewegung von Individuen und Gruppen im geographischen oder sozialen Raum, die
mit einem Wechsel des Wohnsitzes verbunden ist [Dud90, S. 499]. Hier bezeichnet er die dau-
erhafte Übertragung alter Datenbestände auf andere Datenträger bzw. in andere Datenbanken.
27. Nicht an jedem Arbeitsplatz ist z.B. die teure CAD-Software verfügbar. Die im PDM-Umfeld
verwendeten Viewer sind entweder web-basiert oder auf Windows- und Unix-Betriebssystemen
verfügbar. Sie können die CAD-Dateien entweder direkt oder über die Konvertierung in ein
neutrales Format darstellen.
28. Darunter versteht man die Möglichkeit, die dargestellten Produktdaten in einem Viewer mit
Hilfe von einfachen Zeichen- und Schreibfunktionen zu kommentieren. Die Kommentare wer-
den dabei zumeist auf einer eigenen Zeichenebene gespeichert.
29. Die Technische Dokumentation sind Unterlagen, die ein Unternehmen zusammen mit dem Pro-
dukt (Montage- und Bedienungsanleitungen, Service- und Reparaturanweisungen, Ersatzteilka-
taloge) oder zu Verkaufszwecken (Prospekte, Kataloge, Preislisten und Datenblätter) den Kun-
den zur Verfügung stellt. Sie wird zumeist von einer technischen Redaktion erstellt [Bie98].
Siehe hierzu auch [ES01, S. 118ff].
Seite 20 Kapitel 2
und die Finite Elemente Methode (FEM)32. Um diese Untersuchungen durchfüh-
ren zu können, ist es zum einen notwendig, Gestaltsdaten für die Simulation bereit-
zustellen und zum anderen die entstehenden Simulations- und Berechnungsergeb-
nisse im PDM-System abzuspeichern [BK97].
Die Verknüpfung von Gestaltsdaten mit Ergebnissen von Simulationen und
Berechnungen resultiert in einem digitalen Versuchsmodell, dem so genannten
Digital Mock-Up (DMU)33. Dabei ist es natürlich wichtig, dass die verknüpften
Daten auch zusammenpassen, d.h. der gleichen Konfiguration und dem gleichen
Stand entsprechen. Dabei spielen PDM-Systeme die entscheidende Rolle
[VVB+98]. Laufende Entwicklungen bringen eine noch engere Verknüpfung von
PDM und DMU. Das digitale Gestaltsmodell des Produktes dient hier zur Naviga-
tion in den Produktdaten. Das vereinfacht im Vergleich zur herkömmlichen Art der
Navigation durch einen Produktstrukturbaum den Zugriff auf die Produktdaten vor
allem bei sehr komplexen Produkten wie Flugzeugen oder bei Anlagen [Row98].
Bild 2-5 zeigt ein Beispiel für eine solche Navigation im DMU einer Kraftwerks-
anlage.
Entscheidende Bedeutung in dem dargestellten Integrationsszenario hat die Ver-
bindung des PDM-Systems mit der betriebswirtschaftlichen Datenverwaltung
(ERP = Enterprise Ressource Planning). Hier müssen zum Teil gleiche Daten
verwaltet werden34, die sich lediglich durch ihren Stand unterscheiden. Datenab-
gleich und -austausch müssen eindeutig definiert und gesteuert werden. Da es sich
bei ERP-Systemen um strategische IT-Komponenten handelt, wird diese Proble-
matik in Kapitel 2.1.1.3 weiter vertieft.
PDM-Systeme sind auch die Basis für einen geregelten Datenaustausch zwischen
verschiedenen Unternehmen, die entweder in einer Zulieferer-Lieferanten-Bezie-
hung stehen oder Entwicklungspartner sind. Zum einen werden CAD-Daten ausge-
tauscht, bei denen die PDM-Systeme die Kontrolle und Protokollierung der über-
tragenen Versionen und Konfigurationen übernehmen. Zum anderen werden im
30. Davon erhofft man sich vor allem eine Kostenersparnis durch Verzicht auf teure physikalische
Prototypen bzw. durch Verbesserung und damit Reduzierung dieser Prototypen durch vorherige
Überprüfung im Rechner („Do it right the first time“). [GS98]
31. Sie dient zur Untersuchung des Bewegungsverhaltens von komplexen Systemen. Damit können
u.a. Kollisionen von Bauteilen rechtzeitig erkannt, das Schwingungsverhalten überprüft und auf
das System wirkende Kräfte ermittelt werden. [GEK01, S. 425ff]
32. Sie dient vor allem zur Ermittlung des Bauteilverhaltens aufgrund äußerer Lasteinflüsse.
Dadurch werden Verformungen und mögliches Bauteilversagen vorhersagbar. Eine der komple-
xesten dieser Untersuchungen ist die Crash-Analyse in der Automobilindustrie. [GEK01, S.
439ff]
33. Synonym werden auch die Begriffe Virtuelles Produkt, Electronic Design, Electronic Defini-
tion, Electronic Mock-Up, Virtual Mock-Up und Paperless Engineering verwendet. [SK97a, S.
400]
34. U.a. Artikelstämme, Sachmerkmalleisten, Stücklisten, Arbeitspläne, Prüfpläne. [JS96]
Einführung von PDM-Systemen Seite 21
PDM-System gespeicherte Metadaten wie Artikelstammsätze und Produktstruktu-
ren im Austausch benötigt. [GHI+00]
Fazit PDM-Systeme als Integrationsdrehscheibe
Die weitreichenden Integrationsfähigkeiten von PDM-Systemen erfordern bei
deren Einführung neben der Analyse der bestehenden Systemlandschaft vor allem
die Beteiligung der verantwortlichen Experten des Unternehmens für die verschie-
denen Systeme. Außerdem sind viele der genannten Systemwelten in den Unter-
nehmen als Insellösungen, d.h. nicht oder nur sehr locker integriert35. Die Grenzen
müssen bei der Definition einer neuen Systemarchitektur aufgelöst und die
Systeme enger zusammengeführt werden.
2.1.1.3 Querverbindungen von PDM zu anderen strategischen
IT-Komponenten und strategischen Unternehmenszielen
Das Integrationsszenario aus Kapitel 2.1.1.2 zeigt, dass bei der Einführung von
PDM-Systemen auch andere Komponenten der strategischen Informationstechno-
Bild 2-5: Navigation durch die Produktdaten im Digital Mock-Up einer Kraft-
werksanlage [GBK+00]
35. Zu Integrationsmodellen für CAE-Werkzeugen siehe [Hah98, S. 23ff]
Seite 22 Kapitel 2
logie betroffen sind. Neben den dort schon angesprochenen Systemen zum Enter-
prise Ressource Planning (ERP)36 gehören dazu noch Groupware-Systeme und
seit der rasanten Kommerzialisierung des Internets auch Systeme aus dem Umfeld
des so genannten e-Business. Diese drei IT-Komponenten und ihre Verbindung
zum PDM werden im Folgenden dargestellt.
Strategische IT-Komponente Enterprise Ressource Planning (ERP)
ERP-Systeme bilden in den meisten Unternehmen den Kern der betriebswirtschaft-
lichen Datenverarbeitung. Wie schon angedeutet, verwalten sie zum Teil gleichar-
tige Daten wie die PDM-Systeme. Dies gilt insbesondere für den Bereich der Pro-
duktionsplanung und -steuerung (PPS)37. Es wird deshalb oft die Frage
aufgeworfen, warum zusätzlich zum bestehenden ERP-System überhaupt ein
PDM-System eingeführt werden soll, anstatt das ERP-System auch in der Ent-
wicklung zu nutzen. Es gibt zwei Hauptgründe, die hier für den zusätzlichen Ein-
satz eines PDM-Systems sprechen: die Entstehung und Verwendung von Metada-
ten und Produktstrukturen sowie die unzureichenden Integrationsfähigkeiten der
ERP-Systeme.
Die Metadaten und Produktstrukturen im ERP-System sind fertigungsorientiert
und dürfen aus Gründen der Haftung und Nachvollziehbarkeit nicht mehr änderbar
sein, da nach ihnen ausgelieferte Produkte gefertigt werden. In der Entwicklung
werden zusätzliche Metadaten und andere Sichten auf die Produktstruktur benötigt
(z.B. funktionsorientierte Sicht). Diese unterliegen noch ständigen Änderungen
[BB96]. Das Zusammenspiel zwischen PDM und ERP über den zeitlichen Ablauf
zeigt Bild 2-6.
Das PDM-System ist dabei das führende System für die Produktstrukturen und den
entwicklungsrelevanten Teil der Metadaten. In ihm entsteht die erste Produktstruk-
tur während der Produktplanung und wird während der weiteren Entwicklung ver-
feinert. Erst ein abgeschlossener, geprüfter und freigegebener Stand wird dann in
das ERP-System übertragen und dient dort als Basis für die Fertigung. Unter
Umständen können auch Metadaten aus dem ERP-System zurück übertragen wer-
den, wenn sie den Konstrukteur bei Entwicklungsentscheidungen unterstützen38.
Als Orientierung für die Kopplung dienen die Prozesse, in denen die Übergänge
eindeutig zeitlich und inhaltlich definiert werden müssen [JS96]. Dabei kann es je
nach Art der Geschäftsprozesse eines Unternehmens zu einer unterschiedlichen
Arbeitsteilung zwischen PDM und ERP kommen (siehe Bild 2-7). Eine redundante
36. Die weltweit am weistesten verbreiteten Systeme sind hier SAP R/3 der SAP AG, Waldorf und
die Oracle Application Suite 11i der Oracle Corporation, Redwood Shores, USA.
37. Zur Funktionalität von PPS-Systemen siehe [GF99, S. 411ff].
38. Z.B. Kosten oder Lagerbestände.
Einführung von PDM-Systemen Seite 23
Datenhaltung ist dabei selten zu vermeiden und durch organisatorische und
systemtechnische Maßnahmen zu steuern und zu kontrollieren [KB00].
ERP-Systeme weisen nur eine unvollständige Funktionalität zur Integration von
CAE-Werkzeugen auf. Außerdem existieren nur wenige zumeist unzureichende
Schnittstellen zu den Erzeugersystemen. Zudem fehlt es den ERP-Herstellern an
Engineering Know-how, um ihre Systeme entsprechend zu verbessern39 [Mül00a].
Bild 2-6: Zusammenspiel zwischen CAE, ERP und PDM-Systemen [Vaj97]
Bild 2-7: Optionen der Arbeitsteilung zwischen ERP und PDM [ES01, S. 209]
39. Die ERP-Hersteller und hier insbesondere die SAP AG, Walldorf unternehmen große Anstren-
gungen, um dieses Defizit aufzuarbeiten [SL98]. Die mittlerweile angebotenen PDM-Module
sind aber noch in der Entwicklung und werden z.Zt. nur wenig eingesetzt. Eine Aussage über
die erzielte Verbesserung ist deshalb nicht möglich.
CAE
Fertigen bestimmter Versionen
ERP
PDM
Zeit
Erzeugen
Ändern
Versionieren
Ändern
Versionieren
Archivieren
Das unterstützt
Erzeugen, Ändern, Versionieren
und Archivieren von Produkt-
strukturen.
PDM-System
Das unterstützt
Fertigung (”Materialisierung”)
und Verteilung bestimmter
Versionen der Produkt
ERP-System
struktur.
Die modellieren
das Produkt und erzeugen damit
die Elemente der Produktstruktur.
CAE-Systeme
CAE: Computer Aided Engineering
ERP: Enterprise Ressource Planning
PDM: Produktdatenmanagement
Weitgehende
Funktionalität
im PDM
Geringe PDM-
Funktionalität
im ERP
Hohe PDM-
Funktionalität
im ERP
Geringe
Funktionalität
im PDM
PDM-System
hält alle
technischen Daten
Verteilung 1
(PDM Max)
PDM-System
hält alle
Engineering Daten
Verteilung 2
(verteilte Zuständigkeit)
PDM-System
hält nur
Konstruktionsdaten
Verteilung 3
(PDM Min)
Seite 24 Kapitel 2
Deshalb entscheiden sich die meisten Unternehmen für eine so genannte
Zwei-System-Strategie, d.h. die Einführung eines PDM-Systems zusätzlich zum
existierenden ERP-System [Sch97], [Sch98d].
Strategische IT-Komponente Groupware
Unter Groupware versteht man verschiedene Typen von IT-Systemen, die die
Kommunikation, Kooperation und Koordination von Gruppen unterstützen40. Man
kann diese danach unterscheiden, ob die Zusammenarbeit der Teammitglieder ört-
lich und zeitlich zusammen oder getrennt stattfindet (siehe Bild 2-8).
Spezielle Groupware-Systeme integrieren die verschiedenen Funktionen wie
E-Mail, Kalender, To-Do-Listen, Dokumentendatenbanken und Workflows41.
Damit bieten sie die Funktionalität für die Organisation der täglichen Arbeit
sowohl des einzelnen Mitarbeiters als auch des Teams. Sie ergänzen bzw. über-
schneiden sich damit in der Funktionalität mit PDM-Systemen [Wie98].
Eine besondere Bedeutung kommt der Unterstützung der Kommunikation und
Kooperation der Anwender untereinander bei verteilten Entwicklungs- und Ferti-
gungsstandorten zu. Auch PDM-Systeme bieten deshalb E-Mail- und Groupware-
funktionen, z.B. zum Senden von Nachrichten oder - eine der Hauptfunktionen von
PDM - zum gemeinsamen Zugriff auf die Produktinformationen. Dabei werden in
der Regel für die E-Mail-Funktionen die in den Unternehmen vorhandenen
40. Der Begriff Groupware ist aufgrund des Wandels, in dem sich das Forschungsgebiet des koope-
rativen Arbeitens (Computer Supported Cooperative Work (CSCW)) befindet, noch nicht ein-
heitlich definiert. Es existieren verschiedende Systematisierungs- und Erklärungsansätze
[FHD+00, S. 238ff]. Im Rahmen dieser Arbeit sollen alle Systeme zur Unterstützung des
kooperativen Arbeitens als Groupware verstanden werden.
Bild 2-8: Groupware-Typen und -Werkzeuge
41. Die bekannstesten Groupware-Systeme sind Microsoft Exchange der Microsoft Corporation,
Redmond, USA und Lotus Notes der Lotus Development Corporation, Cambridge, USA.
- E-Mail-Systeme
- Voice-Mail-Systeme
- Systeme für Electronic Conferencing
- Electronic Bulletin Boards
- Shared Information Systems
- Workflow-Systeme
- Terminkalendermanagement für
Gruppen
- Projektmanagement-Systeme
- Audio- und Videokonferenzsysteme
- Screen-Sharing-Systeme
- Mehrautorensysteme
- System zur computerunterstützten
Sitzungsmoderation
- Präsentationssysteme
- Group Decision Support Systems
Zusammenarbeit
der Gruppe zu gleicher Zeit zu verschiedenen Zeiten
am gleichen Ort
an verschiedenen
Orten
Einführung von PDM-Systemen Seite 25
E-Mail- oder Groupware-Systeme angebunden, während für die Verwaltung der
Produktinformationen die PDM-Systeme genutzt werden42. Dies liegt vor allem
daran, dass Groupware-Systeme zumeist dokumentenorientiert arbeiten und das
für PDM prägende Paradigma der Teileorientierung nicht unterstützen. Außerdem
ist keine oder nur eine sehr lose Kopplung zu den CAE-Systemen möglich.
Wie bei den ERP-Systemen wird deutlich, dass eine exakte Abgrenzung notwendig
ist: Welche Daten und Funktionen werden von welchem System verwaltet bzw.
bereitgestellt? Welches System steuert das andere?
Strategische IT-Komponente e-Business
Allgemein wird unter e-Business (Electronic Business) die elektronische Abwick-
lung sämtlicher interner und externer Geschäftsprozesse mit Hilfe der Standards
und Quasi-Standards des Internets43 verstanden. Die dazugehörigen Bausteine
zeigt Bild 2-9. Für jeden dieser Bausteine existieren auf dem Markt spezielle
Systeme, die von einigen Unternehmen eingeführt werden. Allerdings ist unbestrit-
ten, dass PDM-Systeme zentraler Bestandteil des Bausteins „Business Information
Management“ sind, weil sie die Quelle für alle produktbeschreibenden Daten und
Dokumente sind [ZAS00b]. Insbesondere für die erklärungsbedürftigen Produkte
des Maschinenbaus spielen sie jedoch auch in den Bausteinen e-Commerce, Sup-
ply Chain Management und Customer Relationship Management eine wichtige
Rolle. Dies wird im Weiteren erläutert.
Für den elektronischen Handel (e-Commerce) zwischen Unternehmen44 sind
neben den produktbeschreibenden Daten vor allem die im PDM-System gespei-
cherten Konfigurations- und Klassifikationsdaten von Bedeutung. Auf dieser Basis
können zum einen Produktkataloge und komplexe Produktkonfiguratoren für den
Kunden bereitgestellt werden45. Zum anderen stellen die PDM-Systeme die Klas-
sifizierung von Produkten zur Verfügung, die zur Integration der elektronischen
Produktkataloge in so genannten elektronische Marktplätze46 notwendig ist47.
42. Neuere Entwicklungen integrieren zusätzlich Funktionen wie Videokonferenz oder so genannte
Shared Whiteboards. Letztere ermöglichen es, dass mehrere Anwender gleichzeitig von geogra-
phisch verteilten Orten Grafiken, 3D-Modelle und Texte wie auf einer gemeinsamen Wandtafel
betrachten und verändern können. [GEK01, S. 532]
43. U.a. das Transmission Control Protocol/Internet Protocol (TCP/IP), das World Wide Web
(WWW) mit dem Hypertext Transfer Protocol (HTTP) und der Hypertext Markup Language
(HTML), das File Transfer Protocol (FTP), die Programmiersprache Java und als neueste Ent-
wicklung die eXtensible Markup Language (XML). [SS97, S. 42ff], [HS99, S. 16ff], [Kra99, S.
17ff]
44. Man bezeichnet diese Art des e-Commerce auch als „Business-to-Business“ (B2B). Dabei han-
delt es sich bei den Produkten zumeist um Zulieferkomponenten und Anlagen. B2B muss vom
Handel mit Konsumgütern zwischen Unternehmen und Verbrauchern, dem so genannten „Busi-
ness-to-Consumer“ (B2C) und anderen unterschieden werden. Eine Übersicht über die mögli-
chen Markt- und Transaktionsbereiche gibt [HS99, S. 22ff].
Seite 26 Kapitel 2
Diese dient dort als Basis für die Suche nach Produkten aus Katalogen verschiede-
ner Anbieter [GKP+98].
Wird die Rechnerunterstützung der internen Wertschöpfungskette eines Unterneh-
mens dahingehend erweitert, dass auch die externen Prozesse mit Kunden und Lie-
feranten einbezogen werden, spricht man von Supply Chain Management
(SCM). Die bestehenden Ansätze, das SCM zu unterstützen, sind allerdings stark
logistisch orientiert, d.h. sie berücksichtigen nur die reinen Beschaffungs- und
Vertriebsprozesse und vernetzen zur Integration die bestehenden ERP-Systeme der
Unternehmen [HS99, S. 124]. Erweitert man den Ansatz um die gemeinsame
45. Die Produktstruktur mit den Beziehungen zwischen den Baugruppen und den damit verbunde-
nen Regeln ist die Grundlage für die Konfiguration. An die Produktstruktur gehängte Doku-
mente dienen zur Visualisierung des konfigurierten Produktes im Verkaufsprozess, z.B. von
erklärungsbedürftigen komplexen mechatronischen Produkten. [Gra00, S. 70ff u. 104ff]
46. Als elektronische Marktplätze werden - im Gegensatz zum direkten elektronische Handel zwi-
schen zwei Geschäftspartnern - Plattformen verstanden, auf denen mehrere Anbieter und Nach-
frager von Produkten oder Dienstleistungen ihre Einkaufs- bzw. Vertriebsaktivitäten zusam-
menführen. Damit soll zum einen eine Abnahme des Organisationsaufwandes zur Etablierung
elektronischer Geschäftsbeziehungen und zum anderen eine effektive Koordination von Ange-
bot und Nachfrage erreicht werden [Wen01b]. Eine bedeutende Initiative in diesem Bereich ist
GEN (Global Engineering Networking), an der auch der Lehrstuhl Rechnerintegrierte Produk-
tion am Heinz Nixdorf Institut, Universität Paderborn beteiligt ist (siehe hierzu u.a. [Gau96],
[Gau97]).
47. Ein Konzept für den notwendigen Datenaustausch zwischen PDM-System und elektronischen
Marktplatz auf Basis der eXtensible Markup Language (XML) beschreibt [GLK+99].
Bild 2-9: PDM ist wesentlicher Bestandteil des e-Business Bausteins „Business
Information Management“ [ZAS00b]
e-Commerce
Business
Information
Management
Customer
Relationship
Management
Supply Chain
Management
Enterprise
Resource
Management
e-Business
Einführung von PDM-Systemen Seite 27
unternehmensübergreifende Produktentwicklung („e-Engineering“), spielen wie-
derum PDM-Systeme eine große Rolle. Sie müssen gewährleisten, dass alle Ent-
wicklungspartner auf der gleichen Konfiguration eines Produktes im aktuellen
Stand arbeiten. Sind in den Unternehmen unterschiedliche Anwendungssysteme
vorhanden, muss eine gesteuerte Konvertierung von Daten stattfinden. Räumliche
Entfernungen werden durch CSCW-Werkzeuge (siehe Abschnitt Groupware)
überbrückbar.
Für das so genannte Customer Relationship Management (CRM)48 gibt es ein
Portfolio an unterstützenden Softwareanwendungen. Für erklärungsbedürftige
technische Produkte sind viele dieser Anwendungen nicht ohne die Verbindung zu
PDM-Systemen möglich [Mei01]. So reicht es zumeist nicht aus, ein Produkt für
sich zu verkaufen. Kundenzufriedenheit und damit Kundenbindung erzeugen erst
zusätzlich angebotene Dienstleistungen [HS99, S. 274ff]. Dazu zählen, neben der
Bereitstellung zusätzlicher multimedial aufbereiteter Produktinformation über das
Internet, auch die Wartung und Reparatur von Anlagen („e-Services). Dafür müs-
sen die Produktinformationen aus dem PDM-System zur Verfügung stehen49. Die
Möglichkeit des Rückflusses von Informationen aus der Wartung in die Entwick-
lung, z.B. über Ausfallhäufigkeiten von Teilen, ermöglicht die ständige Produkt-
verbesserung, die wiederum den Kundennutzen erhöht [Sch00b].
Weitere strategische Unternehmensziele
Neben dem großen gegenseitigen Einfluss, den PDM und die oben genannten stra-
tegischen IT-Komponenten aufeinander haben, gilt es auch zu beachten, wie PDM
allgemeine strategische Unternehmensziele unterstützt. Einen Überblick hierzu
zeigt Tabelle 2-2. Die PDM-Funktionen, die hier zur Unterstützung dienen, wer-
den in Kapitel 2.1.1.2 und Kapitel 2.1.2 zum größten Teil erläutert und müssen hier
nicht weiter vertieft werden. Auch so wird die hohe strategische Bedeutung von
PDM bereits deutlich.
Zusätzlich betonen viele Autoren die große Bedeutung, die PDM zur Bewältigung
der Risiken und Ausnutzung der Chancen bietet, die sich durch die zunehmende
Globalisierung der Wirtschaft ergeben50 [FJS98], [Hes00].
48. Auch Kundenbindungsmanagement genannt: Ganzheitlicher Ansatz zur Integration und Opti-
mierung sämtlicher kundenbezogener Prozesse innerhalb eines Unternehmens. [IDS01, S. 26]
49. Das kann so weit gehen, dass für bestimmte, z.B. sicherheitsrelevante, Baugruppen nicht nur
bekannt sein muss, was grundsätzlich für Teile eingebaut wurden, sondern sogar genau die Seri-
ennummer des in einer Anlage eingebauten Teils.
50. Z.B. ermöglicht bei Ford der Einsatz von Produktdatenmanagement eine so genannte 24-Stun-
den-Entwicklung. Entwicklungsgruppen in verschiedenen Zeitzonen der Erde arbeiten dabei
rund um die Uhr an der Entwicklung eines Motors. Die Zeit vom anfänglichen Konzept zur
Serienreife kann dadurch erheblich verkürzt werden und ein innovatives Produkt frühzeitig am
Markt angeboten werden. Dadurch entsteht ein Wettbewerbsvorteil. [Has00]
Seite 28 Kapitel 2
Fazit strategische IT-Komponenten und Unternehmensziele
Es wird deutlich, dass PDM-Systeme je nach eigenem Funktionsumfang andere
strategische IT-Komponenten ergänzen oder teilweise bzw. ganz ersetzen können.
Inwieweit dies im Rahmen der Einführung geschieht, muss unternehmensspezi-
fisch geprüft und entschieden werden. Produktdatenmanagement als Konzept
erfordert nicht zwingend die vollständige Ablösung aller Systeme durch ein
PDM-System. Es bedeutet vielmehr, die Stärken der Systeme auszunutzen und
diese über die Prozesse zu integrieren. So entsteht ein schlüssiges Gesamtsystem,
in dem über Schnittstellen und Regeln die Konsistenz der Daten sowie die Trans-
parenz51 des Zugriffs auf diese gesichert ist. Weiterhin ist es notwendig, die beste-
henden inhaltlichen und zeitlichen Abhängigkeiten zwischen den strategischen
IT-Projekten zu dokumentieren und Zwischenergebnisse abzustimmen [VDI99, S.
11]52.
Tabelle 2-2: PDM unterstützt eine Reihe von strategischen Unternehmenszielen
[SK97a, S. 251]
Unternehmensziele Konsequenz PDM-Unterstützung
Schlankes Unternehmen Flache Hierarchien Teamorientierte
Produktentwicklung
Flexible Produktpalette Dynamische Prozesssteue-
rung
Workflows,
Klassifizierung
Kundenspezifische
Produktion
Rückfluss der Kunden-
wünsche,
Variantenproduktion
Versions- und Änderungs-
management
ISO 9000 Qualitätsma-
nagement
Erweiterte (zeitliche) Produkt-
und Qualitätsanforderungen
Langzeitarchivierung,
STEP,
Archivierung
DIN 4000
Sachmerkmalleisten
Bessere Klassifizierung von
Objekten,
Wiederauffinden von Norm-/
Wiederholteilen
Erweiterte SML,
verknüpfte Suchbegriffe,
kurze Suchzeiten
Integration aller
Produktionseinheiten
Unternehmensweite Verfüg-
barkeit aller Informationen
Metadaten- und Konfigura-
tionsmanagement
Time to Market Kosten-/Durchlaufzeit verrin-
gern
Unterstützung/Integration
aller Bereiche
51. Transparenz bedeutet hier, dass der Benutzer nicht wissen muss, wo genau die Daten gespei-
chert sind, also in welcher Datenbank oder welchem Verzeichnis. Das System erlaubt ihm den
Zugriff über die Metadaten und stellt sicher, dass er den richtigen Stand zur Verfügung hat.
52. Dies kann z.B. durch die Aufstellung eines so genannten IT-Masterplans geschehen. In ihm sind
frühzeitig auch die Verantwortlichen für die Projekte und die Integration festzulegen. [Fri96]
Einführung von PDM-Systemen Seite 29
Aufgrund der hohen strategischen Bedeutung von PDM ergibt sich die Notwendig-
keit, die PDM-Einführung in einen übergeordneten Prozess der Strategiefindung
und -kontrolle einzubinden. D.h. konkret, dass aus der allgemeinen Unternehmens-
strategie und der IT-Strategie Zielvorgaben für die PDM-Einführung erwachsen53,
deren Erfüllung im weiteren Verlauf der Einführung und während des anschließen-
den Betriebes anhand von Kennzahlen überprüft werden muss. Außerdem ist es
unerlässlich, dass das Projekt durch das Top-Management, also auf Ebene von
Geschäftsführung oder Vorstand, unterstützt und vorangetrieben wird. Diese
Unterstützung wird allgemein als einer der wichtigsten Erfolgsfaktoren für die
PDM-Einführung angesehen54.
2.1.1.4 Nutzenpotentiale von PDM-Systemen
Der mit der Einführung von PDM erreichbare Nutzen durch Kosteneinsparungen,
Zeitverkürzungen und Qualitätsverbesserungen ist allgemein anerkannt und wird
für die meisten betroffenen Unternehmensbereiche als hoch bis sehr hoch einge-
schätzt (siehe Bild 2-10) [Wen01a, S. 96ff]. Dabei wird zwischen direktem und
indirektem Nutzen unterschieden [VS97].
Direkter Nutzen entsteht rein operativ durch Kosteneinsparungen oder Produktivi-
tätssteigerungen im eigentlichen Funktionsbereich des PDM-Einsatzes. Indirekter
53. „IT follows Strategy“ oder „IT follows Business“. [Ber99]
54. Siehe dazu u.a. [ES01, S. 287], [KM95], [LK96], [RK01], [Wen01a, S. 42].
Bild 2-10: Der Nutzen von PDM wird im Allgemeinen als hoch bis sehr hoch ein-
geschätzt [Wen01a, S. 97]
0% 10% 20% 30% 40% 50% 60% 70% 80% 90% 100%
Kundendienst/Wartung
Fertigung und Montage
Fertigungsvorbereitung
Materialeinkauf
Dokumentation/Normung
Änderungskonstruktion
Neukonstruktion
sehr stark
stark
weniger stark
schwach
gar nicht
keine Angabe
Stärke des Nutzens (Anteil der Befragten)
Seite 30 Kapitel 2
Nutzen ergibt sich dagegen speziell aus der in Kapitel 2.1.1.3 dargestellten hohen
strategischen Bedeutung von PDM. Eine Zuordnung einzelner Nutzenaspekte zu
direktem und indirektem Nutzen ist aber nicht immer eindeutig möglich [Höf99, S.
37]. Wie bei vielen anderen strategischen Lösungen sind außerdem die indirekten
Nutzenpotentiale sehr vielschichtig und lassen sich zum Teil überhaupt nicht oder
nur sehr schwer messen [Wen01a, S. 96]. Bild 2-11 verdeutlicht die Problematik
beispielhaft an Hand einiger Nutzenpotentiale, die durch PDM entstehen kön-
nen55. Es kommt hinzu, dass der Nutzen oft nicht dort im Unternehmen entsteht,
wo der Aufwand, z.B. für mehr Datenpflege, anfällt.
Die gesamte Nutzenbetrachtung wird dadurch erschwert, dass die PDM-Einfüh-
rung nicht nur die Systemeinführung beinhaltet, sondern vor allem auch eine orga-
nisatorische Herausforderung darstellt56. Ohne die entsprechende Anpassung der
Geschäftsprozesse wird zum Teil gar kein Nutzen erzielt [SV96]. Eine genaue
Ermittlung, welchen Beitrag das System z.B. zu einer Entwicklungszeitverkürzung
beträgt, ist daher selten möglich [Wen01a, S. 97]. Daneben existieren Herausforde-
rungen, wie z.B. die Beherrschung der Datenflut oder die Nachweispflicht durch
Konfigurationsmanagement, die ohne den Einsatz von PDM nicht zu bewältigen
sind:
Bei uns war einfach die Notwendigkeit gegeben, weil wir sonst
mit der Datenhaltung Probleme bekommen hätten. Ohne eine
effiziente Datenverwaltung hätten wir überhaupt keinen Nutzen
mehr gehabt. (Dr.-Ing. W. Schmidt, Trumpf Werkzeugmaschinen
GmbH + Co. KG, Ditzingen, nach [Wen01a, S. 96f]).
55. Zu weiteren Nutzenaspekten siehe u.a [BFR+98, S. 17f], [ES01, S. 281ff], [Höf99, S. 38f],
[Sch99, S. 232 u. 293], [Wen01a, S. 87ff]. Aussagen zu gemessenem Nutzen finden sich u.a. in
[HSS95, S. 4f], [IIC00], [KRA+98] und [VS97.]
Bild 2-11: Der Nutzen des Einsatzes von PDM-Systemen ist zumeist schwer zu
quantifizieren [Abr96c]
56. Siehe Kapitel 2.1.1.1.
Kosten
Nutzen
- Produktivitätssteigerung
- Stärkere Nutzung von Standardlösungen
- weniger Änderungen/Änderungskosten
leicht
- Auftragszeitverkürzung
- Verkürzung der Änderungszeiten
- Reduzierung der Qualitätskosten
schwer
- Höhere Flexibilität
- Besserer Datenzugriff
- Konformität mit vorhandenen Normen
sehr
schwer
Quantifizierbarkeit
Einführung von PDM-Systemen Seite 31
Die Vermeidung eines „negativen Nutzens“ durch die Einführung von PDM lässt
sich somit in einer Kosten/Nutzen-Analyse auf der Habenseite des PDM verbu-
chen. Es lässt sich außerdem feststellen, dass in vielen Projekten schon die weni-
gen quantifizierbaren Nutzeneffekte eine Projektrealisierung rechtfertigen
[Abr96a].
Fazit Nutzenpotentiale
Die Ermittlung des PDM-Nutzens ist aufgrund des hohen indirekten Anteils und
der Verknüpfung der Systemeinführung mit organisatorischen Maßnahmen
schwierig. Ohne Nachweis des Nutzens wird eine so große Investition wie sie eine
PDM-Einführung darstellt allerdings kaum getätigt. Für den quantifizierbaren Nut-
zen kann eine klassische Investitionsrechnung57 durchgeführt werden. Zusätzlich
muss eine Methode gefunden werden, die es ermöglicht, zum einen bei Verglei-
chen von Investitionsalternativen und zum anderen zur Kontrolle festgelegter stra-
tegischer Ziele auch die nicht quantifizierbaren Nutzenpotentiale zu berücksichti-
gen.
2.1.2 Produktdatenmanagement-Systeme
Wie schon mehrfach beschrieben und aus der Arbeitsdefinition (siehe Kapitel 2.1)
ersichtlich, ist Produktdatenmanagement als ein ganzheitliches Konzept zu sehen,
das nicht zwingend durch ein einzelnes System umgesetzt werden muss. Da in den
meisten Unternehmen aber nicht alle benötigten PDM-Funktionen von den vorhan-
denen Systemen bereitgestellt werden und diese Systeme zum Teil veraltet und
nicht integrierbar sind, ist es sinnvoll, bei jeder PDM-Einführung auch über Ein-
führung eines speziellen PDM-Systems nachzudenken.
Diese Systeme bieten mit ihrer Grundfunktionalität zur Verwaltung von Produkt-
daten und Prozessen eine nahezu vollständige Unterstützung für die Umsetzung
des Konzeptes PDM in einem Unternehmen. Im Folgenden werden zunächst die
Grundfunktionen beschrieben (Kapitel 2.1.2.1 und Kapitel 2.1.2.2). Anschließend
wird der allgemeine Aufbau eines PDM-Systems erläutert (Kapitel 2.1.2.3) und
abschließend kurz auf den Stand der am Markt verfügbaren Systeme eingegangen
(Kapitel 2.1.2.4).
2.1.2.1 Grundfunktionen zur Verwaltung von Produktdaten
Das in Kapitel 2.1.1.1 dargestellte Modell des Metadaten- und Dateimanage-
ments58 bildet die Basis für das Produktstruktur-, Dokumenten- und Konfigurati-
onsmanagement sowie die Klassifikation von Produktdaten.
57. Zu verschiedenen Verfahren der Investitionsrechnung siehe z.B. [GEK01, S. 171ff].
Seite 32 Kapitel 2
Produktstrukturmanagement: Der Kern des Metadatenmodells ist die Produkt-
struktur. Nach DIN 199 ist
die Produktstruktur ein produktdarstellendes Modell, das die
Gesamtheit der nach bestimmten Gesichtspunkten (z.B. Ferti-
gung, Montage, Funktion, Disposition, Kalkulation) festgelegten
Beziehungen zwischen Baugruppen und Einzelteilen eines Pro-
duktes beschreibt. Sie schafft somit den logischen Zusammen-
hang zwischen dem Produkt und den Bestandteilen, aus denen es
sich zusammensetzt. [DIN77]
Moderne PDM-Systeme ermöglichen eine grafische Darstellung von Produktstruk-
turen als Bäume oder Grafen inklusive der Zuordnung der zugehörigen Dokumente
wie CAD-Modelle, Arbeitspläne und Prüfberichte. Eine derartige Visualisierung
der Produktstruktur bietet eine bessere Anschaulichkeit und mehr Transparenz
über die Zusammenhänge als die Darstellung in Form von Stücklisten [GFG98].
Diese sind für den jeweiligen Zweck vollständige, formal aufgebaute Verzeich-
nisse für ein Produkt oder eine Baugruppe, die alle zugehörigen Baugruppen und
Bauteile unter Angabe von Bezeichnung, Menge und Einheit enthalten. Sie werden
in PDM-Systemen nicht mehr als eigenständige Objekte verwaltet, sondern aus der
Produktstruktur als Bericht abgeleitet. Berichtsformen sind unter anderem die
Mengenstückliste, die Baukastenstückliste oder der Verwendungsnachweis. Durch
die Zuordnung der Dokumente wird die visualisierte Produktstruktur darüber hin-
aus zur Grundlage für die Navigation durch den gesamten Produktdatenbestand.
Dokumentenmanagement: Das integrierte Dokumentenmanagement ermöglicht
die Verwaltung der Resultate der CAE-Systeme, die als Dateien existieren. Ferner
wird die Verbindung zwischen den erzeugenden CAE-Systemen und den Dateien
abgebildet. Die Tiefe der Integration hängt stark vom Umfang der Schnittstellen
des PDM-Systems ab. Dieser reicht von der einfachen Referenzierung der Doku-
mente im PDM-System bis hin zum gegenseitigen Austausch von Metadaten und
internen Dokumentenstrukturen zwischen dem PDM-System und den Erzeugersy-
stemen. Zur Konsistenzerhaltung der Dokumente bedienen sich PDM-Systeme so
genannten Check-in/Check-out-Mechanismen. Mit einem Check-in trägt ein
Benutzer sein Resultat (Datei) in die Datenbank ein. Damit gibt er aus seiner Sicht
die Besitzrechte an einen Metadatensatz oder einer Datei ab. Durch einen
Check-out sperrt er ein Dokument für andere Benutzer [Sch99, S. 259ff]. Dadurch
ist gewährleistet, dass Dokumente, die ein Anwender in Bearbeitung hat, nicht von
anderen Anwendern an anderer Stelle doppelt bearbeitet werden. Sie können nur
gelesen werden. Der lesende Benutzer weiß über ihren Status, dass das Dokument
anderweitig in Bearbeitung ist und er noch mit Änderungen rechnen muss. Zusätz-
58. Bezugnehmend auf den objektorientierten Ansatz, der in den meisten PDM-Systemen Anwen-
dung findet, werden anstatt Metadaten und Dateien auch häufig die Begriffe Business Objekt
und Data Objekt verwendet. [Sch99, S. 94]
Einführung von PDM-Systemen Seite 33
lich können im PDM-System logische Speicherbereiche mit zugehörigen Zugriffs-
rechten definiert werden, so genannte Vaults. In einem Vault werden Metadaten
oder Dokumente unabhängig von ihrem physikalischen Speicherort logisch in
einem Speicherbereich zusammengefasst59. Damit lassen sich die Zugriffsrechte
auf die Daten für ganze Benutzergruppen festlegen. Vaults können unter anderem
abteilungs-, projekt- oder prozessbezogen definiert werden (z.B. Fertigungsvault,
Projektvault X, Freigabevault). Eine Versionskontrolle stellt zusätzlich sicher, dass
immer auf dem aktuellen Stand eines Dokumentes gearbeitet wird.
Konfigurationsmanagement: Den Stand einer Produktstruktur mit den ihr zuge-
ordneten Dokumenten zu einem bestimmten Zeitpunkt bzw. definiertem Ausliefe-
rungsstatus bezeichnet man als Konfiguration. Das Konfigurationsmanagement
beinhaltet die dazugehörigen technischen und verwaltungsmäßigen Regeln60. Auf
diese Weise werden die systematische Steuerung von Konfigurationsänderungen
und die Aufrechterhaltung der Vollständigkeit und Verfolgbarkeit der Konfigura-
tion während des gesamten Produktlebenszyklus61 erreicht [EH98]. PDM-Systeme
bieten die entsprechenden Möglichkeiten zur datums- oder seriennummernbezoge-
nen Vergabe von Gültigkeiten und zur Definition von Varianten. Über die Work-
flowmanagementkomponente (siehe Kapitel 2.1.2.2) ist außerdem die Abbildung
der notwendigen Änderungsabläufe möglich.
Klassifikation von Produktdaten: Grundlage für leistungsfähige Such- und
Retrievalmechanismen in PDM-Systemen ist die Klassifizierung von Teilen und
Teilefamilien. Diese geschieht zumeist mit Hilfe so genannter Sachmerkmalslei-
sten (SML). Danach werden die Eigenschaften (Merkmale) von ähnlichen Teilen
bzw. Baugruppen tabellarisch erfasst62. Es ist auch möglich, Merkmale z.B. über
Formeln aus anderen Merkmalen abzuleiten. Die Sachmerkmalleisten erlauben das
schnellere Wiederfinden von Teilen und das Auffinden ähnlicher Teile. In der Pra-
xis der PDM-Einführungsprojekte wird das Thema Klassifizierung oft sehr spät
angegangen, obwohl hier eines der Hauptnutzenpotentiale von PDM-Systemen
liegt, nämlich die Wiederverwendung von Teilen.
59. Der physikalische Speicherort wird in Ergänzung dazu als Vault Location bezeichnet. [Sch99,
S. 95f]
60. Die Notwendigkeit für das Konfigurationsmanagement ergibt sich u.a. auch aus den Verpflich-
tungen der Unternehmen durch nationale und internationale Produkthaftungsgesetze. Siehe
dazu [Pla96].
61. Er zieht sich von der Produktplanung über die Produktentwicklung, Fertigung und Nutzung bis
hin zur Entsorgung [ABJ00]. In jeder Phase des Produktlebenszyklus werden Daten benötigt
oder verändert. Der Begriff Life-Cycle-Management (LCM) wird deshalb seit einiger Zeit als
Synonym zu Konfigurationsmanagement verwendet [Sch99, S. 229].
62. Neben der Klassifikation des eigengefertigten Teilespektrums eines Unternehmens ist es auf
diese Weise auch möglich, Bibliotheken mit Normteilen [SH97] oder Kataloge von Zulieferern
[LLH00] in das PDM-System einzubinden und recherchierbar zu machen.
Seite 34 Kapitel 2
Produktstrukturen, Dokumententypen, Konfigurationsbeziehungen und Klassifika-
tionschemata sind unternehmensspezifisch. Die Definition des unternehmensspezi-
fischen Produktdatenmodells ist deshalb eine der Kernaktivitäten der PDM-Ein-
führung. Sie muss frühzeitig erfolgen und aufgrund der darin liegenden
Komplexität methodisch unterstützt werden.
2.1.2.2 Grundfunktionen des Prozessmanagements
Neben der reinen Verwaltung der Produktdaten unterstützen PDM-Systeme auch
die Planung, Steuerung und Überwachung von Abläufen, die mit der Erzeugung
und Veränderung der Produktdaten im Zusammenhang stehen. Dazu beinhalten sie
Funktionen zum Workflow- und Projektmanagement sowie zur Kommunikations-
unterstützung.
Workflowmanagement: Produktdaten durchlaufen während ihrer Existenz immer
wieder bestimmte, zumeist detailliert definierte administrative Abläufe, wie bei
einer Änderung oder zur Erreichung eines bestimmten Status (z.B. Fertigungsfrei-
gabe). Die dabei ablaufenden Schritte und die dazugehörigen Regeln für die Über-
gänge zwischen diesen werden in der Workflowkomponente des PDM-Systems
modelliert [Pör98]. Dies geschieht meistens grafisch interaktiv. Während des
Durchlaufs steuert sie die Weiterleitung, Verteilung und Statusänderung der Pro-
duktdaten. Mit Hilfe von Berichten über den aktuellen Stand der Produktdaten im
Workflow ist eine Überwachung des Prozesses möglich.
Projektmanagement: Zur Planung und Steuerung großer Entwicklungsprojekte
müssen PDM-Systeme Funktionen des Projektmanagements beinhalten. Die ver-
fügbaren PDM-Systeme bieten eine Basisfunktionalität. Häufig werden zusätzlich
spezielle Projektmanagementsysteme angeschlossen.
Kommunikation: Insbesondere bei verteilten Entwicklungs- und Fertigungs-
standorten kommt der Unterstützung der Kommunikation der Anwender unterein-
ander eine besondere Bedeutung zu. PDM-Systeme bieten deshalb E-Mail- und
Groupwarefunktionen, z.B. zum Senden von Nachrichten oder zur Planung von
Besprechungen. Dies geschieht in der Regel durch Anbindung der in den Unter-
nehmen vorhandenen E-Mail- oder Groupware-Systeme (siehe hierzu auch Kapitel
2.1.1.3). Neuere Entwicklungen integrieren zusätzlich Funktionen des Computer
Supported Cooperative Work (CSCW) wie Videokonferenz oder so genannten
Shared Whiteboards. Letztere ermöglichen es, dass mehrere Anwender gleichzei-
tig von geographisch verteilten Orten Graphiken, 3D-Modelle und Texte wie auf
einer gemeinsamen Wandtafel betrachten und verändern können63.
63. Der Trend zu so genannten web-basierten Lösungen hat aufgrund der vereinheitlichten Stan-
dards den größten Fortschritt in der Integration von PDM-Systemen und CSCW-Werkzeugen
gebracht. [Sch00a]
Einführung von PDM-Systemen Seite 35
2.1.2.3 Aufbau von PDM-Systemen
Die beschriebenen Funktionen für das Produktdaten- und Prozessmanagement bil-
den zusammen mit allgemeinen Systemfunktionen wie dem Benutzermanagement,
den Kern eines PDM-Systems. Zur vollständigen Erfüllung ihrer Aufgabe als Inte-
grationsplattform für alle Daten und Systeme der Produktentwicklung sind zusätz-
liche Komponenten erforderlich, die durch die in Bild 2-12 dargestellte allgemeine
Architektur dargestellt werden. Neben Standardbausteinen eines Informationssy-
stems wie der Benutzungsoberfläche, dem Betriebssystem und dem Datenbanksy-
stem sind die Entwicklungsumgebung und die Schnittstellen von besonderer
Bedeutung.
Entwicklungsumgebung: PDM-Systeme sind nur sehr selten direkt einsetzbar
(Out-of-the-Box). Zumeist sind sie eher Baukästen, die durch entsprechende
Anpassungen (Customizing) zu einer Lösung für ein Unternehmen werden. Die
Anforderungen an die Anpassung hängen dabei z.B. vom Fertigungstyp und der
Branche des Unternehmens ab. Die Entwicklungsumgebung erlaubt z.B. über
Masken- und Tabellengeneratoren sowie Programmierschnittstellen (Application
Programming Interface, API) die erforderlichen unternehmensspezifischen Anpas-
sungen vorzunehmen. Die Kosten für die Anpassungen sind in der Regel hoch und
übersteigen meist die Kosten für Hardware und Lizenzen. Entscheidend ist, dass
mit den Anpassungen ein attraktiver Return on Investment erreicht wird. Einige
Hersteller bieten zur Reduzierung des Anpassungsaufwandes mittlerweile bran-
chenbezogen vorkonfigurierte PDM-Systeme an.
Schnittstellen: Die Integration von CAE-Systemen und anderen Anwendungen in
das PDM-System wird durch Schnittstellen realisiert. Dabei sind zu den gängigen
Anwendungen im Produktentstehungsprozess, z.B. CAD, FEM oder Textverarbei-
Bild 2-12: Allgemeine Architektur von PDM-Systemen [GEK01, S. 533]
Schnitt-
stellen
Benutzungsoberfläche
PDM-Funktionen
Datenbanksystem
Betriebssystem / Hardware
Entwick-
lungs-
umgebung
Verwaltung
von
Produktdaten
Verwaltung
von
Prozessdaten
Datenbank-Management-System
Datenbank
Allg.
System-
funktionen
Seite 36 Kapitel 2
tung, zumeist fertige Schnittstellen vorhanden. Die entsprechenden Module kön-
nen bezogen und über die Entwicklungsumgebung angepasst werden. Für die
Anbindung von Eigenentwicklungen eines Unternehmens ist eine Schnittstelle
projektspezifisch zu realisieren. Dafür existieren mittlerweile auch Standards wie
die PDM-Enabler Spezifikation der Object Management Group (OMG) [OMG00]
und PDMI2 (Product Data Management Based on International Standards) in der
STEP-Initiative [BHK00]. Man unterscheidet Schnittstellen nach der Art des
Datenaustausches zwischen dem PDM-System und der entsprechenden Anwen-
dung nach Online- und Offline-Schnittstellen. Online-Schnittstellen greifen bei der
Ausführung einer Funktion in einem der gekoppelten Systeme direkt oder zumin-
dest zeitnah über das Netzwerk auf das andere System zu und übertragen diesem
Daten bzw. stoßen dort weitere Funktionen an. Dies kann allerdings unter Umstän-
den die Performance eines Systems erheblich beeinflussen. Offline-Schnittstellen
dagegen sammeln Aktionen wie Datenübertragungen von einem System zum
anderen in einem Zeitraum und führen diese z.B. über Nacht aus. Dabei entsteht
die Gefahr von Dateninkonsistenzen, da der aktuelle Dateninhalt des nachgelager-
ten Systems nicht immer den aktuellen Stand der Bearbeitung widerspiegelt. Wel-
che Art der Kopplung gewählt wird, hängt stark von den organisatorischen und
technischen Umständen des Projektes ab.
Verteilte Datenhaltung: Wegen ihrer Architektur bzw. des eingesetzten Client/
Server-Prinzips64 können PDM-Systeme grundsätzlich als verteilte Systeme ange-
sehen werden. Die PDM-Anwendung und die darunter liegenden Datenbanksy-
steme laufen auf einem oder mehreren Server-Rechnern, die räumlich getrennt sein
können. Der Zugriff des Benutzers und die Kommunikation der Server untereinan-
der geschehen über das Netzwerk [Ger00, S. 44]. Dabei unterscheidet man zwi-
schen verteilten und föderierten PDM-Systemen. Verteilte PDM-Systeme unterlie-
gen einer hierarchischen Struktur, wobei ein Hauptserver verschiedene Subserver
haben kann, die nicht autonom miteinander kommunizieren. Eine föderierte
PDM-Lösung hingegen besteht aus verschiedenen autonomen Installationen eines
PDM-Systems mit unterschiedlichen Datenmodellen. [AGL98]
Die Wahl des Verteilungsprinzips hängt stark von den Unternehmensgegebenhei-
ten ab und erfordert ein hohes Maß an Know-how im Bereich der Datenbank- und
Netzwerktechnologie sowie vertiefte Kenntnis der unternehmenseigenen Hard-
ware und Netzwerk-Infrastruktur.
64. Rechnerarchitektur, bei der mehrere Clients (Arbeitsplatzrechner) mit einem oder mehreren
Servern (zentrale Rechner) verbunden sind. Dabei enthalten die Server Daten (Datenbanken)
und Programme, die von den Clients (gleichzeitig) genutzt werden können. [SS97, S. 182]
Einführung von PDM-Systemen Seite 37
2.1.2.4 Stand der am Markt verfügbaren Systeme
Die Zahl der am Markt verfügbaren Systeme ist groß. Die umfangreichste verfüg-
bare Marktübersicht, der „PDM Buyer’s Guide“ von CIMdata Inc. [Cim00], führt
nicht weniger als 56 Systeme auf. In einer weiteren Marktübersicht, die jährlich in
der Zeitschrift „EDM-Report“ erscheint [Mur01], werden zehn Systeme mit rele-
vantem Marktanteil in Deutschland genannt (siehe Bild 2-13). Einige wichtige
Anbieter sind hier nur aufgrund fehlender Angaben in der Befragung nicht aufge-
führt 65.
Alle Systemen haben eine Gemeinsamkeit: Sie können zwar nicht alle in den vor-
hergehenden Kapiteln beschriebenen Möglichkeiten gleichermaßen abdecken
[Abr96a], aber dennoch eine sehr hohe Funktionalität beinhalten. Des Weiteren
weisen sie folgende Gemeinsamkeiten auf, die Einfluss auf die PDM-Einführung
haben:
Modularität: Mehr als zwei Drittel der Systeme sind durch Strukturierung der
Funktionalität in Module geeignet, schrittweise in einzelnen Modulen eingeführt
zu werden [KJV96].
Objektorientierung: Die Systeme sind in der Regel auf dem Paradigma der
Objektorientierung aufgebaut66. Alle Informationen werden in Form von Objekten
repräsentiert [Sch99, S. 93].
Konfigurierbarkeit: Alle Systeme sind mit Hilfe spezieller Entwicklungsumge-
bungen (siehe Kapitel 2.1.2.3) an die Unternehmensgegebenheiten anpassbar.
Bild 2-13: Marktanteile der am deutschen Markt eingesetzten PDM-Systeme
gemessen an der Anzahl der installierten Lizenzen [Mur01]
65. Dazu zählen u.a. Enovia VPDM (IBM/Dassault), PDM9000 (Logotec Engineering), SAP PLM
(SAP AG) und Windchill (Parametrics Technologies).
axalant (E+P)
27%
Metaphase (SDRC)
15%
Pro*File (Procad)
10%
Gain System (PDS)
9%
Compass (AIM)
7%
CIM Database
(Contact)
6%
AM Workflow
(Cyco)
5%
Iman (UGS)
5%
eMatrix (MatrixOne)
4%
Helios (ISD)
3% Sonstige
9%
Seite 38 Kapitel 2
Dazu ist besonderes Know-how über das System notwendig [BS98]. Je nach Grad
der Vorkonfigurierung und der weiteren Konfigurationsmöglichkeiten unterschei-
det man zwischen Toolbox- und Turnkey-Systemen [Sch99, S. 286ff].
Unterschiede zwischen den Systemen selbst sind oftmals nur im Detail auszuma-
chen. Sie beziehen sich vor allem auf den unterschiedlichen Funktionsumfang
sowie die Verfügbarkeit und Qualität der Schnittstellen. Das Eingehen auf Kun-
denwünsche bei der Weiterentwicklung der Systeme durch die Hersteller führt
dabei zu einem ständigen Angleich von Funktionalität [BFR+98, S. 13]. Bei der
Auswahl eines Systems müssen deshalb neben den rein technischen Merkmalen
vor allem andere Kriterien wie die Herstellerkompetenz, die Verfügbarkeit von
Branchenlösungen oder die geplante Weiterentwicklung eines Systems berücksich-
tigt werden [Abr96b].
Fazit Produktdatenmanagementsysteme
Eine PDM-Einführung ist aufgrund der hohen Funktionalität und der meist weitrei-
chenden Anpassungsmöglichkeiten der PDM-Systeme nicht nur organisatorisch
sondern auch rein technisch sehr umfangreich und komplex. Um diese Komplexi-
tät zu beherrschen, ist es notwendig, die Einführung gut zu strukturieren, im Unter-
nehmen Wissen über die Anwendungsmöglichkeiten von PDM-Systemen aufzu-
bauen sowie, wenn nötig, auf Experten zurückzugreifen. Eine detaillierte Analyse
aller PDM-Systeme auf ihre Anforderungserfüllung hin ist wegen der hohen Zahl
der verfügbaren Systeme kaum möglich, so dass eine grobe Vorauswahl auf Basis
von Schlüsselanforderungen getroffen werden muss. Weil die führenden Systeme
mittlerweile eine große Ähnlichkeit aufweisen, sinkt das Risiko, ein völlig unge-
eignetes System auszuwählen67.
2.1.3 Schlussfolgerungen
Die Komplexität des Themas Produktdatenmanagement sowohl von strategischer
als auch von technischer Seite stellt an die PDM-Einführung hohe Anforderungen,
die in den vorhergegangenen Kapiteln dargestellt wurden. Zur Beherrschung der
Komplexität ist vor allem ein strukturiertes Vorgehen notwendig. In dieses Vorge-
hen müssen sowohl strategische als auch technische Aspekte berücksichtigt wer-
den. Dem „Faktor Mensch“ ist besondere Aufmerksamkeit zu widmen.
66. Die Objektorientierung beruht darauf, einzelne Elemente der jeweiligen Problemumgebung
durch so genannte Objekte zu modellieren. Die Grundidee ist dabei die Zusammenführung von
Daten und Funktionen und deren Kapselung in den Objekten (weitere Erläuterungen siehe
[GEK01, S. 269ff]).
67. Das Ergebnis der Befragung aus [IIC00] bestätigt diese Auffassung. Bei der Frage nach den
größten Risiken von PDM-Systemen wird die Auswahl des Systems am geringsten eingestuft.
Einführung von PDM-Systemen Seite 39
Zwischen diesen Anforderungen und der tatsächlichen Durchführung von
PDM-Einführungsprojekten in der Praxis besteht oft eine erhebliche Diskrepanz.
Diese wird in Kapitel 2.2 dargestellt. Es ergeben sich daraus im Detail weitere
Anforderungen, die in einem Vorgehensmodell zur PDM-Einführung zu berück-
sichtigen sind.
2.2 Rahmenbedingungen von PDM-Einführungsprojekten
Die folgenden Ausführungen beschreiben die üblichen Rahmenbedingungen, unter
denen PDM-Einführungsprojekte zur Zeit in den Unternehmen stattfinden. Die
Ausführungen beziehen sich dabei sowohl auf zahlreiche Projektbeschreibungen
aus der Literatur als auch auf persönliche Erfahrungen des Autors. Bild 2-14 zeigt
die Rahmenbedingungen im Überblick.
2.2.1 Ausgangspunkt
Ausgang für die Initiierung eines PDM-Einführungsprojektes ist oft eine einzelne
Abteilung, z.B. die Konstruktion. Das PDM-System wird dort zur Lösung lokaler
Probleme benötigt68. Erst im Verlauf des Projektes kommt es dann zur Einsicht,
dass auch andere Bereiche von PDM profitieren können. Daraus entstehen Folge-
projekte zur Ausweitung des PDM-Einsatzes. U.U. wird die PDM-Problematik
sogar in mehreren Bereichen gleichzeitig angegangen und es entstehen parallele
Projekte69. [Abr99] bezeichnet diese Vorgehensweise auch als Bottom-Up-Strate-
Bild 2-14: Rahmenbedingungen von PDM-Einführungsprojekten
68. Z.B. zur Verwaltung der wachsenden Zahl an Modellen, die durch die Einführung eines
3D-CAD-Systems entstehen.
69. In einem Projekt, an dem der Autor beteiligt war, wurde bei einem Automobilhersteller parallel
noch an mindestens vier verschiedenen PDM-Lösungen für einzelne Bereiche gearbeitet.
Beteiligung
interner
Mitarbeiter
Stakeholder
Ausgangs-
punkt Outsourcing
PDM-Einführung
Betrieb
des
Systems
Projekt-
management
Standard-
software und
Customizing
Methoden-
einsatz
Seite 40 Kapitel 2
gie. Im Gegensatz dazu steht eine Top-Down-Strategie, bei der ausgehend von
einem integrativen PDM-Gesamtkonzept für das Unternehmen die Einführung in
den Bereichen sukzessive vorgenommen wird70.
Die verbreitete Bottom-Up-Strategie wirft allerdings Probleme auf, die im weite-
ren Verlauf zu einem Scheitern führen können:
• Durch die lokale Initiierung in einer Abteilung wird das Projekt oft als eines von
vielen IT-Projekten verstanden. Die besondere strategische Bedeutung (siehe
Kapitel 2.1.1) und der notwendige Wandel werden nicht berücksichtigt. Das
Projekt bekommt erst später, wenn es auf andere Unternehmensbereiche ausge-
weitet wird, die Aufmerksamkeit des Top-Managements („Management Atten-
tion“), obwohl diese als größter Erfolgsfaktor von PDM-Einführungen gilt71.
• Bei mehreren PDM-Projekten sind die entstehenden Insellösungen in Prozess-
und Datenmodell nicht aufeinander abgestimmt und dadurch oft inkonsistent
bzw. redundant. Dies wiederum führt im operativen Geschäft zu Fehlern und
Mehrarbeit, die den angestrebten Nutzen erheblich reduzieren.
• Lokale Optimierung für einzelne Unternehmensbereiche führt nicht zwingend zu
einer Optimierung in anderen Bereichen oder einem Gesamtoptimum für das
Unternehmen. Wird eine PDM-Lösung zunächst für eine Abteilung ohne Bezug
auf ein Gesamtkonzept erstellt, führt dies bei anschließender Ausweitung in
andere Bereiche dort oft zu großen Widerständen, da man die eigenen Belange
nur unzureichend berücksichtigt sieht72.
• Die Einschränkung des PDM-Einsatzes auf die Lösung akuter Probleme eines
Unternehmensbereiches führt häufig zu einer stark technisch orientierten und im
Detail verhafteteten Auswahl des letztendlich falschen Systems73.
Auch empirisch wurde nachgewiesen, dass eine Top-Down-Strategie den größeren
Erfolg verspricht. Nach [Abr99] haben in einer Studie mehr als zwei Drittel der
Unternehmen, die eine erfolgreiche PDM-Einführung durchgeführt haben, diese
langfristig und ausgerichtet auf strategische Ziele geplant und dabei eine
Top-Down-Strategie verfolgt.
70. „Think big, act small“ [Ler00]
71. Siehe Kapitel 2.1.1.3
72. Aus eigener Erfahrung des Autors hat dies zusätzlich oft einen stark politischen Hintergrund.
Zwischen den Bereichen gibt es meistens Unstimmigkeiten über Kompetenzen, Rechte und
Pflichten. Der initiierende Bereich setzt nun zunächst seine Auffassung in der eigenen
PDM-Lösung um. Bei Ausweitung des Einsatzgebietes werden die anderen Bereiche vor voll-
endete Tatsachen gestellt und lehnen daher die Lösung ab.
73. Z.B. wählt die Konstruktionsabteilung aufgrund ihrer lokalen Problematik ein sehr CAD-nahes
System aus (so genannte Team Data Manager (TDM), siehe Kapitel 2.1.1.2). Dieses ist aber im
Sinne einer prozessübergreifenden Zusammenarbeit, an der u.a. die Produktplanung, der Ver-
trieb, die Fertigung oder die Instandhaltung beteiligt sein können, ungeeignet.
Einführung von PDM-Systemen Seite 41
2.2.2 Stakeholder
Wegen der unternehmensweiten Bedeutung von PDM sind sehr viele verschiedene
Anspruchsgruppen von der PDM-Einführung betroffen. Jeder dieser so genannten
Stakeholder verfolgt andere Ziele und steht deshalb der PDM-Einführung eher
positiv als negativ gegenüber. Diese Stakeholder sind in die PDM-Einführung ein-
zubeziehen. Zu den Stakeholdern gehören:
• das Management,
• der unternehmenseigene Informationstechnikbereich,
• die Mitarbeiter der verschiedenen Fachabteilungen als Endanwender,
• der Betriebsrat,
• die Eigentümer und andere [Dob98, S. 7], [Abr96b].
Auf die Bedeutung des Managementsupports für die PDM-Einführung ist in Kapi-
tel 2.1.1 bereits ausführlich eingegangen. Das Management vertritt auch die Inter-
essen der Eigentümer.
Informationstechnikbereiche halten oft an alten Systemen fest, weil sie dort über
die Jahre Wissen aufgebaut haben und nun befürchten, durch das neue System an
Bedeutung zu verlieren. Sie werden aber zum einen als Know-how-Träger für die
bestehende technische Infrastruktur und die Datenmigration benötigt [Fur98] als
auch für den späteren Betrieb des neuen Systems [Inf00a]. Es ergibt sich also kein
Bedeutungsverlust sondern eine Verschiebung von Aufgaben. Diese neuen Aufga-
ben können aber nur durch frühzeitige Einbindung in die PDM-Einführung bewäl-
tigt werden.
Die Mitarbeiter sind in ihrer täglichen Arbeit am meisten von der PDM-Einfüh-
rung betroffen, so dass ihre Beteiligung eine entscheidende Rolle spielt. Da sich
durch die Neuorganisation der Prozesse auch Aufgaben und Stellenbeschreibungen
ändern sowie in der Nutzung des PDM-Systems auch immer die Möglichkeit der
Überwachung von Arbeitsfortschritten besteht, ist der Betriebsrat im Zweifelsfall
auch mit einzubeziehen.
Die Stakeholder können aus Mangel an entsprechendem Know-how zu Beginn der
Einführung nicht selbst erkennen, dass sie davon betroffen sind. Sie müssen also
frühzeitig informiert und aktiv einbezogen werden.
„Alle Betroffenen müssen zu Beteiligten gemacht werden.“
[Zah98]
2.2.3 Beteiligung interner Mitarbeiter
Bei der Beteiligung der internen Mitarbeiter sind die bestehenden Unterschiede
zwischen den Zielen der Stakeholder zu beachten. Zum einen bekommen sie daher
Seite 42 Kapitel 2
in der Projektorganisation ihren Zielen angepasste Aufgaben [Neu98]. Zum ande-
ren sind die Informations- und Qualifizierungsmaßnahmen darauf abzustimmen
[Dre96].
Es besteht in den Unternehmen die Tendenz, für Projekte, die neben dem Tagesge-
schäft abgewickelt werden, Mitarbeiter abzustellen, die dort zur Zeit nicht benötigt
werden. Hinzu kommt, dass die Mitarbeiter nicht ausreichend vom Tagesgeschäft
freigestellt werden [LFH99]. Da die Ansprüche an die Qualifikation bei der
PDM-Einführung aber sehr hoch sind, wird dadurch der Projekterfolg gefährdet.
Es müssen stattdessen die möglichst am besten qualifizierten und mit der nötigen
Kompetenz für Entscheidungen ausgestatteten Mitarbeiter einbezogen werden74
[Rei99].
Bei der PDM-Einführung handelt es sich nicht um ein rein technisches Unterfan-
gen. Daher ist es wichtig, nicht nur die fachlichen Fähigkeiten zu beurteilen son-
dern auch die entsprechenden „weichen Faktoren“ wie die Motivation oder die
Veränderungsbereitschaft bei der Auswahl zu berücksichtigen [Gei00]. Besonders
im Mittelstand kann dies zu einem Problem werden, da dort zumeist nur wenige
solcher „Key-User“ zur Verfügung stehen [Gro98].
Unabhängig davon, welche Mitarbeiter in das Projekt einbezogen werden, weisen
65% der Unternehmen Wissensdefizite im PDM-Bereich auf [MMH97]. Auch in
internen IT-Abteilungen sind nicht immer die notwendigen Qualifikationen vor-
handen. Laut einer Studie der Gartner Group bezeichnen deshalb 43% der befrag-
ten IT-Manager das fehlenden Know-how als Problem und 42% sehen die Qualifi-
zierung als eine der großen Herausforderungen (siehe Bild 2-15). Bestimmtes
Wissen, z.B. über ein neues System, kann in einem Unternehmen nicht vorausge-
setzt werden.
Deshalb kommt dem Aspekt der Qualifizierung bei der PDM-Einführung insge-
samt eine entscheidende Bedeutung zu. Dies muss beim Vorgehen berücksichtigt
werden. Lassen sich bestimmte Qualifikationsdefizite im Unternehmen nicht durch
Maßnahmen mit den bestehenden Mitarbeitern ausgleichen, bestehen zwei Mög-
lichkeiten, die damit fehlenden Ressourcen in das Projekt zu bringen.
Einige Unternehmen beschaffen sich die fehlenden Ressourcen auf dem Markt,
d.h. sie stellen PDM-Experten ein. Eine Steigerung entsprechender Stellenanzei-
gen lässt sich in den letzten Jahren beobachten. Ein Beispiel für eine solche Stel-
lenanzeige zeigt Bild 2-16.
Allerdings ist es nicht immer möglich, den Bedarf an Experten über Neueinstellun-
gen zu decken. Dies liegt vor allem daran, dass PDM in der Ausbildung noch nicht
so verankert ist, wie z.B. CAD. Hier besteht ein Handlungsbedarf unabhängig von
der PDM-Einführung.
74. „Get the right people together“. [Rud95-ol]
Einführung von PDM-Systemen Seite 43
Eine weitere Möglichkeit ist die Einbeziehung externer Experten in die PDM-Ein-
führung. Dieses so genannte Outsourcing ist bei PDM-Einführungen weit verbrei-
tet.
2.2.4 Outsourcing
Unter Outsourcing versteht man allgemein die vollständige oder teilweise Übertra-
gung von zuvor innerbetrieblich erfüllten Tätigkeiten im Zusammenhang mit dem
Einsatz von Informationstechnik an wirtschaftlich unabhängige Dienstleistungsun-
ternehmen [Kno93]. Im Rahmen der PDM-Einführung fallen darunter Tätigkeiten
der Beratung, Konzeption, Qualifizierung, Implementierung und der technischen
Unterstützung. Neben den in Kapitel 2.2.3 genannten Gründen der fehlenden Qua-
lifikation oder Verfügbarkeit von Mitarbeitern werden externe Berater auch oft
deswegen hinzugezogen, weil sie einen anderen Blickwinkel auf interne Prozesse
mitbringen. Sie sind eher in der Lage, als Vermittler zwischen den im Unterneh-
men vorherrschenden unterschiedlichen Auffassungen zu fungieren [Blä98],
[Rad00].
Externe Unterstützung können u.a. Beratungsunternehmen, Softwarehäuser und
Forschungsinstitute liefern [Spu96]. Dabei kommt es auf die Phase im Projekt und
die Aufgaben an, welche Anbieter hinzugezogen werden sollten. Systemanbieter
werden bevorzugt in der Systemanpassung eingesetzt, weil sie dort das beste
Know-how mitbringen [BS98]. Systemunabhängige Beratungshäuser und Institute
können eher in den früheren Phasen unterstützen, in denen es vor allem auf allge-
meine PDM-Kenntnisse und systemübergreifendes Wissen ankommt. In der
Systemanpassung können sie eine neutrale Instanz zur Beurteilung der Leistung
Bild 2-15: Herausforderungen von IT-Managern [Gar02]
14%
15%
16%
21%
25%
31%
42%
43%
43%
47%
0% 5% 10% 15% 20% 25% 30% 35% 40% 45% 50%
Platform Selection
Java Adoption
Outsourcing
New/Emerging Technologies
Technology Standards
Web Development
Training
Integration with Packages
Skills Availability
Integration with Legacies
Seite 44 Kapitel 2
des Systemanbieters sein sowie die systemunabhängigen Tätigkeiten des Change
Managements unterstützen. Unter Umständen wird sogar der Betrieb inklusive der
Hardware an externe Dienstleister vergeben [ZAS00b]. Man spricht hier von
Application Service Providing (ASP).
Unternehmen, die für die PDM-Einführung externe Unterstützung brauchen, ste-
hen hier vor dem Problem, die richtigen Berater zum Ausgleich der eigenen Defi-
zite bzw. zur Ausfüllung von bestimmten Projektrollen zu finden. Die Auswahl
muss sich dabei, wie bei den internen Mitarbeitern, an dem benötigten Qualifikati-
onsprofil orientieren und auch die humanorientierten Kompetenzen einbeziehen.
Zusätzlich kommen wirtschaftliche Bewertungskriterien hinzu [Inf98a]. Da der
Bild 2-16: Unternehmen haben Bedarf an PDM-Experten (Stellenanzeige der
Toyota-Motorsport GmbH für einen Experten des PDM-Systems
CATIA Virtual Product Manager) [VDI02a]
Einführung von PDM-Systemen Seite 45
externe Berater die Prozesse des Unternehmens nicht kennt, sollte er zumindest
Branchenkenntnisse vorweisen können [MMH97].
Für externe Dienstleister stellt sich die Aufgabe, entsprechend qualifizierte Mitar-
beiter bereitzustellen. In den meisten Projekten werden ähnliche Tätigkeiten nach
extern vergeben. Dazu zählen insbesondere die allgemeine PDM-Beratung, die
Unterstützung in der Anwendung von Methoden und die Tätigkeiten der
Systemanpassung. Hier besteht wiederum die Notwendigkeit, den wachsenden
Bedarf auf Seiten der Dienstleistungsunternehmen durch entsprechende Ausbil-
dungsmaßnahmen zu decken.
Die Beteiligung externer Dienstleister ist auch unter rechtlichen Aspekten zu
beleuchten. Durch die Dienstleistung, z.B. in Form von Beratung oder Softwarent-
wicklung, entsteht ein Vertragsverhältnis. Der Dienstleister verpflichtet sich,
gegen Bezahlung eine vereinbarte Leistung zu erbringen. Um Unstimmigkeiten
darüber zu vermeiden, ob eine Leistung in der geforderten Qualität erbracht wor-
den ist, müssen die Anforderungen des Kunden, also des Unternehmens, das die
PDM-Einführung durchführt, klar und für beide Seiten eindeutig spezifiziert sein.
Das erfordert zumeist den Einsatz von bestimmten Methoden (siehe Kapitel 2.2.6).
2.2.5 Projektmanagement
In Anbetracht der bisher dargestellten Komplexität einer PDM-Einführung und der
Beteiligung vieler unterschiedlicher Projektpartner wird deutlich, dass einem guten
Projektmanagement eine besondere Bedeutung zukommt. Ein starker Projektleiter
mit den entsprechenden Kompetenzen und eine sorgfältige Planung aller notwen-
digen Schritte sind notwendig, um zum Erfolg zu kommen. Die Realität stellt sich
zum Teil anders dar.
Ähnlich wie die Projektmitarbeiter (siehe Kapitel 2.2.3) ist auch der Projektleiter
oft nicht vom Tagesgeschäft freigestellt oder stellt in Bezug auf seine Qualifikation
einen Kompromiss dar, da die geeigneten Mitarbeiter in anderen Tätigkeiten als
Leistungsträger eingebunden sind [Fri96]. Daraus resultiert auch, dass er zumeist
nicht mit der entsprechenden Entscheidungskompetenz ausgestattet ist oder über
keinen großen Rückhalt aus der Unternehmensführung verfügt [Mar99].
Das Vorgehen bei der PDM-Einführung ist in vielen Projekten relativ ungeplant.
Da die Ziele nicht klar definiert sind, ist auch der Plan für den Weg zu deren Errei-
chung nicht stimmig [Fri96]. Oft wird das Ausmaß der PDM-Einführung unter-
schätzt, so dass zu hohe Ziele in eine zu kurze Projektlaufzeit eingeplant werden75.
Hinzu kommt, dass der Fokus der Planung sehr stark direkt auf die Systemanpas-
sungsphase gelegt wird, ohne die vorbereitenden und begleitenden Arbeiten zu
75. Grund hierfür ist oft auch die in Kapitel 2.2.1 erläuterte Bottom-Up-Strategie, die zu Beginn der
Planung nicht alle Auswirkungen berücksichtigt.
Seite 46 Kapitel 2
berücksichtigen [Mar99]. So werden kosten- und zeitintensive Tätigkeiten wie die
Altdatenübernahme (Migration), Schnittstellenentwicklungen und Schulungsmaß-
nahmen unterschätzt und vernachlässigt [PWC98], obwohl sie auch von der Wich-
tigkeit her sehr hoch einzuschätzen sind [Led96]. Die Migration sichert vorhan-
dene Datenbestände und dient zur Initialbefüllung des neuen Systems [Sch98d].
Dabei sind besonders die Aufwände für die Bereinigung der Altdaten vor der
Übernahme enorm [BS00], was zum Teil auf den in Kapitel 2.1.1.1 beschriebenen
Paradigmenwechsel von der Dokumenten- zur Teilezentrierung zurückzuführen
ist. Schnittstellen dienen zur Integration der vorhandenen Anwendungen in das
PDM-System, einem der Hauptanliegen der PDM-Einführung. Es ist bereits auf
die Gründe für die hohe Bedeutung von Schulungen mehrfach eingegangen wor-
den.
Ein weiterer Aspekt, der beim Projektmanagement für die PDM-Einführung oft
nicht beachtet wird, ist die sehr unterschiedliche inhaltliche Ausrichtung der ein-
zelnen Phasen. Während gemäß der geforderten Top-Down-Strategie zunächst
strategische und Nutzenaspekte im Mittelpunkt stehen, verschiebt sich der Fokus
später dazu, ein passendes System auszuwählen. Erst am Ende steht eine Implem-
tierungsphase. Nach jeder dieser Phasen kommt es zu einer Entscheidung, ob mit
der nächsten überhaupt begonnen wird oder nicht. Obwohl jeweils sehr unter-
schiedliche Teams zur Aufgabenbewältigung nötig sind und auch die Projektlei-
tung unterschiedlich besetzt werden sollte, werden die meisten PDM-Einführun-
gen von einem festen Team durchgeführt. Es wird deshalb als Verbesserung
vorgeschlagen, die PDM-Einführung nicht als ein Projekt, sondern als Folge meh-
rerer Projekte mit oben genannten Abgrenzungen anzusehen.
2.2.6 Methodeneinsatz
Die Vielzahl der beteiligten Partner und durchzuführenden Aktivitäten werfen ein
weiteres Problem auf: die ungenügende Definition von Anforderungen. Sind
Begriffe nicht eindeutig geklärt und die Anforderungen wie die Ziele nicht klar
definiert, kann es während des Projektes zu Konflikten darüber kommen, ob eine
Anforderung erfüllt ist oder nicht. Dies ist, wie in Kapitel 2.2.4 bereits dargestellt,
auch ein rechtiliches Problem.
Deshalb müssen die Anforderungen klar und unmissverständlich definiert werden.
Dazu ist es zunächst notwendig, zu Beginn der Einführung die verwendeten
Begriffe in einem Glossar einheitlich festzulegen und zu beschreiben [Wen95-ol].
Außerdem muss die Dokumentation der Anforderungen mit Hilfe geeigneter
Methoden76 durchgeführt werden, um den Interpretationsspielraum einzuschrän-
ken [KFV99]. Das Problem vieler Methoden ist allerdings der sehr starke Grad der
Formalisierung. Dieser kann die Anforderungsdefinition einschränken und dazu
76. Zur genauen Definition des Begriffs „Methoden“ siehe Kapitel 2.3.1.
Einführung von PDM-Systemen Seite 47
führen, dass vor allem die Anwender die Dokumentation nicht mehr verstehen und
beurteilen können. Hier bietet sich an, eine semiformale Spezifikationstechnik zu
verwenden.
Neben Problemen mit der Form der Dokumentation können auch inhaltliche Fra-
gen zu einer ungenauen Spezifikation von Anforderungen führen. Die Mitarbeiter
des Unternehmens weisen vielfach Wissensdefizite zum Thema PDM auf (siehe
Kapitel 2.2.3). Deshalb sind sie gar nicht in der Lage, genaue Anforderungen zu
spezifizieren [KW98]. Deshalb benötigen sie auch hier methodische Unterstüt-
zung, die durch so genannte Best Practices77 oder Referenzmodelle geboten wer-
den kann. Trotz aller Unternehmenseigenheiten bestehen zumindest in Branchen
oft sehr ähnliche Prozesse. Best Practices sind Lösungen für einzelne Prozesse, die
sich allgemein anerkannt als nutzbringend herausgestellt haben. An Hand der Best
Practices lassen sich bisher unbekannte Sachverhalte deutlich aufzeigen.
Sind die Anforderungen klar und eindeutig defniert, kommt es in den meisten
PDM-Projekten bei der Systemanapassung immer noch zu einem Bruch in der
methodischen Vorgehensweise. Dies liegt daran, dass viele gängige Methoden
lediglich die Analyse- und Konzeptionstätgkeiten unterstützen und eine zumindest
teilautomatisierte Anpassung des Systems nicht möglich ist [GA98]. Bei der Aus-
wahl der Methoden für die PDM-Einführung muss darauf also zusätzlich geachtet
werden.
2.2.7 Standardsoftware und Customizing
PDM-Systeme an sich sind so genannte Standardsoftware. Darunter versteht man
Software, die zur Lösung einer sich relativ häufig stellenden Aufgabe beiträgt und
deshalb als Produkt am Markt angeboten werden werden kann78 [GF99, S. 453].
Da die PDM-Einführung aber auch Prozessänderungen und die Integration in
bestehende Systemwelten erfordert, können die Systeme selten direkt im Standard
eingesetzt werden. Deshalb bieten die Systeme umfangreiche Anpassungsmöglich-
keiten über das so genannte Customizing. Customizing wird definiert als
„... der kontinuierliche Prozess der Anpassung eines Softwaresy-
stems im Rahmen seiner unternehmensneutralen Standardfunk-
tionen an kundenspezifische (bzw. unternehmensspezifische)
Anforderungen ...“ [GA98].
Die Anpassung bezieht sich dabei zunächst auf die formale Beschreibung von Pro-
zessen, die Vergabe von Berechtigungen, die Festlegung von Datenmodellen und
die unternehmenspezifische Gestaltung der Benutzungsoberfläche [GA98]. Die
77. Best Practice = Optimales Verfahren.
78. Demgegenüber steht die Individualsoftware, die zur Lösung eines mehr oder weniger individu-
ellen Problems beiträgt und deren Vermarktung nicht vorgesehen ist [GF99, S. 453].
Seite 48 Kapitel 2
Erfahrung des Autors zeigt, dass es dabei oft nicht bleibt, sondern erhebliche
Änderungen von Anwendungsfunktionen durchgeführt werden, die eher einem
Redesign gleich kommen. Der hohe Aufwand, der in die Anpassung fliesst, lässt
sich auch an Hand des Marktwachstums für PDM-Software und -dienstleistungen
erkennen. Während die Umsätze mit Software nur moderat steigen, wächst der
Anteil der Dienstleistungen, zu denen das Customizing zu zählen ist, überpropor-
tional (siehe Bild 2-17).
Auf jeden Fall stellt jede PDM-Implementierung trotz der Nutzung von Standard-
software ein Unikat dar [Gut99]. Die Softwareerstellung nimmt auf Seiten der
Kosten und des Personalaufwandes einen erheblichen Teil des Budgets ein. Für
den softwaretechnischen Teil der PDM-Einführung ergeben sich daraus folgende
Implikationen:
Für die Durchführung des Customizing sind zum Teil die in der allgemeinen Soft-
wareentwicklung verwendeten vorhandenen Methoden und Werkzeuge einzuset-
zen. Die Architektur und bestimmte Programmiermöglichkeiten werden durch das
PDM-System vorgegeben und schränken die Anpassungsmöglichkeiten zum Teil
ein. Die Anpassung muss möglichst weitgehend auf den Standardfunktionen des
Systems aufbauen. Im Prinzip stellt das Standardsystem schon einen ersten Proto-
Bild 2-17: Das Marktwachstum für PDM ist besonders bei den Dienstleistungen
und der Softwarewartung enorm [Cim02-ol]
0,0
2,0
4,0
6,0
8,0
10,0
12,0
1995 1996 1997 1998 1999 2000 2001 2002 2003 2004 2005 2006
Software
Softwarewartung
Dienstleistungen
(2002 - 2006 geschätzt)
Mrd. $
Einführung von PDM-Systemen Seite 49
typen dar79. Dieser bildet für die weitere Implementierung den Ausgangspunkt und
erleichtert, sehr frühzeitig den Anwendern die Funktionsweise des Systems darzu-
stellen [Rie96 u.a.], [AGW+00].
Das PDM-System als Produkt des Systemlieferanten besteht also am Ende aus der
Standardsoftware und den Softwareanpassungen. Zusätzlich gehört auch die
Dokumentation zum Lieferumfang [Dum00, S. 3]. Um eine gewisse Qualität und
die Abnahmefähigkeit dieses Gesamtproduktes zu sichern, sollten Verfahrenswei-
sen der Softwarequalitätssicherung und des Softwarekonfigurationsmanagements
angewandt werden [PK00] und um ein Dokumentenmanagement ergänzt werden.
Diese Verfahren sind möglichst durch Werkzeugunterstützung in Form von Soft-
warekonfigurations- und Dokumentenmanagementsysteme zu unterstützen
[SFB+00, S. 40f]. Als eine erfolgreiche Methode zur Sicherung der Softwarequali-
tät wird auch allgemein angesehen, wenn der Lieferant ein normiertes Qualitäts-
managementsystem nach DIN ISO 9001 [ISO94] anwendet80. Auf die Einhaltung
von Kosten- und Zeitzielen hat dies allerdings keinen Einfluss [SMT98].
2.2.8 Betrieb des Systems
Am Schluss der PDM-Einführung steht der Übergang des Systems in die operative
Nutzung. Alle Mitarbeiter des Unternehmens, die in betroffenen Prozessen arbei-
ten, wenden nun die Funktionen des Systems zur Bewältigung ihrer Aufgaben an.
Dabei ergeben sich einige Schwierigkeiten, die in Bild 2-18 dargestellt sind.
Besonders problematisch werden dabei der Herstellersupport und die Anwen-
derakzeptanz bewertet. Außerdem sind Wartung, Anwenderbetreuung und
Systemperformance als Schwierigkeiten benannt. Diese Punkte müssen also bei
der PDM-Einführung adressiert werden, um einen reibungslosen Betrieb zu
gewährleisten.
Probleme mit dem System in Bezug auf Performance oder Stabilität treten auf,
wenn die technische Infrastruktur des Unternehmens während der Einführung
nicht hinreichend analysiert, angepasst und getestet wurde. Diese Tätigkeiten müs-
sen also fest geplant und durchgeführt werden.
Für die Wartung und Anwenderbetreuung wird im Unternehmen Know-how benö-
tigt, das während der Einführung aufgebaut werden muss. Die Wartung sowie der
technische Support müssen durch die interne Systemadministration durchgeführt
werden. Diese muss entsprechende Schulungen erhalten. Sie sollte schon während
der Einführung in relevante Aktivitäten einbezogen werden. Die Anwenderbetreu-
ung erfolgt idealerweise zunächst vor Ort in den Abteilungen. Dort müssen so
79. Zur genauen Definition des Prototyping siehe Kapitel 4.7.2.
80. Für ein Beispiel eines Qualitätsmanagementsystems nach DIN ISO 9001 für die Softwarent-
wicklung siehe [Bur95].
Seite 50 Kapitel 2
genannte Key-User das System und die Prozesse so gut beherrschen, dass sie die
Betreuung leisten können. Auch diese Key-User müssen intensiv bei der
PDM-Einführung einbezogen werden. Die Betreuung durch die Key-User muss in
zweiter Ebene zu Bewältigung schwerwiegender Anwendungsprobleme durch eine
Hotline o.ä. ergänzt werden.
Der Herstellersupport sollte während der Einführung als Auswahlkriterium für die
Auswahl eines PDM-Systems berücksichtigt und in die Planung der Supportstruk-
tur aufgenommen werden.
2.2.9 Schlussfolgerungen
In den meisten Fällen werden bei der Durchführung von PDM-Einführungen viele
Probleme nicht ausreichend berücksichtigt. In den vorhergehenden Kapiteln sind
die jeweiligen Möglichkeiten zur Bewältigung genannt worden. Es zeigt sich, dass
die meisten Probleme deshalb entstehen, weil sie im Vorgehen nicht explizit
berücksichtigt und eingeplant werden.
Gefordert ist deshalb ein Modell, das alle relevanten Schritte der PDM-Einführung
unter Berücksichtigung der genannten Einflussgrößen enthält. Basis dafür ist die
Definition eines so genannten Vorgehensmodells. Der Begriff und die dahinter ste-
henden Konzepte werden nachfolgend in Kapitel 2.3 erläutert.
Besondere Beachtung muss im Vorgehen dem Personal, sowohl in Bezug auf die
Projektmitarbeiter als auch auf die späteren Systemanwender geschenkt werden.
Bild 2-18: Schwierigkeiten im Betrieb eines PDM-Systems [Wen01a, S. 81]
0% 10% 20% 30% 40% 50% 60% 70% 80% 90% 100%
Herstellersupport
Wartung und Updates
Anwenderakzeptanz
Betreuung der Anwender
Erweiterung des Systems
Systemstabilität
Systemperformance
sehr schwierig
schwierig
normal
einfach
sehr einfach
keine Angabe
Schwierigkeitsgrad (Anteil der Befragten)
Einführung von PDM-Systemen Seite 51
Deshalb schließt sich in Kapitel 2.4 eine Betrachtung des Komplexes der Personal-
planung und -entwicklung an.
2.3 Vorgehensmodelle
Vorgehensmodelle werden seit den 60er Jahren im Bereich der Softwareentwick-
lung und der Einführung informationstechnischer Systeme verwendet. Sie waren
der Versuch, die so genannte Softwarekrise81 zu bewältigen. Rekonstruiert man
den Begriff „Vorgehensmodell“ aus seinen Wortbestandteilen, wird der Zweck
deutlich. Das Vorgehen bei der Entwicklung oder Einführung von Softwareanwen-
dungen wird auf Basis von Beschreibungen und Anleitungen sowie durch Struktu-
rierung aus verschiedenen Sichten als Modell abgebildet und somit transparent und
planbar [BF96].
Grundsätzlich besteht somit zwischen einem Vorgehensmodell zur Softwareent-
wicklung oder -einführung und in der Betrachtung sogenannter Geschäftpro-
zesse82 kaum ein Unterschied. Es treten bei deren Definition prinzipiell die glei-
chen Fragen auf [OHJ+98, S.16f]:
• In welche Teile kann das Vorgehen zerlegt werden?
• In welcher Reihenfolge können/müssen diese Teilschritte ausgeführt werden?
• Welche Ressourcen (Mensch, Informationen) sind erforderlich?
• Welche Informationen müssen als Eingangsgrößen vorliegen?
• Welche Ergebnisse werden in den Teilschritten erzeugt?
• Welche Methoden werden in den Teilschritten zur Erzielung der Ergebnisse
angewendet?
• Welche Werkzeuge stehen zur Unterstützung zur Verfügung?
2.3.1 Bestandteile
Ein Vorgehensmodell muss deshalb in der Regel folgende Bestandteile beinhalten:
Aktivitäten oder Tasks beschreiben die einzelnen durchzuführenden Teilschritte
der Softwareentwicklung oder -einführung. Sie können zeitlich nacheinander
81. Die rasante Entwicklung im Bereich der Hardware führte zu einer erhöhten Leistungsfähigkeit
der Rechner. Immer größere und komplexere Probleme konnten mit Hilfe von Computern
gelöst werden. Die Erstellung der dazu ebenfalls notwendigen komplexeren Software konnte
mit den damals zur Verfügung stehenden Mitteln der Softwareentwicklung nicht mehr bewältigt
werden. Es war deshalb ein Umdenken notwendig, was schliesslich zum Begriff des Software
Engineering führte. Darunter wird die Adaption der methodischen Vorgehensweisen der Inge-
nieurwissenschaften auf die Softwareentwicklung verstanden. [PS94, S. 19ff]
82. Ein Geschäftsprozess ist eine Menge von Aktivitäten zur Erbringung eines Ergebnisses, das für
den Kunden von Nutzen ist. Synonym werden auch die Begriffe „Prozess“ oder „Leistungser-
stellungsprozess“ angewendet. [GF99, S. 324f]
Seite 52 Kapitel 2
(sequentiell) oder gleichzeitig (parallel) durchgeführt werden. In vielen Vorge-
hensmodellen werden die Tasks in einem Top-Down-Ansatz zunächst grob defi-
niert, um dann mehrstufig in Sub-Tasks zerlegt zu werden.
Mit der Durchführung einer Aktivität entstehen Ergebnisse83, z.B. in Form von
programmiertem Code oder einem Dokument. Diese können als Zwischenergebnis
in einer nachfolgenden Aktivität als Eingangsinformation benötigt werden. Sie
können aber auch direkt Bestandteil der erstellten Leistung sein, z.B. der entwik-
kelten Software .
Die Aktivitäten werden z.T. automatisiert, aber vor allem von Personen durchge-
führt. Um eine Allgemeingültigkeit des Vorgehensmodells zu erreichen, werden
den Aktivitäten diese jedoch nicht direkt, d.h. in Form einer reellen Person zuge-
ordnet, sondern in Form von Rollen. Eine Rolle repräsentiert eine Aufgabe oder
eine Zusammenfassung mehrerer Aufgaben in einem Projekt, z.B. Projektleiter
oder Programmierer. Eine Person kann eine oder mehrere Rollen in einem oder
mehreren Projekten ausüben [Sch99, S.97f].
Methoden definieren die Art und Weise des Vorgehens innerhalb einer Aktivität84.
Die Eingangsgrößen einer Aktivität werden durch ein auf einem Regelsystem auf-
bauendem Verfahren und planmäßigem Vorgehen [Dud90, S. 497] in die Aus-
gangsgrößen tranformiert. Methoden können zu einzelnen Aktivitäten, aber auch
übergreifend über eine Abfolge von Aktivitäten definiert sein. Ziel des Methoden-
einsatzes muss es sein, die Transformation von Ergebnissen einer Aktivität in die
nächste möglichst effizient zu gestalten, also eine hohe Durchgängigkeit zu errei-
chen [PB97, S. 11], [Ehr95, S. 2]. Werkzeuge85 ermöglichen bzw. erzwingen die
Umsetzung der Methoden und erhöhen dadurch die Produktivität und Qualität des
Entwicklungsprozesses [PS94, S. 44].
Zusätzlich enthalten Vorgehensmodelle des Software Engineerings zum Teil wei-
tere Maßnahmen, die nicht zur eigentlichen Softwareerstellung gehören. Das Pro-
jektmanagement dient der Planung, Steuerung und Überwachung der eingesetzten
Ressourcen und soll vor allem die Einhaltung von Entwicklungszeit und -kosten
gewährleisten. Die Einhaltung funktionaler und vor allem nicht funktionaler
Anforderungen wird durch das Qualitätsmanagement gesteuert und kontrolliert
[PK00], [SMT98]. Um die Integration der von verschiedenen Entwicklern erstell-
ten Softwaremodule zu gewährleisten, wird ein Softwarekonfigurationsmanage-
83. Weitere verwendete Begriffe sind Produkte [BD93] und Artefakte [BRJ99, S. 514].
84. [Mül90] definiert eine Methode als eine Menge von Vorschriften, deren Ausführung den Voll-
zug einer als zweckmäßig erachteten Operationsfolge unter gegebenen Bedingungen hinrei-
chend sicherstellt. Zu einer genaueren Betrachtung und Klassifikation des Methodenbegriffs
und die Abgrenzung zum Begriff Methodik siehe [GLR+00, S. 31ff].
85. Ohne sie ist ist moderne Softwareentwicklung nicht denkbar, so dass die Existenz einer Werk-
zeugunterstützung für ein Vorgehensmodell oder eine Methode schon fast allein über deren Ein-
satz entscheidet [PS94, S. 60f].
Einführung von PDM-Systemen Seite 53
ment eingesetzt. Dies dient auch der Nachvollziehbarkeit des Standes bzw. der
Version einer Software zu einem bestimmten Zeitpunkt, z.B. einem Test oder der
Abnahme.
2.3.2 Klassifizierung
Im Laufe der Entwicklung des Software Engineerings von den 60er Jahren bis
heute haben sich auch die Vorgehensmodelle weiter enwickelt. Dabei hatten die
meisten Vorgehensmodelle einer Epoche charakteristische Merkmale, die zu einer
historischen Klassifizierung in sechs Arten (z.T. mit entsprechenden Unterarten)
führte (siehe Bild 2-19).
Die Entwicklung vom Wasserfallmodell bis heute ist dabei durch eine schrittweise
Veränderung der zugrundeliegenden Vorgehensweisen in den Modellen gekenn-
zeichnet. Die ersten Vorgehensmodelle waren aufgrund der vorweg genommenen
Planung mehr sequentiell orientiert. Grundlegendes Problem dieser Ansätze
besteht darin, dass die Risiken in die Zukunft verschoben werden. Es wird immer
teurer, Fehler früherer Phasen rückgängig zu machen. Dadurch besteht die Ten-
denz, die Risiken eines Projektes zu verbergen, bis es zu spät ist, Gegenmaßnah-
men zu ergreifen (siehe Bild 2-20). Die notwendige Zusammenarbeit der unter-
schiedlichen beteiligten Rollen in den Phasen wird ebenfalls kaum unterstützt.
Softwareentwicklungsprojekte hatten deshalb mit den gleichen Problemen der
Bild 2-19: Historie der Vorgehensmodelle [OHJ+98, S. 17]
Wasserfall-
modell
Phasenmodell
Phasen-/
Tätigkeits-
modell
Komponenten-
modell U-Modell
Spiralmodell
1960
1970
1980
1975
1990
Seite 54 Kapitel 2
„Throw it over the wall“-Mentalität zu kämpfen, die im Bereich der Ingenieurwis-
senschaften zu den Konzepten des Simultaneous/Concurrent Engineering führ-
ten86.
Aus diesen Gründen sind die Phasenmodelle nach und nach erweitert und weiter-
entwickelt worden. Der erforderliche hohe Grad der Zusammenarbeit aller Betei-
ligten am Gesamtprozess führte zu einer mehr inkrementellen87 und iterativen88
Vorgehensweise, z.B. im Spiralmodell von Boehm [Boe88]. Wichtigster Aspekt ist
hier, dass alle im Projekt Beteiligten, die Anwender und betroffene Organisations-
Bild 2-20: Das Wasserfallmodell der Softwareentwicklung erhöht das Risiko des
Scheiterns von Projekten [Kru99, S. 6]
86. Concurrent bzw. Simultaneous Engineering (SE) ist das bekannteste und am weitesten verbrei-
tete Integrationskonzept für die produzierende Industrie. SE zielt auf eine Verkürzung von Ent-
wicklungszeiten bei gleichzeitiger Steigerung der Produktqualität durch eine verbesserte
Abstimmung zwischen den am Entwicklungsprozess beteiligten Bereichen [GLR+00, S. 12].
Wesentliche Merkmale eines im Sinne von SE organisierten Entwicklungsprozesses sind die
mit zeitlicher Überlappung durchgeführten Entwicklungsphasen (Prozessparallelisierung) und
regelmäßige fachübergreifende Abstimmungsvorgänge (organisatorische Integrationsmaßnah-
men). Insbesondere durch diese Abstimmungsvorgänge sollen kosten- und zeitintensive Ände-
rungen in den späten Phasen des Entwicklungsprozesses vermieden werden [EBL95], [TSS00].
87. Inkrement: Betrag, um den eine Größe zunimmt [Dud90, S. 349]. Eine inkrementelle Vorge-
hensweise ist also dadurch gekennzeichnet, dass ein Produkt schrittweise in wachsenden Zwi-
schenprodukten entsteht [OHJ+98, S. 358].
88. Iterativ: wiederholend; Aktionsart, die eine häufige Wiederholung von Vorgängen ausdrückt;
sich schrittweise in wiederholten Rechengängen der exakten Lösung annähernd [Dud90, S.
370]. Eine iterative Vorgehensweise ist also dadurch gekennzeichnet, dass der Entwicklungs-
prozess in mehrere gleichartige Zeitabschnitte zerlegt wird [OHJ+98, S. 359].
Anforderungs-
analyse
Code &
Einheitentest
Subsystem-
test
Systemtest
Zeit
Risiko
Design
Einführung von PDM-Systemen Seite 55
einheiten, durch regelmäßige Validierungsschritte (siehe Bild 2-21) über das bis-
her Geleistete und das im nächsten Zyklus Geplante Einigkeit erzielen. Fehler wer-
den früher erkannt und Lösungsalternativen können mit vertretbarem Aufwand
erwägt werden [PB96, S. 28].
Die Entwicklungen der Vorgehensmodelle und die dahinter liegenden Gründe sind
Gegenstand zahlreicher Veröffentlichungen89 und müssen hier nicht weiter vertieft
werden. Es ist festzustellen, dass eine Kombination einer übergeordneten sequenti-
ellen Vorgehenweise mit inkrementellen und iterativen Elementen in einzelnen
Phasen nach heutigem Kenntnisstand den Anforderungen von großen Softwarepro-
jekten am ehesten genügt.
2.3.3 Schlussfolgerungen
Es lassen sich aus den Erfahrungen und Entwicklungen der Vorgehensmodelle der
Softwareentwicklung allgemeine Anforderungen an ein Vorgehensmodell zur
PDM-Einführung ableiten.
Dieses muss zunächst, um vollständig zu sein, alle notwendigen in Kapitel 2.3.1
erläuterten Bestandteile (Aktivitäten, Ergebnisse, Rollen und Methoden) beinhal-
ten. Des weiteren soll es eine übergeordnete sequentielle Struktur haben. Einzelne
Sequenzschritte können inkrementelle und iterative Elemente enthalten. Beglei-
Bild 2-21: Der iterative und inkrementelle Prozess [Kru99, S. 7]
89. Siehe dazu [OHJ+98, 16ff], [PB96, S. 17ff], [PS94, S. 35ff und S. 63ff], [Bal92, S. 468f].
Vorplanung
Planung
Anforderungen
Analyse & Design
Implementierung
Verteilung
Test
Evaluierung
Jede Iteration
ergibt ein aus-
führbares Release
Seite 56 Kapitel 2
tende Maßnahmen wie Projekt-, Qualitäts- und Konfigurationsmanagement müs-
sen ebenfalls berücksichtigt werden.
Zusätzlich ist es sinnvoll, für einen Teil der PDM-Einführung ein vorhandenes
Vorgehensmodell der allgemeinen Softwareentwicklung zu integrieren (siehe auch
Kapitel 2.2.7).
2.4 Personalplanung und -entwicklung
Als Personal oder Human Resources90 werden in Unternehmen auf die Erfüllung
der jeweiligen Aufgaben beschäftigte Personen bezeichnet [WMN93, S. 196]. Mit
der Entwicklung der Industriegesellschaft hat sich seit dem 19. Jahrhundert in den
Unternehmen mit dem Personalwesen ein eigener Funktionsbereich zur Steuerung
des Produktionsfaktors Arbeit herausgebildet. Parallel dazu entstand mit der Perso-
nalwirtschaftslehre ein entsprechender Zweig der Betriebswirtschaftslehre. Mitt-
lerweile wird der Begriff Personalmanagement verwandt. Damit wird der Entwick-
lung von der reinen quantitativen Personalverwaltung zur ganzheitlichen Planung,
Steuerung und Überwachung des Personaleinsatzes Rechnung getragen [Sta91, S.
718ff]. Das Personalmanagement umfasst im Allgemeinen neun Aufgabenfelder,
die jeweils zentrale Fragen beantworten [Sch94, S. 45ff]:
Personalbestandsanalyse: Wie viele Mitarbeiter welcher Qualifikation sind zur
Zeit vorhanden bzw. werden aufgrund der bereits feststehenden Veränderungen zu
welchem Zeitpunkt vorhanden sein?
Personalbedarfsbestimmung: Wieviele Mitarbeiter welcher Qualifikation wer-
den aufgrund der vorgegebenen Sachaufgaben zu welchem Zeitpunkt benötigt?
Personalbeschaffung: Wie können und sollen zusätzlich benötigte Mitarbeiter auf
dem externen oder internen Arbeitsmarkt gewonnen werden?
Personalentwicklung: Wie können und sollen die Fähigkeiten der Mitarbeiter im
Hinblick auf den bestehenden bzw. den zukünftigen qualitativen Personalbedarf
erhöht werden?
Personalfreisetzung: Wie kann überzähliges Personal aus einem Unternehmens-
bereich unter Berücksichtigung sozialer Gesichtspunkte abgebaut werden?
Personalveränderung: Wie soll zwischen alternativen Möglichkeiten zur Perso-
nalveränderung (Beschaffung, Entwicklung, Freisetzung) entschieden werden?
Personaleinsatz: Wie können Mitarbeiter entsprechend ihren Fähigkeiten und ent-
sprechend der Sachaufgaben eingesetzt werden?
90. „Menschliche Mittel“: Der Begriff gründet sich aus der englischen Bezeichnung der klassischen
Produktionsfaktoren Arbeit, Boden und Kapital (Human, natural and monetary resources).
Einführung von PDM-Systemen Seite 57
Personalführung: Wie kann und soll das Verhältnis zwischen Vorgesetzten und
Untergebenen im Hinblick auf eine weitergehende Integration von Unternehmens-
und Individualzielen ausgestaltet werden?
Personalkostenmanagement: Welche gegenwärtigen und zukünftigen Kosten
verursachen der aktuelle bzw. der zukünftige Personalbestand, die aktuellen bzw.
geplanten personellen Einzelmaßnahmen sowie die (vorgesehenen) Planungsmaß-
nahmen?
Diese Felder beinhalten alle Tätigkeiten, die im betrieblichen Personalmanage-
ment durchzuführen sind. Im Rahmen von Projekten wie der Einführung von
PDM-Systemen sind nicht alle Felder bzw. deren Tätigkeiten relevant. Im Folgen-
den Kapitel 2.4.1 werden die Personalmanagementaufgaben deshalb eingegrenzt
und nur die Aufgaben detaillierter beschrieben, die im Rahmen von Projekten von
Bedeutung sind.
2.4.1 Eingrenzung der Personalmanagementaufgaben im Rahmen
der PDM-Einführung
Die Personalmanagementaufgaben lassen sich allgemein nach zwei Dimensionen
aufteilen, dem Aufgabenschwerpunkt und dem Zeithorizont. Bei den Aufgaben-
schwerpunkten unterscheidet man zwischen quantitativen Aufgaben, die sich mit
der Menge der benötigten Mitarbeiter beschäftigen und qualitativen Aufgaben,
deren Fokus die Übereinstimmung von Aufgaben und Fähigkeiten ist. Vom Zeit-
horizont her unterscheidet man zwischen kurzfristig, mittelfristig und langfristig.
Kurzfristige Aufgaben umfassen den Zeitraum der nächsten ein bis zwei Jahre,
mittelfristige die Planung für fünf bis zehn Jahre und langfristige beziehen sich auf
einen Zeitraum von mehreren Jahrzehnten [WMN93, S. 216].
Wie aus Bild 2-22 ersichtlich, dauern mehr als die Hälfte der PDM-Projekte weni-
ger als zwei Jahre91. Das Personalmanagement für die PDM-Einführung, d.h. für
die in den Projekten beteiligten Mitarbeiter, wird daher als kurzfristig eingestuft.
Die von der PDM-Einführung ausgehenden Veränderungen von Geschäftsprozes-
sen und Arbeitsabläufen prägen das Unternehmen für einen längeren Zeitraum.
Die damit verbundenen Personalmanagementaufgaben, die sich auf die späteren
Anwender des PDM-Systems beziehen, sind deshalb als mittelfristig anzusehen.
Mit diesen Unterscheidungen und in Anbetracht der in Kapitel 2.1 und Kapitel 2.2
an verschiedenen Stellen angesprochenen mitarbeiterbezogenen Problemstellun-
gen kristallisieren sich die in Tabelle 2-3 eingeordneten Personalmanagementauf-
91. Dabei wird hier von der PDM-Einführung als einem großen Projekt ausgegangen. Gemäß der in
Kapitel 2.2.5 gemachten Definition, nach der die PDM-Einführung als Folge verknüpfter Pro-
jekte anzusehen ist, sind die in der Befragung gemachten Angaben noch einmal zu unterteilen.
Der Anteil von Projekten unter zwei Jahren ist somit noch höher einzuschätzen.
Seite 58 Kapitel 2
gaben als relevant für die PDM-Einführung heraus. Zum größten Teil handelt es
sich dabei um planerische Tätigkeiten. Lediglich die Personalentwicklung selbst
ist dem nicht zuzuordnen. Im weiteren Verlauf der Arbeit sollen die Tätigkeiten
deshalb unter „Personalplanung und -entwicklung“ zusammengefasst werden.
2.4.1.1 Kurzfristige Aufgaben im Rahmen der Projektplanung
Da es sich bei der PDM-Einführung um ein bzw. mehrere Projekte handelt, wird
sie entprechend durch ein für den Projektzeitraum zusammengestelltes Team
durchgeführt. Dieses muss zum einen eine ausreichende Anzahl an Mitarbeitern
enthalten, um die Aufgaben im gesteckten Zeitrahmen zu erfüllen. Dazu erfolgt
Bild 2-22: Personalmanagementaufgaben für PDM-Projekte sind als kurzfristig
anzusehen, weil mehr als die Hälfte der Projekte kürzer als zwei Jahre
dauern [PDM02-ol]
Tabelle 2-3: Kategorisierung der Personalmanagementaufgaben im Rahmen der
PDM-Einführung
quantitativ qualitativ
kurzfristig
Personalbedarfsermittlung
Personaleinsatzplanung
Personalbedarfsermittlung
Personaleinsatzplanung
Personalentwicklungsplanung
Personalbeschaffungsplanung
Personalentwicklung
mittelfristig
Personalbedarfsermittlung
Personalbestandsermittlung
Personalfreisetzungsplanung
Personalbedarfsermittlung
Personalbestandsermittlung
Personaleinsatzplanung
Personalentwicklungsplanung
Personalentwicklung
langfristig --
Keine Antwort
7%
< 3 Monate
2%
3 - 6 Monate
12%
7 - 12 Monate
20%
1 - 2 Jahre
20%
> 2 Jahre
39%
Einführung von PDM-Systemen Seite 59
eine quantitative Personalbedarfsermittlung. Diese erfolgt im Rahmen der Pro-
jektvorbereitung auf Basis der geplanten Tätigkeiten und dem damit verbundenen
geschätzten Aufwand.
Es reicht allerdings nicht aus, nur die Anzahl der benötigten Mitarbeiter festzule-
gen. Viel bedeutender ist die Ermittlung der benötigten Qualifikationen bzw. Kom-
petenzen der Mitarbeiter durch die qualitative Personalbedarfsermittlung. Der
Begriff Qualifikation bzw. Kompetenz92 umfasst dabei die Summe aller Fähigkei-
ten, die zur Erfüllung einer bestimmten Tätigkeit erforderlich sind [WMN93, S.
229]. Aufgrund vielfältiger in Kapitel 2.1 und Kapitel 2.2 genannter Gründe
bezieht sich dies nicht nur auf fachliche Kompetenz, z.B. die Kenntnis einer
bestimmten Modellierungstechnik, sondern auch auf die so genannte humanorien-
tierten Kompetenz93, z.B. die Fähigkeit zum logischen Denken. Zur Ermittlung
des Bedarfes muss hier also auf Basis der zu bewältigenden Aktivitäten festgelegt
werden, welche fachlichen und humanorientierten Kompetenzen ein Mitarbeiter
haben muss.
Die Zuordnung geeigneter Mitarbeiter zu den Tätigkeiten im Projekt ist Aufgabe
der qualitativen Personaleinsatzplanung. Dabei ist auch deren Verfügbarkeit zu
berücksichtigen (quantitative Personaleinsatzplanung). Die Planung basiert dabei
auf dem aktuellen Bestand der Mitarbeiter des Unternehmens. Die Personalbe-
standsermittlung ist aber keine Tätigkeit, die im Rahmen der Projektvorbereitung
durchgeführt wird. Sie ist vielmehr dem ständigen operativen Personalmanage-
ment zuzuordnen.
Nicht immer sind geeignete Mitarbeiter in ausreichender Anzahl verfügbar (siehe
Kapitel 2.2.3). Dann ist im Rahmen der qualitativen Personalentwicklungsplanung
zu prüfen, ob sich die Mitarbeiter bestimmte fehlende Kompetenzen noch durch
eine Qualifizierung94 aneignen können. Ist dies möglich, wird die entsprechende
Personalentwicklung meistens in Form von Weiterbildung angestossen. Wenn das
nicht möglich ist, muss entweder auf dem externen Arbeitsmarkt nach einem
geeigneten Mitarbeiter gesucht werden (qualitative Personalbeschaffungsplanung)
oder die Tätigkeit an ein externes Dienstleistungsunternehmen vergeben werden
(siehe Kapitel 2.2.4).
92. Im weiteren Verlauf der Arbeit wird der Begriff „Kompetenz“ verwendet.
93. In der Literatur finden sich auch weitere Begriffe wie Soziale Kompetenz [Son99] oder, die
Wichtigkeit dieser Faktoren für die moderne Arbeitswelt betonend, Schlüsselqualifikation
[GSE+98], [Lan00].
94. Unter Qualifizierung versteht man allgemein die Durchführung von Maßnahmen zur Vermitt-
lung von Wissen und zur Erlangung von notwendigen Fähigkeiten, die es dem Mitarbeiter
erlauben, seine Aufgaben zu lösen. [GLR+00, S. 23]
Seite 60 Kapitel 2
2.4.1.2 Mittelfristige Aufgaben im Rahmen der Projektdurchführung
Neben den Projektmitarbeitern sind die Anwender des PDM-Systems die zweite
Gruppe von Mitarbeitern, für die die Personalplanung und -entwicklung bei der
PDM-Einführung eine große Rolle spielen. In Kapitel 2.1.1.1 ist ausführlich erläu-
tert worden, dass bei einer PDM-Einführung neben der Anwendung eines neuen
Systems vor allem die neuen Prozesse und Denkweisen eine besondere Herausfor-
derung darstellen. Es gelten hier im Prinzip die gleichen Fragestellungen, wie bei
der in Kapitel 2.4.1.1 beschriebenen kurzfristigen Personalplanung:
• Wie viele Mitarbeiter werden für die neuen Prozesse benötigt?
(quantitative Personalbedarfsermittlung)
• Wie viele Mitarbeiter sind vorhanden?
(quantitative Personalbestandsermittlung)
• Welche Kompetenzen werden für die neuen Prozesse benötigt?
(qualitative Personalbedarfsermittlung)
• Haben die Mitarbeiter diese Kompetenzen?
(qualitative Personalbestandsermittlung)
• Welche Mitarbeiter besetzen in Zukunft welche Stellen?
(qualitative Personaleinsatzplanung)
• Wie schaffe ich die fehlenden Kompetenzen?
(qualitative Personalentwicklungsplanung)
Weil die PDM-Einführung durch die Verbesserung von Abläufen und die Automa-
tisierung von Tätigkeiten auch ein Rationalisierungspotential enthält, gehört auch
die Personalfreisetzungsplanung zu den relevanten Tätigkeiten. Die Frage lautet:
• Wie viele Mitarbeiter kann ich einsparen?
(qualitative Personalfreisetzungsplanung)
Betrachtet man die aktuelle Diskussion über den zunehmenden Mangel an Fach-
kräften, insbesondere Ingenieuren [VDI02b-ol] und setzt dagegen die Wachstums-
ziele der meisten Industrieunternehmen, verliert der Aspekt der Personalfreistel-
lung an Bedeutung. Selten werden Rationalisierungspotentiale beim Personal in
PDM-Einführungen realisiert. Es geht vielmehr darum, die Mitarbeiter von
bestimmten Tätigkeiten zu entlasten, um ihnen die Möglichkeit zu geben, das stei-
gende Arbeitsvolumen überhaupt zu bewältigen. Ein Einsparungspotential für das
Unternehmen ergibt sich dann eher durch den Abbau teurer Überstunden.
Neben den bisher genannten mittelfristigen planerischen Tätigkeiten erwächst aus
der Personalentwicklungsplanung natürlich auch der Bedarf an der Durchführung
von Personalentwicklungsmaßnahmen. Darunter fallen sowohl die Schulungsmaß-
nahmen zu den neuen Prozessen und dem neuen System für das bestehende Perso-
nal als auch entsprechende Maßnahmen zur Einarbeitung neuer Mitarbeiter.
Einführung von PDM-Systemen Seite 61
2.4.2 Schlussfolgerungen
Die PDM-Einführung beinhaltet kurzfristige und mittelfristige Tätigkeiten zur Per-
sonalplanung und -entwicklung. Diese sind als Aktivitäten im Vorgehensmodell zu
berücksichtigen und wie die übrigen Aktivitäten mit Methoden zu unterstützen.
Besondere Bedeutung haben dabei allgemein die kompetenzgerechte Zuordnung
der Mitarbeiter zu den Aufgaben sowie die Ermittlung und Qualifizierung von feh-
lenden Kompetenzen.
Die Qualität des Ergebnisses der PDM-Einführung ist von den Kompetenzen der
Projektmitarbeiter abhängig. Ihre Auswahl muss deshalb besonders betrachtet wer-
den.
2.5 Anforderungen
Aus der ausführlichen Problemanalyse lassen sich in Bezug auf die PDM-Einfüh-
rung folgende Anforderungen ableiten:
A1 Das Vorgehen zur PDM-Einführung ist in einem Vorgehensmodell zu struk-
turieren. Das Vorgehensmodell muss vollständig in der Beschreibung sein,
also Aktivitäten, Ergebnisse und Akteure enthalten. Außerdem soll das Vor-
gehensmodell systemunabhängig und frei verfügbar sein.
A2 Das Vorgehensmodell muss alle Phasen vom Anstoß der Einführung bis zum
Betrieb des Systems umfassen. Zusätzlich müssen begleitende Aktivitäten wie
das Projektmanagement berücksichtigt werden.
A3 Die Aktivitäten des Vorgehensmodells müssen möglichst vollständig durch
Methoden unterstützt werden. Dabei ist auf eine hohe Durchgängigkeit der
Methoden im Übergang zwischen Aktivitäten zu achten. Als spezielle Metho-
den sind die Anwendung von Referenzmodellen, des Prototypings sowie eine
iterative und inkremtelle Softwareentwicklungsmethode zu integrieren.
A4 Die PDM-Einführung muss in die Unternehmensstrategie eingebunden wer-
den. Daher soll das Vorgehensmodell im Grundsatz eine Top-Down-Strate-
gie abbilden. In der Betrachtung des Nutzens der PDM-Einführung sind
strategische Aspekte zu berücksichtigen. Diese müssen durch strategische
Kennzahlen untermauert und überprüft werden. In der Organisation der
PDM-Einführung muss die Unterstützung durch das Top-Management fest
verankert werden.
A5 Das Vorgehensmodell muss PDM-spezifische Aspekte berücksichtigen. Dazu
gehören die Paradigmenwechsel, die Abbildung eines Metadatenmodells,
die Notwendigkeit der Altdatenübernahme und die Realisierung durch eine
Standardsoftware.
A6 Im Vorgehensmodell muss der besondere Integrationscharakter von PDM
berücksichtigt werden. Dies bezieht sich sowohl auf die Verbindung zu ande-
Seite 62 Kapitel 2
ren strategischen IT-Komponenten als auch auf die Rolle von PDM als Inte-
grationsplattform für Anwendungen.
A7 Das Vorgehensmodell muss die kurz- und mittelfristigen Aktivitäten der Per-
sonalplanung und -entwicklung berücksichtigen. Basis dafür sollen die für
die Aufgabenerfüllung notwendigen Kompetenzen sein. Dabei sind neben
den fachlichen Kompetenzen auch die humanorientierten Kompetenzen zu
betrachten.
A8 Die Personalplanung und -entwicklung muss explizit die Notwendigkeit zum
Ausgleich von Kompetenzdefiziten sowie die Beteiligung externer Mitarbei-
ter berücksichtigen.
Unabhängig von der PDM-Einführung ergibt sich aus dem in Kapitel 2.2.3 und
Kapitel 2.2.4 angesprochenen Problemen eine weitere allgemeine Anforderung:
A9 Es müssen Ausbildungsmöglichkeiten geschaffen werden, um den in Zukunft
wachsenden den Bedarf an Mitarbeitern mit PDM-Kenntnissen sowohl auf
Seiten der Anwender als auch auf Seiten der Dienstleister zu decken.
Stand der Technik Seite 63
3 Stand der Technik
Das Ziel dieses Kapitels ist die Überprüfung des Standes der Technik. Dazu wer-
den die bestehenden Vorgehensmodelle zur PDM-Einführung hinsichtlich der
Erfüllung der in Kapitel 2.5 zusammengefassten Anforderungen analysiert, Es las-
sen sich hier Defizite feststellen, die zu einem Handlungsbedarf führen.
Aufgrund der in Kapitel 2.2 erläuterten Wichtigkeit der methodischen Durchgän-
gigkeit in den Phasen werden auch Vorgehensmodelle der allgemeinen Software-
entwicklung hinsichtlich ihrer Relevanz betrachtet.
3.1 Vorgehensmodelle zur Einführung von PDM-Systemen
In der Literatur finden sich eine Vielzahl von Vorschlägen, wie das Vorgehen der
PDM-Einführung zu gestalten ist. Die im Folgenden analysierten Modelle stellen
einen repräsentantiven Querschnitt über die in der Literatur aufgeführten Modelle
dar. Es lassen sich auf Grund der Quelle vier Kategorien von Modellen unterschie-
den:
• Einführungsmodelle von Standardisierungsgremien und Verbänden,
• Einführungsmodelle aus dem Bereich der Forschung,
• Einführungsmodelle mit industriellem Hintergrund sowie
• Einführungsmodelle von PDM-Systemanbietern und Beratungsunternehmen.
Die Modelle werden jeweils kurz charakterisiert und dann im Hinblick auf die
Erfüllung der in Kapitel 2.5 aufgestellten Anforderungen bewertet. Dabei wird an
entsprechender Stelle auf die Nummern der Anforderungen im Katalog referen-
ziert1.
3.1.1 Einführungsmodelle von Standardisierungsgremien und
Verbänden
Auf nationaler Ebene hat sich der Verband Deutscher Ingenieure (VDI) dem
Thema der PDM-Einführung angenommen und als Leitfaden die VDI Richtlinie
2219 „Datenverarbeitung in der Konstruktion - Einführung und Wirtschaftlichkeit
von EDM/PDM-Systemen“ veröffentlicht. Internationale Bemühungen zur Stan-
dardisierung im Bereich PDM gehen von der STEP2-Initiative und der Object
Management Group3 (OMG) aus.
1. A1 bis A9.
2. STEP, der „STandard for the Exchange of Product model data“, ist eine Aktivität zur Schaffung
internationaler Standards unter der Schirmherrschaft des ISO TC184/SC4 (International Orga-
nization for Standardization, Technical Committee 184 „Industrial automation systems and inte-
gration“, Subcommittee 4 „Industrial Data“). Ziel ist es, verbindliche Vorgaben für den Aus-
tausch von Produkdaten über den gesamten Lebenszyklus zu definieren. [OMG99, S. 9]
Seite 64 Kapitel 3
3.1.1.1 VDI-Richtline 2219
Die VDI Richtlinie 2219 „Datenverarbeitung in der Konstruktion - Einführung und
Wirtschaftlichkeit von EDM/PDM-Systemen“ [VDI99] definiert ein Vorgehens-
modell für die PDM-Einführung. Sie wurde erstellt, um Wissen und Erfahrung von
Unternehmen und Institutionen über die PDM-Einführung sowie bewährte Vorge-
hensweisen zur Verfügung zu stellen. Interessierte Unternehmen wird ein Leitfa-
den für die PDM-Einführung an die Hand gegeben [Vaj99]. Die Richtlinie ist bis-
her als Entwurf veröffentlicht, dieser bildet die Grundlage der Analyse, da die
endgültige Fassung der Richtlinie voraussichtlich im November 2002 erscheint.
Bild 3-1 zeigt das in der Richtlinie vorgeschlagene Vorgehen zur PDM-Einfüh-
rung. Es wird zunächst mit einer Gestaltungsphase begonnen, in der die Projektor-
ganisation der PDM-Einführung aufgestellt und eine Ist-Analyse durchgeführt
wird. In der anschließenden Konzeptionsphase erfolgt die Definition einer Soll-
konzeption und die darauf folgende Systemauswahl. Auf Basis der Systemauswahl
werden in der Projektdurchführungsphase zunächst Prototpypen und Piloten
erstellt. Anschließend erfolgt die Systemimplementierung, bevor das System in
den Betrieb übergeben wird.
Das Modell deckt somit nahezu alle Phasen der PDM-Einführung inklusive des
begleitenden Projektmanagements ab (A2). Lediglich die Einbindung in die Unter-
nehmensstrategie erfolgt unzureichend. Es wird zwar auf strategische Anforderun-
gen an das System hingewiesen, welchen Einfluss diese auf die PDM-Einführung
haben, wird aber nicht erläutert (A4). Die Beschreibung der Phasen erfolgt relativ
grob und nicht vollständig mit Ergebnissen und Akteuren für jede Aktivität (A1).
Ausführliche Methoden werden nur für die Wirtschaftlichkeitsbetrachtung angebo-
ten, eine Softwareentwicklungssystematik ist ebenfalls nicht eingebunden. Dafür
ist der Einsatz von Prototypen ausdrücklich vorgesehen (A3). PDM-spezifische
Aspekte werden bis auf die mit der Einführung verbundenen Paradigmenwechsel
3. Die Object Management Group ist ein Zusammenschluß führender Soft- und Hardwareherstel-
ler, deren Ziel die Definition allgemeiner Standards für alle Bereiche der Objektorientierung ist.
Bild 3-1: Phasenmodell der PDM-Einführung nach VDI 2219 [VDI99]
Projekt-
organisation Ist-Analyse Sollkonzeption System-
auswahl
Prototypen-
und Pilotphase
System-
implemen-
tierung
Konzeptionsphase
Pflichtenheft,
strategische Entscheidung
Prozessmodell,
Aufbau- und
Ablauforganisation
PDM-
Einführung
Gestaltungsphase
Vorprojekt
Projektdurchführungsphase
Betrieb
Stand der Technik Seite 65
gut berücksichtigt (A5). Auch der Integrationscharakter von PDM findet Beach-
tung (A6). Aus dem Bereich der Personalplanung und -entwicklung werden nur die
Anwenderschulungen und die Beteiligung externer Mitarbeiter ausreichend
betrachtet (A7, A8).
Zusammenfassend lässt sich sagen, dass das Vorgehensmodell der VDI-Richtlinie
2219, besonders was den direkten Bezug zu PDM angeht, viele Stärken hat. Dabei
werden aber die wichtigen strategischen und personalbezogenen Aspekte vernach-
lässigt.
3.1.1.2 STEP PDM Schema und OMG PDM Enablers
Neben den nationalen Standardisierungsbemühungen durch den VDI existieren im
internationalen Umfeld die Projekte PDM Enablers in der OMG [OMG00] und
PDMI2 (Product Data Management Based on International Standards) in der
STEP-Initiative [BHK00].
Die OMG verfolgt das Ziel, standardisierte Systemschnittstellen zu definieren, mit
denen verschiedene Systeme über die Rahmenarchitektur CORBA4 kommunizie-
ren. D.h. gegenseitig Systemfunktionen aufrufen und Daten austauschen. Schwer-
punkt hierbei ist die Bereitstellung von Systemfunktionalität. Die PDM Enablers
Spezifikation definiert dazu ein modularisiertes und hierarchisch strukturiertes
objektorientiertes Klassenmodell, das sich an den Aktivitäten und Funktionen
eines PDM-Systems orientiert [KWF00]. Sie beschreibt eine eher operationale
Schnittstelle für die Online-Kopplung, ohne die auszutauschenden Daten vollstän-
dig semantisch zu beschreiben. PDM-Systeme, die über eine nach PDM-Enablers
definierte Schnittstelle verfügen, können demnach gegenseitig Funktionen auf
einen freigegebenen Ausschnitt ihrer Informationsmodelle ausführen.
Im Gegensatz dazu gibt das im Rahmen des Projektes PDMI2 entstandene PDM
Schema eine vollständige semantische Beschreibung eines neutralen Datenaus-
tauschmodells auf der Basis der STEP Anwendungsprotokolle 214 und 203. Die-
ses beschreibt die auszutauschenden administrativen Daten bis hin zu einzelnen
Attributen von Datenobjekten. Auf dieser Grundlage kann ein dateibasierter
Datenaustausch zwischen PDM-Systemen erfolgen. Allerdings müssen diese über
entsprechende PDM Schema-konforme Post- und Preprozessoren für Export und
Import der STEP Daten verfügen. PDM-Funktionalitäten oder Aktivitäten werden
nicht wiedergespiegelt [LM99b].
Es wird deutlich, dass die Einführung von PDM-Systemen vorrangig keine Rolle
bei diesen internationalen Standardisierungsbemühungen spielt. Vorgehensmo-
4. Die Common Object Request Broker Architecture definiert eine allgemeine Architektur zur
Verwirklichung der Kommunikation zwischen objektorientierten Softwaresystemen. Sie ist
zusammen mit einem allgemeinen Objektmodell Bestandteil der von der OMG als Industrie-
standard vorgeschlagene Objektmanagementarchitektur (OMA) [OMG92].
Seite 66 Kapitel 3
delle sind kein Bestandteil der veröffentlichten Vorschläge (A1). Die beschriebe-
nen Funktionalitäten und Datenmodelle können dennoch eine Rolle in der
PDM-Einführung spielen. Es hat sich im Bereich der Einführung von ERP-Syste-
men als nützlich erwiesen, bei der Erstellung der Sollkonzeption auf so genannte
Referenzmodelle zurückzugreifen5. Dieses Vorgehen schlagen Karcher und Wirtz
auch für die PDM-Einführung vor [KW98], [KW00]. Die Funktions-, Daten- und
Prozessmodelle aus PDM Enablers und PDM Schema können in der Prototy-
ping-Phase als Referenzmodelle dienen, um bestimmte PDM-typische Vorgehens-
weisen zu demonstrieren6 (A3). Dies ist besonders dort sinnvoll, wo spezielles
PDM-Know-how im Unternehmen fehlt und somit auch die Vorstellung von den
Möglichkeiten, die diese neue Technologie bietet (siehe Kapitel Kapitel 2.2.3 und
Kapitel 2.2.6). Die Referenzmodelle werden auf die Anwendbarkeit und den zu
erzielenden Nutzen im betroffenen Unternehmen überprüft. Anwendbare und nut-
zenbringende Prozesse gehen in die Sollkonzeption ein.
3.1.2 Einführungsmodelle aus dem Bereich der Forschung
Aus dem Bereich der Forschung existieren eine große Anzahl an Ansätzen zur
Verbesserung der PDM-Einführung. In den meisten Fällen zielen diese Ansätze
allerdings darauf ab, einzelne Phasen der Einführung methodisch zu unterstützen.
Sie bieten deshalb kein vollständiges Vorgehensmodell an7. Diese Ansätze werden
hier auf Grund der Anforderung nach Vollständigkeit des Vorgehensmodells über
alle Phasen (A2) nicht betrachtet. Die im Folgenden analysierten Modelle umfas-
sen zumindest einen Großteil der Phasen der PDM-Einführung.
3.1.2.1 EDM-Studie des Fraunhofer-Institut für Arbeitswirtschaft und
Organisation IAO
Das Fraunhofer Institut für Arbeitswirtschaft und Organisation präsentiert in der
mittlerweile zweimal erschienenen Markstudie über PDM-Systeme [BHM96],
[BFR+98] neben der eigentlichen Untersuchung auch sein eigenes Leistungsange-
5. Branchen-Referenzmodelle fassen die allgemeingültigen Prozesse und Strukturen von Unter-
nehmen einer Branche zusammen. Durch weitergehende Spezialisierung können aus daraus
Modelle einzelner Unternehmen abgeleitet werden. Software-Referenzmodelle beschreiben
Strukturen, Funktionen und Abläufe, wie sie durch die Verwendung einer speziellen (zumeist
betriebswirtschaftlichen) Standard-Software unterstützt werden. [App97]
Das bekannsteste Beispiel eines Referenzmodells ist die „Architektur integrierter Informations-
systeme“ (ARIS) [Sch98b], [Sch98c], die vor allem im Umfeld der Einführung des
ERP-Systems SAP R/3TM eine große Bedeutung erlangt hat.
6. STEP PDM Schema und PDM Enablers sind dabei komplementär, d.h. sie ergänzen sich gegen-
seitig. Die Zusammenhänge zwischen den Standards sind in [OMG99, S. 16ff] ausführlich dar-
gestellt. Hinweise zur Implementierung von darauf basierenden Systemen gibt [OMG01].
7. Siehe z.B. [Höf99], [Kah00], [Wir01].
Stand der Technik Seite 67
bot. Dazu gehört u.a. die Beratung in PDM-Einführungsprojekten. Das zu diesem
Zweck entworfene Vorgehensmodell ist in Bild 3-2 dargestellt.
Die Beschreibung des Modells erfolgt nur grob und unvollständig auf Basis der
dargestellten Hauptphasen und ohne Berücksichtigung des Betriebes (A1). Beglei-
tende Maßnahmen und die Einbindung in die Unternehmensstrategie sind nicht
vorgesehen (A2, A4). Der Einsatz von Methoden wird unvollständig für die Pha-
sen von der Voranalyse bis zum „Style Freeze8“ vorgeschlagen, zusätzlich ist der
Einsatz von Prototypen berücksichtigt (A3). Personalplanung und -entwicklung
sind nicht Bestandteil des Modells.
Das vorgeschlagene Vorgehensmodell erfüllt also nur einen geringen Teil der
Anforderungen. Die Einbindung in die Unternehmensstrategie (A4) und die Perso-
nalplanung und -entwicklung (A7, A8) werden nicht berücksichtigt.
3.1.2.2 RapidPDM Implementation Methodology
RapidPDM ist eine von der Europäische Union (EU) gefördertes internationales
Projekt9. Es hat das Ziel, verbesserte Methoden und Werkzeuge für die Einführung
von PDM-Systemen zu schaffen. Der Fokus liegt dabei auf den frühen Phasen der
PDM-Einführung (siehe Bild 3-3), so dass das Modell nicht die komplette
PDM-Einführung abdeckt (A2). Die Beschreibung erfolgt formal und enthält Akti-
vitäten, Ergebnisse und Akteure (A1).
Auf Grund des Fokus auf den Beginn der PDM-Einführung sind die möglichen
Ausgangspunkte der PDM-Einführung und die strategischen Aspekte in den Pha-
sen „Awareness“ und „Readiness“ sehr ausführlich berücksichtigt (A4). Die drei
beschriebenen Phasen werden durch umfangreiche Methoden unterstützt, die zum
Bild 3-2: Die Phasen einer EDM-Implementierung nach [BFR+98]
8. Darunter wird der Zeitpunkt verstanden, an dem keine neuen Anforderungen an das
PDM-System mehr aufgenommen werden.
9. Projektnummer ESPRIT 26892, relevante Literatur siehe [Dun00], [Dun01], [PHM00].
Voranalyse-
phase
Vorprojekt-
phase
Analyse-
phase
Szenario-
phase
Design-
phase
Pilot-
phase
System-
implemen-
tierung
Projektdurchführung
Entscheidung für
ein EDM-Projekt
Entscheidung
Pilot
System-
entscheidung
“Style-
Freeze”
Kick-Off
Meeting
Seite 68 Kapitel 3
Teil aber nicht durchgängig über die Phasen sind. Da die Implementierung nicht
mehr im Fokus des Modells liegt, sind keine Ansätze zum Prototyping und zur
Integration einer Methode der allgemeinen Softwarentwicklung enthalten. Die
begleitenden Aktivitäten im Rahmen des Projektmanangements werden ebenfalls
nicht einbezogen. Sie werden sogar explizit als nicht zum Modell gehörend ausge-
grenzt (A3).
In Bezug auf die PDM-spezifischen Aspekte, die das Vorgehensmodell zu berück-
sichtigen hat, erfüllt die RapidPDM Implementation Methodology nur einen Teil
der Anforderungen. Die Paradigmenwechsel werden zum Teil in der Phase „Rea-
diness“ adressiert. Im Rahmen der „Implementation Preparation“ findet die gefor-
derte Auswahl einer Standardsoftware statt (A5).
Die Personalplanung und -entwicklung nimmt einen erheblichen Teil der Beschrei-
bung der RapidPDM Implementation Methodology ein und berücksichtigt vor
allem humanorientierte Aspekte. Alle Ausführungen beziehen sich dabei auf die
späteren Anwender des PDM-Systems, eine Betrachtung der notwendigen Maß-
nahmen für die Projektmitarbeiter findet nicht statt (A7).
Die RapidPDM Implementation Methodology bietet insbesondere wegen ihrer
starken Betonung des strategischen Charakters einen vielversprechenden Ansatz
für die PDM-Einführung. Ihre Anwendbarkeit wird durch die Fokussierung auf die
Phasen vor der Systemanpassung aber erheblich eingeschränkt.
Bild 3-3: Die 5 Phasen des RapidPDM-Einführungsprozesses [PHM00]
Monitoring
Awareness
Readiness
Implementation
Preparation
Implementation
Launch
RapidPDM Fokus
Stand der Technik Seite 69
3.1.2.3 Einführungstrategie für Engineering Data Management-Systeme
nach Eversheim
Die Einführungstrategie für Engineering Data Management-Systeme nach Evers-
heim [ERW96] enthält vor allem Anleitungen für intensive Analysen zur Vorberei-
tung einer PDM-Einführung (siehe Bild 3-4). Aus den Ergebnissen der Analysen
werden Erkenntnisse abgeleitet, die zur Anpassung des PDM-Systems benötigt
werden. Außerdem bilden die Ergebnisse die Basis zur Beurteilung der Wirtschaft-
lichkeit.
Die Einführungstrategie für Engineering Data Management-Systeme beschreibt
das Vorgehen zur PDM-Einführung nur unzureichend. Sie ist unvollständig in
Bezug auf die allgemeinen Elemente eines Vorgehensmodells (Aktivitäten, Ergeb-
nisse, Akteure) (A1) und beinhaltet nicht alle Phasen (A2). Die beschriebenen Pha-
sen der Analyse und Konzeption werden nur zum Teil durch Methoden unterstützt
(A3). Die entscheidenden Aspekte der strategischen Einbindung der PDM-Einfüh-
rung (A4) und der Personalplanung und -entwicklung (A7, A8) werden von dem
Vorgehensmodell nicht aufgegriffen.
Bild 3-4: Strategie zur Einführung von Engineering Data Management Systemen
[ERW96]
Ergebnisse
Prozessanalyse
Dokumentenanalyse EDV-Hilfsmittelanalyse
Tätigkeitsanalyse
- EDV-Einsatz
- Änderungsanteil
- ...
- Tätigkeitsverteilung
- organisatorische
Maßnahmen
- Sachmerkmal-Leiste
- Nummernsystematik
- Dokumentenstruktur
- Nomenklatur
- Ist-/Sollabläufe
- Aufwands- und
Nutzenabschätzung
- Systembeschreibungen
Seite 70 Kapitel 3
3.1.2.4 Nutzenorientierte Einführung von PDM-Systemen nach Wehlitz
Die nutzenorientierte Einführung von PDM-Systemen nach Wehlitz [Weh00]
beschreibt ein Vorgehensmodell zur PDM-Einführung. Darin wird, ausgehend von
einem groben generischen Modell (siehe Bild 3-5), die Reihenfolge der Umset-
zung von Funktionen durch den Anwendernutzen bestimmt. Dieser ist aus dem
Datenbefüllungsgrad, der durch die einzuführenden Funktionen erreicht wird,
abgeleitet. Der Datenbefüllungsgrad wird dabei an Hand der Anzahl der im System
gespeicherten Datenobjekte und Verknüpfungen ermittelt, wobei diese von ihrer
Bedeutung her gewichtet werden.
Das Modell von Wehlitz beschreibt die PDM-Einführung auf einer relativ hohen
Ebene bzw. geringen Phasendetaillierung. Dadurch entfallen eine Reihe von not-
wendigen Schritten, die beachtet werden sollten (A1, A2). Der Methodeneinsatz ist
zum Teil sehr detailliert, aber nicht vollständig und durchgängig über alle Phasen
(A3).
Strategische Aspekte und einige wichtige PDM-Spezifika wie die Paradigmen-
wechsel werden nur sehr wenig berücksichtigt (A4, A5). Dies resultiert vor allem
aus dem oben beschriebenen einseitigen Nutzenbegriff10.
Die Personalplanung und -entwicklung findet in dem Vorgehensmodell nur zum
Teil Berücksichtigung. Es wird ansatzweise auf notwendige Kompetenzen und die
Zusammensetzung des Projektteams eingegangen. Eine methodische Herleitung
findet aber nicht statt. Qualifizierungsmaßnahmen sind nicht enthalten (A7, A8).
Insgesamt genügt das von Wehlitz vorgeschlagene Vorgehensmodell den Anforde-
rungen nicht. Grund dafür ist die starke Einengung auf die Datenbefüllung als ein-
zigen Nutzen stiftenden Aspekt von PDM-Systemen. Die beschriebenen Methoden
rund um die Bewertung der Datenbefüllung sind eher als Ergänzung für einzelne
Bild 3-5: Vorgehensmodell für die nutzenorientierte PDM-Einführung nach
[Weh00, S. 36]
10. Es ist anzuzweifeln, ob der Datenbefüllungsgrad als alleiniger Maßstab für den Nutzen eines
PDM-Systems gelten kann. Ab einem bestimmten Grad hindert eine zu hohe Informationsdichte
den Anwender eher daran, effizient zu arbeiten.
Ziel-
klärung System-
auswahl
PDM-
Einführung PDM-Betrieb
Projektmanagement
Stand der Technik Seite 71
Phasen der PDM-Einführung, insbesondere im Umfeld der Datenmigration, zu
sehen.
3.1.3 Einführungsmodelle mit industriellem Hintergrund
Berichte aus der industriellen Praxis der PDM-Einführungen beschränken sich
zumeist auf die Vermittlung von Projekterfahrungen, wie sie in die Problemana-
lyse in Kapitel 2.2 eingeflossen sind. Es finden sich aber auch einige ausführlicher
beschriebene Vorgehensmodelle. Die Autoren arbeiten zumeist bei Beratungsun-
ternehmen oder Systemanbietern, präsentieren aber ein eigenes allgemeines Vor-
gehen. Deshalb werden die Modelle nicht zu den in Kapitel 3.1.4 beschriebenen
Einführungsmodellen von PDM-Systemanbietern und Beratungsunternehmen
gezählt.
3.1.3.1 PDM-Einführung nach Eigner und Stelzer
Eigner und Stelzer strukturieren das Vorgehen zur PDM-Einführung in die in Bild
3-6 dargestellten Phasen. Ein besonderer Schwerpunkt des Modells liegt in der
Analyse eines optimalen Sollzustandes der Integration von Unternehmenbereichen
als Ziel der PDM-Einführung. Dieser ist definiert als höchstmögliche Integration
bei geringstmöglichen Kosten [ES01, S. 286ff].
Die Phasen des Modells werden auf Grund des speziellen Fokus nicht in einheitli-
cher Tiefe beschrieben. Auf die Analyse des Ist-Zustandes in der Problemphase
sowie die Erstellung der Soll-Konzeption in der Konzeptphase wird sehr detailliert
eingegangen. Die weiteren Phasen werden der Vollständigkeit halber erwähnt,
aber nicht weiter verfeinert. Das Modell ist somit unvollständig im Sinne der
Beschreibung und in der Abdeckung der Phasen (A1, A2).
Auch die vorgeschlagenen Methoden decken nur die Problemphase und die Kon-
zeptphase ab. Eine Durchgängigkeit ist dabei nicht gegeben. Prototyping, Best
Practices und Softwareentwicklungsmethodik sind im Gegensatz zu Projektmana-
gement nicht integriert (A3). Wegen des Fokus auf die frühen Phasen der
Bild 3-6: Phasen der PDM-Einführung nach Eigner/Stelzer [ES01, S. 288]
Problem-
phase
Konzept-
phase
Spezifi-
kations-
phase
Entwick-
lungs-
phase/
Umsetzung
Produk-
tions-
phase/
Roll-Out
Nutzungs-
phase
Auslauf-
phase
Seite 72 Kapitel 3
PDM-Einführung werden die Anforderungen in Bezug auf die Einbindung in die
Unternehmenstrategie weitestgehend erfüllt (A4). Außer der als Ziel der
PDM-Einführung festgelegten Integration (A6) werden die weiteren PDM-spezifi-
schen Aspekte nur unzureichend berücksichtigt (A5).
Die Personalplanung und -entwicklung wird im Vorgehensmodell nicht explizit
berücksichtigt. Es erfolgt lediglich ein Hinweis auf die Einbeziehung externer
Partner (A7, A8). Außerdem wird eine Projektorganisation vorgeschlagen, die für
die gesamte PDM-Einführung gilt.
Zusammenfassend lässt sich feststellen, dass hier ebenso wie beim Modell von
Wehlitz (siehe Kapitel 3.1.2.4) eine Beschränkung in den möglichen Zielen und im
Nutzenbegriff erfolgt, die eine generelle Anwendbarkeit des Modells in Frage
stellt.
3.1.3.2 Einführung von Produktdatenmanagementsystemen nach
Strohmayer/Suhm
Strohmeyer und Suhm schlagen das in Bild 3-7 dargestellte Vorgehen in sechs
Phasen für die PDM-Einführung vor [SS96].
Die Beschreibung der Phasen ist dabei nur grob und nicht vollständig, da weder die
Akteure noch einzusetzende Methoden benannt werden (A1, A3). Die Phasen der
PDM-Einführung sind auf hoher Aggregationssstufe nahezu vollständig berück-
sichtigt. Die geringe Detaillierung der Phasen führt allerdings dazu, dass einzelne
Aktivitäten sowie begleitende Maßnahmen fehlen (A2). Eine Einbindung der
PDM-Einführung in die Unternehmensstrategie ist nicht vorgesehen11 (A4).
Bild 3-7: Vorgehensmodell für die PDM-Einführung nach [SS96]
11. Der Begriff „Gesamtstrategie“ in der ersten Phase bezieht sich direkt auf die PDM-Einführung
und meint das Vorgehen im Projekt.
- Gesamt-
strategie
- Haupt-
prozesse
- Potential-
analyse
- Kosten-
Nutzen-
Analyse
=> Projekt-
rahmen
Projekt-
definition
- Produkt-
strukturen
- Nummern-
systematik
- Abläufe
=> Rahmen-
konzept
PDM-
Vorbereitung
- Pflichten-
heft
- Vorauswahl
- Detail-
Untersuchung
- Bewertung
=> Entschei-
dungs-
vorlage
System-
auswahl
- Projek-
tierung
- Datenmodell
- Artikel
- Dokumente
- Projekte
- Ergebnis-
kontrolle
=> Ausbau-
stufe 1 .. n
Umsetzung
- Wartung
- langfristige
Weiter-
entwicklung
=> langfristiger
optimierter
Einsatz
PDM-
Betreuung
- Projekt-
organisation
- Stufenplan
- DV-Infra-
struktur
=> Investitions-
antrag
Projekt-
planung
Stand der Technik Seite 73
PDM-spezifische Aspekte werden durch das Vorgehensmodell zum Teil berück-
sichtigt. Im Mittelpunkt stehen dabei insbesondere die Verwendung von Standard-
software sowie die Abbildung von Produktstrukturen. Die wichtigen Paradigmen-
wechsel und die Notwendigkeit der Altdatenübernahme werden vernachlässigt
(A5). Ebenso wird der Integrationscharakter von PDM nicht explizit hervorgeho-
ben (A6).
Zusätzlich zu den schon beschriebenen Defiziten findet die Personalplanung und
-entwicklung kaum Berücksichtigung im Vorgehensmodell (A7, A8). Es genügt
damit einem Großteil der Anforderungen an ein Vorgehensmodell zur PDM-Ein-
führung nicht.
3.1.3.3 Einführungstrategie für Produktdatenmanagement nach Schöttner
Die Einführungstrategie für Produktdatenmanagement nach Schöttner [Sch99]
wird ausführlich, aber nicht formal als Vorgehensmodell mit Aktivitäten, Ergeb-
nissen und Akteuren beschrieben (A1). An Hand einer pragmatischen Schilderung
von Rahmenbedingungen und inhaltlichen Schwerpunkten werden aber die in Bild
3-8 dargestellten Phasen erläutert.
Das Modell umfasst bis auf den Betrieb alle Phasen der Einführung inklusive
einem Teil der begleitenden Aktivitäten (A2). Die Einbindung in die Unterneh-
mensstrategie und das Engangement des Top-Managements werden als wichtig
postuliert. Eine Umsetzung strategischer Vorgaben, z.B. in Form eines Kennzah-
lensystems und einer strategische Kontrolle, erfolgt aber nicht (A4). Die wichtig-
sten PDM-spezifischen Aspekte werden berücksichtigt. Besondere Aktivitäten
werden daraus aber nur für die Altdatenmigration und die Auswahl einer Standard-
software getroffen (A5).
Bild 3-8: Phasen der Einführungsstrategie für Produktdatenmanagement nach
Schöttner [Sch99, S. 523ff]
Projekt-
definition
Projekt-
planung
Projektdurchführung
Anforde-
rungs-
aufnahme
System-
auswahl
Pflichten-
heft
Systeman-
passung
Systemein-
führung
Seite 74 Kapitel 3
In Bezug auf den Integrationscharakter von PDM berücksichtigt die Einführungs-
strategie lediglich die Systemintegration. Ein Abgleich mit anderen strategsichen
Projekten ist nicht vorgesehen (A6).
Aktivitäten der Personalplanung und -entwicklung sind im Modell nur unvollstän-
dig und nicht aufeinander abgestimmt enthalten. Die Notwendigkeit, humanorien-
tierte Kompetenzen einzubeziehen, wird lediglich erwähnt. Die Personalentwick-
lung beschränkt sich auf nicht rollenbasierte Anwender- und
Administratorenschulungen, ohne die projektvorbereitende Qualifizierung zu
berücksichtigen (A7, A8).
Größte Schwäche der Einführungsstrategie ist der vollständige Verzicht auf die
Einbindung von Methoden, obwohl viele der in der Beschreibung angesprochenen
Problemfelder gerade durch diese zu lösen wären (A3). Das Modell erfüllt deshalb
die gestellten Anforderungen nicht ausreichend.
3.1.4 Einführungsmodelle von PDM-Systemanbietern und
Beratungsunternehmen
Systemanbieter und Dienstleistungunternehmen (z.B. Beratungsunternehmen) füh-
ren PDM-Einführungsprojekte zumeist nach ihren hauseigenen Vorgehensmodel-
len durch. Diese sind Ergebnis der Erfahrungen aus abgewickelten Projekten. Sie
bilden einen großen Teil des geistigen Eigentums des jeweiligen Unternehmens ab.
Deshalb sind diese Vorgehensmodelle zumindest im Detail nicht veröffentlicht
und unterliegen in ihrer Anwendung einem Urheberrecht, d.h. die Nutzung oder
Veröffentlichung des Modells ist oft nur mit Beteiligung des jeweiligen Unterneh-
mens und gegen eine Lizenzgebühr möglich. Somit ist eine freie Verfügbarkeit
nicht gegeben (A1).
Auf diesem Grund und wegen der Vielzahl der Modelle können diese hier nicht
einzelnd und im Detail beschrieben und auf die Erfüllung der Anforderungen hin
betrachtet werden. Es lassen sich aber zwei Klassen von Modellen unterscheiden,
die im Weiteren kurz erläutert werden.
Die erste Klasse bilden die Vorgehensmodelle von PDM-Systemanbietern12. Sie
sind stark auf das jeweilige System des Herstellers zugeschnitten und auf andere
Systeme nicht oder nur bedingt anwendbar. Sie erfüllen deshalb die Forderung
nach Systemunabhängigkeit nicht (A1). Da die Auswahl des Systems zumeist erst
relativ spät während der Einführung geschieht, ist eine Anwendung des dazugehö-
rigen Vorgehensmodells selten sinnvoll. da die Ergebnisse der vor der Systement-
scheidung eingesetzten Methoden damit meistens nicht weiter verwendbar sind
(A3).
12. Z.B. MetaSDMTM (Metaphase Solution Delivery Methodology) der SDRC AG
Stand der Technik Seite 75
Die zweite Klasse sind dagegen die Vorgehensmodelle von Beratungsunterneh-
men. Sie sind meist sehr grob13 oder generisch. D.h. sie lassen sich nicht nur für
PDM-Einführungsprojekte sondern auch für andere Projekte, z.B. zur Einführung
eines PPS-Systems oder eines Rechenzentrums, anwenden. Ein Beispiel für ein
solches unspezifisches Modell ist CatalystTM von CSC Ploenzke Consulting
GmbH, das unter dem Namen ChestraTM auch von der Siemens Business Service
GmbH & Co. OHG angewendet wird. Die prinzipielle Vorgehensweise von Cata-
lystTM/ChestraTM zeigt Bild 3-9.
Mit solchen Modellen wird den spezifischen Problemen der PDM-Einführung sel-
ten Rechnung getragen (A5). Zusätzlich beinhalten sie viele Tätigkeiten, die in
PDM-Projekten keine Rolle spielen.
Es zeigt sich, dass die beiden beschriebenen Klassen von Vorgehensmodellen
wichtige Anforderungen nicht erfüllen und somit keine Lösung für die in Kapitel 2
beschriebenen Probleme bei der PDM-Einführung bieten.
13. Bei [WM00] reduziert sich z.B. das Vorgehensmodell auf eine grobe Einteilung in die drei Pha-
sen Plan - Build - Run (Planung - Realisierung - Betrieb), ohne die Zusammenhänge und den
Inhalt weiter zu detaillieren.
Bild 3-9: Catalyst TM- Prinzipielle Vorgehensweise in Projekten [Kel98]
Vision und Strategie
Architektur
Entwicklung
Integration
Einführung
Betrieb
Entwicklungskoordination
Programm Management
Projekt Management
Organisations-
entwicklung
Technische
Infrastruktur
Prozess-
bereitstellung
Einrichtungs-
infrastruktur
Seite 76 Kapitel 3
3.2 Vorgehensmodelle der allgemeinen Softwareentwicklung
Die bisherige Betrachtung der PDM-Einführungsmodelle zeigt, dass dort nur
unzureichende Aussagen über anzuwendende Methoden und über die Unterstüt-
zung der Implementierungsphase gemacht werden. Da diese aber einen großen
Anteil an der PDM-Einführung ausmacht, ist es sinnvoll, Vorgehensmodelle der
allgemeinen Softwareentwicklung auf ihre Anwendbarkeit in PDM-Projekten zu
untersuchen.
Deren Entwicklung vom Wasserfallmodell bis zum inkrementellen und iterativen
Prozess ist im Rahmen der allgemeinen Erläuterung des Begriffs Vorgehensmodell
in Kapitel 2.3 schon beschrieben worden. An dieser Stelle werden deshalb exem-
plarisch die zwei zur Zeit wichtigsten Modelle, das V-Modell zur Planung und
Durchführung von IT-Vorhaben in der Bundesverwaltung und der Unified Soft-
ware Development Process betrachtet.
3.2.1 V-Modell zur Planung und Durchführung von IT-Vorhaben in
der Bundesverwaltung
Das „V-Modell“ zur Planung und Durchführung von IT-Vorhaben in der Bundes-
verwaltung regelt die Softwarentwicklung für öffentliche Auftraggeber14 durch
eine einheitliche und verbindliche Vorgabe von Aktivitäten und Ergebnissen. Es
hat seinen Namen von der V-fömigen Anordnung seiner Phasen (siehe Bild 3-10).
Die Idee ist, dass spezifizierende Tätigkeiten den zugehörigen umsetzenden Tätig-
keiten gegenübergestellt sind. Die Prüfaktivitäten des rechten Flügels des Modells
orientieren sich an den Spezifikationen aus den Tätigkeiten des linken Flügels
[GEK01, S. 265f].
Das Submodell Softwareerstellung (SWE), das durch die im Bild dargestellten
Hauptaktivitäten beschrieben wird, regelt, welche Tätigkeiten während der Soft-
wareerstellung durchzuführen, und wann welche Produkte zu erstellen sind.
Zusätzlich beinhaltet das V-Modell drei weitere sogenannte Submodelle:
Das Submodell Qualitätssicherung (QS) regelt die Aufgaben und Funktionen der
Qualitätssicherung während des Softwareentwicklungsprozesses und gewährleistet
die Erfüllung der Qualitätsanforderungen.
Das Submodell Konfigurationsmanagement (KM) stellt sicher, dass Produkte ein-
deutig identifizierbar sind und Änderungen an Produkten nur kontrolliert durchge-
führt werden können.
Das Submodell Projektmanagement (PM) regelt die Planung, Steuerung und Kon-
trolle der Tätigkeiten des Softwareentwicklungsprozesses. Die Modelle sind eng
miteinaner verzahnt und beeinflussen sich gegenseitig (siehe Bild 3-11).
14. Z.B. Ministerien oder die Bundeswehr.
Stand der Technik Seite 77
Die Tätigkeiten der Submodelle werden jeweils bestimmten Rollen zugeordnet15.
Für jede Rolle wird in einer Zuordnungstabelle festgelegt, inwieweit sie an jeder
Aktivität beteiligt ist. Dabei wird zwischen den Beteiligungen „ausführend“, „mit-
wirkend“ und „beratend“ unterschieden. Außerdem ist sowohl festgelegt welche
Fach- und Methodenkompetenz mit einer Rolle verbunden sind als auch ein Teil
der humanorientierten Kompetenzen16.
Da das V-Modell für die Entwicklung unterschiedlichster Systeme17 anwendbar
sein soll, ist es nicht auf spezifische Anwendungstypen ausgerichtet. Es muss des-
halb für das konkrete Projekt angepasst werden. Dazu dient das so genannte „Tai-
loring“18. Dabei wird in Abhängigkeit von den Projektbedingungen eine Auswahl
von durchzuführenden Aktivitäten getroffen. Zusätzlich wird festgelegt, welche
Produkte der Auftragnehmer dem Auftraggeber zu übergeben hat [GEK01, S.
Bild 3-10: V-förmige Anordnung der Phasen im V-Modell zur Planung und
Durchführung von IT-Vorhaben in der Bundesverwaltung [BD93, S.
24]
15. Das V-Modell verwendet insgesamt 21 interne und zwei externe Rollen. Interne Rollen sind
z.B. Systemanalytiker oder Projektassistent, die externen Rollen sind Auftraggeber und Anwen-
der. [BD93, S. 55f]
16. Z.B. werden vom Projektleiter u.a. die Kenntnis der Methoden und Werkzeuge ebenso verlangt
wie die Fähigkeit zur Führung, Motivation und Moderation.
17. Z.B. auch Realzeitanwendungen oder sicherheitskrititsche Softwareanteile [BD93, S. 30]
18. To tailor = nach Maß schneidern
SWE 1
SWE 2
SWE 3
SWE 4
SWE 5
SWE 6
SWE 7
SWE 8
SWE 9
System-
Anforderungs-
analyse
und -Entwurf
DV-Anforde-
rungsanalyse
und -Entwurf
SW-
Anforderungs-
analyse
Grob-
entwurf
Feinentwurf
Implementierung
SWKE-
Integration
SW-
Integration
Kompo-
nenten-
Integration
DV-
Integration
System-
Integration
Systemanforderungen
Systemarchitektur
System-Integrationsplan
DV-Anforderungen
DV-Architektur
DV-Integrationsplan
SW-Anforderungen
SW-Architektur
Schnittstellenentwurf
SWKE-Integrationsplan
Datenkatalog
SW-Entwurf
Implementierungsdok.
(Modul/Datenbank)
Modul/Datenbank
Implem.-Dokumente
(Komponente)
Komponente
SWKE
(Softwarekonfigu-
rationseinheiten)
Implementierungs-
dokumente
(SWKE)
DV-Segment
System
Handbuch-
Informationen
: Prüfaktivität
: SWE-Aktivität
kursiv : Produkte (Resultate)
Seite 78 Kapitel 3
269]. Es erfolgt auch eine Zuordnung der Rollen zu den konkret ausführenden Per-
sonen.
Methoden und Werkzeuge werden den Aktivitäten im V-Modell selbst nicht zuge-
ordnet. Es existiert aber im Softwareentwicklungsstandard der Bundeswehr eine
Ergänzung, die diese Zuordnung vornimmt [BW93]. Die Menge der angebotenen
Methoden ist dabei sehr groß, da auch hier zunächst kein Bezug auf ein spezielles
Projekt genommen wird, sondern möglichst alle Arten von Softwaresystemen ent-
wickelt werden können. Die Auswahl der passenden Methoden ist wiederum Inhalt
des Tailorings.
Zusammenfassend lässt sich feststellen, dass das V-Modell eine sehr umfangreiche
Hilfestellung für die Erstellung von Software gibt. Es wird den Anforderungen
nach Einsatz von Methoden, Definition von Rollen sowie Berücksichtigung
begleitender Aspekte wie Projektmanagement, Qualitätssicherung und Konfigura-
tionsmanagement grundsätzlich gerecht. Die Defizite in Bezug auf die Einführung
eines PDM-Systems werden allerdings auch deutlich:
• Das V-Modell ist beschränkt auf den reinen Prozess der Softwareerstellung.
Vorbereitende Aspekte wie die strategische Einordnung des geplanten Vorha-
bens und die Vermittlung des Nutzens sind nicht berücksichtigt. Ebenso sind
keine Tätigkeiten zum Ausbringen der erstellten Software in den produktiven
Einsatz im Unternehmen , z.B. die Schulung der Anwender, definiert. (A4)
Bild 3-11: Interaktion der Submodelle des V-Modells [BD93, S. 22]
Projektmanagement (PM)
plant
kontrolliert/steuert
informiert
entwickelt
das System/
Dokumentation
Software-
entwicklung
(SWE)
verwaltet
- Konfigurationen
- Produkte
- Rechte
- Änderungen
Konfigurations-
management
(KM)
Qualitäts-
sicherung
(QS)
gibt
Anforderungen/
Methoden vor
prüft
Stand der Technik Seite 79
• Ähnlich wie bei den Einführungsmodellen der Beratungsunternehmen (siehe
Kapitel 3.1.4) ist das Modell generisch, d.h. es enthält viele für die PDM-Einfüh-
rung überflüssige Schritte und vernachlässigt dafür wichtige Spezifika. (A5)
• Die vorgeschlagenen Methoden sind zwar sehr zahlreich und umfassend aber
nicht durchgängig über die Phasen. (A3)
• Dem Umstand, dass es sich bei PDM-Projekten nicht um eine Neuentwicklung
von Software sondern Customizing eines bestehenden Baukastensystems han-
delt, wird nicht Rechnung getragen. Inkrementelle und iterative Entwicklung mit
Prototypen (siehe Kapitel 2.2.7) wird nicht unterstützt. (A3)
3.2.2 Unified Software Development Process
Die Softwarenentwicklung hat durch die Objektorientierung eine tiefgreifende
Neuorientierung erhalten. Alte Methoden und Spezifikationstechniken verloren
ihre Gültigkeit und mussten durch neue ersetzt werden. Nachdem über einige Jahre
verschiedene Spezifikationstechniken mit unterschiedlichem Fokus auf dem Markt
konkurrierten, haben 1995 drei der wichtigsten Protagonisten19 der Objektorientie-
rung ihre Arbeiten harmonisiert und in eine gemeinsame Spezifikationstechnik, die
Unified Modeling Language (UML), einfliessen lassen. Die UML ist seit dem der
wichtigste Quasi-Standard20 der objektorientierten Softwareentwicklung21.
Um die Beschreibungsmittel der UML in ein methodisches Vorgehen einzubetten,
wurde dazu im Jahr 1999 der Unified Software Development Process (UDSP) ent-
wickelt [JBR99]. Der USDP beschreibt ein generelles Vorgehen für die objektori-
entierte Softwareentwicklung22. Dabei werden bestimmte Prinzipien vorgegeben
und die Entwicklungsaktivitäten gegliedert. Die grundsätzliche Gliederung zeigt
Bild 3-12.
Die Prinzipien des USDP werden durch vier Begriffe charakterisiert:
Anwendungsfallgetrieben: Die Spezifikation der Anforderungen erfolgt im
USDP mit Hilfe von Anwendungsfällen (Use Cases). Diese beschreiben die grund-
sätzlichen Abläufe aus Sicht des Benutzers, fokussiert auf Systemfunktionalität
und äußeres Systemverhalten.
19. Grady Booch[Boo94], Jim Rumbaugh[RBP+91], Ivar Jacobson[Jac95].
20. Als Quasi-Standard bezeichnet man eine Methode, die eine sehr große Verbreitung hat und all-
gemein als der anerkannte Stand der Technik gilt. Sie ist aber nicht von einem Standardisie-
rungsgremium in einem offiziellen Verfahren freigegeben und als Standard bestimmt worden.
21. Für eine detaillierte Darstellung der Beschreibungsmittel der UML siehe u.a. [BRJ99], [GF99,
S. 272ff], [Oes98] und [OHJ+98].
22. Er ist so noch nicht anwendbar, sondern muss zunächst für das entsprechende Einsatzgebiet
angepasst werden. Solche Anpassungen sind u.a. der Object Engineering Process
(OEP)[OHJ+98], der Objektorientierte Weg (OOW)[PS00] oder der Rational Unified Process
(RUP)[Kru99].
Seite 80 Kapitel 3
Architekturzentriert: Die Anwendungsentwicklung muss die vorhandene
Systemarchitektur berücksichtigen. Dadurch ist vorgegeben, welche Artefakte zu
entwickeln sind.
Modellorientiert: Die Struktur und das Verhalten der Anwendung werden durch
die objektorientierten Modelle der UML beschrieben. Daraus können der Code
und die Dokumentation weitestgehend automatisiert erstellt werden.
Iterativ und inkrementell: Die Entwicklung wird in mehrere gleichartige und
sich wiederholende Schritte (Iterationen) zerlegt. Bei jedem Schritt wächst die
Gesamtfunktionalität23.
Bild 3-12: Das Phasenmodell des Unified Software Development Process nach
[JBR99]
23. Siehe dazu auch Kapitel 2.3.2.
Aufgaben/Tätigkeiten Resultate
UML - Use Cases
UML - Objekt Modell
UML - Sequenzdia-
Programmiersprache
UML - Kooperations
Diagramme
Systembeschreibung aus Benutzersicht führt zu
Anforderungen (Benutzerbeteiligung)
Strukturierung der Use Cases
Objekt Modell
Sequenz-, Zustands-
Sequenz Modell
Phasen/Meilensteine
.
1
UML - Zustandsdia-
Klassen Signatur
(Definitionen von
Klassen/Attributen)
Rümpfe (Code
der Operationen)
Programmiersprache
Design Modell
Objekt Modell
Modellierung
dynamisches
statische Struktur
UML - Komponenten-
UML - Verteilungs-
Use Case Modell
Analyse Modell
Design Modell
Anforderungs-
aufnahme
sowie Beschrei-
bungsmittel
Analyse
Design
Implementation
(Java, C++ etc.)
Testberichte (Ta-
bellen, natürliche
Sprachen etc.)
Test des programmierten Systems auf Grundlage
der in den Use Cases spezifizierten Anforderungen.
UML: Unified Modelling
Language
Implement Modell
Test Modell
Test
Betrieb
modell
diagr.
2
3
3
3
4
4
5
gramme
gramme
Verhalten diagramm
Stand der Technik Seite 81
Die Phasen des USDP, wie sie in Bild 3-12 dargestellt sind, werden also mehrfach
hintereinander durchlaufen. Dabei verschiebt sich die Intensität, mit der die einzel-
nen Phasen betrachtet werde (siehe Bild 3-13). In den ersten Iterationen wird die
Aufnahme der Anforderungen intensiver betrachtet. In den späteren Iterationen
verschiebt sich der Schwerpunkt hin zu Implementation und Test.
Der USDP als Grundgerüst enthält selbst keine Vorgaben für das Projektmanage-
ment für die Softwareentwicklung. Im Rational Unified Process (RUP), einer
Anwendung des USDP, ist aber ein umfangreiches Projektmanagement integriert
[Ver00]. Es enthält neben den üblichen Aktivitäten zur Projektplanung, -steuerung
und -überwachung auch eine Aufstellung von Rollen, die an der Softwareentwick-
Bild 3-13: Der Unified Software Development Process [JBR99]
Konstruktion
Weiterentwicklung des Funktionsumfangs
Ziel: stabiles Produkt
Iterationsphasen
Entwurf
Endgültige Definition der Softwarearchitektur
Ziel: validierte, ausführbare und stabile Softwarearchitektur
Konzeption
Definition des Produktes, Wirtschaftlichkeits- und Machbarkeitsanalyse
Ziel: Entscheidung über Weiterführung oder Abbruch
Übergang
Übergabe der Software an den Anwender
Ziel: Beta-Test, Handbücher, Schulung, Markteinführung
Phasen (im Sinne von Iterationen)
Anforderungen
Analyse
Design
Implementation
Test
Prozesse
Iter.
#n.
Iter.
#2 Iter.
... Iter.
... Iter.
... Iter.
... Iter.
... Iter.
#n-1
Iter.
#1
Intensität des Prozesses
Iteration
Entwurf Konstruktion ÜbergangKonzeption
Die technische Realisierung erfolgt in Iterationen, wobei jede Iteration mit
einem ausführbaren Produkt endet und die Prozesse Anforderungen, Analyse,
Design, Implementation und Test unterschiedlich intensiv durchlaufen
werden.
Seite 82 Kapitel 3
lung beteiligt sind sowie Tätigkeiten zum Konfigurations- und Änderungsmanage-
ment.
Zusammenfassend lässt sich feststellen, dass mit USDP und UML der Vorgehens-
und Methodenaspekt der Softwareentwicklung hinreichend abgedeckt sind. Es gel-
ten aber ähnliche Einschränkungen wie beim V-Modell (siehe Kapitel 3.2.1):
• Vorbereitende Aspekte, wie die strategische Einordnung des geplanten Vorha-
bens und die Vermittlung des Nutzens sind nicht berücksichtigt. (A4)
• Der USDP ist generisch, d.h. er enthält viele für die PDM-Einführung überflüs-
sige Schritte und vernachlässigt dafür wichtige Spezifika. (A5)
Die inhärenten Prinzipien des USDP machen ihn aber für die PDM-Einführung
interessant:
• Eine PDM-Einführung ist nur erfolgreich, wenn es gelingt, die Anwender in
ihren Prozessen optimal zu unterstützen. Deshalb ist deren Einbeziehung in die
Anforderungsaufnahme wichtig. Die Anwendungsfälle der UML unterstützen
diese Tätigkeit sehr gut.
• Die Implementierung in der PDM-Einführung ist keine Entwicklung einer neuen
Software sondern Anpassung eines bestehenden Systems. Es existieren also
klare Vorgaben in Bezug auf die Architektur und die zu erstellenden Artefakte
(siehe Kapitel 2.2.7). Dem kommt die Architekturzentrierung des USDP entge-
gen.
• Die Systemanpassung erfolgt mit Hilfe vorgegebener Programmierschnittstellen
(Application Programming Interfaces, API). Diese sind klar spezifiziert, so dass
es z.T. möglich ist, eine automatisierte Codeerstellung dafür abzubilden. Das
entspricht dem Prinzip der Modellorientierung im USDP.
• Zu Beginn der Systemanpassung ist es auf Grund von Unwissenheit über die
genaue Funktionsweise des Systems zum Teil schwer, detaillierte Anforderun-
gen zu stellen. Es kommt zu einer sukzessiven Verfeinerung der Anforderungen
und Anpassungen bis hin zum endgültigen Stand. Iteratives und inkrementelles
Vorgehen, wie im USDP vorgesehen, unterstützt somit die Einarbeitung in die
Anwendungsfunktionalität des PDM-Systems und das Prototyping.
3.3 Resümee und Handlungsbedarf
Tabelle 3-1 fasst die Bewertung der untersuchten Vorgehensmodelle in Bezug auf
die Erfüllung der in Kapitel 2.5 erarbeiteten Anforderungen noch einmal zusam-
men. Es lässt sich feststellen, dass kein Vorgehensmodell allen Anforderungen
hinreichend genügt.
Es zeigen sich folgende Schwerpunkte, bei denen die untersuchten Vorgehensmo-
delle zur PDM-Einführung besondere Schwächen haben:
Stand der Technik Seite 83
• Keines der Vorgehensmodelle bietet eine vollständige Beschreibung der
PDM-Einführung vom Ausgangspunkt bis in die Betriebsphase mit Aktivitäten,
Ergebnissen und Akteuren.
• Die Modelle sind zumeist relativ grob auf der Ebene von Hauptphasen beschrie-
ben. Eine Detaillierung in Unterphasen und durchzuführende Aktivitäten erfolgt
nur vereinzelt, wenn der Fokus der Veröffentlichung eine einzelne Phase ist und
das Vorgehensmodell nur den Rahmen für deren Erläuterung bildet. Dann ist die
Phase, die im Fokus steht, detailliert worden.
Tabelle 3-1: Bewertung des Standes der Technik
A1 A2 A3 A4 A5 A6 A7 A8
VDI-Richtlinie 2219
STEP PDM Schema und OMG
PDM Enablers
EDM-Studie Fraunhofer IAO
RapidPDM Implementation Metho-
dology
Einführung von EDM-Systemen
nach Eversheim
Nutzenorientierte Einführung nach
Wehlitz
PDM-Einführung nach Eigner/Stel-
zer
Einführung von PDM nach Schött-
ner
Einführung von PDM-Systemen
nach Strohmayer/Suhm
PDM-Systemhäuser und Bera-
tungsunternehmen
V-Modell
Unified Software Development Pro-
cess
Seite 84 Kapitel 3
• Es werden nur wenig Methoden angeboten. Falls eine Methode Inhalt des Vor-
gehensmodells ist, unterstützt sie zumeist nur einzelne Phasen und ist nicht
durchgängig. Schwerpunkte der Methoden liegen im Bereich der Systemaus-
wahl und der Konzeption, insbesondere die frühen Phasen der PDM-Einführung
werden selten unterstützt. Eine Integration von Softwarenentwicklungmethoden
ist in den meisten Modellen nicht vorgesehen.
• Die Personalplanung und -entwicklung im Umfeld der PDM-Einführung wird in
keinem Modell hinreichend betrachtet. Sie beschränken sich vollständig auf den
Aspekt der Anwenderschulungen, zum Teil wird die Beteiligung externer Mitar-
beiter zumindest erwähnt. Ein Instrumentarium zur Personalplanung und -ent-
wicklung enthält keines der betrachteten Modelle.
Die untersuchten Vorgehensmodelle der Softwareentwicklung sind nicht direkt auf
die PDM-Einführung umzusetzen, weil sie die wichtigen strategischen Aspekte
und andere PDM-Spezifika unberücksichtigt lassen. Der Unified Software
Development Process (USDP) ist von seinen Prinzipien her für den Einsatz in der
PDM-Einführung aber besser geeignet als das V-Modell.
Diese Ergebnisse stützen die folgende Aussage:
„Es zeigt sich, dass ... weiterer Forschungsbedarf bei der Ent-
wicklung von Einführungsstrategien gegeben ist.“ [Wir01, S.
227]
Es besteht also der Bedarf, ein Vorgehensmodell zu etablieren, das die oben
genannten Schwächen beseitigt und die PDM-Einführung anforderungsgerecht
unterstützt. Das Vorgehensmodell muss gekennzeichnet sein durch:
• Vollständigkeit im Sinne der Beschreibung und der Abdeckung der gesamten
Einführung,
• Durchgängigkeit im Methodeneinsatz unter Einbeziehung des Unified Software
Development Process,
• Integration in die Unternehmensstrategie,
• Berücksichtigung PDM-spezifischer Aspekte wie Paradigmenwechsel und Inte-
grationscharakter sowie
• Berücksichtigung der notwendigen Maßnahmen und Methoden zur Personalpla-
nung und -entwicklung.
Integriertes Vorgehensmodell zur Einführung von PDM-Systemen Seite 85
4 Integriertes Vorgehensmodell zur Einführung von
PDM-Systemen
Ziel dieser Arbeit ist die Konzeption eines Vorgehensmodells für die Einführung
von PDM-Systemen mit folgenden Eigenschaften:
• Berücksichtigung aller Phasen von der Vorstudie bis zum Betrieb,
• Einsatz von aufeinander aufbauenden Methoden über alle Phasen,
• Integration einer Methode für die Personalplanung und -entwicklung bei der
PDM-Einführung.
Zusätzlich sollen eine Reihe von Qualifizierungsmaßnahmen beschrieben werden,
die den Qualifizierungsbedarf sowohl projektbegleitend in Form von Schulungen,
als auch projektunabhängig in der beruflichen Aus- und Weiterbildung decken.
Dazu wird in diesem Kapitel zunächst das Vorgehensmodell bis zu den eingesetz-
ten Methoden dargestellt. Anschließend werden in Kapitel 5 die Methode für die
Personalplanung und -entwicklung sowie die Qualifizierungsmaßnahmen erläutert.
4.1 Überblick
Das integrierte Vorgehensmodell zur PDM-Einführung wird gemäß Bild 4-1
zunächst in vier Ebenen beschrieben. Zur besseren Übersicht werden die Projekte,
Projektphasen und Aktivitäten nummeriert. Die Nummerierung ist gemäß den in
Bild 4-1 in Klammern stehenden Bezeichungen hierarchisch aufgebaut.
Die erste Ebene enthält die drei aufeinander folgenden Hauptphasen der
PDM-Einführung:
• Vorstudie (P1),
• Systemauswahl (P2) und
• Systemeinführung (P3).
Diese Hauptphasen werden jeweils als eigenes Projekt angesehen1. D.h., es besteht
eine unterschiedliche Projektorganisation. Außerdem werden zu Beginn jeweils
unterschiedliche Vorgaben in Bezug auf die inhaltlichen Ziele, die Kosten sowie
die Zeit gemacht. Diese Ziele werden gemäß eines Top-Down-Ansatzes von Pro-
jekt zu Projekt detaillierter. Sie verfeinern sich von strategischen Vorgaben über
die Unterstützung von Sollprozessen zu detaillierten Anwendungsfunktionen.
Dabei darf die Erreichung von Zielen vorhergehender Projekte nicht durch spätere
Projekte gefährdet werden, d.h. die Ziele sind kumulativ.
Am Ende jedes Projektes wird neu über den Start des nächsten Projekts, einen
möglichen Abbruch oder eine Wiederholung entschieden. Wird die Einführung
1. Im Folgenden wird deshalb ausschließlich der Begriff Projekt verwendet.
Seite 86 Kapitel 4
fortgesetzt, definiert das vorhergehende Projekt die detaillierteren Ziele des fol-
genden.Vorstudie (P1) und Systemauswahl (P2) werden dabei im Normalfall
jeweils einmal durchlaufen. Das Projekt der Systemeinführung (P3) kann abhängig
von der am Ende der Systemauswahl (P2) festgelegten Releaseplanung (P2.4)
(siehe Kapitel 4.4.1.4) mehrfach sequentiell oder parallel aufgesetzt werden.
Jedes Projekt für sich hat auf der zweiten Ebene des Vorgehensmodells seine
eigene Anordnung von Projektphasen. Dazu gehören zum einen die Phasen der
inhaltlichen Durchführung und zum anderen projektbegleitende Phasen. Alle Pha-
sen werden während der Projektdurchführung durchlaufen.
Auf der dritten Ebene stehen die in den einzelnen Phasen durchzuführenden Akti-
vitäten. Diese können zum Teil je nach Größe und inhaltlichen Zielen des Projek-
tes entfallen. Die Festlegung dazu wird jeweils zu Beginn des Projektes getroffen.
Auf der Ebene der Aktivitäten werden gemäß der allgemeinen Definition von Vor-
gehensmodellen je Aktivität sowohl die Eingangsgrößen als auch die erstellten
Ergebnisse definiert. Zum Teil werden die Beschreibungen durch Beispiele
ergänzt. Außerdem werden die beteiligten Rollen und ihre Mitwirkung an den
Aktivitäten tabellarisch je Phase zusammengeführt. Dabei werden die Rollen
zunächst nur grob definiert, eine detaillierte Betrachtung dazu findet in Kapitel 5
statt.
Bild 4-1: Die vier Ebenen des integrierten Vorgehensmodells zur Einführung
von PDM-Systemen
Ebene 1:
Projekte
Ebene 2:
Phasen
Ebene 3:
Aktivitäten
Ebene 4:
Methoden
-
- Ziele
- Phasen
- Projektorganisation
Vorstudie (P1) -Systemauswahl (P2)
- Ziele
- Phasen
- Projektorganisation
- Strategiebindung (P1.1)
- Ist-Analyse (P1.2)
- Potentialanalyse (P1.3)
- Projektmanagement (P1.4)
- Grobkonzeption (P2.1)
- Systemvorauswahl (P2.2)
- Benchmark (P2.3)
- Releaseplanung (P2.4)
- Projektmanagement (P2.5)
- Feinspezifikation (P3.1)
- Systemanpassung (P3.2)
- Testen (P3.3)
- Roll-Out (P3.4)
- Projektmanagement (P3.5)
- Aktivität (P1.1.1 - P1.4.n)
- Eingangsgrößen
- Ergebnisse
- Rollen
- Aktivität (P2.1.1 - P2.5.n)
- Eingangsgrößen
- Ergebnisse
- Rollen
- Aktivität (P3.1.1 - P3.5.n)
- Eingangsgrößen
- Ergebnisse
- Rollen
-Systemeinführung (P3)
- Ziele
- Phasen
- Projektorganisation
- OMEGA
- Best Practices
- Unified Software Development Process
- Prototyping
Integriertes Vorgehensmodell zur Einführung von PDM-Systemen Seite 87
Die Durchführung der Aktivitäten wird durch Methoden unterstützt. Diese bilden
im Vorgehensmodell die vierte Ebene. Inhalt des Vorgehensmodells ist dabei
lediglich die Zuordnung geeigneter Methoden zu den Aktivitäten und die durch-
gängige Anwendung der Methoden über die Phasen. Es werden keine neuen
Methoden entwickelt. Welche Methoden angewandt werden können, hängt im all-
gemeinen stark vom vorhandenen Methodenpool des einführenden Unternehmens
und der beteiligten externen Beratungs- und Systemhäuser ab. Die hier vorgestell-
ten Methoden sind als Vorschlag zu sehen. Sie haben sich in der Praxis bewährt
und erfüllen die gestellten Anforderungen vor allem in Bezug auf die freie Verfüg-
barkeit und die Durchgängigkeit. Zur Beschreibung der Methoden wird auf die
entsprechende Literatur verwiesen. An dieser Stelle wird nur auf Aspekte einge-
gangen, die sich ergänzend zu den Methoden ergeben. Diese sind entweder Anpas-
sungen aufgrund der speziellen Anforderungen der PDM-Einführung oder Verbin-
dungen von Methoden zur Erreichung der geforderten Durchgängigkeit.
Die zur Durchführung der Aktivitäten und zur Anwendung der Methoden benötig-
ten Kompetenzen der Projektmitarbeiter bilden die Grundlage für die kurzfristige
Personalplanung und -entwicklung2. Diese wird im Anschluss an die Beschreibung
des Vorgehensmodells in Kapitel 5 ausführlich dargestellt. Die Tätigkeiten der
mittelfristige Personalplanung und -entwicklung für die Anwender sind im Vorge-
hensmodell enthalten. An entsprechenden Stellen wird darauf hingewiesen.
Im Folgenden wird zunächst beschrieben, wodurch die PDM-Einführung angestos-
sen werden kann (Kapitel 4.2). Danach werden die einzelnen Projekte detaillierter
beschrieben (Kapitel 4.3 bis Kapitel 4.5). Die Detaillierung hat folgenden systema-
tischen Aufbau:
• Ziel des Projektes,
• Projektphasen mit Aktivitäten und
• Projektorganisation.
Anschließend wird beschrieben, welche Maßnahmen nach der PDM-Einführung
zur strategischen Kontrolle (Kapitel 4.6.1) und für den operativen Betrieb des
PDM-Systems (Kapitel 4.6.2) getroffen werden müssen.
Abschluss der Darstellung des Vorgehensmodells bilden die vorgeschlagenen
Methoden (Kapitel 4.7).
4.2 Anstoß der PDM-Einführung
Bevor eine PDM-Einführung initiiert wird, muss zunächst im Unternehmen eine
Notwendigkeit dazu bestehen. Diese kann entweder aus der Unternehmensstrate-
2. Zur Abgrenzung der kurz- und mittelfristigen Tätigkeiten siehe Kapitel 2.4.1.
Seite 88 Kapitel 4
gie erwachsen oder durch operative Probleme hervorgerufen werden (siehe Bild
4-2).
Eine strategische Notwendigkeit ist gegeben, wenn Ziele der Unternehmens- bzw.
Informationstechnikstrategie ohne PDM nicht erreichbar sind3 oder die PDM-Ein-
führung großen Nutzen in Bezug auf die strategischen Ziele bringt4.
Die operative Notwendigkeit ensteht im Tagesgeschäft des Unternehmens, z.B.
durch erhöhte Datenflut oder gesetzliche Datenarchivierungsbestimmungen. Hier
ist zu beachten, dass trotz der auf den ersten Blick nur operativen Probleme nicht
direkt mit einer auf diese Probleme ausgerichteten Systemeinführung begonnen
wird. Dies wird durch die Top-Down Vorgehensweise des Vorgehensmodells
gewährleistet. Ungeachtet des eigentlichen Grundes für die Initiierung der
PDM-Einführung werden in der Vorstudie zunächst die strategischen Aspekte
beleuchtet, bevor in der weiteren Detaillierung Systemfunktionalitäten zur Unter-
stützung operativer Tätigkeiten entstehen.
Nach Abschluss der PDM-Einführung5 ergeben sich deshalb ungeachtet des Aus-
gangspunktes zwei Tätigkeiten, die strategische Kontrolle und der operative
Bild 4-2: Durchführung und Nachbearbeitung der PDM-Einführung sind unge-
achtet des Anstosses gleich
3. Z.B. trifft ein Hersteller erklärungsbedürftiger technischer Produkte die Entscheidung in
Zukunft auf e-Business Marktplätzen seine Produkte anzubieten. Die dazu notwendige Bereit-
stellung von Produktkatalogen lässt sich ohne ein PDM-System im Hintergrund nicht realisie-
ren.
4. Z.B. will ein Automobilhersteller seine Produktpalette straffen und Kosten sparen, in dem er
eine Plattformstrategie initiiert. Die notwendige Strukturierung und Modularisierung mit Hilfe
der Produktstruktur- und Konfigurationsmanagementfunktionen eines PDM-Systems durchzu-
führen bringt dabei erheblichen Nutzen. Weitere Beispiele zu strategischen Zielen, bei denen
PDM großen Nutzen bringt, finden sich in Kapitel 2.1.1.3.
5. Bzw. nach Abschluß des ersten Systemeinführungszyklus, näheres dazu in Kapitel 4.4.1.4.
Integriertes Vorgehensmodell zur Einführung von PDM-Systemen Seite 89
Betrieb. Diese beiden Tätigkeiten sind im Sinne der Definition eines Projektes
nicht mehr als zeitlich begrenzt anzusehen, da die Ablösung des Systems selten
vorausgeplant wird. Sie sind deshalb keine Phasen der eigentlichen PDM-Einfüh-
rung. Aufgrund ihrer Wichtigkeit und der geforderten Durchgängigkeit des
Modells bis in den Betrieb wird dennoch nach der Beschreibung der PDM-Einfüh-
rung näher auf diese Punkte eingegangen.
4.3 Vorstudie (P1)
Ziele der Vorstudie (P1) sind die Ermittlung des strategischen Handlungsrahmens
für die PDM-Einführung, die Feststellung des bestehenden Zustandes des Unter-
nehmens in Bezug auf PDM-relevante Prozesse sowie die Analyse des von einer
PDM-Einführung zu erwartenden Nutzens. Daraus entsteht eine PDM-Vision, aus
der sich wiederum die Anforderungen an eine umzusetzende Lösung ableiten las-
sen.
4.3.1 Phasen
Die Vorstudie gliedert sich gemäß Bild 4-3 in drei Phasen, die Strategiebindung
(P1.1), die Ist-Analyse (P1.2) und die Potentialanalyse (P1.3). Zusätzlich muss ein
begleitendes Projektmanagement (P1.4) durchgeführt werden. Einige Aktivitäten
der Strategiebindung (P1.1) und Ist-Analyse (P1.2) können z.T. parallel zueinander
ausgeführt werden. Der Beginn der Strategiebindung (P1.1) liegt aber in jedem
Fall vor dem Beginn der Ist-Analyse (P1.2). Die Aktivitäten dieser beiden Phasen
benötigen z.T. Eingangsgrößen aus der jeweils anderen Phase bzw. stellen ihre
Ergebnisse dieser Phase zur Verfügung. Sie sollten vor der Potentialanalyse (P1.3)
abgeschlossen sein. Diese führt die Ergebnisse aus diesen Phasen dann zusammen
und definiert die Vorgaben für das Folgeprojekt der Systemauswahl (P2).
4.3.1.1 Strategiebindung (P1.1)
Aufgrund der in Kapitel 2.1.1 dargestellten strategischen Bedeutung von PDM
ergibt sich die Anforderung, die Einführung grundsätzlich in einem
Top-Down-Ansatz durchzuführen. Deshalb muss die Strategiebindung (P1.1)
immer durchgeführt werden, auch wenn der Anstoß zur PDM-Einführung aus
einer operativen Notwendigkeit heraus gekommen ist (siehe Kapitel 4.2). Durch
die Strategiebindung (P1.1) wird der strategische Handlungsrahmen für die
PDM-Einführung festgelegt. Die folgenden Phasen erhalten dadurch die als beson-
ders wichtig hervorgehobene Aufmerksamkeit durch das Top-Management6.
Die Strategiebindung (P1.1) beinhaltet daher folgende Aktivitäten:
6. Abhängig von der Unternehmensform zählen dazu entweder der Vorstand oder die Geschäfts-
führung sowie unabhängig davon die erste Führungsebene darunter.
Seite 90 Kapitel 4
• Strategische Bedeutung und Nutzenpotentiale des PDM-Konzeptes vermitteln
(P1.1.1),
• Unternehmensspezifische strategische Ziele mit PDM-Relevanz ermitteln
(P1.1.2),
• PDM-relevante Unternehmensbereiche identifizieren (P1.1.3),
• Projektpaten bestimmen (P1.1.4).
Die Zuordnung der Zuständigkeiten für die Aktivitäten zu den beteiligten Rollen
ist in Tabelle 4-1 dargetellt.
Bild 4-3: Die Phasen der Vorstudie (P1)
Tabelle 4-1: Zuständigkeiten der Aktivitäten der Strategiebindung (P1.1)
D: Durchführungsverantwortung
M: Mitwirkungspflicht
I: Informationsanspruch
E: Entscheidung
K: Kontrolle/Überprüfung
X: Gesamtverantwortung (D/E/K)
Projektleiter
Externer Berater
Führung 1. Ebene
Führung 2. und 3. Ebene
Strategische Bedeutung und Nutzenpotentiale des
PDM-Konzeptes vermitteln (P1.1.1)
D,K D M M
Unternehmensspezifische strategische Ziele mit
PDM-Relevanz ermitteln (P1.1.2)
XD,KM,EM
PDM-relevante Unternehmensbereiche identifizieren
(P1.1.3)
XD,KI M,E
Projektpaten bestimmen (P1.1.4) X D,K E M
Integriertes Vorgehensmodell zur Einführung von PDM-Systemen Seite 91
Aktivität: Strategische Bedeutung und Nutzenpotentiale des
PDM-Konzeptes vermitteln (P1.1.1)
Beschreibung: Die vollständige strategische Dimension einer PDM-Konzeption
ist in den Unternehmen selten vollständig bewusst. Deshalb muss in dieser ersten
Aktivität dieses Bewusstsein bei den Entscheidungsträgern geschaffen werden.
Dies geschieht mit Hilfe von verschiedenen Workshops für die ersten Führungs-
ebenen. Diese sind auf den jeweiligen Adressatenkreis zugeschnitten. Auf der
obersten Ebene von Vorstand oder Geschäftsführung stehen die strategischen
Dimensionen und die möglichen Umsatz- und Gewinnsteigerungen durch PDM im
Vordergrund, während sich für die weiteren Führungsebenen der Schwerpunkt zu
den erreichbaren operativen Prozessverbesserungen und funktionalen Aspekten
von PDM-Systemen verschiebt (siehe Bild 4-4)
Zur Moderation der Workshops und Präsentation der Grundlagen ist die Beteili-
gung eines externen Beraters notwendig. Um die später anstehende Entscheidung
für ein bestimmtes PDM-Sytem nicht vorwegzunehmen, sollte dieser systemunab-
hängig sein, z.B. als freier unabhängiger Berater, von einem systemunabhängigen
Beratungshaus oder einem Hochschulinstitut. Wichtig für die Akzeptanz des Bera-
ters sind neben den PDM-Kenntnissen vor allem Branchenkenntnis und die Fähig-
keit, die Sprache des Managements zu sprechen.
Eingangsgrößen: Informationen über die Branche und Produkte sowie über die
Vision und Strategie des Unternehmens.
Ergebnisse: „PDM-Awareness7“ der Führungskräfte.
Bild 4-4: Unterschiedliche Schwerpunktbildung in den Workshops für verschie-
dene Führungsebenen
7. Darunter wird verstanden, dass die strategische Bedeutung und die Nutzenpotentiale von PDM
erkannt sind und diese Informationen in Bezug auf die Situation des eigenen Unternehmens
reflektiert werden können.
Strategische
Dimension /
Wirtschaftlicher
Nutzen
Prozess-
verbesserungen /
PDM-
Funktionalität
Ebene 1:
Vorstand/
Geschäftsleitung
Ebene 2:
Hauptabteilungsleiter/
Geschäfts-
bereichsleiter
Ebene 3:
Abteilungsleiter
Seite 92 Kapitel 4
Aktivität: Unternehmensspezifische strategische Ziele mit PDM-Relevanz
ermitteln (P1.1.2)
Beschreibung: Nach dem die Führungsebenen des Unternehmens über die allge-
meinen Nutzenpotentiale und strategischen Implikationen von PDM aufgeklärt
sind, wird nun ermittelt, welche der bestehenden Unternehmensziele durch PDM
unterstützt werden können. Aus diesen Zielen ergeben sich abhängig von ihrer
Priorität die Managementvorgaben für die PDM-Einführung.
Diese Aktivität kann auch mit der vorhergehenden Aktivität in einem Workshop
zusammengefasst werden.
Eingangsgrößen: PDM-Awareness der Führungskräfte, Unternehmensstrategie,
verwendete Kennzahlen der strategischen Kontrolle (z.B. aus Balanced Score-
card).
Ergebnisse: Gewichtete strategische Zielvorgaben für die PDM-Einführung in
Form von Kennzahlen.
Beispiel: Die Strategie eines Unternehmens im kundenspezifischen Anlagenbau
definiert als Ziel, die Marktführerschaft in Bezug auf die schnelle Pro-
jektierung der Anlage vom Auftrag zur Übergabe an den Kunden
(time-to-delivery) zu erreichen. Daraus ergibt sich, dass der Nutzen der
PDM-Einführung vor allem an erreichten Prozesszeitverkürzungen
gemessen wird, während Kostenreduktion und Qualitätsverbesserungen
geringer priorisiert werden.
Aktivität: PDM-relevante Unternehmensbereiche identifizieren (P1.1.3)
Beschreibung: Sind die Vorgaben in Bezug auf die strategischen Unternehmens-
ziele der PDM-Einführung gemacht, muss identifiziert werden, welche Unterneh-
mensbereiche dadurch betroffen sind. Hat ein Bereich Ziele, die von den
PDM-relevanten Unternehmenszielen abgeleitet sind8, gehört er in den Untersu-
chungsbereich der nachfolgenden Analysen.
Diese Aktivität kann auch mit den vorhergehenden Aktivitäten in einem Workshop
zusammengefasst werden.
Eingangsgrößen: PDM-relevante strategische Unternehmensziele, PDM-Awaren-
ess der Bereichsleiterebene, Übersicht über die Unternehmensbereiche und deren
abgeleitete Ziele.
Ergebnisse: Festlegung des Untersuchungsbereichs für die Ist-Analyse.
8. Dies ist im Sinne einer Zielpyramide zu verstehen, in der die Unternehmensziele über die Hier-
archieebenen hinweg immer weiter detailliert werden.
Integriertes Vorgehensmodell zur Einführung von PDM-Systemen Seite 93
Beispiel: Aus dem Unternehmensziel „Marktführerschaft time-to-delivery (s.o.)“
leitet sich für den technischen Vertrieb eines Unternehmens das
Bereichsziel „Schnelle Bearbeitung von Angeboten“ ab. Weil dieses
Ziel PDM-relevant ist, muss der Unternehmensbereich in der folgenden
Ist-Analyse (P1.2) mit untersucht werden.
Aktivität: Projektpaten bestimmen (P1.1.4)
Beschreibung: Es muss ein Vertreter der oberen Führungsebenen über die gesamte
Laufzeit der Einführung als Pate zur Verfügung stehen. Grund dafür ist, die strate-
gischen Bedeutung der PDM-Einführung im weiteren Verlauf der Projekte im
Unternehmen auch in den unteren Ebenene deutlich zu machen. Wie hoch diese
Person angesiedelt ist, hängt davon ab, welche und wieviele Unternehmensberei-
che zum Untersuchungsbereich der Einführung gehören. Der Projektpate begleitet
die Einführung während der gesamten Laufzeit und sitzt in den weiteren Phasen
dem Lenkungskreis9 vor.
Diese Aktivität kann auch mit den vorhergehenden Aktivitäten in einem Workshop
zusammengefasst werden.
Eingangsgrößen: PDM-Awareness der Führungskräfte, PDM-relevante Unter-
nehmensbereiche.
Ergebnisse: Benannter und nach aussen offen kommunizierter Projektpate.
Beispiel: In einem Unternehmen der Automobilindustrie fokussiert sich die
PDM-Einführung aufgrund der entsprechenden strategischen Vorgaben
stark auf die Integration der Entwicklungsbereiche. Projektpate wird
deshalb der Entwicklungsvorstand und nicht einer der Entwicklungsbe-
reichsleiter.
4.3.1.2 Ist-Analyse (P1.2)
Die Ist-Analyse (P1.2) dient der Ermittlung der Ausgangssituation im Unterneh-
men. Es müssen alle Gegebenheiten im festgelegten Untersuchungsbereich analy-
siert werden, die PDM-relevant sind, bzw. Rahmenbedingungen für die PDM-Ein-
führung festlegen.
Die Ist-Analyse (P1.2) beinhaltet daher die folgenden Aktivitäten:
• Ablauforganisation analysieren (P1.2.1),
• IT-Infrastruktur analysieren (P1.2.2),
• Laufende Strategie- und IT-Projekte analysieren (P1.2.3),
9. Zur grundsätzlichen Rolle des Lenkungskreises in der Projektorganisation siehe Kapitel 4.3.2.
Seite 94 Kapitel 4
• Stakeholder ermitteln (P1.2.4),
• Veränderungsgrad analysieren (P1.2.5).
Die Zuordnung der Zuständigkeiten für die Aktivitäten zu den beteiligten Rollen
ist in Tabelle 4-2 dargetellt.
Aktivität: Ablauforganisation analysieren (P1.2.1)
Beschreibung: Die Ablauforganisation ist aus der Aufbau- und der Prozessorgani-
sation zusammengesetzt. Sie beschreibt die Zuordnung der Leistungserstellungs-
prozesse zu den Funktionseinheiten des Unternehmens. Ein einheitliches und von
allen Projektbeteiligten anerkanntes Gesamtbild der bestehenden Ablauforganisa-
tion bildet die Basis sowohl für die Optimierungsaktivitäten im Laufe der
PDM-Einführung als auch für die spätere Gestaltung eines PDM-Systems. Zusätz-
lich werden aus der Ablauforganisation die quantitative und der fachbezogene Teil
der qualitativen Personalbestandsermittlung entnommen. Der Analyse der Ablauf-
organisation ist deshalb besondere Aufmerksamkeit zu widmen.
Die Analyse erfolgt mit Hilfe von Dokumentenanalysen, Interviews und Work-
shops über den gesamten vorher definierten Untersuchungsbereich. Dokumentiert
wird die Ablauforganisation mit Hilfe grafischer Modellierungsmethoden und
ergänzender textueller Informationen. Einem externen PDM-Experten kommt
dabei die Rolle zu, die für eine PDM-Einführung relevanten Informationen heraus-
zufiltern bzw. in den Interviews und Workshops durch gezielte Fragestellung zu
ermitteln.
Tabelle 4-2: Zuständigkeiten der Aktivitäten der Ist-Analyse (P1.2)
D: Durchführungsverantwortung
M: Mitwirkungspflicht
I: Informationsanspruch
E: Entscheidung
K: Kontrolle/Überprüfung
X: Gesamtverantwortung (D/E/K)
Projektleiter
Externer Berater
Unternehmensexperten
Methodenexperten
Lenkungskreis
Ablauforganisation analysieren (P1.2.1) X M,K M M I
IT-Infrastruktur analysieren (P1.2.2) X M,K M M I
Laufende Strategie- und IT-Projekte analysieren
(P1.2.3)
X M,K M M I,K
Stakeholder ermitteln (P1.2.4) X M.K M,K I
Veränderungsgrad analysieren (P1.2.5) X M,K M M I,K
Integriertes Vorgehensmodell zur Einführung von PDM-Systemen Seite 95
Eingangsgrößen: Organigramme, bestehende Prozessbeschreibungen und Ver-
fahrensanweisungen, Wissen der Mitarbeiter im Unternehmen.
Ergebnisse: Übersichtliche Darstellung des Geschäftsprozessmodells, Konsens
der Unternehmensvertreter über das Modell.
Aktivität: IT-Infrastruktur analysieren (P1.2.2)
Beschreibung: Am Ende der PDM-Einführung steht immer eine technische
Lösung. Diese muss natürlich so gut wie möglich in die bestehende technische
Infrastruktur des Unternehmens integriert sein. Deshalb ist diese Infrastruktur
genau zu ermitteln. Ausserdem sind Unternehmensrichtlinien in Bezug auf den
Einsatz bevorzugter Informationstechnik zu ermitteln, weil sie den Lösungsraum
für die mögliche technische Lösung einschränken können.
Zur technischen Infrastruktur gehören die vorhandene Hardware, das Netzwerk
und die eingesetzte Software. Um dem Charakter von PDM als Integrationslösung
gerecht zu werden, ist besonderes Augenmerk auf die Ermittlung von Schnittstel-
len zwischen den bestehenden Systemen zu legen. Auch dabei ist es wichtig, die
Ergebnisse der Analyse anschaulich darzustellen.
Eingangsgrößen: Bestehende Dokumentation, Wissen der Mitarbeiter im Unter-
nehmen, Unternehmensrichtlinien für Hardware, Software und Netzwerk..
Ergebnisse: Darstellung von Hardware-, Software- und Netzwerkarchitektur, Dar-
stellung der Schnittstellen, Dokumentation der Restriktionen.
Beispiel: Die Unternehmensrichtlinie, im Entwicklungsbereich nur Unix-basierte
Anwendungen zu benutzen, kann die Auswahl der möglichen
PDM-Systeme einschränken.
Aktivität: Laufende Strategie- und IT-Projekte analysieren (P1.2.3)
Beschreibung: Wie in Kapitel 2.1.1.3 ausführlich erläutert, hat PDM starke
Wechselwirkungen mit strategischen Projekten wie einem Business Process Reen-
gineering oder anderen IT-Projekten. Um zu vemeiden, dass solche parallel laufen-
den Projekte Festlegungen treffen, die die Umsetzung der PDM-Lösung behindern
oder gefährden (oder umgekehrt), müssen die laufenden Projektaktivitäten des
Unternehmens auf mögliche Wechselwirkungen hin untersucht werden. Die
erkannten möglichen Wechelwirkungen müssen dokumentiert werden. Diese
haben sowohl Einfluss auf die weitere Projektplanung der PDM-Einführung als
auch auf die anderen Projekte, z.B. durch Harmonisierung von Konzeptionspha-
sen. Die Abstimmung während der Projektdurchführung kann auch durch einen
Integrationskreis durchgeführt werden.
Seite 96 Kapitel 4
Eingangsgrößen: Projektübersicht, Projektbeschreibungen, Wissen der Mitarbei-
ter im Unternehmen.
Ergebnisse: Darstellung der inhaltlichen und zeitlichen Wechselwirkungen zu
anderen Projekten (Projektmasterplan). Abstimmung zwischen den Projekten über
Koordinationsmaßnahmen.
Beispiel: In einem Unternehmen ist die Einführung eines neuen ERP-Systems
geplant. Dabei sollen auch die Prozesse zum Aufbau von Stücklisten
optimiert werden. Da die Grunddaten für die Stücklisten aus dem
PDM-System kommen, müssen die Projekte ihre Releaseplanung aufein-
ander abstimmen und ein Integrationsteam bilden, dass die inhaltliche
Koordination der Stücklistendefinitionen beider Projekte übernimmt.
Aktivität: Stakeholder ermitteln (P1.2.4)
Beschreibung: Um Akzeptanz und damit Erfolg der PDM-Einführung zu gewähr-
leisten, müssen die betroffenen Funktionsbereiche des Unternehmens spätestens
bei der Potentialanalyse (P1.3) einbezogen werden. Die Mitwirkung und Mitver-
antwortung bei der Ermittlung von Schwachstellen und den daraus erwachsenden
Verbesserungspotentialen reduziert die Unsicherheit über die zu erwartenden Ver-
änderungen durch die PDM-Einführung und damit zu einer besseren Identifizie-
rung mit den Zielen.
Stakeholder sind nicht nur die direkt am Prozess Beteiligten. Unternehmensspezifi-
sche oder gesetzliche Regelungen verlangen oft auch die Beteiligung weiterer Stel-
len wie die des Betriebsrats oder eines Sicherheitsbeauftragten.
Eingangsgrößen: Untersuchungsbereich, Identifizierte PDM-relevante Prozesse,
rechtliche und unternehmensinterne Bestimmungen.
Ergebnisse: Übersicht über die im weiteren Verlauf der PDM-Einführung einzu-
beziehenden Funktionsbereiche des Unternehmens, Namentliche Nennung von
Vertretern der Funktionsbereiche.
Aktivität: Veränderungsgrad analysieren (P1.2.5)
Beschreibung: PDM fordert aufgrund der in Kapitel 2.1.1.1 beschriebenen Para-
digmenwechsel ein Umdenken im Unternehmen. Hat dieses bisher noch nicht
stattgefunden, müssen bei der PDM-Einführung begleitende Maßnahmen dazu
durchgeführt werden. Deshalb wird bei dieser Aktivität untersucht, welche der Pra-
digmenwechsel schon wie weit vollzogen sind. Dies kann z.T. aus der Analyse der
Ablauforganisation (P1.2.1) abgeleitet werden.
Bei der Untersuchung soll auch schon frühzeitig festgestellt werden, wie stark der
zu erwartende Widerstand gegen die Veränderungen durch die PDM-Einführung
Integriertes Vorgehensmodell zur Einführung von PDM-Systemen Seite 97
sein wird. Dazu ist auch eine Betrachtung der Unternehmenskultur notwendig.
Hier können z.B. Interviews von geschulten Beratern durchgeführt werden oder
bisher durchgeführte Veränderungsprojekte im Unternehmen analysiert werden.
Diese Aktivität ergänzt somit die qualitative Personalbestandsermittlung um die
humanorientierten Kompetenzen.
Eingangsgrößen: Dokumentation durchgeführter Veränderungsprojekte, Unter-
nehmenskulturprofile.
Ergebnisse: Grad der Umsetzung der Paradigmenwechsel, Grad der Verände-
rungsbereitschaft im Unternehmen, Abschätzung zu erwartender Widerstände.
Beispiel: Die Analyse der Ablauforganisation hat ergeben, dass nur wenig
Schnittstellen zwischen Funktionsbereichen bestehen und eher abtei-
lungsorientiert gearbeitet wird. Daraus ergibt sich die Notwendigkeit,
das prozessorientierte Denken der Mitarbeiter des Unternehmens wäh-
rend der PDM-Einführung zu fördern und durch eine entsprechende
Umsetzung in neue Sollprozesse zu unterstützen.
4.3.1.3 Potentialanalyse (P1.3)
Steht die Ausgangssituation des Unternehmens fest, muss als nächstes ermittelt
werden, wo durch die PDM-Einführung welcher Nutzen im Untersuchungsbereich
erzielt werden kann. Der Nutzen kann zum einen durch die Verbesserung von
Schwachstellen der bestehenden Prozesse durch PDM entstehen. Zum anderen
können vollständig neue Prozesse, die erst durch PDM möglich werden, weiteren
Nutzen bringen. Die von diesen Prozessen betroffenen Funktionen des Unterneh-
mens müssen ermittelt werden, um in die Einführung einbezogen zu werden. Aus
wirtschaftlicher Sicht wird der erwartete Nutzen quantifiziert und als Meßgröße für
den Erfolg der PDM-Einführung festgeschrieben. Die ermittelten Potentiale bilden
die Entscheidungsgrundlage für den Beginn des Folgeprojektes der Systemaus-
wahl.
Die Potentialanalyse (P1.3) beinhaltet daher die folgenden Aktivitäten:
• Schwachstellen identifizieren (P1.3.1),
• Verbesserungspotentiale ermitteln (P1.3.2),
• Wirtschaftliche Ziele festlegen (P1.3.3),
• über Beginn der Systemauswahl entscheiden (P1.3.4).
Die Zuordnung der Zuständigkeiten für die Aktivitäten zu den beteiligten Rollen
ist in Tabelle 4-3 dargetellt.
Seite 98 Kapitel 4
Aktivität: Schwachstellen identifizieren (P1.3.1)
Beschreibung: Schwachstellen können durch kritische Betrachtung der Ist-Pro-
zesse und den Vergleich mit so genannten Best Practices, d.h. allgemein anerkann-
ten guten Lösungen für eine Problemstellung, erkannt werden. Dabei sind auch die
grafischen Darstellungen der Ist-Situation von großem Nutzen. Des weiteren kön-
nen Schwachstellen durch rechnerische Auswertungen von Prozessinformationen
(z.B. Durchlaufzeiten) ermittelt werden. Schwachstellen können voneinander
abhängen, so dass eine nach aussen sichtbare Schwachstelle oftmals nur das Sym-
ptom für ein tieferliegendes Problem im Prozess darstellt. Darum sind auch die
Ursachen für erkannte Schwachstellen und die Verknüpfung der Schwachstellen
untereinander mit zu betrachten. Jede Schwachstelle ist außerdem auf ihre Auswir-
kung auf Durchlaufzeiten, Kosten und Ergebnisqualität hin zu untersuchen. Ursa-
chen, Abhängigkeiten und Auswirkungen der Schwachstellen fliessen in eine
Gewichtung ein.
In dieser Aktivität werden auch die operativen Notwendigkeiten, die den Anstoß
für den Start der PDM-Einführung gegeben haben (siehe Kapitel 4.2), wieder mit
in die Betrachtung einbezogen.
Eingangsgrößen: Ergebnisse der Ist-Analyse, Best Practices, erkannte operative
Probleme.
Ergebnisse: Nach Ursachen, Abhängigkeiten und Auswirkungen gewichteter
Schwachstellenkatalog mit detaillierter Beschreibung der Schwachstellen.
Tabelle 4-3: Zuständigkeiten der Aktivitäten der Potentialanalyse (P1.3)
D: Durchführungsverantwortung
M: Mitwirkungspflicht
I: Informationsanspruch
E: Entscheidung
K: Kontrolle/Überprüfung
X: Gesamtverantwortung (D/E/K)
Projektleiter
Externer Berater
Prozessexperten
Methodenexperten
Unternehmenscontrolling
Lenkungskreis
Schwachstellen identifizieren (P1.3.1) X M,K M,K M I I
Verbesserungspotentiale ermitteln
(P1.3.2)
XM,KM,KM I
Wirtschaftliche Ziele festlegen (P1.3.4)DMMMDE
Über Beginn der Systemauswahl ent-
scheiden (P1.3.5)
DMM ME
Integriertes Vorgehensmodell zur Einführung von PDM-Systemen Seite 99
Beispiel: Bei der Analyse der Arbeitsplanung wird als Schwachstelle die hohe
Fehlerhäufigkeit der Arbeitspläne ermittelt. Zur Beseitigung dieser
Schwachstelle kann auf den ersten Blick die Einführung eines Prüf-
schrittes vor der Weitergabe der Arbeitspläne in die Fertigung sinnvoll
sein. Bei genauerer Untersuchung stellt sich als eigentliche Ursache für
die Fehler ein Medienbruch bei der Übermittlung der Stückliste von der
Entwicklung zur Arbeitsplanung heraus. Hier muss der Medienbruch
beseitigt werden, anstatt den Prüfschritt einzuführen.
Aktivität: Verbesserungspotentiale ermitteln (P1.3.2)
Beschreibung: Sind die Schwachstellen und deren Ursache-Wirkungs-Ketten im
Unternehmen erkannt, lässt sich nun ermitteln, welche Verbesserungspotentiale in
der PDM-Einführung stecken. Dazu nutzt man bekannte Zahlen über den erreich-
ten Nutzen von PDM-Einführungen in Unternehmen mit ähnlichen Prozessen.
Diese findet man in der Literatur oder bekommt sie aus Projekterfahrungen des
externen Beraters.
Eingangsgrößen: Schwachstellenkatalog, Wissen über prinzipielle Nutzenpoten-
tiale von PDM, Best Practices, Wissen der Mitarbeiter des Unternehmens.
Ergebnisse: In Bezug auf Zeit, Kosten und Qualität quantifizierte Verbesserungs-
potentiale für die ermittelten Schwachstellen
Aktivität: Wirtschaftliche Ziele festlegen (P1.3.3)
Beschreibung: Es muss definiert werden, welcher wirtschaftlicher Nutzen im
Sinne von messbaren Kosten- und Zeiteinsparungen von der PDM-Einführung
konkret erwartet wird. Daran wird am Ende gemessen, ob die PDM-Einführung
erfolgreich war oder nicht. Welche Kennzahlen dazu herangezogen werden , hängt
von der Priorisierung der wirtschaftlichen Kosten- und Zeitziele und den wirt-
schafltichen Implikationen von strategischen Zielen ab. Die Höhe der erwarteten
Kosten- und Zeiteinsparungen ergibt sich aus den theoretischen Potentialen und
der Wahrscheinlichkeit, mit der diese Potentiale umgesetzt werden können.
Eingangsgrößen: Bezug auf Zeit, Kosten und Qualität quantifizierte Verbesse-
rungspotentiale, strategische Ziele.
Ergebnisse: Kennzahlen zur Messung des Einführungserfolges, Ausgangswerte
der Kennzahlen, Geforderte Zielwerte.
Aktivität: Über Beginn der Systemauswahl entscheiden (P1.3.4)
Beschreibung: In dieser Aktivität wird über den Beginn des nachfolgenden Pro-
jektes entschieden. Entscheidungsgrundlage ist dabei die glaubwürdige Darstel-
Seite 100 Kapitel 4
lung eines hohen Nutzens von PDM für das Unternehmen. Kostenaspekte spielen
hier noch keine Rolle, da die tatsächlichen Kosten noch nicht ermittelbar sind.
Eingangsgrößen: Festgelegte Kennzahlen, strategische und wirtschaftliche Impli-
kationen von PDM auf das Unternehmen.
Ergebnisse: Projektauftrag zur Durchführung der Systemauswahl.
4.3.1.4 Projektmanagement (P1.4)
Das Projektmanagement während der Vorstudie beschränkt sich im Großen und
Ganzen auf die üblichen Aktivitäten der Definition, Planung, Überwachung und
Steuerung des Projektes sowie dem Projektabschluss. Diese Phasen werden hier
deshalb nicht näher erläutert.
Die Planungsaktivität der Auswahl der Projektmitarbeiter ist Bestandteil der inte-
grierten Personalplanung- und -entwicklung, die in Kapitel 5 beschrieben wird.
Ein wichtiger Aspekt, der gleich zu Beginn der PDM-Einführung beachtet werden
muss, ist die Schaffung eines einheitlichen Begriffsverständnisses unter allen
Beteiligten (siehe Kapitel 2.2.6). Dazu wird bereits in der Projektvorbereitung ein
Glossar angelegt, in dem alle Begriffe eindeutig definiert und abgegrenzt werden.
Im Laufe des Projektes wächst das Glossar dann über die Phasen weiter und wird
gegen Ende Bestandteil der Schulungs- und Systemdokumentation.
4.3.2 Projektorganisation
Die Projektorganisation der Vorstudie (P1) ist in Bild 4-5 dargestellt. Als leitende
Funktionen sind der Projektleiter und der Lenkungskreis definiert. Der Projektlei-
ter wird durch ein Projektmanagementteam unterstützt. Verantwortlich für die
inhaltliche Durchführung ist ein Kernteam. Dieses kann je nach Größe des Projek-
tes und Umfang der Arbeiten durch Fachteams unterstützt werden.
Der Lenkungskreis tritt im Sinne eines internen Kunden als Auftraggeber des Pro-
jektes auf. Er erteilt den Projektauftrag, überprüft die Ergebnisse von Zwischen-
schritten und nimmt das Endergebnis ab. Treten während des Projektes Probleme
auf, die nicht durch die Projektleitung und das Kernteam zu lösen sind, obliegt
ebenfalls dem Lenkungskreis die Entscheidungsfindung. Dabei kann es sich u.a.
um inhaltliche Differenzen zwischen Unternehmensvertretern oder um vertragli-
che Unstimmigkeiten mit externen Projektmitarbeitern handeln. Im Lenkungskreis
sitzen Verteter der von der PDM-Einführung betroffenen Unternehmensbereiche
mit Leitungsfunktion. Wird das Projekt mit externer Unterstützung durchgeführt,
ist auch eine Person mit leitender Funktion aus dem externen Unternehmen vertre-
ten. Sofern Entscheidungsbefugnisse des Betriebrates betroffen sind, z.B. bei
grundsätzlichen Änderungen von Stellenbeschreibungen o.ä., entsendet auch die-
Integriertes Vorgehensmodell zur Einführung von PDM-Systemen Seite 101
ser einen Vertreter in den Lenkungskreis. In der Vorstudie wird das Unternehmen
im Lenkungskreis wegen der strategischen Bedeutung durch Mitglieder der ober-
sten Führungsebenen vertreten. Leiter des Lenkungskreis wird nach seiner Bestim-
mung der Projektpate.
Die Projektleitung wird bei Beteiligung externer Unterstützung von jeweils einem
internen Projektleiter des Unternehmens und des externen Partners gebildet. Sie ist
für die ordnungsgemäße Durchführung des Projektes verantwortlich. Das bezieht
sich sowohl auf die klassischen Projektmanagementtätigkeiten, der Planung,
Steuerung und Überwachung aller Aktivitäten als auch auf die inhaltlichen Ergeb-
nisse des Projektes. Die Projektleitung vertritt das Projekt nach aussen gegenüber
dem Lenkungskreis und in der Kommunikation mit Dritten, z.B. weiteren Unter-
auftragnehmern. Der interne Projektleiter der Vorstudie sollte, um Konflikte zwi-
schen einzelnen Unternehmensbereichen zu vermeiden, aus einem Stabsbereich
der Unternehmensführung kommen. Er ist außerdem im Regelfall und bei entspre-
chender Qualifikation Sprecher der Projektleitung.
Bei der Durchführung ihrer Tätigkeiten kann die Projektleitung je nach Umfang
des Projektes von einem Projektmanagementteam unterstützt werden. In der
Vorstudie beinhalten dessen Aufgaben neben klassischen Sekretariatstätigkeiten
vor allem die Projektkommunikation und das Projektcontrolling.
Das Kernteam wird zur Bearbeitung der inhaltlichen bzw. fachlichen Aktivitäten
aus den Prozessexperten des Unternehmens und den Methodenexperten des exter-
nen Partners gebildet. Die Prozessexperten bringen ihr Wissen über die Abläufe
und Struktur des Unternehmens ein. Sie müssen dazu für die Vorstudie vor allem
über ein übergreifendes Verständnis verfügen, da hier zunächst das gesamte Unter-
Bild 4-5: Projektorganisation in der Vorstudie (P1)
Seite 102 Kapitel 4
nehmen betrachtet wird. Die Methodenexperten unterstützen bei der strukturierten
Erarbeitung und Darstellung der Ergebnisse.
Je nach Größe und Komplexität des betrachteten Unternehmens kann es sinnvoll
sein, die Aufgaben des Kernteams in Fachteams aufzuteilen. Diese bestehen wie-
derum aus internen Experten, unterstützt durch externe Methodenexperten. Die
Aufteilung erfolgt auf Basis teilbarer Arbeitspakete bzw. unterschiedlicher
Betrachtungsebenen. Die Aufgabe des Kernteams ist dann die Koordination der
Aktivitäten und die Zusammenfassung der Ergebnisse dieser Fachteams.
4.4 Systemauswahl (P2)
Ziel der Systemauswahl (P2) ist die Festlegung der technischen Basis für die
PDM-Einführung. Wie in Kapitel 2.1.1.3 dargestellt, handelt es sich bei PDM in
erster Linie um ein Konzept, das nicht zwingend durch ein eigenes System abge-
bildet werden muss. Es existieren auf der einen Seite allerdings sehr hohe Anforde-
rungen in Bezug auf die technische Umsetzung als Integrationsplattform und in
Bezug auf den Umfang der notwendigen Anwendungsfunktionen. Auf der anderen
Seite bieten die am Markt verfügbaren Systeme größtenteils eine sehr gute Basis
zur Erfüllung dieser Anforderungen. Somit treten die Realisierungsoptionen ent-
weder ohne System oder mit einer Eigenentwicklung, das PDM-Konzept umzuset-
zen, zunehmend in den Hintergrund. Ohnehin stellt sich die Frage der Eigenent-
wicklung (make-or-buy) aufgrund der hohen Kosten und des benötigten
Know-hows nur für sehr große Unternehmen. Deshalb wird im weiteren davon
ausgegangen, dass eine marktverfügbare Standardsoftware als Plattform für die
PDM-Einführung dienen soll (siehe Kapitel 2.2.7). Der Auswahlprozess ist auf-
grund der hohen Anzahl der verfügbaren Systeme und des hohen Aufwandes für
die Evaluierung jedes einzelnen Systems zweistufig gestaltet.
4.4.1 Phasen
Die Systemauswahl (P2) gliedert sich deshalb gemäß Bild 4-6 in die vier Phasen
Grobkonzeption (P2.1), Systemvorauswahl (P2.2), Benchmark (P2.3) und
Releaseplanung (P2.4). Auch hier muss wie bei der Vorstudie (P1) ein begleiten-
des Projektmanagement (P2.5) durchgeführt werden. Die Phasen laufen sequentiell
ab.
4.4.1.1 Grobkonzeption (P2.1)
Bevor ein System ausgewählt werden kann, sind die Bewertungskriterien für die
Auswahl festzulegen. Ein System ist dann richtig, wenn es unter Berücksichtigung
strategischer und technischer Vorgaben die Geschäftprozesse des Unternehmens
angemessen unterstützt. Deshalb muss zunächst der gewünschte Sollzustand der
Integriertes Vorgehensmodell zur Einführung von PDM-Systemen Seite 103
Prozesse entworfen werden. Dieser berücksichtigt die in der Vorstudie (P1) ermit-
telten strategischen Vorgaben und beseitigt die festgestellten Schwachstellen.
Neben den Abläufen ist für die Einführung eines datenbankbasierten Systems, wie
es PDM-Systeme darstellen, auch wichtig, die zu verwaltenden Daten zu ermitteln.
Die sich insgesamt ergebenden Anforderungen müssen dokumentiert und gewich-
tet werden.
Die Grobkonzeption (P2.1) beinhaltet daher die folgenden Aktivitäten:
• Sollprozessmodell entwerfen (P2.1.1),
• Grobes Datenmodell entwerfen (P2.1.2),
• Anforderungskatalog erstellen (P2.1.3).
Die Zuordnung der Zuständigkeiten für die Aktivitäten zu den beteiligten Rollen
ist in Tabelle 4-4 dargetellt.
Aktivität: Sollprozessmodell entwerfen (P2.1.1)
Beschreibung: Ausgehend vom Ist-Zustand der Prozesse und mit dem Wissen um
die darin enthaltenen Schwachstellen, wird im Sollprozessmodell der gewünschte
Zustand nach der PDM-Einführung beschrieben. Dazu werden an den Schwach-
Bild 4-6: Die Phasen der Systemauswahl (P2)
Seite 104 Kapitel 4
stellen bestehende Prozesse verändert oder ganz durch andere ersetzt. Der Entwurf
eines Sollprozessmodells ist ein kreativer Prozess, bei dem in mehreren Zyklen
Verbesserungsvorschläge erarbeitet, bewertet und wieder überarbeitet werden
müssen. Eine Lösungsmöglichkeit besteht auch durch die Adaption von Prozessen
anderer Unternehmen, die als besonders gut gelten (Best Practices), oder branchen-
spezifische Referenzmodelle. Oft muss zwischen verschiedenen Alternativen von
Verbesserungen für eine Schwachstelle entschieden werden. Dies sollte an Hand
der strategischen Vorgaben für die PDM-Einführung, der Umsetzbarkeit der vor-
geschlagenen Alternativen sowie dem erreichbaren Nutzen der Alternativen
geschehen. Am Ende des Prozesses steht dann ein von allen beteiligten Bereichen
akzeptierter erwünschter Sollzustand, der die Basis für die Systemeinführung bil-
det.
Eingangsgrößen: Übersichtliche Darstellung des Istprozessmodells, detaillierte
Beschreibung der ermittelten Schwachstellen, erwarteter Nutzen, Best Practices.
Ergebnisse: Übersichtliche Darstellung des Sollprozesses mit Prozessschritten,
Eingangs- und Ausgangsdaten der Prozesse, durchführenden Funktionen sowie
unterstützenden Ressourcen (vor allem IT).
Aktivität: Grobes Datenmodell entwerfen (P2.1.2)
Beschreibung: Letztendlich werden im PDM-System Daten verwaltet. Um festzu-
stellen, ob ein System die notwendigen Daten verwalten kann, wird ein grobes
Datenmodell entworfen. Dieses enthält zunächst nur die Datenobjekte, die im
Unternehmen vorhanden sind (Teile, Dokumente etc.) sowie die zwischen den
Objekten bestehenden Beziehungen. Eine genaue Spezifikation aller beschreiben-
den Attribute ist noch nicht notwendig. Es sei denn, es gibt Einschränkungen bei
den Attributen, z.B. durch ein festes Nummernsystem, die dazu führen können,
Tabelle 4-4: Zuständigkeiten der Aktivitäten der Grobkonzeption (P2.1)
D: Durchführungsverantwortung
M: Mitwirkungspflicht
I: Informationsanspruch
E: Entscheidung
K: Kontrolle/Überprüfung
X: Gesamtverantwortung (D/E/K)
Projektleiter
Externer Berater
Prozessexperten
Methodenexperten
Unternehmenscontrolling
Lenkungskreis
Sollprozessmodell entwerfen (P2.1.1) X M,K M,K M I I
Grobes Datenmodell entwerfen (P2.1.2) X M,K M,K M I
Anforderungskatalog erstellen (P2.1.3) X M M M,K E
Integriertes Vorgehensmodell zur Einführung von PDM-Systemen Seite 105
dass ein System nicht eingesetzt werden kann. Informationen dazu, welche Daten-
objekte verwaltet werden müssen, können aus dem Sollprozess und der Infrastuk-
turanalyse gewonnen werden.
Eingangsgrößen: Darstellung des Sollprozesses, Eingangs- und Ausgangsdaten
der Prozesse, Ergebnisse der IT-Infrastrukturanalyse (vor allem Schnittstellen und
Softwarearchitektur).
Ergebnisse: Unternehmensdatenmodell mit Objekten, Beziehungen und Ein-
schänkungen.
Beispiel: Die Analyse der benutzen Software des Unternehmens hat ergeben, dass
zwei verschiedene CAD-Systeme mit sehr unterschiedlicher Ablage
ihrer Dateien im Einsatz sind. Im Datenmodell müssen beide Arten von
CAD-Dateien berücksichtigt werden. Als Anforderung an das
PDM-System ergibt sich, dass zu beiden CAD-Systemen Schnittstellen
vorhanden sein müssen.
Aktivität: Anforderungskatalog erstellen (P2.1.3)
Beschreibung: Als Grundlage für die Bewertung der PDM-Systeme dient eine
Aufstellung aller relevanter strategischer, funktionaler, technischer und betriebs-
wissenschaftlicher Anforderungen, die das System und der Hersteller erfüllen
müssen. Dabei ist es wichtig, dass diese Anforderungen auch bewertbar und ver-
gleichbar sind. Ausserdem müssen die Anforderungen gewichtet werden. Vor
allem in der folgenden Systemvorauswahl (P2.2) sollten nicht zu viele detaillierte
Anforderungen bewertet werden sondern nur die wichtigsten. Beispiele für Anfor-
derungen zeigt Tabelle 4-5. Bei der Formulierung und Gewichtung können auch
verfügbare Kriterienkataloge von Beratungsunternehmen, Instituten oder aus der
Literatur herangezogen werden, um keine wichtigen Aspekte zu vergessen.
Eingangsgrößen: Sollprozessmodell, Datenmodell, technische Restriktionen,
strategische Vorgaben, Kriterienkataloge.
Ergebnisse: Anforderungskatalog mit gewichteten Anforderungen.
Tabelle 4-5: Beispiele für Anforderungen an ein PDM-System
Kategorie Anforderung Bewertung
Strategisch Hohe Integration in das be-
stehende ERP-System
Nicht integriert (0)
Schnittstelle (1)
Integrierte Anwendung (2)
Seite 106 Kapitel 4
4.4.1.2 Systemvorauswahl (P2.2)
Wie in Kapitel 2.1.2.4 dargestellt, ist der Markt für PDM-Systeme sehr groß und
fragmentiert. Eine detaillierte Bewertung oder sogar Tests aller Systeme sind kaum
möglich. Deshalb wird zunächst an Hand einer Vorauswahl die Anzahl der
Systeme, die einer detaillierten Untersuchung unterzogen werden, eingeschränkt.
Dies geschieht auf Basis der im Anforderungskatalog definierten gewichteten
Anforderungen.
Die Systemvorauswahl (P2.2) beinhaltet daher die folgenden Aktivitäten:
• Marktrecherche durchführen (P2.2.1),
• Systemvergleich durchführen (P2.2.2),
• Short List10 bilden (P2.2.3).
Die Zuordnung der Zuständigkeiten für die Aktivitäten zu den beteiligten Rollen
ist in Tabelle 4-6 dargetellt.
Aktivität: Marktrecherche durchführen (P2.2.1)
Beschreibung: In dieser Aktivität werden zunächst die verfügbaren Systeme
ermittelt und die dazugehörigen Informationen zum System und Anbieter einge-
holt. Eine Bewertung findet zunächst nicht statt. Die Informationen können direkt
vom Anbieter, von Vertriebspartnern oder aus Marktübersichten stammen. Dabei
Funktional Unterstützung eines integrier-
ten Programm- und Projekt-
managements
Nicht vorhanden (0)
Teilweise vorhanden (1)
Vorhanden (2)
Anwendungsstärke (3)
Technisch Unterstützung vorhandener
Hardware
Nicht unterstützt (0)
Teilweise unterstützt (1)
Voll unterstützt (2)
Betriebswirtschaftlich Branchenspezifische Vorkon-
figuration zur Senkung der
Anpassungskosten
Nicht vorkonfiguriert (0)
Teilweise vorkonfiguriert (1)
Branchenstandard (2)
10. Short List = Liste der engeren Wahl
Tabelle 4-5: Beispiele für Anforderungen an ein PDM-System
Kategorie Anforderung Bewertung
Integriertes Vorgehensmodell zur Einführung von PDM-Systemen Seite 107
kann man auf schriftlich verfügbare Informationen zurückgreifen. Zur Gewährlei-
stung der Vergleichbarkeit müssen dort nicht enthaltene Informationen, z.B. auf
Messen nachrecherchiert bzw. beim Anbieter im direkten Kontakt nachgefordert
werden. Eine weitere Möglichkeit ist, den Anforderungskatalog allen Anbietern
zuzusenden und die Anworten auszuwerten.
Eingangsgrößen: Anforderungskatalog, Systeminformationen, Marktübersichten.
Ergebnisse: Aufstellung der Informationen über verfügbare Systeme.
Aktivität: Systemvergleich durchführen (P2.2.2)
Beschreibung: Sind alle notwendigen Informationen ermittelt, müssen die
Systeme an Hand der Anforderungen verglichen werden. Dies kann pro Anforde-
rung absolut, d.h. mit Hilfe einer definierten Bewertungsskala (siehe Tabelle 4-5),
oder relativ durch Aufstellen einer Rangliste der Systeme geschehen. Dabei muss
die Güte der Systeminformation berücksichtigt werden. Aussagen aus Marketing-
broschüren sind schlechter zu bewerten als Aussagen aus unabhängigen System-
tests oder persönliche Erfahrungen von Systemvorführungen.
Eingangsgrößen: Informationen über verfügbare Systeme, Anforderungskatalog.
Ergebnisse: Bewertete Systeminformationen.
Aktivität: Short List bilden (P2.2.3)
Beschreibung: Im letzten Schritt der Systemvorauswahl (P2.2) müssen nun die
Systeme bestimmt werden, die einem detaillierterem Vergleich zu unterziehen
sind. Das sind im Normalfall die Systeme, die im allgemeinen Vergleich am besten
Tabelle 4-6: Zuständigkeiten der Aktivitäten der Systemvorauswahl (P2.2)
D: Durchführungsverantwortung
M: Mitwirkungspflicht
I: Informationsanspruch
E: Entscheidung
K: Kontrolle/Überprüfung
X: Gesamtverantwortung (D/E/K)
Projektleiter
Externer Berater
Prozessexperten
Methodenexperten
Unternehmenscontrolling
Lenkungskreis
Marktrecherche durchführen (P2.2.1) X M,K M,K M I I
Systemvergleich durchführen (P2.2.2) X M,K M,K M I
Short List bilden (P2.2.3) X M M M,K I
Seite 108 Kapitel 4
abgeschnitten haben. Wegen des hohen Aufwandes werden nicht mehr als drei bis
vier Systeme genauer untersucht.
Eingangsgrößen: Bewertete Systeminformationen.
Ergebnisse: Auswahl der im folgenden genauer zu untersuchenden Systeme.
4.4.1.3 Benchmark (P2.3)
Die für die Short List ausgewählten Systeme und die anbietenden Unternehmen
müssen nun eingehender geprüft werden. Dies geschieht auf Basis von definierten
Testfällen, in denen die wichtigsten der ermittelten Schlüsselprozesse des Unter-
nehmens mit den Systemen abgebildet werden. Zusätzlich werden die Systeme
genauer auf den Kriterienkatalog hin untersucht und die Kosten der Systeme mit-
einander verglichen. Am Ende steht die Entscheidung für ein System, mit dem die
PDM-Einführung fortgesetzt werden soll.
Der Benchmark (P2.3) beinhaltet daher die folgenden Aktivitäten:
• Testszenarien definieren (P2.3.1),
• Benchmarks planen (P2.3.2),
• Benchmarks durchführen (P2.3.3),
• Systeme vergleichen (P2.3.4),
• Entscheidung für ein System treffen (P2.3.5).
Die Zuordnung der Zuständigkeiten für die Aktivitäten zu den beteiligten Rollen
ist in Tabelle 4-7 dargetellt.
Tabelle 4-7: Zuständigkeiten der Aktivitäten des Benchmarks (P2.3)
D: Durchführungsverantwortung
M: Mitwirkungspflicht
I: Informationsanspruch
E: Entscheidung
K: Kontrolle/Überprüfung
X: Gesamtverantwortung (D/E/K)
Projektleiter
Externer Berater
Prozessexperten
Methodenexperten
Unternehmenscontrolling
Lenkungskreis
Testszenarien definieren (P2.3.1) X M,K M,K M I I
Benchmarks planen (P2.3.2) X M,K M,K M I
Benchmarks durchführen (P2.3.3) X M M M,K I
Systeme vergleichen (P2.3.4) D M M,K M M E
Entscheidung für ein System treffen
(P2.3.5)
DMM ME
Integriertes Vorgehensmodell zur Einführung von PDM-Systemen Seite 109
Aktivität: Testszenarien definieren (P2.3.1)
Beschreibung: Eine genaue Beurteilung eines PDM-Systems kann nur an Hand
der realen Anwendung erfolgen. Da es aus Kosten- und Zeitgründen nicht möglich
ist, die vollständige Umsetzung mit mehreren Systemen gleichzeitig durchzufüh-
ren, muss ein repräsentativer Ausschnitt der gewünschten Lösung zur Auswahl
herangezogen werden. Dabei sollten möglichst kritische oder besondere Anforde-
rungen getestet werden, da beim heutigen Stand der Systeme davon ausgegangen
werden kann, dass die Standardfunktionalität von allen Systemen zufriedenstellend
angeboten wird. Neben der Anwendung müssen auch technische Aspekte und die
zu erwartenden Kosten als wirtschaftliches Szenario betrachtet werden. Beispiele
für Testszenarien zeigt Tabelle 4-8.
Eingangsgrößen: Anforderungskatalog, Bewertete Systeminformationen, Grob-
konzeption.
Ergebnisse: Anwendungsszenarien mit Beschreibung der Daten und Abläufe,
technische Szenarien für Schnittstellen, Performance etc. Wirtschaftliches Szena-
rio zur Kostenbewertung.
Tabelle 4-8: Beispiele für Testszenarien
Kategorie Beschreibung Bewertung
Anwendungs-
szenario
Ein Unternehmen hat ein variantenreiches
Produktspektrum. Es werden deshalb die
Möglichkeiten zur Abbildung dieses Vari-
antenreichtums in den PDM-Systemen ge-
testet. Dazu wird die Stücklistenstruktur
eines besonders variantenreichen Produk-
tes in den Systemen abgebildet. So wird
zum einen die Anwendbarkeit der Stan-
dardfunktionen zum Produktstrukturmana-
gement getestet. Zum anderen lässt sich
ermitteln, ob alle notwendigen Funktionen
ohne Zusatzprogrammierung vorhanden
sind oder nicht.
Subjektiver Eindruck
der Testpersonen über
das Handling der
Funktionen.
Abdeckungsgrad mit
Standardfunktionalität.
Abdeckungsgrad mit
Zusatzprogrammie-
rung.
Technisches
Szenario
Zur Überprüfung der Performance, also
des Antwortverhaltens bei Aufruf einer
Funktion werden Massendaten in die Sy-
steme geladen und auf diese Daten kom-
plexe Abfragen ausgeführt. Die Systeme
sind dabei auf vergleichbarer Hardware in-
stalliert. Die Zeit, bis eine Suchanfrage be-
endet ist, wird gemessen und zwischen
den Systemen verglichen.
Relativ:
Rangfolge der Syste-
me nach Durschnitts-
zeiten.
Absolut:
Überschreitung eines
akzeptierten Schwel-
lenwertes.
Wirtschaftliches
Szenario
Es wird von den Systemanbietern ein An-
gebot für die Umsetzung der PDM-Lösung
eingeholt. Um eine Vergleichbarkeit der
Kosten herzustellen, wird die Angebots-
struktur vordefiniert.
Kostenvergleich: Inve-
stitionskosten, Dienst-
leistungskosten und zu
erwartende Kosten.
Seite 110 Kapitel 4
Aktivität: Benchmarks planen (P2.3.2)
Beschreibung: Zu den tatsächlichen Systemtests (Benchmarks) müssen viele Par-
teien koordiniert werden. Neben dem Projektteam aus internen und externen Mit-
arbeitern werden nun die Anbieter der Systeme der Short List hinzugezogen. Es
muss festgelegt werden, ob die Systeme im Unternehmen oder vor Ort beim
Anbieter getestet werden sollen11, ob die Tests parallel oder sequentiell durchge-
führt werden und ob von den Anbietern gefordert wird, alternative Lösungsvor-
schläge für einzelne Testszenarien zu machen. Die Anbieter müssen eine angemes-
sene Zeit bekommen, die Testszenarien umzusetzen und ein Angebot zu erstellen.
Je nach Umfang der Benchmarks muss auch verhandelt werden, ob die Anbieter
eine Aufwandsentschädigung dafür erhalten oder nicht.
Eingangsgrößen: Anwendungsszenarien, technische Szenarien, Short List.
Ergebnisse: Benchmarkplan mit Terminen und Ressourcen, Vertragliche Rege-
lungen mit den Anbietern, Angebote.
Aktivität: Benchmarks durchführen (P2.3.3
Beschreibung: Die Systemanbieter setzen die geforderten Testszenarien in der
vorgegebenen Zeit um. Die Bewertung erfolgt durch Mitarbeiter des Unterneh-
mens. Da in den Unternehmen zumeist wenig Erfahrung mit PDM-Systemen vor-
handen ist, werden sie durch die systemunabhängige Beratung unterstützt. Die
Testszenarien werden mit allen Systemen einmal oder mehrfach durchgeführt und
die gemessenen Ergebnisse und subjektiven Eindrücke dokumentiert. Zur Vermei-
dung zu hoher Subjektivität sollten immer mehrere Mitarbeiter die gleichen Szena-
rien testen.
Eingangsgrößen: Anwendungsszenarien, Technische Szenarien, Benchmarkplan
mit Terminen und Ressourcen.
Ergebnisse: Dokumentierte Testläufe, Gemessene Ergebnisse.
Aktivität: Systeme vergleichen (P2.3.4)
Beschreibung: Nach Durchführung der Benchmarks werden die Systeme vergli-
chen. Gemessene objektive Werte können direkt in eine Rangfolge einfliessen,
dabei ist die Gewichtung der Anforderungen zu berücksichtigen. Um die subjek-
tive Beurteilung in eine Rangfolge umzusetzen, wird entweder eine Punkteskala
eingesetzt, oder ein paarweiser Vergleich der Systeme bei den jeweiligen Beurtei-
lungskriterien durchgeführt.
11. Die Durchführung vor Ort eröffnet parallel zur Bewertung des Systems auch die Möglichkeit,
einen Eindruck von der Arbeitsweise und Kompetenz der Mitarbeiter des Systemanbieters zu
erhalten.
Integriertes Vorgehensmodell zur Einführung von PDM-Systemen Seite 111
Eingangsgrößen: Dokumentierte Testläufe, Gemessene Ergebnisse, Angebote.
Ergebnisse: Rangliste der Systeme.
Aktivität: Entscheidung für ein System treffen (P2.3.5)
Beschreibung: Abschließend muss unter Berücksichtigung aller funktionaler,
technischer, wirtschaftlicher und strategischer Vorgaben ein System ausgewählt
werden. Um für die anschließende Releaseplanung eine gewisse Planungssicher-
heit zu erhalten, wird mit dem ausgewählten Anbieter ein Rahmenvertrag
geschlossen, in dem die Preise und die Ressourcenverfügbarkeit des Anbieters für
die Einführung festgelegt werden.
Eingangsgrößen: Rangliste der Systeme, Strategische Vorgaben, Angebote.
Ergebnisse: Ausgewähltes PDM-System, Rahmenvertrag.
4.4.1.4 Releaseplanung (P2.4)
Die vollständige Umsetzung des PDM-Konzeptes dauert, wie in Kapitel 2.4.1 dar-
gestellt, meist mehrere Jahre. Es ist deshalb sinnvoll, die PDM-Einführung in klei-
nere Schritte zu zerlegen, um schon frühzeitig durch eingeführte Funktionalität
Nutzen zu erlangen und Erfahrungen mit der Technologie zu sammeln. Die Rei-
henfolge der Einführung bestimmter Funktionalität wird dabei durch Aufwand,
Nutzen, Systembedingungen und inhaltliche Abhängigkeiten zwischen den Funk-
tionalitäten bestimmt. Zusätzlich zu den inhaltlichen Schritten müssen Aktivitäten
zur Unterstützung der Paradigmenwechsel, zum Akzeptanzmanagement sowie für
das Roll-Out geplant werden.
Die Releaseplanung (P2.4) beinhaltet daher die folgenden Aktivitäten:
• Systemmodule analysieren (P2.4.1),
• Umsetzungsreihenfolge für Funktionalität festlegen (P2.4.2),
• Begleitende Aktivitäten planen (P2.4.3).
Die Zuordnung der Zuständigkeiten für die Aktivitäten zu den beteiligten Rollen
ist in Tabelle 4-9 dargetellt.
Aktivität: Systemmodule analysieren (P2.4.1)
Beschreibung: PDM-Systeme sind zumeist modular aufgebaut (siehe Kapitel
2.1.2.4). Dabei gibt es einige Kernmodule, ohne die die Anwendung nicht möglich
ist. Weitere Module bauen dann darauf auf oder ergänzen den Kern. Zusätzlich
kommen die unternehmensspezifischen Anpassungen dazu. In dieser Aktivität
wird dieser Kern bestimmt und festgelegt, in welcher Reihenfolge die Funktionali-
Seite 112 Kapitel 4
tät des Systems ausgebaut werden kann. Hier bestehen meistens mehrere Möglich-
keiten, die dokumentiert werden.
Eingangsgrößen: Systeminformationen.
Ergebnisse: Alternative Umsetzungspfade aus Systemsicht.
Aktivität: Umsetzungsreihenfolge für Funktionalität festlegen (P2.4.2)
Beschreibung: Die Beschaffenheit des Systems gibt den Rahmen und die Alterna-
tiven für die Umsetzungreihenfolge vor. Die tatsächliche Festlegung, welche der
Alternativen gewählt wird, hängt zum einen vom Nutzen der Funktionalität ab.
Module, die schnell einen hohen Nutzen versprechen, werden priorisiert einge-
führt. Zum anderen sind die Ressourcenverfügbarkeit und das Budget zu berück-
sichtigen. Die wohl wichtigsten Kernmodule fast jeden PDM-Systems sind die für
das Produktstrukturmanagement und für das Dokumentenmanagement. Sie werden
deshalb meist zuerst eingeführt. Zusätzlich müssen bei der Releaseplanung die
Querverbindungen der Funktionen untereinander und zu weiteren strategischen
IT-Projekten berücksichtigt werden. Ein Beispiel für eine funktionale Umset-
zungsreihenfolge zeigt Bild 4-7. Die Umsetzung jedes funktionalen Blockes ist
entsprechend der im folgenden Kapitel 4.5 beschriebenen Systemeinführung (P3)
gegliedert.
Eingangsgrößen: Alternative Umsetzungspfade aus Systemsicht, Sollprozessmo-
dell, gewichtete Anforderungen, Nutzenerwartungen, Ressourcenverfügbarkeit,
Projektmasterplan.
Ergebnisse: Planung der inhaltlichen Schritte der PDM-Einführung mit Definition
abgeschlossener Arbeitspakete.
Tabelle 4-9: Zuständigkeiten der Aktivitäten der Releaseplanung (P2.4)
D: Durchführungsverantwortung
M: Mitwirkungspflicht
I: Informationsanspruch
E: Entscheidung
K: Kontrolle/Überprüfung
X: Gesamtverantwortung (D/E/K)
Projektleiter
Externer Berater
Prozessexperten
Methodenexperten
Systemanbieter
Lenkungskreis
Systemmodule analysieren (P2.4.1) X M,K M,K M M
Umsetzungsreihenfolge für Funktionalität
festlegen (P2.4.2)
X M,KM,KMMI
Begleitende Aktivitäten planen (P2.4.3) X M M M,K M
Integriertes Vorgehensmodell zur Einführung von PDM-Systemen Seite 113
Aktivität: Begleitende Aktivitäten planen (P2.4.3)
Beschreibung: Zu der inhaltlichen Umsetzung der PDM-Funktionalitäten kom-
men begleitende Aktivitäten hinzu, die entweder über die gesamte Einführung hin-
weg oder zu jedem funktionalen Release durchgeführt werden müssen. Zu den
übergreifenden Aktivitäten gehören das Management des Wandels aufgrund von
Paradigmenwechseln und die Projektkommunikation. Die releasebegleitenden
Aktivitäten sind die Qualifizierung, das Qualitätsmanagement sowie das Software-
konfigurations- und Dokumentenmanagement.
Eingangsgrößen: Funktionaler Releaseplan, Grad der Umsetzung der Paradig-
menwechsel, Grad der Veränderungsbereitschaft im Unternehmen, Abschätzung
zu erwartender Widerstände.
Ergebnisse: Erweiterter Releaseplan mit begleitenden Aktivitäten.
4.4.1.5 Projektmanagement (P2.5)
Das Projektmanagement beschränkt sich während der Systemauswahl (P2) im
Großen und Ganzen auf die üblichen Aktivitäten der Definition, Planung, Überwa-
chung und Steuerung des Projektes sowie des Projektabschlusses. Diese Phasen
werden hier deshalb nicht näher erläutert. Einige begleitende Aktivitäten wie das
Dokumenten- und Softwarekonfigurationsmanagement, das Change-Management
und das Qualitätsmanagement spielen in der Systemauswahl nur eingeschränkt
Bild 4-7: Beispiel für eine funktionale Umsetzungreihenfolge.
Dokumentenmanagement
Produktstruktur/Basis
Produktstruktur/Varianten
Konfigurationsmanagement
CAD-Kopplung
Pro/Engineer
CAD-Kopplung
CATIA
Digital
Mockup
Workflowmanagement
10/2002 03/200401/2003 01/200406/2003
Release
1
Release
2
Release
3
Release
4
Release
5
Seite 114 Kapitel 4
eine Rolle. Sie erlangen in der Systemeinführung (P3) eine besondere Bedeutung.
Deshalb werden sie dort genauer erläutert (siehe Kapitel 4.5.1.5).
Die administrativen Tätigkeiten nehmen im Vergleich zur Vorstudie (P1) zu, weil
durch das Hinzuziehen der Systemanbieter der Short-List mehr Partner im Projekt
koordiniert werden müssen.
4.4.2 Projektorganisation
Die Projektorganisation der Systemauswahl (P2) ist in Bild 4-8 dargestellt. Sie
unterscheidet sich vom grundsätzlichen Aufbau nicht von der Projektorganisation
der Vorstudie (P1). Allerdings sind die Teilnehmer und Aufgaben der Gremien
bzw. Teams z.T. unterschiedlich. Diese Unterschiede werden im folgenden erläu-
tert.
Der Lenkungskreis ist auch in der Systemauswahl das Kontroll- und Problemlö-
sungsgremium. Den Vorsitz führt der benannte Projektpate. Im Gegensatz zur Vor-
studie (P1) werden die von der Einführung betroffenen Unternehmensbereiche
durch Mitglieder des mittleren Managements vertreten, die näher am operativen
Geschäft agieren. Zusätzlich wird nach der Systemauswahl ein Entscheidungsträ-
ger des Systemanbieters in den Lenkungskreis aufgenommen.
Die Projektleitung wird wiederum von einem internen und dem systemunabhän-
gigen externen Projektleiter gebildet. Je nach PDM-spezifischer Qualifikation des
internen Projektleiters wird nach Festlegung auf ein System ein Vertreter des
Systemanbieters in die Projektleitung mit aufgenommen oder ersetzt den systemu-
nabhängigen externen Projektleiter. Im Regelfall vertritt der interne Projektleiter
der Vorstudie (P1) auch weiterhin das Unternehmen. Einen Wechsel sollte es nur
Bild 4-8: Projektorganisation in der Systemauswahl
Integriertes Vorgehensmodell zur Einführung von PDM-Systemen Seite 115
in Ausnahmefällen geben, z.B. wenn nach der Vorstudie (P1) feststeht, dass die
PDM-Einführung von vorn herein nur in einem eingeschränkten Unternehmensbe-
reich durchgeführt wird und dort ein geeigneter Projektleiter zur Verfügung steht.
Das Projektmanagementteam wird in der Systemauswahl (P2) durch einen Ver-
treter des Einkaufs ergänzt, der die vertragliche Seite der Systemauswahl begleitet.
Die Verbindung mit parallel laufenden IT- und Strategieprojekten wird durch
einen Integrationskreis gewährleistet. In diesem stimmen die Projektleitungen
untereinander ihre Planungen und Konzeptionen ab.
Auf interner Seite des Kernteams und der Fachteams sind in der Systemauswahl
(P2) vor allem Mitarbeiter vertreten, die in ihrer Funktion später als Anwender das
PDM-System bedienen müssen. Ergänzt werden sie durch Experten der unterneh-
menseigenen IT-Funktionen, die die technischen Aspekte der Systemauswahl
unterstützen sowie durch so genannte Prozessbesitzer. Diese haben die Kompetenz
und Entscheidungsbefugnis, die Konzeption eines neuen Sollprozesses zu erstel-
len. Auf externer Seite wird das Projekt zunächst weiter durch systemunabhängige
Methodenexperten begleitet, die vor allem die Prozess- und Datenmodellierung
unterstützen. Nach der Auswahl des Systems kommen Experten des Systemanbie-
ters hinzu.
4.5 Systemeinführung (P3)
Ziel der Systemeinführung ist die technische und organisatorische Umsetzung der
in den vorhergegangenen Projekten definierten Sollprozesse. Dies geschieht in der
im Releaseplan festgelegten Reihenfolge. Dazu müssen die grob und systemunab-
hängig definierten Anforderungen an das PDM-System detaillierter und imple-
mentierungsnäher spezifiziert werden. Auf der Basis dieser Spezifikation werden
dann die Systemanpassungen vorgenommen und getestet sowie notwendige Infra-
strukturmaßnahmen durchgeführt. Am Ende steht die Übergabe der umgesetzten
Funktionalität in den operativen Betrieb.
4.5.1 Phasen
Die Systemeinführung (P3) gliedert sich deshalb gemäß Bild 4-9 in die vier Phasen
Feinspezifikation (P3.1), Systemanpassung (P3.2), Testen (P3.3) und Roll-Out
(P3.4). Auch hier muss wie in den Projekten vorher ein begleitendes Projektmana-
gement (P3.5) durchgeführt werden, dass aber durch einige Aktivitäten ergänzt
wird. Die Phasen und ihre Aktivitäten werden nicht streng sequentiell durchlaufen.
Im Sinne einer evolutionären, zyklischen Vorgehensweise kann, wenn notwendig,
immer wieder in vorhergehende Aktivitäten zurückgesprungen werden, z.B. um
eine unvollständige Spezifikation zu verbessern oder um die Implementierung
Seite 116 Kapitel 4
einer getesteten Funktionalität zu überarbeiten. Einige Aktivitäten können abhän-
gig vom Fokus des Projektes entfallen.
4.5.1.1 Feinspezifikation (P3.1)
Die in der Grobkonzeption erarbeiteten Sollprozess- und Datenmodelle müssen in
Bezug auf die konkreten Umsetzungsmöglichkeiten im ausgewählten System
detailliert werden. Dabei können bereits Erfahrungen aus den Testszenarien und
den Prototypen der Systemauswahl (P2) einfliessen. Im Vordergrund stehen die
Funktionen für den Anwender. Es muss spezifiziert werden, wer wie mit welchen
Mechanismen und über welche Bildschirmdialoge welche Daten manipulieren
darf.
Die spezifizierten Bestandteile werden im Pflichtenheft dokumentiert. Dies dient
als Basis für die tatsächliche Implementierung im System und als Abnahmedoku-
ment für die Tests. Während im Anforderungskatalog zunächst alle Anforderungen
unabhängig von ihrer Umsetzbarkeit aufgeführt sind, enthält das Pflichtenheft nur
noch die Anforderungen, die mit den gegebenen technischen Möglichkeiten und
Bild 4-9: Die Phasen der Systemeinführung (P3)
Integriertes Vorgehensmodell zur Einführung von PDM-Systemen Seite 117
mit angemessenem Aufwand umgesetzt werden können. Dabei wird, soweit mög-
lich, nicht nur dokumentiert was umgesetzt werden soll sondern auch die Art und
Weise der Umsetzung.
Die Feinspezifikation (P3.1) beinhaltet daher die folgenden Aktivitäten:
• Anwendungsfälle definieren (P3.1.1),
• Datenmodell spezifizieren (P3.1.2),
• Dialogdesign entwerfen (P3.1.3),
• Schnittstellen definieren (P3.1.4),
• Berechtigungskonzept definieren (P3.1.5),
• Tests planen (P3.1.6),
• Pflichtenheft erstellen (P3.1.7).
Die Zuordnung der Zuständigkeiten für die Aktivitäten zu den beteiligten Rollen
ist in Tabelle 4-10 dargetellt.
Aktivität: Anwendungsfälle definieren (P3.1.1)
Beschreibung: Ein Anwendungsfall beschreibt entweder den konkreten Umgang
des Anwenders mit dem System oder eine systeminterne Bearbeitung einer Auf-
gabe. Er besteht aus einer abgeschlossenen Folge von Aktionen, die der Anwender
am System bzw. das System intern ausführen muss, damit ein gewünschtes Ergeb-
nis erreicht wird. Ein gesamter Prozess beinhaltet eine Folge von Anwendungsfäl-
len. Ein einzelner Anwendungsfall kann auch in mehreren Folgen im Prozess vor-
Tabelle 4-10: Zuständigkeiten der Aktivitäten der Feinspezifikation (P1.3)
D: Durchführungsverantwortung
M: Mitwirkungspflicht
I: Informationsanspruch
E: Entscheidung
K: Kontrolle/Überprüfung
X: Gesamtverantwortung (D/E/K)
Projektleiter
Externer Berater
Prozessexperten
Methodenexperten
Systemanbieter
Lenkungskreis
Anwendungsfälle definieren (P3.1.1) X M,K M,K M M I
Datenmodell spezifizieren (P3.1.2) X M,K M,K M M I
Dialogdesign entwerfen (P3.1.3) X M,K M,K M M I
Schnittstellen definieren (P3.1.4) X M,K M,K M M I
Berechtigungskonzept definieren
(P3.1.5)
X M,KM,KMMI
Tests planen (P3.1.6) X M,K M,K M M,K I
Pflichtenheft erstellen (P3.1.7) X M,K M,K M M,K E
Seite 118 Kapitel 4
kommen. Bei der Dokumentation eines Anwendungsfalls müssen auch
Vorbedingungen, Nachbedingungen, nicht-funktionale Anforderungen und Aus-
nahmen bzw. Fehlersituationen beschrieben werden. Die Dokumentation muss ein-
heitlich strukturiert und methodisch unterstützt durchgeführt werden.
Eingangsgrößen: Sollprozessmodell, Anforderungskatalog, Systeminformatio-
nen, Anwendungsszenarien der Systemauswahl.
Ergebnisse: Vollständig dokumentierte und Prozessen zugeordnete Anwendungs-
fälle.
Beispiel: Der Anwendungsfall „Status eines Dokumentes ändern“ beinhaltet eine
Folge von Aktionen des Benutzers (Metadatensatz des Dokumentes auf-
rufen, Änderung speichern etc.) und des Systems (u.a. Berechtigung zum
Statuswechsel überprüfen). Im Prozess kommt der Anwendungsfall
mehrmals vor, z.B. bei der Neuanlage einer Spezifikation oder dem
durch eine Änderung ausgelösten Erzeugen einer neuen Version einer
technischen Dokumentation.
Aktivität: Datenmodell spezifizieren (P3.1.2)
Beschreibung: Zur Umsetzung der Anwendungsfunktionen im System müssen
auch die darin verwalteten Daten genau beschrieben werden. Im groben Datenmo-
dell, das als Basis für die Systemauswahl (P2) gedient hat, wurden zunächst nur die
Objekte selbst und deren Beziehungen unterneinander beschrieben. Hinzu kom-
men nun sämtliche beschreibenden Attribute der Objekte und die Regeln, denen
die Objekte bzw. einzelne Attribute unterworfen sind. Werden Prozessabläufe
systemtechnisch abgebildet, müssen auch die Prozessobjekte in das Datenmodell
integriert werden. Das Datenmodell muss aufgrund seiner Wichtigkeit für die
Systemanpassung (P3.2) formal spezifiziert werden.
Eingangsgrößen: Sollprozessmodell, Anwendungsfälle, Unternehmensdatenmo-
dell mit Objekten, Beziehungen und Einschänkungen aus Grobkonzeption (P2.1),
Datenmodell des PDM-Systems
Ergebnisse: Detailliertes systemspezifisches Datenmodell.
Beispiel: Im groben Datenmodell wurde lediglich die Existenz eines Objektes
„Spezifikation“ mit einer Beziehung zu einem Objekt „Teil“ definiert.
Zusätzlich wurde festgelegt, dass Spezifikation und Teil jeweils durch
einen eindeutigen Schlüssel identifizierbar sein sollen. In der Feinspezi-
fikation wird nun definiert, dass eine Spezifikation aus einem Metada-
tensatz mit n beschreibenden Attributen und einen dazugehörigen Text-
verarbeitungsdokument besteht. Den Schlüssel bildet eine automatisch
generierte Dokumentennummer. Das im Grobkonzept beschriebene
Integriertes Vorgehensmodell zur Einführung von PDM-Systemen Seite 119
Objekt „Teil“ und die Beziehung zwischen den Objekten wird äquiva-
lent detailliert spezifiziert.
Aktivität: Dialogdesign entwerfen (P3.1.3)
Beschreibung: Der Anwender bedient das System über textuelle und grafische
Eingabemöglichkeiten. Diese so genannte Bedienungsoberfläche soll möglichst
einfach zu verstehen sein. Die benötigten Anwendungsfunktionen müssen schnell
gefunden werden und notwendige Eingaben selbsterklärend sein. Davon hängt in
hohem Maße die Akzeptanz des Systems bei den Benutzern ab. Die Benutzungs-
oberfläche ist bei Nutzung eines kommerziellen PDM-Systems meist nicht völlig
frei zu entwerfen. Man unterliegt den Einschränkungen, die durch die Anpassungs-
möglichkeiten des Systems gegeben sind. Falls im Unternehmen vorhanden, müs-
sen Vorschriften zum Corporate Design (z.B. Nutzung von Farben und Logos)
berücksichtigt werden. Außerdem existieren je nach Standort des Unternehmens
gesetzliche Bestimmungen für die ergonomische Gestaltung von Bildschirmar-
beitsplätzen12. Das Ergebnis der Aktivität sind nicht die vollständigen einzelnen
Dialoge, sondern Vorgaben in Bezug auf Bildschirmaufbau, Menues etc., die bei
Gestaltung der Dialoge während der Systemanpassung (P3.2) zu beachten sind.
Eingangsgrößen: Sollprozessmodell, Anwendungsfälle, Vorgaben Corporate
Design, Möglichkeiten des PDM-Systems, gesetzliche Bestimmungen.
Ergebnisse: Dialogdesign.
Aktivität: Schnittstellen definieren (P3.1.4)
Beschreibung: PDM-Systeme dienen als Integrationsplattform. Den Schnittstellen
kommt daher eine besondere Bedeutung zu. Es muss definiert werden, welche
Daten zwischen den Systemen ausgetauscht werden, welches System dabei das
führende ist und welche systemübergreifenden Funktionen benötigt werden. Wich-
tig ist auch die Art der Schnittstelle, z.B. als Onlineschnittstelle. Dies ist stark von
den Möglichkeiten der zu verbindenden Systeme abhängig.
Eingangsgrößen: Sollprozessmodell, Anwendungsfälle, Datenmodell, technische
Restriktionen, Ergebnisse der IT-Infrastrukturanalyse, Systeminformationen
(PDM-System und anzuschliessende Systeme).
Ergebnisse: Schnittstellenspezifikationen.
12. Diese sind je nach Staat oder inländisch für Bundesländer bis hinunter zu Städten und Gemein-
den oft unterschiedlich, deshalb wird hier auf eine Aufzählung verzichtet.
Seite 120 Kapitel 4
Aktivität: Berechtigungskonzept definieren (P3.1.5)
Beschreibung: Nicht jeder Anwender darf alle Funktionen des Systems ausführen
oder auf alle Daten zugreifen. Die Regelungen dazu werden im Berechtigungskon-
zept festgelegt. Da eine Festlegung der Berechtigungen für jeden einzelnen
Anwender zu komplex und aufwendig ist, definiert man im System Berechtigungs-
gruppen oder -profile. Berechtigungsgruppen beschreiben einen Satz von System-
funktionen, die in dieser Zusammenstellung immer zusammen an einen Anwender
vergeben werden. Ein Berechtigungsprofil beschreibt alle Funktionen, die ein
Anwender ausführen kann, wenn er eine bestimmte Rolle im Prozess einnimmt. Es
ist zumeist aus mehreren Berechtigungsgruppen und Einzelberechtigungen zusam-
mengesetzt. Rollen können auch eingeschränkt werden, in dem sie z.B. projektbe-
zogen vergeben werden. Die Möglichkeiten dazu hängen von System ab.
Eingangsgrößen: Sollprozessmodell, Anwendungsfälle, Datenmodell, Systemin-
formationen.
Ergebnisse: Berechtigungskonzept.
Beispiel: Das Berechtigungsprofil „CAD-Daten verwalten“ beinhaltet alle Funk-
tionen zum Anlegen, Ändern und Löschen von CAD-Daten. Die Rolle
„Projektleiter“ enthält alle Funktionen des Projektmanagementmoduls
und die Freigabefunktionen des Workflowmoduls. Wird diese Rolle pro-
jektbezogen vergeben, kann der Projektleiter die Funktionen nur auf
Daten ausführen, die seinem Projekt zugeordnet sind.
Aktivität: Tests planen (P3.1.6)
Beschreibung: Um die Funktionsfähigkeit der Systemanpassungen und Program-
mierungen sowie die Erfüllung der Anforderungen zu überprüfen, muss vor Inbe-
triebnahme getestet werden. Mit der systematischen Vorausplanung der Tests wird
gewährleistet, dass zum einen möglichst keine notwendigen Tests vergessen wer-
den und zum anderen die Verantwortlichkeiten für die korrekte und vollständige
Umsetzung der Anforderungen klar definiert sind.
Eingangsgrößen: Sollprozessmodell, Anwendungsfälle, Datenmodell, Berechti-
gungskonzept, Systeminformationen.
Ergebnisse: Testplan mit Definition von Testfällen und Testdaten.
Aktivität: Pflichtenheft erstellen (P3.1.7)
Beschreibung: Die in den vorhergehenden Aktivitäten erarbeiteten Ergebnisse
werden in einem Pflichtenheft zusammengefasst. Das Pflichtenheft dokumentiert
das erwartete Ergebnis der Systemanpassung und dient als vertragliche Basis für
die spätere Abnahme der Ergebnisse der Systemanpassung.
Integriertes Vorgehensmodell zur Einführung von PDM-Systemen Seite 121
Eingangsgrößen: Sollprozessmodell, Anforderungskatalog, Systeminformatio-
nen, Anwendungsfälle, Datenmodell, Dialogdesign, Schnittstellenspezifikationen,
Testplan.
Ergebnisse: Pflichtenheft.
4.5.1.2 Systemanpassung (P3.2)
Die Systemanpassung (P3.2) umfasst alle Schritte zur softwaretechnischen Umset-
zung der im Pflichtenheft definierten Funktionen. Die Art und Weise der Anpas-
sung ist stark abhängig vom verwendeten System. Sie kann vom einfachen Custo-
mizing durch Einstellung einiger Systemparameter über eine Bildschirmmaske bis
hin zu komplexen Programmierungen reichen. Danach richten sich auch die not-
wendigen Aktivitäten. Aus diesem Grund wird an dieser Stelle darauf verzichtet,
einzelne Aktivitäten zu beschreiben, da sie nicht als allgemeingültig oder repräsen-
tativ angesehen werden können. Bei der Einführung muss hier auf die Dokumenta-
tion des ausgewählten Systems zurückgegriffen werden.
Die Zuordnung der Zuständigkeiten für die Systemanpassung (P3.2) zu den betei-
ligten Rollen ist in Tabelle 4-11 dargetellt.
4.5.1.3 Testen (P3.3)
Um die Funktionsfähigkeit der Systemanpassungen und deren Konformität mit den
Anforderungen des Pflichtenhefts nachweisen zu können, müssen sie dokumentiert
und getestet werden. Das Testen (P3.3) ist dabei weniger als geschlossener Ablauf
zu sehen. Sie läuft parallel zur Systemanpassung (P3.2), beginnt aber später, weil
erst nach den ersten Anpassungen getestet werden kann. Die Aktivitäten von
Systemanpassung (P3.2) und Testen (P3.3) sind eng miteinander verzahnt. Im
Prinzip testet ein Entwickler ständig seine speziellen Anpassungen und dokumen-
tiert die Implementierung. Da zumeist mehrere Entwickler an einem System arbei-
ten, muss auch das Zusammenspiel ihrer Anpassungen getestet werden. Zur
Ermittlung der Anwortzeiten des Systems und daraus abgeleiteten programmtech-
nischen Änderungen oder Hardwareaufrüstungen wird auch die Performance des
Tabelle 4-11: Zuständigkeiten in der Systemanpassung (P3.2)
D: Durchführungsverantwortung
M: Mitwirkungspflicht
I: Informationsanspruch
E: Entscheidung
K: Kontrolle/Überprüfung
X: Gesamtverantwortung (D/E/K)
Projektleiter
Externer Berater
Prozessexperten
Methodenexperten
Systemanbieter
Lenkungskreis
Systemanpassung (P3.2) E,K M,K M,K M D I
Seite 122 Kapitel 4
angepassten Systems überprüft. Letztendlich müssen vor einer Produktivsetzung
von Anpassungen auch die Prozesse durchgängig mit allen Anwendungsfunktio-
nen, Schnittstellen etc. getestet werden. Die Durchführung dieses Tests obliegt
Vertretern des Unternehmens, weil hier die vollständigen Anforderungen des
Pflichtenhefts überprüft werden. Daraus resultiert bei positivem Testergebnis auch
die offizielle Abnahme. Bei negativen Testergebnissen wird bei allen Tests jeweils
je nach Fehlerursache in die Feinspezifikation oder die Anpassung zurückgesprun-
gen.
Das Testen (P3.3) beinhaltet daher die folgenden Aktivitäten:
• Komponenten testen (P3.3.1),
• Integrationstests durchführen (P3.3.2),
• Performancetests durchführen (P3.3.3),
• Anwendungstest durchführen (P3.3.4),
• Implementierung dokumentieren (P3.3.5).
Die Zuordnung der Zuständigkeiten für die Aktivitäten zu den beteiligten Rollen
ist in Tabelle 4-12 dargetellt.
Aktivität: Komponenten testen (P3.3.1)
Beschreibung: Aufgrund der modularen Struktur der meisten PDM-Systeme lässt
sich die Systemanpassung zumeist in einzelne Komponenten aufteilen. Diese wer-
den dann auf mehrere Entwickler verteilt umgesetzt. Dabei ist jeder einzelne Ent-
wickler dafür verantwortlich, dass seine Komponenten jede für sich so funktio-
niert, wie sie spezifiziert wurde. Dieses testet er laufend während der Entwicklung
auf seinem Entwicklungssystem.
Tabelle 4-12: Zuständigkeiten der Aktivitäten des Testens (P3.3)
D: Durchführungsverantwortung
M: Mitwirkungspflicht
I: Informationsanspruch
E: Entscheidung
K: Kontrolle/Überprüfung
X: Gesamtverantwortung (D/E/K)
Projektleiter
Externer Berater
Prozessexperten
Methodenexperten
Systemanbieter
Lenkungskreis
Komponenten testen (P3.3.1) E,K K M,K M,K D I
Integrationstests durchführen (P3.3.2) E,K K M,K M,K D I
Performancetests durchführen (P3.3.3) E,K K M,K M,K D I
Anwendungstest durchführen (P3.3.4) D,K K D M,K M E
Implementierung dokumentieren (P3.3.5) D,K K M,K M,K D
Integriertes Vorgehensmodell zur Einführung von PDM-Systemen Seite 123
Eingangsgrößen: Pflichtenheft, programmierte Komponente, Dialogmasken,
Testplan, Testdaten.
Ergebnisse: Getestete Komponenten.
Aktivität: Integrationstests durchführen (P3.3.2)
Beschreibung: Um das technische und funktionale Zusammenspiel zwischen ein-
zelnen Komponenten zu gewährleisten, muss auch dieses getestet werden. Das
geschieht in den Integrationstests (P3.3.2). Bei auftretenden Fehlern muss geklärt
werden, welche Komponente für den Fehler verantwortlich ist. Diese wird dann
neu angepasst und nach erneutem erfolgreichen Komponententest wieder in den
Integrationstest eingeplant.
Eingangsgrößen: Pflichtenheft, getestete Komponenten, Schnittstellen, Testplan,
Testdaten.
Ergebnisse: Funktional und technisch integrationsfähige Komponenten.
Beispiel: Zur Abbildung eines digitalen Freigabeverfahrens für Dokumente ist
eine spezielle Komponente zur Abfrage einer digitalen Signatur inklu-
sive der Anbindung eines Kartenlesers programmiert worden. Im Inte-
grationstest muss das Zusammenspiel der Komponente mit dem für das
Verfahren konzipierten Workflow getestet werden, weil bestimmte
Aktionen und Verzweigungen im Workflow von der Authentifizierung
des Benutzers durch seine Karte abhängen.
Aktivität: Performancetest durchführen (P3.3.3)
Beschreibung: Im Performancetest werden Funktionen ausgeführt und dabei die
Anwortzeiten des Systems gemessen. Dabei kann es sich entweder um einzelne
Aktionen aus einer Bildschirmmaske heraus handeln oder um Tests von Massenda-
tenverarbeitung durch automatisch ablaufende Programme. Werden die erwarteten
Werte nicht erreicht, wird ermittelt, ob die langsamen Zeiten auf die Programmie-
rung oder auf unzureichende technische Ausstattung zurückzuführen sind. Daraus
werden entsprechende Maßnahmen zur Verbesserung abgeleitet.
Eingangsgrößen: Pflichtenheft, getestete und integrationsfähige Komponenten,
Testplan, Testdaten.
Ergebnisse: Messdaten, Maßnahmen zu Programmverbesserungen, Notwendige
Hardwareaufrüstung.
Beispiel: Es wird eine Funktion getestet, die konfigurationsgesteuert aus einer
komplexen Produktstruktur heraus über die Verknüpfungen zu Doku-
menten eine Liste sämtlicher verfügbarer Dokumente zu einer bestimm-
Seite 124 Kapitel 4
ten Konfiguration ableitet. Eine langsame Anwortzeit kann dabei aus
ineffizient umgesetzten Algorithmen, unzureichender softwaretechni-
scher Skalierung des Dokumentenmanagementmoduls oder zu geringer
Speicherausstattung des Servers resultieren.
Aktivität: Anwendungstest durchführen (P3.3.4)
Beschreibung: Die PDM-Einführung beinhaltet nicht nur das PDM-System und
seine Anwendungsfunktionen. Vielmehr ist ein neuer Prozess definiert worden, aus
dem sich Änderungen des Arbeitsinhaltes und der Verantwortung der Anwender
ergeben kann. Erfolgreich ist die Einführung nur dann, wenn Prozess und System
zusammen funktionieren und die Anforderungen erfüllen. Deshalb wird vor Pro-
duktivsetzung abschließend der Anwendungstest durchgeführt. Dabei wird das
komplette Zusammenspiel von Prozess und System mit Produktivdaten und allen
möglichen Ausnahmen von den späteren Anwendern durchgespielt. Soweit mög-
lich findet dieser Test direkt im produktiven System statt. Sind alle Anforderungen
des Pflichtenhefts erfüllt, erfolgt die Abnahme des Systems.
Eingangsgrößen: Pflichtenheft, getestete und integrationsfähige Komponenten,
Testplan.
Ergebnisse: Getestetes und abgenommenes PDM-System.
Aktivität: Implementierung dokumentieren (P3.3.5)
Beschreibung: Um nach der PDM-Einführung Erweiterungen und Fehlerbehe-
bungen auf einer fundierten Informationsbasis durchführen zu können, müssen die
Anpassungen am System und die programmierten Komponenten durch die Ent-
wickler ausführlich dokumentiert werden. Die Dokumentation erfolgt nach einem
einheitlichen Schema meist über Formblätter und über Spezifikationstechniken.
Bei Programmen kann sie durch Kommentare im Quellcode ergänzt werden.
Eingangsgrößen: Pflichtenheft, implementierte Komponenten, implementierte
Integration.
Ergebnisse: Systemdokumentation.
4.5.1.4 Roll-Out(3.4)
Bevor ein angepasstes System tatsächlich in den Produktivbetrieb eingeführt wer-
den kann, müssen die Rahmenbedingungen für die Nutzung des Systems geschaf-
fen werden. Dazu gehört die technische Einrichtung des Systems, die Vorbereitung
der Anwender und die Überführung von Daten aus den auslaufenden Systemen in
das PDM-System. Einige dieser Aufgaben des Roll-Out (P3.4) können oder müs-
sen dabei schon parallel zur Systemanpassung (P3.3) vorbereitet und durchgeführt
Integriertes Vorgehensmodell zur Einführung von PDM-Systemen Seite 125
werden, um einen verzögerungsfreien, reibungslosen Produktivstart zu gewährlei-
sten. Da ein fehlerhafter Start auch nach umfangreichen Tests nicht ausgeschlossen
werden kann, ist auch ein Rückfallplan zu erarbeiten.
Der Roll-Out (P3.4) beinhaltet daher die folgenden Aktivitäten:
• Hardware beschaffen (P3.4.1),
• Hardware installieren (P3.4.2),
• Schulungsunterlagen erstellen (P3.4.3),
• Schulungen durchführen (P3.4.4),
• Datenmigration durchführen (P3.4.5),
• Produktivstart durchführen(P3.4.6).
Die Zuordnung der Zuständigkeiten für die Aktivitäten zu den beteiligten Rollen
ist in Tabelle 4-13 dargetellt.
Aktivität: Hardware beschaffen (P3.4.1)
Beschreibung: Wird zusätzliche Hardware benötigt, muss diese spätestens zum
Produktivstart verfügbar sein, unter Umständen auch schon für die Durchführung
der Systemanpassung (P3.3), z.B. für die Performancetests (P3.3.3). Da es für
Hardware zum Teil sehr lange Lieferzeiten geben kann, muss die Beschaffung
frühzeitig eingeleitet werden.
Eingangsgrößen: Ergebnisse der IT-Infrastrukturanalyse, Technische Szenarien,
Systeminformationen.
Tabelle 4-13: Zuständigkeiten der Aktivitäten des Roll-Out (P3.4)
D: Durchführungsverantwortung
M: Mitwirkungspflicht
I: Informationsanspruch
E: Entscheidung
K: Kontrolle/Überprüfung
X: Gesamtverantwortung (D/E/K)
Projektleiter
Externer Berater
Prozessexperten
Methodenexperten
Systemadministration
Systemanbieter
Hardware beschaffen (P3.4.1) X M,K M
Hardware installieren (P3.4.2) X M,K M
Schulungsunterlagen erstellen (P3.4.3) X M,K M M,K M
Schulungen durchführen (P3.4.4) X M,K M M
Datenmigration durchführen (P3.4.5) X M,K M M
Produktivstart durchführen (P3.4.6) X M,K M M M
Seite 126 Kapitel 4
Ergebnisse: Gelieferte Hardware.
Aktivität: Hardware installieren (P3.4.2)
Beschreibung: Die Einrichtung der Hardware und die Anbindung an bestehende
Netzwerkstrukturen ist Bestandteil dieser Aktivität.
Eingangsgrößen: Ergebnisse der IT-Infrastrukturanalyse, Technische Szenarien,
Systeminformationen, gelieferte Hardware.
Ergebnisse: Installierte Hardware.
Aktivität: Schulungsunterlagen erstellen (P3.4.3)
Beschreibung: Durch Schulungen sollen die Mitarbeiter des Unternehmens in die
Lage versetzt werden, die definierten Sollprozesse zu verstehen und unterstützt
durch das PDM-System in ihrer täglichen Arbeit umzusetzen. Die Schulungen die-
nen deshalb vor allem dazu, die neuen Prozessabläufe zu vermitteln. Dabei sollte
jeder Mitarbeiter zunächst den Prozess im Ganzen verstehen. Aus der Definition
des Prozesses ergeben sich auch die Rollen, die die Mitarbeiter auszuführen haben
und in denen sie durch das PDM-System unterstützt werden. In welchen System-
funktionen sie dann im Detail geschult werden, wird aus diesen Rollen abgeleitet.
War ein Alt-System vorhanden und wurden daraus Altdaten migriert, muss auch
geschult werden, wie die Altdaten im neuen Datenmodell abgebildet sind.
Für die Ableitung der Rollen aus den Prozessen und die Zuordnung der betroffenen
Mitarbeiter zu den Schulungen kann im Prinzip das gleiche Verfahren angewandt
werden, wie für die profilbasierte Bestimmung des Qualifizierungsbedarfes von
Projektmitarbeitern, wie es in Kapitel 5.2 näher beschrieben wird. Die Aktivität
entspricht demnach der mittelfristigen qualitativen Personalentwicklungsplanung.
Zusätzlich wird auf Basis der Schulungsunterlagen die Anwendungsdokumenta-
tion in Form von rollenbasierten Benutzungshandbüchern erstellt, aus der der
Anwender im laufenden Betrieb Hilfe erhalten kann. Diese kann sowohl in Form
von gedruckten oder digitalen Dokumenten als auch integriert in die Hilfe-Funk-
tionen des Systems erstellt werden.
Eingangsgrößen: Pflichtenheft (vor allem Sollprozessmodell), Systeminformatio-
nen, Prototypen, Mitarbeiterinformationen.
Ergebnisse: Schulungsunterlagen, Rollenbasierter Schulungsplan, Anwendungs-
dokumentation (Benutzungshandbücher).
Beispiel: Alle Mitarbeiter erhalten eine Schulung über den gesamten Prozess und
die darin enhaltenen Aufgaben und Rollen. Danach werden rollenba-
sierte Schulungen durchgeführt. Ein Programmmanager erhält ledig-
lich eine Schulung über die Durchführung von Freigaben mittels Work-
Integriertes Vorgehensmodell zur Einführung von PDM-Systemen Seite 127
flow und das Betrachten von Zeichungen mittels Viewing. Der
CAD-Konstrukteur wird in der Bedienung der CAD-Schnittstelle und
der Erstellung von Stücklisten geschult usw.
Aktivität: Schulungen durchführen (P3.4.4)
Beschreibung: Bei umfassender Einführung eines PDM-Systems sind zumeist
sehr viele Unternehmensbereiche und Mitarbeiter betroffen. Die Durchführung der
Schulungen für die Anwender muss deshalb frühzeitig beginnen, um sie rechtzeitig
zum Produktivstart abgeschlossen zu haben. Die Schulungen sollen nicht am Stan-
dard- sondern am angepassten System erfolgen. Erhöhte Akzeptanz wird erreicht,
in dem die Schulungen von Mitarbeitern des Unternehmens durchgeführt werden,
die selbst später in den gleichen Rollen und z.T. in den gleichen Abteilungen wie
die Schulungsteilnehmer mit dem System arbeiten. Diese Mitarbeiter, die meistens
schon als Projektmitarbeiter in der PDM-Einführung mitgearbeitet haben, stehen
dann auch hinterher während des Betriebes als Ansprechpartner („Key-User“) zur
Verfügung (siehe Kapitel 4.6.2).
Eingangsgrößen: Schulungsunterlagen, Mitarbeiterinformationen.
Ergebnisse: Geschulte Mitarbeiter.
Aktivität: Datenmigration durchführen (P3.4.5)
Beschreibung: Vielfach müssen Daten aus alten Systemen in das neue
PDM-System übernommen werden. Da dies selten eins-zu-eins möglich ist,
besteht die Aktivität dabei aus drei Hauptschritten: Daten im alten System vorbe-
reiten, Daten übertragen, Daten im neuen System nachbearbeiten. Insbesondere für
die Vor- und Nachbereitung sind zumeist erhebliche Aufwände nötig, die oft
unterschätzt werden.
Eingangsgrößen: Pflichtenheft, Datenmodell, Schnittstellen.
Ergebnisse: Daten im PDM-System.
Aktivität: Produktivstart durchführen (P3.4.6)
Beschreibung: Sind alle inhaltlichen, qualitätstechnischen und sonstigen vorberei-
tenden Tätigkeiten abgeschlossen, kann das System in den operativen Betrieb
überführt werden. Dabei sind unter anderem folgenden Punkte zu beachten:
Der Produktivstart ist zumeist nicht per Knopfdruck auf einen Schlag durchführ-
bar. Bei großen Projekten mit mehreren hundert Anwendern kann allein die Install-
tion der benötigten Client-Software auf den Rechnern der Anwender mehrere Tage
dauern. Während dieser Zeit könne einige Anwender schon mit dem System arbei-
Seite 128 Kapitel 4
ten, andere nicht. Es muss also mit einer Übergangsphase gerechnet werden, in der
klare Regeln für die Benutzung von altem und neuem System eingehalten werden
müssen.
Zu Beginn der Anwendung ist die Belastung von Netzwerk und Hardware mei-
stens höher, als für den normalen Betrieb geplant, weil zunächst alle Anwender
öfter und mehr mit dem System arbeiten. Dadurch sinkt die Performance des
Systems, was gleich zu Beginn der Nutzung die Zustimmung zum System unter-
graben kann.
Die Produktivsetzung des neuen Systems geht außerdem selten reibungslos von-
statten. Meistens lassen sich erkannte Fehler schnell und ohne größere Einschrän-
kungen des Unternehmens abstellen. Im schlimmsten Fall kann aber das System
wegen unerkannter Fehler vollständig ausfallen oder zumindest soweit funktions-
untüchtig sein, dass der Betrieb leidet. Für diese Fälle muss ein Rückfallplan exi-
stieren. Dieser beschreibt, unter welchen Umständen mit dem neuen System noch
weitergearbeitet werden kann und wann zurückgeschaltet werden soll, um den
Betrieb mit den alten Systemen aufrecht zu erhalten. Es ist auch der Zeitpunkt zu
bestimmen, ab wann ein Zurückschalten nicht mehr möglich ist, z.B. weil schon zu
viele neue Daten im neuen System angelegt wurden.
Eingangsgrößen: Pflichtenheft, Systeminformationen.
Ergebnisse: Produktives System, Rückfallplan.
4.5.1.5 Projektmanagement (P3.5)
Aufgrund der vielfältigen, zum Teil sehr speziellen Aufgaben der Systemeinfüh-
rung, wie sie in den vorhergehenden Kapiteln erläutert wurden, wächst auch das
Projektteam stark an. Es kommen immer mehr Anwender hinzu, um die Anforde-
rungen zu definieren. Außerdem werden für die Aktivitäten vermehrt Spezialisten
benötigt. Deshalb wächst der administrative Aufwand hier im Vergleich zu den
vorangegangen Projekten noch einmal an. Es müssen Maßnahmen getroffen wer-
den, um einheitliche Vorgehensweisen und gleichbleibende Qualität in den Teil-
projekten zu gewährleisten.
Hinzu kommt, dass die PDM-Einführung, wie an verschiedenen Stellen eingehend
erläutert, keine reine Systemeinführung ist, sondern auch einen großen Wandel in
den Arbeits- und Denkweisen beinhaltet. Bei der Produktivsetzung des Systems
müssen die Mitarbeiter diesen Wandel verstanden und so weit wie möglich vollzo-
gen haben.
Im Projektmanagement der Systemeinführung (P3.5) spielen deshalb die folgen-
den zusätzlichen Aktivitäten eine besondere Rolle:
• Change Management (P3.5.1),
Integriertes Vorgehensmodell zur Einführung von PDM-Systemen Seite 129
• Qualitätsmanagement (P3.5.2),
• Dokumenten- und Softwarekonfigurationsmanagement (P3.5.3).
Dabei handelt es sich im Gegensatz zu den bisher beschriebenen Aktivitäten nicht
um abgeschlossene Phasen mit definierten Eingangsgrößen und Ergebnissen. Die
Aktivitäten setzen sich eher aus einer Vielzahl von Tätigkeiten zusammen, die zum
Teil begleitend in den inhaltlichen Phasen von der Feinspezifikation (P3.1) bis
zum Roll-Out(3.4) durchgeführt werden bzw. übergreifend in der Projektdurchfüh-
rung angesiedelt sind. Die Zuordnung der Zuständigkeiten für die Aktivitäten zu
den beteiligten Rollen ist in Tabelle 4-14 dargetellt.
Aktivität: Change Management (P3.5.1)
Die erforderlichen Veränderungen der Denk- und Arbeitsweisen durch PDM erfor-
dern während der Einführung besondere Beachtung. Je größer der zu vollziehende
Wandel, desto schwieriger ist es, die aus dem Wandel resultierenden Ängste der
Mitarbeiter zu zerstreuen13.
Werden die Vorbehalte nicht beseitigt, resultiert dies zumeist in einer Ablehnung
des PDM-Systems und führt zum Teil zum stillen Boykott der Nutzung. Damit
kann der gewünschte Nutzen nicht realisiert werden. Vielfach wird deshalb auch
vom so genannten Akzeptanzmanagement gesprochen. Ist das System bei Einfüh-
rung akzeptiert, ist das aber meistens nicht ausreichend. Die Erfahrung zeigt, dass
sich Fehler und Unzulänglichkeiten zum Produktivstart nicht vermeiden lassen.
Die Akzeptanz schlägt dann schnell wieder in Ablehnung um (siehe Bild 4-10).
Ziel des Change Managements muss es deshalb sein, eine möglichst hohe Zustim-
mung zur PDM-Einführung zu erreichen, um bei Rückschlägen im Akzeptanzbe-
reich zu bleiben.
Tabelle 4-14: Zuständigkeiten der begleitenden Aktivitäten des
Projektmanagements (P3.5)
D: Durchführungsverantwortung
M: Mitwirkungspflicht
I: Informationsanspruch
E: Entscheidung
K: Kontrolle/Überprüfung
X: Gesamtverantwortung (D/E/K)
Projektleiter
Externer Berater
Prozessexperten
Methodenexperten
Systemanbieter
Lenkungskreis
Change Management (P3.5.1) M M.K M X
Qualitätsmanagement (P3.5.2) X M,K M M,K M
Dokumenten- und Softwarekonfigurati-
onsmanagement (P3.5.3)
XM,KM
13. Zur ausführlichen Darstellung des Problems siehe Kapitel 2.1.1.1.
Seite 130 Kapitel 4
Während der Voranalyse (P1) ist in der Aktivität Veränderungsgrad analysieren
(P1.2.5) ermittelt worden, inwieweit die geforderten Paradigmenwechsel bereits
umgesetzt sind. Um beim Produktivstart des Systems die entsprechende vollstän-
dige Basis zu haben, ist es Aufgabe des Change Managements, die noch nicht voll-
zogenen Paradigmenwechsel einzuleiten. Dazu dient in erster Linie eine umfas-
sende Information aller Mitarbeiter über Art und Nutzen der Veränderungen und
die Folgen für die tägliche Arbeit. Dies kann zunächst durch Informationsveran-
staltungen im Rahmen der Projektkommunikation geschehen. Im späteren Verlauf
werden die Informationen in den Prozessschulungen des Roll-Out(3.4) wiederholt.
Wichtig ist dabei auch die Unterstützung der Mitglieder des Lenkungskreises, um
die unternehmenspolitische bzw. strategische Dimension der PDM-Einführung
deutlich zu machen. Es ist dehalb möglich, für diese Aktivität auch die Durchfüh-
rungsverantwortlichkeit an den Lenkungskreis zu übertragen (siehe Tabelle 4-14).
Eine weitere Maßnahme zur Reduzierung von Unsicherheit ist die Beteiligung der
späteren Anwender am Projektgeschehen. Mitarbeiter aus allen betroffenen Unter-
nehmensbereichen definieren zum Teil selbst in den Fachteams die Anforderungen
und testen das System vor dem Produktivstart. Diese so genannten Key-User
haben zusätzlich im Rahmen des Change Managements (P3.5.1) die Aufgabe, in
Bild 4-10: Vor der Produktivsetzung des Systems muss eine Zustimmung erzeugt
werden, um für den Betrieb eine Akzeptanz zu sichern
S
ystem-
einschätzung
Einführungs-
zeit
Akzeptanz
Zustimmung
Ablehnung
Produktiv-
setzung
Akzeptanz bei Produktivsetzung
Zustimmung bei Produktivsetzung
Integriertes Vorgehensmodell zur Einführung von PDM-Systemen Seite 131
ihren Abteilungen laufend über die PDM-Einführung zu informieren. Außerdem
sollen sie als Sprachrohr die Wünsche und Forderungen ihrer Kollegen in die Kon-
zeption einfliessen lassen. Nach Produktivstart sind sie die ersten Ansprechpartner
bei Problemen in ihren Bereichen (siehe Aktivität: Anwenderunterstützung in
Kapitel 4.6.2).
Aktivität: Qualitätsmanagement (P3.5.2)
Neben Einhaltung von Kosten und Terminen wird der Erfolg der PDM-Einführung
auch an der Qualität der Ergebnisse gemessen. Die Qualität wird dabei durch viele
Faktoren definiert, z.B. die Vollständigkeit, die Bedienbarkeit u.a. Welche Fakto-
ren herangezogen werden, ist nicht bei allen PDM-Einführungen gleich. Das Qua-
litätsmanagement (P3.5.2) hat die Aufgabe, die Vorgaben für die Qualität zu
machen, während der Einführung ihre Erreichung zu gewährleisten und am Ende
zu bestätigen.
Die Vorgabe eines strukturierten Vorgehens durch dieses Modell und die Anwen-
dung von Methoden sind so gesehen schon an sich Bestandteile eines Qualitätsma-
nagements. Im Sinne einer Qualitätsvorausplanung gehört das Risikomanagement
als Tätigkeit des allgemeinen Projektmanagements ebenfalls dazu. Im speziellen
sind die Aktivitäten des Testens (P3.3) Teil des Qualitätsmanagements (P3.5.2).
Da ein hoher Ausbildungsstand der Mitarbeiter Qualität fördert, sind auch die Qua-
lifizierungsmaßnahmen für die Projektmitarbeiter dem Qualitätsmanagement
(P3.5.2) zuzuordnen.
Aktivität: Dokumenten- und Softwarekonfigurationsmanagement (P3.5.3)
In der Systemeinführung (P3) entstehen vor allem Dokumente und Softwarebau-
steine. Die Erstellung erfolgt dabei dezentral. Ohne einheitliche Regeln für die
Erstellung, Verwaltung und Verwendung dieser Bausteine kann es zu erheblichen
Problemen kommen, z.B. wenn unfertige Versionen von Softwarekomponenten
getestet werden oder eine falsche Spezifikation zur Erstellung einer Softwarekom-
ponente verwendet wird. Im Prinzip gilt hier die gleiche Problematik der Datenhal-
tung, aus der heraus das PDM-Konzept entstanden ist (siehe Kapitel 2.1). Es müs-
sen also ähnliche Mechanismen zur Vermeidung von Fehlern angewandt werden.
Das Dokumenten- und Softwarekonfigurationsmanagement beinhaltet deshalb fol-
gende Maßnahmen:
• Bereitstellung von einheitlichen Dokumentenvorlagen und Softwaretemplates,
• Datenverwaltungskonzept (Speicherung, Namenskonventionen etc.),
• Berechtigungskonzept,
• Änderungsmanagement und Freigabewesen sowie
Seite 132 Kapitel 4
• Konfigurationsmanagement.
Sind der Umfang des Projektes und die Menge der erstellten Dokumente und Soft-
warebausteine sehr groß, ist es sinnvoll, diese Maßnahmen durch ein Dokumenten-
managementsystem und ein Softwarekonfigurationsmanagementsystem zu unter-
stützen.
4.5.2 Projektorganisation
Die Projektorganisation der Systemeinführung (P3) ist in Bild 4-11 dargestellt.
Der Lenkungskreis entspricht in seiner Zusammensetzung dem der Systemaus-
wahl (P2) inklusive des Vertreters des Systemanbieters. Zusätzlich zu den Aufga-
ben als Kontroll- und Entscheidungsgremium haben die Mitglieder des Lenkungs-
kreis die Aufgabe, in den von ihnen verantworteten Unternehmensbereichen das
Change Management zu unterstützen.
Die Projektleitung wird von einem internen und einem Vertreter des Systeman-
bieters gebildet. Ist das PDM-Know-how im Unternehmen noch nicht ausgeprägt
genug, ist es sinnvoll, zusätzlich einen systemunabhängigen externen Projektleiter
hinzuzuziehen, um eine fachkundige, neutrale Beurteilung der Ergebnisse zu
gewährleisten. Je nach Größe des Projektes und Qualifikation der Projektleiter
kann eine Trennung zwischen technischer und organisatorischer Projektleitung
Bild 4-11: Projektorganisation in der Systemeinführung
Integriertes Vorgehensmodell zur Einführung von PDM-Systemen Seite 133
vorgenommen werden. In den meisten Fällen ist diese Trennung in den Rollen der
zentralen Projektleitung (organisatorisch) und Teilprojektleitung (technisch) ver-
ankert.
Das Projektmanagementteam muss in der Systemeinführung (P3) einen Teil der
in Kapitel 4.5.1.5 beschriebenen begleitenden Aufgaben verantwortlich durchfüh-
ren oder koordinieren. Deshalb wird es durch einen Qualitäts- und einen Konfigu-
rationsmanagementbeauftragten ergänzt. Zusätzlich wird die Projektkommunika-
tion verstärkt.
Der Integrationskreis stimmt die Spezifikationen und Implementierungen parallel
laufender IT-Projekte ab. Er initiiert, wenn notwendig, die Implementierung von
Schnittstellen und Integrationstests zwischen den Systemen.
Auf interner Seite der Fachteams sind in der Systemeinführung (P3) vor allem
Mitarbeiter vertreten, die in ihrer Funktion später als Anwender das PDM-System
bedienen müssen. Ergänzt werden sie durch Experten der unternehmenseigenen
IT-Funktionen, die die Einrichtung von Hardware, Software und Netzwerk
betreuen. Auf externer Seite wird das Projektteam vor allem durch Implememen-
tierer des Systemanbieters gestellt. Systemunabhängige PDM-Berater und Metho-
denexperten begleiten vor allem die Feinspezifikation (P3.2) und das Testen
(P3.3). Da die technische Einrichtung und die Schulungen begleitend und fachge-
bietsübergreifend vorbereitet werden, sind dazu eigene Teams zu bilden.
Die Abstimmung der Arbeitsergebnisse zwischen den Teilprojekten ist Aufgabe
des Kernteams, das hier durch die Teilprojektleiter und die Prozessbesitzer (siehe
Kapitel 4.4.1.5) gebildet wird. Zusätzlich sollten bei sehr großen Projekten aus den
jeweiligen Experten der einzelnen Fachteams aufgabenbezogene Integrations-
teams gebildet werden, die die Arbeiten und Ergebnisse der Fachteams koordinie-
ren.
4.6 Tätigkeiten nach der PDM-Einführung
Nach der Fertigstellung des ersten Release wird das PDM-System in den dort
umgesetzten Sollprozessen und mit den realisierten Anwendungsfunktionen im
Unternehmen produktiv eingesetzt. Wie in Kapitel 4.2 beschrieben, ergeben sich
dabei zwei Aufgaben, die strategische Kontrolle und der operative Betrieb, die im
Folgenden erläutert werden.
4.6.1 Strategische Kontrolle
Mit der Umsetzung von PDM soll ein zu Beginn der Einführung definierter Nutzen
erzielt werden. Dieser entsteht nicht bei der Einführung oder der Produktivsetzung
sondern während der Nutzung des Systems im produktiven Betrieb. Um den Erfolg
der PDM-Einführung also letztendlich festzustellen, werden bei der strategischen
Seite 134 Kapitel 4
Kontrolle die in der Vorstudie (P1) definierten Kennzahlen laufend gemessen und
mit den ebenfalls dort festgesetzten Sollwerten verglichen. Bei Abweichungen
sind die Gründe dafür zu prüfen und Maßnahmen zu ergreifen. Dazu zählen eine
weitere Anpassung von Prozessen und System oder die Festlegung neuer Sollkenn-
werte. Bei starken Abweichungen oder sogar Verschlechterungen der Kennzahlen
sind die letzten Konsequenzen die Abschaltung des Systems und ein Rückschritt
auf die alten Prozesse.
Beispiel: Als Ziel für die PDM-Einführung ist eine Durchlaufzeitverkürzung der
Bearbeitung eines Angebots von der Anfrage bis zur Abgabe definiert
worden. Der Prozess soll sich um 25% verkürzen. Nach der PDM-Ein-
führung wird eine Verkürzung von lediglich 10% ermittelt. Es wird nun
geprüft, ob die umgesetzte Systemlösung fehlerhaft ist, oder ob sich evtl.
Rahmenbedingungen des Prozesses geändert haben, die dazu führen,
dass das ursprüngliche Ziel nicht mehr erreicht werden kann. Es stellt
sich heraus, dass ein Fehler im Workflow die Verkürzung einschränkt.
Daraus ergibt sich die Maßnahme, den Workflow noch einmal zu über-
arbeiten.
4.6.2 Operativer Betrieb
Nach Produktivsetzung wird das PDM-System von den Anwendern im Tagesge-
schäft genutzt. Dazu ist begleitend eine Betreuung von System und Anwendern
notwendig, um Probleme, Fehler, Fragen und Verbesserungsvorschläge bearbeiten
zu können. Der operative Betrieb beinhaltet die folgenden Aktivitäten:
• Monitoring,
• Anwenderunterstützung,
• Technischer Support,
• Change Board14,
• Schulung neuer Anwender.
Die Zuordnung der Zuständigkeiten für die Aktivitäten zu den beteiligten Rollen
ist in Tabelle 4-15 dargestellt. Solange parallel noch weitere Releases eingeführt
werden, wird ein Teil der Aktivitäten vom Projektteam mitveranwortet. Später
müssen eigene Gremien dafür geschaffen werden. Der Support durch den Herstel-
ler ist im Betrieb für alle Aktivitäten die letzte Eskalationsstufe, d.h. wenn die
unternehmenseigenen Supportkräfte ein Problem nicht lösen können, wird dieses
an den Hersteller zur Lösung weitergeleitet. Der Kontakt geschieht immer durch
die Supportstruktur des Unternehmens und nicht durch den Anwender selbst.
14. Change Board = Änderungsgremium.
Integriertes Vorgehensmodell zur Einführung von PDM-Systemen Seite 135
Aktivität: Monitoring
Das System muss im laufenden Betrieb ständig überwacht werden, um Ausfälle
oder Fehlfunktionen frühzeitig zu erkennen und zu beheben. Das bezieht sich
sowohl auf die rein technische Funktionsfähigkeit der Hardware, der Software und
des Netzwerkes als auch auf die Überwachung der Prozesse und Schnittstellen und
die Erhaltung der Datenqualität.
Die technische Überwachung unterscheidet sich im Wesentlichen nicht von der
anderer Systeme und wird durch die Systemadministration vorgenommen. Mit
Hilfe von speziellen Funktionen des PDM-Systems muss vor allem die vollstän-
dige Ausführung von Workflows und die Funktion von Schnittstellen überwacht
werden. Dies wird zumeist von speziell geschulten Key-Usern durchgeführt. Zur
Überprüfung der Datenqualität werden regelmäßig Berichte erstellt, aus denen feh-
lerhafte und unvollständige Daten zu erkennen sind.
Aktivität: Anwenderunterstützung
Die Anwender benötigen im Tagesgeschäft Ansprechpartner für Fragen und Pro-
bleme. Diese Unterstützung wird abhängig von der Art der Probleme mehrstufig
gewährleistet.
Einfache Probleme in der Bedienung der Anwendung oder Fragen zu Anwen-
dungsfunktionen werden in den Unternehmensbereichen von den Key Usern bear-
beitet. Hat das Unternehmen einen eigenen User Help Desk, sollte auch dieser in
der Lage sein, diese Probleme zu lösen.
Tabelle 4-15: Zuständigkeiten der Aktivitäten des operativen Betriebs
D: Durchführungsverantwortung
M: Mitwirkungspflicht
I: Informationsanspruch
E: Entscheidung
K: Kontrolle/Überprüfung
X: Gesamtverantwortung (D/E/K)
Projektleitung
Prozessexperten
Key User
Systemadministration
Hotline
Monitoring X M
Anwenderunterstützung X M M
Technischer Support X
Change Board X M,K M
Schulung neuer Anwender X M
Seite 136 Kapitel 4
Treten Probleme technischer Art oder Unklarheiten auf, die nicht vor Ort von den
Key Usern gelöst werden können, werden diese auch über den User Help Desk
gemeldet. Dieser leitet die Meldung an die zuständige Stelle weiter. Dies ist bei
technischen Problemen die Systemadministration (siehe Aktivität: Technischer
Support). Bei Anwendungsproblemen findet die Unterstützung durch Fachbetreuer
statt. Diese sind entweder selbst vom Unternehmen aufgebaut oder werden vom
Systemanbieter als Dienstleistung zur Verfügung gestellt. Laufen im Unternehmen
noch Projekte für weitere Releases, kann die Fachbetreuung auch durch das Pro-
jektteam übernommen werden.
Aktivität: Technischer Support
Die Aufgabe des technischen Supports ist die Sicherstellung der durchgängigen
Verfügbarkeit und Sicherheit des PDM-Systems. Dazu zählen zum einen die
Betreuung von Hardware und Netzwerk und zum anderen die Datensicherung. Da
ein unterbrechungsfreier Betrieb für eine so wichtige Anwendung, wie das
PDM-System von entscheidender Bedeutung ist, sollte deshalb der technische
Support direkt im Unternehmen angesiedelt werden. Im Roll-Out des Projektes
müssen die notwendigen Maßnahmen dazu eingeplant und die Mitarbeiter qualifi-
ziert werden.
Aktivität: Change Board
Erfordert eine Meldung eine Änderung der Prozesse oder des Systems, muss durch
das so genannte Change Board entschieden werden, ob die Änderung durchgeführt
wird oder nicht. Dazu wird die Meldung zunächst durch die Fachbetreuung klassi-
fiziert. Handelt es sich um einen Fehler, der die Funktionstüchtigkeit von Prozess
oder System beeinträchtigt, wird dieser sofort behoben. Handelt es sich um eine
neue Anforderung oder einen Verbesserungsvorschlag, müssen diese zunächst vom
Anwender begründet werden. Die Fachbetreuung bewertet sie auf Basis des erwar-
teten Nutzens und des geschätzten Aufwandes. Das Change Board entscheidet dar-
aufhin über die Umsetzung. Es entspricht somit in der Funktion einem Lenkungs-
kreis für den operativen Betrieb.
Sind parallel zum Betrieb noch Releaseprojekte in der Einführung, wird die Beur-
teilung durch die Projektleitung und das Kernteam und die Entscheidung durch den
Lenkungskreis der laufenden PDM-Einführung übernommen. Dabei kann berück-
sichtigt werden, ob die durch die Meldung neu geäußerte Anforderung durch das
nächste Release abgedeckt ist oder mit in die Releaseplanung aufgenommen wer-
den kann.
Integriertes Vorgehensmodell zur Einführung von PDM-Systemen Seite 137
Aktivität: Schulung neuer Anwender
Während der Systemeinführung (P3) sind alle betroffenen Anwender geschult
worden. Im Betrieb kann jetzt durch Neueinstellungen oder Versetzungen von Mit-
arbeitern sowie durch Ausweitung des Einsatzbereiches des PDM-Systems erneut
Schulungsbedarf entstehen. Deshalb werden die rollenbezogenen Schulungen in
den Schulungskatalog der Mitarbeiterweiterbildung des Unternehmens aufgenom-
men. Auch hier sind sowohl die Prozesse als auch die angepassten Systemfunktio-
nen zu schulen.
4.7 Methoden
Die Aktivitäten des Vorgehensmodells beschreiben auführlich, in welcher Reihen-
folge welche Tätigkeiten bei der PDM-Einführung auszuführen sind. Zusätzlich
beinhaltet die Beschreibung, welche Eingangsgrößen zur Ausführung der Aktivitä-
ten notwendig sind, welche Ergebnisse erzeugt werden und wer welche Verant-
wortung bei der Ausführung trägt. Die Methoden vervollständigen das Vorgehens-
modell dahin, dass sie vorgeben, mit welchen Mitteln die Tätigkeiten auszuführen
sind und in welcher Form die Ergebnisse vorliegen.
Der Methodeneinsatz basiert im Kern auf vier Grundmethoden:
• Objektorientierte Methode zur Geschäftsprozessmodellierung und -analyse
(OMEGA),
• Prototyping,
• Best Practices sowie
• Unified Software Development Process.
Der Einsatz über die Phasen und das Zusammenspiel dieser Methoden ist als
Methodenlandkarte in Bild 4-12 dargestellt.
Die vorgeschlagenen Methoden sind nicht neu und zumeist nicht speziell für die
PDM-Einführung entwickelt worden. Sie haben aber ihre Tauglichkeit in verschie-
denen vom Autor begleiteten Projekten bewiesen. Wie aus den Anforderungen an
das Vorgehensmodell ersichtlich, kommt der Durchgängigkeit der Methoden eine
besonders hohe Bedeutung zu (siehe Kapitel 2.2.6). Im Folgenden werden die
Methoden selbst deshalb nur kurz mit Hinweis auf weiterführende Literatur
beschrieben. Es wird vielmehr dargestellt, welchen Nutzen die Methoden in der
PDM-Einführung bringen und wie das Zusammenspiel der Methoden funktioniert.
Eine vollständige Übersicht zur Zuordnung der beschriebenen Methoden zu den
einzelnen Aktivitäten des Vorgehensmodells befindet sich in Anhang B.
Seite 138 Kapitel 4
4.7.1 Objektorientierte Methode zur Geschäftsprozessmodellierung
und -analyse (OMEGA)
Die Methode OMEGA wurde am Heinz Nixdorf Institut der Universität Paderborn
entwickelt15. Sie dient grundsätzlich sowohl zur vollständigen Modellierung einer
Ablauforganisation in einem Modell als auch als Instrument zur Analyse und Pla-
nung von Leistungserstellungsprozessen. Eine besondere Stärke liegt dabei in der
anschaulichen Visualisierung. In Bezug auf die PDM-Einführung bietet sich
OMEGA an, weil sie durch ihre Konstrukte (siehe Bild 4-13) über die gesamte
PDM-Einführung als methodische Klammer dienen kann. Außerdem existieren
eine Vielzahl von ergänzenden methodischen Hilfsmitteln zur Unterstützung vor
allem der ersten zwei Projekte, der Vorstudie (P1) und der Systemauswahl (P2).
Die Einbindung der PDM-Einführung in die Unternehmensstrategie in der Phase
der Strategiebindung (P1.1) ist bei OMEGA durch die Integration der Methode in
das Vier-Ebenen-Modell der zukunftsorientierten Unternehmensgestaltung [GF99,
S.65ff] gewährleistet. Die Optimierung der Prozesse durch die PDM-Einführung
stellt im Sinne des Modells den Strategietransfer dar.
Kern der Anwendung von OMEGA ist die Abbildung von Prozessen. Hier kommt
die Methode sowohl bei der Ist-Analyse (P1.2) als auch bei der Erstellung von
Sollprozessen in der Grobkonzeption (P2.1) zur Anwendung. Bei der Ist-Analyse
wird das Prozessmodell durch Datenflussdiagramme nach [GF99, S. 441] ergänzt.
Diese beschreiben die im Prozess enthaltenen Schnittstellen bezogen auf Übertra-
Bild 4-12: Durchgängiger Einsatz von Methoden im Vorgehensmodell zur
PDM-Einführung (Methodenlandkarte)
15. Zur vollständigen Darstellung und Vertiefung siehe [GF99, S. 342ff], [Fah95], [GLS+97].
OMEGA
Prototyping
Best
Practices
Unified
Software
Development
Process
Vorstudie(P1) System-
auswahl(P2)
Systemein-
führung(P3)
Integriertes Vorgehensmodell zur Einführung von PDM-Systemen Seite 139
gungshäufigkeit, Übertragungsmenge, Übertragungsmedium, Datenformat und
erforderliche Nacharbeit (siehe Bild 4-14).
Das OMEGA-Prozessmodell ist in der Ist-Analyse (P1.2) damit Basis der weiteren
Analysen. Die Bearbeitungsobjekte bilden die Elemente des groben Datenmodells.
Die IT-Infrastruktur kann an Hand der im Modell enthaltenen IT-Ressourcen und
den Datenflussdiagrammen beschrieben werden. In der zunächst groben Modellie-
rung der Ist-Analyse (P1.2) sind auch die betroffenen Unternehmensbereiche als
Organisationseinheiten im Prozessmodell enthalten. Bei verfeinerter Modellierung
während der Grobkonzeption (P2.1) werden die Prozesse soweit heruntergebro-
chen, dass durch die Organisationseinheiten des Modells die verschiedenen
Anwenderrollen beschrieben werden. Diese sind später im Roll-Out (P3.4) die
Basis für die rollenbasierten Schulungen.
Die Aktivitäten der Potentialanalyse (P1.3) werden durch die auf OMEGA basie-
rende Methode zur Optimierung von Leistungserstellungsprozessen nach [Lew00]
unterstützt. Diese ermöglicht sowohl die Ermittlung der Schwachstellen und Ver-
besserungspotentiale als auch die Bewertung von alternativen Sollprozessen zur
Behebung der Schwachstellen.
Bei der Bewertung von Systemalternativen während der Systemauswahl (P2) spielt
neben dem rein funktionalen Vergleich vor allem der Nutzen der Gesamtlösung
Bild 4-13: Konstrukte der Methode OMEGA[GF99, S. 342]
Geschäfts-
prozess
Organisationseinheit
Techn.
Ressource
Eingehendes
Bearbeitungs-
objekt
Ausgehendes
Bearbeitungs-
objekt
Ein ist
eine Menge von Aktivitäten
zur Erbringung eines
Ergebnisses (auf beliebigem
hierarchischen Level)
Geschäftsprozess
Bearbeitungsobjekte erfahren in dem
Geschäftsprozess eine Transformation bzw.
werden zu dessen Ausführung benötigt
(Inputobjekte) oder sind Produkte (Ergebnisse)
des Geschäftsprozesses (Outputobjekte)
Papier-
objekt
Info.-
gruppe
mündliche
Information
Material-
objekt
IT-
objekt
Kommunikationsbe-
ziehungen stellen Bezie-
hungen zwischen den
Modellkonstrukten dar
Organisationseinheiten
sind die Objekte der Auf-
bauorganisation in Form
von Stellen, Abteilungen
und Teams. Sie führen
die Geschäftsproz. aus.
Externe Objekte
sind Schnittstellen
zur Modellumwelt,
z.B. Kunden, Lie-
feranten etc.
Papier-
speicher
IT-Appli-
kation
Material-
speicher
Technische Ressourcen
sind IT-Applikationen und
Speicher für Information
und Material
Externes
Objekt
Seite 140 Kapitel 4
aus Prozess und System eine große Rolle. Dies wird in der prozessseitig ebenfalls
OMEGA-basierten Methode zur Nutzenorientierten Planung des Einsatzes von
CAD-/CAE-Systemen nach [Lem01] berücksichtigt.
Während der Systemanpassung (P3) werden die Anwendungsfälle, in denen vor
allem konkrete Systemfunktionen beschrieben werden, durch eine Verknüpfung
mit OMEGA in den Prozesszusammenhang eingeordnet (siehe Kapitel 4.7.4).
Die OMEGA Prozessmodelle dienen im weiteren Verlauf der Einführung zusätz-
lich als Quelle für die Definition von Testabläufen in der Testplanung (P3.1.6), für
die Prozessdokumentation der Anwenderhandbücher sowie für die Schulung der
Prozesse im Roll-Out (P3.4).
OMEGA und OMEGA-basierte Methoden bilden somit die methodische Klammer
über die gesamte PDM-Einführung, vom Beginn der Vorstudie bis zur Produktiv-
setzung am Ende des Roll-Outs.
4.7.2 Prototyping
Die PDM-Einführung zieht nur sehr selten die Neuimplementierung eines
PDM-Systems nach sich, sondern basiert meist auf einem PDM-System als Stan-
dardsoftware. Dieses bringt von Anfang an einen umfangreichen Satz an Funktio-
nen mit. Man kann also frühzeitig auf Basis dieser vorhandenen Funktionen
ablauffähige Anwendungen erstellen, demonstrieren und bewerten. Diese Vorge-
hensweise bezeichnet man als Prototyping [KLS+92]. Man unterscheidet dabei
Bild 4-14: Datenflussdiagramm zur Beschreibung von Schnittstellen (Beispiel)
DTP
CAD 2
PPS
Technische Dokumentation
Werkzeugbau
Arbeitsplanung
mehrmals täglich
täglich
wöchentlich
monatlich Papier
Diskette
UNIX
mit %-Angabe
z.B. IGES
Macintosh
DOS / Windows
automatisch /
online
jährlich
IGES
DXF
CAD 1
Konstruktion
20%
10%
Übertragungshäufigkeit Übertragungsmedium Betriebssystem /
Hardwareplattform
Nacharbeit
Datenformat
Integriertes Vorgehensmodell zur Einführung von PDM-Systemen Seite 141
drei Arten von Prototypen, die während der PDM-Einführung zum Einsatz kom-
men können:
Explorative Prototypen bzw. so genannte Demonstrationsprototypen dienen in der
Vorstudie (P1) sowohl dazu, die Grundlagen und Paradigmen von PDM zu vermit-
teln als auch die Nutzenpotentiale von PDM-Systemen aufzuzeigen. Während der
Systemauswahl (P2) wird zum einen die technische Machbarkeit von Lösungen
der Grobkonzeption überprüft und zum anderen der Benchmark durch Prototypen
der zu untersuchenden Systeme unterstützt. Man bezeichnet diese Art der Prototy-
pen als experimentelle Prototypen. Bei der Systemanpassung (P3) wird das System
gemäß der angewandten Softwareentwicklungssystematik (siehe Kapitel 4.7.4)
nach und nach durch Verfeinerung und Erweiterung der Anpassungen vom
Ursprungssystem zum letzendlich unternehmensspezifischen System ausgebaut.
Diese zyklische Komplettierung des Systems bezeichnet man als evolutionäres
Prototyping.
Zur halbautomatischen Ableitung von Prototypen aus den Prozessspezifikationen
in OMEGA kann das Softwarewerkzeug OMEGAPrestige verwendet werden
[GF99, S. 350f]. Diese basiert auf dem Prinzip der integrierten Prozess- und Pro-
duktmodellierung16, das in Bild 4-15 dargestellt ist.
Bild 4-15: Integrierte Prozess- und Produktdatenmodellierung als Basis für die
Erstellung von experimentellen Prototypen [GGP+97]
16. Siehe dazu [GGP+97], [GGP+98], [GHK+97].
PDM-Server
DB
CAD
FEM
CAE
Seman-
tische und
konzeptionelle Prozess-
und Datenmodellierung
(Generieren der Prozess- und
Datenspezifikationen)
Implementierung der
Prozess- und Datenmodelle in
PDM-Systemen
class Speicher;
subtype of class Techn. Res.;
Kapazität: integer;
end class;
class Materialspeicher;
subtype of class Speicher;
end class;
...
Entwicklung der Prozess- und Produktstruktur-
modelle durch die Phasen:
i) Ist-Erfassung,
ii) Ist-Analyse und
iii) Soll-Konzeption
mittels Geschäftsprozesse,
Kommunikationsobjekte,
Technischen Ressourcen ...
Produktdatenmanagement (PDM)
Semantisches Modell
Formales Modell
Implementierung
Applikation
Material-
speicher
elektr.
Speicher Papierkorb
Technische
Ressource
Speicher
Seite 142 Kapitel 4
4.7.3 Best Practices
In Unternehmen, die mit der PDM-Einführung beginnen, sind zum Teil die Mög-
lichkeiten, die sich damit für Prozesse und Systemunterstützung ergeben, nicht
hinreichend bekannt. Es ist daher in den ersten Phasen der Einführung wichtig, auf
externe Informationen über diese Möglichkeiten zurückzugreifen und darauf auf-
zubauen. Dazu dienen die Best Practices.
Unter Best Practices versteht man Vorgehensweisen, die allgemein anerkannt als
für ihren Anwendungsbereich optimal gelten. Anwendungsbereiche können dabei
Unternehmenfunktionen oder Branchen sein. Zum Teil spricht man auch von so
genannten Referenzmodellen17 [KW98], [KWF00]. Diese sind meist aufgrund
anderer Rahmenbedingungen nicht vollständig im Unternehmen umsetzbar, kön-
nen aber als Leitfaden für Verbesserungen dienen. Die Best Practices unterstützen
daher im integrierten Vorgehensmodell zur PDM-Einführung die Aktivitäten der
Vorstudie (P1) und der Systemauswahl (P2).
In der Vorstudie (P1) dienen die Best Practices sowohl zur Darstellung der allge-
meinen PDM-spezifischen Paradigmen als auch als Vergleichsprozesse bei der
Ermittlung von Verbesserungspotentialen in den Ist-Prozessen. Stellen sich die
Best Practices als anwendbar dar, bilden sie zugleich die Grundlage für die Kon-
zeption der Sollprozesse in der Systemauswahl (P3). Zum Teil existieren auf
Anwendungsebene Best Practices für den Einsatz von Funktionen eines bestimm-
ten Systems. Diese unterstützen dann auch die Spezifikation der Anwendungs-
funktionen und Datenmodelle in der Systemnapassung (P3).
Als Best Practices für die PDM-Einführung können z.B. das STEP PDM-Schema
und die PDM Enablers der OMG verwendet werden18. Das STEP PDM-Schema
basiert allerdings zum größten Teil auf dem Anwendungsprotokoll AP214, das auf
den Prozessen der Automobilindustrie aufbaut und ist deshalb branchenbezogen.
Die PDM Enablers hingegen sind branchenunabhängig. Je nach Branche des ein-
führenden Unternehmens sind die Referenzmodelle deshalb immer kritisch zu hin-
terfragen. Branchenspezifische Best Practices bieten einige Anbieter von
PDM-Systemen auch in Form von vorkonfigurierten Systemen an. Diese sind zur
Systemauswahl und anschließend bei der Anpassuung in Betracht zu ziehen.
4.7.4 Unified Software Development Process
Der Unified Software Development Process (USDP) ist in Kapitel 3.2.2 schon
beschrieben worden. Er unterstützt im Vorgehensmodell zur PDM-Einführung die
Phasen der Systemanpassung (P3) bis in den Betrieb. Die Modelle der UML die-
nen dabei zur Spezifikation der Anforderungen in der Feinspezifikation (P3.1) zur
17. Siehe dazu auch Fußnote in Kapitel 3.1.1.2.
18. Siehe dazu auch Kapitel 3.1.1.2.
Integriertes Vorgehensmodell zur Einführung von PDM-Systemen Seite 143
automatisierten Durchführung der Systemanpassung (P3.2) sowie zur Dokumenta-
tion beim Testen (P3.3). Das Grundprinzip des USDP des inkrementellen und ite-
rativen Vorgehens fügt sich vor allem gut mit dem Ansatz des Prototyping zusam-
men.
Um die Durchgängigkeit der Methoden zu gewährleisten, ist es notwendig, eine
Verbindung von den Prozessmodellen in OMEGA zu den Spezifikationen der
UML zu schaffen.
Die oberste Ebene der Spezifikationstechniken der UML bilden die Use Cases. Sie
beschreiben aus Sicht des Benutzers, welche Funktionen das System bieten soll.
Die Darstellung erfolgt in so genannten Anwendungsfalldiagrammen (siehe Bild
4-16). Der Anwender (Akteur), er entspricht im detaillierten OMEGA-Modell
einer Organisationseinheit, wird in Form eines Strichmännchens dargestellt, die
Anwendungsfälle mit Hilfe von Ellipsen. Anwendungsfälle können durch Eingren-
zung mit einem Kasten und Vergabe eines Diagrammnamens gruppiert werden.
Für die Integration von OMEGA und UML wird die Gruppierung an Hand der
OMEGA-Prozesse vorgenommen. Es existiert eine n-m-Beziehung, d.h. ein
Geschäftprozess aus OMEGA kann mehrere Use Cases beinhalten, ein Use Case
kann aber auch in mehreren Geschäftsprozessen verwendet werden. Die Zuord-
nung geschieht grafisch im OMEGA-Prozessmodell (siehe Bild 4-17). Die Use
Cases wiederum werden dann entsprechend der Methode des USDP an Hand der
weiteren UML-Diagramme19 verfeinert. Die Klassen des Klassendiagramms der
UML werden aus den Bearbeitungsobjekten des OMEGA-Prozessmodells abgelei-
tet.
Bild 4-16: Anwendungsfalldiagramm (Beispiel)
19. Z.B, Kooperationsdiagramm, Sequenzdiagramm, Klassendiagram, Zustandsdiagramm, Vertei-
lungsdiagramm, Komponentenmodell und Testmodell.
Seite 144 Kapitel 4
4.7.5 Programmierschnittstellen
Die Anpassung des Systems geschieht über die systemeigenen Programmier-
schnittstellen. Diese dienen zur Anpassung der Datenmodells, der Definition von
Workflows und Berechtigungen, der Programmierung von unternehmenspezifi-
schen Systemfunktionen sowie zur Anpassung der Benutzungsschnittstelle. Eine
Vereinfachung ergibt sich, wenn es möglich ist, aus den Spezifikationsmodellen
von OMEGA und der UML Teile der Programmierung automatisiert abzuleiten
(siehe Kapitel 4.7.1 und Kapitel 4.7.4).
4.7.6 Weitere Methoden
Zur Unterstützung einzelner Aktivitäten sind die bisher beschriebenen Methoden
zum Teil zu ergänzen. Die entstehenden Ergebnisse sind meist nicht für nachfol-
gende Aktivitäten relevant. Daher spielt der Aspekt der Durchgängigkeit hier eine
untergeordnete Rolle. Die zusätzlichen Methoden und ihre Zuordnung zu den
Aktivitäten können der Tabelle in Anhang B entnommen werden.
Bild 4-17: Zuordnung der UML Use Cases zu OMEGA Prozessen (Beispiel)
Personalplanung und -entwicklung Seite 145
5 Personalplanung und -entwicklung
Das in Kapitel 4 vorgestellte Vorgehensmodell beschreibt die PDM-Einführung an
Hand der durchzuführenden Aktivitäten, den dazu benötigten Eingangsgrößen und
der erzielten Ergebnisse. Außerdem nimmt es eine Zuordnung von Rollen zu den
Aktivitäten vor. Die benannten Rollen sind dabei zunächst in den Zuordnungsta-
bellen nur grob benannt worden. Im Folgenden wird der Bereich der Personalpla-
nung und -entwicklung aufgrund seiner Wichtigkeit für die PDM-Einführung
(siehe Kapitel 2.4) vertieft.
In Kapitel 2.4.1 wurden die Aufgaben der Personalplanung und -entwicklung im
Rahmen der PDM-Einführung in zwei Bereiche unterteilt, die kurzfristigen Aufga-
ben im Rahmen der Projektplanung und die mittelfristigen für die späteren Anwen-
der des PDM-Systems. Die kurzfristige Personalplanung und -entwicklung ist im
Vorgehensmodell zunächst ausgeklammert worden, während die mittelfristigen
Aufgaben weitestgehend enthalten sind. Sie werden aber noch nicht mit Methoden
unterstützt.
Am Beispiel der kurzfristigen Personalplanung und -entwicklung soll im Folgen-
den eine Methode vorgestellt werden, die die definierten Aufgaben adäquat unter-
stützt und damit die größte Lücke bisheriger PDM-Einführungsmodelle (siehe
Kapitel 3.3) schließt.
Die Methode verläuft in drei Schritten (siehe Bild 5-1). Ausgangspunkt ist die
Ableitung von Rollen auf Basis der Aktivitäten des Vorgehensmodells. Dieser
Vorgang wird deshalb als nächstes erläutert und beispielhaft an Hand eines Aus-
schnitts des Vorgehensmodells dargestellt (Kapitel 5.1). Anschließend wird die
Zuordnung interner und externer Projektmitarbeiter zu den Rollen dargestellt
(Kapitel 5.2). Im abschliessenden Kapitel 5.3 wird dann auf den Bereich des Aus-
gleiches von Qualifizierungsdefiziten beschrieben.
5.1 Ableitung von Rollen aus dem integrierten Vorgehensmodell
Eine Rolle ist definiert als eine Aufgabe oder die Zusammenfassung mehrerer Auf-
gaben in einem Projekt. Ein Mitarbeiter kann in einem Projekt je nach Qualifika-
tion und Auslastung eine oder mehrere Rollen einnehmen. Bezogen auf die groben
Rollen aus Kapitel 4 könnte das beispielsweise bedeuten, dass der PDM-Berater
gleichzeitig als Methodenexperte fungiert.
Ziel dieses ersten Schrittes ist es, die Aufgaben des integrierten Vorgehensmodells
zu Rollen zusammenzufassen. Dies geschieht auf Basis der für die Erfüllung der
Aufgaben notwendigen Kompetenzen. Aufgaben, die gleiche Kompetenzen erfor-
dern, können in einer Rolle zusammengefasst werden. Im nachfolgenden Kapitel
wird zunächst erläutert, welche Kompetenzen berücksichtigt werden müssen und
Seite 146 Kapitel 5
wie sie beschrieben werden. Anschließend wird die Zuordnung der Kompetenzen
zu den Aufgaben und die darauf basierende Ableitung der Rollen dargestellt.
5.1.1 Kompetenzen für die PDM-Einführung
Eine Definition des Begriffes Kompetenz ist bereits in Kapitel 2.4.1.1 erfolgt. Es
ist auch festgestellt worden, dass zwei Arten von Kompetenzen bei der PDM-Ein-
führung eine Rolle spielen: die humanorientierten Kompetenzen und die fachli-
chen Kompetenzen. Zur Anwendung in der Methode muss für diese Kompetenzen
eine einheitliche Art der Klassifizierung, Beschreibung und Bewertung gefunden
werden.
5.1.1.1 Humanorientierte Kompetenzen
Es existiert in der Literatur eine Vielzahl von Kriterienkatalogen zur Beschreibung
von humanorientierten Kompetenzen. Für die Durchführung der Methode ist es
zunächst nicht entscheidend, welcher dieser Kataloge verwendet wird. Es ist aber
wichtig, eine einheitliche Definition der humanorientierten Kompetenzen zu ver-
wenden, um eine Vergleichbarkeit der Kompetenzprofile zu gewährleisten. Außer-
dem müssen Kriterien enthalten sein, an Hand derer die Ermittlung sowohl der für
die Aufgabenbewältigung notwendigen als auch der bei den Mitarbeitern vorhan-
denen Kompetenzen möglich ist. Für die Darstellung der vorgestellten Methode
soll deshalb die vom Deutschen Institut für Normung (DIN) herausgegebene Publi-
Bild 5-1: Schritte der Personalplanung und -entwicklung für die PDM-Einfüh-
rung
Personalplanung und -entwicklung Seite 147
kation „Schlüsselqualifikationen in neuen Organisationsformen - Ein Kriterienka-
talog für die Praxis“ [GSE+98] als Katalog dienen.
In dem ausgewählten Katalog werden die humanorientierten Kompetenzen in sie-
ben Dimensionen eingeteilt (siehe Bild 5-2).
Jede Dimension beinhaltet sowohl die Fähigkeiten als auch die Bereitschaft, die
Fähigkeiten effizient und effektiv einzusetzen [GSE+98, S. 3]. Eine Aufzählung
aller zu den Dimensionen zugeordneten und zu betrachtenden Kompetenzen befin-
det sich in Anhang C.
Zusätzlich beinhaltet der Katalog für jede Kompetenz eine Definition sowie posi-
tive und negative Indikatoren zur näheren Bestimmung (siehe Bild 5-3). Diese die-
nen der Beurteilung darüber, ob die einzelnen Kompetenzen für die Erfüllung einer
Aufgabe notwendig sind oder nicht bzw. inwieweit die entsprechenden Kompeten-
zen bei einem Mitarbeiter ausgeprägt sind. Die Zusammenfassung von Kompeten-
zen zu Dimensionen ermöglicht eine aggregierte Bewertung.
5.1.1.2 Fach- und Methodenkompetenzen
Humanorientierte Kompetenzen stellen zunächst allgemeine Grundlagen für die
Arbeitsfähigkeit eines Mitarbeiters dar, die unabhängig von der PDM-Einführung
sind. Der oben genannte Katalog ist also universell anwendbar und die Dimensio-
nen und Kompetenzen sind für jedes Projekt der PDM-Einführung gleich. Sie
unterscheiden sich lediglich in der Bewertung der Notwendigkeit für einzelne Auf-
Bild 5-2: Dimensionen humanorientierter Kompetenzen [GSE+98, S. 3]
Persönlichkeit
Persönlichkeitsmerkmale, die
das Ergebnis des Handelns
und die Qualität der Arbeit
beeinflussen
Kommunikation
Befähigung zur adäquaten
mündlichen und schriftlichen
Kommunikation sowie an-
gemessene Verhaltensweisen
Motivation/Antrieb
Charakterliche Eigenschaften
und innere Anreize, die den
Mitarbeiter zu guter Leistung
motivieren
Kooperation
Fähigkeit zur offenen und
vertrauensvollen Zusammen-
arbeit mit Kollegen und
Vorgesetzten
Intellekt
Intellektuelle Faktoren, die
die Eignung der betreffenden
Person für das Aufgabenfeld
bestimmen
Effizientes Handeln
Qualitäten des Mitarbeiters,
die den effizienten Ablauf
eines Geschäftsprozesses
gewährleisten
Führung/Coaching
Persönlichkeitsmerkmale,
die die Eignung der Person
für eine Führungsposition
bestimmen
Seite 148 Kapitel 5
gaben. Fachliche Kompetenzen sind dagegen direkt mit der inhaltlichen Ausfüh-
rung einer Aufgabe verbundene Fähigkeiten. Deshalb kann sich der Katalog der
fachlichen Kompetenzen bei unterschiedlichen PDM-Einführungen und je nach
Projekt unterscheiden.
Beispiel: Ein Mitarbeiter, der für die Systemanpassung des PDM-Systems verant-
wortlich ist, muss als Methode die Programmiersprache beherrschen,
mit der die Anpassung durchgeführt wird. Diese ist abhängig vom aus-
gewählten System, so dass in einer PDM-Einführung Kenntnisse in
C++ gefragt sein können, während in einer anderen PDM-Einführung
Kentnisse in Java gefordert sind.
Um zumindest auf einer aggregierten Ebene eine Vergleichbarkeit herzustellen,
werden die fachlichen Kompetenzen für die PDM-Einführung ebenfalls in sieben
Dimensionen eingeteilt (siehe Bild 5-4). Diese Dimensionen sind fest definiert,
während die einzelnen Kataloge von Kompetenzen dahinter wechseln können.
Es ist deshalb an dieser Stelle nicht möglich und für die weitere Erläuterung der
Methode nicht notwendig, einen vollständigen Katalog aller fachlichen Kompeten-
zen aufzustellen. Im Weiteren werden auf Basis des für die Darstellung der
Methode ausgewählten Ausschnitts des integrierten Vorgehensmodells beispiel-
haft fachliche Kompetenzen benannt.
Bild 5-3: Beschreibung einer humanorientierten Kompetenz nach [GSE+98]
(Beispiel)
Geistige Flexibilität
Begriffsbestimmung: Flexibilität: (lat.), Fähigkeit, sich im Erleben
und Verhalten wechselnden Situationen anzupassen. Gegensatz:
Rigidität.
Flexibel: An veränderte Umstände anpassungsfähig
Quelle: dtv Lexikon (1995)
Quelle: Wahrig: Deutsches Wörterbuch (1989)
Erläuterung: Der Betreffende ist nicht auf eine Meinung und eine
Denkweise festgelegt und festgefahren, sondern offen für neue
Standpunkte und Denkansätze. Er kann Gedankensprünge nach-
vollziehen und sich in verschiedene Situationen hineindenken.
Beispiele:
Positive Indikatoren Negative Indikatoren
- ist festgefahren auf alte Sach-
verhalte und Situationen
- sieht eine Angelegenheit nur
unter dem ersten Eindruck
- bildet sich eine Meinung, die
umzuwerfen oder zu ändern er
nicht mehr bereit ist
- lebt in der Vergangenheit, will
keine Veränderungen
- kann sich in neue Situationen
schnell hineindenken
- ist bereit, eine Angelegenheit auch
unter verschiedenen Gesichts-
punkten zu betrachten
- ist nicht zu festgefahren auf seine
eigene Meinung
- versucht, auf neue Trends
einzugehen, ist offen für Neues
Personalplanung und -entwicklung Seite 149
5.1.2 Ermittlung der Rollen
Die fachlichen und humanorientierten Kompetenzen müssen nun dahingehend
bewertet werden, inwieweit sie für die Bewältigung der im integrierten Vorgehens-
modell enthaltenen Aufgaben relevant sind. Diese Bewertung geschieht mit Hilfe
der in Bild 5-5 dargestellten Aufgaben-Kompetenzen-Matrix. In den Zeilen sind
die Aufgaben aus dem integrierten Vorgehensmodell eingetragen, während die
Kompetenzen in den Spalten stehen. Im Schnittpunkt von Aufgabe und Kompe-
tenz wird mit einer Skala von 0 bis 5 bewertet, wie wichtig die Kompetenz für die
Aufgabe ist. Die Skalenwerte haben dabei folgende Bedeutung:
• 0: Kompetenz nicht relevant/Keine Kompetenz gefordert
• 1: Kompetenz unwichtig/Kompetenz kann vorhanden sein
• 2: Kompetenz hilfreich/Geringe Kompetenz sollte vorhanden sein
• 3: Kompetenz notwendig/Geringe Kompetenz muss vorhanden sein
• 4: Kompetenz wichtig/Kompetenz muss vorhanden sein
• 5: Kompetenz zwingend/Hohe Kompetenz muss vorhanden sein
Durch die vollständige Bewertung einer Zeile der Matrix entsteht ein Kompetenz-
profil für eine Aufgabe. Aufgaben mit gleichen Kompetenzprofilen können nun zu
einer Rolle zusammengefasst werden. Da das Vorgehensmodell vorsieht, die
Hauptphasen als eigene Projekte zu gestalten, erfolgt die Bildung der Rollen je
Hauptphase. D.h. in einer Aufgaben-Kompetenzen-Matrix werden alle Aufgaben
der Aktivitäten eines Projektes bewertet und zu Rollen zusammengefasst.
Bild 5-4: Dimensionen fachlicher Kompetenzen für die PDM-Einführung
Unternehmen
Wissen über die Geschäfts-
prozesse und das Umfeld
des Unternehmens
Erfahrung
Vorhandenes Wissen zu all-
gemeinen Themen und
speziellen Fragestellungen
aus vergangenen Projekten
System
Technische und anwen-
dungsbezogene Kenntnisse
über den PDM-Markt und
das ausgewählte System
Projektmanagement
Kenntnisse zu den
Prozessen, Aufgaben und
Werkzeugen des
Projektmanagements
PDM
Know-how über die fach-
lichen Grundlagen von
PDM, seine Auswirkungen
und den Nutzen
Technik
Technisches Wissen
zur Hardware, zu
Netzwerken und zu
Supportfunktionen
Methoden
Fähigkeit zur Anwendung
der verschiedenen
Methoden der
PDM-Einführung
Seite 150 Kapitel 5
Die Ableitung der Rollen mit den Kompetenzprofilen stellt im Sinne des Personal-
managements die qualitative Personalbedarfsanalyse dar. Zusätzlich muss nun für
jede Rolle der Aufwand für die Bewältigung der Aufgaben geschätzt werden1
(quantitative Personalbedarfsanalyse). Dazu werden die Aufwände jeder einzelnen
Aufgabe in Personenentagen (PT) geschätzt, auf Basis der Aktivitäten aufsum-
miert und zusätzlich zum Kompetenzprofil der Rolle eingetragen. Pro Projekt ent-
steht so eine Rollenliste, in der alle zu besetzenden Rollen mit dem notwendigen
Kompetenzprofil und dem geschätzten Aufwand über die Aktivitäten aufgeführt
sind (siehe Bild 5-6). Bei den Aktivitäten sind auch die Zeiträume zu betrachten,
zu denen sie durchgeführt werden. Diese sind dem Projektplan zu entnehmen.
Bild 5-5: Aufgaben mit gleichen Kompetenzprofilen werden zu Rollen zusam-
mengefasst
1. Welche Schätzmethode dazu verwendet wird, ist für den Ablauf der Personalplanung und -ent-
wicklung nicht von Belang. Deshalb wird hier nicht weiter darauf eingegangen.
Aufgaben-Kompetenzen-Matrix Systemeinführung (P3)
Aktivitäten
Tests planen (P3.1.6)
Kompetenzprofil
Aufgaben
Prozessmodell analysieren
Zeitplan erstellen
...
Integrationstests
durchführen (P3.3.2)
3
Denken in Zusammenh.
systematisch-analyt. D.
intuitiv-kreatives Denken
...
Systemarchitektur
Anwendungsfunktionen
Datenbefüllungsschnittst.
...
Intellekt System
51 242
351 242
3
4
35
35
234 331
0: Nicht relevant / Keine Kompetenz gefordert
1: Unwichtig / Kompetenz kann vorhanden sein
2: Hilfreich / Geringe Kompetenz sollte vorhanden sein
3: Notwendig / Geringe Kompetenz muss vorhanden sein
4: Wichtig / Kompetenz muss vorhanden sein
5: Zwingend / Hohe Kompetenz muss vorhanden sein
Anwend.-fälle analysieren
Testdaten ermitteln
.
.
Rollen
Integrationstester
.
.
.
.
.
.
.
.
Komponenten einspielen
Testdaten einspielen
Funktionen testen
Test dokumentieren
...
351242
351242
343535
513
5
22
242341
Datenadministrator
.
.
343535
.
.
4
4
4
3
3
3
3
41
1
1
2
2
2
5
1
24
42
Personalplanung und -entwicklung Seite 151
Die Rollen müssen nun durch Mitarbeiter besetzt werden. Der damit verbundene
Prozess wird im Folgenden beschrieben.
5.2 Besetzung der Rollen
Der Prozess der Besetzung der Rollen ist in Bild 5-7 in Form eines Flussdia-
gramms dargestellt2. Ziel des Prozesses ist es, für jede Rolle Mitarbeiter zu finden,
die zum einen dem geforderten Kompetenzprofil entsprechen und zum anderen
von der Ressourcenplanung her verfügbar sind. Verfügbarkeit bedeutet, dass der
Mitarbeiter in dem Zeitraum, in dem eine Aktivität abläuft, an der seine Rolle
beteiligt ist, noch nicht für so viele andere Aufgaben eingeplant ist, dass er den
geschätzten Aufwand nicht mehr leisten kann.
Der dargestellte Ablauf basiert dabei auf folgenden Rahmenbedingungen und
Annahmen:
• Es wird zunächst immer versucht, die Rollen durch interne Mitarbeiter zu beset-
zen. Nur wenn sowohl kein Mitarbeiter mit dem notwendigen Kompetenzprofil
vorhanden bzw. verfügbar ist als auch eine Nachqualifizierung der fehlenden
Kompetenzen nicht möglich ist, werden die Rollen mit externen Mitarbeitern
besetzt.
• Erfolgt eine Qualifizierung, ist diese immer erfolgreich.
Bild 5-6: Rollenliste mit Kompetenzprofilen und Aufwänden
2. Einige Elemente des Flussdiagramms sind mit einer Nummerierung (K1 bis K12) versehen.
Diese dient in der folgenden Beschreibung zur Referenzierung der Elemente.
Rollenliste Systemeinführung (P3)
Aufwände (PT)
Kompetenzprofil
...
5
...
P3.1.1 (07/02 - 09/02
P3.1.2 (07/02 - 10/02)
P3.1.6 (10/02 - 12/02)
...
42 24
6
451 0
18
425 44
351
.
.
Rollen
Integrationstester
.
.
.
.
.
.
P3.5.3 (07/02 - 07/03
3
2
0
4
.
.
.
.
Intellekt
.
.
Feinspez. (P3.1)
.
.
PT: Personentage
Denken in Zusammenh.
systematisch-analyt. D.
intuitiv-kreatives Denken
00 15
Prozessanalyst
Datenmodellierer
Moderator
...
2
2
0
4
1
1
3
Seite 152 Kapitel 5
Bild 5-7: Vergabe der Rollen für die PDM-Einführung
Personalplanung und -entwicklung Seite 153
• Wird auf externe Mitarbeiter zurückgegriffen, sind die damit verbundenen Ver-
tragsverhandlungen immer erfolgreich.
• Auf dem Dienstleistungsmarkt sind immer externe Mitarbeiter für die offenen
Rollen vorhanden und verfügbar.
• Eine Beschaffung von internen Mitarbeitern auf dem Arbeitsmarkt wird nicht
eingeleitet, weil davon ausgegangen wird, dass aufgrund des in Kapitel 2.2.3
dargestellten Mangels an Ausbildungsmöglichkeiten für PDM eine solche
Beschaffung nicht erfolgreich ist.
• Voraussetzung für die Auswahl auf Basis der Kompetenzprofile ist, dass die vor-
handenen Kompetenzen der Mitarbeiter in der gleichen Form vorliegen wie die
geforderten Kompetenzen der Rollen. Diese Profile sind für die internen Mitar-
beiter unternehmensweit in einer Profildatenbank gespeichert. Für die externen
Mitarbeiter existiert ebenfalls eine Profildatenbank, z.B. auf einem elektroni-
schen Marktplatz.
• Für die Prüfung der Verfügbarkeit existiert entsprechend jeweils eine Ressour-
cenplanungsdatenbank für interne Mitarbeiter und für externe Mitarbeiter.
• Die Möglichkeiten der Qualifizierung sind in einer Qualifizierungsdatenbank
abgebildet.
In den Kompetenzprofilen der Mitarbeiter wird äquivalent zu den Rollenprofilen
mit Hilfe einer Skala von 0 bis 5 bewertet, in welcher Qualität die jeweilige Kom-
petenz bei dem Mitarbeiter ausgeprägt ist. Bild 5-8 zeigt beispielhaft ein solches
Mitarbeiterprofil.
Die Skalenwerte haben dabei folgende Bedeutung:
• 0: Kompetenz bei Mitarbeiter nicht vorhanden
• 1: Kompetenz bei Mitarbeiter nur gering ausgeprägt
• 2: Kompetenz bei Mitarbeiter ausbaufähig vorhanden
• 3: Kompetenz bei Mitarbeiter vorhanden
Bild 5-8: Darstellung eines Mitarbeiterprofils (Beispiel)
Mitarbeiterprofil für Erika Mustermann
Kompetenzprofil
...
...
Intellekt System
0: Komp. bei Mitarbeiter nicht vorhanden
1: Komp. bei Mitarbeiter nur gering ausgeprägt
2: Komp. bei Mitarbeiter ausbaufähig vorhanden
3: Komp. bei Mitarbeiter vorhanden
4: Komp. bei Mitarbeiter überdurchschnittlich vorhanden
5: Komp. stellt ausgesprochene Stärke des Mitarbeiters dar
Mitarbeiter
Erika Mustermann
.
.
.
.
Denken in Zusammenh.
systematisch-analyt. D.
intuitiv-kreatives Denken
Systemarchitektur
Anwendungsfunktionen
Datenbefüllungsschnittst.
22334432
Seite 154 Kapitel 5
• 4: Kompetenz bei Mitarbeiter überdurchschnittlich vorhanden
• 5: Kompetenz stellt ausgesprochene Stärke des Mitarbeiters dar
Zur detaillierten Beschreibung des Prozesses und der damit verbundenen Methode
wird im Folgenden zunächst der im Flussdiagramm grau markierte Pfad beschrie-
ben. Er bildet den Fall ab, dass ein interner Mitarbeiter gefunden wird, der sowohl
das passende Kompetenzprofil hat als auch verfügbar ist. Danach werden die
abweichenden Pfade erläutert.
5.2.1 Auswahl interner Mitarbeiter
Die Vergabe der Rollen an interne Mitarbeiter verläuft ähnlich der Systemauswahl
bei der PDM-Einführung zweistufig. Zunächst wird das Kompetenzprofil der zu
vergebenden Rolle mit den Mitarbeiterprofilen auf grober Ebene verglichen (K1).
Dazu wird die mittlere Abweichung der Kompetenzwerte der Mitarbeiterprofile
vom Kompetenzwert des Profils der Rolle berechnet. Die dazugehörige Formel
lautet:
Die Variablen haben dabei folgende Bedeutung:
AmMittlere Abweichung von Mitarbeiter m.
n Anzahl der Kompetenzen im Kompetenzprofil.
W Kompetenzbewertung im Kompetenzprofil (Wertebereich 0-5).
M Kompetenzwert des Mitarbeiters (Wertebereich 0-5).
i Zählvariable der Summenformel.
Je kleiner die mittlere Abweichung ist, desto besser stimmt das Mitarbeiterprofil
mit dem geforderten Kompetenzprofil überein. Eine Abweichung von 0 bedeutet,
dass die Profile vollständig übereinstimmen. In diesem Fall kann direkt die Verfüg-
barkeit der entsprechenden Mitarbeiter geprüft werden.
Bei der hohen Anzahl an zu vergleichenden Kompetenzen in den Profilen3 ist es
wahrscheinlicher, dass zumindest geringe Abweichungen auftreten. Diese können
aber je nach Art der Kompetenz und ihrem Betrag auch als unkritisch eingestuft
werden4. Deshalb werden im nächsten Schritt die Profile der Mitarbeiter mit den
geringsten Abweichungen detaillierter mit dem Kompetenzprofil der Rolle vergli-
3. Allein bei den humanorientierten Kompetenzen enthält der Katalog 70 Einträge (siehe Anhang
C).
4. Eine genaue Aussage darüber, welche Abweichungen als akzeptabel anzusehen sind, ist nicht
möglich. Dazu wären umfangreiche empirische Erhebungen notwendig, die in dieser Art nicht
existieren. Die Einschätzung obliegt deshalb der durchführenden Person.
Am
WiMi
–
i1=
n
∑
n
-----------------------------------------
=
Personalplanung und -entwicklung Seite 155
chen (K2), um festzustellen, in welchen Dimensionen und Kompetenzen Defizite
oder Überqualifizierungen bestehen (siehe Bild 5-9).
Wird ein Mitarbeiter ermittelt, dessen Profil der Rolle genügt, muss als nächster
Schritt seine Verfügbarkeit geprüft werden (K3). Dazu wird der für die Rolle
geschätzte Aufwand (siehe Bild 5-6) mit der Ressourcenplanung abgestimmt. Ist
die Verfügbarkeit gegeben, wird der Mitarbeiter für die Rolle eingeplant (K4) und
die nächste Rolle besetzt (K5).
An mehreren Stellen des Prozesses ergibt sich die Notwendigkeit, von dem
beschriebenen Pfad abzuweichen. Gründe hierfür sind entweder die fehlenden
Qualifikationen des betrachteten Mitarbeiters oder der Mitarbeiter ist nicht verfüg-
bar. Die alternativen Pfade sollen nachfolgend erläutert werden.
Qualifikationsdefizit
Ergibt der Profilvergleich (K2), dass die vorhandenen Kompetenzen des betrachte-
ten Mitarbeiters nicht mit dem geforderten Profil der Rolle übereinstimmen, muss
als nächstes geprüft werden, ob die Möglichkeit der Qualifizierung besteht (K6).
Dazu wird zum einen aus dem Profilvergleich ermittelt, bei welchen Kompetenzen
ein Qualifikationsdefizit besteht und wie groß dieses ist. Zum anderen kann der
Bild 5-9: Detaillierter Vergleich zwischen Rollenprofil und Mitarbeiterprofilen
Profilvergleich für Rolle Integrationstester
Erika Mustermann
Kompetenz
Denken in Zusammenhängen
Systematisch-analytische Denken
Intuitiv-kreatives Denken
...
012345
Intellekt
.
.
Arbeitstempo
Qualitätsbewusstsein
Selbstorganisation
...
Effiz. Handeln
Systemarchitektur
Anwendungsfunktionen
Datenbefüllungsschnittstelle
...
System
Rollenprofil
Mitarbeiterprofil
Gerd Tester
012345
.
..
.
.
.
.
.
1,25
Abweichung 0,58
Seite 156 Kapitel 5
Qualifizierungsdatenbank entnommen werden, ob eine Qualifizierungsmaßnahme
existiert, die das ermittelte Defizit ausgleichen kann. Dies ist grundsätzlich bei
Defiziten in fachlichen Kompetenzen eher möglich als bei den humanorientierten
Kompetenzen.
Beispiel: Der Vergleich zwischen Rollenprofil und Mitarbeiterprofil von Gerd
Tester (siehe Bild 5-9) ergibt ein Defizit bei der Kompetenz „Selbstor-
ganisation“. Um dieses auszugleichen, kann der Mitarbeiter an einem
Zeitmanagementseminar teilnehmen.
Ist die Qualifizierung möglich, wird zunächst wieder die Verfügbarkeit des Mitar-
beiters geprüft (K7). Bei Verfügbarkeit wird er für die Rolle eingeplant (K8) und
die Qualifizierungsmaßnahme veranlasst (K9). Einen Überblick über die verschie-
denen Arten der Qualifizierung für die PDM-Einführung gibt Kapitel 5.3.
Es besteht die Möglichkeit, dass ein Mitarbeiter in bestimmten Kompetenzen auch
überqualifiziert ist. Auch dieser Fall ist intensiv zu prüfen. Auf den ersten Blick ist
es für das Projekt natürlich nicht relevant, weil der Mitarbeiter in der Lage ist, die
Rolle zu besetzen. Wird der Mitarbeiter aber auf einer ihn stark unterfordernden
Rolle eingesetzt, kann dies zu negativen Folgen aufgrund von Motiviationsverlust
führen. Deshalb sollte davon abgesehen werden, Rollen mit überqualifizierten Mit-
arbeitern zu besetzen.
Ist die Qualifizierung nicht möglich, wird der Profilvergleich mit dem nächsten der
ermittelten Mitarbeiter auf der Liste durchgeführt (K10).
Mangelnde Verfügbarkeit
Bei mangelnder Verfügbarkeit eines Mitarbeiters wird unabhängig davon, ob die-
ser mit oder ohne Nachqualifizierung für die Rolle passend gewesen wäre, mit dem
nächsten Mitarbeiter auf der Liste fortgefahren (K10)5.
Der Prozess läuft pro Rolle so lange, bis alle aufgrund einer geringen mittleren
Abweichung geeigneten Mitarbeiter von der Liste abgearbeitet sind. Kann eine
Rolle dabei nicht intern vergeben werden, wird für diese Rolle der Prozess der
externen Vergabe angestoßen (K11). Dieser wird im nachfolgenden Kapitel erläu-
tert.
Am Ende des Prozesses sind alle Rollen des Projektes besetzt und das Projektteam
damit vollständig (K12).
5. Bei der Verfügbarkeitsprüfung ist ein Punkt zu beachten, der durch den Prozess nicht abgebildet
werden kann. Natürtlich besteht bei negativem Ergebnis der Verfügbarkeitsprüfung die Mög-
lichkeit, unternehmensintern zu regeln, dass ein Mitarbeiter, der aufgrund seines Profils beson-
ders für eine Rolle in der PDM-Einführung geeignet ist, von anderen bisher in der Ressourcen-
planung eingestellten Aufgaben freigestellt wird.
Personalplanung und -entwicklung Seite 157
Sonderfälle
Es ist grundsätzlich möglich, dass ein Mitarbeiter mehrere Rollen besetzt. Dies
kann bei sehr ähnlichen Rollenprofilen der Fall sein. Zusätzlich muss der Aufwand
pro Rolle und Aktivität entsprechend gering sein. Ein weiterer Sonderfall entsteht,
wenn der Aufwand für eine Rolle in einer Aktivität höher ist, als durch einen Mit-
arbeiter zu bewältigen ist. Dann kann eine Rolle auf mehrere Mitarbeiter verteilt
werden.
Beispiel: Der geplante Zeitraum für eine Ist-Analyse ist sehr kurz, obwohl viele
Interviews zu führen sind. Die Rolle „Interviewer“ muss deshalb von
mehreren Mitarbeitern besetzt werden.
5.2.2 Auswahl externer Mitarbeiter
In Kapitel 2.2.4 ist die Notwendigkeit des Einsatzes externer Mitarbeiter ausführ-
lich erläutert worden. Das vorgestellte Modell berücksichtigt deshalb den Fall,
dass eine Rolle extern vergeben werden muss. Der dahinterstehende Prozess ist in
Bild 5-10 dargestellt.
Das Verfahren ist ebenfalls zweistufig. Im ersten Schritt wird an Hand der Formel
aus Kapitel 5.2.1 die mittlere Abweichung der in der Profildatenbank gespeicher-
ten Beraterprofile ermittelt. Daraus ergibt sich eine Liste mit potentiellen Beratern.
Deren Kompetenzprofile werden dann nach dem in Bild 5-9 dargestellten Verfah-
ren detaillierter mit dem Kompetenzprofil der Rolle verglichen. Ist das Profil eines
Beraters passend, wird auch hier die Verfügbarkeit geprüft und der Berater bei
positiver Prüfung eingeplant. Zusätzlich wird die Vertragsverhandlung angestos-
sen. Ist das Profil eines Beraters nicht passend oder dieser nicht verfügbar, wird der
nächste Berater der Liste näher betrachtet. Es findet hier im Gegensatz zum Ver-
fahren bei den internen Mitarbeitern keine Untersuchung eines möglichen Aus-
gleichs des Qualifizierungsdefizites statt, da aus Sicht des Unternehmens, das die
PDM-Einführung durchführen will, nicht in interne Prozesse des Dienstleistungs-
unternehmens eingegriffen werden kann.
Sonderfall
Bei konsequenter Anwendung des Verfahrens kann es passieren, dass das interne
Projektteam durch externe Mitarbeiter aus vielen unterschiedlichen Dienstlei-
stungsunternehmen unterstützt wird. Dies ist sowohl aus Kostengründen als auch
aus Gründen der Koordination des Teams nicht sinnvoll. Es ist deshalb bei der
Auswahl der externen Mitarbeiter darauf zu achten, dass eine Rolle im Zweifelsfall
nicht immer mit dem besten Berater aus der Liste besetzt wird. Statt dessen sollte
man versuchen, das beste Team aus Beratern von möglichst wenigen unterschiedli-
chen Dienstleistungsunternehmen auszuwählen.
Seite 158 Kapitel 5
Marktplatz
Die Möglichkeit der unternehmensübergreifenden Suche nach Beraterprofilen
erfordert die Existenz einer entsprechenden Infrastruktur. Diese kann z.B. durch
einen elektronischen Marktplatz zur Verfügung gestellt werden. Die Konzeption
eines solchen Marktplatzes ist nicht Bestandteil dieser Arbeit.
Bild 5-10: Ablauf der externen Vergabe von Rollen
Personalplanung und -entwicklung Seite 159
5.2.3 Anwendung der Methode auf die mittelfristige
Personalplanung und -entwicklung
Die vorgestellte Methode kann weitestgehend auch für die Aufgaben der mittelfri-
stigen Personalplanung und -entwicklung verwendet werden. Basis für die Ablei-
tung der Kompetenzprofile für Arbeitsaufgaben und die darauf aufbauende Defin-
tion von Rollen sind hier die Prozesse des Sollprozessmodells und die
Anwendungsfälle. Sie entsprechen den Aktivitäten und Aufgaben des Vorgehens-
modells (siehe Bild 5-5). Die humanorientierten Kompetenzen und ihre Dimensio-
nen werden übernommen. Für die fachlichen Kompetenzen müssen dem
Arbeitsumfeld des Unternehmens angepasste Dimensionen und Kompetenzen
definiert werden.
Der dargestellte Prozess (siehe Bild 5-7) dient dann dazu, die neuen Rollen des
Sollprozesses durch die bestehenden Mitarbeiter zu besetzen. Die ermittelten Qua-
lifikationsdefizite für fachliche und humanorientierte Kompetenzen dienen dann
als Input für verschiedene weitere Aktivitäten der PDM-Einführung:
• Aus den fachlichen Defiziten können die Anforderungen für die Planung der rol-
lenbasierten Anwenderschulungen (P3.4.3) abgeleitet werden.
• Die Defizite in den humanorientierten Kompetenzen dienen als Eingangsgröße
für das begleitende Change Management (P3.5.1).
Lediglich der Aspekt der Einbindung externer Mitarbeiter kann für die Adaption in
den meisten Fällen vernachlässigt werden.
5.3 Ausgleich von Qualifizierungsdefiziten
Im Umfeld der PDM-Einführung spielen drei Dimensionen der Qualifizierung eine
entscheidende Rolle (siehe Bild 5-11). Im Folgenden werden Maßnahmen für
diese Dimensionen vorgestellt. Dieser Abschnitt bildet damit den Abschluss der
Personalplanung und -entwicklung im integrierten Vorgehensmodell zur Einfüh-
rung von PDM-Systemen.
5.3.1 Qualifizierung für die Projektarbeit
Zum einen müssen die Projektmitarbeiter in der PDM-Einführung für ihre Aufga-
ben ausreichend qualifiziert werden. Wie der rollenspezifische Qualifizierungsbe-
darf aus dem integrierten Vorgehensmodell ermittelt wird, ist in Kapitel 5.2.1
bereits ausführlich erläutert worden. Zum Ausgleich dieser Defizite dienen vor
allem klassische Schulungen, in denen der Mitarbeiter möglichst vor Projektbeginn
die fehlenden Kompetenzen, z.B. fehlende Methodenkenntnisse zur Prozessmodel-
lierung, vermittelt bekommt (off-job).
Seite 160 Kapitel 5
Zur Schaffung eines einheitlichen Verständnisses aller Beteiligten über Zielset-
zung, Inhalt und Methoden der jeweils anstehenden Phase ist es notwendig, mit
dem gesamten Projektteam Kick-off Workshops durchzuführen, in denen diese
Themen vorgestellt und diskutiert werden.
Eine weitere mögliche Maßnahme ist das Coaching. Dabei wird der Mitarbeiter
während der Arbeit am Projekt in seiner Aufgabe von einem kompetenten Berater
oder Kollegen angeleitet (on-job).
Als dritte projektbegleitende Maßnahme zur Qualifizierung dient die Einrichtung
eines Wissensmanagements für die PDM-Einführung. Während die ersten drei
Maßnahmen vor allem für die Qualifizierung von Grundlagen geeignet sind, kann
mit Hilfe des Wissensmanagements die Lösung akuter Probleme unterstützt wer-
den, in dem auf Erfahrungen anderer Mitarbeiter oder externer Dienstleistungsun-
ternehmen zurückgegriffen werden kann6.
5.3.2 Anwenderschulungen
Die Anwenderschulungen dienen dazu, die Mitarbeiter des Unternehmens auf ihre
spätere Rolle in den neuen Geschäftsprozessen vorzubereiten. Deshalb ist es wich-
tig, die Schulungen so zu gestalten, dass sowohl die neuen Prozesse und die damit
verbundenen Änderungen als auch die Systemfunktionen vermittelt werden. Es
reicht nicht aus, die Anwender in der Bedienung des Systems an Hand von vorge-
fertigten, nicht an die unternehmensspezifischen Anpassungen adaptierten Stan-
dardschulungen zu unterweisen. Die entsprechenden Aktivitäten enthält das inte-
grierte Vorgehensmodell zur Einführung von PDM-Systemen. Außerdem wurde
im Rahmen der Personalplanung und -entwicklung eine Methode vorgestellt, die
es ermöglicht, die Anforderungen an die rollenbasierten Schulungen abzuleiten
(siehe Kapitel 5.2.3).
Bild 5-11: Dimensionen der Qualifizierung im Umfeld der PDM-Einführung
6. Siehe [CM97], [Kah00].
Qualifizierung im Umfeld der PDM-Einführung
Qualifizierung für die Projektarbeit
Anwenderschulungen
Berufliche Aus- und Weiterbildung
Personalplanung und -entwicklung Seite 161
Eigene Erfahrungen aus Projekten des Autors haben gezeigt, dass die Beherr-
schung des Systems sehr stark mit der Nutzung zusammenhängt. Anwender, die
täglich mit einem System arbeiten, haben auch mit komplizierten Funktionen
kaum Probleme. Wird das System aber nur selten genutzt, werden oft schon sehr
einfache Schritte falsch gemacht. Es muss dehalb aufbauend auf den Schulungen
für die Anwender möglich sein, jederzeit an ihrem Arbeitsplatz einzelne Lernein-
heiten zu wiederholen, um ihr Wissen wieder aufzufrischen. Vielfältige Möglich-
keiten ergeben sich dazu durch das so genannte Computer Based Training (CBT)
mit multimedialer Lernsoftware7.
5.3.3 Berufliche Aus- und Weiterbildung
Neben den direkt projektbezogenen Qualifizierungsmaßnahmen muss der wach-
senden Bedeutung von PDM-Systemen als festen Bestandteil der täglichen Arbeit
in der Entwicklung oder Fertigung auch in der beruflichen Bildung Rechnung
getragen werden (siehe Kapitel 2.2.3 und Kapitel 2.2.4). Ebenso muss der Bedarf
an qualifizierten PDM-Experten, die die Einführungsprojekte durchführen,
gedeckt werden. Die im Folgenden beschriebenen Maßnahmen erfüllen diese For-
derungen in drei Stufen:
• Anleitung zukünftiger Benutzer in der Bedienung von PDM-Systemen,
• Vertiefte Vermittlung von PDM-Kenntnissen mit Schwerpunktbildung,
• Außeruniversitäre Ausbildung von PDM-Experten.
5.3.3.1 Einsatz eines PDM-Systems in der Lehre für Ingenieure
Die Ausbildung an Hochschulen und Fachhochschulen hat zur Aufgabe, die
zukünftigen Ingenieure praxisgerecht auf ihre zukünftigen Aufgaben in der Indu-
strie vorzubereiten. Dazu gehört auch der Umgang mit gängigen Methoden und
Werkzeugen. Diese unterliegen einer ständigen Weiterentwicklung, der auch die
Bildungsinstitute folgen müssen, um nicht am Bedarf vorbei auszubilden. Ein
gutes Beispiel ist hier der Einsatz von CAD in der Lehre, der mittlerweile fester
Bestandteil des Maschinenbaustudiums ist und die Erstellung technischer Zeich-
nungen von Hand weitgehend abgelöst hat. Ebenso kann Computergestütztes Kon-
struieren in fast allen deutschen Maschinenbaustudiengängen als Schwerpunkt
gewählt werden. Eine ähnliche Entwicklung ist für die Nutzung von PDM-Syste-
men auch in der Lehre anzustreben.
Der erste Schritt dazu ist die Integration eines PDM-Systems in die CAD-Kon-
struktionsübungen. Der Ablauf entspricht dabei dem Prozess einer Konstruktions-
7. CBT auf Basis von Internettechnologien und mit integrierten Online-Funktionen wird heute
auch mit dem aktuellen Schlagwort e-Learning versehen.
Seite 162 Kapitel 5
freigabe, wie er täglich von Konstrukteuren in Unternehmen auch durchschritten
wird. Er ist als Workflow im PDM-System hinterlegt.8
Die Studierenden erhalten ihre Aufgabe als Auftrag vom PDM-System. Die not-
wendigen Daten, z.B. die Anforderungsliste für das zu konstruierende Produkt
oder Normblätter, werden ebenfalls über das PDM-System zur Verfügung gestellt.
Die Studierenden konstruieren wie bisher im CAD-System. Die Zwischenergeb-
nisse werden dann vollständig mit Produktstruktur und Geometriedaten über die
CAD-PDM-Schnittstelle im PDM-System abgelegt. Sie können hier vom Prüfer
zwischenbegutachtet und von den Studenten immer wieder zu Verbesserungen auf-
gerufen werden.
Dabei lernen die Studenten den alltäglichen Umgang mit dem PDM-System und
die damit verbundenen Arbeitsschritte wie das Ein- und Auschecken von Daten
oder den Umgang mit Arbeitslisten und Workflows. Sie können durch die gängi-
gen Darstellungen der Produktstruktur als Bäume oder Listen navigieren.
Zum Abschluss wird das Testat im Rahmen eines Freigabeprozesses auch über das
PDM-System abgewickelt. Die Studierenden schicken ihre Endergebnisse mit der
Workflowkomponente an den Betreuer. Dieser begutachtet die Arbeit und weist sie
entweder mit den entsprechenden Anmerkungen zurück an die Studierenden oder
erteilt das Testat, das automatisch über das System ausgefüllt und an die zustän-
dige Verwaltungsstelle weitergeleitet wird.
Diese Maßnahme lässt sich sowohl für Einzeltestate als auch für Gruppenübungen
in die Lehre integrieren. Im zweiten Fall lernen die Studierenden zusätzlich die
Funktionen zur Zugriffs-, Versions- und Konfigurationskontrolle kennen, da sie
gemeinsam an einer Aufgabe arbeiten und die von ihnen bearbeiteten
CAD-Dateien wieder freigeben und den anderen Gruppenmitgliedern zur Verfü-
gung stellen müssen.
5.3.3.2 Studienwahlfach PDM
Die Studienordnungen der Studiengänge Maschinenbau, Wirtschaftsingenieurwe-
sen und Ingenieurinformatik an der Universität Paderborn sehen im Hauptstudium
die Auswahl mehrerer so genannter Wahlpflichtfächer zur Schwerpunktbildung
vor9.
8. Ein ähnliches Konzept verfolgen die „Konstruktionsübungen-Online“ des Lehrstuhls für Kon-
struktionstechnik (LKT) der Universität des Saarlandes, Saarbrücken. Allerdings wird hier
lediglich ein selbstprogrammiertes System verwendet, das nur eine sehr vereinfachte Work-
flowunterstützung und keine echte CAD-PDM-Schnittstelle bietet [Mut99]. Es deutet die Mög-
lichkeiten von PDM nur an und zeigt nicht die Vielfalt der Funktionen auf.
9. Durch die Wahl von Wahlpflichtfächern sollen die Studierenden im Hauptstudium die Möglich-
keit erhalten, ein persönliches Profil zu entwickeln. Ein Wahlpflichtfach besteht aus unter-
schiedlichen Lehrveranstaltungen zu einem Themengebiet, das durch den Titel des Wahlpflicht-
faches beschrieben wird.[Uni01e, S. 16]
Personalplanung und -entwicklung Seite 163
Ein Wahlpflichtfach beinhaltet dabei acht Semesterwochenstunden (SWS) für den
Studiengang Wirtschaftingenieurwesen bzw. neun SWS für den Studiengang
Maschinenbau. Diese setzen sich aus einem Pflichtteil von vier SWS und einem
Wahlteil aus vier bzw. fünf SWS zusammen (siehe Bild 5-12). Zur Vermittlung
vertiefter PDM-Kenntnisse wurde ein solches Wahlpflichtfach unter dem Titel
„Produktdatenmanagement (PDM)“ konzipiert.
Kern des Wahlpflichtfaches mit acht bzw. neun SWS bilden als Pflichtfächer eine
Grundvorlesung „Produktdatenmanagement (PDM)“ mit zwei SWS und ein dazu-
gehöriges Projektseminar mit ebenfalls zwei SWS. Die übrigen vier bzw. fünf
SWS können aus einem Katalog von Vorlesungen, Übungen und Seminaren frei
gewählt werden. Dieser Katalog enthält Themen, die eine sinnvolle Wissenserwei-
terung darstellen, z.B. aus dem Bereich der rechnergestützten Produktentwicklung
(CAE), der industriellen Informationssysteme oder der allgemeinen Softwareent-
wicklung.
Tabelle 5-1 zeigt beispielhaft die im Wintersemester 2000/2001 und Sommersem-
ster 2001 angebotenen Veranstaltungen der Fachbereiche Wirtschaftswissenschaf-
ten, Maschinentechnik und Informatik, die als Wahlfächer gewählt werden sollten
[Uni00], [Uni01a]10.
Bild 5-12: Aufbau eines Wahlpflichtfaches nach Studienordnung Wirtschaftsinge-
nieurwesen [Uni01e, S. 16]
Tabelle 5-1: Fächerkatalog des Wahlfplichtfaches „Produktdatenmanagement“
(PDM)
Veranstaltungsname (Anbieter) P/W1Typ und
Umfang2
Produktdatenmanagement (PDM) (Gausemeier/N.N.) P V2
Einführung von Produktdatenmanagementsytemen (N.N.) P S2
ABWL: Management (Personal und Organisation) (N.N.) W V1
10. Detailliertere Informationen zu den einzelnen Lehrveranstaltungen bieten die kommentierten
Vorlesungsverzeichnisse der Fachbereiche Wirtschaftswissenschaften, Maschinentechnik und
Informatik im Internet [Uni01b-ol], [Uni01c-ol], [Uni01d-ol].
Titel des Wahlpflichtfaches (Koordinator bzw.
Koordinatorin des Wahlpflichtfaches)
i.d.R. Obligatorischer Kern von 4 SWS ( )Pflichtbereich
Kanon von Lehrveranstaltungen (Vorlesungen, Übungen,
Seminare, Praktika) von etwa 10 SWS, aus dem i.d.R.
4 SWS zu wählen. ( )Wahlbereich
Seite 164 Kapitel 5
Arbeitswissenschaft und Industriebetriebslehre (Treier) W V2
Berechnungsverfahren des Maschinenbaus
(Wallaschek/Herrmann/Richard/Buchholz) WV4 Ü2
Betriebliche Anwendungssysteme und Anwendungsmanagement (Fischer) W V2
Betriebliche Kommunikationssysteme und Kommunikationsmanagement
(Electronic Business) (Fischer) WV2
CAE-Anwendungsprogrammierung in einer höheren Programmiersprache
(C) (Koch/Mitarbeiter) WV3
Datenbanken 1 (Böttcher) W V2 Ü1
Datenbanken 2 (Böttcher) W V2 Ü1
Datenmanagement: Datenbanken und Datenmodellierung (Fischer) W V2
Einführung in das Qualitätsmanagement (Koch/Mitarbeiter) W V3
Einführung in das Qualitätsmanagement (Übung) (Koch/Mitarbeiter) W Ü1
Entwicklung mechatronischer Systeme in der Automobilindustrie
(Lückel/Lefarth) WV1
Grundlagen der Konstruktionssystematik (Schlattmann) W V2 Ü1
Grundlagen des Informationsmanagements am Arbeitsplatz (Nastansky) W V2
Grundlagen von Web-based Systems (Suhl/Kassanke) W V/Ü2
Implementierung von Benutzungsschnittstellen (Szwillus) W V2 Ü1
Industrieinformatik (Gausemeier) W V2
Industrieinformatik (Übung) (Gausemeier) W Ü2
Informationsmodelle, -methoden und -systeme für das logistikorientierte Pro-
duktionsmanagement (ILP) (Dangelmaier/Felser) WV/Ü2
Innovations- und Entwicklungsmanagement (IEM) (Gausemeier) W V2
Konstruktionsmethodik (Zimmer) W V2 Ü1
Konstruktionssystematik und rechnergestütztes Konstruieren (CAD) (Koch) W V2
Konstruktionssystematik und rechnergestütztes Konstruieren (CAD) (Übung)
(Koch) WÜ2
Management von IT-Projekten (IT-Consulting I) (Suhl/Mellouli) W V/Ü2
Mechatronik (Wallaschek) W V2 Ü1
Neue Organisationsformen unter Nutzung der I&K-Technologien
(Dangelmaier, Claussen) WV/Ü2
Objektorientierte Programmierung (Kastens) W V2 Ü1
Office Systeme 1 (Nastansky) W V/Ü2
Tabelle 5-1: Fächerkatalog des Wahlfplichtfaches „Produktdatenmanagement“
(PDM)
Veranstaltungsname (Anbieter) P/W1Typ und
Umfang2
Personalplanung und -entwicklung Seite 165
Es ergibt sich die Möglichkeit der weiteren Spezialisierung durch Schwerpunktbil-
dung bei den Wahlfächern. Durch sinnvolle Kombination entsteht ein Ausbil-
dungsprofil für Anwender, Berater oder Programmierer für Produktdatenmanage-
ment. Die Zuordnung der Fächer aus Tabelle 5-1 zu den Schwerpunkten findet sich
in Anhang D.1.
Die Pflichtvorlesung „Produktdatenmanagement (PDM)“ beinhaltet die Grundla-
gen zum Produktdatenmanagement und zur Einführung von PDM-Systemen. U.a.
wird das hier vorgestellte Vorgehensmodell gelehrt. Im dazugehörigen Seminar
wird das Vorgehensmodell dann von Studierenden im Team anhand einer konkre-
ten Aufgabenstellung aus der Industrie angewandt11. Die Vorlesungssteckbriefe
dieser beiden Veranstaltungen stehen in Anhang D.2.
Die Vorlesung und Übung können auch als Wahlfächer in anderen Studienordnun-
gen der oben genannten Fachbereiche integriert werden. Aus dem Fachbereich
Maschinentechnik sind das z.B. die Blöcke:
Produktion und Logistik: Methoden der Planung und Organisation
(Dangelmaier) WV/Ü4
Produktion und Logistik: Informationssysteme zur Produktionsplanung und
-steuerung (Dangelmaier) WV/Ü4
Projekt IT-Consulting (IT-Consulting II) (Toschläger) W S4
Projektseminar Innovations- und Entwicklungsmanagement (IEM)
(Gausemeier) WS2
Rechnergestütztes Konstruieren (CAD) (Koch) W V2
Rechnergestütztes Konstruieren (CAD)(Übung) (Koch) W Ü1
Rechnergestütztes Konstruieren und Planen (CAE) (Koch) W V2
Rechnergestütztes Konstruieren und Planen (CAE)(Übung) (Koch) W Ü1
Standardsoftware im Maschinenbau (Koch/Mitarbeiter) W V2 Ü1
Strategisches Produktionsmanagement (SPM) (Gausemeier) W V2
Übung zu ABWL: Management (Personal und Organisation)
(Groening/Weller) WÜ1
Übung zu Datenmanagement: Datenbanken und Datenmodellierung
(Steffen) WÜ2
Unternehmensorganisation (Pullig) W V2
Web-Engineering (Heckel) W V2 Ü1
1. P = Pflicht, W = Wahl
2. V = Vorlesung, Ü = Übung, S = Seminar; Anzahl der Semesterwochenstunden
Tabelle 5-1: Fächerkatalog des Wahlfplichtfaches „Produktdatenmanagement“
(PDM)
Veranstaltungsname (Anbieter) P/W1Typ und
Umfang2
Seite 166 Kapitel 5
• Entwurf mechatronischer Systeme (Lückel),
• Industrieinformatik (Gausemeier),
• Innovations- und Produktionsmanagement (Gausemeier),
• Konstruktionssystematik (Zimmer),
• Praktische Konstruktionslehre (Schlattmann),
• Prozessketten in der Fertigungstechnik (Vollertsen) und
• Qualitätsmanagement (Koch).
Im Rahmen von Studien- und Diplomarbeiten in Zusammenarbeit mit Industrie-
partnern (z.B. PDM-Beratungsunternehmen oder Unternehmen, die PDM in ihre
Prozesse integrieren) können die Studierenden das in den Veranstaltungen erlernte
Wissen weiter vertiefen und in der Praxis anwenden.
5.3.3.3 Traineeprogramm für PDM-Berater und Implementierer
Da nicht ausreichend Absolventinnen und Absolventen mit PDM-Kenntnissen von
den Hochschulen und anderen Bildungseinrichtungen (z.B. Berufsakademien)
abgehen, sind die Unternehmen gezwungen, die entsprechende Qualifizierung für
PDM selbst durchzuführen oder durchführen zu lassen. Für Unternehmen, in denen
PDM angewandt oder eingeführt wird, geschieht dies im Rahmen der in Kapitel
5.3.1 beschriebenen projektbezogenen Maßnahmen. Beratungsunternehmen und
Systemhäuser sind selbst gefordert.
Zu diesem Zweck hat der Lehrstuhl Rechnerintegrierte Produktion am Heinz Nix-
dorf Institut der Universität Paderborn in Zusammenarbeit mit einem ortsansässi-
gen Beratungsunternehmen ein Traineeprogramm12 für PDM-Berater/-Beraterin-
nen und Implementierer/Implementiererinnen für das PDM-System Metaphase
konzipiert und seit 1997 mehrfach erfolgreich durchgeführt (siehe Bild 5-13).
11. Projektseminare zur Einführung von technischen Informationssystemen bzw. PDM-Systemen
finden am Lehrstuhl Rechnerintegrierte Produktion, Heinz Nixdorf Institut, Universität Pader-
born bereits seit 1992 in unregelmäßigen Abständen statt. Einen ähnlichen Seminartyp in der
Lehre des Instituts für Produktentwicklung (PE) an der Technischen Universität München
beschreibt [Kar99].
12. Ein Traineeprogramm wird von vielen Unternehmen für Hochschulabsolventinnen/absolventen
zum systematischen Einstieg in die Berufspraxis angeboten. Die Unternehmen wollen hiermit in
der Regel ein Reservoir qualifizierter und praxisnaher Mitarbeiterinnen/Mitarbeiter mit mög-
lichst großer Verwendungsbreite heranbilden. Ein Traineeprogramm sieht üblicherweise ein
sechs bis 24 Monate dauerndes bereichsübergreifendes Ausbildungs- und Einarbeitungspro-
gramm vor. Gegen Ende des Traineeprogramms oder vor Beginn einer besonderen Vertiefungs-
phase entscheiden Unternehmen und Trainee gemeinsam, welcher zukünftige Aufgabenbereich
am ehesten den Fähigkeiten und Neigungen des Trainees entspricht. [WMN93, S. 265f],
[Ind01-ol]
Personalplanung und -entwicklung Seite 167
Ziel, Teilnahmevoraussetzungen und Ablauf werden im Folgenden dargestellt. Ein
detaillierter Plan mit Zeitplan, Beschreibung der einzelnen Ausbildungseinheiten
sowie den Übungsaufgaben befindet sich in Anhang E.
Ziel
Ziel des Ausbildungsprogrammes ist die Vorbereitung der Teilnehmerinnen und
Teilnehmer auf den Einsatz in Industrieprojekten. Sie sollen in die Lage versetzt
werden, unter Anleitung einer erfahrenen Projektleiterin bzw. eines erfahrenen
Projektleiters produktiv in Metaphase Einführungsprojekten mitzuarbeiten. Dazu
müssen sie Bedienung, Administration und Customizing (Anpassung) von Meta-
phase erlernen. Schwerpunkte ergeben sich dabei aus der Ausbildung und Eignung
der einzelnen Teilnehmerinnen und Teilnehmer.
Des weiteren sollen ihnen folgende allgemeine Kenntnisse vermittelt werden:
• Grundlagen des Produktdatenmanagements,
Bild 5-13: Ausschreibung für Teilnehmer am PDM-Traineeprogramm
Karrierechance Produktdatenmanagement
Wir führen in Zusammenarbeit mit großen, international agierenden Unternehmen
bei unseren Kunden Komplettlösungen zum Produktdatenmanagement ein. Wir
beraten unsere Kunden von der Unternehmensstrategie über die
Geschäftsprozeßoptimierung bis hin zur Systemeinführung.
Mit dem Produkt MetaphaseTM setzen wir auf Systemebene ein modernes,
international etabliertes Produkt mit herausragenden Eigenschaften ein. Für diesen
schnell wachsenden Markt suchen wir ab 01. August je drei
Ingenieure/ Techniker(innen)
bzw.
Informatiker/Softwareentwickler(innen)
mit Kompetenz und Erfahrung in:
• SW-Entwicklung in C/C++
• Objektorientierten SW-Konzepten
• Einsatz von RDBMS (z.B. Oracle)
• Unix und Windows NT
• Netzwerken in heterogenen Plattformen und TCP-/IP-Konzepten
In Teams mittlerer Größe unterstützen wir unsere Kunden über den gesamten
Einführungszyklus von der Erarbeitung der Anwenderspezifikation bis zur
Aufnahme des operativen Betriebes.
Verständnis über die Abläufe im Bereich der Produktentwicklung, Teamfähigkeit,
Organisationsgeschick und Eigeninitiative erleichtern Ihnen den Start bei uns.
Wir bieten Ihnen nach einem 5- bis 6-monatigen Trainee-Programm in diesem
Umfeld eine entwicklungsfähige Berater- bzw. Entwicklerposition in
internationalen Projekten mit attraktiven Konditionen und leistungsorientierter
Bezahlung.
Für zusätzliche Informationen wenden Sie sich bitte an:
Herrn Rainer Pusch, Tel.: 05251/69090-0, Fax: 05251/69090-99, email:
Ihre Bewerbungsunterlagen senden Sie bitte bis 21. Juli 1997 an:
UNITY AG
Kennwort: PDM Trainee
Technologiepark 19
33100 Paderborn
Seite 168 Kapitel 5
• Grundlagen der Projektarbeit,
• Grundlagen des Entwicklungsprozesses und des Einsatz von Informationssyste-
men (CAE),
• Grundlagen der PDM-Einführung.
Teilnehmer
Die Teilnehmer müssen folgende Einstellungsvorraussetzungen erfüllen:
• Abgeschlossene Ausbildung an einer Hochschule oder einer anderen weiterfüh-
renden technischen Ausbildungseinrichtung (Berufsakademie, Techni-
ker-Schule, BIB13 etc.) in den Bereichen Informatik, Maschinenbau,
Elektrotechnik, Wirtschaftsinformatik oder Wirtschaftsingenieurwesen,
• Kompetenz und Erfahrung erwünscht in:
• Softwareentwicklung mit C/C++,
• Objektorientierten Software-Konzepten,
• Einsatz von relationalen Datenbanken (z.B. Oracle),
• Betriebssystemen Unix und Windows NT sowie
• Netzwerken in heterogenen Plattformen und TCP-/IP-Konzepten.
Ablauf
Das Programm ist in zwei Blöcke geteilt. Im ersten Block von ca. drei Monaten
erhalten die Teilnehmer die notwendigen allgemeinen und Metaphase-spezifischen
Grundkenntnisse. Dieser Block enthält:
• den Metaphase-Basiskurs,
• die Metaphase Integrator Toolkit Schulung,
• den Metaphase-Kurs "Verteilte Umgebungen",
• regelmäßige Vorträge und Übungen zu den o. g. Grundlagen,
• angeleitete, praxisbezogene Übungen zu Metaphase und
• selbstständige, praxisbezogene Übungen zu Metaphase.
Im zweiten Block (ca. drei Monate) vertiefen die Teilnehmer unter Anleitung des
jeweiligen Projektleiters ihre Kenntnisse in konkreten Projekten vor Ort. Dabei
wird je nach Ausbildung und Verlauf des ersten Blocks ggf. eine Spezialisierung
sowohl im Bezug auf die zukünftige Tätigkeit als Consultant bzw. Implementierer
als auch in Bezug auf z.B. spezielle Module des Systems vorgenommen.
13. Bildungszentrum für informationsverarbeitende Berufe.
Personalplanung und -entwicklung Seite 169
5.3.3.4 Intensivtraining
Die Erfahrungen mit dem Traineeprogramm zeigen, dass die Ausbildungszeit
sowohl bei entsprechender Vorbildung in den Bereichen Programmierung und
Datenbanken als auch bei Quereinsteigern mit Berufserfahrung aus anderen Gebie-
ten der Informationstechnologie (z.B. ERP, Telekommunikation etc.) erheblich
verkürzt werden kann. Es müssen kaum Grundlagen vermittelt werden. Eine sol-
che Weiterbildungsmaßnahme beschränkt sich deshalb auf die Vermittlung des
systemspezifischen Wissens. Ein entsprechendes vierwöchiges Intensivtraining für
das System Metaphase wurde aus dem in Kapitel 5.3.3.3 beschriebenen Trainee-
programm abgeleitet und vom o.g. Beratungsunternehmen mehrfach durchgeführt.
Eine verkürzte Ausbildung kann ebenfalls stattfinden, wenn der Mitarbeiter sehr
spezialisiert eingesetzt werden soll. Dies gilt insbesondere für Netzwerk- und
Hardwarespezialisten, Systemadministratoren sowie Programmierer.
5.3.3.5 Außeruniversitäre Berufsausbildung
In Deutschland überwiegt in der Informationstechnologie zurzeit noch die akade-
mische Ausbildung [BMB00, S. 7f]. Dementsprechend dominierten bei den Teil-
nehmern der durchgeführten Trainee- bzw. Intensivprogramme die Hochschulab-
solventen. Durch die Einführung neuer Ausbildungsberufe14 im dualen
Ausbildungssystem15 im Jahre 1997 und das Angebot staatlich anerkannter Aus-
bildungseinrichtungen, die vor allem Studienabbrecherinnen und Studienabbrecher
ansprechen, wird mittlerweile die Lücke geschlossen16. Um das gesamte benötigte
Spektrum an Spezialisten für PDM-Projekte abdecken zu können, können sowohl
das Trainee- als auch das Intensivprogramm im Rahmen dieser außeruniversitären
Ausbildungen durchgeführt werden.
14. Es handelt sich um die staatlich anerkannten Ausbildungsberufe Fachinformatiker/-in (Anwen-
dungsentwickler), Fachinformatiker/-in (Systemintegration), Informatikkaufmann/-frau,
IT-Systemkaufmann/-frau, IT-Systemelektroniker/-in.
15. Die Ausbildung findet dabei im Wesentlichen an zwei Lernorten statt: Im Betrieb, in der die
berufspraktische Ausbildung erfolgt, und in der Berufsschule, in der die berufstheoretische Aus-
bildung dominiert. [WMN93, S. 88]
16. Es entsteht so eine breitere Basis an verschiedenen abgestuften Ausbildungs- und Einsatzmög-
lichkeiten mit unterschiedlichem Grad des Praxisbezuges wie sie es z.B. im Bereich des
Maschinenbaus oder der Elektrotechnik schon seit langem gibt (Betriebliche Ausbildung -
Technikerschule - Fachhochschule - Universität).
Seite 170 Kapitel 5
Zusammenfassung und Ausblick Seite 171
6 Zusammenfassung und Ausblick
PDM-Systeme bilden das Rückgrat der Datenverarbeitung in der Produktentwick-
lung. Die hohe strategische Bedeutung des hinter PDM stehenden Konzeptes und
die hohe Komplexität der PDM-Systeme führen in vielen Unternehmen zu Proble-
men bei der Einführung. Ein strukturiertes, methodisches Vorgehen unter Berück-
sichtigung der besonders betroffenen menschlichen Aspekte verspricht hier
Abhilfe.
Aus dieser Erkenntnis heraus ist ein Anforderungskatalog an ein Vorgehensmodell
zur PDM-Einführung mit integrierter Personalplanung und -entwicklung entwik-
kelt worden. Die Analyse bestehender Vorgehensmodelle zeigt, dass die Anforde-
rungen zur Zeit von keinem der Modelle alle erfüllt werden. Bestehende Vorge-
hensmodelle sind unvollständig, wenig durch Methoden unterstützt und
berücksichtigen im Rahmen der Personalplanung und -entwicklung lediglich den
Aspekt der Anwenderschulungen.
Es besteht also der Handlungsbedarf, ein Vorgehensmodell zu etablieren, das die
oben genannten Schwächen beseitigt und die PDM-Einführung anforderungsge-
recht unterstützt. Das Vorgehensmodell muss gekennzeichnet sein durch Vollstän-
digkeit, Durchgängigkeit im Methodeneinsatz, Integration in die Unternehmens-
strategie, Berücksichtigung PDM-spezifischer Aspekte sowie die
Berücksichtigung notwendiger Maßnahmen und Methoden zur Personalplanung
und -entwicklung.
Dieser Handlungsbedarf führt zur Entwicklung eines integrierten Vorgehensmo-
dells für die Einführung von PDM-Systemen. Das Vorgehensmodell beschreibt die
PDM-Einführung an Hand der durchzuführenden Aktivitäten, den dazu benötigten
Eingangsgrößen und der erzielten Ergebnisse. Außerdem nimmt es eine Zuord-
nung von Rollen zu den Aktivitäten vor. Es enthält zusätzlich einen Satz an aufein-
ander abgestimmten Methoden, die durchgängig alle Phasen der PDM-Einführung
unterstützen.
Aus den Aktivitäten des Vorgehensmodells wird abgeleitet, welche fachlichen und
humanorientierten Kompetenzen zur Bewältigung der darin enthaltenen Aufgaben
notwendig sind. So entsteht für jede Aufgabe ein Kompetenzprofil. Aufgaben mit
gleichen Kompetenzprofilen werden zu Rollen für die PDM-Einführung zusam-
mengefasst. Für jede Rolle wird zusätzlich der Aufwand geschätzt, der für die Auf-
gaben in den Aktivitäten aufgebracht werden muss.
Es ist ein Prozess definiert, wie die Rollen mit Mitarbeitern des Unternehmens
besetzt werden. Die Zuordnung geschieht auf Basis der Kompetenzprofile und der
Verfügbarkeit der Mitarbeiter. Ist ein Kompetenzdefizit vorhanden, das sich durch
eine Qualifizierungsmaßnahmen ausgleichen lässt, wird diese Maßnahme eingelei-
tet. Findet sich im Unternehmen kein passender Mitarbeiter für eine Rolle, wird
Seite 172 Kapitel 6
diese extern besetzt. Das Verfahren der Zuordnung entspricht dabei dem für die
internen Mitarbeiter. Abschließend sind Maßnahmen zur Qualifizierung für die
Projektarbeit, für Anwenderschulungen und für die berufliche Aus- und Weiterbil-
dung beschrieben.
Das vorgestellte integrierte Vorgehensmodell bietet für die PDM-Einführung fol-
genden Nutzen:
• Es beschreibt alle relevanten inhaltlichen und begleitenden Tätigkeiten, so dass
Versäumnisse bei der Planung einer PDM-Einführung vermieden werden.
• Es weist auf mögliche Schwierigkeiten bei der Durchführung der Aktivitäten
hin. Dadurch erleichtert es das Risikomanagement, was letztendlich zu besseren
Projektergebnissen führt.
• Die Methoden erleichtern die Durchführung der Aktivitäten. Ihre Durchgängig-
keit verhindert Fehler bei der Übertragung von Ergebnissen von einer Phase in
die nächste.
• Die integrierte Methode zur Personalplanung und -entwicklung ermöglicht den
effizienten und effektiven Einsatz der Mitarbeiter im Projekt und in den durch
die PDM-Einführung neu gestalteten Prozessen. Die Besetzung von Rollen auf
Basis der Kompetenzen führt zu höherer Arbeitsleistung und Motivation.
Aufbauend auf dieser Arbeit sollte sich zukünftige Forschung vor allem auf zwei
Bereiche konzentrieren. Zum einen sind die eingesetzten Methoden noch besser zu
integrieren, auf PDM-Spezifika anzupassen und durch weitere Methoden, z.B. zur
integrationsgerechteren Definition der Produktdaten, zu ergänzen. Auch die Unter-
stützung durch Werkzeuge für die Methoden bringt hier weiteren Nutzen. Zum
anderen besteht der Bedarf, empirisch zu ermitteln, inwieweit sich für bestimmte
Rollen unternehmens- und projektunabhängige Kompetenzprofile festlegen lassen.
Dadurch kann der relativ hohe Aufwand, der bei jeder PDM-Einführung für die
Ermittlung der Kompetenzprofile entsteht, verringert werden.
Eine Hürde zur vollständigen Umsetzung des Personalplanungsprozesses ist die
Tatsache, dass zur Zeit kein Marktplatz zur Beschaffung externer Mitarbeiter exi-
stiert, der eine Besetzung von Rollen über Kompetenzprofile ermöglicht. Da es
sich dabei um eine kommerzielle Vermittlungstätigkeit handelt, ist dies aber weni-
ger ein Problem der Forschung. Statt dessen ist es erforderlich, die mit der Vermitt-
lung verbundene Dienstleistung in ein tragfähiges Geschäftsmodell umzusetzen.
Literaturverzeichnis Seite 173
7 Literaturverzeichnis
[AB93] Abramovici, M. / Bickelmann, S.: Engineering Daten Manageement (EDM) Systeme -
Anforderungen, Stand der Technik und Nutzenpotentiale; in: CIM Management 5/
1993, S. 20-28
[Abe00] N.N.: Beating The Competition with Collaborative Product Commerce - Leveraging
the Internet for New Product Innovation; Aberdeen Group Inc., Boston, USA, 2000
[ABJ00] Anderl, R. / Daum, B. / John, H.: Produktdatenmanagement zum Management des
Produktlebenszyklus; in: ProduktDatenManagement 1/2000, S. 10-15
[Abr96a] Abramovici, M.: Informationsmanagement und -logistik mit
Engineering-Data-Management; in: VDI Bericht 1289 - Effiziente Anwendung und
Weiterentwicklung von CAD/CAM-Technologien; VDI-Verlag, Düsseldorf, 1996
[Abr96b] Abramovici, M.: EDM-Systemauswahl - Was zählt, ist nicht die Menge der Kriterien;
in: EDM-Report Nr. 1/1996, S. 12-15
[Abr96c] PDM-Technologie - Positionierung und Zukunftsperspektiven; in : PDM Info
Workshop, Siemens Nixdorf Informationssysteme, München, 1996
[Abr99] Abramovici, M.: EDM/PDM-Einführungstrategien - Erfahrungen und Perspektiven;
in: VDI Bericht 1497- Beschleunigung der Produktentwicklung durch EDM/PDM-
und Feature-Technologie; VDI-Verlag Düsseldorf, 1999
[AGL97] Abramovici, M. / Gerhard, D. / Langenberg, L.: Application of PDM Technology for
Product Life Cycle Management; in: Krause, F.-L. / Seliger, G. (Hrsg.) Life Cycle
Networks - Proceedings of the 4th CIRP International Seminar on Life Cycle
Engineering; Chapman & Hall, London, 1997
[AGL98] Abramovici, M. / Gerhard, D. / Langenberg, L.: Unterstützung verteilter
EntwicklungsProzesse durch EDM/PDM; in: VDI Bericht 1435 - Prozeßketten für die
virtuelle Produktentstehung in verteilter Umgebung; VDI-Verlag, Düsseldorf, 1998
[AGW+00] Alpar, P. / Grob, H.-L. / Weimann, P. / Winter, R.: Anwendungsorientierte
Wirtschaftsinformatik - Eine Einführung in die strategische Planung, Entwicklung und
Nutzung von Informations- und Kommunikationssystemen; 2. Auflage, Vieweg
Verlag, Braunschweig, 2000
[App97] Appelrath, H.-J. (Hrsg.): Jahresbericht des Oldenburger Forschungs- und
Entwicklungsinstitut für Informatik-Werkzeuge und -Systeme (OFFIS) 1997;
Oldenburg, 1997
[AS01] Abramovici, M. / Sieg, O.: PDM-Technologie im Wandel - Stand und
Entwicklungsperspektiven; in: Industrie Management 3/2001, S. 71-75
[Bal92] Balzert, H.: Die Entwicklung von Software-Systemen - Prinzipien, Methoden,
Sprachen, Werkzeuge; BI-Wissenschaftsverlag, Mannheim, 1992
[Bal93] Balzert, H. (Hrsg.): CASE - Systeme und Werkzeuge; BI-Wissenschaftsverlag,
Mannheim, 1993
[Bal96] Balzert, H.: Lehrbuch der Software-Technik - Software-Entwicklung; Spektrum Akad.
Verlag, Heidelberg, 1996
[Bau97] Baumeister, J.: Der Lebenszyklus der Software; in: IT Management 1/1997, S. 26-35
[BB96] Bourke, D. / Bartuli, G.: Product Life Cycle Tools; in: APICS - The Performance
Advantage 1/1996
[BD93] Bröhl, A.-P. / Dröschel, W.: Das V-Modell - Standard für die Softwareentwicklung
mit Praxisleitfaden; Oldenbourg Verlag, München, 1993
[BDD+98] Benn, Wolfgang et. al.: ISO 10303 (STEP) - Datenaustauschformat oder
Modellierungsbasis?; in: Industrie Management Special - Engineering Management
1997/1998, S. 34-37
[Bee95] Beeck, H.: Prozeßorientierte Qualifizierung für die rechnerintegrierte Fertigung; in:
Schubert, S. (Hrsg.): Innovative Konzepte für die Ausbildung, 6. GI Fachtagung
Informatik und Schule INFOS ’95; Springer Verlag, Berlin, 1995
Seite 174 Literaturverzeichnis
[Ben00] Bender, K.: Einführungsstrategien für Engineering-Werkzeuge zur integrierten
Produktentwicklung; in: Lindemann, U. (Hrsg.): Arbeits- und Ergebnisbericht
1997-2000 des SFB 336, Transferbereich 2; Technische Universität München, 2000
[Ber99] Bernhard, M.: Rechenknecht - IT-Controlling entwickelt sich zum qualitativen
Erfolgsfaktor; in: IT Management 12/1999, S. 64-71
[BF96] Biskup, H. / Fischer, T..: Vorgehensmodelle - Versuch einer begrifflichen Einordnung
- Vorstellung erster Ergebnisse einer Arbeitsgruppe der Fachgruppe 5.1.1; in:
Leitungsgremium des GI-FA 5.1 (Hrsg.): Rundbrief 2/96 des Fachausschusses 5.1
"Management der Anwendungsentwicklung und -wartung"; Karlsruhe, 1996
[BH99] Baake, U. / Haußmann, D.: Optimising distributed product development by global
EDM/PDM introduction; in: VDI Bericht 1497- Beschleunigung der
Produktentwicklung durch EDM/PDM- und Feature-Technologie; VDI-Verlag
Düsseldorf, 1999
[BHK00] Barra, R. / Hauser, M. / Kindrick, J.: Usage Guide for the STEP PDM Schema Release
4.1; PDM Implementor Forum, 2000
[BHM96] Bullinger, H.-J. / Hartmann, R. / Marcial, F.: Marktstudie Engineering Data
Management Systeme - EDM als strategischer Erfolgsfaktor im innovativen
Unternehmen; Fraunhofer-Institut für Arbeitswirtschaft und Organisation IAO,
Stuttgart, 1996
[BFR+98] Bullinger, H.-J. et al.: Marktstudie Engineering Data Management Systeme - EDM als
strategischer Erfolgsfaktor im innovativen Unternehmen; 2. Auflage, Fraunhofer-
Institut für Arbeitswirtschaft und Organisation IAO, Stuttgart, 1998
[Bia98] Bianchi, R.: SFS Stadler elimiert Routinejobs - CAD-EDM-Lösung erschließt
Rationalisierungspotential; in: CAD-CAM-Report 12/1998, S. 56-60
[Bie98] Bierling, T.: EDM und Database Publishing - Königsweg für die technische
Dokumentation; in: EDM-Report Nr. 2/1998, S. 66-68
[BK97] Bauhofer, M. / Knechtel, U.: Integration von PDM- mit CAE-Systemen; in:
EDM-Report Nr. 3/1997, S. 50-52
[BKK+92] Budde, R. / Kautz, K. / Kuhlenkamp, K. / Züllighoven, H.: Prototyping - An Approach
to Evolutionary System Development; Springer-Verlag, Berlin, 1992
[Blä98] Blätz, W.: Aus fremden Fehlern lernen; in: Office Management 10/1998, S. 10-11
[BMB00] N.N.: Analyse und Evaluation der Softwareentwicklung in Deutschland; Studie des
Bundesministeriums für Bildung und Forschung (BMBF), Berlin, 2000
[Boe88] Boehm, Barry: A Spiral Model of Software Development and Enhancement; in: IEE
Computer, Mai 1998, S. 61-72
[Boo94] Booch, G.: Objektorientierte Analyse und Design: Mit praktischen
Anwendungsbeispielen;
Addisson-Wesley, Bonn, Paris, Reading Mass, 1994
[Bre97] Brexel, D.: Methodische Strukturmodellierung komplexer und variantenreicher
Produkte des integrativen Maschinenbaus; Dissertation am Heinz Nixdorf Institut der
Universität-GH Paderborn; HNI Verlagsschriftenreihe Band 32, Paderborn, 1997
[BRJ99] Booch, G. / Rumbaugh, J. / Jacobson, I.: Das UML-Benutzerhandbuch;
Addison-Wesley-Verlag, München, 1999
[BS98] Boczanski, M. / Schenk, M.: EDM/PDM-Auswahl - Erst die Flexibilität, dann das
Maß; in: Industrie Management Special - Engineering Management 1997/1998, S.
18-19
[BS00] Bange, C.; Schinzer, H.: Aufbauhilfe und Prozeßsteuerung - ETL-Werkzeuge für das
Data Warehouse; in: IT-Fokus 7/2000, S. 10-16
[Bul92] Bullinger, H.-J.: Personalentwicklung und -qualifikation. Springer Verlag, Berlin,
1992
[Bur95] Burgartz, D.: QM-Handbuch der Softwareentwicklung - Muster und Leitfaden nach
DIN ISO 9001; Vieweg Verlag, Braunschweig/Wiesbaden, 1995
Literaturverzeichnis Seite 175
[Bur97] Burger, A.: Methode zum Nachweis der Wirtschaftlichkeit von Investitionen in die
rechnerintegrierte Produktion; Dissertation am Heinz Nixdorf Institut der
Universität-GH Paderborn; HNI Verlagsschriftenreihe Band 22, Paderborn, 1997
[BW93] N.N.: Software-Entwicklungs-Standard der Bundeswehr "Methodenstandard";
Allgemeiner Umdruck. Nr. 251/Rü T III 1, 1993
[CAE96] N.N.: CAE Poll Results - Who’s to Blame for Schedule Slips?; in: Computer-Aided
Engineering 10/1996
[Cie96] Cieslok, M.: Dokumentenmanagement und Worklow - Lohnt sich die Anschaffung für
unser Unternehmen?; in: in: IT Management 10/1996
[Cim00] CIMdata Inc.: PDM Buyer’s Guide 6th and 7th Edition; CIMdata Inc., Ann Arbor, MI,
USA, 2000
[Cim02-ol] CIMdata Inc.: PLM Market Outlook Solid Despite Economic Downturn; unter: http://
www.cimdata.com/press-releases/PR02-0731.html, 06.10.2002
[CM97] Christmann-Jacoby, H. / Maas, R.: Wissensmanagement im Projektumfeld auf Basis
von Internet-Technologien; in: Information Management 3/1997, S. 16-26
[DF93] Dedering, H. / Feig, G.: Personalplanung und Weiterbildung im Betrieb - ein Lern-
und Arbeitsbuch; Deutscher Universitäts-Verlag, Wiesbaden, 1993
[DHP+99] Deimel, B. et al.: Die Praxis der Softwareentwicklung - Eine Erhebung; in: Informatik
Spektrum (1999) 22, S. 24-36
[DIN77] DIN 199, T. 1-5: Begriffe im Zeichnungs- und Stücklistenwesen; Beuth-Verlag,
Berlin, 1977
[DIN85] DIN 6763: Nummerung - Grundbegriffe; Beuth-Verlag, Berlin, 1985
[DIN90] DIN 6789: Dokumentationssystematik, Teil 1 bis Teil 3; Beuth-Verlag, Berlin, 1990
[DIN92] DIN 4000-1: Sachmerkmal-Leisten; Begriffe und Grundsätze; Beuth-Verlag, Berlin,
1992
[Dob98] Doblies, M.: Globales Produktdatenmanagement zur Verbesserung der
Produktentwicklung; in: Uhlmann, E. (Hrsg.): Berichte aus dem
Produktionstechnischen Zentrum Berlin; Fraunhofer IPK, Berlin, 1998
[Dre96] Dreßler, A.: Mitarbeiterqualifikation für optimierte GeschäftsProzesse; in: ZWF 91
(1996) 9, S. 412-414
[Dri96] Driemeyer, A.: PDM als Integrationsdrehscheibe für ein mittelständisches
Unternehmen der Automobilzuliefererindustrie: in: 5. Internationaler EDM-Kongreß,
Düsseldorf, 1996
[Dud90] Duden Band 5 - Das Fremdwörterbuch; 5. Auflage, Duden Verlag, Mannheim, 1990
[Dür99] Dür, B.: EDM/PDM-Beratung und Systemeinführung; in: EDM-Report Nr. 2/1999, S.
62-67
[Dum00] Dumke, R.: Software Engineering - Eine Einführung für Informatiker und Ingenieure:
Systeme, Erfahrungen, Methoden, Tools; 2. Auflage, Vieweg Verlag, Braunschweig,
2000
[Dun00] Dunne, K.: RapidPDM Implementation Methodology - Deliverable D72/D73 of
RapidPDM Project (ESPRIT 26892); Galway, 2000
[Dun01] Dunne, K.: RapidPDM Implementation Methodology Handbook - Deliverable D82 of
RapidPDM Project (ESPRIT 26892); Galway, 2001
[EBL95] Eversheim, W. / Bochtler, W. / Laufenberg; L.: Simultaneous Engineering - von der
Strategie zur Realisierung. Erfahrungen aus der Industrie für die Industrie; Berlin,
1995
[EH98] Eigner, M. / Haesner, D.: Konfigurationsmanagement als integrierter Teil von PDM;
in: EDM-Report Nr. 3/1998, S. 24-28
Seite 176 Literaturverzeichnis
[Ehr95] Ehrlenspiel, K.: Integrierte Produktentwicklung - Methoden für Prozeßorganisation,
Produkterstellung und Konstruktion; Carl Hanser Verlag, München, 1995
[Eig91] Eigner, M.: Engineering Database - Strategische Komponente in CIM-Konzepten;
Hanser Verlag, München, 1991
[Eig96] Eigner, M.: Technische Informationssysteme - Stand der Technik am Beispiel eines
PDM/EDM-Systems; in: ZWF 91 (1996) 9, S. 395-397
[EK92] Esser, U. / Kemmner, G.-A.: Arbeitsorganisation und Qualifikation bei
rechnerintegrierter Produktion; Campus Verlag, Frankfurt, 1992
[ER93] Eigner, M. / Rüdinger, W.: Betriebliche Einführung von EDM-Systemen; in: CIM
Management 5/1993, S. 43-48
[ERW96] Eversheim, W. / Ritz, P. / Walz, M.: Einsatz einer Engineering Data Base -
Erfahrungen und Potentiale; in: VDI Bericht 1289 - Effiziente Anwendung und
Weiterentwicklung von CAD/CAM-Technologien; VDI-Verlag, Düsseldorf, 1996
[ES01] Eigner, M. / Stelzer, R.: Produktdatenmanagement-Systeme - Ein Leitfaden für
Product Development und Life Cycle Management; Springer Verlag, Berlin, 2001
[Fah95] Fahrwinkel, U.: Methode zur Modellierung und Analyse von GeschäftsProzessen zur
Unterstützung des Business Process Reengineering; HNI Verlagsschriftenreihe,
Paderborn, 1995
[FH96] Friedmann, T.: Kein Ei gleicht dem anderen - Auswahl und Test von EDM-Systemen;
in: EDM-Report Nr. 2/1996, S. 29-33
[FHD+00] Fischer, J. et al.: Bausteine der Wirtschaftsinformatik - Grundlagen, Anwendungen,
PC-Praxis; 2. vollständig überarbeitete Auflage, Erich Schmidt Verlag, Berlin, 2000
[Fis98] Fischer, W.: Automatische Erstellung technischer Dokumentationen; in: EDM-Report
Nr. 1/1998, S. 26-31
[Fis99] Fischer, W.: EDM/PDM versus DMS - Unterschiede und Gemeinsamkeiten; in:
EDM-Report Nr. 1/1999, S. 44-49
[FJS98] Friedmann, T. / Jungfermann, W. / Schmid, C.: Global Engineering - Welchen Beitrag
leisten EDM-Systeme und das Internet?; in: EDM-Report Nr. 4/1998, S. 40-43
[Fri96] Friedmann, T.: EDM als ’Enabling technology’ - Eine Standortbestimmung nach 8
Jahren Beratung in EDM-Projekten; in: 5. Internationaler EDM-Kongreß, Düsseldorf,
1996
[Fur98] Furrer, M.: Maximale Systemverfügbarkeit durch ausfallsichere Hardware; in:
EDM-Report Nr. 1/1998, S. 14-21
[FW99] Frank, J. / Wagner, T.: Integration eines PDM-Systems in die
ProduktentstehungsProzesse eines Automobil-Zulieferers; in: VDI Bericht 1497-
Beschleunigung der Produktentwicklung durch EDM/PDM- und Feature-Technologie;
VDI-Verlag Düsseldorf, 1999
[GA98] Grabowski, H. / Adamietz P.: Prozeßorientiertes Customizing von EDM/
PDM-Systemen; in: VDI Bericht 1435 - Prozeßketten für die virtuelle
Produktentstehung in verteilter Umgebung; VDI-Verlag, Düsseldorf, 1998
[Gar02] N.N.: The Most Important Concerns of Enterprise IT Managers; Gartner Group,
Stamford, CT, USA, 2002
[Gau87] Gausemeier, J.: CAD/CAM-Systeme in der Fertigungsautomatisierung;
atp-Sonderheft Fertigungsautomatisierung, Oldenbourg-Verlag, München, 1987
[Gau96] Gausemeier, J. (Hrsg.): First European Workshop on Global Engineering Networking;
HNI Verlagsschriftenreihe Band 13, Paderborn, 1996
[Gau97] Gausemeier, J. (Hrsg.): GEN ’97 - International Symposium on Global Engineering
Networking; HNI Verlagsschriftenreihe Band 20 + 21, Paderborn, 1997
Literaturverzeichnis Seite 177
[GBK+00] Gausemeier, J. et al.: Virtual Web Plant - Ein Internet-basiertes
Projektinformationssystem für den Anlagenbau; in: Tagungsband CAD 2000 -
Kommunikation, Kooperation, Koordination; Berlin, 2000
[GEK01] Gausemeier, J. / Ebbesmeyer, P. / Kallmeyer, F.: Produktinnovation - Strategische
Planung und Entwicklung der Produkte von morgen; Hanser Verlag, München, 2001
[Gei00] Geiger, T. F.: Gedanken und Vorschau zum Erfolgsfaktor „P“; in: Proceedings der
European Engineering User Conference 2000; kec&m Verlag, München, 2000
[Ger00] Gerhard, D.: Erweiterung der PDM-Technologie zur Unterstützung verteilter
kooperativer Produktentwicklungsprozesse; Schriftenreihe Institut für
Konstruktionstechnik, Universität Bochum; Shaker Verlag, Aachen, 2000
[GF99] Gausemeier, J. / Fink, A.: Führung im Wandel - Ein ganzheitliches Modell zur
zukunftsorientierten Unternehmensgestaltung; Carl Hanser Verlag, München, 1999
[GFG98] Gausemeier, J. / Flath, M. / Grasmann, M.: Geschäftsprozeßübergreifendes
Produktstrukturmanagement - Integration der bereichsspezifischen Sichten bei der
durchgängigen rechnergestützten Entwicklung von variantenreichen Erzeugnissen; in:
VDI-Bericht 1434 - Effektive Entwicklung und Auftragsabwicklung variantenreicher
Produkte; VDI-Verlag, Düsseldorf, 1998
[GG97] Grabowski, H. / Geiger, K. (Hrsg.): Neue Wege zur Produktentwicklung; Raabe
Verlag, Stuttgart, 1997
[GGP+97] Gausemeier, J. / Grasmann, M. / Pusch, R. / Schneider, W.: Integrierte Produkt- und
Prozeßmodellierung - ein Ansatz zur schnelleren Einführung von Engineering Daten
Management-Systemen; in: VDI Bericht 1357 - Neue Generationen von CAD/
CAM-Systemen - Erfüllte und enttäuschte Erwartungen; VDI-Verlag, Düsseldorf,
1997
[GGP+98] Gausemeier, J. / Grasmann, M. / Pusch, R. / Siebe, A.: Von semantischen
Geschäftsprozeßmodellen zu Prozeßspezifikationen für EDM-Systeme; in: ZWF 93
(1998) 7-8, S. 320-324
[GHI+00] Golla, K.-M. / Heinz, S. / Iselborn, B. / Wüseke, P.: CAD-Geometrie alleine reicht auf
Dauer nicht aus - Übertragung von PDM-Produktstrukturen und Organisationsdaten
mit STEP in der Automobilindustrie; in: Konstruktion 11/12-2000, S. 32-34
[GHK+97] Gausemeier, J. / Hahn, A. / Kespohl, H. / Schneider, W.: Integrated Process and
Product Data modeling - An Approach to speed up the Implementation of Product
Data Technology; Proceedings of the European Conference Product Data Technology
Days 1997, Sophia Antipolis, 1997
[GK99] Gausemeier, J. / Kuhle, J.-P.: Prozeßorientiertes Projektmanagement -
Einsystematischer Ansatz für die Gestaltung und das Management von
EntwicklungsProzessen; in: Industrie Management 4/1999, S. 9-13
[GKP+98] Gausemeier, J. / Kespohl, H. / Pusch, R. / Seifert, L.: Gateway Integration of Global
Engineering Networking (GEN) and Product Data Management (PDM); Proceedings
of IiM 98 - Changing the Ways We Work, Göteborg, 1998
[GLK+99] Gausemeier, J. / Lewandowski, S. / Kespohl, H. / Pusch, R. / Seifert, L.: Gateway
Integration of Global Engineering Networking (GEN) and Product Data Management
(PDM); WDK-Schriftenreihe - Proceedings of the 12th International Conference on
Engineering Design (ICED 99), München, 1999
[GLR+00] Gausemeier, J. / Lindemann, U. / Reinhart, G. / Wiendahl, H.-P.: Kooperatives
Produktengineering - ein neues Selbstverständnis des ingenieurmäßigen Wirkens; HNI
Verlagsschriftenreihe Band 79, Paderborn, 2000
[GLS+97] Gausemeier, J. / Lewandowski, A. / Siebe, A. / Fink, A.: Rechnerunterstützte Methode
zur Optimierung von GeschäftsProzessen; in: ZwF-CIM 92 (1997) 7-8
[GLS+98] Gausemeier, J. / Lewandowski, A. / Siebe, A. / Soetebeer, M.: Comprehensive
object-oriented Method for Strategic Business Process Design; in: Proceedings of
ProSTEP Science Days ‘98, Product Data Technology Facing the Future, Wuppertal,
17. - 18. Juni 1998
Seite 178 Literaturverzeichnis
[Göt98] Göttsch, N.: EDM-Systeme sorgen für reibungslose Prozeßabläufe; in: Industrie
Management Special - Engineering Management 1997/1998, S. 45-47
[Gra00] Grasmann, M.: Produktkonfiguration auf Basis von Engineering Data
Managementsystemen - Eine Methode zum Aufbau und zur Pflege der Wissensbasis
von Konfigurationssystemen und deren Einsatz in VerkaufProzessen; Dissertation am
Heinz Nixdorf Institut der Universität-GH Paderborn; HNI Verlagsschriftenreihe Band
75, Paderborn, 2000
[Gro98] Gronau, N.: Migration von Engineering Management Systemen in den Mittelstand; in:
Industrie Management Special - Engineering Management 1997/1998, S. 11-17
[GS98] Gehrke, U. / Scheibler, M.: Ein effektives Produktdatenmanagement - Rückgrat für die
virtuelle Produktentstehung in: VDI Bericht 1435 - Prozeßketten für die virtuelle
Produktentstehung in verteilter Umgebung; VDI-Verlag, Düsseldorf, 1998
[GSE+98] Grandke, S. / Schmitt, P. / Emmerich, H. / Hentschel, W.: Schlüsselqualifikationen in
neuen Organisationsformen - Ein Katalog für die Praxis; DIN Deutsches Institut für
Normung e.V. (Hrsg.), Beuth Verlag, Berlin, 1998
[Gut99] Guthmann, M.: Start ohne Risiko - Management von PDM-Projekten; in: CAD World
3(1999), S. 88-89
[Hah98] Hahn, A.: Integrationsumgebung für verteilte objektorientierte Ingenieursysteme;
Dissertation am Heinz Nixdorf Institut der Universität-GH Paderborn; HNI
Verlagsschriftenreihe Band 33, Paderborn, 1998
[Has00] Hase, M.: Konstruktion ohne Stillstand; in: Information Week 29/2000, S. 144
[Hat00] Hattwig, J.: Projekt- und Qualitätsmanagement - Lemminge sind keine Vorbilder; in:
Information Week 6/2000, S. 66-67
[Hel99] Helms, R. W.: RapidPDM PDM Functions- Deliverable D51 of RapidPDM Project
(ESPRIT 26892); Eindhoven, 2000
[Hes99] Hesel, J.: Neue Aufgaben für Plot-Management-Systeme; in: EDM-Report Nr. 4/1999,
S. 42-37
[Hes00] Hesel, J.: Dokumente und Daten über das internet elegant verteilen; in: EDM-Report
Nr. 2/2000, S. 32-37
[HM00a] Hartmann, J. / Müller, P.: Digitale Archivierung und Output-Management im Umfeld
von SAP-PLM - Teil 2; in: EDM-Report Nr. 3/2000, S. 28-30
PDM als Grundlage für Archivierung und Plotmanagement
[HM00b] Hartmann, J. / Müller, P.: Digitale Archivierung und Output-Management im Umfeld
von SAP-PLM - Teil 2; in: EDM-Report Nr. 4/2000, S. 62-65
[Höf99] Höfener, C.: Methode zur Bewertung des strategischen Nutzens von integriertem
Produktdaten-Management (PDM); in: Darmstädter Forschungsberichte für
Konstruktion und Fertigung; Shaker Verlag, Aachen, 1999
[Hön98] Hönicke, I.: Qualitäts - Gütesiegel für Berater; in: Office Management 10/1998, S.
10-11
[Hor98] Horn, H.: Die Einführung von EDM-Systemene in mittelständischen Unternehmen; in:
Industrie Management Special - Engineering Management 1997/1998, S. 6-10
[HS97] Hellwig, H. / Sanders, H.: Integration 3D-CAD und EDM/PDM - Möglichkeiten und
Grenzen; in: VDI Bericht 1357 - Neue Generationen von CAD/CAM-Systemen -
Erfüllte und enttäuschte Erwartungen; VDI-Verlag, Düsseldorf, 1997
[HS99] Hermanns, A. / Sauter, M.: Management-Handbuch Electronic Commerce -
Grundlagen, Strategien, Praxisbeispiele; Verlag Franz Vahlen, München, 1999
[HSS95] Hameri, A. / Schinzel, J. / Sulonen, R.: Engineering Data Management and System
Support the Main Process Functions of a Large-Scale Project; LHC Note 361,
MT-Division, CERN, Genf (Schweiz), 1995
[Hub00] Huber, T.: Größer als Oracle; in: Netinvestor 11/2000, S. 108
Literaturverzeichnis Seite 179
[Hum00] Humbert, A.: Einführung von 3D-CAD und PDM im Spezialmaschinenbau - Theorie
<> Praxis - Ein Erfahrungsbericht; in: VDI Bericht 1569 - Produkte entwickeln im
realen Umfeld - Was bringen neue Werkzeuge wie 3D-CAD/CAM, EDM/PDM und
Virtualisierung?; VDI-Verlag, Düsseldorf, 2000
[IDS01] IDS-Scheer Taschenwörterbuch 3 - Customer Relationship Management; IDS Scheer
AG, Saarbrücken, 2001
[IIC00] IBM / ITM / CIMdata: International Benchmark Study on „Benefits of Product Data
Management in the Manufacturing Industry“; in: CEFE Arbeitsgruppe 45 -
Langzeitarchivierung und EDM/PDM-Systeme, Workshop vom 07. Dezember 1999,
Hannover, 1999
[Ind01-ol] N.N.: Industrie-Job.de Bewerbungs-Lexikon; unter: http://www.industrie-job.de/
lexikon.shtml, 01.08.2001
[Inf98a] N.N.: Das Risiko falscher IT-Beratung wächst; in: Information Week 18/1998, S.
16-18
[Inf98b] N.N.: Reengineering ist ein Irrweg; in: Information Week 10/1998, S. 20-22
[Inf99] N.N.: IT-Dienstleistungen - Hilfe erwünscht; in: Information Week 22/1999, S. 30-42
[Inf00a] N.N.: IT-Support - das verdrängte Problem; in:
[Inf00b] N.N.: Pauken im Netz; in: Information Week 24/2000, S. 36-41
[ISO94] ISO 9001: Quality Systems - Models for quality assurance in design/development,
production, installation and servicing; International Standardization Organisation,
1994
[ISO95] ISO/IEC 12207: Information Technology - Software life cycle processes; International
Standardization Organisation, 1995
[ISO96] DIN V ENV ISO 10303-STEP: Industrielle Automatisierungssysteme und Integration
- Produktdatendarstellung und -austausch; Beuth Verlag GmbH, Berlin, 1996
[JS96] Jungfermann, W. / Schmidt, S.: EDM-PPS-Kopplung - Orientierung an den Prozessen
führt zum Erfolg; in: EDM-Report Nr. 1/1996, S. 42-49
[Jac95] Jacobson, I.: Object oriented software engineering - a use case driven approach - 4.
Auflage; Addison Wesley, Wokingham, 1995
[JBR99] Jacobson, I. / Booch, G. / Rumbaugh, J.: The Unified Software Development Process;
Addison-Wesley, Reading, USA, 1999
[Kah00] Kahlert, Toralf: Konzeption eines webbasierten Beratungs-Unterstützung-Systems am
Fallbeispiel einer PDM-Systemauswahl; Fraunhofer-Institut für Produktionsanlagen
und Konstruktionstechnik (IPK), Berlin, 2000
[Kar99] Karcher, A.: Produktdatentechnologie in der Lehre - „Learning by doing“; in:
Produktdatenjournal 1/1999, ProSTEP Verein zur Förderung internationaler
Produktdatennormen e.V., Darmstadt, 1999
[KB00] Kaiser, J. / Berninger, A.: Ganzheitliches Änderungsmanagement für verteilte
Produktentwicklung mit PDM und ERP am Beispiel der KUKA Roboter GmbH; in:
VDI Bericht 1569 - Produkte entwickeln im realen Umfeld - Was bringen neue
Werkzeuge wie 3D-CAD/CAM, EDM/PDM und Virtualisierung?; VDI-Verlag,
Düsseldorf, 2000
[Kel96] Kelch, M.: Auswahl und Einführung eines EDM-Systems; in: Reinhart, G. / Milberg,
J.: Seminarberichte iwb 24 - Engineering Data Management; Herbert Utz Verlag
Wissenschaft, München, 1996
[Kel98] Kelch, M.: Konzeption, Auswahl und Einführung von EDM/PDM-Systemen; in:
Reinhart, G. / Milberg, J.: Seminarberichte iwb 31 - Engineering Data Management -
Erfahrungsberichte und Trends; Herbert Utz Verlag Wissenschaft, München, 1998
[KFV99] Karcher, A. / Fischer, F. / Viertlböck, M.: EDM/PDM-System als Rückgrat der
Integrierten Produktentwicklung - ein modulares Einführungs- und
Integrationskonzept; in: VDI Bericht 1497- Beschleunigung der Produktentwicklung
durch EDM/PDM- und Feature-Technologie; VDI-Verlag Düsseldorf, 1999
Seite 180 Literaturverzeichnis
[KHB00] Kindrick, J. / Hauser, M. / Barra, R.: Usage Guide for the STEP PDM Schema Release
4.1; PDM Implementor Forum, 2000
[Kie95] Kief, H. B.: NC/CNC Handbuch; Carl Hanser Verlag, München, 1995
[Kir96] Kirchmer, M.: GeschäftsProzeßorientierte Einführung von Standardsoftware -
Vorgehen zur Realisierung strategischer Ziele; Gabler, Wiesbaden, 1996
[KJV96] Krause, F.-L.; Jansen, H.; Vollbach, A.: Modularität von EDM-Systemen; in: ZWF 91
(1996) 3, S. 109-111
[Kle01] Kleinken-Palma, C.: Neues Gesetz knebelt Unternehmen; in: Information Week 16/
2001, S. 60-64
[KLS+92] Kieback, A. / Lichter, H. / Schneider-Hufschmidt, M. / Züllighoven, H.: Prototyping in
industriellen Software-Projekten; in: Informatik Spektrum (1992) 15, S. 65-77
[KM95] Kay, C. / Madden, D.: Critical Sucess Factors in Implementing Product Data
Management; in: International Journal of Micrographics & Optical Technology Vol.
13, No. 4/95, S. 191-194
[Kno93] Knolmayer, G.: Modelle zur Unterstützung von Outsourcing-Entscheidungen; in:
Kurbel, K. (Hrsg.): Wirtschaftsinformatik ’93 - Innovative Anwendungen,
Techonolgie, Integration; Physica Verlag, Heidelberg, 1993
[Kra99] Krause, J.: Praxishandbuch Electronic Commerce; Carl Hanser Verlag, München,
1999
[KRA+98] Kempis, R.-D. et al.: Do IT Smart - Chefsache Informationstechnologie, auf der Suche
nach Effektivität; Wirtschaftsverlag Carl Ueberreuter, Frankfurt/M., 1998
[Kru99] Kruchten, Philippe: Der Rational Unified Process - Eine Einführung; Addison-Wesley,
München, 1999
[Krz99] Krzepinski, A.: Nutzenorientierung - Zentraler Faktor in PDM-Projekten; in: CAD
World 5 (1999), S. 66-68
[Küh01] Kühn, S.: GDPdU - Neue Herausforderung für Daten-Management-Systeme?; in:
EDM-Report Nr. 4/2001, S. 44-46
[Kup01] Kupper, H.: Zur Kunst der Projektsteuerung - Qualifikation und Aufgaben eines
Projektleiters - aufgezeigt am Beispiel von DV-Projekten; 9. völlig überarbeitete
Auflage, R. Oldenburg Verlag, München, Wien, 2001
[KW98] Karcher, A. / Wirtz, J.: STEP-basierte objektorientierte Anforderungsmodellierung zur
PDM-Systemspezifikation; in: Produktdatenjournal 1/1998, ProSTEP Verein zur
Förderung internationaler Produktdatennormen e.V., Darmstadt, 1998, S. 24-27
[KW99] Karcher, A. / Wirtz, J.: From drawing administration to Virtual PDM - managing the
paradigm shift; International EDM/PDM Symposium 99. Heidelberg-Wiesloch,
Germany, 1999
[KW00] Karcher, A. / Wirtz, J.: The PDM Enablers data model as a reference model for the
customization of PDM-Systems; in: ECEC'2000 - 7th European Concurrent
Engineering Conference, Leiscester, United Kingdom, 2000
[KWF00] Karcher, A. / Wirtz, J. / Fischer, F.: Das PDM Enablers-Datenmodell als
Referenzmodell für das Customizing von PDM-Systemen; in: Industrie Management
Special - ProduktDatenManagement 2 (2000), S. 23-28
[Lan00] Lang, R.: Schlüsselqualifikationen; Deutscher Taschenbuchverlag, München, 2000
[Led96] Ledermann, A.: Unternehemensweite Einführung eines PDM-Systems: in: 5.
Internationaler EDM-Kongreß, Düsseldorf, 1996
[Lem01] Lemke, J.: Nutzenorientierte Planung des Einsatzes von CAD- / CAE-Systemen;
Dissertation am Heinz Nixdorf Institut der Universität-GH Paderborn; HNI
Verlagsschriftenreihe Band 91, Paderborn, 2001
[Ler00] Lermer, J.: Gestufte EDM/PDM-Systemeinführung; in: Konstruktion 3-2000, S. 21-22
Literaturverzeichnis Seite 181
[Lew00] Lewandowski, A.: Methode zur Gestaltung von Leistungserstellungsprozessen in
Industrieunternehmen; Dissertation am Heinz Nixdorf Institut der Universität-GH
Paderborn; HNI Verlagsschriftenreihe Band 68, Paderborn, 2000
[LFH99] Lashin, G. / Feldhusen, J. / Heuer, R.: Integration von EDM/PDM zur globalen
Entwicklung von Schienenfahrzeugen; in: VDI Bericht 1497- Beschleunigung der
Produktentwicklung durch EDM/PDM- und Feature-Technologie; VDI-Verlag
Düsseldorf, 1999
[Lin97] Linner, S.: 3D-CAD - Wettbewerbsfaktor oder nur teurer Weg zur Zeichnung?; in:
VDI Bericht 1357 - Neue Generationen von CAD/CAM-Systemen - Erfüllte und
enttäuschte Erwartungen; VDI-Verlag, Düsseldorf, 1997
[LLH00] Lewandowski, S. / Lewandowski, A. / Herzberg, J.: Integriertes Teilemanagement in
3D-Konstruktionsumgebungen - Prozeßorientierte Kopplung von ERP/PPS, EDM/
PDM, CAD- und Normteilsystemen am Beispiel des Adtranz-Konzerns; in: VDI
Bericht 1569 - Produkte entwickeln im realen Umfeld - Was bringen neue Werkzeuge
wie 3D-CAD/CAM, EDM/PDM und Virtualisierung?; VDI-Verlag, Düsseldorf, 2000
[LK96] Lermer, J. / Kießling, G.: Auswahl und Einführung eines PDM-Systems im
Siemens-Geschäftsgebiet Installationsgeräte und -systeme; in: VDI Bericht 1289 -
Effiziente Anwendung und Weiterentwicklung von CAD/CAM-Technologien;
VDI-Verlag, Düsseldorf, 1996
[LM99a] Lermer, J. / Muschiol, M.: Erfolgreiche EDM/PDM-Systemeinführung durch gestufte
Vorgehensweise; in: VDI Bericht 1497- Beschleunigung der Produktentwicklung
durch EDM/PDM- und Feature-Technologie; VDI-Verlag Düsseldorf, 1999
[LM99b] Lämmer, L. / Machner, B.: Online-PDM-Kopplung auf der Basis von Standards –
STEP PDM Schema und OMG PDM Enablers; in: ProduktDaten Journal, 6. Jahrgang,
November 1999, S. 7-9
[Mal97a] Malle, B.: Datenbestände auf lange Zeit gesichert - Teil I; in: EDM-Report Nr. 1/1997,
S. 40-45
[Mal97b] Malle, B.: Datenbestände auf lange Zeit gesichert - Teil II; in: EDM-Report Nr. 2/
1997, S. 26-29
[Man95] Manji, J.F.: Making PDM Pay; in: Machine Design 6/1995, S. 81-84
[Mar99] Martin, R.: Dynamisches DV-Projektmanagement bei der Einführung von
ERP-Systemen; in: Industrie Management4/1999, S. 35-38
[Mei01] Meier, P.: Der Kunde steht im Mittelpunkt; in: EDM-Report Nr. 4/2001, S. 40-43
[MMH97] Matthes, J. / Marcial, F. / Hartmann, R.: Engineering Data Management in der
betrieblichen Praxis; in: EDM-Report Nr. 1/1997, S. 34-39
[MR95] Marks, P. / Riley, K.: Aligning Technology for Best Business Results - A Guide for
Selecting and Implementing Computer-aided Design and Manufacturing Tools;
Design Insight, Los Gatos, USA, 1995
[Mül90] Müller, J.: Arbeitsmethoden der Technikwissenschaften - Systematik, Heuristik,
Kreativität; Springer Verlag, Berlin, 1990
[Mül00a] Müller, P.: Produktdatenmanagement mit SAP R/3; in: Industrie Management Special
- ProduktDatenManagement 1 (2000), S. 24-26
[Mül00b] Müller-Meernach, R.: Digitale Archivierung und Zeichnungsreproduktion im Wnadel
der Zeit; in: EDM-Report Nr. 2/2000, S. 38-45
[Mur01] Murgai, M.: PDM-Marktstudie 2000 für Deutschland; in: EDM-Report Nr. 2/2001,
S.26-29
[Mut99] Muth, M.: Produktdatenmanagement - Eine Herausforderung im Entwicklungsprozeß;
in: ZIPaktuell 2/1999, S. 2-6
[Neu98] Neubauer, M.: IT-Kooperationen - Der Berater als Mittler; in: Office Management 10/
1998, S. 10-11
[Nik99] Nikol, G.: Viewer - wohin geht die Entwicklung; in: EDM-Report Nr. 3/1999, S.
34-39
Seite 182 Literaturverzeichnis
[Nik00] Nikol, G.: Viewer sind mehr als nur Visualisierungswerkzeuge; in: EDM-Report Nr.
4/2000, S. 34-39
[Nor95] Norton, R.L.: Push Information, not Paper; in: Machine Design 12/1994, S. 105-109
[Oes98] Oestereich, B. : Objektorientierte Softwareentwicklung - Analyse und Design mit der
Unified Modeling Language; 4. Auflage, R. Oldenbourg Verlag, München, 1998
[OHJ+98] Oestereich, B. (Hrsg.) et al.: Erfolgreich mit Objektorientierung - Vorgehensmodelle
und Managementpraktiken für die objektorientierte Softwareentwicklung; R.
Oldenburg Verlag, München, Wien, 1999
[OMG92] N.N.: Object Management Architecture; Object Management Group, Document
Number 92.11.1, London, 1992
[OMG99] N.N.: STEP and OMG Product Data Management Specification - A Guide for
Decision Makers - Draft; Object Management Group, London, 1999
[OMG00] N.N.: Product Data Management Enablers Specification Version 1.3; Object
Management Group, London, 2000
[OMG01] Lämmer, Lutz: OMG PDM Enablers Usage Guide - Draft C; Object Management
Group, London, 2001
[PB96] Pomberger, G. / Blaschek, G.: Software Engineering - Prototyping und
objektorientierte Software-Entwicklung; 2. Auflage, Carl Hanser Verlag, München,
1996
[PB97] Pahl, G. / Beitz, W.: Konstruktionslehre - Methoden und Anwendung; 4. Auflage,
Springer Verlag, Berlin, 1997
[PDM02-ol] PDMIC (Product Data Management Information Center) - Project Watch Survey;
unter: http://www.pdmic.com/XXX, 20.02.2002
[PHM00] Pels, H. J. / Helms, R. W. / Mandemaker, T. H.: RapidPDM - Faster Implemenatation
of PDM; in: Proceedings of PDT Days 2000, Noordwijk, Niederlande, 2000
[PI96] Ploenzke Informatik: EDMS katalog; in: 5. Internationaler EDM-Kongreß,
Düsseldorf, 1996
[PK00] Prahalad, C. / Krishan, M.: So lässt sich Qualität von Software bewerten; in: Harvard
Business Manager 2/2000, S. 48-57
[Pla96] Platt, K. E.: Notwendigkeit und Grundlagen für ein integriertes
Konfigurationsmanagement; in: 5. Internationaler EDM-Kongreß, Düsseldorf, 1996
[Pör98] Pörtner, Rainer: Daten im Entwicklungsprozeß durchgängig nutzen; in: EDM-Report
Nr. 3/1998, S. 38-42
[Pot97] Potthof, I.: Chancen und Risiken des IV-Outsourcing; in: Industrie Management 5/
1997, S. 32-36
[PP98] Potthast, P. / Pluszynski, K.: Trends und für den Aufbau einer IT-Infrastruktur in
EDM/PDM-Projekten; in: Industrie Management Special - Engineering Management
1997/1998, S. 42-44
[PS94] Pagel, B.-U. / Six, H.-W.: Software Engineering - Band 1: Die Phasen der
Softwareentwicklung: Addison-Wesley, Bonn, 1994
[PS00] Pulfer, R. / Schmid, U.: Der Objekt-Orientierte Weg - Prozessmodell für den Bau und
die Beschaffung komponentenbasierter Systeme; Pulinco AG, Zollikofen, 2000
[PWC98] N.N. (Price Waterhouse Change Integration Team): Warum IT-Projekte scheitern; in:
Information Week 21/1998, S. 16-22
[Rad00] Rademeier, E.: Durchlaufzeiten drastisch verkürzt; in: EDM-Report Nr. 3/2000, S.
44-48
[RBP+91] Rumbaugh, J. / Blaha, M. / Premerlani, W. / Eddy, F. / Lorensen, B.: Object-Oriented
Modeling and Design; Prentice Hall, Englewood Cliffs, 1991
[Rei99] Reimann, N.: Business-Reengineering bei Danfoss; in: EDM-Report Nr. 1/1999, S.
16-22
Literaturverzeichnis Seite 183
[Ren98] Rensmann, J.: IT-Dienstleistungen - Drum prüfe, wer sich bindet; in: Office
Management 10/1998, S. 10-11
[Rie96] Ries, R.: PDM Implementation - From Prototype to Pilot Application: in: 5.
Internationaler EDM-Kongreß, Düsseldorf, 1996
[RK01] Richter, K. / Krause, L.: Erfolgreicher Einsatz von Produktdatenmanagement als
Schlüsseltechnologie für E-Business; in: Industrie Management 3/2001, S. 81-85
[Row98] Rowell, A.: PDM sports a new look; in: Computer Graphics World 2/1998, S. 42-46
[Rud95-ol] Rudy, M.: Ten Steps to Ensuring a Successful PDM-Project; unter: http://
www.pdmic.com/articles/art10stp.html, 11.01.2001
[Sch94] Scholz, C.: Personalmanagement - Informationsorientierte und verhaltenstheoretische
Grundlagen; 4. verbesserte Auflage, Verlag Franz Vahlen, München, 1994
[Sch96] Schäfer, H.: Engineering-Teams im Mittelpunkt - Steigerung der Kernkompetenz
durch Simultaneous Engineering; in: VDI Bericht 1289 - Effiziente Anwendung und
Weiterentwicklung von CAD/CAM-Technologien; VDI-Verlag, Düsseldorf, 1996
[Sch97] Schmich, M.: PDM als Integrationsdrehscheibe zur Logistik - Kopplungsstrategie von
CAD/EDB mit SAP; in: VDI Bericht 1357 - Neue Generationen von CAD/
CAM-Systemen - Erfüllte und enttäuschte Erwartungen; VDI-Verlag, Düsseldorf,
1997
[Sch98a] Scharf, A..: Auf dem Weg zur virtuellen Produktion; in: Monitor - Die Zeitschrift für
den erfolgreichen Computereinsatz 7-8/1998
[Sch98b] Scheer, A.-W.: ARIS - Modellierungsmethoden, Metamodelle, Anwendungen;
Springer Verlag, Berlin, 1998
[Sch98c] Scheer, A.-W.: ARIS - vom Geschäftsprozeß zum Anwendungssystem; Springer
Verlag, Berlin, 1998
[Sch98d] Schittko, K.: Kopplung von EDM und PPS; in: Industrie Management Special -
Engineering Management 1997/1998, S. 55-57
[Sch99] Schöttner, J.: Produktdatenmanagement in der Fertigungsindustrie; Carl Hanser
Verlag, München, 1999
[Sch00a] Schmitz, B.: Collaborating into the Future; in: Computer-Aided Engineering 3/2000
[Sch00b] Schuster, M.: Serviceleistungen und Teledienste im Internet; in: VDI-Bericht 1537 -
Der Ingenieur im Internet; VDI-Verlag, Düsseldorf, 2000
[Sei96] Seiche, W.: Praxisbericht - EDM-Einführung mit CAD- und PPS-Integration; in:
Reinhart, G. / Milberg, J.: Seminarberichte iwb 24 - Engineering Data Management;
Herbert Utz Verlag Wissenschaft, München, 1996
[SFB+00] Schätz, B. et al.: Abschlußbericht der Vordringlichen Aktion des Bundesministeriums
für Bildung und Forschung - Entwicklung, Produktion und Service von Software für
eingebettete Systeme in der Produktion; VDMA Verlag, Wiesbaden, 2000
[Sin96-ol] Singh, R.: International Standard ISO/IEC 12207 - Software Life Cycle Processes;
unter: http://www.abelia.com/docs/12207cpt.pdf, 15. 03.2001
[Sin99-ol] Singh, R.: An Introduction to International Standard ISO/IEC 122ß7 - Software Life
Cycle Processes; unter: http://www.abelia.com/docs/12207tut.pdf, 15.03.2001
[SH97] Stich, J. / Hoffmann, A.: 2D/3D-Normteiltechnologie in CAD/PDM-Systemen; in:
EDM-Report Nr. 1/1997, S. 16-23
[She95] Shelley, T.: How Data Drives The Whole Business; in: Eureka 4/1995, S. 43-45
[SK97a] Spur, G. / Krause, F.-L.: Das virtuelle Produkt - Management der CAD-Technik;
Hanser Verlag, München, 1997
[SK97b] Stanek, J. / Kursawe, G.: Integration der Informationsquellen des Konstrukteurs -
Aufbau eines benutzerfreundlichen globalen Informationssystems; in: VDI Bericht
1357 - Neue Generationen von CAD/CAM-Systemen - Erfüllte und enttäuschte
Erwartungen; VDI-Verlag, Düsseldorf, 1997
Seite 184 Literaturverzeichnis
[SL98] Schmidt, U. / Lozinski, V.: Implementierungsstrategien für integrierte
ProduktetnwicklungsProzesse; in: EDM-Report Nr. 3/1998, S. 20-23
[SMT98] Stelzer, D. / Mellis, W. / Taube, F.: Stand des Qualitätsmanagements in der
Softwareentwicklung; in: Hummeltberg, W. (Hrsg.): Information Management for
Business and Competitive Intelligence and Excellence; Proceedings der
Frühjahrstagung Wirtschaftsinformatik’98, Wiesbaden, 1998, S. 313-326
[Som98] Sompek, H.: Concurrent Engineering - Wunsch oder Wirklichkeit?; in:
CAD-CAM-Report Nr. 9/1998, S. 64-69
[Son99] Sonntag, K.-H. (Hrsg.): Personalentwicklung in Organisationen; 2. überarbeitete und
erweiterte Auflage, Hogrefe-Verlag, Göttingen, 1999
[Spu94] Spur, G. (Hrsg.): Fabrikbetrieb; Carls Hanser Verlag, München, 1994
[Spu96] Spur, G.: Externe Beratungsleistung gewinnbringend nutzen; in: ZWF 91 (1996) 12, S.
580-581
[SR98] Schäfer, D. / Roller, D.: Parametrische Produkt- und Prozeßmodellierung; in:
CAD-CAM-Report Nr. 10/1998, S. 75-80
[SS96] Strohmayr, R.; Suhm, A.: Einführung von Produktdaten-Managementsystemen; in:
ZWF 91 (1996) 9, S. 402-405
[SS97] Schulz, C. / Schäffer, P.: Informationstechnik für Manager - Von Internet bis
Workflow - Chancen und Risiken erkennen und bewerten; Carl Hanser Verlag,
München, 1997
[Sta91] Staehle, W.: Management - Eine verhaltenswissenschaftliche Perspektive; Verlag
Frank Vahlen, München, 6. Auflage, 1991
[Ste97] Stelzer, R.: Neue Technologien bei der Integration von CAD- und PDM-Systemen; in:
VDI Bericht 1357 - Neue Generationen von CAD/CAM-Systemen - Erfüllte und
enttäuschte Erwartungen; VDI-Verlag, Düsseldorf, 1997
[Ste00] Stelzer, R.: Erweiterte PDM-Funktionen zum Produktentwicklungs- und
Lifecycle-Management; Konstruktion 9-2000, S. 40-42
[Str00] Strasser, E.: Change Management im Engineering - Die Handhabung von
menschlichen Schwierigkeiten systematisch planen und organisieren; in: Proceedings
der European Engineering User Conference 2000; kec&m Verlag, München, 2000
[Stü98] Stümpfig, T.: Soll man auf den fahrenden PDM-Zug aufspringen?; in: EDM-Report
Nr. 13/1998, S. 32-36
[SV96] Stark, J. / Vajna, S.: Reengineering vor der EDM-Einführung; in: EDM-Report Nr. 2/
1996, S. 65-71
[TH96] Thome, R. / Hufgard, A.: Continuous System Engineering; Vogel Verlag, Würzburg,
1996
[TSS00] Tönshoff, H. K. / Schmidt, B. C. / Seidemann, H.: Co-operative Product Engineering
(CPE) - A new Approach to Simultaneous Engineering; in: Proceedings of 2nd CIRP
International seminar in Intelligence Computation in Manufacturing Engineering
(ICME2000); Capri, Italy, 2000
[Uni00] Universität Paderborn (Hrsg.): Personal und Vorlesungsverzeichnis Wintersemester
2000/2001; Paderborn, 2000
[Uni01a] Universität Paderborn (Hrsg.): Vorlesungsverzeichnis Sommersemester 2001;
Paderborn, 2001
[Uni01b-ol] N.N.: Universität Paderborn - Fachbereich 5 - Wirtschaftwissenschaften:
Kommentiertes Vorlesungsverzeichnis; unter: http://wiwi.uni-paderborn.de/,
24.07.2001
[Uni01c-ol] N.N.: Universität Paderborn - Fachbereich 10 - Maschinentechnik: Kommentiertes
Vorlesungsverzeichnis; unter: http://wwwhni.uni-paderborn.de/rip/lehre/
kvlz_fb10_neu/index.php3, 24.07.2001
Literaturverzeichnis Seite 185
[Uni01d-ol] N.N.: Universität Paderborn - Fachbereich 17 - Mathematik und Informatik:
Studienveranstaltungen im Fach Informatik ; unter: http://www.uni-paderborn.de/cs/
studium/veranstaltungen.html, 24.07.2001
[Uni01e] Universität Paderborn (Hrsg.): Studienordnung für den integrierten
Diplomstudiengang Wirtschaftsingenieurwesen an der Universität Paderborn;
Paderborn, 2001
[Vaj97] Vajna, S.: CAD/CAM-Systeme - Leistungsstand und Entwicklungsrichtungen; in:
VDI Bericht 1357 - Neue Generationen von CAD/CAM-Systemen - Erfüllte und
enttäuschte Erwartungen; VDI-Verlag, Düsseldorf, 1997
[Vaj99] Vajna, S.: Die neue Richtlinie 2219 - Praxiserprobte Hinweise zu
Einführungsstrategien und Wirtschaftlichkeit von EDM/PDM-Systemen; in: VDI
Bericht 1497- Beschleunigung der Produktentwicklung durch EDM/PDM- und
Feature-Technologie; VDI-Verlag Düsseldorf, 1999
[VDI99] N.N.: VDI-Richtlinie 2219 - Datenverarbeitung in der Konstruktion - Einführung und
Wirtschaftlichkeit von EDM/PDM-Systemen; VDI-Verlag, Düsseldorf, 1999
[VDI02a] N.N.: Stellenanzeige für einen PDM-Experten; in: VDI nachrichten, 8. März 2002, Nr.
10; VDI-Verlag, Düsseldorf, 2002
[VDI02b-ol]N.N.: Ingenieurbedarf 2000; Studie des Vereins deutscher Ingenieure e.V.: unter:
http://www.vdi.de/vdi/vrp/s_reporte/02348/index.php, 07.10.2002
[Ver00] Versteegen, G.: Projektmanagement mit dem Rational Unified Process; Springer
Verlag, Berlin, 2000
[VS97] Vajna, S. / Stark, J.: Wirtschaftlichkeit von EDM-Systemen; Océ Schriftenreihe PDM,
Band 4; Océ-Deutschland GmbH, Mülheim a.d. Ruhr, 1997
[VVB+98] Vitel, E. / Vilela, J. B. / Baake, U. / Haussmann, D.: Introduction of Virtual Product
Development in practice; in: VDI Bericht 1435 - Prozeßketten für die virtuelle
Produktentstehung in verteilter Umgebung; VDI-Verlag, Düsseldorf, 1998
[Weh00] Wehlitz, P.: Nutzenorientierte Einführung eines Produktdatenmanagement-Systems;
Dissertation, Technische Universität, München, 2000
[Wen95-ol] Wendt, D.: Klassische Fehler der Software-Entwicklung; CEFE - CAD/CAM
Entwicklungsgesellschaft, Arbeitsgruppe 19, Software Engineering; unter: http://
www.fb9dv.uni-duisburg.de/cefe/klassische-fehler.htm, 26.02.2001
[Wen01a] Wendenburg, M.: Nutzung und Nutzen des Produktdatenmanagements; Océ
Schriftenreihe PDM, Band 6; Océ-Deutschland GmbH, Mülheim a.d. Ruhr, 2001
[Wen01b] Wendenburg, M.: Elektronische Marktplätze als Integrationsplattform für b2b; in:
Produktdatenjournal 2/2001, ProSTEP Verein zur Förderung internationaler
Produktdatennormen e.V., Darmstadt, 2001
[Wet97] Wetjen, K.-H.: Outsourcing erleichtert Einführung komplexer Standardsoftware; in:
Industrie Management 5/1997, S. 51-53
[WFG99] Wenge, B. / Freisleben, D. / Gerhard, D.: Einführung eines EDM/PDM-Systems in
einem Unternehmen des öffentlichen Personennahverkehrs (ÖPNV); in: VDI Bericht
1497- Beschleunigung der Produktentwicklung durch EDM/PDM- und
Feature-Technologie; VDI-Verlag Düsseldorf, 1999
[Wid96] Widmer, H.-J.: Optimierung der Prozeßketten in der Produktentwicklung mit Hilfe
rechnergestützter kooperativer Konstruktionsarbeit; in: VDI Bericht 1289 - Effiziente
Anwendung und Weiterentwicklung von CAD/CAM-Technologien; VDI-Verlag,
Düsseldorf, 1996
[Wie98] Wiechmann, A.: Groupware und Internettechnologien im verteilten
Entwicklungsverbund - Auswirkungen auf EDM-Systeme; in: Reinhart, G. / Milberg,
J.: Seminarberichte iwb 31 - Engineering Data Management - Erfahrungsberichte und
Trends; Herbert Utz Verlag Wissenschaft, München, 1998
[Wil90] Wildemann, H.: Einführungsstrategien für die computerintegrierte Produktion (CIM);
Gesellschaft für Manegement und Technologie Verlag, München, 1990
Seite 186 Literaturverzeichnis
[Wir99-ol] Wirtz, J.: Einführungsstrategien und Customizing von PDM-Systemen; unter: http://
www.itm.tum.de/Forschung/em/schwerpunkte/edm_pdm_3.asp, 30.04.1999
[Wir01] Wirtz, J.: Ein Referenzmodell zur integrationsgerechten Konzeption von
Produktdatenmanagement; Herbert Utz Verlag - Wissenschaft; München, 2001
[WM00] Windmüller, T. / Müller, R.: Maximale Prozeßsicherheit durch EDM-Lösung; in:
Industrie Management Special - ProduktDatenManagement 1 (2000), S. 27-30
[WMN93] Weber, W. / Mayrhofer, W. / Nienhüser, W.: Grundbegriffe der Personalwirtschaft;
Schäffer-Poeschel Verlag, Stuttgart, 1993
[Zah98] Zahn, R.: Vorbereitung einer EDM-Systemeinführung und Systemauswahl; in:
Reinhart, G. / Milberg, J.: Seminarberichte iwb 31 - Engineering Data Management -
Erfahrungsberichte und Trends; Herbert Utz Verlag Wissenschaft, München, 1998
[ZAS00a] Zetzl, R. / Ahle, U. / Schmitt, J.: Das e-Business verlangt neue Dienstleistungformen -
Teil II; in: EDM-Report Nr. 3/2000, S. 32-35
[ZAS00b] Zetzl, R. / Ahle, U. / Schmitt, J.: Das e-Business verlangt neue Dienstleistungformen -
Teil II; in: EDM-Report Nr. 4/2000, S. 58-61
Anhang
Inhaltsverzeichnis Seite
A Abkürzungsverzeichnis . . . . . . . . . . . . . . . . . . . . . . . . 1
B Vorgehensmodell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
B.1 Zuordnung der Methoden zu den Aktivitäten des
Vorgehensmodells . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
C Katalog humanorientierter Kompetenzen . . . . . . . . . 1
C.1 Dimension Persönlichkeit . . . . . . . . . . . . . . . . . . . . . . . . 1
C.2 Dimension Intellekt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
C.3 Dimension Motivation/Antrieb. . . . . . . . . . . . . . . . . . . . . 2
C.4 DimensionFührung/Coaching. . . . . . . . . . . . . . . . . . . . . 2
C.5 Dimension Effizientes Handeln. . . . . . . . . . . . . . . . . . . . 2
C.6 Dimension Kommunikation. . . . . . . . . . . . . . . . . . . . . . . 2
C.7 Dimension Kooperation . . . . . . . . . . . . . . . . . . . . . . . . . 3
D Wahlpflichfach Produktdatenmanagement . . . . . . . . 1
D.1 Schwerpunktbildung der Wahlfächer . . . . . . . . . . . . . . . 1
D.2 Steckbriefe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
E Traineeprogramm für PDM-Consultants und
Implementierer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
E.1 Ablaufplan des Programms . . . . . . . . . . . . . . . . . . . . . . 1
E.2 Beschreibung der Ausbildungsblöcke . . . . . . . . . . . . . . 3
E.3 Übungsaufgaben . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
E.3.1 Aufgabe C1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
E.3.2 Aufgabe E1: . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
E.3.3 Aufgabe I1:. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
E.3.4 Aufgabe J1: . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
E.3.5 Aufgabe K1: . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
E.3.6 Aufgabe L1: . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
ii Anhang
Abkürzungsverzeichnis A-1
A Abkürzungsverzeichnis
API Application Programming Interface
ARIS Architektur integrierter Informationssysteme
ASP Application Service Providing
B2B Business-to-Business
B2C Business-to-Consumer
BIB Bildungszentrum für informationsverarbeitende Berufe
BPR Business Process Reengineering
CAD Computer Aided Design
CAE Computer Aided Engineering
CIM Computer Integrated Manufacturing
CORBA Common Object Request Broker Architecture
CPC Collaborative Product Commerce
CRM Customes Relationship Management
CSCW Computer Supported Cooperative Work
DBMS Database Management System
DIN Deutsches Institut für Normung
DMS Dokumentenmanagementsystem
DMU Digital Mockup
DOS Disk Operating System
DTP Desktop Publishing
DV Datenverarbeitung
DXF Data Exchange Format
EDB Engineering Database
EDM Engineering Data Management
EMV Elektromagnetische Verträglichkeit
ERP Enterprise Resource Planning
FEM Finite Elemente Methode
FTP File Transfer Protocol
A-2 Anhang
GDPdU Grundsätze für den Datenzugriff und die Prüfung
digitaler Unterlagen
GEN Global Engineering Networking
HNI Heinz Nixdorf Institut
HTML Hypertext Markup Language
HTTP Hypertext Transfer Protocol
HW Hardware
IAO Institut für Arbeitswirtschaft und Organisation
IGES Initial Graphics Exchange Specification
ISO International Standardisation Organisation
IT Informationstechnik
KM Konfigurationsmanagement
L-PDM Lokales PDM
LCM Lifecycle Management
LKT Lehrstuhl für Konstruktionstechnik
MKS Mehrkörpersimulation
NC Numerical Control
OMEGA Objektorientierte Methode zur Geschäftsprozessmodellierung
und -analyse
OMG Object Management Group
OO objektorientiert
PDM Produktdatenmanagement
PDMI Product Data Management based on International Standards
PDMS Produktdatenmanagementsystem
PLM Product Lifecycle Management
PM Projektmanagement
PPS Produktionsplanung und -steuerung
QM Qualitätsmanagement
QS Qualitätssicherung
RUP Rational Unified Process
SC Subcommittee
SCM Supply Change Management
Abkürzungsverzeichnis A-3
SE Simultaneous Engineering
SFB Sonderforschungsbereich
SGDT Système de Gestion des Donées Techniques
SKM Softwarekonfigurationsmanagement
SML Sachmerkmalleisten
STEP Standard for the Exchange of Product model Data
SW Software
SWE Softwareentwicklung, Softwareentwicklung
SWKE Softwarekonfigurationsmanagement
SWS Semesterwochenstunden
TC Technical Committee
TCP/IP Transmission Control Protocol/Internet Protocol
TDM Team Data Manager
TIM Technische Informationsmanagement
UML Unified Modeling Language
USDP Unified Software Development Process
V-Modell Vorgehensmodell
VDI Verein deutscher Ingenieure
WWW World Wide Web
XML eXtensible Markup Language
A-4 Anhang
Vorgehensmodell B-1
B Vorgehensmodell
B.1 Zuordnung der Methoden zu den Aktivitäten des
Vorgehensmodells
Die folgenden Tabelle ordnet die in Kapitel 4.7 beschriebenen Methoden den Akti-
vitäten des Vorgehendmodells zu.
Tabelle B-1: Unterstützung der Aktivtäten des Vorgehensmodells durch die
Methoden
OMEGA+
Prototyping
Best Practices
USDP
Programmierschnittstellen
Weitere Methoden
Strategische Bedeutung und Nutzenpotentia-
le des PDM-Konzeptes vermitteln (P1.1.1) XXX
Unternehmensspezifische strategische Ziele
mit PDM-Relevanz ermitteln (P1.1.2) XX
1
PDM-relevante Unternehmensbereiche iden-
tifizieren (P1.1.3) X
Projektpaten bestimmen (P1.1.4) X
Ablauforganisation analysieren (P1.2.1) X
IT-Infrastruktur analysieren (P1.2.2) X
Laufende Strategie- und IT-Projekte analy-
sieren (P1.2.3) X2
Stakeholder ermitteln (P1.2.4) X
Veränderungsgrad analysieren (P1.2.5) X3
Schwachstellen identifizieren (P1.3.1) X X
Verbesserungspotentiale ermitteln (P1.3.2) X X
Wirtschaftliche Ziele festlegen (P1.3.3) X
Über Beginn der Systemauswahl entschei-
den (P1.3.4) n/a4
Sollprozessmodell entwerfen (P2.1.1) X X X
Grobes Datenmodell entwerfen (P2.1.2) X X
B-2 Anhang
Anforderungskatalog erstellen (P2.1.3) X X
Marktrecherche durchführen (P2.2.1) n/a
Systemvergleich durchführen (P2.2.2) X X5
Short List bilden (P2.2.3) X6
Testszenarien definieren (P2.3.1) X
Benchmarks planen (P2.3.2) X X
Benchmarks durchführen (P2.3.3) X X X
Systeme vergleichen (P2.3.4) X7
Entscheidung für ein System treffen (P2.3.5) n/a
Systemmodule analysieren (P2.4.1) X X
Umsetzungsreihenfolge für Funktionalität
festlegen (P2.4.2) X
Begleitende Aktivitäten planen (P2.4.3) X
Anwendungsfälle definieren (P3.1.1) X X X
Datenmodell spezifizieren (P3.1.2) X X X
Dialogdesign entwerfen (P3.1.3) X X X
Schnittstellen definieren (P3.1.4) X X X
Berechtigungskonzept definieren (P3.1.5) X X
Tests planen (P3.1.6) X X
Pflichtenheft erstellen (P3.1.7) X X
Systemanpassung (P3.2) X X X
Komponenten testen (P3.3.1) X X
Integrationstests durchführen (P3.3.2) X X
Tabelle B-1: Unterstützung der Aktivtäten des Vorgehensmodells durch die
Methoden
OMEGA+
Prototyping
Best Practices
USDP
Programmierschnittstellen
Weitere Methoden
Vorgehensmodell B-3
Performancetests durchführen (P3.3.3) X X
Anwendungstest durchführen (P3.3.4) X X
Implementierung dokumentieren (P3.3.5) X X X
Hardware beschaffen (P3.4.1) n/a
Hardware installieren (P3.4.2) X
Schulungsunterlagen erstellen (P3.4.3) X X X8
Schulungen durchführen (P3.4.4) n/a
Datenmigration durchführen (P3.4.5) X X
Produktivstart durchführen (P3.4.6) n/a
Change Management (P3.5.1) X X X X9
Qualitätsmanagement (P3.5.2) X X X
Dokumenten- und Softwarekonfigurations-
management (P3.5.3) X10
1. Balanced Scorecard
2. Projekt-Roadmap
3. Humanorientierte Kompetenzprofile
4. Nicht anwendbar, keine Methode vorhanden
5. Nutzwertanalyse
6. Nutzwertanalyse
7. Nutzwertanalyse
8. Kompetenzprofile
9. Kompetenzprofile
10. Konfigurationsmanagementmethoden
Tabelle B-1: Unterstützung der Aktivtäten des Vorgehensmodells durch die
Methoden
OMEGA+
Prototyping
Best Practices
USDP
Programmierschnittstellen
Weitere Methoden
B-4 Anhang
Katalog humanorientierter Kompetenzen C-1
C Katalog humanorientierter Kompetenzen
Die folgende Liste dient als Grundlage für die Beschreibung der für die Bewälti-
gung einer Aufgabe notwendigen humanorientierten Kompetenzen und für die
Bewertung der bei den Mitarbeitern vorhandenen Kompetenzen. Die Kompeten-
zen sind zu sieben Dimensionen zusammengefasst. [GSE+98]
C.1 Dimension Persönlichkeit
• Aufrichtigkeit/Offenheit
• Belastbarkeit
• Durchsetzungsvermögen
• Innovationsfreude
• Konsequenz
• Konzentrationsvermögen
• Optimismus
• Problemlösungsfähigkeit
• Risikobereitschaft
• Selbstvertrauen
• Selbstwahrnehmung
• Soziale Unabhängigkeit
• Urteilvermögen
• Veränderungsbereitschaft
• Verantwortung übernehmen
• Zuverlässigkeit
C.2 Dimension Intellekt
• Auffassungsgabe
• Denken in Zusammenhängen
• Geistige Flexibilität
• Intuitiv-kreatives Denken
• Lernpotential
• Merkfähigkeit
• Räumliches Vorstellungsvermögen
• Systematisch-analytisches Denken
• Technisches Verständnis
C-2 Anhang
C.3 Dimension Motivation/Antrieb
• Begeisterungsfähigkeit
• Berufliche Perspektive
• Durchhaltevermögen
• Eigeninitiative
• Einsatzbereitschaft
• Kreativität
• Leistungbereitschaft
• Lernbereitschaft und Fortbildungsstreben
C.4 DimensionFührung/Coaching
• Delegationsfähigkeit
• Effektivität
• Entscheidungen treffen
• Mitarbeiter fördern
• Mitarbeiter motivieren
• Objektivität/Neutralität
• Vorbildfunktion
• Ziele setzen
C.5 Dimension Effizientes Handeln
• Arbeitstempo
• Kostenbewusstsein
• Profitbewusstsein
• Qualitätsbewusstsein
• Selbstorganisation
• Zielstrebiges Handeln
C.6 Dimension Kommunikation
• Angemessenes Kommunikationsniveau
• Auftreten
• Mündliches Ausdrucksvermögen
• Fachsprache (mündlich)
• Fremdsprache (mündlich)
• Rhetorische Fähigkeiten
Katalog humanorientierter Kompetenzen C-3
• Überzeugungskraft
• Zuhören können
• Schriftliches Ausdruckvermögen
• Fachsprache (schriftlich)
• Fremdsprache (schriftlich)
C.7 Dimension Kooperation
• Einbeziehung anderer
• Einfühlungsvermögen
• Feedback-Bereitschaft
• Führbarkeit
• Informationsaustausch
• Kompromissfähigkeit
• Konfliktfähigkeit
• Kontaktfähigkeit
• Loyalität
• Teamdisziplin
• Toleranz
• Unterstützung und Beratung
C-4 Anhang
Wahlpflichfach Produktdatenmanagement D-1
D Wahlpflichfach Produktdatenmanagement
Die folgenden Tabellen und Darstellungen dienen zur Detaillierung des in Kapitel
5.3.3.2 beschriebenen Wahlpflichtfaches „Produktdatenmanagement (PDM)“.
D.1 Schwerpunktbildung der Wahlfächer
Tabelle D-1 zeigt die Möglichkeiten zur Schwerpunktbildung innerhalb des Wahl-
pflichtfaches.
Tabelle D-1: Schwerpunktbildung im Wahlfplichtfach PDM
Veranstaltungsname A1C P
Produktdatenmanagement (PDM) P2PP
Einführung von Produktdatenmanagementsytemen P P P
ABWL: Management (Personal und Organisation) X
Arbeitswissenschaft und Industriebetriebslehre X X
Berechnungsverfahren des Maschinenbaus X
Betriebliche Anwendungssysteme und Anwendungsmanagement X
Betriebliche Kommunikationssysteme und Kommunikationsmanagement
(Electronic Business) X
CAE-Anwendungsprogrammierung in einer höheren Programmiersprache X
Datenbanken 1 X
Datenbanken 2 X
Datenmanagement: Datenbanken und Datenmodellierung X X
Einführung in das Qualitätsmanagement X X
Einführung in das Qualitätsmanagement(Übung) X X
Entwicklung mechatronischer Systeme in der Automobilindustrie X X
Grundlagen der Konstruktionssystematik X
Grundlagen des Informationsmanagements am Arbeitsplatz X X X
Grundlagen von Web-Based Systems X X
Implementierung von Benutzungsschnittstellen X
Industrieinformatik X X X
Industrieinformatik (Übung) X X X
Informationsmodelle, -methoden und -systeme für das Logistikorientierte
Produktionsmanagement (ILP) XX
Innovations- und Entwicklungsmanagement (IEM) X
Konstruktionsmethodik X
Konstruktionssystematik und rechnergestütztes Konstruieren (CAD) X
D-2 Anhang
Konstruktionssystematik und rechnergestütztes Konstruieren (CAD)(Übung) X
Management von IT-Projekten (IT-Consulting I) X X
Mechatronik X
Neue Organisationsformen unter Nutzung der I&K-Technologien X
Objektorientierte Programmierung X
Office Systeme 1 X
Produktion und Logistik: Methoden der Planung und Organisation X
Produktions und Logistik: Informationssysteme zur PPS X
Projekt IT-Consulting (IT-Consulting II) X X
Projektseminar Innovations- und Entwicklungsmanagement (IEM) X
Rechnergestütztes Konstruieren (CAD) X
Rechnergestütztes Konstruieren (CAD)(Übung) X
Rechnergestütztes Konstruieren und Planen (CAE) X X
Rechnergestütztes Konstruieren und Planen (CAE)(Übung) X
Standardsoftware im Maschinenbau X X
Strategisches Produktionsmanagement (SPM) X
Übung zu ABWL: Management (Personal und Organisation) X
Übung zu Datenmanagement: Datenbanken und Datenmodellierung X
Unternehmensorganisation X
Web-Engineering X
1. A: PDM-Anwender, C: PDM-Berater, P: PDM-Programmierer
2. P: Pflichtfach, X: Fach wird für Schwerpunkt zur Wahl empfohlen
Tabelle D-1: Schwerpunktbildung im Wahlfplichtfach PDM
Veranstaltungsname A1C P
Wahlpflichfach Produktdatenmanagement D-3
D.2 Steckbriefe
Bild D-1: Steckbrief der Vorlesung „Produktdatenmanagement (PDM)“
Ziel:
Inhalt:
Zielgruppen: Voraussetzungen:
Literatur: Ergänzende Veranstaltungen:
Produktdatenmanagement (PDM)
Gausemeier/N.N. V2
Die HörerInnen kennen die Problematik der Datenmengen und -vielfalt in der Pro-
duktentwicklung, die den Einsatz von Produktdatenmanagement notwendig macht.
Sie kennen die strategische Bedeutung und den Nutzen des Produktdatenmanage-
ments in Industrieunternehmen sowie die Architektur und Funktionen von PDM-Syste-
men. Sie sind qualifiziert, an einer methodischen Einführung von PDM-Systemen
mitzuwirken.
1 Grundlagen
1.1 Die virtuelle Produktentwicklung
1.2 Daten im Produktentwicklungsprozess
1.3 Definition Produktdatenmanagement
1.4 Die Produktstruktur als Kern des Produktdatenmanagements
2 Produktdatenmanagement in Industrieunternehmen
2.1 Strategische Bedeutung
2.2 Nutzen
3 PDM-Systeme
3.1 Architektur
3.2 Funktionen
3.3 Fallbeispiele kommerzieller Systeme
4 Einführung von PDM-Systemen
4.1 Umfeld von PDM-Einführungen
4.2 Vorgehensmodell und Methoden zur Einführung
4.3 Qualifikation als Schlüsselfaktor für die erfolgreiche PDM-Einführung
5 Ergänzende Themen
5.1 PDM und e-Business
5.2 Datenaustausch
Studierende der Studienrichtungen
Maschinenbau, Wirtschaftsinformatik und
Wirtschaftsingenieurwesen.
VL Technische Informatik
VL Industrielle Produktion
Vorlesungsmanuskript
Gausemeier et al.: Produktinnovation, Carl
Hanser Verlag München, 2001
Schöttner, J.: Produktdatenmanagement in
der Fertigungsindustrie; Carl Hanser Verlag,
München, 1999
Projektseminar „Einführung von PDM-Syste-
men“.
sowie Lehrveranstaltungen aus dem Wahl-
pflichtfach Produktdatenmanagement (siehe
Fächerkatalog).
Stand: 31. Juli 2002
D-4 Anhang
Ziel:
Inhalt:
Zielgruppen: Voraussetzungen:
Literatur: Ergänzende Veranstaltungen:
Projektseminar „Einführung von PDM-Systemen“
N.N. S2
Produktdatenmanagement (PDM) unterstützt das Daten- und Prozessmanagement
von Industrieunternehmen über den gesamten Produktlebenszyklus.
Die TeilnehmerInnen haben ein Vorgehensmodell zur PDM-Einführung und die da-
zugehörigen Methoden und Techniken kennengelernt und dieses Wissen an Hand
eines konkreten Projektes vertieft.
Sie sind in der Lage, Arbeitsergebnisse überzeugend zu präsentieren.
Ferner haben die TeilnehmerInnen gelernt, im Team unter Zeitdruck effizient zusam-
menzuarbeiten.
Gegenstand des Projektseminars ist eine konkrete Aufgabenstellung (Fallstudie)
eines Partnerunternehmens. Dabei sind technische, strategische und wirtschaftli-
che Aspekte zu berücksichtigen, um sicherzustellen, dass das eingeführte PDM-
System einen Return on Investment bringt.
Arbeitsorganisation:
Die TeilnehmerInnen werden in Gruppen mit je 4 Personen aufgegliedert.
Die Gruppen stehen im Wettbewerb zueinander. Begleitend zur Projektarbeit
wird intensiv Rede- und Präsentationstechnik trainiert, in dem alle Teilnehmer
mehrfach Gelegenheit erhalten, die Arbeitsergebnisse unterschiedlichenZiel-
gruppen zu präsentieren (Kunden, Geschäftsleitung der eigenen Firma etc.).
Vermittelte Methoden und Techniken:
Vorgehensmodell zur PDM-Einführung, Prozess- und Datenmodellierung,
Projektmanagement, Rede- und Präsentationstechnik, Arbeitsmethodik
Dauer
Das Projektseminar findet als einwöchiger Block statt.
Studierende der Studienrichtungen
Maschinenbau, Wirtschaftsinformatik und
Wirtschaftsingenieurwesen.
VL Produktdatenmanagement (PDM)
Gausemeier et al.: Produktinnovation, Carl
Hanser Verlag München, 2001
Pusch: Personalplanung und -entwick-
lung in einem integrierten Vorge-
hensmodell zur Einführung von PDM-
systemen, Paderborn, 2002
Lehrveranstaltungen aus dem Wahlpflicht-
fach Produktdatenmanagement (siehe Fä-
cherkatalog).
Stand: 31. Juli 2002
B
ild D-2: Steckbrief des Projektseminars „Einführung von Produktdatenma-
nagementsytemen“
Traineeprogramm für PDM-Consultants und Implementierer E-1
E Traineeprogramm für PDM-Consultants und
Implementierer
Die folgenden Informationen dienen zur Detaillierung des in Kapitel 5.3.3.3
beschriebenen Traineeprogramms für PDM-Consultants und Implementierer.
E.1 Ablaufplan des Programms
In Bild E-1 bis Bild E-3 ist der konkrete Ablauf eines vom Heinz Nixdorf Institut
konzipierten und in Zusammenarbeit mit einem in Paderborn ansässigen Bera-
tungsunternehmen durchgeführten Programms aus dem Jahre 1997 dargestellt.
Bild E-1: Ablauf Traineeprogramm 1. Monat
Datum Ort
Mi 1
Do 2
Fr 3
Sa 4
So 5
Mo 6
Di 7
Mi 8
Do 9
Fr 10
Sa 11
So 12
Mo 13 C: Übung OMF, PSM (User) Paderborn
Di 14 D: Übung LCM (User) Paderborn
Mi 15
Do 16
Fr 17 F: Ausbildungsergänzung PDM-Einführung Paderborn
Sa 18
So 19
Mo 20
Di 21
Mi 22
Do 23
Fr 24
Sa 25
So 26
Mo 27
Di 28
Mi 29
Do 30
Fr 31 J: Ausbildungsergänzung BPR Paderborn
B: Metaphase Basiskurs
G: Metaphase Integrator Toolkit
E: Übung OMF (Admin)
I: Übung Systemadministration/Customizing
Neu-Isenburg
H: Übung LCM (Admin) Paderborn
Paderborn
Neu-Isenburg
Oktober
Paderborn
A: Kick-Off Meeting, Einführung Paderborn
E-2 Anhang
Bild E-2: Ablauf Traineeprogramm 2. Monat
Datum Ort
Sa 1
So 2
Mo 3
Di 4
Mi 5
Do 6
Fr 7 L: Ausbildungsergänzung PDM-Themen Paderborn
Sa 8
So 9
Mo 10
Di 11
Mi 12
Do 13
Fr 14 N: Ausbildungsergänzung Projektarbeit Paderborn
Sa 15
So 16
Mo 17
Di 18
Mi 19
Do 20
Fr 21 P: Ausbildungsergänzung IT-Infrastrukturanalyse Paderborn
Sa 22
So 23
Mo 24
Di 25
Mi 26
Do 27
Fr 28 R: Ausbildungsergänzung CAD/CAE Paderborn
Sa 29
So 30
November
O: Übung Customizing,
Methodenimplementierung Paderborn
Q: Übung Customizing,
Methodenimplementierung Paderborn
Paderborn
M: Übung Customizing,
Änderung und Erweiterung Klassenmodell Paderborn
K: Übung Customizing,
Änderung und Erweiterung Klassenmodell
Traineeprogramm für PDM-Consultants und Implementierer E-3
E.2 Beschreibung der Ausbildungsblöcke
Im folgenden wird der Inhalt der einzelnen Ausbildungsblöcke des in Kapitel E.1
dargestellten Programms detailliert. Es werden jeweils das Ziel, die Aufgabe und
evtl. Zusatzinformationen beschrieben.
A: Kick-Off Meeting, Einführung
Ziel: Kennenlernen der Lehrgangsteilnehmer und des Schulungspersonals, detail-
lierte Vorstellung des Schulungsprogramms, Einführung in das Thema Produktda-
tenmanagement, Kennenlernen der Schulungsrechner, Kennenlernen von META-
PHASE.
B: METAPHASE Basiskurs
Siehe Schulungsunterlagen SDRC1
1. Kann hier aus Urheberrechtsgründen nicht genauer beschrieben werden.
Bild E-3: Ablauf Traineeprogramm 3. Monat
Datum Ort
Mo 1
Di 2
Mi 3
Do 4
Fr 5 U: Ausbildungsergänzung PDM-Themen Paderborn
Sa 6
So 7
Mo 8
Di 9
Mi 10
Do 11
Fr 12
Sa 13
So 14
Mo 15
Di 16
Mi 17
Do 18
Fr 19
Sa 20
So 21
S: Übung Toolintegration Paderborn
Dezember
V: Übung Applikationsentwicklung
W: Übung Applikationsentwicklung Paderborn
T: Übung Installation Paderborn
Paderborn
E-4 Anhang
C: Übung OMF, PSM (User)
Ziel: Vertiefung der erworbenen Kenntnisse aus Basiskurs.
Aufgaben: Anlegen von Business und Data Items und entsprechenden Beziehun-
gen, Registrieren von Files, CheckIn, CheckOut, Baselining etc.
Beispiel: Fahrrad
• Produktstruktur mit Baugruppen und Unterbaugruppen anlegen (Unter-
lage: tabellarische Baugruppenstückliste), Supplier und Standardpart etc
berücksichtigen
• verschiedene Dokumente, z.B. Zeichnungen, Zusammenbauanweisungen
und Materialspezifikationen anlegen, an Struktur hängen
• zugehörige Files registrieren und an Dokumente hängen
• in Gruppen-Vault stellen, aus Gruppen-Vault in eigene Worklocation aus-
checken, neue Versionen anlegen, in Vault einchecken. Kopien anlegen
D: Übung LCM (User)
Ziel: Vertiefung der erworbenen Kenntnisse aus Basiskurs.
Aufgaben: Starten von LifeCycles, Durchlaufen der verschiedenen möglichen
LifeCycle Steps.
Beispiel: Fortsetzung Fahrrad
• Änderungsprozeß mit Arbeitszuweisung,- durchführung,- review
• Prozeß „Anlegen eines neuen Teils“
• Review mit Verteilerliste
• Verschiedene Aktionen (Approval, Reject mit und ohne Kommentar etc.)
E: Übung OMF (Admin)
Ziel: Vertiefung der erworbenen Kenntnisse aus Basiskurs.
Aufgaben: Anlegen von Usern/Gruppen und Work/Vault Locations, Definition
von Regeln für ein neues Entwicklungsprojekt
Beispiel: Fortsetzung Fahrrad
• Erarbeitung der benötigten Vaults und Regeln anhand einer Beschreibung
des Projektes (Projektgruppen, -rollen etc.)
• Einrichtung der benötigten User, Vaults und Locations
• Definition der Rollen und Regeln für die Projektarbeit
Traineeprogramm für PDM-Consultants und Implementierer E-5
F: Ausbildungsergänzung PDM-Einführung
Ziel: Die Lehrgangsteilnehmer sollen eine strukturierte Vorgehensweise für die
PDM-Einführung kennenlernen.
Inhalt: Einführungsphasen, Anforderungsaufnahme und -analyse, semantische
und konzeptionelle Prozeß- und Produktstrukturmodellierung, entwicklungsbe-
gleitende Tätigkeiten (Demonstrationsprototypen, Anwenderschulungen,
Reviews)
G: METAPHASE Integrator Toolkit
Siehe Schulungsunterlagen SDRC (s.o.)
H: Übung LCM (Admin)
Ziel: Vertiefung der erworbenen Kenntnisse aus Basiskurs.
Aufgaben: Anlegen von Lifecycles und notwendigen Randbedingungen (Regeln,
Participants, Vaults etc.)
Beispiel: Fortsetzung Fahrrad
• Erarbeitung der benötigten Life Cycles anhand einer Beschreibung der
Prozesse innerhalb des neuen Projektes
• Änderungsprozeß mit Arbeitszuweisung,- durchführung,- review
• Prozeß „Anlegen eines neuen Teils“
• Review mit Verteilerliste
I: Übung Systemadministration/Customizing
Ziel: Einrichtung des Systems für das Customizing.
Aufgaben. Anlegen von Testumgebungen, Einspielen von Daten in eine Produkti-
vumgebung
• Testumgebung anlegen
• Customization-Directories einrichten
• Verschiedene Schritte des Kompilierens anhand von Beispieldateien ken-
nenlernen (Eintragen in die Definitionsfiles, Initialisierung, Kompilie-
rung, Datenbankupdate)
• Notwendige Schritte bei zerstörten Datenbanken etc.
J: Ausbildungsergänzung BPR
Ziel: Die Lehrgangsteilnehmer sollen die Grundlagen des Business Process Reen-
gineering kennlernen.
E-6 Anhang
Inhalt: Definition BPR, grundsätzliche Vorgehensweise (Aufnahme, Schwach-
stellenanalyse, Sollkonzeption, systemabhängige Konzeption), Unterstützung
durch Methoden und Werkzeuge, OMEGA/PRESTIGE
K: Übung Customizing, Änderung und Erweiterung Klassenmodell
Ziel: Die Lehrgangsteilnehmer sollen Anpassungen und Ergänzungen des Meta-
phase-Klassenmodells durchführen können.
Aufgaben: Hinzufügen von Attributen zu bestehenden Klassen, Definition neuer
Klassen (instantiable, inserted)
Beispiel: neues Fahrradprojekt erfordert Benutzung einer neuen CAD-Software,
dadurch neue Attribute und neue Dokumententypen
• Attribute definieren (mit Pictures etc.)
• Attribute an bestehende Klasse attachen
• Anpassung der Fenster für Create, Update und Query mit dwe
• Neue Klassen definieren (Dokument und File)
• Browserdefinitionen für neue Klassen
L: Ausbildungsergänzung PDM-Themen
Ziel: Die Lehrgangsteilnehmer sollen Standardprobleme bei der PDM-Einführung
und dazugehörige Lösungsansätze kennenlernen.
Inhalt: Ablösung von Altsystemen, Nummernsysteme
M: Übung Customizing, Änderung und Erweiterung Klassenmodell
Ziel: Die Lehrgangsteilnehmer sollen Anpassungen und Ergänzungen des Meta-
phase-Klassenmodells durchführen können.
Aufgaben: Fortsetzung von Block K, Definition neuer Beziehungsklassen
• Definition eines neuen Beziehungstyps zwischen den neu definierten
Klassen
• Popup - Menue - Definitionen für Expansion der Beziehungen
N: Ausbildungsergänzung Projektarbeit
Ziel: Die Lehrgangsteilnehmer sollen die Grundlagen der Projektarbeit kennenler-
nen.
Inhalt: Was ist eine Projekt, welche Phasen durchläuft es, wie ist die Rolle des
Projektleiters, Erstellung von Projektplänen, Projektverfolgung, Krisenmanage-
ment
Traineeprogramm für PDM-Consultants und Implementierer E-7
O: Übung Customizing, Methodenimplementierung
Ziel: Die Lehrgangsteilnehmer sollen neue Funktionalitäten programmieren kön-
nen.
Aufgaben: Implementierung von Methoden für neue dynamische Attribute (ähn-
lich Metaphase-Klasse Projekt)
• Definition der Klasse und dazugehöriger Browser und Fenster
• Attachment des Attributs an neue Dokumentenklasse
• Methoden für das Attributhandling (SetDialogDefaults und ValidateDia-
log)
P: Ausbildungsergänzung CAD/CAE
Ziel: Die Lehrgangsteilnehmer sollen die im Produktentwicklundsprozeß einge-
setzten CAE-Systeme und die Anforderungen an die Integration in eine Verfahren-
skette kennenlernen.
Inhalt: CAD-Systeme, FEM (Finite Elemente Methode), Simulationstools etc.,
Produktdatenaustausch, Standards (IGES, STEP etc.)
Q: Übung Customizing, Methodenimplementierung
Ziel: Die Lehrgangsteilnehmer sollen neue Funktionalitäten programmieren kön-
nen.
Aufgaben: Fortsetzung von Block O, Zusatzaufgaben je nach Fortschritt der Lehr-
gangsteilnehmer
R: Ausbildungsergänzung IT-Infrastrukturanalyse
Ziel: Die Lehrgangsteilnehmer sollen ein Verfahren zur strukturieten Analyse
einer bestehenden IT-Infrastruktur kennenlernen.
Inhalt: Welche IT-Systeme werden wo und wie eingesetzt, wo sind bestehende
Schnittstellen. Welche Funktionalitäten können/müssen durch das PDM-Sysem
abgelöst werden, Definition der neuen Schnittstellen
S: Übung Toolintegration
Ziel: Die Lehrgangsteilnehmer sollen neue eine Anwendung als neues Tool in die
PDM-Umgebung einbinden können.
Aufgaben: Ein neues Werkzeug zur Erstellung von Dokumentationen soll einge-
richtet werden
• Tooldefinition, Aufrufparameter etc.
E-8 Anhang
• Anlegen eines entsprechenden Filetyps
T: Übung Installation
Ziel: Die Lehrgangsteilnehmer sollen die Schritte der Metaphase-Installation ken-
nenlernen.
Aufgaben: Installation eines neuen (stand-alone) Metaphase-Servers und Clients
für einen neuen Standort des Fahrradherstellers
• Datenbankinstallation (Oracle)
• METAPHASE Server - Installation (alle Module)
• Client - Installation unter Windows
U: Ausbildungsergänzung PDM-Themen
Ziel: Die Lehrgangsteilnehmer sollen Standardprobleme bei der PDM-Einführung
und dazugehörige Lösungsansätze kennenlernen.
Inhalt: Integration PDM-PPS, CAD-Integration
V: Übung Applikationsentwicklung
Ziel: Die Lehrgangsteilnehmer sollen ein selbständig laufendes Programm unter
Nutzung der Metaphase-API erstellen.
Aufgabe: Entwicklung einer Applikation zur Altdatenübernahme
Beschreibung:
• Auslesen von Daten aus einer strukturierten ASCII-Datei,
• Erzeugung von PSM-Instanzen mit Relationen
• Kontrollroutinen
W: Übung Applikationsentwicklung
Ziel: Die LehrgangsteilnehmerMetaphase sollen ein selbständig laufendes Pro-
gramm unter Nutzung der Metaphase-API erstellen.
Aufgabe: Fortsetzung von Block V
E.3 Übungsaufgaben
Die zu lösenden Aufgaben sind in den nächsten Abschnitten dargestellt. Das Bei-
spiel ist durchgängig ein Unternehmen, das Fahrräder produziert.
Traineeprogramm für PDM-Consultants und Implementierer E-9
E.3.1 Aufgabe C1
Sie sind verantwortlich für die Übertragung von bestehenden Stücklisten in das
neue PDM-System. Für ein bestehendes Fahrradprojekt soll die folgende durch
eine Stückliste beschriebene Produktstruktur mit allen Baugruppen, Einzelteilen
und Beziehungen angelegt werden. Zusätzlich sind die Kaufteile entsprechend zu
kennzeichnen und die Kaufinformationen einzugeben.
Anschließend sollen eine Gesamt- und die Baugruppenstücklisten erstellt und den
entsprechenden Teilen zugeordnet werden. Für Einzelteile ist ein Verwendungs-
nachweis zu erstellen und zuzuordnen.
Spezifikationen und andere Dokumente sollen ebenfalls in die Struktur eingehängt
werden.
Tabelle E-1: Stückliste „Fahrrad“
Stückliste
008-456-001 MB 143 15.09.97
Pos. Nr. Name Anz. Bemerkungen1
1 008-456-012 Rahmen, gesamt 1
1.1 008-456-013 Rahmen 1
1.2 008-456-014 Gabel 1
1.3 008-456-015 Steuerlager 1
2 008-456-016 Lenker, gesamt 1
2.1 008-456-010 Lenkstange 1
2.2 008-456-011 Vorbau 1 Ersatz:Vorbau 007-327-056
2.3 008-456-017 Griff 2
3 008-456-018 Sattel, gesamt 1
3.1 008-456-018 Sattelstütze 1
3.2 008-456-019 Sattel 1 Brooks, S340, Best.-Nr. FZ673-340
4 008-456-020 Vorderrad 1
4.1 008-456-021 Felge 1 Mavic, MA40, Best.-Nr. M-MA40-003
4.2 008-456-022 Speiche 64
4.3 008-456-023 Nabe 1
4.3.1 008-456-024 Nabenkörper 1
4.3.2 008-456-025 Lagerkugel 24 SKF, Best.-Nr. KL801-5-8.8
4.3.3 008-456-026 Achse 1
4.3.4 008-456-027 Schnellspanner 2
4.4 008-451-097 Mantel 1 Michelin M27x12, Best.-Nr. 12/3-27/12
4.5 008-451-098 Schlauch 1 Michelin S27x12, Best.-Nr. 26/5-27/12
5 008-456-028 Hinterrrad 1
5.1 008-456-021 Felge 1 Mavic, MA40, Best.-Nr. M-MA40-003
5.2 008-456-022 Speiche 64
5.3 008-456-029 Nabe 1
5.3.1 008-456-030 Nabenkörper 1
E-10 Anhang
E.3.2 Aufgabe E1:
Für die bestehende Organisationsstruktur der Fahrradentwicklung soll das pas-
sende Berechtigungskonzept in Metaphase abgebildet werden.
Sie haben dabei die Aufgabe, zunächst anhand einer Beschreibung des Aufbaus
und der Arbeitsweise der Organisation ein Konzept für die Umsetzung in Meta-
phase zu entwickeln. Nach Abstimmung des Konzeptes mit dem Auftraggeber soll
dieses dann in Metaphase umgesetzt werden.
Arbeitsbeschreibung:
Die Produktion neuer Fahrräder wird durch drei Abteilungen vorbereitet. Neue
Ideen für Fahrräder werden durch die Produktplanung entwickelt. Diese leitet eine
5,3,2 008-456-025 Lagerkugel 24 SKF, Best.-Nr. KL801-5-8.8
5.3.3 008-456-031 Achse 1
5.3.4 008-456-027 Schnellspanner 2
5.4 008-456-032 Kassettenzahnkränze 1 Shimano CS-M950, Best.-Nr. 45603B
5.5 008-451-097 Mantel 1 Michelin M27x12, Best.-Nr. 12/3-27/12
5.6 008-451-098 Schlauch 1 Michelin S27x12, Best.-Nr. 26/5-27/12
6 008-456-033 Bremsen (Satz) 1
6.1 008-456-034 Vorderbremse, gesamt 1
6.1.1 008-456-035 Vorderbremse 1
6.1.2 008-456-036 Bremsbeläge 2
6.1.3 001-190-005 Bautenzug 1 Länge ca. 60cm
6.2 008-456-038 Hinterbremse, gesamt 1
6.2.1 008-456-039 Hinterbremse 1
6.2.2 008-456-036 Bremsbeläge 2
6.2.3 001-190-005 Bautenzug 1 Länge ca. 125cm
6.3 008-456-040 Bremshebel 2
7 008-456-041 Schaltung 1
7.1 008-456-042 Schalthebel 2
7.2 008-456-043 Schaltzug 2 Länge ca. 95cm und 135cm
7.3 008-456-044 Umwerfer 1 Shimano FD-M950-E, Best.-Nr. 45607B
7.4 008-456-045 Schaltwerk 1 Shimano RD-M950-GS, Best.-Nr. 45606B
8 008-456-046 Kurbelgarnitur 1 Shimano FC-M950, Best.-Nr. 45605B
9 008-456-047 Pedal 2 Shimano PD-M747, Best.-Nr. 45309B
10 008-456-048 Lager 1 Shimano BB-M950, Best.-Nr. 45601B
11 008-456-049 Kette 1
1. Die angegebenen Bestellnummern sind fiktiv
Tabelle E-1: Stückliste „Fahrrad“
Stückliste
008-456-001 MB 143 15.09.97
Pos. Nr. Name Anz. Bemerkungen1
Traineeprogramm für PDM-Consultants und Implementierer E-11
ausgefertigte Idee (grobe Struktur des Produktes mit beschreibenden Dokumenten,
wie Skizzen, Katalogauzügen und Spezifikationen) an die Entwicklungsabteilung
weiter. In dieser arbeiten drei Entwicklungsteam. Der Entwicklungsleiter weist
neue Produktideen einem Entwicklungsteam zu, welches das Fahrrad eigenständig
fertig konstruiert, berechnet etc. Die Verantwortung trägt dafür der Teamleiter. Ein
fertig konstruiertes Fahrrad wird dann nach gemeinsamer Abnahme durch den Ent-
wicklungsleiter und den Leiter der Fertigungsplanung an die letztgenannte Abtei-
lung übergeben. Dort werden abschließend die Fertigungsunterlagen, Arbeitspläne
etc. erstellt.
Organisation:
• Die Produktplanung wird durch Frau Gudrun Idee durchgeführt.
• Der Chef der Entwicklungsabteilung ist Herr Hans Boss.
• Die drei Entwicklungsteams sind:
• Fritz Müller, Sabine Meier (Teamleiterin) und Frank Schulze;
• Boris Becker (Teamleiter), Michael Stich, Carl-Uwe Steeb;
• Oliver Bierhoff, Jürgen Klinsmann (Teamleiter), Birgit Prinz.
• Chefin der Fertigungsplanung ist Frau Eva Meister.
• Als Fertigungsplaner arbeiten Herr Jürgen Möllemann und Herr Charly
Neumann.
E.3.3 Aufgabe I1:
In der Fahrradfabrik ist im Sinne der Produkthaftung eine gut strukturierte Doku-
mentenverwaltung unumgänglich. Im Rahmen des dazu erstellten Konzeptes wür-
den mehrere Dokumentenarten wie z.B. Zeichnung spezifiziert. Diese sollen von
dem PDM-System verwaltet werden können.
Arbeitsbeschreibung:
Um Metaphase entsprechend customizen zu können, müssen Sie zuerst eine Test-
umgebung anlegen. Freundlicherweise hat ein Vorgänger von Ihnen für das Doku-
ment Zeichnung die MODel-Files schon erstellt. Leider hat er sich mit der Kom-
mentierung stark zurückgehalten. Kommentieren Sie die Files bitte ausführlich !
Führen Sie anschließend alle Schritte durch um Metaphase um die Klasse Zeich-
nung zu erweitern und binden Sie diese in die Browser ein.
Erweitern Sie die Klasse Zeichnung zudem um 2 Attribute, die Ihrer Meinung nach
unbedingt notwendig sind.
Senden Sie die von Ihnen überarbeiteten Files per E-Mail wieder zurück.
E-12 Anhang
Lernziel:
• Erstellen einer Testumgebung
• Einführung in die MODeL-Programmierung
• Erweitern von Klassen um Attribute
E.3.4 Aufgabe J1:
Ziel ist die Verwirklichung eines PDM-Systems für das CyberBike-Werk.
Die Aufgabe unterteilt sich in die Modellierung der Produkte (Produktstruktur)
sowie die Abbildung innerhalb des Produktdatenmanagementsystems Metaphase.
Das PDM-System soll die wesentlichen Datenstrukturen des Unternehmens (Pro-
duktstrukturen und zugehoerige Dokumente) verwalten.
Durch die Verwendung eines PDM-Systems steht der CyberBike AG eine lei-
stungsfähige Produktstruktur- und Dokumentenverwaltung zur Verfügung.
Arbeitsbeschreibung:
Das PDM-System bietet dem Benutzer Funktionen zur Produktstrukturierung an.
Das System ermöglicht es dem Benutzer, ein Produkt zu strukturieren und die
Struktur zu modifizieren, zu betrachten und die zugehörigen Dokumente zu bear-
beiten.
Die Produkte sind folgendermaßen strukturiert und im PDM-System abzubilden:
Ein Produkt besteht aus Baugruppen, die wiederum aus Teilen bestehen. Verein-
facht kann man sagen ein Produkt und eine Baugruppe sind jeweils ein Teil und
ein Teil ist die Summe von Teilen, wobei die Summe auch gleich Null sein kann.
Ein Teil wird durch Dokumente beschrieben, z.B. Spezifikationen, Zeichnungen
(Konstruktions- und Fertigungszeichnungen) und Montageanleitung.
Diese Dokumente werden eindeutig einem bestimmten Teil zugeordnet.
Die Attribute eines Dokuments sind z.B.:
• Dokumententyp
• Auslaufdatum
• Sachbearbeiter
Alle Zuordnungen müssen in beide Richtungen nachvollziehbar sein. Für ein Teil
muß zum Beispiel erkennbar sein, welche Dokumente es beschreiben. Aus dem
Dokument muß erkennbar sein, welche Teile von diesem beschrieben werden.
Erstellen Sie ein Konzept mit den dazugehörigen semantischen und konzeptionel-
len Datenmodellen. Implementieren Sie anschließend Ihr Konzept in Metaphase.
Traineeprogramm für PDM-Consultants und Implementierer E-13
Generieren Sie dazu die benötigten Klassen- und Browserdefinitionen und gestal-
ten Sie die Eingabefenster benutzerfreundlich.
Lernziel:
• Erweiterung der Customizingfähigkeiten.
• Strukturierte Vorgehensweise.
• Erstellung des semantischen und konzeptionellen Datenmodelles gemäß
den spezifizierten Anforderungen. Realisierungsnachweis des Konzeptes.
E.3.5 Aufgabe K1:
Bei der Einführung der Produkt- und Dokumentenstruktur bei der Cyber-Bikes AG
sind mehrere Anforderungen an Metaphase aufgetaucht die sich mit Metaphase
Basisfunktionalitäten nicht realisieren lassen. Zudem will die Firma den APC nicht
einsetzen. Deshalb ist eine Methodenimplementierung unumgänglich.
Arbeitsbeschreibung:
Der Projektleiter hat deshalb Teams gebildet, die folgende Funktionalitäten zu
implementieren haben:
Teilprojekt A:
• Beim Erstellen eines Dokumentes soll der Ersteller automatisch erfaßt
werden.
• Um eine konsistente Dokumentenhistorie aufrechtzuerhalten, sollen Gül-
tigkeitsdaten eingeführt werden. Dazu soll beim Erstellen eines neuen
Dokuments das Gültigkeitsdatum automatisch auf das Systemdatum
gesetzt werden. Die Gültigkeitsdauer ist defaultmäßig 10 Jahre.
• Das eingeführte Konzept soll bei Expand- und Query- Funktionalitäten
sinnvoll berücksichtigt werden.
Teilprojekt B :
• Um den Anforderungen aus Aufgabe J1 zu genügen, darf ein Dokument
nur eindeutig einer Baugruppe zuordenbar sein.
• Um ein strukturiertes Dokumentenmanagement zu gewährleisten, dürfen
einem Dokument nur ausgewählte Data-Items wie zum Beispiel nur Auto-
cad-Zeichnungen oder nur Word-Dokumente zugeordnet werden.
Teilprojekt C:
• Um den Anforderungen an die Benutzerfreundlichkeit zu genügen, sollen
von Metaphase aus automatisch Applikationen gestartet werden können,
unter anderem beim Erstellen eines Data-Items nach automatischer Regi-
E-14 Anhang
strierung und beim Expandieren von Data-Items von einem Dokument
aus.
• Weiterhin soll beim Drag und Drop eines Data-Items auf ein Tool-Icon
automatisch die Applikation mit dem entsprechenden Data-Item gestartet
werden können.
Lernziel:
• Spezifikation von zu überschreibenden Methoden mit Hilfe des Trace-
Modus.
• Schreiben einfacher Methoden.
E.3.6 Aufgabe L1:
Nachdem die wesentlichsten Anforderungen an die Produkt- und Dokumenten-
struktur vorerst realisiert worden sind, soll bei der Cyber-Bikes AG eine White-
Box Toolintegration zwischen Metaphase und einem Textverarbeitungssystem
durchgeführt werden. Dazu sind API-Funktionalitäten zu verwenden.
Weiterhin sollen die Funktionalitäten im Bereich des Prozeßmanagements ausbaut
werden.
Arbeitsbeschreibung:
Die Aufgaben untergliedern sich in 3 Bereiche:
Klasse Process erweitern:
• Applikationen mit denen die Data-Items gestartet werden, sollen in dem
Dialog beim Anlegen eines Processschrittes mit angegeben werden kön-
nen und über die Worklist automatisch gestartet werden.
Definition der Transformationsabbildung:
• Zu jedem Dokument sollen zusätzliche Attribute geführt werden können,
die sich applikationsspezifisch unterscheiden können.
• Wenn sich zwischen 2 Lifecycle-Steps die applikationsspezifischen Attri-
bute unterscheiden, dann muß eine Transformationsabbildung dynamisch
definiert werden.
White Box- Tool integration
• Wenn in einem Lifecycle-Step eine Textverarbeitung als Tool angegeben
ist, sollen alle applikationsspezifischen Attribute des Dokumentes im
Kopf des in der Textverarbeitung erscheinenden Dokumentes eingetragen
werden.
Der Projektleiter hat wiederum drei Teams gebildet.
Traineeprogramm für PDM-Consultants und Implementierer E-15
Weitere Aufgaben und Aspekte:
• Fulltables, dynamische Attributlisten
Lernziel:
• Lernen, bei grob spezifizierten Aufgaben durch Nachfragen die Problem-
stellung im Detail zu erfassen
• Konzeptionserstellung in Teamarbeit und Teamübergreifendes Arbeiten
• Spezifikation des konzeptionellen Datenmodelles
• Erbringung des Realisierungsnachweises durch Klassencustomizing und
Methodenimplementierung in Metaphase
• Vertiefung und Erweiterung des Lifecycle-Managers
• Kennenlernen des dbx
E-16 Anhang
