Product Lifecycle Management für die Praxis: Ein Leitfaden zur modularen Einführung, Umsetzung und Anwendung [1 ed.] 3540340084, 9783540340089 [PDF]

Zitiervorschau

Product Lifecycle Management für die Praxis

Jörg Feldhusen · Boris Gebhardt

Product Lifecycle Management für die Praxis Ein Leitfaden zur modularen Einführung, Umsetzung und Anwendung

123

Prof. Dr.-Ing. Jörg Feldhusen Lehrstuhl und Institut für Allgemeine Konstruktionstechnik des Maschinenbaus RWTH Aachen Steinbachstr. 54B 52074 Aachen Deutschland e-mail: [email protected] Dr.-Ing. Boris Gebhardt Neuhauser Str. 53 52146 Würselen Deutschland e-mail: [email protected] e-mail zum Buch: [email protected]

ISBN 978-3-540-34008-9

e-ISBN 978-3-540-34009-6

DOI 10.1007/978-3-540-34009-6 Bibliografische Information der Deutschen Nationalbibliothek Die Deutsche Nationalbibliothek verzeichnet diese Publikation in der Deutschen Nationalbibliografie; detaillierte bibliografische Daten sind im Internet über http://dnb.d-nb.de abrufbar. c 2008 Springer-Verlag Berlin Heidelberg  Dieses Werk ist urheberrechtlich geschützt. Die dadurch begründeten Rechte, insbesondere die der Übersetzung, des Nachdrucks, des Vortrags, der Entnahme von Abbildungen und Tabellen, der Funksendung, der Mikroverfilmung oder der Vervielfältigung auf anderen Wegen und der Speicherung in Datenverarbeitungsanlagen, bleiben, auch bei nur auszugsweiser Verwertung, vorbehalten. Eine Vervielfältigung dieses Werkes oder von Teilen dieses Werkes ist auch im Einzelfall nur in den Grenzen der gesetzlichen Bestimmungen des Urheberrechtsgesetzes der Bundesrepublik Deutschland vom 9. September 1965 in der jeweils geltenden Fassung zulässig. Sie ist grundsätzlich vergütungspflichtig. Zuwiderhandlungen unterliegen den Strafbestimmungen des Urheberrechtsgesetzes. Die Wiedergabe von Gebrauchsnamen, Handelsnamen, Warenbezeichnungen usw. in diesem Werk berechtigt auch ohne besondere Kennzeichnung nicht zu der Annahme, dass solche Namen im Sinne der Warenzeichen- und Markenschutz-Gesetzgebung als frei zu betrachten wären und daher von jedermann benutzt werden dürften. Satz: Reproduktionsfähige Vorlage der Autoren Einbandgestaltung: deblik, Berlin Production: LE-TEX Jelonek, Schmidt & Vöckler GbR, Leipzig, Germany Gedruckt auf säurefreiem Papier 987654321 springer.com

Inhaltsverzeichnis

1

Einleitung .......................................................................................... 1 1.1 Augenblickliche Unternehmenssituation .................................. 1 1.2 Grundlegende Aspekte von PLM .............................................. 3 1.3 Anspruch und Zielgruppe des Buches....................................... 5 1.4 Aufbau des Buches.................................................................... 7 1.5 Danksagungen der Autoren ..................................................... 11

2

Die Situation heutiger Unternehmen ............................................ 13 2.1 Ursachen und Folgen von Unternehmenskomplexität ............ 13 2.2 PLM als strategischer Ansatz zur Beherrschung der Komplexität....................................................................... 20 2.3 Die Entwicklung einer PLM-Strategie .................................... 22 2.4 Grundsätzliche Maßnahmen zur Umsetzung einer PLM-Strategie ................................................................ 25 2.5 Zusammenfassung Kapitel 2 ................................................... 29

3

PLM-Voraussetzungen im Unternehmen..................................... 31 3.1 Anforderungen an eine erfolgreiche PLM-Strategie ............... 31 3.1.1 Allgemeine Anforderungen an PLM........................... 32 3.1.2 Anforderungen an die Hauptunternehmenselemente ...................................... 35 3.2 Mögliche Produktarten für PLM ............................................. 36 3.2.1 Grundlegende Begriffe im Bereich der Modularisierung.................................................... 37 3.2.2 Multi-Life-Produkte.................................................... 40 3.2.3 Plattformprodukte ....................................................... 42 3.2.4 Mechatronische Produkte............................................ 43 3.3 Modulare Prozesse .................................................................. 49 3.4 Modulare Organisationen ........................................................ 52 3.5 Zusammenfassung Kapitel 3 ................................................... 54

VI

Inhaltsverzeichnis

4

Umsetzung von PLM...................................................................... 57 4.1 Anwendung der PLM-Strategie auf der Basis vorhandener Produkte ............................................................. 57 4.2 Steuerung der Daten- und Informationsflüsse......................... 65 4.3 Beherrschung der Unternehmenskomplexität durch ein PDMS ...................................................................... 74 4.3.1 Grundlegende PDM-Systemarchitektur...................... 75 4.3.2 Grundlegende PDM-Systemfunktionalitäten .............. 77 4.3.3 PDM-Systemanforderungen ....................................... 78 4.4 Unternehmensanforderungen an eine PDMS-Einführung....... 79 4.5 Zusammenhänge im Bereich „PDMS-Fähigkeit“ ................... 83 4.6 Zusammenfassung Kapitel 4 ................................................... 87

5

Der PDMS-Regelkreis .................................................................... 91 5.1 Nachteile vorhandener PDMS-Einführungsmethoden ............ 91 5.2 Grundlage der modularen Vorgehensweise: Der PDMS-Regelkreis............................................................. 95 5.3 Zusammenfassung Kapitel 5 ................................................. 101

6

Lösungsbaustein 1: PDM-Systemeinführung ............................ 103 6.1 Beschreibung der methodischen Vorgehensweise ................ 103 6.2 Organisation und Ablauf des PDMS-Projekts....................... 104 6.2.1 Aufbau der PDMS-Projektorganisation .................... 105 6.2.2 Ablauf des PDMS-Projekts....................................... 109 6.2.3 Kosten des PDMS-Projekts....................................... 111 6.3 Die unternehmensinterne Vorklärungsphase......................... 113 6.4 Die Untersuchungsphase ....................................................... 115 6.4.1 Arbeitsschritt 1: Definition der Zielsetzungen.......... 115 6.4.2 Arbeitsschritt 2: Erstellung der IST-Analyse und Ableitung des SOLL-Konzepts.......................... 122 6.5 Die Umsetzungsphase ........................................................... 145 6.5.1 Arbeitsschritt 3: Ergänzung oder Erstellung der Modelle ............................................................... 145 6.5.2 Arbeitsschritt 4: Die Pilotphase ................................ 171 6.6 Die Betriebsphase.................................................................. 179 6.7 Zusammenfassung Kapitel 6 ................................................. 183

Inhaltsverzeichnis

VII

7

Lösungsbaustein 2: Bewertung der PDMS-Fähigkeit ............... 189 7.1 Definition der Capability Scorecard (CSC)........................... 189 7.2 Aufbau der Capability Scorecard .......................................... 190 7.3 Anwendung der CSC und Ermittlung des PDMS-Reifegrads ........................................................... 196 7.3.1 Die Nutzwertanalyse (NWA).................................... 197 7.3.2 Ermittlung des PDMS-Reifegrads und der Perspektiven-Reifegrade ..................................... 199 7.3.3 Die Schwachstellenanalyse ....................................... 202 7.4 Arbeitsschritt A: Definition der Zielsetzungen ..................... 203 7.5 Arbeitsschritt B: Ermittlung der PDMS-Bewertungskriterien .................................................. 205 7.6 Arbeitsschritt C: Ermittlung des Perspektiven-Reifegrads.... 214 7.7 Arbeitsschritt D: Ableitung von Verbesserungsaktivitäten ... 223 7.8 Exemplarische Ermittlung der PDMS-Fähigkeit................... 227 7.9 Die CSC als Grundlage des PDMS-Projektcontrollings ....... 237 7.10 Zusammenfassung Kapitel 7 ................................................. 241

8

Wirtschaftlichkeitsbetrachtung................................................... 245 8.1 Grundgedanken der Wirtschaftlichkeitsbetrachtung ............. 245 8.2 Nutzenerhebung mit Hilfe des Business Case....................... 250 8.2.1 Definition und Aufbau eines Business Case ............. 250 8.2.2 Allgemeine Nutzenpotenziale ................................... 252 8.2.3 Unternehmensindividuelle Nutzenpotenziale ........... 254 8.3 Monetäre Erhebung des Nutzens........................................... 255 8.4 Ermittlung der Kosten ........................................................... 258 8.5 Bewertung der Wirtschaftlichkeit ......................................... 262 8.5.1 Das Prinzip des Total Cost of Ownership (TCO) ..... 263 8.5.2 Die Prozesskostenrechnung ...................................... 265 8.5.3 Exemplarische Kennzahlen der Investitionsbewertung ............................................... 267 8.5.4 Moderne Verfahren der Investitionsberechnung....... 271 8.6 Bewertung der Unternehmensperspektive Finanzen ............. 273 8.7 Risiken der PDMS-Einführung ............................................. 277 8.8 Zusammenfassung Kapitel 8 ................................................. 279

VIII

9

Inhaltsverzeichnis

Fallbeispiel..................................................................................... 283 9.1 Allgemeine Unternehmenssituation und Vorklärungsphase........................................................... 284 9.2 Lösungsbaustein 1: Die PDM-Systemeinführung ................. 289 9.2.1 Durchführung des Arbeitsschritts 1 .......................... 290 9.2.2 Durchführung des Arbeitsschritts 2 .......................... 294 9.2.3 Durchführung des Arbeitsschritts 3 .......................... 299 9.2.4 Durchführung des Arbeitsschritts 4: Pilotphase........ 306 9.3 Lösungsbaustein 2: Bewertung der PDMS-Fähigkeit ........... 311 9.3.1 Durchführung des Arbeitsschritts A ......................... 311 9.3.2 Durchführung des Arbeitsschritts B.......................... 312 9.3.3 Durchführung des Arbeitsschritts C.......................... 315 9.3.4 Durchführung des Arbeitsschritts D ......................... 318 9.4 Der Business Case................................................................. 320 9.5 Zusammenfassung Kapitel 9 ................................................. 326

Sachwortverzeichnis .............................................................................. 329

1 Einleitung

„Durch die Umsetzung von Product Lifecycle Management führen wir in unserem Unternehmen kein neues IT-System ein, sondern eine völlig neue Denkweise des Produktentwickelns.“ (Der Leiter des Technischen Bereichs in einem mittelständischen Unternehmen)

1.1 Augenblickliche Unternehmenssituation Aufgrund der zunehmenden Globalisierung müssen sich viele Unternehmen einem internationalen Wettbewerb stellen. Seine Herausforderungen bestehen in einem Preiswettbewerb auf der einen sowie in einem Technologie-/Innovationswettbewerb auf der anderen Seite. Was noch vor einigen Jahren nur für Großunternehmen galt, betrifft heute auch zunehmend mittelständische Unternehmen. Der Preiswettbewerb bedeutet für Unternehmen, den Kunden ihre Produkte bzw. Dienstleistungen günstiger als die Mitbewerber am Markt anzubieten. Um die Unternehmensgewinne nicht zu gefährden, wird i. A. eine Preisreduktion der Produkte durch eine Kostenreduktion bei ihrer Entwicklung, ihrer Herstellung oder ihrem Vertrieb zu erreichen versucht. Dies geschieht durch den Einsatz von teilweise sehr aufwändigen und umfangreichen Maßnahmen wie das Target-Costing [Horvath 1993; Seidenschwarz 1993] oder das Design-to-Cost [Domin u. Maskow 1985]. Ihr Erfolg hängt wesentlich von der Erfahrung und der Umsetzungskonsequenz des einzelnen Unternehmens ab. Der Technologie- bzw. Innovationswettbewerb führt zur Einführung neuer Technologien oder Innovationen bei Produkten, um sich in der Kundenwahrnehmung vom Wettbewerber abzuheben. Häufig birgt jedoch die Einführung von Funktionen oder ganzer Produkte auf der Basis neuer Technologien hohe Risiken für ein Unternehmen in sich [Brezing 2006]. Um international wettbewerbsfähig zu bleiben, sind Unternehmen häufig gezwungen, beide Wege zu beschreiten. Diese Vorgehensweisen sind allerdings mit erheblichen Risiken verbunden und müssen sorgfältig geplant

2

1 Einleitung

werden, um die Unternehmensexistenz nicht zu gefährden. Gerade mittelständischen Unternehmen fehlen häufig notwendige finanzielle Rücklagen, um Fehlplanungen in diesen Bereichen auffangen zu können. Eine wesentliche Folge des Preis- und des Technologiewettbewerbs ist die sich ständig verkürzenden Marktpräsenz von vielen Produkten. Neben Konsumgütern wie Mobiltelefonen oder Digitalkameras gilt dies mittlerweile auch für Investitionsgüter wie Automobile. Dadurch ergeben sich für die Unternehmen immer kürzere Zeitspannen, in denen während der Markpräsenz ihrer Produkte die entsprechenden Gewinne erzielt werden müssen. In der Abb. 1.1 ist diese Problematik prinzipiell wiedergegeben.

Abb. 1-1 Gewinnverlauf bei unterschiedlicher Marktpräsenz eines Produkts

Besonders kritisch wird die Situation dadurch, dass bei Produkten mit kurzer Marktpräsenz auch die gesamten Produktionsvorbereitungskosten wie Entwicklungs- und Konstruktionskosten, Kosten für die Fertigungsvorbereitung und -einführung etc. häufig drastisch gekürzt werden. Dadurch gelangen diese Produkte zu einem Zeitpunkt auf den Markt, zu dem sie technisch noch nicht ausgreift sind. Anders ausgedrückt muss eine neue Technologie möglichst kostengünstig und kurzfristig eingeführt werden, um ihre eigenen Forschungs- bzw. Entwicklungskosten zu decken. Daraus resultieren häufig Fehlleistungen, die sich in entsprechend kostspieligen Rückrufaktionen oder Garantieleistungen niederschlagen. Häufig wird seitens des Unternehmens reagiert, dass nur noch „sichere“, d. h. verkaufbare Produkte auf den Markt gebracht werden. Die notwendige Innovation findet aufgrund der Befürchtung, mit innovativen Produkten auf dem Markt

Grundlegende Aspekte von PLM

3

zu scheitern, nur sehr zögerlich oder überhaupt nicht statt. Das Unternehmen befindet sich in einem strategischen Teufelskreis. Neben einem finanziellen Verlust leidet hierunter auch das Image des betroffenen Unternehmens. Viele mittelständische Unternehmen sind auf die Herausforderungen der beschriebenen Marktsituation und dem sich ergebenden Teufelskreis nur unzureichend vorbereitet. Einen strategischen Ausweg bietet das Product Lifecycle Management (PLM). Häufig jedoch sind sich Unternehmen über die Möglichkeiten, aber auch Risiken sowie die Auswirkungen auf das Unternehmen von PLM nicht bewusst. Ebenso herrscht Unklarheit darüber, welche Ziele mit PLM überhaupt realisiert und welche nicht realisiert werden können. Deshalb wird der Aufwand bei der Planung einer PLM-Umsetzung häufig unterschätzt. Der vermeintlich heilbringende Lösungsweg aus dem strategischen Teufelskreis entpuppt sich als ressourcenintensives „Groschengrab“, welches nicht selten vorzeitig abgebrochen wird. Wie PLM strategisch geplant und mit Hilfe eines ProduktdatenmanagentSystems (PDMS) in der täglichen Unternehmenspraxis umgesetzt werden kann, bilden die Schwerpunkte des vorliegenden Buchs. Dabei wird besonders die Frage behandelt, ob ein mittelständisches Unternehmen in seinem jetzigen Zustand seine strategischen und operativen Ziele mit PLM und PDMS überhaupt erreichen kann.

1.2 Grundlegende Aspekte von PLM Einer der wichtigsten Aspekte von PLM liegt in der gezielten Nutzung und Bereitstellung des im Unternehmen vorhandenen Wissens, um daraus mit dem gewünschten minimalen Aufwand bei der Produktentwicklung den maximalen Vorteil gegenüber den Wettbewerbern zu erzielen. Damit wird deutlich, dass ein Überleben auf dem globalen Markt auch davon abhängt, wie Unternehmen ihr vorhandenes Wissen effektiv für die Entwicklung neuer Produkte nutzen und, falls notwendig, an entsprechenden Stellen ergänzen. Das Wissen eines Unternehmens bildet sich folglich direkt in seinen Produkten ab. Es ist offensichtlich, dass damit die vorhandene Struktur bestehender als auch die Planung der Struktur zukünftiger Produkte einen weiteren wesentlichen Aspekt von PLM darstellt. Das Unternehmenswissen wird heute als das bedeutsamste Kapitel innerhalb des Unternehmens angesehen [Sveiby 1998; Schnauffer et al. 2004; Mertins et al. 2005; North 2005]. Indirekt hat dieses gespeicherte

4

1 Einleitung

Produktwissen Auswirkungen auf der Gestaltung effizienter Abläufe innerhalb des Unternehmens. Diese Aussage betrifft Abläufe wie Entwicklungstätigkeiten ebenso wie diejenigen in der Fertigung oder im Service. Damit ist ein weiterer Aspekt von PLM identifiziert: PLM beeinflusst die Prozesse innerhalb des Unternehmens sowie zwischen einzelnen Standorten und den Zulieferern. Das vorhandene Unternehmenswissen soll über eine hohe Nachhaltigkeit verfügen, d. h. es soll über einen langen Zeitraum gültig und relevant sein. Um die Effizienz im Umgang mit Wissen und eine ständige Aktualisierung zu gewährleisten, ist eine definierte Strukturierung und Vernetzung wünschenswert. Bei einer Strukturierung kann bspw. in Entwicklungswissen, Fertigungswissen oder Konstruktionswissen unterschieden werden. Eine sinnvolle Vernetzung verknüpft diese einzelnen Wissensbausteine. So erfordert ein durch bestimmte Geometrieelemente gestaltetes Bauteil aus einem bestimmten Werkstoff entsprechende Fertigungsprozesse. Ein Beispiel sind Gussbauteile, bei denen Gestaltung, Werkstoffeigenschaften und Fertigungsverfahren gekoppelt sein müssen, um die geforderte Wissenseffizienz zu erhalten. Eine geeignete Wissenssteuerung stellt die Verfügbarkeit relevanter Daten und Informationen sicher. Der Gedanke, dass jedem Produktelement in Abhängigkeit bspw. des Werkstoffs bestimmte Gestaltungsvorgaben und/oder Fertigungsprozesse zugeordnet sind, wurde bereits erläutert. Konsequenterweise lässt sich diese Aussage verallgemeinern: Jedem Produktelement ist ein bestimmter Ablauf in Abhängigkeit seiner Lebenszyklusphase wie Entwicklung oder Produktion zugeordnet. Ein Produktelement muss konstruiert, gefertigt, montiert und gewartet werden. Diese Tätigkeiten werden durch Unternehmensmitarbeiter durchgeführt. Sowohl die Tätigkeiten als auch die Mitarbeiter müssen in ihrer Ausführung entsprechend koordiniert werden. Dies gilt insbesondere bei standortübergreifenden Aktivitäten. Sie werden dabei durch Maschinen und/oder spezieller Software wie CAD im Konstruktionsbereich, ERP im betriebswirtschaftlichen Bereich oder MES im fertigungstechnischen Bereich unterstützt. Damit bildet auch der organisatorische Struktur einen Bestandteil von PLM: Im Sinne der Effizienz muss sicher gestellt werden, dass jeder Mitarbeiter bzw. jedes DV-System zum richtigen Zeitpunkt sämtliche Daten bzw. Informationen in der aktuellen Form erhält, die zur erfolgreichen Tätigkeitsausführung notwendig sind. Die erfolgreiche Umsetzung einer PLM-Strategie beeinflusst folgende Schwerpunkte im Unternehmen nachhaltig: x den Aufbau und die Struktur der Produkte; x davon abgeleitet, den Aufbau und die Struktur der Abläufe/Prozesse und

1.3

Anspruch und Zielgruppe des Buches

5

x den Aufbau der vorhandenen Unternehmensorganisation. Sämtliche Daten und Informationen, die zwischen diesen drei Unternehmensschwerpunkten fließen (Daten- und Informationsflüsse), werden auf der systemtechnischen Ebene durch ein Produktdatenmanagement-System (PDMS) gesteuert. Die effektive und effiziente Steuerung der D&I-Flüsse, in Verbindung mit einem definierten Aufbau der Schwerpunkte Produkte, Prozesse und Organisation, bildet eine möglichen Weg, um den Teufelskreis zu durchbrechen.

1.3 Anspruch und Zielgruppe des Buches Bei sämtlichen durchgeführten Industrieprojekten im PLM-Bereich, für die beide Autoren verantwortlich waren bzw. sind, konnte ein gemeinsamer Faktor festgestellt werden: Die betreuten mittelständischen Unternehmen hatten sich bereits mit den Schwerpunkten PLM und seiner rechnerunterstützten Umsetzung durch ein PDMS auseinandergesetzt. Jedoch waren den Projektbeteiligten oftmals die Bedeutung und das Ausmaß von teilweise tiefgreifenden Auswirkungen einer PLM-Umsetzung und PDMSEinführung nicht bewusst. Dies führte häufig zu PLM-Fragestellungen wie x Was ist überhaupt PLM? x Was bringt es für mein Unternehmen, wo liegen die Grenzen und was bedeutet dies für mein Unternehmen, meine Mitarbeiter, meine Produkte und meine Abläufe überhaupt? x Wie gehe ich am besten bei der Umsetzung von PLM und bei einer PDMS-Einführung am effizientesten und risikoärmsten vor? x Wie „PLM-fit“ ist mein Unternehmen und wie kann ich das überprüfen? x An welchen konkreten Stellen muss mein Unternehmen noch „Hausaufgaben“ machen, so dass ich ein PDMS möglichst sofort nach seiner Einführung produktiv einsetzen kann? Da ein PDMS in vielen Unternehmen zunächst innerhalb des Technischen Bereichs eingeführt wird, gelten dieselben Fragestellungen sinngemäß auch für einzelnen Abteilungen bzw. Unternehmensstandorte. Aus diesen Fragen, welche die Unsicherheit vieler mittelständischer Unternehmen im Umgang mit PLM und/oder PDMS aufgrund mangelnder Erfahrung deutlich machen, entstand die Idee, zur strategischen und operativen Planung, Umsetzung und Bewertung ein praxisorientiertes Werk zu verfassen. Neben den gewonnenen Projekterfahrungen beinhaltet es konkrete Vorgehensweisen zur Erstellung einer unternehmensindividuellen

6

1 Einleitung

PLM-Strategie, die Planung einer PDMS-Einführung sowie eine ständige Bewertung und Controlling des gewünschten Zielerreichungsgrads. Dazu sind Kennzahlen wie der PDMS-Reifegrad eines Unternehmens oder Hilfsmittel wie die Capability Scorecard beschrieben, deren Anwendung beispielhaft gezeigt wird. Diese Zusammenhänge, welche im Buch erläutert sind, zeigt schematisch Abb. 1-2.

Abb. 1-2 Grundsätzliche Zusammenhänge bei der Umsetzung und Bewertung von PLM in mittelständischen Unternehmen

Neben der gewünschten Praxisorientierung steht ein zweiter, aber häufig vernachlässigter PLM-Aspekt im Mittelpunkt des Buches, obwohl er in der Bezeichnung Product Lifecycle Management beinhaltet ist: Das Verständnis einer erfolgreichen PLM-Strategie geht von den Unternehmensprodukten aus – seien diese nun materiell wie ein Mobiltelefon oder immateriell wie eine angebotene Dienstleistung. Dieser produktzentrierte Ansatz ist insofern bedeutsam, da in den betreuten Projekten viele Aktivitäten entweder IT-getrieben oder Prozessgetrieben waren. Im späteren Verlauf wird gezeigt, dass die beiden letzten Ansätze sich häufig mit den bestehenden Produkten eines Unternehmens schwer vereinbaren lassen, falls diese bereits zu Beginn eines PLM-Strategie nicht sorgsam in die Planungen mit einbezogen werden. Dieses Dilemma führt häufig zu großen internen Widersprüchen, an denen die Umsetzung einer PLM-Strategie oftmals scheitert. Sämtliche Ausführungen in diesem Buch erheben nicht den Anspruch, bestehende und etablierte Literatur zu dieser Thematik ersetzen zu wollen.

1.4

Aufbau des Buches

7

Sie sollen ausschließlich als Ergänzung verstanden werden, um den Praktiker eine erste Orientierung ermöglichen zu können. Aus diesem Grund wird auf bedeutsame Themen wie die Nummernsystematik oder die Produktversionierung, die innerhalb der Umsetzung von PLM berücksichtigt werden müssen, an den entsprechenden Stellen nicht vertieft eingegangen, sondern an die jeweilige Fachliteratur verwiesen. Damit wird nicht nur der wissenschaftliche Anspruch, den die Autoren wahren wollen, unterstützt, dass Buch wird dadurch auch zu einer ersten Orientierung für den Leser in Bezug auf empfehlenswerte Sekundärliteratur. Sie findet sich am Ende eines jeden Kapitels. Das Buch ist kein IT-Buch, obwohl an entsprechenden Stellen ITspezifische Fragestellungen behandelt werden. Dies geschieht jedoch nur in einer Tiefe, die für ein Verständnis der beschriebenen Zusammenhänge notwendig ist. Auch in diesem Fall wird gezielt auf entsprechende Literatur verwiesen. Angesprochen werden sämtliche Ingenieure, Projektleiter und Managementmitglieder bzw. Geschäftsführer mittelständischer Unternehmen in allen Branchen, die sich mit dem Product Lifecycle Management beschäftigen. Dabei sind die Ausführungen nicht nur auf die Umsetzung von PLM und die Einführung eines PDMS beschränkt, sondern können auch bei einer bereits laufenden Betriebsphase angewendet werden. Dies gilt besonders für das Controlling des gewünschten Zielerreichungsgrads.

1.4 Aufbau des Buches Aufgrund des beschriebenen Anspruchs besitzt das Buch zwei Schwerpunkte, die durch betriebswirtschaftliche Betrachtungen und ein umfassendes Fallbeispiel ergänzt werden: x strategische Fragestellungen und Ausführungen zu PLM sind als Wegweiser in den beiden ersten Kapiteln nach der Einleitung behandelt. x operative Fragestellungen zur PLM-Umsetzung mittels der Einführung eines PDMS und die augenblickliche Eignungsbewertung des Unternehmens sind die Inhalte des vierten bis siebten Kapitels i. S. anwendbarer Werkzeuge. x wirtschaftliche Fragestellungen beschreibt das achte Kapitel. x Ein Fallbeispiel auf der Grundlage eines durchgeführten Industrieprojekts fasst exemplarisch und in anonymisiertes Form sämtliche Ausführungen der vorherigen Kapitel zusammen. Dieses Kapitel entspricht in-

8

1 Einleitung

haltlich dem Buchaufbau, so dass ein schneller Vergleich zwischen Theorie und Praxis möglich ist. Der Buchaufbau ist zur schnellen Übersicht in Abb. 1-3 dargestellt. Dabei können die Inhalte der einzelnen Kapitel entweder nacheinander durchgelesen werden. Es ist jedoch auch möglich, jedes einzelne Kapitel herauszugreifen, um sich über den dort behandelten Themenkomplex zu informieren.

Abb. 1-3 Behandelte Fragestellungen des Buches und Kapitelinhalte

Die Einleitung (Kap. 1) umreißt die Buchthematik und stellt die behandelten Buchinhalte vor. Kapitel 2 beschreibt die allgemeine Unternehmenssituation, die zur Unternehmenskomplexität führt und die letztendlich durch PLM beherrscht wer-

1.4

Aufbau des Buches

9

den soll. Eine typische Folge von Unternehmenskomplexität ist das Auftreten einer hohen Anzahl von Produktvarianten, die einerseits unzureichend beherrscht werden und andererseits Auswirkungen auf die interne Ablauf- und Aufbauorganisation besitzen. Neben der Definition von PLM wird eine Vorgehensweise zur Erstellung einer unternehmensindividuellen PLM-Strategie vorgestellt und auf drei erfolgsentscheidende Maßnahmen hingewiesen. Sie beeinflussen die drei Hauptunternehmenselemente Produkte, Prozesse und Organisation. Allgemeine Anforderungen an das Unternehmen und insbesondere Anforderungen, die die PLM-Strategie an die drei Hauptunternehmenselemente stellt, bilden den Inhalt von Kapitel 3. Es werden zunächst die relevanten Begriffe wie Modularisierung, Baukästen oder Module besprochen, um eine gemeinsame Verständnisgrundlage zu schaffen. Anschließend werden die Anforderungen und insbesondere die Auswirkungen auf die Produkte, die Prozesse und die Unternehmensorganisation behandelt. Dabei liegt der Schwerpunkt auf der Beschreibung geeigneter Produktarten wie MultiLife-Produkte, die eine PLM-Strategie besonders effizient unterstützen. Eine Möglichkeit, die bestehenden Produkte in ihrer Struktur an die Anforderungen von PLM anzupassen, besteht in der Erstellung von Referenzprodukten. Die Referenzprodukt-Strategie zur Vermeidung von unbeherrschter Variantenerzeugung bei gleichzeitiger Abdeckung vieler Kundenwünsche wird in Kap. 4 beschrieben. Aufgrund der hohen Datenmengen, die mit Referenzprodukten verbunden sind, kann diese Strategie nur effizient im Unternehmen wirken, wenn sie systemtechnisch durch ein PDMS unterstützt wird. Dies hängt wesentlich von dem systemtechnischen Aufbau und von den Funktionsmöglichkeiten ab. Es wird dargelegt, dass PLM auf der operativen Ebene wesentlich durch die Einführung eines PDMS unterstützt wird. Folglich müssen sich Unternehmen mit der Planung einer Systemeinführung auseinandersetzen. Es werden Anforderungen von mittelständischen Unternehmen identifiziert, die diese an eine Vorgehensweise zur PDMS-Einführung stellen. Dies beinhaltet neben konkreten Vorgehensschritten auch die Möglichkeit eines ständigen Projektcontrollings, um Abweichungen von den PLM-spezifischen Projektzielen bereits während der Systemeinführung erkennen zu können und mit entsprechenden Maßnahmen gegensteuern zu können. Eine weitere Anforderung ist der Wunsch nach einer Bewertung der augenblicklichen Unternehmenseignung, das (kostenintensive) PDMS gemäß den Unternehmenszielsetzungen einsetzen zu können. Es wird folglich eine Bewertungsmethode gewünscht, die vor, während und nach der Systemeinführung (also auch in der Betriebsphase) die PDMS-Fähigkeit misst und durch die Kennzahl PDMS-Reifegrad beschreibt. Die PDMS-Fähigkeit

10

1 Einleitung

lässt sich anhand von fünf PDMS-Einflussgrößen ermitteln. Diese Begriffe werden in Kapitel 4 definiert. Es wird gezeigt, dass der Reifegrad für die einzelnen Hauptunternehmenselemente gezielt ermittelt werden und bei einem ungenügenden Ergebnis entsprechende Verbesserungsmaßnahmen identifiziert werden können. Der Lösungsansatz, welcher diese Anforderungen berücksichtigt, ist der PDMS-Regelkreis. Er besteht aus zwei Bausteinen, die in Kap. 5 vorgestellt werden. Dabei handelt es sich um die beiden Bausteine Einführung des PDMS und Ermittlung des PDMS-Reifegrads. Der erste Baustein beschriebt die Vorgehensweise bei der Planung und Einführung eines PDMS. Gleichzeitig werden mit ihm die unternehmensindividuellen PDMSEinflussgrößen ermittelt, welche die Grundlagen für den zweiten Baustein, die eigentliche Eignungsermittlung des Unternehmens durch den PDMSReifegrad, bilden. Diese Bewertung dient als Controlling-Grundlage nicht nur während der Systemeinführung, sondern auch während der Systembetriebsphase. Anhand des ermittelten Reifegrads können Verbesserungspotenziale identifiziert und entsprechende Verbesserungsmaßnahmen gezielt eingeleitet werden, um den PDMS-Reifegrad zu erhöhen. Die Umsetzung der Verbesserungsmaßnahmen geschieht durch den ersten Baustein; ihre Auswirkungen auf den PDMS-Reifegrad werden mit einer erneuten Bewertung überprüft. Damit ist der PDMS-Regelkreis geschlossen. Beide Bausteine gliedern sich in jeweils vier einzelne Arbeitsschritte. Ihre Ziele und die Vorgehensweisen innerhalb jedes Arbeitsschritts sowie die dafür verwendeten Hilfsmittel werden in den Kap. 6 und 7 ausführlich beschrieben. Dies geschieht mittels Flussdiagrammen, checklistenartigen Aufzählungen, Kriterienkatalogen, Klassifizierungsschemata sowie entsprechenden Dokumententemplates, die direkt verwendet oder ohne viel Aufwand für die Unternehmenspraxis angepasst werden können. Auch die systemtechnische Seite hinsichtlich der vorhandenen IT-Landschaft im Unternehmen wird bei den Ausführungen berücksichtigt. Ein wesentlicher Aspekt bei der Umsetzung von PLM ist die Wirtschaftlichkeitsbetrachtung. Kapitel 8 widmet sich diesem zentralen Aspekt. Das Management möchte wissen, welchen Nutzen und welche Risiken ein PDMS für das Unternehmen beinhaltet. Die zentrale Frage hierbei sind selbstverständlich die zu erwartenden Kosten für die Systemeinführung und den laufenden Systembetrieb. Diese Aspekte werden durch die Erstellung eines Business Case erfasst. Er beinhaltet neben dem erwarteten Nutzen, den möglichen Risiken und den definierten Zielen auch eine Wirtschaftlichkeitsbetrachtung. Hierzu sind exemplarische Kennzahlen

1.5

Danksagungen der Autoren

11

erläutert, die sich bei durchgeführten Industrieprojekten als sinnvoll erwiesen haben. Auch die Gründe für die Unsicherheit einer Wirtschaftlichkeitsbetrachtung im PLM-Bereich werden erläutert. Die Inhalte sämtlicher Kapitel werden durch ein Fallbeispiel zusammengefasst, welches auf einem durchgeführten Industrieprojekt beruht. Dabei handelt es sich um ein mittelständisches Zulieferunternehmen aus dem Maschinenbau. Dieses Fallbeispiel wird im abschließenden Kap. 9 behandelt. Jedes Kapitel beginnt mit einer kurzen Inhaltsangabe, die den Bezug zu den Ergebnissen des vorangegangenen Kapitels herstellt. Eine Zusammenfassung am Kapitelende beschreibt die gewonnenen Erkenntnisse. In den Abschnitten selbst sind relevante Begriffe kursiv geschrieben. Diese Begriffe finden sich im Sachwortverzeichnis.

1.5 Danksagungen der Autoren An der Entstehung eines Buches sind niemals nur die Autoren allein beteiligt; es ist das Ergebnis vieler Tätigkeiten, Erfahrungen und Gespräche. Aus diesem Grund möchten die Autoren allen danken, die in direkter oder indirekter Weise an diesem Werk mitgewirkt haben. Besonderen Dank schulden wir Herrn Dipl.-Ing. Ingo Schulz sowie Herrn Dipl.-Ing. Stephan Stockinger, die unser Manuskript kritisch beurteilt und an entsprechenden Stellen hilfreiche Hinweise gegeben haben. Ebenso danken wir dem Springer-Verlag für seine Unterstützung. Hier ist insbesondere Frau Hestermann-Beyerle hervorzuheben, die dieses Buch während seiner Umsetzung technisch und inhaltlich ausgezeichnet betreut hat. Literatur Brezing A (2006) Planung innovativer Produkte unter Nutzung von Design- und Ingenieurdienstleistungen. Shaker, Aachen Domin A, Maskow W (1985) Design-to-Cost (DTC) – eine Methode zur Kostenreduzierung in der Produktentwicklungsphase. In: Konstruktion 37, SpringerVDI, Düsseldorf Horvath P (1993) Target Costing. Schäffer-Poeschel, Stuttgart Mertins K, Alwert K, Heisig P (2005) Wissensbilanzen - intellektuelles Kapital erfolgreich nutzen und entwickeln. Springer, Berlin-Heidelberg-New York North K (2005) Wissensorientierte Unternehmensführung – Wertschöpfung durch Wissen. 4., aktualisierte und erweiterte Auflage. Gabler, Wiesbaden

12

1 Einleitung

Schnauffer HG, Stieler-Lorenz B, Peters S (2004) Wissen vernetzen - Wissensmanagement in der Produktentwicklung. Springer, Berlin-Heidelberg-New York Seidenschwarz W (1993) Target Costing – marktorientiertes Zielkostenmanagement. Vahlen, München Sveiby KE (1998) Wissen ist Kapital - das unentdeckte Vermögen. Moderne Industrie, Landsberg am Lech

2 Die Situation heutiger Unternehmen

Aufgrund der bestehenden nationalen und internationalen Marktbedingungen ist die Situation heutiger Unternehmen durch eine hohe Komplexität gekennzeichnet. Die konkreten Ursachen für diese Unternehmenskomplexität sind vielfältig: Eine Ursache liegt in der Verflechtung zwischen den internen Geschäftsprozessen mit externen Unternehmen wie Produktionspartnern oder verteilten Standorten. Doch auch durch die Ausführung der eigenen Geschäftsprozesse und der dazu notwendigen Daten und Informationsflüsse entsteht Komplexität. Hier ist besonders der Produktentstehungsprozess relevant. Folglich sind Strategien zur Reduktion sowie zur Beherrschung der Unternehmenskomplexität erforderlich. Im Rahmen möglicher strategischer Ansätze bildet die PLM-Strategie einen wesentlicher Lösungsansatz. In diesem Kapitel werden die Ursachen für die Unternehmenskomplexität beschrieben und aufgezeigt, wie sie mit PLM beherrschbar gemacht werden kann. Dies beinhaltet neben der Beschreibung einer Vorgehensweise zur Entwicklung einer unternehmensindividuellen PLM-Strategie auch die Identifikation von wesentlichen Maßnahmen, die für eine erfolgreiche PLM-Umsetzung entscheidend sind.

2.1 Ursachen und Folgen von Unternehmenskomplexität Befragt man heute Mitarbeiter in Unternehmen, wie sie ihre eigene Situation empfinden, so wird neben der allgemein hohen Arbeitsanspannung immer wieder die Komplexität des Umfeldes als Ursache für Fehlleistungen genannt [Luczak 1998; Braun 2003]. Als unbefriedigend wird insbesondere die fehlende Zeit zur Beschäftigung mit neuen und innovativen Produkten betont. Dies ist nicht nur für die einzelnen Mitarbeiter demotivierend, sondern insbesondere für das Unternehmen schädlich. Ressourcen werden vergeudet für Aufgaben, die vom Kunden nicht oder nur sehr gering honoriert werden. Typische Ursachen für diese Situation zeigt Abb. 21; sie werden nachfolgend diskutiert.

14

2 Die Situation heutiger Unternehmen

Abb. 2-1 Exemplarische Ursachen heutiger Unternehmenskomplexität

Ein Unternehmen ist heutzutage eingebunden in ein umfangreiches Informationsnetz. Dieses enthält weite Bereiche, die außerhalb des Unternehmens liegen. Man spricht hier von extern determinierter Unternehmenskomplexität. Sie ist gekennzeichnet durch Faktoren wie x die nationale oder internationale Marktsituation; x die Anforderungen, Erwartungen und/oder Wünsche der potenziellen Kunden; x die vorhandenen Wettbewerber und ihre Reaktion auf die Kundenanforderungen wie Preisgestaltung oder Produktangebotsumfang; x den technischen Fortschritt, der v. a. in Konsumgütern wie Mobiltelefonen, Laptops oder Digitalkameras umsetzbar gemacht werden muss; oder auch x Einflüsse aus Politik und Gesellschaft wie ein vertieftes Verständnis hinsichtlich Umwelt- und/oder Entsorgungsfragen. Häufig manifestieren sich derartige Einflüsse in umzusetzende, oftmals landestypische Gesetzgebungen, die in der Produktentwicklung berücksichtigt werden müssen. Die Globalisierung ist eine Tatsache, die heute jedes Unternehmen betrifft. Die Gründe für ein Unternehmen, global zu agieren, können dabei sehr unterschiedlich sein: Sie reichen von der Möglichkeit einer günstigen Beschaffung von Produktionsmitteln bis hin zu strategischen Allianzen mit ausländischen Unternehmen, um gemeinsam deren Heimatmarkt zu bedienen. Unabhängig von ihren Ursachen hat die Globalisierung weit reichende Folgen für Hersteller von Produkten und für deren Konsumenten. Neben den erwähnten Folgen wie einem Preisverfall oder einer Angebotsvielfalt ist hier insbesondere eine zunehmende Transparenz der Märkte zu nennen, die in dieser Form früher nicht vorhanden war. Als Konsequenz wird der Kunde immer anspruchsvoller, da er weiß, dass es

2.1

Ursachen und Folgen von Unternehmenskomplexität

15

irgendwo auf der Welt einen Hersteller gibt, der das nachgefragte Produkt noch kostengünstiger und/oder schneller produziert. In Ländern mit höheren Herstellkosten zwingt der ständig zunehmende Wettbewerbsdruck die Unternehmen, immer neue Kundenbedürfnisse zu finden und mit entsprechenden Produkten zu befriedigen [Hichert 1986; Jeschke 1997; Lindemann u. Baumberger 2006]. Dies bedeutet, dass jede Marklücke entdeckt und geschlossen werden will. Neben diesen markt- und wettbewerbsgetriebenen Faktoren gibt es noch weitere, die vom Unternehmen nur sehr bedingt beeinflusst werden können. Hierzu zählen insbesondere der allgemeine technische Fortschritt und das politische und gesellschaftliche Umfeld. Obwohl diese beiden Faktoren für alle Unternehmen im Wesentlichen gleich sind, kommt es insbesondere hierbei auf die richtigen und schnellen Entscheidungen sowie auf Produkte an, die möglichst zeitnah und mit geringem Kostenaufwand an die neuen (Markt-)Gegebenheiten anpassbar sind. In Kap. 3 wird dargelegt, dass insbesondere modulare Produkte diese Anforderungen unterstützen. Allerdings sind auch bei entsprechend strukturierten Produkten und dem Einsatz moderner, vorwiegend rechnerunterstützter Hilfsmittel während der Produktentstehung die Reaktionszeiten auf Veränderungen der Randbedingungen immer noch relativ lang. Wie entscheidend ein schneller Markteintritt mit adäquaten Produkten sein kann, zeigt die Abb. 2-2.

Abb. 2-2 Einfluss eines schnellen Markteintritts neuer Produkte auf den Erfolg eines Unternehmens [Kramer u. Kramer 1997]

16

2 Die Situation heutiger Unternehmen

Verschärft wird die Situation insbesondere bei hochtechnischen Konsumgütern wie Digitalkameras oder Laptops durch deren geringe Präsenzdauer am Markt. Die Zeitspanne, die zur Verfügung steht, um mit einem Produkt Geld zu verdienen, wird damit immer kürzer; dementsprechend muss auch die Zeitdauer für die Produktentstehung bis zum Markteintritt (Time-tomarket) verkürzt werden. Dies stellt für Unternehmen, die die genannten hochtechnischen Konsumgüter produzieren, ein echtes Dilemma dar. Um sich vom Wettbewerber zu differenzieren, muss viel Aufwand (und damit Kosten) in den Entstehungsprozess des Produktes investiert werden. Dagegen ist die Zeitspanne für die Erwirtschaftung eines profitablen Return on Investment (RoI) hinsichtlich dieses Produkts sehr kurz. Als mögliche Folge wäre bspw. ein höherer Marktpreis denkbar, der sich aber wegen der geschilderten Wettbewerbssituation schwer durchsetzen lässt. Von entscheidender Bedeutung für den Erfolg eines Unternehmens ist also dessen Reaktionsgeschwindigkeit auf veränderte Rahmenbedingungen bei gleichzeitiger Kontrollhoheit über die Kosten. Ein Unternehmen ist heute gezwungen, eine Vielfalt von Produkten sehr kostengünstig anzubieten. Diese Produktvielfalt wird als externe Vielfalt bezeichnet, da sie durch die beschriebenen externen Faktoren getrieben ist, die sich außerhalb des Unternehmens befinden. Dabei ist es nicht entscheidend, ob es sich bei den Produkten für neue Marksegmente um wirklich neue Produkte handelt. Wichtig ist vielmehr der Eindruck, den der Kunde hat, also der empfundene Neuheitsgrad. Bei Konsumgütern wie Digitalkameras oder Mobiltelefonen spielt der tatsächliche oder empfundene Neuheitsgrad eine bedeutende Rolle für die Akzeptanz des Produkts durch den Kunden. Bei Investitionsgütern wie Automobilen steht dagegen die individuelle Lösung eines Kundenproblems im Vordergrund. Als Folge aus den genannten extern determinierten Faktoren resultiert eine hohe Anzahl an Produktvarianten, mit denen das Unternehmen die vorhandenen Kundenbedürfnisse optimal befriedigen will. Die Existenz einer hohen Variantenanzahl resultiert jedoch auch aus einer Komplexität, die innerhalb des Unternehmens auftritt. Sie wird als intern determinierte Komplexität bezeichnet. Einige Ursachen sind in Abb. 2-1 auf der rechten Seite gezeigt. Insbesondere die Organisationsformen für die Ablauf- bzw. Aufbauorganisation sind hier zu nennen (interne Vielfalt). Hierdurch werden ganz entscheidend u. a. sämtliche Informationsschnittstellen festgelegt. Da alle Unternehmensprozesse gleichzeitig Wissens- und damit auch Informationsmanagementprozesse sind, wird deutlich, dass durch eine nicht angepasste Organisation die Komplexität im Unternehmen unnötig ansteigt [Schuh 2004].

2.1

Ursachen und Folgen von Unternehmenskomplexität

17

Von sämtlichen Prozessen besitzt der Produktentstehungsprozess (PEP) den bedeutendsten Einfluss auf die Komplexität innerhalb des Unternehmens. Durch seine Gestaltung und seinen Umfang werden die beteiligten Bereiche, Abteilungen bzw. Mitarbeiter hinsichtlich ihrer Anzahl, ihrer Verantwortung und ihren (Arbeits-)Beziehungen untereinander festgelegt. Der PEP umfasst sämtliche Aktivitäten, die sich, ausgehend von der Ideenfindung für das Produkt bis hin zum Abschluss der Produktion, auf die gesamte Produktentstehung beziehen [Pahl et al. 2007].

Abb. 2-3 Die verschiedenen Konkretisierungsstufen des PEP am Beispiel des Konstruktionsprozesses

Die Komplexität aus dem PEP entsteht einerseits aus der Anzahl der zu bearbeitenden Teilprozesse sowie deren einzelnen Teilaufgaben inklusive ihrer zu berücksichtigenden Daten und Informationen. Andererseits sind die einzelnen Teilaufgaben in ihrem Ablauf häufig nicht mehr sequentiell, sondern vernetzt miteinander verbunden. Damit der PEP effektiv umgesetzt werden kann, muss, ausgehend von einzelnen Geschäftsprozessen wie dem Konstruktionsprozess, jeder zugehörige Prozess bzw. Teilprozess soweit konkretisiert werden, dass alle am Prozess beteiligten Mitarbeiter eindeutig ihre Aufgabeninhalte kennen und diese ausführen können. Abbildung 2-3 zeigt den Zusammenhang der Teilprozessschritte und der Konkretisierungsgradstufen von Prozessen am Beispiel des Konstruktionsprozesses. Die vorhandenen Geschäftsprozesse bilden folglich eine wesentliche Komplexitätsursache innerhalb eines Unternehmens.

18

2 Die Situation heutiger Unternehmen

Einen weiteren Einfluss auf die Situation des Unternehmens hinsichtlich seiner Reaktionsfähigkeit auf sich verändernde Rahmenbedingungen haben sämtliche Produkte, mit denen es sich in der Vergangenheit befasst hat. Neben rationell bedingten Aspekten besitzt eine bestehende Produktvielfalt auch eine historische Komponente. So kommt es im Laufe einer Geschäftsbeziehung auf Seiten des Kunden zu Gewöhnungseffekten: Kunden machen Bedürfnisse geltend in der berechtigen Erwartung, dass diese durch eine entsprechende Lösung des Anbieters erfüllt werden. Häufig wird dabei aber die zugrunde liegende Notwendigkeit nicht kritisch genug hinterfragt. So kommt es zu Produktvarianten, deren Nutzen nicht die verursachten Entwicklungs- und Herstellungskosten rechtfertigen und die durch die Erlöse von betriebswirtschaftlich erfolgreichen Produkten im Unternehmen subventioniert werden [Schuh 2005]. Zusätzlich kumulieren sich die im Laufe der Zeit erzeugten Produktdaten. Indem während der Produktentwicklung auf Altdaten zurückgegriffen wird, lassen sich zwar Ressourcen und Entwicklungszeit sparen. Oftmals steigt in der industriellen Praxis durch unkontrollierte Wiederverwendung die Menge der aktiven Produktdaten und damit die interne Vielfalt überproportional an. Die Ursache ist eine fehlende Strategie im Umgang mit der Verwendung von Altdaten. Im Laufe des Unternehmenslebens haben sich dadurch eine Unternehmenshistorie und ein Unternehmenswissen gebildet, die eine sehr wichtige Basis für den künftigen Unternehmenserfolg darstellen. Bedauerlicherweise können beide jedoch auch das Unternehmen bei der Investition in neue Technologien hemmen. Aus der Summe aller genannten Ursachen entsteht eine hohe interne Unternehmenskomplexität, die sich in einer hohen Anzahl an vorhandenen Produktvarianten niederschlägt [Franke et a. 2002; Schuh 2005; Hofbauer u. Schweidler 2006]. Der Begriff Variante umfasst nach [DIN 199] „Gegenstände ähnlicher Form und/oder Funktion mit in der Regel hohem Anteil identischer Gruppen oder Teile“. [Franke 1998] erweitert diese Definition, indem er zwischen Produkt- und Prozessvarianten technischer Systeme unterscheidet: Eine Variante eines technischen Systems ist ein anderes technisches System gleichen Zwecks, das sich in mindestens einer Beziehung oder einem Element unterscheidet. Ein Element unterscheidet sich von einem anderen Element in mindestens einer Eigenschaft.

2.1

Ursachen und Folgen von Unternehmenskomplexität

19

Damit wird deutlich, dass eine nicht mehr beherrschbaren Variantenanzahl sowohl die Produkte als auch sämtliche Abläufe betrifft, die zur ihrer Entwicklung und Umsetzung notwendig sind. Es ist leicht vorstellbar, dass in Verbindung mit den ausführenden Organisationseinheiten und Mitarbeitern die Komplexität exponenziell ansteigt. In der Abb. 2-1 sind diese Aspekte als Folge der extern und intern determinierten Situation von Unternehmen übersichtsartig dargestellt. Der vom Markt geforderten externen Vielfalt steht also die interne Vielfalt im Unternehmen gegenüber. Hierunter wird die Anzahl der Produktelemente und -komponenten verstanden, mit der die verschiedenen am Markt angebotenen Produktvarianten erzeugt werden. Typischerweise besteht zwischen der externen und internen Vielfalt eines Unternehmens eine enge Kopplung. Eine hohe externe Vielfalt ruft also auch im Normalfall eine hohe interne Vielfalt hervor. In Abb. 2-4 ist dieser Zusammenhang wiedergegeben. Werden keine Maßnahmen ergriffen, gerät das Unternehmen in eine Komplexitätsfalle.

Abb. 2-4 Entstehung der Komplexitätsfalle in Unternehmen

Die Komplexität im Unternehmen ist allerdings nicht nur durch die Anzahl der Produktvarianten bestimmt. Vielmehr erhöht sie sich aufgrund der Vielfalt der Daten, welche den Lebenszyklus eines Produktes von der Planung, dem Entwurf und der Gestaltung über die Fertigung und Nutzung bis zur Verwertung bzw. Entsorgung beschreiben. Typische Daten sind bspw. Geometriedaten, Simulationsmodelle, Qualitätssicherungs-Daten, Fertigungsdaten, Serviceinformationen oder Vertriebsdaten. Zwischen Vielfalt und Komplexität des Lebenszyklus besteht ein direkter Zusammenhang. Die interne Vielfalt ist ein wesentlicher Komplexitätstreiber, da mit der Vielfalt der Daten aus dem Lebenszyklus eines Produktes ohne weitere Maßnahmen auch die Zahl der Beziehungen und Abhängigkeiten wächst. Dies wiederum hat komplexere Prozesse zur Folge und erfordert umfangreichere Ressourcen.

20

2 Die Situation heutiger Unternehmen

Im Resultat werden wegen der schlechteren Effizienz der Produktentstehungsprozesse die Durchlaufzeiten der einzelnen Prozessschritte verlängert und zusätzliche Kosten verursacht. Diese Kosten sind sowohl ressourcen- als auch zeitkritisch. In einigen Fällen werden die Prozesse durch eine hohe Komplexität sogar so stark gestört, dass es zu einer Verringerung der Effektivität kommt und benötigte Daten nicht mehr oder nur eingeschränkt verfügbar sind. In dem Spannungsfeld zwischen der Positionierung des Unternehmens am Markt und der Senkung von Komplexitätskosten sind Lösungen zur Optimierung der Profitabilität eines Unternehmens erforderlich. Sie müssen unter dem Gesichtspunkt der Absatzsteigerung die Bedürfnisse der Kunden befriedigen und gleichzeitig die durch die Komplexität entstehenden Kosten minimieren.

2.2 PLM als strategischer Ansatz zur Beherrschung der Komplexität In dem geschilderten Spannungsfeld zwischen Maximierung der Umsätze durch marktgerechte Produkte einerseits und Minimierung der Komplexitätskosten andererseits stellt die Vielfalt den Stellhebel zur optimalen Positionierung eines Unternehmens dar. Ein Unternehmen steckt letztlich in dem Dilemma, bei wachsender externer Vielfalt die interne Vielfalt möglichst klein zu halten und gleichzeitig die nach wie vor hohe Komplexität im Sinne eines effektiven Produktentstehungsprozesses zu beherrschen. Aufgrund der geschilderten Situation sind von dem überwiegenden Teil der Unternehmen Maßnahmen ergriffen worden, um ihre Situation hinsichtlich der dargestellten Probleme zu verbessern. Dabei darf jedoch keine einseitige Fokussierung auf nur einen Faktor geschehen; vielmehr müssen bei geplanten Maßnahmen alle Bausteine modernen Unternehmensmanagements berücksichtigt werden, wie sie in Abb. 2-5 gezeigt sind. Einen wesentlichen Ansatz zur Bewältigung der geschilderten Probleme bildet das Product Lifecycle Management (PLM) [Feldhusen et al. 2006]: Product Lifecycle Management (PLM) ist eine wissensbasierte Unternehmensstrategie für alle Prozesse und deren Methoden hinsichtlich der Produktentwicklung von der Produktidee bis hin zum Recycling. Vor dem Hintergrund der hier betrachteten Aspekte Komplexität und Produktvielfalt eines Unternehmens muss ein wesentlicher Gesichtspunkt des

2.2

PLM als strategischer Ansatz zur Beherrschung der Komplexität

21

PLM näher erläutert werden. Es geht beim PLM nicht ausschließlich um das Managen der Informations- und Datenflüsse im Unternehmen als Ausdruck des Wissensmanagements. Wie bereits ausgeführt wurde, könnten dadurch lediglich die aus der Organisation resultierenden Komplexitätstreiber beeinflusst werden. Vielmehr bezieht sich die PLM-Strategie auf das Produkt, wie es bereits in ihrer Bezeichnung Product Lifecycle Management zum Ausdruck kommt. Die Vielfalt der Produkte und ihrer Komponenten ist der zweite wesentliche Komplexitätstreiber im Unternehmen. Aus der Vielfalt der Produkte entsteht die Vielfalt und damit die Komplexität im Unternehmen. Eine PLM-Strategie muss also sowohl die Informationsflüsse im Unternehmen als auch die Ausprägung der Produkte subsumieren.

Abb. 2-5 Bausteine modernen Unternehmensmanagements [Kramer u. Kramer 1997]

Diese beiden Hauptaspekte von PLM können nicht getrennt betrachtet werden, da sie sich gegenseitig beeinflussen. Es sei nochmals darauf hingewiesen, dass die Informationsflüsse im Unternehmen letztlich dessen Organisation abbilden. Im Zentrum der PLM-Strategie stehen das Produkt und seine Gestaltung. Hierauf aufbauend können dann Aussagen zu den Informationsflüssen im Unternehmen und der zugehörigen adäquaten Organisationsstruktur gemacht werden.

22

2 Die Situation heutiger Unternehmen

Grundlage zur Entwicklung einer unternehmensindividuellen PLMStrategie sind die beiden Hauptaspekte, die sich direkt aus den strategischen Hauptzielen ableiten lassen. Sie beziehen sich auf die drei Hauptunternehmenselemente Produkt, Prozess und Organisation, die in Kap. 3 behandelt werden. Für alle drei Hauptunternehmenselemente müssen aus der Unternehmensvision Ziele abgeleitet werden, die mit Hilfe der PLMStrategie erreicht werden können. Typische strategische Ziele in einer PLM-Strategie sind x produktbezogene Ziele:  konfigurierbare Produkte;  weitgehende Produktstandards;  Modularisierung der Produkte;  konsistentes Variantenmanagement;  … x prozessbezogene Ziele:  Verkürzung der Time-to-market;  Reduktion der Teilprozesse;  Schaffung eindeutiger Meilensteine;  … x organisationsbezogene Ziele:  Verkürzung der Kommunikationswege;  Flexibilisierung der Organisation;  Schaffung definierter und eindeutiger Verantwortlichkeiten;  … Diese strategischen Ziele müssen natürlich weiter konkretisiert werden. Am Ende dieses Konkretisierungsprozesses stehen Maßnahmen, deren Umsetzungsgrad durch ein spezifisches und unternehmensindividuelles Kennzahlensystem überprüft werden kann. Auch hierauf wird in Kap. 3 eingegangen.

2.3 Die Entwicklung einer PLM-Strategie Grundsätzlich ist die PLM-Strategie Bestandteil einer übergeordneten, ganzheitlichen Unternehmensstrategie. Deshalb muss PLM aus der Unternehmensstrategie heraus individuell entwickelt werden. Eine Vorgehensweise zur Entwicklung wird nachfolgend beschrieben und ist schematisch in Abb. 2-6 dargestellt.

2.3

Die Entwicklung einer PLM-Strategie

23

Abb. 2-6 Grundsätzliches Vorgehen bei der Entwicklung einer PLM-Strategie

Die Vorgehensweise zur unternehmensindividuellen Erstellung einer PLM-Strategie geschieht vom Allgemeinen zum Speziellen. Dazu muss zunächst eine Unternehmensvision (bzw. ein Unternehmensleitbild) entwickelt werden. Diese Vision ist typischerweise durch folgende exemplarische Kriterien gekennzeichnet: x x x x x x x

sie lässt den Nutzen für das Unternehmen erkennen; sie ist sehr anspruchvoll; sie ist offen in der Umsetzung; sie ist einfach und klar formuliert; sie ist leicht für jeden Mitarbeiter verständlich; sie ist von jedem Mitarbeiter einem Dritten erklärbar; …

Eine Unternehmensvision kann beispielsweise die nachfolgende Formulierung haben: „Wir wollen ein international agierendes Unternehmen werden und dem Markt Produkte anbieten in einer Qualität und Flexibilität, die vom Kunden wahrgenommen und honoriert wird. Wir wollen die Rendite des Unternehmens in den nächsten 10 Jahren verdoppeln.“

24

2 Die Situation heutiger Unternehmen

Aus dieser Unternehmensvision werden in einem ersten Schritt die durch eine PLM-Strategie beeinflussbaren Teile extrahiert. Anders ausgedrückt muss geklärt werden, welche Anteile der Vision durch PLM beeinflusst werden können. Hierzu wird die Unternehmensvision in Bezug zu einem erweiterten PEP gebracht. Der erweiterte PEP schließt die Nutzung des Produkts bis zu dessen Lebensende ein. In dem aufgeführten Beispiel sind die Qualität sowie die Flexibilität der Produkte und die Rendite des Unternehmens direkt durch den erweiterten PEP beeinflussbar. Durch entsprechende Gestaltung des Produkts und den Teilprozessen Entwicklung, Konstruktion und Herstellung seines Entstehungsprozesses werden die genannten Größen determiniert. Im zweiten Schritt wird dann die PLM-Strategie aufgestellt. Sie beschreibt die strategischen, d. h. grundsätzlichen Ansätze, um die aus der Vision extrahierten Hauptziele durch Festlegung der prinzipiellen Prozess- und Produkteigenschaften sowie deren jeweilige Gestaltung zu erreichen. Bezogen auf das Hauptziel „Qualität“ der Vision des Beispiels lässt sich bspw. folgender grundsätzlicher Ansatz ableiten: „Gezielte und kontinuierliche Optimierung der Qualität durch Ermittlung der Ist-Qualität der Produkte und daraus abgeleiteten Maßnahmen zur gezielten Qualitätsverbesserung.“ In diesem Ausschnitt der PLM-Strategie stecken Aspekte des Produktlebenszyklus und der Vision: … die vom Kunden wahrgenommen und honoriert wird…“. Mit Optimierung ist hier also entsprechend der Vision gemeint, die Produktqualität mit den Erwartungen des Kunden abzugleichen. Im Resultat wird unnötige und vom Kunden nicht honorierte oder eine zu niedrige Qualität vermieden. Im dritten Schritt werden die generellen Ziele der PLM-Strategie, unter Berücksichtigung von deren gegenseitigen Abhängigkeiten, zu operativen Zielen fokussiert. Dabei ist darauf zu achten, möglichst eindeutige und klare Ziele zu wählen, deren Erreichungsgrad einfach zu messen ist. In Abb. 2-6 ist zwar eine Abhängigkeit der Teilziele untereinander dargestellt, grundsätzlich sollte diese aber vermieden werden. Als operatives Teilziel des oben aufgeführten Aspekts der PLMStrategie, die Umsetzung einer kontinuierlichen Ermittlung der ISTQualität der Produkte, kann bspw. ein Kundenfeedbacksystem installiert werden. Dessen Ausgestaltung wird dann im vierten Schritt festgelegt. Dieser vierte Schritt umfasst die Definition von Maßnahmen zur Zielumsetzung, die ggf. bis zur Mitarbeiterebene reichen. Gleichzeitig werden die Kennzahlen zur Überprüfung des Zielerreichungsgrades definiert. Im vor-

2.4

Grundsätzliche Maßnahmen zur Umsetzung einer PLM-Strategie

25

liegenden Beispiel „Aufbau eines Kundenfeedbacksystems“ könnten die operativen Maßnahmen folgende Punkte umfassen: x Entwicklung von Fragebögen zur Klärung der Kundenzufriedenheit hinsichtlich der Produktqualität; x Entwicklung von strukturierten Interviews zur Befragung von Schlüsselkunden; x Erstellung/Auswahl einer Software zur Auswertung der Ergebnisse. Zugehörige Kennzahlen könnten beispielsweise sein: x der Rücklaufgrad der Fragebögen; x die Anzahl der geführten Interviews und x der Implementierungs- und Schulungsaufwand für die Software. Daran schließt sich ein kontinuierlicher Controllingprozess an. Dabei ist auf die Bildung eines Regelkreises zu achten, wie er in Abb. 2-6 angedeutet ist. Damit wird die ständige Überprüfung der gesetzten Ziele auf Erreichbarkeit und Zweckmäßigkeit gewährleistet. Im Resultat kann eine solches Controlling zu einer Korrektur der gesetzten Ziele führen. Eine Möglichkeit zur Bewertung und zum Controlling innerhalb der PLM-Strategie wird in Kap. 7 beschrieben.

2.4 Grundsätzliche Maßnahmen zur Umsetzung einer PLM-Strategie Eine tragfähige PLM-Strategie bezieht sich im Wesentlichen auf die richtige Balance zwischen der externen und internen Vielfalt eines Produkts. Die Begründung für diese Aussage ist naheliegend und erschließt sich bei Betrachtung der in Abschn. 2.2 aufgeführten Definition von PLM. Es geht zum einen um das Managen des Datenflusses über den gesamten Produktlebenszyklus und zum anderen um einen möglichst einfachen Produktaufbau. Das Ziel ist die Beherrschung der Komplexität im Unternehmen und diese auf ein Minimum zu reduzieren. Es sollen mit möglichst wenigen Komponenten ein Großteil aller vom Markt honorierten Produktvarianten erzeugt werden können. An dieser Stelle sei angemerkt, dass diese strategische Zielsetzung auch ein Dilemma beinhaltet: Die Reduktion der Anzahl produktbildender Komponenten führt zwar zu einer Reduktion der Anzahl ihrer repräsentierenden Daten, macht jedoch ein qualifiziertes Konfigurationsmanagement erforderlich. Sein wesentlicher Bestandteil ist ein effizientes Schnittstel-

26

2 Die Situation heutiger Unternehmen

lenmanagement zwischen den einzelnen Produktkomponenten. Hierauf wird im nächsten Kapitel eingegangen. Aus den bisherigen Ausführungen lassen sich drei wesentliche Maßnahmen zur Beherrschung der Unternehmenskomplexität ableiten. Sie sind in Abb. 2-7 dargestellt und beinhalten x die nutzen-/marktgerechte Optimierung der externen Vielfalt; x die Entkopplung der externen und internen Vielfalt und x die Bewältigung der Komplexität aufgrund der internen Vielfalt. Alle drei Maßnahmen müssen bei einer erfolgreichen PLM-Umsetzung im Unternehmen berücksichtigt werden. Sie werden nachfolgend beschrieben. Das in Abb. 2-7 gezeigte Produktdatenmanagement-System (PDMSystem) stellt ein wesentliches Hilfsmittel bei der PLM-Umsetzung dar und wird in Kap. 4 behandelt.

Abb. 2-7 Komplexitätstreiber und Optimierungsansätze

Die erste Maßnahme beeinflusst die nutzen- und marktgerechte Optimierung der externen Vielfalt. Sie beschäftigt sich mit der Frage, welchen Nutzen ein Kunde zum Erfolg des Unternehmens beiträgt. Hierbei sind mehrere Aspekte zu berücksichtigen. Zunächst ist der kaufmännische Aspekt i. S. einer Kundenbeitragsrechnung zu beachten. Hierbei zeigt sich oft eine grobe Fehleinschätzung: Kunden, mit denen ein Unternehmen „gute Geschäfte“ zu machen glaubt, tragen häufig wenig oder nichts zum Gewinn bei. Diese Fehleinschätzung stellt sich meistens aufgrund des Um-

2.4

Grundsätzliche Maßnahmen zur Umsetzung einer PLM-Strategie

27

stands ein, dass der Kunde „keine Schwierigkeiten macht“ und „alles glatt läuft“. Die Ursache liegt häufig in dem Bemühen des Unternehmens, als Teil seiner Marktstrategie alle Kundenbedürfnisse bzw. -wünsche mit seinem Produktangebot erfüllen zu müssen. Die Marktstrategie ist somit der zweite wichtige Aspekt. Im Sinne der externen Vielfalt führt sie dazu, dass aus „strategischen Gründen“ ein Kunde oder Marktsegment bedient wird, um beispielsweise einen Zugang zu einem für das Unternehmen neuen Markt zu erlangen. Ziel dieser Maßnahme ist eine marktgerechte Reduzierung der externen Vielfalt in dem Sinne: „Lohnt es sich, diese Variante anzubieten?“. Auf Marktstrategien wird an dieser Stelle nicht weiter eingegangen. Diese Thematik wird bspw. in [Kramer u. Kramer 1997] ausführlich behandelt. Die Durchführung der zweiten Maßnahme, die Entkopplung von externer und interner Vielfalt, ist bedeutend aufwändiger. Der Grundgedanke besteht darin, mit möglichst wenigen produzierten Komponenten (interne Vielfalt) möglichst viele unterschiedliche Produkte (externe Vielfalt) zu erzeugen. Bei diesem Ansatz geht es also um das Produkt und seine Gestaltung. Es existiert eine ganze Reihe von Produktarten, die die hier betrachtete Forderung erfüllen wie Baureihen (Variation der Größe), Baukästen (Variation der Gesamtfunktion) oder Plattformen (Variation des Designs). Auf diese Produktarten wird in Kap. 3 näher eingegangen. Auch wenn die beiden Maßnahmen umgesetzt werden, verbleibt i. A. eine große Anzahl von herzustellenden Produktkomponenten. Deshalb muss als dritte Maßnahme die interne Vielfalt bewältigt und beherrscht werden. Zwischen der internen Vielfalt und der Komplexität des Lebenszyklus besteht ein direkter Zusammenhang. Die interne Vielfalt ist ein wesentlicher Komplexitätstreiber, da mit der Vielfalt der Daten aus dem Lebenszyklus eines Produktes ohne weitere Maßnahmen auch die Zahl der Beziehungen und Abhängigkeiten wächst. Dies wiederum hat komplexere Prozesse zur Folge und erfordert mehr Ressourcen [Feldhusen 2007]. In der Konsequenz wird die Komplexität zwar reduziert, ihre Beherrschung stellt dennoch eine große Herausforderung für das Unternehmen dar. Es werden entsprechende Strategien, Methoden und Hilfsmittel benötigt. Jede der drei Maßnahmen ist Bestandteil der PLM-Strategie eines Unternehmens. Damit bewirkt eine PLM-Umsetzung tiefgreifende Auswirkungen auf die Produkte, Prozesse und die Organisation. Aufgrund der heutigen immensen Datenmengen in diesen Bereichen kann eine effiziente Daten- und Informationssteuerung als ein wesentlicher PLM-Aspekt nur

28

2 Die Situation heutiger Unternehmen

rechnerunterstützt erfolgen [Gebhardt 2007]. Aus diesem Grund kommt dem PDM-System eine zentrale Bedeutung im Umgang mit Komplexität zu. Um die bestehende Unternehmenskomplexität zu beherrschen, ist im Rahmen der PLM-Umsetzung ein Reengineering sämtlicher Bestandteile innerhalb der Produktentstehung erforderlich. Ein ganzheitlicher Reengineering-Ansatz verfolgt allgemein das Ziel, den Produktentstehungsprozess hinsichtlich der Dimensionen Zeit, Kosten und Qualität zu optimieren, siehe Abb. 2-8. Als Stellschrauben stehen hierbei die Hauptkomponenten der Produktentstehung zur Verfügung: x das Produkt selbst, x die Prozesse der Produktentstehung und x die eingesetzten Hilfsmittel (Tools). Die Ressourcen steuern zwar auch einen Teil zur Komplexität bei, hängen jedoch von den Prozessen ab und sind daher indirekt berücksichtigt. Art und Umfang der durchgeführten Reengineering-Maßnahmen orientieren sich an den Unternehmenszielen, die im Rahmen einer Unternehmensstrategie zu Beginn definiert sein müssen. Zusätzlich ist eine ControllingInstanz erforderlich, um die Erreichung der Ziele zu überprüfen.

Abb. 2-8 Ganzheitlicher Reengineering-Prozess mit den Hauptkomponenten Produkt, Prozess und eingesetzte Tools

2.5

Zusammenfassung Kapitel 2

29

Die Inhalte der einzelnen Maßnahmen, die zur Beherrschung der Unternehmenskomplexität beitragen, bilden den Schwerpunkt des nächsten Kapitels. Hierbei werden besonders diejenigen Anforderungen diskutiert, die eine PLM-Umsetzung an die drei Hauptkomponenten Produkt, Prozess und Organisation stellt.

2.5 Zusammenfassung Kapitel 2 Im diesem Kapitel sind die Ursachen für Komplexität im Unternehmen erläutert. Einerseits liegen sie außerhalb des Unternehmens und beinhalten Faktoren wie Marktbedingungen, Kundenbedürfnisse oder die Verflechtung mit externen Partnern (externe Vielfalt). Andererseits beeinflussen auch interne Faktoren wie die Aufbau- und Ablauforganisation die Unternehmenskomplexität (interne Vielfalt). Sie äußert sich in einem hohen Anteil sowohl an Produkt- als auch Prozessvarianten, deren Beherrschung vielen mittelständischen Unternehmen zunehmend schwerer fällt. Ein möglicher Lösungsansatz zur Beherrschung der Unternehmenskomplexität ist das Product Lifecycle Management (PLM). Dabei handelt es sich um einen strategischen Ansatz, der die bestehenden Daten- und Informationsflüsse im Unternehmen effizient steuert sowie die Ausprägungen der Produkte definiert. Um PLM effektiv im Unternehmen mit dem Ziel der Komplexitätsbeherrschung umsetzen zu können, müssen drei Maßnahmen durchgeführt werden: x die nutzen-/marktgerechte Optimierung der externen Vielfalt; x die Entkopplung der externen und internen Vielfalt und x die Bewältigung der Komplexität aufgrund der internen Vielfalt. Aus der Durchführung dieser Maßnahmen resultieren notwendige Anforderungen an die Produkte, die Aufbau- und die Ablauforganisation. Diese Anforderungen werden durch einen ganzheitlichen Reengineering-Ansatz im Bereich der gesamten Produktentwicklung erreicht. Literatur Braun J (2003) Grundlagen der Organisationsgestaltung. In: Neue Organisationsformen im Unternehmen, 2. neu bearbeitete und erweiterte Auflage. Springer, Berlin-Heidelberg-New York DIN 199, Teil 1 (2002) Begriffe – Technische Produktdokumentation: CADModelle, Zeichnungen und Stücklisten. Beuth, Berlin-Wien-Zürich

30

2 Die Situation heutiger Unternehmen

Feldhusen J (2007) Komplexität als Erfolgsfaktor. In: Digital-EngineeringMagazin 10/2007. WIN, Vaterstetten Feldhusen J, Gebhardt B, Macke N, Nurcahya E, Bungert F (2006) Development of A Set of Methods To Support The Implementation of A PDMS for SME’s with A High Product Variance. In: Innovation in Life Cycle Engineering And Sustainable Development. Springer, Dordrecht Franke HJ (1998) Produkt-Variantenvielfalt - Ursachen und Methoden zu ihrer Bewältigung, effektive Entwicklung und Auftragsabwicklung variantenreicher Produkte. VDI-Berichte 1434, Düsseldorf Franke HJ, Hesselbach J, Huch B (2002) Variantenmanagement in der Einzel- und Kleinserienfertigung. Hanser, München-Wien Gebhardt B (2007) Abschätzung der Produktdatenmanagement-Systemfähigkeit produzierender Unternehmen. Shaker, Dissertation RWTH Aachen Hichert R (1986) Probleme der Vielfalt - Teil 3: Was bestimmt die optimale Erzeugnisvielfalt? In Werkstatttechnik 76 Nr.: 11. Springer-VDI, Düsseldorf Hofbauer G, Schweidler A (2006) Professionelles Produktmanagement – der prozessorientierte Ansatz, Rahmenbedingungen und Strategien. Publicis Corporate Publishing, Erlangen Jeschke A (1997) Beitrag zur wirtschaftlichen Bewertung von Standardisierungsmaßnahmen in der Einzel- und Kleinserienfertigung durch Konstruktion. Dissertation, TU Braunschweig Kramer F, Kramer M (1997) Bausteine der Unternehmensführung, 2. Auflage. Springer, Berlin-Heidelberg-New York Lindemann U, Baumberger GC (2006) Individualisierte Produkte. In: Individualisierte Produkte – Komplexität beherrschen in Entwicklung und Produktion. Springer, Berlin-Heidelberg-New York Luczak H (1998) Arbeitswissenschaft. 2., vollständig neubearbeitete Auflage. Springer, Berlin-Heidelberg-New York Pahl G, Beitz W, Feldhusen J, Grote KH (2007) Konstruktionslehre - Grundlagen erfolgreicher Produktentwicklung, 7. Auflage. Springer, Berlin-HeidelbergNew York Schuh G (2004) Komplexitätsmanagement - Studie 2004. WZL der RWTH Aachen, Aachen Schuh G (2005) Produktkomplexität managen, 2. überarbeitete Auflage. Hanser, München-Wien

3 PLM-Voraussetzungen im Unternehmen

Eine unternehmensindividuelle PLM-Strategie beeinflusst das gesamte Unternehmen. Dies betrifft im Besonderen die Hauptunternehmenselemente Produkt, Prozess und Organisation, die im Mittelpunkt von PLM stehen. Ihre Voraussetzungen als Grundlage einer erfolgreichen PLM-Umsetzung bilden den Inhalt dieses Kapitels. Zunächst werden allgemeine Anforderungen an eine PLM-Strategie beschrieben. Zusätzlich gibt es eine Reihe spezifischer Anforderungen in Bezug auf die drei Hauptunternehmenselemente, die bei einer Umsetzung berücksichtigt werden müssen. Anschließend werden die für eine Umsetzung geeigneten und erforderlichen Produktarten vorgestellt. Deren Modularität ist hierbei von größter Bedeutung. Dies gilt auch für die Unternehmensprozesse, deren erforderliche Flexibilität innerhalb der PLM-Strategie wesentlich durch modulare Teilprozesse unterstützt wird. Aufgrund dieser notwendigen Flexibilität schließt das Kapitel mit der Betrachtung geeigneter Organisationsformen ab, welche die behandelten Anforderungen für die Hauptunternehmenselemente Produkt und Prozess in einer geeigneten Weise unterstützen.

3.1 Anforderungen an eine erfolgreiche PLM-Strategie In Kap. 2 wurde dargelegt, dass die PLM-Strategie ein Teil der übergeordneten Unternehmensstrategie sein muss. Sie bezieht sich im Wesentlichen auf die produktbezogenen Datenflüsse im Unternehmen und auf die Gestaltung für das Unternehmen nachhaltiger Produkte. Als erfolgreich kann dementsprechend eine PLM-Strategie dann bezeichnet werden, wenn durch ihre Umsetzung die Datenflüsse im Unternehmen während des Produktentstehungsprozesses (PEP) verbessert und die Entstehung langfristig tragfähiger Produkte (Multi-Life-Produkte) gefördert werden. Ein weiterer grundsätzlicher Anspruch ist die Förderung der Unternehmensziele sowie typischerweise die Reduktion der Kosten sowie die Senkung der PEPDurchlaufzeit. Als Folge werden i. Allg. auch die Produktkosten selber reduziert. Die PLM-Strategie bezieht sich zwar im Kern auf die Produkte,

32

3 PLM-Voraussetzungen im Unternehmen

beeinflusst aber letztlich das gesamte Unternehmen. Damit sind konkret neben dem Produkt auch seine zugehörigen Entwicklungs- sowie Produktionsprozesse zu dessen Entstehung und die dazu erforderliche, unterstützende Organisation gemeint. Die Produkte, die Prozesse und die Organisation bilden somit die Hauptunternehmenselemente. Neben allgemeinen Anforderungen sind also insbesondere jene zu beachten, die sich auf eine Verbesserung der Hauptunternehmenselemente beziehen und konsequenterweise die finanzielle Situation des Unternehmens verbessern. In Abb. 3-1 ist dieser Zusammenhang dargestellt.

Abb. 3-1 Zusammenhang zwischen den Anforderungen an eine PLM-Strategie

In den folgenden Abschnitten werden die einzelnen Anforderungscluster verdeutlicht, auf deren Basis ein Unternehmen eine erfolgreiche PLMStrategie definieren kann. Aufgrund seiner Bedeutung bezüglich der Unternehmenskomplexität werden die Daten- und Informationsflüsse (D&I-Flüsse) zwischen den Hauptunternehmenselementen ausführlich in Kap. 4 behandelt. 3.1.1 Allgemeine Anforderungen an PLM Jede Strategie zielt auf den effizienten und effektiven Einsatz von Mitteln zur Erreichung eines definierten Ziels ab [Kroehl 2000; Herbst 2003]. Alle Entscheidungen eines Unternehmens müssen sich konsequenterweise auf die Umsetzung der Strategie beziehen und so der Erreichung von definierten Zielen dienen. Wesentliches Kennzeichen einer Strategie ist ihre Langfristigkeit und planmäßige Umsetzbarkeit. Dies bedeutet neben einer strategischen auch eine einhergehende operative Umsetzungsplanung aller

3.1

Anforderungen an eine erfolgreiche PLM-Strategie

33

Ziele (Operationalisierbarkeit). In der Abb. 3-2 sind die einzelnen Stufen zur Operationalisierung einer Strategie, ausgehend von der Unternehmensvision, wiedergegeben. Daraus können die allgemeinen Anforderungen abgeleitet werden.

Abb. 3-2 Vorgehensschritte zur Operationalisierung einer Unternehmensstrategie

Die beiden Keile in Abb. 3-2 repräsentieren die Unternehmenshistorie und seine zukünftige Entwicklung. In ihrer Breite spiegelt sich die direkte Einflusshöhe auf oder durch den jeweiligen Schritt wieder. Bezüglich der Unternehmenshistorie stellt die Breite die Einflusshöhe der Unternehmenshistorie auf die Inhalte und Ausprägung der einzelnen Schritte dar. Die Breite des die Zukunft darstellenden Keils soll verdeutlichen, wie stark diese durch einen Arbeitsschritt direkt beeinflusst werden kann. Bei der Aufstellung einer Vision, die ja zukunftsorientiert ist, darf die Unternehmenshistorie nicht vernachlässigt werden. Die Grafik verdeutlicht jedoch auch, dass umgekehrt der Einfluss einer Vision auf die Gestaltung der Zukunft nicht überschätzt werden sollte. Die zukünftige Entwicklung eines Unternehmens erfolgt insbesondere durch die festgelegten und umgesetzten Maßnahmen zur Realisierung einer Vision. Auf dem Weg von

34

3 PLM-Voraussetzungen im Unternehmen

der Vision bis zur Umsetzung einer Strategie vergeht erfahrungsgemäß ein großer Zeitraum. Gesellschaftliche Ereignisse oder Gesetzesänderungen können nennenswerte Abweichungen vom ursprünglichen Plan erfordern. Aus diesem Zusammenhängen können eine Reihe von allgemeinen Anforderungen abgeleitet werden, die an eine PLM-Strategie gestellt werden müssen. Die wesentlichen allgemeinen Anforderungen sind nachfolgend aufgelistet (vgl. auch Abb. 3-1). Dabei gibt die Reihenfolge nicht unbedingt ihre Bedeutung innerhalb einer erfolgreichen PLM-Strategie wieder. x Die PLM-Strategie muss langfristig tragfähig sein. Typischerweise sollte sie eine Gültigkeit für mindestens drei bis fünf Jahre haben. Modifikationen als Reaktion auf sich verändernde Rahmenbedingungen sind hierbei unberücksichtigt. x Die PLM-Strategie unterstützt in direkter Form die Unternehmensziele. x Die Integration der drei Hauptunternehmenselemente Produkt, Prozess, Organisation muss gewährleistet sein. x Die Wirkung einzelner Strategieelemente auf die Hauptunternehmenselemente ist eindeutig beschreibbar. x Die PLM-Strategie hat einen angemessenen Konkretisierungsgrad. So sind notwendige Aktivitäten und deren Verknüpfung zu einem Umsetzungsplan ableitbar. x Die PLM-Strategie ist auf neue Ziele adaptierbar. Dies geschieht durch einen modularen Aufbau. Die einzelnen Module beziehen sich auf die Produkte, die Prozesse und die Organisation und können unabhängig von einander ausgetauscht werden. x Die PLM-Strategie wird so formuliert, dass neue Randbedingungen aus dem Unternehmen oder dessen Umfeld berücksichtigt werden und problemlos in der PLM-Strategie berücksichtigt werden können. Die Abhängigkeiten einzelner Strategieelemente von ihren jeweiligen Rahmenbedingungen werden in der Strategie beschrieben bzw. die Voraussetzungen zu ihrer Umsetzung dargelegt. x Die erwarteten Ergebnisse sind eindeutig quantifizierbar. Die erfolgreiche Umsetzung der gesamten Strategie bzw. einzelner Teilen kann einfach und nachvollziehbar gemessen werden. Neben diesen allgemeinen Anforderungen gibt es aber noch solche, die sich speziell auf die drei Hauptunternehmenselemente Produkte, Prozesse und Organisation beziehen. Erst wenn diese drei ebenfalls bestimmte Anforderungen erfüllen, kann eine PLM-Strategie erfolgreich umgesetzt werden. Diese Anforderungen sind der Grund, warum die Umsetzung einer PLM-Strategie häufig umfangreiche Vorarbeiten erfordert.

3.1

Anforderungen an eine erfolgreiche PLM-Strategie

35

Die Ursache hierfür liegt in der Unternehmenshistorie und damit in der Historie der drei Hauptunternehmenselemente. Die Produkte beispielsweise entwickeln sich in einem Unternehmen meistens evolutionär; sehr selten sind völlige Neukonstruktionen erforderlich. Ihr Kern, also die Produktarchitektur und die wesentlichen Funktionsträger (Baugruppen und Bauteile) sind möglicherweise unter ganz anderen Voraussetzungen und mit ganz anderen Zielen entstanden, als es zum Zeitpunkt der Umsetzung einer PLM-Strategie erforderlich wäre. Solche Produkte lassen sich, wenn überhaupt, nur mit größerem Aufwand in eine PLM-Strategie integrieren. Ohne eine Überprüfung, ob und wie weit die Anforderungen erfüllt sind, ist die Umsetzung einer PLM-Strategie zum Scheitern verurteilt. Die Fragestellung, ob ein Produkt „PLM-geeignet“ ist, bildet den Gegenstand der nachfolgenden Buchkapitel. 3.1.2 Anforderungen an die Hauptunternehmenselemente Die beiden wesentlichen Schwerpunkte von PLM bilden das Managen der Daten- und Informationsflüsse über den gesamten Produktlebenszyklus sowie die aus Modulen konfigurierbaren Produkte (Multi-Life-Produkte). Da die während des Produktentstehungsprozesses (PEP) zu verwaltenden Daten und Informationen hauptsächlich durch die Festlegung von Produktausprägungen wie Funktionen, Geometrien, Werkstoffen oder Fertigungsverfahren entstehen, besitzen sämtliche Dateninhalte zwangsläufig eine produktspezifische Abhängigkeit. Anders ausgedrückt kann man sagen, dass sämtliche Daten und Informationen entlang des PEP durch den Entstehungsfortschritt des Produkts entstehen. Es besteht eine direkte Kopplung zwischen den Daten und Informationen des PEP und dem Produkt. Bezogen auf das Produkt bedeutet PLM, solche Produkte zu entwickeln, die durch Anpassung an neue Marktbedürfnisse ohne Veränderung des Grundansatzes des Produkts eine lange und erfolgreiche Marktpräsenz in unterschiedlichen Ausprägungen aufweisen. Hierfür sind konfigurierbare, aus Modulen aufgebaute Produkte besonders geeignet. Damit können einzelne Module ohne Veränderung ihrer Schnittstellen ausgetauscht werden, um so neue Marktanforderungen zu realisieren. Wie bereits erwähnt, entsteht das Produkt im Rahmen des PEP. Er wiederum ist ein Bestandteil des übergeordneten Geschäftsprozesses eines Unternehmens [Schmelzer u. Sesselmann 2004]. Der PEP kann in Teilprozesse aufgeteilt werden, wie es die [VDI2221] für den Entwicklungs- und Konstruktionsprozess vorschlägt. Jeder dieser Teilprozesse dient dazu, be-

36

3 PLM-Voraussetzungen im Unternehmen

stimmte Daten und Informationen in einzelnen Phasen der Produktentwicklung zu verarbeiten bzw. zu erzeugen. Verändert sich das Produkt an einer Stelle, bspw. durch Austausch eines Moduls, muss sich konsequenterweise auch der PEP durch Austausch des betreffenden Teilprozesses verändern. Wird z. B. die Konstruktion eines Getriebegehäuses aufgrund erhöhter Stückzahlen von einer Schweißkonstruktion in eine Gusskonstruktion umgewandelt, so verändern sich auch die Beschaffungs- und Fertigungsprozesse ganz massiv. Für die Entwicklungsplanung sind andere Daten erforderlich wie die Beschaffungszeit für ein Gussbauteil oder die Festigkeitswerte des Gusswerkstoffs. Der zugehörige D&I-Fluss ändert sich also, wenn aus einem selbst gefertigten Bauteil ein zu beschaffendes Bauteil wird. Dabei bleibt in diesem Beispiel Auswirkungen auf die Funktion und Konstruktion des gesamten Produkts noch unberücksichtigt. Deshalb sind im Sinne des PLM-Gedankens nicht nur modulare und konfigurierbare Produkte, sondern auch ein aus Teilprozessmodulen bestehender und konfigurierbarer PEP erforderlich. Dieser Aspekt wird in Abschn. 3.3 vertieft behandelt. Die Ausführung des PEP und seiner Teilprozesse findet innerhalb der Unternehmensorganisation statt. Durch sie werden die zugehörigen Abläufe strukturiert und die Reihenfolge von Teilprozessen sowie ihre Verantwortlichkeiten festgelegt. Da der PEP, seine Teilprozesse und deren Reihenfolge von der Ausprägung des zu erstellenden Produkts abhängen, muss sich auch die Unternehmensorganisation den Prozesserfordernissen anpassen. Dies bedeutet, dass die Organisation eines Unternehmens ebenfalls modular strukturiert sein muss, wenn PLM erfolgreich umgesetzt werden soll. Zusammenfassend kann festgehalten werden, dass die wesentliche Voraussetzung zur Umsetzung einer PLM-Strategie modulare Produkte (MultiLife-Produkte), modulare Prozesse und eine modulare Organisation sind. Mögliche Ansätze für eine entsprechende Umsetzung innerhalb der drei Hauptunternehmenselemente werden in den nachfolgenden Abschnitten vorgestellt.

3.2 Mögliche Produktarten für PLM In den vorangegangenen Abschnitten wurde die Modularisierung der Produkte als eine wesentliche Voraussetzung für eine erfolgreiche Umsetzung einer PLM-Strategie erläutert. In diesem Abschnitt werden mögliche Pro-

3.2

Mögliche Produktarten für PLM

37

duktarten dargestellt, die unterschiedliche Modularisierungsgrade aufweisen. Da jedoch hinsichtlich der Thematik „Modularisierung“ ein teilweise erheblich unterschiedliches Verständnis in der industriellen Praxis besteht, werden zunächst die relevanten Begriffe definiert. Danach erfolgt die Vorstellung der entsprechenden Produktarten, die zur Unterstützung einer PLM-Umsetzung besonders geeignet sind. 3.2.1 Grundlegende Begriffe im Bereich der Modularisierung Wichtige Ansätze zur Definition der Modularität und von Modulen finden sich bei [Koller 1998] und [Göpfert 1998]. Darauf aufbauend, wird der Begriff der Modularität wie folgt definiert [Canales Salacerry 2006]: Modularisierung ist eine Strukturierungsmethode von Produkten unter definierten Gesichtspunkten. Modularisierung schafft einerseits Unabhängigkeit zwischen den Elementen durch weniger stark definierte Beziehungen untereinander und andererseits durch wenige, standardisierte Schnittstellen. Die Definition eines Moduls erfolgt in der Literatur sehr unterschiedlich. Sehr streng ist sie bei [Koller 1998]. Hier wird unter einem Modul ein Baustein eines Baukastens verstanden, der nicht strukturgebunden ist, also an beliebiger Stelle in die Struktur eines Produkts eingebunden werden kann. Damit kann jedes Modul eines Produkts gegen ein anders ausgetauscht werden, sofern dieses zum gesamten Produktspektrum gehört. Die Umsetzung dieser Definition ist in der Praxis bisher nur bei sehr wenigen und einfachen Produkten gelungen. Aus diesem Grund erscheint es sinnvoll, bei einer pragmatischen Definition des Modulbegriffs vom Begriff des Baukastens auszugehen und dieser hinsichtlich der Ziele von PLM zu erweitern. Nach [Pahl et al. 2007] ist ein Baukasten folgendermaßen definiert: Unter einem Baukasten werden Maschinen, Baugruppen und Einzelteile verstanden, die als Bausteine mit oft unterschiedlichen Lösungen durch Kombination verschiedene Gesamtfunktionen erfüllen. Beim Baukasten werden demnach die Kunden- und Herstellerbedürfnisse annähernd gleichwertig berücksichtigt. Der Kunde hat je nach Baukastentyp die Möglichkeit, Funktionen auch zu einem späteren Zeitpunkt zu ändern. Deshalb werden in der Praxis meistens komplette Teilfunktionen durch einen Baustein des Baukastens erfüllt. Ein typischer Vertreter für

38

3 PLM-Voraussetzungen im Unternehmen

den Grundgedanken eines Baukastens sind Getriebemotoren. Der Hersteller kann kostengünstig in abgesicherter Qualität produzieren und dabei unterschiedliche Kundenwünsche nach Motorleistung, Baugröße etc. berücksichtigen. Neben den bei den Baukästen genannten Gesichtspunkten kommt bei Modulen noch ein weiterer, entscheidender hinzu, wie die folgende Definition für den Begriff Modul zeigt: Ein Modul ist ein Subsystem, dessen Grenzen nach fertigungstechnischen und funktionalen Gesichtspunkten festgelegt sind, mit dem Ziel, es unabhängig vom Gesamtsystem entwickeln, konstruieren, fertigen und prüfen zu können. Diese relative Unabhängigkeit eines Moduls vom restlichen System ist die Grundlage für seine Wiederverwendbarkeit, Austauschbarkeit und Standardisierung [Göpfert 1998] sowie Konfigurierbarkeit [Schuh 1988; Meier 2007]. Bei einem modularen Produkt kann es sich demnach auch um einen Baukasten handeln. Die Zielrichtung modularer Produkte ist aber eine andere, nämlich die konsequente Unabhängigkeit der Module untereinander, wie dies in der Definition gefordert und in Abb. 3.3 verdeutlicht wird. Deshalb ist die Möglichkeit, Module unabhängig voneinander prüfen zu können, eine ganz entscheidenden Voraussetzung zur Rationalisierung innerhalb der einzelnen Hauptunternehmenselemente.

Abb. 3-3 Grundgedanke von Modulen

Im Gegensatz zu den einzelnen Bausteinen eines Baukastens bilden Module in der Praxis meist keine geschlossene Funktion ab. Sie sind aus diesem Grund auch nicht unbedingt als einzelnes Produkt marktfähig, wobei auch hier wieder Ausnahmen möglich sind. Bei einem Getriebemotorenbaukas-

3.2

Mögliche Produktarten für PLM

39

ten stellen sowohl der Elektromotor, das Getriebe und eine evtl. Kupplung zwischen den beiden jeweils für sich genommen marktfähige Produkte dar. Alle drei Bausteine bilden jeweils eine geschlossene Funktion ab. Die Funktion des Elektromotors ist das Wandeln von elektrischer in mechanische Energie, die des Getriebes das Ändern der Drehzahl, die der nicht schaltbaren Kupplung das Leiten des Drehmoments. Im Sinne des PLM müssen die Module, aus denen sich das Produkt zusammensetzt, so geschnitten werden, dass sie jeweils ohne Einfluss auf den Rest des Produkts bzw. seine Gesamtfunktion gegen ein anderes Modul ausgetauscht werden können. Der Produktstrukturierung kommt deshalb insbesondere im Fall eines modularen Produkts eine ganz besondere Bedeutung zu [Franke et al. 1993]. Den Ausgangspunkt für sämtliche Überlegungen zur Modularisierung eines Produkts bildet die Produktarchitektur, die schematisch in Abb. 3-4 gezeigt ist. Nach [Ulrich 1995] wird unter der Produktarchitektur das Schema der Beziehungen zwischen der Funktionsstruktur eines Produkts und seiner physischen Baustruktur verstanden. Den einzelnen Teilfunktionen (in Abb. 3-4 in der oberen Ebene dargestellt) werden zu ihrer Erfüllung Funktionsträger, also Baugruppen oder Bauteile eines Produkts, zugeordnet. Diese Zuordnung, welche die angesprochenen Beziehungen repräsentiert, ist in der Grafik als Pfeile dargestellt. Es wird deutlich, dass zur Erfüllung einer Funktion mehrere Funktionsträger erforderlich sein können. Umgekehrt kann auch ein Funktionsträger mehrere Funktionen erfüllen.

Abb. 3-4 Schematische Darstellung der Produktarchitektur und der Beziehung zwischen der Funktions- und Produktstruktur nach [Göpfert 1998]

40

3 PLM-Voraussetzungen im Unternehmen

Ausführliche Betrachtungen zur Modularisierung von Produkten finden sich bspw. in [Göpfert 1998; Lang 2000]. Mit der besonderen Situation einer nachträglichen Modularisierung bereits vorhandener Produkte beschäftigt sich [Baumgart 2005]. 3.2.2 Multi-Life-Produkte Die in Kap. 2 beschriebenen Vorteile der PLM-Strategie in Bezug auf die externe und interne Vielfalt werden durch die Multi-Life-Produkte am nachhaltigsten unterstützt. Diese Produktart besitzt für Unternehmen die effizientesten Auswirkungen innerhalb der PLM-Strategie und ist folgendermaßen definiert [Pahl et al. 2007]: Multi-Life-Produkte sind modulare Produkte, bei denen die Module und/oder deren Schnittstellen so geplant sind, dass zukünftige Marktbedürfnisse durch eine Veränderung, einen Austausch oder ein Hinzufügen von Modulen ohne eine Neukonstruktion des Produkts erfüllt werden können. Multi-Life-Produkte können als Sonderfall eines Baukastens betrachtet werden. Im Fall der Multi-Life-Produkte sind die Bausteine aber als Module ausgeführt und gehorchen der oben aufgeführten Definition. Im Gegensatz zu Baukastenprodukten bedeutet dies, dass bei dieser Produktart nicht nur die unterschiedliche Gesamtfunktion des Produkts variiert. Vielmehr betrifft die Variation bei Multi-Life-Produkte Eigenschaften des Produkts im Allgemeinen. Diese Eigenschaftsvariationen können die Gesamtfunktion einschließen, aber auch einzelne Aspekte wie das Design bei gleicher Gesamtfunktion betreffen. Beispiele für solche Produkte sind augenblicklich noch selten. Allerdings sind insbesondere bei „Weißer Ware“ wie Kühlschränken oder Waschmaschinen sowie im Automobilsektor erste Ansätze für eine Umsetzung zu erkennen. So sind bei Waschmaschinen schon länger die Waschprogramme softwaretechnisch gespeichert. Neue Erkenntnisse zum Waschvorgang können für neue Produkte ohne zusätzliche Eingriffe in die Konstruktion eingebracht werden. Ebenso kann auf diese Weise einfach auf die Waschbedürfnisse neuer Textilarten reagiert werden. Im Automobilbereich werden bei einer Neuentwicklung bereits mögliche Folgemodelle der nächsten Generation berücksichtigt. Ein Teil aller Eigenschaften eines Multi-Life-Produkts ist folglich bei dessen Markteintritt zur Abdeckung der aktuellen Kunden- und Marktbedürfnisse direkt verfügbar.

3.2

Mögliche Produktarten für PLM

41

Abb. 3-5 Daten- und Informationsflüsse eines Multi-Life-Produkts im Zusammenhang mit seinen Lebenszyklusphasen [Pahl et al. 2007]

Um die zukünftigen Marktbedürfnisse durch entsprechende Produkteigenschaften berücksichtigen und abdecken zu können, sind mehrere Ansätze möglich: x Bereits bei der ersten Lancierung besitzt das Produkt Eigenschaften, die erst bei Bedarf und/oder in der nächsten Produktentwicklungsstufe aktiviert werden. In die Kabelbäume von Automobilen beispielsweise wurden bisher Leitungen für elektrische Zusatzfunktionen integriert, die nur bei bestimmten Varianten eines Typs benötigt wurden. Mittels Software können bestimmte Funktionalitäten ergänzt oder verändert werden, wie dies bspw. bei den Waschmaschinen gezeigt wurde. Dies kann auch über Hardwarekomponenten eines Produkts geschehen: So ist die Ergänzung oder Veränderung von Funktionen über Bussysteme mit entsprechenden Endgeräten möglich, ohne dass ein Eingriff in die physikalische Ausprägung des Produkts vorgenommen werden muss. Die Produktmodule sind bereits im Vorfeld derartig gestaltet, dass ihre Eigenschaften bei Bedarf ohne Beeinflussung des restlichen Produkts und ohne Neukonstruktion des betreffenden Moduls angepasst werden können. Insbesondere bei Getriebebaukästen als Sonderfall von Multi-LifeProdukten sind solche Anwendungen bekannt [Ehrlenspiel et al. 2005]. x Module können innerhalb des Produkts gegen andere ausgetauscht werden, ohne das übrige Produkt verändern zu müssen (Getriebemotoren als Sonderfall modularer Produkte).

42

3 PLM-Voraussetzungen im Unternehmen

x Externe Module können hinzugefügt oder entfernt werden, ohne das übrige Produkt verändern zu müssen. Die Plattformen im Automobilbau stellen eine Sonderform von Multi-Life-Produkten dar. Sie gestatten es, insbesondere neue Designanforderungen, ohne Änderung des Konzepts und der Struktur des Produkts einzubringen. Lediglich die direkten Schnittstellen müssen angepasst werden. Diese Ansätze müssen auch auf der Ebene der zugehörigen D&I-Flüsse berücksichtigt werden, um einer PLM-Strategie zu genügen. In Abb. 3-5 ist der D&I-Fluss im Zusammenhang mit der Veränderung von Produkteigenschaften über den Lebenszyklus eines Multi-Life-Produkts dargestellt. 3.2.3 Plattformprodukte Ein Plattformprodukt besteht aus einer ausführungsneutralen Produktplattform und aus produktspezifischen Anbauten. Die Produktplattform wird auch als Schnittstellenträger, die produktspezifischen Anbauten als Hutmodule bezeichnet [Ley u. Hofer 1999; Haf 2001; Metzger et al. 2002; Stang et al. 2002]. Da die produktspezifischen Anbauten untereinander nicht kombinierbar oder gegenseitig tauschbar sein müssen, stellt ein Plattformprodukt keinen Baukasten dar [Baumgart 2005]. Der grundlegende Aufbau eines Plattformprodukts ist in Abb. 3-6 dargestellt.

Abb. 3-6 Komponenten eines Plattformprodukts nach [Cornet 2002]

3.2

Mögliche Produktarten für PLM

43

Die erste konsequente und flächendeckende Umsetzung von Plattformprodukten geschah in der Automobilindustrie; einige Beispiele, die alle auf einer Plattform basieren, sind in Abb. 3-7 gezeigt.

Abb. 3-7 Beispiel für eine Plattform aus dem Automobilbereich nach [Volkswagen AG]

Trotz der konzeptionellen Nachteile aufgrund der starren Plattform ist ein Plattformprodukt auch eine Untermenge der Multi-Life-Produkte, da alle zukünftigen Hutmodule bereits bei der Plattformentwicklung vorab geplant werden müssen [Cornet 2002]. Im Automobilbau wird als Hutmodul die Karosserie des Fahrzeugs bezeichnet. Allgemein handelt es sich also dabei um die äußere Form bestimmende Produktelemente, welche vom Kunden phänomenologisch wahrgenommen werden. Entsprechend der Abb. 3-5 erfährt die Plattform mehrere Lebenszyklen bei wechselnden Hutmodulen. 3.2.4 Mechatronische Produkte Eine hohe Anzahl von Produkten besteht heute aus mechanischen, elektrisch/elektronischen und softwaretechnischen Komponenten. Solche Produkte werden als mechatronische Produkte bezeichnet [VDI2206]. In der Abb. 3-8 sind diese drei Bestandteile eines mechatronischen Produkts dargestellt.

44

3 PLM-Voraussetzungen im Unternehmen

Abb. 3-8 Die drei Hauptbestandteile mechatronischer Produkte

Wenn auf solche Produkte PLM im Sinne von Multi-Life-Produkten angewendet werden soll, so ergeben sich besondere Schwierigkeiten. Die Module des Produkts haben nicht nur eine, sondern drei Komponentenarten in sich vereint, wie sie die Ebenen in der Abb. 3-8 symbolisieren. Jede dieser Ebenen muss eine eindeutige Schnittstelle i. S. der Modul-Definition zu seinen Nachbarn aufweisen. Konsequenterweise ist damit die in Abb. 39 dargestellt Struktur eines mechatronischen Produkts am besten geeignet, um ein Multi-Life-Produkt zu erstellen. In der Grafik ist ersichtlich, dass die drei Ebenen eines jeden Moduls genau auf dieses Modul begrenzt sind. Sie integrieren kein weiteres Modul durch die Überdeckung der betrachteten Ebene (Mechanik, Elektrik/Elektronik, Software) über mehrere Module.

Abb. 3-9 Struktur eines mechatronischen Multi-Life-Produkts

3.2

Mögliche Produktarten für PLM

45

In der Praxis ist ein mechatronisches Modul in dieser Form nur selten realisierbar. Beispielsweise sind Regelung oder Steuerung solcher Produkte normalerweise nicht nur für ein Modul zuständig, sondern übergreifend für das gesamte Produkt. Bei heutigen mechatronischen Produkten kann also ohne besondere Maßnahmen kein Modul im Sinne eines Multi-LifeProdukts nach der aufgeführten Definition behandelt werden. Neben dem grundsätzlichen Lösungsansatz, also die strikte Aufteilung jeder Ebene (Mechanik, Elektrik/Elektronik, Software) mit entsprechenden Schnittstellen auf die Module des Produkts, ist noch ein weiterer Ansatz denkbar.

Abb. 3-10 Struktur eines mechatronischen Multi-Life-Produkts mit einer modularen integrierten Softwareebene

Seit längerem wird versucht, die Funktionalität von mechanischen Komponenten durch elektrische Komponenten oder durch Software zu ersetzen. Dieser Ersatz erfolgt nicht nur aus Kostengründen. Vielmehr bieten entsprechend aufgebaute Produkte eine sehr hohe Flexibilität, weil z.B. neue Funktionalitäten durch entsprechende Programmänderungen der Software realisiert werden können. Dies ist möglich, ohne das physikalische Bild des Produkts verändern zu müssen. So kann ein LCD-Pannel zur Anzeige von Messgrößen auch zur Wiedergabe beliebiger anderer optischer Signale genutzt werden. Dagegen ist eine mechanische Anzeige in ihrer Funktionalität auf den einmal festgelegten Umfang beschränkt. So ist es denkbar, ein Produkt in Weiterentwicklung des in Abb. 3-9 dargestellten Ansatzes aus einer integrierten, modularen Softwareebene, die sämtliche Module des Produkts integriert, und den einzelnen Produktmodulen mit der elektrischen/elektronischen sowie mechanischen Ebene aufzubauen. Dieser Ansatz ist in Abb. 3-10 dargestellt.

46

3 PLM-Voraussetzungen im Unternehmen

Die Software nach Abb. 3-10 integriert zwar durch ihre Funktionalität alle Module des mechatronischen Produkts, ist selbst aber modular aufgebaut. Dies wird in der Grafik durch die weißen Linien symbolisiert, welche die Softwaremodulgrenzen repräsentieren. Auf diese Weise ist es denkbar, Produkteigenschaften, welche durch Software realisiert werden, durch Veränderung, Austausch oder Hinzufügen eines Softwaremoduls neuen Anforderungen anzupassen. Ein immenser Vorteil dieses Ansatzes besteht darin, dass die Fertigungseinrichtungen für solche Produkte bei der beschriebenen Art der Veränderung von Produkteigenschaften unberührt bleiben. Hieraus entsteht ein enormes Potenzial an möglichen Kosteneinsparungen. Ähnlich kann mit der elektrisch/elektronischen Ebene des mechatronischen Produkts verfahren werden. Auch hier ist eine Integration insbesondere der Elektronik eines Produkts zu beobachten. Aufgrund der heutigen Fertigungsweise für elektronische Komponenten müssen die entsprechenden Fertigungseinrichtungen zwar neu programmiert und/oder neu eingerichtet werden. Typischerweise können aber auf einer Fertigungsstraße, insbesondere für elektronische Flachbaugruppen (Leiterplatten), sehr unterschiedliche Typen solcher Komponenten gefertigt werden. Es existieren Beispiele für diese zu elektrisch/elektronischen Baugruppen zusammengefassten Flachbaugruppen und elektrischen Bauteile. Sie sind modular in dem hier verwendeten Sinn gegliedert und genügen gleichzeitig den PLM-Ansprüchen. In Abb. 3-11 ist ein Beispiel einer solchen elektrischen/elektronisch Baugruppe wiedergegeben. Im gezeigten Beispiel sind die von der Elektrik/Elektronik zu erfüllenden Funktionen auf mehrere standardisierte Leiterplatten aufgeteilt, siehe Abb. 3-11 unteres Teilbild. Die durchgeführte Standardisierung bezieht sich nicht nur auf die Abmessungen der Leiterplatten und deren Gehäuse, also die Geometrie der Bauteile, vielmehr sind auch die elektrischen Schnittstellen zur nächsten Teilbaugruppe standardisiert. Die elektrische und datentechnische Verbindung dieser Teilbaugruppen erfolgt wiederum über ein standardisiertes Leitungs-/Schienensystem. So kann jede Teilbaugruppe an beliebiger Stelle der Gesamtbaugruppe eingefügt werden, siehe Abb. 3-11 oberes Teilbild.

3.2

Mögliche Produktarten für PLM

47

Abb. 3-11 Beispiel für eine modular aufgebaute Elektronikbaugruppe aus Einzelmodulen mit definierten Schnittstellen [© Phoenix Contact GmbH & Co. KG]

Solche elektronischen Baugruppen werden typischerweise zum Aufbau von Steuer- und Regelungseinheiten in maschinenbaulichen oder elektrotechnischen Produkten eingesetzt. In der Abb. 3-12 ist ein Hochleistungsstromrichter gezeigt, der bspw. in Walzwerken eingesetzt wird.

Abb. 3-12 Beispiel für eine modular aufgebauten Stromrichter, der als elektronische Baugruppe die in Abb. 3-11 gezeigten Module beinhaltet [© Phoenix Contact GmbH & Co. KG]

48

3 PLM-Voraussetzungen im Unternehmen

Die spezifischen Besonderheiten des Aufbaus mechatronischer Produkte müssen auch innerhalb der PLM-Strategie, insbesondere bei der Produktentwicklung, berücksichtigt werden. So sind die mechanischen Komponenten eines Produkts aufgrund der von ihnen jeweils zu erfüllenden Funktion in Verbindung mit dem für sie gewählten Werkstoff geometrisch determiniert. Dies gilt sowohl für ihren Bauraum und ihre einzelnen Abmessungen als auch für ihre Schnittstellen zu anderen Bauteilen. Deshalb sind sie i. S. eines modularen Produkts sehr unflexibel. Je nach ihrem Standardisierungsgrad können sie in ihrer Detailausprägung noch durch die Konstruktion variiert werden. In Abb. 3-13 ist dieser Zusammenhang dargestellt: Katalog- oder Normteile wie eine M6 x 35 DIN-ISO-Schraube sind vollkommen geometrisch bestimmt. Zeichnungs-/Konstruktionsteile können im Rahmen ihrer Aufgabe und des gewählten Werkstoffs noch in größerem Umfang gestaltet werden. Häufig sind aber auch hier strenge Vorgaben aufgrund der Schnittstellen zu anderen Bauteilen, des gewählten Werkstoffs oder des vorgegebenen Fertigungsverfahrens implizit vorhanden. Günstiger sind die Verhältnisse bei elektrischen und insbesondere bei elektronischen Bauteilen, siehe Abb. 3-13. Insbesondere bei kleinen Leistungen, wie sie zur Steuerung und Regelung verwendet werden, sind solche elektronischen Baugruppen fast räumlich unabhängig.

Abb. 3-13 Geometrischer Determinierungsgrad der Komponentenarten eines mechatronischen Produkts

3.3

Modulare Prozesse

49

Vollkommen „körperlos“ ist Software. Allerdings ist sie manchmal an Hardware, d. h. entsprechende Bauteile, gebunden, um funktionsfähig zu sein. Alle beschriebenen Bestandteile eines mechatronischen Produkts müssen einerseits die PLM-Anforderungen erfüllen und andererseits durch ihren Aufbau rechnerunterstützt verwaltbar sein. Gerade im Bereich der Software ist diese Forderung bedeutsam und in der praktischen Umsetzung nicht trivial. Dies zeigt sich bspw. darin, dass es oftmals seitens des Unternehmens nur mit hohem Aufwand nachvollziehbar ist, in welchem ausgelieferten Produkt welche Softwareversion aufgespielt ist. Ein typischer Stellvertreter für diese Fragestellung ist ein Computer und die aufgespielte Version seiner Betriebssoftware. Die Abb. 3-13 veranschaulicht auch indirekt den Flexibilitätsgrad der einzelnen Komponentenarten eines mechatronischen Produkts hinsichtlich ihrer Gestaltung und Anordnung in diesem Produkt. Beispiele der jüngeren Vergangenheit wie die Ablösung mechanischer Kameras mit analoger Filmaufzeichnung durch elektronische Digitalkameras verdeutlichen die gemachten Aussagen.

3.3 Modulare Prozesse Der Grundgedanke eines modularen Produkts besteht in der Möglichkeit, einzelne Module des Produkts ohne Eingriff in andere Module weglassen, austauschen oder verändern zu können. Dieses Unabhängigkeitsprinzip muss auch für die Unternehmensprozesse und ihre Teilprozesse gelten. Dies wird durch eine Gestaltung der Teilprozesse, aus denen sich ein Gesamtprozess zusammensetzt, als Module, hier also Prozessmodule, erreicht. Voraussetzung ist eine durchgängige und vollständige Festlegung aller im Rahmen der PLM-Strategie betrachteten Prozesse. Für jedes der den Gesamtprozess bildenden Prozessmodule müssen die in der Abb. 3-14 dargestellten Punkte genau festgelegt und beschrieben werden.

50

3 PLM-Voraussetzungen im Unternehmen

Abb. 3-14 Erforderliche Festlegungen für die Grobdefinition eines Teilprozessmoduls

Die erforderliche Modularität der Prozesse erfordert aber als zweiten Schritt nach der Grobdefinition der Prozessmodule deren detaillierte Festlegung. Auf diese Weise werden die die Module verbindenden Prozessschnittstellen definiert, was die Voraussetzung eines durchgängigen Prozesses ist. Diese Arbeit ist auch erforderlich, um Prozesse mit einem PDMS in Form eines Workflows abbilden zu können. In Kap. 6 ist eine konkrete Vorgehensweise zur Erstellung von Prozessmodulen beschrieben. Abb. 3-15 gibt einen Ausschnitt einer solchen Prozessmoduldefinition wieder.

Abb. 3-15 Detaillierte Festlegungen für die Definition eines Prozessmoduls

3.3

Modulare Prozesse

51

In der betrieblichen Praxis ist es aus Gründen der Effizienz sinnvoll, auf Basis der Prozessmodule Standardprozesse für immer wiederkehrende Aufgaben zu definieren. Diese Standardprozesse bestehen aus nicht variablen Prozessmodulen, die bei jeder Aufgabe durchlaufen werden müssen, und solchen, die variabel sind, also nicht immer zur Anwendung kommen, siehe Abb. 3-16. Die Struktur des Prozesses und die Verknüpfung der einzelnen Module untereinander sind dabei i. Allg. durch einen Referenzprozess fixiert.

Abb. 3-16 Exemplarische Struktur eines Standardprozesses auf der Grundlage von Prozessmodulen

Das Prinzip variabler Prozessmodule soll am Beispiel des Fertigungs- und Beschaffungsprozesses für ein Getriebegehäuse erläutert werden. Im Standardfall und bei geringen Stückzahlen wird dieses Gehäuse als Schweißkonstruktion im eigenen Unternehmen gefertigt. Damit sind die Inhalte und Umfänge der Prozessmodule für die Fertigung und den Einkauf festgelegt. Bei höheren Stückzahlen wird aus Kostengründen von einer Schweiß- auf eine Gusskonstruktion umgestellt. Damit kann das Gehäuse nicht mehr im eigenen Unternehmen gefertigt werden und wird von einem externen Anbieter beschafft. Der Gegenstand der betroffenen Prozessmodule, das Getriebegehäuse, bleibt unverändert. Die Prozessmodule für die Fertigung und den Einkauf haben nun jedoch völlig andere Inhalte und Umfänge. Die Schnittstellen der betroffenen Prozessmodule, also die des Fertigungsprozesses für das Gehäuse, der in diesem Fall wegfällt und die des Einkaufsprozesses bleiben aber weiterhin kompatibel zu den restlichen Prozessmodulen. Sowohl bei der Schweißkonstruktion, als auch bei der Gusskonstruktion bleibt die Schnittstelle der betroffenen Prozessmodule (Fertigung des Gehäuses und Einkauf der notwendigen Komponenten) dieselbe, nämlich ein fertiges Getriebegehäuse, das für die Montage be-

52

3 PLM-Voraussetzungen im Unternehmen

reitgestellt wird. Insbesondere die Beschaffungstätigkeiten als Inhalte des betroffenen Prozessmoduls sind in den beiden Fällen vollkommen unterschiedlich. Vertiefende Aspekte zur Betrachtung von Prozessen finden sich u. a. in [Schantin 1999; Pfeifer 2001; Canales Salacerry 2006].

3.4 Modulare Organisationen Analog zur Prozesslandschaft muss auch die Organisationsform eines Unternehmens der PLM-Strategie angepasst werden. Im vorherigen Abschnitt wurde im Zusammenhang mit den Unternehmensprozessen deren erforderliche und flexible Anpassung an die jeweilige Produktausprägung auf Basis der für das Produkt gewählten Module hingewiesen. Konsequenterweise resultiert aus dieser geforderten Prozessflexibilität auch eine notwendige entsprechend flexible Anpassungsmöglichkeit der Organisationsform. In der Praxis hat sich hierfür die Zweilinien- oder Matrixorganisation durchgesetzt, deren prinzipieller Aufbau in Abb. 3-17 gezeigt ist.

Abb. 3-17 Schematischer Aufbau einer Matrixorganisation

Die im Rahmen einer PLM-Strategie erforderliche Flexibilität der Unternehmensorganisation wird durch die Bildung von organisatorischenfunktionalen Einheiten erzeugt. Diese sind unabhängig vom Unterneh-

3.4

Modulare Organisationen

53

mensprozess und können deshalb jedem Abschnitt des Produktentstehungsprozesses für jeden beliebigen Auftrag zugeordnet werden. Dies entspricht den in der Abb. 3-17 eingezeichneten Flächen, die an den Kreuzungspunkten zwischen Funktion (Beschaffung, Produktion…) und Auftrag (Produktgruppe A, Produktgruppe B…) i. S. von Organisationsschnittstellen auftreten. Sie symbolisieren die genannten auftrags- und prozessunabhängigen Organisationseinheiten zur Erfüllung bestimmter Aufgaben. Diese Organisationseinheiten entsprechen gedanklich den Modulen bei einem Produkt. Sie können bei konsequenter Umsetzung des Modulgedankens ebenfalls an beliebiger Stelle des Produkts eingesetzt werden, wie dies in Abschn. 3.2 ausgeführt wurde. In Abb. 3-18 ist das Schema einer Matrixorganisation wiedergegeben, wie sie für den Technischen Bereich eines Unternehmens aussehen könnte.

Abb. 3-18 Zweilinien- oder Matrixorganisation für den Technischen Bereich eines Unternehmens nach [Eversheim 1998]

In der Abbildung ist erkennbar, dass die betreffenden Mitarbeiter des Technischen Bereichs nach ihren Fähigkeiten und Kompetenzen in jeweils so genannten Funktions- oder Kompetenzpools zusammengefasst sind. In dem dargestellten Technischen Bereich umfassen die Pools die Entwicklung, Konstruktion, Detailkonstruktion und Berechnung. Die Aufträge eines so organisierten Unternehmens werden in Projekten abgewickelt. Die zu Beginn des Abschnitts angesprochene notwendige Flexibilität entsteht

54

3 PLM-Voraussetzungen im Unternehmen

aufgrund der Möglichkeit, jedes im Unternehmen aktive Projekt aus den Funktionspools mit den erforderlichen Mitarbeitern auszustatten. Es muss aber deutlich gemacht werden, dass in der unternehmerischen Praxis die Matrixorganisation eine große Herausforderung darstellt. Insbesondere gilt dies für das Daten- und Informationsmanagement. Die Projektleitung muss also entsprechend qualifiziert sein und über die notwendigen Methoden und Hilfsmittel verfügen, siehe Abb. 3-19.

Abb. 3-19 Erforderliche Kompetenzen und Methoden einer Projektleitung [Pahl et al. 2007]

In der Praxis wird die durch eine Matrixorganisation erlangte und notwendige Flexibilität bei der Einführung einer PLM-Strategie durch eine gegenüber einer Linienorganisation deutlich erhöhten Komplexität erkauft. Wegen dieser erhöhten Komplexität, verursacht insbesondere durch das notwendige Informations- und Datenmanagement bei einer Projektabwicklung, sind rechnerunterstützte Hilfsmittel wie ein PDMS unerlässlich.

3.5 Zusammenfassung Kapitel 3 Eine erfolgreiche PLM-Strategie bezieht sich auf die drei Hauptunternehmenselemente „Produkte“, „Prozesse“ und „Organisation“. Diese müssen von der PLM-Strategie so eingebunden werden, dass die Erreichung der zuvor definierten Unternehmensziele gefördert wird. Notwendig ist die Operationalisierung der Strategie, was die Definition und Umsetzung kon-

3.5

Zusammenfassung Kapitel 3

55

kreter Maßnahmen bedeutet. Dabei muss von Beginn an die Messung des Umsetzungserfolgs bei der Planung und Festlegung der Maßnahmen zwecks späterer Erfolgskontrolle beachtet werden. Der Schlüssel zum Erfolg ist die konsequente Modularisierung der Hauptunternehmenselemente. Das bedeutet die Erstellung modularer Produkte im Rahmen modularer und flexibler Standardprozesse auf der Basis einer Matrixorganisation. Allerdings ist dazu in der überwiegenden Zahl der Fälle in den heute typischen Unternehmen eine Reihe von Vorarbeiten erforderlich, welche die Wirtschaftlichkeit der Maßnahmen in Frage stellen können. Literatur Baumgart IM (2005) Modularisierung von Produkten im Anlagenbau. Dissertation, RWTH Aachen Canales Salacerry FE (2006) Integrierter Preisfindungsprozess im Maschinenbau. Dissertation, RWTH Aachen Cornet A (2002) Plattformkonzepte in der Automobilentwicklung. Deutscher Universitätsverlag, Wiesbaden Ehrlenspiel K, Kiewert A, Lindemann U (2005) Kostengünstig Entwickeln und Konstruieren, 5. Auflage. Springer, Berlin-Heidelberg-New York Eversheim W (1998) Organisation in der Produktionstechnik – Band 2: Konstruktion, 3. Auflage. Springer, Berlin-Heidelberg-New York Franke HJ, Lippardt S, Jeschke A, Feldhahn K (1993) Standardisierung der Produktstruktur zur Verbesserung der Ablauforganisation in einem Unternehmen des Spezialmaschinenbaus. In: VDI-Z 135 Nr. 10. Springer-VDI, Düsseldorf Göpfert J (1998) Modulare Produktentwicklung - Zur gemeinsamen Gestaltung von Technik und Organisation. Deutscher Universitätsverlag, Wiesbaden Haf H (2001) Plattformbildung als Strategie zur Kostensenkung. VDI Berichte 1645, Düsseldorf Herbst D (2003) Corporate Identity - Aufbau einer einzigartigen Unternehmensidentität, Leitbild und Unternehmenskultur, Image messen, gestalten und überprüfen, 2., völlig überarbeitete Auflage. Cornelsen, Berlin Koller R (1998) Konstruktionslehre für den Maschinenbau. Springer, BerlinHeidelberg-New York Kroehl H (2000) Corporate Identity als Erfolgskonzept im 21. Jahrhundert. Vahlen, München Lang R (2000) Technologiekombination durch Modularisierung. Shaker, Aachen Ley W, Hofer AP (1999) Produktplattform - Ein strategischer Ansatz zur Beherrschung der Variantenvielfalt. In: io management Nr. 7/8. HandelsZeitung Fachverlag AG, Zürich Meier J (2007) Produktarchitekturentypen globalisierter Unternehmen. Dissertation, RWTH Aachen

56

3 PLM-Voraussetzungen im Unternehmen

Metzger U, Kontny H, Burkert WD (2002) Kundenindividuelle Produkte leicht gemacht - Plattform- und Modulgestaltung im Investitionsgüterbereich über Target Engineering. In: Produktmanagement Nr. 11 Pahl G, Beitz W, Feldhusen J, Grote KH (2007) Konstruktionslehre - Grundlagen erfolgreicher Produktentwicklung, 7. Auflage. Springer, Berlin-HeidelbergNew York Pfeifer T (2001) Qualitätsmanagement - Strategien, Methoden, Techniken. 3. Auflage. Hanser, München-Wien Schantin D (1999) Kundenorientierte Gestaltung von Geschäftsprozessen durch Segmentierung und Kaskatierung. Dissertation, TU Graz Schmelzer HJ, Sesselmann W (2004) Geschäftsprozessmanagement in der Praxis, 4. Auflage. Hanser, München-Wien Schuh G (1988) Gestaltung und Bewertung von Produktvarianten - Ein Beitrag zur systematischen Planung von Serienprodukten. Dissertation, RWTH Aachen Stang S, Hesse L, Warnecke G (2002) Plattformkonzepte - Eine strategische Gratwanderung zwischen Standardisierung und Individualität. In: ZWF 97 Nr. 3. Hanser, München-Wien Ulrich K (1995) The Role of Product Architecture in Manufacturing Firm. In: Research Policy 24 Nr. 5. Elsevier, Amsterdam VDI-Richtlinie 2206 (2004) Entwicklungsmethodik für mechatronische Systeme. VDI Verlag, Düsseldorf VDI-Richtlinie 2221 (1993) Methodik zum Entwickeln und Konstruieren technischer Systeme und Produkte. VDI Verlag, Düsseldorf

4 Umsetzung von PLM

In den beiden ersten Kapiteln wurde das Potenzial des Product Lifecycle Managements (PLM) beschrieben. Im Idealfall soll bei einer Realisierung im Unternehmen dieses Potenzial vollständig erfasst und umgesetzt werden. Gleichzeitig muss der dazu notwendige Aufwand an Ressourcen überschaubar bleiben. In diesem Kapitel werden für eine effiziente PLM-Umsetzung mögliche Ansätze, notwendige Voraussetzungen und ihre Auswirkungen im Unternehmen vorgestellt. Dies beinhaltet neben der Berücksichtigung der Datenund Informationsflüsse (D&I-Flüsse) entlang des Produktentstehungsprozesses (PEP) auch eine geeignete Modellierung der Produkte, Prozesse und Organisation. Dabei wird die Umsetzung und Realisierung von PLM maßgeblich durch den Einsatz eines Produktdatenmanagement-Systems (PDMS) unterstützt. Seine Systemfunktionalitäten bilden eine erfolgsentscheidende Voraussetzung zur gewünschten Beherrschung der Unternehmenskomplexität. In vielen Fällen sind sich Unternehmen unsicher hinsichtlich ihrer Erwartungen an das PDMS und des damit verbundenen Einführungsaufwands. Aus den Bedürfnissen des jeweiligen Unternehmens werden allgemeine Anforderungen abgeleitet, die für eine erfolgreiche Systemeinführung berücksichtigt werden müssen. Dabei betrifft eine wesentliche Anforderung die Ermittlung der augenblicklichen Unternehmenseignung, das PDMS nach seiner Einführung effektiv und effizient einsetzen zu können. Dies geschieht durch die Bestimmung der unternehmensindividuellen PDMS-Fähigkeit. Sie lässt sich durch den PDMSReifegrad bewerten.

4.1 Anwendung der PLM-Strategie auf der Basis vorhandener Produkte Sämtliche Produkte eines Unternehmens bilden seine Existenzgrundlage. Deshalb müssen in diesem Bereich alle Eingriffe sehr zielgerichtet und ab-

58

4 Umsetzung von PLM

gesichert vorgenommen werden. Falsche Entscheidungen gefährden die Existenz des Unternehmens. In Kap. 3 wurde auf die Bedeutung der Modularität, insbesondere bei den Produkten als Voraussetzung zur erfolgreichen Umsetzung einer PLM-Strategie eingegangen. In der Vergangenheit entwickelten sich bei vielen Unternehmen die Produkte jedoch oftmals evolutionär aufgrund von Kundenaufträgen mit gleichen oder ähnlichen Anforderungskriterien [ElMaraghy 2007]. Deshalb bauen die Entwicklungsstufen derartiger Produkte aufeinander auf und sind sich ebenfalls ähnlich. Diese Vorgehensweise war und ist für das Unternehmen wirtschaftlich und birgt überschaubare Risiken. Da diese evolutionären Produkte einen großen Anteil am Gesamtunternehmenserfolg ausmachen, stellt sich die Frage, wie mit ihnen bei einer PLM-Umsetzung umgegangen werden soll. Dabei ist besonders zu berücksichtigen, dass in diesen Produkten das gesamte Unternehmenswissen direkt oder indirekt gespeichert ist. Dieses Wissen stellt ein bedeutsames Unternehmenskapital dar; es muss folglich bewahrt werden und zur weiteren Nutzung verfügbar bleiben. Die radikale Umsetzung einer sofortigen Entwicklung und Fertigung modular aufgebauter Produkte ist für viele Unternehmen scheinbar nicht durchführbar. Oftmals stehen dafür weder die notwendigen finanziellen noch personellen Ressourcen zur Verfügung. Ebenso ist das Risiko einer Fehlentwicklung hoch. Dennoch ist die Umsetzung einer Produktmodularität für neue Produktlinien attraktiv: Einmal entwickelt, bieten modular aufgebaute Produkte ein hohes Einsparpotenzial bei den erforderlichen Ressourcen in Abteilungen wie der Auftragsabwicklung, der Fertigung, dem Service oder der Entwicklung. Nachteilig ist jedoch der hohe betriebswirtschaftliche (Einmal-)Aufwand für die Ersterstellung, der kalkuliert werden muss. Letztlich entscheidet die zukünftig erwartete absetzbare Stückzahl der neuen modularen Produkte über eine Realisierung. Ein möglicher Ansatz zur Lösung dieses Dilemmas zwischen vorhandenen evolutionären und idealerweise modularen Produkten im Rahmen der PLM-Umsetzung ist eine Sonderform des Variantenmanagements. Es handelt sich um die sog. Referenzprodukt-Strategie. Dabei werden so genannte Referenzprodukte definiert. Als ein wesentlicher Baustein zur Reduzierung der vorhandenen Unternehmenskomplexität wurde die nutzen- und marktgerechte Optimierung der externen Produktvielfalt identifiziert (vgl. Abb. 2-6). Durch folgende Schritte wird die Optimierung erreicht:

4.1

Anwendung der PLM-Strategie auf der Basis vorhandener Produkte

59

x In einem ersten Schritt werden über eine Analyse der Verkaufszahlen und der erzielten Renditen die für das Unternehmen wirtschaftlichsten Produkte und ihrer Varianten ermittelt. x Im zweiten Schritt werden die unwirtschaftlichen Produkte einschließlich ihrer Varianten konsequent aus dem Angebot gestrichen. x Schließlich kann im dritten Schritt für jede wirtschaftliche Produktgruppe ihr spezifisches Variantenbild erstellt werden, wie es schematisch in Abb. 4-1 gezeigt ist.

Abb. 4-1 Schematische Darstellung des spezifischen Variantenbildes einer Produktgruppe

Das wichtigste Untersuchungsergebnis stellt dabei das Referenzprodukt der betrachteten Produktgruppe dar. Das Referenzprodukt ist in der Mitte der Abb. 4-1 gezeigt. In der Praxis ist es möglich, dass innerhalb einer Produktgruppe mehrere Referenzprodukte existieren. Die dargestellten schwarzen Punkte in der Abbildung repräsentieren diejenigen Baugruppen bzw. Bauteile, die in jeder Variante unverändert bleiben. An den Enden einiger Strukturäste sind die Ausprägungen möglicher variabler Baugruppen bzw. Bauteile in Form von unterschiedlichen wei-

60

4 Umsetzung von PLM

ßen Symbolen abgebildet. Durch die Ableitung aus der Referenzstruktur können die in diesem Beispiel gezeigten Varianten 1 bis 6 erzeugt werden. Dem Aufbau des Referenzprodukts kommt eine entscheidende Rolle bei der Gestaltung der PLM-Umsetzung zu. In Abb. 4-2 ist die allgemeine Struktur eines Referenzprodukts in Form einer schematischen Strukturstückliste dargestellt. Die weißen Strukturelemente repräsentieren diejenigen Baugruppen bzw. Bauteile, die in allen abgeleiteten Varianten unverändert bleiben. Sie entsprechen in Abb. 4-1 den schwarzen Punkten. Die unveränderlichen Strukturelemente sind folglich für sämtliche Varianten des Referenzprodukts bekannt und beinhalten deshalb auch die entsprechenden Identnummern der zugehörigen Bauteile bzw. Baugruppen. Das hellgraue Element steht stellvertretend für alle möglichen vorgedachten Varianten von Baugruppen bzw. Bauteilen, die an dieser Stelle alternativ eingesetzt werden. Sie entsprechen in Abb. 4-1 den unterschiedlichen weißen Symbolen. Da es sich nach der Festlegung der Variante aufgrund der Kundenanforderung ebenfalls um konkrete, vorhandene Baugruppen bzw. Bauteile handelt, können auch in diesem Fall die zugehörigen Identnummern angegeben werden.

Abb. 4-2 Schematische Darstellung einer Referenzproduktstruktur

Die Struktur eines jeden Referenzprodukts mit seinen unveränderlichen Referenzbauteilen bzw. -baugruppen ist in Form einer Strukturstückliste im Produktplanungssystem (PPS) des Unternehmens gespeichert. Hier sind zudem die zulässigen Standardvariantenbaugruppen bzw. -bauteile für die jeweiligen Referenzprodukte abgelegt. Ebenfalls im PPS sind auch die zulässigen Standardvariantenbauteile bzw. die zulässigen Standardvarianten-

4.1

Anwendung der PLM-Strategie auf der Basis vorhandener Produkte

61

baugruppen in Form von Stücklisten für die jeweiligen Referenzprodukte gespeichert. Nach der Festlegung von Referenzstrukturen stellt sich für das Unternehmen ein typischer Kundenbestellvorgang wie folgt dar: Bei Eingang einer Bestellung wird anhand der Kundenanforderungen überprüft, welche im PPS vorhandene Referenzstruktur dem gewünschten Produkt am ähnlichsten ist. Im Idealfall ist dies ein bereits vorhandenes Standardprodukt. Dabei ist es aus Gründen der Effektivität zulässig, nicht benötigte Referenzbaugruppen bzw. -bauteile entfallen zu lassen. Damit eine undefinierte Schnittstelle, die zuvor nicht am Referenzprodukt festgelegt wurde, am realen Produkt erst gar nicht entstehen kann, ist die unkontrollierte Einführung neuer Baugruppen oder Bauteile unbedingt zu vermeiden. Auf den Fall solcher kundenspezifischen Elemente wird später eingegangen. Nach dieser Zuordnung ist ein Referenzprodukt einschließlich seiner Identnummer für den Kundenauftrag spezifisch festgelegt. In Abb. 4-2 besitzt das Referenzprodukt die Identnummer 4711. Da das zugeordnete Referenzprodukt aus konkreten, unveränderlichen (in Abb. 4-2 weiß dargestellten) Strukturelementen besteht, besitzen diese ebenfalls Identnummern. Anschließend werden aufgrund der Kundenanforderungen die variablen Baugruppen bzw. -teile zur Erfüllung bestimmt. Sie sind durch das hellgraue Strukturelement in Abb. 4-2 repräsentiert. Diese variablen Baugruppen und Bauteile sind ebenfalls im PPS gespeichert. Dies bedeutet, dass alle sinnvollen variablen Elemente eines Referenzprodukts hinsichtlich ihrer Entwicklung und Konstruktion, zumindest in ihren wesentlichen Maßen, bereits „vorgedacht“ wurden. Unabdingbar ist dabei die detaillierte Gestaltung der Schnittstellen zwischen den variablen Elementen und dem restlichen, festgelegten Referenzprodukt. In den beschriebenen Ausführungen zur Umsetzung der PLM-Strategie ist diese Anforderung erfüllt, da von der vereinfachten Annahme vorhandener Produkte ausgegangen wurde. Diese Annahme trifft allerdings in der Unternehmenspraxis kaum zu, so dass entsprechende Anpassungsarbeiten an den zugeordneten Produkten vorgenommen werden müssen. Die Auswahl der erforderlichen Produktkomponenten erfolgt bei dem beschriebenen Ablauf auf Basis der Kundenbestellung und der zugehörigen Anforderungsliste. Wie die in Abb. 4-1 dargestellte Struktur des betrachteten Referenzprodukts zeigt, sind in der Praxis mehrere Schnittstellen für Baugruppen- bzw. Bauteilvarianten vorhanden. Aus diesem Grund muss nach der Auswahl der variablen Produktkomponenten zunächst die Einhaltung der geforderten Anforderungen kontrolliert werden.

62

4 Umsetzung von PLM

Auch wenn die ausgewählten variablen Elemente der Produktstruktur die Anforderungen erfüllen, muss deren Zulässigkeit im Zusammenspiel mit dem gesamten Produkt geprüft werden. Damit wird gewährleistet, dass das Produkt mit den gewählten Elementen auch funktionstüchtig ist. Hierfür waren früher in der Praxis häufig gebaute, reale Prototypen erforderlich. Mittlerweile werden diese Prototypen bis zu einem gewissen Grad zunehmend in virtueller Form mit Hilfe von Simulationen auf die Einhaltung der geforderten Funktionalitäten geprüft. Hierzu zählen im Bereich der Festigkeitsüberprüfung bspw. die Finite Elemente Methode (FEM), im Bereich der Kinematik bspw. die Mehrkörpersimulation (MKS) oder im Bereich der Strömungssimulation das Computational Fluid DynamicsVerfahren (CFD). Das Referenzprodukt ermöglicht jedoch auch die Einbringung von kundenspezifischen Baugruppen bzw. Bauteilen (in Abb. 4-2 als schwarz gefülltes Strukturelement dargestellt), die im PPS nicht als „vorgedachte“ Varianten abgelegt sind. Dies geschieht an einem genau definierten Strukturpunkt innerhalb der Referenzproduktstruktur. Dadurch wird eine beliebige Integration von kundenspezifischen Elementen und eine daraus resultierende hohe Produktkomplexität, wie sie in Kap. 2 beschrieben wurde, vermieden. Der genau definierte Strukturpunkt des Referenzprodukts wird am realen Produkt als offene Schnittstelle gestaltet. Ein Beispiel ist die Gestaltung eines Rohflansches, an dem ein zusätzliches kundenspezifisches Bauteil angeflanscht werden kann. Je nach Beschaffenheit der Schnittstelle des kundenspezifischen Bauteils muss der Rohflansch noch bearbeitet werden, bspw. durch das Einbringen zusätzlicher Bohrungen. An diesem Beispiel ist erkennbar, dass auch die „offenen“ Schnittstellen im Produkt planbar sein müssen. Folglich müssen auch kundenspezifische Elemente bis zu einem bestimmten Grad vorhersehbar sein. Für ihre Gestaltung, besonders an den Schnittstellen, wird ein konventioneller Entwicklungs-/Konstruktionsprozess (E/K) durchgeführt. Der vorgestellte strategische Ansatz mittels Referenzprodukten (Referenzprodukt-Strategie) bei einer PLM-Umsetzung bietet ein hohes Einsparpotenzial hinsichtlich sämtlicher beteiligter Ressourcen. Dies ist in Abb. 43 gezeigt. Der Grund liegt darin, dass nun im Vergleich zum bestehenden konventionellen E/K innerhalb der Produktentwicklung eine Verlagerung von ehemals nicht oder nur schlecht planbarer Denkarbeit zu einer planbaren Routinearbeit stattfindet. Ein positiver Aspekt ist, dass dieser Ansatz ein hohes Standardisierungspotenzial beinhaltet. Zusätzlich bieten Referenzprodukte eine ausgezeichnete Steuerungsmöglichkeit hinsichtlich der Beherrschung von Produktvarianten.

4.1

Anwendung der PLM-Strategie auf der Basis vorhandener Produkte

63

Auf der anderen Seite wird jedoch der bisherige „traditionelle“ E/KAblauf im Unternehmen völlig verändert, was ein flexibles Umdenken bei den beteiligten Mitarbeitern voraussetzt [Champy 2002].

Abb. 4-3 Wandel des konventionellen Entwicklungs-/Konstruktionsprozesses (E/K) durch Anwendung der Referenzprodukt-Strategie.

Eigene Erfahrungen der Autoren zeigen, dass der Anteil von variablen Strukturelementen bei einem Referenzprodukt 10% nicht übersteigen sollte, wenn eine effiziente Beherrschung der Produktvarianten erreicht werden soll. Kundenspezifische Elemente sollten grundsätzlich als Sonderfall behandelt werden. In Abb. 4-4 ist das Gesamtsystem bei der Anwendung der Referenzprodukt-Strategie dargestellt. Sie zeigt das Zusammenspiel einer Referenzstruktur mit einem Referenzprozess wie dem PEP und dem PPS als Wissensspeicher. Das Zusammenspiel erfolgt über Daten- und Informationsflüsse zwischen den einzelnen Elementen. Im unteren Teil der Abbildung ist der bereits in Abschn. 3.3 vorgestellte Standardprozess wiederzuerkennen. Es ist zweckmäßig, bei der Anwendung der Referenzprodukt-Strategie einen zum Referenzprodukt zugehörigen Referenzprozess zu definieren oder einen vorhandenen Prozess entsprechend anzupassen. Dies geschieht auf der Grundlage von Standardprozessen. Da das Referenzprodukt aus unveränderlichen bzw. „vorgedachten“ variablen Elementen besteht, werden ebenfalls unverän-

64

4 Umsetzung von PLM

derliche bzw. „vorgedachte“ variable Prozesselemente in Form von Prozessmodulen benötigt. Ihre Anpassung erfolgt in Abhängigkeit von der Art der im Produkt verwendeten variablen Komponenten, die in der Abb. 4-2 als grau gefüllte Elemente dargestellt sind. Der eigentliche Referenzprozess bleibt in seiner Struktur und in seinem Ablauf unberührt. Dies bedeutet, dass für die Erstellung von Referenzprozessen auf dieselbe Weise wie bei den Referenzprodukten vorgegangen werden kann.

Abb. 4-4 Zusammenspiel zwischen der Referenzstruktur, dem Referenzprozess und dem Wissensspeicher (PPS).

Durch den Wissensspeicher soll sämtliches unternehmensspezifisches Wissen gesammelt und den Mitarbeitern zur Verfügung gestellt werden [Mertins et al. 2003; Holsapple 2003]. Wie bereits ausgeführt wurde, sind die einzelnen Wissensinhalte nach Anwendung der ReferenzproduktStrategie im PPS abgespeichert. Sie bestehen aus fertigen Lösungen in Form von Zeichnungen und Stücklisten des Referenzprodukts sowie seiner variablen Komponenten. Vorhandene Lösungen sind in Abb. 4-4 durch die einzelnen Papierblätter symbolisiert.

4.2

Steuerung der Daten- und Informationsflüsse

65

Damit ist jedoch nur ein Teil des vorhandenen Unternehmenswissens erfasst. Neben dem Wissen in den Köpfen der Mitarbeiter betrifft dies auch Wissensinhalte, die erfahrungsgemäß dezentral in IT-Systemen über das gesamte Unternehmen verteilt sind. So befinden sich bspw. CAD-Modelle in anderen Datenbanken als ihre Simulationsdaten oder der produktzugehörige Standardprozess mit seinen variablen Prozessmodulen. Im idealen Fall sind diese verteilten Daten aufeinander referenziert und können durch entsprechende Daten- und Informationsflüsse gesteuert werden. Dieser Idealfall repräsentiert jedoch nicht die tatsächliche Situation in kleinen und mittelständischen Unternehmen. Eine Lösungsmöglichkeit besteht in der Erfassung der Daten- und Informationsflüsse durch geeignete Modelle. Diese können durch ein PDMS verwaltet, gepflegt, aktuell gehalten und gesteuert werden.

4.2 Steuerung der Daten- und Informationsflüsse Wie in Abschn. 4.1 deutlich wurde, bildet die Anpassung der vorhandenen Unternehmensprodukte einen Schwerpunkt bei der PLM-Umsetzung. Dies kann bspw. mittels der Referenzprodukt-Strategie geschehen. Dabei ist es zweckmäßig, jedem einzelnen Produktelement einen entsprechenden Prozessschritt aus dem zugehörigen Standard- bzw. Referenzprozess zuzuordnen. Durch diese Zuordnung ist es möglich, das PLM-Potenzial entlang des PEP vollständig zu nutzen. So können sämtliche Abteilungen auf alle benötigten Produkt- und Prozessdaten während des Produktlebenszyklus zugreifen und sie für die einzelnen Aktivitäten innerhalb der Lebenszyklusphase verwenden, siehe Abb. 4-5. Beispielsweise können die CADDaten, welche im Entwicklungsbereich erzeugt werden, auch für die Betriebsmittelerstellung und für die Fertigung genutzt werden. Dies ist jedoch nur dann möglich, wenn alle Daten zum entsprechenden Zeitpunkt am richtigen Ort in der entsprechenden Form und der benötigten Aktualität vorhanden sind. Anders ausgedrückt: Die unternehmensweite Integration sämtlicher Daten und Informationen stellt einen zweiten PLMUmsetzungsschwerpunkt dar. Es werden v. a. die Steuerbarkeit, die Durchgängigkeit und die Vollständigkeit sämtlicher Daten betrachtet, die im Unternehmen vorhanden sind.

66

4 Umsetzung von PLM

Abb. 4-5 Daten- und Informationsflüsse entlang des PEP zur Nutzung aller beteiligten Abteilungen [Pahl et al. 2007]

4.2

Steuerung der Daten- und Informationsflüsse

67

In Kap. 3 wurde ausgeführt, dass sich sämtliche Produkte, produktentwicklungsrelevante Prozesse und die zugehörige Aufbauorganisation des Unternehmens gegenseitig beeinflussen. Alle drei Aspekte können durch Produktdatenmodelle, Prozessmodelle und Rollenmodelle beschrieben werden [Schöttner 1999; Eigner u. Stelzer 2001]. Sie werden nachfolgend definiert. Die Modelle selbst bestehen aus den entsprechenden Produktdaten, Prozessdaten und Verantwortlichkeiten in Form von Rollen. Sie bilden in ihrer Gesamtheit die D&I-Flüsse des Unternehmens. Die enge gegenseitige Wechselwirkung zwischen Produktdaten, Prozessdaten und Rollen zeigt Abb. 4-6 am Beispiel des Technischen Bereichs eines Unternehmens. Der Technische Bereich wird deshalb betrachtet, da in dieser Abteilung die meisten relevanten Produktdaten erzeugt werden [Ehrlenspiel 2006; Pahl et al. 2007]. Nachfolgend werden die einzelnen Modelle mit ihren Grundstrukturen kurz und vereinfacht beschrieben. Ihre Erstellung und Bewertung wird in den Kap. 6 und 7 ausführlicher behandelt.

Abb. 4-6 Daten- und Informationsflüsse innerhalb des Technischen Bereichs

[Feldhusen et al. 2005 a] definiert das Produktdatenmodell wie folgt: Unter dem Produktdatenmodell wird die modellhafte Darstellung eines physischen Produkts verstanden, welches sämtliche produktbeschreibenden Daten einschließlich deren Klassifizierungen, Referenzierungen und Eigenschaften (Attribute) beinhaltet.

68

4 Umsetzung von PLM

Das Produktdatenmodell per se enthält keine prozess- oder organisationsbeschreibenden Daten; es besteht ausschließlich aus produktbeschreibenden Daten wie Angaben zu Bauteilen oder Baugruppen. Nach [Eigner u. Stelzer 2001] bildet die Stückliste des Endgeräts die Produktstruktur in erster Näherung ab und kann damit als Grundlage zur Modellerstellung verwendet werden. Eine weitere Grundlage bildet das CAD-Modell, welches mit Hilfe entsprechender CAD-Software von dem verantwortlichen Konstrukteur erzeugt worden ist. Die vereinfachte Struktur eines Produktdatenmodells ist schematisch in Abb. 4-7 dargestellt. Diese Darstellungsform ist nicht für eine Systemimplementierung, wie sie bspw. in der [ISO 10303] vorgeschlagen wird, geeignet. Sie eignet sich jedoch ausgezeichnet für die Darstellung der relevanten Produktdaten und ihrer gegenseitigen Abhängigkeiten. Dabei liegen die einzelnen Produktdaten unter den elliptisch dargestellten Datenschwerpunkten. Spezifische Datenschwerpunkte können in Abhängigkeit des betrachteten Produkts zum dargestellten Produktdatenmodell ergänzt werden.

Abb. 4-7 Schematische Darstellung des Produktdatenmodells

Das hier gezeigte schematische Produktdatenmodell besteht aus folgenden Datenschwerpunkten: x Vertriebsspezifische Daten wie Kundenauftrag, Lastenheft, Terminvorgaben, Material etc. aus dem Vertrieb;

4.2

Steuerung der Daten- und Informationsflüsse

69

x Projektspezifische Ressourcendaten wie Termine oder verfügbare Mitarbeiter (ggf. Rechenzeit etc.) aus der Projektmanagementabteilung oder dem Projektplanungssystem; x die eigentlichen Produktdaten, welche sich in Bauteil- und Baugruppendaten unterteilen. Sie sind, wie in Abschn. 4.1 ausgeführt, im PPS in Form von Stücklisten und/oder (Tabellen-)Zeichnungen gespeichert. In diesen Datenschwerpunkten werden neben den mechanischen auch die elektrischen bzw. elektronischen sowie die softwaretechnischen Produktkomponenten geführt; x produktzugehörige Verpackungsdaten, die einem Produkt entweder eine bestimmte Standardverpackung oder Varianten davon zuweisen. Die Variantenzuweisung wird notwendig, wenn bspw. aufgrund des Lieferwegs oder des Bestimmungsorts besondere klimatische (Temperatur; Luftfeuchtigkeit etc.) oder transporttechnische Bedingungen (Stoßempfindlichkeit etc.) berücksichtigt werden müssen; x sowie produktspezifische weitere Datenschwerpunkte, die vom hergestellten Endprodukt oder der Dienstleistung abhängig sind. Ein Beispiel stellt die (Steuerungs-)Software eines mechatronischen Produkts dar. Einen Sonderfall stellt der Fertigungsauftrag dar: Falls es sich bei einer Kundenbestellung um ein Katalogprodukt ohne entsprechende Kundenanpassungen handelt, kann der Fertigungsauftrag auf der Grundlage des Produktdatenmodells direkt erzeugt werden. Möglicherweise kann auch sofort aus dem Lager geliefert werden, auch dieser Auftrag leitet sich unmittelbar aus dem Produktdatenmodell ab. Ein neues Entwicklungsprojekt wird nur dann notwendig, wenn aufgrund der Kundenanforderungen spezifische Anpassungen notwendig werden. Dies geschieht auf der Grundlage der Referenzprodukt-Strategie entweder über vorhandene „vorgedachte“ Strukturelemente oder über kundenspezifische Produktanpassungen. Aus den Ausführungen ist erkennbar, dass ein reines Produktdatenmodell in der Praxis in dieser Form faktisch nicht vorhanden ist, da die Daten durch entsprechende Tätigkeiten von Personen oder IT-Systemen (Hardund/oder Software) erzeugt werden müssen. Die Tätigkeitsausführung geschieht in Form von definierten Arbeitsabläufen. Sie werden durch das Prozessmodell definiert [Feldhusen et al. 2005c]. Das Prozessmodell ist eine modellhafte Darstellung von zielgerichteten Aktivitäten bzw. Abläufen einschließlich der prozessrelevanten Eingangs- und Ausgangsdaten und Rollen. Das Prozessmodell bildet die einfachste Ausgangsbasis zur Erfassung derjenigen Daten, die zur Erstellung aller drei Modelle benötigt werden.

70

4 Umsetzung von PLM

In Abb. 4-8 ist der grundsätzliche Aufbau eines Prozessmodells gezeigt. Die einzelnen Bestandteile wie Eingangs- oder Ausgangsdaten sind dabei von der Betrachtungsebene unabhängig – sie gelten für den Gesamtprozess ebenso wie für die darunter liegende Teilprozessebene oder für jeden einzelnen Prozessschritt, welcher die auszuführende Aktivität beschreibt. Der Gesamtprozess bzw. seine Teilprozesse werden oftmals in Form von Flussdiagrammen dargestellt. Für die systemtechnische Darstellung haben sich Hilfsmittel wie das SADT-Diagramm (Structured Analysis and Design Technique) oder das ARIS-Toolset (Architektur integrierter Informationssysteme) in der Praxis etabliert (vgl. Kap. 6).

Abb. 4-8 Schematischer Aufbau des Prozessmodells einschließlich seiner beschreibenden Daten

Jeder Geschäftsprozess, Teilprozess und Prozessschritt ist durch folgende Größen gekennzeichnet: x Eingangsdaten stellen das Ergebnis einer vorgelagerten Aktivität dar. Durch sie wird ein nachfolgender (Teil-)Prozess bzw. Prozessschritt ausgelöst. Weitere Eingangsdaten zur Aktivitätenausführung sind die zugewiesenen Ressourcen oder auch die Ziele, die durch den Prozess bzw. die Aktivität erreicht werden sollen. x Die Ausgangsdaten stellen das Ergebnis des (Teil-)Prozesses bzw. der Aktivität dar. Je nach Betrachtungsebene können dies sowohl Produktdaten als auch der gefertigte reale Prototyp sein. Die Ausgangsdaten lö-

4.2

Steuerung der Daten- und Informationsflüsse

71

sen wiederum Aktivitäten nachgelagerter Prozessschritte aus. Diesen dienen sie als Eingangsdaten. x Jeder Prozess bzw. Prozessschritt wird neben seinen Ausführungsinhalten durch Steuerungsgrößen bestimmt. Dabei handelt es sich um Informationen wie Arbeitsvorgaben oder Daten wie die Durchlaufzeit. Diese Steuerungsgrößen besitzen bei Wirtschaftlichkeitsbetrachtungen eine hohe Bedeutung, da durch sie die Prozesseffizienz entscheidend beeinflusst werden kann. Sämtliche Prozessaktivitäten und die Erzeugung bzw. Nutzung der mit ihnen verbundenen Prozess- und/oder Produktdaten müssen von entsprechenden Akteuren durchgeführt werden. Diese Akteure können entweder Unternehmensmitarbeiter oder auch bestimmte Systemfunktionalitäten sein, die bspw. automatische E-Mails generieren oder an bestimmte Termine erinnern. Die Zuweisung von Akteuren zu einzelnen Prozessaktivitäten und deren Berechtigungen an den entsprechenden Prozess- bzw. Produktdaten wird durch das Rollenmodell festgelegt [Feldhusen et al. 2006a]: Eine Rolle ist die nutzerneutrale Beschreibung einer Funktion, einer Aufgabe oder einer auszuführenden Aktivität. Sie wird auch als Unternehmensinstanz bezeichnet. Die Zugriffsberechtigungen einer Rolle werden kontext- und objekttypabhängig unter Berücksichtigung der Produktlebenszyklusphase durch das Rollenkonzept beschrieben. Dies geschieht in Abhängigkeit der Ablauforganisation und weist eindeutige Verantwortlichkeiten durch die Zuordnung von personellen oder systemtechnischen Akteuren auf. Die Gesamtheit zwischen Rollen und deren Steuerung über das Rollenkonzept wird als Rollenmodell bezeichnet. Die Steuerung über Rollen und deren Zugriffsberechtigungen auf Prozessund Produktdaten ist in Abb. 4-9 gezeigt. Dabei werden als Datenobjekte nicht nur Prozess- oder Produktdaten, sondern sämtliche am PEP beteiligten bzw. im Laufe des PEP erzeugten Daten wie Dokumente, Zeichnungen, E-Mails, eingescannte Formulare etc. verstanden. Die Zusammenhänge zwischen Rollen, Prozessen bzw. Teilprozessen oder Prozessschritten und Datenobjekten stellt sich folgendermaßen dar: Eine Rolle beschreibt neutral eine bestimmte Aufgabe, die an bestimmten Datenobjekten oder während bestimmter Prozessschritte auszuführen ist. So muss bspw. ein erzeugtes 3D-CAD-Modell von einem verantwortlichen Prüfer geprüft werden, bevor die Daten in andere Abteilungen wie der Fertigung oder der Betriebsmittelherstellung weitergeleitet werden dür-

72

4 Umsetzung von PLM

fen. Die Aufgabe stellt das „Dokument prüfen“ dar; verantwortlich ist der Prüfer. Die Ausführung einer Aufgabe geschieht als Tätigkeit während eines Prozessschritts. Der Unterschied zur Aufgabe besteht einerseits in ihrer aktiven Durchführung, andererseits in der Zuweisung einer konkreten Verantwortung. So ist in diesem Beispiel der neutral beschriebene Prüfer der Projektleiter, welcher als Akteur durch den Mitarbeiter „Noah Gebhardt“ namentlich zugewiesen ist. Dieser Mitarbeiter besitzt als Projektleiter definierte Rechte. Sie legen fest, was er mit dem Datenobjekt tun darf: In diesem Fall kann er das Modell lesen, er darf es jedoch nicht verändern oder gar löschen. Dies darf nur der Mitarbeiter Schulze, der in der Rolle „Konstrukteur“ für die Erzeugung und die Pflege des Modells verantwortlich ist. In der Praxis allerdings verwischt die beschriebene Trennung zwischen Aufgabe und Tätigkeit; beide werden als identisch betrachtet.

Abb. 4-9 Steuerung der Prozess- und Produktdaten über Rollen

Der Vorteil von Rollen liegt in ihrer neutralen Beschreibung von Aufgaben; diese Beschreibungen sind Arbeitsplatzbeschreibungen ähnlich, jedoch viel spezifischer definiert. Dadurch ist es möglich, in IT-Systemen bspw. im Krankheitsfall eines Mitarbeiters schnell einen anderen Akteur einzusetzen, der die entsprechenden Tätigkeiten des erkrankten Mitarbeiters übernimmt. Damit werden kontinuierliche Prozessabläufe sichergestellt, die nicht von einzelnen Mitarbeitern abhängig sind.

4.2

Steuerung der Daten- und Informationsflüsse

73

Zusätzlich lassen sich durch Rollenbeschreibungen entsprechende Mitarbeiterprofile erstellen, die gezielt als Schulungsgrundlage genutzt werden können. Sie beschreiben notwendige Qualifikationen, die der verantwortliche Mitarbeiter zur effizienten Ausübung seiner Tätigkeit besitzen muss. In Kap. 6 wird auf die Erstellung des Rollenmodells auf der Grundlage definierter Rollen vertieft eingegangen. Die Darstellung durch diese drei Modelle unterstützt die Erfassung sowie die Analyse der bestehenden Daten- und Informationsflüsse vor- und während einer PLM-Umsetzung. Dies umfasst sämtliche Produkt- und Prozessdaten einschließlich ihrer Dokumente sowie den zugehörigen Verantwortlichkeiten. Damit kann letztendlich das explizite Unternehmenswissen erfasst und im Wissensspeicher zur weiteren Verwendung abgelegt werden. Anhand der Darstellung in Abb. 4-5 ist leicht erkennbar, dass in heutigen Unternehmen die Zahl der existierenden Daten immens ist. So kann die Speichergröße für beschreibende Produktdaten bspw. im Anlagenbau für eine einzige Anlage mehrere Terabytes umfassen. Bei hochkomplexen Produkten wie Automobilen o. ä. sind ähnliche Datenmengen vorhanden. Auch bei verhältnismäßig „einfachen“ Produkten wie einem Mobiltelefon können die zugehörigen Datenmengen schnell unüberschaubar werden, wenn die entsprechenden Variantenprägungen in die Betrachtungen einbezogen werden. Hinzu kommt eine Vielzahl unterschiedlicher Datentypen wie 3D-CAD-Modelldaten, 2D-Zeichnungen, eingescannte Skizzen oder beschreibende Dokumente wie Lastenhefte. Folglich ist es nachvollziehbar, dass eine effiziente Steuerung der D&I-Flüsse nur rechnerunterstützt erfolgen kann. Der in Abschn. 4-1 vorgestellte Wissensspeicher muss deshalb systemtechnisch erweitert werden, damit die beschriebenen Modelle in ihm gespeichert werden können (Abb. 4-10). So ist es bspw. nicht ohne weiteres möglich, CAD-Modellierungsdaten im PPS abzulegen. Zusätzlich müssen spezielle Systemfunktionalitäten vorhanden sein, die eine Modellpflege ermöglichen und die entsprechenden Daten zum richtigen Zeitpunkt den einzelnen Mitarbeitern gezielt zur Verfügung stellen können. Die meisten gebräuchlichen PPS besitzen diesen notwendigen Funktionsumfang nur eingeschränkt oder überhaupt nicht, da sie für diese Verwendung ursprünglich nicht gedacht waren. Aus den bisherigen Ausführungen lassen sich zwei wesentliche Modellanforderungen ableiten: Die Modelle müssen die einzelnen Hauptunternehmenselemente Produkt, Prozess und Organisation hinreichend abbilden können. Zusätzlich müssen sie aber auch durch ihren Aufbau geeignet sein, die Anwendung wesentlicher Systemfunktionalitäten zu unterstützen.

74

4 Umsetzung von PLM

Dies betrifft bspw. die Berücksichtigung von Produktvarianten oder Produktversionen auf Endgeräte-, Baugruppen- und Bauteilebene.

Abb. 4-10 Zusammenspiel zwischen den Referenzprodukten, Referenzprozessen und dem erweiterten Wissensspeicher mit den gespeicherten Modellen

Die Aufgabe der Modell- und Datenverwaltung übernimmt im Rahmen der PLM-Strategie ein Produktdatenmanagement-System (PDMS). Der Begriff „PDMS“, seine Architektur und seine Funktionalitäten werden im nächsten Abschnitt erläutert.

4.3 Beherrschung der Unternehmenskomplexität durch ein PDMS Neben der entsprechenden Ausprägung der Produkte ist das Ziel einer PLM-Strategie die Steuerung der D&I-Flüsse über den gesamten Produktlebenszyklus. Die damit verbundenen Produkt-, Prozess- und Organisationsdaten werden durch ein Produktdatenmanagement-System (PDMS)

4.3

Beherrschung der Unternehmenskomplexität durch ein PDMS

75

gesteuert, abgelegt und bereitgestellt [Schöttner 1999; Vajna 2000; Eigner u. Stelzer 2001; Niemann 2003; Saaksvuori u. Immonen 2004]. Ein PDMS unterstützt die Umsetzung von PLM auf operativer Ebene. Ein Produktdatenmanagement-System (PDMS) ist ein rechnerunterstütztes Datenbank- und Kommunikationssystem zur Speicherung, Verwaltung und Bereitstellung aller produktbeschreibenden Daten während des gesamten Produktlebenszyklus [Feldhusen et al. 2005a, in Anlehnung an die VDI-Richtlinie 2219]. Die Unterstützung des Produktentwicklungsprozesses durch den Einsatz eines PDMS gründet sich auf den Funktionsumfang, welchen das System den Anwendern bereitstellt. Deshalb werden nachfolgend neben der prinzipiellen Systemarchitektur auch die grundlegenden Systemfunktionalitäten erläutert, sofern sie für die Ermittlung der PDMS-Fähigkeit bedeutsam sind. Beide Aspekte müssen berücksichtigt werden, da bestimmte Voraussetzungen innerhalb des Unternehmens für einen effizienten Systemeinsatz vorhanden sein müssen. Zusätzlich lassen sich aus der Systemarchitektur und den Systemfunktionalitäten wesentliche Kriterien bei der Bewertung der Unternehmenseignung für den PDMS-Einsatz ableiten. 4.3.1 Grundlegende PDM-Systemarchitektur Prinzipiell können mit einem PDMS sämtliche, in elektronischer Form vorliegenden Daten und Objekte verwaltet werden. Dies gilt unabhängig von ihrem Datenformat und von ihrer erzeugenden systemtechnischen Quelle [Wehlitz 2000]. Aufgrund ihres gemeinsamen Entwicklungsursprungs aus den Dokumenten-Managementsystemen (DMS) der zugehörigen 3D-CAD-Systeme unterscheidet sich die Architektur heutiger PDMS nur wenig [Schöttner 1999; Eigner u. Stelzer 2001; Saaksvuori u. Immonen 2004; Stark 2006; VDI 2219]. Sie ist in Abb. 4-11 dargestellt und repräsentiert den grundlegenden Aufbau. Vertiefende Informationen über generell mögliche Softwarearchitekturen finden sich bspw. in [Gulbins et al. 2002; Müller 2005]. Grundlage eines PDMS sind Datenbanken, die über ein Datenbankmanagementsystem (DBMS) verwaltet werden. Das PDMS unterscheidet zwischen Metadaten und den eigentlichen physikalischen Datenobjekten, die in Dateiarchiven, sog. Vaults, gespeichert sind. Die physikalischen Datenobjekte werden über Metadaten beschrieben und referenziert. Beide werden in einer eigenen Datenbank gespeichert. Über sie gelangt die Kopie eines Datenobjekts über einen Auscheckvorgang auf die Festplatte des je-

76

4 Umsetzung von PLM

weiligen Anwenders. Dieser kann, abhängig von seiner Berechtigung in der jeweiligen Produktlebenszyklusphase, als einziger Anwender das Datenobjekt entsprechend manipulieren. Alle anderen Anwender haben in diesem Augenblick nur lesenden Zugriff auf den letzten Objektstand innerhalb des Vaults. Sind die Tätigkeiten an dem Datenobjekt abgeschlossen, gelangt das manipulierte Objekt per Eincheckvorgang zurück in den Vault. Dabei wird vom System automatisch ein aktueller Stand des Datenobjekts angelegt, sofern der Anwender nicht eine andere Anweisung gegeben hat.

Abb. 4-11 Prinzipielle Systemarchitektur von PDMS [in Anlehnung an die VDIRichtlinie 2219]

4.3

Beherrschung der Unternehmenskomplexität durch ein PDMS

77

Über die grafische Benutzeroberfläche kann von jedem berechtigten Benutzer auch auf komplexere oder umfangreichere Objekte zugegriffen werden. Da sich bei den heutigen PDMS in der Regel eine browserbasierte Web-Technologie durchgesetzt hat, können diese Objekte auch bei räumlich verteilten Organisationsstrukturen und unterschiedlichen Systemplattformen zur Verfügung gestellt werden. Alle PDMS besitzen notwendige Systemschnittstellen zur gängigen eingesetzten Applikationssoftware wie Enterprise Ressource Planning-Systeme (ERP-Systeme) oder Manufacturing Execution Systeme (MES). Wird ein entsprechendes Datenobjekt an ein anderes IT-System übergeben, so besteht das gesamte Datenpaket nicht nur aus dem eigentlichen Datenobjekt (bspw. einem CAD-Modell), sondern auch aus den beschreibenden Metadaten und entsprechenden Transportdaten. Die Transportdaten unterstützen den Datenaustausch zwischen den einzelnen IT-Systemen. 4.3.2 Grundlegende PDM-Systemfunktionalitäten Die in einem PDMS vorhandenen Funktionen zur Unterstützung aller beim Produktentwicklungsprozess anfallenden Tätigkeiten lassen sich in drei Gruppen einteilen [Pusch 2003]. Es handelt sich um: x anwendungsbezogene Funktionen, x anwendungs- bzw. systemübergreifende Funktionen und x sonstige Funktionen. Anwendungsbezogene Funktionen unterstützen das applikationsspezifische Daten- und Informationsmanagement wie die Zeichnungs- oder Stücklistenverwaltung. Applikationsspezifisch bedeutet in diesem Zusammenhang die Erweiterung der Objektverwaltungsfunktionen, um spezifische Anforderungen des Technischen Bereichs abbilden zu können. Dies betrifft bspw. die Möglichkeit, Produktkonfigurationen mit dem System zu verwalten [Wehlitz 2000; Gulbins et al. 2002]. Weitere anwendungsbezogene Funktionsmodule beziehen sich auf: x Produktdaten- und Dokumentenmanagement zum Anlegen und Verwalten von Stammdaten; x Produktstruktur- und Konfigurationsmanagement für die Verwaltung von Strukturdaten bzw. Stücklisten; x Klassifizierung und Teilefamilienmanagement einschließlich der Nummernvergabe und Suchfunktionalitäten. Hierzu zählt auch das Definieren von Abhängigkeiten zwischen unterschiedlichen Objekttypen, das Setzen von Gültigkeiten, die Vergabe von Attributen, die Zusammenfas-

78

4 Umsetzung von PLM

sung von Objekten zu Gruppen oder Merkmalsklassen zur Beschleunigung der Suchfunktionalitäten; x Prozess- und Workflowmanagement einschließlich der Werkzeuge zur interaktiven grafischen Beschreibung von Prozessabläufen. Besonderer Schwerpunkt liegt auf dem Freigabe- und Änderungsmanagement, wobei die Möglichkeit der Objektstatusvergabe in Abhängigkeit der Lebenszyklusphase besteht; x Benutzermanagement für die Zuweisung einer eindeutigen Tätigkeitsverantwortung zu bestimmten Rollen in Abhängigkeit des zugehörigen Kontexts und der zugehörigen lebenszyklusabhängigen Berechtigungen; x Projektdatenmanagement: dazu gehören die Verwaltung der Informationsbearbeitung wie das Arbeitsmanagement über Versionen, die Steuerung des Informationsflusses zwischen den prozessbeteiligten Mitarbeitern mittels Workflowmanagement und die Verfolgung aller Ereignisse und Änderungen während der Prozessabwicklung durch eine Arbeitsprotokollverwaltung bzw. Iterationen [Eigner u. Stelzer 2001]. Das Projektmanagement wird oftmals durch ein ERP-System oder spezifische Projektapplikationen gesteuert [Hartmann u. Schmidt 2004]. Anwendungsübergreifende Funktionsbausteine stellen im Rahmen der vorhandenen IT-Infrastruktur systemübergreifende Möglichkeiten für das Datenmanagement bereit [VDI 2219]. Dies beinhaltet Funktionen für die Archivierung, Steuerung von Ein- und Ausgabegeräten, die Objektvisualisierung innerhalb unterschiedlicher Applikationsumgebungen oder allgemeine Kommunikationsmöglichkeiten wie projektspezifische Nutzerforen [Schöttner 1999; Wehlitz 2000; Eigner u. Stelzer 2001; Gulbins et al. 2002]. Oftmals stellen PDMS weitere Systemfunktionen zur Unterstützung der System- bzw. Business-Administration, Customizingfunktionen und zugehörige Schnittstellenmöglichkeiten für die Anbindung vorhandener ITSysteme bereit [Schöttner 1999; Eigner u. Stelzer 2001; Saaksvuori u. Immonen 2004; Stark 2006]. 4.3.3 PDM-Systemanforderungen Damit ein PDMS effizient eingesetzt werden kann, müssen bestimmte Systemanforderungen im Bereich der vorhandenen Hardware und der benötigten Software erfüllt sein. Sie leiten sich aus der vorgestellten Systemarchitektur ab und gewährleisten die Steuerung der D&I-Flüsse mittels der Systemfunktionalitäten. Die notwendigen Systemanforderungen umfassen hauptsächlich

4.4

Unternehmensanforderungen an eine PDMS-Einführung

79

x vorhandene, möglichst standardisierte Systemschnittstellen zur Einbettung in die vorhandene IT-Landschaft des Unternehmens; x ausreichend dimensionierte Server und Speichermedien; x eine ausreichend dimensionierte Server-Client-Architektur einschließlich der zugehörigen Datenleitungen mit entsprechendem Datendurchsatz; x ein vorhandenes stabiles und robustes Multitasking-Betriebssystem; x die Fähigkeit, ein vorhandenes und geeignetes Produktdatenmodell, Prozessmodell und Rollenmodell abbilden zu können. Die Analyse dieser Anforderungen im Unternehmen erfolgt vor der eigentlichen Systemimplementierung. Bei einer ungenügenden Eignung der vorhandenen IT-Struktur kann der notwendige Handlungsbedarf zur Strukturverbesserung gezielt hergeleitet werden. Dies bildet eine hinreichende Einflussgröße bei der Bewertung der Unternehmenseignung.

4.4 Unternehmensanforderungen an eine PDMSEinführung Viele Einführungen wurden aufgrund mangelnder Unternehmenserfahrungen oder unerfüllter Unternehmenserwartungen abgebrochen [McAffee 2003]. Einige typische Erwartungen sind in Abb. 4-12 dargestellt. Aus ihnen lassen sich relevante Anforderungen ableiten, die ein methodischer Ansatz zur Abschätzung der PDMS-Einführungseignung erfüllen muss. Die Erwartungshaltung in mittelständischen Unternehmen ist vor einer PDMS-Einführung durch folgende Punkte charakterisiert [McAffee 2003; Schoen 2005; Feldhusen u. Gebhardt 2005c; Feldhusen et al. 2006b]: x Oftmals bestehen unklare Vorstellungen darüber, auf welche Weise das PDM-System im Unternehmen sinnvoll eingesetzt werden kann. Entsprechend unscharf sind die Ziele definiert, die mit einer Einführung erreicht werden sollen. Daraus resultiert eine generelle Unsicherheit sowohl im Management als auch bei den Mitarbeitern. x Obwohl bei einer Systemeinführung intuitiv eine Vorgehensweise angenommen wird, gibt es Unsicherheiten bei der konkreten Einführung des PDMS. Dies betrifft bspw. notwendige Tätigkeiten, die Zeitpunkte ihrer Ausführung, die zugehörigen Verantwortlichkeiten und die Qualität des erwarteten Ergebnisses. Diese Unsicherheit verstärkt sich bei der Anwesenheit externer (System-)Berater, deren Maßnahmen häufig als zu allgemein für die spezielle Unternehmenskomplexität angesehen werden.

80

x

x

x

x

4 Umsetzung von PLM

Das Unternehmen befürchtet einen Verständnis- und Kontrollverlust innerhalb der Systemeinführung für seine individuellen Problemstellungen. Oftmals sind sich Unternehmen nicht bewusst, ob sie für eine derartige Einführung bereits entsprechend vorbereitet sind. Es fehlt eine neutrale Bewertungsmöglichkeit. Sie soll die Unternehmenseignung für die PDMS-Einführung bewerten und notwendige Verbesserungsmaßnahmen gezielt einleiten. Aufgrund der mit der Systemeinführung verbundenen hohen Kosten wird eher das Projektrisiko als der zu erwartende Nutzen gesehen. Eine Kontrolle mit dem Zweck einer Risikobegrenzung bei der Systemeinführung empfinden Unternehmen als scheinbar nicht möglich. Häufig wird bis zu einem bestimmten Einführungszeitpunkt keine Entscheidung darüber getroffen, ob ein PDMS eines externen Systemanbieters angeschafft oder die vorhandene EDV durch zusätzlichen Programmierungsaufwand erweitert werden soll. Die Systemeinführung soll möglichst effektiv und effizient mit einem Minimum an benötigten Ressourcen geplant und durchgeführt werden.

Abb. 4-12 Typische Unternehmenserwartungen und die abgeleitete intuitive Vorgehensweise bei einer PDMS-Einführung in mittelständischen Unternehmen

Aus den beschriebenen Erwartungen ergeben sich für mittelständische Unternehmen spezifische Fragestellungen. Sie bilden die Grundlage für einen Anforderungskatalog, die eine pragmatische Vorgehensweise zur PDMSEinführung erfüllen muss. Die einzelnen Anforderungen sind in Abb. 4-13

4.4

Unternehmensanforderungen an eine PDMS-Einführung

81

gezeigt und werden nachfolgend kurz erläutert. Sie alle besitzen den gemeinsamen Anspruch, die spezifischen Belange mittelständischer Unternehmen zu berücksichtigen.

Abb. 4-13 Spezifische Fragestellungen in mittelständischen Unternehmen und abgeleitete Anforderungen, die eine Vorgehensweise zur PDMS-Einführung erfüllen muss

Das PDMS soll sämtliche (Teil-)Prozesse durch organisations- und prozessübergreifende Datenzentralisation steuern, die dem übergeordneten Produktentwicklungsprozess (PEP) zugeordnet sind. Insbesondere wegen des komplexen Umsetzungsaufwands für die Verwirklichung, Änderung und Anpassung der vorhandenen Produkte fällt es Unternehmen schwer, PLM durch die Einführung eines PDMS zu realisieren. Diese Aussage gilt ebenfalls für die Aufbau- und Ablauforganisation. Weitere Faktoren sind die damit einhergehenden beträchtlichen Kosten sowie die teilweise tief greifenden Auswirkungen durch die Systemeinführung im Unternehmen selbst. Das Scheitern eines derartigen Umsetzungsprojekts kann sich für ein mittelständisches Unternehmen existenzbedrohend auswirken. Folglich wird eine methodische Vorgehensweise für die PDMS-Einführung benötigt. Sie bildet einerseits die Grundlage für eine (zunächst) PDMsystemneutrale Einführungsplanung, andererseits stellt sie konkrete Handlungsanweisungen für die Systemeinführung zur Verfügung. Dies beinhaltet auch eine bewusste Selbstreflexion des Unternehmens mit einer an-

82

4 Umsetzung von PLM

schließenden expliziten Zieldefinition auf strategischer und operativer Ebene. Da es sich bei einer solchen Einführung um ein ressourcenintensives Vorhaben handelt, wird auch eine Abschätzung hinsichtlich Kosten, Nutzen und Risiken gewünscht. Folglich wird ein Bewertungshilfsmittel benötigt. Es soll sowohl vor als auch während der Systemeinführung eine Aussage über den Grad der augenblicklichen Unternehmenseignung erlauben. Durch die Bewertung sollen vorhandene Problemfelder identifiziert und durch entsprechende Verbesserungsmaßnahmen gezielt eliminiert werden. Damit können die Risiken kontrolliert und der Nutzen gewährleistet werden. Aus den beschriebenen Zusammenhängen können fünf konkrete Anforderungsdimensionen abgeleitet werden: x eine explizite Berücksichtigung strategischer und operativer Unternehmensziele, die durch die Systemeinführung erreicht werden sollen; x eine systemneutrale und methodische Vorgehensweise mit konkreten Handlungsanweisungen für das Unternehmen in jeder Projektphase; x ein Bewertungsvorgehen der augenblicklichen PDMS-Fähigkeit als vorbereitender Bestandteil der Projektplanung vor der eigentlichen Systemeinführung; x die Ableitung und Umsetzung von Verbesserungsmaßnahmen zur gezielten Erhöhung der PDMS-Fähigkeit; x ein zielgerichtetes, projektbegleitendes Controlling während der gesamten PDMS-Projektdauer. Idealerweise umfasst die Vorgehensweise zur Systemeinführung sowie die Bewertung der Unternehmenseignung auch die Betriebsphase eines PDMS. Aktuell werden Abschätzungen zur Systemeinführung ausschließlich über betriebswirtschaftliche Prognosehilfsmittel gewonnen. Deren Ergebnisse können jedoch nur tendenziellen Charakter besitzen, da sie nicht die notwendigen Kriterien zur Bewertung der Unternehmenseignung bereitstellen. Zusätzlich betrachten sie die Systemeinführung ausschließlich unter finanziellen Aspekten [Abramovici u. Schulte 2004; Schoen 2005; VDI 2219]. Ihre Grundlage bilden idealisierte Voraussetzungen, die von den meisten Unternehmen nicht erfüllt werden. Die Frage, ob und wie weit ein Unternehmen für den Einsatz eines PDMS in Bezug auf seine Ablauf- und Aufbauorganisation bereits vorbereitet ist, wird nicht gestellt. Damit werden konsequenterweise auch diejenigen Kosten nicht berücksichtigt, die das

4.5

Zusammenhänge im Bereich „PDMS-Fähigkeit“

83

Unternehmen für seine PDMS-Fähigkeit aufwenden muss, so dass die Systemeinführung zum gewünschten Erfolg führt.

4.5 Zusammenhänge im Bereich „PDMS-Fähigkeit“ Wie in Abschn. 4.4 dargelegt wurde, besteht in mittelständischen Unternehmen Unsicherheit bei ihrer Selbsteinschätzung hinsichtlich der Einführung eines Produktdatenmanagement-Systems. Deshalb werden Kriterien benötigt, aus denen sich Aussagen ableiten lassen, welche Unternehmensvoraussetzungen bereits hinreichend erfüllt sind und welche gezielt verbessert bzw. geschaffen werden müssen. Diese Kriterien sind die PDMSFähigkeit und der PDMS-Reifegrad, die nachfolgend erläutert werden. Anschließend werden diejenigen Einflussgrößen identifiziert, die die PDMSFähigkeit eines Unternehmens beschreiben. Die Systemeinführung selbst wird als PDMS-Projekt bezeichnet. Definition des PDMS-Projekts Die Umsetzung der in den vorherigen Abschnitten beschriebenen Zusammenhänge erfolgt über ein strukturiertes Vorgehen mit dem Ziel, ein PDMS erfolgreich im Unternehmen einzuführen. Dieses Vorgehen wird als PDMS-Projekt bezeichnet und ist wie folgt definiert [Gebhardt 2007]: Unter einem PDMS-Projekt wird die zielgerichtete Vorbereitung, Durchführung und der Abschluss sämtlicher Tätigkeiten zur Ermittlung der PDMS-Fähigkeit und der Einführung eines PDMS verstanden. Inhaltsschwerpunkte des PDMS-Projekts sind eine methodische Vorgehensweise, eine Bewertung der PDMS-Fähigkeit sowie ein permanentes Controlling in Bezug auf die Einhaltung der definierten Projektziele (Zielerfüllungsgrad) und der Projektressourcen. Mit dem eingeführten Pilotsystem ist das PDMS-Projekt beendet. Danach beginnt die Betriebsphase. Definition der PDMS-Fähigkeit und des PDMS-Reifegrads In den bisherigen Ausführungen wurde deutlich, dass mittelständische Unternehmen eine Aussage hinsichtlich ihrer augenblicklichen Eignung für den schnellen und zielgerichteten Einsatz eines PDMS wünschen. Damit soll einerseits die Entscheidung für die Einführung eines solchen kostenintensiven Systems unterstützt, andererseits die Planungssicherheit gewähr-

84

4 Umsetzung von PLM

leistet werden. Die augenblickliche Unternehmenseignung für den Systemeinsatz wird als PDMS-Fähigkeit bezeichnet [Feldhusen u. Gebhardt 2005b]: Der Begriff „PDMS-Fähigkeit“ beschreibt die Fähigkeit eines Unternehmens, zu einem bestimmten Zeitpunkt ein PDMS effektiv und effizient in Übereinstimmung mit zuvor definierten Unternehmenszielen einzusetzen. Die PDMS-Fähigkeit kann sowohl als Prognose- als auch als Messinstrument genutzt werden. Durch ihre Ermittlung sollen bereits im Vorfeld eines PDMS-Projekts Maßnahmen für die Effizienzsteigerung des PDMSEinsatzes identifiziert und umgesetzt werden. Damit besitzt sie aufgrund ihrer prognostizierenden Zielorientierung den Charakter eines Frühindikators. Es geschieht ebenfalls eine rückwirkende Bewertung der Unternehmenseignung vor und nach der Maßnahmenumsetzung aufgrund festgelegter Zielsetzungen. Damit erfüllt die PDMS-Fähigkeit auch die Anforderungen eines Spätindikators. Die PDMS-Fähigkeit stellt somit eine veränderliche Bewertungsgröße dar. In Abhängigkeit des Bewertungszeitpunkts ist es möglich, die Änderungen in der Unternehmenseignung aufgrund der durchgeführten Maßnahmen zu messen. Die IST-PDMS-Fähigkeit beschreibt den Grad der augenblicklichen Unternehmenseignung vor einer Systemeinführung. Der nach Abschluss der Systemeinführung gemessene Eignungsgrad wird als SOLLPDMS-Fähigkeit bezeichnet. Idealerweise entsprechen sich zu diesem Bewertungszeitpunkt beide PDMS-Fähigkeiten. Falls die SOLL-PDMSFähigkeit jedoch die Unternehmenserwartungen nicht erfüllt, müssen die durchgeführten Maßnahmen spezifiziert werden (siehe Abschn. 7.9). Aus der ermittelten IST-PDMS-Fähigkeit lässt sich der zu erwartende Gesamtaufwand bei der Umsetzung eines PDMS-Projekts bzw. bei der Einführung eines PDMS abschätzen. Die Aufwandsabschätzung selbst wird durch einen Indikator, den PDMS-Reifegrad, beschrieben [Gebhardt 2007]: Der PDMS-Reifegrad stellt den Indikator des Bewertungsergebnisses der PDMS-Fähigkeit in Form einer Klassifizierung dar. Der PDMS-Reifegrad ordnet die ermittelte PDMS-Fähigkeit in vier abgestufte Reifegrade ein. Sie sind an das deutsche Schulnotensystem von „sehr gut“ bis „ausreichend“ angelehnt und in Tabelle 4-1 dargestellt. Der Übergang zwischen den einzelnen Reifegraden ist fließend. Diese einfache

4.5

Zusammenhänge im Bereich „PDMS-Fähigkeit“

85

Darstellungsform besitzt den Vorteil einer leichten und eindeutigen Verständlichkeit für alle PDMS-Projektbeteiligten. Tabelle 4-1 Klassifizierung des PDMS-Reifegrads in Anlehnung an die deutsche Schulnotensystematik Reifegrad

zugehörige PDMS-Fähigkeit

geschätzter Umfang an Verbesserungsaktivitäten

Reifegrad 1

Unternehmen ist uneingeschränkt PDMS-fähig

keine Verbesserungsaktivitäten erforderlich

Reifegrad 2

Unternehmen ist PDMS-fähig mit leichten Einschränkungen

wenig Verbesserungsaktivitäten erforderlich

Reifegrad 3

Unternehmen ist PDMS-fähig mit erheblichen Einschränkungen

umfangreiche Verbesserungsaktivitäten erforderlich

Reifegrad 4

Unternehmen ist nicht PDMSfähig

erhebliche Verbesserungsaktivitäten erforderlich

Der PDMS-Reifegrad setzt sich aus einzelnen Perspektiven-Reifegraden zusammen. Sie beschreiben die PDMS-Fähigkeit einzelner Unternehmensperspektiven wie bspw. die Betrachtung der augenblicklichen PDMSEignung von spezifischen Prozessen oder Produkten. Dadurch werden Fragen beantwortet wie „Ist mein Produkt in seiner augenblicklichen Struktur PDMS-gerecht?“ oder „Besitzen meine Prozesse eine ausreichende Qualität zur Implementierung in ein PDMS?“. Die einzelnen Unternehmensperspektiven ergeben sich aus den Einflussgrößen der PDMSFähigkeit. Die Einflussgrößen werden im nachfolgenden Abschnitt behandelt. Der PDMS-Reifegrad beschreibt den geschätzten Umfang der Verbesserungsaktivitäten. Er dokumentiert den jeweiligen IST-Zustand aller Perspektiven des Unternehmens. Anhand des PDMS-Reifegrads können die eingeleiteten Maßnahmen überprüft und ihre Wirkung festgestellt werden. Der PDMS-Reifegrad stellt somit ebenfalls eine veränderliche Größe dar. Damit bekommt er den Charakter einer Qualitätskennzahl als Grundlage eines Kontinuierlichen Verbesserungsprozesses (KVP). Somit kann er als Ergänzung zu den traditionellen betriebswirtschaftlichen Bewertungskennzahlen wie den Return of Investment (RoI) o. ä. angesehen werden. Die PDMS-Fähigkeit sowie der PDMS-Reifegrad treffen eine Aussage darüber, wie geeignet die vorhandene Aufbau- und Ablauforganisation einschließlich der Produktstrukturen für den augenblicklichen PDMS-

86

4 Umsetzung von PLM

Einsatz ist. Ihre Ermittlung führt zwangsläufig zu der Frage, welche Voraussetzungen im Unternehmen gegeben sein müssen, damit sich die Nutzung eines PDMS als zufrieden stellend erweist. Diese Voraussetzungen lassen sich durch spezifische Einflussgrößen beschreiben. Sie werden im nächsten Abschnitt vorgestellt. Einflussgrößen der PDMS-Fähigkeit Die PDMS-Fähigkeit trifft eine Aussage über die augenblickliche Unternehmenseignung für eine PDMS-Einführung. Die nachfolgende Aufzählung beinhaltet wesentliche Anforderungen, welche die dazu benötigten Voraussetzungen beschreiben: x die bestehende Unternehmenskomplexität und ihre Auswirkungen auf die Produkte sowie die Ablauf- und Aufbauorganisation des Unternehmens; x die sich daraus ergebenden strategischen und operativen Zielsetzungen mit dem Hauptziel, die vorhandenen Daten- und Informationsflüsse zu beherrschen; x die Erfüllung benötigter PDM-Systemanforderungen; x die Funktionalitäten, die das PDM-System zur Unterstützung der Zielsetzungen zur Verfügung stellt; x die (Modell-)Eignung vorhandener Daten und Informationen, welche die Ablauf- und Aufbauorganisation sowie die Produkte beschreiben. Aus diesen Anforderungen können Einflussgrößen zur Beschreibung der PDMS-Fähigkeit abgeleitet werden. Sie sind in Abb. 4-14 dargestellt und werden als PDMS-Einflussgrößen bezeichnet. Es handelt sich dabei um die PDMS-Einflussgrößen x formulierte strategische Ziele, wie bspw. ein schnelleres „Time-tomarket“ oder eine standortübergreifende Vereinheitlichung des PEP (siehe Kapitel 2); x daraus abgeleitete operative (Umsetzungs-)Ziele wie bspw. eine höhere Standardisierung der Produkte oder der Prozesse (siehe Kapitel 3); x Anforderungen des PDMS an die IT-Infrastruktur des Unternehmens sowie Funktionalitäten, die das PDMS standardmäßig, d. h. ohne zusätzlichen Anpassungsaufwand, zur Verfügung stellt (siehe Abschn. 4.3); x Anforderungen an die Produkte, die Prozesse und die Organisation sowie ihrer Modelle bezüglich ihrer augenblicklichen Systemumsetzungsfähigkeit (siehe Abschn. 4.2). Dies betrifft bspw. eine eindeutige Referenzierung der Produktdaten oder vollständig definierte Prozessabläufe.

4.6

Zusammenfassung Kapitel 4

87

Die PDMS-Einflussgrößen bilden die Grundlage für eine unternehmensindividuelle Bewertung der PDMS-Fähigkeit.

Abb. 4-14 Charakteristische Einflussgrößen zur Beschreibung der unternehmensindividuellen PDMS-Fähigkeit

Die PDMS-Einflussgrößen besitzen eine hohe Ähnlichkeit zu Kriterien, wie sie für Zertifizierungsmaßnahmen aus dem Bereich Qualitätsmanagement (QM) benötigt werden. Daraus ergibt sich die Möglichkeit, vorhandene Ergebnisse aus dem QM für die Bewertung der PDMS-Fähigkeit zu nutzen. Ebenso kann die Ergebnisermittlung aufgrund identifizierter PDMS-Einflussgrößen qualitätsverbessernde Maßnahmen nach sich ziehen. Dieser Synergieeffekt verringert für das Unternehmen den Ermittlungsaufwand innerhalb des PDMS-Projekts [Scheer 2001; Arnold et al. 2005; Feldhusen et al. 2005d]. Die PDMS-Fähigkeit und die PDMS-Einflussgrößen stellen Eingangsgrößen für eine Wirtschaftlichkeitsberechnung dar. Damit wird eine bewertbare Ausgangssituation geschaffen, auf welcher die Wirtschaftlichkeitsrechnung aufbauen kann.

4.6 Zusammenfassung Kapitel 4 In diesem Kapitel wurden einleitend die Potenziale der PLM-Strategie beschrieben. Als wichtigste Zielsetzung wurde dabei die Beherrschung der Daten- und Informationsflüsse (D&I-Flüsse) identifiziert: Nur dadurch

88

4 Umsetzung von PLM

wird sichergestellt, dass sämtliche benötigte Daten zur richtigen Zeit am richtigen Ort den richtigen Mitabeitern verfügbar sind. Dies bildet die Voraussetzung für eine effektive und effiziente Durchführung von bspw. Entwicklungstätigkeiten entlang des Produktentwicklungsprozesses. Die D&I-Flüsse bestehen aus Produktdaten, Prozessdaten und Rollen. Sie können durch Produktdaten-, Prozess- und Rollenmodelle dargestellt werden. Die Modelle bilden in ihrer Gesamtheit die inhaltliche Grundlage zur Nutzung eines Produktdatenmanagement-Systems (PDMS). Dabei bestimmt die Modellqualität unter Berücksichtigung der strategischen Unternehmensziele unmittelbar den Nutzen, der durch den Einsatz eines PDMS erwartet wird. Auf dieser Grundlage werden Unternehmensbedürfnisse hinsichtlich der Einführung und des laufenden Betriebs eines PDMS identifiziert. Sie können durch fünf PDMS-Einflussgrößen beschrieben werden, wobei in diesem Zusammenhang der Begriff der PDMS-Fähigkeit besonders bedeutsam ist. Diese kennzeichnet die augenblickliche Unternehmenseignung, ein PDMS zielgerichtet in Übereinstimmung mit den gewünschten Unternehmenserwartungen einzusetzen. Die Verbesserung der PDMS-Fähigkeit beinhaltet v. a. Maßnahmen zur x Überarbeitung der Produktstruktur, x vollständigen Beschreibung der Prozessabläufe und x eindeutigen Definition der Aufbauorganisation in Form von Rollen. Die in diesem Kapitel beschriebenen Zusammenhänge bilden die Grundlage für eine unternehmensindividuelle Bewertung der PDMS-Fähigkeit. Der zugehörige Lösungsansatz wird im fünften Kapitel vorgestellt. Literatur Abramovici M, Schulte S (2004) PLM - logische Fortsetzung der PDM-Ansätze oder Neuauflage des CIM-Debakels? In: I2P (Tagungsband), VDI-Berichte 1819. VDI-Verlag, Düsseldorf Arnold V, Dettmering H, Engel T, Karcher A (2005) Product Lifecycle Management beherrschen. Springer, Berlin-Heidelberg-New York Champy J (2002) X-Engineering The Corporation - Reinventing Your Business in The Digital Age. Warner Business Books, New York Ehrlenspiel K (2006) Integrierte Produktentwicklung - Denkabläufe, Methodeneinsatz, Zusammenarbeit, 3. Auflage. Hanser, München-Wien Eigner M, Stelzer R (2001) Produktdatenmanagement-Systeme - ein Leitfaden für Product Development und Life Cycle Management. Springer, BerlinHeidelberg-New York

4.6

Zusammenfassung Kapitel 4

89

ElMaraghy HA (2007) Reconfigurable Process Plans for Responsive Manufacturing Systems. In: Digital Enterprise Technology, Springer, Berlin-HeidelbergNew York Feldhusen J, Gebhardt B (2005a) Methodik zur Vorbereitung einer PDMSEinführung in KMU’s mit hoher Produktvarianz. In: Product Lifecycle Management – mit System zum Erfolg. WZLforum an der RWTH Aachen Feldhusen J, Gebhardt B (2005b) Ein Beitrag zur Bewertung der PDMS-Fähigkeit eines Unternehmens - die Capability Scorecard. In: Informations- und Wissensdrehscheibe Produktdatenmanagement. GITO, Berlin Feldhusen J, Gebhardt B (2005c) Der Weg zum individuellen Produkt – Redefintion eines Variantenerzeugungsprozesses in der Praxis. In: 3. Gemeinsames Kolloquium Konstruktionstechnik (Tagungsband). Shaker, Aachen Feldhusen J, Gebhardt B, Macke N, Nurcahya E, Bungert F (2005d) Development of A Set of Methods To Support The Implementation of A PDMS for SME’s with A High Product Variance. In: Proceedings of CIRP, 12th Seminar on Life Cycle Engineering. Springer, Dordrecht NL Feldhusen J, Gebhardt B, Macke N, Nurcahya E (2006a) Development of An Enterprise-individual Role Model for Increase of Process Efficiency within A PLM-strategy. In: Tools And Methods of Competitive Engineering. University of Technology, Delft Feldhusen J, Gebhardt B, Nurcahya E, Bungert F (2006b) Development of A Performance Measurement System for A SME’s PDMS-capability. In: Tools And Methods of Competitive Engineering. University of Technology, Delft Gebhardt B (2007) Abschätzung der Produktdatenmanagement-Systemfähigkeit produzierender Unternehmen. Shaker, Aachen Gulbins J, Seyfried M, Strack-Zimmermann H (2002) Dokumentenmanagement, 5. Auflage. Springer, Berlin-Heidelberg-New York Hartmann G, Schmidt U (2004) my SAP® Product Lifecycle Management, 2. Auflage. Bonn, Galileo Press Holsapple CW (2003) Handbook on Knowledge Management Vol. 1 - Knowledge Matters. Springer, Berlin-Heidelberg-New York ISO 10303-11 (1992) The EXPRESS Language Reference Language Manual, Product Data Representation and Exchange - Part 11. Beuth, Berlin-WienZürich McAffee A (2003) When Too Much IT-Knowledge Is A Dangerous Thing. In: MIT Sloan Management Review Winter, Vol. 44 No. 2. Massachusetts, MIT School of Sloan Management Mertins K, Heisig P, Vorbeck J (2003) Knowledge Management - Concepts and Best Practices. Springer, Berlin-Heidelberg-New York Müller J (2005) Workflow-based Integration. Springer, Berlin-Heidelberg-New York Niemann J (2003) Management des Produktlebenslaufs. In: Neue Organisationsformen im Unternehmen, 2. Auflage. Springer, Berlin-Heidelberg-New York Pahl G, Beitz W, Feldhusen J, Grote KH (2007) Konstruktionslehre - Grundlagen erfolgreicher Produktentwicklung, 7. Auflage. Springer, Berlin-HeidelbergNew York

90

4 Umsetzung von PLM

Pusch R (2003) Personalplanung und -entwicklung in einem integrierten Vorgehensmodell zur Einführung von Produktdatenmanagementsystemen. Dissertation, Universität Paderborn Saaksvuori A, Immonen A (2004) Product Lifecycle Management, 2nd edition. Springer, Berlin-Heidelberg-New York Scheer AW, Boczanski M, Muth M, Schmitz WG, Segelbacher U (2006) Prozessorientiertes Product Lifecycle Management. Springer, Berlin-Heidelberg-New York Schoen R (2005) PLM-Einführung mit Erfolg - Risiken & Wirtschaftlichkeitsaspekte. In: Product Lifecycle Management - mit System zum Erfolg. Seminar am WZLforum der RWTH Aachen am 25.01.2005 Schöttner J (1999) Produktdatenmanagement in der Fertigungsindustrie - Prinzip, Konzepte, Strategie. Hanser, München-Wien Stark J (2006) Product Lifecycle Management - 21st Century Product Paradigm for Product Realisation, 3rd edition. Springer, London Vajna S (2000) Die neue Richtlinie VDI 2219. In: Konstruktion 3-2000. SpringerVDI, Düsseldorf Wehlitz P (2000) Nutzenorientierte Einführung eines ProduktdatenmanagementSystems. Dissertation, Technische Universität München VDI-Richtlinie 2219 Informationsverarbeitung in der Produktentwicklung - Einführung und Wirtschaftlichkeit von EDM/PDM-Systemen. Beuth, BerlinWien-Zürich

5 Der PDMS-Regelkreis

Im vorherigen Kapitel wurden Anforderungen identifiziert, welche insbesondere mittelständische Unternehmen an eine PDM-Systemeinführung stellen. Als wichtigste Anforderungen gelten eine pragmatische Vorgehensweise bei der Systemeinführung und ein ständiges, zielgerichtetes Controlling der PDMS-Fähigkeit. Der in diesem Kapitel beschriebene Lösungsansatz berücksichtigt diese Anforderungen. Er beinhaltet sowohl eine Vorgehensweise zur Systemeinführung als auch eine Vorgehensweise zur Bewertung der PDMSFähigkeit. Beide Vorgehensweisen beeinflussen sich gegenseitig. Aufgrund dieses rekursiven, regelkreisartigen Verhaltens wird die Vorgehensweise als PDMS-Regelkreis bezeichnet. Zunächst wird der Grundgedanke des PDMS-Regelkreises behandelt. Anschließend werden die beiden Vorgehensweisen bis hin zu ihren einzelnen Arbeitsschritten erläutert. Einführend werden grundsätzliche Problemstellungen bei der Anwendung bestehender Einführungsmethoden beschrieben. Die Vermeidung der beschriebenen Probleme wird durch den PDMS-Regelkreis ebenfalls gewährleistet.

5.1 Nachteile vorhandener PDMS-Einführungsmethoden Obwohl in der Literatur eine Vielzahl von Methoden zur PDMSystemeinführung beschrieben wird, herrscht in Unternehmen eine hohe Abbruchquote bei PDMS-Projekten [McAffee 2003]. Eine mögliche Ursache liegt darin, dass Einführungsmethoden oftmals im Rahmen von Systemeinführungen bei Großunternehmen aus der Automobilindustrie oder dem Bereich der Luft- und Raumfahrt entstanden [Schöttner 1999]. In diesen Projekten war vorrangig die Frage nach Systemfunktionalitäten relevant; die Unternehmenseignung besaß eine untergeordnete Bedeutung. Obwohl in den letzten Jahren die Anstrengungen sowohl seitens der wissenschaftlichen als auch der industriellen Forschung auf kleine und mittelständische Unternehmen (KMUs) ausgerichtet wurden, konnte in diesen

92

5 Der PDMS-Regelkreis

Unternehmen die Abbruchquote nicht wesentlich reduziert werden [McAffee 2003; Abramovici u. Schulte, 2004]. Dies liegt darin begründet, dass die in Abschn. 4.4 identifizierten Unternehmensanforderungen bei Systemeinführungen immer noch unzureichend berücksichtigt sind. Insbesondere die augenblickliche Unternehmenseignung ist für KMUs aufgrund des hohen finanziellen Risikos bedeutsam. Um flexibel auf unternehmensindividuelle Anforderungen, wie sie in KMUs vorherrschen, reagieren zu können, muss eine Einführungsmethodik bei Bedarf durch zusätzliche Verfahrensbausteine modular erweiterbar sein. Diese Bausteine können bspw. aus dem strategischen Management oder bestehenden Einführungsmethoden anderer ITUnternehmenssoftware wie Enterprise Ressource Planning - Systeme (ERP-Systeme) oder Manufacturing Execution Systeme (MES) stammen [Kramer u. Kramer 1997; Gulbins et al. 2002; Schwab 2004 ;Kletti 2007]. Bei bisherigen Vorgehensweisen hinsichtlich PDM-Systemeinführungen kann eine grobe Unterscheidung in „klassische“ und „moderne“ PDMSEinführungsmethoden vorgenommen werden [Gebhardt 2007]. Klassische PDMS-Einführungsmethoden wie die VDI-Richtlinie 2219 beschreiben ausschließlich die eigentliche Vorgehensweise bei einer Systemeinführung. Eine Bewertung findet nicht oder nur unter betriebswirtschaftlichen Gesichtspunkten statt. Dagegen versuchen moderne PDMS-Einführungsmethoden wie die nach John Stark [Stark 2006] die Bewertungsintegration nichtbetriebswirtschaftlicher Einflussgrößen. Die Grundlage hierfür bilden Reifegradmodelle aus dem Bereich der Softwareentwicklung. Eine Analyse bestehender PDMS-Einführungsmethoden hat ergeben, dass keine bestehende Einführungsmethodik die identifizierten Unternehmensanforderungen vollständig erfüllt [Gebhardt 2007]. Die „klassischen“ PDMS-Einführungsmethoden beinhalten keine oder ausschließlich betriebswirtschaftliche Bewertungsaspekte. Die modernen Ansätze dagegen legen ihren Schwerpunkt auf die Ablauforganisation. Verbesserungsmaßnahmen zur Steigerung der PDMS-Fähigkeit in Bezug auf die Aufbauorganisation und die Produkte werden nur unzureichend berücksichtigt. Dies gilt auch für konkrete Handlungshinweise zur Verbesserung der PDMS-Fähigkeit. Die Folgen sind eine ineffiziente Projektvorbereitung aufgrund fehlender Unternehmenserfahrung sowie eine unzureichende Bewertung der augenblicklichen Unternehmenseignung [Feldhusen u. Gebhardt 2005]. Da ein zielgerichtetes Projektcontrolling fehlt, wird der zeitliche Umfang des PDMS-Projekts häufig deutlich überschritten. Die gewünschten Ziele der

5.1

Nachteile vorhandener PDMS-Einführungsmethoden

93

Systemeinführung können trotz eines hohen Ressourcenaufwands nicht erreicht werden.

Abb. 5-1 Nachteile bisheriger Vorgehensweisen zur PDM-Systemeinführung und abgeleitete Anforderungen an eine ganzheitliche Vorgehensweise

94

5 Der PDMS-Regelkreis

In der oberen Hälfte der Abb. 5-1 sind die Mängel der bisherigen Lösungsansätze für eine methodische Systemeinführung grafisch dargestellt. Der hohe Unternehmensaufwand als Eingangsgröße besitzt die Form einer Stufensprungfunktion – es sollen mittels der PDMS-Einführung sofort alle Zielsetzungen erreicht und sämtliche existierenden Unternehmensprobleme gelöst werden. Dieser Anspruch wird durch eine spontane Bindung umfangreicher Ressourcen zu erreichen versucht und führt zu einem schwer kalkulierbaren Projektrisiko. Als Ausgangsgröße ergibt sich ein verzögerter Funktionsverlauf, der sich asymptotisch einem gewünschten Idealzustand, wie er nach der Systemeinführung bestehen soll, annähert. Zu einem bestimmten Messzeitpunkt wird die augenblickliche IST-PDMSFähigkeit bestimmt (vgl. Abschn. 4.5). Ihr Abstand zur SOLL-PDMSFähigkeit des Idealzustands stellt den Grad zwischen dem erreichten und dem gewünschten Nutzen der Systemeinführung dar. Je kleiner dieser Abstand ausfällt, umso effektiver und effizienter kann das eingeführte PDMS im Sinne der gewünschten Unternehmensziele genutzt werden. Dies zeigt die untere Hälfte der Abb. 5-1. Somit steht der erreichte Nutzen in direktem Zusammenhang mit der augenblicklichen PDMS-Fähigkeit. Über eine strukturierte Vorgehensweise ist es möglich, ein PDMSProjekt bereits im Vorfeld zu planen und abzuschätzen. Dazu sind konkrete methodische Handlungsanweisungen für jeden einzelnen Vorgehensschritt notwendig. Damit wird eine Aussage hinsichtlich des Aufwands und der Kosten möglich, das Projektrisiko wird minimiert. Unterstützt wird die Vorgehensweise durch eine unternehmensindividuelle Ermittlung und fortlaufende Bewertung der PDMS-Einflussgrößen. Durch die Bewertungsergebnisse können Verbesserungsmaßnahmen identifiziert und umgesetzt werden. Die Ableitung der Verbesserungsmaßnahmen und die erneute Bewertung ihrer Auswirkungen auf die PDMS-Fähigkeit finden durch eine rekursive Rückkopplung statt. Die einzelnen Arbeitsschritte innerhalb der Vorgehensweise und der Bewertung werden durch ein projektbegleitendes Controlling unterstützt. Der dargestellte Lösungsansatz zur Einführung eines PDM-Systems ermöglicht die gewünschte Effektivitäts- und Effizienzsteigerung. Der Abstand zwischen SOLL- und IST-PDMS-Fähigkeit wird geringer. Der Zielerreichungsgrad für das Unternehmen erhöht sich bei einer gleichzeitigen Verkürzung der Einführungsdauer. Dies wird durch ein begleitendes und zielgerichtetes Projektcontrolling gewährleistet. In der funktionalen Darstellung des Projektverlaufs als Ausgangsgröße ist die Nutzen steigernde und beschleunigte Systemeinführung durch den steileren Kurvenanstieg erkennbar.

5.2

Grundlage der modularen Vorgehensweise: Der PDMS-Regelkreis

95

Der im nächsten Abschnitt beschriebene PDMS-Regelkreis erfüllt diese Anforderungen. Dabei ersetzt er die Wirtschaftlichkeitsberechnung nicht, sondern ergänzt diese im Projektvorfeld und während des Projektverlaufs.

5.2 Grundlage der modularen Vorgehensweise: Der PDMS-Regelkreis Im Abschn. 5.1 wurden Anforderungen identifiziert, die der Lösungsansatz zur Bewertung der PDMS-Fähigkeit eines Unternehmens erfüllen muss. Der nachfolgend vorgestellte Ansatz erfüllt diese Anforderungen. Er besitzt den Charakter eines Regelkreises und ist in Abb. 5-2 dargestellt. Seine grundlegenden Zusammenhänge werden nachfolgend erläutert. Die detaillierten Vorgehensweisen hinsichtlich seiner Umsetzung sind im sechsten und siebten Kapitel beschrieben.

Abb. 5-2 PDMS-Regelkreis zur Abschätzung und Verbesserung der PDMSFähigkeit. Auf seiner Grundlage werden die einzelnen Arbeitsschritte zur Bewertung und Systemeinführung abgeleitet

Zunächst wird der gewünschte SOLL-Zustand des Unternehmens definiert. Er beschreibt das gewünschte Szenario, welches im Unternehmen nach einer Systemeinführung vorherrschen soll. Dies beinhaltet sämtliche Ziele und Wünsche des Unternehmens. Anschließend wird der augenblickliche IST-Zustand anhand der PDMS-Einflussgrößen ermittelt und bewertet. Zur Ermittlung des IST-Zustands anhand der PDMS-Einflussgrößen ist eine methodische Vorgehensweise notwendig. Sie muss neben konkreten Handlungsanweisungen auch die Möglichkeit beinhalten, mittels des Bewertungsergebnisses bestehende Schwachstellen zu identifizieren und zu eliminieren. Anschließend werden SOLL- und IST-Zustand verglichen. Das Vergleichsergebnis, d. h. die Größe der vorhandenen Zustandsabweichung, stellt den augenblicklichen PDMS-Reifegrad des Unternehmens dar. Die Zustandsabweichung bildet die Stellgröße „e“ des Regelkreises: Wie in

96

5 Der PDMS-Regelkreis

Abschn. 5.1 beschrieben, ist für eine effiziente Steuerung des PDMSProjekts eine möglichst kleine Abweichung wünschenswert. Dies gilt auch für die spätere Betriebsphase, in der das PDM-System in das Unternehmen produktiv eingeführt wird. Bei einer Abweichung zwischen beiden Zuständen wird ein Iterationszyklus mit ergebnisverbessernden Maßnahmen eingeleitet. Diese haben das Ziel, bei einem weiteren Bewertungsdurchgang die vorhandene Zustandsabweichung zu verringern. Dies geschieht durch eine Änderung der PDMS-Einflussgrößen, die sog. Regelgrößen „R“ des Regelkreises. Diese Änderungen besitzen Auswirkungen auf den SOLL- und IST-Zustand. Gewünscht sind kleine und überschaubare Einführungsstufen bei einer Systemeinführung sowie die geringste Zustandsabweichung. Die Stufen als Regeleingangsgröße als auch das resultierende Regelverhalten als Ausgangsgröße sind in Abb. 5-2 in Form von schematischen Graphen dargestellt. Der Regelkreis wird so lange durchlaufen, bis entweder die gewünschte Stellgröße e oder ein definiertes Abbruchkriterium erreicht wird. Die Stellgröße e bildet der gewünschte PDMS-Reifegrad. Das Abbruchkriterium wird oftmals durch die Ausschöpfung zugewiesener Ressourcen innerhalb des PDMS-Projekts bestimmt. Der beschriebene Regelkreis bildet die Grundlage für die methodische Vorgehensweise zur Ermittlung der PDMS-Fähigkeit. Er besteht aus den Bausteinen Zieldefinition, Maßnahmenumsetzung zur Zielerreichung und Bewertung des Zielerreichungsgrads, wie in Abb. 5-3 gezeigt. Dabei beinhaltet jeder Baustein konkrete Arbeitsschritte.

Abb. 5-3 Methodische Vorgehensweise zur Ableitung der PDMS-Fähigkeit, des PDMS-Reifegrads und der zugehörigen Hilfsmittel

Die linke Seite der Abb. 5-3 zeigt die Vorgehensweise des Lösungsansatzes in allgemeiner Form. Sie orientiert sich am intuitiven Vorgehen bei

5.2

Grundlage der modularen Vorgehensweise: Der PDMS-Regelkreis

97

einer Systemeinführung, wie sie in Abschn. 4.4 beschrieben wurde. Damit sind die benötigten Unternehmensanforderungen vollständig berücksichtigt. Im ersten Baustein wird eine genaue Zieldefinition vorgenommen. Hier werden diejenigen Ziele festgelegt, die mit der Einführung eines PDMS erreicht werden sollen. Sie werden auf ihre augenblickliche oder generelle Umsetzbarkeit im Rahmen einer PDMS-Einführung qualitativ bewertet. Dies geschieht auf der Grundlage der PDMS-Einflussgrößen mit Hilfe des Bewertungsinstruments Capability Scorecard (CSC). In Abhängigkeit des Bewertungsergebnisses werden die definierten Ziele angepasst und überarbeitet. Damit ist der gewünschte SOLL-Zustand hinreichend erfasst. Der zweite Baustein beinhaltet die Wahl und Umsetzung geeigneter Maßnahmen, mit denen die definierten Ziele erreicht werden sollen. Dabei werden anhand der PDMS-Einflussgrößen zunächst die Umsetzungsvoraussetzungen des Unternehmens überprüft. Dies betrifft die Qualität der vorhandenen IT-Landschaft ebenso wie die Eignung der vorhandenen Produkt-, Prozess- und Rollenmodelle. Es werden diejenigen Voraussetzungen analysiert, die das PDMS in Übereinstimmung mit den definierten Zielen für einen effektiven und effizienten Betrieb benötigt. Aus den Bewertungsergebnissen ergeben sich Rückschlüsse auf die augenblickliche Beherrschung der D&I-Flüsse innerhalb des Unternehmens. Daraus lassen sich notwendige Verbesserungsmaßnahmen ableiten. Dies ist für die Aufwandsabschätzung der späteren Systemimplementierung bedeutsam. Die entsprechenden Zusammenhänge sind in Abschn. 4.5 beschrieben. Die Umsetzungsfähigkeit beschreibt die Fähigkeit des Unternehmens, die abgeleiteten Verbesserungsmaßnahmen aufgrund vorhandener Qualifikation, Kompetenz und/oder Erfahrung tatsächlich umsetzen zu können. Erst durch die zielgerichtete Maßnahmenumsetzung kann der gewünschte SOLL-Zustand erreicht werden. Die Umsetzungsfähigkeit stellt somit einen wesentlichen Erfolgsfaktor für eine Verbesserung des PDMSReifegrads dar. Aufgrund einer häufig unzureichenden Unternehmenserfahrung sind hier konkrete Handlungsanweisungen erforderlich. Diese Handlungsanweisungen beeinflussen ebenfalls die PDMS-Einflussgrößen. Auch die Unterstützung durch externe und neutrale PDMS-Spezialisten kann sehr vorteilhaft sein. In Abhängigkeit des Bewertungsergebnisses wird eine erneute Überprüfung der Umsetzungsvoraussetzungen eingeleitet. Durch diesen Iterationszyklus ergibt sich entweder eine Anpassung der geplanten Umsetzungsmaßnahmen oder der definierten Ziele. Auch hierfür müssen konkrete Handlungsanweisungen vorhanden sein. Darüber hinaus müssen in diesem

98

5 Der PDMS-Regelkreis

Baustein organisatorische Maßnahmen wie Schulungs- und Informationskonzepte für die späteren Systemanwender berücksichtigt werden. In Abschn.. 4.2.3 wurde dieser Aspekt bereits behandelt; es sei an dieser Stelle zudem auf die Arbeiten von [Wehlitz 2000; Pusch 2003; Walther 2005] verwiesen. Im dritten Baustein wird der augenblickliche Zielerreichungsgrad festgestellt. Dies geschieht durch die Ermittlung des PDMS-Reifegrads. Wurden die definierten Ziele nicht oder nur unzureichend erreicht, werden verbessernde Aktivitäten durchgeführt. Sie werden innerhalb der vorherigen Bausteine umgesetzt und besitzen korrigierende Auswirkungen. Zwischen den Bausteinen des vorgestellten Lösungsansatzes ist der PDMS-Regelkreis nach Abb. 5-2 erkennbar. Die erforderlichen Instrumente zur Ermittlung der PDMS-Fähigkeit sind auf der rechten Seite der Abb. 5-3 aufgeführt. Die augenblickliche PDMS-Fähigkeit wird mit Hilfe der Capability Scorecard (CSC) ermittelt. Durch sie können die PDMS-Einflussgrößen unternehmensindividuell bewertet werden. Der CSC-Aufbau und ihre Anwendung werden in Kapitel 7 behandelt. Die Ermittlung der PDMS-Einflussgrößen geschieht durch eine begleitende und rekursive PDMS-Einführungsmethodik. Sie beinhaltet konkrete Handlungsanweisungen zur Erfassung jeder einzelnen Einflussgröße. Ebenso beinhaltet sie Vorgehensweisen zur Ableitung und Umsetzung von Verbesserungsmaßnahmen, die anhand des CSC-Bewertungsergebnisses identifiziert wurden. Somit bildet die PDMS-Einführungsmethodik den Rahmen des PDMS-Projekts. Dadurch ist die unmittelbare Iteration zur Verbesserung der PDMS-Fähigkeit sichergestellt. Mittelbar besitzt das Unternehmen einen standardisierten Ablauf, an dem es sich bei einer PDM-Systemeinführung orientieren kann. Die Beschreibung der PDMSEinführungsmethodik geschieht im sechsten Kapitel. Der gesamte Lösungsansatz kann auch im Sinne eines Kontinuierlichen Verbesserungsprozesses (KVP) über die eigentliche Einführungsphase hinaus angewendet werden. Damit ist eine ständige Rückmeldung über die augenblickliche PDMS-Fähigkeit und den Zielorientierungsgrad während der Betriebsphase für das Management sowie die Systemanwender möglich. Sowohl die Vorgehensweise zur Bewertung der PDMS-Fähigkeit als auch die PDMS-Einführungsmethodik bestehen aus einzelnen Arbeitsschritten. Sie sind in Abb. 5-4 dargestellt. Nummerierte Arbeitsschritte sind der

5.2

Grundlage der modularen Vorgehensweise: Der PDMS-Regelkreis

99

PDMS-Einführungsmethodik zugeordnet; alphabetisch bezeichnete Bewertungsschritte werden während des Bewertungsvorgangs ausgeführt.

Abb. 5-4 Arbeitsschritte der drei Bausteine „Zieldefinition“, „Maßnahmenumsetzung“ und „Zielbewertung“

Die PDMS-Einführungsmethodik beginnt mit der Definition der strategischen und operativen Zielsetzungen, die das Unternehmen mit der Systemeinführung erreichen möchte. Anschließend wird eine IST-Analyse durchgeführt. Neben der Datenerfassung zur Modellerstellung bzw. Modellergänzung, die im dritten Arbeitsschritt geschieht, ist v. a. die unternehmensindividuelle Erfassung der PDMS-Einflussgrößen bedeutsam. Basierend auf den gewonnenen Ergebnissen wird ein SOLL-Szenario beschrieben, welches als Vergleichsgrundlage für die anschließende pilothafte Systemimplementierung dient. In dieser Pilotphase wird überprüft, ob und wie das betrachtete PDMS die Ziele unter realen Unternehmensbedingungen erfüllen kann. Die Bewertung des Zielereichungsgrads beginnt ebenfalls mit einer strategischen und operativen Zieldefinition. Diese Ziele werden in der Beschreibung des SOLL-Szenarios berücksichtigt. Anschließend wird anhand spezifischer Bewertungskriterien der IST-Zustand des Unternehmens bewertet. Die Bewertungskriterien lassen sich aus den PDMS-

100

5

Der PDMS-Regelkreis

Einflussgrößen ableiten. Damit können bestehende Schwachstellen hinsichtlich der augenblicklichen Unternehmenseignung, das PDMS gemäß den getroffenen Zielsetzungen einsetzen zu können, identifiziert werden. Mit Hilfe gezielt eingeleiteter Verbesserungsmaßnahmen werden die identifizierten Schwachstellen eliminiert. Anschließend erfolgt eine erneute Bewertung, um die Auswirkungen der durchgeführten Maßnahmen beurteilen zu können. Neben einer unterstützenden Wechselwirkung ist auch ein hoher Überdeckungsgrad bei der Ausführung der einzelnen Arbeitsschritte erkennbar. So ist bspw. der Bewertungsschritt A zu Beginn der PDMSFähigkeitsbewertung mit dem Arbeitsschritt 1 der Einführungsmethodik identisch. Eine ähnliche Aussage trifft für den Bewertungsschritt B zu, in dem die unternehmensspezifischen PDMS-Einflussgrößen ermittelt werden. Die zugehörige Ermittlung selbst geschieht in Arbeitsschritt 2. Weiterhin können in diesen vier Vorgehensschritten Ergebnisse verwendet werden, die im Rahmen einer eventuell bereits erfolgten QMZertifizierung bspw. nach ISO 9000ff. gewonnen wurden. Da diese Ergebnisse im Unternehmen bereits dokumentiert sind, kann der Ermittlungsaufwand erneut reduziert werden. Ebenso ist es umgekehrt möglich, aus den Resultaten, die bei der Ermittlung der PDMS-Fähigkeit gewonnen wurden, qualitätsverbessernde Konsequenzen zu ziehen. Durch die standardisierte Vorgehensweise werden neben einer hohen Planungssicherheit auch reproduzierbare Ergebnisse erreicht, die trotz einer branchenabhängigen Unternehmensindividualität vergleichbar sind. Dies geschieht mittels der Durchführung eines Benchmarks. Neben dem CSCEinsatz lassen sich auf diese Weise weitere Verbesserungspotenziale für den PDMS-Einsatz ermitteln. Die Ergebnisse der einzelnen Arbeits- und Bewertungsschritte werden durch die Anwendung entsprechender Einzelmethoden wie Interviews oder Szenario-Techniken erreicht. Durch die Reihenfolge der Vorgehensschritte ist eine zeitliche Abfolge zwar weitgehend festgelegt, dennoch sind Iterationen zwischen den einzelnen Schritten erlaubt und notwendig. Die Umsetzung von Verbesserungsmaßnahmen erfolgt direkt innerhalb des betroffenen Arbeitsschritts. Dadurch werden seine Inhalte zielgerichtet angepasst und ergänzt. Somit ist eine ständige, zielorientierte Kontrolle während des PDMS-Projekts und der Betriebsphase möglich. Durch diese Vorgehensweise können gefährdende Einflüsse frühzeitig erkannt und durch entsprechende Maßnahmen eliminiert werden. Auch wenn keine spätere Systemeinführung geplant ist, kann durch den modularen Aufbau des PDMS-Regelkreises die Effektivität und die Effi-

5.3

Zusammenfassung Kapitel 5

101

zienz der einzelnen Einflussgrößen im Sinne von QualitätsmanagementMaßnahmen (QM) gezielt beeinflusst werden. Aus diesem Grund bildet jeder Arbeitsschritt hinsichtlich Einführung und Bewertung ein eigenes Anwendungsmodul. In den Ausführungen dieses Abschnitts wird deutlich, dass sich beide Lösungsbausteine gegenseitig ergänzen. Aus Gründen der Übersichtlichkeit werden sie in den nachfolgenden Kapiteln getrennt behandelt, ohne an den entsprechenden Stellen ihren gegenseitigen Bezug zu vernachlässigen. Dabei behandelt Kap. 6 die Vorgehensweise bei der Ermittlung der PDMS-Einflussgrößen und der Systemeinführung. Die Bewertung der PDMS-Fähigkeit und das Vorgehen bei der Ableitung von Verbesserungsmaßnahmen werden in Kap. 7 ausgeführt.

5.3 Zusammenfassung Kapitel 5 In diesem Kapitel wurde die grundsätzliche Vorgehensweise zur Unternehmensbewertung hinsichtlich der augenblicklichen PDMS-Fähigkeit beschrieben. Dazu wurden zunächst die bestehenden Schwächen bei der Anwendung bestehender Vorgehensweisen nachgewiesen. Deren Vermeidung bildet in Kombination mit den Unternehmensanforderungen aus Kapitel 4 die Grundlage für den vorgestellten Lösungsansatz. Eine wesentliche Anforderung ist ein begleitendes, zielorientiertes Controlling bei einer Systemeinführung und während der SystemBetriebsphase. Nur dies gewährleistet eine Verbesserung der PDMSFähigkeit. Dazu muss jede durchgeführte Aktivität zur Verbesserung der Unternehmenseignung unmittelbare Auswirkungen auf die Einführungsund Betriebsaktivitäten besitzen. Aufgrund dieses rekursiven, regelkreisartigen Verhaltens wird die Vorgehensweise als PDMS-Regelkreis bezeichnet. Der PDMS-Regelkreis wurde als konkrete Vorgehensweise beschrieben, die aus den beiden Bausteinen „PDM-Systemeinführung“ und „Bewertung der PDMS-Fähigkeit“ besteht. Bei der PDMSystemeinführung werden gleichzeitig die PDMS-Einflussgrößen unternehmensindividuell ermittelt. Durch die Anwendung des PDMS-Regelkreises können Unternehmen sowohl im Vorfeld eines PDMS-Projekts sowie während der eigentlichen Systemeinführung ein kontinuierliches Controlling hinsichtlich des Zielerreichungsgrads durchführen. Damit ist eine effiziente Ressourcen- und Kostenkontrolle möglich, die auch für die Systembetriebsphase genutzt werden kann.

102

5

Der PDMS-Regelkreis

Literatur Abramovici M, Schulte S (2004) PLM - logische Fortsetzung der PDM-Ansätze oder Neuauflage des CIM-Debakels? In: I2P (Tagungsband), VDI-Berichte 1819. VDI-Verlag, Düsseldorf Feldhusen J, Gebhardt B. (2005) Ein Beitrag zur Bewertung der PDMS-Fähigkeit eines Unternehmens - die Capability Scorecard. In: Informations- und Wissensdrehscheibe Produktdatenmanagement. GITO, Berlin Gebhardt B (2007) Abschätzung der Produktdatenmanagement-Systemfähigkeit produzierender Unternehmen. Shaker, Dissertation RWTH Aachen Gulbins J, Seyfried M, Strack-Zimmermann H (2002) Dokumentenmanagement, 5. Auflage. Springer, Berlin-Heidelberg-New York Kletti J (2007) Konzeption und Einführung von MES-Systemen. Springer, BerlinHeidelberg-New York Kramer F, Kramer M (1997) Bausteine der Unternehmensführung, 2. Auflage. Springer, Berlin-Heidelberg-New York McAffee A (2003) When Too Much IT-Knowledge Is A Dangerous Thing. In: MIT Sloan Management Review Winter, Vol. 44 No. 2. Massachusetts, MIT School of Sloan Management Pusch R (2003) Personalplanung und -entwicklung in einem integrierten Vorgehensmodell zur Einführung von Produktdatenmanagementsystemen. Dissertation, Universität Paderborn Schöttner J (1999) Produktdatenmanagement in der Fertigungsindustrie - Prinzip, Konzepte, Strategie. Hanser, München-Wien Stark J (2006) Product Lifecycle Management - 21st Century Product Paradigm for Product Realisation, 3rd edition. Springer, London Schwab A (2004) Managementwissen für Ingenieure. Springer, BerlinHeidelberg-New York Walther I (2005) Rollen- und Situationsmodellierung bei betrieblichen Dispositions- und Planungssystemen. Dissertation, Technische Universität Erlangen-Nürnberg Wehlitz P (2000) Nutzenorientierte Einführung eines ProduktdatenmanagementSystems. Dissertation, Technische Universität München

6 Lösungsbaustein 1: PDM-Systemeinführung

Mit Hilfe des in Kapitel 5 beschriebenen PDMS-Regelkreises können Unternehmen ihre PLM-Strategie zielgerichtet planen und umsetzen. Mit seinen zwei Lösungsbausteinen werden die wichtigsten Anforderungen nach pragmatischen Vorgehensweisen bei der PDM-Systemeinführung und der Bewertung erfüllt. In diesem Kapitel wird die Vorgehensweise zur Systemeinführung ausführlich beschrieben. Dies beinhaltet die einzelnen Arbeitsschritte und ihre konkreten Handlungsanweisungen einschließlich der erforderlichen Hilfsmittel. Zusätzlich werden Rahmenbedingungen des PDMS-Projekts wie die Projektorganisation erläutert. An geeigneten Stellen sind checklistenartige Aufzählungen zur Vorbereitung und Kontrolle einzelner Aktivitäten zu finden. Weiterhin werden mit diesem Baustein die vorhandenen PDMSEinflussgrößen unternehmensindividuell ermittelt. Sie bilden die Grundlage für die Unternehmensbewertung der augenblicklichen PDMS-Fähigkeit.

6.1 Beschreibung der methodischen Vorgehensweise Der erste Lösungsbaustein unterstützt die PDMS-Einführung durch notwendige Aktivitäten zur unternehmensindividuellen Ermittlung der PDMS-Einflussgrößen. Die Vorgehensweise ist in vier einzelne Arbeitsschritte gegliedert und in Abb. 6-1 dargestellt. Jeder Arbeitsschritt besteht aus konkreten Handlungsanweisungen, die durch den Einsatz entsprechender Hilfsmittel unterstützt werden. Sowohl die Handlungsanweisungen als auch die eingesetzten Hilfsmittel werden in diesem Kapitel behandelt. Damit sind Unternehmen in der Lage, ein PDMS-Projekt mit eigenen Ressourcen bereits im Vorfeld zu planen und die Systemeinführung zu beschleunigen. Weiterhin werden innerhalb des ersten Lösungsbausteins die für die Bewertung der augenblicklichen PDMS-Fähigkeit notwendigen Daten und Informationen ermittelt. Die Vorgehensweise zur Datenermittlung, die

104

6

Lösungsbaustein 1: PDM-Systemeinführung

Einführung eines PDMS, der Ablauf des PDMS-Projekts sowie die Projektorganisation werden in den folgenden Abschnitten beschrieben.

Abb. 6-1 Darstellung der Arbeitsschritte, der Arbeitsergebnisse sowie der eingesetzten Hilfsmittel für die Einführung eines PDMS

6.2 Organisation und Ablauf des PDMS-Projekts Unter dem PDMS-Projekt werden sämtliche Aktivitäten zur zielgerichteten Vorbereitung, Durchführung und Beendigung verstanden, die für die Ermittlung der PDMS-Fähigkeit notwendig sind. Dies beinhaltet auch die Einführung eines PDMS (siehe Abschn. 4.5). Mit der eigentlichen Systemeinführung ist das PDMS-Projekt beendet; es beginnt die Betriebsphase. In den folgenden Abschnitten werden die notwendige Projektorganisation und ihre Aufgaben sowie der eigentliche Projektablauf behandelt. Diese Beschreibungen sind als Orientierung zu verstehen und müssen den vorhandenen Unternehmensbedingungen angepasst werden. Dies gilt insbesondere hinsichtlich der verfügbaren Projektmitarbeiter und -ressourcen.

6.2

Organisation und Ablauf des PDMS-Projekts

105

6.2.1 Aufbau der PDMS-Projektorganisation Die gewünschte Einführung eines PDM-Systems ist häufig die Folge einer unbefriedigenden, konkreten Arbeitssituation auf Gruppen- und/oder Abteilungsebene. Motivierende Auslöser können bspw. der Wunsch nach x einer effizienteren Verwaltung der CAD-Daten und der mit ihnen verbundenen Dokumente wie Stücklisten; x einer digitalen Erfassung der vorhandenen Abläufe mit dem Wunsch einer Effizienzsteigerung der Gesamtprozesse; x einer schnellen und zielgerichteten Suchfunktion bei der Wiederauffindung bereits durchgeführter Projekte mit ähnlichen konstruktiven Anforderungen oder x einem komfortablen Arbeiten unter einer Benutzeroberfläche ohne häufiges Wechseln zwischen Programmfenster sein. Auf der Grundlage dieser Verbesserungswünsche von einem oder mehreren Mitarbeitern (so genannten Projekttreibern) resultieren Gespräche mit dem mittleren Management, um einen potenziellen Systemnutzen zu diskutieren. Meist ist dies der Auslöser für eine erste Machbarkeitsstudie, in welcher der Nutzen für die Abteilung und dadurch Argumente für ein mögliches PDMS-Projekt erfasst werden sollen. Diese Phase der unternehmensinternen Reflexion wird Vorklärungsphase genannt und folgt einem Bottom-Up-Ansatz. Bereits in der Vorklärungsphase lässt sich eine informelle Projektorganisation mit zugehörigen Projekttreibern und Projektmitgliedern aus betroffenen Abteilungen erkennen. Sie kann als Grundlage für das spätere Projektkernteam dienen. Der Aufbau der Projektorganisation, ihre einzelnen Mitglieder und deren Hauptaufgaben sind in Abb. 6-2 exemplarisch dargestellt. Es ist erkennbar, dass sich in den einzelnen Projektinstanzen Spezialisten wiederfinden, die für die inhaltliche Ermittlung der einzelnen PDMS-Einflussgrößen benötigt werden. x Der Projektleiter plant, überwacht und steuert das gesamte PDMSProjekt. Dies beinhaltet neben der eigentlichen Systemeinführung auch die Verantwortlichkeit für die Unternehmensbewertung. Zusätzlich führt er das Kern- und das spätere Pilotteam. Ihm obliegt ebenfalls die Darstellung des jeweiligen Projektstands sowie der phasenabhängigen Projektergebnisse. Damit stellt er die Kommunikationsschnittstelle zwischen dem Projektpaten, dem Kern- bzw. Pilotteam und dem übrigen Unternehmen dar. Die Ausübung dieser Tätigkeit ist von projektentscheidender Bedeutung; aus diesem Grund soll der Projektleiter von einem Projektmanagementteam (oder Project Office) unterstützt werden,

106

6

Lösungsbaustein 1: PDM-Systemeinführung

welches für formale Aufgaben wie Einkäufe, Schriftwechsel oder Dokumentationen von Arbeitsergebnissen verantwortlich ist. Auch die Koordination mit bereits vorhandenen Unternehmensprojekten obliegt dem Projektmanagementteam. Dadurch findet eine wesentliche Entlastung des Projektleiters statt. Die gesamte Projektleitung kann zwischen einem unternehmensinternen und einem neutralen externen Projektleiter aufgeteilt werden. Die Weisungsbefugnis verbleibt in der Praxis beim unternehmensinternen Projektleiter. Beide Projektleiter werden von zwei Instanzen wesentlich unterstützt: Dem Projektpaten sowie dem Kernteam. Von der Qualität dieser Unterstützung hängt der Projekterfolg wesentlich ab! x Der Projektpate ist Teil des Lenkungsausschusses und bildet die kommunikative Schnittstelle zur Geschäftsführung bzw. dem TopManagement. Der Projektpate berichtet dem Lenkungsausschuss über den Projektfortschritt und gibt strategische Entscheidungen des Managements, sofern sie für das PDMS-Projekt bedeutsam sind, weiter. Der Lenkungsausschuss besitzt die Gesamtverantwortung über das PDMS-Projekt. Dies beinhaltet neben einer eindeutigen strategischen Zielfestlegung im Rahmen der Unternehmensvision (PDMSEinflussgröße strategische Ziele) auch die Bestimmung des Projektleiters und des Projektteams. Zusätzlich trifft der Lenkungsausschuss projektkritische Entscheidungen wie die Einleitung einer neuen Projektphase und die Zuteilung notwendiger Ressourcen. Er besteht aus dem Projektpaten, Mitgliedern des Top-Managements und evtl. externen, neutralen Experten wie Angehörige spezialisierter Hochschulinstitute, Beratungsfirmen o. ä. x Das Kernteam ist während der Systemeinführung für die Durchführung und Umsetzung der einzelnen Arbeitsschritte verantwortlich. Dies geschieht auf der Grundlage der operativ festgelegten Zielsetzungen (PDMS-Einflussgröße operative Ziele), die mit dem PDMS-Projekt erreicht werden sollen. Sie werden inhaltlich durch die PDMSEinflussgrößen IT-Struktur sowie produkt-, prozess- und organisationsspezifische Aspekte beschrieben. Aus diesem Grund soll sich das Kernteam nicht nur aus Mitgliedern der von einer Systemeinführung betroffenen Abteilungen zusammensetzen, sondern auch aus Experten, welche die einzelnen Inhalte abdecken können. So werden bspw. system- und datentechnische Aspekte von den unternehmensinternen IT-Spezialisten abgedeckt (PDMS-Einflussgröße Anforderungen des PDMS). Die Erfassung der Produkte oder Prozesse kann durch Konstrukteure oder Organisationsexperten erfolgen (PDMS-Einflussgrößen Produkt, Prozess und Organisation). Um dem Risiko der „Betriebsblindheit“ vorzubeugen, ist die Beteiligung neutraler externer Experten zu empfehlen, die ebenfalls

6.2

Organisation und Ablauf des PDMS-Projekts

107

Mitglieder des Kernteams sind. Zusätzlich wird durch ihre Einbindung die Berücksichtigung des aktuellen (Wissens-)Standes der Technik gewährleistet. Damit wird das PDMS-Projekt mit der größtmöglichen technischen Aktualität umgesetzt.

Abb. 6-2 Exemplarischer Aufbau der PDMS-Projektorganisation, ihrer Mitglieder und ihrer Hauptaufgaben

Das Kernteam in der vorgestellten Zusammensetzung führt v. a. Aktivitäten durch, die vor der eigentlichen Systemeinführung stattfinden können. Dabei ist es vorteilhaft, dass für viele Aktivitäten Mitarbeiter des Unternehmens eingesetzt werden können. Sie kennen die unternehmensspezifischen Gegebenheiten besser als jeder externe Berater und bilden somit ei-

108

6

Lösungsbaustein 1: PDM-Systemeinführung

ne unverzichtbare Wissensquelle. Zusätzlich wird durch ihren Einsatz die Wertigkeit des PDMS-Projekts im gesamten Unternehmen deutlich unterstützt. Weiterhin können erhebliche Beratungskosten externer Dienstleister wie Systemhäuser oder Softwareanbieter eingespart werden. Nachteilig ist, dass zur Vermeidung von Doppelarbeit die Mitarbeiter des Kernteams von einem externen Spezialisten methodisch angeleitet werden müssen, wie dies bspw. bei der Durchführung der IST-Analyse empfehlenswert sein kann. Sobald jedoch die eigentliche Systemimplementierung eines bestimmten Softwareherstellers durchgeführt werden soll, wandelt sich das Kern- in das Pilotteam. Dies geschieht vor der Pilotphase des PDMS-Projekts. Die Pilotphase ist Bestandteil der Umsetzungsphase (siehe Abschn. 6.2.2). Das ursprüngliche Kernteam wird von externen Spezialisten des Softwareanbieters verstärkt, die „ihr“ PDMS am besten kennen. Sie stellen die optimale Umsetzung der Projektergebnisse des Kernteams sicher. Zusätzlich ist eine gewünschte Mischung aus Unternehmenserfahrung und aktuellem (externen) Stand der (Wissens-)Technik gewährleistet. x Die Verantwortlichkeiten des Pilotteams sowie der Projektleiter sind mit denjenigen des Kernteams identisch. Das Pilotteam wird durch entsprechende Systemspezialisten erweitert, welche die system- und schulungstechnische Einführung begleiten. Dies umfasst die Schulung der Anwender während der Pilotphase ebenso wie die Erstellung eines unternehmensweiten Qualifikations- und Ausbildungsplans für eine mögliche Systembetriebsphase. Von besonderer Bedeutung innerhalb des Kern- und Pilotteams sind der Business-Administrator und der System-Administrator. Sie teilen sich die Administrationsaufgaben des PDMS, jedoch mit unterschiedlichen Schwerpunkten. Der System-Administrator ist für sämtliche IT-Aspekte des PDMS verantwortlich. Hierzu zählen die Systemimplementierung und Einbindung in die bestehende IT-Landschaft, die Einhaltung und Überwachung der Wartungszyklen, die Systempflege und die Einspielung von Updates bzw. Upgrades. Seine Hauptaufgabe besteht darin, das PDMS während der späteren Betriebsphase störungsfrei zu halten und auf der IT-Ebene an die Unternehmensanforderungen anzupassen. Die Systemadministration wird von einem Mitarbeiter der IT-Abteilung durchgeführt. Der Business-Administrator ist für die eigentlichen PDM-Systeminhalte verantwortlich. Dazu zählen die Erfassung der relevanten Daten, die Pflege und Aktualisierung der Modelle und die Erstellung der Workflows. Er verantwortet auch die Planung, Umsetzung und Überwachung des Schulungskonzepts. Der Business-Administrator bildet die Ablauf- und Aufbauorga-

6.2

Organisation und Ablauf des PDMS-Projekts

109

nisation sowie die vorhandenen Unternehmensprodukte im PDMS ab. Gleichzeitig ist er Ansprechpartner für sämtliche Mitarbeiter bei inhaltlichen Systemfragen. Der Business-Administrator übernimmt sämtliche Aufgaben eines Inhouse-Consultants im Bereich PLM bzw. PDMS. Dies kann nicht neben dem Tagesgeschäft geschehen; gerade in den sensiblen ersten Monaten der Betriebsphase muss der Business-Administrator für alle Mitarbeiter ständig erreichbar sein. Nur durch diese Unterstützung wird eine hohe Akzeptanz für das PDMS im Unternehmen gewährleistet. Aus diesem Grund wird die Schaffung einer neuen Stabsstelle empfohlen. Diese Stelle ist unmittelbar unter der Managementebene angesiedelt; der Business-Administrator ist in Abstimmung mit dem Management voll für die PLM-Strategie und deren Umsetzung im Unternehmen verantwortlich. Die begleitende Projektbetreuung eines (system-)neutralen PDMSExperten als externer Projektleiter wird während der Systemeinführung empfohlen [Schöttner 1999; Scheer 2001; Eigner u. Stelzer 2001; Feldhusen et al. 2005c]. Ein solcher Experte kann bspw. aus dem Umfeld eines spezialisierten Hochschulinstituts oder Consultingunternehmens beauftragt werden. Aufgrund seiner Erfahrung berücksichtigt er wesentliche Projektziele, die von den beteiligten Mitarbeitern zum jetzigen Zeitpunkt nicht abzuschätzen sind. Auch die fachspezifische Vertretung zur Wahrung der unternehmensindividuellen Zielsetzungen gegenüber den Software- bzw. Systemanbietern wird gewährleistet. Dies untermauert das Vertrauen der Unternehmensmitarbeiter in das PDMS-Projekt. Der externe Projektleiter arbeitet eng mit dem internen Projektleiter des Unternehmens zusammen. Der externe Projektleiter besitzt keine projektgebundene Weisungsbefugnis. Er ist nicht mit dem Berater eines Systemherstellers oder Systemhauses identisch! 6.2.2 Ablauf des PDMS-Projekts Wie in Abschn. 4.5 definiert wurde, umfasst das PDMS-Projekt sämtliche Tätigkeiten innerhalb einer PDMS-Einführung. Dabei müssen neben den Zielvorgaben auch Aspekte wie zeitliche, finanzielle und personelle Ressourcen berücksichtigt werden [DIN 69 901]. Ihre Steuerung geschieht durch eine phasenorientierte Projektplanung [Frech et al. 1999; Becker et al. 2003; Schwab 2004]. Wie in Abb. 6-3 gezeigt ist, gliedert sich das PDMS-Projekt in die beiden Phasen Untersuchung und Umsetzung. Vor der eigentlichen Untersuchungsphase findet eine unternehmensinterne Vorklärungsphase statt. In der Vorklärungsphase wird seitens ein-

110

6

Lösungsbaustein 1: PDM-Systemeinführung

zelner Mitarbeiter der Handlungsbedarf für die Einführung eines PDMS intuitiv erkannt. Die Vorklärungsphase besitzt meist informellen Charakter und initiiert das spätere PDMS-Projekt [Pusch 2003; Sendler u. Wawer 2005], bildet jedoch keinen unmittelbaren Bestandteil der methodischen Vorgehensweise. Dennoch liefert sie relevante Eingangsgrößen, die im ersten Arbeitsschritt zur Datenaufnahme benötigt werden. Die Vorklärungsphase wird in Abschn. 6.3 behandelt; ihre Aktivitäten werden als Arbeitsschritt 0 bezeichnet.

Abb. 6-3 Ablauf eines PDMS-Projekts, seine einzelnen Phasen und ihre zugehörigen Inhalte. Die unternehmensinterne Vorklärungsphase bildet keinen unmittelbaren Bestandteil des PDMS-Projekts, liefert jedoch relevante Eingangsgrößen

Die Ziele der Untersuchungsphase liegen v. a. in der Beantwortung der Frage, ob und wie sehr ein Unternehmen für die Einführung eines PDMS bereits vorbereitet ist. Dazu wird im ersten Arbeitsschritt eine Definition derjenigen Ziele vorgenommen, die durch das PDMS-Projekt erreicht werden sollen. Anschließend werden die Ziele priorisiert und hinsichtlich ihrer Unterstützungseignung durch ein PDMS qualitativ bewertet. Die Ziele bil-

6.2

Organisation und Ablauf des PDMS-Projekts

111

den in Form der Anforderungsliste das Ergebnis des ersten Arbeitsschritts. Bestandteil dieses Arbeitsschritts ist auch die verbindliche Festlegung der Projektorganisation. Er endet mit einer Entscheidung für oder gegen die Durchführung des zweiten Arbeitsschritts. Im zweiten Arbeitsschritt wird eine IST-Analyse des Unternehmens durchgeführt. Anhand des Analyseergebnisses werden mögliche Einführungsszenarien abgeleitet, die hinsichtlich ihres Umsetzungsaufwandes bewertet werden. Das durch das Unternehmen favorisierte Szenario stellt das systemneutrale SOLL-Konzept des PDMS-Projekts dar. Für das SOLL-Konzept wird eine Wirtschaftlichkeitsberechnung durchgeführt. Es bildet zusammen mit der ergänzten Anforderungsliste die Entscheidungsgrundlage, ob und wie die nächste Projektphase umgesetzt wird. Damit ist die Untersuchungsphase abgeschlossen. In der anschließenden Umsetzungsphase werden ausgewählte Prozesse zusammen mit dem Produktdatenmodell und dem Rollenmodell in ein Pilotsystem implementiert. Eine Neuerstellung bzw. Ergänzung vorhandener Modelle findet im dritten Arbeitsschritt statt. Das Ergebnis dieses Arbeitsschritts sind implementierungsfähige und systemneutrale Modelle, die die definierten Zielsetzungen aus der ersten Projektphase erfüllen. Im vierten Arbeitsschritt werden die eigentliche Systemimplementierung sowie die Modellimplementierung in das PDMS vorgenommen. Es handelt sich um die sog. Pilotphase. Damit sollen erste Anhaltswerte für den Implementierungsaufwand und die sinnvolle Durchdringungstiefe für die spätere Betriebsphase gewonnen werden. Ebenso soll der Nachweis einer erfolgreichen Anbindung an die bestehenden IT-Systeme des Unternehmens erbracht werden. Die Erfahrungen werden in der Anforderungsliste berücksichtigt. Anschließend wird über eine unternehmensweite Systemeinführung entschieden. Das Ergebnis des vierten Arbeitsschritts bildet ein laufendes Pilotsystem. 6.2.3 Kosten des PDMS-Projekts Die ungefähren Kosten eines typischen IT-Großprojekts sind in Abb. 6-4 exemplarisch dargestellt. Sie umfassen in der PDMS-Einführungsphase x x x x

die eigentlichen Softwarekosten; die Kosten für erforderliche Hardware; Kosten für (externe) Berater und Systemconsulting; Personalkosten durch Neueinstellungen oder Abzug vom Tagesgeschäft;

112

6

Lösungsbaustein 1: PDM-Systemeinführung

x Schulung und Training des Kernteams (Anwender, Superuser und Administratoren). Zusätzlich müssen anfallende Kosten für die Durchführung von Workshops bzw. Meetings oder die Anmietung entsprechender Räumlichkeiten für deren Durchführung berücksichtigt werden.

Abb. 6-4 Kostenverteilung in einem typischen IT-Großprojekt [Schoen, 2005]

Anhand der dargestellten Kostenverteilung ist deutlich erkennbar, dass die eigentlichen Softwarekosten innerhalb eines PDMS-Projekts etwa ein Fünftel der Initialkosten ausmachen [Schoen 2005]. Dieser Kostenanteil wird üblicherweise in der (finanziellen) Ressourcenberücksichtigung eines PDMS-Projekts irrtümlich als größter Kostenfaktor eingeschätzt. Die zusätzlichen Kosten wie Personal-, Trainings- und Consultingkosten werden dagegen in der Praxis oftmals unterschätzt und zu gering budgetiert [Schmidt 2002; Stark 2006; Kletti 2007]. Häufig wird in diesem Bereich auch die fehlerhafte Annahme gemacht, diese Kostenaspekte könnten durch die unternehmenseigene IT-Abteilung aufgefangen werden. Dazu ist jedoch in diesem Bereich eine umfassende Qualifizierung aufgrund der besonderen Anforderungen der PLM-Strategie und der PDMS-Einführung

6.3

Die unternehmensinterne Vorklärungsphase

113

notwendig – ein IT-Administrator ist normalerweise kein Prozess- oder Produktmanager. Nach einem erfolgreich abgeschlossenen PDMS-Projekt mit anschließender Betriebsphase wird in der Regel angestrebt, dass sich die Systemkosten während der Betriebsphase innerhalb eines Zeitraums von 3 Jahren amortisiert haben [Abramovici et al. 2005]. Erst dann wird von einer erfolgreichen, wirtschaftlichen Systemeinführung gesprochen [Schöttner 1999; Kütz 2003]. Extrapolierte 3-Jahres Folgekosten während der Systembetriebsphase sind bspw. x Lizenzkosten für die Softwarenutzung; x Personalkosten, welche mögliche Neueinstellungen spezialisierter Fachkräfte zur Systembetreuung sowie Weiterentwicklung der PLMStrategie betreffen und die Schulungskosten zur Mitarbeiterqualifizierung; x möglicherweise auch Leasingkosten für Soft- und/oder Hardware. In der dargestellten Kostenverteilung betragen die 3-Jahre-Folgekosten ungefähr ein Drittel der Gesamtkosten, die sich aus den Initialkosten des eigentlichen PDMS-Projekts und der Betriebsphase zusammensetzen. Selbstverständlich ist dieser Wert von unternehmensindividuellen Gegebenheiten wie den strategischen und operativen Zielsetzungen, der Anzahl der Systemnutzer oder der Art die Softwarelizensierung (Floating oder Licence) abhängig. Die aufgeführten Werte haben sich jedoch in durchgeführten PDMS-Projekten als hinreichend genau erwiesen. Im Bereich der Consultingkosten wird durch die Ermittlung der PDMSFähigkeit und die Anwendung der CSC durch die Unternehmen die meiste Kostenersparnis erzielt. Einsparungen ergeben sich auch im Bereich der Personalkosten sowie der Schulung des Kernteams.

6.3 Die unternehmensinterne Vorklärungsphase In den beiden ersten Buchkapiteln wurde aufgezeigt, dass die bestehende Unternehmenskomplexität durch die Umsetzung von PLM und die Einführung eines PDMS beherrscht werden soll. Die Erwartungen und die Anforderungen eines Unternehmens, die mit der PDMS-Einführung verknüpft sind, wurden in Abschn. 4.4 diskutiert. Diese Zusammenhänge sind dem Unternehmensmanagement und den Mitarbeitern vor Beginn eines möglichen PDMS-Projekts intuitiv bewusst, auch wenn konkrete Auswirkungen

114

6

Lösungsbaustein 1: PDM-Systemeinführung

auf die einzelnen Bereiche bzw. Standorte zu diesem frühen Zeitpunkt noch nicht vollständig abgeschätzt werden können [Wehlitz 2000; Hansel u. Lomnitz 2003]. Häufig werden die erreichbaren Ziele dem Management sowie den Mitarbeitern übertrieben positiv dargestellt [Höfener 1999]. Während des eigentlichen Projektverlaufs wird deutlich, dass sie aufgrund unterschiedlicher Unternehmens- und/oder Systemvoraussetzungen nur eingeschränkt oder nicht umgesetzt werden können [McAffee 2003]. Dies gefährdet den Projekterfolg, da sich Vorbehalte seitens des Managements und v. a. der Mitarbeiter ergeben. Um diesen Schwierigkeiten bereits vor Beginn des PDMS-Projekts vorzubeugen, muss eine offene Erwartungshaltung sowohl auf Managementebene als auch bei den Mitarbeitern innerhalb des Unternehmens geschaffen werden. Dazu ist eine zu diesem Zeitpunkt unscharfe Formulierung der Handlungsfelder, ihre Abstimmung mit bestehenden Aktivitäten im Unternehmen sowie erste Zielbeschreibungen vorzunehmen. Weiterhin sollen die wichtigsten Randbedingungen definiert werden, um den Handlungsrahmen abzustecken. Dazu gehören neben ungefähren Zeit- und Kostenvorgaben auch erste Überlegungen zur Schaffung einer institutionellen Projektorganisation [Schöttner 1999; Scheer 2001; Eigner u. Stelzer 2001]. Sie stellt die funktionale Realisierung der Untersuchungs- und Umsetzungsphase sicher [Frech et al 1999; Schwab 2004]. Oftmals wird das PDMS des gleichen Herstellers wie der vorhandenen 3D-CAD-Softwareapplikation favorisiert, da man sich einen störungsfreien Datenaustausch und eine allgemein geringere Schnittstellenproblematik bei der PDM-Systemanbindung erwartet [Schöttner 1999; Eigner u. Stelzer 2001; Stark 2006]. Spätestens in der Pilotphase zeigt sich, ob das favorisierte System sämtliche Zielsetzungen hinreichend erfüllen kann. Die beschriebenen Zusammenhänge können als Auslöser für die Initiierung eines PDMS-Projekts wie folgt zusammengefasst werden: x Vorgaben der Führungsebene, die den Projektrahmen definieren; x Wünsche, Erwartungen oder Anforderungen seitens der Mitarbeiter sowie x erste Projektskizzen einschließlich eines favorisierten PDM-Systems. Die beschriebenen Auslöser sind in unterschiedlicher Qualität dokumentiert [Lindemann u. Reichswald 1998; Fischer u. Scheibeler 2003; Cassel 2003]. Dabei handelt es sich um Dokumente wie Notizen, Gesprächsprotokolle oder eine Auflistung gewünschter Ziele. Diese Dokumente bilden die Eingangsgrößen für den ersten Arbeitsschritt. Am Ende der unterneh-

6.4

Die Untersuchungsphase

115

mensinternen Vorklärungsphase steht als Ergebnis die Entscheidung des Managements, ob und wie das PDMS-Projekt initiiert werden soll. Damit beginnt die eigentliche PDMS-Einführung.

6.4 Die Untersuchungsphase Nachfolgend werden die beiden ersten Arbeitsschritte der Untersuchungsphase, ihre einzelnen Aktivitäten sowie die benötigten Hilfsmittel beschrieben. Durch ihre Anwendung wird die zweite Projektphase des PDMS-Projekts vorbereitet. 6.4.1 Arbeitsschritt 1: Definition der Zielsetzungen Unter Berücksichtigung der Eingangsgrößen aus der Vorklärungsphase werden in diesem Arbeitsschritt die Ziele des Managements und der zukünftigen Anwender aufgenommen. Dies geschieht durch gemeinsame Gespräche und Workshops. Die aufgenommenen Ziele werden priorisiert und daraufhin qualitativ bewertet, ob sie durch die PLM-Strategie und ein PDMS unterstützt werden können. Durch diese Vorgehensweise sollen unrealistische Zielsetzungen bereits zu Projektbeginn identifiziert werden. Durch die eindeutige Zieldefinition in Form von Anforderungen wird die Grundlage für die Bewertung des projektabschließenden Zielerreichungsgrads gelegt. Die grundsätzliche Vorgehensweise innerhalb des ersten Arbeitsschritts ist in Abb. 6-5 als Flussdiagramm gezeigt. Die durchzuführenden Aktivitäten werden nachfolgend kurz erläutert. Das Ergebnis des ersten Arbeitsschritts stellen der Abschlussbericht, die Anforderungsliste und der Projektplan für das PDMS-Projekt dar. Diese Dokumente begleiten sämtliche nachfolgenden Arbeitsschritte und müssen auf dem jeweiligen aktuellen Projektstand gehalten werden. Alle drei Dokumente werden bei einer Änderung der Ziele oder der ProjektRahmenbedingungen angepasst.

116

6

Lösungsbaustein 1: PDM-Systemeinführung

unternehmensinterne Vorklärungsphase

Arbeitsschritt 1: Zieldefinition

CSC

Situationsanalyse

Projektdurchführung?

nein

Projektende

ja

Durchführung Evaluierungsworkshop

CSC

Qualitative Zielbewertung

ja Nacharbeit erforderlich? nein

Nächster Arbeitsschritt ?

nein

Projektende

ja Arbeitsschritt 2: IST-Analyse und SOLL-Konzept

CSC

Bewertung mittels Capability Scorecard (CSC)

Abb. 6-5 Vorgehensweise des ersten Arbeitsschritts zur Bestimmung der Ziele, die mit dem PDMS-Projekt erreicht werden sollen

Zu Beginn des Arbeitsschritts müssen die strategischen Projektziele sowie die verfügbaren Projektressourcen definiert werden. Dazu findet ein Aus-

6.4

Die Untersuchungsphase

117

tausch zwischen dem PDMS-Projektleiter und dem Unternehmensmanagement statt. Dabei werden x relevante Begrifflichkeiten wie PLM, PDMS sowie „PDMS-Fähigkeit“ als gemeinsame Verständnisgrundlage geklärt; x Wünsche, Erwartungen und Projektziele auf Managementebene sowie deren Einbettung in die Unternehmensstrategie aufgenommen; x sämtliche Projektressourcen, wie bspw. das finanzielle Budget und der zeitliche Umfang vereinbart; x die Projektorganisation festgelegt und x die Vorgehensweise bei der Ergebnisdokumentation und Berichterstattung abgeklärt. Mit Hilfe dieser Inhalte kann eine erste Projektabschätzung hinsichtlich des erreichbaren Nutzens sowie des zu erwartenden Aufwands getroffen werden. Dies geschieht durch eine qualitative Bewertung mittels der Capability Scorecard (CSC), indem sich jedes strategische Ziel sowohl dem übergeordneten Unternehmens-Leitziel als auch den einzelnen Unternehmensperspektiven wie „Produkt“ oder „Prozess“ zuordnen lässt (siehe Abschn. 7.4.1 - Bewertung Arbeitsschritt A). Ist eine Zuordnung nicht möglich, kann das Ziel mit Hilfe der PLM-Strategie nicht erreicht werden. Anders formuliert: Stimmt ein gewünschtes Unternehmensziel nicht mit denjenigen Zielsetzungen, welche durch die PLM-Strategie möglich sind, überein, muss das Unternehmensziel entweder abgeändert werden oder ist für eine Unterstützung mittels PLM nicht geeignet. Dies trifft bspw. zu, falls ein PDMS mit dem Ziel eines Personalabbaus eingeführt werden soll. Die wichtigsten PLM-Zielsetzungen auf strategischer Ebene wurden im zweiten Kapitel behandelt. Anschließend werden in einem Workshop mit dem Projektteam die operativen Zielsetzungen festgelegt. Es werden folgende Inhalte ermittelt: x Es wird eine Aufnahme sämtlicher Wünsche und Erwartungen der zukünftigen Anwender durchgeführt. Dies kann bspw. auf der Ergebnisgrundlage der Vorklärungsphase, durch heuristische Methoden wie einem Brainstorming o. ä. geschehen. Die Erwartungen und Wünsche werden auf Textkarten schriftlich festgehalten, thematisch zusammengefasst und als operative Ziele klassifiziert. x Die Ziele werden hinsichtlich ihrer Potenziale und Risiken für die einzelnen Abteilungen sowie das gesamte Unternehmen diskutiert. Aus den Diskussionsergebnissen werden Bewertungskriterien für eine Zielpriorisierung abgeleitet. Die Berücksichtigung des gesamten Unternehmens ist bedeutsam, da

118

6

Lösungsbaustein 1: PDM-Systemeinführung

häufig Auswirkungen in anderen Abteilungen zu beobachten sind als in denjenigen, in denen das PDMS eingeführt wurde. Aus diesem Grund sind eine eindeutige, abteilungsbezogene Nutzenbewertung sowie eine Wirtschaftlichkeitsberechnung schwer durchführbar [VDI2219]. x Die Zielpriorisierung geschieht anhand einer einfach einzusetzenden Hilfsmittels wie die Präferenzmatrix [Breiing und Knosala 1997]. Die Ziele mit der höchsten Priorität werden innerhalb des PDMS-Projekts vorrangig umgesetzt, da sie die effizientsten Auswirkungen versprechen. Jedes operative Ziel wird auf seine grundsätzliche Umsetzungseignung durch ein PDMS überprüft. Das Ergebnis wird als qualitative PDMSFähigkeit bezeichnet und beschreibt eine prozentuale Zielzuordnung zu den einzelnen PDMS-Einflussgrößen. Ist eine solche Zuordnung nicht möglich, kann das Ziel innerhalb des PDMS-Projekts nicht erreicht werden. Es muss entweder umformuliert werden oder bleibt unberücksichtigt. Je mehr Ziele den PDMS-Einflussgrößen zugeordnet werden können, desto höher ist die qualitative PDMS-Fähigkeit. Damit sind sowohl die strategischen als auch die operativen Ziele in der CSC dokumentiert. Tabelle 6-1 Exemplarische Ziele mittelständischer Unternehmen, die durch den Einsatz eines PDMS unterstützt werden können Zielsetzungen auf operativer Ebene

Bewertungskriterium/Kennzahl

x schnelle und effiziente Suche

x Suchzeiten / Trefferquote

x Steigerung von Prozesseffizienz

x Durchlaufzeit einzelner Aktivitäten

x Steigerung der Prozesstransparenz

x Art und Anzahl vorhandener Prozessteilschritte

x Reduzierung der Prozesskosten

x vorhandene Prozesskosten

x Reduzierung der Fehlerhäufigkeit

x Anzahl der Medienbrüche

x Beherrschung von Varianten

x Anzahl vorhandener Varianten

x Reduzierung von Prozessschnittstellen

x Anzahl der Prozessschnittstellen

x eindeutige Verantwortlichkeiten

x Anzahl definierter Rollen

x Verbesserung der Produktkonfiguration

x Anzahl vorhandener Referenzgeräte

x automatische Ausleitung von Katalogen, Produktunterlagen etc.

x zeitlicher Anteil der Unterlagenerstellung

x durchgängige Dokumentation

x Zertifizierungskriterien ISO 9000ff

x …

x …

6.4

Die Untersuchungsphase

119

Einige typische operative Zielsetzungen in mittelständischen Unternehmen sind in Tabelle 6-1 dargestellt [Feldhusen et al. 2005c]. Bei der Formulierung der strategischen bzw. operativen Ziele ist darauf zu achten, dass sie durch entsprechende Kriterien bzw. Kennzahlen auch zu bewerten sind. Nur durch diese Messbarkeit sind eine Überprüfung der Zielerreichbarkeit und das Ableiten entsprechender Verbesserungsmaßnahmen überhaupt möglich. So kann bspw. eine ProzessEffizienzsteigerung durch die Messung der Durchlaufzeit oder eine Verbesserung der Prozesstransparenz durch die Anzahl der MitarbeiterRückfragen innerhalb bestimmter Aktivitäten erfasst werden. Das siebte Kapitel geht auf die Bewertungskriterien vertieft ein. Aus den umsetzbaren Zielen werden Anforderungen formuliert, die bei Abschluss des PDMS-Projekts erfüllt sein müssen. Das Ergebnis ist ein erstes Lastenheft. Dieses bildet den Kern der fortlaufenden Projektdokumentation durch die Anforderungsliste. Damit ist zu jedem Zeitpunkt eine lückenlose Nachvollziehbarkeit des Projekts und der zugehörigen Entscheidungen gegeben. Verantwortlich für die Anforderungsliste und das Lastenheft ist die Projektleitung. Unter Berücksichtigung der Projekt-Rahmenbedingungen und der Anforderungsliste wird ein erster Projektplan erstellt. Zu diesem Zeitpunkt stellt er die prinzipielle Vorgehensweise innerhalb des PDMS-Projekts dar. Da er die Umsetzung der gesamten Projekttätigkeiten steuert und kontrolliert, muss der Projektplan mit dem Projektfortschritt abgeglichen werden. Dies geschieht fortlaufend während der nachfolgenden Einführungsaktivitäten. Mit den identifizierten Anforderungen, Potenzialen und Risiken kann eine qualitative Projekteinschätzung vorgenommen werden. Sie enthält alle Ergebnisse bis zum augenblicklichen Projektzeitpunkt, die das Unternehmensmanagement für die Entscheidung zur Einleitung des zweiten Arbeitsschritts benötigt. Diese sind x die Anforderungsliste und der Projektplan; x das erwartete Risiko, der geschätzte Aufwand und erwartete Nutzen des PDMS-Projekts sowie x die qualitative PDMS-Fähigkeit. Die Projekteinschätzung dient als Entscheidungsgrundlage, ob das PDMSProjekt aufgrund falscher Zielerwartungen des Unternehmens oder unrealistischer Rahmenbedingungen beendet wird. Sind die präsentierten Ergebnisse als Entscheidungsgrundlage unzureichend, werden sie durch eine Iteration präzisiert. Dabei werden entweder der gesamte erste Arbeits-

120

6

Lösungsbaustein 1: PDM-Systemeinführung

schritt oder nur einzelne Aktivitäten durchlaufen. Dieser Iterationsgedanke ist für alle Arbeitsschritte gültig. Bei einer positiven Entscheidung wird der zweite Arbeitsschritt eingeleitet. Um eine durchgängige Projektdokumentation zu gewährleisten, werden sämtliche Ergebnisse in einem Abschlussbericht zusammengefasst. Dadurch können zu einem späteren Zeitpunkt neben den Ergebnissen sämtliche Projektaktivitäten nachvollzogen werden. Der Abschlussbericht bildet neben der Anforderungsliste das Eingangsdatum für den zweiten Arbeitsschritt. Hilfsmittel zur Gewichtung der Anforderungen: Die Präferenzmatrix Das wichtigste Ergebnis des ersten Arbeitsschritts sind diejenigen Ziele, die durch die Einführung eines PDMS erreicht werden sollen. Ihre Erfassung geschieht einerseits durch Expertengespräche mit dem Management, andererseits durch Workshops mit dem Kernteam bzw. ausgewählten Mitarbeitern. Eine wesentliche Anforderung seitens der Geschäftsführung an das PDMS-Projekt stellt eine schnelle Umsetzung und Realisierung dar. Da die Zeit begrenzt ist und meist die Genehmigung der nachfolgenden Projektphase von schnellen, erfolgreichen Umsetzungsergebnissen abhängt, müssen diejenigen Ziele identifiziert werden, welche den Nutzen am besten demonstrieren (auch als Quick Wins bezeichnet). Die einzelnen Ziele müssen folglich priorisiert, d. h. in eine Reihenfolge ihrer Umsetzungsdringlichkeit gebracht werden. Dies geschieht durch den Einsatz der Präferenzmatrix, wie sie in Abb. 6-6 dargestellt ist. Die Vorgehensweise gliedert sich in zwei Schritte: Zunächst werden sämtliche Ziele paarweise miteinander verglichen. Anschließend werden sie gewichtet. Dadurch ergibt sich automatisch die gewünschte Priorisierung. Die Präferenzmatrix besteht auf ihrer linken Seite aus einer Auflistung der operativen Ziele bzw. den aus ihnen abgeleiteten Bewertungskriterien. Jedem Kriterium ist dabei ein Kennbuchstabe zugeordnet. Es werden jeweils zwei Kriterien miteinander verglichen im Sinne von „Bewertungskriterium a ist wichtiger gegenüber Bewertungskriterium c“. In Abb. 6-6 ist ersichtlich, dass von den beiden Zielsetzungen „administrative Möglichkeit zur Eigenpflege des PDMS“ und „Qualität des Produktdatenmodells“ das Ziel einer möglichst hohen Modellqualität als bedeutsamer eingestuft wurde. Der Kennbuchstabe „c“ wird an der Schnittstelle beider Zielsetzungen ein-

6.4

Die Untersuchungsphase

121

getragen. Sie ist in der Abbildung durch die verstärkte Umrandung gekennzeichnet. So wird weiter verfahren, bis sämtliche Ziele bzw. Kriterien gegeneinander paarweise verglichen wurden und die rechte Spitze der Matrix komplett ausgefüllt ist.

Abb. 6-6 Präferenzmatrix mit exemplarischen Bewertungskriterien und Skala zur Normierung

Anschließend werden die ausgefüllten Matrizen sämtlicher Bewertungsteilnehmer durch den Projektleiter ausgewertet, gewichtet und priorisiert. Dieser zweite Schritt geschieht mit der in Abb. 6-6 gezeigten Tabelle zur Ermittlung der Gesamtwertigkeit. In ihr wird die Häufigkeit aller Zielsetzungen aus dem ersten Schritt eingetragen. Anschließend erfolgt eine Normierung aller Ziele bzw. Bewertungskriterien. Diese Normierung wird später für die Anwendung der CSC benötigt und sollte deshalb bereits an dieser Stelle durchgeführt werden. Der Vorteil dieser Vorgehensweise liegt in ihrer einfachen Durchführung. In der Praxis hat es sich gezeigt, dass sich die Präferenzmatrix zur Priorisierung von maximal 10 Zielsetzungen eignet. Bei einer höheren Anzahl gehen Übersichtlichkeit und Handhabbarkeit verloren. Zusätzlich haben psychologische Untersuchungen ergeben, dass Menschen nur eine eingeschränkte Koordinationsfähigkeit bei der gleichzeitigen Umsetzung mehrerer Ziele besitzen [Zimbardo 1992; Asendorpf 1996]. Ein Erfahrungswert aus durchgeführten Industrieprojekten zeigt, dass sich auf die Umsetzung der ersten drei priorisierten Ziele während der Systemeinführungsphase konzentriert werden sollte. Einerseits versprechen diese für die Abteilung

122

6

Lösungsbaustein 1: PDM-Systemeinführung

bzw. das Unternehmen den größten Mehrwert, andererseits können diese während der zeitlich begrenzten Dauer des PDMS-Projekts auch hinreichend umgesetzt werden. Alle weiteren Ziele werden in der folgenden Systembetriebsphase realisiert. Von besonderer Bedeutung sind dabei ein permanenter Zielabgleich sowie eine eventuelle Zielanpassung an die PLM-Strategie. Alternativ kann zur Zielpriorisierung anstelle der Präferenzmatrix auch das Rangfolgeverfahren eingesetzt werden [Breiing und Knosala 1997]. 6.4.2 Arbeitsschritt 2: Erstellung der IST-Analyse und Ableitung des SOLL-Konzepts Der zweite Arbeitsschritt besitzt den Charakter einer detaillierten Machbarkeitsstudie des PDMS-Projekts. Dazu wird eine IST-Analyse durchgeführt. Mit ihr werden die vorhandenen D&I-Flüsse entlang des PEP erfasst. Anhand der Analyseergebnisse lassen sich mehrere mögliche Umsetzungsszenarien ableiten. Die Umsetzungsszenarien beschreiben mögliche Vorgehensweisen bei der Systemeinführung bspw. bezüglich der Einführungstiefe des PDMS oder des betrachteten PEP-Abschnitts. Damit lassen sich Aussagen hinsichtlich des Aufwandes, der Risiken und des Nutzens treffen. Anschließend wird ein Szenario ausgewählt, das die Anforderungen des ersten Arbeitsschritts hinreichend erfüllt. Das ausgewählte Szenario stellt das umzusetzende SOLL-Konzept dar. Die durchzuführenden Aktivitäten des zweiten Arbeitsschritts zeigt Abb. 6-7. Während des zweiten Arbeitsschritts werden die gewonnenen Ergebnisse mittels der CSC begleitend bewertet. Dies lässt eine Aussage hinsichtlich der vorhandenen D&I-Flüsse und der Implementierungseignung ihrer beschreibenden Modelle zu. Die qualitativen Aussagen des ersten Arbeitsschritts erhalten einen quantifizierbaren Charakter. Ergänzend wird eine Wirtschaftlichkeitsberechnung für das ausgewählte Umsetzungsszenario durchgeführt. Die Ergebnisse des zweiten Arbeitsschritts bilden das gewählte Umsetzungsszenario, die aktualisierte Anforderungsliste, der angepasste Projektplan sowie die IST-PDMS-Fähigkeit. Letztere beschreibt die augenblickliche Unternehmenseignung aufgrund der gewonnenen Analyseergebnisse und der gewünschten Zielsetzungen (siehe Abschn. 4.5). Auf dieser Grundlage wird die Entscheidung getroffen, ob die zweite Projektphase durchgeführt wird. Dies beinhaltet auch die Entscheidung, ob für das weitere Vorgehen bei externen PDM-Systemanbietern angefragt oder die vor-

6.4

Die Untersuchungsphase

123

handenen Software-Applikationen durch die unternehmenseigene ITAbteilung modifiziert werden sollen. Bei einer negativen Entscheidung ist das PDMS-Projekt beendet. In diesem Fall können die gewonnenen Analyseergebnisse als Grundlage für weiterführende QM-Maßnahmen im Unternehmen genutzt werden. In beiden Entscheidungsfällen ist die Untersuchungsphase abgeschlossen. Arbeitsschritt 2

CSC

nein

Arbeitsschritt 2: IST-Analyse

Arbeitsschritt 2: SOLL-Konzept

Durchführung IST-Analyse

Entwicklung von PDMS-Einführungsszenarien

Quantitative Bewertung PDMSFähigkeit

Aussage ausreichend?

CSC

ja

Szenarienbewertung

Szenarien ausreichend?

nein

ja

Szenariovorstellung und -auswahl

Nacharbeit erforderlich?

ja

nein Nächste Projektphase?

nein

Projektende

ja Arbeitsschritt 3: Modellerstellung

CSC

Bewertung mittels Capability Scorecard (CSC)

Abb. 6-7 Vorgehensweise des zweiten Arbeitsschritts zur Erfassung des ISTZustands und der Ableitung möglicher SOLL-Szenarien. Mit diesem Arbeitsschritt werden auch die PDMS-Einflussgrößen unternehmensindividuell erfasst

124

6

Lösungsbaustein 1: PDM-Systemeinführung

Durchführung der IST-Analyse Die vollständige Aufnahme und Dokumentation sämtlicher relevanter Daten ist entscheidend für die Bewertung der PDMS-Fähigkeit [Feldhusen et al. 2006b]. Dazu wird eine IST-Analyse durchgeführt. Ihr Ziel ist die Erfassung der für die Produktentwicklung bedeutsamen D&I-Flüsse innerhalb des Unternehmens. Die Effizienz der D&I-Flüsse ist dabei nicht nur von den repräsentierenden Produktdaten-, Prozess- und Rollenmodellen abhängig, sondern auch von der vorhandenen IT-Systemlandschaft. Vor dem Hintergrund des praxisnahen Einsatzes wurde eine einfache Durchführung der Daten- und Informationsermittlung als wesentliche Unternehmensanforderung identifiziert. Dabei sind hauptsächlich zwei Problemkreise angesprochen, die eng miteinander verknüpft sind. Es handelt sich um die Verfügbarkeit der relevanten Daten („Welche Daten brauche ich?“) sowie den Umfang der Datenermittlung („Wie bekomme ich diese Daten und welcher Aufwand ist dafür notwendig?“). Idealerweise erfasst eine Vorgehensweise alle notwendigen Daten mit hinreichendem Ermittlungsaufwand. Die in Abb. 6-8 dargestellte Vorgehensweise erfüllt diese Anforderung.

Abb. 6-8 Allgemeine Top-Down-Vorgehensweise zur Datenermittlung auf den unterschiedlichen Abstraktionsebenen

6.4

Die Untersuchungsphase

125

Die Vorgehensweise folgt einem Top-Down-Ansatz vom Abstrakten zum Konkreten. Da viele Unternehmen ihre Ablauforganisation auf Geschäftsprozessebene in hinreichender Qualität dokumentiert haben [Wassermann 2004], wird der PEP als Ausgangsbasis für die Datenerfassung verwendet. Der PEP ist häufig in Form eines groben Ablaufdiagramms visualisiert und in einzelne Teilprozesse gegliedert. Falls dieses Ablaufdiagramm unzureichend ist, kann es mit Hilfe des Meilenstein-Konzepts überprüft und ggf. verbessert werden. Dies geschieht auf den ersten beiden Prozessebenen durch Expertengespräche. Die Zielsetzung jedes Teilprozesses und seine zugehörigen Prozessdaten werden in das Prozessaufnahmeblatt eingetragen, welches im nachfolgenden Abschnitt vorgestellt wird. Dabei ist jedem Teilprozess ein spezifisches Prozessaufnahmeblatt zugeordnet. Da die Ablaufdaten oftmals widersprüchlich und/oder unvollständig sind, werden sie durch Mitarbeiterinterviews ergänzt. Dazu werden die Teilprozesse in einzelne Teilprozessschritte aufgeteilt. In jedem Teilprozessschritt wird eine zielgerichtete Tätigkeit bzw. Aktivität ausgeführt (siehe Abschn. 4.2). Es werden diejenigen Mitarbeiter befragt, die an den entsprechenden Aktivitäten beteiligt sind. Die Interviews werden anhand eines Interviewfragebogens am Mitarbeiterarbeitsplatz durchgeführt und stellen sicher, dass sämtliche Daten auf der Vorgangsebene erfasst werden. Die Interviewergebnisse werden ebenfalls im Prozessaufnahmeblatt dokumentiert. Sie ergänzen die bereits vorhandenen Daten der Teilprozessebene. Durch diese Vorgehensweise werden auch vorhandene Datenmodelle erfasst und ergänzt. Auf dieser Datengrundlage können die D&I-Flüsse erstellt werden. Dazu werden die gesammelten Daten in die tabellarische Form einer D&I-Liste gebracht und durch eine D&I-Landkarte visualisiert [Feldhusen et al. 2005b]. Mit dieser Vorgehensweise zur Datenerfassung der Ablauforganisation ergeben sich zwangsläufig die korrespondierenden Daten der Aufbauorganisation und der Produkte. So werden bspw. bei der erfassten Aktivität „Erstellung des Lastenhefts“ automatisch die beteiligten Akteure als Tätigkeitsverantwortliche sowie die zugehörige Auftragsnummer als Produktdatum aufgenommen. Diese Daten sind nicht nur für die Modellbewertung bedeutsam, sondern auch für die spätere Implementierung auf (system-)technischer Ebene. Insofern kann die bereits angesprochene vertiefte Datenerfassung für das Modell-Reengineering bereits in diesem Arbeitsschritt durchgeführt werden. Diese direkte Vorgehensweise ist in Abb. 6-8 durch weiße Pfeile dargestellt. Ergänzt wird die Datenerfassung in beiden Arbeitsschritten durch die begleitende Analyse vorhandener Dokumente wie Entwicklungs- oder

126

6

Lösungsbaustein 1: PDM-Systemeinführung

Konstruktionshandbücher, Werksnormen, Organigramme, Arbeitsplatzbeschreibungen sowie Unterlagen aus der Marketingabteilung (Imagebroschüren, Produktkataloge oder Projektstudien) und dem Qualitätsmanagement [Fischer u. Scheibeler 2003; Walther 2005]. Hilfsmittel zur Gliederung auf Teilprozessebene: MeilensteinKonzept Damit vorhandene Geschäftsprozesse wie der PEP überhaupt analysiert werden können, müssen sie in einzelne Teilprozesse heruntergebrochen werden. Dabei wird unter einem Teilprozess eine Folge von einzelnen Prozessschritten bzw. Aktivitäten verstanden, die inhaltlich einem bestimmten Ablauf- bzw. Projektziel, so genannten Prozess-Gates, zugeordnet werden können. Die terminliche Erreichung dieses Ziels wird innerhalb des übergeordneten Geschäftsprozesses durch Meilensteine definiert und festgelegt. Anhand dieser Zusammenhänge können die einzelnen Teilprozesse erstmalig erfasst oder bereits vorhandene Prozessdokumentationen überprüft bzw. ergänzt werden.

Abb. 6-9 Meilenstein (MS)-Konzept zur Ablauferfassung auf Teilprozessebene

Im Mittelpunkt des Meilenstein-Konzepts stehen die einzelnen Meilensteine, die der zu analysierende Geschäftsprozess erreichen und durchlaufen muss. Die einzelnen Fragestellungen hinsichtlich der Teilprozessschritte bzw. ihrer zugehörigen Aktivitäten sind in Abb. 6-9 gezeigt. Da sie in enger Verbindung mit der Datenaufnahme mittels des Prozessaufnahmeblatts stehen, wird an dieser Stelle auf den nachfolgenden Abschnitt verwiesen.

6.4

Die Untersuchungsphase

127

Von besonderer Bedeutung ist bei der Anwendung des MeilensteinKonzepts sein Ergebnis als tabellarische Darstellung des Geschäftsprozesses und seiner relevanten Meilensteine. Diese Meilensteine definieren unterschiedliche Prozessphasen, welche A-Phase, B-Phase etc., Entwicklungsphase, Serienanlauf etc. oder ähnliche Bezeichnungen besitzen. Diese Darstellungsform findet sich in vielen Unternehmen aufgrund der Anforderungen, wie sie bspw. nach [ISO 9000] bzw. [ISO 9004] gefordert sind. Damit können die vorhandnen Geschäftsprozessdokumentationen schnell und einfach überprüft werden. Hilfsmittel zur Datenaufnahme auf Teilprozessebene: Prozessaufnahmeblatt Das Prozessaufnahmeblatt stellt neben der Anforderungsliste das wichtigste Dokument innerhalb des PDMS-Projekts dar. Es dient als Informationsbasis zwischen den Projektbeteiligten sowie als Grundlage für die spätere Erstellung bzw. Überarbeitung der Modelle. Abbildung 6-10 zeigt ein exemplarisch ausgefülltes Aufnahmeblatt für den Teilprozess „Erzeugung von Mustern“ mit der Aktivität „Erstellung des Lastenheftes“ und einer integrierten Rollen-Organisations-Matrix.

Abb. 6-10 Prozessaufnahmeblatt mit integrierter Rollen-Organisationsmatrix

Im Prozessaufnahmeblatt sind folgende Daten dokumentiert:

128

6

Lösungsbaustein 1: PDM-Systemeinführung

x der übergeordnete Geschäftsprozess und seine Prozessnummer, auf welche seine zugehörigen Teilprozesse eindeutig referenziert werden können; x die Teilprozess-Bezeichnung einschließlich einer eindeutigen Teilprozess-Nummer, auf welche sich vorherige oder nachfolgende Teilprozesse referenzieren können; x das Ziel bzw. das Ergebnis, welches mit dem Teilprozess erreicht werden soll; x der namentliche Prozessinhaber, der für den Teilprozess verantwortlich ist; x die Beschreibung der einzelnen Aktivitäten, aus denen sich der Teilprozess zusammensetzt (Prozessbeschreibung); x die benötigten Eingangsdaten einschließlich der zugehörigen Datenquelle(n) und der vorhandenen Datenform. Zur Erfassung von Datenredundanzen wird zwischen analogen Daten (bspw. Briefe, Faxe oder Notizen) und digitalen Datenobjekten (Dateien CAD-Modellen oder EMails) unterschieden. Damit lassen sich Medienbrüche zwischen den einzelnen Teilprozessschritten identifizieren; x die erzeugten Ausgangsdaten einschließlich der nachfolgend adressierten Teilprozesse, die an der Prozesstätigkeit beteiligten Mitarbeiter und die eingesetzten Hilfsmittel. Im exemplarischen Teilprozessschritt der Abb. 6-10 verbleibt das Lastenheft beim Konstrukteur. Ein Ausgangsdatum wird erst in einer späteren Aktivität erzeugt. Mittels der schematisch dargestellten Rollen-Organisations-Matrix ist erkennbar, welche Abteilung in welcher Rolle am jeweiligen Prozessschritt beteiligt ist. So zeigt die Matrix in Abb. 6-10, dass der Vertrieb aufgrund entsprechender Kundenwünsche ein neues Lastenheft erstellt. Anschließend erhält es der Projektleiter entweder als Datei oder in ausgedruckter Form. Von ihm muss es verantwortlich geprüft werden, wobei auch ein Mitarbeiter aus der Konstruktion beteiligt sein kann. Die Rollen-Organisations-Matrix dient ausschließlich der Übersicht zwischen dem betrachteten Teilprozess und den zugehörigen beteiligten Unternehmensinstanzen. Sie ersetzt nicht das Rollenmodell. Hilfsmittel zur Datenaufnahme auf Vorgangsebene: Interviewfragebogen Grundlage der IST-Analyse auf Teilprozessebene bilden vorhandene Ablaufdokumentationen im Unternehmen. Sie wurden zumeist im Rahmen entsprechender Zertifizierungen erstellt. Der durch die Mitarbeiter „gelebte“ Ablauf unterscheidet sich oftmals erheblich von den dokumentierten

6.4

Die Untersuchungsphase

129

Vorgehensweisen. Seine Erfassung und die Berücksichtigung durch Mitarbeiterinterviews ist für eine spätere Akzeptanz des PDM-Systems erfolgsentscheidend [Hansel u. Lomnitz 2003; Pusch 2003]. Dabei dienen die erfassten informellen Prozesse lediglich als Orientierung für das Prozess-Reengineering; keinesfalls dürfen sie die alleinige Grundlage zur Definition neuer Abläufe bilden. Jeder Teilprozess kann in einzelne Teilprozessschritte gegliedert werden. In jedem Teilprozessschritt werden zielgerichtete Tätigkeiten bzw. Aktivitäten durchgeführt. Für ihre effiziente Durchführung werden spezielle Eingangsdaten benötigt. Aus der Aktivität resultieren Ausgangsdaten, die wiederum als Eingangsdaten von nachfolgenden Aktivitäten zwingend benötigt werden. Aus der Summe der einzelnen Aktivitäten resultiert der D&I-Fluss des gesamten Teilprozesses. Seine Effizienz auf der Vorgangsebene ist dadurch gekennzeichnet, dass sämtliche benötigten Daten vorhanden und den verantwortlichen prozessbeteiligten Akteure bekannt sind. Ebenso dürfen keine Ablaufbrüche auftreten. Dies wird mit dem Fragebogen ermittelt, der in Abb. 6-11 gezeigt ist. Bei den Mitarbeiterinterviews werden folgende Daten aufgenommen: x Welche Funktion bzw. welche Tätigkeiten übt der befragte Mitarbeiter aus? x Welche Daten benötigt der Mitarbeiter zwingend zur Ausübung seiner Tätigkeit (Eingangsdaten) und welche Daten werden von ihm erzeugt (Ausgangsdaten)? Welche Daten unterstützen ihn bei seiner Tätigkeitsausführung? x Wie können die Daten inhaltlich beschrieben werden und in welchen Dokumenten befindet sich die Information? x Liegen die Daten in analoger (A) oder digitaler (D) Form vor? x An welchem Ort (bspw. Archiv) oder in welchem System (bspw. Datenbank) sind die Daten abgelegt? Wer kann darauf zugreifen? x Besitzt die interviewte Person Zugriffsrechte auf die benötigten Daten? Falls ja, welche? So zeigt der exemplarische Interviewfragebogen, dass der beteiligte Konstrukteur ein händisch ausgefülltes Lastenheft in Papierform (A) aus dem Vertrieb erhält. In diesem Lastenheft sind verschiedene Daten erfasst wie die Kundenwünsche, die Projektnummer oder bestehende Termine. Das Lastenheft wird entweder persönlich abgegeben oder per Hauspost gesendet. Der Konstrukteur besitzt ausschließlich Leserechte, d. h., er darf an dem Dokument keine Änderungen vornehmen. Auf der Grundlage des Lastenhefts wird eine vorhandene Stückliste händisch geändert, als digitale

130

6

Lösungsbaustein 1: PDM-Systemeinführung

Datei neu erstellt (D) und anschließend per E-Mail an den Musterbeauftragten versendet. Die händisch geänderte Stückliste wird im Projektordner abgelegt. Durch den Medienbruch ist hier ein möglicher Datenverlust wahrscheinlich, da spätere Stücklistenänderungen nicht mehr in das abgelegte Dokument eingepflegt werden.

Abb. 6-11 Interviewfragenbogen zur Erfassung der „informellen“ Mitarbeiterdaten

6.4

Die Untersuchungsphase

131

Nach Abschluss aller Interviews werden die erfassten Daten in der Datenund Informations-Liste (D&I-Liste) aufbereitet. Dies dient der Identifikation von redundanten und/oder fehlenden Daten. Die D&I-Liste stellt eine tabellarische Zusammenfassung der Interviewergebnisse dar und ergänzt als Dokument das Prozessaufnahmeblatt. Sie bildet eine wesentliche Grundlage sowohl für die Erstellung der D&I-Flüsse als auch für das Modell-Reengineering des dritten Arbeitsschritts. Ihr Aufbau orientiert sich am inhaltlichen Aufbau des Interviewfragebogens. Damit beinhaltet die D&I-Liste die Spalten x x x x x x

x x x x

Name des Interviewers; Name des interviewten Mitarbeiters; Abteilung und Funktion des interviewten Mitarbeiters; Daten(objekt)typ: Eingangsdatum, Ausgangsdatum oder arbeitsunterstützendes Datum; Inhalt des Datenobjekts wie Liefervorschrift, Kostenaufstellung, Leistungsschilddaten oder Messergebnisse; Dokumentenreferenzierung: in welchen Dokumenten befindet sich der Inhalt - bspw. in E-Mails, händischen Notizen, CAD-Zeichnungen, Normen oder Formularen; Form des Datenobjekts: analog (in Papierform) oder digital (auf einem Speichermedium); Speicherort bei digitalen Daten bzw. der Ablageort bei analogen Daten: welche Datenbank oder welcher Projektordner vorhandene Zugriffsberechtigungen des interviewten Mitarbeiters wie lesen, schreiben oder löschen; eine Spalte für Bemerkungen, die während des Interviews notiert wurden.

Mit Hilfe der beschriebenen Vorgehensweise können die modellrelevanten Daten zur Darstellung der D&I-Flüsse in ihrer Gesamtheit hinreichend genau erfasst werden. Analyse der vorhandenen IT-Landschaft Um eine Basis für den Einsatz eines PDMS zu schaffen, ist neben einer eindeutigen Datenpräsenz eine leistungsfähige IT-Infrastruktur obligatorisch. Die IT-Analyse wird im Rahmen der IST-Analyse durchgeführt. Die Vorgehensweise ist in Abb. 6-12 gezeigt.

132

6

Lösungsbaustein 1: PDM-Systemeinführung

Abb. 6-12 Top-Down-Vorgehensweise bei der Durchführung der IT-Analyse

Folgende Aspekte sind bei der IT-Analyse bedeutsam [Feldhusen et al. 2004]: x Bei der Analyse der Infrastruktur im IT-Bereich werden die Netztopologie, die vorhandene Netzwerkversorgung sowie die Anbindung der Server und Clients betrachtet. Anhand der Netztopologie sind Schwachstellen für die spätere PDMS-Anwendung bereits im Vorfeld erkennbar. Dadurch lassen sich frühzeitig Maßnahmen ergreifen, um zumindest die technische Funktion des PDMS später sicherstellen zu können. x Die Analyse der Serverstrukturen beschreibt, welche Serverapplikation auf welcher Maschine läuft und welche Funktionen diese erfüllt. Dazu werden die Verbindungen der Server untereinander ebenso betrachtet wie die Kommunikation der Applikationen miteinander. Es werden Datenschnittstellen analysiert und vorhandene Datenredundanzen identifiziert. Hier ergeben sich bereits Verbesserungsmöglichkeiten, die noch vor der Systemimplementierung umgesetzt werden können. x Die Analyse der Client-Applikationen beschäftigt sich mit der Frage, welche Applikationen auf den Clientrechnern benötigt werden und ob diese für den Betrieb eines PDMS entscheidend sind. So muss bspw. geklärt werden, welche Applikationen auf welchen Rechnern eingesetzt werden, wie die Anbindung der Rechner realisiert ist und ob die Kommunikationsfähigkeit mit einem PDMS vorhanden ist.

6.4

Die Untersuchungsphase

133

x Die Analyse der Datenstrukturen geht u. a. den Fragen nach, welche Daten zu welchem Modell gehören, an welchem Ort sie abgelegt wurden, welche Abhängigkeiten unter ihnen bestehen und ob notwendige Referenzen vorhanden sind. Diese Kenntnis ist für das ModellReengineering im dritten Arbeitsschritt bedeutsam. An dieser Stelle zeigen sich die unternehmensspezifischen Einschränkungen für die Modellierungen, da neben der Produktivität des neuen Systems auch die Migration bereits bestehender Daten gewährleistet sein muss. Die Analyseergebnisse können als IT-Systemlandkarte visualisiert werden (Abb. 6-13). Sie stellt eine strukturelle Übersicht der aufgenommenen Datenbanken, Server, Clients und Applikationen des gesamten Unternehmens dar. Zusätzlich werden ihre datentechnischen Verbindungen untereinander sowie ihre augenblickliche Organisationszugehörigkeit erfasst. So lässt sich in Abb. 6-13 erkennen, dass CAD-Daten nicht nur im Content Management System (CMS) gespeichert werden, sondern dass auch die Betriebsmittelvorbereitung auf diese Daten zugreift und sie sogar abspeichert. Ebenfalls sind die abteilungsübergreifenden D&I-Flüsse erkennbar: Im Projekt Management System (PMS) werden Kundendaten abgefragt, die im Verkauf angelegt werden. Das CMS liefert dem Verkauf über eine Datenbank bspw. Daten hinsichtlich der möglichen Verpackungsarten bestimmter sensibler Produkte, die bei Bedarf an den Kunden weitergegeben werden können. Um die IT-Systemlandkarte zu erstellen, wird eine Gliederung nach den organisatorischen Bereichen wie Verkauf, Technischer Bereich, Einkauf, Controlling, Fertigung, Wareneingang/Produktionslager, Personalwesen, Versand/Vertriebslager und Qualitätssicherung empfohlen. Damit können mögliche Planungen im IT-Bereich abteilungsübergreifend unterstützt werden, die im Zusammenhang mit der PDMS-Einführung stehen. Mit den ausgefüllten Prozessaufnahmeblättern für jeden Teilprozess, der D&I-Liste und der IT-Landkarte liegen sämtliche notwendigen Daten vor, welche die augenblicklichen D&I-Flüsse des Unternehmens repräsentieren. Ein exemplarischer, vereinfachter D&I-Fluss ist in Abb. 6-14 schematisch dargestellt.

134

6

Lösungsbaustein 1: PDM-Systemeinführung

Abb. 6-13 Beispielhafte IT-Systemlandkarte eines mittelständischen Unternehmens, gegliedert nach einzelnen Abteilungen

In dem dargestellten Beispiel nimmt ein Mitarbeiter des Vertriebs handschriftlich Kundendaten für ein bestelltes Produkt auf. Anschließend legt er im Projekt Management System (PMS) das dazugehörige Projekt an. Typische Daten sind die Abschätzung der zeitlichen Ressourcen, Termine aufgrund der Kundenvorgaben oder Vorschläge zur Projektteamzusammensetzung einschließlich eines geeigneten Projektleiters. Das PMS generiert ebenfalls relevante Daten wie die Projektnummer. Das dazugehörige Projektfreigabeblatt wird ausgedruckt, vom Vorgesetzten unterschrieben und geht per Hauspost an den Projektleiter. Der Projektleiter legt im Content Management System (CMS) unter der vorgegebenen Projektnummer, das zugehörige Lastenheft an; gleichzeitig benachrichtigt er sein zugewiesenes Projektteam entweder mündlich, per Telefon oder per E-Mail. Der

6.4

Die Untersuchungsphase

135

Konstrukteur lädt sich das Lastenheft aus dem CMS herunter und erstellt auf seiner Grundlage die Stückliste sowie das zugehörige CAD-Modell des bestellten Produkts. Sämtliche Daten speichert er zurück in das CMS. Vertrieb Kundendaten (A)

Projektfreigabeblatt (A)

Projektleiter

PMS

Lastenheft (D)

Benachrichtigung (D/A)

CMS Daten- & Informationsflüsse (D&I-Flüsse)

Stückliste (D) CAD-Modell (D)

Lastenheft (D)

A: Daten liegen in analoger Form vor D: Daten liegen in digitaler Form vor allgemeine Rollenbezeichnung Konstrukteur

Abb. 6-14 Vereinfachte Darstellung einer D&I-Flusses

Anhand dieses einfachen Beispiels lässt sich die Komplexität eines einzelnen realen D&I-Flusses erahnen. Falls mehrere D&I-Flüsse zusammenwirken, werden ihre Wechselwirkungen und Zusammenhänge schnell abstrakt. Um vorhandenes Verbesserungspotenzial zu identifizieren, ist eine Visualisierung der D&I-Flüsse hilfreich. Das zugehörige Instrument ist die Daten- und Informationslandkarte (D&I-Landkarte). Die D&I-Landkarte kann entweder systemorientiert oder rollenorientiert aufgebaut werden. In beiden Fällen wird für jedes einzelne Datum sein Erzeugungsursprung, sein Bestimmungsort, sein aktueller Speicherort sowie sein Inhalt dargestellt. Wird dies für jedes Datum durchgeführt, so ergibt sich die grafische Darstellung der D&I-Flüsse in Form der D&I-Landkarte. Dadurch können System-, Medien- und Ablaufbrüche innerhalb der D&IFlüsse einfach identifiziert werden. Ebenfalls sind Schnittstellenbrüche zu anderen Abteilungen erkennbar. An diesen Stellen befindet sich Verbesserungspotenzial zur Ablauf- und zur Modelloptimierung. Den Ausschnitt einer vollständigen D&I-Landkarte, wie sie in einem Industrieprojekt erstellt wurde, zeigt Abb. 6-15.

136

6

Lösungsbaustein 1: PDM-Systemeinführung

Abb. 6-15 Ausschnitt einer realen D&I-Landkarte aus einem Industrieprojekt

Die identifizierten Ablauf- und Systembrüche stellen ein erstes Analyseergebnis dar. Dieses ist jedoch für eine Aussage hinsichtlich der Umsetzungseignung vorhandener Modelle und der Ableitung konkreter Verbesserungsmaßnahmen zu ungenau. Deshalb wird eine quantitative Abschätzung der IST-PDMS-Fähigkeit mittels der CSC durchgeführt. Damit werden vorhandene Problemfelder, ihre Auswirkungen auf einen PDMS-Einsatz sowie abgeleitete Verbesserungsaktivitäten ermittelt. Diese Erkenntnisse dienen als Grundlage zur Erstellung von möglichen PDMSEinführungsszenarien. Falls die aufgenommenen Daten für die Ermittlung der IST-PDMSFähigkeit unzureichend waren, muss die IST-Analyse erneut durchgeführt werden. Andernfalls ist die IST-Analyse abgeschlossen. Erstellung des SOLL-Konzepts Auf der Grundlage der IST-Analyseergebnisse werden mögliche PDMSEinführungsszenarien ermittelt. Dies geschieht mit Hilfe der Szenariotechnik [Kramer u. Kramer 1997; Pahl et al. 2005]. Mit ihrer Hilfe werden mögliche Einführungsstrategien durchdacht und durch bildhafte Szenarien beschrieben. Obwohl sich die einzelnen Szenarien in Abhängigkeit der Analyseergebnisse unternehmensindividuell unterscheiden, können generell vier

6.4

Die Untersuchungsphase

137

grundlegende Einführungsstrategien verfolgt werden [Feldhusen et al. 2004]. Sie werden nachfolgend erläutert. Szenario 1 – „alles bleibt, wie es ist“ In diesem (Extrem-)Szenario finden keine Änderungen im Unternehmen statt. Ein PDMS wird nicht eingeführt. Dieses Szenario zeigt Abb. 6-16.

Abb. 6-16 Schematische Darstellung des Einführungsszenarios 1

Das Szenario besitzt, obwohl auf den ersten Blick nicht erkennbar, durchaus seine Betrachtungsberechtigung. Zu diesem Projektzeitpunkt wird spätestens deutlich, ob die gewünschten Unternehmensziele innerhalb einer PLM-Strategie durch die PDM-Systemeinführung überhaupt realisierbar sind. Dabei sind zwei Ergebnisse möglich: Wenn eine Zielerreichung als realistisch angesehen wird, wird eines der anderen Szenarien als geeignete Umsetzung gewählt. Wird die Zielereichung aufgrund bspw. zu hoher Kosten oder zu tiefer Eingriffe in die Unternehmensabläufe nicht oder als zu aufwändig gesehen, so wird das PDMS-Projekt nach diesem Arbeitsschritt abgebrochen. Das Szenario 1 ist in diesem Fall bereits umgesetzt, da es die augenblickliche, unveränderte Unternehmenssituation beschreibt – mit allen bestehenden Vor- und Nachteilen. Allerdings haben Unternehmen durch die Ausführung der beiden ersten Arbeitsschritte einen augenblicklichen Überblick hinsichtlich ihrer Produkte sowie ihre Ablauf- und Aufbauorganisation. Daraus kann die Frage abgeleitet werden, inwiefern das Management ihr Unternehmen für zukünftige Herausforderungen des Marktes aufgestellt sieht. Die Antwort auf diese Frage bildet die Grundlage für einen möglichen notwendigen Hand-

138

6

Lösungsbaustein 1: PDM-Systemeinführung

lungsbedarf; der Durchführungsaufwand der Untersuchungsphase des PDMS-Projekts war folglich nicht umsonst. Szenario 2 – Funktionalitätserweiterung In diesem Szenario werden die bestehenden IT-Systeme um PDMSFunktionalitäten erweitert. Dies wird durch die unternehmenseigenen ITSpezialisten durchgeführt. Es findet eine Integration von Daten und Anwendungsfunktionalitäten unterschiedlicher Softwareprogramme statt. Branchenspezifische Sonderapplikationen wie spezielle Messprogramme und deren Datenbanken bleiben von der Integration unberührt. Abbildung 6-17 zeigt schematisch Szenario 2. Die Erfahrung hat gezeigt, dass dieses Szenario häufig von der unternehmenseigenen IT-Abteilung favorisiert wird. Die Umsetzung dieses Szenarios verlangt jedoch nicht nur IT-spezifische Fähigkeiten zur Implementierung bestimmter Softwarefunktionalitäten, sondern auch ein Verständnis für die Aufbau- und Ablauforganisation des Unternehmens sowie der Produkte i. S. der PLM-Strategie (siehe hierzu Abschn. 6.2.1). Um die Projektkosten im Bereich Personal, Training und Consulting möglichst niedrig zu halten, müssen die IT-Mitarbeiter entsprechend geschult werden. Als gute Alternative hat sich die Beratung durch einen neutralen, externen Berater erwiesen. Unternehmenseigene, spezialisierte Mitarbeiter müssen in jedem Fall eingebunden werden. Dadurch wird der Aufbau unternehmensinternen Know-hows gewährleistet.

Abb. 6-17 Schematische Darstellung des Einführungsszenarios 2

6.4

Die Untersuchungsphase

139

Szenario 3 – PDMS-Einführung Ein PDMS wird eingeführt und umfasst als gemeinsame Benutzerschnittstelle sämtliche Systemanwendungen, deren Funktionalitäten im Systemhintergrund aktiv bleiben. Die Anwender arbeiten ausschließlich über die grafische Benutzeroberfläche des PDMS. Sämtliche Anwendungen werden über eine einzige Benutzeroberfläche gestartet, genutzt und beendet. Einzige Ausnahme bilden Sonderapplikationen und deren Datenbanken (siehe Abb. 6-18). Dieses Szenario wird zur Umsetzung in mittelständischen Unternehmen empfohlen, da es einen Großteil der strategischen Zielsetzungen (siehe Kap. 2) erfüllt. Als vorteilhaft erweist sich die zielgerichtete Einführung und Umsetzung des PDMS durch die Anbieter oder Softwarehäuser; nachteilig ist die dazu notwendige Einbindung von außenstehenden, „unternehmensfremden“ Beratern (vgl. Abschn. 4.4). Auch bei diesem Szenario wird die Einbindung eines neutralen, externen Beraters empfohlen, der die Wahrung der Unternehmensbedürfnisse und -wünsche sicherstellt [Gebhardt, 2007].

Abb. 6-18 Schematische Darstellung des Einführungsszenarios 3

Szenario 4 – „schöne neue Welt“ Das eingeführte PDMS übernimmt sämtliche Anwendungsfunktionalitäten komplett. Die bisherigen Systemanwendungen mit Ausnahme der Sonder-

140

6

Lösungsbaustein 1: PDM-Systemeinführung

applikationen werden nicht mehr benötigt. In Abb. 6-19 ist Szenario 4 gezeigt.

Abb. 6-19 Schematische Darstellung des Einführungsszenarios 4

Das (Extrem-)Szenario 4 ist diejenige Situation, die von Systemanbietern und Softwarehäusern, häufig im Rahmen einer Verkaufspräsentation, versprochen wird. Theoretisch sind heute die technischen Möglichkeiten vorhanden; in der Praxis jedoch ist diese ehrgeizige Vision bei der Systemeinführung in mittelständischen Unternehmen mit hohen Risiken behaftet. So verzögern sich Projekte dieser Dimension aufgrund inkompatibler Systemschnittstellen zu bestehenden Unternehmenssystemen oder geänderter Anforderungen an die Datenhaltung. Häufig werden lawinenartige Auswirkungen sichtbar, die bei diesem Szenario ebenfalls gelöst werden müssen. Damit steigt der zeitliche und finanzielle Kostenrahmen exponentiell an. Dies kann im schlimmsten Fall eine erhebliche Gefährdung der Unternehmensexistenz bedeuten. Derartig ambitionierte Projekte werden mittelfristig häufig abgebrochen, da für die Mitarbeiter und dem Management kein Ende in Sicht ist [McAffee 2003]. Aus diesem Grund sollte die Umsetzung von Szenario 4 zunächst eine Vision bleiben, die jedoch langfristig innerhalb des (PDMS-erfahrenen) Unternehmens evolutionär umgesetzt werden kann („Domino-Szenario“). Kurzfristig verspricht Szenario 4 gegenüber Szenario 3 keinen wesentlichen Mehrwert. Die Szenarienerstellung selbst kann zeitlich parallel zur IST-Analyse begonnen werden. Dies betrifft besonders die Erstellung der beiden Extremszenarien. Zusätzlich umsetzbare Szenarien liegen zwischen diesen beiden Extremen. Da sie auf den Analyseergebnissen aufbauen, können sie erst nach der abgeschlossenen IST-Analyse entwickelt werden.

6.4

Die Untersuchungsphase

141

Jedes ermittelte Szenario wird unter Berücksichtigung des zu erwartenden Aufwandes, Nutzens und Risikos für das Unternehmen bewertet. Dies kann bspw. mit einer Kosten-Nutzen-Analyse oder der Durchführung von Business-Cases geschehen [Schmidt 2002; Schwab 2004]. Damit wird eine Entscheidungsgrundlage für die nachfolgende Auswahl des Umsetzungsszenarios geschaffen. Kosten-Nutzen-Regelkreis Abbildung 6-20 stellt die Zusammenhänge zwischen dem Umsetzungsaufwand und den Faktoren Nutzen, Risiken sowie Kosten schematisch als Kosten-Nutzen-Regelkreis dar. Er wird für jedes der entwickelten Einführungsszenarien durchlaufen. Für die Bewertung wird das gerade betrachtete Szenario als gewünschter SOLL-Zustand nach Abschluss des PDMSProjekts angenommen. Die Ziele entsprechen den dokumentierten Anforderungen in der Anforderungsliste. Je mehr Ziele durch das betrachtete Szenario erfüllt werden, desto höher ist der entsprechende Nutzen für das Unternehmen. Dies beinhaltet auch die Erfüllung bis zu diesem Zeitpunkt unberücksichtiger Ziele, die sich aus dem durchdachten Szenario ergeben und sich als sinnvoll erweisen. Sie werden in der Anforderungsliste ergänzt.

Abb. 6-20 Der Kosten-Nutzen-Regelkreis zeigt die Zusammenhänge zwischen den Faktoren Umsetzungsaufwand, Nutzen, Ziele, Risiken und Kosten bei der Szenarienbewertung

Der eigentliche Umsetzungsaufwand ergibt sich aus dem Vergleich zwischen dem betrachteten Szenario und den Ergebnissen der IST-Analyse. Basierend auf den Analyseergebnissen wurde die IST-PDMS-Fähigkeit ermittelt. Aus ihr lässt sich mit Hilfe der Perspektiven-Reifegrade eine für diesen Teilarbeitsschritt ausreichende Aufwandsabschätzung treffen.

142

6

Lösungsbaustein 1: PDM-Systemeinführung

Die Umsetzung jeder einzelnen Maßnahme ist mit Risiken verbunden. Die Risiken werden in die Kategorien „beeinflussbar“ und „nicht beeinflussbar“ unterteilt. Zu den beeinflussbaren Risiken zählt die Einbeziehung eines externen Systemherstellers oder eine PDMSFunktionalitätenerweiterung der vorhandenen IT-Systeme. Als nicht beeinflussbares Risiko zählt bspw. die Frage, ob sich der gewählte Systemhersteller auch noch in fünf Jahren auf dem Markt befindet und den Systemsupport gewährleisten kann. Eine vertiefende Betrachtung ist durch die Anwendung von Hilfsmitteln wie der Fehler-Möglichkeiten und EinflussAnalyse (FMEA) möglich [Schwab 2004; Ophey 2005]. Das erwartete Ergebnis der umgesetzten Maßnahmen kann durch eine Kosten-Nutzen-Analyse oder eine andere Wirtschaftlichkeitsberechnung monetär überschlägig bewertet werden [Schöttner 1999; Eigner u. Stelzer 2001; Brandt 2002; VDI2219]. Überschreiten die kalkulierten Kosten die vorgegebenen Projekt-Rahmenbedingungen, besitzt dies Auswirkungen auf das betrachtete Szenario. Um die Kosten zu senken, werden oftmals Einschnitte in den Umsetzungen durchgesetzt, was zu einer Senkung des erwarteten Nutzens führt. Hier muss eine hinreichende Balance zwischen den einzelnen Faktoren gefunden werden. Die Szenarienvorstellung und die Auswahl geschehen im Rahmen eines Workshops, der von den beiden Projektleitern moderiert wird. In diesem werden die erarbeiteten Szenarien einschließlich ihres Aufwandes, Nutzen und Risiken vorgestellt und anschließend durch die Workshopteilnehmer bewertet. Dies geschieht auf der Grundlage der in Arbeitsschritt 1 erarbeiteten Bewertungskriterien. Anschließend wird das favorisierte Szenario als zu erreichendes SOLL-Konzept festgelegt. Bei der Auswahl sollen folgende Aspekte berücksichtigt werden: x Das gewählte Szenario soll die definierten Zielsetzungen sowohl des Unternehmens als auch der Anwender am besten erfüllen. x Das gewählte Szenario soll die Möglichkeiten eines PDMS umfassend unterstützen und nutzen. x Das gewählte Szenario beinhaltet die definitive weitere Vorgehensweise, ob ein externer Systemanbieter in die zweite Projektphase involviert wird. Die Workshopteilnehmer werden durch das Projektkernteam gebildet. Sie können durch Vertreter des Managements und anderer Abteilungen ergänzt werden. Diese Teilnehmerzusammensetzung stellt die Berücksichtigung sämtlicher Interessen und Sichten in Bezug auf das PDMS-Projekt sicher. Falls die Workshopteilnehmer nicht berücksichtigte Aspekte bei

6.4

Die Untersuchungsphase

143

den erstellten Szenarien feststellen, erfolgt eine iterative Nachbearbeitung. Das Workshopergebnis wird protokolliert und der Projektdokumentation beigefügt. Das Ergebnis sind bewertete Szenarien hinsichtlich ihres Umsetzungsrisikos, ihres Umsetzungsnutzens und ihres Umsetzungsaufwands. Falls das Bewertungsergebnis aufgrund ungenau beschriebener Szenarien unzureichend ist, müssen die Szenarien in einer Iteration erneut formuliert werden. Anschließend wird das Umsetzungsszenario ausgewählt, welches für die Erfüllung der definierten Ziele aus Anwender- und Managementsicht geeignet erscheint. Dies geschieht anhand der Bewertungskriterien aus dem ersten Arbeitsschritt. Das ausgewählte Szenario stellt das zu erreichende SOLL-Konzept nach Abschluss des PDMS-Projekts dar. Das ausgewählte SOLL-Szenario bildet im Rahmen der Wirtschaftlichkeitsbetrachtung die Grundlage für den Business-Case. Die Wirtschaftlichkeitsbetrachtung wird in Kap. 8 ausführlich behandelt. An dieser Stelle sei angemerkt, dass sich die beiden Extremszenarien in der Praxis häufig als unrealistisch erwiesen haben. Würde die Einführung eines PDMS nicht wenigstens theoretisch vom Management in Erwägung gezogen, so würde das Projekt über die interne Vorklärungsphase nicht hinauskommen. Dennoch besteht die Möglichkeit der Szenarienumsetzung in dem Fall, wenn ein Unternehmen die Umsetzung und Erfüllung seiner Ziele zum jetzigen Projektzeitpunkt mittels PLM als nicht möglich ansieht. Die Folge ist ein Projektabbruch. Weiterhin stellt das Szenario 4 den angestrebten Idealfall jedes Systemanbieters bzw. Softwarehauses dar. Ein vergleichbares Szenario der „schönen neuen Welt“ lässt sich in Unternehmen häufig bei der Einführung eines ERP-Systems beobachten. Aufgrund des Erreichens der ehrgeizigen Vision scheint die Einführungsphase nicht enden zu wollen. Häufig wird sie nicht sauber abgeschlossen, sondern einzelne Softwaremodule gehen bereits in die Betriebsphase über, während andere Module noch implementiert werden. Da zu diesem Projektzeitpunkt hohe finanzielle Mittel in das Projekt geflossen sind, scheut sich das Management vor einem Projektabbruch. Denselben Fehler möchte man bei der Einführung eines PDMS nicht wiederholen und verhält sich entsprechend zögerlich. In beiden beschriebenen Extremszenarien ist dabei die Frage zwischen Aufwand und Nutzen zu stellen – bei einer PDMS-Einführung steht der versprochene Nutzen (seitens der Systemanbieter) zum durchzuführenden Aufwand (seitens des mittelständischen Unternehmens) in keiner Relation zueinander. Aus diesem Grund ist eine Umsetzung des vierten Szenarios aus der praktischen Erfahrung heraus genau abzuwägen.

144

6

Lösungsbaustein 1: PDM-Systemeinführung

In der Praxis ergibt sich häufig das Szenario 3 oder Variationen davon als gewähltes Umsetzungsszenario. Auf der Grundlage des gewählten SOLL-Konzepts werden die Anforderungsliste sowie der Projektplan angepasst. Zur genauen Ermittlung der SOLL-PDMS-Fähigkeit kann bereits zum jetzigen Projektzeitpunkt eine Szenarienbewertung mittels der CSC durchgeführt werden. Der SOLLPDMS-Reifegrad bildet den Richtwert, der nach Abschluss der Umsetzungsphase erreicht werden soll. Oftmals ist eine Abschätzung des gewünschten SOLL-PDMS-Reifegrads bereits ausreichend. Zusätzlich wird eine vertiefende Wirtschaftlichkeitsberechnung für das ausgewählte SOLL-Konzept durchgeführt. Damit wird die Einhaltung der finanziellen Projekt-Rahmenbedingungen überprüft. Dies geschieht durch die Entwicklung so genannter Business Cases. Sie werden in Kap. 8 behandelt. Spätestens am Ende des vierten Arbeitsschritts (Pilotphase) muss die SOLL-PDMS-Fähigkeit ermittelt werden (vgl. Abschn. 7.9). Um eine durchgängige Projektdokumentation zu gewährleisten, werden sämtliche Aktivitäten des zweiten Arbeitsschritts in den bestehenden Abschlussbericht eingepflegt. Dadurch können zu einem späteren Zeitpunkt neben den eigentlichen Ergebnissen auch durchgeführte Änderungen und die zugehörigen Verantwortlichen nachvollzogen werden. Der erweiterte Abschlussbericht ist Bestandteil der Projektdokumentation und beinhaltet x die aktualisierte Anforderungsliste und den aktualisierten Projektplan; x die Ergebnisse der IST-Analyse einschließlich der IST-PDMSFähigkeit; x das SOLL-Konzept inklusive der SOLL-PDMS-Fähigkeit und der Umsetzungsmaßnahmen; Auf dieser Ergebnisgrundlage trifft das Unternehmensmanagement die Entscheidung, ob das PDMS-Projekt fortgesetzt wird. Bei einer positiven Entscheidung ist die Untersuchungsphase beendet und die Umsetzungsphase wird begonnen. Der bisherige Status der Projektdokumentation ändert sich vom Lastenheft in das Pflichtenheft. Dieses ist bei der Einbindung eines externen Systemherstellers am Ende des dritten Arbeitsschritts bindend. Die Entscheidung des Lenkungsausschusses hinsichtlich der Projektdurchführung bildet ebenfalls einen Bestandteil der Projektdokumentation.

6.5

Die Umsetzungsphase

145

6.5 Die Umsetzungsphase Nach der Untersuchungsphase beginnt mit dem dritten Arbeitsschritt die Umsetzungsphase. In dieser Phase stehen die Analyse vorhandener Produktdatenmodelle, Prozessmodelle und Rollenmodelle im Vordergrund. Falls diese Modelle im Unternehmen existieren, werden sie aufgrund der Ergebnisse der ISTAnalyse ergänzt oder aktualisiert; sind keine Modelle vorhanden, werden sie mit geeigneten Methoden und Hilfsmittel erstellt. Dies geschieht im dritten Arbeitsschritt. Im vierten Arbeitsschritt beginnen die pilothafte Implementierung eines ausgewählten PDMS im Unternehmen und die Implementierung geeigneter Modelle in das PDM-System. Anhand der Ergebnisse dieser Pilotphase wird entschieden, ob das System in eine unternehmensweite Betriebsphase (auch als Produktivphase bezeichnet) übergeht. Entscheidungskriterium ist der Grad der Zielerreichbarkeit, die durch die Anforderungen des Lastenhefts dokumentiert wurden – die PDMS-Fähigkeit des Unternehmens. 6.5.1

Arbeitsschritt 3: Ergänzung oder Erstellung der Modelle

Im zweiten Arbeitsschritt wurde eine umfassende Daten- und Informationserhebung durchgeführt. Auf ihrer Grundlage werden im dritten Arbeitsschritt vorhandene Produktdaten-, Prozess- und Rollenmodelle ergänzt oder neu erstellt. Dies geschieht durch eine methodische Vorgehensweise, die schematisch in Abb. 6-21 dargestellt ist. Das Ergebnis ist eine modellhafte Beschreibung der Produkte, der Ablauf- und der Aufbauorganisation auf datentechnischer Ebene. Weiterhin leitet der dritte Arbeitsschritt die Umsetzungsphase des PDMS-Projekts ein. Die Implementierungseignung der Modelle wird durch die Erfüllung modellspezifischer Anforderungen sichergestellt. Sie basieren auf den PDMSEinflussgrößen, die in Abschn. 4.5 beschrieben wurden. Der Grad der Anforderungserfüllung für jedes Modell wird am Ende des Arbeitsschritts durch die CSC bewertet. Damit wird gezielt vorhandenes Verbesserungspotential ermittelt und umgesetzt. Bei vorhandenen Modellen kann die Bewertung bereits im zweiten Arbeitsschritt durchgeführt werden.

146

6

Lösungsbaustein 1: PDM-Systemeinführung Arbeitsschritt 3: Modellerstellung

Datenmodell vorhanden?

ja

nein

Festlegen der ModellAnforderungen

detaillierte Erfassung der spezifischen Modelldaten

Erstellung bzw. Reengineering Produktdatenmodell

Erstellung bzw. Reengineering Prozessmodell

CSC

ja

Erstellung bzw. Reengineering Rollenmodell

Bewertung der PDMS-Fähigkeit des Datenmodells

Nacharbeit erforderlich? nein

Nächste Projektphase?

nein

Projektende

ja Arbeitsschritt 4: pilothafte PDMSUmsetzung

CSC

Bewertung mittels Capability Scorecard (CSC)

Abb. 6-21 Darstellung der Vorgehensweise des Arbeitsschritts 3 zur Neuerstellung oder Ergänzung vorhandener Modelle im Unternehmen

6.5

Die Umsetzungsphase

147

Die Aktivitäten für die Modellerstellung orientieren sich an der Vorgehensweise des zweiten Arbeitsschritts. In Abhängigkeit der Vorgehenstiefe können im dritten Arbeitsschritt einige Aktivitäten wie bspw. die detaillierte Erfassung modellspezifischer Daten übersprungen werden. Zusätzlich unterscheiden sich einige Aktivitäten bei der Modellerstellung nur durch ihre modellspezifischen Dateninhalte. Bestimmte Daten lassen sich auch mehreren Modellen zuordnen. So sind die verantwortlichen Akteure eines Prozessschritts auf der Vorgangsebene häufig mit den Rollen des Rollenmodells identisch. Damit wird der Vorgehensaufwand wesentlich verringert. Das Ergebnis dieses Arbeitsschritts bilden implementierungsfähige und systemneutrale Modelle der Produkte, der Aufbau- und der Ablauforganisation. Anforderungen an die Modelle Zunächst werden die zu modellierenden Produkte und Prozesse ausgewählt. Damit findet eine implizite Festlegung der beteiligten Rollen statt [Brandt 2002; Walther 2005; Feldhusen et al. 2006a]. Anschließend werden die Anforderungen definiert, die jedes Modell hinsichtlich seiner effizienten PDMS-Eignung erfüllen muss. Prinzipiell sind sie für alle drei Modelle identisch und unterscheiden sich nur durch modellspezifische Eigenschaften wie den betrachteten Dateninhalt. Die für eine Systemimplementierung benötigte Modellqualität wird durch die nachfolgenden Modellanforderungen definiert: x Identifikation und Klassifizierung sämtlicher modellrelevanter Daten. Im Falle des Produktdatenmodells sind dies produktrelevante Daten wie die Artikelnummer oder Geometriedaten. Die zugehörigen Prozessdaten beschreiben die Daten erzeugenden Arbeitsabläufe. Darin sind auch die prozessbeteiligten Akteure mit ihren Verantwortlichkeiten enthalten. Diese Informationen werden neutral durch das Rollenmodell erfasst. Durch diese und die nachfolgende Anforderung wird die gegenseitige Wechselwirkung zwischen den Modellen berücksichtigt (siehe Abschn. 4.2). x Referenzierung der Beziehungen und Abhängigkeiten der modellspezifischen und modellübergreifenden Daten. So beeinflussen sich bspw. der Durchmesser einer Antriebswelle und der Durchmesser der zugehörigen Wellendichtungen gegenseitig. Beide Daten werden durch die prozessspezifische Aktivität „Erstellung des 3D-CAD-Modells“ erzeugt und dem Produkt eindeutig zugeordnet. Verantwortlich für die Erstellung

148

6

Lösungsbaustein 1: PDM-Systemeinführung

und Speicherung ist der Konstrukteur; verantwortlich für die Freigabe ist der Projektleiter. x Festlegung der zugehörigen Mitabreiterrollen einschließlich ihrer lebenszyklusabhängigen Zugriffsberechtigungen an Datenobjekten. Diese Anforderung berücksichtigt in Abhängigkeit der Lebenszyklusphase, welcher Mitarbeiter an welchem Datenobjekt bestimmte Aktivitäten durchführen darf. So darf ein Konstrukteur während der Entwicklungsphase entsprechende CAD-Modelldaten manipulieren. Nach der Fertigungsfreigabe durch den Projektleiter verliert er diese Berechtigung. x Systemneutraler Aufbau und Nutzbarkeit jedes Modells. Diese Anforderung stellt sicher, dass sämtliche Modelle systemunabhängig implementiert werden können. Dies geschieht in einem ersten Schritt mit Flussdiagrammen, Baumdiagrammen oder anderen grafischen Elementen; anschließend werden sie durch Modellierungstechniken wie der UML, STEP/ISO 10303 oder ARIS formuliert [Scheer 2001; Feldhusen et al. 2005c; Arnold et al. 2005]. Zusätzlich können derartige Modelle auch für weitere Anwendungen wie bspw. zur Simulation von Funktionen, Verhalten oder Prozessen sowie in Fertigungseinrichungen wie Manufacturing Execution Systems (MES) oder NC-Maschinen genutzt werden [Klaus 2006; Kletti 2007; Krause et al. 2007]. x Dynamische Modellstruktur und Modellimplementierbarkeit unter Berücksichtigung der aktuellen Rahmenbedingungen. Die Struktur eines Prozessmodells nach seiner Systemimplementierung muss einfach zu ergänzen sein. Dies kann bspw. durch veränderte Geschäftsprozessabläufe oder durch Umstrukturierungen in der Aufbauorganisation verursacht werden. Dieselbe Forderung gilt für Produktdatenmodelle, da nur durch die Modelldynamik eine Erweiterbarkeit durch zusätzliche Baugruppen, Einzelteile oder andere Elemente gewährleistet wird. Dieser Aspekt ist besonders für Multi-Life-Produkte (siehe Abschn. 3.2) bedeutsam. Rollenmodelle müssen ebenfalls dynamisch erweiterbar sein, um sich der Unternehmensorganisation flexibel anzupassen. Dies ist bspw. bei Abteilungsumstrukturierungen oder der Schaffung neuer Arbeitsplätze der Fall. Bei der Einbindung von Zulieferern können alle drei Modelle betroffen sein. Die ausgewählten Produkte müssen eine überschaubare Komplexität beinhalten, die modelltechnisch während der zeitlich begrenzten Pilotphase erfasst und implementiert werden kann. Eine ähnliche Aussage trifft für die ausgewählten Prozesse zu. Hier muss bspw. dokumentiert werden, welche Teilarbeitsschritte aus unternehmensinternen Gründen nicht überarbeitet werden dürfen. Die Modellerstellung sowie deren Systemimplementierung müssen dennoch repräsentative Aussagen hinsichtlich des

6.5

Die Umsetzungsphase

149

Zielerreichungsgrads nach der Pilotphase zulassen. Nur dann kann den Anwendern und dem Management der Systemnutzen innerhalb des Unternehmens vermittelt werden. Abschnitt 6.5.2 greift diese Aspekte vertiefend auf. Wie bereits in Kap. 4 erwähnt, wird im Rahmen einer PDMSystemeinführung von Unternehmen häufig die Modellimplementierung eines „best-selling“ Produkts („cash-cows“) sowie eines Prozesses wie dem Änderungsprozess gewünscht. Durch diese Umsetzung soll einerseits die unternehmensindividuelle Leistungsfähigkeit sowie der potenzielle Nutzen des Systems demonstriert werden, da erfahrungsgemäß in diesen Bereichen die meisten Unternehmen die höchste Komplexität besitzen (vgl. Kap. 2 und 3). Man möchte den Aufwand und die Ressourcen, die mit der geplanten Systemeinführung auftreten, gleichzeitig auch für eine Optimierung derjenigen Abläufe und der Produkte nutzen, die augenblicklich ohnehin Probleme bereiten. Davor ist eindringlich zu warnen: In dieser Projektphase dürfen bestehende Produkt- bzw. Prozessprobleme keinesfalls mit der Bewertung eines PDMS vermischt werden! Dies bedeutet: Probleme, die sich aus einem unzureichend definierten und komplexen Prozess wie dem Änderungsprozess ergeben, dürfen nicht mit der Bewertung der Leistungsfähigkeit eines PDMS vermengt werden. Die Redefinition von Prozessen, Produkten oder der Ablauforganisation bildet den Inhalt einzelner Verbesserungsmaßnahmen, die sich aufgrund der CSCBewertung ergeben; die Identifikation benötigter und/oder fehlender PDMS-Funktionalitäten ist von dieser Redefinition vollständig losgelöst. Wird dies nicht beachtet, kann es zu keinem eindeutigen Abschluss mit konkreten Aussagen hinsichtlich der PDMS-Fähigkeit des Unternehmens nach Beendigung der Pilotphase kommen. Dies stellt einen wesentlichen Grund dar, warum in der bisherigen Praxis PDMS-Projekte häufig ihre zugewiesenen Ressourcen überschritten haben und letztendlich erfolglos abgebrochen wurden. Innerhalb des PDMS-Projekts ist es effektiv, einfach strukturierte Produkte und „triviale“, d h. übersichtliche und beherrschte Prozesse wie den Ablauf bei einer Zeichnungsänderung o. ä. für eine Analyse, Redefinition, Modellierung und Implementierung zu wählen. Die Aussagen und Erkenntnisse auf der Grundlage derartiger Produkte bzw. Prozesse, die am Ende der Umsetzungsphase stehen, sind für die Bewertung völlig ausreichend. Auf dieser Basis kann auch eine verlässliche Managemententscheidung bezüglich des weiteren Vorgehens getroffen werden. In der Beschreibung des Arbeitsschritts 4 werden diese Zusammenhänge vertiefend beschrieben.

150

6

Lösungsbaustein 1: PDM-Systemeinführung

Vorgehensweise zur Erstellung eines Produktdatenmodells Ein Produktdatenmodell beinhaltet sämtliche Daten, die zur vollständigen Beschreibung eines bestimmten Unternehmensprodukts notwendig sind. Dies umfasst neben konstruktiven auch fertigungstechnische oder projektbeschreibende Daten einschließlich deren Klassifizierungen, Referenzierungen und Attribute (siehe Abschn. 4.2). In Abhängigkeit der Anzahl und der Charakteristika der produzierten Produkte sind in Unternehmen normalerweise mehrere Produktdatenmodelle vorhanden. Die Erstellung des Produktdatenmodells bzw. das Modell-Reengineering umfasst drei wesentliche Schritte. Sie sind in Abb. 6-22 dargestellt. Die Erfahrung zeigt, dass in vielen mittelständischen Unternehmen Produktdatenmodelle nicht oder nicht vollständig existieren. Deshalb konzentrieren sich die nachfolgenden Ausführungen auf eine Modell-Neuerstellung. Die Vorgehensweise ist jedoch sinngemäß auch auf vorhandene Modelle anwendbar. Eventuell können dabei einige Aktivitäten übersprungen werden. Bei der Erfassung der Produktdaten kommen viele Hilfsmittel zum Einsatz, die bereits in Arbeitsschritt 2 (IST-Aufnahme und SOLL-Konzeption) beschrieben wurden. Deshalb werden sie an dieser Stelle nicht weiter behandelt. Sinngemäß gilt dies auch für das Prozessmodell, dessen Erstellung im nachfolgenden Abschnitt ausgeführt wird.

Abb. 6-22 Top-Down Vorgehensweise zur Erstellung bzw. Aktualisierung eines Produktdatenmodells

6.5

Die Umsetzungsphase

151

Zunächst müssen geeignete Produkte gefunden werden, die sich für eine Modellierung in der Umsetzungsphase eignen. Ihr Aufbau muss dabei so komplex sein, dass einerseits repräsentative Aussagen hinsichtlich der Zielerreichbarkeit und Systemeignung möglich sind, andererseits müssen sie im Rahmen der beschränkten Ressourcen des PDMS-Projekts modellierbar sein. Abzuraten ist von einer versuchten Modellierung der umsatzträchtigsten Unternehmensprodukten (die so genannten „cash-cows“). Das Risiko eines Datenverlustes ist aufgrund der fehlenden Modellierungserfahrung sehr hoch. Nach der Produktauswahl werden die ermittelten Produktdaten der ISTAnalyse aus dem zweiten Arbeitsschritt komplettiert. Dazu werden die Produkte zunächst auf der Projektmanagementebene analysiert. Dies beinhaltet nicht nur die eigentlichen Projektdokumente, sondern auch die zugehörigen Zeichnungssätze und Stücklisten. Die Dokumente liefern Aussagen über den vorhandenen Produktaufbau einschließlich ihrer Metadaten, relevante Produktdaten sowie ihre gegenseitigen Referenzierungen. Anhand der vorhandenen D&I-Liste sowie der D&ILandkarte können fehlende Daten einfach ergänzt werden. Anschließend werden die physischen Produkte bis in ihre Einzelteile zerlegt, um die Produktarchitektur zu verstehen. Hierbei ist die Frage bedeutsam, ob und in welcher Dokumentenform (analog oder digital) physische Baugruppen bzw. Einzelteile in den betrachteten Unterlagen vorhanden sind. Oftmals ist eine Nachvollziehbarkeit der Produktarchitektur aufgrund mangelnder Referenzen, fehlender Daten oder Redundanzen innerhalb der vorliegenden Dokumente wie der Stückliste nicht eindeutig möglich. Diese Fragen werden in erneuten Expertengesprächen bzw. Mitarbeiterinterviews geklärt. Die Ergebnisdokumentation erfolgt anschließend im Prozessaufnahmeblatt, in den vorhandenen D&I-Listen sowie der D&I-Landkarte. Damit können produktdatenspezifische Schnittstellen- oder Medienbrüche aufgezeigt werden, die im zweiten Arbeitsschritt nicht erkennbar waren. Ebenso bedeutsam ist die Berücksichtigung fehlender Daten oder vorhandener Datenredundanzen. An dieser Stelle fließen auch die Ergebnisse der IT-Landkarte ein: Damit lassen sich die physischen Speicherorte der erfassten Daten dokumentieren. Oftmals erhält man das Ergebnis, dass benötigte Daten auf Servern anderer Abteilungen gespeichert sind, auf die Mitarbeiter keinen oder nur eingeschränkten Zugriff besitzen. So wurde in einem Unternehmen festgestellt, dass konstruktionsrelevante Messdaten auf Servern des Verkaufs abgespeichert waren. Dies war historisch durch eine interne Umstrukturierung bedingt und nicht geändert worden.

152

6

Lösungsbaustein 1: PDM-Systemeinführung

Abb. 6-23 Produktdatenmodell in seiner einfachsten Darstellung

Durch die „Produktsezierung“ sowie den Stücklistenvergleich kristallisieren sich produkt- und unternehmenstypische Datenschwerpunkte heraus, die als Grundlage für die Erstellung des Produktdatenmodells dienen. Unter einem Datenschwerpunkt wird die gemeinsame Konzentration inhaltsgleicher Daten auf unterschiedlichen Modelldarstellungsebenen wie der Bauteilebene verstanden [Feldhusen et al. 2005c]. Dies bedeutet, dass jedem Datenschwerpunkt spezifische Produktdaten zugeordnet werden. So ist dem Datenschwerpunkt „Produkt“ die Artikelnummer, die Auftragsnummer sowie entsprechende Teile- und Zeichnungsnummern zugeordnet. Dabei kann ein Produkt auch eine Baugruppe sein, welches in einem anderen Endgerät verbaut wird. Dies ist häufig bei Lieferantenprodukten der Fall. Datenschwerpunkte können auch anderen Datenschwerpunkten zugeordnet sein. Der Vorteil dieser Darstellungsform liegt in einer ersten Grobklassifizierung, da anhand der Datenschwerpunkte eine Zuordnung der in den D&IListen dokumentierten Daten erfolgen kann [Feldhusen et al. 2005c]. Die Vorgehensweise lässt auch Aussagen hinsichtlich der logischen Verknüp-

6.5

Die Umsetzungsphase

153

fung zwischen den einzelnen Datenschwerpunkten zu. Ein Produktdatenmodell in seiner einfachsten Darstellungsebene zeigt Abb. 6-23, wobei Rohstoffe und Vorstufen einzelner Baugruppen bzw. Bauteile auf dieser Darstellungsebene nicht gezeigt sind. Die Darstellung des Datenschwerpunktes „Produkt (Baugruppe)“ auf der darunter liegenden, ersten Gliederungsebene ist in Abb. 6-24 gezeigt. Auf diese Weise können die Gliederungsebenen weiter detailliert und die in Arbeitsschritt 2 gewonnenen Daten zugeordnet werden. Dabei handelt es sich um Daten, die aufgrund der Sachmerkmalliste, geforderten Zertifizierungen oder Angaben auf dem Leistungsschild eines stromführenden Produkts erforderlich sind. Auf dieser Ebene werden bereits erste Referenzierungen erkennbar: So besteht eine Beziehung zwischen dem Lieferanten und dem Lagerbestand, sofern Bauteile aus externer Fertigung verbaut werden. Sie müssen vor Erreichen einer kritischen Lagermenge durch die Einkaufsabteilung rechtzeitig in Auftrag gegeben werden. Derartige Referenzen sind in der Abbildung aus Gründen der Übersichtlichkeit nicht dargestellt.

Abb. 6-24 Darstellung des Datenschwerpunkts „Produkt (Baugruppe)“ auf der ersten Gliederungsebene als Partialmodell

Aus Sicht des Produktdatenmodells stellt sich ein typischer Bestellvorgang folgendermaßen dar: Ein Kunde bestellt ein Produkt. Es wird ein Kundenauftrag generiert, der idealerweise sämtliche Kundenanforderungen erfasst. Dabei ist jedem Kunden ein eindeutiger Kundenauftrag zugeordnet. Handelt es sich dabei um ein Katalogprodukt, wird aus dem Kundenauftrag sofort ein Fertigungsauftrag generiert; der Technische Bereich muss keine Änderungen an einem bestehenden Produkt vornehmen. Häufig jedoch verlangt der Kunde spezifische Anpassungen eines bereits vorhandenen (Katalog-)Produkts speziell auf seine individuellen Bedürfnisse. Auf dieser

154

6

Lösungsbaustein 1: PDM-Systemeinführung

Grundlage wird ein neues Projekt generiert, dem eine unterschiedliche Anzahl von speziellen Mitarbeitern zugeteilt werden. Diese Zuteilung ist abhängig von der Mitarbeiterqualifikation und von ihrer zeitlichen Verfügbarkeit. Das (Katalog-) Produkt wird im Sinne einer Anpassungskonstruktion geändert, gefertigt und dem Kunden geliefert. Damit ist eine neue Variante erzeugt worden. Entsprechend der Kundenanforderungen muss ggf. die Verpackung angepasst werden – so können konstruktive Maßnahmen eine größere Verpackung erfordern, als dies beim ursprünglichen Produkt der Fall war. Die Daten und Informationen hinsichtlich des Kunden sowie der zugehörigen Projektmitarbeiter einschließlich des Projektleiters entstammen dem Rollenmodell. Sämtliche Abläufe bei der Erstellung von Baugruppen, Einzelnteilen oder der Projektablauf sind in den Prozessmodellen definiert. Bereits an diesem Beispiel wird die enge Verzahnung der Modelle, wie sie in den ersten Buchkapiteln hergeleitet wurde, deutlich.

Abb. 6-25 Darstellung des Produktdatenmodells in der internationalen Notifikation nach ISO 10303

Bei dieser Vorgehensweise muss berücksichtigt werden, dass auch viele neue Produktdaten wie eine neue Artikelnummer oder entsprechende Zeichnungssätze entstehen. Dieses Vorgehen ist häufig in mittelständischen Unternehmen zu beobachten und eine wesentliche Ursache für die in Kap. 2 dargestellte interne Unternehmenskomplexität. Die Linien zwischen den einzelnen Datenschwerpunkten geben die gegenseitigen Beziehungen an. So ist erkennbar, dass einem Kundenauftrag mehrere Projekte zugeordnet sein können. Dies ist immer dann der Fall,

6.5

Die Umsetzungsphase

155

wenn für einen Kunden spezifische Muster gefertigt werden. Falls das ausgelieferte Muster den Kundenspezifikationen nicht genügt und nachgearbeitet werden muss, wird auf der Basis des ursprünglichen Kundenauftrags ein neues Projekt angelegt. Im Gegensatz hierzu ist ein Entwicklungsprojekt eindeutig einem bestimmten Kundenauftrag zugeordnet. Es handelt sich in der Abb. 6-23 folglich um eine n:1-Beziehung. Die in den Abb. 6-23 und 6-24 gezeigten Darstellungsformen besitzen den Vorteil, dass sie für sämtliche Mitarbeiter und dem Management ohne Vorkenntnisse verständlich ist. In dieser Form kann das Modell jedoch nicht in das PDMS implementiert werden. Eine entsprechend systemgeeignete Aufbereitung findet mit Hilfe der Unified Modeling Language (UML) oder der objektdatenorientierten Modellierungssprache EXPRESS statt [ISO 10303-11; Anderl et al. 2006]. Die Modellierung in eine dieser Notifikationen geschieht entweder unternehmensintern durch spezialisierte IT-Mitarbeiter oder unternehmensextern durch Dienstleister. Im Idealfall besitzt das PDMS einen grafischen Editor, mit dem dies bewerkstelligt werden kann. Abbildung 6-25 stellt das gezeigte Produktdatenmodell in der internationalen Nomenklatur nach ISO 10303 dar. Unabhängig von der gewählten Darstellungsform müssen die einzelnen Produktdaten klassifiziert, den einzelnen Datenschwerpunkten zugeordnet und gegenseitig referenziert werden. Vorgehensweise zur Erstellung eines Prozessmodells Nach der Definition in Abschn. 4.2 beinhaltet ein Prozessmodell die Beschreibung sämtlicher zielgerichteter Aktivitäten einschließlich ihrer relevanten Eingangs- und Ausgangsdaten sowie der zugehörigen Rollen. Die grundsätzliche Vorgehensweise zur Erstellung eines Prozessmodells ist in Abb. 6-26 gezeigt. Sie orientiert sich an den Ausführungen der Vorgehensweise zur Erfassung der D&I-Flüsse, die im zweiten Arbeitsschritt beschrieben wurde. Die Anzahl benötigter Prozessmodelle im Unternehmen leitet sich aus der Anzahl der vorhandenen und für eine Implementierung vorgesehenen Prozesse ab. Die ausgewählten Prozesse werden entweder neu erfasst oder sind bereits im Rahmen entsprechender Zertifizierungen definiert. Die Erfassung der Prozessdaten und ihre gegenseitigen Referenzen geschieht durch eine vertiefende Analyse von vorhandenen Projektdokumentationen, Handbüchern oder Projekterfahrungsberichten auf der Teilprozessebene. Sie wird durch Expertengespräche und ergänzende Mitarbeiterinterviews auf der Vorgangsebene unterstützt. Die Ergebnisse werden in die D&I-Liste und die

156

6

Lösungsbaustein 1: PDM-Systemeinführung

D&I-Landkarte eingepflegt. Beide wurden in Abschn. 6.4.2 beschrieben. Anschließend erfolgt die Identifikation von prozessspezifischen Problemstellen. Hierbei sind insbesondere Ablaufbrüche sowie fehlende Eingangsund Ausgangsdaten einschließlich ihrer verantwortlichen Rollen bedeutsam.

Abb. 6-26 Top-Down-Vorgehensweise zur Erstellung bzw. Aktualisierung eines Prozessmodells

Die Darstellung des Prozessmodells geschieht in der Form von Flussdiagrammen nach [DIN 66 001] und ist in Abb. 6-27 gezeigt. Es ist deutlich erkennbar, dass die Eingangsdaten, die Ausgangsdaten, die einzelnen Prozessaktivitäten mit zugeordneten Prozessschrittnummern sowie die beteiligten Rollen dargestellt sind. Dies geschieht auf der Grundlage der D&IListe. Die relevanten Eingangs- und Ausgangsdaten sowie die zugehörigen Rollen können für jeden einzelnen Prozessschritt in tabellarischer Form dokumentiert werden (siehe Abb. 6-28). Ähnlich wie beim Produktdatenmodell kann das Prozessmodell in dieser Form nicht in das PDMS implementiert werden [Mylopoulos u. Borgida 2006]. Der Vorteil dieser Darstellungsweise liegt in einer hohen Verständlichkeit der identifizierten Daten einschließlich ihrer Zuordnung auf der Vorgangsebene und der technischen Ebene. Ebenso können die prozessbeteiligten Akteure den Prozessaktivitäten eindeutig zugeordnet werden. Damit beinhaltet die Darstellung sämtliche Modellanforderungen, die für eine aussagekräftige Bewertung der PDMS-Fähigkeit vorhanden sein müssen. Bei einem unzureichenden Bewertungsergebnis wird ein Modell-

6.5

Die Umsetzungsphase

157

Reengineering durchgeführt. Für eine Prozessverbesserung geschieht dies zumeist mit Hilfe eines Business Process Reengineering (BPR) [Scheer 2001; Rosemann 2003; Schwab 2004; Feldhusen et al. 2005c]. 1000 START

INPUT: Daten aus LH (A) -> Grundtyp bzw. Kataloggerät; Auftragsnr.; Projektnr.; Auftragstyp; Stückzahl; externes LH vorhanden?; Versionsnr.; Kundenanforderung(en); ProduktGrunddaten-Checkliste (Spannungsbereich; IP-Schutzart; sonstige Umweltbelastungen; ISO-Klasse(n); CAD-Schnittstellen; Terminplan; (...) OUTPUT: Ausfüllen Projektdatenblatt (D): Projektvorgaben Entwicklung (Musterkosten/Stck [€]; Termin Prototypenserie; Werkzeugkosten [€]; Betriebsmittelkosten [€]; Entwicklungsaufwand [Std.]; zuletzt bearbeitet von…; zugesagter Mustertermin; Stückzahl Prototypenserie; Fremdaufwand [€]; Etnwicklungsaufwand [€]; Datum letzte Änderung); Projektplanung und Projektteam (Projektphase; Solltermine; Aufwand; Verantwortlicher; Projektteam; zugehörige Abteilung); (...) ROLLE: MA/Konstrukteur aus Abt. Technischer Bereich; Projektleiter; MA aus Vertrieb

1010 Eingang LH aus Vertrieb

1020 Prüfen des LH und Ableiten der Kundenwünsche auf StüLi-Ebene

INPUT: Grundtypnr. bzw. Kataloggerätenr. (A) als Referenzgerät (Eingabe in ERP) OUTPUT: Referenz-StüLi (A) ROLLE: MA/Konstrukteur aus Abt. Technischer Bereich

1030 Ausdrucken StüLi (Referenzgerät) aus ERP

1040 Referenz-StüLi

INPUT: Daten aus LH (A), v.a. Kundenwünsche und Richtlinien/ Normen etc. -> Kennzeichnung der von den Kundenwünschen betroffenen BG und/oder Unterlagen OUTPUT: Referenz-StüLi’s der betroffenen BG’s und Unterlagen (A) ROLLE: MA/Konstrukteur aus Abt. Technischer Bereich

1050 Kennzeichnung der von den Kundenwünschen betroffenen BG’s

1051 elektronsiche BG betroffen?

ja

1052 Mustererstellung der elektronischen BG in Abt. Elektronik

...

nein

... Abb. 6-27 Ausschnitt aus dem Teilprozess „Erstellung von Mustern“ einschließlich der prozessrelevanten Daten aus dem Produktdaten- und dem Rollenmodell auf der Vorgangsebene [Feldhusen u. Gebhardt 2005a]

158

6

Lösungsbaustein 1: PDM-Systemeinführung

Abb. 6-28 Tabellarische Form der beteiligten Rollen eines Prozessschritts sowie der zugehörigen Eingangs- und Ausgangsdaten

Abb. 6-29 Darstellung eines Workflowausschnitts des Teilprozesses „Erzeugung von Mustern“ in einem grafischen Workfloweditor

6.5

Die Umsetzungsphase

159

Das Prozessmodell kann auch in einer industriekonformen Darstellungsweise wie der Architektur integrierter Informationssysteme (ARIS) oder dem Sequenzdiagramm der Unified Modeling Language (UML) beschrieben werden [Scheer 2001; Arnold et al. 2005]. Aufgrund der nachfolgenden Ausführungen wird an dieser Stelle auf diese Darstellungsformen nicht weiter eingegangen. Unabhängig von der Darstellungsweise bildet das Prozessmodell die Grundlage für Systemworkflows auf technischer Ebene [Müller 2005]: Bei einem Workflow handelt es sich um eine systemtechnische Abbildung eines Arbeitsablaufs, der aus mehreren Arbeitsschritten besteht. Er wird nach einmal definierten Regeln durch ein Workflowmanagement-System (bzw. durch eine entsprechende Systemkomponente oder Systemfunktionalität) gesteuert und überwacht. In vielen Fällen muss der Workflow auf definierte Prozesse oder Teilprozesse zurückgreifen, die eine Tätigkeitsbeschreibung sowie Eingangs- und Ausgangsdaten beinhalten. Zusätzlich werden Angaben zur Aufbauorganisation einschließlich der zugehörigen Verantwortlichkeiten benötigt [Gulbins et al. 2002; Becker et al. 2003]. Ein Prozess kann in seiner Gesamtheit oder auch nur in Teilen (!) seines Ablaufs durch einen Workflow abgebildet werden. Diese Workflows werden mittels eines grafischen Editors im PDMS erstellt. Damit kann ein geschulter Anwender ohne Kenntnisse in Programmierung oder UML ein Prozessmodell als Workflows in ein PDMS integrieren - sofern das System diese Funktionalität bereitstellt. Abbildung 6-29 zeigt eine Möglichkeit, den vorgestellten Teilprozess in Form eines Workflows darzustellen. Er wurde in einem Industrieprojekt als Teil eines Gesamtworkflows erfolgreich implementiert. In dem grafischen Workfloweditor erfolgt auch die Verknüpfung mit den prozess- und verantwortungsrelevanten Daten der beiden anderen Modelle. Das Rollenmodell im PDMS-Umfeld Die Erstellung einer neuen Rolle sowie die Überprüfung einer bereits vorhandenen Rolle ist – je nach Qualität der dokumentierten Prozesse – ein zeitintensiver Vorgang. Aus diesem Grund stellen die meisten PDMS bereits vordefinierte Rollen (sog. Standardrollen) zur Verfügung, die sich auf den abgeleiteten Workflow anwenden lassen. Sie können den einzelnen Aktivitäten innerhalb des Workflows im grafischen Editor sofort zugeordnet werden. Nur die Zugriffsrechte müssen noch vergeben werden.

160

6

Lösungsbaustein 1: PDM-Systemeinführung

Da der Zweck eines PDMS die Bereitstellung und Verwaltung von Produkt-, Prozess- und organisatorischen Daten ist, besitzen solche Systeme einen unterschiedlichen Umfang an Funktionalitäten. Sie können mit beliebigen Rollen verknüpft werden und steuern kontextabhängig die unterschiedlichen Zugriffsberechtigungen der Rolle (bzw. des Akteurs) auf zugewiesene (Daten-)Objekttypen in den einzelnen Lebenszyklusphasen bzw. Objektstatus. In Abb. 6-30 ist ein typischer Lebenszyklus eines Datenobjekts gezeigt: Das Datenobjekt wie ein CAD-Modell wird zunächst durch die Rolle „Konstrukteur“ erzeugt (Objektstatus: „In work“ bzw. „in Bearbeitung“ oder eine systemabhängige ähnliche Bezeichnung), anschließend zur Freigabe eingereicht und idealerweise freigegeben oder zurückgewiesen. Diese Freigabe geschieht durch die Rolle „Projektleiter“. Beiden Rollen werden in der Praxis durch konkrete Mitarbeiter ersetzt, die für die Tätigkeiten verantwortlich sind. Bei einer Freigabe ändert sich der Objektstatus. Nach einer definierten Zeitperiode kann das Datenobjekt ungültig werden. Dies kann bspw. bei einem neu erstellten CAD-Modell geschehen. Jedem Datenobjekttyp ist ein eigener Lebenszyklus zugeordnet. So unterscheidet sich bspw. der Lebenszyklus des Objekttyps Dokument durch die Anzahl durchlaufender Objektstatus und der zugehörigen Lebenszyklus-Gates.

Abb. 6-30 Beispiel eines typischen Lebenszyklus für Datenobjekte wie CADDaten. Jedem Datenobjekttyp ist ein eigener Lebenszyklus zugeordnet

Typische Systemfunktionalitäten und ihre abgeleiteten Berechtigungen, die einer Rolle durch ein PDMS zugeordnet werden können, sind: x lesen (Read) – die Berechtigung, ein angelegtes bzw. vorhandenes Datenobjekt zu sehen und zu öffnen; x Datenobjekte bzw. Dateninhalte ändern (Modify) – die Berechtigung, das Datenobjekt selbst, dessen Inhalte, seine Attribute sowie andere objektbeschreibenden Charakteristika zu ändern, die Bestandteil der (unternehmensindividuellen) Objektdefinition sind;

6.5

Die Umsetzungsphase

161

x Datenobjekt erzeugen (Create) – die Berechtigung, jedes Datenobjekt oder nur bestimmte Datenobjekttypen wie CAD-Modelle zu erzeugen; x zurückweisen (Revise) – die Berechtigung, ein Datenobjekt an einem Gate zurückzuweisen und damit den neuen Objektstatus nicht zu vergeben; x neue Sicht erzeugen (New view version) – die Berechtigung, ein neues Datenobjekt unter der Berücksichtigung einer abteilungsspezifischen Sicht zu erzeugen (wie die Konstruktionssicht, die Fertigungssicht oder die Vertriebssicht); x löschen (Delete) – die Berechtigung, Dateninhalte zu löschen. Sämtliche PDMS lassen die Löschung eines kompletten Datenobjekts aus Gründen der Referenzierungen und der gesetzlich bestimmten Archivierung in bestimmten Branchen nicht (oder nur sehr eingeschränkt) zu; x Berechtigungen ändern (Change permissions) – die Berechtigung, bereits vergebene Rechte an Rollen, Gruppen oder Akteuren zu ändern oder neue Rechte zuzuweisen; x administrieren (Administrate) – die Berechtigung, administrative Aufgaben durchführen zu können wie bspw. die Zuweisung oder Änderung einer Rolle zu einem bestimmten Datenobjekt.

PDMSfunktionalitäten

PDMS-Standardrollen

Rollen im Unternehmen

• Antragsteller

• Projektleiter

• Bearbeiten/ Ändern

• Prüfer

• Projekt-Mitglieder:

• Lesen • Prüfen • Freigeben/ Ablehnen • …

• Teamleiter • Team-Mitglied • Beobachter • Genehmiger • …

•Vertrieb

abgeleitet

• Speichern

abgeleitet

• Erzeugen

•EV •Konstruktion •… • Prüfer • Genehmiger • …

Abb. 6-31 Abgeleitete Standardrollen auf der Grundlage von vorhandenen PDMSFunktionalitäten

In Abhängigkeit dieser Funktionalitäten werden von dem System definierte Standardrollen bereitgestellt. Sie werden, wie bereits beschrieben, durch Mitarbeiter besetzt, die diese Rollen ausfüllen und die für die zugewiesenen Prozessaktivitäten verantwortlich sind. Abbildung 6-31 zeigt beispiel-

162

6

Lösungsbaustein 1: PDM-Systemeinführung

haft die Zusammenhänge zwischen den Systemfunktionalitäten und den abgeleiteten Standardrollen, die mit entsprechenden Akteuren besetzt werden. Standardrollen bieten im Bezug auf ein PDMS unerfahrenen Administratoren die Möglichkeit, die vorhandene Unternehmensaufbauorganisation einfach abzubilden. Somit lassen sich bestimmten Datenobjekten entsprechende Rollen mit den relevanten Berechtigungen einfach zuweisen; dies unterstützt den gewünschten schnellen Systemeinsatz. Manchmal jedoch reichen in der Praxis die vorgegebenen Standardrollen nicht aus und es müssen unternehmensindividuelle Rollen erstellt werden, die exakt auf spezifische Unternehmensdaten oder Abläufe zugeschnitten sein müssen. Diese Individualrollen beschreiben die Ablauf- und Aufbauorganisation deutlich über der (technischen) Workflowebene. Folglich können sie mit den Standardrollen auf der Workflowebene nur unzureichend erfasst werden. Ihre Erfassung findet auf der Vorgangs- und Teilprozessebene statt (vgl. hierzu die Ausführungen in Abschn. 6.4.2). Die Vorgehensweise zur Ergänzung eines vorhandenen bzw. die Erstellung eines neuen Rollenmodells bildet den Inhalt der nachfolgenden Abschnitte. Vorgehensweise zur Erstellung eines Rollenmodells In den vorangegangenen Abschnitten wurde erläutert, wie sich die Zusammenhänge auf der Produktebene, der Prozessebene und der organisatorischen Ebene darstellen. Dabei ist das Rollenmodell eine Repräsentation der zugrunde liegenden Aufbaustruktur. In diesem Abschnitt wird eine Vorgehensweise zur Erstellung eines Rollenmodells beschrieben. Abbildung 6-32 zeigt die generelle Vorgehensweise bei einer Rollenmodellerstellung bzw. -überprüfung. Die beiden Matrizen als unterstützende Hilfsmittel werden später erläutert. Im ersten Vorgehensschritt werden notwendige Rollen allgemein bestimmt und formuliert, die sich aufgrund der einzelnen Prozessschritte zwingend ergeben. Besonders bedeutsam ist die Berücksichtigung von Rollen, die sich aufgrund informeller Prozessschritte im betrieblichen Ablauf gebildet haben. Sie bilden einen wesentlichen Faktor für ein mögliches Produktoder Prozess-Reengineering. In diesem Schritt werden auf der Grundlage bestehender Abläufe sowohl die Aufgaben als auch zugehörige Verantwortlichkeiten erfasst. Dadurch lassen sich zum einen erste Aussagen über die relevanten Attribute, zum anderen grobe Abschätzungen über deren Inhalt treffen. Als Grundlage hierfür dient der Rollenpool, wie er exemplarisch in Tabelle 6-1 dargestellt ist. Er beinhaltet die Standardrollen, die im

6.5

Die Umsetzungsphase

163

vorherigen Abschnitt beschrieben wurden. Die allgemeinen Standardrollen werden in den nachfolgenden Schritten zu dem unternehmensindividuellen Rollenmodell ausformuliert.

Abb. 6-32 Vorgehensweise zur Erstellung eines Rollenmodells

Anschließend müssen diejenigen Daten erfasst werden, welche zur Aufgabenbeschreibung für die im ersten Schritt beschriebenen Rollen notwendig sind. Hierzu werden im zweiten Schritt die unternehmensindividuellen Produktstrukturen und Prozessbeschreibungen analysiert. Je nach Qualität der Prozessmodelle und ihrer Beschreibung lassen sich die Prozesstätigkeiten, ihre Eingangs- und Ausgangsdaten sowie ihre verantwortliche organisatorische Ausführungsinstanz zuordnen. Ebenso können entsprechende Benutzer- und Objektrechte zugewiesen werden. In diesem Schritt wird folglich das Rollenkonzept ausgearbeitet und ggf. informelle Strukturen berücksichtigt. Typische Quellen hierzu sind Arbeitsplatzbeschreibungen, Prozessabläufe nach ISO 9000, Stücklisten, Organigramme oder Best-

164

6

Lösungsbaustein 1: PDM-Systemeinführung

Practice-Berichte. Auch Expertengespräche und/oder Mitarbeiterinterviews sind eine sinnvolle Ergänzung. An dieser Stelle sei auf den Unterschied zwischen der Beschreibung einer Rolle und dem Rollenkonzept hingewiesen (vgl. auch Abschn. 4.2): Bei einer Rolle handelt es sich um eine ausschließliche Aufgaben- und Verantwortlichkeitsbeschreibung. Die zugehörigen Benutzer/Akteure, die betroffenen Objekttypen sowie die kontextabhängigen und statusabhängigen Berechtigungen sind im Rollenkonzept definiert. Somit stellt das Rollenkonzept eine Präzisierung auf systemtechnischer Ebene in Bezug auf allgemeine formulierte Rollen dar. Wie bereits beschrieben, geschieht diese Zuordnung auch bei der Anwendung der vom PDMS vorgegebenen Rollen. Diese beiden ersten Vorgehensschritte finden in der Praxis zumeist parallel statt und werden durch den so genannten Business-Administrator oder den Prozessverantwortlichen durchgeführt. Mit diesen beiden ersten Schritten ist es möglich, sich bei der Erstellung von neuen (d.h. im Unternehmen oder in der Abteilung noch nicht vorhandenen) Rollen eine erste Grundlage in Anlehnung an das Prozessmodell und damit implizit an das Produktdatenmodell zu schaffen. Diese beiden Modelle liefern wichtige Informationen hinsichtlich der rollenspezifischen Attribute, welche im dritten Schritt bestimmt und/oder spezifiziert werden. An dieser Stelle sei angemerkt, dass es nachfolgend mit dem dritten Schritt möglich ist, bereits vorhandene Rollen bzw. Rollenmodelle zu überprüfen und gegebenenfalls zu aktualisieren. Die Vorgehensweise bleibt in diesem Fall gleich, auch wenn dies in den folgenden Ausführungen nicht explizit erwähnt wird. Im dritten Vorgehensschritt werden die Rollenattribute aufgestellt bzw. ergänzt/aktualisiert. Dies geschieht mit Hilfe der Was-Matrix und der WerMatrix, mit denen die Attribute erfasst und dokumentiert werden. Beide Matrizen werden im folgenden Abschnitt beschrieben. Normalerweise wird mit dem Ausfüllen der „Was-Matrix“ begonnen, da die geforderten Inhalte durch die im ersten und zweiten Schritt dokumentierten Ergebnisse bereits vorhanden sind. Sollten entsprechende Lücken vorhanden sein, muss den betroffenen Datenobjekten ein für sie definierter Lebenszyklus innerhalb des betreffenden Prozesses zugeordnet werden (vgl. Abb. 6-30). Anschließend werden der allgemein beschriebenen Rolle mittels der „WerMatrix“ ein konkreter Kontext sowie ein oder mehrere eindeutige Benutzer zugewiesen. Über die Benutzerzuordnung wird ein für die Aktivität verantwortlicher Akteur bestimmt. Die konkrete Rollenbeschreibung einschließlich ihrer Attribute in der „Wer-Matrix“ wird nun der „Was-Matrix“

6.5

Die Umsetzungsphase

165

zugeordnet. Diese systematische Attributszuordnung und gleichzeitige Dokumentation mittels beider Matrizen ist der Inhalt des vierten Vorgehensschritts. Damit ist das Rollenkonzept vollständig erstellt. Der vierte Schritt wird in der Praxis durch den System-Administrator unterstützt, welcher das Rollenkonzept später in das PDMS umsetzt. Im letzten Schritt werden die eindeutig beschriebenen Rollen als unternehmensindividuelles Rollenmodell formuliert. Beispiele sind die ausgefüllten Matrizen oder eine rechnerunterstützende Darstellungsweise wie dies exemplarisch in Abb. 6-33 (hier in der UML-Notifikation) gezeigt ist. Das Rollenmodell beschreibt die Rolle, ihre zugehörigen Attribute und ihre Beziehungen in Form des Rollenkonzepts. Es ist nochmals darauf hingewiesen, dass die Erstellung eines derartigen Rollenmodells nur sinnvoll ist, falls mit den definierten Standardrollen die Aufbauorganisation nicht oder nur ungenügend abgebildet werden kann (vgl. Abb. 6-32). Eignung

Tätigkeit

1..*

Verantwortlichkeit 1..* 1

0..* Akteur

1..*

0..*

Rolle

-Name

Mitarbeiter

1..* 1

Kontext

Gruppe

Berechtigung 1

-Produkt -Projekt

-Name

-Nutzerrechte -Objektrechte 1..* Produkt

Organisation -Abteilung

Projekt -Kontext

-Kontext -Artikelnummer -Teilenummer

«Teilsystem» PDMS

Abb. 6-33 Darstellung eines Rollenmodells in UML-Notifikation

Diese Vorgehensweise ist für jede Rolle und für jeden Objekttyp durchzuführen. Auf diese Weise entsteht durch Kombination der unterschiedlichen kontext- und objekttypabhängigen Matrizen ein umfassendes Rollenmodell auf Abteilungs- bzw. Unternehmensebene.

166

6

Lösungsbaustein 1: PDM-Systemeinführung

Hilfsmittel zur Erfassung der Rollenattribute: Die „Wer-Matrix“ und die „Was-Matrix“ Die unternehmensindividuelle Erfassung der Rollenattribute bildet die Grundlage zur Abbildung der unternehmensspezifischen Aufbauorganisation. Sie wird unterstützt und dokumentiert durch zwei miteinander interagierende Matrizen, der Was-Matrix und der Wer-Matrix. Mit diesen beiden Hilfsmitteln können alle rollenbeschreibenden Attribute erfasst werden. In Abb. 6-34 und 6-35 sind die beiden Matrizen in allgemeiner Form gezeigt. Dabei stellt die eigentliche Rollenbeschreibung die verbindende Schnittstelle zwischen den beiden Matrizen dar. Diese Rollenbeschreibung kann bspw. in einer Form geschehen, wie sie in Tabelle 6-1 dargestellt ist. Sie bildet die Grundlage eines Katalogs allgemein formulierter Rollen, aus welchem bei Bedarf die entsprechende Rollenbeschreibung ausgewählt werden kann. Dieser Katalog wird Rollenpool genannt. Die einzelnen Rollen resultieren entweder aus den Systemfunktionalitäten (Standardrollen) oder der beschriebenen Vorgehensweise nach Abb. 6-32. CAD-Modell: Baugruppe „Welle“ (Teilenr. AB-007) Status bzw. LC-Phase

Status 1: in Bearbeitung

Status 2: Freigabe

Rolle 1: Konstrukteur

create, modify, delete, read, submit

read

Rolle 2: Projektleiter

read, revise

read

…

…

Abb. 6-34 Allgemeine Darstellung der „Was-Matrix“ zur Bestimmung und Dokumentation der statusabhängigen Rollenberechtigungen

Die Was-Matrix in Abb. 6-34 beschreibt, welchen Rollen für bestimmte Datenobjekte lebenszyklusabhängig Berechtigungen eingeräumt werden. Sie wird ausgefüllt, wenn Objekttypen und deren Status eindeutig definiert sind. Diese Informationen lassen sich aus den Produktdatenmodellen und den Prozessmodellen generieren. Fehlen einige dieser Angaben, so ist dies ein Hinweis auf eine notwendige Überarbeitung der zugehörigen Prozessbzw. Produktbeschreibungen [Feldhusen et al. 2005c].

6.5

Die Umsetzungsphase

167

Die relevanten Parameter der „Was-Matrix“ sind x die allgemeine Rollenbeschreibung wie Konstrukteur oder Projektleiter; x der zugehörige Objekttyp, bspw. das CAD-Modell einer Baugruppe; x der zugehörige Objekttypstatus bzw. die zugehörige Lebenszyklusphase (LC-Phase) wie „in Beabreitung“ oder „Freigabe“ und x die zugewiesenen Berechtigungen, bspw. „erzeugen“ oder „lesen“. Tabelle 6-1 Exemplarische Rollen und ihre Tätigkeitsbeschreibung als Basis für einen allgemeinen Rollenpool Rolle

Aktivität

Erläuterung

Erzeuger

Datenobjekt gen

erzeu-

Der Erzeuger kreiert ein Datenobjekt und legt es im System an. Oftmals darf der Erzeuger das Datenobjekt bis zu einer bestimmten Statusänderung bearbeiten.

Antragsteller

Datenobjekt einreichen

Der Antragsteller bestimmt, wann ein Objekt (bspw. eine Zeichnung) zu einer Statusänderung bereit ist und reicht es ein.

Prüfer

Datenobjekt prüfen

Der Prüfer prüft das Objekt auf seine Richtigkeit, gibt ggf. Anmerkungen ein und stimmt für bzw. gegen eine Statuserhöhung.

Genehmiger

Status erhöhen

Der Genehmiger entscheidet, ob der Status eines Objekts erhöht (angenommen) oder nicht erhöht (abgelehnt) wird. Er alleine besitzt die Befugnis, den Status zu erhöhen oder herabzusetzen, eine Objekteinreichung abzulehnen oder das Objekt aus einem Prozess komplett zu entfernen.

Beobachter

Datenobjekt/Workflow obachten

be-

Der Beobachter wird benachrichtigt, wenn ein Objekt zur Statusänderung eingereicht wurde. Er kann das Objekt, die Eingaben des Prüfers und die Kriterien zur Änderung des Status einsehen, aber er kann diesbezüglich keine Entscheidungen treffen.

168

6

Lösungsbaustein 1: PDM-Systemeinführung

In Abb. 6-34 ist erkennbar, dass der Konstrukteur bei der Erstellung von CAD-Daten zur Modellierung der Baugruppe „Welle“ während der Lebenszyklusphase „In work“ (vgl. hierzu Abb. 6-30) die Berechtigungen „Create“, „Modify“, „Submit“, „Read“ und „Delete“ besitzt. Nach dem Einreichen ändert sich der Projektstatus in „Freigabe“; damit ändern sich die Benutzerrechte in „Read“. Eine Datenmanipulation nach der Freigabe durch den Konstrukteur ist nicht mehr möglich, da er nun ausschließlich Leserechte am Objekt „CAD-Modell“ besitzt. Sollen oder müssen nach dem Statuswechsel am CAD-Modell noch entsprechende Änderungen vorgenommen werden, wird in den Unternehmen der Änderungsprozess angestoßen. Er wird an dieser Stelle nicht weiter ausgeführt; selbstverständlich unterliegt der Änderungsprozess denselben Anforderungen innerhalb des PDMS-Projekts, die auch für sämtliche anderen Prozesse gültig sind. Die allgemein beschriebene Rolle der „Was-Matrix“ wird durch die konkrete Rollenbeschreibung und -zuordnung der Wer-Matrix in Abhängigkeit des betreffenden Kontexts genauer spezifiziert. In dieser Matrix wird festgelegt, in welchem Kontext welche(r) Benutzer welcher Rolle zugeordnet werden. Dieser Rolle lassen sich somit konkrete Personen bzw. Systemdienste zuweisen, die aus der Verantwortlichkeit der einzelnen Prozesstätigkeiten resultieren. Durch diese Interaktion ordnet die „Wer-Matrix“ der allgemein beschriebenen Rolle der „Was-Matrix“ einen oder mehrere eindeutige kontextabhängige Benutzer zu (vgl. Abb. 4.9). Dabei ergeben sich die Gruppen aus der Organisationsstruktur der Abteilungen bzw. des Unternehmens; der Kontext stellt die Zuordnung zu einzelnen Produkten oder Projekten dar. Damit ist auch die in der Praxis vorkommende Interdisziplinarität der einzelnen Produktteams bzw. Projektteams berücksichtigt. Die relevanten Parameter der „Wer-Matrix“ sind x die unternehmensweite Verfügbarkeit aller Benutzer wie Personen und Systemdienste (bspw. automatische E-Mail-Versendung nach Eintreten eines bestimmten Ereignisses wie Freigabe) x die Beschreibung des Kontexts; dieser ist normalerweise ein bestimmtes Projekt oder ein bestimmtes Endgerät, Baugruppe oder Einzelteil; x die kontextabhängige Rollenzuordnung: welche Rolle ist für welches Projekt oder welches Endgerät zuständig; x die eindeutige und namentliche Zuordnung zu einem verantwortlichen Benutzer in Form eines Mitarbeiters wie Noah Gebhardt. In Abb. 6-35 ist gezeigt, dass die CAD-Modellierungsdaten der Baugruppe „Welle“ dem Produkt „Axiallüfter“ mit der Artikelnummer A-650-2211 zugeordnet sind. Die Engerätenummer entstammt dem Produktdatenmo-

6.5

Die Umsetzungsphase

169

dell. Der Rolle Konstrukteur ist der Akteur Noah Gebhardt eindeutig und verantwortlich zugewiesen. Ebenso ist erkennbar, dass ein Akteur mehrere Rollen erfüllen kann: Noah Gebhardt ist gleichzeitig der Projektleiter. Die lebenszyklusabhängigen Rechte sich in der Was-Matrix dokumentiert. Die eindeutige Zuordnung eines Benutzers zu einer Aktivität erfolgt durch die Zuordnung zum Produktdaten- und/oder Prozessmodell. Axiallüfter (Artikelnr.: A-650-2211) User/Akteur 1: User/Akteur 2: Noah Gebhardt Erwin Nurcahya Rolle 1: Konstrukteur

Baugruppe Welle (Teilenr. AB-007)

Rolle 2: Projektleiter

Projekt Lager AG (Projektnr. LA-192)

…

Baugruppe Stator (Teilenr. XY-666)

…

Abb. 6-35 Allgemeine Darstellung der „Wer-Matrix“ zur Bestimmung und Dokumentation der kontextbezogenen Rollenbeschreibungen

Aufgrund der Modellbewertung und der durchgeführten Verbesserungsmaßnahmen können sich zusätzliche Anforderungen an das PDMS ergeben. So können sich bspw. bestimmte Systemfunktionalitäten für einen durchgängigen Prozessablauf als zwingend notwendig erweisen, die bislang nicht berücksichtigt wurden. Diese können bspw. die Anbindung von Ein- und Ausgabegeräten wie Scanner, Plotter oder Drucker betreffen. Auch ein grafischer Editor innerhalb des Systems erleichtert die Prozessumsetzung deutlich, da keine Programmierkenntnisse vom Anwender verlangt werden. Auf Modellebene müssen unterschiedliche Sichten wie die Konstruktions-, Fertigungs- oder Montagesicht des Produktdatenmodells dargestellt werden können. Auch die Beherrschung von Referenzproduktstrukturen ist bedeutsam. Hinsichtlich des Rollenmodells müssen vollständig definierte Standardrollen wie der Projektleiter ebenso vorhanden sein wie die Möglichkeit, unternehmensspezifische Rollen mit entsprechenden Berechtigungen lebenszyklusabhängig erstellen zu können. Derartige Anforderungen werden im Lastenheft dokumentiert. Die Erstellung eines unternehmensindividuellen Rollenmodells erscheint aufwändig. Dieser Aufwand relativiert sich jedoch schnell, wenn das Rollenmodell auch als individuelle Schulungsgrundlage für die Mitarbeiter

170

6

Lösungsbaustein 1: PDM-Systemeinführung

genutzt wird. Dies ist möglich, da jeder Rolle entsprechende Verantwortlichkeiten und Prozessschritte zugeordnet sind. Auf dieser Grundlage können die Akteure für die Ausübung ihrer spezifischen Aufgaben und Tätigkeiten gezielt geschult werden. Aus dem erstellten Schulungskonzept können auch entsprechende Funktionalitäten abgeleitet werden, die das PDMS zur effizienten Arbeitsunterstützung der Mitarbeiter erfüllen muss. Sind diese notwendigen Systemfunktionalitäten bislang nicht in der Anforderungsliste dokumentiert, müssen sie als Anforderung aufgenommen werden. Zur Ableitung von Schulungen auf der Grundlage eines Rollenmodells ist auf die Arbeiten von [Pusch 2003; Walther 2005] verwiesen. Am Ende des dritten Arbeitsschritts enthält die Projektdokumentation: x die Anforderungsliste unter besonderer Berücksichtigung der ITAnalyseergebnisse aus dem zweiten Arbeitsschritt; x sämtliche notwendigen Systemfunktionalitäten, die sich aus den Modellbewertungsergebnissen ergeben haben; x das SOLL-Konzept einschließlich der ausgewählten Modelle, die innerhalb der Pilotphase implementiert werden sollen; x den aktuellen Projektplan. Die Projektdokumentation wird zum Lastenheft, welches als schriftliche Anforderungsgrundlage für potenzielle Systemanbieter dient [Arnold et al. 2005; Pahl et al. 2005]. Anschließend wählt das Unternehmen ein oder mehrere PDMS für den vierten Arbeitsschritt aus. In diesem werden die ausgewählten Systeme innerhalb des Unternehmens unter realen Bedingungen getestet, um eine Aussage hinsichtlich ihrer Eignung und Zielerfüllung zu erhalten. Für eine effiziente Pilotphase und eine aussagekräftige Bewertung i. S. des PDMS-Einführungsszenarios ist zu diesem Zeitpunkt bedeutsam, dass die Rahmenbedingungen eindeutig definiert sind. Dies geschieht auf der Grundlage des gewählten SOLL-Szenarios in Arbeitsschritt 2 (siehe Abschn. 6.4.2). Besonders wichtig wird dies, falls mehrere Systeme gegeneinander verglichen werden sollen. Ansonsten sind keine eindeutigen Aussagen möglich. Zusätzlich müssen die Daten bzw. Modelle der zu betrachtenden Prozesse, die entsprechenden Produkte sowie ihre Verantwortlichkeiten eindeutig definiert und ebenfalls schriftlich dokumentiert vorliegen. Dies ist nur mit einer eindeutigen und sauber dokumentierten Anforderungsliste möglich; ebenso eindeutig müssen die Antworten sein, die sich am Ende der Pilotphase darauf ergeben. Wird dies nicht beachtet, so wird schlimmstenfalls die Durchführung einer weiteren Pilotphase not-

6.5

Die Umsetzungsphase

171

wendig, um die erforderlichen PDMS-Einflussgrößen sowie die gewünschte Zielerreichbarkeit bewerten zu können. Am Beginn dieses Kapitels wurde darauf hingewiesen, dass die zu implementierenden Prozesse und Produkte so einfach wie möglich und so komplex wie nötig sein müssen, um den Piloten innerhalb des zeitlich angesetzten Umfangs durchzuführen. Die gewonnenen Erkenntnisse sind für eine Bewertung und Ableitung der PDMS-Fähigkeit absolut ausreichend. 6.5.2

Arbeitsschritt 4: Die Pilotphase

In diesem Arbeitsschritt wird das ausgewählte PDMS anhand der im Lastenheft definierten Anforderungen bewertet. Dies geschieht durch seinen praktischen Einsatz innerhalb des Unternehmens. Dazu wird das System pilothaft in die vorhandene IT-Umgebung implementiert und in einen simulierten betrieblichen Ablauf eingebunden. Zusätzlich wird das bisherige Kernteam durch Spezialisten eines Systemanbieters oder eines Softwarehauses ergänzt. Ebenso können externe, neutrale Berater oder spezialisierte Consultants hinzugezogen werden, sofern dies bis zu diesem Zeitpunkt nicht schon geschehen ist. Das ehemalige Kernteam wandelt sich zum Pilotteam des PDMS-Projekts. Die Mitglieder des Pilotteams sind verantwortlich für die systemtechnische Implementierung, die Planung und Durchführung von Qualitäts- und Schulungsmaßnahmen sowie die Unterstützung der Pilotanwender. Zusätzliche Ausführungen finden sich in Abschn. 6.2.1. Besonders bedeutsam ist in diesem Arbeitsschritt eine enge Abstimmung hinsichtlich des Zielcontrollings zwischen Projektleiter, Lenkungsausschuss und Systemanbieter bzw. Softwarehaus. Wird dies nicht beachtet, werden oftmals Vorstellungen des Systemanbieters umgesetzt, die mit den gewünschten Unternehmensanforderungen nicht unbedingt übereinstimmen – man sagt, „die Software verbiegt das Unternehmen“ (vgl. hierzu die Ausführungen in Abschn. 4.4). Aus diesem Grund müssen sämtliche Mitglieder des ehemaligen Kernteams regelmäßig in die Anforderungsüberprüfungen einbezogen werden. Sie haben in den beiden ersten Arbeitsschritten die Anforderungen aufgrund ihres Arbeitsablaufs festgelegt, kennen ihre Bedürfnisse am besten und leisten somit einen unverzichtbaren Beitrag zum Anforderungscontrolling. Die Grundlage für die Überprüfung der Systemeignung bilden die im dritten Arbeitsschritt ausgewählten Modelle. Sie werden in das PDMS implementiert und die definierten Unternehmensanforderungen auf ihren Erfüllungsgrad getestet. In Abhängigkeit der PDMS-Projektressourcen umfasst

172

6

Lösungsbaustein 1: PDM-Systemeinführung

die Pilotphase eine ungefähre Zeitdauer zwischen sechs bis zwölf Monaten [Schöttner 1999; Eigner u. Stelzer 2001; Saaksvuori u. Immonen 2004; Stark 2006]. Da die Pilotphase stark von den unternehmensindividuellen Gegebenheiten beeinflusst ist, können in diesem Abschnitt nur allgemeingültige Aussagen getroffen werden. Wichtig: Das Pilotsystem darf keinesfalls in die Abläufe des aktuellen Tagesgeschäfts eingreifen, sondern läuft in einer isolierten IT-Umgebung unter Simulationsbedingungen realer, unternehmenstypischer Problemstellungen. Dies bedeutet, dass das Pilotsystem in einer eigenen IT-Umgebung unter vergleichbaren Tagesgeschäftbedingungen getestet wird, jedoch vom realen Tagesgeschäft entkoppelt sein muss. Bei einer Nichtbeachtung dieser Entkopplung besteht zu diesem Projektzeitpunkt ein hohes Risiko, dass ein Fehler innerhalb des Pilotsystems unberechenbare Auswirkungen auf die bestehende IT-Landschaft des Unternehmens hat. Mögliche Folgen sind eine Beeinträchtigung oder schlimmstenfalls ein komplettes Erliegen des realen Tagesgeschäfts. Durch die Pilotphase sollen Erfahrungen und Aussagen gewonnen werden, die hinsichtlich des Umsetzungsaufwands auf eine spätere abteilungs- bzw. unternehmensweite Systemeinführung skaliert werden können. Auch die Systemdurchdringungstiefe bezüglich des bestehenden Ablaufs soll für eine bessere Planbarkeit der Betriebsphase abgeschätzt werden. Von besonderer Bedeutung sind dabei die Punkte [Schöttner 1999; Eigner u. Stelzer 2001; Schoen 2005; Feldhusen et al. 2005b; Stark 2006]: x geschätzter Einführungs- und Umsetzungsaufwand des Systems in Bezug auf die notwendigen Ressourcen; x die Höhe der einmaligen Kosten, die mit dem eigentlichen Systemkauf, notwendigen Lizenzen oder notwendiger Hardwareanschaffungen (falls entsprechende Komponenten nicht geleast werden) verbunden sind; x die Höhe der laufende Kosten, welche durch notwendige Softwareupgrades, Systempflege und zusätzliche Lizenzen notwendig sind; x die Ermittlung der notwendigen Durchdringungstiefe des PDMS wie bspw. die Ermittlung des Umfangs und des Aufwands, mit dem vorhandene Unternehmensprozesse sinnvoll implementierbar sind; x die problemlose PDM-Systemanbindung an die bereits vorhandenen Hard- und Softwaresysteme des Unternehmens wie bspw. ERPSysteme, CAx-Systeme oder Sonderapplikationen; x der Migrationsaufwand des vorhandenen Unternehmensdatenbestands; x die Erreichung des Mehrwerts durch das PDMS entsprechend der strategischen und operativen Zielsetzungen;

6.5

Die Umsetzungsphase

173

x Anwendererfahrungen im Umgang mit dem PDMS sowie der notwendige Schulungsaufwand. An dieser Stelle sei darauf hingewiesen, dass in diesem Arbeitsschritt eine im Unternehmen vorhandene Produkt- und Prozessproblematik keinesfalls mit dem PDMS-Piloten vermischt werden darf! Dies bedeutet, dass zwischen vorhandenen aktuellen Unternehmensproblemen, die aus unzureichenden Produktstrukturen und Prozessabläufen resultieren, und der Systemeignung hinsichtlich der Leistungsfähigkeit unterschieden werden muss. Nur durch diese strikte Trennung können bspw. fehlende Systemfunktionalitäten identifiziert werden. Weitere Ausführungen finden sich in Abschn. 6.5.1

Abb. 6-36 Exemplarische Darstellung eines einfachen (Teil-)Prozesses, seiner Workflow-Umsetzung im PDMS und der zugeteilten Rollen in einem realen Industrieprojekt

Unbedingte Voraussetzung für die Bewertung der Pilotphase ist neben einer eindeutig formulierten Anforderungsliste die Wahl überschaubarer Prozesse und Produkte, die während der Pilotphase implementiert werden können. Wie bereits in den Modellanforderungen beschrieben wurde, sol-

174

6

Lösungsbaustein 1: PDM-Systemeinführung

len hier einfache, aber aussagekräftige Produkte sowie Prozesse gewählt werden. Das Problem besteht darin, einerseits Prozesse zu wählen, die im Zeitraum der Pilotphase abbildbar sind, andererseits auch die Unternehmensrealität im Tagesgeschäft abbilden. Empfehlenswert sind bspw. Abläufe zur Zeichnungsänderung, zur Mustererstellung oder zur Freigabe von beliebigen Datenobjekten; nicht empfehlenswert sind komplexe Prozesse wie der gesamte Änderungsprozess oder Prozesse, die einen Concurrent Engineering-Anteil bzw. Simultaneous-Engineering-Anteil enthalten. Eine erfolgreiche Modellimplementierung darf nicht darüber hinwegtäuschen, dass im Unternehmen hochkomplexe Produkte und Prozesse vorhanden sind, deren Implementierung während einer möglichen späteren Betriebsphase einen deutlich erhöhten Aufwand verlangen. Eventuell bedingt dies auch ein Modell-Reengineering mit Auswirkungen, wie sie in Abschn. 4.1 kurz im Zusammenhang mit dem konventionellen Entwicklungs-/Konstruktionsprozess angesprochen wurden. In Abb. 6-36 sind exemplarisch die beschriebenen Zusammenhänge illustriert; sie entstammen einem realen Industrieprojekt. Selbstverständlich zeigt die Abb. nur einen Ausschnitt aus der Gesamtimplementierung. Die daraus resultierenden Anforderungen an die Pilotphase lassen sich mit den folgenden Stichworten zusammenfassen: x definierte Abbildung der gewählten Prozesse und Produkte, x überschaubarer Aufwand zur Modellierung und Implementierung während der Pilotphase, x eindeutige Prüfung der definierten Unternehmens- und Systemanforderungen, die im Lastenheft dokumentiert sind und x Beurteilung der erhaltenen Ergebnisse aus dem SOLL-IST-Vergleich zwischen Pilotphase und Lastenheft.; x eingehendes Testing des ausgewählten Systems oder der ausgewählten Systeme anhand definierter Aufgabenstellungen in einer isolierten Testumgebung unter realen Bedingungen des Tagesgeschäfts zusammen mit dem Pilotteam. Dies umfasst die Systemfunktionalitäten und ihre Anwendungen ebenso wie die Anbindung an vorhandene IT-Systeme, eine exemplarische Datenmigration oder die Durchführung von Schulungen. Werden diese Forderungen nicht oder nicht genügend beachtet, kann dies zu einer Wiederholung des Arbeitsschritts und einer neuen Pilotphase führen. Nur bei einer Einhaltung werden die Systemanbieter und/oder die Softwarehäuser zu einer klaren Aussage hinsichtlich der Leistungsfähigkeit ihres Systems gezwungen. Dies ist insbesondere bedeutsam, wenn während der Pilotphase zwischen mehreren PDM-Systemen unterschiedli-

6.5

Die Umsetzungsphase

175

cher Anbieter verglichen werden soll. Selbstverständlich müssen hierfür eindeutige Rahmenbedingungen geschaffen werden, damit die Ergebnisse i. S. eines Benchmarks einerseits überhaupt vergleichbar und andererseits auch aussagekräftig sind. Dies geschieht wiederum auf der Grundlage einer eindeutig definierten Anforderungsliste für Prozesse und Produkte. Arbeitswochen

Vorbereitung

1

2

System-Installation Einweisung Training

4

5

6

7

Anpassung 2 Anpassung 3

Projektabschluss

9

10

11

22 Tage 3 8 4 7 40 Tage

Anpassung Anpassung 1

8

14 Tage

Installation Vor-Installation

3

2 14 19 5

Abb. 6-37 Schematisierter Ablauf einer dreimonatigen Pilotphase in einem Industrieprojekt

Der vierte Arbeitsschritt basiert – neben dem Lastenheft und den definierten Modellen – auf einem pilotspezifischen Projektplan. Er umfasst sämtliche notwendigen Aktivitäten, die für eine spätere Erfahrungsskalierung notwendig sind. Der schematisierte Projektplan, welcher in Abb. 6-37 dargestellt ist, entstammt einem durchgeführten Industrieprojekt. Ein Ausschnitt aus dem tatsächlichen Projektplan zeigt Abb. 6-38. Beide Abbildungen sollen einen Eindruck hinsichtlich der Anzahl von Aktivitäten innerhalb einer realen Pilotphase vermitteln. An dieser Stelle sei angemerkt, dass in dem beschriebenen Industrieprojekt aus strategischen und firmeninternen politischen Gründen die Dauer der Pilotphase mit drei Monaten veranschlagt war. Zwar wurde die Pilotphase innerhalb dieser Zeit durchgeführt; um dies zu erreichen, konnten jedoch einige Bewertungen nur oberflächlich durchgeführt werden (vgl. das in Kap. 9 beschriebene Fallbeispiel). Für eine Erfassung des optimalen PLMPotenzials werden sechs bis zwölf Monate für die Pilotphase empfohlen. Neben den Inhalten können wichtige Erfahrungen bei dem Pilotteam und den beteiligten Mitarbeitern gesammelt werden.

176

6

Lösungsbaustein 1: PDM-Systemeinführung

Abb. 6-38 Auszug aus dem Projektplan eines realen Industrieprojekts

Die Pilotimplementierung beinhaltet folgende Einzelphasen: x In der Vorbereitungsphase wird das Pilot-Projektmanagement zwischen dem Systemanbieter und dem Unternehmen koordiniert. Anschließend wird das ausgewählte Projektteam mit der geplanten Vorgehensweise vertraut gemacht. Insbesondere betrifft dies den geplanten Projektablauf inklusive benötigter Ressourcen (zur Planung von personellen und/oder organisatorischen Einschränkungen bspw. in der IT-Abteilung, an Anwenderarbeitsplätzen oder Belegung von Schulungsräumen) sowie den Schulungsablauf. Hierzu gehören neben den eigentlichen Schulungsterminen der Schulungstyp wie Anwender- oder Administratorenschulung, sowie die Auswahl der Schulungsteilnehmer und die Festlegung der Schulungsumfänge. Die Schulungen selbst finden begleitend nach der PDM-Systeminstallation und während der gesamten Anpassungsphase statt. Dies beinhaltet auch die Systemeinweisung für die IT-Spezialisten. Empfohlen wird, dass sich die unternehmenseigenen IT-Mitarbeiter des Pilotteams von Beginn der Installationsphase mit den externen PDMSystemexperten austauschen; damit ist ein Maximum an wertvoller Wissensgenerierung für das Unternehmen gewährleistet. Mit einem Kick-Off-Meeting ist die Vorbereitungsphase abgeschlossen. x In der Installationsphase wird das PDMS implementiert. Dies umfasst in einer Vor-Installation die Vorbereitung der vorhandenen Hardware und des Netzwerks. Danach wird die PDM-Systemsoftware installiert

6.5

Die Umsetzungsphase

177

und ihre Netzwerkanbindung überprüft. In Kap. 9 ist eine ITArchitektur beispielhaft gezeigt und erläutert. Nach der Systemeinweisung durch die externen Softwarespezialisten wird das Projektteam einschließlich der beiden Administratoren für die Nutzung des PDMS geschult. Dies beginnt unmittelbar nach der Systeminstallation. x In der Anpassungsphase werden die ausgewählten Modelle des dritten Arbeitsschritts implementiert und eine exemplarische Datenmigration durchgeführt. Anschließend erfolgen zusammen mit dem Projektteam mehrere iterative System- und Modellanpassungen. Dies geschieht auf der Grundlage eines „angeleiteten Ausprobierens“ durch den Schulungsleiter und den Mitgliedern des Pilotteams. Während dieser Phase nutzen die Anwender des Pilotteams das PDMS weiter und vertiefen ihre Fähigkeiten im Umgang mit dem System nach ihren zugewiesenen Aufgaben wie Anwendungsnutzung oder Administrierung anhand von realen Aufgabenstellungen. Anschließend wird die von den Anwendern empfundene Systemunterstützung diskutiert und dokumentiert. Sie bildet die Grundlage für eine iterative Verbesserung, die im nächsten Anwendungsschritt gemeinsam umgesetzt wird. Durch diese Vorgehensweise wird nicht nur Akzeptanz des PDMS bei den Pilotanwendern gesteigert, es lässt sich auch der Detaillierungsgrad der implementierten Modelle bestimmen. So können bspw. bestimmte Stellen innerhalb des Workflows identifiziert werden, an denen sich die Anwender durch das System im Rahmen ihrer Tätigkeitsausübung als zu eingeschränkt fühlen. Von besonderer Bedeutung sind in dieser Phase auch Aussagen hinsichtlich der Bedienbarkeit und Ergonomie des ausgewählten Systems. Dies betrifft v. a. die Strukturierung der grafischen Bedienoberfläche (GUI – Graphic User Interface). Hierbei sind Aspekte wie selbsterklärende Menüs oder logische Unterstützung der Anwender bei der Nutzung von Funktionalitäten zu beachten. Ein besonderes Augenmerk muss auf eine einfache, schnelle und zuverlässige Suchfunktionalität gelegt werden. x In der Projektabschlussphase werden die gesammelten Erfahrungen sowohl auf IT-Ebene als auch auf Anwenderebene aufbereitet. Dies beinhaltet auch einen Ausblick auf die Vorgehensweise einer möglichen umfassenden Systemeinführung einschließlich Schulungskonzept im Anschluss an die Pilotphase. Zusätzlich können die Aufwände für die Modellerstellung der nicht betrachteten Produkte bzw. Prozesse besser abgeschätzt werden.

178

6

Lösungsbaustein 1: PDM-Systemeinführung

Durch eine erneute CSC-Bewertung auf der Grundlage der PDMSEinflussgrößen wird die erreichte SOLL-PDMS-Fähigkeit nach Abschluss der Pilotphase ermittelt. Die zweite Bewertung sollte idealerweise im Vergleich zur ermittelten IST-PDMS-Fähigkeit am Ende des zweiten Arbeitsschritts aufgrund der umgesetzten Verbesserungsmaßnahmen einen besseren Reifegrad für das Unternehmen aufweisen. Zusätzlich dient sie zur Überprüfung der ermittelten SOLL-PDMS-Fähigkeit, falls diese für das gewählte Umsetzungsszenario aus dem zweiten Arbeitsschritt ermittelt wurde. Damit kann eine Aussage über den Grad der Zielerreichbarkeit getroffen werden. Als weiteres Ergebnis der Pilotphase erhält man eine Aussage über die Eignung des Pilotsystems durch die Mitglieder des Pilotteams. Hier spielen Kriterien wie die Bedienerfreundlichkeit, die Erlernbarkeit, die empfundene Arbeitsunterstützung, die Administration und der vorhandene Funktionalitätsumfang eine Rolle. Sowohl aufgrund der gewonnenen Ergebnisse als auch aufgrund der CSCBewertung entscheidet das Unternehmensmanagement über die weiteren Vorgehensschritte. Wurden die definierten Zielsetzungen nicht erreicht, beginnt ein erneuter Durchlauf des PDMS-Regelkreises, bis das festgelegte Abbruchkriterium erreicht ist (siehe Abschn. 5.2). Bei einer zufrieden stellenden Zielerreichung wird entschieden, ob das PDMS im Unternehmen eingeführt wird und in die Betriebsphase übergeht. Das eigentliche PDMSProjekt ist mit dieser letzten Entscheidung beendet. Die Entscheidung über die weitere Vorgehensweise sowie sämtliche Ergebnisse aus der Pilotphase einschließlich der CSC-Bewertung werden in die Projektdokumentation eingepflegt. Falls sich aufgrund ungenügender Zielerfüllungen oder anderer Gründe das Management gegen eine Betriebsphase entscheidet, muss ein entsprechendes Ausstiegsszenario erarbeitet werden. So kann es in der Praxis vorkommen, dass bspw. nur Teilergebnisse aus der Pilotphase umgesetzt werden sollen. Dies ist häufig der Fall, wenn bestimmte Systemfunktionalitäten wie das Workflowmanagement bereits durch bestehende Systeme abgedeckt werden können. Das Ausstiegsszenario könnte bspw. auf der Grundlage der vorgestellten Szenarien 1 oder 2 (vgl. Abschn. 6.4.2) entwickelt werden; eine unternehmensweite Systemeinführung nach Beendigung der Pilotphase ist nicht immer sinnvoll.

6.6

Die Betriebsphase

179

6.6 Die Betriebsphase Sofern sich das Management für eine Einführung des PDMS entschieden hat, beginnt nun die Betriebsphase. Aufgrund der Ergebnisse des vierten Arbeitsschritts und der Erfahrungen während der Pilotimplementierung können die relevanten Fragen nach Aufwand, Durchdringungstiefe und Anbindungsmöglichkeiten beantwortet und auf den beabsichtigten Umfang der gesamten Einführung skaliert werden. An dieser Stelle ist darauf hinzuweisen, dass mit dem Ende der Pilotphase erst ein kleiner Teil der Aufgaben, die eine Systemeinführung mit sich bringt, abgeschlossen ist. Nun erfolgt die umfassende Umsetzung sämtlicher Modelle. Sie müssen ständig aktualisiert und den Unternehmensgegebenheiten angepasst werden. Möglicherweise decken auch die vorhandenen Standardrollen des PDMS die Anforderungen der bestehenden Aufbauorganisation nicht oder nur unzureichend ab. In einem solchen Fall muss das Rollenmodell spätestens zu diesem Zeitpunkt erstellt bzw. erweitert werden. Je nach Größe des Unternehmens stellt die Modellierung und Modellpflege eine Vollzeitaufgabe für einen oder mehrere PDMSSpezialisten dar. Aufgrund dieser Ausführungen ist es bedeutsam, dass vor Beginn jeglicher Aktivitäten für die Betriebsphase ein PDMS-Einführungskonzept ausgearbeitet wird, welches die Migration, den Roll-Out und die Überführung des PDMS in die Breitenanwendung beinhaltet. Dieses Konzept umfasst auch einen Projektplan mit definierten Meilensteinen sowie die Zuweisung der Abteilungen bzw. der Mitarbeiter zu den einzelnen Schulungsmaßnahmen. Ebenso ist die Einbettung in die bestehende IT-Systemlandschaft hinsichtlich der Systemanbindungen, der daraus resultierenden Schnittstellen oder auch die Festlegung des führenden Systems für die Systemfunktionalitäten zu planen. Der letzte Aspekt beschäftigt sich mit der Frage, ob bspw. bestimmte Daten im ERP-System geändert werden sollen und das PDMS auf diese Daten zugreift oder umgekehrt. Dazu müssen Workflows definiert und die entsprechenden Datenobjekttypen zugewiesen werden; so ist es nicht sinnvoll, Konstruktionsdaten im ERP-System zu ändern, wogegen betriebswirtschaftliche Daten nicht im PDMS bearbeitet werden sollten. Eine ähnliche Entscheidung hinsichtlich des führenden Systems ist auch bei der Anlage von Artikelstämmen zu treffen. Diese genau festgelegte Zuweisung ist für eine Vermeidung von Dateninkonsistenzen unabdingbar. Bedeutsame Umsetzungsinhalte auf der Grundlage des gewählten SOLLSzenarios aus dem zweiten Arbeitsschritt sind für die Betriebsphase

180

6

Lösungsbaustein 1: PDM-Systemeinführung

x die Migration des Altdatenbestandes. Um den Migrationsaufwand überschaubar zu halten, muss eine kritische Überprüfung der lohnenswerten Produktdaten durchgeführt werden. So lohnt sich in vielen Fällen die Migration von Produktdaten nicht mehr bei Produkten, die bereits am Ende ihres Lebenszyklus stehen und die vom Unternehmen nicht mehr weitergeführt werden sollen. Ein anderes Auswahlkriterium betrifft die Zeitspanne zwischen der letzten Datenverwendung und dem Migrationszeitpunkt. Bei Daten, die bspw. in den letzten fünf Jahren nicht mehr benötigt wurden, sollte deren Migration kritisch hinterfragt werden; x Definition der Systemhierarchien auf IT-Ebene (führendes System) und die Zuweisung der Datenobjekttypen zur Vermeidung von Dateninkonsistenzen sowie zur Gewähr der Datenaktualität; x die Ressourcenplanung hinsichtlich der Gesamteinführung des PDMS einschließlich zeitlicher Vorgaben und entsprechender Kennzahlen für das Controlling; x die Einrichtung eines zertifizierungsfähigen Langzeitarchivs für sämtliche Produktdaten im Rahmen einer DIN ISO-Zertifizierung und zur Gewährleistung der Produkthaftung, wie dies bspw. in der Luftfahrtindustrie gesetzlich vorgeschrieben ist. In diesem Langzeitarchiv sind auch diejenigen Daten gespeichert, die im Rahmen der o. g. Migrationsüberprüfung als augenblicklich nicht lohnenswert eingestuft wurden. Im Anschluss an das Erfahrungs-Review der Pilotphase folgt im Regelfall das Roll-Out des PDMS. Darunter wird das unternehmensweite PDMSEinführungsprojekt verstanden. Das Einführungsprojektteam besteht idealerweise neben dem Pilotteam des PDMS-Projekts auch aus Vertretern derjenigen Abteilungen bzw. Unternehmensstandorte, in denen das PDMS produktiv eingeführt werden soll. In diesem Gremium werden sämtliche Informationen bzw. Kennwerte zusammengetragen und durch die Fachkompetenz der Teammitglieder verifiziert. Zusätzlich nimmt das Einführungsprojektteam die Anforderungen sowie die auftretenden Probleme aus dem laufenden PDMS-Betrieb auf, entwickelt entsprechende Lösungen und leitet deren Umsetzung ein. Dies wird durch die Anwendung des PDMS-Regelkreises signifikant unterstützt. Typische Kennwerte innerhalb der Betriebsphase sind bspw. x die Anzahl der geplanten PDMS-User, die in der Endausbaustufe des PDMS das System tatsächlich zur Unterstützung ihrer Arbeit nutzen sollen. Anhand dieses Kennwerts kann die Anzahl der benötigten Softwarelizenzen, der Umfang von erforderlichen externen Serviceleistun-

6.6

Die Betriebsphase

181

gen (Service Level Agreements - SLA’s) oder auch der Umfang erforderlicher Serverkapazitäten abgeschätzt werden. x der Umfang vorhandener Hardware. Dabei ist die vorhandene Hardware zu überprüfen, ob sie denjenigen Systemanforderungen, wie sie für den Roll-Out festgelegt wurden, auch genügt. Sollte sie unterdimensioniert sein, so müssen entsprechende Anpassungen durchgeführt werden. Möglicherweise ist es die beste und preisgünstigste Lösung, die vorhandene Hardware-Infrastruktur komplett zu ersetzen. Dies ist insbesondere zu überdenken, falls mögliche Systemausfallzeiten aufgrund mangelhafter Rechnerkapazität in derartige Überlegungen einbezogen werden. Dieser Fall ist jedoch unter Einbeziehung aller Kosten sorgsam abzuwägen. x der Qualifizierungsstand der (zukünftigen) Anwender. Neben einem technisch problemlos funktionierenden PDMS ist die sichere Systembedienung durch die Anwender eine ebenso wichtige Grundvoraussetzung. In einem ersten Schritt zur Erstellung von individuellen Anwenderschulungen muss deshalb der Qualifizierungsstand der Mitarbeiter aufgenommen werden. Er wird mit denjenigen Anforderungen zur Ausübung von Tätigkeiten verglichen, die auf der Grundlage des Rollenmodells dokumentiert wurden. Anschließend muss ein Schulungskonzept entwickelt werden, das standardisiert genug ist, um es bspw. bei der Einarbeitung neuer Mitarbeiter wiederholt einsetzen zu können. Zusätzlich muss es jedoch auch modular aufgebaut sein, um individuelle Vorkenntnisse der Anwender berücksichtigen zu können. Aus diesem Grund besteht im Idealfall ein derartiges Schulungskonzept aus mehreren Bausteinen: Aufbauend auf einem Grundkurs lassen sich spezielle Schulungsbausteine weitgehend frei miteinander kombinieren. Dabei ist zu berücksichtigen, dass Anwender aus der Entwicklung, dem Vertrieb oder der Fertigung unterschiedliche Sichten auf das PDMS haben. Zwar nutzt die Fertigung das PDMS nur indirekt; sie müssen jedoch auf die (visualisierten) Produktdaten mittels einer geeigneten Viewing-Software zugreifen können. Eine ähnliche Aussage kann für die Mitarbeiter des Vertriebs getroffen werden, die bspw. ein ProduktkonfigurationsSoftwaremodul zur Verkaufsunterstützung bei ihren Kunden einsetzen. Die Schulungsinhalte der einzelnen Bausteine müssen diese abteilungsspezifischen Anforderungen entsprechend berücksichtigen. Neben den beschriebenen Kennwerten wird ein erfolgreicher Roll-Out im Unternehmen noch von folgenden Aspekten beeinflusst: x Bei der Frage nach organisatorischen Verantwortlichkeiten muss abgeklärt werden, welcher der systemnutzenden Unternehmensbereiche

182

x

x

x

x

6

Lösungsbaustein 1: PDM-Systemeinführung

Mandatsfunktionen, Linienverantwortung und letztendlich auch Kostenverantwortung des PDMS-Betriebs übernimmt. Ein mit der organisatorischen Verantwortung verbundener Aspekt ist die systemtechnische Verteilung des PDMS im Unternehmen [Schöttner 1999; Gulbins et al. 2002; Bernus u. Schmidt 2006]: Soll ein PDMS zentral an einer Stelle installiert sein oder ist eine Dezentralisierung mit mehreren PDM-Systemen, v. a. in den einzelnen Standorten, sinnvoller? Die Erfahrung zeigt, dass sich in Großunternehmen die Systemzentralisierung durchgesetzt hat; es ist zu erwarten, dass mittelständische Unternehmen diesem Trend folgen. Zusammen mit der systemtechnischen Verteilung müssen zeitgleich die Systementwicklung und Systemanpassungen während des Roll-Outs an die bestehenden Unternehmensanforderungen geplant werden. Hierbei ist besonders die Einbindung von Zulieferbetrieben zu berücksichtigen. Die Verantwortlichkeit liegt entweder in der IT-Abteilung oder beim Einführungsteam. Besondere Aufmerksamkeit muss der Frage nach der Systemoptimierung und der Fehlerbehebung gewidmet werden. Nach der Einführung bildet das PDMS häufig die systemtechnische Wirbelsäule des gesamten Entwicklungsprozesses [Schuh 2005]. Aus diesem Grund müssen mögliche Systemausfallzeiten minimiert werden, um die Durchgängigkeit der unternehmensweiten D&I-Flüsse zu garantieren. Typische auftretende Probleme während des Systembetriebs umfassen bspw. signifikantes Absinken der Performance, komplette Systemausfälle oder auch methodische Unklarheiten im Ablauf. In derartigen Fällen muss ein systematischer „Einsatzplan“ (ein sog. Support-Netzwerk) zur Beherrschung dieser Probleme vorhanden sein. Dieses Support-Netzwerk besteht aus mehreren Stufen, die der Komplexität des auftretenden Problems angemessen sind. Beispiele sind User-Helpdesks bzw. Hotlines, bei denen Anwender aufgetretene Systemstörungen melden können und die sofort behoben werden. Bei umfangreicheren Problemen muss der Softwarelieferant zeitnah den vollständigen PDMS-Funktionseinsatz sicherstellen. Methodische Ablaufbrüche werden durch das Einführungsprojektteam eliminiert. Die Aktualisierung der Systemsoftware geschieht in der Praxis in kleinen Durchführungsschritten, um die Systemstabilität des gesamten laufenden IT-Betriebs nicht zu gefährden. Dabei muss zwischen den beiden Möglichkeiten einer viertel- bzw. halbjährlichen Releaseplanung oder einer kurzfristigen Einspielung von Änderungen in das PDMS abgewägt werden (Paketierung vs. Patches). Für die Durchführung ist entweder das Einführungsteam oder die IT-Abteilung verantwortlich.

Zusammenfassung Kapitel 6

183

Anhand der aufgeführten Aspekte wird deutlich, dass ein erfolgreicher PDMS-Roll-Out wesentlich von dem Einbettungsgrad in das Netzwerk abhängig ist, welches von abteilungsinternen, abteilungsübergreifenden und standortübergreifenden Prozessen gebildet wird. Aufgrund der ständigen Veränderung von unternehmensinternen Prozessen, Organisationsstrukturen und Produkten wird zusätzlich deutlich, dass die Systemanpassung auch nach Beendigung des Roll-Outs nicht abgeschlossen sein kann. Nur durch die Umsetzung eines kontinuierlichen Verbesserungsprozesses (KVP) wird das gewünschte Potenzial eines PDMS vollständig ausgeschöpft. Somit stellen die PLM-Strategie und deren PDMS-Umsetzung eine permanente, „lebende“ Aufgabe dar, die im Laufe der Zeit in der Unternehmensphilosophie verankert werden muss. Zur Durchführung des KVP kann der PDMS-Regelkreis nicht nur während der eigentlichen Einführunsphase, sondern ebenfalls während der Betriebsphase angewendet werden. Damit ist ein ständiges Controlling der PLM-Strategie, ihrer Ziele und eine Ermittlung der PDMS-Fähigkeit auf operativer Ebene möglich. So können Zielabweichungen schnell und eindeutig ermittelt werden; durch die Einleitung spezifischer Verbesserungsmaßnahmen werden potenzielle Probleme bereits während ihrer Entstehung eliminiert. Die offene Vorgehensweise des PDMS-Regelkreises erlaubt auch eine permanente Zielanpassung. So können neue strategische Unternehmensziele, die sich bspw. aus einer Veränderung des Marktes ergeben, in die PLM-Strategie neu aufgenommen und auf die operative Ebene heruntergebrochen werden. Überholte Zielsetzungen lassen sich aus der Anforderungsliste streichen.

6.7 Zusammenfassung Kapitel 6 Im fünften Kapitel wurde der PDMS-Regelkreis als Lösungsansatz zur Einführung eines PDMS und zur Bewertung der augenblicklichen Unternehmenseignung hinsichtlich des Systemeinsatzes im Unternehmen vorgestellt. In diesem Kapitel wurde der erste Lösungsbaustein beschrieben. Er beinhaltet die methodische Vorgehensweise zur PDMS-Einführung. Neben dieser Zielsetzung erfüllt er auch die unternehmensindividuelle Ermittlung der PDMS-Einflussgrößen zur Bewertung der PDMS-Fähigkeit mittels der Capability Scorecard (CSC).

184

6

Lösungsbaustein 1: PDM-Systemeinführung

Einführend wurde der Ablauf des gesamten PDMS-Projekts, die notwendige Projektorganisation mit ihren Instanzen und Aufgaben sowie die „inoffizielle“ Vorklärungsphase innerhalb des Unternehmens erläutert. Danach wurde der eigentliche Projektablauf detailliert vorgestellt und die einzelnen Arbeitsschritte sowie die eingesetzten Hilfsmittel beschrieben. Das PDMS-Projekt besteht aus der Untersuchungsphase und der Umsetzungsphase. Jede einzelne Phase besteht aus jeweils zwei Arbeitsschritten. In der Untersuchungsphase werden im ersten Arbeitsschritt die strategischen Ziele mit dem Management definiert und mit dem Kernteam auf die operative Ebene umgesetzt. Diese Ziele werden durch entsprechende Bewertungskriterien beschrieben, priorisiert und in einer Anforderungsliste dokumentiert. Anschließend erfolgt eine IST-Analyse des Unternehmens auf der Grundlage der PDMS-Einflussgrößen. Aus den Analyseergebnissen und der Anforderungsliste wird ein gewünschtes SOLLEinführungsszenario abgeleitet. Durch den Vergleich zwischen dem ISTZustand und dem SOLL-Szenario wird mittels der CSC die augenblickliche IST-PDMS-Fähigkeit ermittelt. Dies sind die Inhalte des zweiten Arbeitsschritts. Mit dem dritten Arbeitsschritt beginnt die Umsetzungsphase. In ihm findet eine Modellerstellung oder eine Modellergänzung (das sog. ModellReengineering) auf der Ebene der Produkte, Prozesse und der Aufbauorganisation statt. Die Modelle werden auf ihre Eignung hinsichtlich ihrer PDMS-Implementierungsfähigkeit geprüft und entsprechend überarbeitet bzw. neu erstellt. Sämtliche Modelle werden im vierten Arbeitsschritt pilothaft in das ausgewählte PDMS implementiert. In dieser Pilotphase muss sich das System unter realen Unternehmensbedingungen in einer abgeschlossenen Testumgebung bewähren. Damit können einerseits die Erfüllung der definierten Anforderungen durch das PDM-System selbst, aber auch Aussagen hinsichtlich der Durchdringungstiefe oder den Ressourcenaufwand bei einer späteren, möglichen unternehmensweiten Einführung abgeleitet werden. Ebenso wird mittels der CSC der Erreichungsgrad der SOLL-PDMS-Fähigkeit ermittelt und mit der IST-PDMS-Fähigkeit verglichen. Bei einem ungenügenden Ergebnis findet eine erneute, iterative Durchführung aller oder auch nur einzelner Arbeitsschritte statt. Die Testumgebung ist notwendig, um das reale Tagesgeschäft durch mögliche Fehler innerhalb der Pilotphase nicht zu gefährden. Alle vier Arbeitsschritte unterteilen sich in einzelne Teilarbeitsschritte mit konkreten Handlungsanweisungen. Sie und ihre eingesetzten Hilfsmittel wurden in diesem Kapitel ebenfalls beschrieben.

Zusammenfassung Kapitel 6

185

Literatur Abramovici M, Schulte S, Leszinski, C (2005) Best Practice Strategien für die Einführung von Product Lifecycle Management. In: Industrie Management 21. GITO, Berlin Anderl R, John H, Pütter C (2006) EXPRESS. In: Handbook on Architectures of Information Systems, 2nd edition. Springer, Berlin-Heidelberg-New York Arnold V, Dettmering H, Engel T, Karcher A (2005) Product Lifecycle Management beherrschen. Springer, Berlin-Heidelberg-New York Asendorpf JB (1996) Psychologie der Persönlichkeit. Springer, Berlin-Heidelberg, New York Becker J, Kahn D, Wernsmann C (2003) Project Management. In: Process Management - A Guide for The Design of Business Processes. Springer, BerlinHeidelberg-New York Bernus P, Schmidt G (2006) Architectures of Information Systems. In: Handbook on Architectures of Information Systems, 2nd edition. Springer, BerlinHeidelberg-New York Brandt T (2002) Analyse existierender Ansätze zur Wirtschaftlichkeitsberechnung. In: Qualität und Wirtschaftlichkeit. Symposion, Düsseldorf Breiing A, Knosala R (1997) Bewerten technischer Systeme – theoretische und methodische Grundlagen bewertungstechnischer Entscheidungshilfen. Springer, Berlin-Heidelberg-New York Cassel M (2003) Qualitätsmanagement nach ISO-9001:2000 - Grundwerk. Hanser, München-Wien DIN 66001 (1983) Informationsverarbeitung – Sinnbilder und ihre Anwendung. Beuth, Berlin-Wien-Zürich DIN 69901 (1987) Projektwirtschaft, Projektmanagement, Begriffe. Beuth, BerlinWien-Zürich Eigner M, Stelzer R (2001) Produktdatenmanagement-Systeme - ein Leitfaden für Product Development und Life Cycle Management. Springer, BerlinHeidelberg-New York Feldhusen J, Gebhardt B, Nurcahya E, Macke N (2004) Das unternehmensindividuelle Produktdatenmodell als Voraussetzung einer erfolgreichen PDMSEinführung. In: 2. Gemeinsames Kolloquium Konstruktionstechnik (Tagungsband). Dresden, Saxoprint Feldhusen J, Gebhardt B (2005a) Der Weg zum individuellen Produkt – Redefintion eines Variantenerzeugungsprozesses in der Praxis. In: 3. Gemeinsames Kolloquium Konstruktionstechnik (Tagungsband). Shaker, Aachen Feldhusen J, Gebhardt B, Macke N, Nurcahya E, Bungert F (2005b) Development of A Set of Methods To Support The Implementation of A PDMS for SME’s with A High Product Variance. In: Proceedings of CIRP, 12th Seminar on Life Cycle Engineering. Springer, Dordrecht Feldhusen J, Gebhardt B, Macke N, Nurcahya E (2005c) Entwicklung einer Methodik zur Einführungsunterstützung eines PDMS bei KMU’s mit hoher Produktvarianz. In: Konstruktion 6-2005. Springer-VDI, Düsseldorf

186

6

Lösungsbaustein 1: PDM-Systemeinführung

Feldhusen J, Gebhardt B, Macke N, Nurcahya E (2006a) Development of An Enterprise-individual Role Model for Increase of Process Efficiency within A PLM-strategy. In: Tools And Methods of Competitive Engineering. University of Technology, Delft Feldhusen J, Gebhardt B, Nurcahya E, Bungert F (2006b) Development of A Performance Measurement System for A SME’s PDMS-capability. In: Tools And Methods of Competitive Engineering. University of Technology, Delft Fischer F, Scheibeler AAW (2003) Handbuch Prozessmanagement. Hanser, München-Wien Frech M, Schmidt A, Heimerl-Wagner P (1999) Management - drei klassische Konzepte und ihre Befunde. In: Management – Theorien, Führung, Veränderung. Schaeffer-Poeschel, Stuttgart Gebhardt B (2007) Abschätzung der Produktdatenmanagement-Systemfähigkeit produzierender Unternehmen. Shaker, Dissertation RWTH Aachen Gulbins J, Seyfried M, Strack-Zimmermann H (2002) Dokumentenmanagement, 5. Auflage. Springer, Berlin-Heidelberg-New York Hansel J, Lomnitz G (2003) Projektleiter-Praxis – optimale Kommunikation in der Projektarbeit, 4. Auflage. Springer, Berlin-Heidelberg-New York Höfener C (1999) Methode zur Bewertung des strategischen Nutzens von integriertem Produktdaten-Management. Dissertation, Technische Universität Darmstadt ISO 9000 (2000) Qualitätsmanagementsysteme – Grundlagen und Begriffe. Beuth, Berlin-Wien-Zürich ISO 9004 (2000) Qualitätsmanagementsysteme – Leitfaden zur Leistungsverbesserung. Beuth, Berlin-Wien-Zürich ISO 10303 (1994) Industrielle Automatisierungssysteme und Integration. Beuth, Berlin-Wien-Zürich ISO 10303-11 (1992) The EXPRESS Language Reference Language Manual, Product Data Representation and Exchange - Part 11. Beuth, Berlin-WienZürich Klaus A (2006) Innovation und Wertschöpfungssteigerung im PLM-Kontext durch Integration von MES. In: Karlsruher Leittechnisches Kolloquium 2006. Fraunhofer IRB, Stuttgart Kletti J (2007) Konzeption und Einführung von MES-Systemen. Springer, BerlinHeidelberg-New York Kramer F, Kramer M (1997) Bausteine der Unternehmensführung, 2. Auflage. Springer, Berlin-Heidelberg-New York Krause FL, Franke HJ, Gausemeier J (2007) Innovationspotenziale in der Produktentwicklung. Hanser, München-Wien Kütz M (2003) Kennzahlen in der IT – Werkzeuge für Controlling und Management. Heidelberg, dpunkt Lindemann U, Reichwald R (1998) Integriertes Änderungsmanagement. Springer, Berlin-Heidelberg-New York McAffee A (2003) When Too Much IT-Knowledge Is A Dangerous Thing. In: MIT Sloan Management Review Winter, Vol. 44 No. 2. Massachusetts, MIT School of Sloan Management

Zusammenfassung Kapitel 6

187

Müller J (2005) Workflow-based Integration. Springer, Berlin-Heidelberg-New York Mylopoulos J, Borgida A (2006) Properties of Information Modelling Techniques for Information Systems Engineering. In: Handbook on Architectures of Information Systems, 2nd edition. Springer, Berlin-Heidelberg-New York Ophey L (2005) Entwicklungsmanagement - Methoden in der Produktentwicklung. Springer, Berlin-Heidelberg-New York Pahl G, Beitz W, Feldhusen J, Grote KH (2005) Konstruktionslehre - Grundlagen erfolgreicher Produktentwicklung, 6. Auflage. Springer, Berlin-HeidelbergNew York Pusch R (2003) Personalplanung und -entwicklung in einem integrierten Vorgehensmodell zur Einführung von Produktdatenmanagementsystemen. Dissertation, Universität Paderborn Rosemann M (2003) Preparation of Process Modelling. In: Process Management – A Guide for The Design of Business Processes. Springer, Berlin-HeidelbergNew York Saaksvuori A, Immonen A (2004) Product Lifecycle Management, 2nd edition. Springer, Berlin-Heidelberg-New York Schmidt M (2002) Business Case Guide, 2nd edition. Solution Matrix Ltd, Boston Scheer AW (2001) ARIS – Modellierungsmethoden, Metamodelle, Anwendungen, 4. Auflage. Springer, Berlin-Heidelberg-New York Schoen R (2005) PLM-Einführung mit Erfolg - Risiken & Wirtschaftlichkeitsaspekte. In: Product Lifecycle Management - mit System zum Erfolg. Seminar am WZLforum der RWTH Aachen am 25.01.2005 Schöttner J (1999) Produktdatenmanagement in der Fertigungsindustrie - Prinzip, Konzepte, Strategie. Hanser, München-Wien Schuh G (2005) Produktkomplexität managen, 2. überarbeitete Auflage. Hanser, München-Wien Schwab A (2004) Managementwissen für Ingenieure. Springer, BerlinHeidelberg-New York Sendler U, Wawer V (2005) CAD und PDM - Prozessoptimierung durch Integration. Hanser, München-Wien Stark J (2006) Product Lifecycle Management - 21st Century Product Paradigm for Product Realisation, 3rd edition. Springer, London VDI-Richtlinie 2219 Informationsverarbeitung in der Produktentwicklung - Einführung und Wirtschaftlichkeit von EDM/PDM-Systemen. Beuth, BerlinWien-Zürich Walther I (2005) Rollen- und Situationsmodellierung bei betrieblichen Dispositions- und Planungssystemen. Dissertation, Technische Universität ErlangenNürnberg Wassermann O (2004) Das intelligente Unternehmen, 5. Auflage. Springer, Berlin-Heidelberg-New York Wehlitz P (2000) Nutzenorientierte Einführung eines ProduktdatenmanagementSystems. Dissertation, Technische Universität München Zimbardo P (1992) Psychologie. Springer, Berlin-Heidelberg-New York

7 Lösungsbaustein 2: Bewertung der PDMSFähigkeit

Die PDMS-Einflussgrößen und der vorgeschlagene Lösungsansatz beinhalten neben strategischen auch operative Zielsetzungen, die bewertet werden müssen. Das geschieht mit der Capability Scorecard (CSC), die in ihren Anwendungsvoraussetzungen der Balanced Scorecard (BSC) ähnelt. Die Vorstellung und die Anwendung der CSC bilden den inhaltlichen Schwerpunkt dieses Kapitels. Zunächst wird die CSC definiert und ihre Herleitung kurz beschrieben. Anschließend werden ihr Aufbau und ihre Anwendungsweise sowie die verwendeten Hilfsmittel behandelt. In diesem Zusammenhang werden die spezifischen Bewertungskriterien zur Bewertung der PDMS-Fähigkeit und die Vorgehensweise bei der Ermittlung des PDMS-Reifegrads vorgestellt. Dabei liegt der Schwerpunkt auf der Prozessbewertung. Schließlich werden mögliche Maßnahmen für eine Verbesserung des PDMS-Reifegrads beispielhaft abgeleitet.

7.1 Definition der Capability Scorecard (CSC) Die augenblickliche Unternehmenseignung für den Einsatz eines PDMS lässt sich durch die PDMS-Einflussgrößen beschreiben. Da die PDMSEinflussgrößen lediglich allgemeinen Charakter besitzen, müssen sie für jedes betrachtete Unternehmen spezifisch ermittelt und bewertet werden. Dies ist die Aufgabe der Capability Scorecard. Die Capability Scorecard (CSC) ist eine methodische Vorgehensweise zur Bewertung der augenblicklichen PDMS-Fähigkeit eines Unternehmens, welche sowohl PLM-strategische Ziele als auch deren spezifische PDMS-Einflussgrößen sowie ihre Wechselwirkungen berücksichtigt [Feldhusen u. Gebhardt 2005a]. Das Ziel der CSC ist die Ermittlung der PDMS-Fähigkeit, die durch den PDMS-Reifegrad ausgedrückt wird. Der Zweck der CSC liegt in der Umsetzung der PLM-Strategie durch konkrete Handlungsanweisungen.

190

7 Lösungsbaustein 2: Bewertung der PDMS-Fähigkeit

Gleichzeitig kann mit ihr festgestellt werden, ob und in welchem Ausmaß sich die PDMS-Fähigkeit aufgrund der durchgeführten Verbesserungsmaßnahmen ändert. Die Bewertung selbst wird mit Hilfe von sog. Aktivitätenmatrizen (AM) durchgeführt. Sie bilden den wesentlichen Bestandteil der CSC, da mit ihnen die wichtigsten Bewertungskriterien unternehmensindividuell gemessen werden. Anschließend werden mit ihnen die Ergebnisse hinsichtlich der PDMS-Eignung und die abgeleiteten Maßnahmen, die sog. Aktivitäten, dokumentiert. Die AM wird im nächsten Abschnitt beschrieben. Die Grundlage der CSC bildet die Balanced Scorecard (BSC), die von Kaplan und Norton entwickelt wurde [Kaplan u. Norton 1996]. Sie ist eine Managementmethode, die sowohl die Strategien eines Unternehmens als auch deren interne und externe Auswirkungen auf das Unternehmen berücksichtigt. Dabei werden sowohl die Strategie als auch ihre Auswirkungen aus vier Unternehmensperspektiven betrachtet. Es handelt sich um die Finanzperspektive, die Kundenperspektive, die Prozessperspektive und die Entwicklungsperspektive aufgrund des vorhandenen Mitarbeiterpotenzials. Jede Perspektive kann mittels qualitativer und/oder quantitativer Messgrößen erfasst werden, die die Annäherung an die strategischen Ziele messen. Die BSC wurde als Grundlage für die CSC gewählt, da sie im Gegensatz zu den meisten anderen Bewertungsmethoden strategische Ansätze einschließlich ihrer abgeleiteten Ziele ausdrücklich berücksichtigt [Kaplan u. Norton 1996; Ehrmann 2003; Feldhusen u. Gebhardt 2005a]. Aus diesem Grund stellt die CSC eine erweiterte BSC dar, die um benötigte Hilfsmittel für die Bewertung der PDMS-Fähigkeit ergänzt wurde. Weitere Gründe liegen in ihrem klaren Aufbau, ihrer einfachen Anwendung und in ihrem eindeutigen Verständnis für das Management sowie die Unternehmensmitarbeiter [Kaplan u. Norton 1996; Brandt 2002; Friedag u. Schmidt 2004].

7.2 Aufbau der Capability Scorecard Die strategischen Ziele bilden einen wesentlichen Bestandteil der CSC. Sie sollen mit Hilfe der PLM-Strategie und der PDMS-Unterstützung erreicht werden. Die Zielformulierung wird dabei nicht nur ausschließlich unter finanziellen Aspekten betrachtet, sondern zusätzlich unter Berücksichtigung der PDMS-Einflussgrößen. Sie werden in Anlehnung an die BSC als Unternehmensperspektiven bezeichnet und repräsentieren diejenigen Unternehmenssichten, die für eine erfolgreiche Systemeinführung beachtet

7.2

Aufbau der Capability Scorecard

191

werden müssen. Abbildung 7-1 stellt den Aufbau der CSC schematisch dar.

Abb. 7-1 Grundlegender Aufbau der Capability Scorecard (CSC) mit den fünf Perspektiven, die jeweils durch eine Aktivitätenmatrix (AM) beschrieben werden

Die CSC besteht aus fünf Perspektiven zur Bewertung der PDMSFähigkeit, die sich gegenseitig beeinflussen. Dabei handelt es sich um: x Die finanzielle Perspektive ermöglicht eine Abschätzung, ob und welche finanziellen Potenziale die Einführung eines PDMS besitzt. Diese Perspektive wird von Unternehmen als die bedeutsamste, jedoch oftmals auch als die einzig relevante innerhalb eines PDMS-Projekts angesehen [Ehrmann 2003; Schöttner 1999]. Dabei erstreckt sich deren Bewertung stets auf die Rentabilität im Sinne typischer Kennzahlen wie den CashFlow oder Unternehmenswertveränderungen [Schabacker 2001; Schmidt 2002]. x Die Produktperspektive berücksichtigt die augenblickliche Eignung der Produkte, um durch eine PDM-Systemunterstützung die definierten Ziele zu erreichen. Relevante Bewertungskriterien stellen bspw. die Kom-

192

7 Lösungsbaustein 2: Bewertung der PDMS-Fähigkeit

plexität der Produktstruktur, der Standardisierungsgrad oder der vorhandene Anteil an Wiederholteilen dar. x In der Prozessperspektive werden die zu bewertenden Prozesse auf ihre augenblickliche Systemimplementierungsfähigkeit überprüft. Dies geschieht anhand von Kriterien wie der vorhandenen Anzahl der zugehörigen Teilprozesse oder die Vollständigkeit dokumentierter Prozessdaten. Diese Perspektive betrachtet die Ablauforganisation des Unternehmens. x Die IT-Perspektive berücksichtigt die vorhandene IT-Systemlandschaft im Unternehmen. Sie bewertet Voraussetzungen wie die Schnittstellenkompatibilität der Systeme oder eine ausreichende Dimensionierung der Netzwerk-Infrastruktur für den PDM-Systemeinsatz. Die Vorgehensweise zur IT-Analyse ist in Abschn. 6.4.2 beschrieben. x In der Organisations- bzw. Rollenperspektive wird die Aufbauorganisation des Unternehmens hinsichtlich ihrer PDMS-Eignung überprüft. Dies geschieht anhand von Bewertungskriterien wie bspw. Eindeutigkeit und Vollständigkeit der Rechtevergabe an Datenobjekten. Damit hängt sie stark mit den Perspektiven Produkt und Prozess zusammen. Jede Perspektive wird durch eine Aktivitätenmatrix (AM) repräsentiert. In jeder AM findet die Überführung der strategischen Zielsetzungen auf die operative Ebene statt. Ebenso wird mit ihrer Hilfe die eigentliche Bewertung der PDMS-Fähigkeit durchgeführt. Jede Unternehmensperspektive wird durch zugehörige Modelle beschrieben, die den zu bewertenden Inhalt der entsprechenden AM bilden. Die finanzielle Unternehmensperspektive wird durch einen modellhaften Business Case dargestellt [Schmidt 2002]. Die IT-Landkarte ist die modellhafte Darstellung der IT-Perspektive. Die anderen Perspektiven sind durch das Produktdatenmodell, das Prozessmodell und das Rollenmodell berücksichtigt. In den folgenden Abschnitten werden die Begriffe zur Bezeichnung der Unternehmensperspektive und ihr zugehöriges Modell synonym verwendet. Wie in Kap. 4 ausgeführt wurde, bilden das Produktdatenmodell, das Prozessmodell und das Rollenmodell die vorhandenen D&I-Flüsse innerhalb der vorhandenen IT-Landschaft ab. Die D&I-Flüsse werden durch die PDM-Systemfunktionalitäten gesteuert. Folglich kann eine Bewertung der PDMS-Fähigkeit nur unter Berücksichtigung der Erfüllung konkreter Systemfunktionalitäten erfolgen. Dies bedeutet, je mehr Funktionalitäten ohne eine Modellanpassung genutzt werden können, desto höher ist der Modelleignungsgrad für eine Systemunterstützung. Aus dieser Überlegung lassen sich perspektivenspezifische Bewertungskriterien ableiten. Dies wird im Abschn. 7.5 exemplarisch für die AM Prozess gezeigt. Dadurch können die

7.2

Aufbau der Capability Scorecard

193

Modelle auf ihre augenblickliche Umsetzungseignung in ein PDMS bewertet werden. Anhand der Bewertungsergebnisse kann ihr benötigter Überarbeitungsaufwand für die Systemimplementierung abgeschätzt werden. Anschließend lassen sich gezielte Verbesserungsaktivitäten einleiten.

Abb. 7-2 Aufbau der Aktivitätenmatrix „Prozess“ am Beispielprozess „Erzeugung von Mustern“

Mit der Beschreibung dieser Zusammenhänge ist der notwendige Aufbau einer AM hinreichend festgelegt. Abbildung 7-2 zeigt ihn exemplarisch für die AM „Prozess“. Die AM „Prozess“ beinhaltet: x das Prozessmodell des zu bewertenden Prozesses wie bspw. „Erzeugung von Mustern“ einschließlich der Teilprozess-Nummer, um die Prozessaufnahmenblattzuordnung zu gewährleisten (siehe Abschn. 6.4.2); x die operativen Ziele, die mittels der PDM-Systemunterstützung erreicht werden sollen wie bspw. „Senkung der Durchlaufzeit auf maximal vier Tage“; x die perspektivenspezifischen Bewertungskriterien wie den Komplexitäts- oder den Flexibilitätsgrad des Prozesses; x das Ergebnis der durchgeführten Bewertung in Form von Prozessklassen und dem Perspektiven-Reifegrad sowie x die daraus abgeleiteten Verbesserungsaktivitäten wie „Erfassen der notwendigen Prozessdaten für Prozessschritt 1020“. Die Verbesserungsaktivitäten müssen anschließend durch entsprechende Umsetzungsprojekte im Unternehmen realisiert werden.

194

7 Lösungsbaustein 2: Bewertung der PDMS-Fähigkeit

Die Aktivitätenmatrizen der anderen Unternehmensperspektiven besitzen einen vergleichbaren Aufbau. In Abb. 7-1 ist der grundlegende Aufbau der CSC dargestellt. Diese Darstellungsform ist jedoch für eine Bewertungsdurchführung und Ergebnisdokumentation ungeeignet. In Abb. 7-3 ist ein geeignetes Hilfsmittel, das sog. CSC-Aufnahmeblatt, gezeigt. Um die Nähe zum QM zu verdeutlichen, wurde die Darstellungsform an das „House of Quality“ angelehnt [Hering et al. 2003; Schwab 2004]. Im CSC-Aufnahmeblatt werden die strategischen PLM-Zielsetzungen, ihre abgeleiteten Teilziele sowie ihre Kennzahlen in Form der PerspektivenReifegrade erfasst. Die Perspektiven-Reifegrade sowie zugehörige Maßnahmen für eine Reifegradverbesserung sind in den Aktivitätenmatrizen auf der linken Seite des CSC-Aufnahmeblatts dokumentiert. Die Verbesserungsmaßnahmen werden innerhalb der PDMS-Einführung durch spezielle Umsetzungsprojekte realisiert. Jedes Projekt wird seiner Perspektive und seinem strategischen (Teil-)ziel innerhalb der dick umrandeten Projektumsetzungsmatrix eindeutig zugeordnet. Die Projektumsetzungsmatrix besteht in diesem Beispiel aus 15 Zellen, in denen einige Umsetzungsprojekte dargestellt sind. In der Praxis kann sie jedoch, abhängig von der Anzahl der strategischen Teilziele, aus einer höheren Zellenanzahl bestehen. Der Zielerfüllungsgrad sämtlicher perspektivenspezifischer Ziele zum übergeordneten Leitziel wird durch den PDMS-Reifegrad als übergeordnete Kennzahl berücksichtigt. Das CSC-Aufnahmeblatt unterstützt neben der Bewertungsdokumentation auch die Kontrolle des PDMS-Projekts. Damit stellt es ein geeignetes Präsentationsinstrument für das Management dar. In diesem Fall kann die Projektmatrix durch ein Polardiagramm ersetzt werden, dessen Achsen die Perspektiven-Reifegrade der einzelnen Unternehmensperspektiven anzeigen. Im nächsten Abschnitt wird die Vorgehensweise bei der Anwendung der CSC innerhalb der Perspektive „Prozess“ und die Ermittlung des zugehörigen Perspektiven-Reifegrads behandelt. Die Vorgehensweise bei der Ermittlung der anderen Perspektiven-Reifegrade ist identisch, auch wenn sie nicht explizit erläutert wird.

7.2

Aufbau der Capability Scorecard

195

Abb. 7-3 Exemplarische Darstellung des CSC-Aufnahmeblatts zur Erfassung der Perspektiven, ihrer Bewertung und der abgeleiteten Verbesserungsmaßnahmen, die durch einzelne Projekte umgesetzt werden

196

7 Lösungsbaustein 2: Bewertung der PDMS-Fähigkeit

7.3 Anwendung der CSC und Ermittlung des PDMSReifegrads Aus dem vorgestellten Aufbau der CSC ergibt sich die Vorgehensweise bei ihrer Anwendung zur Reifegradermittlung. Die Vorgehensweise muss neben der Zielerfassung auch die unternehmensindividuelle Ermittlung sämtlicher Daten beinhalten, die für die Bewertung der PDMS-Fähigkeit erforderlich sind. Dies geschieht durch die PDMS-Einführungsmethodik. Ebenso muss die Vorgehensweise Hilfsmittel für die eigentliche Bewertung und deren Anwendung beinhalten. Schließlich müssen das vorhandene Verbesserungspotenzial identifiziert und geeignete Maßnahmen zur Beeinflussung der PDMS-Fähigkeit abgeleitet werden. Damit sind die Schwerpunkte innerhalb der Vorgehensweise festgelegt. Die Vorgehensweise besteht aus vier Arbeitsschritten und ist in Abb. 7-4 dargestellt.

Abb. 7-4 Vorgehensweise und Arbeitsschritte bei der CSC-Anwendung, ihre Ergebnisse einschließlich der verwendeten Hilfsmittel

Bei den einzelnen Arbeitsschritten handelt sich um die: x Definition der Zielsetzungen (Arbeitsschritt A): Es werden diejenigen Ziele definiert, die durch die Unterstützung eines PDMS erreicht werden sollen. Dies gilt für strategische Zielsetzungen in Form des Leitziels ebenso wie für die operativen Zielsetzungen. Das Ergebnis ist die Anfor-

7.3

Anwendung der CSC und Ermittlung des PDMS-Reifegrads

197

derungsliste bzw. das Lastenheft sowie die AM-Inhalte der Spalten „betrachteter Prozess“ und „operative Ziele“. x individuelle Ermittlung der PDMS-Bewertungskriterien (Arbeitsschritt B): In diesem Arbeitsschritt werden die PDMS-Bewertungskriterien unternehmensindividuell ermittelt. Anschließend werden sie in Abhängigkeit der operativen Zielsetzungen gewichtet. Das Ergebnis sind spezifische Bewertungskriterien sowie deren Gewichtungen. Sie werden in der AM-Spalte „Bewertungskriterien“ dokumentiert. x Ermittlung des Kriterienwerts und des Perspektiven-Reifegrads (Arbeitsschritt C). Es werden die gewichteten Werte der Bewertungskriterien, die sog. Kriterien-Wertungszahlen, aus Schritt B ermittelt. Dies geschieht anhand der unternehmensindividuellen Zuordnung von Eigenschaftsgrößen und ihren zugehörigen Maßzahlen. Mit den Kriterien-Wertungszahlen wird der Perspektiven-Reifegrad ermittelt. Der Perspektiven-Reifegrad wird in der AM Spalte „Bewertungsergebnis“ schriftlich festgehalten. x Ableitung und Umsetzung von Verbesserungsmaßnahmen (Arbeitsschritt D): Aufgrund der Bewertungsergebnisse werden Maßnahmen zur Verbesserung des Reifegrads ermittelt und umgesetzt. Dies geschieht innerhalb der PDMS-Einführungsmethodik. Die durchzuführenden Verbesserungsmaßnahmen werden in der AM-Spalte „abgeleitete Maßnahmen“ dokumentiert. Sie dienen als Grundlage für nachfolgende Projekte zur Umsetzung der identifizierten Verbesserungsmaßnahmen. Sämtliche Ergebnisse einschließlich der Projekte zur Maßnahmenumsetzung werden im CSC-Aufnahmeblatt (siehe Abb. 7-3) dokumentiert. Neben dem CSC-Aufnahmeblatt sind in Abb. 7-4 auch weitere Hilfsmittel aufgelistet. Ihre Ergebnisse werden für die CSC-Bewertung übernommen. Die Hilfsmittel wurden bereits in Abschn. 6.4 erläutert und werden an dieser Stelle nicht weiter behandelt. Nachfolgend werden nur die eingesetzten Analyseverfahren zur Bewertung beschrieben. 7.3.1 Die Nutzwertanalyse (NWA) Die Grundlage der ersten drei Arbeitsschritte A bis C bildet die Nutzwertanalyse (NWA) nach [Zangemeister 1973]. Die NWA ist ein Bewertungsverfahren, mit dem der Beitrag definierter Anforderungen in Bezug auf einen übergeordneten Gesamtnutzwert bestimmt werden kann [Breiing u. Knosala 1997; Pahl et al. 2005]. In diesem Kontext stellt der Gesamtnutzwert die erwarteten Zielsetzungen dar, die durch eine PDMS-Einführung erreicht werden sollen. Er wird durch den PDMS-Reifegrad repräsentiert.

198

7 Lösungsbaustein 2: Bewertung der PDMS-Fähigkeit

Dieselbe Überlegung gilt für die Unternehmensperspektiven und die zugehörigen Perspektiven-Reifegrade. Aus den strategischen und operativen Zielsetzungen werden im ersten Arbeitsschritt der Einführungsmethodik die Anforderungen abgeleitet. Die Berücksichtigung ihres einzelnen Anteils am gesamten Zielerreichungsgrad wird durch Gewichtungsfaktoren erreicht. Anhand der schematischen Darstellung in Abb. 7-5 wird die Vorgehensweise kurz erläutert. Vertiefende Erläuterungen finden sich in den Ausführungen der einzelnen Arbeitsschritte und des Fallbeispiels in Kap. 9.

Abb. 7-5 Schematische Darstellung des gesamten Zielsystems bei der Vorgehensweise der Nutzwertanalyse

Die Nutzwertanalyse umfasst … x …die Erstellung des Zielsystems, welches bewertet werden soll. . Das Zielsystem unterteilt sich in Zielbereiche und Zielstufen. Den Zielbereichen i werden die einzelnen Reifegrade der fünf Unternehmensper-

7.3

Anwendung der CSC und Ermittlung des PDMS-Reifegrads

199

spektiven wie bspw. „Produkt“ oder „Prozess“ zugeordnet. Die Zielstufen s berücksichtigen den Detaillierungsgrad der Bewertungskriterien bei der Ermittlung der einzelnen Reifegrade. Der Perspektivenreifegrad „Prozess“ wird bspw. durch Kriterien ermittelt, die den Komplexitätsgrad oder den Flexibilitätsgrad eines Prozesses beschreiben. Inhaltlich ähnliche Kriterien werden in thematischen Kriterienclustern zusammengefasst. Die Erstellung des Zielsystems bis zur Zielstufe „Bewertungskriteriencluster“ wird in Arbeitsschritt A durchgeführt. x …die Zuordnung der Bewertungskriterien, mit denen bewertet werden soll. Sie werden den Kriterienclustern zugeordnet und sind inhaltlich von der Unternehmensperspektive abhängig. So wird bspw. der Komplexitätsgrad eines Prozesses durch seine Anzahl an zugehörigen Teilprozessen oder prozessbeteiligten Rollen beschrieben. Es kann erwartet werden, dass der Prozess mit jeweils steigender Rollenanzahl komplexer und entsprechend schwerer beherrschbar wird. Die Zuordnung der Bewertungskriterien zu den Kriterienclustern wird in Arbeitsschritt B durchgeführt. Damit wird eine detailliertere Zielstufe innerhalb der NWA erreicht. x …die eigentliche Bewertungsdurchführung einschließlich der Gewichtungsermittlung. Dies schließt die Kriterienbeschreibung durch Eigenschaftsgrößen und deren Zuordnung zu einer PDMS-Werteskala ein. So kann die Anzahl der Teilprozesse gezählt und mittels einer Maßzahl der Werteskala zugeordnet werden. Falls der Prozess aus vielen Teilprozessen besteht, ist die Umsetzung in ein PDMS nur mit erheblichen Einschränkungen möglich. Die zugeordnete Maßzahl besitzt in diesem Fall den Wert 3. Die Maßzahlen werden benötigt, um die Kriterienwerte in Bezug auf den Perspektiven-Reifegrad zu ermitteln. Aus den einzelnen Perspektiven-Reifegraden setzt sich der PDMS-Reifegrad zusammen. Die absoluten Gewichtungsfaktoren bilden die Grundlage, um im letzten Arbeitsschritt mittels der Schwachstellenanalyse die effektivsten Verbesserungsmaßnahmen zu identifizieren. Die Ermittlung der relativen und absoluten Gewichtungsfaktoren wird im folgenden Abschnitt beschrieben. 7.3.2 Ermittlung des PDMS-Reifegrads und der PerspektivenReifegrade Wie in Abschn. 4.5 ausgeführt wurde, beschreibt der PDMS-Reifegrad RGPDMS die augenblickliche PDMS-Fähigkeit des gesamten Unternehmens. Er wird aus der Summe der fünf einzelnen Perspektiven-Reifegrade

200

7 Lösungsbaustein 2: Bewertung der PDMS-Fähigkeit

RGPerspektive,i gebildet. Die Bestimmung des PDMS-Reifegrads RGPDMS zeigt Gleichung 1. Der Index i bezeichnet die jeweilige Unternehmensperspektive bzw. den Zielbereich der NWA. Beide sind identisch. 5

RG PDMS

0,2 ˜ (¦ RG Perspektive, i )

(7.1)

i 1

Das NWA-Zielsystem zur Ermittlung von RGPDMS umfasst die beiden ersten Zielstufen der Abb. 7-5. Dabei sind die fünf Unternehmensperspektiven gleich gewichtet. Dies wird durch den Faktor „0,2“ in Gl. (7.1) ausgedrückt. Die einzelnen Perspektiven-Reifegrade beschreiben die Eignung der einzelnen Unternehmensperspektiven für den augenblicklichen PDMSEinsatz. Die Unternehmensperspektiven selbst wurden anhand der PDMSEinflussgrößen identifiziert. Die Einflussgrößen können anhand spezifischer Kriterien j bewertet werden, die sich zu Bewertungskriterienclustern zusammenfassen lassen. Ihr Beitrag zur Zielerreichung durch eine PDMSUnterstützung wird durch Gewichtungsfaktoren GF berücksichtigt. Dabei wird zwischen zwei Gewichtungsfaktoren unterschieden: x Die relativen Gewichtungsfaktoren rGF beschreiben die Anteile der einzelnen Bewertungskriterien bezogen auf ihren Knoten der unmittelbar übergeordneten Zielstufe (s-1). In Abb. 7-5 sind dies bspw. die beiden Kriterien „Anzahl der Teilprozesse“ und „Anzahl der prozessbeteiligten Rollen“, die sich auf den übergeordneten Knoten „Komplexitätsgrad“ beziehen. Ihre relativen Gewichtungsfaktoren werden im ersten Arbeitsschritt der PDMS-Einführungsmethodik bestimmt. Dies geschieht mit Hilfe der Präferenzmatrix. Die Summe aller rGF in einer Zielstufe bezüglich ihres übergeordneten Knotens ergibt den numerischen Wert „1“. x Die absoluten Gewichtungsfaktoren aGF bestimmen den Anteil der einzelnen Bewertungskriterien bezüglich ihrer zugehörigen Perspektive. So lässt sich über den absoluten Gewichtungsfaktor die Bedeutung des Beitrags eines Bewertungskriteriums bestimmen, mit dem er zur Zielerreichung innerhalb der Perspektive beiträgt. Dies bildet die Grundlage zur Identifizierung von Verbesserungspotenzial durch die Schwachstellenanalyse. Sie wird im nachfolgenden Abschnitt beschrieben. Der absolute Gewichtungsfaktor eines Zielstufenelements ergibt sich aus der Multiplikation seines relativen Gewichtungsfaktors mit dem absoluten Gewichtungsfaktor des übergeordneten Zielstufenelements, siehe Gl. (7.2). Der absolute Gewichtungsfaktor des Bewertungskriteriums „Anzahl der

7.3

Anwendung der CSC und Ermittlung des PDMS-Reifegrads

201

Teilprozesse“ errechnet sich aus dem Produkt seines relativen Gewichtungsfaktors mit dem absoluten Gewichtungsfaktor des zugeordneten Kriterienclusters „Komplexitätsgrad“.

aGF( s , j )

rGF( s , j ) ˜ aGF( s 1, j )

(7.2)

Bei der Ermittlung der absoluten Gewichtungsfaktoren findet durch den Bezug auf ihren übergeordneten Knoten automatisch eine Normierung statt. Sie bildet die Voraussetzung für die Durchführung der Schwachstellenanalyse. Ebenso wird dadurch eine perspektiven- und unternehmensübergreifende Vergleichbarkeit der Kriterien i. S. eines Benchmarks möglich. Nach der Ermittlung bzw. Berechnung der Gewichtungsfaktoren auf jeder Zielstufe werden den einzelnen Bewertungskriterien mittels ihrer beschreibenden Eigenschaftsgrößen entsprechende Maßzahlen zugeordnet. In diesem Beispiel ist die Eigenschaftsgröße des Bewertungskriteriums „Anzahl der Teilprozesse“ die tatsächlich vorhandene Anzahl derjenigen Teilprozesse, aus denen das betrachtete Prozessmodell besteht. Ist die ermittelte Anzahl zu hoch, so muss mit erheblichen Einschränkungen bei einer PDMS-Unterstützung gerechnet werden. Die entsprechende Maßzahl MZ, d. h. der zugeordnete Wert aus der Werteskala beträgt folglich „3“. Durch die Multiplikation der Maßzahl mit dem absoluten Gewichtungsfaktor erhält man den gewichteten Wert für jedes Bewertungskriterium j. Sie werden nachfolgend als Kriterienwerte KWj bezeichnet und nach Gl. (7.3) berechnet.

KW j

aGF j ˜ MZ j

(7.3)

Der Perspektiven-Reifegrad RGPerspektive,i stellt die Summe aller Werte der gewichteten Bewertungskriterien einer Unternehmensperspektive dar. Seine Berechnung zeigt Gl. (7.4). Es fließen nur diejenigen Kriterienwerte in die Ermittlung ein, die sich am Ende eines jeden Zweigs auf der untersten Zielstufe befinden. Die Anzahl n der Kriterienwerte ist mit der Anzahl der betrachteten Bewertungskriterien identisch. n

RGPerspektive , i

¦ KW

j

(7.4)

j 1

Die beschriebene Ermittlung des Perspektiven-Reifegrads RGPerspektive,i nach Gl. (7.4) findet in Arbeitsschritt C statt. Dabei ist die Vorgehensweise für alle Unternehmensperspektiven identisch. Das NWA-Zielsystem zur

202

7 Lösungsbaustein 2: Bewertung der PDMS-Fähigkeit

Ermittlung von RGPerspektive,i umfasst die zweite sowie alle darunter liegenden Zielstufen. Anschließend kann in Arbeitsschritt D der gesamte PDMSReifegrad RGPDMS nach Gl. (7.1) und die Zuordnung nach Tabelle 4-1 erfolgen. 7.3.3 Die Schwachstellenanalyse Die NWA wird gemäß den Erfordernissen des PDMS-Regelkreises zur Bestimmung des Perspektiven-Reifegrads angepasst und erweitert. Dies geschieht im vierten Arbeitsschritt D durch die Identifikation von vorhandenen Verbesserungspotenzialen und die Ableitung von Verbesserungsmaßnahmen. Dazu wird eine Schwachstellenanalyse durchgeführt [Breiing u. Knosala 1997; Pahl et al. 2005]. Sie stellt die normierten absoluten Gewichtungen der einzelnen Bewertungsgrößen ihren zugeordneten Maßzahlen in Form von Werteprofilen gegenüber. Dadurch werden besonders einflussreiche Verbesserungspotenziale visualisiert und identifiziert. Es lassen sich Aussagen treffen, welche Maßnahmen den größten Einfluss auf den Reifegrad besitzen und folglich zuerst durchgeführt werden sollen. In Abb. 7-6 wird eine Schwachstellenanalyse gezeigt, die sich auf das beschriebene Beispiel der NWA bezieht (siehe Abb. 7-5).

Abb. 7-6 Exemplarische Darstellung zweier Werteprofile der Unternehmensperspektive „Prozess“

7.4

Arbeitsschritt A: Definition der Zielsetzungen

203

In der Schwachstellenanalyse werden die normierten absoluten Gewichtungsfaktoren über den Maßzahlen der einzelnen Bewertungskriterien aufgetragen. Die dadurch entstandene Fläche stellt den Kriterienwert dar. In Abb. 7-6 wird anhand der Werteprofile deutlich, dass eine Beeinflussung des Bewertungskriteriums „Anzahl der Teilprozesse“ eine höhere Auswirkung auf den Reifegrad besitzt als das Bewertungskriterium „Anzahl beteiligter Rollen“. Dies ist einerseits an dem schlechteren Wert der Maßzahl, andererseits an dem höheren normierten Gewichtungsfaktor ablesbar. Ein größeres Verbesserungspotenzial besitzt folglich eine Maßnahme zur Reduktion der augenblicklich vorhandenen Teilprozessanzahl des betrachteten Prozesses. Die nachfolgenden Abschnitte beschreiben die Vorgehensweise innerhalb der Arbeitsschritte A bis D. Auf den Einsatz der NWA und der Schwachstellenanalyse wird eingegangen. Für eine vertiefende Betrachtung sei auf die Arbeiten von [Zangemeister 1973; Breiing u. Knosala 1997] verwiesen.

7.4 Arbeitsschritt A: Definition der Zielsetzungen Die Durchführung des Arbeitsschritts A ist mit dem Arbeitsschritt 1 der PDMS-Einführungsmethodik identisch. Nachfolgend werden diejenigen Aspekte behandelt, die für die Bewertung bedeutsam sind. Mit dem Arbeitsschritt A werden die Ziele aus der unternehmensinternen Vorklärungsphase erfasst, die durch die Einführung eines PDMS erreicht werden sollen. Dies wurde in Abschn. 6.4.1 beschrieben. Durch einen Workshop mit dem Management werden die aktuelle Unternehmenssituation und die daraus resultierenden Zielsetzungen auf strategischer Ebene definiert. Von besonderer Bedeutung ist hierbei die explizite Einbettung des Leitbildes und des Leitziels innerhalb des PDMS-Projekts. Ein mögliches exemplarisches Unternehmensleitbild durch die Umsetzung von PLM ist eine gewünschte Wahrnehmung beim Kunden als „innovatives Unternehmen mit hoher kundenindividueller Produktindividualisierung“. Als zugehöriges Leitziel ergibt sich die Beherrschung der Unternehmenskomplexität durch die Unterstützung eines PDMS. Um das Leitziel und letztendlich das Leitbild zu erreichen, werden anschließend strategische (Teil-)Ziele abgeleitet. Sie dienen als Grundlage zur Umsetzung auf die operative Ebene und werden mit Hilfe der Präferenzmatrix priorisiert. Die Ermittlung des Leitbildes, des Leitzieles und der strategischen Teilziele werden im ersten Arbeitsschritt der PDMS-

204

7 Lösungsbaustein 2: Bewertung der PDMS-Fähigkeit

Einführungsmethodik durchgeführt. Sie werden im CSC-Aufnahmeblatt dokumentiert und durch den PDMS-Reifegrad als Kennzahl beschrieben. Anschließend werden das Leitbild, das Leitziel und die Teilziele dem Projektteam kommuniziert. Dies geschieht mittels eines Workshops. In ihm werden die strategischen Teilziele auf die operative Ebene umgesetzt. Dabei ergeben sich erste Bewertungskriterien, mit deren Hilfe die Zielerreichbarkeit gemessen werden kann. Da man sich zu diesem Zeitpunkt der Einführung auf einer hohen Zielstufe der NWA befindet, sind die Bewertungskriterien entsprechend unscharf. Mit ihnen sind somit nur qualitative Bewertungsaussagen möglich. Dies wird als qualitative PDMS-Fähigkeit bezeichnet (siehe Abschn. 6.4.1). Es ist jedoch möglich, die unscharfen Kriterien thematisch zu übergeordneten Bewertungskriterienclustern zusammenzufassen. Die Bewertungskriteriencluster stellen unscharfe Bewertungsbereiche dar, die sich mit Hilfe der Präferenzmatrix priorisieren lassen. Damit können sie hinsichtlich ihrer Umsetzungswichtigkeit für das Management und das Projektteam geordnet werden. Erfahrungsgemäß stehen für das Management eher finanzielle, für das Projektteam eher operative Bewertungsaspekte im Vordergrund. Die Bewertungskriteriencluster bilden zu diesem Zeitpunkt einen Rahmen für die Zuordnung detaillierter Bewertungskriterien. Diese Zuordnung wird in Arbeitsschritt B durchgeführt. Weiterhin lassen sich mit Hilfe der Cluster erste qualitative Aussagen hinsichtlich des Aufwands und des Nutzens einer Systemeinführung ableiten. Eventuell müssen die Zielsetzungen aufgrund der qualitativen Bewertungsergebnisse bereits zu diesem Zeitpunkt verifiziert werden. Bei ungenauen Ergebnissen wird der Workshop erneut durchgeführt. Da sich die Kriteriencluster an perspektivenabhängigen Zielen orientieren, sind sie automatisch entsprechenden Aktivitätenmatrizen zugeordnet. Beispiele für Bewertungskriteriencluster bei der Unternehmensperspektive „Prozess“ sind der Komplexitätsgrad oder der Flexibilitätsgrad der betrachteten Prozesse. Diese Cluster bestehen aus spezifischen, einzelnen Bewertungskriterien. Durch diese Vorgehensweise werden die beschriebenen Zielstufen der NWA entwickelt (siehe Abschn. 7.3.1). Die Zuordnung der Bewertungskriterien zu ihren Clustern geschieht in Arbeitsschritt B. Ergebnisse des Arbeitsschritts A sind die strategischen Zielsetzungen, die operativen Zielsetzungen, ihre zugehörigen Bewertungskriteriencluster sowie deren Gewichtungsfaktoren. Die Ergebnisse werden für die Arbeitsschritte B und C innerhalb des Bewertungsvorgehens benötigt. Die Ergebnisdokumentation erfolgt in den Spalten „betrachteter Prozess“, „operative

7.5

Arbeitsschritt B: Ermittlung der PDMS-Bewertungskriterien

205

Ziele“ sowie „Bewertungskriterien“ der entsprechenden Aktivitätsmatrizen innerhalb des CSC-Aufnahmeblatts. Die Zielsetzungen werden als formulierte Anforderungen in der Anforderungsliste und im Lastenheft schriftlich festgehalten. Dies geschieht abschließend im ersten Arbeitsschritt.

7.5 Arbeitsschritt B: Ermittlung der PDMSBewertungskriterien Im Arbeitsschritt B findet die Zuordnung individueller Bewertungskriterien zu den in Arbeitsschritt A ermittelten Zielen statt, um den Grad der Zielerreichbarkeit im nachfolgenden Arbeitsschritt messen zu können. In einem ersten Schritt muss ein konkreter Prozess bestimmt werden, dessen Prozessmodell auf seine augenblickliche Eignung zur Unterstützung durch ein PDMS bewertet wird. Dies schließt die Beschreibung der gewünschten operativen Ziele ein. Anschließend werden die zielbeschreibenden Bewertungskriterien sowie ihre Eigenschaftsgrößen ermittelt. Der Arbeitsschritt endet mit der Ermittlung der Gewichtungsfaktoren. Die Vorgehensweise des Arbeitsschritts B zeigt Abb. 7-7. Damit die PDMS-Fähigkeit eines Prozesses ermittelt werden kann, müssen diejenigen Prozesse bestimmt werden, für die die Bewertung durchgeführt werden soll. Dies geschieht im Teilarbeitsschritt B.1. Im Rahmen der späteren System-Pilotphase wird empfohlen, sich auf wenige Prozesse zu konzentrieren [Schöttner 1999; Eigner u. Stelzer 2001; Müller 2005; Feldhusen u. Gebhardt 2005a]. Im Fall des beispielhaft betrachteten Unternehmens handelte es sich um den Prozess „Erzeugung von Mustern“. Das zugehörige Fallbeispiel wird in Kap. 9 behandelt. Der ausgewählte Prozess wird in der Aktivitätenmatrix dokumentiert. Nach der Prozessauswahl werden diejenigen Ziele und ihre zugeordneten Zielgrößen explizit definiert, die durch eine PDMS-Unterstützung operativ erreicht bzw. verbessert werden sollen. Dies geschieht auf der Grundlage der in Arbeitsschritt A priorisierten Ziele. Auch vorhandene Ergebnisse der IST-Analyse und des SOLL-Konzepts aus dem zweiten Arbeitsschritt der PDMS-Einführungsmethodik werden berücksichtigt. So wurde bspw. für den ausgewählten Prozess „Erzeugung von Mustern“ eine Verbesserung des operativen Ziels „Senkung der Durchlaufzeit auf maximal vier Tage“ festgelegt. Mit der Dokumentation der operativen Ziele in der Aktivitätenmatrix endet der Teilarbeitsschritt B.2.

206

7 Lösungsbaustein 2: Bewertung der PDMS-Fähigkeit

Arbeitsschritt B: Individuelle Ermittlung der PDMS-Bewertungskriterien

B.1 Defintion Bewertungsobjekt(e)

B.2 Definition operative Ziele durch PDMSUnterstützung

B.3 Zuordnung relevanter Bewertungskriterien und ihrer Eigenschaftsgrößen

Zuordnung ausreichend?

nein

ja B.4 Ermittlung der Gewichtungsfaktoren jedes Bewertungkriteriums

Arbeitsschritt C: Ermittlung der Kriterienwertungszahl und des Perspektiven-Reifegrads

Abb. 7-7 Darstellung der Vorgehensweise des Arbeitsschritts B

7.5

Arbeitsschritt B: Ermittlung der PDMS-Bewertungskriterien

207

Die Definition der operativen Ziele ist voraussetzend für die Ermittlung des Perspektiven-Reifegrads. Um den einzelnen Zielerfüllungsgrad messen zu können, werden im Teilarbeitsschritt B.3 jedem Ziel spezifische Bewertungskriterien zugeordnet. Dies geschieht zunächst anhand des Bewertungskriterienclusters der Unternehmensperspektive Prozess. Anschließend wählt man aus dem Cluster diejenigen Kriterien, deren Manipulation das entsprechende Ziel beeinflusst. So lässt sich das operative Ziel „Senkung der Durchlaufzeit“ dadurch erreichen, indem man bspw. den Komplexitätsgrad des Prozesses ändert. Dies beinhaltet die Analyse der Anzahl prozessbeteiligter Rollen oder vorhandener Teilprozesse. Durch eine Reduzierung der Rollen und/oder der Teilprozesse wird die Prozesskomplexität gemindert. Es ist zu erwarten, dass sich als direkte Folge die Durchlaufzeit verringert. In einem zweiten Schritt können somit dem operativen Ziel die spezifischen Bewertungskriterien „Anzahl der prozessbeteiligten Rollen“ und „Anzahl vorhandener Teilprozesse“ zugeordnet werden. Weitere Bewertungskriteriencluster und zugehörige Bewertungskriterien sind in Abb. 7-8 gezeigt. Die Eigenschaftsgrößen beider Bewertungskriterien stellen die numerischen Werte der tatsächlich gezählten Teilprozesse bzw. Rollen dar. Über die Eigenschaftsgrößen lassen sich entsprechende Wertemaßstäbe zuordnen, die zur Ermittlung des Perspektiven-Reifegrads benötigt werden. Dies geschieht in Arbeitsschritt C. Durch die Zuordnungsbeschreibung wird deutlich, dass die Bewertungskriteriencluster perspektivenspezifische Kriterienkataloge darstellen. Sie bestehen aus einzelnen Bewertungskriterien, die den operativen Zielen unternehmensindividuell zugeordnet werden können [Picot u. Rohrbach 1995; Schabacker 2001; Feldhusen u. Gebhardt 2005a]. Dabei können einzelne Kriterienkataloge als Bewertungsgrundlage für weitere Unternehmensperspektiven dienen. So kann der Katalog „Detaillierungsgrad“ sowie seine Bewertungskriterien sowohl auf die Prozess-, als auch auf die Produktperspektive angewendet werden. Die spezifischen Bewertungskriterien der einzelnen Cluster ergeben sich aus den Datenlisten, die als Ergebnis der IST-Analyse innerhalb der PDMS-Einführungsmethodik gewonnen wurden (siehe Abschn. 6.4.2). Die Kriterienkataloge werden durch die Datenlisten eines neu durchgeführten PDMS-Projekts ergänzt. Somit wird mittelfristig ein Instrument geschaffen, welches die wichtigsten Bewertungskriterien für eine PDMSEinführung in mittelständischen Unternehmen enthält. Zusätzlich werden sie durch die Bewertungskriterien aus dem ersten Arbeitsschritt ergänzt.

208

7 Lösungsbaustein 2: Bewertung der PDMS-Fähigkeit

Abb. 7-8 Zusammenhang zwischen dem betrachteten Prozess(-modell), den definierten Zielen, den Kriterienclustern und den spezifischen Bewertungskriterien innerhalb des Arbeitsschritts B

Der Teilarbeitsschritt B.3 wird entsprechend wiederholt, bis sämtlichen operativen Zielen die spezifischen Bewertungskriterien einschließlich ihrer beschreibenden Eigenschaftsgrößen zugeordnet wurden. Jedes Ziel sollte

7.5

Arbeitsschritt B: Ermittlung der PDMS-Bewertungskriterien

209

mit höchstens drei Kriterien bewertet werden; pro Unternehmensperspektive werden nicht mehr als zwanzig Bewertungskriterien empfohlen. Dieser Wert ist aus der Anwendung der BSC abgeleitet [Ehrmann 2003; Friedag u. Schmidt 2004]. Durch diese Limitierung erfolgt zum einen die Beschränkung auf die wesentlichen Kriterien; zum anderen bleibt dadurch die CSC für den praktischen Einsatz überschaubar und beherrschbar. Im Anwendungsbeispiel zeigt sich, dass die beschränkte Anzahl an Bewertungskriterien für repräsentative Aussagen ausreichend ist. In einem Workshop werden dem Unternehmensmanagement sowie dem Projektteam die Ergebnisse des Teilarbeitsschritts B.3 vorgestellt. Anschließend ermitteln die Teilnehmer die zugehörigen relativen Gewichtungen der einzelnen Bewertungskriterien. Dazu wird erneut die Präferenzmatrix eingesetzt. Die relativen Gewichtungen der Kriteriencluster wurden bereits in Arbeitsschritt A in den jeweiligen Workshops ermittelt. Anschließend werden die absoluten Gewichtungsfaktoren nach Gl. (7.2) berechnet. Damit ist der Teilarbeitsschritt B.4 abgeschlossen. Es wird von der Annahme ausgegangen, dass alle fünf Unternehmensperspektiven im Rahmen des PDMS-Projekts die gleiche Bedeutung besitzen. Entsprechend werden sie nach Gl. (7.1) mit dem relativen Gewichtungsfaktor von jeweils 0,2 versehen. Falls aus unternehmensspezifischen Gründen eine oder mehrere Perspektiven besonders hervorgehoben werden sollen, muss dies durch eine Korrektur an diesen Gewichtungsfaktoren geschehen. Die Entscheidung hierüber trifft das Management. Das Ergebnis des Arbeitsschritts B stellen die definierten operativen Ziele, die zugeordneten Bewertungskriterien einschließlich ihrer Eigenschaftsgrößen sowie ihre Gewichtungsfaktoren dar. Sämtliche Ergebnisse sind in der AM als Teil des CSC-Aufnahmeblatts dokumentiert. Auf der Grundlage dieser Ergebnisse kann die eigentliche Bewertung der perspektivenabhängigen PDMS-Fähigkeit durchgeführt werden. Dies ist das Ziel des Arbeitsschritts C. Kriteriencluster und Bewertungskriterien für die anderen Unternehmensperspektiven Die Ermittlung und Anwendung sämtlicher Kriteriencluster einschließlich ihrer Bewertungskriterien für die anderen Unternehmensperspektiven geschieht mittels der gleichen Vorgehensweise wie bei der beschriebenen Prozess-Perspektive.

210

7 Lösungsbaustein 2: Bewertung der PDMS-Fähigkeit

Abb. 7-9. Kriteriencluster und exemplarische Bewertungskriterien für die Unternehmensperspektive „Produkt“

7.5

Arbeitsschritt B: Ermittlung der PDMS-Bewertungskriterien

211

Für jede Perspektive bleiben einige der beschriebenen Kriteriencluster wie Komplexitätsgrad, Detaillierungsgrad oder Flexibilitätsgrad bestehen; zur Erfassung des Perspektiven-Reifegrads ist es jedoch sinnvoll, in Abhängigkeit der betrachteten Unternehmensperspektive weitere Cluster zu berücksichtigen. Dies geschieht bspw. bei der Eignungsbewertung vorhandener Produkte, in welchem der augenblickliche Standardisierungsgrad eine wesentliche Rolle innerhalb der PLM-Strategie spielt. Der Grad der vorhandenen Produktstandardisierung muss folglich bei einer Bewertung berücksichtigt werden. Die Kriteriencluster und die zugehörigen Bewertungskriterien der Unternehmensperspektive Produkt sind in Abb. 7-9 gezeigt. Der Komplexitätsgrad beschreibt die Anzahl und die Vielfalt der einzelnen Produktstrukturelemente. Neben den „klassischen“ mechanischen Bauteilen werden hier insbesondere die mechatronischen Bauelemente berücksichtigt. Die Beziehungen zwischen den einzelnen Elementen einschließlich ihrer beschreibenden Attribute betrachtet der Detaillierungsgrad. Den gewünschten Anteil einer gemeinsamen Datennutzung zur Effizienzsteigerung der Abläufe erfasst der Grad der Produktelementverflechtung. Ein hoher Anteil stellt sicher, dass verschiedene Softwareprogramme wie 3D-CAD-Modellierungsprogramme und CFD-Simulationsprogramme die gleiche Datenbasis nutzen. Zusätzlich berücksichtigt dieser Kriteriencluster auch die Bewertung vorhandener Konfigurationsregeln und einer eindeutigen Produktstruktur. Besonders bedeutsam für ein „PDMS-gerechtes“ Produktdatenmodell und zur optimalen Ausnutzung der Systemfunktionalitäten sind der Modularitätsgrad und der Standardisierungsgrad. Während der Modularitätsgrad den Grad der Austauschbarkeit einzelner Produktelemente beschreibt, berücksichtigt der Standardisierungsgrad die Anzahl der verwendeten Wiederhol- bzw. Gleichteile innerhalb eines Produkts. Damit wird die in Abschn. 4.1 beschriebene Referenzprodukt-Strategie wesentlich unterstützt. Sie bildet einen bedeutsamen Mehrwert für das Unternehmen bei einer PLM-Umsetzung. Bei der Unternehmensperspektive Organisation erfolgt die Bewertung auf der Grundlage der Aufbauorganisation und der davon abgeleiteten organisatorischen Funktionsstellen (vgl. Abschn. 3.4). Die Bewertungskriterien der einzelnen Kriteriencluster Komplexitätsgrad, Detaillierungsgrad, Grad der Arbeitsteilung, Grad der Rollenverflechtung und Flexibilitätsgrad werden auf das Rollenmodell angewendet (siehe Abb. 7-10). Die Vorgehensweise erfolgt wie bei den bereits vorgestellten Unternehmensperspektiven, nur die inhaltlichen Aspekte ändern sich. So ist bspw. der Kriteriencluster Detaillierungsgrad bei den Unternehmensperspektiven Prozess, Produkt

212

7 Lösungsbaustein 2: Bewertung der PDMS-Fähigkeit

und Organisation vorhanden; wie in den zugehörigen Abbildungen ersichtlich ist, wird er jedoch anhand unterschiedlicher, perspektivenabhängiger Bewertungskriterien ermittelt.

Abb. 7-10 Kriteriencluster und exemplarische Bewertungskriterien für die Unternehmensperspektive „Organisation“ bzw. Rollen

Dieselben Aussagen gelten auch bei der Ermittlung des Reifegrads für die Unternehmensperspektive IT. In Abb. 7-11 sind die Kriteriencluster und ihre Einzelkriterien zur Bewertung der IT-Systemlandschaft dargestellt.

7.5

Arbeitsschritt B: Ermittlung der PDMS-Bewertungskriterien

213

Abb. 7-11 Kriteriencluster und exemplarische Bewertungskriterien für die ITUnternehmensperspektive

214

7 Lösungsbaustein 2: Bewertung der PDMS-Fähigkeit

Alternativ lässt sich zur vereinfachten Ermittlung des IT-PerspektivenReifegrads eine Einteilung verwenden, die auf den Ausführungen in Abschn. 6.4.2 beruht. Die einzelnen Cluster x x x x

PDMS-Eignung der vorhandenen IT-Infrastruktur, PDMS-Eignung der vorhandenen Serverstrukturen, PDMS-Eignung der vorhandenen Client-Applikationen und PDMS-Eignung der vorhandenen Datenstrukturen

können überschlägig mit Hilfe von Tabelle 7-1 abgeschätzt und ein Mittelwert sämtlicher Clusterwerte gebildet werden. Diese Vorgehensweise ist einfach und schnell durchführbar; sie hat jedoch den Nachteil, dass aufgrund der nicht berücksichtigten, genaueren (Einzel-)Bewertungskriterien vorhandene Schwachstellen möglicherweise unentdeckt bleiben. Tabelle 7-1 Werteskala zur PDMS-Eignungsabschätzung der vorhandenen ITStrukturen in Anlehnung an Schulnoten Wert

Eignung der vorhandenen IT zur PDMS-Unterstützung

1

uneingeschränkt PDMS-geeignet

2

PDMS-geeignet mit leichten Einschränkungen

3

PDMS-geeignet mit erheblichen Einschränkungen

4

nicht PDMS-geeignet

Die Vorgehensweise zur Bewertung der Unternehmensperspektive Finanzen wird in Kap. 8 behandelt. Die beschriebenen Kriteriencluster und ihre einzelnen Bewertungskriterien sind ausschließlich beispielhaft zu verstehen und besitzen keinen Anspruch auf Vollständigkeit. Vielmehr müssen sie den unternehmensindividuellen Zielsetzungen in jeder Unternehmensperspektive angepasst und ggf. erweitert werden.

7.6 Arbeitsschritt C: Ermittlung des PerspektivenReifegrads Auf der Ergebnisgrundlage von Arbeitsschritt B werden in Arbeitsschritt C die Werte der Eigenschaftsgrößen ermittelt. Ihnen werden repräsentative Maßzahlen zugeordnet. Aus der Maßzahl und dem absoluten Gewichtungsfaktor ergeben sich die Kriterien-Wertungszahlen. Sie beschreiben den gewichteten Wert eines jeden Bewertungskriteriums. Aus den Krite-

7.6

Arbeitsschritt C: Ermittlung des Perspektiven-Reifegrads

215

rien-Wertungszahlen ergibt sich der Perspektiven-Reifegrad. Damit ist das Bewertungszielsystem innerhalb einer Perspektive vollständig erfasst. Die Ermittlung des Perspektiven-Reifegrads und eine erste Identifikation von möglichem Verbesserungspotenzial sind die Ziele des Arbeitsschritts C. Seine Vorgehensweise ist in Abb. 7-12 dargestellt. Im Teilarbeitsschritt B.3 wurde jedem Bewertungskriterium eine Eigenschaftsgröße zugeordnet. Diese Eigenschaftsgröße besitzt eine beschreibende und messbare Eigenschaft. So lässt sich bspw. für das Bewertungskriterium „Anzahl der prozessbeteiligten Rollen“ die vorhandene Anzahl beteiligter Rollen am Prozess durch die Prozessmodellanalyse ermitteln. Ihr numerischer Wert stellt die Eigenschaftsgröße des Bewertungskriteriums dar. Um eine Aussage hinsichtlich ihrer PDMSUnterstützungseignung zu erhalten, muss die Eigenschaftsgröße in eine PDMS-Werteskala eingeordnet werden, die die PDMS-Eignung repräsentiert. Dadurch wird dem ermittelten numerischen Wert der Eigenschaftsgröße ein repräsentativer Punktewert der PDMS-Werteskala, die sog. Maßzahl, zugeordnet. Die Maßzahlenzuordnung wird in Teilarbeitsschritt C.1 durchgeführt. In Tabelle 7-2 ist die Werteskala für das Zielsystem gezeigt. Tabelle 7-2 PDMS-Werteskala zur Zuordnung eines Punktewerts zu den ermittelten Ergebnissen der Einflussgrößen in Anlehnung an Schulnoten Punkte (Maßzahl)

PDMS-Unterstützungseignung

1

uneingeschränkt PDMS-geeignet

2

PDMS-geeignet mit leichten Einschränkungen

3

PDMS-geeignet mit erheblichen Einschränkungen

4

nicht PDMS-geeignet

Die Punktezuordnung zu den Eigenschaftsgrößen erfolgt entweder durch die Projektleiter oder gemeinsam mit dem Projektteam in einem Workshop. Da es sich um eine Wertung von operativen Kriterien handelt, ist die Einbindung des Managements nicht zwingend notwendig. Durch diese Zuordnung wird implizit auch die Implementierbarkeit des Prozessmodells bewertet, was in Arbeitsschritt D geschieht.

216

7 Lösungsbaustein 2: Bewertung der PDMS-Fähigkeit

Arbeitsschritt C: Ermittlung der Kriterienwertungszahl und des Perspektiven-Reifegrads

C.1 Werten der Eigenschaftsgrößen (Zuordnung der Maßzahl)

C.2 Gewichten des Werts des Bewertungskriteriums aus C.1 (Kriterienwertungszahl)

für alle Kriterien durchgeführt?

nein

ja C.3 Ermittlung des PerspektivenReifegrads

C.4 Erste Identifikation von Verbesserungspotential durch Klassifizierung

Arbeitsschritt D: Ableitung und Umsetzung von Verbesserungsaktivitäten

Abb. 7-12 Darstellung der Vorgehensweise des Arbeitsschritts C

7.6

Arbeitsschritt C: Ermittlung des Perspektiven-Reifegrads

217

Die Ermittlung des gewichteten Werts eines Bewertungskriteriums, der sog. Kriterienwert, wird im Arbeitsschritt C.2 durchgeführt. Dies geschieht nach Gl. (7.3) durch die Multiplikation des absoluten Gewichtungsfaktors mit dem zugeordneten Punktewert der Werteskala. Der Kriterienwert betrifft ausschließlich die Kriterien auf der niedrigsten Zielstufe eines jeden Zweigs des Zielsystems. Da die Multiplikation mit den absoluten Gewichtungsfaktoren durchgeführt wird, ist der Kriterienwert ebenfalls normiert. Er dient als Grundlage für die Schwachstellenanalyse zur Identifizierung von Verbesserungsmaßnahmen in Arbeitsschritt D. Der Teilarbeitsschritt C.2 wird für jedes Bewertungskriterium durchgeführt. Durch die Addition sämtlicher Kriterienwerte aus dem vorherigen Teilarbeitsschritt nach Gl. (7.4) lässt sich der Perspektiven-Reifegrad RGPerspektive,i für den betrachteten Prozess ermitteln. Dies geschieht in Teilarbeitsschritt C.3. Im praktischen Einsatz hat sich eine tabellarische Auflistung als hilfreich erwiesen, in der sämtliche relevanten Daten des Zielsystems dokumentiert sind. Sie enthält für jede Unternehmensperspektive nicht nur die gewählten Bewertungskriterien, sondern auch die beiden Gewichtungsfaktoren, die Eigenschaftsgröße und ihr Ergebnis, den zugehörigen Wert der Werteskala und den errechneten Kriterienwert. Ebenfalls ist der resultierende Reifegrad des betrachteten Prozesses beinhaltet. Diese Auflistung ist als Perspektiven-Wertetabelle in Abb. 7-13 dargestellt und ergänzt die entsprechende Aktivitätenmatrix der CSC.

Abb. 7-13 Darstellung der Perspektiven-Wertetabelle am Beispiel des Prozesses „Erzeugung von Mustern“. In ihr sind sämtliche Werte des Zielsystems übersichtlich dokumentiert. Damit ergänzt sie die zugehörige Aktivitätenmatrix

Anhand der Perspektiven-Wertetabelle lassen sich nach einer PDMSRegelkreisiteration die Auswirkungen einer Verbesserungsmaßnahme in bestimmten Bereichen einfach erkennen. Dazu müssen die neu ermittelten Werte einfach mit den bereits eingetragenen Werten für jedes Bewertungskriterium verglichen werden.

218

7 Lösungsbaustein 2: Bewertung der PDMS-Fähigkeit

Die Perspektiven-Wertetabelle ergänzt die Dokumentation der entsprechenden Aktivitätenmatrix. Nachteilig ist jedoch, dass sie in Abhängigkeit der Bewertungskriterienanzahl schnell unübersichtlich werden kann. Für eine einfache erste Aussage hinsichtlich der PDMS-Eignung kann der betrachtete Prozess entsprechenden Prozessklassen zugeordnet werden. Dies geschieht durch den ermittelten Reifegrad in Teilarbeitsschritt C.4. Durch die Prozessklassen lassen sich Aussagen über den Grad des zu erwartenden technischen und wirtschaftlichen Aufwands einfach ableiten. Dies beinhaltet die augenblickliche Implementierungseignung in das PDMS ebenso wie sinnvoll erscheinende Verbesserungsmaßnahmen. Damit stellt die Einteilung in Prozessklassen ein einfaches Einschätzungsinstrument hinsichtlich des zu erwartenden Verbesserungsaufwandes dar. Aus diesem Grund erweist es sich als sinnvolleres Management-Tool als die vorgestellte Perspektiven-Wertetabelle. Die Prozessklassen sind in Abb. 7-14 dargestellt.

Abb. 7-14 Prozessklassen zur Abschätzung der Implementierungseignung und des Verbesserungsaufwands

7.6

Arbeitsschritt C: Ermittlung des Perspektiven-Reifegrads

219

Die vorgestellten Prozessklassen sind aus den Kriterienclustern abgeleitet. Ihre Charakteristika entsprechen den vorgestellten Bewertungskriterien. Sämtliche betrachtete Unternehmensprozesse können vier Klassen, abhängig von ihrem Reifegradergebnis, zugeordnet werden: x Die Klasse Routineprozess ist durch eine klare Struktur mit einem hohen Standardisierungsanteil seiner Teilprozesse charakterisiert. Ein solcher Prozess besitzt eine geringe Anzahl von Schnittstellen zu anderen Prozessen. Damit ist er für eine Systemimplementierung gut geeignet. Verbesserungsmaßnahmen sind in dieser Prozessklasse in der Regel nicht notwendig. Ein Beispiel ist der Ablauf bei internetbasierten KundenBestellvorgängen auf der firmeneigenen Homepage. x Die Klasse Regelprozess mit hohem Routineanteil besitzt einen Anteil individueller Prozessschritte, die von ihren Akteuren unterschiedlich ausgeführt werden. Dennoch überwiegt ein standardisierter Prozessablauf. Der (Haupt-)Prozess und seine Teilprozesse sind in ihren Abläufen gut kontrollierbar. Verbesserungsmaßnahmen sind in geringem Umfang notwendig, um eine effiziente PDM-Systemunterstützung zu gewähren. Ein Beispiel ist der standardisierte Ablauf bei der Verwendung von Wiederholteilen in der Produktentwicklung. x In die Klasse Regelprozess mit hohem Flexibilitätsanteil werden Prozesse eingeordnet, die einen gewünschten flexiblen Ablauf unter definierten Bedingungen besitzen. Sie können nur in bestimmten geeigneten Teilprozessen durch ein PDMS unterstützt werden. Da eine Prozessautomatisierung sehr aufwendig ist, sind auch umfassende Verbesserungsmaßnahmen notwendig. Ein Beispiel ist der Ablauf bei der Erzeugung von Produktvarianten. x Die Klasse einmaliger Prozess beinhaltet sämtliche Prozesse, deren Ablauf sich individuell innerhalb vorgegebener Prozessparameter wie bspw. dem durchführenden Akteur ändert. Dadurch kann der Ablauf nicht eindeutig definiert werden und eine Prozessautomatisierung ist nicht sinnvoll. Prozesse in dieser Klasse lassen sich ohne erhebliche Verbesserungsmaßnahmen, die oftmals zu einer kompletten Umstrukturierung des Ablaufs führen, durch ein PDMS nicht unterstützen. Ein typisches Beispiel sind Kundengespräche, die keinem schematisierten Ablauf folgen. Es wird deutlich, dass die Perspektiven-Fähigkeit eines Unternehmens umso effizienter ausfällt, je mehr seiner bewerteten Prozesse in die beiden Klassen „Routineprozess“ und „Regelprozess mit hohem Routineanteil“ eingeordnet werden können. Somit muss das Ziel sämtlicher Verbesse-

220

7 Lösungsbaustein 2: Bewertung der PDMS-Fähigkeit

rungsmaßnahmen die gezielte Beeinflussung der entsprechenden Prozesscharakteristika zur Steigerung der PDMS-Unterstützung sein. Idealerweise sind diejenigen Prozesse, welche im Rahmen der Pilotimplementierung (Arbeitsschritt 3 der PDMS-Einführungsmethodik) ausgewählt wurden, einer dieser beiden Klassen zuzuordnen. Die letztendliche Entscheidung, ob für bestimmte Schlüsselprozesse die ermittelte Prozessklasse aus firmeninternen Gründen bestehen bleiben soll, muss das Management treffen. Dies gilt vor allem für Prozesse der Prozessklasse „einmaliger Prozess“, die in mittelständischen Unternehmen oftmals das Kundenumfeld betreffen. In solchen Fällen muss den Entscheidern bewusst sein, dass diese Prozesse nur unzureichend durch das PDMS unterstützt werden. Mit der Zuordnung der Prozessklassen ist der Arbeitsschritt C beendet. Das Ergebnis des Arbeitsschritts C stellen die ausgefüllte PerspektivenWertetabelle, der ermittelte Perspektiven-Reifegrad des betrachteten Prozesses sowie eine erste grobe Identifizierung von Verbesserungspotenzial anhand der Prozessklassen dar. Der ermittelte Reifegrad und die zugeordnete Prozessklasse des bewerteten Prozesses werden in der Aktivitätenmatrixspalte „Bewertungsergebnis“ dokumentiert. Die spezifische Identifikation besonders effizienter Verbesserungsmaßnahmen geschieht mit der Schwachstellenanalyse in Arbeitsschritt D. Eignungsklassen zur Implementierung der anderen Unternehmensperspektiven Die Kennzahl Perspektiven-Reifegrad charakterisiert jedes Modell perspektivenabhängig auf seine augenblickliche PDMS-Eignungsfähigkeit Zur Ressourcenabschätzung hinsichtlich der durchzuführenden Verbesserungsmaßnahmen ist diese Kennzahl für das Management ohne Kenntnis der PDMS-Projektinhalte wenig aussagekräftig. Aus diesem Grund ist es sinnvoll, eine erste grobe Abschätzung einschließlich des zu erwartenden Umsetzungsaufwands aufgrund von perspektivenabhängigen Modellklassen durchzuführen. Eine genaue Schwachstellenanalyse und die gezielte Herleitung von Verbesserungsmaßnahmen geschieht in Arbeitsschritt D. Im vorherigen Abschnitt wurde die Klassen für die Unternehmensperspektive Prozess hergeleitet und beschrieben. Die Ableitung entsprechender Modellklassen für die anderen Unternehmensperspektiven geschieht auf dieselbe Weise. Die Produktklassen, die in Abb. 7-15 aufgeführt sind, unterscheiden sich v. a. durch ihren Anteil an verwendeten Gleich- bzw. Wiederholteilen. Je höher dieser Anteil im Sinne „vorgedachter“, d. h. bereits vorhandener Produktteile und -baugruppen ist, desto mehr wird die Referenzprodukt-

7.6

Arbeitsschritt C: Ermittlung des Perspektiven-Reifegrads

221

Strategie unterstützt (siehe Abschn. 4.1). Bei einem zunehmenden Customzing-Anteil an kundenindividuellen Produktspezifikationen besteht die Gefahr eines unkontrollierbaren Wachstums an Produktvarianten. Der Extremfall ist ein Individualprodukt, das aufgrund spezifischer Kundenanforderungen für einen einzigen Kunden gezielt entwickelt und umgesetzt wurde. Für Bereiche wie dem Anlagen- oder dem Sondermaschinenbau ist dies durchaus gewünscht; in derartigen Fällen muss kritisch geprüft werden, ob eine PDMS-Unterstützung sinnvoll ist.

Abb. 7-15 Produktklassen zur Abschätzung der Implementierungseignung des Produktdatenmodells und des Verbesserungsaufwands

Abbildung 7-16 zeigt die Einteilung von Rollenklassen. Ähnlich wie bei den Produkt- und Prozessklassen steigt die Implementierungseignung einer Rolle mit dem Grad ihrer eindeutigen Aufgabendefinition, ihren zugehörigen Berechtigungen an Datenobjekten und ihre Zuweisung zu den einzelnen organisatorischen Funktionsstellen an. Dabei leiten sich Standardrollen aus dem Funktionalitätsumfang eines PDMS ab. Ein vollständig unternehmensspezifisches Rollenmodell mit individuell beschriebenen

222

7 Lösungsbaustein 2: Bewertung der PDMS-Fähigkeit

Rollen findet sich häufig in Großunternehmen des Automobilbaus oder der Luft- und Raumfahrt.

Abb. 7-16 Rollenklassen zur Abschätzung der Implementierungseignung des Rollenmodells sowie des Verbesserungsaufwands

Die Einteilung der IT-spezifischen Systemklassen bzw. betriebswirtschaftlichen Finanzklassen geschieht auf dieselbe Art. In der Praxis ist eine derartige Klasseneinteilung für diese Unternehmensperspektiven jedoch nicht sinnvoll. Der Grund liegt darin, dass sich hier einzuleitende Verbesserungsmaßnahmen weniger abstrakt darstellen als in den anderen Unternehmensperspektiven. So ist bspw. bei einer nicht ausreichenden Dimensionierung der Hardware (zu niedrige Prozessorleistung) oder Software (veraltetes Betriebssystem) offensichtlich, wie diese Schwachstelle mit welchem Aufwand und zu welchen Kosten eliminiert werden kann. Dies geschieht anhand der vorhandenen Erfahrungswerte in jeder IT-Abteilung mit hinreichender Genauigkeit. Zugehörige Kostenaussagen können durch eine Recherche bei einschlägigen Anbietern schnell ermittelt werden.

7.7

Arbeitsschritt D: Ableitung von Verbesserungsaktivitäten

223

Deshalb wird eine Ergebnisklassifizierung dieser beiden Perspektiven an dieser Stelle nicht behandelt. Generell muss der Aufwand zur Erreichung der nächsthöheren Modellklasse mit dem damit verbundenen Nutzen sorgsam abgewogen werden. So kann es für ein mittelständisches Unternehmen durchaus sinnvoll sein, ein Rollenmodell der Klasse 2 in das PDMS zu implementieren. Eine definierte Zuordnung zu organisatorischen Instanzen, eine eindeutige Prozesszuordnung sowie eine durchgängige Dokumentation ist für das Rollenmodell der meisten mittelständischen Unternehmen völlig ausreichend. Dieselbe Aussage ist für die Unternehmensperspektive Produkt und Prozess gültig.

7.7 Arbeitsschritt D: Ableitung von Verbesserungsaktivitäten Auf der Grundlage der Ergebnisklassifizierung konnte im vorherigen Arbeitsschritt vorhandenes Verbesserungspotenzial innerhalb einer Perspektive eingegrenzt werden. In diesem Arbeitsschritt werden mit Hilfe der Schwachstellenanalyse geeignete Verbesserungsaktivitäten zur Steigerung des Reifegrads konkret identifiziert. Sie werden durch spezifische Projekte umgesetzt. Anschließend findet ein erneuter Bewertungsdurchlauf statt, um die Auswirkungen der umgesetzten Verbesserungsmaßnahmen auf die PDMS-Fähigkeit zu überprüfen. Bei einem zufrieden stellenden Ergebnis wird abschließend der PDMS-Reifegrad ermittelt. An dieser Stelle sei auf eine zweite Vorgehensmöglichkeit hingewiesen: Es ist möglich, zunächst den gesamten PDMS-Reifegrad zu ermitteln und anschließend die Verbesserungsmaßnahmen umzusetzen. Es wird lediglich die Abfolge der einzelnen Teilarbeitsschritte, nicht jedoch deren Inhalt geändert. In der Praxis hat sich jedoch die Vorgehensweise bewährt, direkt nach der Ermittlung des Perspektiven-Reifegrads die perspektivenspezifischen Verbesserungsaktivitäten einzuleiten. Deshalb wird in diesem Abschnitt die erste Möglichkeit diskutiert. Unabhängig von seinem Ermittlungszeitpunkt bildet die Bestimmung des gesamten PDMS-Reifegrads das Ziel des Arbeitsschritts D. Sein Ablauf ist in Abb. 7-17 dargestellt. Aufgrund der ermittelten Perspektiven-Reifegrade lässt sich Verbesserungspotenzial in den einzelnen Unternehmensbereichen gezielt formulieren. Das Verbesserungspotenzial wird genutzt, um eine PDM-

224

7 Lösungsbaustein 2: Bewertung der PDMS-Fähigkeit

Systemeinführung aufgrund fehlender Voraussetzungen nicht zu gefährden. Falls sämtliche Unternehmensperspektiven mit einem Ergebnis von „PDMS-fähig mit leichten Einschränkungen“ oder besser bewertet wurden (siehe Tabelle 4-1), kann auf die Durchführung von Verbesserungsmaßnahmen im Rahmen der Systemeinführung verzichtet werden. Der PDMSReifegrad kann nach Gl. (7.1) ermittelt werden. Falls nur eine Unternehmensperspektive in der Bewertung nicht berücksichtigt oder mit einem Reifegrad von 3 oder schlechter bewertet wurde, müssen gezielte Verbesserungsmaßnahmen eingeleitet werden. Bei einer fehlenden Unternehmensperspektive beginnt die Herleitung des Reifegrads mit dem Arbeitsschritt A. Teilarbeitsschritt D.5 beschreibt diese Notwendigkeit. In Arbeitsschritt C konnte mit Hilfe der Prozessklassifizierung mögliches Verbesserungspotenzial zur Steigerung des Perspektiven-Reifegrads erkannt werden. Im Rahmen der begrenzten Projektressourcen müssen jedoch diejenigen Maßnahmen umgesetzt werden, die eine möglichst effiziente Verbesserung des Perspektiven-Reifegrads versprechen. Dazu findet eine Identifikation mit Hilfe der Schwachstellenanalyse im Teilarbeitsschritt D.1 statt. Ihre Anwendung innerhalb der Unternehmensperspektive „Prozess“ sowie die Ermittlung der Werteprofile einzelner Bewertungskriterien wurden bereits in Abschn. 7.3.3 behandelt. Anhand der Werteprofile kann das effizienteste Verbesserungspotenzial identifiziert und hinsichtlich der abzuleitenden Verbesserungsmaßnahmen priorisiert werden. Dies wird in Teilarbeitsschritt D.2 durchgeführt. Dabei wird die Maßzahl, die jedem Bewertungskriterium in Teilarbeitsschritt C.1 zugeordnet wurde, in Relation zu seinem absoluten Gewichtungsfaktor gesetzt. So wurde in Abschn. 7.3.3 erläutert, dass das Bewertungskriterium „Anzahl der Teilprozesse“ den Wert des Perspektiven-Reifegrads höher beeinflusst als das Bewertungskriterium „Anzahl beteiligter Rollen“. Der Schwerpunkt bei der Umsetzung von Verbesserungsmaßnahmen ist somit festgelegt. Die gewählten Verbesserungsmaßnahmen werden in der AMSpalte „abgeleitete Maßnahmen“ dokumentiert. Damit ist die AM für diesen Bewertungsdurchgang vollständig ausgefüllt und dient als Vergleichsgrundlage für die nächste Bewertungsiteration.

7.7

Arbeitsschritt D: Ableitung von Verbesserungsaktivitäten

Arbeitsschritt D: Ableitung und Umsetzung von Verbesserungsaktivitäten

PerspektivenReifegrad ok?

nein

D.1 Durchführung der Schwachstellenanalyse

D.2 detaillierte Identifikation von Verbesserungspotential

D.3 Umsetzung der Verbesserungsmaßnahmen durch Umsetzungsprojekte

D.5 Durchführung des AS A, B und C für die anderen Perspektiven

nein

alle PerspektivenReifegrade vorhanden? ja

D.4 Ermittlung des PDMS-Reifegrads

ENDE: Aussage über Unternehmenseignung

Abb. 7-17 Darstellung der Vorgehensweise des Arbeitsschritts D

ja

225

226

7 Lösungsbaustein 2: Bewertung der PDMS-Fähigkeit

Die Umsetzung der gewählten Verbesserungsmaßnahmen erfolgt durch entsprechende Umsetzungsstrategien. Im Fall des ausgewählten Kriteriums „Anzahl der Teilprozesse“ geschah dies durch die Strategie eines Business Process Reengineerings (BPR). Ihr Schwerpunkt lag auf der Ermittlung des vorhandenen Rationalisierungspotenzials auf Teilprozessebene. Als Ergebnis konnten einzelne Teilprozesse zusammengefasst, anderen Geschäftsprozessen sinnvoll zugeordnet oder vollständig eliminiert werden [Feldhusen u. Gebhardt 2005b]. Weitere Beispiele für durchgeführte Umsetzungsprojekte finden sich in Abb. 7-3. Die gewählte Strategie hängt von der Unternehmensperspektive und dem identifizierten Verbesserungspotenzial ab. So sind möglicherweise für die Produktperspektive Strategien zur Produktoptimierung wie die Referenzprodukt-Strategie oder für die Organisationsperspektive Managementstrategien wie Lean Management geeignet. Mögliche Umsetzungsstrategien werden an dieser Stelle nicht vertiefend behandelt. Es wird auf die einschlägige Literatur verwiesen wie bspw. [Niemann 2003; Schwab 2004; Ophey 2005; Schuh 2005]. Die perspektivenbezogene Auswahl einer geeigneten Strategie zur Maßnahmenumsetzung erfolgt im Teilarbeitsschritt D.3. Für jede Umsetzungsstrategie wird jeweils ein spezielles Umsetzungsprojekt im Unternehmen angestoßen. Dieses wird in der Projektumsetzungsmatrix des CSC-Aufnahmeblatts dokumentiert. Falls die ermittelten Perspektiven-Reifegrade ohne oder nach der Umsetzung von Verbesserungsmaßnahmen auf eine ausreichende PerspektivenFähigkeit schließen lassen, wird im letzten Teilarbeitsschritt D.4 der gesamte PDMS-Reifegrad hergeleitet. Dies geschieht durch die Summierung aller fünf Perspektiven-Reifegrade nach Gl. (7.1). Anschließend kann aufgrund des numerischen Werts eine Aussage über die augenblickliche PDMS-Fähigkeit des Unternehmens getroffen werden. Mit Beendigung des Teilarbeitsschritts D.4 ist der eigentliche Bewertungszyklus mittels der CSC abgeschlossen. Falls die Reifegrad-Ergebnisse nicht zufrieden stellend sind, wird ein erneuter Bewertungszyklus eingeleitet. Damit wird die Effizienz der umgesetzten Verbesserungsmaßnahmen überprüft. Sollte aufgrund der Bewertungsergebnisse eine Neuausrichtung der definierten Ziele notwendig sein, beginnt die erneute Bewertung mit Arbeitsschritt A. Ohne eine notwendige Neuausrichtung wird mit Arbeitsschritt B begonnen. In beiden Fällen können einzelne Teilarbeitsschritte übersprungen werden. Die gewonnenen Ergebnisse des Arbeitsschritts D werden innerhalb der PDMS-Einführungsmethodik umgesetzt. Gleichzeitig stellt er den letzten

7.8

Exemplarische Ermittlung der PDMS-Fähigkeit

227

Bewertungsschritt innerhalb des gesamten PDMS-Regelkreises dar, sobald das definierte Abbruchkriterium erreicht wurde (siehe Abschn. 5.2).

7.8 Exemplarische Ermittlung der PDMS-Fähigkeit Die beschriebenen Arbeitsschritte A - D werden nachfolgend durch ein Beispiel erläutert. Hierbei wird die Unternehmensperspektive „Prozess“ betrachtet und das entsprechende Zielsystem der Nutzwertanalyse (siehe Abschn. 7.3.1) entwickelt. Die Vorgehensweise für die anderen Unternehmensperspektiven ist identisch; es ändern sich lediglich die beschriebenen Inhalte. Dies gilt insbesondere für die Ziele sowie die Zuordnung zu den Kriterienclustern. An dieser Stelle kommen die vorgestellten Kriterienkataloge für jede Unternehmensperspektive zum Einsatz. Ein Kriterienkatalog ist eine Sammlung von einzelnen Bewertungskriterien, die einem bestimmten Kriteriencluster zugeordnet sind (siehe Abschn. 7.5).

Abb. 7-18 Allgemeine Vorgehensweise zur Ermittlung des PerspektivenReifegrads

Das Beispiel bezieht sich auf den Teilprozess „Erzeugung von Mustern“. Die Ermittlung des zugehörigen Perspektiven-Reifegrads wurde innerhalb

228

7 Lösungsbaustein 2: Bewertung der PDMS-Fähigkeit

eines Industrieprojekts durchgeführt. Das Projekt sowie der Prozess werden in Kap. 9 beschrieben. Die allgemeine Vorgehensweise zur Ermittlung der Perspektivenfähigkeit ist in Abb. 7-18 gezeigt. Auch wenn sich die nachfolgende Beschreibung auf das PDMS-Projekt bezieht, ist die Vorgehensweise während der System-Betriebsphase ebenfalls anwendbar. Der Arbeitsschritt A ist identisch mit dem ersten Arbeitsschritt der PDMSEinführungsmethodik. Es werden die Ziele auf strategischer Ebene dem Unternehmensleitbild (der Unternehmensvision) zugeordnet. Diese strategischen Ziele werden auf ihre Eignung zur generellen Umsetzbarkeit mittels der PLM-Strategie überprüft. Das Ergebnis ist die qualitative PDMSFähigkeit. In Kap. 9 werden die strategischen Ziele und ihre qualitative PDMS-Fähigkeit dargestellt.

Abb. 7-19 Anwendung der Präferenzmatrix und die zugehörigen Gewichtungsfaktoren im Arbeitsschritt A

Anschließend werden die strategischen Ziele auf die operative Ebene der jeweiligen Unternehmensperspektiven heruntergebrochen. Als betrachteter Beispielprozess wurde bereits zu diesem Zeitpunkt der Ablauf zur Erstellung von Mustern im Unternehmen gewählt. Dies geschah aus dem Grund, da der vorhandene Ablauf als eine wesentliche Ursache für die hohe Variantenanzahl im Unternehmen verantwortlich gemacht wurde. Das zugehörige strategische Ziel war eine Reduzierung der (internen) Variantenan-

7.8

Exemplarische Ermittlung der PDMS-Fähigkeit

229

zahl bei gleichzeitiger Beibehaltung eines möglichst hohen externen Variantenangebots für die Kunden (siehe Kap. 2). Dieses strategische Ziel sollte u. a. durch eine Prozessoptimierung mittels PDMS-Unterstützung erreicht werden. Zur Umsetzung auf die operative Ebene wurden von den Mitgliedern des Kernteams folgende Ziele identifiziert: x x x x x x

die Möglichkeit einer (Modell-)Eigenpflege; die Verkürzung der gesamten Prozessdurchlaufzeit; die Erstellung eines definierten und flexiblen Prozessmodells; Analysemöglichkeiten zur Kostensenkung; die Minimierung der Benutzer-Schnittstellenanzahl und eine hohe Prozesstransparenz in Bezug auf die einzelnen Datenobjektstatus.

Sämtliche operativen Ziele wurden in einem Workshop ermittelt und mittels der Präferenzmatrix priorisiert. Die Priorisierung erfolgte durch die Zuordnung einzelner Gewichtungsfaktoren, die sich durch die Anwendung der Präferenzmatrix ergaben. Die operativen Ziele für den betrachteten Prozess und ihre normierten Gewichtungsfaktoren sind in Abb. 7-19 dargestellt.

Abb. 7-20 Darstellung der AM „Prozess“ nach den Arbeitsschritten A und B

230

7 Lösungsbaustein 2: Bewertung der PDMS-Fähigkeit

Mit der Ermittlung der operativen Ziele und ihrer relativen (normierten) Gewichtungsfaktoren ist der Arbeitsschritt A abgeschlossen. Beide werden in der Spalte „operative Ziele“ der Aktivitätenmatrix (AM) „Prozess“ dokumentiert (siehe Abb. 7-20). Falls in diesem Arbeitsschritt der zu bewertende (Teil-)Prozess noch nicht ausgewählt wurde, geschieht dies zu Beginn des Arbeitsschritts B. Der ausgewählte Prozess dient als Grundlage der Bewertung. In diesem Beispiel wurde der Prozess „Erstellung von Mustern“ durch das Unternehmen ausgewählt. Seine PDMS-Fähigkeit sollte innerhalb der Pilotphase verbessert werden. Der gewählte Prozess wird in die erste Spalte der AM eingetragen; die zugehörige Prozessanalyse sowie das vorhandene Prozessmodell wurden in Arbeitsschritt 2 während der IST-Analyse dokumentiert. Einen Prozessausschnitt zeigt Abb. 6-28. Danach müssen die operativen Zielsetzungen den einzelnen Kriterienclustern zugeordnet werden. Dabei werden aus den Kriterienkatalogen diejenigen Bewertungskriterien bestimmt, deren Manipulation das entsprechende operative Ziel maßgeblich beeinflusst. Die Kriteriencluster und ihre Kriterienkataloge wurden in Abschn. 7.5 beschrieben. Wie in Abb. 7-20 gezeigt, lassen sich z. B. die operativen Ziele „Senkung der Durchlaufzeit“ (DLZ) und „Möglichkeit der Modelleigenpflege“ (MEP) durch Kriterien bewerten, die sich im Kriterienkatalog des Bewertungskriterienclusters „Komplexitätsgrad“ (KG) befinden. So kann die Durchlaufzeit durch die Anzahl der vorhandenen Teilprozesse beeinflusst werden: Je mehr Teilprozesse am Gesamtprozess beteiligt sind, desto höher ist die Durchlaufzeit. Eine ähnliche Überlegung gilt für das Ziel „Modelleigenpflege“.

Abb. 7-21 Exemplarische Vorgehensweise zur Ermittlung der relativen Gewichtungsfaktoren auf der Zielstufe „Bewertungskriteriencluster“

7.8

Exemplarische Ermittlung der PDMS-Fähigkeit

231

Nach dieser Zuordnung können auf der Zielstufe „Bewertungskriteriencluster“ der Nutzwertanalyse die relativen Gewichtungsfaktoren für jeden einzelnen Kriteriencluster ermittelt werden. Dies ist in Abb. 7-21 gezeigt: Die normierten Gewichtungsfaktoren der operativen Ziele DLZ und MEP werden addiert und bilden einen gesamten relativen Gewichtungsfaktor von 0,46 für den Kriteriencluster „Komplexitätsgrad“:

rGFDLZ  rGFMEP

rGFKG

0,22  0,24 0,46 Zur Ermittlung der relativen Gewichtungsfaktoren der anderen Kriteriencluster wird in gleicher Weise vorgegangen. Die komplette Tabelle für diese Zielstufe findet sich in Kap. 9. Aus Gründen der Übersichtlichkeit wird empfohlen, maximal drei Bewertungskriterien einem entsprechenden Cluster zuzuordnen.

Abb. 7-22 Zielsystem bis zur Zielstufe der Bewertungskriteriencluster einschließlich der berechneten Gewichtungsfaktoren (Arbeitsschritt B)

Das Zielsystem bis zur Zielstufe „Bewertungskriteriencluster“ ist in Abb. 7-22 dargestellt. Hier ist auch erkennbar, dass der Kriteriencluster „Grad der Arbeitsteilung“ in die Bewertung nicht einfließt, da sich ihm keine operativen Ziele zuordnen lassen. In einem anderen Unternehmen kann es jedoch vorkommen, dass dieser Cluster aufgrund anderer Zielsetzungen

232

7 Lösungsbaustein 2: Bewertung der PDMS-Fähigkeit

berücksichtigt werden muss. Die Summe aller relativen Gewichtungsfaktoren muss auf dieser Zielstufe den Wert „1“ bilden; damit kann auch die korrekte Gewichtung kontrolliert werden.

Abb. 7-23 Zielsystem bis zur Zielstufe der Bewertungskriterien aus den Kriterienkatalogen einschließlich der berechneten Gewichtungsfaktoren (Arbeitsschritt B)

Die relativen Gewichtungsfaktoren auf der niedrigsten Zielstufe „Bewertungskriterien“ werden durch einen weiteren Workshop unter Anwendung der Präferenzmatrix ermittelt. So ist in Abb. 7-23 erkennbar, dass der Kriteriencluster „Komplexitätsgrad“ für den Musterprozess aus drei einzelnen Bewertungskriterien besteht: x Anzahl der Teilprozesse (rGF = 0,5), x Anordnung der Aktivitäten (rGF = 0,25) und x Anzahl beteiligter Rollen (rGF = 0,25). Anhand der ermittelten relativen Gewichtungsfaktoren wird deutlich, dass die Mitglieder des Kernteams durch eine Verminderung der Teilprozessanzahl das höchste Potenzial zur Reduzierung der Prozesskomplexität sehen. Die beiden anderen Kriterien wurden in ihren Auswirkungen auf den Prozess-Komplexitätsgrad als gleichwertig eingestuft. Auch hier ist die Vorgehensweise bei allen anderen Bewertungskriterien identisch; die Kontrolle findet ebenfalls durch die Summierung aller relativen Gewichtungsfaktoren, bezogen auf ihren übergeordneten Knoten, statt. Ihre Summe ergibt den Wert 1.

7.8

Exemplarische Ermittlung der PDMS-Fähigkeit

233

Anschließend können mit Hilfe von Gl. (7.2) die absoluten Gewichtungsfaktoren auf dieser und den übergeordneten Zielstufen ermittelt werden. Beispielhaft ist dies für das Kriterium „Anzahl beteiligter Rollen“ (AR) gezeigt:

aGFAR aGFAR

rGFAR ˜ aGFKG 0,25 ˜ 0,46 0,115

Die ausgewählten Kriterien und ihre relativen sowie absoluten Gewichtungsfaktoren werden in der Wertetabelle dokumentiert. Die Wertetabelle wurde in Abschn. 7.6 beschrieben und ist für den Beispielprozess ausschnittsweise in Abb. 7-25 dargestellt. Mit der Ermittlung aller Gewichtsfaktoren für jede Zielstufe ist der Arbeitsschritt B abgeschlossen. In Arbeitsschritt C wird jedes Bewertungskriterium anhand einer typischen Eigenschaftsgröße beschrieben. Dabei muss es sich um eine Eigenschaftsgröße handeln, die das Kriterium einerseits hinreichend genau beschreibt und andererseits erfassbar bzw. messbar ist. Bspw. kann das Bewertungskriterium „Anzahl der prozessbeteiligten Rollen“ dadurch beschrieben werden, indem die prozessbeteiligten Rollen gezählt werden. Das Bewertungskriterium „Eindeutigkeit der Prozessdaten“ kann anhand der Anzahl vorhandener Referenzierungen zwischen den erfassten Datenobjekten charakterisiert werden. Die beteiligten Rollen sowie die Anzahl der Referenzierungen wurden während der IST-Analyse im zweiten Arbeitsschritt der Einführungsmethodik erfasst. Dies gilt auch für die Eigenschaftsgrößen sämtlicher anderer Bewertungskriterien. Anhand der PDMS-Werteskala, die in Abschn. 7.6 beschrieben wurde, wird jeder Einflussgröße ihre entsprechende Maßzahl zugeordnet. Damit kann der Kriterienwert für jedes Bewertungskriterium nach Gl. (7.3) berechnet werden.

234

7 Lösungsbaustein 2: Bewertung der PDMS-Fähigkeit

Abb. 7-24 Ermittlung des Kriterienwerts für das Bewertungskriterium „Anzahl der Teilprozesse“ im Arbeitsschritt C

Nachfolgend wird die Berechnung des Kriterienwerts KW für das Kriterium „Anzahl der Teilprozesse“ (ATP) gezeigt (siehe Abb. 7-24). Hierbei wird von der Überlegung ausgegangen, die bereits in Arbeitsschritt B durchgeführt wurde: Je weniger Teilprozesse vorhanden sind, umso einfacher stellt sich die Struktur des Gesamtprozesses dar. Die Folge sind eine geringere Komplexität und damit eine bessere PDMSImplementierungseignung in Form eines Workflows. Der betrachtete Musterprozess besteht aus zwei Teilprozessen, d. h. die Eigenschaftsgröße „Anzahl der Teilprozesse“ besitzt den Wert 2. Damit ist der Musterprozess gut für die Systemimplementierung geeignet. Die ISTAnalyse hat jedoch ergeben, dass die Aktivitäten eines Teilprozesses unzureichend erfasst sind; deshalb wird die Maßzahl MZ mit dem Wert 2 (PDMS-geeignet mit leichten Einschränkungen) zugeordnet. Nach Gl. (7.3) errechnet sich der entsprechende Kriterienwert KWATP: KW ATP KW ATP

aGFATP ˜ MZ ATP 0,23 ˜ 2 0,46

Die Vorgehensweise ist in Abb. 7-24 grafisch dargestellt. Der Perspektiven-Reifegrad ergibt sich nach Gl. (7.4) durch die Addition aller Krite-

7.8

Exemplarische Ermittlung der PDMS-Fähigkeit

235

rienwerte auf der untersten Zielstufe. Ein Ausschnitt aus der zugehörigen Wertetabelle zeigt Abb. 7-25; die vollständige Wertetabelle für den betrachteten Prozess wird in Kap. 9 beschrieben.

Abb. 7-25 Ausschnitt der Wertetabelle für den Beispielprozess „Erzeugung von Mustern“

Der Perspektiven-Reifegrad für den Prozess „Erstellung von Mustern“ liegt bei RGMusterprozess = 2,8. Seine Berechnung mit den entsprechenden Kriterienwerten wird in Kap. 9 durchgeführt. Der Musterprozess in seiner augenblicklichen Form ist somit der Prozessklasse „Regelprozess mit hohem Flexibilitätsanteil“ zuzuordnen. Damit ist er in seinem analysierten Ablauf zur Umsetzung in ein PDMS geeignet. Nach Tabelle 7-3 sind jedoch umfangreiche Verbesserungsmaßnahmen erforderlich. Nach Abb. 7-14 (Beschreibung der Prozessklassen) können bspw. die Anzahl der beteiligten Rollen reduziert oder ein standardisierter Prozessablauf geschaffen werden, der von dem bearbeitenden Mitarbeiter entkoppelt ist. Für detaillierte Verbesserungsmaßnahmen wird die Schwachstellenanalyse durchgeführt. Die Durchführung der Schwachstellenanalyse findet in Arbeitsschritt D statt. Aufgrund der einzelnen Bewertungsfaktoren und ihrer zugehörigen Kriterienwerte können Verbesserungsmaßnahmen gezielt ermittelt werden, die das größte Umsetzungspotenzial versprechen. Die Identifizierung dieser Maßnahmen ist insbesondere während der Pilotphase bedeutsam, um den Mehrwert eines PDMS gegenüber dem Management und den Mitarbeitern darzustellen.

236

7 Lösungsbaustein 2: Bewertung der PDMS-Fähigkeit

Tabelle 7-3 Klassifizierung des Perspektiven-Reifegrads der Unternehmensperspektive „Prozess“ (in Anlehnung an Tabelle 4-1) Reifegrad

zugehörige PDMS-Fähigkeit

geschätzter Umfang an Verbesserungsaktivitäten

Reifegrad 1

Prozess ist uneingeschränkt PDMS-fähig

keine Verbesserungsaktivitäten erforderlich

Reifegrad 2

Prozess ist PDMS-fähig mit leichten Einschränkungen

wenig Verbesserungsaktivitäten erforderlich

Reifegrad 3

Prozess ist PDMS-fähig mit erheblichen Einschränkungen

umfangreiche Verbesserungsaktivitäten erforderlich

Reifegrad 4

Prozess ist nicht PDMS-fähig

erhebliche Verbesserungsaktivitäten erforderlich

Im beschriebenen Beispiel wurden die Bewertungskriterien „Anzahl beteiligter Teilprozesse“, „Anordnung der Prozessaktivitäten“ und „Durchgängigkeit der D&I-Flüsse“ behandelt. In Abb. 7-25 ist ein Ausschnitt der zugehörigen Wertetabelle gezeigt. Bedeutsam für die Durchführung der Schwachstellenanalyse sind die absoluten Gewichtungsfaktoren sowie die zugehörige Maßzahl. Sie werden in ein Koordinatensystem eingetragen. Einen Ausschnitt der Schwachstellenanalyse zeigt Abb. 7-26; die Größe der dargestellten Flächen stellt den jeweiligen Kriterienwert dar.

Abb. 7-26 Ausschnitt aus der Schwachstellenanalyse des Beispielprozesses „Erzeugung von Mustern“

7.9

Die CSC als Grundlage des PDMS-Projektcontrollings

237

Anhand der Schwachstellenanalyse der drei analysierten Bewertungsfaktoren zeigt sich, dass Verbesserungsmaßnahmen im Bereich der beteiligten Teilprozessanzahl die größte Änderung für den Perspektiven-Reifegrad „Prozess“ bedingen. Verbesserungsmaßnahmen zur Prozessreduzierung können bspw. eine Verschmelzung mehrerer Teilprozesse zu einem Teilprozess oder eine komplette Streichung „überflüssiger“ Teilprozesse sein. Diese Maßnahmen werden in die Aktivitätenmatrix eingetragen und anschließend durch ein Verbesserungsprojekt umgesetzt. Damit ist die Aktivitätenmatrix ausgefüllt (siehe Abb. 7-27). Nach der Umsetzung findet eine erneute Überprüfung des Perspektiven-Reifegrads statt, um die Wirksamkeit der Maßnahmenumsetzung zu kontrollieren.

Abb. 7-27 Ausgefüllte Aktivitätenmatrix für den betrachteten Beispielprozess „Erzeugung von Mustern“

Die gesamte Schwachstellenanalyse für den betrachteten Musterprozess findet sich in Kap. 9.

7.9 Die CSC als Grundlage des PDMS-Projektcontrollings Eine wesentliche Unternehmensanforderung an den methodischen Lösungsansatz ist eine begleitende Kontrolle des PDMS-Projekts. Mit der PDMS-Einführungsmethodik und der CSC wurden zwei Instrumente entwickelt, mit denen sich diese Anforderung erfüllen lässt. In diesem Ab-

238

7 Lösungsbaustein 2: Bewertung der PDMS-Fähigkeit

schnitt werden die Zusammenhänge und die notwendigen Bewertungszeitpunkte vorgestellt, um ein zielgerichtetes Projektcontrolling hinreichend zu gewährleisten. Das Controlling eines PDMS-Projekts besitzt zwei Schwerpunkte. Dabei handelt es sich um die Einhaltung der Projektrahmenbedingungen sowie die Kontrolle des augenblicklichen Zielerfüllungsgrads. In Abb. 7-28 ist die Berücksichtigung beider Schwerpunkte begleitend zur Einführungsmethodik dargestellt.

Abb. 7-28 Darstellung der beiden Schwerpunkte des PDMS-Projektcontrollings und ihr zeitlicher Einsatz

Die Einhaltung der Projektrahmenbedingungen betrifft das klassische Projektcontrolling der verfügbaren Projektressourcen wie Zeit, Kosten und Mitarbeiter. Dies geschieht auf der Grundlage des Ablaufplans, wie er in Abschn. 6.5.2 dargestellt ist. Über den Projektstand einschließlich der verbrauchten Projektressourcen berichtet die Projektleitung zu festgelegten Zeitpunkten, den sog. Meilensteinen, dem Unternehmensmanagement. Sie finden am Ende jedes Arbeitsschritts statt. Bei Bedarf können zusätzliche

7.9

Die CSC als Grundlage des PDMS-Projektcontrollings

239

Meilensteine festgelegt werden. Sämtliche Meilensteine sind fest im Ablaufplan definiert. Das klassische Controlling der Projektressourcen berücksichtigt ausschließlich organisatorische, nicht jedoch inhaltliche Aspekte eines PDMS-Projekts. So ist es bspw. nicht möglich, während der Projektlaufzeit eine Aussage über den augenblicklichen Grad der Zielerreichung zu erhalten. Dies stellt eine wesentliche Voraussetzung dar, um frühzeitig auf Fehlentwicklungen während des eigentlichen Projektdurchlaufs reagieren und durch geeignete Maßnahmen korrigierend eingreifen zu können. Mit Hilfe der CSC und der PDMS-Fähigkeit kann der augenblickliche Zielerfüllungsgrad ermittelt werden (das sog. CSC-Projektcontrolling). Dies geschieht auf der Grundlage eines SOLL-IST-Vergleichs innerhalb des PDMS-Regelkreises. Aus den Vergleichsergebnissen lassen sich Aussagen ableiten, ob die definierten Ziele vereinbarungsgemäß erreicht werden. Dies geschieht jeweils am Ende der Untersuchungs- und der Umsetzungsphase. In Abhängigkeit des Bewertungszeitpunkts wird das Ergebnis als IST- bzw. SOLL-PDMS-Fähigkeit bezeichnet. Als Bewertungsgrundlage dienen die strategischen sowie operativen Zielsetzungen, die Qualität der identifizierten Daten- und Informationsflüsse einschließlich ihrer repräsentierenden Modelle und die notwendigen Verbesserungsmaßnahmen. Die eigentliche Vorgehensweise bei der Bewertungsdurchführung ist in Abb. 7-29 exemplarisch für die Unternehmensperspektive „Prozess“ gezeigt. Hier sind auch die zugehörigen Arbeitsschritte aufgeführt, die für das Projektcontrolling gezielt durchgeführt werden müssen. Für die anderen Unternehmensperspektiven muss diese Vorgehensweise inhaltlich angepasst werden. Die durchgeführte Bewertung in der Untersuchungsphase findet auf der Geschäftsprozessebene und seiner Teilprozesse statt. Der ablauforientierte Ansatz wird gewählt, da aufgrund von QM-Maßnahmen in vielen Unternehmen die technischen Prozesse auf diesen beiden Ebenen dokumentiert sind [Fischer u. Scheibeler 2003; Cassel 2003]. Diesen dokumentierten Abläufen werden die Produkt-, die IT-, die Organisations- und die Kostendaten zugeordnet. Sie werden aus den repräsentierenden Modellen der einzelnen Unternehmensperspektiven entnommen. Damit ergeben sich die Daten- und Informationsflüsse. Mittels der CSC-Bewertungskriterien kann deren augenblicklicher Zustand perspektivenabhängig bewertet sowie bestehende Problemfelder und resultierendes Verbesserungspotenzial erkannt werden. Das Ergebnis wird als augenblickliche IST-PDMS-Fähigkeit bezeichnet.

240

7 Lösungsbaustein 2: Bewertung der PDMS-Fähigkeit

Am Ende der Untersuchungsphase dient die Bewertungsaussage als Entscheidungsgrundlage, ob die zweite Phase durchgeführt oder das PDMSProjekt beendet werden soll. Wird das Projekt fortgeführt, so können aufgrund der Bewertungsergebnisse Verbesserungsmaßnahmen gezielt eingeleitet werden. Damit kann der weitere Aufwand zur Erreichung des SOLLZustands abgeschätzt werden.

Abb. 7-29 Vorgehensweise bei der Bewertung der PDMS-Fähigkeit am Beispiel der Unternehmensperspektive „Prozess“. Die benötigten Daten für die Bewertung werden aus der methodischen Vorgehensweise gewonnen

In der Umsetzungsphase werden die Verbesserungsmaßnahmen durch spezifische Projekte umgesetzt. Ihr Ziel ist die Steigerung der Implementierungseignung des Produktdaten-, des Prozessdaten- und des Rollenmodells. Sie werden anschließend in das PDMS implementiert.

7.10

Zusammenfassung Kapitel 7

241

Begleitend zur Pilotphase findet eine zweite CSC-Bewertung statt. Es wird überprüft, ob sich durch die umgesetzten Maßnahmen die ermittelte ISTPDMS-Fähigkeit verbessert hat. Dies schließt auch die Bewertung hinsichtlich des Zielerreichungsgrads ein. Das Bewertungsergebnis wird am Ende der Umsetzungsphase als SOLL-PDMS-Fähigkeit bezeichnet. Sie dient als Entscheidungsgrundlage, ob das PDMS im Unternehmen flächendeckend eingeführt werden soll. Falls das Ergebnis der SOLL-PDMS-Fähigkeit den Unternehmenserwartungen nicht entspricht, müssen die durchgeführten Maßnahmen spezifiziert werden. Es findet ein iterativer Rücksprung statt. In diesem Augenblick erhält die SOLL-PDMS-Fähigkeit den Status einer gemessenen ISTPDMS-Fähigkeit. Anschließend werden weitere Maßnahmen zur Verbesserung der PDMS-Fähigkeit eingeleitet, bis das definierte Abbruchkriterium des PDMS-Regelkreises erreicht ist. Aufgrund seiner vier Arbeitsschritte findet das CSC-Projektcontrolling ständig begleitend zur PDMS-Einführungsmethodik statt. Zusammen mit den vorgegebenen Projektressourcen sind die Inhalte des gesamten PDMSProjekts vollständig erfasst.

7.10

Zusammenfassung Kapitel 7

Neben einer methodischen Vorgangsweise zur Einführung eines PDMS ist eine wesentliche Unternehmensanforderung die Durchführungsmöglichkeit einer Selbstbewertung. Damit soll die augenblickliche Unternehmenseignung in Bereichen wie vorhandenen Produkten, der bestehenden Ablauf- und der Aufbauorganisation bewertet werden. Anschließend lassen sich Aussagen hinsichtlich des Umsetzungsaufwands von PLM, der Mehrwert für das Unternehmen bei einer PDMS-Einführung und die Identifizierung bestehender Schwachstellen für die Ableitung gezielter Verbesserungsmaßnahmen treffen. Die Bewertungsergebnisse verbessern das Controlling des PDMS-Projekts bei einer Systemeinführung, aber auch während der Systembetriebsphase deutlich. Um eine zielgerichtete Systemeinführung zu gewährleisten, beinhaltet der zweite Lösungsbaustein des PDMS-Regelkreises aus Kap. 5 ein Bewertungsinstrument zur Unterstützung eines projektbegleitenden Controllings. Mit Hilfe der Capability Scorecard (CSC) ist es möglich, die Unternehmenseignung in Form der PDMS-Fähigkeit bereits im Vorfeld der Systemeinführung zu bestimmen.

242

7 Lösungsbaustein 2: Bewertung der PDMS-Fähigkeit

Dazu wird die CSC zunächst definiert und ihr Aufbau beschrieben. In Anlehnung an die Balanced Scorecard besteht die CSC aus fünf Unternehmensperspektiven, die von der PDM-Systemeinführung beeinflusst werden. Dabei werden neben finanziellen Aspekten auch vorhandene Produkte, bestehende Prozesse, die augenblickliche Organisationsform sowie die vorhandene IT-Systemlandschaft betrachtet. Jede Unternehmensperspektive wird durch ihr entsprechendes Modell wie das Produktdatenmodell oder das Rollenmodell repräsentiert. Die Vorgehensweise zur Bewertung geschieht in vier Arbeitsschritten. Im ersten Arbeitsschritt werden die strategischen und operativen Ziele bestimmt. Anschließend werden im zweiten und dritten Arbeitsschritt diese Ziele in spezifische Bewertungskriterien überführt, die aus PDMSspezifischen Kriterienkatalogen stammen. Anhand dieser Bewertungskriterien wird die augenblickliche Eignungsfähigkeit zur Systemimplementierung der einzelnen Modelle jeder Unternehmensperspektive beurteilt. Dies geschieht durch die Anwendung der Nutzwertanalyse. Das Ergebnis ist der Perspektiven-Reifegrad, der eine Aussage über die augenblickliche PDMS-Eignungsfähigkeit jeder Unternehmensperspektive trifft. Mit Hilfe der Bewertungsergebnisse können durch eine Schwachstellenanalyse im vierten Arbeitsschritt vorhandene Schwachstellen identifiziert und konkrete Verbesserungsmaßnahmen gezielt eingeleitet werden. Alle vier Arbeitsschritte sind anhand eines Beispiels dargestellt. Durch die Bewertung können Aussagen über den Umsetzungsaufwand und vorhandenes Verbesserungspotenzial getroffen werden. Nach der Durchführung konkreter Verbesserungsmaßnahmen werden durch einen erneuten Bewertungsdurchlauf ihre Auswirkungen auf die PDMS-Fähigkeit gemessen. Die benötigen Bewertungsdaten werden durch den ersten Lösungsbaustein, der methodischen Vorgehensweise zur Systemeinführung, bereitgestellt. Die Bewertungsdokumentation erfolgt im CSC-Aufnahmeblatt. Die Bewertungsergebnisse werden unmittelbar während der Systemeinführung umgesetzt und mittels der CSC ständig gemessen. Der gesamte Lösungsansatz besitzt den Charakter eines Regelkreises. Literatur Brandt T (2002) Analyse existierender Ansätze zur Wirtschaftlichkeitsberechnung. In: Qualität und Wirtschaftlichkeit. Symposion, Düsseldorf Breiing A, Knosala R (1997) Bewerten technischer Systeme – theoretische und methodische Grundlagen bewertungstechnischer Entscheidungshilfen. Springer, Berlin-Heidelberg-New York

7.10

Zusammenfassung Kapitel 7

243

Cassel M (2003) Qualitätsmanagement nach ISO-9001:2000 - Grundwerk. Hanser, München-Wien Ehrmann H (2003) Balanced Scorecard - Kompakt Training, 3. Auflage. Kiehl, Ludwigshafen Eigner M, Stelzer R (2001) Produktdatenmanagement-Systeme - ein Leitfaden für Product Development und Life Cycle Management. Springer, BerlinHeidelberg-New York Feldhusen J, Gebhardt B (2005a) Ein Beitrag zur Bewertung der PDMS-Fähigkeit eines Unternehmens - die Capability Scorecard. In: Informations- und Wissensdrehscheibe Produktdatenmanagement. GITO, Berlin Feldhusen J, Gebhardt B (2005b) Der Weg zum individuellen Produkt – Redefintion eines Variantenerzeugungsprozesses in der Praxis. In: 3. Gemeinsames Kolloquium Konstruktionstechnik (Tagungsband). Shaker, Aachen Fischer F, Scheibeler AAW (2003) Handbuch Prozessmanagement. Hanser, München-Wien Friedag H, Schmidt W (2004) My Balanced Scorecard, 3. Auflage. Haufe, Freiburg-Berlin-München-Zürich Gebhardt B (2007) Abschätzung der Produktdatenmanagement-Systemfähigkeit produzierender Unternehmen. Shaker, Aachen Hering E, Triemel J, Blank HP (2003) Qualitätsmanagement für Ingenieure. Springer, Berlin-Heidelberg-New York Kaplan RS, Norton DP (1996) The Balanced Scorecard – Translating Strategy into Action. Harvard Business School Press, Boston McAffee A (2003) When Too Much IT-Knowledge Is A Dangerous Thing. In: MIT Sloan Management Review, Vol. 44 No. 2. MIT School of Sloan Management, Massachusetts Müller J (2005) Workflow-based Integration. Springer, Berlin-Heidelberg-New York Niemann J (2003) Management des Produktlebenslaufs. In: Neue Organisationsformen im Unternehmen, 2. Auflage. Springer, Berlin-Heidelberg-New York Ophey L (2005) Entwicklungsmanagement - Methoden in der Produktentwicklung. Springer, Berlin-Heidelberg-New York Pahl G, Beitz W, Feldhusen J, Grote KH (2005) Konstruktionslehre - Grundlagen erfolgreicher Produktentwicklung, 6. Auflage. Springer, Berlin-HeidelbergNew York Picot A, Rohrbach P (1995) Organisatorische Aspekte von WorkflowManagement-Systemen. In: DIN Mitteilungen + elektronorm Heft 4, 74 Jg. Beuth, Berlin-Wien-Zürich Schabacker M (2001) Bewertung der Nutzen neuer Technologien in der Produktentwicklung. Dissertation, Technische Universität Magdeburg Schmidt M (2002) Business Case Guide, 2nd edition. Solution Matrix Ltd, Boston Schöttner J (1999) Produktdatenmanagement in der Fertigungsindustrie. Hanser, München-Wien Schuh G (2005) Produktkomplexität managen, 2. überarbeitete Auflage. Hanser, München-Wien

244

7 Lösungsbaustein 2: Bewertung der PDMS-Fähigkeit

Schwab A (2004) Managementwissen für Ingenieure, 3., neubearb. Aufl. Springer, Berlin-Heidelberg-New York Stark J (2006) Product Lifecycle Management – 21st Century Product Paradigm for Product Realisation, 3rd printing, Springer, London Zangemeister C (1973) Nutzwertanalyse in der Systemtechnik, 3. Auflage. Wittemannsche Buchhandlung, München

8 Wirtschaftlichkeitsbetrachtung

In den bisherigen Ausführungen wurde deutlich, dass sich mit Hilfe eines PDM-Systems die operativen Abläufe in den Hauptunternehmensebenen Produkt, Prozess und Organisation deutlich verbessern lassen. Neben diesen Auswirkungen sind jedoch auch kaufmännische Überlegungen vor und während der Systemeinführung zu berücksichtigen. Die Ausführungen in diesem Kapitel sollen bei kaufmännischen Abschätzungen einer Systemeinführung helfen. Dabei ist es nicht das Ziel, eine allgemeingültige Standardlösung zu beschreiben. Es wird anhand einer grundsätzlichen Vorgehensweise dargelegt, wie die einzelnen Unternehmensperspektiven der CSC unter betriebswirtschaftlichen Gesichtspunkten unternehmensindividuell in Verbindung gebracht werden können. Dies geschieht mit Hilfe des sog. Business Case. Auf seiner Grundlage lassen sich bereits vorhandene Verfahren und Kennzahlen aus der Betriebswirtschaft anwenden.

8.1 Grundgedanken der Wirtschaftlichkeitsbetrachtung Sämtliche Unternehmen haben den Zweck, die Bedürfnisse von Konsumenten zu erfüllen. Ein Konsument kann nicht nur ein externer Kunde, sondern auch das Unternehmen selbst sein. Bedürfnisse treten dabei nicht nur in Form von benötigten Produkten, sondern auch in Form von Dienstleistungen auf. Beide müssen durch eine gesteuerte Koordination vorhandener Arbeitsleistungen und Güter produziert werden, so dass neue bzw. veränderte Dienstleistungen oder Produkte entstehen [Mentzel 2006]. Aufgrund zunehmender Produktentwicklungskosten bei gleichzeitig niedrigem Marktpreis für Produkte kann es sich kein global agierendes Unternehmen erlauben, kostenintensive Projekte ohne vorherige inhaltliche und kaufmännische Prüfung durchzuführen. Dies geschieht aus der Verantwortung gegenüber den Anteilseignern, den Eigentümern und auch den beschäftigten Mitarbeitern heraus. Wirtschaftlichkeitsbetrachtungen und Kostenmanagement unterstützen somit die strategischen Unternehmensent-

246

8 Wirtschaftlichkeitsbetrachtung

scheidungen. Der wesentlichste Punkt ist hierbei eine ökonomische Zielsetzung für das Unternehmen. Auch umfassende IT-Projekte wie das PDMS-Projekt müssen unter betriebswirtschaftlichen Gesichtspunkten analysiert werden. Eine nachweisbare Einbindung des Nutzens in die Wirtschaftlichkeit wird daher immer bedeutsamer und ist bei der geplanten Einführung eines PDMS projektentscheidend. In Anlehnung an die betriebswirtschaftliche Literatur wie [Schwab 2004; Mentzel 2006; Töpfer 2007] wird der Begriff Wirtschaftlichkeit wie folgt definiert: Unter Wirtschaftlichkeit wird das Verhältnis zwischen zukünftigen bzw. erwarteten Leistungen und geplanten bzw. erwarteten Kosten verstanden, bezogen auf eine definierte Zeitperiode. Eine Aussage über die Wirtschaftlichkeit des PDMS-Projekts setzt sich aus den beiden Faktoren Leistung i. S. von erwartetem Nutzen für das Unternehmen sowie den dazu notwendigen Kosten zusammen. Beide Faktoren müssen möglichst exakt und unternehmensspezifisch ermittelt werden, wenn unter kaufmännischen Gesichtspunkten eine Entscheidung getroffen werden soll. Dies betrifft die Beantwortung von Fragen wie x Rechnen sich die Investitionen in ein PDMS? x Welche Einsparungen können erzielt werden? x Wann wird sich die Systemeinführung amortisieren und wie hoch ist der „Return on Investment“? Oftmals wurden PDMS-Projekte anhand von klassischen betriebswirtschaftlichen Verfahren und Kennzahlen bewertet. Diese Bewertungen geschahen oftmals ohne Berücksichtigung der spezifischen Besonderheiten einer PDM-Systemeinführung. Somit wurden häufig unzureichende oder falsche Aussagen getroffen bzw. unrealistische Erwartungen geweckt. Einige Gründe hierfür sind: x Die Auswirkungen der PLM-Strategie und die PDMS-Einführung umfassen nicht nur eine einzelne Abteilung. Häufig sind deutliche Einsparungspotenziale in anderen Abteilungen auszumachen als in denjenigen, in denen das PDMS eingeführt wurde. x Viele Nutzenfaktoren wie Prozess-Standardisierungen oder höhere Produktqualität können monetär schwer oder nicht erfasst werden, obwohl sie deutliche positive Auswirkungen auf die Produktentwicklung oder die Produktion besitzen.

8.1

Grundgedanken der Wirtschaftlichkeitsbetrachtung

247

x Deutliche finanzielle Auswirkungen innerhalb des Unternehmens treten meist zeitlich verzögert auf, häufig erst in der folgenden Produktgeneration. So müssen diejenigen Maßnahmen, die zu einer höheren Teilewiederverwendung oder weniger Produktänderungen führen, zunächst operativ umgesetzt werden. x Da sich der Nutzen eines PDMS am offensichtlichsten anhand der Durchgängigkeit und Qualität der D&I-Flüsse sowie der zugehörigen Prozesse offenbart, ist er in den frühen Produktentstehungsphasen kaum monetär quantifizierbar. x Meist wird nur die technische Seite einer Einführung berücksichtigt; die zeitliche Komponente für das „Umdenken“ innerhalb der PLM-Strategie und die Akzeptanz des PDMS bei den Mitarbeitern wird häufig vernachlässigt. Aus den genannten Gründen ist eine Zuordnung von Auswirkungen wie Einsparungen zu einer bestimmten Kostenstelle schwer durchführbar; dagegen lassen sich die Kosten für das PDMS-Projekt eindeutig dem Technischen Bereich zuordnen. Diese Zusammenhänge sind vereinfacht in Abb. 8-1 dargestellt: In den frühen Phasen der Produktentwicklung ist der nicht-monetäre Nutzen wie eine Prozessstandardisierung oder kontrollierter D&I-Flüsse sehr hoch; dazu korrespondieren die höchsten Ausgaben zur Umsetzung von PLM im Technischen Bereich. Der monetäre Nutzen einer Systemeinführung zeigt sich v. a. in späteren Lebenszyklusphasen deutlich. Dies betrifft bspw. die Fertigung auf der Basis von Wiederholteilen oder ein verbesserter Kundenservice aufgrund schnell verfügbarer und aktueller Produktdaten.

Abb. 8-1 Nutzenpotenziale und Ausgaben über einen betrachteten Produktlebenszyklus

Innerhalb der CSC geschieht die Wirtschaftlichkeitsbetrachtung in der Unternehmensperspektive Finanzen. Mittels der in den Arbeitsschritten zur

248

8 Wirtschaftlichkeitsbetrachtung

Bewertung und zur Einführung gewonnenen Ergebnisse wird versucht, jede Unternehmensperspektive auf ihr wirtschaftliches Potenzial zu analysieren. Dabei kommen bereits vorhandene betriebswirtschaftliche Verfahren und Kennzahlen zum Einsatz. Der Schwerpunkt dieser Vorgehensweise liegt auf einer expliziten Berücksichtigung der Zusammenhänge zwischen jeder Unternehmensperspektive und den wirtschaftlichen Aspekten, die durch eine PDMS-Einführung ausgelöst wird. Abbildung 8-2 soll ein Gefühl für die komplexe Abhängigkeit der einzelnen Faktoren in jeder Unternehmensperspektive vermitteln.

Abb. 8-2 Abhängigkeit exemplarischer Faktoren der Unternehmensperspektiven bei einer PDMS-Einführung

In Abb. 8-3 ist die grundsätzliche Vorgehensweise zur Erhebung von Wirtschaftlichkeitsbetrachtungen im PDMS-Bereich schematisch dargestellt. Dabei besitzt sie nicht den Anspruch, klassische betriebswirtschaftliche Verfahren zu ersetzen; sie spezifiziert lediglich die Eingangsgrößen, die zur kaufmännischen Bewertung eines PDMS-Projekts notwendig sind (vgl. hierzu Kap. 5.2). Das wichtigste Hilfsmittel zur unternehmensindividuellen Erfassung des Nutzens stellt das gewählte SOLL-Szenario aus Arbeitsschritt 2 dar. Wird das SOLL-Szenario durch Kostenaspekte erweitert, ergibt sich der sog. Business Case. Er dokumentiert gleichzeitig die Vorgehensweise bei der Ermittlung der Wirtschaftlichkeit des PDMS-Projekts.

8.1

Grundgedanken der Wirtschaftlichkeitsbetrachtung

249

Die Nutzenerhebung sowie die Erfassung der relevanten Kosten auf der Grundlage des SOLL-Szenarios und des Business Case werden in den nachfolgenden Abschnitten behandelt.

Abb. 8-3 Grundsätzliche Vorgehensweise zur Ermittlung der Wirtschaftlichkeit eines PDMS-Projekts

Die in diesem Kapitel vorgestellten Verfahren und Kennzahlen haben sich zur Bewertung bei der Einführung von IT-Systemen mit Hilfe das Business Case als aussagekräftig erwiesen. Die nachfolgenden Ausführungen wurden bewusst einfach gehalten, um die Wirtschaftlichkeitsaspekte eines PDMS-Projekts durch das Management beurteilen zu können. Somit besitzen die Beschreibungen in diesem Abschnitt ausschließlich einen Übersichtscharakter. Möglicherweise sind sie für das Controlling oder die Finanzabteilung nicht aussagekräftig genug; in einem solchen Fall muss der Business Case durch zusätzliche Kennzahlen ergänzt werden. Oftmals sind bestimmte Kennzahlen auch abhängig von der Sicht bzw. dem Interesse des Unternehmens.

250

8 Wirtschaftlichkeitsbetrachtung

In beiden Fällen ist auf die einschlägige betriebswirtschaftliche Literatur verwiesen.

8.2 Nutzenerhebung mit Hilfe des Business Case Bei der Erfassung von Nutzenpotenzialen sind zwei Wege möglich, die sich gegenseitig ergänzen: Zunächst wird anhand von vorhandenen Erfahrungen bei anderen Untenehmen, Veröffentlichungen oder Studien im Bereich PLM/PDMS das grundsätzlich mögliche Potenzial ermittelt. Damit ist für das Unternehmen eine erste Einschätzung möglich. Anschließend wird das unternehmensindividuelle Nutzenpotenzial mit Hilfe der CSC für jede Unternehmensperspektive ermittelt. Die identifizierten Schwachstellen stellen dabei das vorhandene Nutzenpotenzial dar, das durch die Umsetzung der Verbesserungsmaßnahmen realisiert wird. Erst auf dieser unternehmensindividuellen Grundlage ist eine betriebswirtschaftliche Bewertung für ein Unternehmen sinnvoll. Aus diesem Grund wird eine Wirtschaftlichkeitsberechnung nach der ersten Bewertung der anderen Unternehmensperspektiven empfohlen, da sich nur dann unternehmensspezifische und seriöse Aussagen über mögliche Verbesserungen durch ein PDMS treffen lassen. Die betriebswirtschaftliche Bewertung selbst geschieht mit Hilfe des gewählten SOLL-Szenarios und des darauf aufbauenden Business Case. 8.2.1 Definition und Aufbau eines Business Case Nach [Schmidt 2002] ist ein Business Case wie folgt definiert: Der Business Case ist ein Hilfsmittel zur Entscheidungsfindung und Planung, das erwartete finanzielle Ergebnisse und darüber hinausgehende Auswirkungen auf das Unternehmen vorhersagt [Übersetzung durch die Autoren]. Der Business Case berücksichtigt neben den geforderten finanziellen Aspekten auch Auswirkungen, die sich aufgrund der Zusammenhänge zwischen den einzelnen Unternehmensperspektiven ergeben. Er erfüllt somit die wesentliche Forderung der CSC nach einer ganzheitlichen Betrachtung. Somit ist der Business Case als Grundlage für eine Wirtschaftlichkeitsbetrachtung geeignet. Er dient als Entscheidungsunterstützung und Kontrollinstrument für das Top-Management.

8.2

Nutzenerhebung mit Hilfe des Business Case

251

Aus diesem Grund beginnt der Business Case mit einer Zusammenfassung der Ergebnisse für das Management (Executive Summary). Anschließend werden folgende Schwerpunkte behandelt [Schmidt 2002]: x Inhalt und Zweck: Der Zweck und der Rahmen des betrachteten Business Case müssen klar und eindeutig beschrieben sein. Dies betrifft nicht nur den Inhalt, sondern auch die betrachteten Kostenarten und Nutzenpotenziale einschließlich des definierten Betrachtungszeitraums. x Unternehmensauswirkungen: Sämtliche erwarteten finanziellen und nicht-finanziellen Auswirkungen durch die PDMS-Einführung werden beschrieben. Dies geschieht auf der Grundlage des unternehmensindividuellen SOLL-Szenarios und der CSC-Bewertung. Nur dadurch können zeitlichen Entwicklungen verfolgt und strategische Maßnahmen wie Kostenreduzierung oder Zielanpassungen durch das Management durchgeführt werden. x Annahmen und angewendete Verfahren: Um diese Entwicklung für das Top-Management nachvollziehbar zu machen, müssen die Annahmen zur Ermittlung der Kennzahlen sowie ihre angewendeten betriebswirtschaftlichen Verfahren dokumentiert sein. x Sensitivitäts-, Risiko- und Wahrscheinlichkeitsanalyse: Es wird gezeigt, wie die gewonnenen Ergebnisse mit den getroffenen Annahmen zusammenhängen. Ebenfalls wird analysiert, unter welchen Umständen und mit welcher Wahrscheinlichkeit von den erwarteten Ergebnissen abgewichen wird. Die Wahrscheinlichkeit dient als Grundlage zur Ermittlung des finanziellen Perspektivenreifegrads. x Abschließende Empfehlungen: Die Ergebnisse des Business Case werden zusammengefasst, der ermittelte Reifegrad dokumentiert und Handlungsempfehlungen abgeleitet. Dies betrifft bspw. die Wahl des geeigneten Szenarios ebenso wie die Umsetzung geeigneter Verbesserungsmaßnahmen aufgrund der CSC-Bewertung. Ähnlich wie bei der CSC ist jedoch von Nachteil, dass einige Inhalte des Business Case entweder rückblickend oder vorhersagend bspw. aufgrund finanzieller Entwicklungen der letzten Geschäftsjahre getroffen werden müssen. Sie besitzen einen retrospektiven oder prospektiven Charakter. Die einzelnen Arbeitsschritte der in Abb. 8-3 gezeigten Vorgehensweise unterstützen die Erstellung des Business Cases hinsichtlich seines Aufbaus. Dabei greifen sie auch auf die Projektdokumentation zurück, die während der Systemeinführung angelegt wurde (siehe Kap. 6). Von besonderer Bedeutung sind hierbei die Unternehmensauswirkungen. Sie dürfen nicht nur ausschließlich über finanzielle Vorgehensweisen

252

8 Wirtschaftlichkeitsbetrachtung

und Kennzahlen erfasst werden, sondern müssen auch die CSC-Reifegrade der einzelnen Unternehmensperspektiven berücksichtigen. Die Unternehmensauswirkungen und die angewendeten betriebswirtschaftlichen Verfahren einschließlich der verwendeten Kennzahlen bilden einen Bestandteil des in Kap. 9 beschriebenen Fallbeispiels. 8.2.2 Allgemeine Nutzenpotenziale Durch den Einsatz eines PDMS erwarten Unternehmen deutliche Verbesserungen hinsichtlich der Faktoren Zeit, Qualität und Kosten. Im Einzelnen bedeutet dies x einen hohen Wiederverwendungsgrad von Bauteilen mit Hilfe von Standardisierung, Modularisierung und Baukästen, insbesondere unter Aspekten des hohen Zeit- und Kostendrucks; x die Reduzierung der kostenintensiven Änderungen nach dem Start of Production (SOP) durch eine frühzeitige Fehleridentifikation und Produktverbesserung in den frühen Phasen des Produktlebenszyklus; x eine Verbesserung der (standortübergreifenden) Zusammenarbeit durch definierte Prozesse und Prozessverantwortlichkeiten; x Zeitvorteile durch hohe konsistente sowie aktuelle Datenverfügbarkeit; x die Erhöhung des zeitlichen Anteils an wertschöpfenden EngineeringTätigkeiten zur Schaffung von Innovationen; x die Erhöhung der Durchgängigkeit von Prozessen und Kommunikation auf der Grundlage kontrollierter D&I-Flüsse; x Reduktion von Medien- und Informationsbrüchen aufgrund heterogener IT-Systeme, informeller Prozesse und unterschiedlichen Mitarbeiterwissens, insbesondere zwischen den Bereichen Entwicklung - Produktion, Entwicklung - Vertrieb/Service sowie ebenfalls zwischen den am PEP beteiligten einzelnen Abteilungen; x … Das aufgelistete allgemeine Nutzenpotenzial stellt lediglich einen Ausschnitt dar; weitere Nutzen sind bspw. in [Schöttner 1999; Schabacker; McGrath 2004; Schabacker 2004; Abramovici 2004; Schuh 2005; Stark 2006; VDI2219] aufgeführt. Eine Nutzenquantifizierung ist jedoch problematisch. Sie basiert zumeist auf Erfahrungswerten, Literaturangaben oder Studien. So sind in Tabelle. 8-1 ausgewählte Nutzenpotenziale und ihre erwarteten Nutzenrenditen auf der Basis durchgeführter Industrieprojekte aus unterschiedlichen Branchen aufgeführt [Schabacker 2004]. Unter der beschriebenen „Nutzenrendite“

8.2

Nutzenerhebung mit Hilfe des Business Case

253

wird hierbei das Verhältnis zwischen dem Nutzengewinn für das Unternehmen und dem eingebrachten Aufwand verstanden. Damit entspricht die Nutzenrendite der Wirtschaftlichkeit eines PDMS-Projekts. Tabelle 8-1 Ausgewählte Nutzen und erwartete Nutzenrendite für PDM-Systeme [Schabacker 2004] ausgewählte Nutzenpotenziale

erwartete Nutzenrendite

systematische Erfassung der Informationen über vorhandene Produkte

20%-30%

Standardisierung der Produktdaten

15%-25%

parametrisierte Produktdaten in einer Produktdatenbank

20%-30%

systematische Eingabe der Kunden- und Marktinformationen

15%-27%

Vermeidung redundanter Erfassung von Produktdaten in der Produktentwicklung

10%-25%

Vermeidung redundanter Erfassung von Produktdaten in ERP-Systemen

25%-30%

Eingabe Produkt-/Fragestatus

05%-12%

standardisiertes Reporting zu Produkten, Prozessen und Projekten

10%-15%

Belieferung operativer Vertriebssysteme mit Produktdaten

25%-40%

Reduktion und Beherrschung der Produktkomplexität

20%-40%

Transparenz und Nachhaltigkeit im Produktportfolio

12%-17%

Wissensmanagement für alle Produkte

33%-74%

Abbildung 8-4 zeigt prozentuale Werte, die bei Industrieunternehmen durch die Umsetzung von PLM erreicht werden konnten [Abramovici 2004]. Dabei werden als „PLM-Fortgeschrittene“ diejenigen Unternehmen bezeichnet, die die PLM-Strategie bereits seit mehreren Jahren in ihrem Unternehmen erfolgreich umsetzen; das PDMS befindet sich in seiner Betriebsphase. „PLM-Nachzügler“ stehen am Beginn der Systemeinführung bzw. nach erfolgreicher Einführung am Anfang der Betriebsphase. Dies erklärt auch die hohen prozentualen Anteile der PLM-Nachzügler in den Bereichen „Wiederverwendung von Daten“, „Datenflüsse“ und

254

8 Wirtschaftlichkeitsbetrachtung

„Kommunikation“: In diesen Bereichen zeigt sich die Effizienz eines eingeführten PDMS am schnellsten (siehe auch Abschn. 8.1). Die PLMfortgeschrittenen Unternehmen haben ihre Altsysteme bereits integriert und greifen auf eine vollständig migrierte (Alt-)Datenbasis zurück. Daraus resultiert die hohe Informationsdurchgängigkeit der D&I-Flüsse mit den Vorteilen der Standardisierung sowie der einhergehenden Datenkonsistenz im Produkt- und Prozessbereich. Die Produktdaten werden abteilungsübergreifend entlang des gesamten Produktlebenszyklus genutzt.

Abb. 8-4 Real erreichter Nutzen durch die Umsetzung von PLM [Abramovici 2004]

Die angegebenen Zahlenwerte sollen ausschließlich eine erste Orientierung für das mögliche Nutzenpotenzial geben. Die Erfahrung zeigt jedoch, dass diese Werte innerhalb eines PDMS-Projekts erreicht werden können. In Abhängigkeit der Unternehmensbranche oder der formulierten Zielsetzungen sind Nutzenpotenziale teilweise schwer abschätzbar; dies macht eine Aussage hinsichtlich ihres Beitrags zur Wirtschaftlichkeit des PDMSProjekts schwierig. 8.2.3 Unternehmensindividuelle Nutzenpotenziale Anhand der strategischen und operativen Ziele haben Unternehmen als Ergebnis des ersten Arbeitsschritts ihre Erwartungen an eine PDMSEinführung festgelegt. Im zweiten Arbeitsschritt wurde ein allgemeines Umsetzungsszenario ausgewählt, welches der gewünschten PDMSEinführung am ähnlichsten war (siehe Abschn. 6.4.2). Die unternehmensspezifische Individualisierung des Umsetzungsszenarios findet durch die Zuordnung der definierten Ziele des ersten Arbeitsschritts statt.

8.3

Monetäre Erhebung des Nutzens

255

Bei der Bestimmung der qualitativen PDMS-Fähigkeit wird jedes Ziel der entsprechenden CSC-Unternehmensperspektive zugeordnet. Die einzelnen Ziele beschreiben den erwarteten Nutzen, den das Unternehmen für jede Perspektive erreichen möchte. Dies kann die Erhöhung von Teilewiederverwendung auf Produktebene oder eine Reduzierung der Prozessdurchlaufzeit sein. Durch die Zielzuordnung wird das ausgewählte Szenario an die unternehmensindividuellen Bedürfnisse angepasst. Das unternehmensindividuelle SOLL-Szenario beschreibt denjenigen Zustand, welchen das Unternehmen nach der PDMS-Einführung erreichen möchte. Werden die zugeordneten Ziele für jede Unternehmensperspektive erreicht, stellt dies die Realisierung des vorhandenen Nutzenpotenzials dar. Anderenfalls findet eine Anpassung der Ziele statt, wie in Abb. 8-5 gezeigt ist.

Abb. 8-5 Ermittlung des unternehmensindividuellen SOLL-Szenarios

Für eine betriebswirtschaftliche Aussage muss das Szenario durch die Erfassung der verursachten Kosten konkretisiert werden - aus dem gewählten SOLL-Szenario entwickelt sich der Business Case.

8.3 Monetäre Erhebung des Nutzens Erfahrungen aus der Praxis haben gezeigt, dass sich „klassische“ Wirtschaftlichkeitsbetrachtungen bei einer PDMS-Einführung als nur bedingt sinnvoll erwiesen haben. Der Grund liegt v. a. darin, dass bei einer PDMSystemeinführung monetär messbare und monetär nicht messbare Nutzenpotenziale betrachtet werden müssen [Schöttner 1999; Höfener 1999; Eigner u. Stelzer 2001; VDI2219]. Exemplarische Beispiele für diese Nutzenpotenziale sind in Abb. 8-6 dargestellt [in Anlehnung an die VDI-Richtlinie 2219].

256

8 Wirtschaftlichkeitsbetrachtung

Da ein PDMS innerhalb des Technischen Bereichs eingeführt wird, werden diesem Bereich auch die Kosten zugeordnet. Viele bedeutsame und wertschöpfende Auswirkungen aufgrund der PDMS-Einführung sowie des folgenden PDMS-Betriebs werden jedoch in anderen Abteilungen sichtbar. Aus diesem Grund ist eine reale Kosten-Nutzen-Analyse im Unternehmen diffizil - die Kosten werden einer Abteilung zugeordnet, obwohl ein erheblicher Anteil des erzeugten Nutzens abteilungsübergreifend erzeugt wird [VDI2219]. Auftretende Kosten und Kostenarten im Zusammenhang mit dem PDMS-Projekt und der anschließenden System-Produktivphase werden in Abschn. 8.4 behandelt.

Abb. 8-6 Nutzenpotenziale von PLM unter Berücksichtigung der Quantifizierbarkeit und ihre Berücksichtigung durch die PDMS-Einflussgrößen [in Anlehnung an VDI2219]

Monetär messbares Nutzenpotenzial kann bspw. durch die Messung von Werkzeug- und Maschinenauslastung erfolgen. Auf strategischer Ebene kann eine Änderung des Marktanteils oder des Unternehmensgewinns ermittelt werden. Derartige Ermittlungen werden durch spezielle Verfahren gewonnen, die häufig rechnerunterstützt und automatisiert ablaufen. Die gewonnenen Daten können unmittelbar direkten Kosten im Unternehmen zugeordnet werden.

8.3

Monetäre Erhebung des Nutzens

257

Nutzenpotenzial, welches monetär nicht messbar, jedoch quantifizierbar ist, kann im Rahmen der PDMS-Fähigkeitsermittlung ebenfalls kostenmäßig erfasst werden. Der Ermittlungsaufwand ist jedoch deutlich höher – bspw. kann eine Ermittlung der Durchlaufzeitverkürzung nur mittels einer persönlichen Messung durch einen Prozesscontroller mit der Stoppuhr erfolgen, wenn die Ergebnisse aussagekräftig sein sollen. So konnte bei PDMS-Projekten, für welche die Autoren verantwortlich waren, eine Verkürzung der Durchlaufzeit in einem Beispielprozess bis zu 40% erreicht werden. Bei einer anteiligen Zuordnung der Gesamtprozesskosten zu jedem Prozessschritt lassen sich bspw. mit Hilfe der Prozesskostenrechnung die einzelnen Kostenanteile ermitteln [Schuh 2005]. Der hohe notwendige Aufwand für sämtliche relevanten Prozesse zur Ermittlung des PDMS-Mehrwerts ist leicht vorstellbar. Deshalb werden üblicherweise in der Praxis diese Potenziale entweder mit einer hohen Unsicherheit abgeschätzt oder als überschlagene indirekte Kosten den unternehmerischen Gesamtkosten zugeordnet. Gerade in der PDMSEinführungsphase ist jedoch die Durchführung von Aktivitäten zur Erfassung des quantifizierbaren Nutzens empfehlenswert, da an dieser Stelle besonders das abteilungsübergreifende Potenzial erfasst und in einer monetären Form ausgedrückt werden kann. So besitzt der Nutzenfaktor „weniger Produktänderungen“ offensichtliche Auswirkungen auf die Fertigung, die ihrerseits eine deutlich verlässlichere Planung aufstellen kann. Folglich lassen sich anscheinend „monetär nicht messbare“ Faktoren wie weniger Kundenreklamationen oder Durchlaufzeitverkürzung durchaus erfassen, um gerade in der sensiblen Einführungsphase das Nutzenpotenzial für das gesamte Unternehmen auch unter finanziellen Gesichtspunkten darzustellen. Beide Nutzenarten können den PDMS-Einflussgrößen zugeordnet werden und lassen sich mittels der Capability Scorecard bewerten. Das monetär nicht messbare und nicht quantifizierbare Nutzenpotenzial (vgl. Abb. 8-6) stellt mögliche Verbesserungsmaßnahmen dar, deren Umsetzung eine Steigerung der PDMS-Fähigkeit zur Folge haben. Je nach durchgeführter Maßnahme können die einzelnen Perspektiven-Reifegrade gezielt beeinflusst werden. Dies wird anhand der CSC-Bewertungskriterien überprüft. Die Verbesserungsmaßnahmen selbst können monetär nicht bewertet werden. Dies ist ausschließlich für ihre Ergebnisse möglich, deren Auswirkungen sich anhand der CSC-Bewertungskriterien ermitteln lassen. Bei einem ungenügenden Ergebnis werden erneute Verbesserungsmaßnahmen durchgeführt: Der PDMS-Regelkreis, der in Kap. 5 beschrieben wurde, ist geschlossen (in Abb. 8-6 im unteren Bereich dargestellt).

258

8 Wirtschaftlichkeitsbetrachtung

Für eine monetäre Erfassung des Nutzenpotenzials hat sich ihre Operationalisierung auf die Zielgrößen Zeit, Qualität und Kosten bewährt [Kletti 2006]. Dadurch können die einzelnen Potenziale messbar gemacht werden. Da sich auch die Bewertungskriterien der einzelnen CSCUnternehmensperspektiven diesen Zielgrößen zuordnen lassen, bilden sie einen geeigneten Ausgangspunkt für eine monetäre Nutzenerfassung. Zeit- und Kostenkomponenten sind direkt messbar, wogegen die Qualität über den Weg für die Behebung der Folgen von „Nicht-Qualität“ notwendigen Aktivitäten wie Rückrufaktionen bei fehlerhaften Produkten etc. bewertet werden kann. Diese Aktivitäten können wiederum als Zeit- und Kostenanteile ausgedrückt werden. Zwingend für die Erfassung des Nutzenpotenzials ist eine genaue Zieldefinition: Um wie viel Prozent soll die Durchlaufzeit eines Prozesses reduziert werden? Was soll unter einer „höheren Produktqualität“ genau verstanden werden? So kann sich eine höhere Produktqualität nicht nur auf eine geringere Ausfallquote eines Produkts beziehen, sondern auch auf die Verfügbarkeit von Ersatzteilen hinsichtlich bereits verkaufter und vom Kunden eingesetzter Produkte. Besonders bedeutsam ist dieser Aspekt bspw. bei der eingesetzten Softwareversion mechatronischer Produkte, die genau zu einer speziellen Produktversion einer bestimmten Serie kompatibel sein muss. Erschwerend kommt hinzu, dass diese Produkte bereits im Kundeneinsatz sind und die Zuordnung dennoch eindeutig möglich sein muss.

8.4 Ermittlung der Kosten Die Einführung und der Betrieb eines PDMS stellt für jedes Unternehmen eine große Herausforderung dar und ist mit erheblichem finanziellem Aufwand verbunden. Wie bereits in Abschn. 6.2.3 ausgeführt wurde, entstehen bereits in der Einführungsphase enorme Kosten hinsichtlich Software, Hardware oder Consultingaufwendungen. Während der Betriebsphase müssen zusätzlich noch die laufenden Kosten berücksichtigt werden, die das System selbst und für jede Unternehmensperspektive erzeugt. Hierzu zählen neben Kosten für System-Updates oder Wartung auch Kosten für Mitarbeiterschulungen oder eine ständige Aktualisierung der Produktdaten- oder Prozessmodelle. Die Schwierigkeit liegt insbesondere in der Erfassung und Berücksichtigung von „versteckten“ Kosten innerhalb der Wirtschaftlichkeitsbetrachtung. Werden diese nicht genügend berücksichtigt, können sie ein PDMSProjekt zum Scheitern verurteilen.

8.4

Ermittlung der Kosten

259

In Abb. 8-7 ist die allgemeine Aufteilung von Kostenarten innerhalb eines PDMS-Projekts schematisch dargestellt. Die Projektkosten setzen sich aus den Kosten für die einzelnen Ressourcen zusammen; dabei handelt es sich um Personal- und Sachkosten. Sie können den beiden Kostenarten einmalige Kosten und laufende Kosten auf der Ausgabenseite zugeordnet werden. Dem gegenüber stehen die Einsparungskosten, die sich aus der Umsetzung des beschriebenen Nutzenpotenzials für das Unternehmen ergeben [Arnold et al. 2005].

Abb. 8-7 Kostenarten bei der PDMS-Einführung und Betriebsphase

Einmalige Kosten setzen sich aus den Kosten des PDMS-Projekts, seinen benötigten Ressourcen und des PDM-Systems zusammen. Sie werden üblicherweise über eine Nutzungsdauer von 3 Jahren abgeschrieben und können einzelnen Einführungsphasen bzw. Arbeitsschritten und/oder Funktionen im Unternehmen zugeordnet werden. Die einmaligen Kosten beinhalten x Planungskosten für die Durchführung der PDMS-Einführung einschließlich der IST-Analyse, der SOLL-Konzeption und der Modellerstellung; x Systembeschaffungskosten, die sich aus den Anteilen der Software und der benötigten Hardware bzw. deren Aktualisierung zusammensetzt; x Systemeinführungskosten, mit denen v. a. die Kosten für und während der Pilotphase gemeint sind; x …

260

8 Wirtschaftlichkeitsbetrachtung

Laufende Kosten beinhalten sämtliche Kostenfaktoren, die über den gesamten Lebenszyklus, d. h. die gesamte Einsatzdauer des PDMS, anfallen. Sie werden ihrer Entstehungsursache zuzuordnen versucht. Zu den laufenden Kosten zählen x Direkte Betriebskosten für Personal oder benötigtes Material wie Updates, Upgrades etc.; x Indirekte Betriebskosten, die für Wartung der Hard- und Software, für die Durchführung von Mitarbeiterschulungen oder für Anpassungsmaßnahmen der Prozesse, der Organisation oder des Systems (Customizing) anfallen. Auch Leasingkosten für Hard- und Software werden den indirekten Betriebskosten zugerechnet; x … Diese Kosten-Betrachtungsweise ist für die Systembetriebsphase ebenfalls anwendbar, auch wenn dies explizit nicht erwähnt wird. Als einmalige Kosten werden in dieser Phase bspw. notwendige Erweiterungen bei Hardund Software durch eine Erhöhung der Systemnutzeranzahl verbucht. Den aufgeführten Kosten für Ausgaben stehen Einsparungskosten gegenüber, die sich aus den unternehmensindividuellen Nutzenpotenzialen ergeben. Sie werden häufig nicht oder nicht ausreichend berücksichtigt, da sie sich teilweise nicht exakt beziffern lassen. Dennoch liegt gerade in diesen unscharfen Nutzenpotenzialen oftmals der höchste Mehrwert für Unternehmen. Dies wird besonders deutlich, wenn zwischen strategischem Nutzen und nicht-strategischem Nutzen unterschieden wird [Arnold et al. 2005]: x Unter strategischem Nutzen wird eine Verbesserung der Wechselwirkung zwischen dem Unternehmen und seiner Marktposition oder zu seinen Wettbewerbern verstanden. x Der nicht-strategische Nutzen beschreibt die Verbesserung der innerbetrieblichen Faktoren Zeit, Qualität oder Kosten hinsichtlich der einzelnen CSC-Unternehmensperspektiven. Die Nutzenpotenziale und die Möglichkeiten ihrer monetären Erfassung wurden in den vorherigen Abschnitten beschrieben. Diejenigen Kosten, die sich während des PDMS-Projekts und der anschließenden Betriebsphase ergeben, sind in Abb. 8-8 gezeigt. Nicht berücksichtigt sind dabei die Kosten, die während der unternehmensinternen Vorklärungsphase anfallen. Da in dieser Phase das PDMS-Projekt oft informell zwischen wenigen Projekttreibern angedacht und diskutiert wird, besitzen die Kosten einen geringen Umfang (siehe Abschn. 6.2.3). Deshalb werden sie an dieser Stelle vernachlässigt.

8.4

Ermittlung der Kosten

261

Abb. 8-8 Durchschnittliche Zusammensetzung der Kosten während des PDMSProjekts und der anschließenden Betriebsphase für einen dreijährigen Betrachtungszeitraum

Die Initialkosten umfassen das eigentliche PDMS-Projekt. Die größten Kostenfaktoren sind neben den Beschaffungskosten für Hard- und Software die Kosten für die unternehmensspezifische Systemanpassung. Dies beinhaltet die Systemanbindung in die vorhandene IT-Landschaft ebenso wie die Erstellung unternehmensindividuell gewünschter Funktionalitäten, die nicht im Standardumfang des PDMS enthalten sind. Weiterhin ist die Implementierung der jeweiligen Produkt-, Prozess- und Rollenmodelle enthalten. Zusätzlich sind die Personalkosten für die Einführung zu berücksichtigen. Dabei handelt es sich konkret um externe Berater und Mitglieder des Projektteams, die für das Tagesgeschäft nicht zur Verfügung stehen. Die Betriebskosten sind für einen Zeitraum von drei Jahren nach Abschluss des PDMS-Projekts dargestellt. Dieser Zeitraum ist ausreichend, damit die Mitarbeiter geschult und genügend Erfahrungen im Umgang mit dem PDMS sammeln können, so dass die Nutzenpotenziale in vollem Umfang sichtbar werden. Selbstverständlich schließt dies neben der Systempflege auch die Pflege der Modelle mit ein. Ein ebenfalls zu berücksichtigender Kostenfaktor ist der Erwerb einer zusätzlichen Lizenzanzahl für

262

8 Wirtschaftlichkeitsbetrachtung

den Vertrieb oder die Produktion, um das System abteilungsübergreifend nutzen zu können. In Abb. 8-9 sind die Ergebnisse einer Befragung gezeigt, die bei Unternehmen hinsichtlich der Kostenverteilung bei der Umsetzung von PLM durchgeführt wurde [Abramovici 2004].

Abb. 8-9 Verteilung der wichtigsten Kostenfaktoren bei der Umsetzung der PLMStrategie [Abramovici 2004]

Die Verteilung der Kosten entspricht bei den „PLM-Nachzüglern“ den vorgestellten Ausführungen (vgl. Abschn. 6.2.3). Erkennbar ist auch, wie sich mit zunehmender Erfahrung der Unternehmen die Kosten hinsichtlich der einzelnen Aktivitäten verlagern: So reduzieren sich die Kosten für die Mitabreiterschulungen und das Projektmanagement bei einem laufenden System ohne einen erkennbaren Verlust der Mitarbeiterqualifikation. Dies kann als Zeichen gewertet werden, dass die PLM-Strategie im Unternehmen gelebt und das PDMS als zentrale Daten- und Informationsbasis genutzt wird. Neben der kontinuierlichen Aktualisierung von Hard- und Software investieren erfahrene Unternehmen am meisten in die Implementierung. Die Implementierungskosten umfassen neben einer ständigen Systempflege an die vorhandene IT-Landschaft auch die Modellerstellungs- und Modellimplementierungskosten.

8.5 Bewertung der Wirtschaftlichkeit In diesem Abschnitt werden einige exemplarische Ansätze und Kennzahlen, deren Anwendung sich in der Praxis trotz der unscharfen Faktoren für

8.5

Bewertung der Wirtschaftlichkeit

263

eine Wirtschaftlichkeitsberechnung von Softwaresystemen durchgesetzt hat, betrachtet [Eigner u. Stelzer 2001; Brandt 2002; Schmidt 2002; Kütz 2003; Schoen 2005; Kletti 2007; Töpfer 2007; VDI 2219]. Falls die vorgestellten Verfahren und Kennzahlen für eine Bewertung nicht ausreichend sind, müssen sie im Business Case mit unternehmensspezifischen Kennzahlen ergänzt werden. Dabei handelt es sich um x die Ermittlung der Kosten nach dem Total Cost of Ownership-Prizip (TCO) sowie der Prozesskostenrechnung; x die Bewertung der Wirtschaftlichkeit anhand von Kennzahlen wie dem Return on Investment (RoI), der Amortisationsdauer, dem Net Present Value (auch als Kapitalwertmethode bezeichnet) und der Internal Rate of Return; x moderne Verfahren wie das Total Value of Opportunity (TVO) oder das Total Cost of Business Opportunity (TCBO). Da sich diese Verfahren in der Praxis bislang nur eingeschränkt durchsetzen konnten, wird auf sie nur kurz eingegangen. Mit Hilfe der CSC können die Eingangsfaktoren für diese Berechnungsverfahren bzw. Kennzahlen im Rahmen einer PDMS-Einführung präzisiert werden. Ein Anspruch auf eine vollständige Erfassung kann aufgrund der beschriebenen unterschiedlichen Nutzenarten nicht erhoben werden. 8.5.1 Das Prinzip des Total Cost of Ownership (TCO) Obwohl die Kosten für Hard- und Software gefallen sind, wurde in den Unternehmen ein stetiger Anstieg der IT-Kosten festgestellt. Der Grund liegt in heterogenen und komplexen IT-Strukturen, die auf die vorhandenen Organisationsstrukturen und ihre verbundenen Organisationskosten zurückgeführt werden können [Krcmar 2003; Schuh 2005; Kletti 2007]. Die Abbildung der Organisationsstrukturen sowie die sich daraus ergebenden Nachteile wie veraltete Systemstrukturen, unüberschaubare bzw. redundante Datenspeicherung oder ein unzureichendes Berechtigungskonzept für Mitarbeiter haben eine hohe Komplexität auf der Systemebene zur Folge (vgl. die Ausführungen zur Erfassung der IT-Landkarte in Abschn. 6.4.2). Eine hohe Komplexität macht sich in hohen laufenden Betriebskosten bemerkbar. Die laufenden Betriebskosten, die IT-Systeme während ihres gesamten Lebenszyklus verursachen, bilden folglich ein bedeutsames Kriterium bei der Systemauswahl.

264

8 Wirtschaftlichkeitsbetrachtung

Bei dem TCO-Ansatz (Total Cost of Ownership) handelt es sich um einen „Best-practice“-Ansatz für Unternehmen [Kletti 2007]. Mit seiner Hilfe sollen vor der Systemeinführung versteckte Kostentreiber identifiziert werden. Die Grundlage bei der PDMS-Einführung bilden die unterschiedlichen CSC-Aktivitätenmatrizen. Insbesondere das Prozess- und das Rollenmodell sind hierbei bedeutsam. Zur Ermittlung der Kostentreiber wird unterschieden in x direkte (budgetierbare) Kosten, die durch die Systembeschaffung und dessen Betrieb entstehen. Hierzu zählen Kostenarten wie Anschaffungsund Einführungskosten der Hard- und Software, Weiterentwicklungskosten oder Supportkosten; x indirekte (nicht budgetierbare) Kosten, die ihre Ursache in einer unproduktiven Nutzung durch die Systemnutzer haben. Dies betrifft neben veralteten Systemstrukturen auch Systemausfälle aufgrund verzögerter Problembehandlung bzw. ungeplanter Arbeitsunterbrechungen oder negative Produktivitätseffekte aufgrund schlechter Systemergonomie oder mangelnder Mitarbeiterqualifikation.

Abb. 8-10 Wichtige Kenngrößen des TCO-Verfahrens

In Abb. 8-10 sind die beschriebenen Zusammenhänge dargestellt. Besonders bedeutsam ist die Betrachtung der Kostentreiber, die in strategische und operative Kostentreiber unterschieden werden können. Strategische Kostentreiber betrachten bspw. die Anzahl vorhandener Unternehmensstandorte oder die Durchführungsplanung von Mitarbeiter-

8.5

Bewertung der Wirtschaftlichkeit

265

schulungen. Operative Kostentreiber beinhalten die vorhandene Organisationsstruktur oder die Anzahl der Produkte. Diese Kostentreiber können durch die Analyse der jeweiligen Unternehmensperspektive mittels der CSC erfasst werden. Dies gilt auch für die zugehörigen strategischen und operativen Ziele. Die TCO-Vorgehensweise soll idealerweise in ein umfassendes Kostenmanagementkonzept integriert sein. Hier ist besonders die Vereinbarung von Service Level Agreements (SLA's) vor der Systemeinführung zu berücksichtigen: Sie definieren die Qualität, den Umfang und die Preise für benötigte PDMS-Dienstleistungen. Dadurch werden einige wesentliche Kostentreiber für das Unternehmen vor der Betriebsphase des PDMS erfassbar. 8.5.2 Die Prozesskostenrechnung Wie bereits in den vorherigen Ausführungen beschrieben wurde, laufen die durch eine PDMS-Einführung beeinflussten Prozesse in der Regel abteilungs- und somit kostenstellenübergreifend ab. Diese Problematik soll mit Hilfe der Prozesskostenrechnung gelöst werden. Hierfür werden Kosten in indirekten Leistungsbereichen (im Gegensatz zu den direkten Kosten) wie Qualifizierung oder Prozessmanagement bestimmt und auf einzelne Kostenträger bzw. -erzeuger verrechnet. Durch die Schaffung einer erhöhten Kostentransparenz wird die Identifikation von Einsparpotenzial unterstützt. Die Vorgehensweise bei der Durchführung der Prozesskostenrechnung [Schuh 2005; Kletti 2007] wird durch die Anwendung der CSC auf die PDMS-Einführung erweitert und ist in Abb. 8-11 dargestellt. Gemäß der Natur des Verfahrens liegt hierbei der Schwerpunkt auf der Unternehmensperspektive „Prozess“; es werden auch die Perspektiven „Organisation“ und „Produkt“ berücksichtigt. Die Vorgehensweise unterteilt sich in fünf Schritte: x Im Vorgehensschritt a werden die Prozesstätigkeiten analysiert. Dies geschieht auf der im zweiten Arbeitsschritt durchgeführten ISTAnalyse. Anschließend wird der gewünschte SOLL-Zustand des betrachteten Prozesses definiert. Eine sinnvolle Grundlage hierfür bildet das SOLL-Szenario der PDMS-Einführung. Möglicherweise muss das SOLL-Szenario für den betrachteten Prozess in seiner Ausführung verfeinert werden, bis es für die Prozesskostenrechnung geeignet ist. x Die Wahl der Bezugsgrößen für die Prozesskostenrechnung geschieht in Schritt b. Hierfür können die CSC-Bewertungskriterien herangezogen

266

8 Wirtschaftlichkeitsbetrachtung

werden. Die Bezugsgrößen bilden den augenblicklichen IST-Zustand ab. x Die Festlegung der Plangrößen geschieht in Schritt c. Hierfür werden die Ergebnisse aus den Arbeitsschritten 1 und 2 der Systemeinführung genutzt. Wichtig ist die Festlegung der Messgrößen; sie kann nur anhand einer eindeutigen Zieldefinition wie „Verbesserung der Durchlaufzeit um 40% des aktuellen Wertes“ geschehen. Die Messgröße stellt in diesem Beispiel die Durchlaufzeit dar; die Plangröße ist deren Reduzierung um 40%. x In Schritt d werden diejenigen Kosten der indirekten Leistungsbereiche bestimmt, die einen Einfluss auf die Erreichung der Plangrößen aus Schritt d besitzen. So kann bspw. aufgrund einer mangelnden Mitarbeiterqualifikation einen Reduzierung der Durchlaufzeit nicht erreicht werden. Entsprechend muss in ein Schulungsprogramm investiert werden, für das entsprechende Kosten anfallen. Auf diese Weise können wesentliche Kostentreiber identifiziert werden. x Im letzten Schritt e werden die Prozesskostensätze für die einzelnen Prozesstätigkeiten ermittelt.

Abb. 8-11 Vorgehensweise bei der Durchführung einer Prozesskostenrechnung (in Anlehnung an [Kletti 2007])

8.5

Bewertung der Wirtschaftlichkeit

267

Die Prozesskostenrechnung stellt ein Kostenvergleichsverfahren zwischen einem bestehenden IST-Zustand und einem gewünschten SOLL-Zustand dar, wie dies bei der Einführung eines PDMS gegenüber den bestehenden IT-Altsystemen der Fall ist. Die Differenz zeigt das vorhandene theoretische Einsparpotenzial auf. 8.5.3 Exemplarische Kennzahlen der Investitionsbewertung In der betriebswirtschaftlichen Literatur existiert eine Vielzahl von Kennzahlen zur Bewertung von Investitionen. Die für eine PDMS-Einführung wichtigsten Kennzahlen werden nachfolgend kurz erläutert; für ein tiefer gehendes Verständnis sei auf die entsprechende Fachliteratur verwiesen. Dies gilt auch, falls die vorgestellten Kennzahlen die Anforderungen durch das unternehmensinterne Controlling bzw. Finanzwesen nicht abdecken. Eine Investition ist typischerweise durch eine Basisinvestition in Form eines bestimmten finanziellen Betrags, einer geplanten Nutzungsdauer sowie periodische Erträge charakterisiert. Zur Abschätzung der Vorteilhaftigkeit einer Investition eignet sich zunächst die Ermittlung des Kapitalwerts (auch Barwert oder Net Present Value NPV). Damit können durch Diskontierung der Erträge unterschiedliche IT-Projekte auf den heutigen Zeitpunkt miteinander verglichen werden. Die einzelnen Verfahren zur Werteermittlung sollen an dieser Stelle nicht vertieft werden; um einen praxistauglichen Ansatz herzustellen, wird nachfolgend das Kapitelwertkonzept auf die Berechnung unter Sicherheit beschränkt. Der Kapitalwert wird durch die Diskontierung zukünftiger Einkünfte Zt, d. h. Einsparungen minus Ausgaben in der betrachteten Zeitperiode, ermittelt (Abb. 8-12): T

NPV

I0 

Zt

¦ (1  i)

t

(8.1)

t 1

Dabei bezeichnet I0 die initiale Investitionsausgabe, die entweder den Kaufbetrag oder die Sonderzahlung (Leasing) im Jahr 0 beinhaltet. T stellt die geplante Nutzungsdauer (i.d.R. die Abschreibungsdauer) und t die aktuelle Periode dar.

268

8 Wirtschaftlichkeitsbetrachtung

Abb. 8-12 Kenngrößen zur Ermittlung des NPV

Der Return on Investment (RoI) ist die bekannteste Kennzahl zur Abschätzung der Vorteilhaftigkeit einer Investition. Durch seine Berechnung lässt sich die Rendite des investierten Kapitals ermitteln. Der RoI ist definiert als Quotient aus Periodengewinn und Kapitaleinsatz (Abb. 8-13): RoI

Gewinn ˜100 Kapitaleinsatz

(8.2)

Die Investition erweist sich als vorteilhaft, falls der errechnete RoI einen positiven Prozentualwert ergibt. Dieser Wert stellt eine Aussage über den betriebswirtschaftlichen Totalerfolg einer Investition zu einem bestimmten Zeitpunkt dar.

8.5

Bewertung der Wirtschaftlichkeit

269

Abb. 8-13 Kenngrößen zur Ermittlung des RoI

Mit Hilfe der Amortisationsrechnung lässt sich derjenige Zeitraum ermitteln, in welchem das investierte Kapital über die erwirtschafteten Erlöse wieder in das Unternehmen zurückfließt (Abb. 8-14): Amortisationsdauer

Kapitaleinsatz Periodenerfolg

(8.3)

Der Periodenerfolg setzt sich aus dem Nutzen sowie den entsprechenden Abschreibungen pro Zeitperiode zusammen.

270

8 Wirtschaftlichkeitsbetrachtung

Abb. 8-14 Kennzahlen zur Berechnung der Amortisationsdauer

Bei der Barwertsrentabilitätsmethode oder Methode des internen Zinsfusses (IRR) wird derjenige Zinssatz gesucht, bei dem der Kapitalwert (NPV) des Investitionsprojekts gleich Null ist. Er gibt die Rentabilität des eingesetzten Kapitals an und wird mit dem allgemeinen Kalkulationszinssatz verglichen: T

NPV

I0 

Zt

¦ (1  i)

t

0

(8.4)

t 1

Um den Kapitalwert des betrachteten Projekts zu errechnen, wird zunächst ein beliebiger Zinsfuss i1 als Anfangswert festgelegt. Falls der errechnete Wert NPV1 sich vom Wert Null unterscheidet, muss iterativ ein neuer Zinsfuss i2 festgelegt werden. Durch den Einsatz einer geeigneten Interpolationsformel kann der Näherungswert für den internen Zinsfuss rechnerunterstützt ermittelt werden. Falls der interne Zinssatz und der Kalkulationszinssatz identisch sind, wird die eingesetzte Investition wieder gewonnen und die Beträge genau zu diesem festgelegten Kalkulationszinssatz verzinst. Ist der interne Zinssatz höher als der Kalkulationszinssatz, ist die Investition vorteilhaft, da sich eine zusätzliche Verzinsung ergibt. Bei einem kleineren internen Zinssatz gegenüber dem Kalkulationszinssatz ist die Investition als unwirtschaftlich einzustufen, da nicht einmal die Mindestverzinsung des Kapitalzinssatzes erreicht wird.

8.5

Bewertung der Wirtschaftlichkeit

271

Je nach Interessenlage des Unternehmens können im Business-Case weitere Kennzahlen betrachtet werden. Dazu zählen bspw. der Cash-Flow, der EBIT oder die auf unterschiedliche Größen bezogene Rentabilität. Der Cash-Flow stellt eine wesentliche Bewertungsgröße hinsichtlich der Zahlungskraft eines Unternehmens dar und ermöglicht eine Beurteilung des augenblicklichen Finanzierungspotenzials. Je nach Definition und Bezugsgrößen wird zwischen unterschiedlichen Typen wie dem Brutto-, dem Netto- und dem Discounted Cash-Flow unterschieden. Der EBIT („earnings before interest und taxes“) ist eine Kennzahl, die den Unternehmensgewinn während eines definierten Zeitraums ausgibt. Sie beschreibt in der praktischen Anwendung den Gewinn vor Finanzergebnis, außerordentlichem Ergebnis und Steuern. Die Rentabilität oder Rendite drückt das Verhältnis des Erfolgs bzw. Gewinn zum aufgewendeten Mitteleinsatz aus. Sie ist immer auf einen definierten Zeitraum bezogen und entspricht der in Abschn. 8.1 definierten Wirtschaftlichkeit. In Abhängigkeit der betrachteten Bezugsgrößen kann zwischen der Eigenkapitalrentabilität, der Gesamtkapitalrentabilität und der Umsatzrentabilität unterschieden werden. Die sich ändernde Bezugsgröße ist der Mitteleinsatz: Während die Eigenkapitalrentabilität das eingebrachte Eigenkapital betrachtet, berücksichtigt die Gesamtrentabilität auch Fremdkapital von Banken. Die Umsatzrentabilität ergibt sich, wenn der Gewinn auf den Umsatz bezogen wird. 8.5.4 Moderne Verfahren der Investitionsberechnung

„Klassischen“ IT-Investitionsbewertungsverfahren ist gemein, dass sie ausschließlich betriebswirtschaftliche Aspekte bewerten. Wie bereits dargelegt, gibt es jedoch auch relevante Einflussgrößen, die sich schwer berücksichtigen lassen. Diese Lücke wollen das TVO-Verfahren (Total Value of Opportunity) und das TCBO-Verfahren (Total Cost of Business Opportunity) schließen. In Abb. 8-15 sind beide Verfahren inhaltlich gegenüber gestellt [Schoen 2005].

272

8 Wirtschaftlichkeitsbetrachtung

Abb. 8-15 Moderne Verfahren zur IT-Investitionsentscheidung [Schoen 2005]

Das TVO-Verfahren versucht eine Wahrscheinlichkeitsbewertung der Umsetzung eines IT-Projekts unter Berücksichtigung der vorhandenen Gegebenheiten im Unternehmen. Hierzu werden die Bereiche Unternehmensstrategie sowie IT-Landschaft betrachtet. Ziel ist eine Verbesserung bzw. Umstrukturierung der vorhandenen Geschäftsprozesse. Die Ergebnisse werden in der sog. TVO-Matrix dargestellt. Das Total Cost of Business Opportunity stellt eine Methode zur Kostenevaluation für die Erreichung von Geschäftszielen dar. Hierfür werden entsprechende Lösungen, die bereits entwickelt sein müssen, auf ihre Übereinstimmung mit gewünschten Unternehmensfunktionalitäten analysiert. Bei entsprechender Eignung werden sie anschließend bspw. auf ihre Integrationsfähigkeit in vorhandene Systeme bzw. Abläufe oder auf ihre Mitarbeiter- und Kundezufriedenheit bewertet. Die Ergebnisse werden in einer TCBO-Tabelle dokumentiert. Beide Verfahren versuchen die Erfassung des Nutzens und seine Berücksichtigung unter betriebswirtschaftlichen Aspekten. Nachteilig ist jedoch, dass sie in der industriellen Praxis nicht häufig genutzt werden. Zusätzlich stellen sie ihr Ergebnis entweder in Form einer Matrix oder in Form einer Tabelle dar; einfache Kennzahlen für einen schnellen Überblick fehlen. Dennoch bilden sie eine gute Grundlage zur Ableitung von Verbesserungsmaßnahmen und können als Ergänzung zur CSC herangezogen werden.

8.6

Bewertung der Unternehmensperspektive Finanzen

273

8.6 Bewertung der Unternehmensperspektive Finanzen Eine Investition in ein PDMS ist sinnvoll, falls die vorgestellten Kennzahlen als Bewertungskriterien einen durch das Management bestimmten Grenzwert erfüllen bzw. unterschreiten. Dabei wird angenommen, dass der Grad der Zielereichung in jeder Unternehmensperspektive direkte Auswirkungen auf die Kennzahlen besitzen (vgl. hierzu die Abhängigkeiten, wie sie in Abb. 8-2 dargestellt sind). Die einzelnen Grenzwerte sind stark von den jeweiligen Unternehmen, ihrer Größe, ihrer finanziellen Ertragslage, ihren mit der CSC ermittelten Voraussetzungen und ihrem Umsetzungswillen, getragen vom Management und den Mitarbeitern, abhängig. Deshalb ist eine allgemeine Aussage für die Grenzwerte nicht möglich. Ihre unternehmensindividuelle Definition bildet die Grundlage zur Ermittlung des Perspektiven-Reifegrads „Finanzen“. Die zugehörige Aktivitätenmatrix zeigt Abb. 8-16.

Abb. 8-16 Beispielhafte Aktivitätenmatrix für die Unternehmensperspektive „Finanzen“

Die Aktivitätenmatrix Finanzen besitzt folgende Inhalte: x In der Spalte „betrachteter Business-Case“ wird derjenige BusinessCase dokumentiert, welcher augenblicklich bewertet wird. Im gezeigten Beispiel basiert der betrachtete Business-Case auf dem SOLL-Szenario 3, dessen Umsetzung für die PDMS-Einführung vom Unternehmen im zweiten Arbeitsschritt ausgewählt wurde.

274

8 Wirtschaftlichkeitsbetrachtung

x Die zweite Spalte beinhaltet die betriebswirtschaftlichen Ziele, die durch das PDMS-Projekt erreicht werden sollen. Dies beinhaltet Ziele, die das PDMS-Projekt direkt betreffen wie seine Amortisierung in bspw. fünf Jahren oder einen gewünschten Mindest-RoI. Wichtig ist die Angabe konkreter, betriebswirtschaftlicher (Grenz-)Werte, die durch die Szenarienumsetzung erreicht bzw. erwartet werden. In diese Spalte können auch strategische betriebswirtschaftliche Ziele eingebracht werden wie Steigerung des EBIT um 30%. Auf diese Kennzahlen wird nicht weiter eingegangen. x Die zugehörigen Kennzahlen zur Zielüberprüfung sind in der dritten Spalte dokumentiert. Sie bilden die zugehörigen Bewertungskriterien. x Die vierte Spalte beinhaltet das Bewertungsergebnis. Wie bei allen anderen Unternehmensperspektiven sind der Perspektiven-Reifegrad in Form einer Zahl sowie die aus ihr abgeleitete Investitionsklasse angegeben. Die Investitionsklasse orientiert sich an Tabelle 8-2 und wird in die einzelnen Stufen „sehr empfehlenswert“, „empfehlenswert“, „empfehlenswert mit Einschränkungen“ und „nicht empfehlenswert“ eingeteilt. x Aufgrund der beschriebenen Zusammenhänge zwischen den einzelnen Unternehmensperspektiven wird angenommen, dass die durchgeführten Verbesserungsmaßnahmen die Werte der finanziellen Kennzahlen beeinflussen. Deshalb werden in der fünften Spalte „betrachtete Unternehmensperspektiven“ lediglich diejenigen Unternehmensperspektiven angegeben, von deren Verbesserung man sich die bedeutsamsten betriebswirtschaftlichen Auswirkungen erhofft. Die einzelnen Verbesserungsmaßnahmen sind in der jeweiligen perspektivenzugehörigen Aktivitätenmatrix beschrieben. Tabelle 8-2 Reifegradtabelle zur Durchführungsempfehlung eines PDMS-Projekts unter betriebswirtschaftlichen Gesichtpunkten in Anlehnung an Schulnoten FinanzReifegrad

Investitionsklassen: Die Durchführung des PDMS-Projekts ist…

1

…sehr empfehlenswert

2

…empfehlenswert

3

…empfehlenswert mit Einschränkungen

4

…nicht empfehlenswert

Falls die definierten Grenzwerte der Kennzahlen nicht erreicht werden oder sich als unzureichend erweisen, können sie durch Maßnahmen auf den anderen Unternehmensperspektiven beeinflusst werden. Bspw. beeinflusst eine Verbesserung vorhandener komplexer Produkt- oder Prozessstruktu-

8.6

Bewertung der Unternehmensperspektive Finanzen

275

ren (Steigerung der Prozesstransparenz; Verringerung der Durchlaufzeit; Prozess-Redefinition etc.) den RoI-Wert, da in diesen der Unternehmensgewinn einfließt. Effiziente Prozesse und einfache Produktstrukturen sind weniger kostenintensiv; der Unternehmensgewinn erhöht sich. Ähnliche Aussagen gelten auch für Maßnahmen im Bereich der Produkte, der Organisation und der IT-Landschaft. Die Spalte „Maßnahmen“ auf der AM Finanzen verweist folglich auf die einzelnen Unternehmensperspektiven. Dort sind die entsprechenden Verbesserungsaktivitäten detailliert dokumentiert. Ihre Umsetzung beeinflussen wiederum die betriebswirtschaftlichen Kennzahlen. Dieses UrsacheWirkungs-Prinzip kann für jede einzelnen Lebenszyklusphase erfasst werden und ist in Abb. 8-17 vereinfacht angedeutet. Damit ist eine betriebswirtschaftliche Erfassung der Auswirkungen in jeder einzelnen Lebenszyklusphase möglich. LC-Phase: Beseitigung LC-Phase: FinanzenNutzung Wirkung

Ursache LC-Phase: FinanzenEntwicklung+Produktion Produkt Ursache Wirkung Finanzen (Produktmodell) Wirkung Produkt Ursache Wirkung Ursache

(Produktmodell)

Prozess ProduktUrsache

Wirkung

(Prozessmodell) (Produktdatenmodell)

Wirkung

Ursache Prozess

Wirkung Ursache (Prozessmodell)

Organisation Wirkung Prozess Ursache (Rollenmodell) (Prozessmodell)

Organisation

Wirkung Ursache (Rollenmodell)

Organisation (Rollenmodell)

Abb. 8-17 Ursache-Wirkungs-Prinzip zur Beeinflussung der betriebswirtschaftlichen Kennzahlen in jeder Lebenszyklusphase (LC-Phase)

Übergeordnetes Ziel einer PDMS-Einführung ist für das Unternehmen die Unterstützung bei der Umsetzung ihrer strategischen Ziele wie die Erhöhung des Markterfolgs, der Rendite und/oder des Unternehmensgewinns. Dies soll durch die Erreichung der operativen Ziele auf den einzelnen Unternehmensperspektiven gewährleistet werden. Werden die operativen Ziele erreicht, beeinflusst dies auch den wirtschaftlichen Unternehmenserfolg; damit schließt sich der Kreis. Sowohl der strategische als auch der operative Zielerreichungsgrad können durch entsprechende Zielgrößen bestimmt werden. So lässt sich der Unternehmensgewinn in einem definierten Zeitraum mittels der strategi-

276

8 Wirtschaftlichkeitsbetrachtung

schen EBIT-Kennzahl messen. Der operative Zielereichungsgrad für jede Unternehmensperspektive wird durch den zugehörigen Perspektivenreifegrad bestimmt. Die entsprechenden Zusammenhänge wurden bereits in den vorherigen Ausführungen erläutert und sind in Abb. 8-18 dargestellt.

Abb. 8-18 Zielgrößen der einzelnen Unternehmensperspektiven und des wirtschaftlichen Unternehmenserfolgs

Nach [Abramovici 2004] konnten zwischen 60% und 80% der PLMfortgeschrittenen Unternehmen eine Amortisationsdauer von 3 Jahren erreichen. Dabei investierten PLM-fortgeschrittene Unternehmen mehr als die doppelte Summe im Vergleich zu „PLM-Nachzüglern“. Die Investitionshöhe bewegte sich zwischen einer und vier Millionen Euro jährlich. Bezeichnend ist auch, dass die PLM-fortgeschrittenen Unternehmen ihre Investition regelmäßig durch die Überprüfung der betriebswirtschaftlichen Kennzahlen wie den RoI kontrollierten. Bei einem unbefriedigenden Ergebnis wurden entsprechende Verbesserungsmaßnahmen eingeleitet.

8.7

Risiken der PDMS-Einführung

277

Abb. 8-19 Umsatzauswirkungen, EBIT-Entwicklung und Marktanteile nach der Einführung eines PDMS [Abramovici 2004]

Wie Abb. 8-19 zeigt, konnten sämtliche Unternehmen durch die Umsetzung der PLM-Strategie mittels eines PDMS ihren Umsatz steigern. Interessant ist hierbei, dass die „PLM-Nachzügler“ eine deutlichere Umsatzsteigerung als die PLM-fortgeschrittenen Unternehmen erreichen konnten; aufgrund der hohen anfänglichen Investitionskosten haben sie jedoch einen rückgängigen Gewinnanteil. PLM-fortgeschrittene Unternehmen konnten mit jedem umgesetzten Euro (Umsatzerlös) 4 Euro-Cent erwirtschaften. PLM-Nachzügler erreichten lediglich 1 Euro-Cent je umgesetzten Euro. Ihre Marktanteile konnten sämtliche Unternehmen um bis zu 7% innerhalb von vier Jahren erhöhen.

8.7 Risiken der PDMS-Einführung Jedes IT-Projekt birgt grundsätzlich Risiken in sich. Dies gilt insbesondere für ein PDMS-Projekt und seine Auswirkungen auf das Unternehmen. Häufig liegen die Ursachen in einer unzureichenden Kenntnis hinsichtlich der Auswirkungen oder unrealistische Erwartungen bei der Einführung eines PDMS (vgl. Abschn. 4.4).

278

8 Wirtschaftlichkeitsbetrachtung

Abb. 8-20 Risiken für das Scheitern einer PDMS-Einführung [Abramovici 2004]

Nachfolgend sind einige typische Risikofaktoren aufgeführt, die den Erfolg eines PDMS-Projekts gefährden können (siehe Abb. 8-20): x keine offensichtliche Unterstützung des PDMS-Projekts durch das Management einschließlich einer mangelnden Kommunikation zwischen dem Management, den Unternehmensmitarbeitern und der Projektleitung; x unrealistische betriebswirtschaftliche Erwartungen an den Systemeinsatz einschließlich fehlender Transparenz. Hierzu zählt insbesondere eine realistische Planung der Kosten, der Ressourcen, der Meilensteine sowie eine realistische Nutzenerwartung; x unrealistische bzw. unscharf definierte strategische und/oder operative Zielsetzungen an den Systemeinsatz. Eine eindeutige, auf ein sinnvolles Maß beschränkte Anforderungsliste dokumentiert die Zielsetzungen; x zu starker Fokus auf technische Details mit der Gefahr, den PDMSStandardumfang durch nicht benötigte Funktionalitäten zu erweitern. Dadurch wird das System komplexer und läuft ggf. instabil; x keine Einbeziehung von Vertretern der durch die Einführung betroffenen Abteilungen in den Projektablauf. Eine frühzeitige Einbindung von Vertretern aller betroffenen Abteilungen in das Projekt-Kick-Off sowie den jeweiligen Workshops ist empfehlenswert; x ungenügende Berücksichtigung der Anwenderakzeptanz aufgrund mangelnder Systemergonomie und einer Änderung der „Art der Denkweise“ hinsichtlich bekannter Abläufe. Dies kann durch ein offengelegtes Schulungskonzept, einer eingerichteten unternehmensinternen „Hotline“ oder Nennung von Superusern zur Unterstützung vermieden werden. Der Aspekt des Informations- und Kommunikationsmanagements hinsicht-

8.8

Zusammenfassung Kapitel 8

279

lich des PDMS-Projekts innerhalb des Unternehmens ist hier von entscheidender Bedeutung; x mangelhaftes PDMS-Projektmanagement wie zu große Projektschritte oder keine Berücksichtigung von zeitlichen Puffern. Empfehlenswert ist eine Planung sog. „Quick Wins“, d. h. schnell erreichbare und für alle Beteiligten sichtbaren Zielsetzungen, die den angestrebten SystemMehrwert für die Arbeitsunterstützung nachvollziehbar machen; x unzureichende Modellerstellung und/oder Modellpflege. Die Aktualität der Modelle ist grundlegend für die effektiven Systemeinsatz und die effiziente Systemnutzung durch die Mitarbeiter, da sie die wertvollen Systeminhalte (und somit das vorhandene Unternehmenswissen) darstellen. Veraltete, inkonsistente und/oder redundante Daten deuten auf eine schlechte Modellqualität hin. Besonders berücksichtigt werden muss die Frage nach der Migration des Altdatenbestands. x … Häufig wird ein PDMS-Projekt unter großem Zeit- und Erfolgsdruck begonnen. Dies führt dazu, dass viele der exemplarisch beschriebenen Risikofaktoren aufgrund des Erfolgsdrucks unterschätzt oder bewusst ignoriert werden. Das Projekt soll unter allen Umständen umgesetzt werden. Bei falschen Zielsetzungen und groben Planungsfehlern sind die Projektergebnisse nicht nur nutzlos, sondern können sich für kleine und mittelständische Unternehmen sogar existenzbedrohend auswirken.

8.8 Zusammenfassung Kapitel 8 Die Bewertung der Wirtschaftlichkeit eines PDMS-Projekts ist für das Unternehmensmanagement die wesentliche Entscheidungsgrundlage zur Systemeinführung. Dabei werden sowohl Kostenfaktoren als auch der erwartete Nutzen berücksichtigt. Während die Kostenerfassung sich als vergleichsweise einfach darstellt, ist die Erfassung und monetäre Bewertung des Nutzens schwieriger. Die Grundlage für die Wirtschaftlichkeitsbetrachtung stellt das durch das Unternehmen ausgewählte SOLL-Szenario dar. Es beschreibt denjenigen Zustand, den das Unternehmen nach Abschluss der Systemeinführung erreichen will. Das SOLL-Szenario wird durch die definierten Anforderungen der Anforderungsliste sowie durch betriebswirtschaftliche Aspekte unternehmensindividuell erweitert – es entsteht der Business Case, der die Wirtschaftlichkeit des PDMS-Projekts dokumentiert.

280

8 Wirtschaftlichkeitsbetrachtung

Zur Bewertung der Wirtschaftlichkeit kann in vier Schritten vorgegangen werden: Im ersten Schritt wird das unternehmensindividuelle Nutzenpotenzial identifiziert, welches durch das PDMS-Projekt nutzbar gemacht werden kann. Das Nutzenpotenzial lässt sich aus den Ergebnissen der ISTAnalyse und des gewählten SOLL-Szenarios ableiten. Anschließend wird die monetäre Bewertung des Nutzens durchgeführt. Hierbei wird zwischen monetär messbarem und monetär nicht-messbarem Nutzenpotenzial unterschieden. Das monetär nicht-messbare Nutzenpotenzial unterteilt sich in einen quantifizierbaren und in einen nicht quantifizierbaren Anteil. Während die beiden ersten Nutzenarten durch die CSC direkt erfasst und bewertet werden können, stellt das nicht-monetär messbare und nichtquantifizierbare Nutzenpotenzial die abgeleiteten Verbesserungsmaßnahmen innerhalb der CSC dar. Die mit ihnen erzielten Ergebnisse können bewertet werden. Im dritten Schritt werden die anfallenden Kosten erfasst. Dies geschieht durch die Anwendung von betriebswirtschaftlichen Verfahren wie dem „Total Cost of Ownership“ oder der Prozesskostenrechnung. Anschließend wird im abschließenden vierten Schritt die Wirtschaftlichkeit mit Hilfe spezifischer Kennzahlen wie dem RoI oder der Amortisationsdauer ermittelt. Grundlage für die Wirtschaftlichkeitsbewertung sind das ermittelte Nutzenpotenzial und die erfassten Kosten sowie die Ergebnisse der IST-Analyse und der CSC-Bewertung. Die gewonnenen Ergebnisse werden im Business-Case dokumentiert. Zusätzlich enthält er die inhaltliche Beschreibung des PDMS-Projekts, die getroffenen Annahmen zur Ermittlung der Kennzahlen und mögliche Risiken. Aus dem betrachteten Business-Case lässt sich mit Hilfe der CSCAktivitätenmatrix „Finanzen“ der Perspektiven-Reifegrad ermitteln. Daraus ergeben sich für das Management entsprechende Handlungsempfehlungen. Literatur Abramovici M (2004) Benefits of PLM, Studie des ITM, Universität Bochum Arnold V, Dettmering H, Engel T, Karcher A (2005) Product Lifecycle Management beherrschen. Springer, Berlin-Heidelberg-New York Brandt T (2002) Analyse existierender Ansätze zur Wirtschaftlichkeitsberechnung. In: Qualität und Wirtschaftlichkeit. Symposion, Düsseldorf Eigner M, Stelzer R (2001) Produktdatenmanagement-Systeme. Springer, BerlinHeidelberg-New York Kletti J (2007) Einführung von MES. Springer, Berlin-Heidelberg-New York Krcmar H (2003) Informationsmanagement, 3. Auflage. Springer, BerlinHeidelberg-New York

8.8

Zusammenfassung Kapitel 8

281

Kütz M (2003) Kennzahlen in der IT - Werkzeuge für Controlling und Management. dpunkt, Heidelberg McGrath M E (2004) Next Generation Product Development. McGraw-Hill, New York Mentzel W (2006) BWL Grundwissen, 3. Auflage. Haufe, Planegg/München Schabacker (2004) Sprungbrett für den Mittelstand. In: AutoCAD-Magazin 6/04. WIN-Verlag, Vaterstetten Schmidt M (2002) Business Case Guide, 2nd edition. Solution Matrix Ltd, Boston Schoen R (2005) PLM-Einführung mit Erfolg - Risiken & Wirtschaftlichkeitsaspekte. In: Product Lifecycle Management - mit System zum Erfolg. Seminar am WZLforum der RWTH Aachen am 25.01.2005 Schöttner J (1999) Produktdatenmanagement in der Fertigungsindustrie - Prinzip, Konzepte, Strategie. Hanser, München-Wien Schuh G (2005) Produktkomplexität managen, 2. überarbeitete Auflage. Hanser, München-Wien Schwab A (2004) Managementwissen für Ingenieure, 3., neubearb. Aufl. Springer, Berlin-Heidelberg-New York Stark J (2006) Product Lifecycle Management - 21st Century Paradigm for Product Realisation, 3rd printing. Springer, London Töpfer A (2007) Betriebswirtschaftslehre – anwendungs- und prozessorientierte Grundlagen. Springer, Berlin-Heidelberg-New York VDI-Richtlinie 2219 Informationsverarbeitung in der Produktentwicklung - Einführung und Wirtschaftlichkeit von EDM/PDM-Systemen. Beuth, BerlinWien-Zürich

9 Fallbeispiel

Der beschriebene PDMS-Regelkreis mit seinen beiden Lösungsbausteinen „PDMS-Einführungsmethodik“ und „Bewertung der PDMS-Fähigkeit“ wurde in mehreren Industrieprojekten erfolgreich angewendet. Dabei erfolgte eine ständige Anpassung an die pragmatischen Unternehmensanforderungen. Das nachfolgend geschilderte Fallbeispiel basiert auf einem durchgeführten Industrieprojekt. Zwar wurden die entsprechenden Beschreibungen anonymisiert und die exemplarischen Zahlenwerte geändert, die Inhalte lehnen sich dennoch an reale Bedingungen an. Somit dient das Fallbeispiel durchaus als Orientierung für Unternehmen, die ein PDMSProjekt planen oder gerade durchführen. Zunächst wird das mittelständische Zulieferunternehmen aus dem Maschinenbau kurz charakterisiert und die Ergebnisse der unternehmensinternen Vorklärungsphase vorgestellt. Danach folgt die Beschreibung der Vorgehensweise zur Umsetzung beider Lösungsbausteine. Dies geschieht anhand der Beschreibung der einzelnen Arbeitsschritte. Den Abschluss bildet neben grundsätzlichen Anmerkungen zum zugehörigen Business Case der Ausblick auf die Unternehmensschritte, welche nach der Beendigung des PDMS-Projekts erfolgt sind. Der Beschreibungsschwerpunkt des Fallbeispiels liegt auf der Unternehmensperspektive „Prozess“. Die anderen Perspektiven werden ebenfalls, jedoch weniger ausführlich, behandelt. Bei dem beschriebenen Fallbeispiel wird deutlich, dass sich die Abläufe innerhalb der einzelnen Arbeitsschritte während des Projektverlaufs überschneiden. Eine rein sequentielle Ausführung, wie sie in den vorangegangenen Kapiteln aufgrund einer besseren Verständlichkeit beschrieben wurde, ist in der industriellen Anwendung weder notwendig noch zielführend. Die Abläufe selbst bleiben in ihren Inhalten jedoch unverändert.

284

9 Fallbeispiel

9.1 Allgemeine Unternehmenssituation und Vorklärungsphase Der betrachtete Zulieferbetrieb aus dem Bereich des Maschinenbaus ist weltweit vertreten und besitzt einen Exportanteil von über 75% seiner Produkte. Der Umsatz lag im betrachteten Geschäftsjahr knapp unter einer Milliarde Euro, der von über 8000 Mitarbeitern erwirtschaftet wurde. Die Unternehmenszentrale liegt in Deutschland, in welcher auch die hauptsächlichen Entwicklungstätigkeiten durchgeführt werden. Das Unternehmen ist ISO 9000 zertifiziert. Neben mehreren Vertriebs- und Fertigungsstandorten ist besonders eine Vielzahl regionaler Zulieferer in die einzelnen Phasen des Produktentstehungsprozesses eingebunden. Diese hohe Einbindung an Zulieferbetrieben resultierte aus der historischen Unternehmensentwicklung; deshalb beschränkte sich die Fertigungstiefe des Unternehmens ausschließlich auf die letzten Schritte vor der Endmontage und der Endmontage selbst. Einen wesentlichen Teil der Unternehmensphilosophie stellt die zeitnahe Erfüllung individueller Kundenanforderungen mit einer hohen Produktqualität dar. In Abhängigkeit der Anforderungen besitzen die hergestellten Produkte unterschiedliche Komplexität und variieren in ihrer Baugröße. Der Anteil an verkauften standardisierten Kataloggeräten ist dagegen gering. Beide Faktoren führten zu einer hohen und unüberschaubaren Anzahl an „lebenden“ Produktvarianten, die nur noch unzureichend beherrscht wurden. Zum damaligen Zeitpunkt war der Geschäftsleitung die Existenz von 8000 „lebenden“ Varianten bekannt. Es wurde geschätzt, dass jedes Jahr bis zu 1000 Varianten neu hinzu kamen.

Abb. 9-1 Schematische Darstellung der identifizierten Probleme durch Mitarbeiter des Technischen Bereichs

Die Beherrschung der hohen Variantenzahl und der damit verbundenen Unternehmenskomplexität sollte durch die Umsetzung von PLM und den

9.1

Allgemeine Unternehmenssituation und Vorklärungsphase

285

Einsatz eines PDMS geschehen. Abbildung 9-1 stellt zwei exemplarische Problemstellungen anhand einer Skizze dar, wie sie im Unternehmen aus der Sicht des Technischen Bereichs vorhanden waren. x So wurden bspw. die bestehenden Schnittstellen zwischen dem Vertrieb, dem Technischen Bereich und der Fertigung als ungenügend angesehen, da die übergebenen Vertriebsdaten oftmals für die Entwicklungsabteilung nicht ausreichend waren. Ein ähnliches Qualitätsproblem hinsichtlich der Dateninhalte und deren Umfang stellte sich bei der Übergabe aus den ausländischen Niederlassungen ein. Dies ist zum einen in einer unterschiedlichen Komplexität der landesspezifischen Produktpalette, zum anderen in den unterschiedlichen Standortstrukturen begründet. x Die Schnittstellenproblematik besitzt ihre Ursache auch in einer fehlenden Durchgängigkeit der vorhandenen Abläufe. Dies galt nicht nur abteilungs- bzw. standortübergreifend, sondern auch innerhalb des Technischen Bereichs. Die Problematik wurde noch dadurch verstärkt, dass sich der gesamte Technische Bereich aus mehreren Abteilungen wie die Entwicklung der Mechanik, der Elektrik/Elektronik oder der Entwicklung der Steuerungssoftware zusammensetzte. Deshalb war die Effizienz bestimmter Tätigkeitsabläufe häufig von der Erfahrung des verantwortlichen Mitarbeiters abhängig. Dies machte sich insbesondere bei Produktänderungen bemerkbar: Zwar wurden mittels eines vorhandenen Formblatts sämtliche Anforderungs- bzw. Produktänderungen dokumentiert, ein definierter Änderungsablauf war jedoch nur ansatzweise vorhanden. Häufig wurden deshalb Änderungen erst am Ende des Entwicklungsprozesses während der Nullserie umgesetzt, was einen hohen Kostenanteil und eine entsprechende Zeitverzögerung zur Folge hatte. Die Folgen der bestehenden Situation waren u. a. eine hohe Anzahl an Doppelarbeit in der Entwicklung, unterschiedliche Zeitspannen vom Auftrag bis zur Kundenbemusterung von bis zu mehreren Wochen oder erneute Bestellungen von bereits vorhandenen Werkzeugen. Die Initiative für das PDMS-Projekt ging vom Entwicklungsleiter des Technischen Bereichs aus, der für über 100 Mitarbeiter verantwortlich war. Aufgrund der vorhandenen 3D-CAD-Software favorisierte er die Einführung eines PDMS des gleichen Softwareherstellers. Zu diesem Zeitpunkt erfolgten erste Gespräche mit den Abteilungsleitern, die die Bereiche Mechanik, Elektrik/Elektronik, Controlling, Patente/Dokumentation und Softwareentwicklung repräsentierten. Ebenfalls wurden Mitarbeiter der IT-Abteilung und der Fertigungsleiter eingebunden.

286

9 Fallbeispiel

Aus diesen Diskussionen sowie durchgeführten Marktanalysen, Messebesuchen und Informationsveranstaltungen einschlägiger Softwareanbieter wurde erkannt, dass… x …zur Steigerung der Prozessdurchgängigkeit die Abläufe zur Vertriebsund zur Fertigungsabteilung optimiert und durch die Anbindung des PDMS an die abteilungsspezifischen Systeme realisiert werden mussten; x …effektive und effizientere Abläufe innerhalb des Technischen Bereichs durch eine Verbesserung der bestehenden Ablauf- und Aufbauorganisation, aber auch durch entsprechend geeignete Produktstrukturen geschaffen werden mussten; x …das notwendige Änderungen im Prozess- und/oder im Produktbereich gezielter durchgeführt werden mussten, um die gewünschte Variantenbeherrschung zu erreichen. Dies bezog sich insbesondere auf eine eindeutige Dokumentation und definierte Vorgehensweisen mit zugewiesenen Verantwortlichkeiten. Diese unscharfen Zielsetzungen dienten als Grundlage für ein erstes Projektgespräch mit Vertretern der Geschäftsleitung. Aufgrund der identifizierten Problemstellungen wurden erste Verbesserungsmaßnahmen diskutiert. Dabei schlug der Technische Leiter dem Management als Lösungsmöglichkeit die Einführung eines PDMS vor. Als konkrete Voraussetzungen für den Systemeinsatz nannte er einerseits ein notwendiges Produkt-Reengineering mit den Schwerpunkten Modularisierung, andererseits die interne Standardisierung durch eine erhöhte Wiederholteilverwendung. Zusätzlich sollten bestehende Abläufe wie der Änderungs- oder den Variantenerstellungsprozess eindeutig definiert werden. Da die Geschäftsleitung dem Vorschlag offen gegenüberstand, wurden gemeinsam die folgenden strategischen Ziele erarbeitet, die an eine Systemeinführung gestellt wurden: x die Beibehaltung eines umfangreichen, externen kundenindividuellen Produktangebots bei einer gleichzeitig reduzierten Anzahl an internen standardisierten Produktbauteilen; x ein schnelleres „Time-to-market“ bei mindestens gleichbleibender Produktqualität und Marktpreisen, um sich gegenüber den Mitbewerbern aus dem osteuropäischen und asiatischen Raum behaupten zu können. Dieses Ziel sollte durch eine zeitliche Verkürzung des PEP erreicht werden; x einen Erhalt der engen Verzahnung bzgl. der eingebundenen Zulieferbetriebe und der damit verbundenen geringen Fertigungstiefe aus Gründen der Flexibilität;

9.1

Allgemeine Unternehmenssituation und Vorklärungsphase

287

x die Vereinheitlichung sämtlicher Entwicklungsprozesse, die je nach Produktfamilie an unterschiedlichen Standorten durchgeführt wurden, einschließlich eines standardisierten Datenaustauschs; x die Evaluierung einer möglichen Einsparung von personellen Ressourcen im Bereich der Produktentwicklung durch den Systemeinsatz. Zusätzlich sollten anfallende Routinetätigkeiten im Technischen Bereich durch das PDMS übernommen werden, um mehr Zeit für die Entwicklung innovativer Produkte zu gewinnen. Die PDMS-Einführung war zunächst im Technischen Bereich der Unternehmenszentrale geplant. Die Einbindung weiterer Standorte sowie der Zulieferer war mittelfristig angedacht und sollte in Form einer Systemerweiterung in der späteren Betriebsphase bereits während der Einführungsplanung berücksichtigt werden. Durch die Umsetzung der beschriebenen Ziele wurden eine Unterstützung der Wettbewerbsfähigkeit und eine Steigerung des gegenwärtigen Marktanteils erwartet. Die Durchführung eines PDMS-Projekts wurde beschlossen und die Rahmenbedingungen wie finanzielle, personelle und zeitliche Ressourcen grob festgelegt. Als Projektpate und Gesamtverantwortlicher gegenüber dem Management wurde der Technische Leiter bestimmt. Neben der Einführung eines PDMS wurde im Unternehmensmanagement auch die PLM-Umsetzung auf der Basis des bestehenden ERP-Systems im Unternehmen diskutiert. Die Situation auf Managementebene stellte sich folglich in Form zweier Lager dar, so dass dem erfolgreichen Abschluss des PDMS-Projekts eine entsprechende Bedeutung zugemessen wurde. Das PDMS-Projekt erhielt damit auch eine hohe interne firmenpolitische Brisanz. Alle Beteiligten waren sich einig, dass aufgrund der fehlenden Erfahrung sowie des augenblicklichen starken Tagesgeschäfts ein neutraler, externer Berater mit der Evaluierung und der Durchführung des PDMS-Projekts beauftragt werden musste. Dies geschah durch die Einbindung eines spezialisierten Hochschulinstituts. Die zu diesem Zeitpunkt durch das Unternehmen festgelegten Aufgabendefinitionen für die erste Projektphase zeigt die Abb. 9-2; die erwarteten Ergebnisse sind in Abb. 9-3 aufgeführt. Beide Abbildungen entstammen in ihrer Darstellungsform und in ihrem Konkretisierungsgrad den Notizen aus der unternehmensinternen Vorklärungsphase. Als Zeitraum für die Aufgabenerfüllung und als erster Projektmeilenstein wurden gemeinsam 10 Wochen festgelegt. Einzige Ausnahme bildete die Erfassung des Änderungsprozesses, dessen Zeitrahmen mit fünf Monaten vereinbart wurde.

288

9 Fallbeispiel

Abb. 9-2 Aufgabendefinition für das PDMS-Projekt

Nach der Erteilung des Auftrags wurden sowohl durch den Technischen Leiter als auch vom Hochschulinstitut die beiden Projektleiter und die Projektmitglieder verbindlich bestimmt. Das gesamte Projektteam bestand einschließlich der Hochschulmitarbeiter aus 12 Mitgliedern. Neben den genannten Vertretern der durch die PDMS-Einführung betroffenen Abteilungen wurden zusätzlich Mitarbeiter aus der Arbeitsvorbereitung und der Betriebsmittelerstellung eingebunden. Für das Projektteam besonders wertvoll war die Teilnahme eines pensionierten Mitarbeiters des Technischen Bereichs. Aufgrund seiner sehr langen Unternehmenszugehörigkeit besaß er ein umfangreiches Wissen über die Produkte und Abläufe im Unternehmen. Seine Erfahrung und Kompetenz wurde von allen Projektmitgliedern akzeptiert; dies trug wesentlich zu einem fachlichen und zielgerichteten Projektablauf bei. Die Mitarbeiter des Hochschulinstituts waren für die Daten- und Prozessintegration der PDMS-Einführung verantwortlich. Dabei wurden die Aufgaben in die Evaluation exemplarischer Produkte, des Entwicklungs- und Änderungsprozesses sowie der Schnittstellenanalyse zu der Vertriebs- und Fertigungsabteilung aufgeteilt. Mittelfristig wurde ein PDMS-fähiges Reengineering sämtlicher relevanter Produkte und Prozesse gewünscht. Damit war die unternehmensinterne Vorklärungsphase abgeschlossen. Es begann die Untersuchungsphase mit der Durchführung des ersten Arbeitsschritts.

9.2

Lösungsbaustein 1: Die PDM-Systemeinführung

289

Abb. 9-3 Erwartete Ergebnisse nach der ersten Projektphase

Seitens der Unternehmensführung wurde im weiteren Verlauf des PDMSProjekts der Schwerpunkt auf den Entwicklungsprozess gelegt. Die anfänglich geplante Evaluierung des Änderungsprozesses wurde aus Zeitund Kostengründen auf einen späteren Zeitpunkt verschoben. Aus diesem Grund wird auf diesen Aspekt in den weiteren Ausführungen nicht mehr eingegangen.

9.2 Lösungsbaustein 1: Die PDM-Systemeinführung Die Schwerpunkte bei der Umsetzung des ersten Lösungsbausteins lagen in einer optimalen Vorbereitung des vierten Arbeitsschritts. Darin sollte das PDM-System pilothaft im Unternehmen implementiert werden, um in einer Testumgebung unter simulierten Anforderungen des Tagesgeschäfts die Systemeignung nach vorgegebenen Kriterien zu überprüfen. Die einzelnen Arbeitsschritte des ersten Lösungsbausteins, die in den nachfolgenden Abschnitten beschrieben werden, sind zur besseren Übersicht in Abb. 9-4 dargestellt. Die einzelnen Hilfsmittel und ihre Inhalte, die sich auf das Fallbeispiel beziehen, wurden in Kap. 6 erläutert; ihre Anwendung wird nachfolgend an den entsprechenden Stellen lediglich erwähnt.

290

9 Fallbeispiel

Abb. 9-4 Vorgehensweise bei der PDM-Systemeinführung und Ermittlung der unternehmensindividuellen CSC-Bewertungskriterien

Zusätzlich konnten mittels der durchgeführten Zieldefinition und der ISTAnalyse sämtliche unternehmensindividuellen Daten gesammelt werden, die für die Ermittlung der PDMS-Fähigkeit durch die Capability Scorecard benötigt wurden. Die Bewertung ist Inhalt des zweiten Lösungsbausteins. 9.2.1 Durchführung des Arbeitsschritts 1 Die Untersuchungsphase begann mit einem Gespräch aller Projektbeteiligten auf der Managementebene. Zweck dieses Gesprächs war die Schaffung einer gemeinsamen Verständnisgrundlage hinsichtlich der Begrifflichkeiten wie PLM oder PDMS, eine Evaluierung bzw. Ergänzung hinsichtlich der strategischen Ziele des Unternehmens sowie eine erste Überprüfung ihrer Eignungsfähigkeit hinsichtlich der PLM-Umsetzung. Als Projektziel der Untersuchungsphase wurde die Schaffung einer Entscheidungsgrundlage für das Management festgelegt, anhand derer über eine pilothafte Systemeinführung entschieden werden konnte.

9.2

Lösungsbaustein 1: Die PDM-Systemeinführung

291

Abb. 9-5 Grober Projektplan zur Durchführung der Untersuchungsphase

Fast alle in der Vorklärungsphase definierten strategischen Ziele konnten durch die Einführung eines PDMS unterstützt werden; einzige Ausnahme bildete der Wunsch nach einer Rationalisierung der Mitarbeiteranzahl. Hier wurde deutlich dargelegt, dass das Ziel einer Einsparung von personellen Ressourcen im Technischen Bereich durch die Systemeinführung weder möglich noch wünschenswert war. Zusätzlich wurden mit dem Management neben den Potenzialen auch die entsprechenden Risiken und die Folgen der PDM-Systemeinführung innerhalb des Unternehmens dargelegt. Dies betraf v. a. das notwendige Produkt-Reengineering sowie das einhergehende Prozess-Reengineering. Beides setzt bei den Mitarbeitern die Bereitschaft voraus, „alte Zöpfe abzuschneiden und eine neue Art des Konstruierens anzunehmen“, wie es der Projektpate treffend formulierte. Abschließend erfolgte die Ressourcenfestlegung. Hier wurde insbesondere ein erster grober Projektplan sowie die Inhalte der beiden ersten Arbeitsschritte in einer Form vorgestellt, wie sie in Abb. 9-5 dargestellt ist. Die finanziellen und personellen Ressourcen waren bereits während der Auftragsabklärung zwischen Geschäftsführung, dem Projektpaten und dem beteiligten Hochschulinstitut festgelegt worden.

292

9 Fallbeispiel

Abb. 9-6 Workshopergebnisse zur Identifizierung von Nutzenpotenzialen und Risiken aus Sicht der Anwender und des Managements (Workshop-Originalfolie)

Die eigentliche Unternehmensanalyse begann mit der Durchführung eines Workshops, an dem sämtliche Mitglieder des Projektteams teilnahmen. Der Workshop selbst wurde mit einem Tag angesetzt und hatte folgende Inhalte: x gemeinsame Klärung und Verständnis bedeutsamer Begriffe wie Product Lifecycle Management oder Produktdatenmanagement-System; x die Sammlung von Nutzenpotenzialen und Risiken der Systemeinführung, wie sie in Abb. 9-6 aufgelistet sind. Dies beinhaltet auch die Aufnahme von Arbeitsabläufen u. ä. aus Sicht des Projektteams, die nicht verändert werden sollen; x die Erfassung der operativen Ziele und ihrer Bewertungskriterien. Dies geschah durch eine thematische Gruppierung entsprechender Moderationskarten, auf denen die Teilnehmer ihrer Wünsche formuliert hatten. Diese Gruppierung geschah hinsichtlich der Schwerpunkte Produkte, Prozesse, Verbesserung der Arbeitsabläufe für die Mitarbeiter, technische bzw. funktionelle Systemvoraussetzungen/-erwartungen und sonstige Anforderungen bzw. Zielsetzungen;

9.2

Lösungsbaustein 1: Die PDM-Systemeinführung

293

x die Gewichtung mittels Anwendung der Präferenzmatrix, wie sie für die Prozessperspektive in Abb. 7-19 gezeigt ist. Typische operative Zielsetzungen im Bereich der Prozesse, die mit der Systemeinführung erreicht werden sollten, waren bspw. x eine gewünschte Steigerung der Prozesstransparenz sowie der Durchlaufzeit bei als zu komplex empfundenen Prozessen wie der Muster- und Variantenerstellung. Dadurch erwarteten die Teammitglieder ein besseres Verständnis der vorhandenen Abläufe innerhalb ihres Arbeitsbereichs; x die Senkung der Fehlerquote bei der Erstellung von Prozessdokumentationen und eine damit verbundene Senkung der augenblicklichen Prozesskosten; x eine generelle Senkung der Anzahl sowohl der Prozessbeteiligten als auch der Prozessschnittstellen; x einen direkten und zeitnahen Zugriff auf sämtliche Daten, die jeder Mitarbeiter zur Ausführung seiner Tätigkeiten benötigt. Weitere Zielsetzungen anderer Schwerpunkte waren eine hohe Systemstabilität, eine ergonomische und intuitiv nutzbare Bedienoberfläche, eine einfache Systemadministrierung und Wartung, eine sichtenabhängige Produktstrukturdarstellung (der Konstruktions-, der Fertigungs- oder der Montagesicht) oder eine schnelle, einfache und effiziente Suchfunktionalität.

Abb. 9-7 Ermittelte Bewertungskriterien und deren Gewichtung in Abhängigkeit der Workshop-Teilnehmerstruktur (Auszug)

294

9 Fallbeispiel

Anschließend erfolgte die Vorstellung der Ergebnisse in Form einer Grafik (vgl. Abb. 9-7). Um die Ergebnisse hinsichtlich der erhaltenen Gewichtungsfaktoren besser diskutieren zu können, wurden sie sowohl abteilungsspezifisch als auch in ihrem gesamten Mittelwert dargestellt. Dies geschah, um bereits zu diesem Zeitpunkt abteilungsspezifische Besonderheiten bei der Gewichtungsverteilung berücksichtigen zu können. Dies erwies sich jedoch als nicht notwendig. Nach Abschluss der Workshops ordneten beide Projektleiter die gewonnenen und geclusterten operativen Ziele den einzelnen CSCUnternehmensperspektiven zu. Gleichzeitig wurde dadurch die qualitative Zielbewertung mittels der CSC durchgeführt. Sämtliche operativen Ziele konnten durch die Systemeinführung erreicht werden. Auf dieser Grundlage wurde eine erste Anforderungsliste erstellt. Anschließend begann die Durchführung des zweiten Arbeitsschritts. 9.2.2 Durchführung des Arbeitsschritts 2 Im zweiten Arbeitsschritt wurde die augenblickliche Eignung des Unternehmens hinsichtlich seiner PDMS-Fähigkeit ermittelt. Dies geschah anhand einer IST-Analyse mehrerer Produkte, die stellvertretend das gesamte Produktprogramm repräsentierten. Zusätzlich wurde der Entwicklungsprozess und die vorhandene IT-Landschaft betrachtet. Ausgangspunkt der IST-Analyse bildeten die dokumentierten Abläufe innerhalb des Technischen Bereichs, die aufgrund der ISO-9000Zertifizierung in einem Entwicklungshandbuch erfasst waren (EHB). In diesem Handbuch waren sämtliche Phasen des PEP sowie seine einzelnen Teilprozesse dokumentiert. Jeder Teilprozess wurde durch seine Aktivitäten, eingesetzte Hilfsmittel, den Prozessverantwortlichen und seine Eingliederung in den übergeordneten Gesamtablauf beschrieben. Dadurch konnten die Abläufe auf der Prozess- bzw. Teilprozessebene erfasst werden (vgl. Abschn. 6.4.2). Zusätzlich wurden Dokumente wie vorhandene Konstruktionsrichtlinien, Werksnormen, Organigramme, Arbeitsplatzbeschreibungen sowie Unterlagen aus der Marketingabteilung (Imagebroschüren, Produktkataloge oder Projektstudien) und dem Qualitätsmanagement analysiert.

9.2

Lösungsbaustein 1: Die PDM-Systemeinführung

295

Abb. 9-8 Ergebnis der Mitarbeiterinterviews hinsichtlich der vorhandenen Datenund Informationsflüsse

Um die Abläufe auf der Vorgangsebene zu berücksichtigen, wurden Expertengespräche mit den Abteilungsleitern sowie Mitarbeiterinterviews durchgeführt. Insgesamt wurden 54 Mitarbeiter aus den Abteilungen Technischer Bereich, Verfahrensentwicklung, Vertrieb, Produktion, Materialwirtschaft, Marketing und IT befragt. Dabei wurden 1784 Daten einschließlich ihrer Speicherorte bzw. Ablageorte, beteiligte Personen sowie ihr bestehendes Format (digital/analog) aufgenommen. Sie wurden von Redundanzen bereinigt und in einer Daten- und Informationsliste (D&IListe) dokumentiert. Die einzelnen Datentypen zeigt Abb. 9-8. Nach der Bereinigung von redundanten Daten blieben 587 unterschiedliche Datenobjekte übrig. Dies zeigte einen hohen Anteil an vorhandener Doppelarbeit bei der Datenerstellung. Eine Ursache war die parallele Erzeugung projektsensibler Daten in digitaler und analoger Form. Dies geschah aufgrund einer Skepsis der Geschäftsführung gegenüber bspw. der digitalen Signatur. Eine traditionelle Gegenzeichnung von projektsensiblen Dokumenten wie Änderungsfreigaben o. ä. wurde in Papierform deutlich bevorzugt. Die Anzahl der aufgenommenen Daten war ausreichend, um die D&ILandkarte zu erstellen, wie sie exemplarisch in Abb. 6-15 gezeigt ist. In die D&I-Liste sowie in die D&I-Landkarte wurden zusätzlich sämtliche Daten des EHB’s eingepflegt.

296

9 Fallbeispiel

Besonders auffällig ist hierbei, dass deutlich mehr Ausgangsdaten erzeugt als Eingangsdaten benötigt werden. Dies kann als Hinweis auf Medienund Schnittstellenbrüche gewertet werden, die die Effizienz der D&IFlüsse negativ beeinflussen. Die „überflüssigen“ Daten befanden sie oftmals auf den lokalen Festplatten der Anwender. Dabei handelte es oftmals um Daten, die von den Anwendern als „Zwischenergebnis“ zur Ausführungsunterstützung ihrer Tätigkeiten erzeugt und gespeichert wurden. Weiterhin wurden auch Ausgangsdaten gefunden, die aufgrund mangelnder Definition an keinen Nachfolgeprozessschritt übergeben werden konnten. Ein weiteres Ergebnis der Prozessanalyse war die unzureichende Dokumentation der betrachteten Ablaufbeschreibungen. So waren bspw. einzelne Aktivitäten, beteiligte Rollen und ihre Schnittstellen nicht oder nur mangelhaft erfasst. Die IST-Analyse der D&I-Flüsse ergab mehrere Medien- und Prozessbrüche während des Prozessablaufs, die insbesondere an den Abteilungsgrenzen zum Vertrieb und zur Fertigung auftraten. Häufig besaßen die prozessbeteiligten Mitarbeiter keine oder nur indirekte Zugriffsrechte auf Datenobjekte, die sie für ihre Tätigkeitsdurchführung zwingend benötigten (in Abb. 9-8 als „unterstützende Daten“ bezeichnet). Die Dringlichkeit der erzeugten Ausgangsdaten für nachfolgende Prozessaktivitäten war ihnen aufgrund eines fehlenden Prozessablaufs nicht bewusst. Aufgrund dieser fehlenden Prozesstransparenz ergab sich bei einigen untersuchten Prozessen eine höhere Durchlaufzeit, als eigentlich notwendig gewesen wäre. Im Bereich der Produktdatenerfassung wurden die Stücklisten einschließlich zugeordneter Dokumente wie Montageanweisungen, Berechnungsblätter oder Vorgehensweisen zur Nummernvergabe, die Zeichnungssätze, die Katalogdatenblätter, die Struktur vorhandener CAD-Modelle oder die Projektdokumentation analysiert. Zusätzlich wurde versucht, durch eine Demontage der physischen Produkte bis auf Bauteilebene die einzelnen Produktkomponenten den zugehörigen Stücklistenpositionen zuzuordnen, um die gegenseitige Referenzierbarkeit zu erfassen. Verantwortliche Mitarbeiter für die Produktdaten konnten nur unvollständig und indirekt über die beschriebenen Prozessabläufe ermittelt werden. Parallel zu dieser Vorgehensweise wurden erste Baugruppen bzw. Bauteile klassifiziert. Diese Klassifizierung bildete die Grundlage zur Erstellung von Datenschwerpunkten und zur Ableitung eines Produktdatenmodells im dritten Arbeitsschritt. Nachfolgend sind einige Ergebnisse der IST-Analyse exemplarisch aufgelistet:

9.2

Lösungsbaustein 1: Die PDM-Systemeinführung

297

x Implementierungsfähige Modelle waren nicht vorhanden. Das Entwicklungshandbuch war als Grundlage zur Erstellung eines Prozessmodells geeignet; das rudimentäre Produktdatenmodell, welches zur automatischen Erstellung der Katalogdatenblätter dient, bedurfte einer vollständigen Überarbeitung. Ein Rollenmodell fehlte ganz. x Die definierten Inhalte des Entwicklungshandbuchs wurden von den Mitarbeitern nicht gelebt. Folglich war die Effizienz bestimmter Abläufe von der Erfahrung des ausführenden Mitarbeiters abhängig. Es konnte teilweise eine hohe Abweichung von den definierten Abläufen festgestellt werden. Eine Prozesstransparenz war für die Mitarbeiter nicht gegeben. x Die IT-Landschaft spiegelt die gewachsenen Strukturen der einzelnen Unternehmensbereiche wieder und war entsprechend heterogen. Aus diesem Grund wurde eine Verwaltung der Gesamtheit aller relevanten Entwicklungsprozessinformationen und -daten durch mehrere Serverapplikationen festgestellt. Ansonsten waren die gesamten Netzwerkstrukturen innerhalb des Unternehmens und zu den Standorten ausgezeichnet gepflegt und für eine PDM-Systemanbindung geeignet. x Da die Server teilweise den entsprechenden Abteilungen nicht direkt zugewiesen waren, konnten die Mitarbeiter zur Ausübung ihrer Tätigkeiten nicht direkt auf benötigte Daten zugreifen. Dies beeinträchtigte die Effizienz des Abläufe innerhalb der Daten- und Informationsflüsse erheblich. Dadurch existierten auch viele Schnittstellen- und Medienbrüche. Teilweise waren projektsensible Daten ausschließlich in analoger Papierform dokumentiert oder auf benutzerspezifischen, lokalen Festplatten abgelegt. Dadurch war der Zugriff häufig ausschließlich Mitarbeitern der datenerzeugenden Unternehmensbereiche möglich. x Es gab sehr viele Datenredundanzen und -inkonsistenzen, insbesondere hinsichtlich der Datenaktualität. In einem festgestellten Fall arbeiteten Mitarbeiter mit veralteten Daten. x Die gesamte QM-Dokumentation wurde nicht prozessbegleitend, sondern ausschließlich produktzentriert gestaltet. Dadurch wurden Fehler mit Qualitätsauswirkungen, die ihre Ursache in ungenauen Prozessabläufen besaßen, nur unzureichend erfasst. Dies betraf bspw. das Arbeiten mit inkonsistenten Produktdaten innerhalb eines Projekts. Die Ursache waren festgestellte Schnittstellenbrüche zwischen mehreren Teilprozessen. Nach der abgeschlossenen IST-Analyse wurde ein zweiter Workshop mit dem Projektteam und Vertretern der Geschäftsleitung durchgeführt. Er hatte das Ziel, das gewünschte Umsetzungsszenario zu bestimmen, welches nach Abschluss der Systemeinführung erreicht werden sollte.

298

9 Fallbeispiel

Die möglichen SOLL-Szenarien, die in Abschn. 6.4.2 beschrieben sind, wurden durch die ermittelten Risiken bzw. Potenziale der Systemeinführung sowie die erhaltenen IST-Analyseergebnisse ergänzt. Nach der Vorstellung der einzelnen Szenarien geschah ihre Bewertung durch die Workshopteilnehmer. Die Bewertungsergebnisse der einzelnen Szenarien aus Sicht der IT-Abteilung und aus Sicht der Anwender des Technischen Bereichs sind in Abb. 9-9 dargestellt. Die gemittelte Kurve aller Projektbeteiligten aus den unterschiedlichen Abteilungen zeigt die Gesamtkurve des Unternehmens. Um das erhaltene Unternehmensergebnis besser einschätzen und validieren zu können, führte der externe Projektleiter eine unabhängige Szenarienbewertung mit einer hochschulinternen Kontrollgruppe durch. Diese Ergebnisse sind in der Abbildung ebenfalls ersichtlich und unterstreichen die erhalten Unternehmensergebnisse.

Abb. 9-9 Ergebnisse bei der Ermittlung des SOLL-Szenarios durch das Unternehmen

In Abb. 9-9 ist erkennbar, dass sich die unternehmensinterne IT-Abteilung für eine Umsetzung des Szenarios 2 aussprach. Dieses Szenario sah vor, die bereits vorhandenen IT-Systeme um entsprechende PDMSFunktionalitäten zu erweitern. Die entsprechende Programmierung sollte durch Spezialisten innerhalb der IT-Abteilung geschehen. Da jedoch der Aufwand hinsichtlich Anpassung der Software und der Benutzeroberflächen sowie die fehlenden Mitarbeiterressourcen aufgrund anderer laufender IT-Projekte fehlten, wurde sich seitens des Managements für die Umsetzung des Szenarios 3 entschieden. Dieses Szenario wurde von den Anwendern deutlich favorisiert.

9.2

Lösungsbaustein 1: Die PDM-Systemeinführung

299

Die nach dem ersten Arbeitsschritt aufgestellte Anforderungsliste wurde aufgrund der IST-Analyseergebnisse wie der beschriebenen Modellüberarbeitung sowie der sich ergebenden Anforderungen aufgrund des gewählten SOLL-Szenarios ergänzt. Damit war die Untersuchungsphase beendet. Nach der Ergebnispräsentation beschloss die Geschäftsführung die Durchführung der Umsetzungsphase einschließlich des Pilotsystems. Dabei wurde die Empfehlung der beiden Projektleiter berücksichtigt, aufgrund des gewählten SOLL-Szenarios einen externen Systemanbieter frühzeitig in die Planung der Pilotphase einzubinden. Dies geschah parallel zum Modell-Reengineering des dritten Arbeitsschritts. Aufgrund des knapp kalkulierten Zeitrahmens der Pilotphase wurde aufgrund erwarteter Synergieeffekte derselbe Systemanbieter gewählt, dessen 3D-CAD-Software im Technischen Bereich bereits genutzt wurde. Eine wichtige Randbedingung war hierbei die Erstellung der Testumgebung hinsichtlich reproduzierbarer Testparameter. Sie sollten einerseits das unternehmerische Tagesgeschäft hinreichend genau abbilden, andererseits auch ein später geplantes, zusätzliches Systembenchmark ermöglichen. Dieser Vergleich bezog sich auf die Leistungsüberprüfung des PLM-Moduls der vorhandenen ERP-Software. Um das gewählte Umsetzungsszenario nach Abschluss des PDMS-Projekts erreichen zu können, war die Überarbeitung bzw. Neuerstellung der vorhandenen Modelle auf der Grundlage der D&I-Flüsse eine wesentliche Voraussetzung. Das Modell-Reengineering geschah zeitlich versetzt während der IST-Analyse. 9.2.3 Durchführung des Arbeitsschritts 3 Das Ziel des dritten Arbeitsschrittes bestand in der Bereitstellung implementierungsfähiger Modelle. Anschließend sollten die Projektmitglieder in der Lage sein, entsprechende Modelle der vorhandenen restlichen Prozesse und Produkte selbst erstellen zu können. Hierfür wurden vom Projektpaten ein exemplarischer Prozess und ein exemplarisches Produkt ausgewählt. Bei dem ausgewählten Prozess handelte es sich um den Ablauf zur „Erzeugung von Varianten“. Dieser Ablauf wurde im Unternehmen als eine wesentliche Ursache für die hohe bestehende Variantenanzahl angesehen. Als zu modellierendes Produkt wurde ein Radialventilator ausgewählt. Er war in seinem Aufbau hinreichend komplex und bereits teilweise datentechnisch aufgrund der Katalogblätter für Kunden erfasst. Das Rollenmodell wurde aus Zeitgründen durch die Standardrollen, welche das PDMS bereitstellte, abgebildet. Die Aufstellung eines individuellen

300

9 Fallbeispiel

Rollenmodells sollte zu einem späteren Zeitpunkt erfolgen und wurde in dieser Projektphase nicht weiter verfolgt. Die zugehörigen Rollenbeteiligungen zu dem ausgewählten Prozess und dem Endgerät wurden der D&I-Liste sowie den Ergebnissen der Mitarbeiterinterviews und den Prozessaufnahmeblättern entnommen. Das Rollenmodell wird in den weiteren Ausführungen nicht explizit behandelt. Erstellung des Produktdatenmodells Bei dem ausgewählten Endgerät handelte es sich um einen Radialventilator mit einer externen elektronischen Steuerung, der in unterschiedlichen Baugrößen und Durchmessern angeboten wurde. Eine schematische Explosionsdarstellung zeigt Abb. 9-10.

Abb. 9-10 Explosionsdarstellung des betrachteten Radiallüfters

Bereits während des zweiten Arbeitsschritts geschah auf der Grundlage der zugehörigen Struktur-Stücklistenanalyse und der durchgeführten Datenklassifizierung eine erste Produktstrukturierung. Diese grobe Produktstruktur wurde anhand der Projektdokumente wie Projektaufnahmeblätter, Zeichnungssätze oder Lastenheft verfeinert. Anschließend wurde das physische Produkt bis auf seine Bauteilebene demontiert, um die Produktstruktur komplett verifizieren zu können. Dadurch konnte die Zuordnung einzelner Baugruppen bzw. Bauteile zu ihren übergeordneten Strukturknoten überprüft werden. Dies war besonders an den Schnittstellen zwischen mechanischen, elektrischen/elektronischen und softwaretechnischen Komponenten bedeutsam. Zusätzlich konnten durch die Demontage die vorhandenen Referenzierungen jeder Baugruppen bzw. Bauteile zu ihren Dokumenten, Zeichnungen, Anweisungen, Messdaten oder Berechnungen kontrolliert werden. Den zugehörigen groben Zeitplan zur Durchführung

9.2

Lösungsbaustein 1: Die PDM-Systemeinführung

301

der Aktivitäten zeigt Abb. 9-11. Insgesamt waren für die Modellerstellung vier Monate veranschlagt. Auf der Grundlage der durchgeführten Aktivitäten konnte das Produktdatenmodell formuliert werden. In der Abb. 9-12 ist es auf der ersten Gliederungsebene dargestellt. Dabei wurden aus Gründen der Übersichtlichkeit weitere Baugruppen bzw. Bauteile in dieser Darstellung vernachlässigt. Für die Systemimplementierung geschah die Modellformulierung auf einem höheren Detaillierungsgrad nach ISO 10303 (vgl. die Ausführungen in Abschn. 6.5.1).

Abb. 9-11 Zeitlicher Ablauf bei der Erstellung des Produktdatenmodells

In diesem Modell sind auch beispielhaft einige Referenzierungen zwischen den Attributen einzelner Baugruppen und Bauteile dargestellt. So bestimmen bspw. die geometrischen Abmessungen des Radialventilators wie Länge oder Breite die Wahl des zugehörigen Gehäuses. Die Gehäusegröße ist ebenfalls abhängig vom Durchmesser des Lüfterrads, mit dem der Motor bestückt wird. Die Leistungsdaten des Motors, die sich aus den Kundenanforderungen wie gewünschter Luftdurchsatz oder beabsichtigter Einsatzort (trockene oder feuchte Arbeitsbedingungen) ergeben, bestimmen die Auslegung der Anschlussleitungen. Die Steuerung des Motors geschieht durch die externe Steuereinheit. Der Steuereinheit ist eine bestimmte Version der Steuerungssoftware zugeordnet, die in der Abb. 9-12 hellgrau gezeigt ist. An diesem Modell ist ebenfalls ersichtlich, dass der Radialventilator sowohl mit, als auch ohne Gehäuse verfügbar ist. Im letztgenannten Fall ist die in der Abbildung dargestellte Baugruppe „Radialventilator“ mit der

302

9 Fallbeispiel

Identnummer 4711-0 mit dem Endgerät identisch. Die Baugruppe „Gehäuse“ wird nicht benötigt.

Abb. 9-12 Produktdatenmodell des Radiallüfters auf der niedrigsten Detaillierungsstufe

Im Rahmen der IST-Analyse wurden die im Unternehmen auftretenden Variantentypen erfasst. Ihre Dokumentation geschah anhand einer Häufigkeit-Aufwands-Matrix; anschließend wurden die erfassten Variantentypen mit dem Projektteam besprochen und ergänzt. Die Matrix ist mit einigen Variantenbeispielen in Abb. 9-13 dargestellt und zeigt die Häufigkeit auftretender Varianten gegenüber ihrem geschätzten Erstellungsaufwand. Die grau hinterlegten Bereiche in der Matrix kennzeichnen diejenigen Variantentypen, in denen das größte Standardisierungspotenzial durch eine PDMS-Unterstützung im Vergleich zu der aktuellen Vorgehensweise gesehen wurde. Daraufhin geschah eine Überprüfung des Produktdatenmodells, ob die Modellstruktur jeden dieser Variantentypen abbilden konnte. Anschließend wurde das Modell in das PDMS implementiert.

9.2

Lösungsbaustein 1: Die PDM-Systemeinführung

303

Abb. 9-13 Identifiziertes Standardisierungspotenzial im Bereich der Variantenerstellung des betrachteten Radiallüfters

Für die permanente Modellanpassung und seine Datenaktualisierung war der Business-Administrator verantwortlich. Dies beinhaltete auch die Pflege der zugehörigen Attribute und Referenzen für jedes Produktdatenobjekt. Damit bspw. Änderungen aufgrund unternehmensstrategischer (Wechsel grundlegender Technologien), konstruktiver (Wechsel des Grundmaterials) oder gesetzlicher Anforderungen (Änderung bei der Rücknahme und Entsorgung von Elektronikschrott) berücksichtigt werden konnten, war die Definition entsprechender Abläufe im Unternehmen erforderlich. Nur dadurch konnte ein Einpflegen sämtlicher Produktdatenänderungen in das Produktdatenmodell durch den Business-Administrator sichergestellt werden. Eine derartige Ablaufdefinition war die unabdingbare Voraussetzung zur Gewähr eines aktuellen Produktdatenmodells. Dieselbe Aussage galt entsprechend für alle anderen Modelle. Erstellung des Prozessmodells Die Erstellung des Prozessmodells geschah überschneidend zwischen dem dritten und vierten Arbeitsschritt. In Abschn. 6.5.1 wurde aus Gründen der Übersichtlichkeit die Beschreibung zur Modellerstellung bzw. dem Modell-Reengineering dem Arbeitsschritt 3 zugeordnet. Parallel fanden bereits Aktivitäten statt, die im nachfolgenden Abschnitt beschrieben sind.

304

9 Fallbeispiel

Abb. 9-14 Schematische Darstellung des Gesamtprozesses „Erzeugung von Varianten“ und seiner Teilprozesse

In Abb. 9-14 ist ersichtlich, dass sich der Gesamtprozess „Erzeugung von Varianten“ in zwei Teilprozesse gliedert. Im ersten Teilprozess werden, basierend auf vorhandenen physikalischen Referenz- und/oder Kataloggeräten, spezifische Kundenmuster erstellt. Diese Muster resultieren aus Kundenanforderungen, die der Vertrieb aufnimmt und mittels Lastenheft (LH) dem Technischen Bereich zukommen lässt. Anhand eines bereits vorhandenen Endgeräts erstellt ein Konstrukteur die notwendigen Musterunterlagen sowie die zugehörigen Zeichnungen. Das Referenzgerät wird anhand von Rumpfdaten, wie der geforderten Leistungserbringung, über das ERP-System identifiziert. Anschließend werden die Referenzunterlagen wie die Stückliste einschließlich der Zeichnungen händisch geändert, bis das ursprüngliche Referenzgerät die Kundenanforderungen erfüllt. Die Änderungen geschehen bis zur Bauteilebene. In die Referenzstückliste werden Baugruppen bzw. Bauteile weiterer Endgeräte eingetragen, die den LH-Vorgaben entsprechen. Ihre Ermittlung erfolgt ebenfalls über die Rumpfdaten, die im ERP-System gespeichert sind. Den Baugruppen bzw. Bauteilen wird jeweils eine neue Teilenummer aus einem Nummernbuch zugeordnet. Sie wird während der Musterphase systemtechnisch nicht erfasst. Das Endgerät erhält ebenfalls eine neue, nicht erfasste Artikelnummer. Die händischen Unterlagen werden dem Musterbeauftragten per Hauspost geschickt, welcher den eigentlichen Musterbau veranlasst. Nach

9.2

Lösungsbaustein 1: Die PDM-Systemeinführung

305

der Freigabe übergibt der Vertrieb dem Kunden das fertige Muster. Damit ist der erste Teilprozess abgeschlossen. Aufgrund der zeitnahen Mustererstellung erfolgen die zugehörige Dokumentation der Ergebnisse sowie Freigaben einzelner Unterlagen teilweise erst nach der Musterauslieferung. Das Muster ist mit seinen händisch erstellten Unterlagen in analoger Papierform dokumentiert. Einzige Ausnahme bildet die digitale Eingabe einer „inoffiziellen“ Artikelnummer in das ERP-System, damit ein Lieferschein erstellt werden kann. Eine Referenzierung zu den ursprünglichen Endgeräten, auf denen das erstellte Muster basiert, findet nicht statt. Nachdem der Kunde seinerseits das Muster getestet hat, wird durch die anschließende Kundenbestellung der zweite Teilprozess ausgelöst, in dem die eigentlichen Varianten erstellt werden. Erst jetzt werden die händisch vergebenen Teilenummern aus dem Musterprozess in das ERP-System eingepflegt und sind somit innerhalb des Produktsortiments mit einer „offiziellen“ Artikelnummer verfügbar. Der zweite Teilprozess wird in diesem Beispiel nicht betrachtet. Falls der Kunde nach Erhalt des Mustergeräts keine Bestellung aufgibt, ist der Gesamtprozess beendet. Die analogen Musterdaten werden im Archiv abgelegt und sind in den IT-Systemen nicht vorhanden. Die kaskadierende Vorgehensweise des Gesamtprozesses zur Variantenerstellung ist in Abb. 9-14 durch die Pfeile am rechten Bildrand symbolisiert. Grundlage für die Überarbeitung des Prozessmodells waren die Ergebnisse der IST-Analyse aus dem zweiten Arbeitsschritt. Neben dem Entwicklungshandbuch waren besonders die Mitarbeiterinterviews bedeutsam. Ihre Ergebnisse wurden im Prozessaufnahmeblatt dokumentiert. Anschließend geschah die Erstellung des zugehörigen Flussdiagramms einschließlich aller Aktivitäten und beteiligten Akteuren bzw. Rollen. Dieses Flussdiagramm ist ausschnittsweise in Abb. 6-27 wiedergegeben. Im Rahmen des Business Process Reengineerings wurde aufgrund der definierten Anforderungen in der Anforderungsliste für den Gesamtprozess „Erzeugung von Varianten“ folgendes Optimierungspotential identifiziert: x Einzelne Prozessschritte konnten zusammengefasst oder ausführenden, sinnvolleren Organisationseinheiten zugeordnet werden. x Einzelne Prozessverläufe bzw. Prozessverzweigungen konnten zusammengefasst werden. x Der Verlauf des Variantenprozesses ließ sich – mit entsprechender Prozessschritt- und Aufgabenerweiterung – aus dem Musterprozessverlauf ableiten.

306

9 Fallbeispiel

x Durch eine konsequente und durchgehende Berücksichtigung von 3DCAD-Modellen bereits innerhalb des Prozesses und des abgeleiteten Workflows konnte ein erhöhter Automatismus in Bezug auf die Datenund Informationsflüsse erreicht werden (bspw. in der Projektunterlagenerstellung für Kunden). x Die Tätigkeitsbeschreibungen und Verantwortlichkeiten innerhalb der einzelnen Prozessschritte wurden eindeutiger und nachvollziehbarer. x Dadurch steigerten sich die Prozess- und Kommunikationstransparenz bei den Prozessbeteiligten. x Dies hatte eine Senkung des Fehlerrisikos innerhalb der gesamten Prozesskette zur Folge. Diese Optimierungspotentiale wurden bei der Erstellung des PDMSWorkflows im vierten Arbeitsschritt umgesetzt. Mittels eines Anwenderworkshops, an dem sämtliche Projektmitglieder teilnahmen, wurde das Flussdiagramm verifiziert und ergänzt. Hierbei wurden insbesondere die identifizierten Brüche bei den einzelnen Teilprozessschnittstellen diskutiert. Dies geschah sowohl abteilungsintern als auch an den abteilungsübergreifenden Schnittstellen zum Vertrieb und zur Fertigung. Die Ergebnisse des Workshops wurden in den Muster- bzw. Variantenerstellungsprozesses eingearbeitet. Da der redefinierte Gesamtprozess als Grundlage für die später zu implementierenden PDMS-Workflows genutzt werden sollte, durchlief er eine weitere Iterationsschleife: In einem zweiten Anwenderworkshop wurde der redefinierte Gesamtprozess erneut vorgestellt und verifiziert. Anschließend wurden die beiden verifizierten Teilprozesse in Form von Workflows umgesetzt. Die Überprüfung der Auswirkungen wurde durch die CSC gemessen. Einen Ausschnitt aus dem Workflow des Teilprozesses „Erzeugung von Mustern“ zeigt Abb. 6-29. Die beiden Anwenderworkshops, die Implementierung der Workflows sowie deren Überprüfung mittels der CSC fanden während des vierten Arbeitsschritts statt. 9.2.4 Durchführung des Arbeitsschritts 4: Pilotphase Der Arbeitsschritt 4 begann mit einem Kick-Off-Meeting. Teilnehmer waren die Mitglieder des bisherigen Projektteams, die beiden Projektleiter, der Projektpate sowie Vertreter des beauftragten Softwareunternehmens. Inhalte des Kick-Off-Meetings waren:

9.2

Lösungsbaustein 1: Die PDM-Systemeinführung

307

x die Vorstellung der bisherigen Projektergebnisse sowie Definition der Zielsetzungen an die Pilotphase auf der Grundlage des Lastenhefts, welches dem Softwarehaus während des dritten Arbeitsschritts übergeben worden war; x die Festlegung des Pilotteams, welches aus dem ursprünglichen Projektteam sowie drei Mitarbeitern des Softwareunternehmens bestand einschließlich der Aufgabenverteilung; x die Festlegung des Zeitrahmens der Pilotphase auf drei Monate einschließlich eines Projektplans auf der Grundlage der ISTAnalyseergebnisse und des Lastenhefts. Hierbei fand bereits vor dem Kick-Off-Meeting ein Austausch zwischen den Projektleitern und dem Softwarehaus statt. Arbeitswochen

Vorbereitung

1

2

System-Installation Einweisung Training

4

5

6

7

Anpassung 2

9

10

11

22 Tage 3 8 4 7 40 Tage

Anpassung Anpassung 1

8

14 Tage

Installation Vor-Installation

3

2 14

Anpassung 3

Projektabschluss

19 5

Abb. 9-15 Schematischer Projektplan der dreimonatigen Pilotphase

Ein Mitarbeiter des Softwarehauses war für den Ablauf der Modellimplementierung sowie der Mitarbeiterschulungen verantwortlich. Der zweite Mitarbeiter kümmerte sich um die Systemimplementierung in die bestehende IT-Systemlandschaft und arbeitete eng mit Unternehmensmitarbeitern der IT-Abteilung zusammen. Er stellte auch den zeitnahen Austausch zwischen den beiden Projektleitern und dem Systemhaus sicher. Diese Aufgabenteilung war für eine effiziente Durchführung innerhalb des engen Zeitrahmens sehr förderlich. Der Projektplan wurde bereits in Abschn. 6.5.2 beschrieben und ist noch einmal in Abb. 9-15 schematisch gezeigt. Die Vorbereitung und eigentliche Systeminstallation seitens des Softwarehauses benötigte fünf Arbeitswochen. Um bereits von Beginn an ein um-

308

9 Fallbeispiel

fangreiches Unternehmenswissen aufzubauen, wurden sämtliche Vorbereitungs- und Installationsaktivitäten vom System- und vom BusinessAdministrator des Unternehmens begleitet. Bei diesen Aktivitäten handelte es sich bspw. um x die Einbindung eines neu angeschafften Systemservers für das PDMS sowie die eigentliche Installation und Anbindung der Software an die bestehende IT-Landschaft; x die Implementierung der Modelle in ihrem augenblicklichen Zustand; x die Migration eines definierten Anteils bestehender Daten sowie eines definierten Anteils gespeicherter Altdaten. Hierbei wurde insbesondere auf unterschiedliche Datenobjekte wie 3D-CAD-Daten, 2DZeichnungsdaten oder auch Dokumente geachtet, mit denen im Tagesgeschäft gearbeitet wurde.

Abb. 9-16 Hard- und Softwarearchitektur für den durchgeführten PDMS-Piloten

In Abb. 9-16 ist die umgesetzte IT-Architektur für ausgelegte 2000 aktive Anwender gezeigt. Sie beinhaltet als Komponenten den PDMS- und CADClient, einen FlexLM-Server zur Verwaltung der vorhandenen CADLizenzen und einen LDAP-Server für die gesamte Nutzer- und Gruppenverwaltung. Zusätzlich werden zur CAD-Visualisierung ein CAD Worker, auf dem sich unterschiedliche Dienste befinden sowie der eigentliche PDMS-Server benötigt. Der PDMS-Server beinhaltet die eigentliche

9.2

Lösungsbaustein 1: Die PDM-Systemeinführung

309

Datenbank, den Webserver, die für das PDMS-Softwaremodul erforderliche Java-Umgebung und spezifische Softwareprogramm-Dienste. Die dargestellte Architektur entstammt dem Jahr 2004; mittlerweile haben sich die Möglichkeiten sowohl im Bereich der Hard- als auch der Software weiterentwickelt. Aus diesem Grund kann die Darstellung nur einen ersten Überblick geben. Die aktuelle Architektur muss unternehmensspezifisch und unter Berücksichtigung der aktuellen systemtechnischen Möglichkeiten entsprechend angepasst werden. Die verwendete Hard- und Software für die Pilotphase ist in Abb. 9-17 aufgelistet. Die meisten Hard- und Softwarekomponenten waren bereits im Unternehmen vorhanden und mussten ggf. upgedatet werden.

Abb. 9-17 Übersicht der verwendeten Hard- und Softwarekomponenten in der Pilotphase

Nach dem Abschluss der Systeminstallation und der entsprechenden Systemtests wurden die beiden Administratoren in die Systemarchitektur eingewiesen und aufgabenspezifisch geschult. Anschließend erfolgte ein Anwendertraining des gesamten Pilotteams in zwei Gruppen. Das zweitägige Training wurde für jede Gruppe von zwei Ausbildern durchgeführt, um ein Maximum an Effizienz und individuellem Lernerfolg zu gewährleisten. Die Trainings wurden den Zielsetzungen des Unternehmens und den Bedürfnissen der Teilnehmer speziell angepasst. Damit bildeten die Trainingsinhalte eine erste inhaltliche Grundlage zur Entwicklung eines Schulungskonzepts derjenigen Mitarbeiter, die in der späteren Betriebsphase ebenfalls mit dem PDMS arbeiten sollten.

310

9 Fallbeispiel

Nach den durchgeführten Trainings begannen die Anpassungen des Systems sowie der implementierten Modelle an die Anforderungen der Anwender. Hierbei waren v. a. die folgenden Punkte von Bedeutung: x Anpassung verschiedener Systemfunktionalitäten wie bspw. die Suchfunktion oder das „Redlining“ bzw. Einbringen von Notizen im Viewer; x Anpassung der Abläufe in den implementierten Workflows und der zugehörigen Datenobjekt-Lebenszyklen an die Abläufe des Tagesgeschäfts; x Implementierung des Rechtekonzepts und der identifizierten Rollen auf der Grundlage der vorhandenen Standardrollen des PDMS; x Umsetzung unterschiedlicher Sichten wie Konstruktions- oder Fertigungssicht auf die Stückliste; x Implementierung und Anpassung des unternehmensspezifischen Nummern- und Versionsschemas der Produkte bzw. Prozesse einschließlich der Möglichkeit, Gültigkeitszeiträume zu vergeben; x Demonstration der Langzeitarchivierung aller projektrelevanten Daten (einschließlich entsprechender Attribute und Referenzierungen); x Einbringen von Norm- und Wiederholteilbibliotheken der mechanischen sowie elektrischen/elektronischen Produktkomponenten; x Einbringen von Dokumenten- und Produkttemplates, die aufgrund der produktspezifischen Projektdaten automatisch vom System erstellt werden sollten. Diese Punkte wurden in zwei weiteren Iterationsschleifen verfeinert und jeweils durch einen erneuten Anwenderworkshop verifiziert. Während der gesamten Zeitdauer nach der Systemeinführung konnte das Pilotteam produktiv mit dem implementierten PDMS in seiner Testumgebung, jedoch mit realen Daten und unter realen Bedingungen arbeiten. Dies erhöhte nicht nur die Sicherheit im Umgang mit der Software, sondern trug deutlich zur Erfahrungssteigerung der Anwender bei. Geplant war gegen Ende der Pilotphase ein gezielter Aufbau einiger geeigneter Pilotteammitglieder als Superuser, die in der Betriebsphase allen anderen Unternehmensmitarbeitern bei Problemen oder Unsicherheiten im Systemumgang unterstützend zur Verfügung stehen konnten. Da die Anzahl dieser Mitarbeiter im ersten Schritt der Betriebsphase ausschließlich den Technischen Bereich umfasste, wurde die Einrichtung einer Hotline oder eines Helpdesks aus Kostengründen von der Geschäftsleitung verworfen. Die Pilotphase konnte in ihrem Zeitrahmen eingehalten werden. Die geforderten Zielsetzungen und Anforderungen wurden aus Sicht aller Projektbeteiligter erfüllt. Dies ging aus der Abschlusspräsentation für das Management deutlich hervor.

9.3

Lösungsbaustein 2: Bewertung der PDMS-Fähigkeit

311

9.3 Lösungsbaustein 2: Bewertung der PDMS-Fähigkeit Während der Durchführung der Arbeitsschritte 1 bis 4 geschah mittels der Capability Scorecard (CSC) ein ständiges projektbegleitendes Controlling, um Abweichungen vom gewünschten Grad der Zielerreichbarkeit festzustellen. Dieser gewünschte Grad wird durch die SOLL-PDMS-Fähigkeit beschrieben; den jeweils augenblicklichen IST-Zustand zum gemessenen Projektzeitpunkt erfasst die IST-PDMS-Fähigkeit.

Abb. 9-18 Vorgehensweise bei der Ermittlung der PDMS-Fähigkeit und des PDMS-Reifegrads des betrachteten Unternehmens

In den nachfolgenden Abschnitten wird das Vorgehen bei der CSCBewertung beschrieben. Zur besseren Übersicht ist die Vorgehensweise in Abb. 9-18 gezeigt. Die entsprechenden Hilfsmittel sind in den Kap. 6 und 7 in Bezug auf das Fallbeispiel beschrieben. Einen Ausschnitt des zugehörigen Business Case behandelt der Abschn. 9.4. 9.3.1 Durchführung des Arbeitsschritts A Die durchzuführenden Aktivitäten für diesen Arbeitsschritt waren mit denjenigen identisch, wie sie bereits in Abschn. 9.2.1 ausgeführt wurden.

312

9 Fallbeispiel

Nach der Erfassung der strategischen Zielsetzungen wurden diese mittels qualitativer Zuordnung überprüft, ob sie generell für eine Umsetzung durch die PLM-Strategie geeignet waren. Bei den fünf gewünschten strategischen Zielen war ein Ziel nicht umsetzbar; es ergab sich eine qualitative PDMS-Fähigkeit von 80%. Dabei handelte es sich um den Wunsch nach einer möglichen Einsparung personeller Ressourcen. Dieses Ziel kann durch die PLM-Umsetzung nicht erreicht werden; in diesem Fall sind andere strategische Maßnahmen wie Outsourcing o. ä. vorzuziehen. Da sich das Management nach einer internen Diskussion von dieser Zielsetzung trennte, konnte die gewünschte qualitative PDMS-Fähigkeit von 100% im Bereich der strategischen Zielsetzungen erreicht werden. Dieselbe Vorgehensweise wurde bei der qualitativen Bewertung der operativen Zielsetzungen angewendet. Jedes operative Ziel konnte einer entsprechenden Unternehmensperspektive zugeordnet werden. Es ergab sich eine qualitative PDMS-Fähigkeit von 100%. Mit der gewonnenen qualitativen PDMS-Fähigkeit sowohl auf strategischer als auch auf operativer Ebene waren die zu erreichenden Ziele nach Beendigung des PDMS-Projekts festgelegt. Sämtliche definierten Ziele waren mit Hilfe von PLM und PDMS grundsätzlich umsetzbar. 9.3.2 Durchführung des Arbeitsschritts B In Arbeitsschritt A konnten sämtliche operativen Ziele den einzelnen Unternehmensperspektiven zugeordnet werden. Ihre Dokumentation geschah in der Spalte „operative Ziele“ der entsprechenden Aktivitätenmatrix (AM). Nachfolgend wird exemplarisch die Bewertung des Mustererzeugungsprozesses, wie er in Abschn. 9.2.3 beschrieben wurde, durchgeführt. Die Bewertungsergebnisse weiterer Unternehmensperspektiven wie „Produkt“ und „Organisation“ sind im nächsten Abschnitt gezeigt. Die Vorgehensweise bei ihrer Ermittlung ist identisch.

9.3

Lösungsbaustein 2: Bewertung der PDMS-Fähigkeit

313

Abb. 9-19 Aktivitätenmatrix der Unternehmensperspektive „Prozess“ für den Beispielprozess „Erzeugung von Mustern“ (Ausschnitt)

In Abb. 9-19 ist ein Ausschnitt aus der Aktivitätenmatrix „Prozess“ dargestellt. Die Zuordnung der operativen Ziele zu den einzelnen Kriterienclustern der Bewertungskataloge zeigt Tabelle 9-1. So können die operativen Ziele „Senkung der Fehlerquote um 10%“ und „Senkung der Durchlaufzeit auf max. 4 Tage“ dem Kriteriencluster „Komplexitätsgrad“ zugeordnet werden. Dabei wurde angenommen, dass eine geringere Prozesskomplexität, wie sie bspw. durch eine eindeutige Definition der Abläufe oder der Zusammenfassung von mehreren Prozessschritten erreicht werden kann, die beiden Ziele deutlich positiv beeinflussen. Die Kriteriencluster werden in die AM-Spalte „Bewertungskriterien“ eingetragen. Die einzelnen Gewichtungsfaktoren von 0,24 bzw. 0,22 wurden mit Hilfe der Präferenzmatrix für jedes einzelne Ziel im ersten Arbeitsschritt ermittelt. Die (relativen) Gewichtungsfaktoren des Kriterienclusters „Komplexitätsgrad“ ergeben sich auf dieser Zielstufe der Nutzwertanalyse (NWA) aus der Summe der normierten Gewichtungsfaktoren. Die zeigt die rechte Spalte in Tabelle 9-1. Bei der Zuordnung der anderen Ziele zu ihren Kriterienclustern und der Ermittlung ihrer Gewichtungsfaktoren wird ebenso verfahren. Eine detaillierte Beispielrechnung für den Mustererzeugungsprozess findet sich in Abschn. 7.8.

314

9 Fallbeispiel

Tabelle 9-1 Ermittelte Bewertungskriterien, zugeordnete Kriteriencluster und Gewichtungsfaktoren für den Teilprozess „Erzeugung von Mustern“ operatives Ziel

(normierter) GF

Kriteriencluster

Senkung der Fehlerquote um 10% (durch ModellEigenpflege)

0,24

Senkung der Durchlaufzeit auf max. 4 Tage

0,22

Komplexitätsgrad

Steigerung der Prozesstransparenz

0,21

Flexibilitätsgrad

Erstellung eines flexiblen Prozessmodells

0,13

Detaillierungsgrad

(relativer) GF

Komplexitätsgrad 0,46

0,21

0,26

Senkung der Mustererstellungskosten

0,13

Detaillierungsgrad

Reduzierung der Prozesschnittstellen

0,07

Grad der Interprozessverflechtung

0,07

Im nächsten Schritt wurden aus dem Kriteriencluster „Komplexitätsgrad“ diejenigen Bewertungskriterien konkret bestimmt, deren Manipulation die beiden Ziele am nachhaltigsten beeinflusst. Dabei besteht jeder Kriteriencluster aus einer Sammlung spezifischer Bewertungskriterien für die PDMS-Einführung (vgl. hierzu Abschn. 7.5). Wie bereits beschrieben, waren dies für die betrachteten Ziele „Senkung der Fehlerquote“ und „Senkung der Durchlaufzeit“ die Kriterien x Anzahl der Teilprozesse mit einem relativen Gewichtungsfaktor von 0,5, x Anordnung der Aktivitäten mit einem relativen Gewichtungsfaktor von 0,25 und x Anzahl beteiligter Rollen mit einem relativen Gewichtungsfaktor von 0,25. Diese relativen Gewichtungsfaktoren für jedes einzelne Bewertungskriterium wurden durch den Anwenderworkshop in Arbeitsschritt 1 ermittelt. Mit diesen Daten konnten anschließend die absoluten Gewichtungsfaktoren nach Gl. (7.2) errechnet werden. Sie sind notwendig, um später den augenblicklichen Reifegrad des betrachteten Mustererzeugungsprozesses

9.3

Lösungsbaustein 2: Bewertung der PDMS-Fähigkeit

315

zu ermitteln und aus diesem Wert eine Aussage über die augenblickliche Implementierungseignung in das PDMS zu gewinnen. Jedes Bewertungskriterium sowie seine beiden Gewichtungsfaktoren (normiert und relativ) wurden in die Perspektiven-Wertetabelle eingetragen (siehe Abb. 7-13). 9.3.3 Durchführung des Arbeitsschritts C Jedes Bewertungskriterium wird anhand einer typischen Eigenschaftsgröße beschrieben. Dabei muss es sich um eine Eigenschaftsgröße handeln, die das Kriterium einerseits hinreichend genau beschreibt und andererseits erfassbar ist. Bspw. kann das Bewertungskriterium „Anzahl der prozessbeteiligten Rollen“ beschrieben werden, indem die prozessbeteiligten Rollen gezählt werden. Das Bewertungskriterium „Eindeutigkeit der Prozessdaten“ kann anhand der Anzahl vorhandener Referenzierungen zwischen den erfassten Datenobjekten charakterisiert werden. Es wird deutlich, dass an dieser Stelle auf die Ergebnisse der IST- Analyse und der D&I-Flüsse aus dem zweiten Arbeitsschritt zurückgegriffen wird. Anhand der PDMSWerteskala, die in Abschn. 7.3.1 beschrieben wurde, wird jeder Einflussgröße ihre entsprechende Maßzahl zugeordnet. Damit kann der Kriterienwert für jedes Bewertungskriterium nach Gl. (7.3) berechnet werden. Der Perspektiven-Reifegrad ergibt sich nach Gl. (7.4) durch die Addition aller Kriterienwerte auf der untersten Zielstufe der durchgeführten NutzwertAnalyse. Die vollständig ausgefüllte Wertetabelle für den Beispielprozess zeigt Abb. 9-20. Der Perspektiven-Reifegrad für den Prozess „Erstellung von Mustern“ liegt bei RGMusterprozess = 2,87. Er ist somit der Prozessklasse „Regelprozess mit hohem Flexibilitätsanteil“ zuzuordnen. Damit ist er in seinem analysierten Ablauf zur Umsetzung in ein PDMS geeignet. Nach Tabelle 4-1 sind jedoch umfangreiche Verbesserungsmaßnahmen erforderlich. So müssen bspw. die Anzahl der beteiligten Rollen reduziert oder ein standardisierter Prozessablauf geschaffen werden, der von dem bearbeitenden Mitarbeiter entkoppelt ist (siehe Abb. 7-14).

316

9 Fallbeispiel

Abb. 9-20 Vollständig ausgefüllte Wertetabelle für den Beispielprozess „Erzeugung von Mustern“

Bei der Bestimmung der anderen Perspektiven-Reifegrade ist die Vorgehensweise mit der beschriebenen identisch. In dem durchgeführten Projekt wurden sie nicht detailliert ermittelt, sondern aus Zeitgründen auf der Grundlage der IST-Analyse extrapoliert. Die zugehörigen Aktivitätenmatrizen für die Unternehmensperspektiven Produkt und Organisation zeigen die Abb. 9-21 und 9-22. Die zugehörigen Produkt- bzw. Rollenklassen finden sich in Abschn. 7.6.

9.3

Lösungsbaustein 2: Bewertung der PDMS-Fähigkeit

317

Abb. 9-21 Vollständig ausgefüllte Aktivitätenmatrix der Unternehmensperspektive „Produkt“ für das Beispielprodukt „Radialventilator“

Der Perspektiven-Reifegrad für die Eignung der vorhandene IT-Landschaft wurde anhand der vereinfachten Vorgehensweise, wie sie in Abschn. 7.5 beschrieben wurde, überschlägig berechnet. Ihre ermittelten Werte lagen für die IT-Perspektive sowie für die Finanz-Perspektive bei 2,25, für die Produkt-Perspektive bei 3,0 und für die Rollenperspektive bei 3,25. Mit diesen Werten ergab sich nach Gl. (7.1) ein IST-PDMS-Reifegrad von

RGPDMS , IST

0,2 ˜ (2,25  2,25  2,885  3,0  3,25) 2,73

(9.1)

Nach Tabelle 4-1 war das Unternehmen zu diesem Zeitpunkt PDMS-fähig, jedoch waren umfangreiche Verbesserungsaktivitäten innerhalb der einzelnen Unternehmensperspektiven erforderlich. Als SOLL-Konzept wurde das Umsetzungsszenario 3 mit einem ermittelten SOLL-PDMS-Reifegrad von RGPDMS,SOLL = 2,3 favorisiert. Die Auswahl geschah durch das Projektteam und die Geschäftsleitung auf der Grundlage der IST-Analyseergebnisse, der Wirtschaftlichkeitsberechnung sowie den definierten Anforderungen.

318

9 Fallbeispiel

Abb. 9-22 Vollständig ausgefüllte Aktivitätenmatrix der Unternehmensperspektive „Organisation/Rolle“ für den Technischen Bereich

Die Vorgehensweise zur Ermittlung der SOLL-PDMS-Fähigkeit ist mit derjenigen zur Ermittlung der IST-PDMS-Fähigkeit identisch. Aus diesem Grund wird an dieser Stelle auf die genaue Herleitung der Zahlenwerte nicht eingegangen. 9.3.4 Durchführung des Arbeitsschritts D

Die Ermittlung des vorhandenen Verbesserungspotenzials basiert auf den Gewichtungsfaktoren und den Kriterienwerten jedes Bewertungskriteriums. Durch eine Schwachstellenanalyse konnten diejenigen Maßnahmen identifiziert werden, die den größten Einfluss auf eine Reifegradverbesserung besaßen und zur Demonstration des Systemnutzens zuerst durchgeführt werden sollten. Die durchgeführte Schwachstellenanalyse zur Verbesserung von RGMusterprozess ist in Abb. 9-23 gezeigt. Die nachfolgend beschriebenen Verbesserungsmaßnahmen wurden während der Pilotphase in Form eines Business Process Reengineerings umgesetzt.

9.3

Lösungsbaustein 2: Bewertung der PDMS-Fähigkeit

319

Abb. 9-23 Vollständige Schwachstellenanalyse für den Beispielprozess „Erzeugung von Mustern“

Ein hohes Verbesserungspotenzial wurde in der Reduzierung beteiligter Rollen umgesetzt, indem Verantwortlichkeiten bestimmter Prozessaktivitäten wie bspw. die Musterauslieferung aus dem Technischen Bereich dem Musterbeauftragten zugeordnet wurden. Weitere Teilschritte konnten durch einen Workflow automatisiert werden. Dazu wurden die Prozessaktivitäten sowie ihre zugehörigen Eingangs- und Ausgangsdaten auf der Vorgangsebene eindeutig definiert. So wird jede Stückliste händisch als Datei geändert, indem bestimmte Applikationsfunktionalitäten wie „Redlining“ oder „Drag&Drop“ in den Prozessablauf eingebunden wurden. Damit wurde die Fehlerquote bei der Datenübertragung zwischen den einzelnen Unterlagen nahezu eliminiert. Gleichzeitig wurde dadurch die Anzahl der Medienbrüche reduziert und die Durchgängigkeit der D&I-Flüsse erhöht. Die Durchlaufzeit bei der Mustererstellung sank von durchschnittlich drei Wochen auf vier Tage. Die Daten aller Musterprojekte wurden mit entsprechenden Referenzierungen versehen und in einem speziellen Projektordner gespeichert. Damit waren sie für die prozessbeteiligten Mitarbeiter im System verfügbar.

320

9 Fallbeispiel

Aufgrund der durchgeführten Verbesserungsmaßnahmen ergab eine erneut durchgeführte Analyse der Perspektiven-Fähigkeit den verbesserten Reifegrad RGMusterprozess von 2,17. In der Pilotphase wurde der Schwerpunkt auf die Überarbeitung des Mustererstellungsprozesses gelegt. Eine Überarbeitung der anderen Unternehmensperspektiven fand aus Zeit- und Kostengründen nicht statt. Auf dieser Grundlage ergab sich nach der Pilotphase der verbesserte IST-PDMSReifegrad RGPDMS,IST = 2,56. Damit wurde der gewünschte SOLL-PDMSReifegrad nicht erreicht. Zu seiner Erreichung war die Umsetzung entsprechender Verbesserungsmaßnahmen in den anderen Unternehmensperspektiven zwingend notwendig. Dies wurde dem Management in der Abschlusspräsentation empfohlen.

9.4 Der Business Case Am Ende des vierten Arbeitsschritts wurde der Business Case dem Unternehmensmanagement im Rahmen einer Präsentation vorgestellt. Er sollte die Entscheidung hinsichtlich der unternehmensweiten PDMSystemeinführung unterstützen. Der Business Case, welcher dem Unternehmensmanagement auch in schriftlicher Form durch den Projektpaten übergeben wurde, hatte folgende inhaltlichen Schwerpunkte: x Die Zusammenfassung der Ergebnisse des Business Case in einem Management Executive Summary. Hierbei wurde eine Systemeinführung in Hinsicht auf die mittelfristige Unternehmensentwicklung im globalen Wettbewerb empfohlen. Aufgrund der ermittelten CSC-PerspektivenReifegrade wurde jedoch auch auf die Notwendigkeit der Umsetzung von Verbesserungsmaßnahmen besonders in den Perspektiven „Produkt“ und „Organisation“ hingewiesen. x In der Einführung wurde die augenblickliche allgemeine Unternehmenssituation beschrieben, welche zur Initiierung des PDMS-Projekts geführt hatte. Ebenso wurden die Inhalte und die Ziele des PDMS-Projekts kurz zusammengefasst, da diese die Grundlage des Business Case bildeten. x Anschließend wurden im Abschnitt Methoden und Annahmen der ermittelte IST-Zustand sowie das gewählte Umsetzungsszenario beschrieben. Ebenso wurden die gewählten methodischen Vorgehensweisen und Annahmen erläutert. Besonders bedeutsam war die Definition der verwendeten finanziellen Kennzahlen. Sie wurden mit dem Controlling abgestimmt.

Der Business Case

321

x Die eigentliche Wirtschaftlichkeitsbetrachtung wurde im vierten Abschnitt durchgeführt. Sie beinhaltet die Vorstellung der erwarteten Kosten und Nutzenpotenziale. Während sich die Kosten vergleichweise einfach ermitteln ließen, wurden die erwarteten Nutzenpotenziale aus den Erfahrungen der Pilotphase extrapoliert. x Mögliche Risiken und Abschätzungen zukünftiger Entwicklungen wurden im vorletzten Abschnitt behandelt. Dabei wurde besonders auf die erwarteten grundlegenden Auswirkungen auf die bestehenden Unternehmensabläufe hingewiesen. Die Art der Kommunikation mit den Mitarbeitern hinsichtlich der Umsetzung dieser Auswirkungen und der erwarteten Unterstützung im Tagesgeschäft ist von erfolgsentscheidender Bedeutung für die Anwendungsakzeptanz des PDMS. x Der Business Case endete mit einer Zusammenfassung und Empfehlungen bzgl. der weiteren Vorgehensschritte. Aufgrund der gewonnenen Erkenntnisse wurde eine schnelle und mit allen Standorten abgestimmte Systemeinführung innerhalb der nächsten drei Jahre empfohlen. Die erste Einführung sollte in der Unternehmenszentrale geschehen und danach sternförmig auf alle anderen Standorte ausgeweitet werden. Empfohlen wurde eine Lösung, in welcher jeder Standort ein eigenes PDMS besaß; die damit verbundenen Aufwände und Kosten mussten in einem gesonderten Projekt untersucht werden und waren nicht Bestandteil dieses Business Case. Bei den nachfolgenden Beschreibungen wurden aus Gründen der Anonymität Bezeichnungen sowie Zahlenwerte neutralisiert. Ebenso wird auf unternehmenssensible Themengebiete nicht detailliert eingegangen. Zur Durchführung einer Wirtschaftlichkeitsberechnung sei auf [Eigner u. Stelzer 2001] verwiesen. Getroffene Annahmen

Grundlage für den Business Case war der Vergleich zwischen dem ermittelten IST-Zustand des Unternehmens (Szenario 1) und dem zu erreichenden SOLL-Szenario 3. Der zu erwartende Umsetzungsaufwand des jeweiligen Szenarios wird durch seinen PDMS-Reifegrad beschrieben. Im SOLL-Szenario wurde von einer PDMS-Implementierung unter der Annahme ausgegangen, dass alle Anforderungen des Lastenheftes umgesetzt werden können. Bei der vergleichenden Betrachtung mit Szenario 1 wurde angenommen, dass sich hinsichtlich des betrachteten Zeitraums des Business Case von 3 Jahren keine grundlegenden Änderungen in der analysierten Unternehmenssituation ergeben.

322

9 Fallbeispiel

Die ermittelten Potenziale für das Unternehmen sowie die Kostenfaktoren einschließlich ihres stufenweisen Zuwachses, wie sie in der Wirtschaftlichkeitsbetrachtung erscheinen, resultieren aus dem Vergleich zwischen dem IST-Zustand und dem SOLL-Szenario. Der Business Case beginnt mit dem Kick-Off-Meeting der Pilotphase Ende September 2004 und endet Ende September 2007. Weitere getroffene Annahmen waren: x die Systemimplementierung durch das Softwarehaus beginnt Ende September 2004; x alle Mitarbeiter des Technischen Bereichs erhalten während der Pilotphase und in den ersten drei Monaten der Betriebsphase eine Nutzerlizenz; x nach einem Jahr (Ende September 2005) erreicht die PDMSystemnutzung durch sämtliche Anwender die volle Effizienz und Effektivität im Tagesgeschäft; x zu diesem Zeitpunkt ist ein Großteil der gewünschten Nutzenpotenziale erreicht worden; x es finden keine personellen Änderungen im Technischen Bereich statt. Zusätzlich müssen in den Annahmen betriebswirtschaftliche Größen wie der augenblickliche Stundenlohn eines Ingenieurs sowie seine erwartete Lohnentwicklung innerhalb des betrachteten Zeitraums oder die Anzahl der Arbeitstage pro Jahr berücksichtigt werden. An dieser Stelle sei angemerkt, dass diese Liste keinen Anspruch auf Vollständigkeit erhebt und für jedes Unternehmen individuell ermittelt werden muss. Wirtschaftlichkeitsbetrachtung

Die durchgeführte Wirtschaftlichkeitsbetrachtung brachte das Ergebnis, dass dem Management auch unter betriebswirtschaftlichen Gesichtspunkten ein unternehmensweiter Roll-Out des PDMS zu empfehlen war. Grundlage zur monetären Ermittlung der Kosten und der Nutzenpotenziale waren die ermittelten Werte sowie die gewonnenen Erfahrungen aus der Pilotphase. Sie wurden auf die unternehmensweite Systemeinführung extrapoliert und mit in der Literatur vorhandenen Werten, wie sie in Studien von [Höfener 1999; Schabacker 2001; Schabacker 2004; Abramovici 2004] dokumentiert sind, verglichen. Dadurch sollten unrealistische Extrapolationswerte als Grundlage zur Berechnung vermieden werden.

Der Business Case

323

In Abb. 9-24 sind einige Werte für die Unternehmensperspektive „Prozess“ gezeigt.

Abb. 9-24 Extrapolierte Ergebnisse der Pilotphase für die Unternehmensperspektive „Prozess“ (Auszug) [Feldhusen u. Gebhardt 2005]

Die ermittelten Kosten setzten sich aus den Bereichen Software, Hardware sowie Personal und Dienstleistungen zusammen (vgl. hierzu Abschn. 8.4). Berücksichtigt wurden sowohl einmalige als auch laufende Kosten. Kalkulationsgrundlage war neben den getroffenen Annahmen, wie sie im vorherigen Abschnitt beschrieben wurden, auch das Angebot des Softwareherstellers. In Abhängigkeit vom Umfang der Dienstleistungen in Bereichen wie den Service Level Agreements oder dem Unfang der Mitarbeiterschulungen ergaben sich Gesamtkosten zwischen 1 Million Euro und 1,6 Millionen Euro. Diese Kostenspanne ergab sich u. a. aus einem kompletten unternehmensindividuellen Schulungskonzept einschließlich der zugehörigen Unterlagen, einer Betreuung durch mehrere Systemausbilder und einer einjährige Unternehmenshotline seitens des Softwareunternehmens. Auch die Betreuung bei der Systemimplementierung während des Roll-Outs war durch die ständige Anwesenheit eines Systemberaters eingeschlossen. Von besonderer Bedeutung hierbei sind Einsparungen, die in den Gesamtkosten bereits eingerechnet sind: Aufgrund der durchgeführten Arbeitsschritte vor der eigentlichen Pilotphase waren bereits relevante Untersuchungsergebnisse vorhanden, welche das Softwarehaus nicht mehr

324

9 Fallbeispiel

ermitteln musste. Hierbei konnten durch die Mitarbeiter des Unternehmens über 35 Consultant-Manntage eingespart werden. Zusätzlich wurde dadurch eine wertvolle interne Wissensbasis für den weiteren Systembetrieb gelegt. Einige der erwarteten Nutzenpotenziale sind nachfolgend aufgelistet. x Der größte Nutzenfaktor bzgl. der PDMS-Implementierung wurde im Bereich des Collaborative Engineering innerhalb des gesamten Unternehmens einschließlich seiner Standorte gesehen. Er verteilt sich zur Hälfte direkt auf den Einsatz des PDMS, wogegen die andere Hälfte den mit der CSC identifizierten Verbesserungsmaßnahmen wie dem ModellReengineering oder strategischen Managemententscheidungen zugesprochen wird. x Einen weiteren Nutzen betrifft die Mitarbeiterproduktivität. Er basiert auf der Annahme, dass die Mitarbeiterproduktivität des Technischen Bereichs durch die Systemnutzung im betrachteten Zeitraum ansteigt. Die Ursachen für diesen Anstieg liegen in einem verbesserten Variantenmanagement und in einer effizienteren Konstruktionsweise durch die erhöhte Verwendung von Standard- bzw. Wiederholteilen auf der Basis von Referenzprodukten (vgl. Abschn. 4.1). Zusätzlich wird die Mitarbeiterproduktivität durch ein effizienteres persönliches Projektmanagement sowie durchgängige Daten- und Informationsflüsse signifikant beeinflusst. x Die verbesserten Daten- und Informationsflüsse führen zu einer Steigerung der gesamten Wertschöpfung in sämtlichen Abteilungen entlang des PEP. Zusätzlich wird dies durch die Einbindung von Abteilungen wie dem Vertrieb, dem Service und den beteiligten Zulieferern unterstützt. Dieses Nutzenpotenzial resultierte v. a. aus einer Eliminierung der Schnittstellenbrüche zwischen den Abteilungen, den Standorten und den Zulieferern des Unternehmens. x Aufgrund einer frühzeitigen Fehlererkennung wird eine deutliche Verlagerung von Produktänderungen in die frühen Phasen des PEP erwartet. Dieses Nutzenpotenzial entfaltet jedoch nur seine volle Wirkung, wenn ein durchgängiges und effizientes Änderungsmanagement entlang des gesamten PEP umgesetzt wird. Dies kann mittels eines standardisierten Systemworkflows geschehen. Damit der Änderungsprozess seinen vollen Nutzen entfalten kann, muss er abteilungs- und standortübergreifend eingeführt werden. Weitere Nutzenpotenziale wurden in einem verbesserten abteilungs- bzw. standortübergreifenden Projektmanagement aufgrund einer zielgerichteteren Kommunikation sowie in der Reduzierung der PEP-

Der Business Case

325

Durchlaufzeit gesehen. Diese Reduzierung kann jedoch nur erreicht werden, wenn zusätzlich auch entsprechende Ablaufänderungen in allen am Entwicklungsprozess beteiligten Unternehmensabteilungen umgesetzt werden. Die Einsparungen aufgrund der beschriebenen Nutzenpotenziale wurden im Bereich zwischen 2,5 Millionen und 3 Millionen Euro im betrachteten Zeitraum von drei Jahren angenommen. Grundlage hierfür war die Betrachtung einer idealen Umsetzung des gewünschten SOLL-Szenarios. Dem gegenüber standen Einschränkungen bei den getroffenen Annahmen wie die reibungslose, standortübergreifende Einführung des Änderungsprozesses oder ein längerer Zeitraum hinsichtlich der prognostizierten Mitarbeiterproduktivität. Ebenso war eine wesentliche Voraussetzung die erfolgreiche Umsetzung der Referenzprodukt-Strategie. Anhand des Business Case konnte ein erwarteter, hoher Mehrwert für das Unternehmen durch die PDM-Systemeinführung nachgewiesen werden. Zusammen mit den Ergebnissen der Pilotphase sprachen beide Projektleiter eine deutliche Empfehlung für die Aufnahme der Systembetriebsphase aus. Damit der Mehrwert durch die PDMS-Einführung auch auf strategischer Ebene gegenüber Mitbewerbern auf dem Markt Auswirkungen zeigte, wurde u. a. die Durchführung folgender Verbesserungsmaßnahmen empfohlen: x Redefinition des gesamten betrachteten Prozesses „Erzeugung von Varianten“ als Grundlage für die Redefinition anderer Geschäftsprozesse. Bspw. war es möglich, Prozessschritte zur Erstellung der Stückliste auf der Grundlage der CAD-Modellstruktur zusammenzufassen. Die erwarteten Auswirkungen waren eine Minimierung des Fehlerpotenzials gegenüber der bisherigen händischen Erstellung und eine signifikante Beschleunigung der Prozess-Durchlaufzeit für den Kunden. x Abgestimmte Einbettung des betrachteten Prozesses in den übergreifenden PEP. Da aufgrund der Firmenphilosophie möglichst jeder Kundenwunsch bei einem schnellen „Time-to-market“ und bei gleichzeitig adäquaten Preisen für das Unternehmen erfüllt werden soll, ist die frühzeitige Abstimmung mit Abteilungen wie der Mustererstellung, der Betriebsmittelerstellung oder dem Einkauf bedeutsam. Dadurch erhielt der Variantenerzeugungsprozess den Status eines Kernprozesses innerhalb der Produktentwicklung, da mit diesem ein wesentlicher Aspekt der Unternehmensphilosophie umgesetzt wurde. Diese Verbesserungsmaßnahme entfaltet jedoch erst ihr gesamtes Potenzial, wenn effektiv auf bereits vorhandene Endgeräte, Produktele-

326

9 Fallbeispiel

mente oder Werkzeuge durch den betreffenden Konstrukteur zurückgegriffen werden kann. x Erstellung von Referenzprodukten mittels Umsetzung der Referenzprodukt-Strategie. Mit dieser Maßnahme in Verbindung mit der abgestimmten Prozesseinbettung wurde eine deutliche Erhöhung des Anteils der verwendeten Wiederholteile bzw. Standardbauteile erwartet. Dies wurde als wesentlicher Schritt zur gewünschten Entkopplung der internen (Bauteil-)Vielfalt und der externen (Produkt-)Vielfalt gesehen. x Anpassung der vorhandenen Aufbauorganisation. Hier wurde die dringende Empfehlung gegeben, einen hauptverantwortlichen BusinessAdministrator für die PLM-Strategie einzustellen (bzw. aus dem Pilotteam auszubilden) und dafür die entsprechende Stellenvoraussetzung zu schaffen. Zusätzlich betrifft diese Maßnahme die eindeutig definierte Zuweisung von Rollen einschließlich ihrer Berechtigungen zu den einzelnen Produktdaten und Prozessabläufen in Abhängigkeit der Lebenszyklusphase des Produkts. Die Geschäftsleitung leitete nach Abschluss des beschriebenen PDMSProjekts eine weitere Pilotphase ein. Auf der Grundlage der vorhandenen Analyseergebnisse und der vorhandenen Mitarbeitererfahrung wurde ein Systembenchmark mit dem PLM-Modul der vorhandenen ERP-Software initiiert. Eine Entscheidung hinsichtlich der endgültigen Systemauswahl und des weiteren Vorgehens steht augenblicklich noch aus. Da die IT-Abteilung ihrerseits begonnen hat, PDMS-Funktionalitäten in vorhandene Softwareapplikationen zu programmieren, gleicht die augenblickliche Situation innerhalb des Technischen Bereichs einer Mischform zwischen den beiden ersten Umsetzungsszenarien. Aus diesem Grund wurde das ursprüngliche Ziel der Variantenbeherrschung nicht in vollem Umfang erreicht.

9.5 Zusammenfassung Kapitel 9 Die Beschreibung der praktischen Anwendung beider Lösungsbausteine des PDMS-Regelkreises anhand eines anonymisierten Industrieprojekts bildet den Inhalt dieses Kapitels. Der Kapitelaufbau ist am bisherigen Buchaufbau angelehnt. Zunächst wurde das betrachtete mittelständische Unternehmen charakterisiert und die Abläufe während der Vorklärungsphase geschildert. Das Ergebnis war die Initiierung des PDMS-Projekt mit der Unterstützung eines

9.5

Zusammenfassung Kapitel 9

327

auf PDMS-Einführungen spezialisierten Hochschulinstituts. Anschließend sind die Vorgänge und die Ergebnisse bei der Systemeinführung beschrieben. Dies geschieht anhand der einzelnen Arbeitsschritte innerhalb der Untersuchungs- und der Umsetzungsphase. Die Ergebnisse jedes Arbeitsschritts wurden während des PDMS-Projekts permanent auf den Grad ihrer Zielerfüllung mittels der Capability Scorecard gemessen. Hierzu wurden die IST-PDMS-Fähigkeit des Unternehmens und die SOLL-PDMS-Fähigkeit des gewünschten Umsetzungsszenarios ermittelt. Damit das gewünschte Umsetzungsszenario nach der Systemeinführung auch erreicht werden kann, wurden entsprechende Verbesserungsmaßnahmen ermittelt. Dies geschah durch die Anwendung der Nutzwert- und der Schwachstellenanalyse. Den Abschluss des Kapitels bildet die auszugsweise Beschreibung des Business Cases einschließlich grundlegender Ausführungen zur Wirtschaftlichkeitsbetrachtung. Das Ergebnis zeigt, dass der PDMS-Regelkreis die Unternehmensanforderungen erfüllt. Einerseits werden durch die PDMS-Einführungsmethodik die notwendigen Bewertungsdaten identifiziert, andererseits lassen sich durch die Bewertung aussagekräftige Werte für die Reifegrade und die Verbesserungsmaßnahmen ableiten. Sie werden direkt während der Systemeinführung umgesetzt und beeinflussen die ermittelten Reifegrade. Damit findet das begleitende Projektcontrolling statt. Literatur Abramovici M (2004) Benefits of PLM, Studie des ITM, Universität Bochum Eigner M, Stelzer R (2001) Produktdatenmanagement-Systeme - ein Leitfaden für Product Development und Life Cycle Management. Springer, BerlinHeidelberg-New York Feldhusen J, Gebhardt B (2005) Ein Beitrag zur Bewertung der PDMS-Fähigkeit eines Unternehmens - die Capability Scorecard. In: Informations- und Wissensdrehscheibe Produktdatenmanagement. GITO, Berlin Höfener C (1999) Methode zur Bewertung des strategischen Nutzens von integrierten Produktdaten-Management (PDM). Shaker, Aachen Schabacker M (2001) Bewertung der Nutzen neuer Technologien in der Produktentwicklung. Dissertation, Technische Universität Magdeburg Schabacker (2004) Sprungbrett für den Mittelstand. In: AutoCAD-Magazin 6/04. WIN-Verlag, Vaterstetten

Sachwortverzeichnis

Abschlussbericht 115 Akteur 71 Aktivität 70, 126 Aktivitätenmatrix 190 Finanzen 273 Organisation/Rolle 318 Produkt 317 Prozess 192, 312 Änderungsmanagement 324 Anforderungen an die Pilotphase 174 Anforderungen an eine PLMStrategie 34 Anforderungsliste 61, 115, 205 ARIS 70, 159 Attribut 67 Aufwand 204 Ausgangsdaten 70 Ausstiegsszenario 178 Balanced Scorecard 190 Baukasten 9, 27, 37 Baureihe 27 Baustruktur 39 Benchmark 100, 201 Betriebsphase 83, 179 Kennwerte 180 Bewertungsdurchführung 199 Bewertungsklasse Finanzklasse 222 IT-Systemklasse 222 Produktklasse 220 Prozessklasse 218, 315 Rollenklasse 221 Bewertungskriterien 199, 314 Bewertungskriteriencluster 204, 313

Unternehmensperspektive IT 212 Unternehmensperspektive Organisation/Rolle 211 Unternehmensperspektive Produkt 211 Unternehmensperspektive Prozess 207 Business Case 10, 192, 250, 320 Business-Administrator 164, 303, 308 Capability Scorecard 6, 97, 189 qualitative Bewertung 117 Computational Fluid Dynamics 62 Concurrent Engineering 174 Controllingprozess 25 CSC-Aufnahmeblatt 194 Customzing 221 Daten- und Informationsflüsse 5, 65, 133, 192, 239 Daten- und Informationslandkarte 135, 151, 156 Daten- und Informations-Liste 131, 151, 155 Datenkonsistenz 254 Datenmigration 179 Datenobjektstatus 160 Datenschwerpunkt 68, 152 Design-to-Cost 1 Eigenschaftsgröße 197, 215, 315 Eingangsdaten 70 Entwicklungs- und Konstruktionsprozess 35, 62 ERP-System 77

330

Sachwortverzeichnis

erweiterter Produktentstehungsprozess 24 EXPRESS 155 Fehler-Möglichkeiten und EinflussAnalyse 142 Finite Elemente Methode 62 Flussdiagramm 70, 156 Funktionspool 53 Funktionsstruktur 39 Funktionsträger 39 ganzheitlicher ReengineeringAnsatz 28 Gesamtfunktion 39, 40 Geschäftsprozesse 17 Gewichtung 197 absoluter Gewichtungsfaktor 200, 209, 314 relativer Gewichtungsfaktor 200, 209, 313 Globalisierung 1, 14 Häufigkeit-Aufwands-Matrix 302 Hauptaspekte von PLM 21 Hauptunternehmenselement 9, 22, 32 Anforderungen 35 Organisation 9, 22 Produkt 9, 22 Prozess 9, 22 Identnummer 60 Informationskonzept 98 Innovationswettbewerb 1 Interviewfragebogen 125, 128 Investitionskennzahlen Amortisationsdauer 269 Cash-Flow 271 EBIT 271 Kapitalwert 267 Methode des internen Zinsfusses (IRR) 270 Net Present Value (NPV) 267 Rentabilität/Rendite 271

Return on Investment (RoI) 16, 268 IST-Analyse 124, 205, 294 IT-Analyse 131 IT-Architektur 308 IT-Landschaft 10 IT-Systemlandkarte 133, 192 Kennzahlen 25 Klassifizierung 67 Kompetenzpool 53 Komplexität 20 Komplexitätsfalle 19 Komplexitätstreiber 21 Konfigurationsmanagement 25 Kontinuierlicher Verbesserungsprozess 85, 98, 183 Kosten 258, 323 Betriebskosten 261 direkte Kosten 256 einmalige Kosten 259 Einsparungskosten 260 Gesamtkosten 257 indirekte Kosten 257 Initialkosten 261 laufende Kosten 260 Personalkosten 259 Sachkosten 259 Kostenmanagement 245 Kosten-Nutzen-Analyse 256 Kosten-Nutzen-Regelkreis 141 Kostentreiber operative Kostentreiber 265 strategische Kostentreiber 264 Kundenbestellvorgang 61 Lastenheft 170, 205 Lebenszyklus-Gate 160 marktgerechte Optimierung 58 Marktpräsenz 2 Marktstrategie 27 Maßzahl 197, 215 mechatronisches Produkt 43, 258 elektrische/elektronische Komponente 43

Sachwortverzeichnis mechanische Komponente 43 softwaretechnische Komponente 43 Mehrkörpersimulation 62 Meilenstein-Konzept 125, 126 MES-System 77 Modell CAD-Modell 68 Modellanforderungen 73, 147 Modellanpassung 310 Produktdatenmodell 67, 150, 192, 300 Prozessmodell 67, 69, 155, 192, 303 Rolle 71 Rollenkonzept 71 Rollenmodell 67, 71, 162, 192, 299 Modell-Reengineering 125, 150, 299 Business Process Reengineering 157, 226, 305, 318 Produkt-Reengineering 162 Modul 9, 38 Modularisierung 9 Modularisierungsgrad 37 Modularität 37 Multi-Life-Produkt 35, 40, 148 Nutzen 141, 204 allgemeines Nutzenpotenzial 252 individuelles Nutzenpotenzial 254, 324 monetär messbares Nutzenpotenzial 255 monetär nicht messbares Nutzenpotenzial 255 monetärer Nutzen 247 nicht-monetärer Nutzen 247 nicht-strategischer Nutzen 260 Nutzenquantifizierung 252 strategischer Nutzen 260 nutzengerechte Optimierung 58 Nutzwertanalyse 197 Zielbereich 198 Zielstufe 199

331

Zielsystem 198 Operationalisierbarkeit 33 operative Maßnahmen 25 Organisation Linienorganisation 54 Matrixorganisation 52 Organisationseinheit 52 PDMS-Bewertungskriterien 197 Finanzen 273 IT 212 Kriterienwert 197, 201, 217 Organisation/Rolle 211 Produkt 211 Prozess 207 PDMS-Einflussgrößen 10, 86, 95, 189 PDMS-Einführungsmethoden 91 PDMS-Fähigkeit 9, 84, 189 IST-PDMS-Fähigkeit 84, 94, 239 qualitative PDMS-Fähigkeit 118, 204, 255, 312 SOLL-PDMS-Fähigkeit 84, 94, 144, 239 PDMS-Projekt 83, 104 Auslöser 105, 114 Kernteam 106, 288 Lenkungsausschuss 106 PDMS-Projektkosten 111, 259 Pilotphase 111, 306 Pilotteam 108, 171 Projektleiter 105 Projektmanagementteam 105 Projektorganisation 105 Projektpate 106 Projektressourcen 116, 224, 238 Projekttreiber 105 Umsetzungsphase 111, 239, 299 Untersuchungsphase 110, 239, 290 Vorklärungsphase 109, 287 PDMS-Regelkreis 10, 95, 257 Abbruchkriterium 96 Bausteine 96

332

Sachwortverzeichnis

PDMS-Regelkreisiteration 96, 217 PDMS-Reifegrad IST-PDMS-Reifegrad 317 PDMS-Reifegrad 9, 84, 95, 189, 199, 224 Perspektiven-Reifegrad 85, 197, 199, 201, 217, 315 SOLL-PDMS-Reifegrad 317 PDMS-Unternehmensauswirkungen 251 PDMS-Werteskala 215 Perspektiven-Wertetabelle 217 Pilotphase 108, 171 Pilotsystem 83, 172 Plattformprodukt 42 PLM-Fragestellungen 5 Polardiagramm 194 Präferenzmatrix 118, 120, 200 Preiswettbewerb 1 Product Lifecycle Management 3, 20 Produkt evolutionäres Produkt 58 modulares Produkt 58 Produktarchitektur 35, 39 Produktart 27 Produktarten 9, 37 Produktausprägungen 35 Produktdaten 18, 65, 151 Produktdatenmanagement-System 3, 74 Auscheckvorgang 75 Business-Administrator 108 Datenbanken 75 Datenbankmanagementsystem 75 Datenobjekt 75 Eincheckvorgang 76 Metadaten 75 System-Administrator 108 Systemanforderungen 78 Systemarchitektur 75 Systemfunktionalitäten 75, 77 Systemworkflows 159 Vault 75 Produkteigenschaft 41

Produktentstehungsprozess 17, 31 Produktgruppe 59 Produktionsvorbereitungskosten 2 Produktlebenszyklus 65 Produktplanungssystem 60 Produktplattform 27, 42 Produktstruktur 39 Produktvariante 18, 19 Produktvielfalt 20 Produktwissen 4 produktzentrierter Ansatz 6 Projektcontrolling 9, 92, 237 CSC-Projektcontrolling 239 klassisches Projektcontrolling 238 Projektplan 115, 175 Projektumsetzungsmatrix 194 Prototyp realer Prototyp 62 virtueller Prototyp 62 Prozess 4 Gesamtprozess 49, 70 Geschäftsprozess 126 nicht variables Prozessmodul 51 Prozess-Gate 126 Prozessmodul 49, 64 Prozessschritt 70, 126 Referenzprozess 51 Standardprozess 51, 63 Steuerungsgröße 71 technischen Ebene 156 Teilprozess 70, 126 Teilprozessebene 162 variables Prozessmodul 51 Vorgangsebene 125, 156, 162 Workflowebene 162 Prozessaufnahmeblatt 125, 127 Rollen-Organisations-Matrix 128 Prozessdaten 65 Prozesskostenrechnung 265 Qualitätsmanagement 101 Quick Wins 120 Rangfolgeverfahren 122 Referenzierung 67, 151, 301

Sachwortverzeichnis Referenzprodukt 9, 58 Referenzprodukt-Strategie 9, 58, 221 Referenzprozess 63 Referenzstruktur 60, 63 Risiken 142, 277 Rolle 67, 159 Lebenszyklusphase 160 Rollenkonzept 164 Rollenpool 162 Standardrolle 159 Zugriffsberechtigung 160 SADT-Diagramm 70 Schnittstelle 44 offene Schnittstelle 62 Organisationsschnittstelle 53 Produktschnittstelle 61 Prozessschnittstelle 50 Systemschnittstelle 77 Schnittstellenmanagement 26 Schulungsgrundlage 73 Schulungskonzept 98, 170, 309 Schwachstellenanalyse 200, 202, 223, 318 Simultaneous-Engineering 174 Softwareversion 49 SOLL-Konzept 136, 205, 248 PDMS-Einführungsszenarien 136 SOLL-Szenario 298 Standardisierung 46, 254 Standardisierungspotenzial 302 Strategie, allgemein 32 strategischer Teufelskreis 3 Stückliste 60 Superuser 310 System-Administrator 165, 308 Systemanpassung 310 System-Breitenanwendung 179 Systemdurchdringungstiefe 172 System-Pilotimplementierung 176 System-Roll-Out 179 Systemumsetzungsaufwand 172 Szenariotechnik 136

333

Target-Costing 1 Technologiewettbewerb 1 Teilfunktion 39 Teilprozesse 17 Time-to-market 16 Total Cost of Business Opportunity (TCBO) 271 Total Cost of Ownership (TCO) 263 Total Value of Opportunity (TVO) 271 UML 155, 159 Umsetzungsaufwand 141 Umsetzungsphase 145 Unternehmensanforderungen an eine PDMS-Einführung 79 Unternehmenshistorie 33 Unternehmenskomplexität 8 externe Unternehmenskomplexität 14 interne Unternehmenskomplexität 16 Maßnahmen zur Beherrschung der Unternehmenskomplexität 26 Unternehmensleitbild 23, 203 Unternehmensperspektive 190, 198 Finanzen 191, 247, 273 IT 192 Organisation 192 Produkt 191 Prozess 192 Unternehmensstrategie 22 Unternehmensvision 23, 33 Unternehmenswissen 3, 58 Untersuchungsphase 115 Ursache-Wirkungs-Prinzip 275 variable Baugruppen 59 variables Bauteil 59 Variante 18, 59 Produktvariante 18, 62 Prozessvariante 18 unveränderte Variante 60 Variantentypen 302 vorgedachte Variante 60

334

Sachwortverzeichnis

Variantenmanagement 58 Verbesserungsaktivität 85, 223 Verbesserungsmaßnahmen 96, 194, 197, 202, 325 Verbesserungspotenzial 215, 223 Vielfalt externe Vielfalt 16 interne Vielfalt 16 Vorgehensweise zur... 10 Bewertung des Zielereichungsgrads 99 Durchführung der Prozesskostenrechnung 265 Erhebung von Wirtschaftlichkeitsbetrachtungen 248 Ermittlung des PDMS-Reifegrads 10, 196 Erstellung eines Produktdatenmodells 150 Erstellung eines Prozessmodells 155 Erstellung eines Rollenmodells 162 Optimierung der externen Produktvielfalt 58 PDMS-Einführung 10, 99, 103 unternehmensindividuellen Erstellung einer PLM-Strategie 23 Vorklärungsphase 113

Was-Matrix 166 Wer-Matrix 168 Werteprofil 202, 224 wirtschaftlicher Unternehmenserfolg 275 Wirtschaftlichkeit 10, 246 Wirtschaftlichkeitsberechnung 87 Wirtschaftlichkeitsbetrachtung 245, 322 Wissensspeicher 63 Workflow 159 Zielcontrolling 171 Ziele 10, 141 Definition der Zielsetzungen 115, 196 operative Ziele 24, 117, 204, 275, 293 strategische Ziele 22, 116, 203, 275, 286 Unternehmensleitziel 203 Zielanpassung 183 Zielpriorisierung 118 Zielerfüllungsgrad 83, 207, 238 Zielgröße Kosten 258 Qualität 258 Zeit 258