Prozessorientiertes Product Lifecycle Management 3540284427, 9783540284420, 1280620102, 9781280620102 [PDF]

Zitiervorschau

Prozessorientiertes Product Lifecycle Management

August-Wilhelm Scheer · Manfred Boczanski Michael Muth · Willi-Gerd Schmitz Uwe Segelbacher

Prozessorientiertes Product Lifecycle Management Mit Beiträgen von Andrea Cocchi, Claudia Herzog, Ingo Kern, Harald Okruch Alexander Schadenberger, Bruno Schilli, Momme Stürken

mit 125 Abbildungen und 3 Tabellen

123

Professor Dr. Dr. h.c. mult. August-Wilhelm Scheer

Dr. rer. nat. Uwe Segelbacher

IDS Scheer AG Altenkesseler Straße 17 66115 Saarbrücken E-mail: [email protected]

BMW AG Helene-Mayer-Ring 4 80788 München

Manfred Boczanski Langenbergstraße 19 46147 Oberhausen Privdoz. Dr.-Ing. habil. Michael Muth IDS Scheer AG Altenkesseler Straße 17 66115 Saarbrücken E-mail: [email protected] Willi-Gerd Schmitz IDS Scheer AG Altenkesseler Straße 17 66115 Saarbrücken E-mail: [email protected]

ISBN-10 3-540-28402-8 Springer Berlin Heidelberg New York ISBN-13 978-3-540-2840-4 Springer Berlin Heidelberg New York Bibliografische Information Der Deutschen Bibliothek Die Deutsche Bibliothek verzeichnet diese Publikation in der Deutschen Nationalbibliografie; detaillierte bibliografische Daten sind im Internet über http://dnb.ddb.de abrufbar. Dieses Werk ist urheberrechtlich geschützt. Die dadurch begründeten Rechte, insbesondere die der Übersetzung, des Nachdrucks, des Vortrags, der Entnahme von Abbildungen und Tabellen, der Funksendung, der Mikroverfilmung oder 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. Springer ist ein Unternehmen von Springer Science+Business Media springer.de © Springer-Verlag Berlin Heidelberg 2006 Printed in Germany 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. Einbandgestaltung: design & production GmbH Herstellung: Helmut Petri Druck: Strauss Offsetdruck SPIN 11543381

Gedruckt auf säurefreiem Papier – 43/3153 – 5 4 3 2 1 0

Vorwort

Globalisierung, steigender Wettbewerbsdruck, kürzere Produktlebenszeiten, zunehmende Bedeutung des Erfolgsfaktors Innovation – alles Gründe für Unternehmen, sich nicht nur mit einer Optimierung ihrer Kerngeschäftsprozesse zu befassen, sondern den Produktlebenszyklus und die Gestaltung von kollaborativer Produktentwicklung zu fokussieren. Dass die Betrachtung des Produktlebenszyklus – will man wirklich Kosteneinsparungspotenziale realisieren – nicht mehr nur rein funktions- oder lösungsorientiert erfolgen darf, ist seit längerem bekannt. Dies zeigt schon der längst vollzogene Übergang vom Begriff des Produkt-Daten-Managements (PDM) zum Produkt-Lifecycle-Management (PLM). Was aber ist eine prozessorientierte Sicht auf den Produktlebenszyklus, und warum ist sie erforderlich? Wie sind die Produktentstehung und andere Kerngeschäftsprozesse im Unternehmen vernetzt? Dies nachvollziehbar und transparent darzustellen, ist Anliegen dieses Buches. Die Autoren der IDS Scheer AG verfügen alle über mehr als 10 Jahre Erfahrung in der Konzeption und Einführung von PLM in den unterschiedlichsten Branchen, deren Besonderheiten aufgezeigt werden: PLM ist längst nicht mehr nur Thema in der Investitionsgüterindustrie, auch Branchen wie Pharma- und Konsumgüterindustrie wissen um die Bedeutung der effizienten Abwicklung und Dokumentation der Prozesse rund um Innovation, Produktentstehung und Time-To-Market. Die Autoren sind sich jedoch bewusst, dass die vorliegenden Prozessdarstellungen keinen Anspruch auf Vollständigkeit oder Allgemeingültigkeit haben. Die Darstellung der Prozesse geschieht auf Basis in ARIS modellierter Referenzmodelle, welche auf individuelle Unternehmen spezifisch anzupassen sind. Darstellungen der PLM-Lösungskomponenten werden meist mit Beispielen aus SAP PLM belegt und konkretisiert. Gerade an dieser Komponente einer weit verbreiteten ERP-Lösung lässt sich die Prozessintegration des PLM besonders gut nachweisen. Die prozessorientierte Darstellung erlaubt aber auch einen Transfer auf andere Systemlösungen. Das vorliegende Buch untergliedert sich in drei Teile: Im ersten Kapitel erfolgt eine historisch-wissenschaftliche Einordnung des Begriffes PLM, eine wissenschaftliche Betrachtung der PLM-Herausforderungen und ein Ausblick auf zukünftige Softwarearchitekturen. Die Kapitel 2 bis 8 geben einen praxisnahen Überblick über die Kernprozesse von PLM und deren Vernetzung, die Implementierung eines PLM-Systems und einen Ausblick auf aktuelle Trends. Im zweiten Teil (Kapitel 9 bis 14) werden Fallstudien aus dem Maschinen- und Anlagenbau und der Automobilindustrie vorgestellt, welche unterschiedliche Projektinhalte,

VI

Vorwort

Vorgehensweisen und Projekterfahrungen darstellen. Der dritte Teil schließlich beinhaltet Fallstudien aus der Prozessindustrie (Branchen Konsumgüter, Chemie / Pharma und Stahl). Wir möchten uns insbesondere bei all unseren Kunden bedanken, welche uns bei diesem Buch durch Beiträge unterstützt haben. Dies verstärkt nochmals den so wichtigen Praxisbezug des Buches. Auch möchten wir uns bei Rene Werth bedanken, der im ersten Kapitel die Brücke zwischen den Themen Prozessmanagement und Product Lifecycle Management geschlagen hat. Für ihre Unterstützung bei der Redaktion des Buches und der Erstellung von Projektberichten sagen wir unseren Kollegen Matthias Beer, Christian Berthier, Markus Hansmann, Michael Klika, Jürgen Mayer, Albert Moser und Jan Wahle herzlichen Dank. Schlussendlich möchten wir uns bei Björn Welchering für die Anregungen und die organisatorische Unterstützung bedanken. Saarbrücken, im August 2005

Prof. Dr. Dr. h.c. mult. A.-W. Scheer M. Boczanski Privdoz. Dr.-Ing. habil. M. Muth W.-G. Schmitz Dr. rer. nat. U. Segelbacher

Inhaltsverzeichnis

Teil I: PLM – Prozesse, Konzepte, Lösungen 1

2

3

4

PLM im Wandel der Zeit ................................................. 3 1.1

Referenz Industriebetrieb ........................................................................... 3

1.2

Das Y-CIM-Modell .................................................................................... 4

1.3

Unterstützung der Produktionsplanung und -steuerung ............................ 6

1.4

Statisches Management der Produktentwicklung ...................................... 7

1.5

PLM als Prozess-Unterstützungs- und Integrationskomponente .............. 8

1.6

Ausblick: Diffusion von PLM in Business Process Platforms................ 10

PLM im Überblick ..........................................................13 2.1

Geschäftsprozesse als Grundlage für PLM.............................................. 15

2.2

Generische PLM-Prozesse und deren Bedeutung.................................... 16

2.3

Schwerpunkte in verschiedenen Branchen .............................................. 20

Bausteine und Prozesse im PLM .................................27 3.1

Ein prozessorientierter PLM-Ansatz........................................................ 27

3.2

Komposition einer integrierten PLM-Lösung.......................................... 34

3.3

Einführung und Ausbau einer PLM-Lösung............................................ 41

3.4

Vorteile einer prozessorientierten PLM-Einführung ............................... 42

3.5

Zusammenfassung .................................................................................... 42

PLM und die Kerngeschäftsprozesse des Unternehmens ........................................................43 4.1

Produktentstehung und strategische Planung........................................... 45

4.2

Produktentstehung und Vertriebsprozess................................................. 47

4.3

Integration verschiedener Entwicklungsbereiche und -standorte............ 52

4.4

Integrierte Produkt- und Prozessentwicklung .......................................... 54

4.5

Produktentwicklung und Beschaffung ..................................................... 56

VIII

5

6

7

8

Inhaltsverzeichnis

Unterstützende PLM-Prozesse / Querschnittsprozesse...................................................61 5.1

Collaborative Engineering........................................................................ 62

5.2

Projektmanagement .................................................................................. 63

5.3

Service und Wartung ................................................................................ 65

IT-Bausteine einer prozessorientierten PLM-Lösung...................................................................67 6.1

Das Produktdatenmanagement................................................................. 67

6.2

Die frühen Phasen der Produktentwicklung............................................. 91

6.3

Projektmanagement in der Produktentwicklung...................................... 94

6.4

Projektportfoliomanagement .................................................................. 101

6.5

Qualitätsmanagement ............................................................................. 105

6.6

Instandhaltung und Service .................................................................... 107

6.7

Workflow als Querschnittsfunktion im PLM ........................................ 110

Methoden und Trends .................................................119 7.1

Prototyping.............................................................................................. 119

7.2

Simultaneous Engineering...................................................................... 123

7.3

Digital Mockup....................................................................................... 126

7.4

Collaborative Engineering...................................................................... 131

7.5

Digitale Fabrik ........................................................................................ 133

7.6

Virtuelle Realität (VR) ........................................................................... 135

7.7

Zusammenfassung .................................................................................. 138

Zukünftige Strategien von PLM..................................141 8.1

Produktentstehung .................................................................................. 142

8.2

Produktfertigung ..................................................................................... 143

8.3

Produktentsorgung.................................................................................. 144

Inhaltsverzeichnis

IX

Teil II: Fallstudien aus der Fertigungsindustrie 9

PLM in der Schaeffler-Gruppe ....................................147 Momme Stürken 9.1

Überblick und Projektziele ..................................................................... 147

9.2

CAD-Integration und Stammdaten als Projektherausforderung............ 148

9.3

Ausblick .................................................................................................. 150

10 Komplexitäts- und Produktvariantenmanagement bei einem Serienfertiger..............................................153 10.1 Ausgangssituation................................................................................... 153 10.2 Ziele des PLM-Einsatzes........................................................................ 154 10.3 Vorgehensweise im Projekt.................................................................... 156 10.4 Projektfazit.............................................................................................. 159

11 Optimierung der Produktentwicklung bei einem Maschinenbauer ..........................................................163 11.1 Ausgangssituation................................................................................... 163 11.2 Ziele des PLM-Einsatzes........................................................................ 165 11.3 Projektvorgehen und Projektorganisation.............................................. 166 11.4 Ergebnisse der Konzeptionsphase.......................................................... 168 11.5 Komponenten der PLM-Lösung ............................................................ 169 11.6 Projektfazit.............................................................................................. 171

12 PLM bei BRP-Rotax GmbH & Co. KG.........................173 Harald Okruch und Claudia Herzog 12.1 Das Unternehmen ................................................................................... 173 12.2 Ausgangssituation und Vision................................................................ 174 12.3 Ziele des PLM-Einsatzes........................................................................ 175 12.4 Projektvorgehen und Projektorganisation.............................................. 176 12.5 Ergebnisse des Projektes ........................................................................ 177 12.6 Projekterfahrung und Ausblick .............................................................. 179

X

Inhaltsverzeichnis

13 PLM bei der CARPIGIANI GROUP ..............................181 Andrea Cocchi und Alexander Schadenberger 13.1 Das Unternehmen ................................................................................... 181 13.2 Ziele des PLM-Einsatzes........................................................................ 181 13.3 Vorgehensweise im Projekt.................................................................... 182 13.4 Ergebnisse des Projektes ........................................................................ 184

14 Importance of Product Design and Data Exchange Standards in the Product Life Cycle .....................................................................185 Bruno Schilli und Ingo Kern 14.1 Introduction............................................................................................. 185 14.2 Status of Collaborative Engineering in the Power and Automation Industry ................................................................................................... 186 14.3 Industrial Prerequisites to Enable Collaborative Engineering............... 189 14.4 Portfolio Management for Products, Systems and Services.................. 190 14.5 Standardization of Default Product Information.................................... 191 14.6 Industrial Use of Standards Along the Product Life Cycle ................... 193 14.7 Real-Time Design Collaboration at ABB and Its Supplier Network................................................................................................... 194 14.8 References............................................................................................... 196

Teil III: Fallstudien aus der Prozessindustrie 15 Produktentwicklung bei einem Lebensmittelhersteller ................................................199 15.1 Ausgangssituation................................................................................... 199 15.2 Ziele des PLM-Einsatzes........................................................................ 201 15.3 Projektmethoden und Projektorganisation ............................................. 202 15.4 Projektdurchführung............................................................................... 202 15.5 Komponenten der PLM-Lösung ............................................................ 207 15.6 Ergebnisse des Projektes ........................................................................ 213

Inhaltsverzeichnis

XI

16 Produktentwicklung mit NPDI bei einem Konsumgüterhersteller ...............................................215 16.1 Marktsituation Konsumgüterindustrie ................................................... 215 16.2 Ausgangssituation................................................................................... 217 16.3 Ziele des PLM-Einsatzes........................................................................ 218 16.4 Vorgehen im Projekt............................................................................... 219 16.5 Das Prozesskonzept NPDI...................................................................... 220 16.6 Komponenten der PLM-Lösung ............................................................ 223 16.7 Ergebnisse des Projektes ........................................................................ 228

17 Automatisierte Stammdatenpflege in der Konsumgüterindustrie ................................................231 17.1 Ausgangssituation................................................................................... 231 17.2 Ziele des PLM-Einsatzes........................................................................ 234 17.3 Projektmethoden und Projektorganisation ............................................. 234 17.4 Projektdurchführung und -ergebnisse .................................................... 235 17.5 Komponenten der PLM-Lösung ............................................................ 240 17.6 Ergebnisse des Projektes ........................................................................ 244

18 Spezifikation von Produkten in der Stahlindustrie ....247 18.1 Ausgangssituation................................................................................... 247 18.2 Ziele des PLM-Einsatzes........................................................................ 248 18.3 Projektablauf und Projektorganisation................................................... 248 18.4 Komponenten der PLM-Lösung ............................................................ 249 18.5 Ergebnisse des Projektes ........................................................................ 252

19 Produktentwicklung bei einem Feinchemikalienhersteller ..........................................253 19.1 Ziele des PLM-Einsatzes........................................................................ 253 19.2 Vorgehensweise im Projekt.................................................................... 254 19.3 Komponenten der PLM-Lösung ............................................................ 255 19.4 Ergebnisse des Projektes ........................................................................ 256

Literaturverzeichnis ..........................................................257

Abbildungsverzeichnis

Abb. 1. Abb. 2. Abb. 3. Abb. 4. Abb. 5. Abb. 6. Abb. 7. Abb. 8. Abb. 9. Abb. 10. Abb. 11. Abb. 12. Abb. 13. Abb. 14. Abb. 15. Abb. 16. Abb. 17. Abb. 18. Abb. 19. Abb. 20. Abb. 21. Abb. 22. Abb. 23. Abb. 24. Abb. 25. Abb. 26.

Y-CIM-Modell für den Industriebetrieb................................................5 Einordnung von PLM in das Y-CIM-Modell ......................................10 Product Lifecycle Management und Geschäftsprozess-Plattformen ...11 PLM als Bindeglied zwischen den Säulen Produktion und Produktentwicklung des Y-CIM-Modells ...........................................14 Generische Prozesse des PLM.............................................................15 Prozesslandkarte des PLM ..................................................................16 Kriterienmodell für die Integration von CAD-Systemen.....................17 Collaboration-Prozess in der Automobilindustrie am Beispiel von Produktdaten.................................................................................18 Prozesslandkarte des Produktentstehungsprozesses am Beispiel der Automotive-Branche .....................................................................21 Reduzierung vermeidbarer Änderungen durch die Optimierung von Änderungsprozessen.....................................................................22 Workflowunterstützte Änderungsprozesse schaffen Sicherheit und Prozesstransparenz ..............................................................................22 Entstehung von Stammdaten entlang des Entwicklungsprozesses ......23 Konsumgüter-Industrie mit Schwerpunkt Innovation und Produktentwicklung.............................................................................24 PLM Process Lifecycle........................................................................27 PLM-Prozess-Implementierung .........................................................32 PLM-Prozess-Controlling....................................................................34 PLM-Prozesslandkarte ........................................................................36 Prozesse in der Produktentwicklung (Ausschnitt) ...............................38 Prozesslandkarte in der Prozessindustrie (Chemie).............................40 Entwicklung der Organisation in der Produktentwicklung..................44 Das digitale Produkt ............................................................................46 Kostenfestlegung und Kostenverursachung innerhalb der Teilprozesse der Produktentstehung....................................................55 Prozess- und Datenintegration von der Produktentwicklung in die Fertigung bis hin zu Instandhaltung und Service.................................56 Frühe Integration von Zulieferern innerhalb der Produktentwicklung im Automobilbau...............................................57 Schematische Darstellung des Datenaustausches zwischen Hersteller und Lieferant.......................................................................58 Strukturierung von Produkten aus der Sicht verschiedener Unternehmensbereiche ........................................................................59

XIV

Abbildungsverzeichnis

Abb. 27. Abb. 28. Abb. 29. Abb. 30. Abb. 31. Abb. 32. Abb. 33. Abb. 34. Abb. 35. Abb. 36. Abb. 37. Abb. 38. Abb. 39. Abb. 40. Abb. 41. Abb. 42. Abb. 43. Abb. 44. Abb. 45. Abb. 46. Abb. 47. Abb. 48. Abb. 49. Abb. 50. Abb. 51. Abb. 52. Abb. 53. Abb. 54. Abb. 55. Abb. 56. Abb. 57. Abb. 58. Abb. 59. Abb. 60.

Qualitätsmanagement innerhalb von PLM ..........................................61 Collaborative Engineering und Projektmanagement ...........................62 Aufgaben und Prozesse im Projektmanagement .................................64 Dokumentenverwaltungssatz im SAP DMS........................................69 SAP WebDocuments.. .........................................................................71 Visualisierung eines Dokumentenverwaltungssatzes mit dem im SAP DMS integrierten Viewer.............................................................72 SAP Records Management..................................................................74 Exemplarische Abbildung eines Produktmodells ................................75 Darstellungen einer Stückliste mit ihren Komponenten in SAP..........76 Produktstruktur-Browser in SAP.........................................................78 Klassenhierarchie mit zugeordneten Eigenschaften (Merkmale) ........80 Funktionsprinzip der Variantenkonfiguration .....................................81 Alternative Integrationsszenarien CAD / ERP in einer SAP-Architektur..................................................................................83 CAD-Direktintegration in SAP ...........................................................84 Änderungsprozess mit typischen Objekten und Beteiligten ................87 Der Lebenszyklus im Konfigurationsmanagement..............................89 Lebenszyklusmappe im Konfigurationsmanagement von SAP PLM....91 Innovationsmanagement-Trichter........................................................93 Erweiterter Konstruktionsablauf Anlagenbau mit Funktionen und entstehenden Dokumenten...................................................................94 Schwerpunkte des Projektmanagements in Entwicklungsprojekten....95 Die Phasen / Funktionen eines typischen Projektablaufs ....................98 Wertschöpfungskette – Detailbild Projektabwicklung ........................99 Verzahnung von operativem und strategischem Projektmanagement ...........................................................................102 Kernfunktionen der Projektportfoliomanagement-Lösung xRPM der SAP. ............................................................................................104 Darstellung des Projektportfolios in der PortfoliomanagementLösung xRPM der SAP AG ..............................................................104 Anlagenstruktur im SAP PM mit technischen Plätzen und Equipements. .....................................................................................108 Workfloweingang mit 5 Arbeitsaufträgen im SAP Business Workflow ..........................................................................................113 Ablaufschema eines workflowgesteuerten Änderungsprozesses im Anlagenbau........................................................................................115 Ablaufschema eines netzplanbasierten Workflow.............................116 Verschiedene Prototypen – Proportions-/Ergonomiemodelle ...........120 CAD-Modell und Ableitung für STL-Modell ...................................122 Rapid-Prototyping-Prozesse mit der zugehörigen Datenkonvertierung und Datenaufbereitung......................................123 Parallelisierung in der Produktentwicklung.......................................125 Produktstruktur und 3D-Baugruppendarstellung...............................126

Abbildungsverzeichnis

Abb. 61. Abb. 62. Abb. 63. Abb. 64. Abb. 65. Abb. 66. Abb. 67. Abb. 68. Abb. 69. Abb. 70. Abb. 71. Abb. 72. Abb. 73. Abb. 74. Abb. 75. Abb. 76. Abb. 77. Abb. 78. Abb. 79. Abb. 80. Abb. 81. Abb. 82. Abb. 83. Abb. 84. Abb. 85. Abb. 86. Abb. 87. Abb. 88. Abb. 89. Abb. 90. Fig. 91. Fig. 92. Fig. 93. Fig. 94. Fig. 95. Fig. 96. Fig. 97. Fig. 98. Abb. 99.

XV

Clash-Detection .................................................................................127 Mensch-Modell RAMSIS..................................................................128 Anwendung des Mensch-Modells in der Fahrzeugkonstruktion .......129 FEM-Belastungssimulation ...............................................................130 DMU und Bewegungssimulation ......................................................130 DMU – Package- und Piping-Analyse ..............................................131 Verknüpfung zweier Collaboration-Pyramiden.................................132 Prozesse innerhalb einer Collaboration (Projektbeispiel)..................133 Rendering ..........................................................................................137 Virtuelle Darstellung eines Kontrollzentrums ...................................137 Phasen von Produktentstehung bis Produktentsorgung .....................141 PLM als Collaboration-Plattform ......................................................143 PDM Collaborator Approach ............................................................144 Alte Datenwelt des Produktkonstrukteurs bei INA-Schaeffler KG ...147 Neue Datenwelt des Produktkonstrukteurs bei der INASchaeffler KG ...................................................................................148 Verknüpfung der konstruktiven Stamm- und Strukturdaten in SAP PLM ..........................................................................................150 Ausgangssituation und Zielsetzung ...................................................154 Auswirkung von Varianten auf die Logistikprozesse........................155 Ganzheitliches und integriertes Komplexitätsmanagement...............156 Komplexitätsreduzierung ..................................................................157 Merkmalvariantenbaum.....................................................................158 Das ABC-Konzept bei der Variantendefinition.................................159 Vorgehensmodell Variantenmanagement im ARIS-Scout ................160 Prozesslandschaft Anlagengeschäft...................................................164 Auszug aus der Projektstruktur..........................................................167 Produkte von BRP-Rotax ..................................................................173 Prozesslandkarte und IT-Unterstützung in den verschiedenen Prozessen...........................................................................................174 Projektverlauf / Umsetzungsphasen ..................................................176 Projektorganisation............................................................................177 3D-CAD-Modell eines Motors: Ausgangspunkt für optimierte Datennutzung.....................................................................................178 Collaboration during Product Life Cycle ..........................................187 Evolution of Collaboration Technologies..........................................188 Cross Enterprise Engineering Networks............................................188 Mapping of the Portfolio of an Engineering Company like ABB .....190 Benefits of Standardization Along the Product Life Cycle ...............191 Standardized Product Information in ABB........................................192 The Concept of Cross-Enterprise-Collaboration ...............................194 Implementation of Collaborative Engineering in ABB .....................195 Phasenkonzept der Produktentwicklung............................................203

XVI

Abbildungsverzeichnis

Abb. 100. Detaillierter Ablaufplan der Tätigkeiten für die Phase 3 des Produktentwicklungsprozesses für Produkte einer Produktlinie .......204 Abb. 101. Schulungsblöcke, differenziert nach Anwendergruppen ...................207 Abb. 102. Strukturen des SAP-Projektsystems und deren Beziehungen............208 Abb. 103. Netzplandarstellung aus dem SAP-Projektsystem.............................209 Abb. 104. Automatische Projektsteuerungsfunktion des Workflows.................209 Abb. 105. SAP R/3-Projektinformationssystem.................................................211 Abb. 106. Gruppierung von Dokumenten zu SAP-Dokumentarten mit differenzierten Zugriffsberechtigungen (anonymisiert).....................212 Abb. 107. Marktstudie zu Produktentwicklungszeiten.......................................216 Abb. 108. Marktstudie zu Produktlebenszeiten..................................................216 Abb. 109. Ist-Aufnahme der für Steuerung und Dokumentation des Produktentwicklungsprozesses relevanten IT-Tools ..........................219 Abb. 110. Matrix zur Bewertung zweier Lösungsalternativen anhand eines gewichteten Kriterienkatalogs ...........................................................221 Abb. 111. Das NPDI Konzept............................................................................222 Abb. 112. Eingesetzte Lösungskomponenten im beschriebenen Projekt ...........223 Abb. 113. Struktur einer Verpackungsspezifikation im SAP Spezifikationsmanagement................................................................225 Abb. 114. Projektstruktur in cProjects ...............................................................225 Abb. 115. Auszug aus einer Projektportfolioübersicht in SAP BW...................227 Abb. 116. Arbeitsumgebung eines externen Kollaborationsteilnehmers beim Zugriff auf cFolders...........................................................................228 Abb. 117. Systemübergreifender Pflegeprozess.................................................232 Abb. 118. Prozessmodellierung für Workflow (Ausschnitt) ..............................236 Abb. 119. Customising-Aufwand in Abhängigkeit von der technischen Ausprägung .......................................................................................239 Abb. 120. Ausschnitt aus der Prozesssteuerungsebene ......................................242 Abb. 121. Arbeitsprozess ...................................................................................242 Abb. 122. Individuelles Reportingwerkzeug......................................................243 Abb. 123. IT-Funktionsmodule im Spezifikationsprozess .................................250 Abb. 124. Abbildung der Stahlspezifikation in einer iPPE-Struktur zur Unterstützung des Angebotsprozesses...............................................251 Abb. 125. Schematische Darstellung des Produktentwicklungsprozesses .........255

Teil I PLM – Prozesse, Konzepte, Lösungen

1

PLM im Wandel der Zeit

Mit der Entwicklung des Computer Integrated Manufacturing (CIM) zu Beginn der 1980er Jahre begann der Versuch, industrielle Geschäftsprozesse mittels Informationstechnologie integriert zu steuern. Insbesondere sollten logistische Teilfunktionen eines Unternehmens sowie Forschungs- und Entwicklungsaktivitäten ganzheitlich betrachtet und gesteuert werden. Diese Vision wurde jedoch nur langsam umgesetzt. So gelang es mittels Enterprise-Resource-Planning-(ERP-) Systemen die logistische Prozesskette umfassend anzusprechen und eine integrierte Steuerung zu realisieren. Auf Seiten der Forschungs- und Entwicklungsaktivitäten stand diese Prozessorientierung und integrierte Unterstützung durch Informationstechnologie noch aus. Product Lifecycle Management (PLM) ist angetreten, diese Lücke zu schließen. Dieses Kapitel leitet historisch die Notwendigkeit von Product Lifecycle Management her und ordnet PLM in den Rahmen des Computer Integrated Manufacturing ein. Dies geschieht, indem die Abdeckung des Y-CIM-Modells durch Konzepte und Lösungen (bspw. ERP) geprüft wird. Es wird gezeigt, inwieweit PLM die festgestellten Lücken schließen kann und damit in Kombination mit ERP eine ganzheitliche Betrachtung von Logistik- und Entwicklungsprozessen ermöglicht. Gerade neue, geschäftsprozessorientierte Softwarearchitekturen lassen die Konzepte noch weiter zusammenwachsen. Sie stellen die Basis für eine vollständige Integration zur Verfügung, die aufgrund des industriellen Referenzcharakters eine weite Übertragung auf andere Branchen erwarten lässt.

1.1

Referenz Industriebetrieb

Industrieunternehmen gehören zu den komplexesten Wirtschaftsgebilden. Es sind solche Betriebe, die Rohstoffe in großem Umfang zu Halb- oder Fertigfabrikaten weiterverarbeiten (vgl. [17], S. 1-11). Diese Transformation erfolgt in Massenoder Serienfertigung unter umfassendem Ressourceneinsatz. Teilweise wird auch die Rohstoffgewinnung der Industrie zugerechnet. Im Wesentlichen werden zur Fertigung Menschen und Maschinen eingesetzt, die arbeitsteilig und unter Einsatz einer Vielzahl von Techniken Produkte herstellen. Im Rahmen dieser Transformation vom Rohstoff zum Enderzeugnis erfolgt eine hohe Wertschöpfung an den Produkten. Dabei ist nicht nur der Produktionsprozess selbst komplex, auch die Produktstruktur zeigt sich im Allgemeinen als aufwendig. So bestehen Produkte nicht selten aus tausenden unterschiedlichen Komponenten, die entsprechend vorgefertigt, verarbeitet und zusammengefügt werden müssen. Folglich kommt dem Produkt im Industriebetrieb eine zentrale Bedeutung zu. Aufgrund der Notwen-

4

PLM im Wandel der Zeit

digkeit eines hohen Ressourceneinsatzes verfügen Industrieunternehmen über verhältnismäßig wenige Produktionsstätten (Werke), die viele Maschinengruppen bündeln. Der Geschäftsbetrieb eines Industrieunternehmens erfordert darüber hinaus die Zusammenarbeit mit vielen externen Partnern, sei es beschaffungsseitig, absatzseitig oder im Rahmen von Entwicklungs- oder Fertigungsprozessen. Die Industrie wirft aufgrund dieser Komplexität der wirtschaftlichen Tätigkeiten eine Vielzahl an Problemstellungen auf. Diese sind oftmals zwar nicht nur in der Industrie zu finden. Der Lösungsdruck ist im Industriebetrieb aufgrund der vielschichtigen Gesamtsituation jedoch verhältnismäßig groß, so dass diese Problemstellungen schneller akut werden. Entsprechend liegen oftmals für die Industrie früher Lösungskonzepte vor, die sich auf andere Sektoren übertragen lassen. Als Beispiele seien hier die Versuche zur Industrialisierung des Dienstleistungssektors [6], die Kundenfokussierung im Rahmen des Efficient Consumer Response (ECR) in Handelsunternehmen [49] oder das Neue Steuerungsmodell der öffentlichen Hand erwähnt [23]. Insofern lässt sich vom Industriebetrieb als Idealtyp eines Wirtschaftsunternehmens sprechen und der Referenzcharakter des Industriebetriebs ableiten.

1.2

Das Y-CIM-Modell

Innerhalb des Industriebetriebs fallen eine Vielzahl an unterschiedlichen Tätigkeiten an. Selbst bei einer Beschränkung auf die Kernaufgabe der Industrie, nämlich die Fertigung, bleiben Anzahl und Struktur unüberschaubar. Zur Ordnung haben sich in den letzten Dekaden zahlreiche Modelle herausgebildet, die eine Strukturierung versuchen (vgl. [43], S. 14-21). Das Y-CIM-Referenzmodell für den Industriebetrieb verfolgt genau diese Zielsetzung [40]. Es wurde in vielen Industrieunternehmen als Guideline für die Entwicklung der eigenen Unternehmensgestaltung verwendet [41]. Im Kern betrachtet das Y-CIM-Modell die betriebswirtschaftliche und die technische Prozesskette in der Fertigung. Die betriebswirtschaftlichen Aufgaben zielen dabei auf die Planung und Durchführung von Fertigungsaufträgen. Im Rahmen der Planungsebene wird hier die Gesamtheit der Aufträge zeitlich eingeplant sowie die für die Fertigung notwendigen Materialien ermittelt und disponiert. Auf Fertigungsebene erfolgen dann die Feinplanung der Aufträge, die Realisierung der Fertigungsaufträge sowie die Rückmeldung des Auftragsfortschrittes. Die technische Prozesskette dagegen fokussiert den Entwicklungs- und -herstellungsprozess der tatsächlichen Produkte. Aufgabe hier ist die Planung und Realisierung des Produktportfolios. Dies beinhaltet auf Planungsebene die Konstruktion der Produkte. Darüber hinaus muss das Produktionsumfeld zur Fertigung der konstruierten Produkte geschaffen werden. Hierunter fällt insbesondere die Definition der Arbeitspläne für die Mitarbeiter sowie die Implementierung der Steuerprogramme für die Fertigungsmaschinen. Beides wird auf Fertigungsebene zur Herstellung umge-

Das Y-CIM-Modell

5

setzt, also die Arbeitspläne von den Mitarbeitern sowie die Steuerprogramme von den Maschinen ausgeführt. Betriebswirtschaftliche und technische Prozesskette sind in ihrem Anfang unabhängig. Der Auftragseingang und die Einplanung der Fertigungsaufträge sind prinzipiell unabhängig von dem Produktionsentwicklungsprozess. Umgekehrt ist der Vorgang der Produktentwicklung im Allgemeinen unabhängig von der Auftragsplanung. Die zeitliche Vorgängerschaft wechselt auch von Branche zu Branche. So beginnt in der Massenfertigung der klassischen Konsumgüterindustrie der Produktentwicklungsprozess vor der Auftragsbearbeitung. Dies resultiert aus der Tatsache, dass hier nur zumindest teilkonstruierte Produkte am Markt zum Verkauf angeboten werden können. Demgegenüber liegt der Beginn der betriebswirtschaftlichen Prozesskette bei Einzelfertigung im Investitionsgüterbereich vor der Produktentwicklung. Dieser Bereich ist nämlich dadurch charakterisiert, dass jedes Produkt individuell nach den Anforderungen eines einzelnen Kunden entwickelt und produziert wird. Dies bedeutet allgemein, dass betriebswirtschaftliche Planung im Sinne der Auftragsplanung und technische Planung im Sinne der Produktentwicklung als entkoppelt angesehen werden können. Bei der Realisierung der Produkte im Rahmen von Kundenaufträgen, also der eigentlichen Fertigung, ist diese Unabhängigkeit jedoch nicht mehr gegeben. Vielmehr fallen bei dem Produktionsprozess selbst beide Prozessketten zusammen. Die Durchführung des Kundenauftrags erfordert nämlich die Herstellung des Produktes durch Mitarbeiter und Maschinen. Umgekehrt wird ein Produkt nur technisch gefertigt, wenn ein entsprechender Auftrag vorliegt und zur AusTechnische Prozesskette

ProduktionsProgrammplanung

ti uk od Pr la sp on

Konstruktion

CAE

CAD

KapazitätsBedarfsplanung Auftragsfreigabe

Produktionssteuerung

Fertigungsebene

Produkt-Entwurf

MaterialBedarfsplanung

ng nu

Planungsebene

Betriebswirtschaftliche Prozesskette

Werkstattsteuerung

BetriebsDatenerfassung Soll-Ist-Vergleich (Mengen, Zeiten, Kosten)

Arbeitsplanung

CAP

Steuerung von NC-, CNC-, DNCMaschinen Steuerung von Transportsystem

CAM

Steuerung von Robotern u. Montage Qualitätskontrolle

PPS

Abb. 1. Y-CIM-Modell für den Industriebetrieb (vgl. [40], S.3)

CAQ

CAE

6

PLM im Wandel der Zeit

führung freigegeben wurde. Dies bedingt ein gemeinsames Ausführen von betriebswirtschaftlicher und technischer Prozesskette im sachlogischen und zeitlichen Sinne. Aufgrund der dargestellten Beziehungen zwischen betriebswirtschaftlicher und technischer Prozesskette können im Rahmen einer graphischen Repräsentation beide Ketten auf Fertigungsebene als zusammenliegend beschrieben werden. Unter Voraussetzung einer sachlogischen und zeitlichen Flussrichtung von oben nach unten lassen sich die Sachverhalte als Y darstellen. Es symbolisiert, dass auf Planungsebene beide Prozessketten unabhängig sind, auf Fertigungsebene jedoch zusammenlaufen.

1.3

Unterstützung der Produktionsplanung und -steuerung

Der linke Ast des Y-CIM stellt die betriebswirtschaftlich-logistische Prozesskette in Industrieunternehmen dar. Ausgehend von Absatzprognosen und Auftragsextrapolationen werden die Produktions- und Dispositionsplanungen vorgenommen. Auf Basis dieser längerfristigen Grobplanungen wird der Zeithorizont sukzessive verkleinert und die Planung somit weiter präzisiert. Der letzte Schritt innerhalb der industriellen Planungsaufgaben ist die Auftragsfreigabe, die gleichzeitig die Schnittstelle zur Produktherstellung darstellt. Innerhalb der Fertigung kommt den betriebswirtschaftlichen Prozessen hauptsächlich eine Steuerungsfunktion zu. Hierbei wird der Fertigungsfortschritt mittels der Betriebsdatenerfassung gemessen und aufbereitet. Im Rahmen eines umfassenden Soll-Ist-Vergleichs können zum einen unmittelbare Monitoring-Aufgaben wahrgenommen werden und zum anderen nachgelagertes Controlling durchgeführt werden. Während im ersten Fall eine Regelung direkt in den Fertigungsbetrieb eingreifen kann, erfolgt über das Controlling eine Maßnahmen-Definition, die insbesondere auf dispositive Faktoren einwirkt. Die Produktionsplanung und -steuerung stellt schon lange ein intensiv bearbeitetes Forschungs- und Entwicklungsfeld dar. Schon in den 50er Jahren wurde mit Material Requirements Planning (MRP) der Grundstein zur systematischen Produktionsplanung und -steuerung gelegt. Das MRP-Konzept ersetzte die bisherige, verbrauchsorientierte Materialdisposition durch bedarfsorientierte Verfahren. Ausgehend von absatzmotivierten Produktionsprogrammen wurden die Primärbedarfe ermittelt. Diese wurden unter Auflösung der Stücklisten in Sekundärbedarfe umgewandelt und hieraus unter Abzug von Beständen die Dispositionsmengen und -zeitpunkte abgeleitet. Vervollständigt wurde die Produktionsplanung und -steuerung durch Manufacturing Resource Planning (MRP-II), das in den späten 70er Jahren Verbreitung fand. Gegenüber MRP zeichnet es sich durch die Möglichkeiten zur Planung und Steuerung der längerfristigen Produktionsprogramme aus (vgl. [28], S. 325). Insbesondere die absatz- und umweltdatenbasierte Prognosefähigkeit wurde gestärkt. Weiterhin wurden die ursprünglichen MRP-Verfahren um die Ressourcen-

Statisches Management der Produktentwicklung

7

sicht ergänzt. Damit wurden Kapazitätsbetrachtungen ermöglicht, die Überlastungs- oder Überlagerungssituationen vermeiden konnten. In den 90er Jahren erfolgte schließlich die Einbeziehung aller Unternehmensressourcen in die Planungs- und Steuerungsaufgaben (vgl. [29], S. 2ff). Damit wurde es notwendig, nicht länger die lokalen Unternehmensfunktionen zu betrachten, sondern die unternehmensweiten Geschäftsprozesse zu adressieren. In der Folge zeichnete sich das resultierende Enterprise-Resource-Planning-(ERP-)Konzept durch eine Geschäftsprozess-Orientierung aus. Damit realisierten entsprechende Softwaresysteme, wie SAP R/3, erstmalig eine integrierte, informationstechnische Unterstützung aller Unternehmensbereiche und -prozesse. Diese sind mittlerweile nicht nur in jedem Industriebetrieb zu finden, sondern haben sich zu einem kritischen Erfolgsfaktor für Wirtschaftsunternehmen an sich entwickelt.

1.4

Statisches Management der Produktentwicklung

Der rechte Ast des Y-CIM wurde hauptsächlich in einer statischen Betrachtungsweise adressiert. Es dominierten Fragestellungen wie Konstruktionsunterstützung, Exploration von Kundenanforderungen oder Target Costing. So versucht das Marketing zu eruieren, welche grundlegenden Eigenschaften die Kunden-Zielgruppe von dem (zukünftigen) Produkt fordert bzw. welche Defizite aus Kundensicht an bestehenden Produkten existieren, die in neuen Produkten beseitigt werden sollen. Diese Anforderungen gehen im Rahmen des Computer-Aided Engineering (CAE) in den frühen Produktentwurf ein. Die eigentliche Produktdefinition im Sinne einer Konstruktionsleistung erfolgt beim Computer-Aided Design (CAD). Hier werden sowohl die Produktbestandteile spezifiziert als auch konstruktiv beschrieben. Dies umfasst neben Größen- und Gewichtsangaben auch Leistungsanforderungen, Materialvorgaben und Toleranzmaße für die Fertigung. Diese Produktdaten werden dann unter Einsatz von Konzepten und Anwendungssystemen des Computer-Aided Planning (CAP) in Fertigungsprogramme umgesetzt. Diese beinhalten neben den Arbeitsplänen und Arbeitsgängen auch die NCProgramme zur Steuerung der herstellenden Werkzeugmaschinen. Damit sind sämtliche Planungsinformationen vorhanden, die für die technische Fertigung eines Produktes notwendig sind. Die Produktfertigung im technischen Sinne selbst wird substanziell durch Computer-Aided Manufacturing (CAM) unterstützt. Es umfasst die technische Abwicklung aller Aufgaben im Produktionsbereich. Hierzu zählt insbesondere die koordinierte Maschinensteuerung (NC-Maschinen, Transportsysteme, Robotiksysteme u.a.). Schließlich werden die Produkte auf deren Qualität, bspw. auf die Einhaltung der Toleranzmaße, geprüft. Diese betriebliche Aufgabe wird durch Computer-Aided-Quality-(CAQ-)Systeme geplant, unterstützt und überwacht. Jedoch existieren im Gegensatz zu den betriebswirtschaftlichen Vorgängen keine aufgaben-übergreifenden Konzepte zur Integration und Koordination der einzelnen Tätigkeiten, obwohl diese durch umfangreiche, gegenseitige Abhängigkeiten gekennzeichnet sind. Während also die Dynamik der Produktionsplanung

8

PLM im Wandel der Zeit

und -steuerung durch das Geschäftsprozessmanagement weitreichend beforscht worden ist, wurde der (technische) Produktentwicklungs- und -fertigungsprozess in seiner dynamischen Komponente weitgehend vernachlässigt. Gerade die Produktdimension wurde und wird jedoch zunehmend zu dem erfolgskritischen Kriterium für Industrieunternehmen. Insbesondere vor dem Hintergrund sinkender Produktlebenszeiten und einem Verhältnis von Lebensdauer zu Entwicklungsdauer von weniger als 2 zu 1 kommt dem Faktor Zeit bei der Entwicklung eine Schlüsselrolle zu. So hat sich die Time to Market zu der erfolgsentscheidenden Kenngröße bei der Markteinführung neuer Produkte entwickelt (vgl. [36], S. 221-302). In einigen Branchen ist eine möglichst kurze Dauer der Produktentwicklung auch wirtschaftlich bedeutender als die dabei entstehenden Kosten [26]. Zusätzlich trägt der klassische Entwicklungsprozess nicht der Erkenntnis Rechnung, dass die erfolgreiche Markteinführung, also eine betriebswirtschaftliche Problemstellung, weitaus schwieriger zu realisieren ist als eine technische Problemlösung. So scheitern weitaus mehr Projekte der Produktentwicklung an den wirtschaftlichen Risiken als an technischen Risikofaktoren (vgl. [31], S. 214-227).

1.5

PLM als Prozess-Unterstützungs- und Integrationskomponente

Ausgehend von diesen Erkenntnissen zeigen sich zwei Notwendigkeiten: Zum einen müssen nicht nur die einzelnen technischen Entwicklungs- und Fertigungsaufgaben integriert und ablauflogisch verbunden werden. Dies bedingt eine prozessorientierte Konzeption der Produktentwicklung und die integrierte Datenhaltung, wie sie ERP-Systeme für Produktionsdaten seit Jahren anbieten. Zum anderen muss ein kontinuierliches Alignment zwischen betriebswirtschaftlicher und technischer Planung und Steuerung hergestellt werden. So sind bspw. Stücklisten und Produktstammdaten Elemente, die in beiden Planungssträngen grundlegende Informationsobjekte darstellen. Product Lifecycle Management (PLM) ermöglicht erstmals eine ganzheitliche Betrachtung der Produktentwicklung, insbesondere im Zusammenspiel aus statischen Ergebnissen und dynamischem Vorgehen. Funktional erleichtert es nicht nur das vollständige Stamm- und Entwicklungsdaten-Management, sondern unterstützt und verbessert auch Prozesse in der Produktentwicklung. Dabei zielt PLM nicht nur auf eine Integration der technischen Daten und Prozesse ab, sondern ermöglicht auch eine Vernetzung und Korrelation mit den betriebswirtschaftlichen Kenngrößen, um einerseits eine wirtschaftlich-effiziente Entwicklung sicherzustellen und andererseits das Alignment von Produktentwicklung und Markteinführung herbeizuführen. Die Unterstützungskomponente des Entwicklungsprozesses innerhalb von PLM gründet sich auf einer Erweiterung von Produktdatenmanagement-Systemen (PDM) um Prozessfunktionalitäten. Klassisches Produktdatenmanagement versucht, für eine konsistente Erzeugung und Änderung von Produktstrukturen zu

PLM als Prozess-Unterstützungs- und Integrationskomponente

9

sorgen. Hierzu stehen sowohl eine zentrale Datenhaltung mit Anbindung an die CAx-Werkzeuge bzw. -systeme als auch Mechanismen zur Versionierung und Archivierung zur Verfügung. Die prozessorientierten Erweiterungen des PLM liegen hier zum einen in einem Entwicklungs-Projektmanagement und zum anderen in einem Stammdaten-Changemanagement, die beide auf der zentralen PDMDatenhaltung aufsetzen. Die Projektmanagement-Funktion dient der Definition des Entwicklungsprozesses sowie dessen Controlling, beispielsweise zur Kontrolle der Ressourcenauslastung oder des Projektstatusmonitorings. Das Changemanagement hingegen soll den jedem Entwicklungsprozess inhärenten Änderungsnotwendigkeiten Rechnung tragen. Änderungsbedarfe, die auftreten, können nun integriert angestoßen, bewertet sowie die Änderungsmaßnahme selbst durchgeführt und abgeschlossen werden. Insbesondere wird der Änderungsprozess damit transparent und somit plan- und steuerbar. Eine solche Integration der technischen Prozesse ist jedoch nicht ausreichend. Während die Entwicklungsabteilung im Rahmen ihrer kreativen Prozesse kontinuierlich an der Verbesserung der Produkte arbeitet, sind diese Änderungen für die betriebslogistische Planung und Fertigungssteuerung aufwändig. Häufig ist es für eine erfolgreiche Produktentwicklung und wirtschaftliche Herstellung notwendig, bereits frühzeitig PDM-Daten und betriebswirtschaftliche Informationen zu korrelieren. Die Ansätze, Produktentwicklungsdaten in ERP-Systeme zu integrieren, werden allgemein als problematisch betrachtet (vgl. [15], S. 13). Die resultierenden Systeme werden mit Funktionen überfrachtet und erscheinen als zu komplex und unüberschaubar. Vielmehr sind ERP- und PDM-Systeme funktional zu integrieren. Dennoch ist der Umgang mit den Produktdaten (bspw. mit Artikeldaten und Stücklisten) von beiden Systemen unterschiedlich. So muss die Entwicklung mit vielen Varianten arbeiten können, um die besten Ergebnisse liefernde Version herausfiltern zu können. In der Fertigung wird jedoch nur auf einer bestimmten Version geplant und gefertigt. Bezogen auf das Y-CIM-Modell zur Abbildung der Zusammenhänge in einem Industriebetrieb zeigt sich, dass das PLM-Konzept nicht vollständig darin abbildbar ist. Zwar kann – ähnlich ERP – der prozessintegrierende Charakter in der technischen Prozesskette inhärent eingebunden werden, jedoch fehlt die Verknüpfung und Korrelation zu betriebswirtschaftlicher und technischer Planung und Steuerung. Abbildung 2 zeigt eine mögliche Einbeziehung der Konzepte des Product Lifecycle Management in das ursprüngliche Y-CIM. Insbesondere wird damit der Integrationscharakter von PLM im Zusammenspiel von wirtschaftlichem und technischem Management deutlich. In der Kombination ERP-PLM kann damit die ursprüngliche Vision des Computer Integrated Manufacturing realisiert werden. Diese Konstellation ermöglicht nämlich zum einen über ERP die prozessorientierte Integration der betrieblichen Logistikkette und zum anderen über PLM eine vollständige Prozessabbildung der technischen Forschungs-, Entwicklungs- und Fertigungskette. Darüber hinaus leistet PLM die Integrationsarbeit zwischen diesen beiden Prozessketten und vervollständigt damit die Umsetzung einer ganzheitlichen informationstechnischen Unterstützung der industriellen Geschäftsprozesse.

10

PLM im Wandel der Zeit Technische Prozesskette

ti uk od Pr

ProduktionsProgrammplanung MaterialBedarfsplanung

g un la n sp on

Planungsebene

Betriebswirtschaftliche Prozesskette

KapazitätsBedarfsplanung Auftragsfreigabe

Planungsebene

Produktionssteuerung

Fertigungsebene

Fertigungsebene

PPS

Werkstattsteuerung

BetriebsDatenerfassung Soll-Ist-Vergleich (Mengen, Zeiten, Kosten)

PDM OBJEKTMANAGEMENT Identifikation Revisionierung Objektklassen Fremdobjekteinkapselung

Produkt-Entwurf

Konstruktion

CAE

CAD

STRUKTURMANAGEMENT Produktstruktur Variantenklassifizierung Sachmerkmalleist Digital Mockup. PROZESSMANAGEMENT Freigabe- und Änderungswesen

Arbeitsplanung Steuerung von NC-, CNC-, DNCMaschinen Steuerung von Transportsystem

Verteilwesen

Steuerung von Robotern u. Montage

Konfiguration Check InOut

Qualitätskontrolle

Concurrent Engineering

PLM

CAP

CAM

CAQ

CAE

Abb. 2. Einordnung von PLM in das Y-CIM-Modell (in Anlehnung an [10], S. 9).

1.6

Ausblick: Diffusion von PLM in Business Process Platforms

Kernfunktionalitäten des PLM sind (Produkt-) Daten-Management und (Entwicklungs-) Prozess-Steuerung. Beides sind Funktionen, wie sie die neuen Geschäftsprozess-Plattformen originär bereitstellen. Hierunter versteht man dynamisierte, prozessorientierte Architekturen, die anpassungsfähige, betriebswirtschaftliche Softwarelösungen ermöglichen (vgl. [44], S. 2-13). Zentrale Business Process Engines ermöglichen die Abbildung und Koordination der relevanten Wertschöpfungsaktivitäten im Sinne einer Orchestrierung. Im Zusammenspiel mit Workflow-Funktionalitäten und Enterprise-Application-Integration (EAI) ermöglichen sie die Umsetzung der Prozesslogik. Die Workflow-Funktionalitäten dienen primär der Prozesssteuerung, z. B. durch den Transport der in einem Geschäftsprozess zu bearbeitenden elektronischen Bearbeitungsmappen von einem Arbeitsplatz zum anderen. Die EAI-Funktionalitäten sorgen für die Datenintegration zwischen den zur Prozessausführung notwendigen Modulen. Das Integrationswissen wird aus den zu integrierenden Komponenten extrahiert und ist in einer eigenen Ebene installiert. Die Geschäftsprozessabbildung und -ausführung sind integrale Bestandteile der Business Process Engine. Die darauf aufbauenden Anwendungssysteme erhalten automatisch eine stärkere Geschäftsprozessorientierung. Die Kombination von Gestaltung, Ausführung und Überwachung der betrieblichen Wertschöpfungsaktivitäten macht eine Unterstützung des gesamten Prozesslebenszyklus möglich. Dabei kann das Produktdaten-Management des PLM durch die EAI-Funktionalität von Business Process Engines abgedeckt werden. Insbesondere ermöglichen

Ausblick: Diffusion von PLM in Business Process Platforms

11

Abb. 3. Product Lifecycle Management und Geschäftsprozess-Plattformen

sie eine applikationsübergreifende Produktdaten-Integration und stellen den konsistenten Zugriff in verteilten Umgebungen sicher. Die Steuerung des Entwicklungsprozesses kann durch die Workflow-Funktion der Prozess-Plattformen wahrgenommen werden. Die Produktentwicklung ist damit in ihrer Dynamik erfass- und planbar. Im Bedarfsfall kann steuernd eingegriffen werden. Aufgrund dieser funktionalen Kohärenz steht daher zu erwarten, dass kontinuierlich Funktionen des PLM auch in Business Process Engines (BPE) diffundieren werden. Die betriebliche Aufgabenunterstützung solcher Plattformen würde damit noch weiter wachsen und neben Ressourcen-Management (ERP) und Prozessmanagement (BPM) nun auch das Management der Produkte und Leistungen übernehmen. Letztendlich wird PLM nur noch eine Ausprägung von Business Process Engines im Industriebetrieb sein. Damit würden diese Plattformen alle Teile des Y-CIM-Modells abdecken und somit eine vollständige Unterstützung des Geschäftsbetriebs eines Industrieunternehmens gewährleisten. Aufgrund des eingangs dargestellten Referenzcharakters öffnet diese Entwicklung die Tür für die Etablierung des ganzheitlichen PLM-Gedankens in allen Branchen.

2

PLM im Überblick

Globalisierung, Unternehmenskonzentration und Auslagerung von Prozessen oder kompletten Unternehmensbereichen haben in den letzten Jahren den Bedarf geweckt, die Kernprozesse von Unternehmen besser miteinander zu integrieren, zu optimieren und dazu die Möglichkeiten moderner Technologien noch effektiver zu nutzen. Höchste Priorität hat in diesem Zusammenhang die Gewährleistung der Konsistenz der Daten aus dem Produktentstehungsprozess für Produktion und Logistik sowie für die Kundenprozesse in Vertrieb, Marketing und Kundendienst. Die Industrie sucht nach Konzepten, um die Produkte über ihren gesamten Lebenszyklus hinweg in allen Geschäftsprozessen möglichst effektiv managen zu können. Für dieses strategische Konzept hat sich der Begriff Product Lifecycle Management (PLM) etabliert. Es sollte branchen- und unternehmensspezifische Randbedingungen berücksichtigen. Der Lebenszyklus eines Produktes reicht von der ersten Produktidee und der Produktentwicklung über Produktion und Vertrieb bis hin zu Wartung und Marktentnahme. In diesen gesamten Prozess ist eine Vielzahl von Abteilungen involviert, die unterschiedlichen Informationsbedarf haben. Ziel des PLM ist deshalb die optimale Gestaltung der Prozesse, insbesondere des Produktentwicklungsprozesses, sowie die Bereitstellung aller erforderlichen Produktinformationen über den gesamten Lebenszyklus des Produktes hinweg. Die Anforderungen an integrierte Geschäftsprozesse und Informationsverfügbarkeit wachsen, sowohl unternehmensintern als auch in der Zusammenarbeit mit Partnern, Lieferanten und Kunden. Entscheidend für die Wettbewerbsfähigkeit von Unternehmen ist deren Fähigkeit, die richtigen Produkte zum richtigen Zeitpunkt und mit möglichst geringen Kosten auf den Markt zu bringen. Um diese Innovationskraft zu erhöhen, müssen die Prozessketten der Produktentwicklung und der Produktion/Logistik, symbolisiert durch die Säulen des Y-CIM-Modells, durch die Prozesse des PLM eng verzahnt werden (vgl. Abb. 4). Auf den Märkten ist ein stetiger Innovationsdruck zu verzeichnen, dieser wirkt sich auf die am Markt agierenden Unternehmen aus. Unternehmen sind gefordert, neue Produkte noch schneller und kostengünstiger als die Konkurrenz auf den Markt zu bringen. Produkt- und Unternehmenserfolg hängen eng miteinander zusammen. Die durchgängige Betrachtung des Produktes über den gesamten Lebenszyklus ist daher eine betriebswirtschaftliche Notwendigkeit und erfordert Beratungsleistungen und Softwarelösungen zum PLM. Eine PLM-Lösung muss den Unternehmen umfassende Funktionalitäten für Produktinnovation, -entwicklung

14

PLM im Überblick

Abb. 4. PLM als Bindeglied zwischen den Säulen Produktion und Produktentwicklung des Y-CIM-Modells (Bild: IDS Scheer AG)

und -design sowie Anlagen- und Qualitätsmanagement liefern. Zudem verbindet eine PLM-Lösung durch so genanntes „Collaborative Engineering“ alle an den Geschäftsprozessen beteiligten internen (z. B. Konstruktionsabteilung, Marketing, Vertrieb) und externen Partner weltweit (z. B. Hersteller, Zulieferer, Lieferanten) und unterstützt somit die Kernphasen des Produktlebenszyklus: Produktinnovation und -entwicklung, Produktionsanlauf sowie Produktänderungen und Instandhaltungsmanagement. PLM ist keine neue Systemklasse und auch keine neue Art von Produkt-DatenManagement (PDM), sondern die konsequente, auf Web-Technologie basierte standort- und firmenübergreifende Anwendung der PDM-Kernkompetenzen Datenmanagement, Prozessmanagement und Systemintegration in allen Bereichen und Phasen der industriellen Wertschöpfung. Dies wird erreicht durch ein durchgängiges Konfigurationsmanagement, erweitert um eine höhere Integration in den Phasen Design, Entwicklung sowie Konstruktion und einem breiteren Einsatz im Engineering Prozess über alle Phasen des Produktlebenszyklus, d. h. für ein PLMSystem von der Entwicklung über Produktion und Vermarktung, Service bis hin zur Entsorgung [18]. Einen weiteren wichtigen Bestandteil des PLM bilden das virtuelle Produkt und dessen zeitabhängiges Informations- und Konfigurationsmanagement sowie die Prozesse zur virtuellen produktbasierten Wertschöpfung.

Geschäftsprozesse als Grundlage für PLM

2.1

15

Geschäftsprozesse als Grundlage für PLM

Entlang der Geschäftsprozesse werden Daten und Informationen erzeugt und benötigt. Die Abbildung dieser Prozesse mit allen Funktionen, Daten, Informationen und IT-Systemen bildet somit eine ideale Grundlage für PLM-Strategien und darüber hinaus eine ideale Plattform zur Pflege und Kontrolle implementierter PLM-Prozesse. Von dieser Vorgehensweise profitieren nicht nur Anwender der IT-Systeme, sondern es wird auch eine „schlanke“ IT-Infrastruktur möglich mit ebenfalls „schlanken“ Datenstrukturen. Die richtige Information, zur richtigen Zeit, am richtigen Ort, dieses wichtige Axiom einer PLM-Strategie wird über eine prozessgesteuerte PLM-Einführung und prozessgesteuerten Betrieb gewährleistet. In den folgenden Kapiteln wird mit Hilfe der generischen Darstellung von PLM-Prozessen (siehe Abb. 5) ein Überblick über deren Bedeutung im PLM gegeben. Anhand der generischen Prozesse wird in diesem Kapitel ein kurzer Überblick der Thematik PLM gegeben, in den weiteren Kapiteln dieses Buches wird auf die einzelnen Aspekte detailliert eingegangen, wobei den „Prozesslandkarten“ eine besondere Bedeutung zukommt: Sie entstehen immer mit Branchenbezug. Mit Hilfe einer Prozesslandkarte werden alle Geschäftsprozesse im Rahmen von PLM-Strategien visualisiert und nach Managementprozessen, Kern- und Unterstützungsprozessen gegliedert. Durch Unterprozesse beliebiger Tiefe erreicht man in den Einzelsegmenten alle Prozesse, die den Product Lifecycle eines Produktes beschreiben, hier am Beispiel des Produktentwicklungsprozesses, der wiederum eine eigene Prozesslandkarte für verschiedene Branchen enthält (Abb. 6).

Abb. 5. Generische Prozesse des PLM

16

PLM im Überblick

PLM Prozessbausteine

Managementprozesse Unternehmensplanung

Projektmanagement Innovation

Qualitätsmanagement

Marketing

GeschäftspartnerManagement

Risikomanagement

Kernprozesse Produktmanagementprozess

Kundenmanagement

Produktentwicklungsprozess

Änderungsmanagement

Serviceprozess

Prozessentwicklung

Anfrageprozess

Produktionsprozess

Unterstützungsprozesse Personal

Finanzen Controlling

Management Logistikkette

IT Organisation

externe Dienstleistung

Recht

Beschaffung Einkauf

Abb. 6. Prozesslandkarte des PLM

2.2

Generische PLM-Prozesse und deren Bedeutung

2.2.1 Time to Market Unter dem Begriff Time to Market verbirgt sich der Prozess von der Produktidee bis zur Markteinführung. Da die Produktlebenszeit, also die Verweilzeit von Produkten im Markt, ständig sinkt, ist es um so wichtiger, Produkte schnell und kostengünstig auf den Markt zu bringen und gleichzeitig eine hohe Qualität zu gewährleisten. Durch rechtzeitigen Markteintritt, möglichst vor vergleichbaren Produkten der Konkurrenz, können entscheidende Marktanteile gesichert werden. Somit sinken am Markt auch die Zeiten, die für die Produktentwicklung zur Verfügung stehen, eine umfassende Steuerung des Time-To-Market-Prozesses wird für Unternehmen immer wichtiger. 2.2.2 CAD Integration / Engineering Um die Entwicklungszeit eines neuen Produktes zu reduzieren und die Verfügbarkeit der Produktdaten für alle beteiligten Bereiche sicherzustellen, benötigen die meisten Unternehmen in der Fertigungsindustrie eine direkte Integration ihrer

Generische PLM-Prozesse und deren Bedeutung

Implementierung • Konzept • Kompetenz • Engagement Kosten • Lizenzen • Implementierung • Zusatzkosten (HW / Server, ...) • Lizenzmodell

Strategische Eignung • Zukunftssicherheit • Verbreitung / Referenzen • Service- und Supportgarantien

Standardisierung • Einheitlichkeit von Prozessen & Bedienung • Oberfläche

Funktionale Eignung • Massenverarbeitung • Prüfung (Freigabe etc.) • Fkt. Anpassungsmöglichkeiten

Kriterienmodell für die Integration von CAD-Systemen

Administration • Architektur / Systemvielfalt Usability • Releasefähigkeit • Intuitive Führung • Support • Bedienung aus CAD • Flexibilität der Oberfläche

17

Performance • Check-in / Check-out • Anwendung • Stabilität

Abb. 7. Kriterienmodell für die Integration von CAD-Systemen

CAD-Systeme in die Geschäftsprozesse rund um Enterprise Resource Planning, Produktion, Supply Chain Management und Customer Relationship Management. 2.2.3 Collaboration Collaboration ermöglicht Zusammenarbeit und den Austausch von Informationen unternehmensinterner und unternehmensübergreifender Abteilungen entlang des Produktentwicklungsprozesses. Die Zusammenarbeit unterschiedlichster Unternehmen mit einer gemeinsamen Zielsetzung führt zu wertschöpfungsorientierten Netzwerken mit Zulieferern, Kunden und Partnern. Eine Neuausrichtung zu kooperationsförderlichen Aufbauund Ablauforganisationen wird bei allen am Prozess Beteiligten unumgänglich. Hieraus entstehen Herausforderungen wie: x Kooperative, virtuelle und integrierte Produktentstehungsprozesse x Frühe und enge Einbeziehung von Engineeringpartnern x Wachsende Anzahl von Experten und deren Wissen x Projektorientierte Technologieentwicklung x Gemeinsames Kosten- und Zeitmanagement x Hohe Transparenz der Entscheidungsprozesse x Synchronisation der Produktionsnetzwerke

18

PLM im Überblick

Abb. 8. Collaboration-Prozess in der Automobilindustrie am Beispiel von Produktdaten

2.2.4 Stammdatenmanagement Das Stammdaten- oder Produktdatenmanagement umfasst die Verwaltung aller produktbeschreibenden Stammdaten wie Dokumente, Artikelstämme, Stücklisten, aber auch Spezifikationen und klassifizierende Sachmerkmale. Zu verwalten sind neben dem Datenaufwuchs im Produktentstehungsprozess auch Änderungsstände und Konfigurationen über die im Produktlebenszyklus durchgeführten Änderungen. Stammdatenmanagement setzt die abgestimmte Definition von Datenobjekten und ihren Datenfeldern voraus, um über den gesamten Produktlebenszyklus konsistente und harmonisierte Stammdaten zu garantieren. Neben den Daten sind im Stammdatenmanagement auch die Pflegeprozesse zur Entstehung und Änderung der Daten und die verantwortlichen Organisationseinheiten zu definieren. Hier haben sich in der Praxis Prozesse bewährt, die eine Datenpflege am Ort der Entstehung (in der Fachabteilung) vorsehen und diese kombinieren mit einer zentralen Stammdatenpflegestelle, die Verantwortung für den Gesamtprozess (im Sinne einer permanenten Kontrolle und Optimierung) trägt und eventuell auch wesentliche Dateninhalte selbst pflegt (z. B. Nummernvergabe). Schließlich gehört zum Stammdatenmanagement die Definition einer Stammdaten-IT-Architektur mit Datenflüssen und Datenverteilung an alle Systeme, in denen die Stammdaten für nachgelagerte Prozesse benötigt werden. Hier bewährt es sich, für die Stammdatenobjekte jeweils eindeutig führende Systeme zu definieren, in denen die Objekte gepflegt und geändert werden und von wo eine Verteilung ihren Ausgang nimmt.

Generische PLM-Prozesse und deren Bedeutung

19

2.2.5 Enterprise Content Management Enterprise Content Management (ECM) ist das Management aller im Unternehmen vorhandenen unstrukturierten Informationen. Dazu gehören – im Gegensatz zu strukturierten Informationen in ERP-Systemen oder Datenbanken – Dokumente, Dateien beliebiger Formate sowie gescannte Belege. Diese Informationen sind zu erzeugen, zu verwalten, mit Partnern auszutauschen. Es müssen Funktionen zur PLMProzessintegration, zum Input- und Outputmanagement, zur Sicherung und zur Langzeitaufbewahrung angeboten werden. ECM geht also über die Grundfunktionen des klassischen Dokumentenmanagements im Produktdatenmanagement hinaus. Es umfasst auch die Funktionen einer Archivierung, bei der weniger der Lebenszyklus eines Dokuments, sondern dessen sichere und unveränderte Langzeitaufbewahrung im Vordergrund steht. Man versucht, alle dokumentähnlichen Informationen – egal ob es sich noch um ein lebendes Dokument im Dokumentenmanagement oder ein bereits unveränderbar archiviertes Dokument handelt – mit der gleichen Technologieinfrastruktur zu verwalten. 2.2.6 Asset Lifecycle Management / Instandhaltung PLM umfasst nicht nur die Verwaltung der Produktdaten, sondern auch die damit in Zusammenhang stehende Verwaltung der technischen Anlagen und Instandhaltungsressourcen eines Unternehmens über deren gesamten Lebenszyklus hinweg. Dazu sind Funktionen aus den Bereichen Wartung, Reparatur, Instandhaltung und Service zu etablieren, umfassend als Asset Lifecycle Management bezeichnet. Den Grundstein für eine funktionierende Instandhaltung legt bereits der Produktentwicklungsprozess. Hier entstehen nicht nur die ersten Instandhaltungsstammdaten, sondern es sind Instandhaltungsfunktionen vorzudenken und Instandhaltungsbedürfnisse zu berücksichtigen. 2.2.7 Qualitätsmanagement Qualitätsmanagement (QM) ist nicht mehr allein die Unterstützung klassischer Funktionen wie der Qualitätsprüfung. Im Sinne eines Lebenszyklusmanagements meint QM das Management der Produkt- und Prozessqualität in Hinblick auf Qualitätssicherung und Qualitätsverbesserung. Collaborative Produktentwicklungsprozesse, die den Austausch von Produktinformationen über Unternehmensbereiche und Unternehmensgrenzen zur Folge haben, bedingen auch eine neue Ausrichtung des Qualitätsmanagements. Qualitätswesen ist bereits in die Produktentwicklung mit einzubeziehen. Qualitätsziele sind in einer frühen Entwicklungsphase zu berücksichtigen. Qualitätskontrolle und Qualitätssicherung ist in der

20

PLM im Überblick

Produktentwicklung vorzudenken, ein Regelkreis für das Qualitätsmanagement ist zu etablieren. Beispiele dafür sind die in der Automobilindustrie etablierten Ansätze APQP1 und PPAP2, Six-Sigma oder GMP3 in der Prozessindustrie. Effizientes und effektives Qualitätsmanagement bedeutet: x Alle Prozesse der Qualitätsplanung, Qualitätskontrolle und der kontinuierlichen Verbesserung werden unterstützt. x Mitarbeiter haben alle wichtigen qualitätsrelevanten Informationen jederzeit zur Verfügung. x Alle Anforderungen im Sinne eines Total Quality Management wie auch entsprechender Qualitätsnormen, branchenbezogener Richtlinien sowie gesetzlicher Verordnungen werden erfüllt [19].

2.3

Schwerpunkte in verschiedenen Branchen

Die Einführung eines PLM-Systems ist immer verbunden mit einer Anpassung wichtiger Unternehmensprozesse – vor allem im Engineering. Im Ergebnis entstehen optimierte Abläufe, die die zusätzlichen Möglichkeiten des DV-gestützten Product Lifecycle Management berücksichtigen und die als Workflow in PLMSystemen abgebildet werden können. Dies führt insbesondere bei komplexen Abläufen und verteilter Arbeit zu einer spürbaren Beschleunigung der Produktentwicklung. In den folgenden Abschnitten sollen verschiedene Branchenschwerpunkte im Rahmen von PLM-Projekten aufgezeigt werden. In den späteren Kapiteln wird dann wieder im Einzelfall der Branchenbezug hergestellt. 2.3.1 Virtuelle Produktentwicklung im Bereich Automobilindustrie Die virtuelle Produktentwicklung stärkt die Innovationskraft der Unternehmen in der Automobilindustrie. Fachwissen wird durch eine vollständig digitale Abbildung von Prozessen und Produktdaten für verschiedene Sichten zielgruppengerecht aufbereitet und unternehmensweit zugänglich. Dies ist der Ansatz von PLM. Es geht also nicht nur um die Abbildung des Entwicklungsprozesses bis zur Fertigung, sondern um einen vollständigen, digitalen Produktlebenszyklus. Unternehmen können damit beliebig viele Partner und Zulieferer in ihre lokale Arbeitsumgebung einbinden. Das Ergebnis sind erheblich verkürzte Innovationszyklen und enorme Kosteneinsparungen – das Fraunhofer Institut geht von bis zu 35 Prozent aus, Erfahrungswerte aus Projekten liegen in Einzelfällen auch darüber vor. 1

Advanced Product Quality Planning

2

Production Part Approval Process

3

Good Manufacturing Practices

Schwerpunkte in verschiedenen Branchen

21

Produktentwicklungsprozess

OEM

Marketing Research

Konzept

Design

Multi-Tier Supplier

Anfragemanagement

Anforderungsmanagement OEM's

Produktmanagement

1 Tier Supplier

Konzept

Anforderungsmanagement OEM, Multi-Tier

Konstruktion

2 Tier Supplier

Abb. 9. Prozesslandkarte des Produktentstehungsprozesses am Beispiel der AutomotiveBranche

Die Verkürzung der Modellzyklen, Reduzierung der Produktentwicklungszeit, Verlagerung von Entwicklungsaufgaben, Zunahme der Varianten und der Trend zu Systemen sind wesentliche Faktoren, die bei den Automobilzulieferern zu einer dramatischen Erhöhung der Anzahl und der Komplexität von Entwicklungsprojekten und Produkten führen. 2.3.2 PLM-Anforderungen im Bereich Investitionsgüter Maschinen- und Anlagenbauer stehen häufig vor der Situation, dass Maschinen zwar standardisiert sind, mit Varianten angereichert werden, aber dennoch ein hoher Anteil an kundenindividuellen Änderungen je Auftrag erforderlich wird. Dadurch sind interne und externe Prozesse schlecht oder sogar gar nicht planbar. Selbst wenn 80% einer Maschine standardisiert produziert werden, verursachen 20% der individuellen Fertigung meist 50% der Kosten. Auch in Kundenservice und Wartungsprozessen verursachen genau diese 20% im Produktlebenszyklus einen hohen Anteil an Kosten im Bereich der Ersatzteilbeschaffung oder Austauschbarkeit von Funktionsbaugruppen. Damit wird der Änderungsprozess zur zentralen Kostenschraube in diesen Unternehmen. „Wer die Änderung beherrscht, beherrscht den Markt“, ist eine gängige Aussage in dieser Branche.

22

PLM im Überblick

47 %

Neuerungsbedingte Änderungen

40 % (21 %)

53 %

Vermeidbare Änderungen

davon

Fehlerbedingte Änderungen

60 % (32 %)

Unvermeidbare Änderungen

Quelle: Lindemann

Abb. 10. Reduzierung vermeidbarer Änderungen durch die Optimierung von Änderungsprozessen

Folgende übergeordnete Ziele sind für den Änderungsprozess relevant: x Maximale Sicherheit x Minimaler Änderungsaufwand / Kosten im Änderungsprozess x Flexibilität / Schnelligkeit zum Kunden hin x Risikominimierung durch RLA (Risk Level Assessment) hinsichtlich kommerzieller, anwendungstechnischer und produktionstechnischer Aspekte x Kostentransparenz für den Änderungsprozess

Workflow Änderungsantrag Änderungsmeldung

PM

CB

Antrag angelegt Änderungsantrag anlegen

Konstr. Avor alle Objekte geprüft

Antrag freigegeben

Änderungsobjekte auswählen und freigeben

Machbarkeit Einzelobjekte prüfen

Abb. 11. Workflowunterstützte Änderungsprozesse schaffen Sicherheit und Prozesstransparenz

Schwerpunkte in verschiedenen Branchen

23

2.3.3 Beherrschung von Stammdaten – eine PLM-Herausforderung für die Prozessindustrie Betrachtet man die Unterstützung der Produktentwicklung in der Prozessindustrie, so stellt man oft erhebliches Verbesserungspotenzial im Bereich des Stammdatenmanagements fest. Der Produktdatenentstehungsprozess umfasst hier typischerweise viele beteiligte Unternehmensbereiche und Einzelpersonen, ist somit bei hohen Prozesslaufzeiten sehr abstimmungsintensiv. Die Fülle der zu verwaltenden Daten ist oft deutlich höher als in der stückorientierten Fertigung. Zwar sind Zeichnungen und CADDaten wesentlich seltener anzutreffen, auch die Produktstrukturen sind weniger komplex. Aber im Bereich der Spezifikationen und Artikelstammdefinitionen ist eine große Menge an Datenfeldern und Attributen zu verwalten. Extrem ist die Fülle von anfallenden produktbeschreibenden Daten zum Beispiel im Pharmabereich, bedingt durch die gesetzlich vorgeschriebenen Zulassungen. Oft gibt es eine Reihe von dezentralen, stammdatenführenden Systemen, die nicht unternehmensweit abgestimmt sind. Heterogene Systemlandschaften für den Produktentstehungsprozess und die Abwicklung der Kerngeschäftsprozesse forcieren noch das Problem. Die Folge sind redundante und inkonsistente Daten, manuelle Schnittstellen, wiederholte Dateneingabe. Unklare Pflegeprozesse, gerade bei der Datenentstehung im Rahmen der Time To Market-Prozesse erschweren die Sicherstellung einer durchgängigen Datenqualität und die Einhaltung unternehmensweiter Qualitätsrichtlinien. Das Bewusstsein, dass qualitativ hochwertige Produktstamm-

Analyse und Verbesserung

Beschreibende Produktdaten  Materialqualität  Lackierung

SpezifikationsVerwaltung

 Grüner Punkt  Prägung

 WirkstoffGehalte

RezepturManagement

 Innovation und Renovation

... QM-Daten Produktion

 Zusammensetzung  Rohstoffe  Mengen

 Qualitätssicherung  Markt-Daten

Produktidee

 Einkaufsdaten

 AV-Medien

Planungsrezept

Stückliste

Dokumente  Zeichnungen  Berichte

 Stammdaten  Lieferantendaten

Machbarkeit DokumentenVerwaltung

 Kalkulationsdaten  Preise  Materialien (Logistik)

Materialstamm Klassifikation

Abb. 12. Entstehung von Stammdaten entlang des Entwicklungsprozesses

24

PLM im Überblick

daten Voraussetzung für erfolgreiche Optimierung der Kerngeschäftsprozesse wie Supply Chain Management, Strategisches Einkaufsmanagement oder Customer Relationship Management sind. Im PLM-Projekt gilt es dann, sich vorrangig mit der Sicherstellung einer einheitlichen Produktdatenbasis, durchgängigen Stammdatenprozessen und einer definierten Stammdatenverantwortung zu beschäftigen und dies in den im nächsten Abschnitt beschriebenen Time-To-Market-Prozess zu integrieren. 2.3.4 Time to Market – Eine wichtige PLM-Komponente im Bereich Konsumgüter Der Konsumgüterbereich ist in der Regel geprägt von Produkten mit Serienfertigung. Ob elektronische Konsumgüter (z. B. Waschmaschinen, Trockner) oder Produkte aus dem Bereich Food & Beverage (z. B. Getränke, Verpackungen, Süßwaren), sie alle haben eine Gemeinsamkeit: Produzenten müssen schnell und flexibel auf die Bedürfnisse des Marktes und die technischen Neuerungen reagieren. Bei kürzer werdenden Produktzyklen wird es immer wichtiger eine effiziente und flexible Produktentwicklung zu haben. Das Produkt muss möglichst schnell zur Marktreife gelangen um so früh als möglich Profit zu generieren. Die Definition und systembasierte Unterstützung eines einheitlichen, effizienten Entwicklungs- oder Time-to-Market-Prozesses ist damit eine der wichtigsten Aufgaben im Rahmen von PLM im Bereich Konsumgüter und Voraussetzung für den Unternehmenserfolg. Nur so kann die nötige Transparenz innerhalb eines Entwicklungsprojektes und über alle laufenden Entwicklungen eines Unternehmens

Abb. 13. Konsumgüter-Industrie mit Schwerpunkt Innovation und Produktentwicklung

Schwerpunkte in verschiedenen Branchen

25

hinweg geschaffen werden. Dies stellt die Grundlage eines erfolgreichen Entwicklungsprojektmanagements dar und schafft gleichzeitig die Grundlage eines Portfoliomanagements. ÎReduzierung Time to Market durch x Professionelles Projekt- und Prozessmanagement in der Produktentwicklung x Effizientes Änderungsmanagement von Produkten x Transparentes Stammdaten- und Dokumentenmanagement ÎErhöhung der Innovationskraft durch x Unternehmensweites Wissensmanagement x Effiziente Ideengenerierungsprozesse x Effektive Auswahl- und Screeningverfahren x Entlastung kreativer Mitarbeiter von administrativen Tätigkeiten

3

Bausteine und Prozesse im PLM

3.1

Ein prozessorientierter PLM-Ansatz

BU SIN

ESS PROCESS ES

Sales, Purchase, Produ

ction

, Lo

g is

Process Controlling E MANAGEM EN ANG T CH

tic

s…

Process Strategy

Sa r

CO T NT Process EN I NU OUS IMPROVEM Implementation

ba ne sOx

Process Design

l

ey

Ac

t,

Ri

sk

&C

COM

on t

rol

P LIA

Man

NCE PROCESSES

agem

ent, Quality Manageme nt …

Abb. 14. Process Lifecycle der IDS Scheer, in PLM-Projekten wird dieser mit den Bausteinen PLM Strategy, PLM Process Design, PLM Process Implementation und PLM Process Controlling ausgeprägt

Produkt-Lebenszyklus-Management ist eine Strategie, die auf alle Prozesse rund um das Produkt fokussiert. Daher orientiert sich die Auswahl und Ausgestaltung der PLM-Bausteine an den im jeweiligen Betrachtungsbereich liegenden Prozessen; daher setzt sich eine PLM-Lösung eines entwicklungsorientierten Unternehmens aus anderen PLM-Bausteinen zusammen wie die eines Unternehmens mit Schwerpunkt im Service-Bereich. Um PLM effizient und zielgerichtet realisieren zu können, ist daher durchweg ein prozessorientierter Ansatz zu empfehlen. Eine an Funktionen orientierte Vorgehensweise, die in der Vergangenheit beispielsweise bei der Einführung von CAD noch propagiert wurde, ist bei PLM nicht zielführend, da sie das Produkt selbst nicht in das Zentrum der Betrachtung setzt. Für PLM charakteristisch ist, dass einerseits das Produkt selbst mit Entwicklung, Produktion, Distribution und Service im Mittelpunkt steht und andererseits Ausgangspunkt und Ziel aller Prozesse auf oberster Ebene der Kunde ist. Das be-

28

Bausteine und Prozesse im PLM

deutet, dass die gesamte Prozesskette, die ein Produkt durchläuft, mit PLM abgedeckt werden muss, und dabei alle durchlaufenen Funktionen und Organisationsbereiche ebenso integriert werden wie die spezifischen IT-Systeme. Zentraler Bestandteil eines prozessorientierten PLM-Ansatzes ist immer die Definition einer übergeordneten PLM-Strategie. Diese Strategie ist Dreh- und Angelpunkt für die spezifische Ausgestaltung eines PLM-Prozess-Regelkreises. Dieser Regelkreis ist in Abb. 14 dargestellt und besteht aus den 4 Bestandteilen: x PLM-Strategie x PLM-Prozess-Design x PLM-Prozess-Implementierung x PLM-Prozess-Controlling Eine definierte PLM-Strategie legt die Zielsetzungen und Randbedingungen für ein PLM-Prozess-Design fest. Des Weiteren werden in der Strategiephase Kenngrößen ermittelt oder vorgegeben, die in der darauf folgenden Design-Phase spezifiziert und in eine Metrik transferiert werden, sofern die Kenngrößen quantifizierbar sind. Die PLM-Implementierung bildet unter Berücksichtigung der festgelegten Strategie die in der Design-Phase definierten Ziel-Prozesse in einer zuvor ausgewählten IT-Systemlandschaft ab. In der Controlling- oder Steuerungs-Phase werden nun die in der Strategie festgelegten und in der Design-Phase ausspezifizierten Kenngrößen auf der Basis der Implementierung gesteuert und gemessen. Die Ergebnisse sind wiederum Eingangswerte für eine Optimierungsschleife mit erneutem Start der Design-Phase. Die Ergebnisse aller Phasen finden ebenfalls eine Rückkopplung zur Strategie, um die Vorgaben zu verifizieren bzw. die Vorgaben den sich fortentwickelnden Randbedingungen eines Unternehmens und eines PLM-Projektes anzupassen. Grundsätzlich ist ein Einstieg an jedem Punkt dieses Regelkreises möglich; es muss nicht immer mit der Design-Phase begonnen werden. So kann beispielsweise auch auf der Basis einer laufenden Installation mit der Messung der Prozesse begonnen werden, um Input für ein Prozess-Redesign zu erhalten. 3.1.1 PLM-Strategie Die Schwerpunkte der PLM-Strategien unterscheiden sich in der Regel nach den verschiedenen Branchen, nach der Quelle der Wertschöpfung eines Unternehmens, aber auch nach der aktuellen Situation, in der sich ein Unternehmen befindet, dem Entwicklungsstand seiner Prozesse sowie dem Integrationsgrad der unterstützenden IT-Systeme. Exemplarisch seien hier einige PLM-Strategien angeführt: x Harmonisierung unternehmensweiter Produktentwicklungs-Prozesse infolge eines Zusammenschlusses von Unternehmen x Optimierung der produktzentrierten Prozesse aufgrund veränderter Randbedingungen, wie z. B. Einsatz neuer Technologien in den Produkten, neue oder geänderte Kunden- und Marktanforderungen, Weiterentwicklung des Unternehmens vom Teilezulieferer zum Systemlieferanten

Ein prozessorientierter PLM-Ansatz

29

x Re-Strukturierung eines Unternehmens in eigenverantwortliche Geschäftsbereiche (je Geschäftsfeld oder Funktion) mit eigenen internen Prozessen und Systemen, aber definierten Standards an den Prozess-Schnittstellen x Harmonisierung des unternehmensweiten Produktspektrums mit einhergehender Zentralisierung des Stammdaten-Managements x Strategische Ausrichtung des Unternehmens auf eine einheitliche IT-Infrastruktur mit entsprechenden Systemwechseln x Konzentration auf die Kernprozesse und Schlüsselprodukte des Unternehmens mit einhergehendem Outsourcing der nicht mehr im Fokus befindlichen Bereiche x Verstärkung der unternehmensübergreifenden Zusammenarbeit und engere Anbindung der Partner (insbesondere im Rahmen von Globalisierung) Die PLM-Strategie prägt folglich die Schlüsselfaktoren für den gesamten Geschäftsprozess-Lebenszyklus aus. Wenn sich beispielsweise ein reiner Teilezulieferer zum Systemhaus entwickelt, so ist ein neuer Schlüsselfaktor seine Innovationskraft und die Fähigkeit, diese Innovationen zeitgerecht in marktfähige Produkte umzusetzen. Gleichzeitig bedeutet das eine Änderung in der Wertschöpfung des Zulieferers; während vorher vornehmlich Fertigung und Logistik für den Unternehmenserfolg verantwortlich waren, kommt nun noch der gesamte Bereich der Produktentwicklung hinzu. Der Produkt-Lebenszyklus des Zulieferers muss folglich um die Produktentstehungsprozesse und die damit verbundenen logistischen Prozesse erweitert werden. Neben der eigentlichen Prozessdefinition ist die Definition von Kennzahlen und deren Quantifizierung unerlässlich, um den Projekterfolg zu messen und die Ziele auf ihren Erreichungsgrad hin zu verifizieren. Typische PLM-Prozesskennzahlen sind beispielsweise: x Kosten eines Prozessschrittes und in der Summation Kosten eines Prozesses. Beispiele:  Kosten für eine Änderung am Produkt  Kosten für ein Produkt über einen Zeitraum hinweg inkl. der Kosten aller bis dahin aufgelaufenen Änderungen  Kosten für einen Prototypen  Kosten für eine Simulation  Kosten für eine Vorserienstudie x Zeit für die Vorbereitung, Durchführung und Nachbereitung einer Aktivität und eines Prozesses; dabei kann Vor- und Nachbereitung die Transformation von Daten oder Transportzeit bedeuten. Wichtig ist in diesem Zusammenhang auch die Aufnahme von Liege- und Wartezeiten. Beispiel:  Zeit für die Detailkonstruktion  Zeit für Datenkonvertierung, Datentransfer und Datenaufbereitung

30

Bausteine und Prozesse im PLM

 Rechenzeit für Simulationen  Zeit für die Aufbereitung von VR-Studien x Anzahl der zu durchlaufenden Schleifen (z. B. im Rahmen eines Prüfprozesses) und Wiederholungen. Beispiele:  Anzahl von Änderungsdurchläufen  Anzahl von Rückweisungen bei einer Freigabe  Anzahl von iterativen Berechnungen und Simulationen aufgrund von Design-Änderungen x Anzahl der involvierten Personen und Organisationseinheiten. Beispiele:  Einbindung externer Ressourcen für neue Fertigungstechnologien  Organisation in virtuellen Design-Teams  Einbindung von zentralem Einkauf, Qualitätsmanagement und Normung in Freigabeprozess für Produktänderungen x Anzahl der zu nutzenden Systeme, Informationsquellen oder Datenqualität etc. sowie des damit verbundenen Aufwands. Beispiele:  Einsatz verschiedener CAD-Systeme in Produkt- und Sondermaschinenkonstruktion verbunden mit der Notwendigkeit, Schnittstellenprogramme zu nutzen und Datenverlust während der Konvertierung in Kauf zu nehmen  Nutzung unterschiedlicher Normteilkataloge an verschiedenen Standorten und in verschiedenen Ländern mit der Folge, dass ein zentraler Einkauf Anfragen nicht bündeln kann  Hohe Stammdatenqualität für reibungslosen Übergang von Entwicklung zu Logistik x Anzahl und Umfang der Input-/Output-Dokumente, CAD-Modelle, Spezifikationen etc. Beispiele:  CAD-Modell mit angehängten Zeichnungen  Vom CAD-Modell abgeleitete Neutralformate x Risikoquantifizierung eines Prozesses mit Unterteilung in rechtliche, kaufmännische, konstruktive, produktionstechnische, organisatorische und logistische Risiken. Beispiele:  Personalbesetzung eines Entwicklungsprojektes  Projektklassifizierung in Neuentwicklung, Anpassungs-, Variantenkonstruktion

Ein prozessorientierter PLM-Ansatz

31

 Produktkonfiguration mit Entscheidung über den anzuwendenden Projektplan und Anzahl der zu durchlaufenden Quality Gates oder Meilensteine  Risiko-Management innerhalb eines Projektes x Die Anzahl an Aktivitäten einer Person oder Stelle. Beispiele:  Detailkonstruktion und Berechnung durch einen Konstrukteur  Zeichnungserstellung mit Material- und Stücklistenanlage sowie einhergehender Klassifizierung (Aufbau der Sachmerkmalsleiste) durch eine Person  Verantwortlichkeit für eine große Zahl von Projekten x Mengengerüste über Anzahl der Prozessdurchläufe und Anzahl der verschiedenen Produkte. Beispiele:  Bauteiländerungen pro Jahr  Anzahl und benötigte Zeit für Dauerprüfungen und Belastungstests pro Baureihe  Konfigurationen aus einer Menge von Basiskomponenten, Beherrschung der Variantenvielfalt  Anzahl der Neuentwicklungen, Anpassungs- und Variantenkonstruktionen  Anzahl der Nachbesserungen im Service 3.1.2 PLM-Prozess-Design Die im Rahmen der PLM-Strategie festgelegten Prozess-Ziele fließen unmittelbar in die Soll-Prozess-Definition ein. Dabei ergeben sich die Potenziale sowohl aus den quantitativ messbaren Prozesskennzahlen als auch aus nicht-quantifizierbaren Faktoren, wie Möglichkeiten zur Produktverlagerung, Job-Rotation, LösungsAkzeptanz oder Innovationsfähigkeit. Beim Prozess-Design werden in der Regel die Prozesse entsprechend ihrem Beitrag zur Wertschöpfung eines Unternehmens eingeteilt in: x Kernprozesse x Management-Prozesse x Support-Prozesse Die Kernprozesse umfassen in dem hier beschriebenen Kontext die eigentlich wertschöpfenden Prozesse im Sinne von End-to-End-Prozessen, d. h. die Prozesse beginnen beim Kunden und enden wiederum dort. Der Produktlebenszyklus beginnt beispielsweise mit der Kundenanfrage, erstreckt sich über Spezifikation, Design, Konstruktion, Berechnung bis hin zur Arbeitsvorbereitung, Fertigung und Montage und endet nach der Qualitätsprüfung mit der Lieferung zum Kunden.

32

Bausteine und Prozesse im PLM

Managementprozesse steuern im Sinne der festgelegten PLM-Strategie diese PLM-Kernprozesse. So wird beispielsweise die Produktpalette mit Hilfe eines Portfoliomanagements optimiert, so dass eine Unternehmensentwicklung vom Teilezulieferer zum Systemzulieferer erfolgen kann. Die Risikobetrachtung eines Projektes fließt in das Projektmanagement ein und das Innovationsmanagement beeinflusst im Wesentlichen die frühen Phasen der Produktentwicklung. Die Supportprozesse unterstützen die PLM-Kernprozesse. Exemplarisch seien an dieser Stelle Prozesse zur Personalentwicklung, zur Abrechnung oder Prozesse bzgl. der IT-Infrastruktur angeführt. 3.1.3 PLM-Prozess-Implementierung Auf der Basis einer Prozessdefinition kann dann eine Evaluierung in Frage kommender Systemlösungen durchgeführt werden. Während beispielsweise in der Vergangenheit bei der CAD-Systemauswahl funktionale Aspekte eine tragende Rolle spielen, tritt bei der PLM-Systemauswahl die durchgängige Unterstützung der definierten Soll-Prozesse in den Vordergrund. Dabei konzentriert sich die Prozessunterstützung auf die in den Prozessen festgehaltenen und mit Kennzahlen versehenen Anforderungen, die identifizierten Schlüsselfaktoren und die Behebung von erkannten Defiziten. Abb. 15 verdeutlicht – trotz der unvollständigen Abbildung der realen Verhältnisse – die Komplexität einer PLM-Prozess-Implementierung. In den unterschiedlichen Phasen des Produkt-Lebenszyklus werden sehr unterschiedliche Software-

CAD

Datenbanken

ERP/PPS

Kernprozess Produktentwicklung

Internet

Simulation

Abb. 15. PLM-Prozess-Implementierung

Datenaustausch

Ein prozessorientierter PLM-Ansatz

33

systeme eingesetzt, um die spezifischen Aufgaben zu lösen. So werden beispielsweise mit Hilfe der CAD-Systeme geometrisch orientierte Produktdatenmodelle erzeugt, die mit Hilfe von Datenbanken verwaltet werden, Diese Datenmodelle werden um Informationen aus dem Internet angereichert, beispielsweise um Katalogdaten von Zulieferern. Zur Verifizierung und Optimierung werden diese Daten an Berechnungs- und Simulationsprogramme übergeben. Mit externen Entwicklungspartnern und Zulieferern werden zu den unterschiedlichsten Phasen unterschiedlich qualifizierte Datenmodell ausgetauscht. Letztendlich werden die Daten dann an ein ERP-System übergeben, um die logistischen Prozesse abzuwickeln. 3.1.4 PLM-Prozess-Controlling Oft ignoriert oder schlichtweg vergessen wird die dritte Komponente des ProzessLebenszyklus: das Prozess-Controlling. Im Sinne eines integrierten Qualitätsmanagements und einer kontinuierlichen Verbesserung der Geschäftsprozesse ist es unerlässlich, die erreichten Ziele zu überprüfen und weitere Optimierungspotenziale zu entdecken. Die Ergebnisse des Prozess-Controllings sind wiederum Input für ein anschließendes Re-Design der Prozesse, um die identifizierten Optimierungspotenziale zu erschließen und so den Regelkreis zielgerichtet zu steuern. Dadurch wird deutlich, dass Prozessmanagement kein einmaliger Prozess, sondern eine kontinuierliche Querschnittfunktion in einem sich permanent weiterentwickelnden Unternehmen ist. Dieser allgemein gültige Regelkreis für Geschäftsprozessmanagement gilt auch und gerade für das Management von Produkten über den gesamten Lebenszyklus hinweg. Die Analogien zur Produktentwicklung sind offensichtlich: Ebenso wie die Entwicklung eines neuen Produktes heutzutage in der Regel eine Anpassung eines existierenden Produktes an geänderte Anforderungen darstellt, basiert ein optimierter Prozess auf einem explizit oder implizit bereits existierenden Prozess. Die eigentlichen Herausforderungen liegen in der Identifikation der Optimierungspotenziale und der effizienten Gestaltung eines Change-Managements. Generell sollte dem Prozess-Controlling ein hoher Stellenwert eingeräumt werden. Ebenso wie Produkte und Produktionsanlagen permanent intern und extern auf ihre Tauglichkeit und Effizienz hin untersucht werden, müssen auch Prozesse permanent überprüft werden, um auf geänderte Anforderungen oder sich wandelnde Rahmenbedingungen schnellstmöglich reagieren zu können. In gleichem Maße sollten auch die unterstützenden IT-Systeme in regelmäßigem Abstand kritisch auf ihren Erfüllungsgrad hin analysiert werden. Zeiträume von 5 bis 7 Jahren für die Datenerzeugungssysteme und 8 bis 10 Jahre für die Datenverwaltungssysteme haben sich hier als sinnvoll und praktikabel erwiesen. Abb. 16 verdeutlicht anhand eines Prozessbeispiels, welche Aussagen ein Prozess-Controlling liefern kann. Die Verteilung der Geschäftsvorfälle auf die unterschiedlichen Prozessabläufe gibt erste Hinweise auf Möglichkeiten zur Optimierung. Hiermit können beispielsweise auch Benchmarks zwischen verschiedenen Unternehmensbereichen oder Werken durchgeführt werden. Ebenso kann eine Analyse der Durchlaufzeiten hilfreiche Ansätze zur Fehleranalyse liefern.

34

Bausteine und Prozesse im PLM

Abb. 16. PLM-Prozess-Controlling

3.2

Komposition einer integrierten PLM-Lösung

Da in der Produktentwicklung durch Innovation und Kreativität die Weichen für den Unternehmenserfolg gestellt werden und dieser Bereich 80% der später entstehenden Produkt- und Produktionskosten festlegt, trägt der Bereich Engineering eine besondere Verantwortung für die Wertschöpfung eines Unternehmens. Daher spielt auch die Gestaltung der Engineering-Prozesse eine Hauptrolle in der gesamten Prozessarchitektur eines Unternehmens. Ebenso wichtig ist die Verzahnung dieser Prozesse mit den Prozessen anderer Unternehmensbereiche, wie Vertrieb, Marketing, Produktion und Service. Nur mit einer engen Abstimmung aller Unternehmensbereiche können Innovationen erfolgreich in neue, marktfähige Produkte umgesetzt werden. Wie bereits oben ausgeführt wurde, werden PLM-Prozesse unterschieden in x Kernprozesse, die in direktem Zusammenhang mit den Produkten stehen, x Management-Prozesse, die diese PLM-Kernprozesse steuern, und x Support-Prozesse, die als unterstützende Prozesse den Kernprozessen dienlich sind.

Komposition einer integrierten PLM-Lösung

35

Dabei beginnen insbesondere die PLM-Kernprozesse im Sinne von End-to-EndProzessen beim Kunden zur Spezifikation der Anforderungen, erstrecken sich über die Entwicklung und Arbeitsvorbereitung bis in die Produktion und Distribution und enden zuletzt wiederum beim Kunden mit der Auslieferung des gewünschten Produkts. In diesem Zusammenhang spielen auch die Themen Service und Wartung eine wichtige Rolle. Insgesamt umfasst PLM vornehmlich alle mit dem Produkt und der Produktion in Zusammenhang stehenden Prozesse: x Kreativität, erste Produktidee oder Innovation x Anforderungsaufnahme beim bzw. mit dem Kunden (Lastenheft) x Spezifikation und Konzeption (Pflichtenheft) x Eigentliche Produktentwicklung mit Modellierung, Berechnung, Simulation, Analysen, Verifikation, Risikoanalyse, Prototyping etc. x Zugehörige Prozessentwicklung für Fertigung und Montage von der Vorserie bis zur Serie x Entwicklung der notwendigen Betriebsmittel, Fertigungshilfsmittel, Sondermaschinen bis hin zu den Produktionsstätten x Unternehmensinterne und unternehmensübergreifende Zusammenarbeit x Variantenmanagement bei konfigurierbaren Produkten x Freigabe-, Änderungs- und Konfigurationsmanagement x Distribution der Produkte inkl. Verpackung x Service, Wartung und Instandhaltung x Qualitätsmanagement x Kontinuierliche Verbesserung und Produktpflege x Produktauslauf und Recycling sowie Verschrottung x Berücksichtigung rechtlicher Vorgaben und verbindlicher Randbedingungen bzgl. Produkt- und Prozess-Sicherheit, Gefahrgut-Management, Umwelt x Management aller mit den genannten Punkten in Zusammenhang stehenden Dokumentationen x Management der mit Produkten und Produktion in Zusammenhang stehenden (Teil-) Projekte und übergeordnetem Programm-Management x Archivierung der Produktdokumentation über den Lebenszyklus hinaus Daran sieht man, dass eine prozessorientierte PLM-Betrachtung nicht innerhalb einzelner Unternehmensbereiche oder an einzelnen Aktivitäten festgemacht werden kann, sondern sich als integrierender Querschnitt über das gesamte Unternehmen erstreckt. Eine mögliche Komposition der genannten PLM-Prozesse und Funktionen wird in einer PLM-Prozess-Landkarte dargestellt. Für den Bereich der Fertigungsindustrie könnte eine solche PLM-Prozess-Landkarte auf oberster Ebene wie folgt aussehen (siehe Abb. 17).

Abb. 17. PLM-Prozesslandkarte

Personaleinsatz Planung

technische Innovation

Anforderungsmanagement / Grobkonzept

Risc Level Assessment

Beschaffungsprozess

Vertragsmanagement

Customer Relationship Management

Support-Prozesse

CRM

Kern-Prozesse

Marketing Research

Management-Prozesse

externe technische Dienstleistung

Spezifikation Detailkonzept

Product Data Management

Management Logistikkette Entwicklung

Änderungsmanagement Entwicklung

Produktion

Projektmanagement Produktion

IT/Organisation PLM

Supply Chain Management

Betriebsmittelmanagement

Produktentwicklung

Arbeitsvorbereitung

Projektmanagement Innovation / F&E

Portfolio-Management

Product Data Management

Customer Relationship Management

Service- und Instandhaltung

36 Bausteine und Prozesse im PLM

Komposition einer integrierten PLM-Lösung

37

Managementprozesse wie Portfolio-, Risiko- oder Innovationsmanagement lassen sich von der Unternehmensstrategie allgemein und dabei insbesondere von der PLM-Strategie ableiten; sie steuern die eigentlichen PLM-Kernprozesse. Zur Unterstützung werden IT-, Personal- und Dienstleistungsprozesse herangezogen. Die Kernprozesse selbst beginnen, wie bereits angeführt, beim Kunden; diese Prozesse im Umfeld des Kunden-Kontakt-Managements werden oftmals mit Hilfe einer CRM-Komponente abgebildet. Von hier erstrecken sie sich über eine Anforderungs- und Spezifikationsphase und münden zunächst in der eigentlichen Produktentwicklung. Aufgrund der permanent einfließenden Änderungen wird auch der Änderungsprozess zum Kernprozess und hat Schnittstellen zu nahezu allen anderen Prozessen. Arbeitsvorbereitung, Produktionsplanung und Betriebsmittelmanagement zählen ebenso zu den PLM-Kernprozessen, da in ihnen die Materialisierung des in der Entwicklung definierten Produktes festgelegt wird. Neue Konzepte, wie Simultaneous Engineering, Digitale Fabrik oder Virtuelle Produktentwicklung, erfordern sogar eine noch stärkere Verzahnung dieser hier getrennt dargestellten Prozesse und eine tiefe Integration der unterstützenden ITSysteme. Produktion, Service und Wartung schließen dann den hier beschriebenen Lebenszyklus-Prozess. Bereits auf dieser Ebene lassen sich für einzelne Prozessbereiche PLM-Lösungsbausteine von herausragender Wichtigkeit identifizieren: x Requirements-Engineering x Wissensmanagement x übergreifendes und integriertes Dokumenten-Management x Management von Produktstrukturen und Stammdaten x unternehmensinterne und unternehmensübergreifende Collaboration x Prozessautomatisierung (Workflow) x Änderungswesen x Konfigurationsmanagement Darüber hinaus umfasst PLM vom Grundsatz her auch gesellschaftliche sowie ethische Aspekte. Insbesondere Managementprozesse bedeuten nicht nur unternehmerischen Erfolg, sondern auch in vielen Fällen eine besondere Verantwortung bzgl. der damit einhergehenden Folgen und Risiken. Während die Trends zur Globalisierung oder verteilten Standorten für gemeinsame Entwicklungsprojekte oft gesellschaftliche Probleme hervorrufen, zielt beispielsweise die Technikfolgenabschätzung auf ethische Fragestellungen. Die aktuellen Diskussionen um die deutsche, europäische und globale Wirtschafts- und Forschungspolitik oder um technische Fragen bezüglich der Nutzung von Kernkraft oder Gentechnik zeigen die Sensibilität des gesamten Themenkomplexes, aber auch die Schwierigkeit im Umgang damit. Im weiteren Verlauf wird diese Thematik nicht näher vertieft.

CADModellierung

Engineering Collaboration

KonzeptSimulation

Rapid Prototyping

ErgonomieUntersuchung

Freigabe-/ Änderungswesen

Dokumentation CAD-Modelle

Prozessdaten Fertigung Montage

Kinematik

Produktdaten Stammdaten Stücklisten

Werkstoffauswahl

Berechnung Auslegung

ProjektManagement

Validierung Funktion

Optimierung

Proof of Concept / Freigabe

38 Bausteine und Prozesse im PLM

Abb. 18. Prozesse in der Produktentwicklung (Ausschnitt)

Komposition einer integrierten PLM-Lösung

39

Betrachtet man nun den Bereich der Produktentwicklung (siehe Abb. 18), der aufgrund seiner vorher beschriebenen Wertschöpfung und Kostenverantwortung besondere Bedeutung verdient, so werden die einzelnen Bestandteile einer prozessorientierten PLM-Lösung deutlich. Die Teilprozesse umfassen neben der Spezifikationsphase die Prozesse für Produkt- und Prozessengineering, Simulation und Berechnung, Dokumentation, Validierung und Optimierung sowie Collaboration und Änderungswesen. Gesteuert werden die Teilprozesse dabei von einem übergreifenden Projektmanagement. Nach einer Freigabe in der Produktentwicklung erfolgt dann die Prozessübergabe an die Fertigung. Hier werden weitere IT-Lösungsbausteine ersichtlich, die für eine PLM-Lösung notwendig sind: x CAD- beziehungsweise CAD-/PDM-Integration x Digital Mockup x Synchrone und asynchrone Engineering-Collaboration x Status- und Versionsmanagement x Integration von Berechnungs- und Simulationsprozessen x Datenkonvertierung x Stammdaten- und Stücklistenverwaltung x Projekt- und Multiprojektmanagement Für die Zukunft immer wichtiger wird vor dem Hintergrund einer wachsenden Mechatronisierung der Produkte auch die Integration der zugehörigen Applikationen in den Bereichen der mechanischen, elektrotechnischen und informationstechnischen Komponenten. Im Bereich der Prozessindustrie (Chemie-/Pharma-, Papier-, Textil- und Metallindustrie) werden dagegen die PLM-Prozesse aufgrund der dortigen Anforderungen in anderer Weise aufgeteilt und die Kernprozesse nach anderen Kriterien priorisiert; des Weiteren kommen noch Prozess-Bereiche hinzu, wie x Umweltschutz und Produktsicherheit (Environment, Health and Safety) x Spezifikationsmanagement x Rezepturmanagement Abb. 19 zeigt zum Überblick eine Prozesslandkarte für die Prozessindustrie. Diese Aufzählung bedeutet jedoch nicht, dass in jedem Fall alle ProzessBausteine mit voller Funktionalität in einer integrierten Lösung realisiert werden müssen. Vielmehr kann mit der Qualifikation und Quantifizierung von Kennzahlen, Störfaktoren, kritischen Erfolgsfaktoren sowie Optimierungspotenzialen die unternehmens-spezifische Komposition einer PLM-Lösung erarbeitet werden. Mit Hilfe dieser Prozessparameter lassen sich dann die einzelnen PLM-Bausteine priorisieren und in Verbindung mit Mengengerüsten oder anderen Kriterien eine optimale PLM-Lösung definieren.

Abb. 19. Prozesslandkarte in der Prozessindustrie (Chemie)

Supportprozesse

Customer Relationship Management

CRM

Kernprozesse

Marketing Research

Managementprozesse

Personaleinsatz Planung

Grundlagen Forschung

Inovationsmanagement

Risc Level Assessment

Spezifikations-/ Rezepturmanagement general recipe

Anlagenplanung

Technicum

Spezifikations- / Rezepturmanagement master recipe

Product Data Management

Genehmigung / Zulassung

Laborphase

Beschaffungsprozess

externe technische Dienstleistung

Verfahrensentwicklung

F&E

Risc Level Assessment

Änderungsmanagement Entwicklung

Produktportfoliomanagement

Produktion

Rezepturmanagement control recipe

Anlagenmanagement, Reparatur und Abstellung

Testbetrieb Anlage

Verfahrensoptimierung

40 Bausteine und Prozesse im PLM

Einführung und Ausbau einer PLM-Lösung

41

Die einzelnen PLM-Arbeitspakete sollten in jedem Fall so ausgestaltet werden, dass nach der Realisierung eines Paketes bereits mindestens eine identifizierte Schwachstelle behoben oder ein Projekt-Teilziel erreicht ist, das mit entsprechenden Kennzahlen verifiziert werden kann. Des Weiteren sollte die sog. PLM-ImplementierungsRoadmap aufgrund der engen Verzahnung von PLM mit den anderen Unternehmensbereichen so formuliert werden, dass sie aus weitgehend eigenständigen Lösungsbausteinen zusammengesetzt ist, die sich auch weitgehend separat voneinander im Kontext eines übergeordneten Gesamt-Projektes realisieren lassen.

3.3

Einführung und Ausbau einer PLM-Lösung

Auch und gerade bei der PLM-Einführung dürfen die Projektgröße und die Benutzerakzeptanz nicht unterschätzt werden. Ebenso spielt die Zusammensetzung des Projektteams eine sehr wichtige Rolle. Aufgrund der Notwendigkeit, alle betroffenen Unternehmensbereiche in PLM-Prozesse zu integrieren, darf auch der Abstimmungsaufwand nicht unterschätzt werden. Dieser wächst beträchtlich, wenn eine PLM-Lösung über mehrere Standorte mit verteilten (Teil-) Prozessen hinweg konzipiert werden soll. Auch hier ist die Analogie zu einer „globalen“ Produktentwicklung wiederum offensichtlich. Aus diesem Grunde spielen die mit Kennzahlen belegte Priorisierung der zu realisierenden (Teil-) Prozesse, die Definition der zu implementierenden PLM-Bausteine sowie die Auswahl eines anerkannten Prototypen zur Illustration und Validierung eine wesentliche Rolle für den nachhaltigen Projekterfolg. In der Regel wird beim PLM-Prototyping (PLM-Pilotierung) ein kritischer Unternehmensprozess für eine Produktgruppe von tragender Wichtigkeit realisiert. Typische Pilot-Prozesse sind beispielsweise: x Freigabe oder Änderungsprozesse x Entwicklungsprozesse für Plattformen, kundenspezifische Applikationen oder Varianten x Neuanlaufprozesse x Schnittstellenprozesse, z. B. die Übergabe vom Vertrieb an die Entwicklung oder von der Entwicklung an die Produktion Für eine darauf aufbauende Ausbauphase bieten sich nun grundsätzlich folgende Alternativen an: x Übertragung des kritischen Prozesses auf andere Produktgruppen, Standorte o.ä. (Roll-Out) x Implementierung weiterer Prozesse für diese Produktgruppe x Verknüpfung der genannten Alternativen Bei der Entscheidung spielt wiederum die aktuelle Situation des Unternehmens sowie die Betrachtung der Kennzahlen und Mengengerüste eine tragende Rolle.

42

3.4

Bausteine und Prozesse im PLM

Vorteile einer prozessorientierten PLM-Einführung

Ein prozessorientierter Ansatz führt zwangsläufig zu einer genau zu den unternehmensspezifischen Prozessen passenden PLM-Lösung. Alle PLM-Anforderungen lassen sich in den Prozessen und dort hinterlegten Kennzahlen wiederfinden. Dadurch lässt sich eine PLM-Roadmap definieren, die genau auf die jeweilige Situation im Unternehmen abgestimmt ist. Wachstumspfade ergeben sich aus den Möglichkeiten, die PLM-Lösung auf weitere Prozesse auszudehnen oder die bestehenden Prozesse auf weitere Produktbereiche anzuwenden. Hierdurch kann eine PLM-Gesamtprojektplanung sukzessive an die sich stetig wandelnden Situationen und Prozesse innerhalb eines Unternehmens angepasst werden; dadurch wird nicht nur eine effizientere Einführung der PLM-Lösung erreicht, sondern auch eine nicht zu unterschätzende Minimierung des Projektrisikos.

3.5

Zusammenfassung

Mit Hilfe einer prozessorientierten PLM-Einführung können die tatsächlichen Anforderungen an eine spätere PLM-Lösung genauer spezifiziert werden. Die Orientierung am Prozess reduziert das Risiko eines PLM-Projektes und sorgt in Verbindung mit Kennzahlen für eine zielgerichtete Projektstruktur. Wichtig sind in diesem Zusammenhang die Betrachtung der Prozesse im Sinne von End-toEnd-Prozessen und die Zuordnung von Prozess-Zuständigkeiten über die gesamte Organisation hinweg. Im Sinne eines Prozess-Regelkreises sollte nach einer Prozessmodellierungs- und Implementierungsphase in jedem Fall eine ControllingPhase vorgesehen werden, um die Güte der Prozessrealisierung, den Zielerreichungsgrad sowie die Kennzahlen zu verifizieren. Diese Phase bietet erneut die Möglichkeit, sowohl Schwachstellen als auch Stärken zu quantifizieren, Projektziele neu zu definieren und damit ein Re-Design optimal zu steuern.

4

PLM und die Kerngeschäftsprozesse des Unternehmens

Die Ursprünge des PLM sind klar an den Vorläuferbegriffen wie „Engineering Data Management“ sichtbar und drücken die ehemals enge Bindung an die Produktentwicklung im engeren Sinne aus. Durch die Erweiterung des Begriffes auf „Product Data Management“ und schließlich eben „Product Lifecycle Management“ wird erkennbar, dass zunehmend die gesamten produktbezogenen Daten und schließlich die Prozesse von der Produktentstehung bis zur Auflassung bzw. Wartung und gegebenenfalls Verschrottung in den Mittelpunkt des Interesses rückten. Diese erweiterte Sichtweise bedingt gleichzeitig eine stärkere Verzahnung mit Unternehmensprozessen außerhalb der Produktentwicklung. Insbesondere sind wesentliche Anforderungen an erfolgreiche Unternehmen wie kurze Entwicklungszeiten, geringe Time to Market, niedrige Entwicklungs-, Produktions- und Änderungskosten nur durch enge Integration der Produktentwicklung mit weiteren Kernprozessen des Unternehmens und unternehmensübergreifend mit externen Entwicklungspartnern zu erreichen. Abb. 20 illustriert die Entwicklung von abteilungsbezogener Denkweise in der Produktentwicklung hin zu prozessorientierter und unternehmensübergreifender Optimierung der Entwicklungszusammenarbeit. Das führt dazu, dass der Prozess der Produktentwicklung nicht isoliert betrachtet und optimiert werden darf, sondern im Sinne der Systemtheorie als eingebunden in ein System vernetzter Teilsysteme (bzw. Teilprozesse) zu betrachten ist. Die isolierte Optimierung eines Teilsystems führt zu einem lokalen Optimum für diesen Teilprozess. Das ist die Ausgangssituation, die häufig in Unternehmen anzutreffen ist: Innerhalb der Entwicklungsabteilung sind Abläufe optimiert und sehr gut durch entsprechend angepasste IT-Systeme, beispielsweise Produkt-DatenManagement-Systeme (PDM-Systeme) unterstützt. Im Sinne des Gesamtunternehmens (bzw. des Gesamtsystems) ist aber die Summe lokaler Optima in der Regel nicht das Systemoptimum. Das heißt, die Optimierung von Prozessen, Abläufen und IT-Systemen darf nicht primär innerhalb einer Abteilung gedacht werden, sondern muss zunächst die Wechselwirkung mit übergreifenden Prozessen berücksichtigen, die jeweiligen Schnittstellen identifizieren und dadurch die Rahmenbedingungen für die Optimierung definieren. Innerhalb des so abgesteckten Rahmens bestehen dann weitere Freiheitsgrade, um die Binnenprozesse weiter zu optimieren. Dies wiederum definiert dann die Anforderungen an die unterstützenden IT-Systeme. Dadurch wird aber auch offensichtlich, dass z. B. die Evaluation eines PLM-Systems zum einen eine Unternehmensentscheidung ist, die weit mehr betrifft als den Entwicklungsbereich. Zum anderen sollte eine Systementscheidung

44

PLM und die Kerngeschäftsprozesse des Unternehmens ab 2000

1999 Prozessorientierte Gemeinschaften

1995 1985

Prozessspezifische Netzwerke: „Mauern zwischen Unternehmen“

Prozessorientierte Geschäftsprozesse

Funktionale Organisation: „Mauern zwischen Abteilungen“

Abb. 20. Entwicklung der Organisation in der Produktentwicklung: von funktionaler Abteilungstrennung hin zu prozessorientierten, unternehmensübergreifenden Entwicklungskooperationen

sinnigerweise nach einer Definition der Prozesse und Prozessschnittstellen auf Grund der dadurch vorgegebenen Anforderungen erfolgen. Dieses Prinzip des „IT follows process“ entspricht dem in der Produktentwicklung weitgehend akzeptierten „form follows function“. Diese Vorgehensweise entspricht im Übrigen derjenigen, die innerhalb der Produktentwicklung bereits seit geraumer Zeit z. B. in der Automobilindustrie gelebt wird. Hier wird zu Beginn der Entwicklung zunächst das Gesamtsystem, das zu entwickelnde Fahrzeug betrachtet und auf relativ grobem Level Komponenten und deren Schnittstellen festgelegt. Die einzelnen Entwicklungsteams haben dann innerhalb dieser Spezifikationen Freiheitsgrade zur Ausprägung der einzelnen Komponenten, wobei die Spezifikationen ständig überprüft und verfeinert werden [14]. Eine starke Prozessintegration zwischen Produktentwicklung und weiteren Kernprozessen, wie sie oben skizziert wurde und in den folgenden Abschnitten weiter ausgeführt wird, muss neben Auswirkungen auf die unterstützenden ITSysteme auch Auswirkungen auf die Organisation des Unternehmens haben. Die Definition optimierter Prozesse sollte so weit möglich Brüche, d. h. Übergänge zwischen nicht integrierten IT-Systemen, aber auch organisatorische Brüche vermeiden. In organisatorischer Hinsicht kann das bedeuten, dass die Ablaufreihenfolge verschiedener Tätigkeiten innerhalb eines Prozesses verändert wird. Dies ist jedoch nur unter Berücksichtigung gegebener Rahmenbedingungen möglich. Beispielsweise sind innerhalb der Produktentwicklung offensichtlich bestimmte Freigabeschritte erforderlich, die nicht zusammengezogen werden können, auch wenn

Produktentstehung und strategische Planung

45

dies hinsichtlich der organisatorischen Zuständigkeit wünschenswert wäre. Ein anderer Einflussparameter ist die Aufbauorganisation. Sind beispielsweise bei der Entwicklung mechatronischer Komponenten sehr häufige und intensive Abstimmungen zwischen Mechanik-, Elektronik- und Software-Entwicklung erforderlich, so ist zumindest an die organisatorische Zusammenführung dieser Entwicklungsbereiche in einer Projektorganisation zu denken, oder aber an eine Integration der Aufbauorganisation. Hinsichtlich der unterstützenden IT-Systeme definiert wiederum der vernetzte Prozess die Anforderungen an sehr unterschiedliche Funktionalitäten, die integriert werden müssen. Wie wir im Folgenden erkennen werden, ist beispielsweise für Abstimmungen mit Kunden, d. h. originäre Vertriebsfunktionen, häufig der Zugriff auf Daten der Produktentwicklung erforderlich. Diese Anforderungen gehen häufig weit über unmittelbare Produktdaten hinaus und umfassen umfangreiche Pakete wie Projektdaten, Produktstrukturen etc. Einerseits ist es offensichtlich, dass unterschiedliche Werkzeuge zum Einsatz kommen müssen, da geometrieerzeugende Systeme wie CAD Vertriebsprozesse nicht unterstützen bzw. Vertriebssysteme nicht in der Lage sind, 3D-Modelle zu generieren und zu berechnen. Andererseits stellt der Prozess hohe Anforderungen an die Integration dieser Systeme. Deshalb ist es die Aufgabe von Product Lifecycle Management, diese integrativen Anforderungen auch in integrierten IT-Systemen abzubilden. In den folgenden Abschnitten werden einige Aspekte der Prozessintegration zwischen der Produktentwicklung und anderen Kernprozessen der Unternehmen betrachtet und daraus jeweils auch Anforderungen an die organisatorische Berücksichtigung und Gestaltung der IT-Systeme abgeleitet.

4.1

Produktentstehung und strategische Planung

Ausgangs- und gleichzeitig Zielpunkt der Produktentstehung ist die strategische Unternehmensplanung im Blick auf das Produktportfolio eines Unternehmens. Offensichtlich ist, dass die Ergebnisse der strategischen Planung Auswirkung auf die Prozesse der Produktentstehung haben. Insbesondere im Bereich des Supply Chain Management ist dies evident, da die Absatzplanung Grundlage für die Supply-Chain-Planung ist. Ebenso eindeutig ist der Zusammenhang zwischen der strategischen Planung und dem Innovationsmanagement und Produkt-PortfolioManagement, da das gegenwärtige und in Entwicklung befindliche ProduktPortfolio die Grundlage der Planung bildet. Umgekehrt wiederum leitet sich aus der Unternehmensplanung, insbesondere in der Konsumgüterindustrie, das ZielProdukt-Portfolio ab und damit die Vorgaben an die Produktentwicklung. Weniger offensichtlich, aber nicht minder wichtig ist der Zusammenhang zwischen der strategischen Unternehmensplanung und der Produktentwicklung im engeren Sinne: Für eine stets aktuelle Planungsgrundlage der strategischen Planung ist es unbedingt erforderlich, jederzeit Überblick über den Entwicklungsstand der Produkt-Pipeline zu haben. Bei Abweichungen zur Planung muss

46

PLM und die Kerngeschäftsprozesse des Unternehmens

entsprechend reagiert werden durch Maßnahmen zur Planerreichung oder Änderungen der Planung mit Auswirkungen z. B. auf Marketingmaßnahmen etc. Deshalb gewinnen die Prozess-Integration zwischen strategischer Planung und Produktentwicklung ebenso wie entsprechende, integrierte Tools für MultiProjektmanagement zunehmend an Bedeutung. Den Zusammenhang zwischen Produktportfolio, Unternehmensprozessen und unterstützenden IT-Systemen illustriert die Gruppe „digitales Produkt“ am Zentrum für Produktentwicklung der ETH Zürich am Beispiel des digitalen Produktes in Abb. 21. „Nur das Gleichgewicht von Produkten – Unternehmensprozessen – IT-Tools, sowie die durchgängige Nutzung und Modifizierung der Daten in den Prozessen ermöglichen eine effektive und nachhaltige Umsetzung des Konzeptes sowie Effizienz- und Qualitätssteigerung im Digitalen Produkt“ ([21], [8]). Zu weiteren Details zu digitalen Produkten und digitaler Fabrik siehe Abschnitt 7.3 und 7.5. Wie ist das Produkt charakterisiert - Standardprodukt ohne Varianten - Standardprodukt mit herstellerspez.Varianten - Standardprodukt mit kundenspez. Varianten - Einzelprodukt

Welche Rolle spielen - Kunde - Verkauf - Engineering - Produktion / Logistik -…

P

U

ProduktPlattform

UnternehmensProzesse

T Strategische Tools Geeignete IT-Systemarchitektur bestehend aus - Konfigurationssysteme - CAx-Systeme - Produktionsmanagement Systeme (PDM-Systeme) - Enterprise Resource Planning Systeme (ERP-Systeme)

Abb. 21. Das digitale Produkt

Produktentstehung und Vertriebsprozess

4.2

47

Produktentstehung und Vertriebsprozess

Obwohl bereits seit einigen Jahren ein Wechsel von der Produkt- zur Kundenorientierung nicht nur im Dienstleistungsbereich, sondern auch in produzierenden Unternehmen sowohl eingefordert als auch postuliert wurde, sieht die Realität immer noch anders aus. Untersuchungen zeigen, dass insbesondere viele technologisch ausgerichtete Unternehmen immer noch technik- oder produktorientiert arbeiten und denken. Viele Entwickler und Ingenieure halten Marketing lediglich für ein Mittel zur Vermarktung ihrer technisch geprägten Produkte. Sie müssen lernen, marktorientiert zu denken und zu handeln und Marketing auch als eine Methode der kundenorientierten Produktentwicklung zu verstehen [13]. In einer von der Universität St. Gallen bei Großunternehmen durchgeführten Befragung beschrieben 60% der Unternehmen ihre Marketingaktionen als produkt- und nicht kundenorientiert [53]. Unternehmen der Konsumgüterindustrie betreiben, insbesondere bei technologisch weniger anspruchsvollen Massengütern, intensive Markt- (und Wettbewerbs-)analysen, um neue Produkte optimal auf die Kundenwünsche auszurichten. Ergebnisse der Marktforschung haben unmittelbare Rückwirkung auf das Produktportfolio und die Entwicklungs-Pipeline. In stark Marketing-orientierten Unternehmen ist eine enge Verflechtung des Marketing mit Rückkopplung in die Produktentwicklung zumindest in den Marketing-Bereichen Preispolitik, Produktgestaltung und Werbung [16] sowie beispielsweise im Bereich des umweltorientierten Marketing- zu sehen [41]. Am anderen Ende der Skala, in der Kundeneinzelfertigung oder im Anlagenbau, ist die Berücksichtigung der Kundenwünsche offensichtlich unabdingbar. Dazwischen gibt es jedoch einen breiten Raum von seriengefertigten Produkten, bei denen der Einfluss von Kundenwünschen und -anforderungen sehr unterschiedlich ausgeprägt ist. Dies betrifft sowohl den Anteil z. B. von kundenspezifischen Engineering-Leistungen an der gesamten Wertschöpfung als auch Form und Intensität der Einbeziehung des Kunden in die Produktentwicklung bis hin zur Anpassung von Produkten an veränderte Kundenwünsche oder Marktgegebenheiten im Laufe des Produktlebenszyklus. Im Rahmen dieses Abschnittes wird deshalb der Begriff der Vertriebsprozesse weit gefasst im Sinne sämtlicher Kundeninteraktionen des Unternehmens mit Rückwirkung auf die Gestaltung der Produkte. Selbst in Unternehmen, in deren strategischer Ausrichtung sich die Kundenorientierung durchgesetzt hat, herrscht häufig in internen Prozessen nach wie vor eine produkt- oder abteilungszentrierte Sichtweise vor. Welche Implikationen hat nun aber eine kundenorientierte Sicht auf die Produkte auf die internen Prozesse des PLM? Hier sind insbesondere zu nennen: x Hoher Informationsbedarf zu Kundenwünschen und -erwartungen in frühen Phasen der Produktentwicklung x Frühzeitige Kundeninteraktion in der Produktentwicklung (Teilaspekt von Collaboration-Szenarien)

48

PLM und die Kerngeschäftsprozesse des Unternehmens

x Hohe Flexibilitätsanforderungen im gesamten Produktentstehungsprozess mit entsprechenden Auswirkungen auf die begleitenden Prozesse des Simultaneous Engineering (Software-Entwicklung, Betriebsmittelprozesse, digitale Fabrik, …) x Effiziente Methoden und Werkzeuge, um Entwicklungskapazitäten frühzeitig auf die „richtigen“, d. h. die Kundenwünsche befriedigenden, Produkte zu fokussieren (Innovation, Time to Market) x Frühzeitige, vollständige und aktuelle Verfügbarkeit von Produktdaten (Produktdatenmanagement) 4.2.1 Kundeninteraktion in der Produktentwicklung Der Fokus bei der Betrachtung der Verknüpfung von Produktentstehung und Vertriebsprozessen soll zunächst auf der Kundeninteraktion im Rahmen der Produktentwicklung liegen. Grad und Zeitpunkt der Kundeninteraktion sind stark branchenabhängig. Einige Aspekte dieser Kundeninteraktion sollen in den folgenden Abschnitten näher betrachtet werden. Während beispielsweise in der Konsumgüterindustrie Ergebnisse der Marktforschung sehr hohen Einfluss auf künftige Innovationsprojekte und die Gestaltung künftiger Produkte haben und deshalb bereits in der Ideenphase maßgeblich einfließen, erfolgt die Rückkopplung in anderen Branchen in der Regel unmittelbar innerhalb des Engineeringprozesses in Form der Anforderungsdefinition. 4.2.2 Anforderungsdefinition – Requirements Management Insbesondere im Bereich der Kundeneinzelfertigung und der kundenspezifischen Serienfertigung erfolgt die Anforderungsdefinition primär durch und in der Interaktion mit dem Kunden. Gerade weil die Definition der Anforderungen in einer bereichsorientierten Organisation jedoch häufig an der Schnittstelle zwischen (technischem) Vertrieb und Engineering liegt, steckt darin ein erhebliches Risikopotenzial. Zu denken ist dabei an x Inhaltlich vollständige und konsistente Definition der Anforderungen x Vollständigkeit der dokumentierten Anforderungen x Technische Realisierbarkeit x Sicherstellen des selben Verständnisses bei allen Beteiligten Dennoch wird die Dokumentation der Anforderungen in geeigneter Form und Requirements Engineering bzw. Requirements Management4 als Teil des Produkt4

Requirements Engineering bzw. Requirements Management wird hier verstanden als vollständige Aufnahme, Konsistenzsicherung und Dokumentation der Anforderungen verbunden mit Änderungsprozessen für Änderungen der Anforderungen an das Produkt.

Produktentstehung und Vertriebsprozess

49

entwicklungsprozesses häufig nicht mit derselben Sorgfalt betrachtet wie beispielsweise rechtsverbindliche Produktdokumentationen. Nicht zuletzt deshalb wird im Rahmen dieses Buches nicht nur der klassische Produktentwicklungsprozess betrachtet, sondern die gesamte Produktentstehung von der Produktidee bzw. Konzepten bis zur Markteinführung. Insbesondere im Anlagenbau ist das Requirements Engineering bereits Bestandteil des Engineering im Sinne der Produktentwicklung. Jede Änderung der Anforderungsdefinition kann bereits ab der frühen Phase der Konzeptentwicklung erhebliche Auswirkungen auf das Konzept, die Realisierbarkeit, die erforderlichen Fertigungsprozesse und nicht zuletzt auf die Kosten des Produktes haben [5]. Deshalb sind bereits in der Phase der Anforderungsdefinition gegebenenfalls Change-Request-Verfahren erforderlich, um die Konzepte abzusichern und Auswirkungen von Änderungen der Anforderungen zu bewerten und in die Konzepte einfließen zu lassen. 4.2.3 Konzeptentwicklung In der frühen Phase des Produktdesigns, der Konzeptentwicklung, werden bereits wesentliche Design-Entscheidungen getroffen, die Auswirkungen sowohl auf die Produkteigenschaften, als auch auf die Prozesse der Betriebsmittel und Produktionsvorbereitung haben. Diesem Umstand wird häufig, aber beileibe nicht in allen betroffenen Unternehmen, dadurch Rechnung getragen, dass abteilungs- bzw. bereichsübergreifende Entwicklungsteams gebildet werden. Zielsetzung dieser integrierten Entwicklungsteams ist es, neben der Vereinfachung der Kommunikation zwischen allen Beteiligten, sicherzustellen, dass alle erforderlichen Schritte termingerecht, im Budgetrahmen und in hinreichender Qualität fertig gestellt werden. Außerdem sollen erforderliche Änderungen möglichst frühzeitig erkannt und umgesetzt werden und späte und damit aufwändige Änderungen vermieden werden. Dieser Aspekt gewinnt im Rahmen des Simultaneous Engineering an Bedeutung, da bereits in frühen Phasen der Produktentwicklung Änderungen Auswirkungen auf andere Bereiche wie z. B. die Betriebsmittel- oder Werkzeugkonstruktion haben (siehe folgender Abschnitt). Zur Sicherung dieser Ziele werden in der Konzeptphase beispielsweise folgende Maßnahmen ergriffen: x Festlegung und Festschreibung grundlegender Designentscheidungen x Zeitplanung und Modularisierung x Definition von Entscheidungspunkten (Meilensteinen) und der erforderlichen Freigabeschritte und zu involvierenden bzw. informierenden Abteilungen x Bereichsübergreifende Ressourceneinssatzplanung Um sicherzustellen, dass die Kundenanforderungen bzw. die geplanten oder zugesicherten Produkteigenschaften dauerhaft erreicht werden, werden diese Maßnahmen unter anderem durch Methoden des präventiven Qualitätsmanagements unterstützt, z. B.:

50

PLM und die Kerngeschäftsprozesse des Unternehmens

x APQP: Advanced Product Quality Planning stellt sicher, dass Produkte den Anforderungen der Kunden entsprechen, indem systematisch Maßnahmen definiert, durchgeführt und überwacht werden (hauptsächlich von Automobilherstellern eingesetzt und bei ihren Zulieferern gefordert) x PPAP: Production Part Approval, Verfahren zur Abnahme von Produktionsteilen in der Automobilindustrie; stellt grundlegende Anforderungen für das Vorgehen zur Erstmusterfreigabe von Produktions- und Ersatzteilen. x FMEA: Fehlermöglichkeits- und Einflussanalyse, Ziel: potenzielle kritische Fehler von neuen Produkten oder Produktionsprozessen bereits während der Entwicklung aufzudecken und durch geeignete Maßnahmen zu vermeiden. Die genannten Maßnahmen und Methoden dienen primär zur unternehmensinternen Absicherung der Prozesse und des Produkterfolgs. Allerdings zeigt bereits die Tatsache, dass z. B. Automobilhersteller ihren Zulieferern bestimmte Prozesse diktieren und den Nachweis über deren Einhaltung verlangen, die Kundeninteraktion und den Einfluss der Kunden auf unternehmensinterne Prozesse. In der Regel erfolgt die Kundeninteraktion auch unmittelbar, indem bestimmte Designentscheidungen bzw. Freigaben in Abstimmung mit dem Kunden erfolgen oder bereits während der Konzepterstellung Abnahmen des Konzeptes durch den Kunden erfolgen. In der Konsumgüterindustrie erfolgt die Interaktion indirekt über Marktforschungs- und Akzeptanzstudien zum Produktentwurf. Die genannten Aspekte der Wechselwirkung zwischen den Prozessen der Produktentwicklung und Vertriebsprozessen im weitesten Sinne definieren neben der bereits erwähnten Erfordernis abteilungsübergreifender Entwicklungsteams auch Anforderungen an die unterstützenden IT-Systeme. Mit Blick auf die Konzeptphase sind hier insbesondere zu nennen: x Durchgängige Unterstützung ohne (spürbare) Systembrüche: Sowohl die Anforderungen als auch die Ergebnisse der Konzeptphase müssen in allen Phasen der Produktentwicklung (und darüber hinaus für den gesamten Produktlebenszyklus) unmittelbar zur Verfügung stehen. x Änderungsmanagement von Anforderungen und Konzepten mit Bezug zwischen diesen: Die Auswirkungen von veränderten Anforderungen müssen in den Konzeptänderungen erkennbar sein und im Idealfall muss eine direkte Navigation möglich sein. x Wissensmanagement / Content Management: Erfahrungen, die im Rahmen eines Entwicklungsprojektes gemacht werden, müssen für andere Projekte zur Verfügung stehen. Designentscheidungen und deren Begründung bzw. die Erkenntnis, dass bestimmte Konzepte nicht zum Erfolg führen, stellen ein wesentliches Unternehmens-Know-how dar, das insbesondere für spätere Entwicklungsprojekte enorme Kosten einsparen kann. Dies setzt jedoch voraus, dass diese Ergebnisse leicht auffindbar und verständlich dokumentiert sind.

Produktentstehung und Vertriebsprozess

51

x Wiederverwendung von Konzepten und Ergebnissen der Konzeptphase: Durch geeignete Strukturierung der Daten und Tools zur Suche und Navigation wie Klassifikation etc. wird sichergestellt, dass Konzepte und sonstige Ergebnisse über das aktuelle Entwicklungsprojekt hinaus zur Verfügung stehen. 4.2.4 Kundenspezifische Produktentwicklung In den vorangegangenen Abschnitten wurde jeweils eine große Bandbreite der Wechselwirkung mit Kunden in der Anforderungsdefinition und Konzeptentwicklung betrachtet. In diesem Abschnitt soll nunmehr die Produktentwicklung im engeren Sinne als vollständige, kundenspezifische Detaillierung des Konzeptes bis zur Produktionsreife betrachtet werden. Bei der Entwicklung von Massengütern erfolgt hier kaum Kundeninteraktion, da z. B. Marktanalysen und -forschung spätestens auf Basis des Konzeptes vorliegen sollten und die Grundlage für die Entscheidung für die Konzeptdetaillierung darstellen. Hingegen ist der kundenspezifische Produktentwicklungsprozess, z. B. bei Automobilzulieferern, durch einen stark strukturierten Prozess gekennzeichnet. Innerhalb dieses Prozesses sind Meilensteine oder Gateways definiert, die in der Regel auch Freigaben durch den Kunden beinhalten. Dies bedingt zum einen wiederum die Prozessintegration zwischen Produktentwicklungsprozess und Vertriebsprozess und stellt zum anderen auch Anforderungen an die unterstützenden IT-Systeme. Je nach Form der Kundeninteraktion muss die vollständige Dokumentation zu den Meilensteinen für Vertriebsmitarbeiter oder unmittelbar für den Kunden zur Verfügung stehen, um auf dieser Basis die Freigabe zu erteilen. Insbesondere im letzteren Fall werden hohe Anforderungen an Collaboration-Tools gestellt, da zum einen teilweise hohe Datenvolumina in verständlich strukturierter Form zur Verfügung und auch zum Download bereitgestellt werden müssen. Zum anderen werden aber auch hohe Anforderungen an die Prozesssicherheit gestellt mit Blick auf stringente Prozessführung, ausgereifte Berechtigungskonzepte, Transaktionssicherheit und Sicherheit des Datenaustausches. 4.2.5 Betrieb von Kunden-Anlagen Eine Besonderheit der Kundeninteraktion stellt der Betrieb bzw. die Betriebssicherheit im Maschinen- und Anlagenbau dar. Dies ist streng genommen kein Prozess der Produktentwicklung. Allerdings ist er in der Regel untrennbar verbunden mit einem relativ hohen Anteil kundenspezifischer Engineering-Leistungen. Hier ist der interne Lebenszyklus des Produktes beim Hersteller nicht mit der Auslieferung an den Kunden abgeschlossen. Der Trend geht hingegen zum Betrieb der Anlagen durch den Hersteller im Sinne von „Betreiben statt verkaufen“ [47]. Im Kontext dieses Kapitels bedeutet dies, dass die Kundeninteraktion für das produzierende Unternehmen nicht auf die Produktentwicklung und ggfs. Änderungen

52

PLM und die Kerngeschäftsprozesse des Unternehmens

am Produkt oder der Dokumentation beschränkt ist. Stattdessen werden hohe Anforderungen an die Dokumentation der Konfiguration gestellt, so dass stets der aktuelle, beim Kunden betriebene Zustand der Anlage verfügbar ist. Dies wird im Konfigurationsmanagement durch bestimmte eingefrorene und zeitpunktbezogene Zustände wie „as built“, „as shipped“ oder „as maintained“ dokumentiert. Im Blick auf einen ganzheitlichen PLM-Ansatz bedeutet dies jedoch auch, dass zusätzlich zur Konfiguration auch die entsprechenden Kundenanforderungen und -wünsche sowie Betriebsdaten vorgehalten werden müssen. Durch Veränderung gesetzlicher Vorgaben gewinnt zusätzlich das Responsibility-Management für den Betrieb von Anlagen an Bedeutung und stellt erweiterte Anforderungen an den Betreiber und den Hersteller der Anlagen. Schließlich sind die Menge der entstehenden Daten und die Aufbewahrungsfristen für die Dokumentation von Anlagen zu berücksichtigen, die Archivierungskonzepte erfordern, um jederzeit die einfache Navigation zu benötigten Daten bzw. Dokumenten ermöglicht.

4.3

Integration verschiedener Entwicklungsbereiche und -standorte

Die überwiegende Zahl neuer Produkte entsteht nicht in einem isolierten Entwicklungsbereich, sondern in der intensiven Zusammenarbeit verschiedener Entwicklungsbereiche. Einige Beispiele sollen dies verdeutlichen: x In der Konsumgüterindustrie ist neben dem eigentlichen Produkt die Verpackung mit entscheidend für den Erfolg oder Misserfolg des Produktes. Besonders offensichtlich ist dies beispielsweise bei Parfums mit in der Regel sehr aufwändig gestalteten Flacons. Aber auch bei Alltagsprodukten wie Lebensmitteln müssen neben der Attraktivität der Verpackung zusätzliche Kriterien wie Beständigkeit, Praktikabilität in der Handhabung etc. berücksichtigt werden. Schließlich stellt gerade bei Produkten im Niedrigpreissegment die Verpackung einen wesentlichen Kostenfaktor dar. Aus all diesen Gründen ist die Verpackungsentwicklung ein eigener Bereich innerhalb der Produktentwicklung, die in enger Verzahnung mit der Entwicklung des eigentlichen Produktes geschieht, da die Verpackung nicht zuletzt die Produkteigenschaften verstärken und unterstreichen soll. x Bei der Entwicklung mechatronischer Komponenten erzeugt die Mechanik die sichtbare Wirkung z. B. in Form einer Bewegung eines Aktors. Die Regelung und Steuerung jedoch erfolgt durch die zugehörige Elektronik und häufig durch eine entsprechende Software. Die Entwicklung der Mechanik erfolgt zum überwiegenden Teil in eigenen Entwicklungsbereichen, wogegen die Elektronik- und Software-Entwicklung sowohl innerhalb desselben Bereiches erfolgen kann, als auch in organisatorisch getrennten Einheiten. Die Entscheidung über eine organisatorische Trennung von Elektronik- und Software-Entwicklung hängt neben der Komplexität der Komponenten un-

Integration verschiedener Entwicklungsbereiche und -standorte

53

ter anderem vom Modularisierungsgrad ab. Wird die Software nicht speziell für eine Komponente entwickelt, sondern für eine Bauteilfamilie und sollen Software-Releases unabhängig von Hardware-Änderungen gehalten werden, wird die Entwicklung in der Regel auch in unterschiedlichen Bereichen angesiedelt sein. x Der Anlagenbau umfasst häufig sehr unterschiedliche Disziplinen und Gewerke. Beispielsweise werden im Reinstraumbau hoch spezialisierte mechanische Entwicklungsaufgaben kombiniert mit sehr hohen Anforderungen an Lüftungs-, Klima- und Filtertechniken und hochempfindlichen Sensoren und entsprechender Steuerungselektronik. Trotz der erforderlichen starken Spezialisierung innerhalb der einzelnen Disziplinen ist die Bildung von bereichsübergreifenden Projektteams in diesem Bereich weiter fortgeschritten, da die Projekte in der Regel von längerer Dauer sind und häufig die beteiligten Mitarbeiter über längere Zeiträume exklusiv an einem Projekt arbeiten. Diese, beliebig fortzusetzende, Liste zeigt, dass häufige und intensive Abstimmungen zwischen den verschiedenen beteiligten Entwicklungsbereichen erforderlich sind. Im Sinne der Prozessintegration ist deshalb zum einen zu prüfen, ob der Prozess durch Bildung von bereichsübergreifenden Projektteams unterstützt werden kann. Zum anderen sind geeignete Organisationsformen für die effiziente Projektzusammenarbeit mit eindeutigen Zuständigkeiten, klar definierten Abstimmpunkten und Entscheidungswegen festzulegen. Zunehmend erfolgt die Produktentwicklung nicht nur in abteilungsübergreifender, sondern auch in standortübergreifender Zusammenarbeit. Dies belegt das Ergebnis einer Studie in der Fertigungsindustrie [22], nach der bereits 30% der Unternehmen standortübergreifende Zusammenarbeit realisiert haben, aber weitere 51% dies planen. Die Ausgestaltung dieser Zusammenarbeit wird häufig durch die Bildung virtueller Teams realisiert. Diese Zusammenarbeit muss durch geeignete Werkzeuge, nicht nur für den Austausch der Daten, sondern für kollaborative Zusammenarbeit u.a. in folgenden Bereichen unterstützt werden: x Kommunikation und Kollaboration (siehe Kapitel 5.1 und 7.4) x Projektmanagement x Standortübergreifendes Produktdatenmanagement (inklusive geeigneter Architekturen für performanten Austausch und Zugriff auf teils sehr große Datenmengen) Neben der unternehmensinternen und -übergreifenden Prozessintegration der Produktentwicklung liegt ein wesentlicher Erfolgsfaktor im richtigen Einsatz der Mitarbeiter. Um optimale Ergebnisse zu erzielen, muss sichergestellt werden, dass Wissensträger zielgerichtet in Entwicklungsphasen integriert werden können und ihr Wissen zur Anwendung gebracht werden kann [25]. Lässt sich dies innerhalb einer Abteilung einfach steuern, so sind bei der Bildung virtueller, verteilter Teams, unterstützende Maßnahmen und Werkzeuge erforderlich. Bei-

54

PLM und die Kerngeschäftsprozesse des Unternehmens

spielsweise sollte die Besetzung von Projektteams durch datenbankgestütztes Suchen nach Mitarbeitern mit den benötigten (Spezial-)Kenntnissen erfolgen. Um eine gezielte Einsatz- uns Auslastungsplanung durchführen zu können, muss ein solche Know-how-Datenbank mit Projektmanagement-Werkzeugen integriert werden, um Kapazitätsbedarfe vorplanen zu können und Engpässe rechtzeitig zu erkennen.

4.4

Integrierte Produkt- und Prozessentwicklung

Neben der Integration unterschiedlicher Entwicklungsbereiche (horizontale Integration) spielt die Integration von Prozessen, die auf den Ergebnissen der Produktentwicklung aufsetzen, eine zunehmende Rolle. Zum einen ist ein wesentlicher Faktor für eine kurze Time to Market die Sicherstellung der Produktionsfähigkeit zu einem möglichst frühen Zeitpunkt. Deshalb dürfen die Prozesse der Produktionsvorbereitung nicht erst nach Abschluss der Produktentwicklung begonnen werden, sondern müssen diese schon so früh als möglich und sinnvoll begleiten. Genau die Festlegung dieser Parameter „so früh als möglich“ und „sinnvoll“ stellt eine wichtige und zugleich schwierige Herausforderung in der Festlegung optimierter Prozesse der Produktentstehung dar. Bereits in frühen Phasen der Produktentwicklung wird ein hoher Anteil der Produktionskosten festgelegt, während die eigentliche Kostenverursachung zum Großteil während der Produktionsvorbereitung und der eigentlichen Produktion erfolgt. Abb. 22 zeigt exemplarisch, dass typischerweise im Entwicklungsprozess die Produkteigenschaften sowie rund 70% der Produktkosten definiert werden und dieser hohen Kostenfestlegung lediglich 10% der verursachten Kosten gegenüberstehen [21]. Dies macht deutlich, dass durch die Berücksichtigung der Produktionsprozesse zu einem frühen Zeitpunkt die Kostenfestlegung für die spätere Produktion mit relativ geringem Kostenaufwand beeinflusst werden kann. Über den Hebeleffekt amortisieren sich die einmalig anfallenden Kosten innerhalb der Produktentwicklung über die Reduktion der laufenden Produktionskosten in kurzen Zeiträumen. Die Berücksichtigung der Produktions- bzw. Fertigungs- oder Montageprozesse innerhalb der Produktentstehung erfordert wiederum eine starke Verzahnung der eigentlichen Produktentwicklung mit dem Betriebsmittelbau, der Fertigungsplanung, Arbeitsvorbereitung etc. Die Automobilindustrie ist Vorreiter dieser integrierten Produkt- und Prozessentwicklung. Für den Betriebsmittel- und Werkzeugbau, ebenso wie für die Planung der Produktionslinie oder des Fabrik-Layouts und der Materiallogistik ist nun eigentlich die exakte Kenntnis der zu produzierenden Teile oder Produkte erforderlich. Dies steht jedoch im Widerspruch zu der Anforderung, möglichst frühzeitig mit dem Bau bzw. der Beschaffung von Betriebsmitteln und der Produktionsplanung zu beginnen. Dieser Widerspruch lässt sich nur durch eine Kombination absichernder Maßnahmen auflösen:

Integrierte Produkt- und Prozessentwicklung

55

Abb. 22. Kostenfestlegung und Kostenverursachung innerhalb der Teilprozesse der Produktentstehung [21]

x möglichst genaue Definition der Produkteigenschaften zu einem möglichst frühen Zeitpunkt in Abstimmung mit den betroffenen Fertigungsbereichen x fortwährende Detaillierung der Produkteigenschaften im Laufe des Entwicklungsprozesses x definierte Abstimmtermine zwischen Produktentwicklung und nachfolgenden Prozessen x Freigabeprozesse mit Dokumentation und Information aller beteiligter Bereiche x Sicherstellen der Verfügbarkeit aktueller und vollständiger Produktdaten x Verfügbarkeit der Produktdaten in geeigneter Form zur Weiterverarbeitung in den nachgelagerten Prozessen (digitale Fabrik) Es ist offensichtlich, dass diese Maßnahmen einerseits Prozessaspekte darstellen, die nur durch die Definition und Implementierung entsprechender durchgängiger Prozesse sinnvoll unterstützt werden können. Andererseits ergeben sich daraus auch hohe Anforderungen an unterstützende IT-Systeme, die zum einen die definierten Prozesse absichern und vereinfachen sollen, zum andern die Durchgängigkeit der Produktdaten durch verschiedene Prozesse des Unternehmens mit unterschiedlichen Anforderungen an Art und Umfang der Daten gewährleisten sollen. Insbesondere die derzeitigen Trends zu digitaler Fertigungssimulation bzw. digitaler Fabrik verlangen entsprechend aufbereitete Daten aus der Produktentwicklung. Abb. 23 illustriert diese Prozess- und Datenintegration entlang der Prozesse der Produktentstehung als Integration von PLM und Manufacturing-Execution-Systemen.

56

PLM und die Kerngeschäftsprozesse des Unternehmens

Produktionsauftragspaket

Prozessmodell

ƒ ƒ ƒ ƒ ƒ ƒ

Arbeitspläne Arbeitsanweisungen Dokumente Prozess-Konfiguration Verbrauchsstoffe Produktionsanforderungen ƒ Werkzeuge ƒ Mitarbeiterqualifikation

• E-BOM • M-BOM • Merkmale • Produktkonfiguration

Änderungsanfragen

Produktmodell

PLM

Arbeitsaufträge

Manufacturing Execution System

Werkstattsteuerung • Rückmeldung • Auftragsstatus • Verbrauch

„As Built“Dokumentation / Maschinenakte

ERP

Wartung und Service

Abb. 23. Prozess- und Datenintegration von der Produktentwicklung in die Fertigung bis hin zu Instandhaltung und Service [20]

Dies wird in den jeweiligen Abschnitten dieses Buches weiter vertieft. An dieser Stelle sei lediglich darauf hingewiesen, dass auf Grund der oben genannten Anforderungen Prozesse von der Produktentwicklung bis zur endgültigen Planung der Fertigung zu definieren sind. Allerdings laufen die Prozesse nicht linear ab, nicht nur wegen Änderungen im Produktentstehungsprozess, sondern auch wegen der oben skizzierten fortwährenden Abstimm- und Freigabepunkte, die jeweils eine veränderte Grundlage für die Prozesse der digitalen Fabrik darstellen.

4.5

Produktentwicklung und Beschaffung

In Unternehmen mit geringer eigener Fertigungstiefe oder bei Produkten mit hoher Komplexität besteht das Endprodukt häufig zu einem großen Anteil aus Zukaufteilen. Beispielsweise werden Fahrzeuge in der Automobilindustrie in immer stärkerer Zusammenarbeit mit Zulieferern entwickelt. Insbesondere wenn es sich dabei um Systemlieferanten handelt, die komplette Systeme wie Sitze, mehrere Komponenten des Antriebsstranges oder vollständige Beleuchtungsanlagen liefern, müssen diese Lieferanten bereits sehr frühzeitig in die Fahrzeugentwicklung involviert werden (vgl. Abb. 24). Um den geplanten Serienanlauftermin einhalten zu können, ist es unerlässlich, dass die parallel laufenden Entwicklungsaktivitäten der beteiligten Partner ständig synchronisiert und abgestimmt werden, um das Gesamtkonzept abzusichern. In diesem stark parallelisierten Entwicklungsumfeld sind Zulieferer Lieferanten und Entwicklungspartner zugleich. Dies stellt jedoch zusätzliche Anforderungen an

Produktentwicklung und Beschaffung

57

Virtuelle Produktentstehung Hersteller

Konzeptphase

Zulieferer A Zulieferer B Zulieferer C

Serienfertigung

Verzögerung des Entwicklungsfortschrittes

Zulieferer B Virtuelle Produktentstehung Zulieferer

Abb. 24. Frühe Integration von Zulieferern innerhalb der Produktentwicklung im Automobilbau

den Datenaustausch: Während der Zulieferer genau so wie unternehmensinterne Entwicklungsabteilungen bei der integrierten Entwicklung Zugriff auf die relevanten Daten und Informationen benötigt, muss in externen Entwicklungskooperationen sehr viel mehr Wert auf die Abgrenzung der extern zur Verfügung gestellten Daten gelegt werden. Dies gilt desto mehr, wenn der Entwicklungspartner zugleich Lieferant ist, da wichtige Parameter der Projektsteuerung zugleich kaufmännische Aussagen über Kosten und Kalkulationen ermöglichen. Deshalb sind hier ausgefeilte Berechtigungskonzepte erforderlich, um trotzdem einen hohen Automatisierungsgrad beim Datenaustausch erreichen zu können. Auch in anderen Industriezweigen ist es in wachsendem Maße erforderlich, frühzeitig über die Eigenfertigung oder Fremdbeschaffung von Teilen und Komponenten zu entscheiden, also die Make-or-buy-Entscheidung zu treffen. Diese Entscheidung kann Gegenstand strategischer Überlegungen sein, wie der Konzentration auf das Kerngeschäft, oder auf Grund fehlenden eigenen Know-hows bereits vorgegeben sein. Im Falle einer echten Entscheidungsalternative jedoch sind unternehmensinterne Parameter wie die Kapazitätsauslastung einzelner Fertigungsbereiche, Herstellkosten, Aufbau oder Sicherung von Prozess-Know-how etc. ebenso Basis für die Entscheidung, wie externe Beschaffungsmöglichkeiten, Preise etc. In jedem Falle kann eine Entscheidung jedoch nur auf der Grundlage einer

58

PLM und die Kerngeschäftsprozesse des Unternehmens

möglichst vollständigen und exakten Datenbasis gefällt werden. Diese ist sowohl Voraussetzung für die Beurteilung der internen Fertigungsmöglichkeiten als auch für fundiertes Angebot der Lieferanten. Aus Prozesssicht bedeutet dies, dass die frühzeitige Information und Einbeziehung des Einkaufs in die Prozesse der Produktentwicklung sichergestellt werden muss. Für die Alternativenentscheidung zwischen Eigenfertigung und Fremdbezug müssen jedoch zudem auch die Fertigungsbereiche mit involviert werden, um Herstellkosten der Eigenfertigung, Kapazitätssituation usw. in die Entscheidung einzubringen. Trotzdem wird nicht in jedem Fall eine vollständige Datenbasis zum Zeitpunkt der Make-or-buy-Entscheidung verfügbar sein. Dennoch muss die Entscheidung gefällt werden, um die Beschaffung von Komponenten mit langem Vorlauf rechtzeitig anstoßen zu können. In diesen Fällen muss sichergestellt werden, dass ein permanenter Austausch der Entwicklungsdaten zwischen Hersteller und Zulieferer erfolgt und zu definierten Zeitpunkten der Stand der Entwicklungskooperation Reviews unterzogen wird und auf dieser Basis jeweils über das weitere Vorgehen entschieden wird. In jedem Falle ist also ein frühzeitiger und wiederholter Datenaustausch zwischen Hersteller und Zulieferer erforderlich, der nicht nur prozessseitig klar definiert ist, sondern auch durch entsprechende PLM-Systeme unterstützt wird. Details hierzu finden sich in den Abschnitten zu Collaboration und Simultaneous Engineering in diesem Buch (Abschnitte 2.2.3, 7.2 und 7.4). Hier sei nur schematisch auf die Anforderungen und mögliche Störfaktoren an den Schnittstellen zwischen den beteiligten Systemen hingewiesen (vgl. Abb. 25).

Abb. 25. Schematische Darstellung des Datenaustausches zwischen Hersteller und Lieferant

Produktentwicklung und Beschaffung

59

Eine frühzeitige Make-or-buy-Entscheidung für Komponenten hat jedoch noch wesentlich weiter greifende Auswirkungen innerhalb der Produktentwicklung: Die Struktur der Produkte wird von den verschiedenen beteiligten Unternehmensbereichen unterschiedlich betrachtet (vgl. Abb. 26): x Für die Konstruktion stehen der logische Aufbau aus funktionaler Sicht sowie die Wiederverwendbarkeit von Komponenten im Mittelpunkt der Produktstrukturierung. x Zur Beurteilung der Baubarkeit und der Herstellkosten benötigt die Arbeitsvorbereitung eine Strukturierung des Produktes aus Fertigungs- bzw. Montagesicht. Diese wird auch heute noch häufig parallel zur Konstruktionsstruktur als eigenständige Datenstruktur erstellt und gepflegt. x Zur Kostenkalkulation wird eine summarische, unstrukturierte Auflistung der Teile mit hinterlegten Mengen und Preisen benötigt. x Aus Beschaffungssicht ist eine genaue Differenzierung nach Eigenfertigungs- und Zukaufteilen erforderlich. Insbesondere wenn verschiedene Alternativen existieren. Beispielsweise kann ein Elektromotor mit integriertem Getriebe von einem einzigen Lieferanten bezogen werden, Motor und Getriebe von zwei verschiedenen Lieferanten oder aber das Getriebe eigengefertigt werden und nur der Motor zugekauft werden.

Abb. 26. Strukturierung von Produkten aus der Sicht verschiedener Unternehmensbereiche

60

PLM und die Kerngeschäftsprozesse des Unternehmens

Zur Beurteilung der Sinnhaftigkeit einer Eigenfertigung und für die logistischen Prozesse der Beschaffung ist also nicht nur die Produktstruktur aus Sicht der Produktentwicklung erforderlich, sondern zusätzlich die o.g. Strukturinformationen. Durch die frühzeitige Einbindung von Lieferanten lassen sich jedoch auch bereits in frühen Entwicklungsstadien gegebenenfalls Kostentreiber erkennen und eliminieren und Optimierungen der Konstruktion im Sinne der Erreichung von Design-to-Cost-Zielen durchführen. Dies bedeutet unternehmensübergreifend die konsequente Suche nach der kostengünstigsten Lösung für Komponenten bei gleich bleibender Funktion bereits in der Produktentwicklung unter Berücksichtigung auch später anfallender Folgekosten wie Vertriebskosten, Servicekosten etc. Basis dafür ist das so genannte Target Costing, d. h. die Betrachtung von Alternativen innerhalb der Komponenten eines Produktes mit Festlegung der Zielkosten für die einzelnen Komponenten unter Berücksichtigung der verschiedenen Einflussgrößen. Insbesondere wenn die verschiedenen Komponenten von unterschiedlichen Lieferanten stammen, erfordern die Prozesse des Target Costing und Design to Cost intensive Abstimmungen aller Entwicklungspartner, um Schwankungen auf Komponentenebene in der Summe ausgleichen zu können. Ist eine frühzeitige Entscheidung über den Zukauf von Komponenten gefallen, ermöglicht dies bereits eine beschaffungsgerechte Strukturierung innerhalb der Konstruktion, falls diese nicht ohnehin vom Systemlieferanten durchgeführt wird. Allerdings bleibt auch in diesem Fall die Anforderung bestehen, die Strukturierung der Komponenten beispielsweise für das Ersatzteilgeschäft in unterschiedlicher Form vorliegen zu haben. In Summe bleibt festzuhalten, dass der Trend in der Produktentwicklung hin zu partnerschaftlicher, unternehmensübergreifender Zusammenarbeit ungebrochen ist und die Optimierung der Wertschöpfungskette in der Produktentstehung die Lieferantenbeziehungen mit einbeziehen muss. Dies muss sowohl in der Definition der Prozesse als auch in der Gestaltung der Zuliefervereinbarungen und in der Auswahl und Implementierung der unterstützenden IT-Systeme ihren Niederschlag finden und erfordert im einzelnen Prozesse und IT-Unterstützung für x den Datenaustausch zwischen Entwicklungspartnern x die Kommunikation der Entwicklungspartner x die Dokumentation der gesamten Datenbasis inklusive sämtlicher Änderungen und Entscheidungen im Entwicklungsprozess x die Verwaltung der gesamten kostenrelevanten Produktinformation

5

Unterstützende PLM-Prozesse / Querschnittsprozesse

Unterstützende Prozesse sind operative Prozesse, stellen aber für sich genommen noch keine eigene Wertschöpfung aus Sicht des Kunden dar. Die unterstützenden Prozesse dienen der Bereitstellung der Infrastruktur für die Geschäftsabwicklung. Sie beinhalten z. B.: x Qualitätsmanagement x Collaboration x Projektmanagement x Service- und Wartungsprozesse Produkt- und Prozessqualität sind heute wichtig für alle Unternehmen weltweit. Qualitätsmanagement (QM) innerhalb von PLM bietet ein in den Prozess integriertes und umfassendes Qualitätsmanagement für die Prozessindustrie und die Fertigungsindustrie. Im wettbewerbsintensiven, schnelllebigen Geschäftsumfeld und im Zuge der collaborativen Zusammenarbeit, in der interne und externe Prozesse Hand in Hand gehen müssen, um ein Produkt auf den Markt zu bringen, ist Qualität entscheidend für den Unternehmenserfolg (Quality Collaboration).

Abb. 27. Qualitätsmanagement innerhalb von PLM

62

Unterstützende PLM-Prozesse / Querschnittsprozesse

Die neue Form der collaborativen Zusammenarbeit hat Auswirkungen auf das Qualitätsmanagement. Eine Neuausrichtung, bei der Qualität zum unternehmensübergreifenden Bestandteil der Projektstrukturen wird, erfordert die Integration des Qualitätswesens bereits in der frühen Phase der Produktentwicklung, welche die Qualitätsansprüche durch geeignetes Quality Engineering sicherstellen kann. Durch die Integration des Qualitätswesens in die Produktionsplanung und während der gesamten Produktion können höchste Qualitätsansprüche durch Qualitätskontrollen gewährleistet werden. Entlang der gesamten Wertschöpfungskette müssen die Mitarbeiter und externen Partner in die Qualitätssicherung und -verbesserung einbezogen werden. Durch geeignetes Quality Improvement wird während des gesamten Produktlebenszyklus die Produktqualität kontrolliert, analysiert und mit entsprechenden Qualitätsmaßstäben verglichen und im Bedarfsfall angepasst. Dabei ist entscheidend zu erkennen, wo und wodurch ein Qualitätsmangel entstanden ist, um die Ursache durch Qualitätsverbesserungsmaßnahmen abzustellen sowie eventuelle Mängel durch Früherkennung bereits in der Produktentwicklung abzuwenden. Erst ein integriertes Qualitätsmanagement und das Schaffen von Qualitätsbewusstsein in allen Phasen und Bereichen ermöglichen den Unternehmen einen nachhaltigen Wettbewerbsvorteil.

5.1

Collaborative Engineering

Eine der größten Herausforderung der Fertigungsindustrie ist die unternehmensübergreifende Zusammenarbeit entlang der gesamten Wertschöpfungskette. Collaboration ist für die meisten Unternehmen unumgänglich geworden, um weiterhin im Wettbewerb erfolgreich zu sein. Was zunächst als Widerspruch erscheint, wird am Bespiel der Automobilindustrie sehr deutlich: Klassische Zulieferer der OEMs liefern heute komplette Systemkomponenten und keine Einzelteile wie in früheren Jahren. Um dies zu ermöglichen, ist die Zusammenarbeit der beteiligten Unternehmen schon beim Anforderungsmanagement erforderlich und geht weiter über Engineering Collaboration bis hin zur Zusammenarbeit bei Serviceleistungen und Wartung der gelieferten Systemkomponenten. Diese komplexen und jetzt firmenübergreifenden Prozesse sind ohne durchgehende IT-Unter-

Kunde

Projektmanager

Entwicklungspartner

Information zum Projektstatus

Produktspezifikation

Sammlung der Projektdokumentation Erster Designvorschlag

Monitoring des Projektfortschritts Abschluss der Entwicklung

Abb. 28. Collaborative Engineering und Projektmanagement

Abschließendes Review

Internes Review

Vergleich und Übernahme

Projektmanagement

63

stützung und eine digitale Abbildung der kooperativen Unternehmensprozesse kaum beherrschbar. Die Zusammenarbeit unterschiedlichster Unternehmen mit einer gemeinsamen Zielsetzung führt zu wertschöpfungsorientierten Netzwerken mit Zulieferern, Kunden und Partnern. Eine Neuausrichtung zu kooperationsförderlichen Aufbauund Ablauforganisationen wird bei allen am Prozess Beteiligten unumgänglich. Hieraus entstehen Herausforderungen wie: x Kooperative, virtuelle und integrierte Produktentstehungsprozesse x Frühe und enge Einbeziehung von Engineeringpartnern x Wachsende Anzahl von Experten und deren Wissen x Projektorientierte Technologieentwicklung x Gemeinsames Kosten- und Zeitmanagement x Hohe Transparenz der Entscheidungsprozesse x Synchronisation der Produktionsnetzwerke Die Anforderungen an kollaboratives Projektmanagement steigen, sie übersteigen oft die Funktionen bisher im Einsatz befindlicher Methoden und Werkzeuge.

5.2

Projektmanagement

In den vergangenen Jahren hat sich die Welt des Projektmanagements entscheidend geändert. Unternehmensfusionen, kürzere Produktlebenszyklen und die Verkürzung des „Time to Market“ haben zu einer Projektinflation geführt. Die Optimierung projekt- und unternehmensübergreifender Kooperationen gewinnt daher im modernen Projektmanagement immer mehr an Bedeutung. Schnell und profitabel, innovativ und effektiv: Das sind die Anforderungen, die das moderne Projektmanagement erfüllen muss. Im Fahrzeugbau werden z. B. auf einer Bodengruppe bis zu 10 und mehr verschiedene Modelle unterschiedlicher Marken realisiert. Unterschiedliche Projektpartner an weltweit verstreuten Standorten sind die Regel. Entwicklungspartner übernehmen einen großen Teil der Entwicklungsleistungen. Und dabei dürfen Verzögerungen oder Kostenprobleme nicht auftreten. Dies bedeutet für alle Unternehmen: Die Kooperation innerhalb des Projekts – über Standorte und Unternehmen hinweg – muss reibungslos und zielgerichtet verlaufen. Nach DIN 69 901 ist ein Projekt wie folgt definiert: „Ein Vorhaben, das im wesentlichen durch eine Einmaligkeit der Bedingungen in ihrer Gesamtheit gekennzeichnet ist.“ Hieraus kann man ableiten, dass nicht nur große, komplexe Vorhaben wie z. B. die Entwicklung von Flugzeugen als Projekt zu gestalten sind, sondern alle Tätigkeiten, die sich von der täglichen Routinearbeit unterscheiden und besonderen Gesetzmäßigkeiten unterliegen.

64

Unterstützende PLM-Prozesse / Querschnittsprozesse

Ein Projekt: x hat eine klare Zielvorgabe x ist zeitlich begrenzt durch einen definierten Beginn und ein definiertes Ende x ist charakterisiert durch seine Einmaligkeit und Neuartigkeit x ist komplex und nicht ohne eine strukturelle Gliederung durchzuführen x hat einen vorgegebenen aufgabenbezogenen Kosten- oder Budgetrahmen x wird innerhalb einer projektbezogenen Organisation abgewickelt x benötigt definierte Ressourcen x wird interdisziplinär bearbeitet (fachabteilungsübergreifende Kombination und Kommunikation von Spezialisten) Zur Beherrschung dieser Prozesse wird heute Projektmanagement eingesetzt, das sich aus dem Leitungs- und Organisationskonzept zusammensetzt. Projektmanagement ist ein systematischer Prozess zur Führung komplexer Vorhaben. Es umfasst die Organisation, Planung, Steuerung und Überwachung aller Aufgaben und Ressourcen, die notwendig sind, um die Projektziele zu erreichen. Die unternehmensweite PM-Organisationsform sollte an die Wichtigkeit von Projektarbeit angepasst werden. In manchen Unternehmen werden Projekte lediglich als ergänzende Arbeitsform und verhältnismäßig selten eingesetzt, andere Unternehmen wiederum erbringen einen Großteil ihrer Wertschöpfung in Projekten und können somit als „Projektorientiertes Unternehmen“ bezeichnet werden.

Abb. 29. Aufgaben und Prozesse im Projektmanagement

Service und Wartung

5.3

65

Service und Wartung

Der Stellenwert der Instandhaltung, im Speziellen der vorbeugenden Instandhaltung, wächst in den letzten Jahren stetig. Gründe dafür sind z. B. dass die Planungsauslastung und die Produktionsgeschwindigkeiten von Fertigungsanlagen schon zum Großteil ihre technischen Grenzen erreicht haben und eine nahezu 100%ige Prozessverfügbarkeit gewährleistet werden muss. Weiterhin kann die Fertigungsqualität mit dem Anlagenzustand direkt in Zusammenhang gebracht werden. Um diesen erhöhten Anforderungen gerecht werden zu können, bedarf es angepassten Rahmenbedingungen und einer modernen, übergreifend funktionierenden Instandhaltung. Eine moderne Instandhaltung ist durch zustandsbedingte Maßnahmen gekennzeichnet, deren Prinzipien lauten: x die vorbeugende, d. h. planbare Instandhaltung ist zu minimieren, x die korrektive (nichtplanbare) Instandhaltung ist zu optimieren, x die zustandsüberwachende Instandhaltung ist zu maximieren. Die Aufgaben der Instandhaltung gehen jedoch in vielen Bereichen über die in der Norm 31051 („Maßnahmen zur Bewahrung und Wiederherstellung des Sollzustandes sowie zur Feststellung und Beurteilung des Ist-Zustandes von technischen Mitteln eines Systems“) definierten Funktionen hinaus. Themen wie die Arbeitssicherheit gemäß Betriebssicherheitsverordnung, Umweltschutz, die Kosten- und Lagerbestandsoptimierung sowie die schnelle und effektive Einsatzplanung von internen und externen Arbeitskräften machen den Einsatz eines durchgängigen und intelligente Instandhaltungsplanungs- und Steuerungssystem (IPS) unerlässlich.

6

IT-Bausteine einer prozessorientierten PLM-Lösung

Im den vorangehenden Abschnitten wurden die wertschöpfenden Bausteine und Prozesse vorgestellt, die eine PLM-Lösung unterstützen muss. Nun werden die dazu notwendigen IT-Komponenten erläutert und ihre Funktionen beschrieben. Wir beginnen mit den grundlegenden Funktionen des Produktdatenmanagements, welches die Definition der vollständigen Produktstammdaten mit Teilen, Produktstrukturen und Dokumenten erlaubt. Auch Funktionen zur Abbildung von Änderungen und Nachverfolgung der Änderungsstände über den Produktlebenszyklus werden in diesem Abschnitt erläutert. Danach gehen wir auf die Funktionen ein, die zur Realisierung eines umfassenden Produktentwicklungsprozesses notwendig sind und damit aus Produktdatenmanagement ein ganzheitliches Lifecycle-Management machen: Komponenten zum Ideen- und Anforderungsmanagement, für die operative Steuerung einzelner Projekte und zur Unterstützung von Portfolio- oder Programmmanagement. In den weiteren Phasen des Produktlebenszyklus sind Qualitätsmanagement und Instandhaltung wichtige Funktionen. Wir beschließen die Darstellung mit der Querschnitts-Funktion Workflow. Viele PLM-Systeme bieten ähnliche Funktionen an, die sich von den grundlegenden Konzepten her entsprechen, nur im Detail anders ausgeprägt sind. Wir beschränken uns auf die Darstellung von Funktionen, die in den meisten Systemen ausgeprägt sind. Weitestgehend orientieren wir uns dabei an der Funktionsausprägung in der Lösung mySAP PLM der SAP AG. Es handelt sich hier um eines der marktführenden PLM-Systeme, an dem außerdem die in Kapitel 4 postulierte enge Integration der PLM-Funktionen in andere Kerngeschäftsprozesse des Unternehmens gut dargestellt werden kann.

6.1

Das Produktdatenmanagement

Das Produktdatenmanagement (PDM) oder Lifecycle Data Management ist eine wesentliche Komponente des PLM und erstreckt sich über den gesamten Produktlebenszyklus beginnend bei der Produktentwicklung über Produktion und Verkauf bis hin zu Service und Instandhaltung. Zu Beginn der Produktentwicklung (nach der Ideen- und Konzeptphase) sind Produktdaten zunächst nur rudimentär bekannt, sie werden aber über den Entwicklungsprozess hinweg zunehmend präzi-

68

IT-Bausteine einer prozessorientierten PLM-Lösung

siert und müssen nach ihrer Freigabe mit Hilfe von Funktionen des Änderungsmanagements angepasst und überarbeitet werden. Mangelnde Datenqualität der Produktstammdaten erzeugt eine Fülle von Folgeproblemen nicht nur im Engineering, sondern in allen logistischen Anwendungsbereichen. Daher kommt qualitativ hochwertigen Produktstammdaten höchste Bedeutung zu. Wir beschränken uns bei der Darstellung auf die wesentlichen PDM-Stammdaten Dokumente, Teile und Produktstrukturen sowie das Klassifizierungssystem zum Finden und damit der Wiederverwendung von Daten. Eingegangen wird auch auf die Möglichkeiten zur Abbildung von Produktkonfigurationen und Änderungsprozesse. Bei einer etwas weiteren Fassung des Begriffes umfasst Produktdatenmanagement auch die den Produktionsprozess beschreibenden Stammdaten wie Fertigungshilfsmittel und Arbeitspläne; in der Prozessindustrie entsprechend Rezepturen. Ebenso ressourcenbeschreibende Stammdaten wie Arbeitsplätze und Kapazitäten. 6.1.1 Dokumentenmanagement Die Anfänge des Produktdatenmanagements gehen auf das Verwalten von Konstruktionszeichnungen zurück. Dateien, beispielsweise aus CAD-Systemen, wurden von einem zentralen System so verwaltet, dass sie in der Produktkonstruktion von verschiedenen Anwendern wieder gefunden werden konnten (Zeichnungsverwaltung). Heute hat sich der Anwendungsbereich einer Dokumentenverwaltung wesentlich erweitert: Abgelegt werden nicht mehr nur Zeichnungsdateien, heute sind komplexe Modelle und daraus abgeleitete Ansichten zu verwalten. Auch existiert eine Vielzahl sonstiger Dokumente – nicht zwingend in Zusammenhang mit der Konstruktion stehend – deren Ablage in einem Dokumentenverwaltungssystem Sinn macht, von technischen Berichten und Montageanweisungen bis hin zu Betriebsanleitungen. Nicht nur die Menge der zu verwaltenden Dokumente hat zugenommen, es sind auch verschiedenste Dateitypen mit verschiedenen zugeordneten Anwendungen (von der Textverarbeitung bis zum Auslegungsprogramm) in vielfältigen logischen Dokumentklassen zu organisieren. Die nächsten Abschnitte beschreiben die Kernfunktionen eines Dokumentenmanagementsystems (DMS). 6.1.1.1 Strukturierung von Dokumenten x Bildung von Dokumentenklassen / Dokumentarten: durch Gruppierung werden gleichartige Dokumente geordnet, Dokumentklassen definieren z. B. welche beschreibenden Attribute oder welche Funktionen nutzbar sind. x Bildung von Dokumentenstammsätzen: Dies sind logische Dokumente, denen ein oder mehrere physische Dokumente (Dateien, Originale) zugeordnet werden. Stammsatz und zugeordnete Dateien bilden eine Einheit, die vereinfachend oft als „das Dokument“ bezeichnet wird.

Das Produktdatenmanagement

69

x Dateien oder Originale: Das System verwaltet die Dateien, es sorgt für deren Speicherung und stellt sie bei Bedarf wieder zur Verfügung. In der Regel ist die zugehörige Applikation, mit der das Dokument bearbeitet oder angezeigt werden kann, mit dem DMS verknüpft. x Attribute: Der Dokumentenstammsatz wird durch einen Dokumentschlüssel (eindeutiger Bezeichner) und in der Regel weitere Attribute beschrieben (z. B. Bezeichnung, Ersteller, Erstellungsdatum, Bearbeitungsstand). Für die Bildung dieser so genannten Metadaten gibt es gemeinhin eine Fülle technischer Möglichkeiten (Freitextfelder, Schlagwortkataloge, Klassifizierung).

Abb. 30. Dokumentenverwaltungssatz im SAP DMS, zu erkennen sind die Felder der Dokumentgrunddaten und zwei zugeordnete Dateien. Weitere Metadaten, textuelle Beschreibungen und Verknüpfungen zu befinden sich auf anderen Reitern.

70

IT-Bausteine einer prozessorientierten PLM-Lösung

x Verknüpfung: Dokumente können untereinander durch Bildung von Dokumentenstrukturen oder Hierarchien in Beziehung gesetzt werden. Noch wichtiger ist die Verknüpfung zu anderen PDM-Objekten, z. B. den zugehörigen Teilestämmen. Gerade in ERP integrierte PLM-Anwendungen bieten den Vorteil, dass Dokumente nicht nur zu PDM-Objekten, sondern darüber hinaus zu ERP-Objekten wie z. B. Projekten verknüpft werden können. x Zugriffsschutz: Für den lesenden oder ändernden Zugriff auf Dokumente sind Autorisierungs- oder Berechtigungskonzepte vorhanden, mit denen bestimmten Gruppen von Benutzern der Zugriff gestattet oder verwehrt werden kann. 6.1.1.2 Unterstützung des Dokumenten-Lebenszyklus x Ablage: Das DMS kontrolliert und speichert die Metadaten und die zugehörigen Originaldateien. In der Regel wird für Dateien ein anderes Ablagemedium (externer Speicherbereich, z. B. Fileserver, Archiv, Content-Server) gewählt als für Metadaten, die meist in einer relationalen Datenbank gehalten werden. Das Speichern eines Dokuments bezeichnet man als Check-In. x Recherche: Die Suche nach Dokumenten muss über die eingegebenen Metadaten, vorhandene Verknüpfungen und die Dokumentklassen möglich sein. In der Regel werden verschiedene Systemoberflächen angeboten, die beispielsweise eine Recherche auch im Web-Client oder offline erlauben. x Volltextsuche: Zusätzlich wird oft gefordert, insbesondere bei OfficeDokumenten, das Dokument nicht nur über Metadaten, sondern über jede beliebige Zeichenkette innerhalb der Datei finden zu können. Dazu muss das System beim Check-In eine Recherchestruktur (Volltextdatenbank) aufbauen, die mit Hilfe von Suchalgorithmen, z. B. Ähnlichkeitssuche oder unscharfe Suche, ausgewertet wird. x Visualisierung: Nachdem ein Dokument gefunden wurde, ist das System in der Lage, die abgelegten Dateien dem Anwender zur Verfügung zu stellen (Check-Out) und automatisch in der gewünschten Anwendung anzuzeigen. x Änderungen an freigegebenen Dokumenten führen in der Regel zur Bildung neuer Versionen. Diese werden nach einer definierten Bildungsvorschrift mit Versionsnummern versehen; alte Versionsstände werden zur Dokumentation meist aufbewahrt. Die Versionierung muss in das weiter unten beschriebene Änderungsmanagement integriert sein. x Statuskonzept: Beschreibt den Dokumenten-Lebenszyklus. Statusübergänge entsprechen Phasen im Dokumentbearbeitungsprozess; Status erlauben oder verbieten die Durchführung bestimmter Aktionen am Dokument (z. B. nach Statusübergang zu „Freigegeben“ dürfen die zum Dokument gehörenden Dateien nicht mehr geändert werden; Änderung setzt Bildung einer neuen Version voraus).

Das Produktdatenmanagement

71

Abb. 31. SAP WebDocuments als alternative, browserbasierte Zugriffsoberfläche für das Dokumentenverwaltungssystem im mySAP PLM. Hier wird eine Trefferliste für eine Suchanfrage als „Leuchttisch“ mit so genannten Thumbnails dargestellt, alternativ ist auch eine List- und Detaildarstellung möglich.

x Digitale Signatur: Bestimmte Aktionen am Dokument (z. B. Freigabe) können eine Bestätigung durch eine „elektronische Unterschrift“ erfordern. Der Anwender muss eine durchgeführte Aktion quittieren, dies erfolgt entweder durch Eingabe eines Passwortes oder durch eine Chipkarte. Dadurch sind validierbare Genehmigungsverfahren auch nach Mehr-Augen-Prinzip möglich. x Dokumentenverteilung: Bietet Funktionen zum automatischen Versenden einer Gruppe von Dokumenten an Verteilerlisten, wobei Versand innerhalb des Systems, Versand durch Mail oder Ausdrucken und papierbasierter Versand unterstützt werden sollten.

72

IT-Bausteine einer prozessorientierten PLM-Lösung

Abb. 32. Visualisierung eines Dokumentenverwaltungssatzes mit dem im SAP DMS integrierten Viewer: Ein 3D-Modell (JT-Format) wird gerade angezeigt, Zoomen, Verschieben, Drehen, Bemaßung und Redlining sind möglich.

6.1.1.3 Integrationsfunktionen im DMS x Externe Applikationen: Die Anzeige und Bearbeitung der Originaldatei erfordert entweder den Aufruf der zugeordneten Applikation (externes Viewing z. B. im CAD-Programm) oder wird über im DMS integrierte Viewer ermöglicht. Letzteres bietet Vorteile, wenn die Dokumente einem größeren Benutzerkreis zugänglich gemacht werden. Viewer unterstützen Funktionen wie Redlining und Mark-Up. Anmerkungen und Hervorhebungen werden dabei als separate Layer verwaltet und über das Dokument geblendet. x Außerdem sollte aus häufig genutzten externen Applikationen auch eine direkte Übergabe der Dateien an das DMS mittels einer Online-Integration möglich sein. Diese Integration wird zu Microsoft-Office-Applikationen und CAD-Systemen meist als Standardfunktion bereitgestellt; oft können die Metadaten direkt in der Fremdanwendung erfasst werden, so dass der Anwender bei Ablegen des Dokumentes nicht mit der DMS-Oberfläche arbeitet. Die speziellen Funktionen der CAD-Integration werden in Abschnitt 6.1.5 beschrieben.

Das Produktdatenmanagement

73

x Workflow: Insbesondere für Prüf- und Freigabeschritte sowie für Dokumentenverteilung wird die Integration zu einem Workflowsystem benötigt, siehe hierzu auch Abschnitt 6.7. Freigabezustände am Dokument werden meist durch einen Status gekennzeichnet (in Arbeit, Zur Freigabe, Freigabe für Nullserie, Freigabe für Serie), wobei oft Status am Dokument und Status der zugehörigen Artikelstammsätzen synchron zu halten sind. x Konvertierungsfunktion: bietet die Möglichkeit – meist durch Anbindung kommerziell verfügbarer Konverter – Dateien von einem Applikationsformat (z. B. Office-Anwendung oder CAD) in ein Langzeitformat (z. B. PDF5 oder TIFF6) umzusetzen. x Output-Management: Nach Einführung einer elektronischen Dokumentablage besteht natürlich auch weiterhin die Notwendigkeit, Dokumente auszudrucken. Für die Einzelausgabe von Standardformaten kann in der Regel die Druckfunktion des Viewers oder Originalprogrammes genutzt werden, oft sind aber zusätzliche Funktionen notwendig:  Massendruck, automatisiert  Großformatdrucker oder Plotter sind anzusteuern  Beim Ausdrucken von Zeichnungen müssen Metadaten im CADSchriftfeld (Zeichnungskopf) mit aufgedruckt werden (Stamp by print), z. B. Werkstoff, Gültigkeit, Status, verantwortlicher Konstrukteur.  Beim Anzeigen der Zeichnung soll das Schriftfeld / Zeichnungskopf mit angezeigt werden (Stamp before view).  Beim Drucken sollen ganze Unterlagensätze mit Deckblättern automatisch zusammengestellt werden, z. B. alle Dokumente zu einer Produktstruktur, alle Dokumente zu einem Geschäftsvorfall, alle Dokumente zu einem Fertigungsauftrag im ERP-System  Plotten und Verteilen: Zu druckende Dokumente oder Unterlagensätze sollen empfängerbezogen verteilt werden, möglichst über unterschiedliche Medien wie Mail und Postversand. Hierzu dienen entweder in der Dokumentenverwaltung integrierte Funktionen (Plot-Management, Document Output Management) oder dedizierte Systeme, die über eine Schnittstelle integriert werden.7

5

Adobes PDF stellt Text als Text, Vektoren als Vektoren und sonstige Bilder im Rasterformat dar, bei Textformaten Vorteil hinsichtlich Speicherplatz. 6 TIFF = Tagged Image File Format Gruppe 4, Rasterformat; bietet bei großformatigen Zeichnungen Qualitätsvorteile. 7

Beispielsweise stellt in Ergänzung zum SAP PLM die Lösung „PLOSSYS netdome“ der Firma SEALSystems eine bekannte Lösung dar, in der die geschilderten Funktionen realisiert sind.

74

IT-Bausteine einer prozessorientierten PLM-Lösung

x Input-Management: Bei der Einführung von DMS-Anwendungen liegen oft große Mengen an Altbeständen noch in Papierform vor. Hier gilt es, diese Dokumente im Rahmen einer Datenübernahme insgesamt oder im Einzelfall bedarfsgerecht (Scan on demand) in elektronische Formate zu überführen. Dazu dient das Document Input Management. Dies wird auch benötigt, wenn im Rahmen einer Systemeinführung größere Mengen an Dokumenten oder Produktstrukturdaten aus einem Altsystem in eine neue Anwendung zu übernehmen sind. Bestandteil ist meist eine Funktion zur automatischen Formatkonvertierung. 6.1.1.4 Organisationsprinzipien eines DMS Standardorganisationsprinzip einer Dokumentenverwaltung ist die beschriebene Bildung von Dokumentenstammsätzen mit zugeordneten Dateien. Zur späteren Suche werden die Stammsätze durch Metadaten attributiert und durch Objektverknüpfungen mit anderen Objekten verbunden. Bei Verwaltungssystemen mit Anwendungsschwerpunkt Engineering / PDM findet man regelmäßig dieses Organisationsprinzip vor. Am Markt existieren jedoch auch Systeme, welche die Dokumente gänzlich anders strukturieren. Gerade bei anderen Anwendungsfeldern für das DMS (Bilddatenbank, Marketing, Qualitätsmanagement oder allgemeine Office-Dokument-Ablage) sollten diese alternativen Strukturierungsansätze gegeneinander abgewogen werden.

Abb. 33. SAP Records Management: Zeigt als Beispiel für ein mappenorientiertes DMS eine Produktakte mit Dokumenten und anderen PDM-Objekten.

Das Produktdatenmanagement

75

x Volltext-DMS: Systeme, bei denen Volltextrecherche auf einer Volltextdatenbank das grundlegende Organisationsprinzip ist; Attribute und Metadaten sind nicht zwingend erforderlich. Hauptanwendungsfeld solcher Systeme sind weniger PDM-Anwendungen, ihre Ursprünge liegen meist in der Schwerpunktausrichtung auf Geschäftsprozesse, die ein umfassendes Knowledge-Management erfordern. x Mappenorientierte Ablage: Organisationsprinzip ist hier nicht die Bildung einzelner Dokumentenstammsätze, sondern die Gruppierung der Dateien in Form von Mappen oder Ordnerstrukturen (z. B. Kundenordner, Maschinenakte, Vorgangsmappe). Mittels einer „Umlaufmappe“ können Workflows zur Abbildung von Vorgängen realisiert werden. Diese Arbeitsweise ist gerade im Verwaltungs- oder Versicherungsbereich häufig anzutreffen. 6.1.2 Produkt-Struktur-Management Im Unternehmen finden sich verschiedene Sichten auf die Produktstammdaten. Die Produktentwicklung betrachtet die Produktstruktur beispielsweise eher funktional, die Produktion strukturiert nach Fertigungs- und Montagegesichtspunkten (weitere Beispiele hierzu in Abschnitt 4.5). Eine typische Ausprägung dieses Produktmodells setzt Teilestammsätze (die Produkte) mit den Baugruppen durch Bildung von Relationen in Beziehung. Außerdem werden diese Objekte mit Dokumentenstammsätzen verknüpft, die CADModelle und Zeichnungen enthalten. Entwicklungsprojekt

Dokumentenstammsatz

Produkt

Teilestammsatz

Teilestammsatz

Teilestammsatz

Teilestammsatz

Cad-Modell

Zeichnung

Montageanweisung

Betriebsanleitung

Abb. 34. Exemplarische Abbildung eines Produktmodells

Jede Baukomponente wird von einem Teilestammsatz repräsentiert; egal ob es sich um eine eigenentwickelte oder zugekaufte Komponente handelt. Der Teilestammsatz hat eine identifizierende Nummer (Artikelnummer, Teilenummer) und beschreibende Felder wie Bezeichnung, Artikelart, Produktgruppe, Werkstoff und Gewicht.

76

IT-Bausteine einer prozessorientierten PLM-Lösung

Der konstruktionsbezogene Teilestammsatz wird in der Produktionsplanung und Logistik erweitert. Dabei wird er um betriebswirtschaftliche, planerische und dispositive Daten angereichert, die für Funktionen wie Beschaffungsabwicklung, Disposition, Vertrieb oder Produktionssteuerung erforderlich sind. Die Anzahl der zu verwaltenden Attribute steigt dadurch erheblich an. Beispielsweise umfasst der Materialstammsatz in SAP ca. 60 vordefinierte Standardfelder auf der so genannten Grunddatensicht, die allgemeine Teile-Informationen enthält, viele davon Ergebnis des Konstruktionsprozesses. Der gesamte Materialstamm umfasst in der Vollausprägung über 600 Felder. Die eigentliche Produktstruktur entsteht, indem im Konstruktionsprozess Teile und Baugruppen aus der Zeichnung abgeleitet, identifiziert und dann zueinander in Relation gesetzt werden. Baugruppen setzen sich wiederum aus Unterbaugruppen oder Teilen zusammen. Auch werden Rohteile, Zukaufteile oder Halbfertigteile beschrieben. Durch hierarchische Anordnung der Bestandteile und Strukturbildung entsteht eine Maschine oder Anlage; erst dadurch werden klassische Konstruktionsprinzipien wie Standardisierung, Wiederverwendung, Baukastenstrukturierung und Concurrent Engineering möglich. Das entstehende Produktmodell mit Baugruppen, Teilestämmen, Halbfertigteilen und Rohteilen und deren Beziehung zueinander wird im Allgemeinen als Stückliste bzw. als (mehrstufige) Stücklistenstruktur bezeichnet.

Abb. 35. Darstellungen einer Stückliste mit ihren Komponenten in SAP – links wird die Produktstruktur in einer Browsersicht dargestellt, rechts ist eine einzelne Stückliste zur Bearbeitung ausgewählt.

Das Produktdatenmanagement

77

Die ursprüngliche Konstruktions- oder Entwicklungsstückliste muss für die Verwendung in nachgelagerten Prozessen um zusätzliche Informationen angereichert oder anders ausgeprägt werden. Einige Beispiele für zusätzliche Anforderungen: x Es wird festgelegt, ob Bauteile zugekauft oder gefertigt werden, welche Rohmaterialien und Halbfertigteile zu benutzen sind oder es wird das Einund Auslaufen von Teilen nach Änderungen gesteuert. x In der Arbeitsvorbereitung werden auf Basis der Stücklisten der Produktions- oder Montageprozess und die Steuerung der Maschinen geplant. x Im Vertrieb werden Stücklisten als Erfassungshilfe bei der Eingabe von Kundenaufträgen genutzt. x In der Bedarfsplanung wird durch Stücklistenauflösung Termin und Menge von zu beschaffenden oder zu produzierenden Teilen ermittelt. Man unterscheidet daher verschiedene Stücklistenverwendungen, welche meist durch ein Sichtenkonzept realisiert werden: x Konstruktionsstückliste: gliedert das Produkt nach konstruktiven Gesichtspunkten meist funktional, weist eine eher geringe Stücklistentiefe auf x Fertigungs- oder Montagestückliste: Wird von der Arbeitsvorbereitung erstellt, gliedert das Produkt nach Montage- und Fertigungsgesichtspunkten, weist meist eine höhere Gliederungstiefe auf, da z. B. für die Vormontage kleinere Baugruppen gebildet werden (siehe auch [41], S.571 f.). x Kalkulationsstückliste: gliedert das Produkt gemäß der Kalkulationsrelevanz und wird zur automatischen Ermittlung der Produktkosten benutzt. Das PDM-System muss durch Funktionen zur Visualisierung und Modellierung der Produktstruktur gewährleisten, dass Stücklisten ineinander überführt werden können und nicht jeweils gänzlich neu aufgebaut werden müssen. Im ERP-System werden – im Unterschied zur PDM-Welt – Organisationsebenen (z. B. die Werke, in denen die Stückliste benutzt wird) abgebildet. Meist wird die Entwicklungsstückliste als unternehmensweit gültige Stückliste angenommen, die den produzierenden Werken zugeordnet werden muss oder auch von Werk zu Werk verändert werden kann. Die Anforderung, für bestimmte Funktionsbereiche und Organisationsebenen gezielt separate Stücklisten aufzubauen, impliziert natürlich höheren Aufwand für deren konsistente Pflege, insbesondere im Änderungsfall. Das Modul Stückliste sollte folgende Funktionen bieten: x Stücklistenkopf: beschreibende Daten, die sich auf die ganze Stückliste beziehen (textuelle Beschreibung, Status zur Einschränkung der Verwendung, Losgröße); stellt die Relation zum durch die Stückliste beschriebenen Teilestamm her. x Stücklistenposition: Beschreibung der in der Baugruppe verbauten Teile mit Informationen wie Bezeichnung, Teilenummer, Menge und Einheit;

78

IT-Bausteine einer prozessorientierten PLM-Lösung

gegebenenfalls in Unterpositionen detailliert. Im ERP-System unterscheidet man verschiedene Positionstypen, welche die dispositive Behandlung der Komponente beschreiben (z. B. Lagerposition versus Nicht-Lagerposition). Auch Textpositionen oder Dokumentpositionen sind möglich. x Mehrfachstücklisten: repräsentieren unterschiedliche Alternativen, beispielsweise für verschiedene Losgrößenbereiche. x Auflösung und Ausgabe der Stücklistenstruktur; dabei werden nach [48] in der Regel unterschieden:  Baukastenstückliste: einstufige Stückliste, zeigt nur die Komponenten auf der obersten Ebene der Baugruppe  Strukturstückliste: gibt die vollständige Produktstruktur wieder; dabei können gleiche Teile auf unterschiedlichen Stücklistenebenen mehrfach vorkommen  Mengenübersichtsstückliste: listet alle vorkommenden Komponenten mit kumulierter Mengenangabe auf x Teileverwendungsnachweis: Sucht alle Stücklisten, in denen eine Komponente verwendet wird.

Abb. 36. Produktstruktur-Browser in SAP – erlaubt Darstellung der Produktstruktur mit allen Objekten des SAP PDM, insbesondere Materialien, Dokumente, Stücklisten, Änderungen, Klassifizierung; deren Beziehungen zueinander ausgewertet und dargestellt werden

Das Produktdatenmanagement

79

x Stücklistenvergleich x Funktionen zur Massenänderung von Stücklisten, z. B. Austausch einer Komponente Zur Visualisierung und Manipulation der definierten Produktstrukturen bieten PDM-Systeme in der Regel einen Struktur-Browser an. Dieser ist in der Lage, die komplette Produktstruktur in Form einer hierarchischen Ansicht darzustellen, meist auch verknüpfte Dokumente und sonstige PDM-Objekte. Verschieden konfigurierte und detaillierte Ansichten sollen unterschiedlichen Anwenderkreisen eine jeweils optimale Anwendungsumgebung bereitstellen. Die Stückliste wird somit zu Recht als „einer der wichtigsten Informationsträger in einem Fertigungsunternehmen“ bezeichnet (nach [48], Seite 206). Die Übergänge von der Entwicklungsstückliste zu weiteren Stücklistenverwendungen und vom Teilestammsatz zu dem Materialstammsatz stellen das grundlegende Bindeglied zwischen den Systemwelten PDM und ERP dar. Durch eine enge Integration von PDM- und ERP-Welt wird dieser Übergang deutlich erleichtert und der Konstruktionsprozess enger in logistische Funktionen integriert. Auch in nachgelagerten Prozessen wie Änderungswesen ergibt sich damit ein durchgängiger Prozess frei von Systembrüchen. 6.1.3 Klassifizierung Ein Klassifizierungssystem wird benutzt, um unter einer Vielzahl von Objekten ein bestimmtes Objekt oder ähnliche Objekte zu identifizieren bzw. festzustellen, dass es kein ähnliches Objekt gibt, beispielsweise bei einer Suche nach einem Normteil aus der CAD-Anwendung heraus. Klassifizierungen werden meist für Teilestämme, Produktstrukturen und Zeichnungen aufgebaut, gerade im ERP-System können meist beliebige andere Geschäftsobjekte ebenfalls klassifiziert werden. Klassifizierungen sind nicht der einzige Weg zu einer erfolgreichen Suche – sie ergänzen die Suche über Objektschlüssel und Objektattribute – bieten aber den Vorteil, das sie besser als andere Attribute (z. B. bezeichnende Kurztexte) normiert werden können. Gerade bei zunehmender Informationsmenge und Produktvielfalt wird eine Klassifizierung immer wichtiger: Letztlich geht es nicht nur um schnelles Finden, es geht um Wiederholteilstrategien, Vermeidung von redundanten Stammdaten, effizientes Konstruieren oder Bündelung von Einkaufsvolumina. Objekte werden über ihre Eigenschaften, die so genannten Sachmerkmale, beschrieben. Jedem Merkmal ist ein Wertebereich zugeordnet, durch Auswahl von konkreten Werten wird ein konkretes Objekt identifiziert. Alle Merkmale, die ein Objekt beschreiben, bilden die Sachmerkmalsliste. Ergänzt werden Sachmerkmalslisten oft durch ein hierarchisches Klassifizierungsverfahren, bei dem die Objekte in Baumstrukturen kategorisiert werden. Die Kategorien entstehen, indem Klassen gebildet werden, denen bestimmte Eigenschaften (Merkmale) zugeordnet sind. Die Klassen werden in Baumstrukturen

80

IT-Bausteine einer prozessorientierten PLM-Lösung

angeordnet, niedrigere Klassenstufen verfeinern die Klassifizierung durch weitere oder konkretere Merkmale. Ausgehend von der Merkmalsbewertung der konkreten Objekte werden diese einer Klasse in der Hierarchie zugeordnet; beim Suchen dienen die Klassenbeschreibungen als Wegweiser zu den zugeordneten Objekten. In der Industrie werden oft Standard-Klassifizierungssysteme benutzt, die von Normungsgremien (DIN, ISO) definiert wurden und zum Beispiel in Normteilbibliotheken Verwendung finden.

Eigenschaften

Leistung [W] Masse [kg]

Faltflächengenerator

Rotationsgenerator

Eigenschaften

Eigenschaften

Freiheitsgrade Entfaltungstyp

Winkelgeschwindigkeit

zum vom Allgemeinen zum Allgemeinen vom Speziellen Speziellen

Solargenerator

Abb. 37. Klassenhierarchie mit zugeordneten Eigenschaften (Merkmale)

6.1.4 Variantenkonfiguration / Produktkonfiguration Bei der Definition komplexer, variantenreicher Produkte kann die Variantenkonfiguration eine wesentliche Erleichterung bilden: Sie erspart es der Konstruktion, für unterschiedliche aber ähnliche Produktvarianten jeweils eigene Teilestämme, Stücklisten und Arbeitspläne anzulegen, die sich nur geringfügig unterscheiden. Ziel ist es, durch Variantenkonstruktion eine Produktstandardisierung mit einem möglichst hohen Anteil an Gleichteilen und wieder verwendeten Komponenten zu erreichen. Jeder Auftrag wird zwar speziell für den Kunden „konfiguriert“, dies erfordert aber keine Auftragskonstruktion oder Neuentwicklung mehr. Dazu wird das Produkt auftragsneutral vorgedacht: man konstruiert eine generische Produktstruktur, die ihre Abbildung in Form einer Maximalstückliste und eines Maximalarbeitsplanes findet. Aus diesen können alle (zulässigen) Ausprägungen des Produktes abgeleitet werden. Außerdem wird das bisher beschriebene Produkt-Struktur-Datenmodell um die Konfigurationslogik ergänzt. Zur Ausprägung der Logik gibt es verschiedene Programmiermodelle: x Durch Regeln (Constraints) werden – in Abhängigkeit von der Beschreibung des Endprodukts – sukzessive alternative Komponenten in der Stückliste oder alternative Arbeitsplanvorgänge ausgewählt. Regeln können auch Werte in den Produktstrukturdaten verändern (z. B. Einsatzmenge).

Das Produktdatenmanagement

Kundenauftrag Position 1 Pumpe HGT

Bewertung der Merkmale

Land:

Deutschland

Typ:

HGT32

Netz:

230 V

81

Förderhöhe: 3 m

Auszug der Regeltabelle Netz

Höhe

Antrieb

Gehäuse

HGT32

230

63/011100/028 KONSTRUKTION Status => 63/011100/028 ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------Ktr Teilefamilienschlüssel Pp Änd.Buchstabe Dissl Werk/Segment Ktr Teilefamilienschlüssel Pp Änd.Buchstabe Dissl Werk/Segment 06000 000050 CC 028 63/011100 06000 000050 028 63/011100 ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------Wk/Sg Artikelbezeichnung Al Abmessung Var Mat-F Tot Wk/Sg Artikelbezeichnung Al Ab Ab Sach-Nr Sach-Nr Abmessung Var Mat-F St-Menge St-Menge Bemerkung Bemerkung Tot Pos Pos 63/011900 006-764-940 0000 11 ST 001 63/011900 HH F-234612-11 F-234612-11 006-764-940 20X22X13,3 20X22X13,3 0000 ST 001 KK 63/011900 K HK 1612-52 001-063-928 16X20X9,93 0000 1 002 63/011900 K HK 1612-52 001-063-928 16X20X9,93 0000 1 ST ST 002 KK 03/010800 XX 7,3 000-163-422 0000 18 003 03/010800 NRB NRB 22 7,3 G2 G2 000-163-422 2X7,3 2X7,3 0000 18 ST ST 003 KK 60/000000 005-442-729 0000 0.4 030 60/000000 FETT FETT 005-442-729 0000 0.4 GG 030 KK -SYNTHESO-PRO-AA-2-KFA. -SYNTHESO-PRO-AA-2-KFA. KLUEBER KLUEBER ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------Nr Aemnr Aegr Datum Nr II Aemnr Stücklistenänderungstexte Stücklistenänderungstexte Aegr Vw Vw Datum ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------001 00 HINZU 22 02 2000-05-29 001 AA HINZU PO30 PO30 FETT FETT 0,4G 0,4G 22 02 2000-05-29

Stückliste

Abb. 74. Alte Datenwelt des Produktkonstrukteurs bei INA-Schaeffler KG

148

PLM in der Schaeffler-Gruppe

Konfigurationen

Dokumentenverwaltung

CADSchnittstelle

Änderungsdienst Änderungs dienst

-

Klassensystem

SAP PLM

Stücklistenverwaltung

Projektsystem Materialstammverwaltung

Abb. 75. Neue Datenwelt des Produktkonstrukteurs bei der INA-Schaeffler KG

und Weiterleitung zu steuern und zu kontrollieren. Auch im nächsten Jahr liegt hier der Schwerpunkt der Arbeit. Doch decken sich bereits jetzt weitere Potenziale bei Themen wie Werkzeugabstimmung, Verschleißteilbeschaffung, Auslaufsteuerung usw. auf, die es erst noch in den nächsten Jahren auszuschöpfen gilt. Ein weiteres wesentliches Ziel beim PLM-Einsatz besteht darin, in der gesamten Schaeffler-Gruppe eine Vereinheitlichung der Systeme zu erreichen. Abb. 74 und Abb. 75 geben einen Eindruck darüber, wie es mit SAP PLM gelungen ist, für die Produktkonstrukteure der INA-Schaeffler KG eine Reduzierung der Systemvielfalt und Medienbrüche zu erreichen. Die konstruktive Beschreibung der Erzeugnisse wird nun in diesem Sinne einheitlich in SAP PLM verwaltet.

9.2

CAD-Integration und Stammdaten als Projektherausforderung

Ein Beispiel für die Probleme, die bei derartigen Integrations- und Vereinheitlichungsbemühungen entstehen können, stellt die Zeichnungs- und Modellverwaltung dar. Vor der weltweiten Einführung von SAP PLM mussten die Konstrukteure mit verschiedenen Systemen zur Zeichnungsverwaltung, Dokumentenverwaltung oder CAD-Modellverwaltung arbeiten. Trotz umfangreicher Versuche ist es bislang nicht möglich, die CAD-Modelle höherer Ordnung auch bei komplexeren Baugruppen befriedigend ausschließlich in SAP PLM zu verwalten und damit auf Pro/Intralink zu verzichten. Insofern gibt es nach wie vor nicht nur ein System für

CAD-Integration und Stammdaten als Projektherausforderung

149

den Konstrukteur (was aber langfristiges Ziel bleibt, zumal in der SchaefflerGruppe Pro/Engineer als strategisches CAD-System gesetzt ist). Immerhin konnte es im Dezember 2004 gelingen, einen eindeutigen Bezug zwischen den nativen CAD-Modellen und dem Dokumentenstammsatz in SAP zu gewährleisten. Die gesicherte Weitergabe von Modellversionen an Prozessinstanzen außerhalb der Konstruktion (diese können nun mittels eines Viewers informativ auf die Modelle zugreifen) erhöht natürlich auch die Transparenz und Prozesssicherheit in der gesamten Logistikkette. Pro/Intralink wird also nur noch als Modellaufbewahrungssystem genutzt, die Prozesshandhabung findet komplett in SAP PLM statt. In den Konstruktionsabteilungen selbst führt diese Lösung, die in der gesamten SchaefflerGruppe eingesetzt wird, zu der gewünschten weltweit einheitlichen Anlage, Änderung, Freigabe von CAD-Zeichnungen und -Modellen sowie zur eindeutigen Zuordnung der Konstruktionsdokumente zu den Materialstämmen. Letzteres ist wichtig, weil die Datenqualität des Materialstamms angesichts der Integrationsziele immer mehr steigt. Schließlich werden mit SAP die Feldinhalte des vom Konstrukteur erzeugten Materialstamms in unterschiedliche Anwendungen referenziert (wie z. B. Arbeitsplan oder Bestellanforderung), so dass dieser Stammsatz den Grundbaustein für alle logistischen Prozesse im Unternehmen sowie die Kostenplanung, -erfassung und -verteilung etc. bildet. Der Materialstamm enthält also Informationen aus allen Unternehmensbereichen. Ferner hängen an ihm alle für den Konstrukteur wichtigen Dokumente, Stücklisten und Änderungsinformationen (siehe auch Abb. 76). Um dieser Bedeutung gerecht zu werden, gilt neuerdings eine Freigabesteuerung, nach der nur ein Produktgruppenverantwortlicher berechtigt ist, einen Materialstamm freizugeben. Weiterhin wurde ein Klassifikationssystem aufgebaut, das weltweit in der gesamten Schaeffler-Gruppe eine einheitliche Teilebeschreibung erlaubt und die Funktion als Integrationsmittel unterstützt – und natürlich auch dem Konstrukteur die Möglichkeit einer umfassenden Ähnlich-/Wiederholteilsuche (nach Fit-Form-Function-Merkmalen wie Tragzahl oder Innendurchmesser) bietet. Die geschilderten Integrations- und Vereinheitlichungsleistungen spiegeln sich auch in den umfangreichen Verknüpfungen der PLM-Objekte wider. Abb. 76 zeigt, wie dies im PLM-System zum integrierten Zugriff auf alle produktbezogenen Informationen der Schaeffler-Gruppe führt. Der Ehrgeiz der Schaeffler-Gruppe, alle Objekte integriert zu verwalten, führte darüber hinaus zu dem Bemühen, auch die CAD-Datenstrukturen besser in SAP PLM zu steuern. In diesem Sinne wurde der so genannte CAD-Desktop auf Initiative von INA programmiert. Er ermöglicht eine komfortable Bearbeitung von CAD-Dokumentstrukturen im SAP-System. Insbesondere Zusammenhänge zwischen Dokumenten, wie sie bei Baugruppen auftreten, wurden vorher nicht im SAP-System verwaltet. Dabei erfolgt die Darstellung der CAD-Strukturen über einen (voll konfigurierbaren) Browser, der es erlaubt, alle in SAP abgelegten Dokumentinformationen, wie Status, Sachbearbeiter, Format, Materialverknüpfungen etc., anzuzeigen. Zudem bietet der CAD-Desktop einen direkten Zugriff auf die wichtigsten Verwaltungsbefehle und unterstützt Massenbearbeitungsfunktionen

150

PLM in der Schaeffler-Gruppe Änderungsstamm Änderungsstamm 22 22

Objektverknüpfung

Konstruktions-Stückliste Konstruktions-Stückliste

F-550002 F-550002 /EDB/A00/AB /EDB/A00/AB Status: Status: Abgeschlossen Abgeschlossen Gültig Gültig ab: ab: 1.12.04 1.12.04

500000042-0000 500000042-0000 (2) (2) Fre

Materialstamm Materialstamm 500000042-0000 500000042-0000 F-550002 F-550002 KIPH KIPH Status: Status: „F“ „F“

Materialstamm Materialstamm 500000042-0000-10 500000042-0000-10 F-550002 F-550002 KIPH#v KIPH#v Status: Status: „F“ „F“

DokumenteninfoSatz DokumenteninfoSatz EDD EDD F-550002 F-550002 A00 A00 AB AB Status: Status: Freigegeben Freigegeben Gültig: Gültig: 1.12.04 1.12.04 bis bis ... ... Änderungsnr: Änderungsnr: 22 22

ig

e ab

Pos10 D EDD F-550002 A00 AB (Änderungsnr. 22) Gültig ab 1.12.04 bis 31.12.9999

Netzplan Netzplan

Rückmeldung: Rückmeldung: Aktualisierung Aktualisierung der der Termindaten Termindaten (Änderungsnr. (Änderungsnr. 22) 22)

Original Projektstrukturplan-Element Position Position des des SalesDistribution-Beleg‘s SalesDistribution-Beleg‘s

Abb. 76. Verknüpfung der konstruktiven Stamm- und Strukturdaten in SAP PLM

für eine interaktiv getroffene Dokumentenauswahl, um etwa alle Komponentenzeichnungen einer Baugruppe freizugeben. Somit gilt er heute in der gesamten Schaeffler-Gruppe als wichtigstes Werkzeug zur Bearbeitung von SAPKonstruktionsdaten für Baugruppen, Teile und Zeichnungen.

9.3

Ausblick

Wie geht es nun in der Zukunft weiter? Die zurzeit laufenden Weiterentwicklungen konzentrieren sich darauf, den geschilderten Ideen und Ansätze noch mehr Geltung zu verleihen. So fördern Projekte zur Harmonisierung von Stammdaten und Standards in der Schaeffler-Gruppe sowie der Ausbau von so genannten Gruppengeschäftsprozessen die Bemühungen zur Daten- und Prozessvereinheitlichung im gesamten Konzern. Im kommenden Jahr steht der Roll-Out des konzernweiten Konzeptes in Bereichen der FAG Kugelfischer AG & Co. oHG oder der LuK GmbH & Co. oHG an. Daneben unterstützten beispielsweise Projekte zum Konzept der Digitalen Fabrik die Visionen im Hinblick auf die Integration. In engem Zusammenhang mit diesen strategischen Vorgehensweisen stehen die Anstrengungen, im Tagesgeschäft komfortable Arbeitsweisen für den Konstrukteur sicherzustellen. Jüngste Fortschritte im CAD-Desktop sind hier etwa die Schreibtischfunktionalität für häufig verwendete Normen und Konstruktionsdokumente oder die Möglichkeit, mehrere Zeichnungen gleichzeitig zu öffnen (zum Beispiel zum Zeichnungsvergleich). Wesentliche Konzentration in der Zukunft gilt zudem der Betriebsmittel- und Sondermaschinenkonstruktion, die mit SAP PLM ihre

Ausblick

151

konstruktive Beschreibung vollständig elektronisch verwalten wird. Auch für Versuch und Entwicklung gibt es viel versprechende Ansätze zur PLM-Kontrolle der konstruktiven Beschreibung der Prüfstände, Berechnungsdaten, Platinenlayouts usw. Und eines zeigt sich bereits jetzt: Der weltweite Aufbau einer Global Engineering Database in SAP PLM, die alle Konstruktionsdaten (wie Zeichnungen, Materialstämme, Stücklisten, Änderungsbeschreibungen und Klassifizierung) in einem einzigen System enthält und auf das alle Zugriff haben, bietet erhebliche Potenziale.

10 Komplexitäts- und Produktvariantenmanagement bei einem Serienfertiger

Diese Fallstudie stellt ein Projekt zur Einführung eines Komplexitäts- und Variantenmanagements in der Investitionsgüterindustrie vor. Es wird geschildert, wie durch Beherrschung der Produktkomplexität, Reengineering der damit verbundenen Prozesse in Kombination mit einer Lösung zur Variantenkonfiguration erhebliche positive Effekte realisiert wurden. Das mittelständische Unternehmen erreichte nicht nur eine Optimierung des Produktangebotes, sondern auch positive Effekte auf den Materialfluss, die Logistikstruktur und den Servicegrad.

10.1 Ausgangssituation Ein weltweit führender Anbieter von Maschinen, Anlagen und Dienstleistungen für unterschiedlichste Produktions- und Arbeitsprozesse ist bereits heute mit Niederlassungen und Partnern in über 50 Ländern vertreten. Das mittelständische Traditionsunternehmen hat sich mit mehr als 3000 Mitarbeitern als einer der Vorreiter in der Branche etabliert und zeichnet sich mit zahlreichen Produktinnovationen sowie hoher Produkt- und Servicequalität aus. Um die Gesamtwirtschaftlichkeit (Life-Cycle-Costs) seiner Produkte kontinuierlich und nachhaltig zu optimieren, wird unter anderem modernste Informationstechnologie eingesetzt. Eine Unternehmensanalyse durch IDS Scheer hat jedoch gezeigt, dass innovative Produkte allein nicht ausreichen, um die Wettbewerbsposition nachhaltig zu sichern. Auch die Ansprüche der Kunden an eine weltweit hohe Lieferfähigkeit (hohe Termintreue, kurze Lieferzeiten etc.) stiegen weiter. Das führte u. a. dazu, dass das Unternehmen Aktivitäten zur Optimierung der Logistikkette (Supply Chain) und des Logistiknetzwerkes umsetzte. Auf Basis der von IDS Scheer durchgeführten Unternehmensanalyse konnte man erkennen, dass die Unternehmensziele bei weiter zunehmendem Kostendruck nicht alleine durch eine Optimierung der Logistikkette erreicht werden konnten. Unter anderem wurde dem Haupteinflussfaktor Produktkomplexität zu wenig Beachtung geschenkt. Während die Wiederholhäufigkeit von Bauteilen ständig gesunken ist, war gleichzeitig ein starkes Wachstum der Produktvarianten zu verzeichnen, d. h. die Produktvariantenanzahl stieg überproportional zur verkauften Bauteilstückzahl. Diese Situation stellte an die Unternehmensprozesse (z. B. Änderungsmanagement, Logistik, integrierte Auftragsabwicklung etc.) besondere Anforderungen. Erfahrungswerte zeigen, dass mit jeder Verdopplung der Variantenanzahl die Prozesskosten ca. 20-30 % steigen. Um das größtmögliche Varianten-

154

Komplexitäts- und Produktvariantenmanagement bei einem Serienfertiger

Extern - Marktposition - Umsatz

Marktbedingungen - Kundenanforderungen - Konkurrenzsituation

Unternehmensstrategie - Produktpolitik/-Portfolio - Marktpositionierung/ Marktdurchdringung

Vielfalt im Produkt und der logistischen Leistung

Zukünftig - Kundenbindung - Marktanteil - Reputation, Image

Intern - Leistungsfähigkeit - Unternehmenskomplexität

Unternehmenspotenzial - techn. Fähigkeiten und betriebliche Ressourcen

Variantenvermeidung

Variantenmanagement Variantenbeherrschung

Variantenreduzierung

Abb. 77. Ausgangssituation und Zielsetzung

potenzial (Verhältnis zwischen Variantenkosten zu Variantennutzen) realisieren zu können, war die Einführung eines Komplexitäts- und Produktvariantenmanagements als Bestandteil eines ganzheitlichen Product Lifecycle Management erforderlich. Abb. 78 zeigt das Variantenoptimierungsportfolio in Form eines ABC/XYZDiagramms. Auf Basis einer Datenanalyse wurde nachgewiesen, dass sehr viele hochwertige und aktive Produktvarianten mit einer sehr unregelmäßigen Bedarfssituation vorhanden waren. Zeigt man die Zusammenhänge zwischen den Produktvarianten und den Logistikprozessen auf, so kann man feststellen, dass unter anderem im Bereich Produktionsplanung und Disposition hohe Prozesskosten und Bestände aufgrund der sehr starken Bedarfsschwankungen (bedingt durch eine hohe Variantenanzahl) entstehen. Um die Bedarfsschwankungen zu reduzieren, empfiehlt sich unter anderem die Anzahl der Gleichteile (Variantenreduzierung) durch eine konsequente Umsetzung von Konstruktionsmaßnahmen (Plattformstrategie) zu erhöhen.

10.2 Ziele des PLM-Einsatzes Das einzuführende Komplexitäts- und Produktvariantenmanagement sollte im Unternehmen folgende Ziele realisieren:

Ziele des PLM-Einsatzes

155

Produktwertigkeit

Variantenoptimierungsportfolio

Bedarfsvarianz Abb. 78. Auswirkung von Varianten auf die Logistikprozesse

x Reduzierung der Variantenvielfalt ohne Reduzierung der Angebotsvielfalt (technische Variantenoptimierung) unter Berücksichtigung der Zielkosten (target costs) x Realisierung eines nachhaltigen Varianten- und Komplexitätsmanagements durch Einführung geeigneter Methoden, Prozesse, Organisationen und IT ausgehend von der Unternehmensstrategie x Reduzierung von Over-Engineering-Lösungen, d. h. Realisierung marktkonformer Produkte idealerweise in Form von Plattformen, Modulen und Baukästen

156

Komplexitäts- und Produktvariantenmanagement bei einem Serienfertiger

x Verlagerung des Order-penetration-points (Variantenbestimmungspunkt) auf einen späteren Zeitpunkt innerhalb der Logistikkette (d. h. von Maketo-order-Prozessen zu Assembly-to-order-Prozessen) x Einfache, fehlerfreie Produktauswahl, aktuelle Preis- und Lieferterminangaben x Voraussetzungen schaffen für den Internetverkauf (Produkt-Konfiguration ist dabei eine notwendige Bedingung) x Standardisierung des Verkaufsprozesses und Fokussierung auf das Standard-Produktprogramm x Standardisierung und Strukturierung des Produkts x Verbesserung der Datenqualität durch Variantenmanagement

10.3 Vorgehensweise im Projekt Der Projekterfolg zur nachhaltigen Reduzierung der Produktvarianz ohne wesentliche Reduzierung der Auftragsvarianz konnte nur durch eine ganzheitliche Betrachtung aller Prozesse des Komplexitätsmanagements erreicht werden. Strategie zur Variantenbeherrschung

MarktWettbewerbsanalyse

Produktstrukturierung

Controlling

Variantenmanagement

Integrierte Auftragsabwicklung

Abb. 79. Ganzheitliches und integriertes Komplexitätsmanagement

Vorgehensweise im Projekt

157

Ausgehend von den Unternehmenszielen wurde mit Hilfe von Markt- und Wettbewerbsanalysen der Kundennutzen bzw. die Haupterfolgsfaktoren ermittelt und im Unternehmen als Ziel vor die Realisierung von Kundenindividualität gestellt. Es wurde erkannt, dass das Hauptaugenmerk des Kunden eigentlich auf der funktionalen Eigenschaft der Maschine (z. B. Realisierung einer bestimmten MaschinenLeistungskennlinie) lag, bestellt wurde jedoch die technische Produkteigenschaft (z. B. bestimmter Elektromotor eines Herstellers). Hier war der Vertrieb durch Beratungsleistung besonders gefordert. D. h. der Kunde musste von den Leistungsparametern der Maschine überzeugt werden und nicht von den einzelnen MaschinenKomponenten. Daraus abgeleitet ergab sich in der Unternehmensführung eine Strategie zur Variantenbeherrschung (z. B. Ergebnisorientierung anstelle von Umsatzorientierung), die in allen Bereichen des Unternehmens berücksichtigt werden musste. Auf Basis der von IDS Scheer durchgeführten strategischen Prozesskostenrechnung konnte nachgewiesen werden, dass bestimmte Produktvarianten aus dem Leistungsangebot aufgrund der Höhe der Prozesskosten gestrichen werden mussten. Durch die Produktneustrukturierung wurden geeignetere Produktstrukturen (Plattformen, Module, Baukästen) nach einem vorgegebenen Regelwerk interdisziplinär definiert und konsequent durch ein entsprechendes Organisationskonzept zur Umsetzung gebracht. Das Variantenmanagement hatte dabei als zentrale Aufgabe die Produktkomplexität x zu reduzieren (z. B. Standardisierung von Baukästen), x zu vermeiden (z. B. Modulkonzepte etablieren) und x zu managen (z. B. integriertes Änderungsmanagement).

Produktklassifizierung

Variantenoptimierung

Stücklistenoptimierung

Produktkonfiguration

Abb. 80. Komplexitätsreduzierung

158

Komplexitäts- und Produktvariantenmanagement bei einem Serienfertiger

Bereinigung der Merkmalsausprägungen führt zur Reduzierung der Varianz

Abb. 81. Merkmalvariantenbaum

Im Rahmen einer kontinuierlichen Variantenanalyse wurden die Produkte (Produktfunktionen und Produktstrukturen), Prozesse (Variantenprozesse) und Kosten (Prozesskosten) analysiert und optimiert. Dabei wurden mit einem ProductLifecycle-Management-System alle Bauteile klassifiziert und strukturiert. Ähnliche Teile wurden identifiziert und durch konstruktive Maßnahmen teilweise eliminiert. Dadurch konnten die technischen Merkmalsausprägungen zur Beschreibung aller Produktvarianten wesentlich reduziert werden. Die optimale Produkt- und Variantenstruktur wurde durch eine geeignete Konfigurationslösung in eine integrierte Auftragsabwicklung überführt. Dieser Geschäftsprozess wurde gemäß den Vorgaben des Variantenmanagements im Sinne eines Business Process Reengineerings neu gestaltet. Dabei wurde das Produktspektrum überarbeitet, in drei Klassen eingruppiert und entsprechende Logistikund Product-Lifecycle-Management-Prozesse definiert: x Gruppe A (A-Anlagen): Bei A-Anlagen handelt es sich um Standard-Fertigprodukte, die jeweils kundenauftragsanonym produziert (make-to-stock) werden und in der Regel im Lager zum sofortigen Verkauf bereitstehen. x Gruppe B (B-Anlagen): B-Anlagen sind klassische Standard-Produktvarianten, die im Auftragsfall konfiguriert und danach kundenspezifisch montiert werden (assemble-to-

Projektfazit

B-Anlagen = Varianten

159

CAnlagen

A-Anlagen = Lageranlagen

A-Anlagen: Lageranlagen (anonyme Fertigung mit Materialnummer) „Make-to-stock“ B-Anlagen: Varianten (in Kundeneinzelfertigung montiert) „Assemble-to-order“ C-Anlagen: Kundenspezif. Sonderanlagen (Auftragskonstr., Kundeneinzelfert.) „Engineer-to-order“

Abb. 82. Das ABC-Konzept bei der Variantendefinition

order). Die Komponenten einer B-Anlage sind lagerhaltig und weitgehend standardisiert, so dass weitgehend auf eine Anpassungskonstruktion verzichtet werden kann. x Gruppe C (C-Anlagen): Bei C-Anlagen handelt es sich um Sondermaschinen, die im Auftragsfall kundenspezifisch entwickelt wurden (Engineer-to-order). Diese Sonderanlagen können nur begrenzt vorkonfiguriert werden. Das Herzstück der Geschäftsprozesse Assemble-to-order und Engineer-to-order ist das integrierte Konfigurations- und Änderungsmanagement. Es wurde sehr schnell erkannt, dass ohne entsprechende IT-Unterstützung durch ein geeignetes ProductLifecycle-Management-System die komplexen Prozess-Schnittstellen zwischen der Engineering- und der Logistik-Prozesskette nicht optimiert werden konnten. Auf Basis des von IDS Scheer entwickelten Vorgehensmodells ARIS-Scout für Variantenkonfiguration wurde schnell die Logik für den Variantenkonfigurator festgelegt und im Rahmen eines Implementierungsprojektes eingeführt. Mit dem eingesetzten Konfigurator des PLM-Systems können heute nicht nur Produkt- und Servicestücklisten, sondern auch Arbeitspläne, Betriebsanleitungen und Projekte konfiguriert werden.

10.4 Projektfazit Erst mit der Einführung eines Komplexitäts- und Produktvariantenmanagements und der damit verbundenen Konzentration auf ertragreiche Produkte konnte im vorliegenden Unternehmen eine nachhaltige Optimierung des Materialflusses, eine

160

Komplexitäts- und Produktvariantenmanagement bei einem Serienfertiger

Abb. 83. Vorgehensmodell Variantenmanagement im ARIS-Scout

Reorganisation der Logistikstruktur und eine Erhöhung des Servicegrades nachweislich erzielt werden. Die Komplexität der Produkte zu reduzieren ist dementsprechend einer der besten Hebel beim Streben nach einfachen und leistungsfähigen Prozessen. Das eingesetzte Product-Lifecycle-Management-System hat hierbei einen wesentlichen Beitrag zu einer effizienteren Abwicklung der Prozesse geleistet bzw. eine Prozessintegration zwischen Engineering- und Logistikprozessen überhaupt erst möglich gemacht. Das Beherrschen der Produkt- und Prozesskomplexität führte zu folgenden wesentlichen Erfolgen: x Während der Personalaufwand für die Angebots- und Auftragsabwicklung mit Einsatz des Variantenkonfigurators um ca. 30 % reduziert wurde, konnte darüber hinaus die Durchlaufzeit von der Auftragsanlage bis zur Produktionsfreigabe um mehr als 50% verkürzt werden. x Reduktion des Personalaufwandes in der Konstruktion um ca. 15% bei der Pflege von Produktstrukturen. x Nach einer Reorganisation der Produktstruktur wurde die Anzahl der Konfigurationsmerkmale um 40% reduziert, die Anzahl der Materialien um ca. 30%. x Mit ca. 30 konfigurierbaren Materialien werden zurzeit mehr als 60% des Umsatzes realisiert. x Durch die Priorisierung und Fokussierung auf ertragreiche Produkte wurden die Durchlaufzeiten über die gesamte Logistikkette verkürzt – von der

Projektfazit

161

Beschaffung über die Fertigung bis zum Versand – und die Planungsgenauigkeit erhöht. Dies führte zu einer Reduktion der Bestände an Schnelldreherprodukten um 10% in den Niederlassungen bei gleichzeitiger Erhöhung der Lieferbereitschaft um bis zu 50%.

11 Optimierung der Produktentwicklung bei einem Maschinenbauer

Diese Fallstudie berichtet von der PLM-Einführung und Prozessoptimierung bei einem Maschinenbauer, der mit mehr als 1500 Mitarbeitern in Deutschland und mehr als 3700 Mitarbeitern weltweit einen Umsatz von mehr als 500 Mio. € erwirtschaftet. Im Fokus des Projektes stand die Verringerung der Störfaktoren in Zusammenarbeit der Produktentwicklung mit den Kernprozessen Produktionsplanung und Produktion sowie Beschaffungsplanung und Beschaffung. 100 Anwender nutzen direkt die implementierten SAP-PLM-Funktionen, weitere 150 Mitarbeiter aus den Prozessen Fertigungsplanung, Montagesteuerung und Zentraleinkauf werden durch das System indirekt unterstützt.

11.1 Ausgangssituation Die ausgelieferten Anlagen weisen eine einheitliche Verfahrenstechnik auf und sind nach funktionalen Gesichtspunkten in typisierte Maschinen gegliedert. Die Anlagen werden in mehreren Leistungsstufen und in unterschiedlichen Ausstattungsvarianten angeboten. In Abhängigkeit von der Ausprägung des mit den Anlagen zu produzierenden Endprodukts entstehen zwangsläufig Varianzen, die nahezu alle Funktionsbaugruppen der Maschine betreffen. Zusätzlich werden auftragsspezifisch konstruktive Anpassungen nach Kundenspezifikation vorgenommen. Der Anteil der variablen Teile in einer Maschine entspricht etwa 60%, wobei 20% allein von den Eigenschaften des zu produzierenden Endprodukts abhängen. Die vorliegende Prozesslandschaft gliedert sich in auftragsspezifische, auftragsübergreifende und auftragsunabhängige Prozesse. Auftragsspezifisch arbeiten die Auftragsklärung, ein Teil der Konstruktion/Entwicklung, die Montage und die Auftragsabwicklung. In Programmplanung, Produktionsplanung, Fertigung, Einkauf und Bevorratung laufen die Anforderungen aus allen Aufträgen zusammen. x Grundlagenentwicklung Die Grundlagenentwicklung, inklusive der Umsetzung der Ergebnisse in das aktuelle Maschinenprogramm, erfolgt im Regelfall auftragsunabhängig. Für die Grundlagenforschung ist eine separate Abteilung zuständig, die Umsetzung der Ergebnisse erfolgt durch die Konstruktion. Nach erfolgreicher Erprobung werden die Neuerungen in das Standardprogramm aufgenommen. Die notwendigen Anpassungen an den Produktstammdaten führen dabei

164

Optimierung der Produktentwicklung bei einem Maschinenbauer

Programmplanung

Einkauf

auftragsübergreifend

auftragsübergreifend Produktionsplanung

Fertigung

Bevorratung

auftragsübergreifend

auftragsübergreifend

auftragsübergreifend

auftragsübergreifend

Auftragsklärung

Konstruktion Entwicklung

Montage

Auftragsabwicklung

auftragsspezifisch

auftragsspezifisch

auftragsspezifisch

auftragsspezifisch

Grundlagenentwicklung

Abb. 84. Prozesslandschaft Anlagengeschäft

teilweise zu – aus technischer Sicht unnötigen – Varianten, da durch das Auftragsmanagement technisch identische Maschinen vor und nach dem Änderungstermin aufgelegt werden. Die eigentlich als Änderung durchführbare Modernisierung wird damit zu einer zusätzlichen Produktvariante, da sie parallel zu der vorherigen Ausführung im System geführt werden muss. x Programmplanung Im Rahmen der Programmplanung werden unter Betrachtung vorhandener und erwarteter Aufträge auf Basis des Maschinentyps Teileumfänge zu rationell zu fertigenden Losgrößen zusammengefasst und durch die Produktionsplanung vordisponiert. Die so erzeugten Bedarfe laufen entsprechend der Planung in den Beschaffungs- und den Fertigungsprozess ein und führen zur Bevorratung von Baugruppen und Teilen. Aus jedem Auftrag ergeben sich abhängig von der Maschinengrundvariante und von Vorstellungen des Kunden spezielle Anforderungen, die in der Umsetzung innerhalb eines meist sehr engen Zeitrahmens zur Entwicklung von individuellen Sonderlösungen führen. Die entstehenden Produktvarianzen haben zur Folge, dass die geplanten Losgrößen gesplittet und die Umfänge in Einzel- bzw. Kleinstserien aufgelegt werden müssen. Teile, die bereits in Bevorratung sind, müssen mit hohem Kostenaufwand außerplanmäßig nachgearbeitet werden. Die dem Angebot zugrunde liegende Vorkalkulation auf Basis der Planung weicht dadurch oftmals entscheidend von den Erzeugungskosten ab. x Auftragsklärung Für die Auftragsklärung ist der Vertrieb verantwortlich, der in technischen Fragen durch spezielle Mitarbeiter der Konstruktion unterstützt wird. Diese Abstimmungsvorgänge führen aufgrund der dreistufigen Kommunikation Kunde – Vertrieb – Technik zu langwierigen und fehlerbehafteten Abstimmungsprozessen.

Ziele des PLM-Einsatzes

165

x Konstruktion/Entwicklung Die Verantwortung für die notwendigen konstruktiven Anpassungen liegt bei den für die Bearbeitung eines Funktionsmoduls spezialisierten Fachabteilungen. Diese Abteilungen sind gleichfalls für die Umsetzung der Neuerungen aus der Grundlagenentwicklung zuständig. Die Einarbeitung von Modernisierungsmaßnahmen erfolgt oftmals im Rahmen der auftragsspezifischen Anpassungen. Die Konstruktion der mechanischen und elektrischen Baugruppen und die Erstellung der technischen Dokumentation erfolgt überwiegend CADgestützt. Fertigungsunterlagen und Dokumentation werden in einer jeweils eigenen Datenbankumgebung (PDM-System) verwaltet. Die Produktstruktur ist für die Bearbeitung von Konstruktionsaufgaben „am Brett“ ausgelegt. Unterschiedliche Ausführungen einer Baugruppe werden als Varianten geführt. Gleichteile in den Varianten sind nicht durchgehend als solche gekennzeichnet und sind innerhalb der kontinuierlich wachsenden Anzahl ähnlicher Baugruppen nur schwer auszumachen. x Stammdaten / Produktdokumentation Die Stammdatenerfassung erfolgt durch eine zentrale Stelle, die von den Konstruktionsabteilungen in Papierform mit den erforderlichen Informationen versorgt wird. Diese Funktion („Normenstelle“) ist gleichermaßen für die Kontrolle der Fertigungsunterlagen, deren Freigabe zur Veröffentlichung und für die Verwaltung von Zukaufteilen zuständig. Die Fertigungsunterlagen der Mechanik werden in Form von Microfichen archiviert und per Hauspost an die nutzenden Stellen verteilt. Die Produktion arbeitet ausschließlich mit den so archivierten Fertigungsunterlagen. In der Konstruktion wird überwiegend das CAD-Archiv genutzt. Die Produktdokumentation wird in Form von bildhaften Ersatzteilkatalogen aus Einzelteilzeichnungen aufgebaut. Es existiert keine zentrale Vorgabe für die Erstellung und Verwaltung von Konstruktions-/Entwurfszeichnungen.

11.2 Ziele des PLM-Einsatzes Nach der länger zurückliegenden Einführung des SAP R/3 mit den Modulen FI (Finance), CO (Controlling), MM (Materialmanagement), PP (Produktionsplanung) sowie SD (Sales and Delivery) im SAP Release 3.0f wird ein Projekt zur Umstellung auf das aktuelle SAP Release gestartet. Neben der technischen Umstellung soll in diesem Projekt die Verzahnung der Produktentwicklung mit den Prozessen Produktion / Produktionsplanung und Beschaffung / Beschaffungsplanung optimiert werden. Als Projektziele werden definiert:

166

Optimierung der Produktentwicklung bei einem Maschinenbauer

Verringerung des Klärungs- und Entwicklungsaufwands in der Konstruktion x Anpassung der Baugruppenstruktur an die veränderten operativen Belange durch den Einsatz von CAD-Systemen x Reduzierung der Baugruppen auf die ‚lebenden’ Varianten x Vermehrter Einsatz von Wiederholteilen Erhöhung der Planungssicherheit x Reduzierung von Änderungen an laufenden Aufträgen und bereits disponierten Komponenten x Transparente Kennzeichnung von vorzuplanenden und vorplanbaren Teilen x Optimierung der Auslastung von Montage und Fertigung durch vorgezogene Herstellung und Bevorratung von Standardteilen x Reduzierung der Fertigungs- und Beschaffungskosten durch Bündelung von Aufträgen Verringerung der Auftragsdurchlaufzeit x Der Prozess der Auftragsklärung soll beschleunigt werden, um notwendige Anpassungen an bestehenden Konstruktionen und notwendige Entwicklungen früher bestimmen zu können x Die Disposition soll beschleunigt werden um die Vorlaufzeiten der Fertigung zu maximieren x Die Bereitstellungszeit für aktuelle Fertigungsunterlagen soll reduziert werden x Durch Bevorratung von Standard-Baugruppen und Fertigungsteilen wird der Umfang der auftragsabhängigen Komponenten auf das technisch notwendige Maß reduziert

11.3 Projektvorgehen und Projektorganisation Das Projekt wird in drei sequentiellen Phasen durchgeführt, einer Konzeptphase, einer Detaillierungsphase und einer Implementierungsphase. In der Konzeptphase werden zunächst auf fachlicher Ebene die Prozesse abgegrenzt und analysiert und die Kernpunkte für eine Optimierung fixiert. Auf dieser Basis werden die Aufgabenpakete von den einzelnen Prozessteams formuliert und durch das Lenkungsteam abgeglichen. Ergeben sich übergreifende Aufgabenstellungen, so werden diese prozessteamübergreifenden Arbeitsgruppen übergeben. Die Detaillierungsphase wird bestimmt durch die Arbeit der Prozessteams und der Arbeitsgruppen. Es werden Lösungen in Form von Sollkonzepten fixiert und

Projektvorgehen und Projektorganisation

167

auf Machbarkeit in einem Testsystem untersucht. Das System wird in dieser Phase mit manuell eingestellten Testdaten betrieben. Im Rahmen der Implementierungsphase wird in einem Qualitätssicherungssystem durch Integrationstests das korrekte Zusammenspiel der einzelnen Funktionen verifiziert. Dies erfolgt unter Einbeziehung von Key Usern aus den Fachabteilungen, die im Rahmen der Tests ihre alltäglichen Arbeitsabläufe auf dem System abwickeln. Es werden mit fortschreitender Projektdauer auch Massendaten herangezogen. Um eine praxisnahe Vorgehensweise im Projekt zu erreichen, wird eine prozessorientierte Projektorganisation mit vier Prozessteams eingerichtet: Prozessteam Entwicklung / Prozessteam Fertigung / Prozessteam Planung / Prozessteam Beschaffung. Die Projektleitung und Steuerung erfolgt durch ein übergreifendes Lenkungsgremium aus den Leitern der Prozessteams und dem Projektverantwortlichen. Zur Klärung der Machbarkeit und zur Lösung systemspezifischer Fragen steht den Prozessteams eine Gruppe von Beratern zur Verfügung, die in Umfang und Besetzung kontinuierlich den Anforderungen des Projektes angepasst wird. Für die Bearbeitung der prozessübergreifenden Themen Produktstruktur, Änderungsdienst und Variantenmanagement werden aus den Mitarbeitern der Prozessteams Arbeitsgruppen gebildet. zentrale System -beratung

Lenkungs -gremium

Prozessteam Entwicklung

Prozessteam Beschaffung

MA Entwicklung - E

Prozessteam Planung

Prozessteam Fertigung

Arbeitsgruppe Produktstruktur

MA Disposition

MA Entwicklung - M

MA oper. Einkauf

MA Vorplanung

MA Arbeitsvorber.

Arbeitsgruppe Änderungsdienst

MA Entwicklung - M

MA Zentraleinkauf

MA Feinplanung

MA Fertigungsst...

Arbeitsgruppe Var.Management

MA Software-Entw.

MA Disposition

MA Vorplanung

MA Disposition

MA Grundlagenentw.

MA oper. Einkauf

MA Vorplanung

MA Feinplanung

MA Normung

Abb. 85. Auszug aus der Projektstruktur

168

Optimierung der Produktentwicklung bei einem Maschinenbauer

11.4 Ergebnisse der Konzeptionsphase Im Rahmen der Konzeptphase werden schwerpunktmäßig bereits abgewickelte Aufträge betrachtet und die dabei aufgetretenen Probleme analysiert. Es werden folgende Aufgabenpakete für die prozessorientierten Teilprojekte identifiziert: x Prozessteam Fertigung: Die terminliche Steuerung der Fertigung bzw. Beschaffung von Einzelkomponenten über die Baugruppenstruktur mittels statischer Wiederbeschaffungszeiten über den Kundenauftrag ist unzureichend. Es soll eine flexiblere, auftragsspezifisch terminierbare Methode erarbeitet werden. x Prozessteam Beschaffung: Wegen zum Teil widersprüchlichen Zielsetzungen und Maßnahmen des Zentraleinkaufs und der Entwicklung sollen Teilespektren definiert werden, für die ein zentralisierter Einkauf mittels Kontrakten und fixen Kontingenten lohnt. x Prozessteam Planung: Es soll eine Identifizierung von Teilespektren erfolgen, für die eine Vorplanung auf Basis von Aufträgen der vergangenen 5 Jahre lohnt und Strategien zur Vorplanung erarbeitet werden. x Prozessteam Entwicklung: Es soll der vermehrte Einsatz von Wiederholteilen ermöglicht werden sowie ein organisatorisches Konzept für eine beschleunigte Datenpflege für Konstruktionsteile und Baugruppen sowie für Norm- und Kaufteile definiert werden. Neben diesen prozessspezifischen Aufgaben werden folgende zentrale Herausforderungen erkannt und an die jeweilige Arbeitsgruppe übergeben: x Arbeitsgruppe „Produktstruktur“: Die bestehende Baugruppenstruktur ist nur für Experten zu durchschauen. Neue Funktionen sowie modernisierte Baugruppen sind überwiegend durch parallel geführte Varianten abgebildet, wodurch bei der Vorplanung eine Vielzahl alternativer Baugruppen zu betrachten ist. Die in den Stücklisten abgebildete Struktur ist auf die Bedürfnisse einer auftragsspezifischen Montage ausgerichtet und gliedert die Maschine nach Bereitstellungsgesichtspunkten. Eine Bevorratung neutraler Baugruppen ist auf dieser Basis nicht möglich. Der Vertrieb kann bei Auftragserstellung nicht erkennen, in welchem Rahmen Neuentwicklungen notwendig werden und welche Ausführungen der Maschine bereits entwickelt wurden. Durch die Neuordnung der Produktstruktur sollen die Anforderungen der logistischen Prozesse besser berücksichtigt werden. Der vorherrschende für alle Bauteilgruppen identische Aufbau soll hinterfragt werden. x Arbeitsgruppe „Änderungsdienst“: Es wird nicht unterschieden zwischen auftragsbedingten Änderungen und Modernisierungen auf Basis der Grundlagenentwicklung. Änderungen werden nach operativen Gesichtspunkten

Komponenten der PLM-Lösung

169

der jeweils ausführenden Abteilungen eingesteuert. Die Abstimmung zwischen den unterschiedlichen Unternehmensbereichen ist zeitaufwändig und fehlerbehaftet. Es ist ein durchgängiges Konzept zur Übernahme von Modernisierungsmaßnamen unter Berücksichtigung bereits laufender Beschaffung und disponierten Aufträgen zu erarbeiten. x Arbeitsgruppe „Variantenmanagement“: Einzelanfertigungen zur Erfüllung spezieller Kundenwünsche sind nicht von Standardbaugruppen zu unterscheiden. Die Arbeitsgruppe erhält den Auftrag, Möglichkeiten zur Kennzeichnung eines Standards aufzuzeigen, mit dem der größte Teil der vom Kunden gestellten Anforderungen abgedeckt werden kann.

11.5 Komponenten der PLM-Lösung Zur Umsetzung der geschilderten Anforderungen wurden folgende Lösungsblöcke realisiert: 11.5.1 Produktstruktur Um die aus der fehlenden systematischen Abbildung von Varianten resultierenden Probleme zu überwinden wird die Produktstruktur auf eine Maximalstückliste je Maschinentyp umgestellt. In einer Richtlinie für die Anlage neuer Produktstrukturen wird vereinbart, welche Produktelemente innerhalb dieser Gesamtstruktur in separaten Stücklistenstufen abzubilden sind und welche in Form einer Maximalstückliste angelegt werden. Darüber hinaus wird dort der zweckmäßige Einsatz von Materialvarianten, Auswahlpositionen, Klassenposition und konfigurierbarem Material beschrieben. Mit dieser Regelung wird von einer einheitlichen Produktstruktur abgewichen, bei der alle Baugruppen nach identischem Muster aufgebaut sind. Die angestrebte Produktstruktur soll vielmehr die spätere logistische Abwicklung berücksichtigen. Der dadurch entstehende Klärungsaufwand im Rahmen der Konstruktion wird in Kauf genommen, da sich die nachfolgenden Prozesse auf Basis einer sauberen Stammdatenbasis wesentlich schneller und fehlerfreier abwickeln lassen. Als zentrale Maßnahme wird die flachere Gestaltung der gesamten Produktstruktur beschlossen. Beziehungen zwischen einzelnen Baugruppen, wie zum Beispiel die Kombination einer bestimmten Trommelbaugruppe mit einer Antriebseinheit, werden im Beziehungswissen abgelegt und sollen nicht mehr über eine Stücklistenstruktur abgebildet werden. Baugruppen, die nicht vorgeplant werden und keine weiteren variablen Strukturen beinhalten, wie zum Beispiel Verschutzungen, werden ihrer Funktion nach in einer Maximalstückliste zusammengefasst. Baugruppen, die für eine Vorplanung bzw. Bevorratung in Frage kommen, werden als Materialvariante geführt. Durch die Konstruktion wird dazu die neutrale

170

Optimierung der Produktentwicklung bei einem Maschinenbauer

Variante erzeugt. Im weiteren Ablauf werden durch die Planung spezifische Materialvarianten ergänzt. Die Baugruppenstruktur ist für dieses Teilespektrum so zu gestalten, dass diese keine untergeordneten Strukturen mit weiteren vorzuplanenden Teilen enthalten. 11.5.2 Klassifizierung Um die Suche nach bereits vorhandenen Konstruktions- und Kaufteilen zu erleichtern wird die SAP-Klassifizierung konsequent genutzt. Diese Maßnahme verhindert, dass identische bzw. nahezu identische Teile wiederholt beschafft oder konstruiert werden. Der Aufbau der Klassen für die Normteile erfolgt nach Vorlage der bestehenden Werksnorm, als eine Kombination von bildhaften Darstellungen und zugeordneten Maßtabellen. Die Maßtabellen werden als Merkmalswerte eingestellt. Zur Visualisierung der jeweils zu einer Klasse gehörenden technischen Darstellungen wird das SAP-Dokumentenverwaltungssystem genutzt. Das Klassensystem wird durch eine zentrale Arbeitsgruppe verwaltet, um die dauerhafte Konsistenz zu sichern. Erweiterungen oder Änderungen an der Klassenstruktur werden durch ein Genehmigungsverfahren gewährleistet. Die Materialnummern der klassifizierten Normteile werden, soweit dort vorhanden, an den Cadenas-Normteilepool im CAD-Umfeld übertragen, so dass ein im SAP gefundenes Normteil über die Materialnummer in der CAD-Umgebung gefunden werden kann. Umgekehrt ist der im SAP implementierte Stand an Normteilen bei der Suche im CAD direkt erkennbar, so dass hier im Zweifel ein bereits vorhandenes Normteil eingesetzt werden kann. 11.5.3 Änderungsdienst Um Änderungen an bestehenden Baugruppen zu terminieren und kontrolliert in den Produktionsprozess einzusteuern, wird ein Änderungsdienst eingeführt. Für Modernisierungs- oder Optimierungsmaßnahmen und nicht auftragsbezogene Änderungen an bestehenden Baugruppen werden feste Änderungszyklen jeweils zum Quartal des Jahres vereinbart. Durch diese Maßnahme ist es dem Auftragsmanagement möglich, Aufträge gezielt zum alten oder zum neuen Stand der Entwicklung zu terminieren. Die zu diesem Zweck anzulegenden Änderungsnummern werden als Änderungspakete in einer Änderungshierarchie verwaltet. Auf Anforderung werden Änderungsnummern zentral durch die Disposition erzeugt und nach abgeschlossener Bearbeitung gesammelt durch diese freigegeben. Auftragsbezogene Änderungen werden nicht in Hierarchien verwaltet, hier kommen freie Änderungsstammsätze zum Einsatz. Auch diese Nummern werden zentral durch die Disposition vergeben und nach Abschluss der Bearbeitung durch die Konstruktion gegen weitere Nutzung gesperrt.

Projektfazit

171

11.5.4 Variantenkonfiguration Das Ziel des Einsatzes der Variantenkonfiguration ist die Beschleunigung und Automatisierung der Disposition. Die Auftragsstückliste wird ergebnisorientiert generiert, um Probleme mit nachfolgenden Änderungen innerhalb der teilweise langen Auftragsdurchlaufzeiten zu vermeiden. Es wird eine zweistufige Merkmalsbewertung durchgeführt: Der Vertrieb bewertet nach Kundenspezifikation im Kundenauftrag und die Disposition ergänzt die technisch geprägten Merkmalsbewertungen. Im Ergebnis wird eine Auftragsstückliste generiert, die es ermöglicht, nachfolgende Änderungen innerhalb der teilweise langen Auftragsdurchlaufzeiten auszuführen. Die Pflege der Konfigurationsprofile und des Beziehungswissens erfolgt zentral durch erfahrene Mitarbeiter der Disposition. 11.5.5 Projektsteuerung Zur Fertigungs- und Montagesteuerung wird das Projektsystem eingesetzt. Die Terminsteuerung erfolgt dabei über Netzpläne, die in die Konfiguration eingebunden sind. Langläufer werden speziellen Netzplanvorgängen zugeordnet und so getrennt von der zugehörigen Baugruppe disponiert. Die dafür notwendige Pflege von Bezugsorten in der Stückliste wird nach Fertigstellung der Stückliste in der Konstruktion durch die Disposition vorgenommen. Da auch die Materialverfügbarkeit über den Netzplan geprüft werden soll, entstehen zusätzliche Anforderungen an die Gestaltung der Produktstruktur.

11.6 Projektfazit Zusammenfassend konnten durch das Projekt folgende Ziele erreicht werden: x Verringerung des Klärungs- und Entwicklungsaufwands in der Konstruktion Durch die Nutzung des Klassifizierungssystems für Normteile, den Aufbau eines Klassenbaums und die durchgängige Umsetzung der Klassifizierung durch die Normstelle wird der Aufwand zum Auffinden bereits bekannter Normteile erheblich reduziert. Es werden insgesamt weniger neue Kaufteile benötigt. Durch Anbindung der Cadenas-Datenbank mit den Normteilen an SAP steht der Normteilfundus der Entwicklung direkt in ihrer Arbeitumgebung zur Verfügung. Durch die im SAP abgebildete Vernetzung von Engineering, Fertigungssteuerung und Programmplanung können Auswirkungen von Änderungen besser abgeschätzt, im Vorwege abgestimmt und mittels Änderungsdienst sauber terminiert in den Produktionsablauf eingesteuert werden und verursachen einen erheblichen Rückgang der erforderlichen Nacharbeiten im Rahmen der Auftragsabwicklung. Die neu geordnete Baugruppenstruktur verringert insgesamt den Aufwand im Änderungsdienst, da die Anzahl übergeordneter und damit ebenfalls von einer Änderung betroffenen Baugruppen sinkt.

172

Optimierung der Produktentwicklung bei einem Maschinenbauer

x Erhöhung der Planungssicherheit Durch die Implementierung eins Änderungsprozesses mit Nutzung von Änderungszyklen mit fixen Terminen für die Einsteuerung von Änderungen zum Zwecke der Modernisierung und Optimierung. Wichtig ist hier vor allem, dass im Prozess Änderungen begonnener Fertigungsaufträge nur durch die Baugruppendisposition erfolgen. Durch den Einsatz der Materialvarianten können konfigurierbare Baugruppen in den überwiegend zum Einsatz kommenden Ausführungen bevorratet werden, ohne die Variabilität für spezifische Anforderungen einzuschränken. Einen weiteren Beitrag zur besseren Planung leistet die Nutzung des Projektsystems für die Fertigungssteuerung, durch Pflege von Bezugsorten kann der erforderliche Beschaffungstermin exakter festgelegt werden. x Verringerung der Auftragsdurchlaufzeit Wird einerseits durch organisatorische Maßnahmen erreicht (Stammdatenanlage erfolgt zeitnah durch die Konstruktion direkt im SAP, Strukturierte Pflegeprozesse für Materialstämme mit Pflege durch erfahrene User, Abwicklung von Normteilanforderungen in zentraler Verantwortung), andererseits durch den Einsatz der Variantenkonfiguration im Rahmen der Auftragsklärung. Wesentliche Details der Lösung sind die eingesetzte mehrstufige Bewertung durch Vertrieb und Technik, die Definition von Maximalstücklisten je Maschinentyp und der gezielte, im Rahmen einer Richtlinie fixierte Einsatz von Konfigurationsstrategien in der Produktstruktur. x Risiken im Rahmen der Realisierung Die Neuordnung der Produktstruktur und die vermehrt bereits bei der Datenanlage zu berücksichtigenden Einflüsse von Programm- und Produktionsplanung erfordern ein Umdenken im Bereich der Konstruktion. Die Umsetzung dieser Maßnahmen in der täglichen Arbeit verlief nicht ohne Diskussionen und erforderte die rückhaltlose Unterstützung durch die Fachvorgesetzten. x Potenziale nach Projektabschluss Offen blieb im Projekt die Neustrukturierung der Dokumentation für den Kunden. Die zur jeweiligen Maschine ausgelieferten Handbücher werden baugruppenübergreifend nach Funktionen zusammengestellt (z. B. Druckluftsystem, Hydrauliksystem) und lassen sich daher nicht mit denselben Methoden konfigurieren wie Maschinenbauteile. In diesem Umfeld wird bereits mit einem Baukastensystem gearbeitet, die systemgestützte Kombination der Bausteine zu einem Handbuch konnte aber nicht mit vertretbarem Aufwand realisiert werden.

12 PLM bei BRP-Rotax GmbH & Co. KG Harald Okruch und Claudia Herzog

In dieser Fallstudie beschreiben die Autoren der BRP-Rotax GmbH & Co. KG mit Hauptsitz in Gunskirchen (Österreich), welche Ziele mit dem PLM-Projekt von Mitte 2001 bis 2004 verfolgt wurden. Dabei schildern sie sowohl die Ausgangssituation im Unternehmen als auch die Einteilung des PLM-Gesamtprojektes in thematisch zusammengehörende Teilprojekte, deren Umsetzung und die erzielten Ergebnisse. Die Lösung integriert ca. 300 interne und 50 externe Anwender.

12.1 Das Unternehmen BRP-Rotax, ein Unternehmen der Bombardier Recreational Products Inc., ist internationaler Marktführer in der Entwicklung und Herstellung von modernen 2-Taktund 4-Takt-Motoren für motorisierte Freizeitgeräte wie Ski-Doo und LynxSchneeschlitten, Bombardier-ATV-Geländefahrzeuge (All Terrain Vehicles oder Quads), Sea-Doo-Aufsitzboote und Sportboote, Motorscooter, Motorräder, Karts sowie Leicht- und Ultraleichtflugzeuge.

Abb. 86. Produkte von BRP-Rotax

174

PLM bei BRP-Rotax GmbH & Co. KG

Langjährige Erfahrung, kombiniert mit einem ausgezeichneten Ruf, haben BRPRotax zu einem der renommiertesten und erfahrensten Motorenhersteller außerhalb der Automobilbranche gemacht. Etwa 35 Prozent der über 215 000 Motoren, die jährlich produziert werden, verkauft die BRP-Tochter an Kunden außerhalb des Konzerns. Im letzten Geschäftsjahr erzielte BRP-Rotax mit 1250 Mitarbeitern einen Umsatz von 324 Millionen Euro. Weitere Informationen unter: http://www.rotax.com/

12.2 Ausgangssituation und Vision Nach Einführung einer standardisierten 3D-Modellierung und dem Aufbau von durchgängigen CAx-Prozessketten im Rahmen eines Vorgängerprojektes von 1998 bis 2001 entstand sehr rasch eine große Menge von Daten, deren Aktualität, Bereitstellung und Konsistenz zu SAP bzgl. Version und Status sicherzustellen war. Ein manuelles Datenmanagement sowie die optimale Bereitstellung aller relevanten Zeichnungen, 3D-Modelle und sonstigen Produktinformationen für alle an der Produktentstehung beteiligen Stellen und Personen konnte nicht mehr stabil und sicher gewährleistet werden. Mit der Vision Product Lifecycle Management sahen wir die effiziente Möglichkeit, alle im Produktlebenszyklus entstehenden Daten, weit über die traditionellen PDM-Funktionen hinaus, optimal verwalten, automatisch steuern und in der benötigten Form und Aktualität bereitstellen zu können. Die PLM-Vision von BRP-Rotax als Zusammenfassung der Prozess- und Informationsabläufe im gesamten Produktentstehungsprozess lässt sich zusammenfassen in dem 4R-Prinzip: „die richtige Information, zur richtigen Zeit, in der richtigen Qualität, am richtigen Ort“ mit bestmöglicher Einbindung von Kunden und Lieferanten. Nachdem sich das BRP-Rotax Management 2000 sehr intensiv mit einem Projekt zur Neuausrichtung der Firmenkultur, dem „Rotax-Quality-Production-System“, befasst hatte, wurde die Zielausrichtung von PLM, nämlich alle Lebensphasen der Produktentstehung aus einer gesamtheitlichen Perspektive bestmöglich zu unterstützen, sehr schnell erkannt, so dass ein PLM-Implementierungsprojekt initiiert wurde.

Abb. 87. Prozesslandkarte und IT-Unterstützung in den verschiedenen Prozessen

Ziele des PLM-Einsatzes

175

12.3 Ziele des PLM-Einsatzes Standardisierung des Produkt- und Betriebsmitteldatenmanagements x Standardisierung der Datenstruktur (Namenskonventionen usw.) x Neugestaltung der Freigabe- und Revisionsverwaltung x Absicherung der Datenkonsistenz zwischen CAD und SAP x Harmonisierung der Metadaten x Bereitstellung der Geometriedaten intern als auch für Konzernpartner und Lieferanten über SAP x Optimierung des Berechtigungskonzeptes für internen und externen Zeichnungszugriff über SAP x Workflowgesteuerte Zeichnungsfreigabeprüfung x Verknüpfung der Produkt- und Betriebsmitteldaten zur Verwendungsnachweisführung x Interne Kundeneinbindung durch Collaboration & Redlining Tools (Frontloading) x Altdatenintegration SAP integriertes Ausgabemanagement x Umstellung zum digitalen Masterdokument für Zeichnungen x Dezentrale Zeichnungsausgabe im Pull-System direkt aus SAP heraus x Automatische Protokollierung der Ausgabe- und Verteilerattribute x Automatische Identifikationsstempelung bei der Ausgabe x Ausgabefunktion für Sammelaufträge (Stücklisten, KPL-Zeichnungen) x Workflowsteuerung für Bereitstellungsinformationen (z. B. Zeichnungsfreigabe) B2B-Lieferantenportal x Volle SAP-Integration über NetWeaver-Technologie x Massive Reduktion der Prozesskosten und Reaktionszeiten x Bedeutende Verbesserung der Prozessqualität x Kostengünstige Anschlusslösung für Lieferanten x Automatische Datenpaketierung und -komprimierung (ZIP) x Automatische Protokollierung der Lieferanten-Downloads x Eskalationsmeldung bei nicht erfolgtem Download x Eindeutige Visualisierung des Download-Status

176

PLM bei BRP-Rotax GmbH & Co. KG

x Alte Versionen sind vom Lieferanten jederzeit abrufbar x Parallele Verwendung auch für Lieferplaneinteilungen und Feinabrufe

12.4 Projektvorgehen und Projektorganisation Release 1 Produktdatenmanagement

Release 2 Betriebsmitteldatenmanagement

Release 3 Integriertes Ausgabemanagement

Release 4 B2B-Portal

Release 5 Stabilisierung & Optimierungen

Aug Sep Oct

Nov Dec Jan

07/01

Feb Mar Apr May

01/02

Jun

Jul

Aug Sep Oct

07/02

Nov Dec Jan

Feb Mar

01/03

Apr May Jun

Jul

Aug Sep Oct

07/03

Nov Dec Jan

Feb Mar Apr May

01/04

Jun

Jul

07/04

Abb. 88. Projektverlauf / Umsetzungsphasen

Das Projekt wurde in mehrere Phasen (Releases) funktional gegliedert, folgende Meilensteine zeigen den Projektverlauf: 03 / 2000 10 / 2000 07 / 2001 09 / 2001 12 / 2001 01 / 2002 05 / 2002 09 / 2002 11 / 2002 12 / 2002 01 / 2003 02 / 2003 03 / 2003 04 / 2003

PLM-Initialisierungs-Workshop SAP-Upgrade auf Version 4.6b, Entscheidung für mySAP PLM Kick-Off für PLM-Projekt Scoping: Projektinhalte definiert Implementierungs- und Releaseplanung abgeschlossen Systemarchitektur definiert SAP-Schnittstelle zu Pro/Engineering + Pro/Intralink beauftragt Start der Modultests durch Kernteam Start des Prototypentests durch Start eines Piloten mit 7 Anwendern (Dauer 1 Woche) Start der Anwenderschulungen (ca. 1700 Std.) Roll-Out des Release 1 (Produktdatenmanagement) und KickOff für Release 2 (Betriebsmitteldatenmanagement) Kick-Off von Release 3 (Integriertes Ausgabemanagement) Altdatenintegration zu 90% abgeschlossen (ca. 1050 Std.)

Ergebnisse des Projektes

177

Abb. 89. Projektorganisation

08 / 2003 11 / 2003 02 / 2004 04 / 2004 07 / 2004

Kick-Off von Release 4 (B2B-Lieferantenportal) Roll-Out von Release 2 (Betriebsmitteldatenmanagement) Roll-Out von Release 3 (Integriertes Ausgabemanagement) Roll-Out von Release 4 (B2B-Lieferantenportal) Abschluss der Optimierungsaktivitäten; Projektabschluss

Abb. 89 zeigt die gewählte Projektorganisation. Insgesamt entstand im Projekt ein Schulungsaufwand von 3660 Trainingsstunden, es wurden 46 neue Leitfäden, Anweisungen und Trainingshandbücher erarbeitet.

12.5 Ergebnisse des Projektes Standardisierung der Prozesse x Automatisierung und Dokumentation der Arbeitsabläufe x Klare Zuordnung der Zuständigkeiten x Vermeidung von Medienbrüchen und Insellösungen

178

PLM bei BRP-Rotax GmbH & Co. KG

Verbesserte Datennutzung und -extraktion x eindeutige Daten- und Statusidentifikation x einfacher, schneller Zugriff und Visualisierung von Produkt- und Vorrichtungsdaten x konsistenter und sicherer Informationsfluss x Prozess-Monitoring Besseres Wissens- und Qualitätsmanagement x Detaillierte Produkt- und Prozessdokumentation x Fehlervermeidung durch eindeutige Datenidentifikation x digitale Bereitstellung von ergänzenden Engineering Informationen (Normen, Techn. Spezifikationen) Förderung der Kooperation x Zusammenarbeit der internen Prozesskette, Partner, Lieferanten und Kunden (B2B-Portal) Verkürzung der Produktentwicklungszeiten x kürzere Reaktionszeiten x weniger Iterationsschleifen x technische Basis für Frontloading

Abb. 90. 3D-CAD-Modell eines Motors: Ausgangspunkt für optimierte Datennutzung

Projekterfahrung und Ausblick

179

12.6 Projekterfahrung und Ausblick Auf die Qualifikation externer Projektberater wurde aufgrund schlechter Erfahrungen in der Vergangenheit besonderer Wert gelegt. Eine verantwortungsvolle und gewissenhafte Projektleitung ist ungemein wichtig. Die Erfolgsgarantie ist einzig und allein durch eine bestmögliche Einbeziehung, die Motivation und das Engagement aller Projektbeteiligten bzw. Mitarbeiter zu erzielen. Aufgrund der Notwendigkeit, unser Konfigurationsmanagement hinsichtlich neuer Bestimmungen im Air-Craft-Bereich zu überarbeiten, entschloss sich BRPRotax das Arbeitspaket „Änderungsmanagement“ aus dem PLM-Projektportfolio gemeinsam mit dem Konfigurationsmanagement in einem neuen Projekt namens „NPCM“ (New Product Change Management) abzuarbeiten. Dieses Projekt wurde im Mai 2004 gestartet und soll in einer zweijährigen Laufzeit über 2 Phasen abgearbeitet werden. Die Inhalte sind: Phase 1 (2004) x Ist-Analyse x Definition und Dokumentation des neuen Änderungs- und Konfigurationsmanagements x Aufbau von Phasenschema und Statusidentifikation zum Änderungsprozess x Verfügbarkeit erster Monitoring-Funktionen für Prozess- und Produktkosten x Migration des Änderungsantrages von Notes nach SAP x Nutzung des SAP-Konfigurationsmanagements x SAP-integrierte Datenverwaltung von Produktdokumenten über den gesamten Änderungsprozess Phase 2 (2005) x Fortsetzung des Prozess-Reengineering zur Umsetzung des Änderungsauftrages x Ausbau der Monitoring-Funktionen x Migration von weiteren Notes-Applikationen nach SAP x Integration des After-Sales-Bereichs x Integration der Vorrichtungs- und Werkzeugorganisation (Terminsynchronisation und Kostenmonitoring) x Integration von externen Partnern (Lieferanten, Kunden und Partner) Die Umsetzung des NPCM-Projektes strukturiert sich nach den Anforderungsperspektiven des Engineering Change Managements (ECM) und des Configuration Managements (CFM).

180

PLM bei BRP-Rotax GmbH & Co. KG

Die Ist-Analyse des Änderungsprozesses wurde mit der Prozessmodellierungssoftware ARIS von der IDS Scheer AG durchgeführt und zeigte die Komplexität des bisherigen Änderungsprozesses. Anfänglich überraschte uns die Prozesskomplexität von der Antragserstellung bis zur Umsetzung der Änderung und Verbau des geänderten Teils. Folglich wurde eine Prozessoptimierung als Ausgangspunkt für die Implementierung des neuen Änderungswesens durchgeführt. Getrieben u.a. durch die Vorgabe, die Durchlaufzeit massiv zu reduzieren, die Benutzerfreundlichkeit zu erhöhen und SAP als Systembasis zu verwenden, entschieden sich BRP-Rotax, den neuen Änderungsantrag ebenso über die NetWeaverTechnologieplattform abzubilden wie das vorher erwähnte B2B-Lieferantenportal. Zur Erfassung und weiteren Bearbeitung eines Änderungsantrages wurde das SAPObjekt Meldung benutzt. Zudem wurden Funktionen aus dem SAP-Projektsystem zur Terminsteuerung und Auswertung von Prozess- und Produktkosten in den Änderungsprozess eingearbeitet. Im CFM-Teilprojekt wurden unsere Anforderungen zur Abbildung von historien- bzw. zertifizierungspflichtigen Produkt- und Dokumentstrukturen sowie Prozessen realisiert. In der ersten Phase wird das Configuration-Management-Modul der SAP für einen neuen Flugmotor eingeführt, um hier Rückverfolgbarkeit der Fertigungsund Produktionsdaten in SAP zu gewährleisten. Über die Abbildung von Installationen wird der tatsächliche Produktstatus mit allen vernetzten Daten und Dokumenten abgebildet. In der gesamten Logistikkette werden Daten in Prüflosen den einzelnen Teilen hinterlegt und den physischen Teilen anhand von Scandaten mitgeliefert. In der Teilefertigung und im Wareneingang werden Scanbelege mit der Teile- und Prüflosnummer erstellt und als Etikettenausdruck auf den jeweiligen Verpackungseinheiten angebracht. Bei der Montage scannt der Mitarbeiter arbeitsplatzbezogen zur jeweiligen Motorserialnummer wiederum diese Daten ein und damit erfolgt die Datenübergabe an die Installation. Um diesen Prozess darstellen zu können, wurde ein Datenerfassungs- bzw. Montageerfassungssystem programmiert und die automatische Prüflosabwicklung in der Fertigungskette optimiert. Parallel zur Vorserienproduktion wird dieses Modul getestet und in Serie eingeführt. Des Weiteren wurde ein Installationsvergleich zur Darstellung der Unterschiede zwischen einzelnen Motoren programmiert, um Unterschiede einzelner Produkte leicht auswerten zu können und damit die Rückverfolgbarkeit zu garantieren. Nach erfolgreicher Produktivsetzung der ersten Schritte wird in der zweiten Phase an eine Umsetzung dieser Vorgehensweise für alle bereits in Serie befindlichen Flugmotoren in der Montage gedacht. Als weiterer Ausbauschritt ist auch eine Anbindung der Wartungsdaten der im Feld befindlichen Motoren geplant. Als Ziel muss gelten, zur jeweiligen Motornummer online über SAP die aktuelle Konfiguration abrufen zu können.

13 PLM bei der CARPIGIANI GROUP Andrea Cocchi und Alexander Schadenberger

Die Carpigiani Group aus Italien ist ein Maschinenbau-Unternehmen und Marktführer im Bereich Eismaschinen für Eis nach traditioneller Art, auch bekannt als „Eis nach italienischer Art“. Sie entwickelt und produziert an Standorten in Italien, Spanien und Nordamerika, in weiteren Ländern weltweit unterhält man Vertriebs- und Servicecenter. Die Notwendigkeit der Marktnähe erfordert die Globalisierung des Unternehmens und damit auch die weltweite Verfügbarkeit aktueller technischer Informationen. Aus diesem Grunde wurde im Rahmen eines PLM-Projektes insbesondere die CAD-Integration implementiert. In einem Folgeprojekt werden auf dieser Basis Prozesse für Engineering Collaboration eingeführt. In diesem PLM-Projekt sind etwa 30 CAD-Benutzer aus Entwicklung, Konstruktion und Fertigung sowie weitere PLM-Benutzer aus Einkauf, Qualitätssicherung und Service involviert.

13.1 Das Unternehmen Carpigiani (Bologna, www.carpigiani.com) ist ein Mitglied des Firmenverbundes Ali Group (Mailand; www.aligroup.it). Nach dem Zusammenschluss mit der Ali Group im Jahr 1989 hat das neu eingesetzte Management beschlossen, technologisch und organisatorisch zu wachsen. Der erste große Schritt dieses Wachstums war die Gründung der Carpigiani Group, angeführt durch Carpigiani, der zahlreiche andere Betriebe des Bereichs Eismaschinen angehören. Durch ein weit verbreitetes Vertriebsnetz (Direktvertrieb, angeschlossene Firmen, Niederlassung und Lizenznehmer) ist es der Carpigiani Group möglich, weltweit vor Ort präsent zu sein und in den meisten Ländern eine marktführende Position einzunehmen. Im Jahr 2004 hat Carpigiani ihre Präsenz in den nordamerikanischen Ländern durch den Aufkauf und die Eingliederung der Firma Electro Freeze (East Moline; Illinois – USA) wesentlich ausgebaut.

13.2 Ziele des PLM-Einsatzes Die Carpigiani Group hat die Probleme, die durch die verteilten Entwicklungsund Produktionsstandorte entstehen, erkannt und war vor allem nach dem Kauf des nordamerikanischen Standortes gezwungen zu handeln. Die bei Carpigiani eingeführten Prozesse der Produktentwicklung und Produktpflege waren im Hin-

182

PLM bei der CARPIGIANI GROUP

blick auf die Harmonisierung der verschiedenen Standorte nur noch schwer durchführbar. Es sollte eine Neuausrichtung erfolgen, die die Wiederverwendung von Teilen, das Verhindern von Mehrfachkonstruktionen und die bessere Auslastung der Entwicklungsabteilungen in den Mittelpunkt stellt. Ein Weg, die Synergien der globalen Produktentwicklung und die Zusammenführung von betriebswirtschaftlichen und konstruktionsbedingten Daten zu ermöglichen, war für die Carpigiani Group die Einführung des SAP PLM-Konzeptes. Darüber hinaus war es wichtig, die Prozesse von der ersten Skizze bis zum fertigen Produkt über alle Unternehmensbereiche optimal zu unterstützen und den Bruch der Datenflüsse zu beheben. Durch die PLM-Einführung sollten folgende Ziele erreicht werden: x Engere Verzahnung der Entwicklung mit den anderen Unternehmensbereichen x Globaler, kontrollierbarer Datenpool x Harmonisierung des Produktportfolios x Effizienteres Time-to-Market

13.3 Vorgehensweise im Projekt Das Projekt wurde im Frühjahr 2004 durch ein Kick-Off-Meeting gestartet, bei dem Carpigiani die Arbeitsweise mit SAP PLM und die sich ergebenden Möglichkeiten gezeigt wurden. Im Winter 2004 wurde der produktive Einsatz am Stammsitz der Firma Carpigiani gestartet. Die Anbindung der weiteren Standorte wird sukzessive im Laufe des Jahres 2005 erfolgen. Folgende Projektphasen wurden durchlaufen: x Verständnisphase: Am Anfang stand für alle Mitglieder des Projektes die Schaffung eines gemeinsamen Verständnisses der bisherigen Arbeitsweise und der sich ergebenden Möglichkeit des SAP PLM im Vordergrund. Zum einen musste Carpigiani einen detaillierten Einblick in die Arbeitsweise der Konstruktion (Konstruktion, Datenpflege, Archivierung, ...) gewähren, als auch die schon bekannten Probleme innerhalb der Organisation am Stammsitz und in der Zusammenarbeit der weltweit verteilten Entwicklungs- und Produktionsstandorte aufzeigen. Ergebnis war, dass bei Carpigiani klassisch mit auf Papier ausgedruckten Zeichnungen und manuell gepflegten Stücklisten gearbeitet wird. Die nativen CAD-Zeichnungen werden auf Fileservern in der Konstruktion abgelegt. Die Umsetzungspartner der SAP PLM-Einführung haben durch Demos, Gespräche und Best-Practice-Beispiele die Funktionen von SAP PLM und mögliche Szenarien erklärt. Erster Meilenstein nach dieser Projektphase war die Umsetzung eines exemplarischen Prototypen zur Feinabstimmung der Planungsphase.

Vorgehensweise im Projekt

183

x Planungsphase: Die während der Verständnisphase gemachten Erfahrungen und die sich daraus bei Carpigiani ergebenden Anforderungen wurden nochmals kritisch hinterfragt, auf Machbarkeit (technisch und prozessorientiert) geprüft und dokumentiert. Die Dokumentation hat die Anforderungen und notwendigen Änderungen im Prozess für alle Projektbeteiligten klar zusammengefasst und den Pfad zum weiteren Vorgehen vorgegeben. So sollten die Aktualisierung der Zeichnungskopfdaten und das Erstellen von Stücklisten weitestgehend automatisiert werden. Stücklisten können von jedem Konstrukteur direkt aus der CAD Applikation in mySAP PLM angelegt werden. Die Zeichnungskopfdaten in der CAD Applikation (Beschreibungen, Stati, …) können von jedem Konstrukteur mit den aktuellsten Daten direkt aus mySAP PLM befüllt werden. Meilenstein war hier die Dokumentation der neuen Prozesse und Planung der Umsetzungs- und Einführungsphase. x Umsetzungsphase: Die Umsetzung der in der Planungsphase getroffenen Entscheidungen wurde im Sommer und Herbst 2004 durch die an dem Projekt beteiligten Firmen in enger Abstimmung vorgenommen. Bei den Projektpartnern wurde eine klare Abgrenzung der Aufgaben mySAP PLM Realisierung / CAD Integration und CAD Applikation vorgenommen. Meilensteine waren die Installation von SAP PLM auf allen Systemen der Carpigiani Group innerhalb Europas und schließlich die Testinstallation der für Carpigiani angepassten Systeme. x Einführungsphase: Der Roll-Out wurde mit folgenden Inhalten vorgenommen: Installation der CAD-Integration auf allen CAD-Stationen, Administrationstrainings, SAP PLM-Schulung, Trainings für die Benutzer der angepassten CAD-Integration (vornehmlich Mitglieder der Konstruktionsabteilung). Dieser Roll-Out wurde im Winter 2004 / 2005 erfolgreich abgeschlossen. Durch frühzeitige Einbindung der Fachabteilungen in den ersten Phasen des Projektes gelang es, das Wissen über SAP PLM frühzeitig im Unternehmen zu streuen. Dadurch konnte die Dauer von Trainingsmaßnahmen und des Rollouts insgesamt ohne Qualitätseinbußen auf ein Minimum beschränkt werden. Die Projektmitarbeiter setzten sich aus den Verantwortlichen der Konstruktion und Organisation bei Carpigiani und den drei beteiligten Umsetzungspartnern zusammen. Die Umsetzungspartner hatten dabei jeweils eine ihrer Kernkompetenz entsprechende Aufgabe zu erfüllen. Im Einzelnen war dies: x die Betreuung der SAP-System durch die Firma SIDI-Società Italiana di Informatica SpA (Mailand), x die Betreuung der CAD-Systeme durch die Firma CDM Isigraf S.r.l. (Sorbolo) x und die Beratung und Umsetzung der CAD-Integration durch die StrategicEnterprise AG (Tübingen).

184

PLM bei der CARPIGIANI GROUP

13.4 Ergebnisse des Projektes Projektschwerpunkt lag auf dem Einsatz der SAP-Dokumentenverwaltung, integriert in die bei Carpigiani eingesetzten CAD-Werkzeuge. Hierzu wurde die vom Hersteller der CAD-Werkzeuge angebotene SAP PLM-Integration an die Bedürfnisse der Carpigiani Group angepasst, wobei auf höchstmögliche Releasesicherheit Wert gelegt wurde. CAD-Files werden an die Dokumentenverwaltung (DVS) übergeben, mit den Materialstammdaten automatisch verknüpft und klassifiziert. Carpigiani verwaltet innerhalb des SAP DVS die folgenden Daten: x 2D-Zeichnungen x 3D-Modelle x Abgeleitete 2D-Zeichnungen x Neutrale Formate (JPEG, TIF, PDF) x Dokumentationen der Entwicklung/Konstruktion Hardwareseitig konnte die bestehende SAP-Infrastruktur genutzt werden. Als Plattform für die Dokumentenspeicherung musste ein neuer Server installiert werden. Softwareseitig war die Anschaffung weiterer Lizenzen für die CADIntegrationen und die weiteren 3D-CAD-Arbeitsplätze notwendig. Als wesentliche Erkenntnis kann festgehalten werden, dass sich die oben beschriebene Vorgehensweise, vor allem eine ausführliche Verständnisphase, als sehr vorteilhaft erwiesen hat. Carpigiani konnte durch das sukzessive Einführen und Diskutieren der sich ergebenden Möglichkeiten sehr schnell und harmonisch die Vorteile eines SAP PLM für sich entdecken und diese in die bestehenden Prozesse optimal einpassen. Der sich durch die SAP PLM-Einführung ergebende hohe Grad an Automatisierung der Datenverwaltung und die Verfügbarkeit von wichtigen Daten der Entwicklung für die anderen Unternehmensbereiche/Standorte war ausschlaggebend für einige tief greifende Änderungen der Prozesse innerhalb der Carpigiani Group. Schon sehr früh war die größte Schwierigkeit innerhalb des Projektes die interkulturelle Zusammenarbeit. Dies lässt sich nicht nur an sprachlichen Aspekten sondern auch an den inhaltlich und fachlich unterschiedlichen Kompetenzen festmachen. Als nächster Schritt bei der mySAP PLM Einführung ist die Realisierung der cProjects Suite der SAP als Tool zur besseren Anbindung der Lieferanten vorgesehen.

14 Importance of Product Design and Data Exchange Standards in the Product Life Cycle Bruno Schilli und Ingo Kern

Die Autoren beschreiben in dieser Studie die Herausforderungen zur Einführung von Engineering Collaboration in einem global agierenden Unternehmen. ABB hat zu diesem Zweck mit VDO – Virtual Design Office – eine Projekt-Initiative gestartet. Hier werden nun die Ausgangssituation im Konzern, die im Projektverlauf erkannten Herausforderungen und Schwierigkeiten sowie die entwickelten Lösungsansätze erläutert.

14.1 Introduction Starting with ABB’s situation today as a global company, we will discuss the current status of collaborative engineering based on experience from various engineering projects, involving various cultures, systems and external suppliers. Further approaches to enable collaboration along the product life cycle include modularization and standardization of products, standardization of default product information and the use of standardized tools to support the design phase of products and their life cycle. ABB is one of the leading companies in power and automation technologies with a strong market position in its core businesses. With its headquarters in Zurich, ABB employs more than 110 thousand people in more than 100 countries. In automation technologies ABB offers a comprehensive line of base products, e.g. drives, motors, control hardware, instrumentation and robots as well as engineering services providing system solutions for industrial processes. ABB’s hardware, software and service technologies help customers to improve productivity, efficiency, safety, and quality in plant or process operation. In power technologies, ABB offers comprehensive products and engineering services for high and medium voltage applications, power and distribution transformers, as well as utility and power automation systems. ABB’s investment in research and development of products and services involves more than 6000 people, distributed worldwide across different countries and cultures. ABB’s situation is typical today for a global company, as we have globally distributed product development teams, geographic separation of design and manu-

186

Importance of Product Design and Data Exchange Standards

facturing, global supply chain management with local suppliers, local sales and service organizations which should be globally managed, and customer organizations, which are also globally distributed. In order to implement collaboration along the life cycle of our products, we have started various initiatives, all of which have one common vision: „All participants along the product value chain – customers, product developers, manufacturers, service technicians, and suppliers – must have the right information, at the right time, and in the right format and be able to act on it quickly” These initiatives are: x Use of collaboration tools in project management and engineering x Modularization and standardization of engineered products x Standardization of default product information x Use of standardized tools along the product life cycle

14.2 Status of Collaborative Engineering in the Power and Automation Industry Within the power and automation industry, project driven collaboration during product life cycle can be split into three basic blocks (see Fig. 91): x Collaboration for Design x Collaboration for Manufacturing x Collaboration for Service For each of these blocks the involved person groups are responsible for a deliverable which could be achieved either internally of externally. While within the concept and design phase the main deliverable is the description of the engineering result, requiring detailed description of all aspects of the product, we have a completely different scope of deliverable in the two other phases. We also have to keep in mind that 80% of product costs are committed during design phase The collaboration supply and manufacturing phase arranges the delivery and manufacture of products based on small amounts of information within a bill of material (BOM) of the product. Collaboration for service again requires a complete different set of information. Here we need information about status of individual machines or products from operations communicated over company borders. The amount of information is increasing dramatically over time; imagine an assembly line of gearboxes, where every 45 seconds a whole set of quality data for assembled parts has to be stored. Fundamentally a need for collaborative engineering results from geographical barriers between project members which requires a reduction in travelling time and travelling cost and improvement in the quality of communication. Collaborative engineering allows a multi-disciplinary approach to solve challenges quickly

Status of Collaborative Engineering in the Power and Automation Industry

187

Fig. 91. Collaboration during Product Life Cycle

and effectively and allows the development of better products through brainstorming for higher customer satisfaction. One of the main values to influence successful collaboration is communication. It has been evaluated in the past that about 40% of time spent in engineering is related to communication, where as 10% is dedicated to the design and analysis process it self (Shina et al., 1992). Considering that communication decreases in an office environment by 80% when team members are more then 50 m apart (Allen, 1987), effective collaboration methods and tools are increasing enormously in importance. One would think that collaborative engineering is state of the art if you regard the evolution of collaboration technologies in Fig. 92. However, despite the massive growth in technology, the real use of such in industrial companies is still low. In ABB we have invested a lot in office infrastructure which enables us to email, have online conferences, desk top sharing and setup of databases to store project information. We currently have 72 thousand Lotus Notes users, which allows us to send messages, create databases and team rooms for our projects and implement workflow management systems within our company. We also have Sametime and NetMeeting in use at each workplace, which allows us to chat, share screen and announcing and participation in collaboration meetings. Conferencing WebServices through Genesys counts 2200 users per month or 450 thousand minutes conferencing time, and video conference rooms have been installed in about 300 locations. The number of team rooms for project purposes is not recorded, but must be enormous. But real collaborative design in the sense of CAD data exchange is still a rare and reasons for that are various. Technical reasons are: x You need to distribute and install client software, which requires time and effort x There is no depth collaboration with your suppliers

188

Importance of Product Design and Data Exchange Standards Audio & Text

Video

Synchronization

Real-time

Virtual Reality Immersion

Video conference

Phone

TODAY

Chat

Shared screen E-mail

Non Real-time 1876

Databases/ Groupware

Fax 1971

voice communication

1982

fast information delivery

sending pictures

~ 1995

~ 1990

~ 2000

Functionality

synchronous screen displaying

asynchronous data access

synchronous data sharing

Fig. 92. Evolution of Collaboration Technologies

x Dependence on availability of network and external providers x There are still too many islands of information and documents x Still there are too many CAD-Systems and formats used x The bandwidth is limited as well as stable communication networks x The technology itself contributes only with 25% to implementation success More important are organizational challenges and cultural obstacles in modern Cross Enterprise Engineering Networks.

Fig. 93. Cross Enterprise Engineering Networks

Industrial Prerequisites to Enable Collaborative Engineering

189

Cultural obstacles and boundaries are the most frequent reasons for rejecting the collaboration tools or process. The integration of diversity is the main goal of every global company or brand. To ensure clear benefits despite different organizations and to define a clear method of communication and collaboration it is essential to have a clear understanding of the culture or habitat’s of the people, the company or the group you working with. Collaboration in engineering requires trust and respect of the individual or the individual idea or output a party can offer. Furthermore it is essential that the culture of collaboration is within the strategy of a company. This means that collaboration is not only a way of communication; it is an essential method for the strategic growth and the key to innovation within a global market. Some major soft facts and challenges: x Support of top management is required to get permission to exchange of sensitive information x Training and software support is required for widely distributed users x Security policy may block data exchange with externals x Human resistance to changes in technology x Designer’s willingness to keep developed things under the desk x Overcome threshold for routine use of new technology x Language barriers x Political constraints between locations x Lack of face-to-face contact x Less adventure and pleasure when not travelling x Missing sense of community

14.3 Industrial Prerequisites to Enable Collaborative Engineering In order to enable collaborative engineering within and with externals, global companies have to fulfill a number of prerequisites: x Through portfolio management, the scope of product, systems and services to be delivered to customers have to be reviewed, modularized and, as far as possible, standardized x Basic information for products have to be standardized, quality checked in terms of minimal available documents, process parameters for the customer and design parameters to be used internally, and be provided through an appropriate infrastructure

190

Importance of Product Design and Data Exchange Standards

x Standards have to be implemented along the life cycle chain of the product. These standards should allow easy and approved exchange of product data information, internally as well as externally with customers and suppliers. We will now look in detail into these three prerequisites.

14.4 Portfolio Management for Products, Systems and Services Portfolio management starts with the mapping of deliverables to the customer. It is recommended to divide these into two dimensions, the complexity of the product from low to high and the standardization level from engineering service to commodity. If applied e.g. for the ABB product portfolio, there are simple products like capacitors or installation material, which the customer can buy off-the-shelf. A more complex class of products are e.g. switchgears or substations, which are assembled to order, where as large drives or electrical cubicles for OEM require engineering to order. The most complex class of products is that one where a project has to set-up to create the customer solution, e.g. a process plant or an assembly line for gearbox assembly. In each of these classes the portfolio manager can identify parts of or whole products to be a standard. But what is a standard? First a standard is a proven, pre-engineered, modular building block that is commonly agreed upon, re-usable across projects, and a key benchmark to engineer solutions for customers.

ComplexityofofDelivery Delivery Complexity

High

Off-the-Shelf

Project/Plant Engineering

Engineer-toOrder

Assemble-toOrder

Process Plant Process Plant Pulp and Paper Plant Pulp and Paper Plant Rolling Mill Rolling Mill Powertrain Assembly Powertrain Assembly Offshore Offshore

Large Drives Large Drives Turbines Turbines Offshore Power Plant Offshore Power Plant OEM Projects OEM Projects

Drives Drives Power Electronics Power Electronics Automation Products Automation Products Robots Robots

Small Drives Small Drives Motors Motors

Body-in-White Body-in-White Painting Painting&&Coating Coating

Transformers Transformers Machines Machines

Switchgear Switchgear Substations Substations

Fuses Fuses Switches Switches

After AfterSales Sales Plant PlantService Service

Small SmallTransformers Transformers Wellhead WellheadSystems Systems

Cables Cables Large LargeCapacitors Capacitors

Installation InstallationMaterial Material Capacitors Capacitors

Press PressAutomation Automation Transmission TransmissionLines Lines

Low

Engineering Service

Operator OperatorStations Stations

Special SpecialMotors Motors Valves Valvesand andActuators Actuators

Sensors Sensors

Meters Meters Sensors Sensors

Standardization StandardizationofofDelivery Delivery

Fig. 94. Mapping of the Portfolio of an Engineering Company like ABB

Commodity

Standardization of Default Product Information

191

Second it is a package of information such as datasheets, drawings, solid models, cost calculation tools, reliability information, maintenance manuals and reference projects, and it is type-coded for its identification and usage. Third it must fulfil the requirement to be designed to make processes, such as selling, engineering, releasing, purchasing (incl. cost migration) and commissioning systems, effective and efficient. The business goals, which can be achieved with this approach, are to work with „standards” in order to be competitive, reduce costs, and cut delivery times instead of tailoring individual solutions for the customer. This can be applied for each product in the portfolio, even for project driven solutions (see Fig. 94), and is enabled by IT systems and engineering tools that work hand-in-hand to facilitate standardization. Quote proven quality Early release

Quote

Detailed Quote

Order

Reduce Engineering

Frozen Layout

Design Review

More time to shop & migrate to LCC

Release

Purchase

More simultaneous work

Construction

STAT-03112 CONV-03106

CONV-01105

ASSY-03201

STAT-10008

ROBO-02205

STD TORQ-02007

Bill of Standards

Fig. 95. Benefits of Standardization Along the Product Life Cycle

14.5 Standardization of Default Product Information The second prerequisite is to standardize basic information for products, go through a certification process to do the quality check and make it available through specific infrastructure. ABB has chosen a roadmap, which will x deliver continuous productivity improvement from ABB’s integrated operations, engineering and information management environment x provide more efficient engineering through integrated tools for installation, operation, optimization and maintenance of every device

192

Importance of Product Design and Data Exchange Standards

x guarantees certified interoperability of ABB products using international bus-protocols and communications standards x enables enhanced functions available in certified products enabling „plug and produce” installation in any Industrial IT system x allow extension of ABB installed systems capabilities through system evolution or enhancement The core of the ABB approach is the ABB Aspect Object Model, which has already been presented in various conferences, e.g. by (Krantz 2000, Novak 2002, Bratthall et all. 2002, Schilli et all. 2002, Dai et all. 2003, Schilli et all. 2003). ABB has implemented a system where ABB product classes are modelled in a browser, allowing the display of related products aspects and product aspect presentation (e.g. as technical document), see Fig. 96. Product classes are stored and managed in ABB on a central server. Each product is classified according to a global ABB standard. Minimum product aspects are product description, compliant certification documents, product manual, installation manual, maintenance manual, data sheet, process parameters and design parameters.

Product Classification

Product Aspects

Product Aspect Presentation

Fig. 96. Standardized Product Information in ABB

But most important for successful implementation is to have processes installed to collect product information, to quality proof the content and to release it to the information repository.

Industrial Use of Standards Along the Product Life Cycle

193

14.6 Industrial Use of Standards Along the Product Life Cycle As a third prerequisite to enable collaboration along the product life cycle global companies have to implement standards along the life cycle chain of the product, which allow easy and approved exchange of product data information, internally but also externally with customers and suppliers. As already mentioned before, data exchange during the design and engineering process is completely different to that one required for the manufacturing and service phase. During design and engineering, collaboration requires detailed description of product requirements, of design concepts and of design details, where description of one product part could easily reach mega-byte of data in Computer Aided Design (CAD)-systems. Data exchange in this area is dominated by few standards like IGES (ANSI IGES) and STEP (ISO STEP). Implementation of data exchange with these standards requires commercially available interfaces to CADsystems, which in case of STEP are focused on so called STEP application protocols AP 214 and AP203, as well as Data Exchange Management packages, which are provided by the CAD-tools suppliers and third party implementers. The main issue of implementation still is testing, the set-up of exchange conditions and the implementation of processes, which all establish trust and confidence between the collaboration partners. While the picture in the design and engineering phase is quite clear, in the domain of the manufacturing and service phase there are no established and globally agreed standards available. You could state, of course, that this is the domain of XML-Technology (W3C XML). But W3C only provide us with a number of XML standards, which are the technological basis for implementation. They do not help in order to solve the business process related issues. Here we do not have an agreed standard; however domain or consortium related standards, e.g. OAGIS (OAG 2004) or OPENTrans (OPENTrans 2003) deal with business to business integration. In this domain ABB has developed its own solution, ABB Business Data Object (BDO), to communicate internally in business-to-business applications, but also to communicate with its customers. The requirements in this domain are clear. Solutions for the manufacturing and service phases should be able to handle in a structured manner x Bill of material (BOM), x Bill of Service parts, x Electronic catalogs, x Product process parameters, x Tables of characteristics, x Commercial information, x Contractual information, and x Installed base data

194

Importance of Product Design and Data Exchange Standards

within the context of clearly identified, commonly agreed business cases. Industry urgently needs an international, well accepted standard here.

14.7 Real-Time Design Collaboration at ABB and Its Supplier Network ABB’s initiative VDO – Virtual Design Office has been started in 1999, and its aim has been to leverage the despite company structure and diversity into innovation. The ABB Corporate Research Centers in Krakow and Ladenburg have been evaluating and defining new engineering methods for the new collaboration approach. The tools that have been selected at this time are: Lotus Notes, NetMeeting and further more OneSpace Collaboration. ABB’s Division PTMV worked with them on this approach. The first pilot has involved sites in the US, Poland, Italy, Switzerland, Germany, Finland, Sweden and Norway. The first collaboration pilot had problems with its structure of use and user acceptance. The complexity of the pilot seems too big for a first shot. Marek Fulczyk from ABB and Ingo Kern from Strategic Enterprises have been nominated at this time for the new Program Managers VDO. Both defined a smaller and less complex structure for the „second” pilot – „cross enterprise collaboration”. Despite the first initiative, the cross enterprise collaboration approach included sites from ABB and suppliers.

Fig. 97. The Concept of Cross-Enterprise-Collaboration

Real-Time Design Collaboration at ABB and Its Supplier Network

195

The sites selected had similar management support for this approach and a common engineering „culture”. The PTMV sites of ABB Bergamo and ABB Ratingen selected the enterprise collaboration approach. Furthermore both sites had been requested to select two suppliers each. They were free to decide which supplier would participate in the collaboration project. This supplier selection was an act of cooperation between the engineering and the purchasing department. Every site selected suppliers with a long term and an excellent working relationship. The collaboration methods and software tools were trained onsite and for all involved suppliers. Technology and connections were checked and stressed to ensure a stable working environment. The collaboration environment was able to provide the parties with content, process and software tools and methods. Virtual project folders were created and process rules for collaboration defined. VDO – Virtual Design Office was implemented for the first time at ABB and its suppliers.

Fig. 98. Implementation of Collaborative Engineering in ABB

Cross Enterprise Collaboration Benefits, which have been achieved: x Real time co-work on design x Integration of Suppliers x Cost savings of travel x Cost savings due to reduction of project time

196

Importance of Product Design and Data Exchange Standards

x Immediately decisions x Quality improvement x Reuse of parts x Innovation

14.8 References For further information we refer to [1], [2], [4], [8], [23], [26], [32], [33], [34], [45], [46], [49], and [51].

Teil III Fallstudien aus der Prozessindustrie

15 Produktentwicklung bei einem Lebensmittelhersteller

Dieses Kapitel berichtet von einem PLM-Projekt bei einem Konsumgüterhersteller. Dieser erwirtschaftet als Teil eines internationalen Konzerns in Deutschland mit 10 000 Mitarbeitern einen Umsatz von mehr als 2 Mrd. € mit der Produktion von Lebensmitteln an mehreren Produktions- und Entwicklungsstandorten. Ziele des Projektes waren die Prozesssicherheit und Transparenz des Produktentwicklungsprozesses zu verbessern und durch Toolunterstützung eine Verbesserung des Time to Market zu erreichen. Hierzu wurde eine Lösung mit den Komponenten Dokumentenmanagement, Prozess- und Projektsteuerung sowie Stammdatenmanagement mit SAP PLM eingeführt. Diese wird von ca. 500 Anwendern in der Produktentwicklung und im Umfeld der Produktentwicklungsprojekte genutzt.

15.1 Ausgangssituation Das Unternehmen setzte bereits vor einigen Jahren ein „auf die organisatorische Verbesserung von Prozessabläufen mit Hilfe der Informationstechnologie fokussiertes Projekt“ auf. Nachdem die grundsätzliche Entscheidung für die Einführung von Standardsoftware gefallen war, wurde der Schwerpunkt dieses Projektes die unternehmensweite Einführung des integrierten StandardInformationssystems SAP R/3 als strategisches System in den Bereichen Personalwesen, Beschaffung, Finanzbuchhaltung, Controlling, Vertrieb, Materialwirtschaft und Produktion. Neben den Teilprojekten des Organisationsprojektes in den genannten Bereichen wurden zwei weitere Teilprojekte aufgesetzt: die zentrale Stammdatenverwaltung für die verschiedenen Anwendungsbereiche und die Unterstützung der Produktentwicklung. In der Produktentwicklung war zu Projektbeginn folgende Ausgangssituation vorzufinden: Die Entwicklung neuer Produkte (Artikel) liegt in den Händen der verschiedenen Sparten und wird in der Regel vom Marketing dieser Sparten verantwortet (nicht berücksichtigt sind Beteiligungen und kooperierende Unternehmen). Produktentwicklung bedeutet zum einen Produktinnovationen, d. h. Produkte, die grundlegend neu sind, oder so genannte Line Extensions, also neue Produkte innerhalb bestehender Produktlinien. Zum andern fallen aber auch Produktrenovationen, d. h. substantielle Änderungen bestehender Produkte, sowie Änderungen an

200

Produktentwicklung bei einem Lebensmittelhersteller

Rezeptur oder Verpackung unter die Produktentwicklung. Die Sparten unterscheiden sich wesentlich zum Beispiel hinsichtlich der Anzahl der Produktentwicklungen pro Jahr und der Laufzeit der Produktentwicklung, die von einigen Monaten bis zu mehreren Jahren reicht. Die Ausgangssituation zu Projektbeginn ist einerseits durch die unternehmensweiten Rahmenbedingungen gekennzeichnet: x Heterogene Systemlandschaft (unterschiedliche IT-Systeme auf unterschiedlichen Plattformen für die operative Geschäftsabwicklung) x Keine Integration der Produktentwicklung in die operativen IT-Systeme x Entscheidung für den Einsatz von Standardsoftware SAP R/3 Andererseits sind die Produktentwicklungsprozesse selbst durch folgende Ausgangssituation charakterisiert: x Unterschiedliche Entwicklungsprozesse in den verschiedenen Sparten: Dies ist einerseits durch die Verschiedenartigkeit der Produkte bedingt, andererseits auch Ausdruck der historisch innerhalb der Sparten gewachsenen Prozesse ohne übergreifende Abstimmung. Die Entwicklungsprozesse sind teils lückenhaft und stark technologisch geprägt. x Unterschiedlicher Strukturierungsgrad: Während einzelne Sparten bereits mit definierten Entscheidungspunkten innerhalb des Produktentwicklungsprozesses arbeiten, werden in anderen teilweise bereits weit reichende (und kostenintensive) Entwicklungstätigkeiten begonnen, bevor eine Entscheidung über das weitere Vorgehen vorliegt. x Unterschiedliche Werkzeuge zum Management der Entwicklungsprojekte: Teilweise werden Entwicklungsprojekte rein papierbasiert bearbeitet, was insbesondere bei Änderungen des geplanten Projektablaufes erhebliche Anpassungen erforderlich macht, teilweise werden Excel-Dateien verwendet, allerdings ohne Abbildung der diversen Abhängigkeiten zwischen einzelnen Prozessschritten. x Manuelle Projektsteuerung: Die Steuerung des Entwicklungsprojektes, d. h. der Anstoß weiterer Aktivitäten nach der Beendigung vorheriger liegt vollständig beim Projektleiter bzw. -koordinator. Als Kommunikationsmedien werden dafür Telefon und E-Mail eingesetzt. x Dokumentation: Die Ergebnisse einzelner Tätigkeiten liegen in ganz unterschiedlicher Form vor, teils als Papierdokumente, die per Hauspost verschickt werden, teils als elektronische Dokumente in Form von Wordoder Excel-Dateien, die per E-Mail, teils aber auch in ausgedruckter Form per Hauspost verschickt werden. Dadurch entsteht hoher Koordinations- und Administrationsaufwand. Zudem besteht die Gefahr, dass verschiedene Mitarbeiter mit unterschiedlichen Ständen der Dokumente arbeiten.

Ziele des PLM-Einsatzes

201

x Intransparenz der Entwicklungsprojekte: Sowohl die Zahl als auch das Stadium der aktuellen Entwicklungsprojekte ist nicht in allen Sparten zu jeder Zeit transparent. x Stammdatenerfassung: Während des Produktentwicklungsprozesses entsteht eine Reihe von Daten zum Produkt (Artikel), sowie Rohstoffen und Verpackungen, die in nachgelagerten, operativen IT-Systemen als Stammdaten zur Verfügung stehen müssen. Die Stammdaten werden in einer Reihe von Papierformularen erfasst. Diese Aufgabe obliegt dem Produktverantwortlichen (in der Regel dem Produktmanager), jedoch muss ein erheblicher Teil der Stammdaten von anderen Stellen erfragt und in den Formularen erfasst werden und diese anschließend an die zentrale Stammdatenstelle zur Eingabe in die entsprechenden IT-Systeme geschickt werden. Dies kann sich über lange Zeiträume erstrecken, da die einzelnen Daten zu unterschiedlichen Zeitpunkten an verschiedenen Stellen entstehen. Beispielsweise existiert die Produktbezeichnung (der Artikeltext) bereits mit der Produktidee, dagegen steht das Bruttogewicht der Verkaufseinheit erst nach dem Wiegen der ersten fertig produzierten Einheiten im Werk fest.

15.2 Ziele des PLM-Einsatzes Ausgehend von den vorgenannten Problemfeldern, die sowohl in der Ausgestaltung des Entwicklungsprozesses an sich als auch in dessen systemtechnischer Unterstützung liegen, definieren sich die Ziele des Projektes in verschiedenen Bereichen: 1. Prozesssicherheit x Harmonisierung des Produktentwicklungsprozess über die verschiedenen Sparten x Klare Strukturierung des Produktentwicklungsprozesses 2. Time to market x Verkürzung des Produktentwicklungsprozesses x Frühwarnsystem für Terminüberschreitungen x Möglichst starke Parallelisierung von Entwicklungstätigkeiten x Verringerung von Liege- und Postlaufzeiten 3. Transparenz x Verfügbarkeit vollständiger und aktueller Dokumentation x Vergleichbarkeit der Projekte x Soll-Ist-Vergleiche für Projekte

202

Produktentwicklung bei einem Lebensmittelhersteller

4. Arbeits- und Kosteneinsparung x Entlastung von Terminverfolgungs-Aktivitäten x Vereinfachung von Berichten x Ablösen der Formularflut x Reduzierung von Suchaufwand x Reduzierung des Aufwandes für Übergabe bei Personalwechsel

15.3 Projektmethoden und Projektorganisation Um die genannten Ziele zu erreichen, wurde innerhalb des Gesamtprojektes ein Teilprojekt PLM aufgesetzt, das sich in einem ersten Schritt mit der Optimierung und Harmonisierung des Entwicklungsprozesses an sich (systemunabhängig) und in einem zweiten Schritt mit der Prozessautomatisierung und -unterstützung durch SAP R/3 befasste. In der Konsequenz führen diese gleichzeitige Änderung des Prozesses und die Einführung der Systemunterstützung auf Anwenderseite zwangsläufig zu einer grundlegenden Umstellung der Arbeitsweise. Dadurch wird jedoch die Erarbeitung einer „vollständigen, konsistenten und eindeutigen“ Anforderungsdefinition in der Definitions- bzw. Konzeptionsphase erschwert, da die Anwender mangels detaillierter Kenntnis des zukünftigen Systems nicht immer in der Lage sind, ihre zukünftige Arbeitsweise hinreichend genau zu beschreiben. Aus diesem Grund wurde für die Systemunterstützung die Vorgehensweise eines evolutionären Pilotprojektes in einer Sparte mit relativ wenigen Entwicklungsprojekten gewählt. Grundlage dieser Vorgehensweise ist zunächst eine ausreichend genaue Anforderungsdefinition für die erste Implementierung, die im Verlaufe des Projektes iterativ gemeinsam mit den Anwendern ergänzt und verfeinert und vom Projektteam umgesetzt wird. Nach Abschluss des Pilotprojektes und Konsolidierung der ersten Anwendererfahrungen erfolgte die Einführung bei der größten Sparte als Rollout des Projektes. Das Kern-Projektteam umfasste über den Einführungszeitraum neben dem Prozessverantwortlichen zwei bis drei Unternehmensmitarbeiter (mit jeweils ca. 50 % Kapazität) und zwei bis drei Berater (mit jeweils ca. 30 % Kapazität). Dieses Kernteam wurde für die Anforderungsdefinition und die Abnahmetests durch Key User ergänzt.

15.4 Projektdurchführung Wie im vorigen Abschnitt erwähnt, gliedert sich das Projekt in das Pilotprojekt und den Roll-Out in die weiteren Sparten. Im Folgenden soll jedoch keine streng chronologische Darstellung der Projektdurchführung gegeben werden, sondern auf eine inhaltliche Gliederung gewechselt werden, wo dies instruktiver erscheint.

Projektdurchführung

203

15.4.1 Prozessanalyse und -harmonisierung In einem ersten Projektschritt, der der eigentlichen Systemunterstützung vorgelagert ist, wurde der Produktentwicklungsprozess analysiert und spartenübergreifend abgestimmt. Für den Gesamtprozess wurde ein gemeinsames Phasenkonzept entwickelt, das innerhalb der einzelnen Projektphasen in den verschiedenen Sparten unterschiedlich ausgestaltet sein kann.

Ideen-Phase

Entwicklungs-Phase

Phase 1

E1

Phase 2

E2

Phase 3

E3

E4

Kontroll-Phase

Phase 4

E5

E6

Abb. 99. Phasenkonzept der Produktentwicklung

Die einzelnen Phasen enden mit Entscheidungsmeilensteinen (E1 bis E6). Dadurch ist sichergestellt, dass am Ende jeder Entwicklungsphase explizit eine Entscheidung über eine Weiterführung oder Einstellung des Entwicklungsprojektes gefällt wird. Aufgrund der Art der Aktivitäten in den einzelnen Phasen kann von einer näherungsweise exponentiellen Zunahme der Kosten über die Entwicklungsphasen ausgegangen werden. Durch die expliziten Entscheidungspunkte können dementsprechend stark anwachsende Kosten eines Projektes, das letztlich doch nicht zu einem Produkt führt, vermieden werden. Wie in Abb. 99 dargestellt, sollen die Entwicklungsphasen und die Kontrollphase mit Softwareunterstützung bearbeitet werden. Die Einführung der Softwareunterstützung für diese Phasen wird im Folgenden Gegenstand der Betrachtung sein. 15.4.2 Definition / Konzeption Wie bereits erwähnt, wurde beim Pilotprojekt eine iterative Vorgehensweise anstelle eines starren Phasenkonzeptes gewählt. Zum Start des Roll-Out erfolgte eine Definitions- oder Konzeptionsphase, die sich über einen Zeitraum von zweiein-

204

Produktentwicklung bei einem Lebensmittelhersteller

halb Monaten erstreckte. In dieser Phase wurden drei Teilprojekte gebildet, um die Anwenderanforderungen an die Systemunterstützung zu erarbeiten: 1. Prozess/Projektsystem/Workflow Dieses Team beschäftigte sich zum einen mit der detaillierten Ausgestaltung des Entwicklungsprozesses, zum anderen mit den Anforderungen an das SAPProjektsystem und die Workflowunterstützung. Für die Entwicklungsprozesse wurden Standards definiert, die als Vorlagenetzpläne im Projektsystem hinterlegt werden und dann als Kopiervorlage für operative Projekte dienen (vgl. Abschnitt 15.5.1). Darüber hinaus wird innerhalb einer Sparte zwischen verschiedenen Produktgruppen differenziert, da die Entwicklung von Produkten verschiedener Produktlinien unterschiedliche Tätigkeiten umfassen. Abb. 100 zeigt exemplarisch die definierten Abhängigkeiten einzelner Tätigkeiten und Zuständigkeiten in der Phase Produktionsvorbereitung für Produkte einer Produktlinie mit Meilensteinen am Beginn und Ende der Phase. Jeder Tätigkeit wurde bereits in der Konzeptionsphase ein Bearbeiter (Arbeitsplatz in SAP R/3, siehe oben) und eine Vorgangsdauer zugeordnet. TA*

PM*

670

680

TA*

TP

PGM/PM*

700 KP*

ND-EK*, -EA*, ER*

-

TP,TPM

PM* 590 TA*

570

580

WL-L, WS-L MPF,MPK,MPS

-

630 ND-EK*, -EA*, -ER*

600 MPF,MPK,MPS

WL-FV, WS-V

690

710 ND-EZ*

WS-KK

ND-EZ*

720 PM*

730

750

WS-KK, WL-KK

/ 620

640 TP,TPM

770 660

760

610 650

740 PM*

MPF,MPK,MPS

PMF,PMK,P

815 KE 560

880

PM*,KPA

780 TPM

TTS

790

785

TPM,WL-FV,WS-V TP/TPM

800

810

TA* 830 TA*,TTS

TTS

820

MF*

860

PGM/PM*

840

850

870

Abb. 100. Detaillierter Ablaufplan der Tätigkeiten für die Phase 3 des Produktentwicklungsprozesses für Produkte einer Produktlinie

Die Anforderungen an das SAP-Projektsystem zur Verwaltung und Steuerung der Projekte beziehen sich in erster Linie auf die Bereiche:

Projektdurchführung

205

x Umsetzung der definierten Entwicklungsprozesse in Form von Netzplänen x Benutzerfreundlichkeit (Unterstützung bei Anlage operativer Projekte aus Standardvorlagen) x Unterstützung der Anwender durch Vollständigkeitsprüfungen etc. x Terminierung (nach Rückmeldung einzelner Tätigkeiten) x Berechtigungskonzept für lesenden und schreibenden Zugriff auf Projektinformationen x Berichte über Projektfortschritt, Vergleiche von Projekten, sonstige Auswertungen (z. B. Vorgänge ohne Puffer, Arbeitsplatzauswertungen etc.) x Ressourcen- und Kostenplanung sowie Kostenverfolgung sollen später als funktionale Erweiterung eingeführt werden Anforderungen an die Workflowunterstützung: x Automatische Prozesssteuerung, d. h. automatische Benachrichtigung der Bearbeiter einzelner Tätigkeiten, wenn diese ausgeführt werden sollen, unter Berücksichtigung der im Netzplan definierten Abhängigkeiten x MS-Outlook-Anbindung: Anwender sollen per Internet-Mail über anstehende Tätigkeiten informiert werden x Terminkontrolle und automatische Benachrichtigung der Projektverantwortlichen bei Terminüberschreitungen (Frühwarnsystem) 2. Dokumentenverwaltungssystem Im Bereich der Dokumentenverwaltung wurden die Anforderungen in folgenden Bereichen definiert: x Analyse und Festlegung der Dokumente, die zu Projekten verwaltet werden sollen x Definition der Zuständigkeiten für Einstellen und Aktualisieren von Dokumenten x Festlegung von verschiedenen Zuständen (Status) von Dokumenten und der erlaubten Aktivitäten (z. B. keine Änderung von freigegebenen Dokumenten) x Berechtigungskonzept für den Zugriff auf sensible Dokumente wie Kalkulationen oder Rezepturen x Versionierung von Dokumenten zur Historisierung x Ablage der Originaldateien in einem geschützten Bereich 3. Stammdatenverwaltung Der Schwerpunkt der Anforderungsdefinition für die Stammdatenverwaltung war in erster Linie organisatorischer Natur: x Die Erfassung von Stammdaten soll dezentral erfolgen, d. h. jede organisatorische Einheit pflegt die Daten, die von ihr erzeugt werden, selbst im System.

206

Produktentwicklung bei einem Lebensmittelhersteller

x Festlegung der Zuständigkeiten für die Erfassung einzelner Stammdaten x Einbettung der Stammdatenerfassung als einzelne Tätigkeiten in den gesamten Produktentwicklungsprozess Für die Erfassung von Artikelstammdaten (SAP-Begriff: Materialstammdaten) wurde systemseitig zunächst nur auf eine möglichst komfortable Erfassung der Stammdaten zur Versorgung der Altsysteme abgehoben: x Rollenspezifische Erfassungsmasken, d. h. jeder Anwender sollte auf möglichst wenigen unterschiedlichen Masken Daten pflegen x Unterstützung der Anwender durch Eingabehilfen zu einzelnen Feldern und Gültigkeitsprüfungen In allen Bereichen waren neben systembezogenen Anforderungsdefinitionen auch organisatorische Fragen wie die Definition von Zuständigkeiten zu klären. 15.4.3 Realisierung In dieser Phase erfolgte die Umsetzung der definierten Anforderungen im System SAP R/3 durch folgende Aktivitäten: x Customising des Systems: Festlegung von Prozessen durch Einstellung entsprechender Steuerparameter x Einstellung von Stammdaten, die ebenfalls steuernde Funktion für den Prozessablauf bzw. auf die Ein- und Ausgabemöglichkeiten haben (z. B. Profile, Auswertungen) x Erweiterung des Systems durch Nutzung von Programm-Exits oder UserExits (d. h. Aufruf kundeneigener Programme bzw. Ergänzungen des SAPProgrammcodes an definierten Stellen) x Programmierung von Workflowkomponenten x Erstellen von Berechtigungsprofilen und Zuordnung zu den Benutzern Eine ausführliche Darstellung der Implementierung wird in einem nachfolgenden Abschnitt gegeben. Die Realisierung beinhaltet jeweils Tests der vorgenommenen Einstellungen anhand von Testdaten. Die Realisierungsphase schließt ab mit Integrationstests, in denen die implementierten Prozesse durchgängig getestet werden. Beispielsweise wurden Testprojekte angelegt, die Workflowunterstützung und Benachrichtigungsfunktionalitäten getestet, sowie Dokumente angelegt und mit NetzplanVorgängen verknüpft und Artikel- (Material-) Stammdaten erfasst. Die Realisierungsphase gestaltet sich relativ kurz, da für den Roll-Out lediglich veränderte bzw. zusätzliche Anforderungen zu implementieren waren. Im Gegensatz dazu stehen beim Pilotprojekt etwa gleiche Anteile für die iterativ bearbeiteten Bereiche Definition und Realisierung.

Komponenten der PLM-Lösung

207

15.4.4 Schulung der Anwender Für die Anwenderschulungen wurden zwei Schulungsblöcke gebildet, die sich aus der Rolle der Anwender und der Nutzung des Systems ergeben.

Projektleiter

Beteiligte

1 Tag

SAP-Grundlagen Dokumentenverwaltung Workflow

SAP-Grundlagen Dokumentenverwaltung Workflow

1 Tag

Stammdatenerfassung Informationssystem DVS Grundüberblick PS

Stammdaten/DVS Grundüberblick PS Beispielprojekt gesamt

1 Tag

Detail PS Informationssystem PS Beispielprojekt gesamt

Abb. 101. Schulungsblöcke, differenziert nach Anwendergruppen

Während die Projektleiter (die Key User) den vollen Umfang des implementierten Systems nutzen und deshalb auch im vollen Umfang geschult werden mussten, entfallen für die Beteiligten (Projektmitarbeiter ohne Projektleitertätigkeiten) einige Schulungsblöcke.

15.5 Komponenten der PLM-Lösung 15.5.1 Projektsystem 15.5.1.1 Strukturen des Projektsystems Für die Abbildung der Strukturen des Produktentwicklungsprozesses (Phasen und Tätigkeiten bzw. Bearbeitungsschritte) wurden die Standardfunktionalitäten des SAP-Projektsystems genutzt: Projektstrukturplan (PSP) und Netzplan mit Vorgängen. Zunächst wurde ein Standard-PSP als Kopiervorlage für operative Projekte angelegt. Anschließend wurden Standard-Netzpläne eingestellt, die als Maximalpläne alle Tätigkeiten enthalten (vgl. Abb. 100), die in den einzelnen Phasen durchzuführen sind. Diese Standard-Netzpläne enthalten bereits die Zuordnung der NetzplanVorgänge zu den PSP-Elementen (siehe Abb. 102) sowie die Dauern der Tätigkeiten und die Arbeitsplätze, an denen diese ausgeführt werden. Auf jeweils dem letzten Vorgang einer Phase sitzt zudem ein Meilenstein, der die Freigabe der nachgelager-

208

Produktentwicklung bei einem Lebensmittelhersteller

Entscheidungsphasen PSP Phase 1

Phase 2

Phase 3

Phase 4

Phase 5

Bearbeitungssschritte Vorgang 3 Vorgang 1

Vorgang 2

Vorgang 4

Vorgang 6

Arbeitsplatz

Vorgang 5

Vorgang 8 Vorgang 7

Arbeitsplatz Arbeitsplatz

Arbeitsplatz

Arbeitsplatz

Arbeitsplatz

Arbeitsplatz

Abb. 102. Strukturen des SAP-Projektsystems und deren Beziehungen

ten Vorgänge steuert. Diese Freigabe ist Voraussetzung für die Benachrichtigung der Bearbeiter über den Workflow (siehe unten, Abb. 104). Bei Anlage eines operativen Projektes werden die Standardstrukturen kopiert und anschließend bearbeitet. Beispielsweise werden Tätigkeiten, die für dieses konkrete Entwicklungsprojekt nicht ausgeführt werden, aus dem Netzplan entfernt und die Beziehungen angepasst. Außerdem werden evtl. Zeitdauern von Vorgängen und Arbeitsplätze gepflegt. Sind all diese Arbeiten abgeschlossen, kann über ein Programm (Zusatzentwicklung) die Vollständigkeit geprüft werden. Dies umfasst beispielsweise die Prüfung, ob jedem Vorgang ein Arbeitsplatz zugeordnet ist, ob alle Felder mit steuernder Funktion gepflegt sind oder ob Vorgänge ohne Vorgänger oder Nachfolger existieren. Abb. 103 zeigt den Netzplan eines operativen Projektes aus dem SAP-Projektsystem. Zum Vergleich von verschiedenen Projektzuständen, insbesondere bei Änderungen in laufenden Projekten, wurde eine Projektversionierung implementiert. Das heißt, von einem laufenden Projekt kann eine neue Version angelegt werden, mit dieser weitergearbeitet und die neue Version später mit dem ursprünglichen Projekt verglichen werden. 15.5.2 Workflow Aufgabe des Workflow ist in erster Linie die automatische Steuerung des Projektes. Ist ein operatives Projekt vollständig gepflegt, wird vom Projektleiter der Work-

Komponenten der PLM-Lösung

Abb. 103. Netzplandarstellung aus dem SAP-Projektsystem

Manuelle Rückmeldung

Benachrichtigung durch den WORKFLOW Vorgang Vorgang 22 Vorgang Vorgang 44

Vorgang Vorgang 11

Vorgang Vorgang 55

Vorgang Vorgang 33 Systemstatus: Systemstatus: Frei Frei

Statusänderung durch Freigabemeilenstein

Systemstatus: Systemstatus: EROF EROF Systemstatus: Systemstatus: FREI FREI

Systemstatus: Systemstatus: EROF EROF Systemstatus: Systemstatus: FREI FREI

Vorgänge Vorgänge können können bearbeitet bearbeitetwerden werden

Abb. 104. Automatische Projektsteuerungsfunktion des Workflows

Systemstatus: Systemstatus: EROF EROF

Vorgänge Vorgänge können können noch nochnicht nicht bearbeitet bearbeitetwerden werden

209

210

Produktentwicklung bei einem Lebensmittelhersteller

flow gestartet, der die Struktur des Netzplanes liest und den oder die nachfolgenden Vorgänge „anstößt“ (vgl. Abb. 104). Außerdem werden durch die Freigabefunktion des Meilensteins an diesem ersten Vorgang alle Vorgänge der aktuellen Projektphase freigegeben und so erst deren Bearbeitung ermöglicht. Das „Anstoßen“ eines Vorganges geschieht auf zweifache Weise: x Innerhalb des SAP-Systems wird ein Workitem in den Eingangskorb desjenigen Anwenders geschickt, dessen Arbeitsplatz dem Vorgang zugeordnet ist. x Für nicht regelmäßig in SAP arbeitende Projektmitarbeiter wird eine Internet-Mail an den Bearbeiter des Vorganges geschickt mit dem Hinweis, dass ein Workitem mit einer zu bearbeitenden Tätigkeit in seinem SAPEingangskorb angekommen ist. Nach erfolgter Ausführung der Tätigkeit erfolgt die Rückmeldung wiederum durch ein Workitem. In der weiteren Bearbeitung des Projektes wiederholen sich diese Schritte, zusätzlich unterstützt durch Funktionen wie z. B. Abwesenheitsregelungen. Durch diese Automatisierung wird der Projektleiter im Idealfall nach der Einrichtung des operativen Projektes vollständig von dessen aktiver Steuerung befreit. Um dennoch jederzeit die Information des Projektleiters sicherzustellen und ihm entsprechend Möglichkeiten zur Reaktion zu bieten, wurden folgende Funktionalitäten implementiert: x Automatische Neuterminierung bei verspäteter / früherer Rückmeldung x Benachrichtigung des Projektleiters bei verspäteter Rückmeldung x Benachrichtigung des Projektleiters bei Zeitüberschreitungen x Vorabinformation aller Beteiligten einer Projektphase 15.5.3 Projektinformationssystem Für projektspezifische und projektübergreifende Auswertungen wird das SAP R/3Projektinformationssystem als flexibles Werkzeug zur Verfolgung von Projekten eingesetzt. Es können Einzelprojekte, Teilprojekte oder mehrere Projekte im Vergleich und auf unterschiedlichen Aggregationsniveaus ausgewertet werden. Abb. 105 zeigt eine Übersicht über vordefinierte Berichte (links) und exemplarisch die Strukturübersicht eines Projektes (rechts). Die Strukturübersicht zeigt geschachtelt die Strukturelemente Projektdefinition, Top-PSP-Element (Dreieckssymbol; Aggregation des Gesamtprojektes), Netzplan, PSP-Elemente (Dreieckssymbole), Netzplan-Vorgang (Balkensymbol) und verknüpftes Dokument (Blattsymbol). Verknüpfte Dokumente können direkt aus dem Projektinformationssystem angezeigt werden (siehe auch nächstes Kapitel). Rückmeldedaten werden über die Aggregationsstufe verdichtet und auf den jeweiligen Stufen dargestellt.

Komponenten der PLM-Lösung

211

Abb. 105. SAP R/3-Projektinformationssystem

Als Auswertungen wurden beispielsweise folgende Berichte eingerichtet: x Auswertung zeitkritischer Vorgänge (Vorgänge ohne Pufferzeiten) x Liste sämtlicher Tätigkeiten aller Projekte für einen bestimmten Nutzer x Auswertung nach Produkthierarchien über ein Feld der Projektdefinition 15.5.4 Dokumentenverwaltungssystem In der Konzeptionsphase wurden diejenigen Dokumente, die Informationen zu Produktentwicklungsprojekten enthalten, analysiert und zu Gruppen mit gleicher Zugriffsberechtigung zusammengefasst. Diese Gruppierung wurde in SAP R/3 durch das Konstrukt der Dokumentart abgebildet (siehe Abb. 106). Für alle Dokumentarten wurden folgende Funktionalitäten implementiert: x Automatische Ablage der Originaldateien in einem Sicherheitsbereich (SAP Content Server) x Statusverwaltung mit Einschränkung der möglichen Operationen auf Dokumenten in Abhängigkeit vom Status x Versionierung freigegebener Dokumente bei Änderungen x Verknüpfung mit Projekten x Dokumentensuche über umfangreiche Selektionskriterien

Dokument 8 Dokument 9 Dokument 10 Dokument 11 Dokument 12 Dokument 13 Dokument 14 Dokument 15 Dokument 16 Dokument 17 Dokument 18

Dokumentart 1

x x x x x x x x x x x x x x x

x x x x x

e 17

e 16

Stell

Stell

e 12

e 13 Stell e 14 Stell e 15

x x x x x x x x

Stell

x x

Stell

e9

e 10

e8

e7

Stell

e6

Stell

e5

x x x x x x

Stell

Stell

e4

e3

x x x x x x x x x x x x x x x x x x

x x x

x x x

x

x x x x x x x x x x

Dokumentart 2 Dokumentart 3

Dokumentart 5 Dokumentart 6 Dokumentart 7

Dokument 7

x x x x x x x x x x x x x x x x x x

Dokumentart 4

Dokument 6

x x x x x x x x x x x x x x x x x x

Stell

Dokument 5

x x x x x x x x x x x x x x x x x x

Stell

Dokument 4

Stell

Dokument 3

Stell

Dokument 2

Stell

Dokument Dokument 1

Stell

e1

e2

berechtigte Stelle

e 11

Produktentwicklung bei einem Lebensmittelhersteller

Stell

212

Abb. 106. Gruppierung von Dokumenten zu SAP-Dokumentarten mit differenzierten Zugriffsberechtigungen (anonymisiert).

Die Einführung des Dokumentenverwaltungssystems mit der Verknüpfung von Dokumenten zu Netzplan-Vorgängen und der komfortablen Suche über beschreibende Dokumentendaten und Klassifizierung ändert die Informationsbeschaffung grundlegend. Vor der Einführung der Dokumentenverwaltung war jeweils derjenige Projektmitarbeiter, der ein Dokument erstellt auch dafür verantwortlich, dass dieses an alle anderen Mitarbeiter, die diese Information benötigen, verteilt wird (Push-Prinzip). Mit der Einführung der Dokumentenverwaltung werden die Dokumente stattdessen in das System eingestellt, klassifiziert und verknüpft. Dadurch sind sie für jeden Mitarbeiter einfach auffindbar und nur der Mitarbeiter, der das Dokument benötigt, beschafft sich die Information aus der Dokumentenverwaltung (Pull-Prinzip). 15.5.5 Materialstammdaten Zur Verwaltung der Artikelstammdaten, die während des Produktentwicklungsprozesses entstehen, wurden die Möglichkeiten von SAP R/3 zur Konfiguration des SAP-Objektes Materialstamm genutzt. Es wurden neue Sichten generiert, die eine Reihe zusätzlicher Felder für die Versorgung von Altsystemen beinhalten.

Ergebnisse des Projektes

213

15.6 Ergebnisse des Projektes Deutliche Verbesserungen wurden in folgenden Bereichen erzielt: x Die Prozesstransparenz ist deutlich verbessert. Dies ist einerseits eine Auswirkung des standardisierten Entwicklungsprozesses mit klarer Phasengliederung. Andererseits wird der Zugriff auf Projektinformationen durch die neuen Auswertungsmöglichkeiten des Projektinformationssystems vereinfacht bzw. erst ermöglicht. x Bei den Beteiligten ist ein gestiegenes Bewusstsein für den Gesamtprozess und dessen Abhängigkeit von der rechtzeitigen Bearbeitung jeder einzelnen Teilaktivität zu erkennen. x Die automatische Benachrichtigung der Projektmitarbeiter entlastet die Projektleiter von routinemäßigen Koordinationsaufgaben. x Das Frühwarnsystem ermöglicht eine schnelle Reaktion des Projektleiters auf Verzögerungen. x Alle Mitarbeiter haben (bei entsprechender Berechtigung) Zugriff auf die jederzeit aktuellen Projekt-, Material- und Dokumenteninformationen. x Die Gefahr, dass mit veralteten Ständen von Informationen gearbeitet wird, ist deutlich verringert. x Der Aufwand für Verteilen von Informationen und Dokumenten ist reduziert.

16 Produktentwicklung mit NPDI bei einem Konsumgüterhersteller

Gerade in der Konsumgüter-Branche besteht die Notwendigkeit, in immer kürzeren Abständen innovative Produkte an den Markt zu bringen. Dieser Projektbericht zeigt die Bemühungen der Hersteller, ihre Entwicklungsprozesse zu strukturieren und die Prozesse der Produktstrategie, -innovation und -entwicklung enger mit den logistischen Prozessen und der Produktion zu vernetzen, um keine Wettbewerbsvorteile zu verspielen. Dieses ganzheitliche Business Process Management – realisiert beispielsweise im NPDI Prozesskonzept (New Product Development and Introduction) – hilft, die Time to Market nachhaltig zu optimieren. Das Unternehmen, bei dem das beschriebene Projekt durchgeführt wurde, gehört zu den führenden Anbietern in der Duftbranche mit Tochtergesellschaften und Vertriebspartnern auf allen Kontinenten. Einen wichtigen Beitrag zum Erfolg der Produkte leistet nicht nur der eigentliche Duft, sondern auch die Verpackung und Präsentation. Gerade das Verpackungsdesign macht einen großen Anteil des Produktentwicklungsprozesses aus. In die Produktentwicklungsprojekte sind Anwender unterschiedlicher Bereiche (Marketing, Einkauf, F&E, Produktion, Logistik etc.) involviert, die durch das implementierte System unterstützt werden.

16.1 Marktsituation Konsumgüterindustrie Ein in vielen Branchen zu beobachtender Trend trifft die Konsumgüterbranche im Besonderen: Globalisierung, geändertes Verhalten der Konsumenten und verstärkter Wettbewerb führen dazu, dass die Produktlebenszeit (Zeit von der Einführung eines Produktes bis zur Marktentnahme) stetig sinkt. Um trotzdem Marktanteile zu halten oder auszuweiten, ist es nötig, in immer kürzeren Abständen neue Produkte zu entwickeln und am Markt zu platzieren. Dies erfordert schnellere und häufigere Innovationszyklen, die Produktentwicklungszeit ist ein erfolgskritischer Faktor. Verstärkt wird dies noch dadurch, dass von vielen Innovationen oder Ideen nur ganz wenige tatsächlich Produktreife erlangen und an den Markt gebracht werden. Und bei genau diesen Produkten gilt es, den Markteintritt vor der Konkurrenz zu schaffen, um dadurch entscheidende Marktanteile zu sichern. Konsequenz aus den geschilderten Trends ist, dass im Unternehmen die effiziente Prozessintegration zwischen Forschung / Produktentwicklung und nachgelagerten Prozessen wie Vertrieb, Logistik, Qualitätsmanagement und Produktion immer wichtiger wird. Die Menge an zu verwaltenden Produktstammdaten steigt. Prozessbrüche, die Qualitätsmängel oder gar Doppeleingaben von Stammdaten erfordern, werden

216

Produktentwicklung mit NPDI bei einem Konsumgüterhersteller

Produktentwicklungszeiten „ Wie lange dauert bei Ihnen im Durchschnitt die Produktentwicklungszeit in Jahren für ein neues verkaufsfähiges Endprodukt / Artikel? 3 ,8 Durchschnittlich in Jahren

2 ,8

1 ,6 0 ,8 0 ,5

1990

1995

2000

a ktue ll

2010

Studie „Produktentwicklungsprozesse“ IDS Scheer 3/2004 bei 120 Industrieunternehmen

16

Business Process Excellence

© IDS Scheer AG

www.ids-scheer.com

Abb. 107. Marktstudie zu Produktentwicklungszeiten

Produktlebenszeit Wie lange ist im Durchschnitt Ihre Produktlebenszeit (vom Produktionsbeginn bis zum Produktlaunch des Nachfolgers) in Jahren für Ihr Endprodukt? 14,1 11,8

8,4 6,7 4,2

1990

1995

2000

aktuell

2010

Studie „Produktentwicklungsprozesse“ IDS Scheer 2004 bei 120 Industrieunternehmen © IDS Scheer AG

Business Process Excellence

Abb. 108. Marktstudie zu Produktlebenszeiten

www.ids-scheer.com

Ausgangssituation

217

nicht mehr akzeptiert. Neben der effizienten Verwaltung von Stammdaten und Innovationen wird auch die terminliche Abstimmung der Innovationsprojekte zwischen Entwicklung und nachgelagerten Bereichen immer wichtiger. Produktentwicklung ist als umfassendes Projekt zu begreifen und zu steuern, das auch die Aktivitäten des eigentlichen Produktlaunch mit umfasst und so oft noch vorhandene Prozessbrüche zwischen Produktentwicklung, Logistik und Produktion überwindet. Eine weitere Konsequenz ist, dass das Management im Unternehmen immer größeren Wert darauf legt, jederzeit aktuell über die Planung des Produktportfolios und den Stand der in Arbeit befindlichen Entwicklungsprojekte informiert zu sein, auch dies aus einer den Gesamtprozess umfassenden Sicht.

16.2 Ausgangssituation Die im vorhergehenden Abschnitt geschilderten Faktoren und Konsequenzen galten auch bei dem hier betrachteten Duft-Hersteller. Bei einer detaillierten Betrachtung der Prozesse rund um die Entstehung neuer Produkte wurden eine Reihe konkreter Schwachstellen identifiziert: x Eine einheitlich definierte, systemgestützte Projektsteuerung fand nicht statt, dementsprechend war es mühsam, Statusinformationen über einzelne Projekte zu bekommen. x Durch die fehlende Steuerung traten Zeitverluste in der Projektabwicklung beim Übergang von Aktivitäten zwischen einzelnen Abteilungen auf, ganz besonders bei der Abstimmung mit Aktivitäten externer Dienstleister. x Der Datenaustausch mit diesen externen Dienstleistern (z. B. Entwürfe im Rahmen der Verpackungsentwicklung) war nicht standardisiert und unstrukturiert, Datenaustausch erfolgt per Papier oder Mail, die Kommunikation und Ablieferung von Ergebnissen war fehleranfällig. x Mangels Toolunterstützung taten sich die Projektverantwortlichen schwer, Termintransparenz herzustellen, zur Terminverfolgung wurden individuell konfigurierte Tools meist auf Excel-Basis eingesetzt. x Aufgrund dieser isolierten, dezentralen Projektmanagementtools gab es auf Managementebene keinen jederzeit aktuellen Projektüberblick, Übersichten mussten jeweils mühsam zusammengetragen werden. Dies erschwerte eine genaue Produkt-Portfolioplanung im Produktmanagement und Prognoserechnung auf Ebene von Produktgruppen. x Durch die schwierige Terminverfolgung kam es gerade an den Schnittstellen zwischen Marketing, Produktentwicklung, Verpackungsentwicklung, Einkauf und Produktion oft zu Abstimmungsproblemen, aus denen vereinzelt Verzögerungen beim Markteintritt resultierten.

218

Produktentwicklung mit NPDI bei einem Konsumgüterhersteller

x Aufgrund fehlender Dokumentationsstrukturen war die Übertragung von Ergebnissen zwischen den einzelnen Projekten, das Knowledge-Management, sehr vom individuellen Engagement abhängig. x Als IT-Lösung wurde eine Vielzahl von nicht integrierten Tools benutzt: Für Dokumentation Microsoft-Office-Anwendungen mit einer jeweils individuell ausgeprägten Ablage der Dateien auf Serververzeichnissen, für Groupware-Funktionalitäten und Workflows Lotus Notes, Projektsteuerung meist in Microsoft-Excel, seltener in Microsoft-Project. x Für die in der Logistik wesentlichen Produktstammdaten Material und Stückliste wurde bereits SAP genutzt. Spezielle Stammdaten der frühen Entwicklungsphase wie technische Spezifikationen wurden in separaten Datenbanken verwaltet. Die Stammdatenentstehung und -abstimmung zwischen Entwicklung und logistischen Prozessen erfolgte oft nur verzögert und wies Qualitätsmängel auf. Grundsätzlich gab es die unternehmensweite, strategische Entscheidung, für neue Anwendungen den Einsatz von SAP-Komponenten zu prüfen und, wenn funktionell ausreichend, diese zu verwenden.

16.3 Ziele des PLM-Einsatzes Als Ziele des Projektes wurden nach einer ersten Situationsaufnahme definiert: x Verbesserte Integration von Marketing, Produktentwicklung und Logistik x Klar strukturierter Entwicklungsprozess für Launch und Relaunch x Sicherheit, Prozesstransparenz und Projektsteuerung in den Entwicklungsprojekten verbunden mit einer Terminsteuerung und einem Frühwarnsystem bei Terminüberschreitungen x Schaffung einer eindeutigen und möglichst einheitlichen Datenbasis für den Gesamtprozess x Verbesserter Datenaustausch mit externen Lieferanten x Verbesserung des Arbeitsflusses zwischen den Beteiligten durch aktive Steuerung des Prozesses Die Lösung sollte mittels einfach zu bedienender Tools alle Elemente des Entwicklungsprozesses von der frühen Phase (Konzept- und Spezifikationsphase) bis zum Produktlaunch verwalten: x Dokumente, Konzepte und Briefings aus Marktforschung, Produktmanagement und Marketing x projektbezogene Dokumente, die Verlauf und Inhalt der Produktentwicklungsprojekte dokumentieren (Checklisten, Freigabedokumente) x in Kollaborationen mit Lieferanten entstehende Dokumente und Daten

Vorgehen im Projekt

219

Produktentwicklung

FAX

MS Office Fileablage

Marktforschung, Marke tingkonzepte

Datenaustausch Lieferanten

SAP PDM

Artikelstammdaten

Projekt-Timing

Lotus Note s

M S Access Datenbank

Technische Spezifikationen

M onitoring Soll - Ist

MS Excel

manuell / papierbasiert

Freigabe- und Ände rungsablauf

Checklisten Sortime nte / Artike l

Fileserver

Reinzeichnungen Korrekturabzüge

Produktkalkulation

Abb. 109. Ist-Aufnahme der für Steuerung und Dokumentation des Produktentwicklungsprozesses relevanten IT-Tools

x Daten und Auswertungen aus Projekt- und Produktcontrolling (Budgetierung, Soll-Ist-Vergleiche für Projekte, Analysedaten aus Laborinformationssystemen) x die im Produktentwicklungsprozess entstehenden Stammdaten (Spezifikationen von Produkten und Verpackungen, technische Zeichnungen, Produktstammdaten wie Materialstamm, Stückliste)

16.4 Vorgehen im Projekt In der Projektvorbereitung erfolgten – mit den bereits erläuterten Ergebnissen – eine Aufnahme der Prozesse bei der Einführung einer Produktserie, die Analyse der eingesetzten IT-Tools und eine Identifikation der Störfaktoren. Darauf basierend wurden Projektumfang und Projektziele definiert. Hier wurden für die wesentlichen Bestandteile der Lösung (Dokumentenmanagement, Projektsteuerung, Workflow, Stammdaten) die Umsetzung in SAP und

220

Produktentwicklung mit NPDI bei einem Konsumgüterhersteller

alternativ in Lotus Notes geprüft. Ergebnis war die Entscheidung, die von SAP im Rahmen der NPDI-Initiative (New Product Development and Introduction) integrierten PLM-Tools zu nutzen. Die Detailkonzeption und Implementierung wurde in 2 Stufen durchgeführt: Projektstufe 1 beinhaltete die Integration noch nicht im SAP vorhandener Stammdaten, nämlich der Verpackungsspezifikationen und der zugeordneten Dokumente. Außerdem wurden die Prozesse zur Erstellung der Spezifikationen definiert und umgesetzt, auch mit Workflowunterstützung bei der Freigabe. Konzeption und Realisierung dieses Projektabschnitts erforderten einem Zeitraum von 6 Monaten. Nicht im Projektfokus lag die Abbildung von Rezepturstammdaten mit dem SAP Rezepturmanagement, weil zunächst in der Abbildung der Verpackungen und Verpackungsspezifikationen höhere Potenziale gesehen wurden. Rezepturmanagement kann die Lösung in der Optimierungsphase noch ergänzen. In Projektstufe 2 lag der Schwerpunkt auf Implementierung der Projektsteuerung, Projektdokumentation und Datenaustausch mit Lieferanten (Kollaboration). Realisierung und Implementierung erforderten 8 Monate. Es wurden die von SAP zum Projektmanagement angebotenen Lösungen Collaboration Projects (cProjects: kollaborative, webbasierte Projektsteuerung) und das R/3 Projektsystem PS prototypisch implementiert und ausführlich miteinander verglichen (Vergleichsmatrix siehe Abb. 110). Schließlich wurde cProjects ausgewählt. Die wesentlichen Arbeitspakete in dieser Phase waren: x Definition einer oder mehrerer generischer Projektstrukturen (MusterProjektpläne) als Sollprozess der Projektabwicklung x Realisierung der Projektsteuerung und Terminverfolgung x elektronische Verwaltung von Projektdokumenten x Prozesse und Tools zum strukturierten Austausch von Dokumenten mit externen Partnern x Realisierung eines projektübergreifenden Management-Reporting

16.5 Das Prozesskonzept NPDI Wesentlich für die Realisierung des Projektes war die Orientierung an dem so genannten NPDI-Konzept und den dazu von SAP angebotenen Lösungen, die hier zunächst allgemein vorgestellt werden. Erst seit kurzer Zeit taucht der Begriff NPDI in der Literatur auf. Er drückt aus, dass eine umfassende Betrachtung der Produktentwicklung und Produkteinführung notwendig ist, um die Produktentstehung und -innovation im Unternehmen zu optimieren. Produktentwicklung muss den gesamten Prozess von der Produktidee bis zur Einführung des Produktes am Markt beleuchten – nur dann wird sich ein Unternehmen durch Produktinnovation von seinem Konkurrenten differenzieren können.

Das Prozesskonzept NPDI

Kriterien Allgemeine Kriterien Oberfläche Berechtigungssystem Mehrsprachigkeit Weiterentwicklung Kosten IT Strategie Schulungsaufwand Funktionen eines Projektsystems Projektstruktur Arbeitsweise im Projekt Suchfunktionalitäten Arbeit mit Dokumenten Austausch von Dokumenten mit extern Terminierung Ressourcenplanung Workflow Projektcontrolling Auswertung / Reporting Kriterien der Integration Integration mit SAP R/3 Integration Rechnungswesen Integration Logistik Integration externer Anwendungen Summe

Faktor Faktor Gewicht. SAP R/3 PS cProjects 1 -5

Erfüll.-grad SAP R/3 PS

221

Erfüll.-grad KO cProjects -Krit.

0,6 0,6 1 0,5 0,8 0,6 0,4

0,9 0,8 1 0,9 1 0,8 0,8

4 4 3 5 5 3 3

2,4 2,4 3 2,5 4 1,8 1,2

3,6 3,2 3 4,5 5 2,4 2,4

0,8 0,8 0,6 0,5 0,5 0,8 0,7 0,6 0,9 0,8

0,8 0,8 0,8 0,9 0,9 0,8 0,9 0,8 0,5 0,6

5 5 5 5 5 4 2 5 1 5

4 4 3 2,5 2,5 3,2 1,4 3 0,9 4

4 4 4 4,5 4,5 3,2 1,8 4 0,5 3

0,8 0,8 0,8 0,4

0,4 0,5 0,5 0,8

2 1 1 3

1,6 0,8 0,8 1,2 50,2

0,8 0,5 0,5 2,4 61,8

Abb. 110. Matrix zur Bewertung zweier Lösungsalternativen anhand eines gewichteten Kriterienkatalogs

Nicht nur Schnelligkeit im Erkennen von Kundenwünschen, deren Realisierung in marktreifen Produkten und der Platzierung am Markt ist erforderlich – erfolgskritisch sind auch die Produktqualität, das richtige Prognostizieren des Bedarfs und ein angemessener Preis. NPDI umfasst somit nicht nur Funktionen der klassischen Produktentwicklung, sondern erstreckt sich auch über andere Funktionsbereiche im Unternehmen: vom Produktmanagement, das neue Produktideen liefert, bis zur Absatzprognose und der frühzeitigen Produktkalkulation. Wie folgende Abbildung zeigt, ist NPDI also kein Softwarewerkzeug, sondern ein umfassendes Prozesskonzept, das insbesondere die Ausweitung des engeren Produktentwicklungsprozesses auf die frühe Entwicklungsphase bis zur Markteinführung der Produkte beinhaltet. Dazu sind verschiedene Lösungskomponenten miteinander zu kombinieren. 16.5.1 SAP-Lösungen zur Umsetzung des NPDI-Konzeptes Die SAP AG vermarktet seit 2004 eine Lösung zur Umsetzung des NPDIKonzeptes. Zur Gesamtlösung gehören nicht nur die in diesem Buch bereits erläuterten Kernfunktionen des Produktdatenmanagements (Dokumente, Spezifikationen, Rezepte und Artikelstammdaten), sondern auch Ideen- und Konzeptmanagement.

222

Produktentwicklung mit NPDI bei einem Konsumgüterhersteller

Projektmanagement Produktentw. Zeit & Projektmanagement

Portfoliomanagement

Portfolioplanung

Ideen- und Innovationsmanagement Ideenfindung und Bewertung Konzeptdefinition

Strategische Planung

Produktentwicklung im engeren Sinne

Kosten und Budget

€

Stammdatenmanagement

Markteinführung Produktionsanlauf

Dokumentenmanagement

Markteinführung (CRM) Business Warehouse Produktion (SCM)

Abb. 111. Das NPDI Konzept

Über den gesamten Prozess sind Qualitätsmanagement, Projektmanagement und die Verwaltung des Projekt- und Produktportfolios sowie dessen strategische Planung wesentlich. In der Phase der Markteinführung treten eine funktionierende Integration in die Supply Chain (Absatzplanung, Produktionsanlauf) und das Kundenbeziehungsmanagement (Marketing, Vertrieb) in den Vordergrund. Dies sind meist bereits lange existierende Anwendungen, die mit in den letzten Jahren neu entwickelten Applikationen kombiniert wurden. Zu den neuen Werkzeugen gehören insbesondere die so genannten xApps (Packaged Composite Applications). So hilft die Lösung xPD (xApp Product Definition) in der frühen Entwicklungsphase, Ideen und Konzepte strukturiert zu verwalten. Die Anwendung xRPM (xApp Resource and Program Management) dient der Verwaltung und Steuerung des Projektportfolios. Außerdem ist mit cProjects ein neues Tool zum operativen Projektmanagement vorhanden, das eng mit der KollaborationsPlattform cFolders integriert ist. Zusammengefasst: NPDI ist nicht gleichzusetzen mit der SAP PLM-Lösung. NPDI umfasst den Time-to-Market-Prozess von der Produktidee bis zur Einführung eines Produktes am Markt. PLM hingegen ist weitgehender, beinhaltet z. B. auch Prozesse der Wartung und Instandhaltung oder der Marktentnahme eines Artikels. Andererseits betont das NPDI-Konzept die Integration zu Funktionen wie CRM und SCM, die nicht Bestandteil von PLM sind. Die Vision der NPDI-Gesamtlösung ermöglicht durch die enge Integration der Produktstammdaten und PLM-Funktionen mit den logistischen SAP-Kernanwendungen, die Markteinführung neuer Produkte effizient zu unterstützen. Zu beachten

Komponenten der PLM-Lösung

223

ist allerdings, dass gerade bei der Verbindung der klassischen SAP-Applikationen mit den neuen Produkten an der ein oder anderen Stelle noch Schnittstellenprobleme bestehen, die projektspezifisch gelöst werden müssen. Im hier beschriebenen Kundenprojekt liegt der langfristige Fokus auf dieser ganzheitlichen Prozessunterstützung, der Kunde will dazu aus dem Lösungsportfolio des SAP NPDI sukzessive mehr Tools zum Einsatz bringen.

16.6 Komponenten der PLM-Lösung Produktentwicklung

MS Office Fileablage

Marktforschung, Marketingkonzepte

Datenaustausch Lieferanten

SAP cFolders

SAP PDM

Artikelstammdaten

Projekt-Timing

SAP cProjects

SAP EHS

Technische Spezifikationen

Monitoring Soll - Ist

SAP EHS + Workflow

Freigabe- und Änderungsablauf

Checklisten Sortimente / Artikel

SAP DMS

Reinzeichnungen Korrekturabzüge

Produktkalkulation

MS Excel

Multiprojektreporting

SAP BW

Abb. 112. Eingesetzte Lösungskomponenten im beschriebenen Projekt

Bei der konkreten Beschreibung der Lösungskomponenten wird hier nur auf die Teile der Gesamtlösung detailliert eingegangen, die nicht schon an anderer Stelle im Buch ausführlich beschrieben wurden.

224

Produktentwicklung mit NPDI bei einem Konsumgüterhersteller

16.6.1 Spezifikationsverwaltung Die Spezifikationsverwaltung in SAP kann benutzt werden, um typische Eigenschaften von Stammdatenobjekten in Form von Eigenschaftsbäumen – einer vordefinierten hierarchischen Struktur von Merkmals-Werte-Paaren – zu beschreiben. Eingesetzt wird sie zum Beispiel zur Beschreibung von Stoffen, Gefahrgütern aber auch für Verpackungen als Spezifikationsdatenbank. Die Daten können nicht nur innerhalb der Spezifikationsdatenbank, sondern auch integriert in den sonstigen Produktstammdaten genutzt werden. Dazu werden Spezifikationen von Verpackungsmaterialien beispielsweise mit dazugehörigen Artikelstämmen verknüpft, oder Spezifikationen werden in Rezepturen als Ein- bzw. Ausgangsstoffe aufgenommen. Bei dem hier betrachteten Projekt wurden mit Hilfe der Spezifikationsverwaltung alle Verpackungsbestandteile des Endproduktes (Flasche, Pumpe, Sprühkopf, Verschluss, Faltschachtel etc.) detailliert beschrieben. Dazu dienten verschiedene Spezifikationsarten mit kundenindividuellen Eigenschaftsbäumen. Über Objektverknüpfungen erfolgte eine direkte Verlinkung einer Spezifikation mit dem zugehörigen Material, so dass eine direkte Absprungmöglichkeit gegeben ist. Über spezielle Merkmale eines Eigenschaftsbaumes wurden relevante Dokumente (Zeichnungen, Dokumentationen etc.) verknüpft, so dass auch diese im direkten Zugriff sind. Die Dokumente werden im SAP-Dokumentenmanagement (DVS) verwaltet. Schließlich wurde eine Funktion zum Export der SAP-Spezifikationen nach MS Word integriert. In diesem Format werden die Spezifikationen z. B. externen Partnern präsentiert. 16.6.2 Projektmanagement SAP Collaboration Projects (cProjects) ist ein Projektmanagementsystem, das die gesamte Palette der Projektmanagementaktivitäten abdeckt, von der Planung über die Ausführung bis zur Projektdokumentation. Es nutzt ein Web-Frontend mit rollenbasiertem Zugriff. Die Projekte des Kunden wurden analysiert und gemäß dem Datenmodell von cProjects neu strukturiert. Dabei gliedert sich ein Projekte hierarchisch in: x Projektdefinition, hier werden Daten verwaltet, die für das Gesamtprojekt gültig sind x Projektphasen, welche das Projekt gliedern und optional eine streng phasenorientierte Abwicklung erlauben (Durchführung einer neuen Phase kann erst nach Abschluss der vorhergehenden Phase und Freigabe erfolgen). Hier wurden die Phasen Entwurf (Konzept- und Designentwicklung), Produktdesign und -kalkulation sowie Launch unterschieden. x Projektaufgaben, welche Phasen zugeordnet werden und die tatsächlichen Tätigkeiten / Vorgänge eines Projektes repräsentieren und den Projektphasen

Komponenten der PLM-Lösung

Abb. 113. Struktur einer Verpackungsspezifikation im SAP Spezifikationsmanagement

Abb. 114. Projektstruktur in cProjects

225

226

Produktentwicklung mit NPDI bei einem Konsumgüterhersteller

zugeordnet werden. Sie können durch Unteraufgaben weiter strukturiert und in Vorgänger- bzw. Nachfolgerbeziehung gesetzt werden. Hier wurde eine Gliederung in ca. 10 wesentliche Projektaufgaben pro Phase vorgenommen. x Checklisten, die abgearbeitet werden müssen, bevor eine Phase abgeschlossen wird. Diese Funktion kam bei dem konkreten Projekt nicht zum Einsatz. Für die Projektstruktur wurden unterschiedliche Vorlagen hinterlegt, um den Besonderheiten der verschiedenen Produktarten Rechnung zu tragen. Somit wird der Pflegeaufwand bei der Projektanlage minimiert und die Einhaltung von Standards unterstützt. Die konkrete Projektabwicklung läuft folgendermaßen ab: x Bei der Projektanlage wird eine Projektvorlage kopiert und das LaunchDatum festgelegt. Daraufhin terminiert das System automatisch die Projektaktivitäten (Rückwärtsterminierung). x Den Projektaufgaben (Aktivitäten) sind bereits in der Vorlage die für die Ausführung verantwortlichen Projektrollen (Marketing, Einkauf, Produktion etc.) hinterlegt. Im Rahmen der Projektplanung erfolgt die Besetzung der Rollen mit Ressourcen (Personen). x Der Projektleiter gibt das Projekt frei, was durch einen entsprechenden Projektstatus dokumentiert wird. Außerdem werden alle Projektmitarbeiter automatisch per E-Mail über den Projektstart informiert. x Sobald eine Projektaufgabe zur Bearbeitung ansteht (Erreichen des berechneten frühesten Starttermins), werden die zur Ausführung verantwortlichen Personen durch einen Workflow per E-Mail informiert. Die Nachricht enthält einen Link zur konkreten Aufgabe in cProjects. x Die Bearbeiter quittieren nach Erledigung ihre Aufgabe, Status im Projekt werden automatisch fortgeschrieben. x Am Ende einer Phase startet der Projektleiter einen workflowgesteuerten Prozess zur Abnahme der Phase. Sobald alle Entscheidungsträger die Abnahme durchgeführt haben, wird die nächste Projektphase zur Bearbeitung freigegeben. In Einzelfällen kann eine Phase auch bereits freigegeben werden, obwohl die Vorgängerphase noch nicht abgeschlossen ist. x Dokumente, die im Laufe des Projektes entstehen (z. B. Graphiken, Maßblätter, Reinzeichnungen oder Korrekturabzüge), werden im SAP Dokumentenmanagement abgelegt und direkt in der Web-Oberfläche den Aktivitäten, Projektphasen oder der Projektdefinition zugeordnet. Die Ablage ist auch integriert aus dem Windows Explorer möglich (SAP EasyDMS). Für bestimmte Dokumente ist ein Freigabeworkflow vorgesehen.

Komponenten der PLM-Lösung

227

16.6.3 Projektportfoliomanagement Beim Reporting ist zu unterscheiden zwischen projektbezogenen und projektübergreifenden Auswertungen. Erstere können direkt in cProjects ausgeführt werden (z. B. Aufwandsverteilung pro Projekt, Termine und Ressourcen pro Projekt, Projektfortschritt, Aufwand Ist versus Plan). Projektübergreifende Auswertungen, die eine Sicht auf das Projektportfolio bieten, werden hingegen im SAP Business Warehouse (BW) durchgeführt, in das über definierte Schnittstellen Projektinformationen eingestellt werden. Alternativ könnte auch die SAP-Anwendung xRPM (xApp Resource and Program Management) zum Controlling und zur Steuerung des Projektportfolios zum Einsatz kommen.

Abb. 115. Auszug aus einer Projektportfolioübersicht in SAP BW

16.6.4 Projektkollaboration SAP Collaboration Folders (cFolders) ist eine web-basierte Kooperationsplattform, die eine unternehmensübergreifende Zusammenarbeit unterstützt. Das System ermöglicht den Austausch von Dokumenten und strukturierten Informationen, z. B. Stücklisten oder Datenblättern, mit externen Partnern. Hier wird cFolders verwendet, um Dokumente im Rahmen der Verpackungsentwicklung mit Lieferanten auszutauschen (z. B. Maßblätter, Reinzeichnungen und Korrekturabzüge). Die Dokumente können direkt aus der Projektmanagementumgebung in Ordner (Collaboration Folders) abgelegt werden. Vom Projektleiter werden diese Ordner bestimmten externen Benutzern zugänglich gemacht. Diese erhalten vom System eine Nachricht und können auf die Dokumente über eine Web-Anwendung zugreifen. Nach Bearbeitung können die Dokumente zurückgestellt werden, der Projektleiter wird informiert und kann sie wieder in die Projektumgebung übernehmen. Die Tools cFolders und cProjects wirken also eng zusammen, um Externe, die keinen Zugang zum Projektmanagementtool haben, trotzdem gemäß Projektfortschritt in den Informationsfluss einzubeziehen.

228

Produktentwicklung mit NPDI bei einem Konsumgüterhersteller

Abb. 116. Arbeitsumgebung eines externen Kollaborationsteilnehmers beim Zugriff auf cFolders

16.6.5 Dokumentenmanagement Dokumente können auf drei Wegen in das System gelangen: x Dokumente mit direktem Projektbezug werden in der cProjects-eigenen Dokumentenmanagement-Umgebung gespeichert. x Für den Gesamtprozess relevante Dokumente (technische Zeichnungen, Reinzeichnungen etc.) werden in der SAP Dokumentenverwaltung (DVS) abgelegt und direkt in cProjects bzw. cFolders integriert. x Externe Partner stellen ihre Dokumente in cFolders ein. Egal auf welchem Weg die Dokumentation erfolgt, alle Dokumente werden an SAP DMS übergeben und können dort zentral recherchiert werden. Die physische Speicherung der Dateien erfolgt revisionssicher im SAP Content Server. Zur leichteren Handhabung und besseren Strukturierung der DMS-Dokumente wird das SAP EasyDMS Interface (integriert in Microsoft Office Anwendungen) eingesetzt. Damit ist eine Integration in den Windows Explorer bzw. die MicrosoftOffice Tools gegeben.

16.7 Ergebnisse des Projektes Das Projekt konnte termin- und aufwandsgerecht abgeschlossen werden. Insgesamt wurden die Lösungskomponenten, nach einigen durch intensive Schulung zu behebenden Anlaufschwierigkeiten, von den beteiligten Mitarbeitern erfreulich gut akzeptiert. Hierzu hat sicher wesentlich die – gegenüber den klassischen Modu-

Ergebnisse des Projektes

229

len R/3 PS und R/3 DMS – einfachere und benutzerfreundlichere Oberfläche in cProjects und EasyDMS beigetragen. Mit der Lösung wurden folgende angestrebten Ziele realisiert: x Durch die Strukturierung mit Vorlageprojektplänen wird ein einheitlicher Produktentwicklungsprozess definiert. Mit dem Projektsteuerungstool wird dieser nachvollziehbar für alle Projektbeteiligten gesteuert – in einem firmenweit einheitlichen Tool. x Damit besteht Transparenz hinsichtlich Terminen / Ergebnissen / Projektbesetzung über alle laufenden Produktentwicklungsprojekte. x Durch die Integration in SAP BW wird eine projektübergreifende Auswertung und Analyse ermöglicht und somit dem Management, den Produktmanagern und den Portfoliomanagern eine schnelle Übersicht über das Projektportfolio geboten. x Durch die konsequente Nutzung des Dokumentenmanagements ist ein schneller Zugriff und Austausch aller Dokumente möglich, insbesondere der wichtige Prozess der Bearbeitung und Freigabe von Reinzeichnungen wurde durch Workfloweinsatz deutlich beschleunigt. x Die SAP-Integration der benötigten Stammdaten (Dokumente, Spezifikationen) garantiert erhöhte Datensicherheit, -aktualität und -verfügbarkeit. x Durch den konsequenten Einsatz von SAP gelang eine deutliche Reduktion der Systemvielfalt. Insgesamt resultiert eine beschleunigte und transparentere Produktentwicklung. Termine werden verlässlicher eingehalten, Abweichungen früher erkannt und Gegenmaßnahmen eingeleitet. Das Zusammenspiel der Entwicklung mit den nachgelagerten logistischen Prozessen wird nicht nur durch die übergreifende Projektsteuerung verbessert, sondern auch dadurch, dass die für die späteren Phasen relevanten Produktstammdaten schon zu einem frühen Zeitpunkt im System zur Verfügung stehen.

17 Automatisierte Stammdatenpflege in der Konsumgüterindustrie

Dieser Projektbericht zeigt, wie die Stammdatenentstehung und die Stammdatenpflegeprozesse durch Workflowtools teilautomatisiert und optimiert werden können. Das beschriebene Projekt wurde bei einem Konsumgüterhersteller in Deutschland durchgeführt, der als internationaler Konzern mit weltweit 20 000 Mitarbeitern einen Umsatz von knapp 5 Mrd. € im Jahr erwirtschaftet. In Produktentwicklungsprojekten sind mehrere hundert Anwender involviert, von denen ca. 100 an den hier betrachteten Stammdatenpflegeprozessen teilnehmen und durch das System unterstützt werden.

17.1 Ausgangssituation Das Unternehmen hat wenige Jahre vor dem hier beschriebenen Projekt bereits SAP R/3 für seine europäischen Niederlassungen eingeführt. Zur Unterstützung des Aufwuchsprozesses des wichtigsten Stammdatenobjektes, des Materialstammes (allg. auch als „Artikel“ oder „Artikelstamm“ bezeichnet), wurden bereits in dieser ersten Phase Werkzeuge entwickelt, die dem Anwender das Ausfüllen der relevanten Datensichten durch die Bereitstellung von Arbeitslisten erleichtern sollten. Diese haben sich in Anbetracht der erheblichen Anzahl zu pflegender Objekte als nicht übersichtlich genug und letztendlich, gerade bei zeitkritischen Datensätzen, ungeeignet erwiesen. Ferner boten sie wenig Unterstützung bei häufig wiederkehrenden und somit automatisierbaren Aktivitäten. Um sowohl den Anwendern als auch dem berechtigten Interesse des Unternehmens an optimierten Stammdatenprozessen gerecht zu werden, wurde ein Projekt aufgesetzt, dessen Aufgabe die Abbildung des Materialstammpflegeprozesses und damit zusammenhängender Produktdaten mittels einer WorkflowAnwendung war. Zum Einsatz kam der von SAP ausgelieferte SAP Business Workflows. Hervorzuheben ist in diesem Zusammenhang, dass bei den zu erreichenden Zielen den Faktoren „Prozesssicherheit“ und „Transparenz“ eindeutig der Vorrang vor „Geschwindigkeit“ eingeräumt wurde, was bei der Beschreibung der Ausgangssituation noch deutlicher wird. Somit war die Herausforderung klar formuliert, dass nicht beschleunigende repressive Mittel wie Deadlining und Eskalation sondern anwenderfreundliche Servicefunktionalitäten im Vordergrund standen.

232

Automatisierte Stammdatenpflege in der Konsumgüterindustrie

Stammdatengenerierung

Monitoring Stammdatenpflege

Internationale Stammdatenpflege

Stammdatenverteilung

Nationale/Lokale Stammdatenpflege

Abb. 117. Systemübergreifender Pflegeprozess

17.1.1 Ausgangszustand der Stammdatenpflege Um der organisatorischen Aufstellung des Unternehmens auch in der Stammdatenpflege zu folgen, wurde bei der SAP-Einführung eine zweischichtige Systemarchitektur gewählt, die sicherstellt, dass alle Stammdaten auf internationaler Ebene in Bezug auf ihre Schlüssel und Grunddaten einheitlich sind und sich dennoch regionale Ausprägungen entwickeln können: x Obere Schicht: Pflege des Grunddaten in einem SAP-PLM-System auf internationaler Ebene x Untere Schicht: Pflege der Detaildaten in einem lokalen SAP-System Zwischen den beiden Schichten erfolgt der Datenübergang mittels einer automatisierten Schnittstelle, wie auch das Prozessdiagramm in Abb. 117 zeigt. Nachdem als erstes die Grunddaten in der oberen (internationalen) Schicht angelegt und in das lokale, europäische System eingespielt wurden, setzte der Pflegeprozess für die Detaildaten mittels eines listenorientierten Werkzeugs ein. Dieses Werkzeug stellte für die Mitarbeiter in den pflegenden Abteilungen die zu bearbeitenden Materialien in einer x nicht personalisierten x auf Grund der großen Anzahl unübersichtlichen und x terminlich nicht gesteuerten Listenform zur Verfügung. Obwohl dies im Vergleich zu einer völlig unkontrollierten Bearbeitung „auf Zuruf“ bereits eine erhebliche Verbesserung darstellte, war die Folge dieser Form der Pflege, dass Materialien

Ausgangssituation

233

x nicht in der korrekten Reihenfolge oder x von den falschen Personen gepflegt wurden, was umständliche Korrekturen nach sich zog. Ferner war es für den Einzelnen schwierig zu erkennen, welche Materialien mit Priorität zu pflegen waren, wodurch regelmäßig zeitkritische Prozesse behindert wurden. Ebenfalls problematisch war diese Form der Pflege aus der Sicht des Prozesscontrollings: Sowohl für den einzelnen Mitarbeiter als auch für die Produkt- oder Prozessverantwortlichen war zu keinem Zeitpunkt transparent, in welchem Pflegezustand sich ein Material befand. Als ein weiterer negativer Aspekt dieses Pflegeprozesses wurde angesehen, dass der Materialstatus zur Steuerung der Verwendbarkeit eines Materials in anderen Prozessen nicht verlässlich eingesetzt werden konnte, da es keine klar definierten und kontrollierbaren Zeitpunkte („Meilensteine“) zum Setzen des jeweiligen Status gab. Die Notwendigkeit, den bisherigen Pflegeprozess mittels einer Automatisierung durch Workflow zu unterstützen, wurde durch eine Studie untermauert, die schonungslos die Folgekosten von Verzögerungen und Pflegefehlern aufzeigt. Einige Beispiele aus der Praxis seien hier genannt: x Durch die schnelle Produktion werden Etikettenfehler erst nach ca. 10 00015 000 Einheiten bemerkt, Vorkommen: ca. 6-7 Mal pro Jahr x Falsche Formate von Verfallsdaten, bzw. falsche Verfallsdaten werden ca. 5 Mal pro Jahr erzeugt x Jährliche Mietkosten für verschollene Paletten aufgrund von fehlendem Eintrag in der Stückliste fielen an in Höhe von € 50 000 x Falsche, zu spät oder unvollständig gelieferte Stücklisten erzeugten jährliche kalkulatorische Kosten in Höhe von € 200 000 Die prozentuale Verteilung der untersuchten Störfaktoren am Gesamtschaden ergibt sich aus nachfolgender Tabelle: Tabelle 2. Prozentuale Verteilung der Störfaktoren auf den Gesamtschaden durch fehlerhafte oder nicht optimierte Stammdatenpflege Störfaktor

Anteil [%]

Umsatzentgang durch verspäteten Launch/Relaunch

1

Produktionsfehler durch falsche Stammdaten

4

Nacharbeit, Ausschuss und Vernichtung durch falsche Stammdaten

12

Fehlende Automatisierung der Pflegetätigkeit

24

Zu lange Informationsbeschaffungszeiten in Fachabteilungen

47

Auswirkungen Werk-/Lagerortstruktur (Mehrfachpflege von Daten)

12

234

Automatisierte Stammdatenpflege in der Konsumgüterindustrie

In Anbetracht der konservativ berechneten jährlichen Kosten in Höhe von ca. 1,3 Mio. € durch fehlerhafte Stammdatenpflege oder nicht optimierte Pflegeprozesse erschienen effektive Verbesserungsmaßnahmen als dringend geboten.

17.2 Ziele des PLM-Einsatzes Ausgehend von den vorgenannten Problemfeldern, die sowohl in der Ausgestaltung des Pflegeprozesses an sich als auch in dessen systemtechnischer Unterstützung liegen, definierten sich die Ziele des Projektes in verschiedenen Bereichen: 1. Prozesssicherheit x Alle Prozesse laufen nach klar definierten Regeln ab x Keine „vergessenen“ Materialien x Einhaltung der Pflegereihenfolge nach betrieblichen Notwendigkeiten x Geordnete Statussteuerung (Materialstatus) durch den Workflow 2. Datenqualität x Die richtigen Mitarbeiter erhalten „ihre“ individuellen Arbeitsaufträge x Die Daten können zeitnah erfasst werden 3. Transparenz x Die Mitarbeiter können den Pflegezustand der jeweiligen Materialien im Verlauf des bisherigen Prozesses einsehen x Produkt- und Prozessverantwortliche können jederzeit nach unterschiedlichen Strategien den Pflegeprozess überwachen und bei Bedarf eingreifen 4. Arbeits- und Kosteneinsparung x Reduzierung von Suchaufwand für den Bearbeiter x Entlastung von Terminverfolgungs-Aktivitäten x Übernahme von automatisierbaren Standardaktivitäten durch den Workflow x Reduzierung des Aufwandes für Einarbeitung und Schulung

17.3 Projektmethoden und Projektorganisation Nach Abschluss der grundlegenden SAP-Einführung sowie einer Stabilisierungsphase wurde ein neues Teilprojekt aufgesetzt, das im Rahmen der bestehenden Lösungen und Systeme die beschriebene Problematik adressieren sollte.

Projektdurchführung und -ergebnisse

235

Dieses Projekt bestand im Wesentlichen aus einer Analysephase, der Konzeption, Implementierung, GoLive und einer sich anschließenden Optimierungsphase. Die Analysephase wurde durch die ARIS-Produktfamilie der IDS Scheer unterstützt. Hierbei mussten lediglich die Basisprozesse, die bereits während der initialen SAP-Einführung erhoben und optimiert wurden, um workflowspezifische Informationen ergänzt werden. Ferner konnte weiteres Optimierungspotenzial, beispielsweise durch Parallelisierung und Automatisierung von Hintergrundaktivitäten, identifiziert und in die Prozesse mit eingearbeitet werden. Konzeption, Realisierung und Test verliefen konventionell, wohingegen der GoLive gruppen- bzw. abteilungsweise durchgeführt wurde. Durch diesen weichen Übergang konnten Überbelastungen der Mitarbeiter durch das neue Werkzeug sowie Arbeitsunterbrechungen durch evt. Systemprobleme weitestgehend ausgeschlossen werden. Die Aufteilung der Ressourcen in Wochen Aufwand während der Projektlaufzeit erfolgte ungefähr nach Tabelle 3: Tabelle 3. Aufwand (in Wochen) nach Projektphasen PhasenDauer

Anzahl MA extern

Summe Aufwand extern

Anzahl MA intern

Summe Aufwand intern

Analyse

6

1

2

10

2

Konzeption

4

2

2

-

-

Realisierung

20

2

18

-

-

GoLive

1

3

1

1

1

Optimierung

8

2

2

1

8

Phase

17.4 Projektdurchführung und -ergebnisse Die Projektdurchführung folgte, wie oben bereits erwähnt, weitestgehend einer allgemeinen Einführungsmethodik. Somit sollen im Folgenden weniger der zeitliche Ablauf sondern die Besonderheiten des Projektes und spezielle inhaltliche Aspekte beleuchtet werden. 17.4.1 Prozessanalyse In der etwa sechs Wochen dauernden Analysephase wurden die Prozesse, die bereits für die allgemeine SAP-Einführung erfasst wurden, weiter detailliert und optimiert. Hierzu konnte die in ARIS modellierte Prozesslandschaft auf einfachste Weise wieder verwendet und angepasst werden. Ein Modellierungsbeispiel für einen Teilprozess findet sich in Abb. 118. Die Arbeiten wurden weitestgehend von einem branchenerfahrenen Fachberater in Zusammenarbeit mit Key Playern des Kunden durchgeführt.

236

Automatisierte Stammdatenpflege in der Konsumgüterindustrie

Die zusätzlich erhobenen Informationen beziehen sich z. B. auf x mögliche parallele Prozesszweige x technische Verknüpfungen zu benachbarten Prozessen x Details zu Schleifen und ähnlichen steuernden Konstrukten x Präzisierungen bei der Zuweisung von Bearbeitern x Zusammenfassung von technisch identischen Abläufen zu wieder verwendbaren Unterprozessen x Identifikation von Automatisierungspotenzial Master Data Coordinator International informiert

Materialanfrage liegt vor

Master Data Coordinator International

Internationale Vorgabedaten pflegen FERT

Monitoring Prozess Stufe 0

Stammdatenpflegeprozess initialisiert

Produktionswerk festlegen

Change Control Stammdaten

Internationale Entwicklungsdaten pflegen

Master Data Pfleger International

Internationale Materialstammdaten gepflegt

Abb. 118. Prozessmodellierung für Workflow (Ausschnitt)

Projektdurchführung und -ergebnisse

237

17.4.2 Konzeptionsphase In diesem vier Wochen dauernden Abschnitt des Projektes wurden vom Fachberater sowie einem Workflow-Spezialisten die umfangreichen Anforderungen geordnet und in ein schlüssiges Gesamtkonzept überführt. Die Anforderungen gliederten sich in unterschiedliche Bereiche: 1. Betroffene Module x Materialwirtschaft (MM) x Vertrieb (SD) x Produktionsplanung Prozessindustrie (PP-PI) x Lagerhaltung (WM) x Qualitätsmanagement (QM) x Controlling (CO) 2. Beteiligte Datenobjekte x Materialstamm x Stückliste x Konditionen x Kundeneigene Objekte 3. Organisatorische Rahmenbedingungen x Einfache spätere Ergänzung weiterer Objekte und Prozessabschnitte x Übersichtliches Erscheinungsbild der jeweiligen Arbeitsaufträge bei den Bearbeitern x Wunsch nach einem hohen Automatisierungsgrad 4. Technische Rahmenbedingung x Hohe Anzahl an steuernden Parametern (jeweils bis zu 10 Parameter für die Bearbeiterfindung, die Sichtensteuerung im Materialstamm und den Charakter eines Schrittes: Dialogschritt, Hintergrundschritt, Überspringen des Schritt) x Viele (Steuerungs-) Daten liegen in Kundentabellen vor x Aufgrund der gewünschten Flexibilität Notwendigkeit zu hoher Modularität Im Gegensatz zu einem konventionellen Workflow Design musste, insbesondere aufgrund der Punkte 3. und 4., eine weitestgehend generische Modellierung gewählt werden, die im Wesentlichen aus zwei Ebenen besteht: 1. Einer Prozesssteuerungsebene, in der die jeweiligen Prozessschritte in der korrekten Anordnung zueinander definiert wurden, sowie

238

Automatisierte Stammdatenpflege in der Konsumgüterindustrie

2. einer Detailebene, die sämtliche Funktionalitäten wie Dialogbearbeitung, Hintergrundbearbeitung, Bearbeiterfindung, Fehlerhandling in einem generischen Subprozess kapselt. Hierzu folgen weitere Details im Abschnitt 17.5. Durch dieses Design konnten vor allem die hohen Anforderungen an Erweiterbarkeit, Flexibilität und Wartungsfreundlichkeit erfüllt werden. Nicht verschwiegen werden sollen jedoch die sich aus dem speziellen Design notwendigerweise ergebenden Customising-Aufwände zur Konfiguration des Systems und das dafür benötigte erweiterte Know-how. 17.4.3 Realisierung In dieser etwa fünfmonatigen Projektphase erfolgte die Umsetzung der Anforderungen im SAP R/3 durch einen Entwickler und Workflow-Spezialisten. Die ausgeführten Aktivitäten waren: x Erstellung der Workflows x Programmierung der Steuermechanismen zur Ablage der Regeln für Bearbeiterfindung, Hintergrundaufgaben, Statussteuerung, etc. x Customising des Systems: Festlegung von Prozessen durch Einstellung entsprechender Steuerparameter. x Erweiterung des Systems durch Nutzung von Programm-Exits (d. h. Aufruf kundenspezifischer Sub-Programme) oder User-Exits (d. h. Ergänzungen des Programmcodes an von SAP definierten Stellen). x Erstellung einer kundeneigenen Reporttransaktion, die die Ablaufinformationen zu einem Prozess übersichtlich anonymisiert aufbereitet (im Rahmen der Betriebsvereinbarung mit dem Betriebsrat abgestimmt) x Erstellen von Berechtigungsprofilen und Zuordnung zu den Anwendern Wie oben bereits beschrieben, bestanden im Projekt sehr hohe Anforderungen an die Flexibilität und Erweiterbarkeit des Systems. Diese haben sich nicht nur im Workflow Design und dem relativ hohen Anteil an Programmierung, sondern auch beim Einstellen des Systems und den umfangreichen Tests niedergeschlagen. Abb. 119 gibt einen groben Überblick über das Verhältnis ausgeprägter Generik und des zu erwartenden Customising-Aufwands. Der farblich markierte Abschnitt im oberen Bereich der Kurve entspricht in etwa der Ausprägung des beschriebenen Projektes. Der erzielte Benefit entsprechend der oben beschriebenen Projektziele muss dem folgenden Aufwand gegenübergestellt werden: x Erhöhter Programmieraufwand x Hoher Customising- und Testaufwand x Intensive Betreuung in der Optimierungsphase (siehe weiter unten)

239

hoch

Projekt Charakteristik

niedrig

Customising Aufwand

Projektdurchführung und -ergebnisse

explizit

generisch

Technische Ausprägung Abb. 119. Customising-Aufwand in Abhängigkeit von der technischen Ausprägung

17.4.4 GoLive Die Produktivstartphase konnte aufgrund der gründlichen Vorbereitung und vor allem durch rigides Testen aller Teilfunktionalitäten sehr kurz gehalten werden. Da, wie oben bereits beschrieben, der initiale Start mit einer kleineren Zahl von Anwendern durchgeführt wurde, konnten die Schulungsaktivitäten ebenfalls in Phasen durchgeführt werden und stellten somit keine Beeinträchtigung des Gesamtprozesses dar. Ferner war durch den Einsatz der Standard SAP Inbox („Business Workplace“) die Benutzerschnittstelle entweder bereits bekannt oder aber aufgrund der intuitiven Bedienbarkeit (sehr ähnlich zu den üblichen Mail- oder Groupware Clients) leicht zu erlernen. In dieser Phase wurden ebenfalls die Administratoren des Systems geschult, die in dem sich anschließenden Produktivbetrieb die Einstellung und Wartung des Systems übernehmen. Da in Bezug auf die Administration bewusst eine Trennung zwischen der rein technischen Funktion des Workflows und der mittels Customising einzustellenden (fachlichen) Prozesssteuerung gemacht wurde, mussten sich die (fachlichen) Administratoren der Herausforderung stellen, die Prozesse in allen ihren Facetten verstehen und mithilfe der jeweiligen Prozessverantwortlichen in die Ablaufregeln des Workflows umsetzen zu lernen. 17.4.5 Optimierung In der sich an den GoLive anschließenden Optimierungsphase zu Beginn des Produktivbetriebs wurde das System von den Administratoren fein eingestellt. Der interne Aufwand von etwa zwei Personen-Monaten ist durch die komplexen und variantenreichen Prozesse zu erklären.

240

Automatisierte Stammdatenpflege in der Konsumgüterindustrie

17.5 Komponenten der PLM-Lösung Im Folgenden sollen zwei besonders interessante Teile der implementierten Lösung im Detail vorgestellt werden. Dies ist zum einen die bereits beschriebene generische Workflow-Modellierung, zum anderen das individuell gestaltete Reportingwerkzeug, das sowohl dem am Pflegeprozess beteiligten Anwender als auch dem Prozesskoordinator einen einfachen aber dennoch umfassenden Überblick über einen oder mehrere Prozesse ermöglicht. 17.5.1 Workflow-Modellierung Konventionelle Workflow Modellierung bildet Prozesse üblicherweise nach einer einfachen Vorschrift ab. Häufig erfolgt eine direkte Umsetzung im Verhältnis 1:1, was bedeutet, dass für jeden Prozessschritt, wie er bspw. in einer EPK (ereignisgesteuerte Prozesskette) abgebildet ist, ein entsprechender Workflowschritt angelegt wird. Dieses Vorgehen ermöglicht eine beschleunigte Umsetzung von Prozessen in technische Systeme und liefert einfach einzustellende, transparente und sicher zu betreibende Lösungen. Wenn nun die zu unterstützenden Prozesse nicht ohne weiteres in einer übersichtlichen und vollständigen Form dargestellt werden können, sei es, weil sich sehr viele Ablaufvarianten ausbilden können oder komplexe Regeln die Bearbeiter bestimmter Aufgaben bestimmen, stößt das im vorherigen Absatz beschriebene (geradlinige) Vorgehen schnell an seine Grenzen. Alternativ hierzu bietet sich eine technische Umsetzung an, die nicht aus einer 1:1-Umsetzung der Prozesse besteht, sondern zunächst versucht, einheitliche Strukturen im Prozess zu identifizieren, die unter allen (oder zumindest den meisten) Umständen gleich bleiben. Varianten oder komplexe Regeln aber werden in der technischen Umgebung nicht ausmodelliert, sondern in ein Regelwerk übersetzt. Somit entsteht auf der technischen Ebene ein generischer Ablaufplan, der mittels Customising an die realen Bedingungen angepasst wird, und bei dem ein mehr oder weniger komplexes Regelwerk die Steuerung übernimmt. Die Herausforderung einer solchen Vorgehensweise ist zum einen die Identifikation der allgemeingültigen Prozessfragmente, zum anderen die Definition einer handhabbaren Benutzerschnittstelle, um das eigentliche Prozesswissen in technische Regeln zu überführen. Sind diese beiden Voraussetzungen erfüllt, entstehen hieraus Systeme, die mit einem geringen Modellierungsaufwand für den Basisprozess sowie einem höheren Aufwand für die Steuerungsmechanik ein Optimum an Flexibilität und Wartungsfreundlichkeit bieten. Ist ein solches System nämlich erst einmal korrekt eingestellt, können auf einfachste Weise Änderungen am Prozessablauf oder der Bearbeiterfindung vorgenommen werden, die bei einer 1:1Modellierung im ungünstigsten Fall einen tiefen Eingriff in ein komplexes und unübersichtliches Prozessungetüm darstellten. Im vorliegenden Fall konnten sowohl Basisprozesse (auf zwei verschiedenen Modellierungsebenen im Workflow) identifiziert werden als auch eine geeignete Parametrisierung gefunden werden, die zu dem oben postulierten Optimum an Flexibilität und Wartungsfreundlichkeit führte.

Komponenten der PLM-Lösung

241

Die beiden Modellierungsebenen sind (wie im Abschnitt 17.4.2 bereits erwähnt): x Obere Ebene: Prozesssteuerungsebene oder Ablaufplan, in der z. B. festgelegt wird, in welcher Reihenfolge die verschiedenen Sichten des Materialstammes gepflegt werden, an welchen Stellen der Materialstatus gesetzt wird oder Stücklisten oder kundeneigene Objekte gepflegt werden sollen. x Untere Ebene: In diesem Arbeitsprozess werden einmalig alle Arbeitsfunktionalitäten definiert, wie  Ausführung eines Dialogschritts zur Bearbeitung von Objekten, wie z. B. Pflege einer bestimmten Materialstammsicht, Pflege einer Stückliste, etc.  Ausführung von Hintergrundaktivitäten, wobei dem Anwender lästige oder fehleranfällige aber sinnvoll automatisierbare Aktivitäten abgenommen werden  Bearbeiterfindung, die bestimmt, welchem oder welchen Bearbeitern ein Dialogschritt zugestellt wird. Hier können natürlich sowohl einzelne Personen als auch Gruppen angesprochen werden.  Schrittsteuerung, die festlegt, ob ein Schritt überhaupt ausgeführt wird (z. B. keine Stücklistenpflege für Rohstoffe).  Fehlerhandling, das für die Funktionen Dialogschrittbestimmung, Bearbeiterfindung und Hintergrundaktivität eine Ausnahmebehandlung regelt. Diese erfolgt in der Regel dadurch, dass einem fachlichen Administrator ein Arbeitsauftrag mit der jeweiligen Fehlerbeschreibung zugestellt wird, damit ein ggf. vorliegendes Problem (Customisingfehler, geänderter Prozess, ausgeschiedener Mitarbeiter, etc.) zeitnah und fachkundig behoben werden kann. Hierdurch ist sichergestellt, dass kein Fehler übersehen wird. Hier wurde bewusst zwischen fachlichen und technischen Problemen des Workflow unterschieden, letztere werden wie üblich von Basisbetreuern übernommen, die häufig nur einen geringen Bezug zu den fachlichen Fragestellungen haben. Dieser Arbeitsprozess (Subprozess) ist für sämtliche Prozessschritte (die auf der Prozesssteuerungsebene definiert wurden) gleich. Er wird jedoch je nach Anwendungsfall unterschiedlich parametrisiert aufgerufen und bestimmt sämtliche benötigten Informationen wie zu rufende Transaktion, zu benachrichtigende Bearbeitergruppe, etc. mittels des umfangreichen Regelwerks. Als Parameter zur Steuerung der beschriebenen Stellgrößen dienen neben Materialart, Sparte, Werk, Ladegruppe, Berechtigungsgruppe, Produkthierarchie und weiteren auch etliche kundeneigene Datenfelder. Für jede der Stellgrößen Bearbeiterfindung, Sichtenauswahl und Vorder-/ Hintergrundsteuerung werden jeweils 8 – 10 Parameter in einem eigenen Regelwerk ausgewertet. Die folgenden Abbildungen zeigen zunächst einen Ausschnitt aus der oberen (Prozesssteuerungs-) Ebene (Abb. 120). Hier sind z. B. Aufrufe des Subprozesses für die Pflege der Vertriebs-, Dispo- und QM-Sichten des Materialstamms zu erkennen. In Abb. 121 ist die komplette untere Ebene (Arbeitsprozess) gezeigt, was einen Eindruck von der Prozesskomplexität gibt.

242

Automatisierte Stammdatenpflege in der Konsumgüterindustrie

Abb. 120. Ausschnitt aus der Prozesssteuerungsebene

Abb. 121. Arbeitsprozess

Komponenten der PLM-Lösung

243

17.5.2 Prozessmonitoring Wie oben bereits erwähnt, sollte ein Reportingwerkzeug bereitgestellt werden, das zwei sich widersprechenden Anforderungen gerecht werden musste: x Das Werkzeug musste sowohl für den Anwender, der am Pflegeprozess beteiligt ist, als auch für den Prozesskoordinator oder die fachlichen Administratoren eine hohe Informationsdichte bereitstellen aber andererseits auch x die vom Betriebsrat mit Nachdruck geforderte Anonymisierung in Bezug auf UserID's, Datumseinträge und Uhrzeiten sicherstellen (Stichwort hier: Leistungs- und Verhaltenkontrolle). Es wurde schnell deutlich, dass die standardisierten Auswertungsmöglichkeiten des SAP Workflows nicht genügend verdichtete Informationen liefern. Ferner geben sie zu viele persönliche Daten der Anwender preis, so dass eine Eigenentwicklung unabdingbar war. Die gefundene Lösung zeigt nach bestimmten Selektionsparametern wie Materialnummer, Werk oder Vertriebsweg die in der Pflege befindlichen Materialien in einer Liste an. Neben dem Langtext des Materials werden, in Spalten angeordnet, mittels Symbolen die jeweiligen Pflegezustände der Materialien an Hand von Icons dargestellt. Da diese Informationen nicht mittels einer Datenbankselektion beschafft, sondern während des Prozessablaufs in separate Tabellen geschrieben werden, sind diese Informationen stets aktuell und, auch bei großen Datenmengen, äußerst performant anzuzeigen.

Abb. 122. Individuelles Reportingwerkzeug

244

Automatisierte Stammdatenpflege in der Konsumgüterindustrie

17.6 Ergebnisse des Projektes Die folgende Zusammenfassung zeigt auf, in welchen Bereichen deutliche Verbesserungen erzielt wurden: x Die Prozesssicherheit wurde erheblich gesteigert, Pflegereihenfolgen werden nun automatisch eingehalten und es werden keine Aktivitäten mehr übersehen. Die Möglichkeiten der Bearbeiter, die Pflegevorschriften gewollt oder ungewollt zu umgehen, sind stark eingeschränkt worden. x Es wurde eine optimale Prozesstransparenz erreicht, da sowohl die Mitarbeiter im Rahmen des Pflegeprozesses als auch die Prozessverantwortlichen jederzeit den Pflegezustand und die komplette Historie des Prozesses überblicken können. Hierdurch konnte für alle Beteiligten das Bewusstsein für den Prozess in seiner Gesamtheit geweckt werden (im Gegensatz zu den Prozessfragmenten in der ursprünglichen Pflege). x Neben der Prozesstransparenz wurde nun erstmalig auch eine völlige Transparenz der Pflegevorschriften selbst geschaffen, da diese an zentraler Stelle im System abgelegt und jederzeit einsehbar sind. x Die Datenqualität konnte wesentlich verbessert werden, da die Arbeitsaufträge immer zeitnah an den jeweils verantwortlichen bzw. am besten qualifizierten Mitarbeiter gesendet werden. x Durch eine deutliche Reduzierung von Suchaufwand, vor allem durch die konsequent angewandte Personalisierung der Arbeitsaufträge sowie die Entlastung der Mitarbeiter von Routineaktivitäten wie z. B. Terminverfolgung und wiederkehrende identische Pflege bestimmter Daten, konnte eine erhebliche Arbeits- und Kosteneinsparung realisiert werden. Ferner ist die Eingliederung neuer Mitarbeiter deutlich erleichtert worden, da weniger Trainingsmaßnahmen benötigt werden. x Durch das effektive Fehlerhandling, bei dem jedes (inhaltliche) Problem automatisch bei den fachlichen Administratoren landet, ist eine kontinuierliche Verbesserung der Prozesse sichergestellt, da sowohl Fehler im Prozess als auch solche durch falsche Bearbeitung unmittelbar auffallen. So können z. B. unsichere Mitarbeiter direkt angesprochen werden und Probleme frühzeitig durch Schulung oder Abstimmung beseitigt werden. x Die klare Trennung zwischen technischer und fachlicher Administration des Systems sorgt dafür, dass weder die Prozessspezialisten mit technischen Problemen belastet werden, noch die Basisbetreuer sich in die für sie fremde Prozesswelt einarbeiten müssen. Somit liefert die auch hier sauber vollzogene Arbeitsteilung die besten und zeitnahsten Problemlösungen. Unter der äußerst konservativen Annahme, dass das Projekt weniger als 30% Verbesserung in der Stammdatenpflege bringt, berechnet sich die Amortisationszeit der Projektes mit einem ungefähren Aufwand von € 220 000 zu 7 Monaten.

Ergebnisse des Projektes

245

Die Fehlerbehebung bei unpassendem Customising, z. B. durch geänderte Prozesse, erfordert zwischen 1h und 3h pro Woche und wird durch den internen (fachlichen) Administrator übernommen. Die kontinuierlich anfallenden Wartungs- und Kontrollarbeiten, die für jedes Workflowsystem mit einkalkuliert werden müssen, liegen bei 1h pro Woche und sind damit vergleichsweise gering, was für ein stabiles Workflow Design spricht.

18 Spezifikation von Produkten in der Stahlindustrie

Der hier im Fokus stehende Gesamtkonzern entstand durch den Zusammenschluss mehrerer Einzelkonzerne. Er erwirtschaftet in mehr als 60 Ländern mit über 110 000 Beschäftigten aktuell einen Umsatz von etwa 35 Mrd. Euro. Um dies zu erreichen, werden ca. 50 Mio. t Stahl erzeugt. Um den Herausforderungen eines weltweit operierenden Unternehmens mit den ebenfalls weltweit agierenden Kunden begegnen zu können, müssen insbesondere die Produktdaten und Stahlspezifikationen allen Unternehmensbereichen in einheitlicher Form zur Verfügung stehen. Die Definition und Einführung eines solchen Produktkataloges sowie der damit in Zusammenhang stehenden Prozesse Produktspezifikation und Angebotserstellung werden in dieser Fallstudie dargestellt.

18.1 Ausgangssituation Insbesondere durch den Zusammenschluss der Unternehmen ergab sich die Notwendigkeit, die Prozesse zur Kundenanfrage- und Auftragsabwicklung sowie zur eigentlichen Stahlspezifikation zu harmonisieren. Des Weiteren mussten in diesem Zusammenhang auch die Stahlspezifikationen selbst vereinheitlicht und in einen gemeinsamen Katalog zusammengeführt werden, um unternehmensweit mit Hilfe einer einheitlichen Stahlbeschreibung einen Gesamtüberblick über die produzierten Stahlsorten zu erlangen und gleichzeitig diese Informationen für die Entwicklung zukünftiger Produkte zu verwenden. Nachdem bereits in einzelnen Teilbereichen des Konzerns grundsätzliche Entscheidungen für die Einführung von Standardsoftware gefallen waren und die kaufmännische Abwicklung im Gesamtkonzern bereits mit SAP R/3 durchgeführt wurde, wurde zur Abwicklung des technischen Spezifikationsprozesses ebenfalls SAP R/3 als strategische Plattform ausgewählt. Allerdings sollten die Werke nach wie vor autark arbeiten können, d. h. es sollte zu dem Spezifikationskatalog eine definierte Schnittstelle entwickelt werden, an die sich jedes Werk bzw. jede Organisationseinheit andocken kann.

248

Spezifikation von Produkten in der Stahlindustrie

18.2 Ziele des PLM-Einsatzes Die Spezifikation neuer Stahl-Produkte durch die metallurgischen Experten findet in enger Abstimmung mit dem Kunden statt. Dabei bedeutet Spezifikation in erster Linie die Festlegung physikalischer Eigenschaften. Diese Spezifikation wurde teilweise zentral für weltweit operierende Großkunden durchgeführt, teilweise direkt von den lokalen Werken. Damit fehlte dem Unternehmen die Übersicht über das Produktangebot. Dies ist aber gerade in einem Großkonzern notwendig, um bzgl. der Produkte und Produktionsstätten strategische Entscheidungen fällen zu können. Daher wurden als Projektziele bei der Einführung des unternehmensweiten Produktkataloges definiert: 1. Prozesssicherheit x Standardisierung der Geschäftsprozesse für Anfrage- und Auftragsbearbeitung x Standardisierung zur Klärung von technischer Machbarkeit x Unterstützung bei der Suche nach vorhandenen Spezifikationen und deren Änderung 2. Transparenz x Unternehmensweit einheitliche Produktbeschreibung x Verfügbarkeit vollständiger und aktueller Spezifikationen x Vergleichbarkeit der Spezifikationen x Austausch von Spezifikationen zwischen Werken x Soll-Ist-Vergleiche für Ziel- und Angebotsspezifikation x Einfache Machbarkeitsprüfung und Vergleich der Machbarkeiten 3. Kosteneinsparung x Übersicht über das angebotene und produzierte Produktspektrum als Basis für die zukünftige Produktstrategie x Auswertung des Angebotsspektrums zur Entscheidung über Produktionsverlagerungen x Zukunftsweisende Standardtechnologie zur Produktspezifikation

18.3 Projektablauf und Projektorganisation Um eine effiziente Definition und Einführung des unternehmensweiten Produktkataloges zu gewährleisten, wurde zunächst ein Business Blueprint erstellt. Im Rahmen dieses Blueprints wurden die Kernprozesse und Anforderungen analysiert.

Komponenten der PLM-Lösung

249

Auf dieser Basis wurden SAP-Module ausgewählt und grob spezifiziert. Der Netweaver-Technologie kam dabei eine besondere Rolle zu, da sie die Möglichkeit bot, auch unternehmensspezifische Anforderungen, die im SAP-Standard nicht enthalten sind, zu integrieren. Die Projektdokumentation setzte sich zusammen aus organisatorischen, fachbereichsspezifischen sowie IT- und SAP-bezogenen Lasten- und Pflichtenheften und erfolgte nach dem im Konzern vorgegebenen Standard. Das Projekt-Team setzte sich zusammen aus: x Fachbereichs-Experten x Vertretern der Informatik-Abteilung x Vertretern der IT-Abteilung x SAP-Basisteam x Externen Coachs Darüber hinaus wurde ein Projektleitungsgremium gebildet, das aus dem Projektleiter aus der Informatik-Abteilung sowie dem externen Projektleiter des CoachTeams und einem Assistenten bestand. In kritischen Fragen wurden die Fachbereichs-Experten sowie der Projektauftraggeber hinzugezogen. Diese Gliederung spiegelt auch die generelle Projektvorgehensweise wider. Für jedes Lösungspaket wurden, sofern notwendig, mehrere Alternativen evaluiert und dem Fachbereich vorgestellt. Nach Abwägen der Für und Wider sowie des Aufwands und der Konsequenzen wurde dann die beste Alternative ausgewählt und implementiert. Dieses Vorgehen ermöglichte eine schnelle Reaktion auf wechselnde Randbedingungen.

18.4 Komponenten der PLM-Lösung Nachfolgende Graphik verdeutlicht die einzelnen Bausteine der PLM-Lösung: x Management des Kundenanfrage- und Angebotsprozesses mit der Verbindung von technischen und kaufmännischen Daten sowie der Spezifikationen x Auswahl einer geeigneten Angebotsspezifikation aus einer Datenbank von Referenz-Spezifikationen x Repräsentation der Zielspezifikation mit den werks- und kundenspezifischen Parametern, wie z. B. Gewicht, Abmessungen eines Coils etc. x Repräsentation der neutralen Spezifikation ohne werks- und kundenspezifische Parameter x Abbildung von Machbarkeiten, d. h. der technischen Möglichkeiten der Werke x Management von Regeln für Kundenverhalten und Abhängigkeiten der Produktspezifikation

250

Spezifikation von Produkten in der Stahlindustrie

ReferenzDatenbank

Produktanfrage Kunden-Spezifikation

Näherungssuche

Technische Ziel-Spezifikation

Neutrale ProduktSpezifikation

Machbarkeit

Regeln bzgl. Kunden und Produkten

Abb. 123. IT-Funktionsmodule im Spezifikationsprozess

Zur Umsetzung der Lösung wurden folgende SAP-Module ausgewählt: x SAP PLM EH&S: Als einheitliches Spezifikationssystem zur Repräsentation von Referenzen des Produktangebotes wurde die Spezifikationsdatenbank des Moduls EH&S (Environment, Health and Safety) implementiert. In einer Spezifikationshierarchie werden etwa 600 Spezifikationsparameter verwaltet. x SAP iPPE: Zur Repräsentation der Kundenanfrage und der angebotenen Alternativen wurde die iPPE (Integriertes Produkt- und Prozess-Engineering) eingesetzt. Für den Spezifikationsprozess sowie die Datenübergabe an andere Werke oder Kunden ist die Existenz von Materialstämmen nicht notwendig. Daher konnte hier die Flexibilität der iPPE genutzt werden, um die verschiedenen Spezifikationen und Status abzubilden. x SAP PLM DVS: Das Dokumentenmanagement wird zur Verwaltung der zu den Spezifikationen gehörenden Unterlagen wie Normen sowie zur Ablage

Komponenten der PLM-Lösung

251

der Machbarkeitsdiagramme genutzt. Zusammen mit einer Klassifizierung und entsprechenden Objektverknüpfungen kann der Anwender sehr einfach auf alle Unterlagen zugreifen. x WAS: Auf alle von SAP verwalteten Daten kann über den Web Application Server (WAS) zugegriffen werden. Der WAS ist Teil der NetWeaverArchitektur und bietet die Möglichkeit, auf SAP Daten und Funktionen über einen Browser zuzugreifen. Mit Hilfe der WAS-Schnittstelle können so Spezifikationen, Dokumente, Machbarkeitsdiagramme und angebotene Spezifikationen im Browser dargestellt werden. Diese Möglichkeit wurde aus Ergonomie- und Kostengründen gewählt. Nur die Personen, die aktiv Spezifikationen und Dokumente erzeugen oder ändern, arbeiten mit dem SAP GUI. Alle anderen, die nur Informationen abrufen, per Mail versenden und ausdrucken, greifen über das Web-Interface auf die SAP-Daten zu. Das hat sowohl den notwendigen Schulungsaufwand als auch den Aufwand zum Aufbau eines Berechtigungskonzeptes drastisch reduziert. Des Weiteren war die Benutzerakzeptanz durch das bekannte Medium Internet direkt gegeben. x Eine externe Regelmaschine wurde für technische und kunden-bezogene Regeln sowie für Regeln zur Entscheidungsunterstützung eingeführt und auf der Basis von NetWeaver an SAP gekoppelt. So können Spezifikationen von der Regelmaschine generiert und ausgewertet werden. Steel Application Automotive as requested spec_A

Application Household Appliance as ordered spec_B

as requested spec_B as produced Site XYZ, spec_C

Product Classes: automotive, construction, household appliances, packaging

Views: customer requests, product specification, commercial view, manufacturing view

Functional Structure: referential specification, common generic specification, ...

Material/Specification: dimensions, quality, surface, ...

Documents: documents, diagrams, ...

Abb. 124. Abbildung der Stahlspezifikation in einer iPPE-Struktur zur Unterstützung des Angebotsprozesses

252

Spezifikation von Produkten in der Stahlindustrie

18.5 Ergebnisse des Projektes Diese PLM-Lösung wurde innerhalb von 2 Jahren entwickelt und im gesamten Konzern ausgerollt. Der Kunde hat folgenden Nutzen aus dem Produktkatalog und damit in Zusammenhang stehenden Funktionen ziehen können: x Der Katalog bietet eine Übersicht über das gesamte Produktspektrum. x Die Standardisierung der Spezifikationen sorgt für eine verbesserte Stammdatenqualität, die generell Grundlage und Erfolgsfaktor für standardisierte Geschäftsprozesse ist. x Die um den Katalog implementierten Anfrage- und Spezifikationsprozesse liefern eine deutliche verbesserte Qualität der Angebote und reduzieren die Kosten für die Anfragebearbeitung. x Die zentral verfügbare und standardisierte Datenbank für die Spezifikationen der Referenzdaten und Produkte dient dem Unternehmen als Basis für strategische Entscheidungen. x Die einheitliche Spezifikation sorgt für eine verbesserte Flexibilität in der Produktion und beschleunigte Kunden-Service-Prozesse. x Durch die Standardisierung der Prozesse und Implementierung in SAP können die Anfrage- und Spezifikationsprozesse nachvollzogen werden. x Durch den Coaching-Ansatz konnte das Kundenteam sehr schnell Aufgaben in eigener Regie ausführen; dieser Know-how-Transfer war nur durch die gute Zusammenarbeit zwischen Coach und Projektteam möglich.

19 Produktentwicklung bei einem Feinchemikalienhersteller

Diese Fallstudie berichtet von der Einführung einer PLM-Lösung bei einem Feinchemikalienhersteller, der mit etwa 4000 Mitarbeitern an 18 internationalen Produktions- und Entwicklungsstandorten vertreten ist. Als Teil eines großen internationalen Konzerns ist er durch die Fusion mehrerer Unternehmen entstanden. Durch die räumliche Zergliederung und den unterschiedlichen Ursprung der Standorte stellen einheitliche, transparente und schnelle Prozesse in der Produktentwicklung eine besondere Herausforderung dar, die den Geschäftserfolg entscheidend beeinflusst. Die mangelnde Transparenz führte z. B. in der Vergangenheit dazu, dass Kundenanfragen abgelehnt wurden, da an einem Standort keine passenden Produktionsstätten existierten, obwohl die Anfrage an anderen Standorten sehr wohl hätte bedient werden können. Das durchgeführte Projekt diente somit dem Ziel, einheitliche Prozesse und Tools in der Auftragsabwicklung und Produktentwicklung einzuführen und damit Transparenz über Kundenanfragen und Auftragsentwicklungen zu bekommen. Dazu waren etwas 500 Anwender in den Produktentwicklungsprojekten mit einer Lösung zu unterstützen.

19.1 Ziele des PLM-Einsatzes Der Geschäftserfolg bei der Herstellung von Feinchemikalien ist stark abhängig von der Schnelligkeit der Produktentwicklung und der Bearbeitung von Kundenanfragen sowie von Kosteneffizienz, Transparenz und Qualität. Der betrachtete Prozess ist eine kundenspezifische Auftragsabwicklung mit anschließender Produktentwicklung und Herstellung. Nach der Kundenanfrage wird zunächst geprüft, ob der Auftrag abgewickelt werden kann. Entscheidende Faktoren sind hierbei z. B. ob entsprechende Produktionslinien zur Verfügung stehen, der Auftrag gewinnbringend ist oder wie sich die Nachfrage nach dem Produkt in Zukunft entwickeln kann. Wird der Auftrag angenommen, beginnt die Produktentwicklung, falls nicht bereits der Kunde entsprechende Synthesewege zur Herstellung liefert. Die Entwicklung / Produktion ist in der Regel dreistufig: Entwicklung im Labor-Maßstab, Entwicklung Kilolabor und schließlich die Umsetzung in der Produktionslinie. Projektziel war die Optimierung der Produktentwicklung durch eine Lösung zur Verbesserung des gesamten Prozesses von der Kundenanfrage über Forschung, Entwicklung, Pilotierung und Produktion bis hin zur Auslieferung. Erreicht wer-

254

Produktentwicklung bei einem Feinchemikalienhersteller

den sollte eine Verbesserung hinsichtlich Durchlaufzeit, Transparenz, Kosteneffizienz und Qualität des Prozesses. Die Anforderung an ein PLM-Tool war, alle Daten von der ersten Anfrage bis hin zur Auslieferung des Produktes zu verwalten und allen Beteiligten zugänglich zu machen. Zu diesen Daten gehören Kundeninformationen, Anfrage- und Auftragsinformationen sowie die gesamte Dokumentation der Entwicklung und Produktion incl. Dokumente und Synthesewege. Zu jedem Projekt (Kundenanfrage) sollten darüber hinaus Projektbudgets vergeben und Kosten ermittelt werden. Die Steuerung und Kontrolle der einzelnen Projektphasen sollte durch das Tool gewährleistet werden, zu allen abgeschlossenen Projekten sollten die wesentlichen Projektinformationen zu jeder Zeit recherchierbar vorgehalten werden.

19.2 Vorgehensweise im Projekt Die Projektdurchführung gliederte sich in die folgenden Phasen: x Definition und Priorisierung der Anforderungen x Evaluierung verschiedener auf dem Markt befindlicher Standardsoftware x Feinkonzept zur Erstellung einer Individuallösung x Softwarespezifikation x Implementierung x Tests x Schulung der Key User x Pilotphase x Rollout Das Projektteam befasste sich zunächst mit der Definition und Priorisierung der Anforderungen. Diesem Projektteam gehörten Vertreter aus allen beteiligten Bereichen wie Marketing, Produktion, F&E, FI&CO an. Nach der Prüfung am Markt befindlicher Tools war relativ schnell deutlich, dass keines die Anforderungen in befriedigendem Maße erfüllt. Aus diesem Grund wurde die Realisierung auf Basis SAP R/3 geprüft. Nach dem Aufzeigen der Machbarkeit durch ein Grobkonzept wurde ein Feinkonzept erstellt. Auf Grundlage des Feinkonzepts wurde dann eine Softwarespezifikation erstellt. Die Implementierungsphase dauerte 6 Monate und wurde von 8 Softwareentwicklern durchgeführt. Die Testphase untergliederte sich klassisch in die Entwicklertests, Funktionstests und Integrationstests. Die Funktionstests und die Integrationstests wurden von speziell geschulten Key Usern durchgeführt. Diese Key User schulten im weiteren Verlauf die Endanwender. In der zwei Monate dauernden Pilotphase überprüften die Key User das Tool auf Roll-Out-Fähigkeit. Anschließend folgte der Roll-Out in alle Standorte.

Komponenten der PLM-Lösung

255

Neben der fachlichen Herausforderung stellte dieses Projekt besondere Anforderungen an das Projekt-Marketing. In den vielen verschiedenen Standorten waren zum Teil sehr unterschiedliche Vorgehensweisen und Tools für den Prozess entstanden. Einige Standorte hatten bereits mit der Entwicklung eines eigenen Tools begonnen. Durch fortlaufende Einbeziehung der Endanwender gelang es, eine Akzeptanz für das neue Tool zu erreichen.

19.3 Komponenten der PLM-Lösung Um das Look & Feel des Intranet in dem neuen Tool zu verwirklichen und eine Softwareunabhängigkeit auf Client-Seite zu gewährleisten, wurde eine browserfähige HTML-Oberfläche als Benutzerinterface gewählt. In dieser Oberfläche wurden die Dialoge zur Bearbeitung eines Projektes von der Kundenanfrage bis zur Auslieferung programmiert. Die Business-Logik befindet sich in SAP R/3 und bedient sich größtenteils der Standardmodule und -funktionen wie z. B. Projektverwaltung (SAP PS), Dokumentenverwaltung (SAP DVS), SAP Finance und Controlling (SAP FI/CO) sowie dem Modul SAP EH&S zur Verwaltung von Spezifikationen.

Anfrage / Idee

Marketing

Entwicklung + Produktion

?

Auslieferung

! Laborphase

Pilotproduktion

Evaluation Kilolabor- Produktionslinie phase

Abb. 125. Schematische Darstellung des Produktentwicklungsprozesses

Der Prozess gliedert sich in 7 Phasen, welche workflowunterstützt bearbeitet werden und im SAP-Projektsystem als Elemente der Projektstruktur definiert sind. Im Rahmen der Evaluierung eines Projektes werden neben reinen Kundendaten auch zahlreiche Marktdaten zu einer Anfrage erfasst. Diese werden anschließend unter anderem über diverse Kennzahlen wie z. B. Ergebnispotenzial, Kundenattraktivität oder technologischer Fit bewertet. Anhand verschiedener Checklisten

256

Produktentwicklung bei einem Feinchemikalienhersteller

folgt die Bearbeitung der relevanten F&E-Phasen. Ein Steering Committee entscheidet softwaregestützt über alle Phasen eines Projektes (Zeit, Budget, Ressourcen, Maßnahmen). Der speziell entwickelte Workflow erlaubt in Abhängigkeit der Erfordernisse beliebige Phasenkombinationen, bei ständiger Projektverfolgung. Neben dem reinen Projektmanagement umfasst das Tool auch ein Dokumentmanagement-System auf Basis SAP DVS, welches es ermöglicht, alle zu einem Projekt erzeugten Dokumente oder Freitexte gezielt an den zugehörigen Phasen / Checklistenpunkten oder Meilensteinen abzulegen. Integriert ist für alle Phasen die Dokumentation beliebig komplexer Synthesewege, welche mit dem integrierten Tool Chemdraw direkt in der HTMLOberfläche gezeichnet werden können. Über eine Suchmaschine werden sowohl Volltextsuche als auch Struktur- bzw. Substruktursuche kombiniert. Über einen einzigen Suchbefehl können somit alle Freitextelemente, Dokumente und sämtliche Synthesewege nach der gewünschten Information durchsucht werden. Dies macht das Tool zu einem leistungsfähigen Knowledge-Management-System.

19.4 Ergebnisse des Projektes Folgende Verbesserungen wurden durch die Vereinheitlichung des Prozesses und durch das Tool erreicht: x Transparenz über alle Kundenanfragen und Projekte x Vergleichbarkeit der Projekte x Steuerung aller laufenden Projekte durch ein Steering Committee x Ermöglichen eines Projekt-Portfoliomanagements x Zentrale Dokumentation aller Projekte x Schaffung einer Knowledge Base zu Recherchezwecken x Kostenerfassung, Kostentransparenz

Literaturverzeichnis

[1] [2] [3] [4]

[5]

[6] [7] [8]

[9]

[10] [11] [12] [13] [14]

[15]

ANSI IGES. Initial Graphics Exchange Specification Version 6.0, ANSI Standard Allen, T. 1987. Managing the Flow of Technology, Cambridge, MA, MIT Press 1987 Berth, R.: Der kleine Wurf, Manager Magazin 23/1993, S. 214 – 227 Bratthall, L.; Hasselberg, J.; Hoffmann, B.;. Korendo, Z; Schilli, B; Gundersen, L.: Component Certification – What is the Value?, 4th International Conference on Product Focused Software Process Improvement, Rovaniemi, Finland, December 2002 Bullinger, H.J.: Forschungs- und Entwicklungsmanagement in der deutschen Industrie, in: A.-W. Scheer (Hrsg.), „Simultane Produktentwicklung“, München 1992 Bullinger, H.J.; Scheer, A.-W. (Hrsg.): Service Engineeering, Springer, Berlin 2003 Corsten, Hans: Lexikon der Betriebswirtschaftslehre, 2. Aufl., R. Oldenbourg Verlag, München 1993 Dai, F.; Schilli, B.: Collaborative Engineering with OEM customers in the new age of information and communication technologies, Conference on concurrent engineering, Madeira, Portugal, July 26 – 30, 2003 Dünser, T.; Meier, M.: „Towards a system model to improve the quality of decisions“, International Design Conference – Design 2004, 18th – 21st May 2004, Dubrovnik, Croatiat al. 1984 Eigner, M.: Engineering Database – Strategische Komponente in CIMKonzepten, Hanser Verlag, München 1991 Eisert, U. et. al.: mySAP Product Lifecycle Management, SAPPress, Bonn 2000 Franke, H.-J. et. al.: Variantenmanagement in der Einzel- und Kleinserienfertigung, Hanser Verlag, München 2002 Gochermann, Josef: Kundenorientierte Produktentwicklung. Marketingwissen für Ingenieure und Entwickler, Wiley-VCH, Weinheim 2003 Grabowski, H.: Entwerfen in Konstruktionsräumen zur Unterstützung der Teamarbeit. in: A.-W. Scheer (Hrsg.), „Simultane Produktentwicklung“, München 1992 Grabowski, H.; Lossack, R.; Weißkopf, J.: Datenmanagement in der Produktentwicklung. Hanser Verlag, München 2001

258

Literaturverzeichnis

[16] Gutenberg, E.: Der Absatz, in: „Grundlagen der Betriebswirtschaftslehre“, Bd. 2, 17. Aufl., Berlin et al. 1984 [17] Hansmann, K.-W.: Industrielles Management, Oldenbourg Wissenschaftsverlag, München 2001 [18] http://www.cimdata.com, 2005 [19] http://www.i2com.de, 2005 [20] http://www.manufacturing.net/ctl/article/CA421454?industry=Information+ Control&industryid=22071&spacedesc=communityFeatures, Reed Elsevier Inc. 2004 [21] http://www.zpeportal.ethz.ch/research, ETH Zürich, Zentrum für Produktentwicklung [22] „Innovative Produktentwicklungsprozesse durch PLM in der Investitionsgüterindustrie“, Studie der IDS Scheer AG, Saarbrücken 2004 [23] ISO STEP. ISO TC184 SC4. International Standard ISO 10303-1 ff: Standard for the exchange of Product Model Data [24] KGSt (Hrsg.): Das Neue Steuerungsmodell – Begründung, Konturen, Umsetzung, KGSt-Bericht, Köln 5/1993 [25] Klabunde, Steffen: Wissensmanagement in der integrierten Produkt- und Prozessgestaltung. Best-Practice-Modelle zum Management von Meta-Wissen, Deutscher Universitäts-Verlag, Wiesbaden 2003 [26] Krantz, L. 2000. Industrial IT – the next way of thinking, ABB Review, 2000/01, 2000 [27] Krottmaier, J.: Leitfaden Simultaneous Engineering. Springer, Berlin 1995 [28] Kurbel, K.: Produktionsplanung und -steuerung: methodische Grundlagen von PPS-Systemen und Erweiterungen, 4. Aufl., Oldenbourg Wissenschaftsverlag, München 1999 [29] Langenwalter, G. A.: Enterprise Resources Planning And Beyond – Integrating your entire organization. St. Lucie Press, Boca Raton 2000 [30] Lindemann, U.; Reichwald, R.: Integriertes Änderungsmanagement, Springer, Berlin 1998 [31] Mansfield, E., Raporport, J., Schnee, J., Wagner, S., Hamburger, M.: Research and Innovation in the Modern Corporation. Macmillan, London 1972 [32] Nowak, T. 2002, et. al. Synchronous collaborative design system – functionality and architecture, 9th ISPE international conference on concurrent engineering, Cranfield University, United Kingdom, 27 – 31 July, 2002 [33] OAG 2004, Open Application Group – Best Practices and XML Content for Everywhere-to-Everywhere Integration, OAGIS 8.0, www.openapplications.org/OAGIS [34] OPENTrans 2003, eCommerce Initiative of German Industry, Standard OPENTrans 1.0, www.opentrans.de

Literaturverzeichnis

259

[35] Projektportfolio-Management mit xRPM, Funktionalität, Lösungskonzepte und Einsatzszenarien, Adobe-PDF Präsentation, Internet-Auftritt von Campana & Schott, Frankfurt [36] Reichwald, R.: Marktnahe Produktion. Gabler, Wiesbaden, 1992. [37] SAP Bibliothek – SAP R/3 Enterprise, Online-Doku der SAP, SAP AG, März 2003 [38] SAP Library – SAP cProject Suite 3.10, Online-Doku der SAP, SAP AG, Juni 2004 [39] SAP xRPM Core Business Processes, Referenzmodell zur Nutzung von xRPM der SAP AG, Erscheinungsdatum: 2004, entstanden in Kooperation der SAP AG mit der IDS Scheer, erhältlich unter www.sap.ag. [40] Scheer, A.-W.: CIM. Computer Integrated Manufacturing. Der computergesteuerte Industriebetrieb. 4. Aufl., Springer, Berlin 1990 [41] Scheer, A.-W.: Wirtschaftsinformatik – Referenzmodelle für industrielle Geschäftsprozesse. 7. Aufl., Springer, Berlin 1997 [42] Scheer, A.-W.: ARIS – vom Geschäftsprozess zum Anwendungssystem, 4. Aufl., Springer, Berlin 1998 [43] Scheer, A.-W.: 20 Jahre Gestaltung industrieller Geschäftsprozesse, in: Industrie Management 01/2004, S. 14 – 21. [44] Scheer, A.-W.; Thomas, O.; Seel, C.; Martin, G.; Kaffai, B.: Geschäftsprozessorientierte Software-Architekturen: Revolution auf dem Softwaremarkt? In: Dadam, P., Reichert, M. (Hrsg.): Informatik 2004 – Beiträge der 34. Jahrestagung der Gesellschaft für Informatik e.V., Bonn, 2004, S. 2 – 13. [45] Schilli, B.; Dai, F.: A vision for e-collaboration between Suppliers and OEM customers, Conference on concurrent engineering, Madeira, Portugal, July 26 – 30, 2003 [46] Schilli, B.; Karandikar, H.: Improved collaboration with customers and suppliers by simplifying data exchange through Industrial IT, Annual USPI-NL conference, Amsterdam, March 13th, 2002 [47] Schmid-Vogt, W.; Mayer, J.: Vom Investitionsgut zum gesamtheitlichen Produkt- und Service Life Cycle, in: A.-W. Scheer, F. Abolhassan, W. Jost, H. Kruppke (Hrsg.), „Innovation durch Geschäftsprozessmanagement“, Springer, Berlin 2004 [48] Schöttner, Josef: Produktdatenmanagement in der Fertigungsindustrie, Hanser Verlag, München 1999 [49] Shina et al. 1992 Shina/Markem Corporation, 1992 [50] Von der Heydt, A.: Handbuch Efficient Consumer Response, Vahlen, München 1999 [51] W3C XML, World Wide Web Consortium [52] Woods, Dan: Packaged Composite Applications, O’Reilly & Associates, Sebastopol 2003

260

Literaturverzeichnis

[53] Zellner, Gregor: Beziehungsmanagement im Fokus – Ergebnisse einer empirischen Untersuchung, Universität St. Gallen (HSG), Institut für Wirtschaftsinformatik