prozessorientiertes product lifecycle management

Prozessorientiertes Product Lifecycle Management

August-Wilhelm Scheer · Manfred BoczanskiMichael Muth · Willi-Gerd SchmitzUwe Segelbacher

ProzessorientiertesProduct LifecycleManagementMit Beiträgen vonAndrea Cocchi, Claudia Herzog, Ingo Kern, Harald OkruchAlexander Schadenberger, Bruno Schilli, Momme Stürken

mit 125 Abbildungen und 3 Tabellen

123

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

IDS Scheer AGAltenkesseler Straße 1766115 SaarbrückenE-mail: [email protected]

Manfred Boczanski

Langenbergstraße 1946147 Oberhausen

Privdoz. Dr.-Ing. habil. Michael Muth


Willi-Gerd Schmitz


Dr. rer. nat. Uwe Segelbacher

BMW AGHelene-Mayer-Ring 480788 München

ISBN-10 3-540-28402-8 Springer Berlin Heidelberg New YorkISBN-13 978-3-540-2840-4 Springer Berlin Heidelberg New York

Bibliografische Information Der Deutschen BibliothekDie Deutsche Bibliothek verzeichnet diese Publikation in der Deutschen Nationalbibliografie; detailliertebibliografische Daten sind im Internet über http://dnb.ddb.de abrufbar.

Dieses Werk ist urheberrechtlich geschützt. Die dadurch begründeten Rechte, insbesondere die der Über-setzung, des Nachdrucks, des Vortrags, der Entnahme von Abbildungen und Tabellen, der Funksendung, derMikroverfilmung oder der Vervielfältigung auf anderen Wegen und der Speicherung in Datenverarbeitungs-anlagen, bleiben, auch bei nur auszugsweiser Verwertung, vorbehalten. Eine Vervielfältigung dieses Werkesoder von Teilen dieses Werkes ist auch im Einzelfall nur in den Grenzen der gesetzlichen Bestimmungendes Urheberrechtsgesetzes der Bundesrepublik Deutschland vom 9. September 1965 in der jeweils gelten-den Fassung zulässig. Sie ist grundsätzlich vergütungspflichtig. Zuwiderhandlungen unterliegen den Straf-bestimmungen des Urheberrechtsgesetzes.

Springer ist ein Unternehmen von Springer Science+Business Mediaspringer.de

© Springer-Verlag Berlin Heidelberg 2006Printed in Germany

Die Wiedergabe von Gebrauchsnamen, Handelsnamen, Warenbezeichnungen usw. in diesem Werk berech-tigt auch ohne besondere Kennzeichnung nicht zu der Annahme, dass solche Namen im Sinne der Waren-zeichen- und Markenschutz-Gesetzgebung als frei zu betrachten wären und daher von jedermann benutztwerden dürften.

Einbandgestaltung: design & production GmbHHerstellung: Helmut PetriDruck: Strauss Offsetdruck

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

Vorwort

Globalisierung, steigender Wettbewerbsdruck, kürzere Produktlebenszeiten, zu-nehmende Bedeutung des Erfolgsfaktors Innovation – alles Gründe für Unterneh-men, 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 Kostenein-sparungspotenziale realisieren – nicht mehr nur rein funktions- oder lösungsorien-tiert 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 Kernge-schä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üterin-dustrie 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 Prozessdarstel-lungen keinen Anspruch auf Vollständigkeit oder Allgemeingültigkeit haben. Die Darstellung der Prozesse geschieht auf Basis in ARIS modellierter Referenzmo-delle, 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 ver-breiteten 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 wissen-schaftliche Betrachtung der PLM-Herausforderungen und ein Ausblick auf zu-künftige Softwarearchitekturen. Die Kapitel 2 bis 8 geben einen praxisnahen Überblick über die Kernprozesse von PLM und deren Vernetzung, die Implemen-tierung 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 bedan-ken, 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 PLM im Wandel der Zeit ................................................. 31.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

2 PLM im Überblick ..........................................................132.1 Geschäftsprozesse als Grundlage für PLM.............................................. 152.2 Generische PLM-Prozesse und deren Bedeutung.................................... 162.3 Schwerpunkte in verschiedenen Branchen .............................................. 20

3 Bausteine und Prozesse im PLM .................................273.1 Ein prozessorientierter PLM-Ansatz........................................................ 273.2 Komposition einer integrierten PLM-Lösung.......................................... 343.3 Einführung und Ausbau einer PLM-Lösung............................................ 413.4 Vorteile einer prozessorientierten PLM-Einführung ............................... 423.5 Zusammenfassung .................................................................................... 42

4 PLM und die Kerngeschäftsprozesse des Unternehmens ........................................................434.1 Produktentstehung und strategische Planung........................................... 454.2 Produktentstehung und Vertriebsprozess................................................. 474.3 Integration verschiedener Entwicklungsbereiche und -standorte............ 524.4 Integrierte Produkt- und Prozessentwicklung .......................................... 544.5 Produktentwicklung und Beschaffung ..................................................... 56

VIII Inhaltsverzeichnis

5 Unterstützende PLM-Prozesse / Querschnittsprozesse...................................................615.1 Collaborative Engineering........................................................................ 625.2 Projektmanagement .................................................................................. 635.3 Service und Wartung ................................................................................ 65

6 IT-Bausteine einer prozessorientierten PLM-Lösung...................................................................676.1 Das Produktdatenmanagement................................................................. 676.2 Die frühen Phasen der Produktentwicklung............................................. 916.3 Projektmanagement in der Produktentwicklung...................................... 946.4 Projektportfoliomanagement .................................................................. 1016.5 Qualitätsmanagement ............................................................................. 1056.6 Instandhaltung und Service .................................................................... 1076.7 Workflow als Querschnittsfunktion im PLM ........................................ 110

7 Methoden und Trends .................................................119 7.1 Prototyping.............................................................................................. 1197.2 Simultaneous Engineering...................................................................... 1237.3 Digital Mockup....................................................................................... 1267.4 Collaborative Engineering...................................................................... 1317.5 Digitale Fabrik ........................................................................................ 1337.6 Virtuelle Realität (VR) ........................................................................... 1357.7 Zusammenfassung .................................................................................. 138

8 Zukünftige Strategien von PLM..................................1418.1 Produktentstehung .................................................................................. 1428.2 Produktfertigung..................................................................................... 1438.3 Produktentsorgung.................................................................................. 144

Inhaltsverzeichnis IX

Teil II: Fallstudien aus der Fertigungsindustrie

9 PLM in der Schaeffler-Gruppe....................................147Momme Stürken 9.1 Überblick und Projektziele ..................................................................... 1479.2 CAD-Integration und Stammdaten als Projektherausforderung............ 1489.3 Ausblick .................................................................................................. 150

10 Komplexitäts- und Produktvariantenmanagement bei einem Serienfertiger..............................................15310.1 Ausgangssituation................................................................................... 15310.2 Ziele des PLM-Einsatzes........................................................................ 15410.3 Vorgehensweise im Projekt.................................................................... 15610.4 Projektfazit .............................................................................................. 159

11 Optimierung der Produktentwicklung bei einem Maschinenbauer ..........................................................16311.1 Ausgangssituation................................................................................... 16311.2 Ziele des PLM-Einsatzes........................................................................ 16511.3 Projektvorgehen und Projektorganisation.............................................. 16611.4 Ergebnisse der Konzeptionsphase.......................................................... 16811.5 Komponenten der PLM-Lösung ............................................................ 16911.6 Projektfazit .............................................................................................. 171

12 PLM bei BRP-Rotax GmbH & Co. KG.........................173Harald Okruch und Claudia Herzog 12.1 Das Unternehmen ................................................................................... 17312.2 Ausgangssituation und Vision................................................................ 17412.3 Ziele des PLM-Einsatzes........................................................................ 17512.4 Projektvorgehen und Projektorganisation.............................................. 17612.5 Ergebnisse des Projektes ........................................................................ 17712.6 Projekterfahrung und Ausblick .............................................................. 179

X Inhaltsverzeichnis

13 PLM bei der CARPIGIANI GROUP ..............................181Andrea Cocchi und Alexander Schadenberger13.1 Das Unternehmen ................................................................................... 18113.2 Ziele des PLM-Einsatzes........................................................................ 18113.3 Vorgehensweise im Projekt.................................................................... 18213.4 Ergebnisse des Projektes ........................................................................ 184

14 Importance of Product Design and Data Exchange Standards in the Product Life Cycle .....................................................................185Bruno Schilli und Ingo Kern14.1 Introduction............................................................................................. 18514.2 Status of Collaborative Engineering in the Power and Automation

Industry ................................................................................................... 18614.3 Industrial Prerequisites to Enable Collaborative Engineering............... 18914.4 Portfolio Management for Products, Systems and Services.................. 19014.5 Standardization of Default Product Information.................................... 19114.6 Industrial Use of Standards Along the Product Life Cycle ................... 19314.7 Real-Time Design Collaboration at ABB and Its Supplier

Network................................................................................................... 19414.8 References............................................................................................... 196

Teil III: Fallstudien aus der Prozessindustrie

15 Produktentwicklung bei einem Lebensmittelhersteller ................................................19915.1 Ausgangssituation................................................................................... 199 15.2 Ziele des PLM-Einsatzes........................................................................ 20115.3 Projektmethoden und Projektorganisation ............................................. 20215.4 Projektdurchführung............................................................................... 20215.5 Komponenten der PLM-Lösung ............................................................ 20715.6 Ergebnisse des Projektes ........................................................................ 213

Inhaltsverzeichnis XI

16 Produktentwicklung mit NPDI bei einem Konsumgüterhersteller ...............................................21516.1 Marktsituation Konsumgüterindustrie ................................................... 21516.2 Ausgangssituation................................................................................... 21716.3 Ziele des PLM-Einsatzes........................................................................ 21816.4 Vorgehen im Projekt............................................................................... 21916.5 Das Prozesskonzept NPDI...................................................................... 22016.6 Komponenten der PLM-Lösung ............................................................ 22316.7 Ergebnisse des Projektes ........................................................................ 228

17 Automatisierte Stammdatenpflege in der Konsumgüterindustrie ................................................23117.1 Ausgangssituation................................................................................... 23117.2 Ziele des PLM-Einsatzes........................................................................ 23417.3 Projektmethoden und Projektorganisation ............................................. 23417.4 Projektdurchführung und -ergebnisse .................................................... 23517.5 Komponenten der PLM-Lösung ............................................................ 24017.6 Ergebnisse des Projektes ........................................................................ 244

18 Spezifikation von Produkten in der Stahlindustrie ....24718.1 Ausgangssituation................................................................................... 24718.2 Ziele des PLM-Einsatzes........................................................................ 24818.3 Projektablauf und Projektorganisation................................................... 24818.4 Komponenten der PLM-Lösung ............................................................ 24918.5 Ergebnisse des Projektes ........................................................................ 252

19 Produktentwicklung bei einem Feinchemikalienhersteller ..........................................25319.1 Ziele des PLM-Einsatzes........................................................................ 25319.2 Vorgehensweise im Projekt.................................................................... 25419.3 Komponenten der PLM-Lösung ............................................................ 25519.4 Ergebnisse des Projektes ........................................................................ 256

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

Abbildungsverzeichnis

Abb. 1. Y-CIM-Modell für den Industriebetrieb................................................5Abb. 2. Einordnung von PLM in das Y-CIM-Modell ......................................10Abb. 3. Product Lifecycle Management und Geschäftsprozess-Plattformen ...11Abb. 4. PLM als Bindeglied zwischen den Säulen Produktion und

Produktentwicklung des Y-CIM-Modells ...........................................14Abb. 5. Generische Prozesse des PLM.............................................................15Abb. 6. Prozesslandkarte des PLM ..................................................................16Abb. 7. Kriterienmodell für die Integration von CAD-Systemen.....................17Abb. 8. Collaboration-Prozess in der Automobilindustrie am Beispiel

von Produktdaten.................................................................................18Abb. 9. Prozesslandkarte des Produktentstehungsprozesses am Beispiel

der Automotive-Branche .....................................................................21Abb. 10. Reduzierung vermeidbarer Änderungen durch die Optimierung

von Änderungsprozessen.....................................................................22Abb. 11. Workflowunterstützte Änderungsprozesse schaffen Sicherheit und

Prozesstransparenz ..............................................................................22Abb. 12. Entstehung von Stammdaten entlang des Entwicklungsprozesses ......23Abb. 13. Konsumgüter-Industrie mit Schwerpunkt Innovation und

Produktentwicklung.............................................................................24Abb. 14. PLM Process Lifecycle........................................................................27Abb. 15. PLM-Prozess-Implementierung .........................................................32Abb. 16. PLM-Prozess-Controlling....................................................................34Abb. 17. PLM-Prozesslandkarte ........................................................................36Abb. 18. Prozesse in der Produktentwicklung (Ausschnitt) ...............................38Abb. 19. Prozesslandkarte in der Prozessindustrie (Chemie).............................40Abb. 20. Entwicklung der Organisation in der Produktentwicklung..................44Abb. 21. Das digitale Produkt ............................................................................46Abb. 22. Kostenfestlegung und Kostenverursachung innerhalb der

Teilprozesse der Produktentstehung....................................................55Abb. 23. Prozess- und Datenintegration von der Produktentwicklung in die

Fertigung bis hin zu Instandhaltung und Service.................................56Abb. 24. Frühe Integration von Zulieferern innerhalb der

Produktentwicklung im Automobilbau...............................................57Abb. 25. Schematische Darstellung des Datenaustausches zwischen

Hersteller und Lieferant.......................................................................58Abb. 26. Strukturierung von Produkten aus der Sicht verschiedener

Unternehmensbereiche ........................................................................59

XIV Abbildungsverzeichnis

Abb. 27. Qualitätsmanagement innerhalb von PLM ..........................................61Abb. 28. Collaborative Engineering und Projektmanagement ...........................62Abb. 29. Aufgaben und Prozesse im Projektmanagement .................................64Abb. 30. Dokumentenverwaltungssatz im SAP DMS........................................69Abb. 31. SAP WebDocuments.. .........................................................................71Abb. 32. Visualisierung eines Dokumentenverwaltungssatzes mit dem im

SAP DMS integrierten Viewer.............................................................72Abb. 33. SAP Records Management..................................................................74Abb. 34. Exemplarische Abbildung eines Produktmodells ................................75Abb. 35. Darstellungen einer Stückliste mit ihren Komponenten in SAP..........76Abb. 36. Produktstruktur-Browser in SAP.........................................................78Abb. 37. Klassenhierarchie mit zugeordneten Eigenschaften (Merkmale) ........80Abb. 38. Funktionsprinzip der Variantenkonfiguration .....................................81Abb. 39. Alternative Integrationsszenarien CAD / ERP in einer

SAP-Architektur..................................................................................83Abb. 40. CAD-Direktintegration in SAP ...........................................................84Abb. 41. Änderungsprozess mit typischen Objekten und Beteiligten ................87Abb. 42. Der Lebenszyklus im Konfigurationsmanagement..............................89Abb. 43. Lebenszyklusmappe im Konfigurationsmanagement von SAP PLM....91Abb. 44. Innovationsmanagement-Trichter........................................................93Abb. 45. Erweiterter Konstruktionsablauf Anlagenbau mit Funktionen und

entstehenden Dokumenten...................................................................94Abb. 46. Schwerpunkte des Projektmanagements in Entwicklungsprojekten....95Abb. 47. Die Phasen / Funktionen eines typischen Projektablaufs ....................98Abb. 48. Wertschöpfungskette – Detailbild Projektabwicklung ........................99Abb. 49. Verzahnung von operativem und strategischem

Projektmanagement ...........................................................................102Abb. 50. Kernfunktionen der Projektportfoliomanagement-Lösung xRPM

der SAP. ............................................................................................104Abb. 51. Darstellung des Projektportfolios in der Portfoliomanagement-

Lösung xRPM der SAP AG..............................................................104Abb. 52. Anlagenstruktur im SAP PM mit technischen Plätzen und

Equipements. .....................................................................................108Abb. 53. Workfloweingang mit 5 Arbeitsaufträgen im SAP Business

Workflow ..........................................................................................113Abb. 54. Ablaufschema eines workflowgesteuerten Änderungsprozesses im

Anlagenbau........................................................................................115Abb. 55. Ablaufschema eines netzplanbasierten Workflow.............................116Abb. 56. Verschiedene Prototypen – Proportions-/Ergonomiemodelle ...........120Abb. 57. CAD-Modell und Ableitung für STL-Modell ...................................122Abb. 58. Rapid-Prototyping-Prozesse mit der zugehörigen

Datenkonvertierung und Datenaufbereitung......................................123Abb. 59. Parallelisierung in der Produktentwicklung.......................................125Abb. 60. Produktstruktur und 3D-Baugruppendarstellung...............................126

Abbildungsverzeichnis XV

Abb. 61. Clash-Detection .................................................................................127Abb. 62. Mensch-Modell RAMSIS..................................................................128Abb. 63. Anwendung des Mensch-Modells in der Fahrzeugkonstruktion .......129Abb. 64. FEM-Belastungssimulation ...............................................................130Abb. 65. DMU und Bewegungssimulation ......................................................130Abb. 66. DMU – Package- und Piping-Analyse ..............................................131Abb. 67. Verknüpfung zweier Collaboration-Pyramiden.................................132Abb. 68. Prozesse innerhalb einer Collaboration (Projektbeispiel)..................133Abb. 69. Rendering ..........................................................................................137Abb. 70. Virtuelle Darstellung eines Kontrollzentrums ...................................137Abb. 71. Phasen von Produktentstehung bis Produktentsorgung .....................141Abb. 72. PLM als Collaboration-Plattform ......................................................143Abb. 73. PDM Collaborator Approach ............................................................144Abb. 74. Alte Datenwelt des Produktkonstrukteurs bei INA-Schaeffler KG...147Abb. 75. Neue Datenwelt des Produktkonstrukteurs bei der INA-

Schaeffler KG ...................................................................................148Abb. 76. Verknüpfung der konstruktiven Stamm- und Strukturdaten in

SAP PLM ..........................................................................................150Abb. 77. Ausgangssituation und Zielsetzung ...................................................154Abb. 78. Auswirkung von Varianten auf die Logistikprozesse........................155Abb. 79. Ganzheitliches und integriertes Komplexitätsmanagement...............156Abb. 80. Komplexitätsreduzierung ..................................................................157Abb. 81. Merkmalvariantenbaum.....................................................................158Abb. 82. Das ABC-Konzept bei der Variantendefinition.................................159Abb. 83. Vorgehensmodell Variantenmanagement im ARIS-Scout ................160Abb. 84. Prozesslandschaft Anlagengeschäft...................................................164Abb. 85. Auszug aus der Projektstruktur..........................................................167Abb. 86. Produkte von BRP-Rotax ..................................................................173Abb. 87. Prozesslandkarte und IT-Unterstützung in den verschiedenen

Prozessen...........................................................................................174Abb. 88. Projektverlauf / Umsetzungsphasen ..................................................176Abb. 89. Projektorganisation............................................................................177Abb. 90. 3D-CAD-Modell eines Motors: Ausgangspunkt für optimierte

Datennutzung.....................................................................................178Fig. 91. Collaboration during Product Life Cycle ..........................................187Fig. 92. Evolution of Collaboration Technologies..........................................188Fig. 93. Cross Enterprise Engineering Networks............................................188Fig. 94. Mapping of the Portfolio of an Engineering Company like ABB .....190Fig. 95. Benefits of Standardization Along the Product Life Cycle ...............191Fig. 96. Standardized Product Information in ABB........................................192Fig. 97. The Concept of Cross-Enterprise-Collaboration ...............................194Fig. 98. Implementation of Collaborative Engineering in ABB .....................195Abb. 99. 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 ...................207Abb. 102. Strukturen des SAP-Projektsystems und deren Beziehungen............208Abb. 103. Netzplandarstellung aus dem SAP-Projektsystem.............................209Abb. 104. Automatische Projektsteuerungsfunktion des Workflows.................209Abb. 105. SAP R/3-Projektinformationssystem.................................................211Abb. 106. Gruppierung von Dokumenten zu SAP-Dokumentarten mit

differenzierten Zugriffsberechtigungen (anonymisiert).....................212Abb. 107. Marktstudie zu Produktentwicklungszeiten.......................................216Abb. 108. Marktstudie zu Produktlebenszeiten..................................................216Abb. 109. Ist-Aufnahme der für Steuerung und Dokumentation des

Produktentwicklungsprozesses relevanten IT-Tools ..........................219Abb. 110. Matrix zur Bewertung zweier Lösungsalternativen anhand eines

gewichteten Kriterienkatalogs ...........................................................221Abb. 111. Das NPDI Konzept ............................................................................222Abb. 112. Eingesetzte Lösungskomponenten im beschriebenen Projekt ...........223Abb. 113. Struktur einer Verpackungsspezifikation im SAP

Spezifikationsmanagement................................................................225Abb. 114. Projektstruktur in cProjects ...............................................................225Abb. 115. Auszug aus einer Projektportfolioübersicht in SAP BW...................227Abb. 116. Arbeitsumgebung eines externen Kollaborationsteilnehmers beim

Zugriff auf cFolders...........................................................................228Abb. 117. Systemübergreifender Pflegeprozess.................................................232Abb. 118. Prozessmodellierung für Workflow (Ausschnitt) ..............................236Abb. 119. Customising-Aufwand in Abhängigkeit von der technischen

Ausprägung .......................................................................................239Abb. 120. Ausschnitt aus der Prozesssteuerungsebene ......................................242Abb. 121. Arbeitsprozess ...................................................................................242Abb. 122. Individuelles Reportingwerkzeug......................................................243Abb. 123. IT-Funktionsmodule im Spezifikationsprozess .................................250Abb. 124. Abbildung der Stahlspezifikation in einer iPPE-Struktur zur

Unterstützung des Angebotsprozesses...............................................251Abb. 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 In-formationstechnologie integriert zu steuern. Insbesondere sollten logistische Teil-funktionen 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 Informations-technologie noch aus. Product Lifecycle Management (PLM) ist angetreten, diese Lücke zu schließen.

Dieses Kapitel leitet historisch die Notwendigkeit von Product Lifecycle Mana-gement her und ordnet PLM in den Rahmen des Computer Integrated Manu-facturing 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ög-licht. Gerade neue, geschäftsprozessorientierte Softwarearchitekturen lassen die Konzepte noch weiter zusammenwachsen. Sie stellen die Basis für eine vollstän-dige 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 Massen- oder 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 Transforma-tion 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 vor-gefertigt, verarbeitet und zusammengefügt werden müssen. Folglich kommt dem Produkt im Industriebetrieb eine zentrale Bedeutung zu. Aufgrund der Notwen-


digkeit eines hohen Ressourceneinsatzes verfügen Industrieunternehmen über ver-hältnismäßig wenige Produktionsstätten (Werke), die viele Maschinengruppen bündeln. Der Geschäftsbetrieb eines Industrieunternehmens erfordert darüber hin-aus 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ätigkei-ten 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 Prob-lemstellungen schneller akut werden. Entsprechend liegen oftmals für die Indust-rie früher Lösungskonzepte vor, die sich auf andere Sektoren übertragen lassen. Als Beispiele seien hier die Versuche zur Industrialisierung des Dienstleistungs-sektors [6], die Kundenfokussierung im Rahmen des Efficient Consumer Response (ECR) in Handelsunternehmen [49] oder das Neue Steuerungsmodell der öffent-lichen Hand erwähnt [23]. Insofern lässt sich vom Industriebetrieb als Idealtyp eines Wirtschaftsunternehmens sprechen und der Referenzcharakter des Industriebe-triebs ableiten.

1.2 Das Y-CIM-Modell

Innerhalb des Industriebetriebs fallen eine Vielzahl an unterschiedlichen Tätigkei-ten 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 Struktu-rierung versuchen (vgl. [43], S. 14-21). Das Y-CIM-Referenzmodell für den In-dustriebetrieb verfolgt genau diese Zielsetzung [40]. Es wurde in vielen Industrieunternehmen als Guideline für die Entwicklung der eigenen Unterneh-mensgestaltung verwendet [41].

Im Kern betrachtet das Y-CIM-Modell die betriebswirtschaftliche und die tech-nische 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 Ferti-gungsebene erfolgen dann die Feinplanung der Aufträge, die Realisierung der Fer-tigungsaufträ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 Pro-duktportfolios. Dies beinhaltet auf Planungsebene die Konstruktion der Produkte. Darüber hinaus muss das Produktionsumfeld zur Fertigung der konstruierten Pro-dukte geschaffen werden. Hierunter fällt insbesondere die Definition der Arbeits-plä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 un-abhä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 Auf-tragsplanung. Die zeitliche Vorgängerschaft wechselt auch von Branche zu Bran-che. 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 Ver-kauf angeboten werden können. Demgegenüber liegt der Beginn der betriebswirt-schaftlichen Prozesskette bei Einzelfertigung im Investitionsgüterbereich vor der Produktentwicklung. Dieser Bereich ist nämlich dadurch charakterisiert, dass je-des Produkt individuell nach den Anforderungen eines einzelnen Kunden entwi-ckelt und produziert wird. Dies bedeutet allgemein, dass betriebswirtschaftliche Planung im Sinne der Auftragsplanung und technische Planung im Sinne der Pro-duktentwicklung 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 zusam-men. 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 Aus-

Produktions-

Programmplanung

Material-

Bedarfsplanung

Kapazitäts-

Bedarfsplanung

Auftragsfreigabe

Werkstattsteuerung

Betriebs-

Datenerfassung

Soll-Ist-Vergleich

(Mengen, Zeiten,

Kosten)

Produkt-Entwurf

Konstruktion

Arbeitsplanung

Steuerung von NC-,

CNC-, DNC-Maschinen

Steuerung von

Transportsystem

Steuerung von

Robotern u.

Montage

Qualitätskontrolle

Technische ProzessketteBetriebswirtschaftliche Prozesskette

CAE

CAD

CAP

CAM

CAQ

PPS CAE

Pro

duktio

nsp

lanun

g

Pro

du

ktio

ns

ste

ue

run

g

Fertigungsebene

P

lanu

ngse

bene

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


führung freigegeben wurde. Dies bedingt ein gemeinsames Ausführen von be-triebswirtschaftlicher und technischer Prozesskette im sachlogischen und zeit-lichen 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. Un-ter Voraussetzung einer sachlogischen und zeitlichen Flussrichtung von oben nach unten lassen sich die Sachverhalte als Y darstellen. Es symbolisiert, dass auf Pla-nungsebene beide Prozessketten unabhängig sind, auf Fertigungsebene jedoch zu-sammenlaufen.

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 Auftragsextrapola-tionen werden die Produktions- und Dispositionsplanungen vorgenommen. Auf Ba-sis dieser längerfristigen Grobplanungen wird der Zeithorizont sukzessive ver-kleinert und die Planung somit weiter präzisiert. Der letzte Schritt innerhalb der industriellen Planungsaufgaben ist die Auftragsfreigabe, die gleichzeitig die Schnitt-stelle zur Produktherstellung darstellt. Innerhalb der Fertigung kommt den betriebs-wirtschaftlichen Prozessen hauptsächlich eine Steuerungsfunktion zu. Hierbei wird der Fertigungsfortschritt mittels der Betriebsdatenerfassung gemessen und aufberei-tet. Im Rahmen eines umfassenden Soll-Ist-Vergleichs können zum einen unmittel-bare Monitoring-Aufgaben wahrgenommen werden und zum anderen nachgelager-tes 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 bearbei-tetes Forschungs- und Entwicklungsfeld dar. Schon in den 50er Jahren wurde mit Material Requirements Planning (MRP) der Grundstein zur systematischen Pro-duktionsplanung und -steuerung gelegt. Das MRP-Konzept ersetzte die bisherige, verbrauchsorientierte Materialdisposition durch bedarfsorientierte Verfahren. Ausgehend von absatzmotivierten Produktionsprogrammen wurden die Primärbe-darfe 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 Manufac-turing 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 ge-stä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 Über-lastungs- oder Überlagerungssituationen vermeiden konnten.

In den 90er Jahren erfolgte schließlich die Einbeziehung aller Unternehmensres-sourcen 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 Ge-schä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 Betrachtungs-weise adressiert. Es dominierten Fragestellungen wie Konstruktionsunterstützung, Exploration von Kundenanforderungen oder Target Costing. So versucht das Mar-keting 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 ei-ner Konstruktionsleistung erfolgt beim Computer-Aided Design (CAD). Hier werden sowohl die Produktbestandteile spezifiziert als auch konstruktiv beschrie-ben. Dies umfasst neben Größen- und Gewichtsangaben auch Leistungsanforde-rungen, Materialvorgaben und Toleranzmaße für die Fertigung. Diese Produktdaten werden dann unter Einsatz von Konzepten und Anwendungssyste-men des Computer-Aided Planning (CAP) in Fertigungsprogramme umgesetzt. Diese beinhalten neben den Arbeitsplänen und Arbeitsgängen auch die NC-Programme zur Steuerung der herstellenden Werkzeugmaschinen. Damit sind sämtliche Planungsinformationen vorhanden, die für die technische Fertigung ei-nes 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, Robotiksys-teme u.a.). Schließlich werden die Produkte auf deren Qualität, bspw. auf die Ein-haltung 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ängig-keiten gekennzeichnet sind. Während also die Dynamik der Produktionsplanung


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 Pro-duktdimension wurde und wird jedoch zunehmend zu dem erfolgskritischen Krite-rium für Industrieunternehmen. Insbesondere vor dem Hintergrund sinkender Produktlebenszeiten und einem Verhältnis von Lebensdauer zu Entwicklungsdau-er von weniger als 2 zu 1 kommt dem Faktor Zeit bei der Entwicklung eine Schlüs-selrolle zu. So hat sich die Time to Market zu der erfolgsentscheidenden Kenn-größ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 Rech-nung, dass die erfolgreiche Markteinführung, also eine betriebswirtschaftliche Problemstellung, weitaus schwieriger zu realisieren ist als eine technische Prob-lemlö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 ei-nen müssen nicht nur die einzelnen technischen Entwicklungs- und Fertigungs-aufgaben integriert und ablauflogisch verbunden werden. Dies bedingt eine prozessorientierte Konzeption der Produktentwicklung und die integrierte Daten-haltung, wie sie ERP-Systeme für Produktionsdaten seit Jahren anbieten. Zum an-deren 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 stati-schen Ergebnissen und dynamischem Vorgehen. Funktional erleichtert es nicht nur das vollständige Stamm- und Entwicklungsdaten-Management, sondern unter-stützt und verbessert auch Prozesse in der Produktentwicklung. Dabei zielt PLM nicht nur auf eine Integration der technischen Daten und Prozesse ab, sondern er-möglicht auch eine Vernetzung und Korrelation mit den betriebswirtschaftlichen Kenngrößen, um einerseits eine wirtschaftlich-effiziente Entwicklung sicher-zustellen und andererseits das Alignment von Produktentwicklung und Markt-einfü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 ver-sucht, 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 Ar-chivierung 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 PDM-Datenhaltung aufsetzen. Die Projektmanagement-Funktion dient der Definition des Entwicklungsprozesses sowie dessen Controlling, beispielsweise zur Kontrolle der Ressourcenauslastung oder des Projektstatusmonitorings. Das Changemana-gement hingegen soll den jedem Entwicklungsprozess inhärenten Änderungsnot-wendigkeiten Rechnung tragen. Änderungsbedarfe, die auftreten, können nun integriert angestoßen, bewertet sowie die Änderungsmaßnahme selbst durchge-fü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 kontinu-ierlich 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 korre-lieren. Die Ansätze, Produktentwicklungsdaten in ERP-Systeme zu integrieren, werden allgemein als problematisch betrachtet (vgl. [15], S. 13). Die resultieren-den Systeme werden mit Funktionen überfrachtet und erscheinen als zu komplex und unüberschaubar. Vielmehr sind ERP- und PDM-Systeme funktional zu integ-rieren. 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 abbild-bar ist. Zwar kann – ähnlich ERP – der prozessintegrierende Charakter in der technischen Prozesskette inhärent eingebunden werden, jedoch fehlt die Verknüp-fung und Korrelation zu betriebswirtschaftlicher und technischer Planung und Steuerung. Abbildung 2 zeigt eine mögliche Einbeziehung der Konzepte des Pro-duct 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 Com-puter 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än-digt damit die Umsetzung einer ganzheitlichen informationstechnischen Unter-stützung der industriellen Geschäftsprozesse.


PDM

OBJEKT-

MANAGEMENT

Identifikation

Revisionierung

Objektklassen

Fremdobjekt-einkapselung

STRUKTUR-

MANAGEMENT

Produktstruktur

Varianten-

klassifizierung

Sachmerkmalleist

Digital Mockup.

PROZESS-

MANAGEMENT

Freigabe- und Änderungswesen

Concurrent

Engineering

Verteilwesen

Konfiguration

Check InOut

Produktions-

Programmplanung

Material-

Bedarfsplanung

Kapazitäts-

Bedarfsplanung

Auftragsfreigabe

Werkstattsteuerung

Betriebs-

Datenerfassung

Soll-Ist-Vergleich

(Mengen, Zeiten,

Kosten)

Produkt-Entwurf

Konstruktion

Arbeitsplanung

Steuerung von NC-,

CNC-, DNC-Maschinen

Steuerung von

Transportsystem

Steuerung von

Robotern u.

Montage

Qualitätskontrolle

Technische ProzessketteBetriebswirtschaftliche Prozesskette

Planungsebene

Fertigungsebene

CAE

CAD

CAP

CAM

CAQ

PPS PLM CAE

Pro

duktio

nspla

nung

Pro

du

ktio

nss

teu

eru

ngFe

rtig

ungs

eben

ePlanungsebene

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 (Ent-wicklungs-) Prozess-Steuerung. Beides sind Funktionen, wie sie die neuen Ge-schäftsprozess-Plattformen originär bereitstellen. Hierunter versteht man dynami-sierte, prozessorientierte Architekturen, die anpassungsfähige, betriebswirtschaft-liche 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ög-lichen sie die Umsetzung der Prozesslogik. Die Workflow-Funktionalitäten dienen primär der Prozesssteuerung, z. B. durch den Transport der in einem Geschäfts-prozess zu bearbeitenden elektronischen Bearbeitungsmappen von einem Arbeits-platz zum anderen. Die EAI-Funktionalitäten sorgen für die Datenintegration zwischen den zur Prozessausführung notwendigen Modulen. Das Integrationswis-sen 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 Anwendungs-systeme 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 Prozesslebens-zyklus möglich.

Dabei kann das Produktdaten-Management des PLM durch die EAI-Funktiona-litä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 konsis-tenten Zugriff in verteilten Umgebungen sicher. Die Steuerung des Entwicklungs-prozesses kann durch die Workflow-Funktion der Prozess-Plattformen wahrge-nommen 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 kontinu-ierlich 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 Prozessma-nagement (BPM) nun auch das Management der Produkte und Leistungen über-nehmen. 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 Ge-schäftsbetriebs eines Industrieunternehmens gewährleisten. Aufgrund des ein-gangs 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 ge-weckt, 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 Konsis-tenz 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 Le-benszyklus 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 Produkt-entwicklungsprozesses, sowie die Bereitstellung aller erforderlichen Produktin-formationen ü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 Part-nern, Lieferanten und Kunden.

Entscheidend für die Wettbewerbsfähigkeit von Unternehmen ist deren Fähig-keit, 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, symboli-siert durch die Säulen des Y-CIM-Modells, durch die Prozesse des PLM eng ver-zahnt 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 zu-sammen. Die durchgängige Betrachtung des Produktes über den gesamten Le-benszyklus 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 Instandhal-tungsmanagement.

PLM ist keine neue Systemklasse und auch keine neue Art von Produkt-Daten-Management (PDM), sondern die konsequente, auf Web-Technologie basierte standort- und firmenübergreifende Anwendung der PDM-Kernkompetenzen Da-tenmanagement, Prozessmanagement und Systemintegration in allen Bereichen und Phasen der industriellen Wertschöpfung. Dies wird erreicht durch ein durch-gä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 PLM-System 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 15

2.1 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, Informa-tionen und IT-Systemen bildet somit eine ideale Grundlage für PLM-Strategien und darüber hinaus eine ideale Plattform zur Pflege und Kontrolle implementier-ter 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 richti-gen 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 Darstel-lung 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 „Pro-zesslandkarten“ 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 Un-terstützungsprozessen gegliedert. Durch Unterprozesse beliebiger Tiefe erreicht man in den Einzelsegmenten alle Prozesse, die den Product Lifecycle eines Pro-duktes beschreiben, hier am Beispiel des Produktentwicklungsprozesses, der wie-derum eine eigene Prozesslandkarte für verschiedene Branchen enthält (Abb. 6).

Abb. 5. Generische Prozesse des PLM


Unternehmens-

planung

Projekt-

management

Innovation

Qualitäts-

managementRisiko-

management

Managementprozesse

Kunden-

management

Produkt-

entwicklungs-prozess

Prozess-

entwicklung

Änderungs-

management

Anfrage-

prozessProduktions-

prozess

Produkt-

management-prozess

Kernprozesse

Personal

ManagementLogistikkette

ITOrganisation

Finanzen

Controlling

Beschaffung

Einkauf

Rechtexterne

Dienstleistung

Unterstützungsprozesse

PLM Prozessbausteine

Geschäftspartner-Management

Marketing

Service-

prozess

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 Pro-dukten im Markt, ständig sinkt, ist es um so wichtiger, Produkte schnell und kos-tengü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 Ver-fü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ügbar-keit 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 17

Kriterienmodellfür die Integration von

CAD-Systemen

Strategische Eignung

• Zukunftssicherheit

• Verbreitung /

Referenzen

• Service- und

Supportgarantien

Usability

• Intuitive Führung

• Bedienung aus CAD

• Flexibilität der

Oberfläche

Standardisierung

• Einheitlichkeit von

Prozessen & Bedienung

• Oberfläche

Kosten

• Lizenzen

• Implementierung

• Zusatzkosten (HW /

Server, ...)

• Lizenzmodell

Administration

• Architektur /

Systemvielfalt

• Releasefähigkeit

• Support

Performance

• Check-in / Check-out

• Anwendung

• Stabilität

Implementierung

• Konzept

• Kompetenz

• Engagement

Funktionale Eignung

• Massenverarbeitung

• Prüfung (Freigabe etc.)

• Fkt. Anpassungs-

möglichkeiten

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 Aufbau- und Ablauforganisationen wird bei allen am Prozess Beteiligten unumgänglich. Hieraus entstehen Herausforderungen wie:

Kooperative, virtuelle und integrierte Produktentstehungsprozesse Frühe und enge Einbeziehung von Engineeringpartnern Wachsende Anzahl von Experten und deren Wissen Projektorientierte Technologieentwicklung Gemeinsames Kosten- und Zeitmanagement Hohe Transparenz der Entscheidungsprozesse Synchronisation der Produktionsnetzwerke


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ücklis-ten, aber auch Spezifikationen und klassifizierende Sachmerkmale. Zu verwalten sind neben dem Datenaufwuchs im Produktentstehungsprozess auch Änderungs-stä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 defi-nieren. 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 Gesamtpro-zess (im Sinne einer permanenten Kontrolle und Optimierung) trägt und eventu-ell auch wesentliche Dateninhalte selbst pflegt (z. B. Nummernvergabe).

Schließlich gehört zum Stammdatenmanagement die Definition einer Stamm-daten-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 definie-ren, in denen die Objekte gepflegt und geändert werden und von wo eine Vertei-lung 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, Da-teien beliebiger Formate sowie gescannte Belege. Diese Informationen sind zu er-zeugen, zu verwalten, mit Partnern auszutauschen. Es müssen Funktionen zur PLM-Prozessintegration, zum Input- und Outputmanagement, zur Sicherung und zur Langzeitaufbewahrung angeboten werden.

ECM geht also über die Grundfunktionen des klassischen Dokumentenmana-gements im Produktdatenmanagement hinaus. Es umfasst auch die Funktionen einer Archivierung, bei der weniger der Lebenszyklus eines Dokuments, son-dern 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änder-bar 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 da-mit in Zusammenhang stehende Verwaltung der technischen Anlagen und In-standhaltungsressourcen eines Unternehmens über deren gesamten Lebens-zyklus hinweg. Dazu sind Funktionen aus den Bereichen Wartung, Reparatur, Instandhaltung und Service zu etablieren, umfassend als Asset Lifecycle Mana-gement bezeichnet.

Den Grundstein für eine funktionierende Instandhaltung legt bereits der Pro-duktentwicklungsprozess. Hier entstehen nicht nur die ersten Instandhaltungs-stammdaten, sondern es sind Instandhaltungsfunktionen vorzudenken und Instand-haltungsbedü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 Lebenszyklusmanage-ments meint QM das Management der Produkt- und Prozessqualität in Hinblick auf Qualitätssicherung und Qualitätsverbesserung. Collaborative Produktentwick-lungsprozesse, die den Austausch von Produktinformationen über Unternehmens-bereiche und Unternehmensgrenzen zur Folge haben, bedingen auch eine neue Ausrichtung des Qualitätsmanagements. Qualitätswesen ist bereits in die Produkt-entwicklung mit einzubeziehen. Qualitätsziele sind in einer frühen Entwicklungs-phase zu berücksichtigen. Qualitätskontrolle und Qualitätssicherung ist in der


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: Alle Prozesse der Qualitätsplanung, Qualitätskontrolle und der kontinuierli-chen Verbesserung werden unterstützt. Mitarbeiter haben alle wichtigen qualitätsrelevanten Informationen jeder-zeit zur Verfügung. Alle Anforderungen im Sinne eines Total Quality Management wie auch entsprechender Qualitätsnormen, branchenbezogener Richtlinien sowie ge-setzlicher 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 entste-hen optimierte Abläufe, die die zusätzlichen Möglichkeiten des DV-gestützten Product Lifecycle Management berücksichtigen und die als Workflow in PLM-Systemen abgebildet werden können. Dies führt insbesondere bei komplexen Ab-läufen und verteilter Arbeit zu einer spürbaren Beschleunigung der Produktent-wicklung.

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 Ab-bildung von Prozessen und Produktdaten für verschiedene Sichten zielgruppen-gerecht 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 Innovations-zyklen 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

Produkt-

entwicklungs-prozess

MarketingResearch

Anforderungs-management

OEM's

Anforderungs-management

OEM, Multi-Tier

Anfrage-management

OEM

Multi-TierSupplier

1 TierSupplier

2 TierSupplier

Konzept Design

Produkt-management

KonstruktionKonzept

Abb. 9. Prozesslandkarte des Produktentstehungsprozesses am Beispiel der Automotive-Branche

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 Entwicklungsprojek-ten 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 ho-her Anteil an kundenindividuellen Änderungen je Auftrag erforderlich wird. Da-durch 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 Austausch-barkeit von Funktionsbaugruppen.

Damit wird der Änderungsprozess zur zentralen Kostenschraube in diesen Un-ternehmen. „Wer die Änderung beherrscht, beherrscht den Markt“, ist eine gängige Aussage in dieser Branche.


davon53 %47 %

Fehlerbedingte

Änderungen

Neuerungsbedingte

Änderungen

40 %

(21 %)

60 %

(32 %)

Unvermeidbare

Änderungen

Vermeidbare

Änderungen

Quelle: Lindemann

Abb. 10. Reduzierung vermeidbarer Änderungen durch die Optimierung von Änderungs-prozessen

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

Änderungs-objekte aus-wählen undfreigeben

Änderungs-antraganlegen

Antragangelegt

Workflow ÄnderungsantragWorkflow Änderungsantrag

MachbarkeitEinzelobjekte

prüfen

Antragfreigegeben

allealleObjekteObjektegeprüftgeprüft

CB Konstr. AvorPM

Änderungsmeldung

Änderungs-objekte aus-wählen undfreigeben

Änderungs-antraganlegen

Antragangelegt

Workflow ÄnderungsantragWorkflow Änderungsantrag

MachbarkeitEinzelobjekte

prüfen

Antragfreigegeben

allealleObjekteObjektegeprüftgeprüft

CB Konstr. AvorPM

Änderungsmeldung

Abb. 11. Workflowunterstützte Änderungsprozesse schaffen Sicherheit und Prozesstrans-parenz


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 Stammda-tenmanagements fest.

Der Produktdatenentstehungsprozess umfasst hier typischerweise viele beteilig-te Unternehmensbereiche und Einzelpersonen, ist somit bei hohen Prozesslaufzei-ten sehr abstimmungsintensiv. Die Fülle der zu verwaltenden Daten ist oft deutlich höher als in der stückorientierten Fertigung. Zwar sind Zeichnungen und CAD-Daten 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 Pharmabe-reich, 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 Pro-duktentstehungsprozess 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 Sicher-stellung einer durchgängigen Datenqualität und die Einhaltung unternehmensweiter Qualitätsrichtlinien. Das Bewusstsein, dass qualitativ hochwertige Produktstamm-

Produktidee

Beschreibende Produktdaten

Materialqualität

Lackierung

Grüner Punkt

Prägung

Machbarkeit

Kalkulationsdaten

Preise

Materialien (Logistik)

Produktion

Stammdaten

Lieferantendaten

Einkaufsdaten

Dokumente

Zeichnungen

Berichte

AV-Medien

Zusammensetzung

Rohstoffe

Mengen

Wirkstoff-

Gehalte

Spezifikations-Verwaltung

Rezeptur-Management

Materialstamm

Stückliste Planungs-rezept

Klassifikation

Beschreibende Produktdaten

Materialqualität

Lackierung

Grüner Punkt

Prägung

Dokumenten-Verwaltung

Analyse und Verbesserung

Qualitätssicherung

Markt-Daten

Innovation und Renovation

QM-Daten ...

Abb. 12. Entstehung von Stammdaten entlang des Entwicklungsprozesses


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 ein-heitlichen Produktdatenbasis, durchgängigen Stammdatenprozessen und einer de-finierten 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 Serienferti-gung. Ob elektronische Konsumgüter (z. B. Waschmaschinen, Trockner) oder Pro-dukte aus dem Bereich Food & Beverage (z. B. Getränke, Verpackungen, Süßwa-ren), 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, effizien-ten 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


hinweg geschaffen werden. Dies stellt die Grundlage eines erfolgreichen Entwick-lungsprojektmanagements dar und schafft gleichzeitig die Grundlage eines Portfo-liomanagements.

Reduzierung Time to Market durch Professionelles Projekt- und Prozessmanagement in der Produktentwick-lung Effizientes Änderungsmanagement von Produkten Transparentes Stammdaten- und Dokumentenmanagement

Erhöhung der Innovationskraft durchUnternehmensweites Wissensmanagement Effiziente Ideengenerierungsprozesse Effektive Auswahl- und Screeningverfahren Entlastung kreativer Mitarbeiter von administrativen Tätigkeiten

3 Bausteine und Prozesse im PLM

3.1 Ein prozessorientierter PLM-Ansatz

ProcessControlling

ProcessStrategy

ProcessImplementation

ProcessDesign

CHANGE MANAGEMENT

CONTINUOUS IMPROVEMENT

ProcessControlling

ProcessStrategy

ProcessImplementation

ProcessDesign

BUSINESS PROCESSES

COMPLIANCE PROCESSES

Sales, Purchase, Production, Logistics …

Sa

rba

ne

s-Oxley

Act, Risk & Control Management, Quality Management …

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 Prozes-sen; daher setzt sich eine PLM-Lösung eines entwicklungsorientierten Unterneh-mens 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 bei-spielsweise 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 Entwick-lung, Produktion, Distribution und Service im Mittelpunkt steht und andererseits Ausgangspunkt und Ziel aller Prozesse auf oberster Ebene der Kunde ist. Das be-


deutet, dass die gesamte Prozesskette, die ein Produkt durchläuft, mit PLM abge-deckt werden muss, und dabei alle durchlaufenen Funktionen und Organisations-bereiche 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 An-gelpunkt für die spezifische Ausgestaltung eines PLM-Prozess-Regelkreises. Die-ser Regelkreis ist in Abb. 14 dargestellt und besteht aus den 4 Bestandteilen:

PLM-Strategie PLM-Prozess-Design PLM-Prozess-Implementierung 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 Kenn-größen ermittelt oder vorgegeben, die in der darauf folgenden Design-Phase spezi-fiziert und in eine Metrik transferiert werden, sofern die Kenngrößen quantifizier-bar sind. Die PLM-Implementierung bildet unter Berücksichtigung der festgelegten Strategie die in der Design-Phase definierten Ziel-Prozesse in einer zuvor ausge-wä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 Ergeb-nisse sind wiederum Eingangswerte für eine Optimierungsschleife mit erneutem Start der Design-Phase. Die Ergebnisse aller Phasen finden ebenfalls eine Rück-kopplung 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ög-lich; es muss nicht immer mit der Design-Phase begonnen werden. So kann bei-spielsweise 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:

Harmonisierung unternehmensweiter Produktentwicklungs-Prozesse infolge eines Zusammenschlusses von Unternehmen Optimierung der produktzentrierten Prozesse aufgrund veränderter Rand-bedingungen, 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

Re-Strukturierung eines Unternehmens in eigenverantwortliche Geschäfts-bereiche (je Geschäftsfeld oder Funktion) mit eigenen internen Prozessen und Systemen, aber definierten Standards an den Prozess-Schnittstellen Harmonisierung des unternehmensweiten Produktspektrums mit einher-gehender Zentralisierung des Stammdaten-Managements Strategische Ausrichtung des Unternehmens auf eine einheitliche IT-Infra-struktur mit entsprechenden Systemwechseln Konzentration auf die Kernprozesse und Schlüsselprodukte des Unter-nehmens mit einhergehendem Outsourcing der nicht mehr im Fokus be-findlichen BereicheVerstä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 Ge-schäftsprozess-Lebenszyklus aus. Wenn sich beispielsweise ein reiner Teilezulie-ferer 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öp-fung 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 logisti-schen 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:

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

Zeit für die Vorbereitung, Durchführung und Nachbereitung einer Aktivi-tät und eines Prozesses; dabei kann Vor- und Nachbereitung die Trans-formation 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


Rechenzeit für Simulationen Zeit für die Aufbereitung von VR-Studien

Anzahl der zu durchlaufenden Schleifen (z. B. im Rahmen eines Prüf-prozesses) und Wiederholungen. Beispiele:

Anzahl von Änderungsdurchläufen Anzahl von Rückweisungen bei einer Freigabe Anzahl von iterativen Berechnungen und Simulationen aufgrund von Design-Änderungen

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

Anzahl der zu nutzenden Systeme, Informationsquellen oder Datenqualität etc. sowie des damit verbundenen Aufwands. Beispiele:

Einsatz verschiedener CAD-Systeme in Produkt- und Sondermaschinen-konstruktion verbunden mit der Notwendigkeit, Schnittstellenprogramme zu nutzen und Datenverlust während der Konvertierung in Kauf zu nehmen Nutzung unterschiedlicher Normteilkataloge an verschiedenen Stand-orten 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 Entwick-lung zu Logistik

Anzahl und Umfang der Input-/Output-Dokumente, CAD-Modelle, Spezi-fikationen etc. Beispiele:

CAD-Modell mit angehängten Zeichnungen Vom CAD-Modell abgeleitete Neutralformate

Risikoquantifizierung eines Prozesses mit Unterteilung in rechtliche, kauf-männische, konstruktive, produktionstechnische, organisatorische und lo-gistische Risiken. Beispiele:

Personalbesetzung eines Entwicklungsprojektes Projektklassifizierung in Neuentwicklung, Anpassungs-, Variantenkon-struktion


Produktkonfiguration mit Entscheidung über den anzuwendenden Projekt-plan und Anzahl der zu durchlaufenden Quality Gates oder Meilensteine Risiko-Management innerhalb eines Projektes

Die Anzahl an Aktivitäten einer Person oder Stelle. Beispiele:

Detailkonstruktion und Berechnung durch einen Konstrukteur Zeichnungserstellung mit Material- und Stücklistenanlage sowie ein-hergehender Klassifizierung (Aufbau der Sachmerkmalsleiste) durch eine Person Verantwortlichkeit für eine große Zahl von Projekten

Mengengerüste über Anzahl der Prozessdurchläufe und Anzahl der ver-schiedenen Produkte. Beispiele:

Bauteiländerungen pro Jahr Anzahl und benötigte Zeit für Dauerprüfungen und Belastungstests pro BaureiheKonfigurationen aus einer Menge von Basiskomponenten, Beherrschung der Variantenvielfalt Anzahl der Neuentwicklungen, Anpassungs- und Variantenkonstruk-tionen 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ösungs-Akzeptanz oder Innovationsfähigkeit.

Beim Prozess-Design werden in der Regel die Prozesse entsprechend ihrem Beitrag zur Wertschöpfung eines Unternehmens eingeteilt in:

Kernprozesse Management-Prozesse 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 be-ginnt beispielsweise mit der Kundenanfrage, erstreckt sich über Spezifikation, De-sign, Konstruktion, Berechnung bis hin zur Arbeitsvorbereitung, Fertigung und Montage und endet nach der Qualitätsprüfung mit der Lieferung zum Kunden.


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 kom-mender 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 Pro-zessunterstützung auf die in den Prozessen festgehaltenen und mit Kennzahlen versehenen Anforderungen, die identifizierten Schlüsselfaktoren und die Behe-bung von erkannten Defiziten.

Abb. 15 verdeutlicht – trotz der unvollständigen Abbildung der realen Verhält-nisse – die Komplexität einer PLM-Prozess-Implementierung. In den unterschied-lichen Phasen des Produkt-Lebenszyklus werden sehr unterschiedliche Software-

CAD Datenbanken

SimulationInternet

ERP/PPS

Datenaustausch

Kernprozess Produktentwicklung

CAD Datenbanken

SimulationInternet

ERP/PPS

Datenaustausch

CAD Datenbanken

SimulationInternet

ERP/PPS

Datenaustausch

Kernprozess Produktentwicklung

Abb. 15. PLM-Prozess-Implementierung


systeme eingesetzt, um die spezifischen Aufgaben zu lösen. So werden beispiels-weise 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 Kata-logdaten von Zulieferern. Zur Verifizierung und Optimierung werden diese Daten an Berechnungs- und Simulationsprogramme übergeben. Mit externen Entwick-lungspartnern und Zulieferern werden zu den unterschiedlichsten Phasen unter-schiedlich 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 Prozess-Lebenszyklus: das Prozess-Controlling. Im Sinne eines integrierten Qualitäts-managements und einer kontinuierlichen Verbesserung der Geschäftsprozesse ist es unerlässlich, die erreichten Ziele zu überprüfen und weitere Optimierungs-potenziale zu entdecken. Die Ergebnisse des Prozess-Controllings sind wiederum Input für ein anschließendes Re-Design der Prozesse, um die identifizierten Opti-mierungspotenziale 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 weiterentwi-ckelnden 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 Optimie-rungspotenziale und der effizienten Gestaltung eines Change-Managements.

Generell sollte dem Prozess-Controlling ein hoher Stellenwert eingeräumt wer-den. 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 wan-delnde Rahmenbedingungen schnellstmöglich reagieren zu können. In gleichem Maße sollten auch die unterstützenden IT-Systeme in regelmäßigem Abstand kri-tisch 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 Datenverwaltungssys-teme haben sich hier als sinnvoll und praktikabel erwiesen.

Abb. 16 verdeutlicht anhand eines Prozessbeispiels, welche Aussagen ein Pro-zess-Controlling liefern kann. Die Verteilung der Geschäftsvorfälle auf die unter-schiedlichen Prozessabläufe gibt erste Hinweise auf Möglichkeiten zur Optimierung. Hiermit können beispielsweise auch Benchmarks zwischen verschiedenen Unter-nehmensbereichen oder Werken durchgeführt werden. Ebenso kann eine Analyse der Durchlaufzeiten hilfreiche Ansätze zur Fehleranalyse liefern.


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 ent-stehenden 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 gesam-ten 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 Unter-nehmensbereiche können Innovationen erfolgreich in neue, marktfähige Produkte umgesetzt werden.

Wie bereits oben ausgeführt wurde, werden PLM-Prozesse unterschieden in

Kernprozesse, die in direktem Zusammenhang mit den Produkten stehen, Management-Prozesse, die diese PLM-Kernprozesse steuern, und Support-Prozesse, die als unterstützende Prozesse den Kernprozessen dien-lich sind.

Komposition einer integrierten PLM-Lösung 35

Dabei beginnen insbesondere die PLM-Kernprozesse im Sinne von End-to-End-Prozessen 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 War-tung eine wichtige Rolle. Insgesamt umfasst PLM vornehmlich alle mit dem Pro-dukt und der Produktion in Zusammenhang stehenden Prozesse:

Kreativität, erste Produktidee oder Innovation Anforderungsaufnahme beim bzw. mit dem Kunden (Lastenheft) Spezifikation und Konzeption (Pflichtenheft) Eigentliche Produktentwicklung mit Modellierung, Berechnung, Simulation, Analysen, Verifikation, Risikoanalyse, Prototyping etc. Zugehörige Prozessentwicklung für Fertigung und Montage von der Vorserie bis zur Serie Entwicklung der notwendigen Betriebsmittel, Fertigungshilfsmittel, Sonder-maschinen bis hin zu den Produktionsstätten Unternehmensinterne und unternehmensübergreifende Zusammenarbeit Variantenmanagement bei konfigurierbaren Produkten Freigabe-, Änderungs- und Konfigurationsmanagement Distribution der Produkte inkl. Verpackung Service, Wartung und Instandhaltung Qualitätsmanagement Kontinuierliche Verbesserung und Produktpflege Produktauslauf und Recycling sowie Verschrottung Berücksichtigung rechtlicher Vorgaben und verbindlicher Randbedingungen bzgl. Produkt- und Prozess-Sicherheit, Gefahrgut-Management, Umwelt Management aller mit den genannten Punkten in Zusammenhang stehenden Dokumentationen Management der mit Produkten und Produktion in Zusammenhang stehen-den (Teil-) Projekte und übergeordnetem Programm-Management 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 wer-den kann, sondern sich als integrierender Querschnitt über das gesamte Unter-nehmen erstreckt.

Eine mögliche Komposition der genannten PLM-Prozesse und Funktionen wird in einer PLM-Prozess-Landkarte dargestellt. Für den Bereich der Fertigungs-industrie könnte eine solche PLM-Prozess-Landkarte auf oberster Ebene wie folgt aussehen (siehe Abb. 17).

36 B

austeine und Prozesse im PLM

MarketingResearch

Anforderungs-management /

Grobkonzept

CRM

Risc LevelAssessment

Personal-

einsatzPlanung

Management

LogistikketteEntwicklung

Product Data

Management

externe

technischeDienstleistung

Customer

RelationshipManagement

Supply Chain Management

Projekt-

managementInnovation / F&E

Projekt-

managementProduktion

technische

Innovation

Produkt-

entwicklung

Betriebsmittel-management

Arbeits-vorbereitung

Produktion

Beschaffungs-

prozess

SpezifikationDetailkonzept

Service- undInstandhaltung

Customer

RelationshipManagement

Product Data

Management

Vertrags-

management

Änderungs-

managementEntwicklung

IT/OrganisationPLM

Portfolio-ManagementManagement-Prozesse

Kern-Prozesse

Support-Prozesse

Abb. 17. PLM

-Prozesslandkarte


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 Un-terstü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 Anforde-rungs- und Spezifikationsphase und münden zunächst in der eigentlichen Produkt-entwicklung. 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 IT-Systeme. Produktion, Service und Wartung schließen dann den hier beschriebenen Lebenszyklus-Prozess. Bereits auf dieser Ebene lassen sich für einzelne Pro-zessbereiche PLM-Lösungsbausteine von herausragender Wichtigkeit identifi-zieren:

Requirements-Engineering Wissensmanagement übergreifendes und integriertes Dokumenten-Management Management von Produktstrukturen und Stammdaten unternehmensinterne und unternehmensübergreifende Collaboration Prozessautomatisierung (Workflow) Änderungswesen Konfigurationsmanagement

Darüber hinaus umfasst PLM vom Grundsatz her auch gesellschaftliche sowie ethische Aspekte. Insbesondere Managementprozesse bedeuten nicht nur unter-nehmerischen Erfolg, sondern auch in vielen Fällen eine besondere Verantwor-tung 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 Technik-folgenabschä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 Schwie-rigkeit im Umgang damit. Im weiteren Verlauf wird diese Thematik nicht näher vertieft.

38 B


CAD-

Modellierung

Konzept-

Simulation

Berechnung

Auslegung

Freigabe-/

Änderungswesen

Ergonomie-

Untersuchung

Engineering

Collaboration

Kinematik

ProzessdatenFertigungMontage

Werkstoff-

auswahl

ProduktdatenStammdatenStücklisten

Projekt-

Management

Proof of

Freigabe

Optimierung

Validierung

FunktionRapid

Dokumentation

CAD-Modelle

Prototyping

Concept /

Abb. 18. Prozesse in der Produktentw

icklung (Ausschnitt)


Betrachtet man nun den Bereich der Produktentwicklung (siehe Abb. 18), der auf-grund seiner vorher beschriebenen Wertschöpfung und Kostenverantwortung be-sondere Bedeutung verdient, so werden die einzelnen Bestandteile einer prozess-orientierten PLM-Lösung deutlich. Die Teilprozesse umfassen neben der Spezifi-kationsphase 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 über-greifenden 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:

CAD- beziehungsweise CAD-/PDM-Integration Digital Mockup Synchrone und asynchrone Engineering-Collaboration Status- und Versionsmanagement Integration von Berechnungs- und Simulationsprozessen Datenkonvertierung Stammdaten- und Stücklistenverwaltung Projekt- und Multiprojektmanagement

Für die Zukunft immer wichtiger wird vor dem Hintergrund einer wachsenden Me-chatronisierung der Produkte auch die Integration der zugehörigen Applikationen in den Bereichen der mechanischen, elektrotechnischen und informationstechni-schen Komponenten.

Im Bereich der Prozessindustrie (Chemie-/Pharma-, Papier-, Textil- und Metall-industrie) werden dagegen die PLM-Prozesse aufgrund der dortigen Anforderun-gen in anderer Weise aufgeteilt und die Kernprozesse nach anderen Kriterien priorisiert; des Weiteren kommen noch Prozess-Bereiche hinzu, wie

Umweltschutz und Produktsicherheit (Environment, Health and Safety) Spezifikationsmanagement Rezepturmanagement

Abb. 19 zeigt zum Überblick eine Prozesslandkarte für die Prozessindustrie. Diese Aufzählung bedeutet jedoch nicht, dass in jedem Fall alle Prozess-

Bausteine mit voller Funktionalität in einer integrierten Lösung realisiert werden müssen. Vielmehr kann mit der Qualifikation und Quantifizierung von Kennzah-len, 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 prio-risieren und in Verbindung mit Mengengerüsten oder anderen Kriterien eine opti-male PLM-Lösung definieren.

40 B


MarketingResearch

CRM


Personal-einsatz

Planung

Product Data

Management

externetechnische

Dienstleistung

CustomerRelationship

Management

Grundlagen

Forschung

Beschaffungs-

prozess

Produktportfoliomanagement

Produktion

ÄnderungsmanagementEntwicklung

Verfahrens-entwicklung

Testbetrieb

Anlage

Verfahrens-optimierung

Anlagen-planung

Genehmigung / Zulassung


Inovations-management

F&E Laborphase Technicum

Spezifikations-/Rezepturmanagement

general recipe

Anlagenmanagement,

Reparatur und Abstellung

Spezifikations- /Rezepturmanagement

master recipe

Rezepturmanagement

control recipe

Managementprozesse

Kernprozesse

Supportprozesse

Abb. 19. Prozesslandkarte in der Prozessindustrie (C

hemie)

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 Schwach-stelle behoben oder ein Projekt-Teilziel erreicht ist, das mit entsprechenden Kenn-zahlen verifiziert werden kann. Des Weiteren sollte die sog. PLM-Implementierungs-Roadmap aufgrund der engen Verzahnung von PLM mit den anderen Unterneh-mensbereichen 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 Benut-zerakzeptanz nicht unterschätzt werden. Ebenso spielt die Zusammensetzung des Projektteams eine sehr wichtige Rolle. Aufgrund der Notwendigkeit, alle betroffe-nen Unternehmensbereiche in PLM-Prozesse zu integrieren, darf auch der Ab-stimmungsaufwand 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“ Produkt-entwicklung wiederum offensichtlich. Aus diesem Grunde spielen die mit Kenn-zahlen 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 nach-haltigen Projekterfolg.

In der Regel wird beim PLM-Prototyping (PLM-Pilotierung) ein kritischer Un-ternehmensprozess für eine Produktgruppe von tragender Wichtigkeit realisiert. Typische Pilot-Prozesse sind beispielsweise:

Freigabe oder Änderungsprozesse Entwicklungsprozesse für Plattformen, kundenspezifische Applikationen oder Varianten Neuanlaufprozesse 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:

Übertragung des kritischen Prozesses auf andere Produktgruppen, Standorte o.ä. (Roll-Out) Implementierung weiterer Prozesse für diese Produktgruppe 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.


3.4 Vorteile einer prozessorientierten PLM-Einführung

Ein prozessorientierter Ansatz führt zwangsläufig zu einer genau zu den unter-nehmensspezifischen 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 Si-tuation im Unternehmen abgestimmt ist. Wachstumspfade ergeben sich aus den Möglichkeiten, die PLM-Lösung auf weitere Prozesse auszudehnen oder die be-stehenden Prozesse auf weitere Produktbereiche anzuwenden.

Hierdurch kann eine PLM-Gesamtprojektplanung sukzessive an die sich stetig wandelnden Situationen und Prozesse innerhalb eines Unternehmens angepasst wer-den; 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 An-forderungen an eine spätere PLM-Lösung genauer spezifiziert werden. Die Orien-tierung 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-to-End-Prozessen und die Zuordnung von Prozess-Zuständigkeiten über die gesamte Organisation hinweg. Im Sinne eines Prozess-Regelkreises sollte nach einer Pro-zessmodellierungs- und Implementierungsphase in jedem Fall eine Controlling-Phase vorgesehen werden, um die Güte der Prozessrealisierung, den Zielerrei-chungsgrad sowie die Kennzahlen zu verifizieren. Diese Phase bietet erneut die Möglichkeit, sowohl Schwachstellen als auch Stärken zu quantifizieren, Projekt-ziele 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 Pro-duktentwicklung im engeren Sinne aus. Durch die Erweiterung des Begriffes auf „Product Data Management“ und schließlich eben „Product Lifecycle Manage-ment“ 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 Verzah-nung mit Unternehmensprozessen außerhalb der Produktentwicklung. Insbesonde-re sind wesentliche Anforderungen an erfolgreiche Unternehmen wie kurze Entwicklungszeiten, geringe Time to Market, niedrige Entwicklungs-, Produkti-ons- 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 prozess-orientierter und unternehmensübergreifender Optimierung der Entwicklungs-zusammenarbeit.

Das führt dazu, dass der Prozess der Produktentwicklung nicht isoliert betrach-tet und optimiert werden darf, sondern im Sinne der Systemtheorie als eingebun-den 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 an-zutreffen ist: Innerhalb der Entwicklungsabteilung sind Abläufe optimiert und sehr gut durch entsprechend angepasste IT-Systeme, beispielsweise Produkt-Daten-Management-Systeme (PDM-Systeme) unterstützt. Im Sinne des Gesamtunter-nehmens (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 be-rücksichtigen, die jeweiligen Schnittstellen identifizieren und dadurch die Rah-menbedingungen 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ützen-den 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


Prozessorientierte

Gemeinschaften

ab 2000

Prozessorientierte

Geschäftsprozesse

1995

Funktionale

Organisation:

„Mauern zwischen

Abteilungen“

1985Prozessspezifische

Netzwerke:

„Mauern zwischen

Unternehmen“

1999

Abb. 20. Entwicklung der Organisation in der Produktentwicklung: von funktionaler Abtei-lungstrennung hin zu prozessorientierten, unternehmensübergreifenden Entwicklungsko-operationen

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 akzeptier-ten „form follows function“. Diese Vorgehensweise entspricht im Übrigen derje-nigen, 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 Entwick-lungsteams haben dann innerhalb dieser Spezifikationen Freiheitsgrade zur Aus-prä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 IT-Systeme 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 ver-meiden. In organisatorischer Hinsicht kann das bedeuten, dass die Ablaufreihen-folge verschiedener Tätigkeiten innerhalb eines Prozesses verändert wird. Dies ist jedoch nur unter Berücksichtigung gegebener Rahmenbedingungen möglich. Bei-spielsweise sind innerhalb der Produktentwicklung offensichtlich bestimmte Frei-gabeschritte 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 Abstim-mungen zwischen Mechanik-, Elektronik- und Software-Entwicklung erforderlich, so ist zumindest an die organisatorische Zusammenführung dieser Entwicklungs-bereiche 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 integ-riert 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 ge-hen häufig weit über unmittelbare Produktdaten hinaus und umfassen umfangrei-che Pakete wie Projektdaten, Produktstrukturen etc. Einerseits ist es offensichtlich, dass unterschiedliche Werkzeuge zum Einsatz kommen müssen, da geometrieer-zeugende Systeme wie CAD Vertriebsprozesse nicht unterstützen bzw. Vertriebs-systeme nicht in der Lage sind, 3D-Modelle zu generieren und zu berechnen. Andererseits stellt der Prozess hohe Anforderungen an die Integration dieser Syste-me. Deshalb ist es die Aufgabe von Product Lifecycle Management, diese integra-tiven 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-Portfolio-Management, da das gegenwärtige und in Entwicklung befindliche Produkt-Portfolio die Grundlage der Planung bildet. Umgekehrt wiederum leitet sich aus der Unternehmensplanung, insbesondere in der Konsumgüterindustrie, das Ziel-Produkt-Portfolio ab und damit die Vorgaben an die Produktentwicklung.

Weniger offensichtlich, aber nicht minder wichtig ist der Zusammenhang zwi-schen der strategischen Unternehmensplanung und der Produktentwicklung im engeren Sinne: Für eine stets aktuelle Planungsgrundlage der strategischen Pla-nung ist es unbedingt erforderlich, jederzeit Überblick über den Entwicklungs-stand der Produkt-Pipeline zu haben. Bei Abweichungen zur Planung muss


entsprechend reagiert werden durch Maßnahmen zur Planerreichung oder Ände-rungen der Planung mit Auswirkungen z. B. auf Marketingmaßnahmen etc. Des-halb gewinnen die Prozess-Integration zwischen strategischer Planung und Produktentwicklung ebenso wie entsprechende, integrierte Tools für Multi-Projektmanagement zunehmend an Bedeutung.

Den Zusammenhang zwischen Produktportfolio, Unternehmensprozessen und unterstützenden IT-Systemen illustriert die Gruppe „digitales Produkt“ am Zent-rum für Produktentwicklung der ETH Zürich am Beispiel des digitalen Produk-tes in Abb. 21. „Nur das Gleichgewicht von Produkten – Unternehmens-prozessen – 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.

Geeignete IT-Systemarchitektur bestehend aus

- Konfigurationssysteme

- CAx-Systeme

- Produktionsmanagement Systeme (PDM-Systeme)

- Enterprise Resource Planning Systeme (ERP-Systeme)

Strategische Tools

T

Produkt-

Plattform

Unternehmens-

Prozesse

Wie ist das Produkt

charakterisiert

- Standardprodukt ohne Varianten

- Standardprodukt mit

herstellerspez.Varianten

- Standardprodukt mit

kundenspez. Varianten

- Einzelprodukt

P

Welche Rolle spielen

- Kunde

- Verkauf

- Engineering

- Produktion / Logistik

- …

U

Abb. 21. Das digitale Produkt

Produktentstehung und Vertriebsprozess 47

4.2 Produktentstehung und Vertriebsprozess

Obwohl bereits seit einigen Jahren ein Wechsel von der Produkt- zur Kundenorien-tierung nicht nur im Dienstleistungsbereich, sondern auch in produzierenden Unter-nehmen sowohl eingefordert als auch postuliert wurde, sieht die Realität immer noch anders aus. Untersuchungen zeigen, dass insbesondere viele technologisch ausge-richtete Unternehmen immer noch technik- oder produktorientiert arbeiten und den-ken. 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 kundenorien-tierten 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 technolo-gisch weniger anspruchsvollen Massengütern, intensive Markt- (und Wettbe-werbs-)analysen, um neue Produkte optimal auf die Kundenwünsche auszurichten. Ergebnisse der Marktforschung haben unmittelbare Rückwirkung auf das Pro-duktportfolio und die Entwicklungs-Pipeline. In stark Marketing-orientierten Un-ternehmen ist eine enge Verflechtung des Marketing mit Rückkopplung in die Produktentwicklung zumindest in den Marketing-Bereichen Preispolitik, Produkt-gestaltung und Werbung [16] sowie beispielsweise im Bereich des umweltorien-tierten Marketing- zu sehen [41].

Am anderen Ende der Skala, in der Kundeneinzelfertigung oder im Anlagenbau, ist die Berücksichtigung der Kundenwünsche offensichtlich unabdingbar. Dazwi-schen gibt es jedoch einen breiten Raum von seriengefertigten Produkten, bei denen der Einfluss von Kundenwünschen und -anforderungen sehr unterschiedlich aus-geprägt ist. Dies betrifft sowohl den Anteil z. B. von kundenspezifischen Enginee-ring-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 Un-ternehmens mit Rückwirkung auf die Gestaltung der Produkte.

Selbst in Unternehmen, in deren strategischer Ausrichtung sich die Kundenorien-tierung 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:

Hoher Informationsbedarf zu Kundenwünschen und -erwartungen in frühen Phasen der Produktentwicklung Frühzeitige Kundeninteraktion in der Produktentwicklung (Teilaspekt von Collaboration-Szenarien)


Hohe Flexibilitätsanforderungen im gesamten Produktentstehungsprozess mit entsprechenden Auswirkungen auf die begleitenden Prozesse des Si-multaneous Engineering (Software-Entwicklung, Betriebsmittelprozesse, digitale Fabrik, …) Effiziente Methoden und Werkzeuge, um Entwicklungskapazitäten frühzei-tig auf die „richtigen“, d. h. die Kundenwünsche befriedigenden, Produkte zu fokussieren (Innovation, Time to Market) 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 Ver-triebsprozessen soll zunächst auf der Kundeninteraktion im Rahmen der Produkt-entwicklung liegen. Grad und Zeitpunkt der Kundeninteraktion sind stark branchenabhängig. Einige Aspekte dieser Kundeninteraktion sollen in den folgen-den Abschnitten näher betrachtet werden.

Während beispielsweise in der Konsumgüterindustrie Ergebnisse der Marktfor-schung sehr hohen Einfluss auf künftige Innovationsprojekte und die Gestaltung künftiger Produkte haben und deshalb bereits in der Ideenphase maßgeblich ein-fließ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 Inter-aktion 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 Risiko-potenzial. Zu denken ist dabei an

Inhaltlich vollständige und konsistente Definition der Anforderungen Vollständigkeit der dokumentierten Anforderungen Technische Realisierbarkeit Sicherstellen des selben Verständnisses bei allen Beteiligten

Dennoch wird die Dokumentation der Anforderungen in geeigneter Form und Re-quirements Engineering bzw. Requirements Management4 als Teil des Produkt- 4 Requirements Engineering bzw. Requirements Management wird hier verstanden als voll-ständige Aufnahme, Konsistenzsicherung und Dokumentation der Anforderungen verbun-den mit Änderungsprozessen für Änderungen der Anforderungen an das Produkt.


entwicklungsprozesses häufig nicht mit derselben Sorgfalt betrachtet wie bei-spielsweise rechtsverbindliche Produktdokumentationen. Nicht zuletzt deshalb wird im Rahmen dieses Buches nicht nur der klassische Produktentwicklungspro-zess betrachtet, sondern die gesamte Produktentstehung von der Produktidee bzw. Konzepten bis zur Markteinführung. Insbesondere im Anlagenbau ist das Requi-rements Engineering bereits Bestandteil des Engineering im Sinne der Produkt-entwicklung.

Jede Änderung der Anforderungsdefinition kann bereits ab der frühen Phase der Konzeptentwicklung erhebliche Auswirkungen auf das Konzept, die Reali-sierbarkeit, die erforderlichen Fertigungsprozesse und nicht zuletzt auf die Kosten des Produktes haben [5]. Deshalb sind bereits in der Phase der Anforderungsdefi-nition 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 Produkti-onsvorbereitung haben. Diesem Umstand wird häufig, aber beileibe nicht in allen betroffenen Unternehmen, dadurch Rechnung getragen, dass abteilungs- bzw. be-reichsübergreifende Entwicklungsteams gebildet werden. Zielsetzung dieser integ-rierten Entwicklungsteams ist es, neben der Vereinfachung der Kommunikation zwischen allen Beteiligten, sicherzustellen, dass alle erforderlichen Schritte ter-mingerecht, im Budgetrahmen und in hinreichender Qualität fertig gestellt wer-den. Außerdem sollen erforderliche Änderungen möglichst frühzeitig erkannt und umgesetzt werden und späte und damit aufwändige Änderungen vermieden wer-den. Dieser Aspekt gewinnt im Rahmen des Simultaneous Engineering an Bedeu-tung, da bereits in frühen Phasen der Produktentwicklung Änderungen Auswir-kungen auf andere Bereiche wie z. B. die Betriebsmittel- oder Werkzeugkonstruk-tion haben (siehe folgender Abschnitt). Zur Sicherung dieser Ziele werden in der Konzeptphase beispielsweise folgende Maßnahmen ergriffen:

Festlegung und Festschreibung grundlegender Designentscheidungen Zeitplanung und Modularisierung Definition von Entscheidungspunkten (Meilensteinen) und der erforderlichen Freigabeschritte und zu involvierenden bzw. informierenden Abteilungen Bereichsübergreifende Ressourceneinssatzplanung

Um sicherzustellen, dass die Kundenanforderungen bzw. die geplanten oder zuge-sicherten Produkteigenschaften dauerhaft erreicht werden, werden diese Maßnah-men unter anderem durch Methoden des präventiven Qualitätsmanagements unterstützt, z. B.:


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) PPAP: Production Part Approval, Verfahren zur Abnahme von Produkti-onsteilen in der Automobilindustrie; stellt grundlegende Anforderungen für das Vorgehen zur Erstmusterfreigabe von Produktions- und Ersatzteilen. 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 unternehmensinter-nen 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 Kundeninterak-tion und den Einfluss der Kunden auf unternehmensinterne Prozesse. In der Regel erfolgt die Kundeninteraktion auch unmittelbar, indem bestimmte Designentschei-dungen bzw. Freigaben in Abstimmung mit dem Kunden erfolgen oder bereits während der Konzepterstellung Abnahmen des Konzeptes durch den Kunden er-folgen. In der Konsumgüterindustrie erfolgt die Interaktion indirekt über Markt-forschungs- und Akzeptanzstudien zum Produktentwurf.

Die genannten Aspekte der Wechselwirkung zwischen den Prozessen der Pro-duktentwicklung 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 Konzeptpha-se sind hier insbesondere zu nennen:

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 Pro-duktlebenszyklus) unmittelbar zur Verfügung stehen. Änderungsmanagement von Anforderungen und Konzepten mit Bezug zwischen diesen: Die Auswirkungen von veränderten Anforderungen müs-sen in den Konzeptänderungen erkennbar sein und im Idealfall muss eine direkte Navigation möglich sein. 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 dokumen-tiert sind.


Wiederverwendung von Konzepten und Ergebnissen der Konzeptphase: Durch geeignete Strukturierung der Daten und Tools zur Suche und Na-vigation 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 Konzeptentwick-lung betrachtet. In diesem Abschnitt soll nunmehr die Produktentwicklung im en-geren 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 Ent-scheidung für die Konzeptdetaillierung darstellen.

Hingegen ist der kundenspezifische Produktentwicklungsprozess, z. B. bei Au-tomobilzulieferern, durch einen stark strukturierten Prozess gekennzeichnet. In-nerhalb dieses Prozesses sind Meilensteine oder Gateways definiert, die in der Regel auch Freigaben durch den Kunden beinhalten. Dies bedingt zum einen wie-derum die Prozessintegration zwischen Produktentwicklungsprozess und Ver-triebsprozess und stellt zum anderen auch Anforderungen an die unterstützenden IT-Systeme. Je nach Form der Kundeninteraktion muss die vollständige Doku-mentation zu den Meilensteinen für Vertriebsmitarbeiter oder unmittelbar für den Kunden zur Verfügung stehen, um auf dieser Basis die Freigabe zu erteilen. Insbe-sondere im letzteren Fall werden hohe Anforderungen an Collaboration-Tools ge-stellt, 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 Betriebssi-cherheit im Maschinen- und Anlagenbau dar. Dies ist streng genommen kein Pro-zess 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 Ausliefe-rung an den Kunden abgeschlossen. Der Trend geht hingegen zum Betrieb der An-lagen durch den Hersteller im Sinne von „Betreiben statt verkaufen“ [47]. Im Kontext dieses Kapitels bedeutet dies, dass die Kundeninteraktion für das produ-zierende Unternehmen nicht auf die Produktentwicklung und ggfs. Änderungen


am Produkt oder der Dokumentation beschränkt ist. Stattdessen werden hohe An-forderungen 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 zu-sä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 entste-henden Daten und die Aufbewahrungsfristen für die Dokumentation von Anlagen zu berücksichtigen, die Archivierungskonzepte erfordern, um jederzeit die einfa-che 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 Entwick-lungsbereich, sondern in der intensiven Zusammenarbeit verschiedener Entwick-lungsbereiche. Einige Beispiele sollen dies verdeutlichen:

In der Konsumgüterindustrie ist neben dem eigentlichen Produkt die Ver-packung mit entscheidend für den Erfolg oder Misserfolg des Produktes. Besonders offensichtlich ist dies beispielsweise bei Parfums mit in der Re-gel sehr aufwändig gestalteten Flacons. Aber auch bei Alltagsprodukten wie Lebensmitteln müssen neben der Attraktivität der Verpackung zusätz-liche Kriterien wie Beständigkeit, Praktikabilität in der Handhabung etc. berücksichtigt werden. Schließlich stellt gerade bei Produkten im Niedrig-preissegment die Verpackung einen wesentlichen Kostenfaktor dar. Aus all diesen Gründen ist die Verpackungsentwicklung ein eigener Bereich inner-halb der Produktentwicklung, die in enger Verzahnung mit der Entwick-lung des eigentlichen Produktes geschieht, da die Verpackung nicht zuletzt die Produkteigenschaften verstärken und unterstreichen soll. Bei der Entwicklung mechatronischer Komponenten erzeugt die Mechanik die sichtbare Wirkung z. B. in Form einer Bewegung eines Aktors. Die Re-gelung 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, woge-gen 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 spe-ziell 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 Be-reichen angesiedelt sein. Der Anlagenbau umfasst häufig sehr unterschiedliche Disziplinen und Ge-werke. Beispielsweise werden im Reinstraumbau hoch spezialisierte mecha-nische Entwicklungsaufgaben kombiniert mit sehr hohen Anforderungen an Lüftungs-, Klima- und Filtertechniken und hochempfindlichen Sensoren und entsprechender Steuerungselektronik. Trotz der erforderlichen starken Spezia-lisierung 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 Mit-arbeiter über längere Zeiträume exklusiv an einem Projekt arbeiten.

Diese, beliebig fortzusetzende, Liste zeigt, dass häufige und intensive Abstim-mungen zwischen den verschiedenen beteiligten Entwicklungsbereichen erforder-lich sind. Im Sinne der Prozessintegration ist deshalb zum einen zu prüfen, ob der Prozess durch Bildung von bereichsübergreifenden Projektteams unterstützt wer-den kann. Zum anderen sind geeignete Organisationsformen für die effiziente Pro-jektzusammenarbeit mit eindeutigen Zuständigkeiten, klar definierten Abstimm-punkten und Entscheidungswegen festzulegen.

Zunehmend erfolgt die Produktentwicklung nicht nur in abteilungsübergreifen-der, sondern auch in standortübergreifender Zusammenarbeit. Dies belegt das Er-gebnis einer Studie in der Fertigungsindustrie [22], nach der bereits 30% der Unternehmen standortübergreifende Zusammenarbeit realisiert haben, aber weite-re 51% dies planen. Die Ausgestaltung dieser Zusammenarbeit wird häufig durch die Bildung virtueller Teams realisiert. Diese Zusammenarbeit muss durch geeig-nete Werkzeuge, nicht nur für den Austausch der Daten, sondern für kollaborative Zusammenarbeit u.a. in folgenden Bereichen unterstützt werden:

Kommunikation und Kollaboration (siehe Kapitel 5.1 und 7.4) Projektmanagement 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ön-nen 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-


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 Integ-ration) spielt die Integration von Prozessen, die auf den Ergebnissen der Produkt-entwicklung 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 Produkti-onsvorbereitung 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 opti-mierter 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über-stehen [21]. Dies macht deutlich, dass durch die Berücksichtigung der Produkti-onsprozesse 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 Fertigungspla-nung, Arbeitsvorbereitung etc. Die Automobilindustrie ist Vorreiter dieser integ-rierten Produkt- und Prozessentwicklung.

Für den Betriebsmittel- und Werkzeugbau, ebenso wie für die Planung der Pro-duktionslinie 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 Pro-duktentstehung [21]

möglichst genaue Definition der Produkteigenschaften zu einem möglichst frühen Zeitpunkt in Abstimmung mit den betroffenen Fertigungsbereichen fortwährende Detaillierung der Produkteigenschaften im Laufe des Ent-wicklungsprozesses definierte Abstimmtermine zwischen Produktentwicklung und nachfolgen-den Prozessen Freigabeprozesse mit Dokumentation und Information aller beteiligter Be-reicheSicherstellen der Verfügbarkeit aktueller und vollständiger Produktdaten 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 Pro-zesse 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 ver-langen 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.


PLM

Prozess-

modell

Produkt-

modellWartung und

Service

ERP

Werkstatt-

steuerung

Manufacturing Execution

System

Produktionsauftragspaket

Arbeitspläne

Arbeitsanweisungen

Dokumente

Prozess-Konfiguration

Verbrauchsstoffe

Produktionsanforderungen

Werkzeuge

Mitarbeiterqualifikation

•E-BOM

•M-BOM

•Merkmale

•Produkt-

konfigurationÄnderungsanfragen

„As Built“-

Dokumentation /

Maschinenakte

•Rückmeldung

•Auftragsstatus

•Verbrauch

Arbeitsaufträge

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 An-forderungen 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 ei-ne 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 Zukauftei-len. 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 Komponen-ten 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

Zulieferer A

Zulieferer B

Zulieferer C

Zulieferer B

Verzögerung des Entwicklungsfortschrittes

Virtuelle Produktentstehung Zulieferer

Konzeptphase Serienfertigung

Virtuelle Produktentstehung Hersteller

Abb. 24. Frühe Integration von Zulieferern innerhalb der Produktentwicklung im Auto-mobilbau

den Datenaustausch: Während der Zulieferer genau so wie unternehmensinterne Entwicklungsabteilungen bei der integrierten Entwicklung Zugriff auf die relevan-ten Daten und Informationen benötigt, muss in externen Entwicklungskooperatio-nen 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 kauf-mä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 Kom-ponenten zu entscheiden, also die Make-or-buy-Entscheidung zu treffen. Diese Entscheidung kann Gegenstand strategischer Überlegungen sein, wie der Konzen-tration auf das Kerngeschäft, oder auf Grund fehlenden eigenen Know-hows bereits vorgegeben sein. Im Falle einer echten Entscheidungsalternative jedoch sind un-ternehmensinterne Parameter wie die Kapazitätsauslastung einzelner Fertigungs-bereiche, 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


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 Pro-duktentwicklung sichergestellt werden muss. Für die Alternativenentscheidung zwischen Eigenfertigung und Fremdbezug müssen jedoch zudem auch die Ferti-gungsbereiche mit involviert werden, um Herstellkosten der Eigenfertigung, Ka-pazitä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 recht-zeitig 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 zwi-schen Hersteller und Zulieferer erforderlich, der nicht nur prozessseitig klar defi-niert 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 schema-tisch auf die Anforderungen und mögliche Störfaktoren an den Schnittstellen zwi-schen 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 Unterneh-mensbereichen unterschiedlich betrachtet (vgl. Abb. 26):

Für die Konstruktion stehen der logische Aufbau aus funktionaler Sicht sowie die Wiederverwendbarkeit von Komponenten im Mittelpunkt der Produktstrukturierung. Zur Beurteilung der Baubarkeit und der Herstellkosten benötigt die Arbeits-vorbereitung eine Strukturierung des Produktes aus Fertigungs- bzw. Mon-tagesicht. Diese wird auch heute noch häufig parallel zur Konstruktions-struktur als eigenständige Datenstruktur erstellt und gepflegt. Zur Kostenkalkulation wird eine summarische, unstrukturierte Auflistung der Teile mit hinterlegten Mengen und Preisen benötigt. Aus Beschaffungssicht ist eine genaue Differenzierung nach Eigenferti-gungs- und Zukaufteilen erforderlich. Insbesondere wenn verschiedene Al-ternativen existieren. Beispielsweise kann ein Elektromotor mit integrier-tem Getriebe von einem einzigen Lieferanten bezogen werden, Motor und Getriebe von zwei verschiedenen Lieferanten oder aber das Getriebe eigen-gefertigt werden und nur der Motor zugekauft werden.

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


Zur Beurteilung der Sinnhaftigkeit einer Eigenfertigung und für die logistischen Prozesse der Beschaffung ist also nicht nur die Produktstruktur aus Sicht der Pro-duktentwicklung erforderlich, sondern zusätzlich die o.g. Strukturinformationen.

Durch die frühzeitige Einbindung von Lieferanten lassen sich jedoch auch be-reits 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ücksichti-gung auch später anfallender Folgekosten wie Vertriebskosten, Servicekosten etc. Basis dafür ist das so genannte Target Costing, d. h. die Betrachtung von Alterna-tiven innerhalb der Komponenten eines Produktes mit Festlegung der Zielkosten für die einzelnen Komponenten unter Berücksichtigung der verschiedenen Ein-flussgrößen. Insbesondere wenn die verschiedenen Komponenten von unterschied-lichen Lieferanten stammen, erfordern die Prozesse des Target Costing und Design to Cost intensive Abstimmungen aller Entwicklungspartner, um Schwan-kungen 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 Strukturie-rung der Komponenten beispielsweise für das Ersatzteilgeschäft in unterschiedli-cher 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 Liefe-rantenbeziehungen mit einbeziehen muss. Dies muss sowohl in der Definition der Prozesse als auch in der Gestaltung der Zuliefervereinbarungen und in der Aus-wahl und Implementierung der unterstützenden IT-Systeme ihren Niederschlag finden und erfordert im einzelnen Prozesse und IT-Unterstützung für

den Datenaustausch zwischen Entwicklungspartnern die Kommunikation der Entwicklungspartner die Dokumentation der gesamten Datenbasis inklusive sämtlicher Ände-rungen und Entscheidungen im Entwicklungsprozess 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.:

Qualitätsmanagement CollaborationProjektmanagement 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 integ-riertes 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 Pro-zesse 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


Die neue Form der collaborativen Zusammenarbeit hat Auswirkungen auf das Qua-litä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ätskon-trollen 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 Produktle-benszyklus 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ätsbe-wusstsein 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. Col-laboration ist für die meisten Unternehmen unumgänglich geworden, um weiter-hin 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 beteilig-ten Unternehmen schon beim Anforderungsmanagement erforderlich und geht weiter über Engineering Collaboration bis hin zur Zusammenarbeit bei Service-leistungen und Wartung der gelieferten Systemkomponenten. Diese komplexen und jetzt firmenübergreifenden Prozesse sind ohne durchgehende IT-Unter-

Produkt-spezifikation

Sammlung derProjekt-

dokumentation

ErsterDesign-

vorschlag

Monitoring desProjekt-

fortschritts

Informationzum Projekt-

status

Abschluss derEntwicklung

InternesReview

AbschließendesReview

Vergleichund

Übernahme

Kunde

Projekt-manager

Entwicklungs-partner

Abb. 28. Collaborative Engineering und Projektmanagement

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 Aufbau- und Ablauforganisationen wird bei allen am Prozess Beteiligten unumgänglich. Hieraus entstehen Herausforderungen wie:

Kooperative, virtuelle und integrierte Produktentstehungsprozesse Frühe und enge Einbeziehung von Engineeringpartnern Wachsende Anzahl von Experten und deren Wissen Projektorientierte Technologieentwicklung Gemeinsames Kosten- und Zeitmanagement Hohe Transparenz der Entscheidungsprozesse 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 entschei-dend geändert. Unternehmensfusionen, kürzere Produktlebenszyklen und die Ver-kü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 ver-schiedene Modelle unterschiedlicher Marken realisiert. Unterschiedliche Projekt-partner 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 Un-ternehmen: Die Kooperation innerhalb des Projekts – über Standorte und Unter-nehmen hinweg – muss reibungslos und zielgerichtet verlaufen.

Nach DIN 69 901 ist ein Projekt wie folgt definiert: „Ein Vorhaben, das im we-sentlichen durch eine Einmaligkeit der Bedingungen in ihrer Gesamtheit gekenn-zeichnet 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.


Ein Projekt:

hat eine klare Zielvorgabe ist zeitlich begrenzt durch einen definierten Beginn und ein definiertes Ende ist charakterisiert durch seine Einmaligkeit und Neuartigkeit ist komplex und nicht ohne eine strukturelle Gliederung durchzuführen hat einen vorgegebenen aufgabenbezogenen Kosten- oder Budgetrahmen wird innerhalb einer projektbezogenen Organisation abgewickelt benötigt definierte Ressourcen 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 er-reichen. Die unternehmensweite PM-Organisationsform sollte an die Wichtig-keit von Projektarbeit angepasst werden. In manchen Unternehmen werden Projekte lediglich als ergänzende Arbeitsform und verhältnismäßig selten einge-setzt, andere Unternehmen wiederum erbringen einen Großteil ihrer Wertschöp-fung in Projekten und können somit als „Projektorientiertes Unternehmen“ bezeichnet werden.

Abb. 29. Aufgaben und Prozesse im Projektmanagement

Service und Wartung 65

5.3 Service und Wartung

Der Stellenwert der Instandhaltung, im Speziellen der vorbeugenden Instandhal-tung, wächst in den letzten Jahren stetig. Gründe dafür sind z. B. dass die Pla-nungsauslastung 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 funktionie-renden Instandhaltung.

Eine moderne Instandhaltung ist durch zustandsbedingte Maßnahmen gekenn-zeichnet, deren Prinzipien lauten:

die vorbeugende, d. h. planbare Instandhaltung ist zu minimieren, die korrektive (nichtplanbare) Instandhaltung ist zu optimieren, 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 Sollzustan-des sowie zur Feststellung und Beurteilung des Ist-Zustandes von technischen Mitteln eines Systems“) definierten Funktionen hinaus. Themen wie die Arbeits-sicherheit gemäß Betriebssicherheitsverordnung, Umweltschutz, die Kosten- und Lagerbestandsoptimierung sowie die schnelle und effektive Einsatzplanung von in-ternen 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 Produktdatenmanage-ments, 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 Produktlebens-zyklus werden in diesem Abschnitt erläutert.

Danach gehen wir auf die Funktionen ein, die zur Realisierung eines umfassen-den Produktentwicklungsprozesses notwendig sind und damit aus Produktdaten-management 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 grundlegen-den Konzepten her entsprechen, nur im Detail anders ausgeprägt sind. Wir be-schrä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 Unterneh-mens 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 Produkt-lebenszyklus 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 be-kannt, sie werden aber über den Entwicklungsprozess hinweg zunehmend präzi-


siert und müssen nach ihrer Freigabe mit Hilfe von Funktionen des Änderungs-managements angepasst und überarbeitet werden.

Mangelnde Datenqualität der Produktstammdaten erzeugt eine Fülle von Fol-geproblemen nicht nur im Engineering, sondern in allen logistischen Anwen-dungsbereichen. 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 Änderungs-prozesse.

Bei einer etwas weiteren Fassung des Begriffes umfasst Produktdatenmanage-ment auch die den Produktionsprozess beschreibenden Stammdaten wie Ferti-gungshilfsmittel 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 Kon-struktionszeichnungen zurück. Dateien, beispielsweise aus CAD-Systemen, wur-den von einem zentralen System so verwaltet, dass sie in der Produktkonstruktion von verschiedenen Anwendern wieder gefunden werden konnten (Zeichnungs-verwaltung). Heute hat sich der Anwendungsbereich einer Dokumentenverwal-tung 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 Zusam-menhang mit der Konstruktion stehend – deren Ablage in einem Dokumentenver-waltungssystem Sinn macht, von technischen Berichten und Montageanweisungen bis hin zu Betriebsanleitungen. Nicht nur die Menge der zu verwaltenden Doku-mente hat zugenommen, es sind auch verschiedenste Dateitypen mit verschiede-nen zugeordneten Anwendungen (von der Textverarbeitung bis zum Auslegungs-programm) in vielfältigen logischen Dokumentklassen zu organisieren.

Die nächsten Abschnitte beschreiben die Kernfunktionen eines Dokumenten-managementsystems (DMS).

6.1.1.1 Strukturierung von Dokumenten

Bildung von Dokumentenklassen / Dokumentarten: durch Gruppierung wer-den gleichartige Dokumente geordnet, Dokumentklassen definieren z. B. welche beschreibenden Attribute oder welche Funktionen nutzbar sind. Bildung von Dokumentenstammsätzen: Dies sind logische Dokumente, de-nen ein oder mehrere physische Dokumente (Dateien, Originale) zugeord-net werden. Stammsatz und zugeordnete Dateien bilden eine Einheit, die vereinfachend oft als „das Dokument“ bezeichnet wird.

Das Produktdatenmanagement 69

Dateien oder Originale: Das System verwaltet die Dateien, es sorgt für de-ren Speicherung und stellt sie bei Bedarf wieder zur Verfügung. In der Re-gel ist die zugehörige Applikation, mit der das Dokument bearbeitet oder angezeigt werden kann, mit dem DMS verknüpft. 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 techni-scher Möglichkeiten (Freitextfelder, Schlagwortkataloge, Klassifizierung).

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


Verknüpfung: Dokumente können untereinander durch Bildung von Doku-mentenstrukturen oder Hierarchien in Beziehung gesetzt werden. Noch wich-tiger 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 hin-aus zu ERP-Objekten wie z. B. Projekten verknüpft werden können. 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

Ablage: Das DMS kontrolliert und speichert die Metadaten und die zugehö-rigen Originaldateien. In der Regel wird für Dateien ein anderes Ablageme-dium (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. Recherche: Die Suche nach Dokumenten muss über die eingegebenen Me-tadaten, 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. Volltextsuche: Zusätzlich wird oft gefordert, insbesondere bei Office-Dokumenten, 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. 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. Änderungen an freigegebenen Dokumenten führen in der Regel zur Bil-dung neuer Versionen. Diese werden nach einer definierten Bildungsvor-schrift mit Versionsnummern versehen; alte Versionsstände werden zur Dokumentation meist aufbewahrt. Die Versionierung muss in das weiter unten beschriebene Änderungsmanagement integriert sein. 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).


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

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


Abb. 32. Visualisierung eines Dokumentenverwaltungssatzes mit dem im SAP DMS integ-rierten 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

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 Hervorhe-bungen werden dabei als separate Layer verwaltet und über das Doku-ment geblendet. Außerdem sollte aus häufig genutzten externen Applikationen auch eine di-rekte Ü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 ar-beitet. Die speziellen Funktionen der CAD-Integration werden in Abschnitt 6.1.5 beschrieben.


Workflow: Insbesondere für Prüf- und Freigabeschritte sowie für Doku-mentenverteilung 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 Sta-tus der zugehörigen Artikelstammsätzen synchron zu halten sind. Konvertierungsfunktion: bietet die Möglichkeit – meist durch Anbindung kommerziell verfügbarer Konverter – Dateien von einem Applikationsfor-mat (z. B. Office-Anwendung oder CAD) in ein Langzeitformat (z. B. PDF5

oder TIFF6) umzusetzen. Output-Management: Nach Einführung einer elektronischen Dokumentab-lage besteht natürlich auch weiterhin die Notwendigkeit, Dokumente aus-zudrucken. 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 CAD-Schriftfeld (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 automa-tisch zusammengestellt werden, z. B. alle Dokumente zu einer Produkt-struktur, 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 unterschiedli-che Medien wie Mail und Postversand.

Hierzu dienen entweder in der Dokumentenverwaltung integrierte Funktio-nen (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 Raster-format 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 reali-siert sind.


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 Einzel-fall bedarfsgerecht (Scan on demand) in elektronische Formate zu überfüh-ren. 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 Objektver-knü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 ge-geneinander abgewogen werden.

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


Volltext-DMS: Systeme, bei denen Volltextrecherche auf einer Volltextda-tenbank 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. 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, Maschinen-akte, Vorgangsmappe). Mittels einer „Umlaufmappe“ können Workflows zur Abbildung von Vorgängen realisiert werden. Diese Arbeitsweise ist ge-rade 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 funkti-onal, 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 CAD-Modelle und Zeichnungen enthalten.

Produkt

Teilestammsatz Teilestammsatz

TeilestammsatzTeilestammsatz

Dokumenten-stammsatz

Cad-Modell Zeichnung

Montage-anweisung

Betriebs-anleitung

Entwicklungs-projekt

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 Teile-stammsatz hat eine identifizierende Nummer (Artikelnummer, Teilenummer) und beschreibende Felder wie Bezeichnung, Artikelart, Produktgruppe, Werkstoff und Gewicht.


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 Stan-dardfelder auf der so genannten Grunddatensicht, die allgemeine Teile-Informa-tionen 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 be-schrieben.

Durch hierarchische Anordnung der Bestandteile und Strukturbildung entsteht eine Maschine oder Anlage; erst dadurch werden klassische Konstruktionsprinzi-pien wie Standardisierung, Wiederverwendung, Baukastenstrukturierung und Concurrent Engineering möglich.

Das entstehende Produktmodell mit Baugruppen, Teilestämmen, Halbfertigtei-len 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 Be-arbeitung ausgewählt.


Die ursprüngliche Konstruktions- oder Entwicklungsstückliste muss für die Ver-wendung in nachgelagerten Prozessen um zusätzliche Informationen angereichert oder anders ausgeprägt werden. Einige Beispiele für zusätzliche Anforderungen:

Es wird festgelegt, ob Bauteile zugekauft oder gefertigt werden, welche Rohmaterialien und Halbfertigteile zu benutzen sind oder es wird das Ein- und Auslaufen von Teilen nach Änderungen gesteuert. In der Arbeitsvorbereitung werden auf Basis der Stücklisten der Produkti-ons- oder Montageprozess und die Steuerung der Maschinen geplant. Im Vertrieb werden Stücklisten als Erfassungshilfe bei der Eingabe von Kundenaufträgen genutzt. 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:

Konstruktionsstückliste: gliedert das Produkt nach konstruktiven Gesichts-punkten meist funktional, weist eine eher geringe Stücklistentiefe auf Fertigungs- oder Montagestückliste: Wird von der Arbeitsvorbereitung er-stellt, 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.). Kalkulationsstückliste: gliedert das Produkt gemäß der Kalkulationsrele-vanz 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 – Organisations-ebenen (z. B. die Werke, in denen die Stückliste benutzt wird) abgebildet. Meist wird die Entwicklungsstückliste als unternehmensweit gültige Stückliste ange-nommen, 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:

Stücklistenkopf: beschreibende Daten, die sich auf die ganze Stückliste be-ziehen (textuelle Beschreibung, Status zur Einschränkung der Verwendung, Losgröße); stellt die Relation zum durch die Stückliste beschriebenen Teile-stamm her. Stücklistenposition: Beschreibung der in der Baugruppe verbauten Teile mit Informationen wie Bezeichnung, Teilenummer, Menge und Einheit;


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. Mehrfachstücklisten: repräsentieren unterschiedliche Alternativen, bei-spielsweise für verschiedene Losgrößenbereiche. 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

Teileverwendungsnachweis: Sucht alle Stücklisten, in denen eine Kompo-nente verwendet wird.

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


StücklistenvergleichFunktionen 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 kon-figurierte 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 Konstruk-tionsprozess 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 Zeich-nungen aufgebaut, gerade im ERP-System können meist beliebige andere Ge-schäftsobjekte ebenfalls klassifiziert werden. Klassifizierungen sind nicht der einzige Weg zu einer erfolgreichen Suche – sie ergänzen die Suche über Objekt-schlü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, be-schrieben. 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 Klassifizie-rungsverfahren, bei dem die Objekte in Baumstrukturen kategorisiert werden.

Die Kategorien entstehen, indem Klassen gebildet werden, denen bestimmte Ei-genschaften (Merkmale) zugeordnet sind. Die Klassen werden in Baumstrukturen


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 die-nen 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 Normteilbib-liotheken Verwendung finden.

vom Allgem

einen zum

Speziellenvom

Allgemeinen zum

Speziellen

Solargenerator

EigenschaftenLeistung [W]Masse [kg]

RotationsgeneratorFaltflächengenerator

EigenschaftenFreiheitsgradeEntfaltungstyp

EigenschaftenWinkelge-

schwindigkeit

vom Allgem

einen zum

Speziellenvom

Allgemeinen zum

Speziellen

Solargenerator

EigenschaftenLeistung [W]Masse [kg]

RotationsgeneratorFaltflächengenerator

EigenschaftenFreiheitsgradeEntfaltungstyp

EigenschaftenWinkelge-

schwindigkeit

Abb. 37. Klassenhierarchie mit zugeordneten Eigenschaften (Merkmale)

6.1.4 Variantenkonfiguration / Produktkonfiguration

Bei der Definition komplexer, variantenreicher Produkte kann die Variantenkonfi-guration 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 generi-sche Produktstruktur, die ihre Abbildung in Form einer Maximalstückliste und ei-nes 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 Pro-grammiermodelle:

Durch Regeln (Constraints) werden – in Abhängigkeit von der Beschrei-bung des Endprodukts – sukzessive alternative Komponenten in der Stück-liste oder alternative Arbeitsplanvorgänge ausgewählt. Regeln können auch Werte in den Produktstrukturdaten verändern (z. B. Einsatzmenge).


regelbasierte Ablei-

tungder Stückliste

KundenauftragPosition 1

Pumpe HGT

Bewertung der Merkmale Land: Deutschland

Typ: HGT32

Netz: 230 V

Förderhöhe: 3 m

Antrieb:Kolbenpumpe

Medium: Wasser

Stahl 47Kreisel< 10 m110HGT32Guss 49Kolben< 10 m230HGT32Guss 47Kolben< 2 m230HGT32GehäuseAntriebHöheNetzTyp

Auszug der Regeltabelle

Maximalstückliste

0010 – G453 Gehäuse Guss 470010 – G458 Gehäuse Guss 490010 – G612 Gehäuse Stahl 47

regelbasierte Ablei-

tungder Stückliste

KundenauftragPosition 1

Pumpe HGT

Bewertung der Merkmale Land: Deutschland

Typ: HGT32

Netz: 230 V

Förderhöhe: 3 m

Antrieb:Kolbenpumpe

Medium: Wasser

Stahl 47Kreisel< 10 m110HGT32Guss 49Kolben< 10 m230HGT32Guss 47Kolben< 2 m230HGT32GehäuseAntriebHöheNetzTyp

Auszug der Regeltabelle

Maximalstückliste

0010 – G453 Gehäuse Guss 470010 – G458 Gehäuse Guss 490010 – G612 Gehäuse Stahl 47

Abb. 38. Funktionsprinzip der Variantenkonfiguration

In Entscheidungstabellen sind die verschiedenen möglichen Kombinationen abgelegt In Entscheidungsbäumen ist die Sequenz der zu treffenden Entscheidungen abgelegt und wird nacheinander durchlaufen.

Funktional benötigt man ein Tool zum Erstellen der Konfigurationslogik, danach muss diese Logik in verschiedene Anwendungsprozesse integriert werden: In der Produktentwicklung will man verschiedene Konfigurationen simulieren. In der Auftragsbearbeitung muss vom Vertriebsmitarbeiter oder Kunden in einem Bild-schirmdialog die Produkteigenschaft durch Bewertung der Sachmerkmale spezifi-ziert werden. Eine Logik leitet dann aus der Maximalstruktur, dem Regelwerk und den Entscheidungstabellen die kundenspezifische Produktkonfiguration ab. Pro-zesse wie Beschaffung, Produktion und Vertriebskalkulation müssen die Konfigu-ration berücksichtigen.

Inhaltlich kann die Variantenkonfiguration in verschiedenen Szenarien aus-geprägt werden: Beispielsweise stellt man die Kundensicht in den Vordergrund und erlaubt den Kunden, durch Merkmalsbewertung eine Maschine oder Anlage zu konfigurieren, ohne dass der Kunde technisches Produktwissen mitbringen muss. Durch die Konfigurationslogik wird eine fehlerfreie Produktzusammen-stellung (z. B. aus auf Lager produzierten Standardkomponenten) garantiert. Damit erreicht man eine Quasi-Standardisierung des Verkaufsprozesses (bei ho-her Wahlfreiheit für die Kunden), eine effizientere Auftragsabwicklung und


trotzdem eine Lenkung hin auf ein standardisiertes Produktprogramm. Dieses Szenario wird insbesondere dort eingesetzt, wo die Produkte in Web-Shops im Internet konfiguriert werden können.

Statt des Fokus Verkaufskonfiguration kann natürlich auch die technische Aus-legung eines Produktes durch die Konfiguration im Vordergrund stehen (Ausle-gungslogik) oder die gesamte Produktstruktur durch Konfiguration entstehen (Produktlogik). Es sind ein- oder mehrstufige Konfigurationsszenarien denkbar, bei letzteren wird ein Produkt aus wiederum eigenständig konfigurierbaren Kom-ponenten zusammengebaut.

Bei stark auf Einzelfertigung ausgerichteten Produkten ist es oft notwendig, die konfigurierte Produktstruktur individuell für den Kunden technisch nachzubear-beiten. Damit hier nicht jedes Mal eine neue Stücklistenstruktur aufgebaut werden muss, gibt es die Möglichkeit, die konfigurierte Stückliste als Auftragsstücklistein der Konstruktion abzuändern.

6.1.5 Funktionen zur Integration CAD mit PLM

In der Produktentwicklung des Maschinen- und Anlagenbaus und der Automobil-industrie wird zum Aufbau des zuvor beschriebenen Produktmodells fast immer CAD-Technologie eingesetzt. Daher kommt, will man eine effiziente Abwicklung des Produktentwicklungsprozesses gewährleisten, der Integration von CAD-Anwendungen in PLM-Systeme besondere Bedeutung zu. Ein PLM-System ist ohne gute CAD-Schnittstellen in den genannten Industriesegmenten praktisch nutzlos.

6.1.5.1 Integrationsarchitektur

Kernaufgabe der Integration ist es, eine Abbildung des CAD-Datenmodells und der CAD-Arbeitsergebnisse auf die Geschäfts- und Datenobjekte im PDM-Datenmodell zu erzielen. Ergebnis der CAD-Anwendung sind entweder 2D-Ansichten und Zeichnungen oder 3D-CAD-Modelle mit daraus abgeleiteten Zeichnungen und Berechnungsergebnissen.

Unter funktionalen Gesichtspunkten kann die Integration zum einen durch die CAD-Systeme selbst aber auch durch die unterschiedlichen Anforderungen im Geschäftsprozess stark differieren. Wesentliche systemspezifische Einflussfaktoren sind unter anderem:

ob es sich um ein 2D- oder 3D-CAD-System handelt wie das CAD-System die Modelle, Modellstrukturen sowie Zeichnungen speichert ob das CAD-System über ein eigenes Datenmanagement verfügt wie und wo Normteile verwaltet werden


CAD

Non-SAP PDM

ERP-

Anwendung Anwendung

CADCAD

Non-SAP PDM

ERP-

Anwendung

ERP- + PLM-

Anwendung

CAD

Abb. 39. Alternative Integrationsszenarien CAD / ERP in einer SAP-Architektur

Beim Einsatz von SAP ist einmal eine 3-Systemarchitektur möglich, bei der das PDM-System als dezidiertes System ausgeprägt ist (oder es sich um ein eng ans CAD-System angebundenes Datenmanagement handelt). Die im CAD-System vorliegende Semantik wird auf die PDM-Welt abgebildet, von dort erfolgt wie-derum eine Abbildung auf die Verarbeitungslogik im ERP.

Da SAP PLM alle notwendigen PDM- und PLM-Funktionen direkt beinhaltet, ist auch eine 2-Systemarchitektur möglich: Die CAD-Welt wird direkt in das ERP-System integriert, ein separates PDM-System wird dadurch überflüssig.

Zur Beurteilung, welches Integrationsszenario letztlich für ein Unternehmen das richtige ist, müssen z. B. folgende Punkte geprüft werden:

ob die Wertschöpfung überwiegend im Fertigungs- oder Engineeringbe-reich erfolgt ob einfache oder komplexe Produkte hergestellt werden und die CAD-Modelle hohe oder niedrige Komplexität besitzen ob eine homogene oder heterogene CAD-Infrastruktur vorliegt ob einfache oder komplexe Entwicklungsprozesse, evtl. mit Integration ex-terner Partner vorliegen

6.1.5.2 Funktionale Integration

In der Regel präsentieren sich CAD- und PDM-System dem Anwender in zwei heterogenen Applikationen, die lose miteinander gekoppelt sind. Für deren Integ-ration sind zwei technische Formen denkbar:

Die Integration wird oft dadurch gewährleistet, dass der Anwender aus seiner CAD-Applikation Funktionen im PDM-System aufrufen kann (Dokument ablegen, Dokument suchen, Artikel anlegen). Der CAD-Anwender arbeitet dann nur in sei-nem CAD-Client, Funktionen zum Definieren und Manipulieren der PDM-Daten sind dort integriert, er muss seine vertraute Umgebung nicht verlassen.


Abb. 40. CAD-Direktintegration in SAP: Aus der Unigraphics-Oberfläche können direkt Funktionen zum Suchen und Anlegen von Dokumenten, Materialstammsätzen und Pro-duktstrukturen in SAP angesteuert werden.

Beim zweiten Ansatz arbeitet der Anwender im PDM- oder ERP-System, dort werden Dokumente, Artikel und Strukturdaten gefunden und manipuliert. Wenn Modelle oder Zeichnungen zu bearbeiten sind, wird die CAD-Applikation aufge-rufen und mit den richtigen Daten versorgt. Dieses Modell trägt dem Ansatz Rech-nung, dass bei vielen Prozessen in einer integrierten Anwendung das PDM-System führendes und aktionsauslösendes System ist.

Insgesamt muss die Integration – egal wie sie technologisch ausgeprägt wird – folgende Funktionsblöcke unterstützen:

Modell- und Zeichnungsverwaltung: Ansichten und Modelle von Teilen und Bau-gruppen müssen aus der CAD-Welt im PDM-System abgelegt werden. Dies ist in der Regel mit einem bidirektionalen Datenaustausch verbunden, bei dem das CAD-System die CAD-Datenfiles an das PDM-System übergibt und Schlüssel-informationen wie Teilenummer, Version, Ablagepfad zwischen PDM und CAD synchronisiert werden.

Im PDM-System entstehen dadurch Dokumentenstammsätze, in denen die Zeichnungen abgelegt sind (bzw. im 3D-Bereich komplexe Strukturen von Doku-mentenstammsätzen, welche die Modellstrukturen repräsentieren). Durch diese Schnittstellenfunktion sind später das Laden von CAD-Ansichten und Modellen über das PDM-System und der Check-Out in die CAD-Arbeitsumgebung möglich.


Bei der Realisierung einer konkreten Lösung ist zu prüfen, ob im PDM-System nur (gegebenenfalls proprietäre) CAD-Formate abgelegt werden oder ergänzend eine Konvertierung in Standard-Datenaustauschformate wie Direct Model oder TIFF erfolgt.

Teilemanagement und Klassifikation: Neben Dokumentenstammsätzen müssen im PDM-System auch Teilestammsätze aufgebaut werden. Dazu übergibt das CAD-System aus der Geometrie ableitbare Größen wie Volumen oder Gewicht an das PDM-System, dort werden diese zu Attributen des Teilestammsatzes. Schlüsselin-formationen wie Teilenummer oder Version müssen zwischen beiden Systemwelten abgeglichen bzw. bei Neuanlage erzeugt werden. Dazu ist ein Nummerngenerator meist auf ERP-Seite vorhanden. Gegebenenfalls werden auch Attribute in die Klassifizierung oder Sachmerkmalleiste des Teilestammes übertragen.

Die Erzeugung von Teilestammsätzen erfolgt meist in zeitlichem Zusammen-hang mit der Übertragung von Zeichnungen oder Modellen in Dokumenten-stammsätze, Teilestammsätze werden mit den Dokumentinformationen verknüpft. Dies ist notwendige Voraussetzung für eine Recherche im PDM-System und er-möglicht den im Folgenden beschriebenen Aufbau der Produktstrukturen.

Produktstrukturmanagement: Im CAD-System entsteht nicht nur eine zweidi-mensionale Zeichnung, sondern eine Komponentenstruktur mit einer räumlichen Anordnung der Komponenten. Wichtig ist, dass die interne Struktur des CAD-Modells im CAD-System nicht in jedem Falle mit der Produktstruktursicht über-einstimmen muss. Die abgeleitete Produktstruktur kann also durchaus von der Dokumentenstruktur, die aus dem CAD-System heraus erzeugt wird, abweichen – dies spiegelt auch die unterschiedlichen Sichten von Konstruktion und Ferti-gung auf die Produktstruktur wieder. Diese Abhängigkeiten zwischen CAD-Files und Assemblies einerseits und Materialien und Baugruppen andererseits müssen durch eine geeignete Referenzierungslogik in der Schnittstelle CAD – PLM abgebildet werden.

Neben den genannten Funktionen sind bei Überführung des CAD-Modells in das PDM-System auch Vorkehrungen zu treffen, um das Produkt dort dreidimen-sional darzustellen und verschiedene Arten von Simulation des Produktes zu er-möglichen. Beispielsweise um Zusammenbau und Passgenauigkeit zu prüfen oder Montageplanung vorzunehmen. Man bezeichnet diese Funktionen auch als Digital Mockup (DMU), eine nähere Darstellung enthält Abschnitt 7.3.

6.1.6 Änderungsmanagement

Wie bereits im Kapitel 2 erläutert, kommt der Gestaltung und IT-Unterstützung des Änderungsprozesses hohe Bedeutung zu. Nicht nur um bei Produktänderungen weiterhin konsistente Daten zu garantieren und die historischen Änderungsstände reproduzierbar zu machen, sondern auch weil eine Änderung sehr viele Bereiche im Unternehmen betrifft.


Die Maßnahmen und Instrumente zur Beurteilung, Dokumentation, Einführung und Verifikation von Änderungen lassen sich in zwei Bereiche unterteilen:

Das Änderungsmanagement8 unterstützt die Abwicklung des Änderungs-prozesses vom Änderungsvorschlag über die Genehmigung und Durchfüh-rung bis zur Freigabe der Änderung. Das im nächsten Abschnitt beschriebene Konfigurationsmanagement9 doku-mentiert alle Zustände, die ein Produkt über seinen Lebenszyklus annimmt und wie es sich von der Entwicklung bis zur Auslieferung und Wartung suk-zessive verändert. Es erlaubt, die genaue Ausprägung des Produktes zu einem bestimmten Zeitpunkt (z. B. as-engineered, as-sold, as-planned, as-built) flexibel aber umfassend festzuhalten.

6.1.6.1 Objekte und Prozess des Änderungsmanagements

Der Änderungsprozess teilt sich in der Regel in den Vorlauf (vom Erkennen eines Änderungsbedarfs bis zur Genehmigung der Änderung) und die Änderungsdurch-führung (nach [30]). Es werden folgende Objekte im System abgebildet:

Änderungsvorschlag oder Änderungsmeldung10: bietet unternehmensin-ternen und -externen Anwendern die Möglichkeit, Verbesserungs- oder Änderungsvorschläge zu einem Produkt einzubringen und damit einen Änderungsprozess zu starten. Im System können dabei – oft über eine einfache Browser-Oberfläche – Gründe für die Änderung benannt und durch angehängte Dokumente näher erläutert werden. Die Änderungsan-forderung wird möglichst genau beschrieben. Diese Meldung wird dann – meist workflowunterstützt – an einen Verantwortlichen oder ein Gremi-um weitergeleitet, das den Vorschlag bewertet und bei positiver Ent-scheidung einen Änderungsantrag anlegt. Änderungsantrag11: Vorstufe zum Änderungsauftrag, enthält – neben den aus der Änderungsmeldung übernommenen Daten zur Begründung der Än-derung – bereits einen Verweis auf die zu ändernden Objekte. Dazu muss der Änderungsantrag eine Verknüpfung mit den zu ändernden Stammda-tenobjekten erlauben: Neben Standard-PDM-Objekten wie Artikel, Doku-ment, Stückliste und Arbeitspläne müssen z. B. auch Änderungen an Klassifizierungen und Objekten der Variantenkonfiguration unterstützt werden. Im Prozess der formalen Prüfung der Änderung werden oft eine Gesamtprüfung des Antrags und Prüfungen der einzelnen Änderungsobjekte

8 Auch Änderungswesen, Änderungsdienst 9 Oft auch Lifecycle-Management genannt 10 In Terminologie von SAP PLM auch als Claim-Management bezeichnet 11 Auch Engineering Change Request (ECR)


unterschieden. Werden bei der detaillierten Untersuchung der Änderungs-auswirkungen weitere Objekte als betroffen identifiziert, können diese na-türlich noch integriert werden.

Änderungsauftrag12: entsteht nach Genehmigung in der Regel automatisch aus dem Änderungsantrag. Er enthält alle durchzuführenden Einzelände-rungen, möglichst mit Beschreibung, und stellt somit eine Auftragsliste dar, die bei Änderungsdurchführung abzuarbeiten ist. Alle geänderten oder im Rahmen der Änderung neu erzeugten Objekte werden durch Aufnahme in den Änderungsauftrag gesammelt. Die Freigabe der Änderung erfolgt eben-falls im Änderungsauftrag. Somit bildet dieser eine Klammer über alle zusammengehörenden Änderungen unterschiedlicher Objekte und doku-mentiert im Zusammenspiel mit dem Änderungsantrag auch den Prüf- und Freigabeprozess.

Strukturierung von Änderungen: bei komplexen Änderungen mit einer Vielzahl von betroffenen Objekten ist es oft sinnvoll, statt eines Ände-rungsauftrages eine funktionale oder organisatorische Strukturierung13 in Form von Änderungshierarchien vorzunehmen. Die einzelnen Änderun-gen werden dabei auf verschiedene Änderungsaufträge oder Änderungs-pakete aufgeteilt, die aber insgesamt durch eine Änderungseinheit geklammert werden. Damit bleibt gewährleistet, dass die Änderung ins-gesamt als Einheit identifizierbar ist, aber in Pakete unterteilt bearbeitet werden kann.

Änderungs-initiierung

Änderungs-antrag

PrüfungÄnderungsantrag

Änderungs-auftrag

Änderungs-freigabe

Projektmanagement

EngineeringCollaboration

Änderungs-durchführung

Abb. 41. Änderungsprozess mit typischen Objekten und Beteiligten

12 Auch als Engineering Change Order (ECO) oder einfach als Änderungsstammsatz be-zeichnet 13 Eine organisatorische Strukturierung könnte z. B. alle Änderungsobjekte klammern, für die eine bestimmte Gruppe in der Konstruktion zuständig ist. Eine funktionale Gliederung könnte mechanische von elektronischen Objekten trennen.


6.1.6.2 Funktionen des Änderungsmanagements

Ein umfassendes Änderungsmanagement realisiert folgende Systemfunktionen:

Identifikation durch Änderungsnummern, Gültigkeiten, Versionen oder Revisionen: Änderungen werden durch Änderungsnummern identifiziert und mit einer zeitlichen Gültigkeit versehen. In der Regel gilt ein Ände-rungsstand beginnend mit dem „Gültig-ab Datum“ des Änderungsauftrages bis zur nächsten Änderung. Bestimmte Änderungsstände – nicht nur bei Dokumenten, sondern auch bei anderen PDM-Objekten – werden oft zu-sätzlich (aufsteigend nummeriert) durch Versionen oder Revisionsstände identifiziert.Historisierung / Nachvollziehbarkeit: Durch das Zusammenspiel des Ände-rungsmanagements mit den Produktdaten muss es möglich sein, jeden his-torischen Stand des Produktmodells und der beteiligten Datenobjekte zu reproduzieren, d. h. auswertbar und nachvollziehbar zu machen, wann wel-che Änderungen vorgenommen wurden und wie die Objekte vor und nach der Änderung ausgesehen haben. Damit wird es dann auch möglich, zur gleichen Zeit in unterschiedlichen Prozessen oder Funktionsbereichen mit unterschiedlichen Änderungsständen zu arbeiten (Beispiel: die Montage arbeitet mit einer Stückliste nach älterem Stand während in der Arbeitsvor-bereitung schon auf die neue Stückliste umgestellt wird). Statuskonzept: Um die jeweiligen Zustände einer Änderung (beantragt, ge-nehmigt, in Arbeit, freigegeben) und der einzelnen Änderungsobjekte do-kumentieren zu können, wird ein Statuskonzept genutzt. Durch das Zusammenspiel von einzelner Objektänderung mit der Gesamtänderung und die vielen Beteiligten und Entscheidungsvorgänge wird das Status-schema leicht komplex. Workflow: Genehmigung und Freigabe der Änderung sowie Verteilung der geänderten Objekte sind typische Prozesse, bei denen eine workflow-gesteuerte Benachrichtigung der Beteiligten zur Stabilisierung und Be-schleunigung der Abwicklung beitragen kann. Hier kommt oft auch das bereits im Abschnitt 6.1.1.2 erläuterte Verfahren zur Digitalen Signatur zum Einsatz. Workflow unterstützt nicht nur die eigentliche Durchführung der Änderung in der Produktkonstruktion, sondern auch die damit verbun-denen Tätigkeiten in nachgelagerten Bereichen (Arbeitsvorbereitung, Dis-position, Einkauf usw.). Änderungsverteilung: Die Dokumentation der geänderten Objekte, wie Zeichnungen und Stücklisten, meist aber auch weitere Informationen wie Änderungsantrag und Änderungsdokumentation sind nach Änderungsab-schluss an Beteiligte und von der Änderung betroffene Bereiche zu verteilen. Wo möglich ist eine elektronische Verteilung, integriert in den Workflow zur Änderungsabwicklung, einer papierbasierten Verteilung vorzuziehen.


Bei der Prozessgestaltung des Änderungsprozesses sind besonders die Änderun-gen zu beachten, die über die Produktentwicklung hinaus reichen. Zum Beispiel Änderungen, die Auswirkungen auf in Serie produzierte Teile haben oder die eine in Montage befindliche Anlage betreffen. Hier ist die Zusammenarbeit aller Berei-che zu steuern, die von der Änderung betroffen sind oder an der Änderung mitar-beiten. Solche Änderungen können insbesondere Nacharbeiten an ERP-Objekten wie Montageaufträgen, Fertigungsaufträgen oder Bestellungen zur Folge haben. ERP-Systeme wie SAP bieten Funktionen, diese logistische Einsteuerung von Än-derungen zu unterstützen14.

Ein Beispiel für die Steuerung eines solchen Prozesses zeigt Abschnitt 6.7.3.3. Mit vordefinierten Workflow-Abläufen je nach Art der Änderung können der ge-naue Änderungsablauf und die zu involvierenden Verantwortlichen oder Abtei-lungen bestimmt werden.

6.1.7 Konfigurationsmanagement

Eine Konfiguration bezeichnet gemäß ISO 10007 alle funktionellen und physischen Merkmale eines Produktes, wie sie (zu einem bestimmten Zeitpunkt) in Dokumen-ten beschrieben und im Produkt verwirklicht sind. Ziel des Konfigurationsmanage-ments ist es, den Zustand eines Produktes über seinen Produktlebenszyklus (z. B. in Engineering, Produktion, Montage und Wartung) genau zu dokumentieren.

as shippedas sold

as designed

as engineered

as planned

as built

as maintained

Freigabe Variantenmgmt. Konsistenzprüfung Änderungsmanagement

Engineering

Production / Procurement

Maintenance

Sales / Shipping

Engineering

Production / Procurement

Maintenance

Sales / Shipping

Abb. 42. Der Lebenszyklus im Konfigurationsmanagement 14 Ein- und Auslaufsteuerung sowie Order Change Management, um den Bezug einer Ände-rung zu einzelnen bereits ausgelösten Fertigungsaufträgen herzustellen


Es besteht eine enge Verbindung zum Produktdatenmanagement und insbesondere dem Änderungsmanagement, weil neben der Konfiguration des ursprünglich ent-wickelten Produktes auch die durch Produktänderungen „in regelmäßigen Abstän-den hinzukommenden Änderungskonfigurationen“ (nach [48], S.233) zu dokumen-tieren sind. Jede Änderung erzeugt gemäß Definition eine neue Produktkonfigura-tion.

Konfigurationsmanagement bindet eine Reihe von betrieblichen Funktionsbe-reichen ein und unterstützt durch übergreifende Dokumentation alle Abteilungen, die am Produktlebenszyklus mitarbeiten: Produktentwicklung, Engineering, Ar-beitsvorbereitung, Disposition, Produktion und Service oder Instandhaltung.

Die Anforderung zur Dokumentation des Produktlebenszyklus entsteht auch bei Serienfertigern, höher sind die Anforderungen aber bei Einzelfertigern oder Un-ternehmen, die neben dem Standardprodukt (der Standardkonfiguration, eventuell in Serienproduktion) auch kundenspezifische Produktkonfigurationen produzieren. Hier steigt die Anzahl der zu verfolgenden Zustände stark an, Konfigurationsma-nagement muss hier auch die zuvor beschriebene Varianten- oder Produktkonfigu-ration integrieren.

Das Konfigurationsmanagement erfüllt vier Aufgaben:

Identifizierung und Beschreibung einer konkreten Konfiguration: Hierzu benutzt man Instanzen des in den vorangegangenen Abschnitten beschriebenen Produkt-modells, repräsentiert durch die Teilestammdaten, Produktstrukturen und Doku-mente, eventuell aber auch weitere PLM-Objekte wie Projektdaten oder Instand-haltungsobjekte.

Im System wird die Konfiguration meist durch eine Mappe (Konfigurations-mappe, Lebenszyklusmappe) repräsentiert. Eine einfache Übernahme der Objek-te in die Mappe, beispielsweise direkt per Drag & Drop aus einem Strukturbrowser, muss möglich sein. Die Mappen werden gespeichert, dadurch wird die konkrete Ausprägung festgeschrieben. Die Identifikation der verschie-denen Lebenszyklusphasen erfolgt durch Nummerierung oder Begriffe wie as-designed, as-built.

Überwachung der Konfiguration im zeitlichen Verlauf: Durch den Einsatz des zu-vor beschrieben Änderungsmanagements werden die Ergebnisse jeder die Pro-duktkonfiguration beeinflussenden Änderung genau nachvollziehbar und können im Konfigurationsmanagement dargestellt werden.

Konfigurationsbuchführung: ermöglicht die Auswertung aller Änderungsstände des Produktes und das Reporting über die Änderungshistorie. Dazu müssen alle Versionen der das Produkt beschreibenden Stammdaten und Dokumente in der PDM-Datenbasis vorgehalten werden. Dazu gehören nicht nur Änderungsstände an Produkten und deren Stücklisten, auch die Änderungen an zugehörigen Doku-menten oder verwendeten Bauteilen sind relevant.

Auditierung von Konfigurationen: Stellt durch eine formale Prüfung sicher, dass ein Produkt seine Spezifikation erfüllt und die abgelegte Konfiguration korrekt ist.

Die frühen Phasen der Produktentwicklung 91

Arbeitsvorrat mit Lebensphasen &

Konfigurationsmappen

Details zur Konfigurationsmappe

Metadaten zur gewählten Mappe

bzw. Baseline

Inhalt & Struktur der Konfigurationsmappe

Arbeitsvorrat mit Lebensphasen &

Konfigurationsmappen

Details zur Konfigurationsmappe

Metadaten zur gewählten Mappe

bzw. Baseline

Inhalt & Struktur der Konfigurationsmappe

Abb. 43. Lebenszyklusmappe im Konfigurationsmanagement von SAP PLM

6.2 Die frühen Phasen der Produktentwicklung

Wie bereits im Kapitel 4 erläutert, ist Produktentwicklung kein Selbstzweck. Auch wenn viele Unternehmen eine stark produktzentrierte Ausrichtung haben, ist die strategische Zweckbestimmung der Unternehmen letztlich die Erfüllung von Be-dürfnissen der Kunden oder des Marktes. Es gilt daher – vor Eintritt in die eigent-liche Produktentwicklung – diese Bedürfnisse zu erkennen, frühzeitig Wünsche und Erwartungen der Kunden einzuholen und damit die Entwicklungsaktivitäten auf die richtigen Produkte auszurichten. Dies wird durch Funktionen zur Unter-stützung des Innovationsprozesses ermöglicht. Durch optimale Zusammenarbeit von Marketing, Forschung- und Entwicklung, Vertrieb und der Produktion und durchgängige Toolunterstützung des Innovationsmanagements kann sich das Un-ternehmen einen Vorsprung am Markt sichern.

6.2.1 Ideenmanagement

Erste Systemfunktion im Innovationsprozess ist das Ideenmanagement.Es gilt hier Produkt-, Projekt- oder Serviceideen sowie Produktverbesserungs-

vorschläge aus allen relevanten Quellen und Bereichen (interne Verbesserungs-vorschläge, Vorschläge von Kunden, Ergebnisse aus Forschung und Entwicklung)


zu sammeln und zu bewerten. Dieses Ideen-Repository ist der erste (noch sehr un-spezifische) Schritt hin zu den Produktdaten.

Oft sind ähnliche Funktionen in Unternehmen schon im Rahmen eines struktu-rierten Vorschlagswesens vorhanden, aber nicht konsequent auf die Produktinno-vation hin ausgerichtet.

Aus der Idee entstehen – bei positiver Bewertung – später ein Konzept und dann ein Produkt. Dazu ist es wichtig, neue Ideen jederzeit mit bereits früher ver-folgten Ideen abgleichen zu können. Gespeichertes Wissen wie „diesen Ansatz haben wir vor 3 Jahren schon mal erfolglos versucht“ oder „ein vergleichbarer Ansatz hat bei Produktlinie xy zu einem durchschlagenden Erfolg geführt“ ist der beste Einstieg in eine qualifizierte Ideenbewertung. Ideenmanagement ist also auch ein wichtiger Baustein zur Konservierung des Unternehmenswissens (Know-ledge Management).

Tools zum Einsatz im Ideenmanagement sollten folgende Funktionen bieten:

Sammlung und Beschreibung von Ideen in browserbasierter Oberfläche mit einfachem Zugang + einfacher Bedienung für alle Ideengeber Klassifizierung und Verschlagwortung / Kategorisierung von Ideen Schneller Vergleich mit vorhandenen Ideen und Konzepten und entspre-chende Verknüpfung; dazu Volltextsuche in Ideen- und Konzeptdatenbank Bewertung von Ideen, qualitativ und quantitativ anhand gewichteter Be-wertungskataloge Rückkopplung durch Daten aus der Produktion / Absatz zur Unterstützung der Ideenbewertung Abbildung eines collaborativen Entscheidungsprozesses, welche Ideen wei-terverfolgt werden (im Sinne eines Gating-Verfahrens) Benachrichtigung von Entscheidungsträgern und Einholung ihres Inputs (z. B. workflowbasiert); Dokumentation der Entscheidungen Darstellung der Ideenportfolios; gegebenenfalls mit Szenariosimulation (mehr hierzu im Abschnitt 6.4)

6.2.2 Konzeptmanagement

Nachdem neue Produktideen oder Produktverbesserungen identifiziert sind, gilt es in der Konzept- oder Spezifikationsphase die Ideen zu detaillieren und in ein Konzept zu überführen. Die Ideenbeschreibung wird dabei um Ausarbeitungen angereichert und konkretisiert, Vorgaben und Rahmenbedingungen werden fest-gehalten, eventuell schon erste Entwürfe zur konstruktiven Ausführung erstellt. Den Abschluss dieser Phase bildet die gezielte Beurteilung der Konzepte, bevor dann das Produktdesign und eventuell ein Prototyp im Detail ausgearbeitet werden (zur Vorgehensweise siehe auch Abschnitt 4.2.3)

Die frühen Phasen der Produktentwicklung 93

Zu verwalten sind in dieser Phase überwiegend Office-Dokumente, aber auch Verweise auf Web-Seiten, erste Zeichnungen und Skizzen. Typische Objekte sind:

Anforderungen vom Kunden: Spezifikationen / Leistungsbeschreibungen / Aufstellpläne / Betriebsbedingungen Unternehmensstandards: vergleichbare Produkte, Betriebsnormen, Kon-struktionsstandards, Sicherheitsvorschriften Technische Lösungsansätze: erste Skizzen, Entwürfe, Besprechungsprotokolle Rechtliche Klärungen, Patentrecherchen; Rahmenplanungen

Ein IT-Tool zum Einsatz in der Konzeptphase muss folgende Funktionen gewähr-leisten:

Detaillierte Beschreibung des Konzeptes, insbesondere durch Verwaltung verschiedenartigster zugeordneter Dokumente Flexibilität in der Ausprägung der Dokumentationsstruktur und der Art des Contents (Office-Dokumente, Zeichnungen, CAD-Modelle), aber kein strenges Dokumentenmanagement (mit Versionierung, Statusverwaltung) notwendig Möglichkeit zur gezielten Konzeptbeurteilung aus Marktgesichtspunkten (Zielgruppen, Wettbewerb, Bedarfsanalyse) und aus technischen Gesichts-punkten (Machbarkeit, Preis, Risiko) Prozessunterstützung für eine collaborative Ausarbeitung und Bewertung der verschiedenen Konzepte, möglichst mit einfacher, browserbasierter Oberfläche Verknüpfung mit zugrunde liegenden Ideen und später entwickelten Pro-dukten, um den Prozess durchgängig darzustellen Darstellung des Konzeptportfolios im Rahmen eines Produktportfolio-managements

Abb. 44. Innovationsmanagement-Trichter – zeigt wie durch einen strukturierten Ideenma-nagement-Prozess die richtigen Produktideen ausgewählt werden. (Quelle: SAP)


An dieser Stelle sei noch darauf verwiesen, dass SAP mit der Spezifikationsverwal-tung im PLM-Teilmodul EH&S (Environment, health and safety) die Möglichkeit zum Aufbau beliebig detaillierter Produktspezifikationen in Form strukturierter Da-tensätze (Merkmale in Eigenschaftsbäumen) bietet. Dies wird insbesondere zur Spe-zifikationen von Einsatzstoffen, Produkten und Verpackungen in der Chemie-, Pharma- und Konsumgüterindustrie genutzt, auch über die Konzeptphase hinaus.

Nach dem Abschluss der Definition gilt es, das Konzept als Pflichtenheft zum Input der eigentlichen Produktentwicklung zu machen. Damit tritt dann zuneh-mend der Projektcharakter der Produktentwicklung in den Vordergrund. Die hier benötigten IT-Funktionen beschreibt der nächste Abschnitt.

Ideen-phase

Konzept-phase

Detaillierungs-phase

Realisierungs-phase

Optimierungs-phase

Vorgaben und

Rahmenbeding...

Anforderungen

Lösungs-

ansätze

Berechnungen

Kalkulationen

Detail-

planungen

Baugruppen-

konstruktion

Dokumentations-

erstellung

montage-

begleitende

Funktionstests

Dokumentation

Auslieferungszu...

technische

Handbücher

Ersatzteil-

kataloge

Ideen-

skizze

Ideen-

beschreibung

Abnahmen

Prototypen-phase

Abb. 45. Erweiterter Konstruktionsablauf Anlagenbau mit Funktionen und entstehenden Dokumenten

6.3 Projektmanagement in der Produktentwicklung

Die zunehmende Bedeutung von Concurrent Engineering und Kollaboration in der Produktentwicklung in Verbindung mit der zu beobachtenden stetigen Reduzie-rung der Produktentwicklungszeiten führt dazu, dass Arbeitsschritte im Entwick-lungsprozess zunehmend parallelisiert werden müssen. Daher kommt dem Manage-ment des Produktentwicklungsprozesses zunehmende Bedeutung zu.

In Abschnitt 5.2 wurde erläutert, dass auch die Produktentwicklung Projektcha-rakter hat. Im Folgenden werden die IT-Funktionen vorgestellt, die ein Projektma-nagementtool abbilden muss. Typischerweise beschränkt sich dessen Einsatz nicht auf die Produktentwicklung, Projekte sind in den unterschiedlichsten Unterneh-mensbereichen zu steuern, von Strategieprojekten über Bau- und Investitionspro-jekten bis zu IT-Projekten.

Allgemein gehört zu den Aufgaben eines Projektmanagementtools:

Projektablauf steuern, indem Aufgaben, Termine, Kapazitäten und Kosten geplant und verfolgt werden

Projektmanagement in der Produktentwicklung 95

Durch Prozessmanagement den Projektablauf sicherstellen (Workflow der Projektabwicklung realisieren) Projektablauf dokumentieren, indem projektbezogen Aufwand und Doku-mente erfasst werden Auswertungen zu Projekten ermöglichen (Monitoring von Aufgaben, Ter-minen, Aufwand und Kosten)

Für die ganzheitliche Steuerung der Produktentwicklung sollte das Projektmana-gementtool auch folgende Aufgaben erfüllen:

Datenintegration mit der Produktentwicklung: Ergebnisse eines Entwick-lungsprojektes sind neben Dokumenten auch die Produktstammdaten. Daher muss das Tool die Erzeugung und Speicherung der Produktstammdaten im Projektverlauf durch enge Integration ins Produktdatenmanagementsystem gewährleisten. Umfassende Produktentwicklung: Nicht nur die eigentliche Produktneu-entwicklung muss gesteuert werden, auch umfangreiche Produktänderun-gen, Service- oder Instandhaltungsmaßnahmen am Produkt können selbst wieder Projektcharakter haben. Eine einheitliche toolbasierte Unterstützung auch dieser Prozesse ist anzustreben. Prozessintegration Auftragsabwicklung: Gerade bei Einzelfertigern muss der Gesamtprozess auch die Angebots- und Auftragsphase umfassen, wo wesentliche Produkt- und damit Projektentscheidungen (Projektstrukturie-rung, Kostenplanung, Meilensteinplanung) getroffen werden. Supply-Chain Integration: Die sich an die Produktentwicklung anschlie-ßende Produktion (einschließlich der Prototypenphase) mit notwendiger Vorbeschaffung von Material und gegebenenfalls Auslieferung und Mon-tage einer Anlage sind in die Gesamtplanung einzubeziehen und zu über-wachen. (Tatsächlich machen z. B. beim Bau von Großanlagen gerade diese Phasen den wesentlichen Anteil des Projektes aus.)

Angebots-phase

grobeProjektstruktur

StrukturierteKostenplanung

GrobplanungTermine / Ressourcen

Angebots-dokumentation

Auftrags-phase

Konstruktions-phase

Prototypen-phase

Produktions-phase

Abnahme-phase

Projekt-feinplanung

kostenarten-orientierte

Kostenplanung

DetailplanungTermine / Ressourcen

Liquiditäts-planung

Meilenstein-planung

DarstellungProjektfortschritt

DarstellungTermintreue

Detailabstimmungmit Kunde

techn.Dokumentation

externe Konstruktion /Collaboration

ÄnderungProjektplanung

Prototypen-fertigung

LogistischeKapazitäts- und

Terminsteuerung

Fertigungs-steuerung

Handling Änderungs-anforderungen

Kosten-kontrolle

ÜberwachungLiquidität

Projektabschlussund Abnahme

Projekt-dokumentation

Kosten-analyse

Abb. 46. Schwerpunkte des Projektmanagements in Entwicklungsprojekten


6.3.1 Datenobjekte im Projektmanagementtool

In der Regel werden im Projektsteuerungstool folgende Objekte abgebildet:

Definition von Projekten mit Beginn und Ende, Zielvorgabe Strukturierung von Projekten zur Bildung von Aufgabeneinheiten durch Projektstrukturpläne (PSP). Die Elemente dieser Pläne (PSP-Elemente) stehen zueinander in hierarchischer Beziehung und können eine funktio-nale oder phasenorientierte Gliederung des Projektes bilden. Sie dienen zur Grob-Terminierung, Abbildung von Verantwortlichkeiten (Projektlei-ter, Projektteam) und Kostenverfolgung im Rahmen des Projektcontrol-lings.Detaillierung (Feinplanung, Ablaufplanung) von Projekten durch Netzplä-ne, die das Projekt in Arbeitsvorgänge (die Netzplanvorgänge)15 zerlegen. Diese werden durch Anordnungsbeziehungen in eine logische Reihenfolge gebracht, durch Zuordnung von Terminen und Dauern wird die Feinpla-nung und automatische Terminierung eines Projektes möglich. Auf dieser Ebene erfolgen die detaillierte Planung und das Controlling von Ressourcen und Kosten. Verknüpfungen: Zwischen Projektstrukturplan und Netzplan werden Beziehungen hergestellt, die Netzplanvorgänge werden PSP-Elementen zugeordnet. Diese logische Zuordnung (Netzplanelemente detaillieren PSP-Elemente) erlaubt die Übergabe und Abstimmung von Terminen zwischen Netzplan und Projektstrukturplan und die Verfolgung von Aufwand und Kosten während der Projektabwicklung im Projektstruktur-plan.16

Ressourcenplanung: Es müssen Ressourcen (Mitarbeiter, Arbeitsplätze, Maschinen) und deren Kalender mit Kapazitätsangeboten für die Kapazi-täts- und Einsatzplanung verwaltet werden. Oft werden ergänzend auch die Qualifikationen der Mitarbeiter im Tool geführt. Damit ist eine skillbasierte Suche nach Projektmitarbeitern möglich.

15 Werden auch nach [48] als „Prozessobjekte“ bezeichnet, die den „Aufgabenobjekten“ im Projektstrukturplan zugeordnet sind. Es entsteht also eine aufgabenorientierte und eine pro-zessorientierte Gliederung des Projektes. 16 In SAP-Terminologie ist der Netzplanvorgang dem PSP-Element zugeordnet, dadurch sind Kosten, die bei Abarbeitung des Netzplanes gebucht werden, auf dem zugehörigen PSP-Element sichtbar und können über die PSP-Hierarchie zu den Projektgesamtkosten verdichtet werden. Im Allgemeinen besitzt der Netzplanvorgang im Controlling eine Ab-rechnungsvorschrift auf das PSP-Element.


6.3.2 Funktionen im Projektmanagementtool

Folgende wesentliche Funktionen müssen unterstützt werden:

Projektstart: Definition von Projektverantwortlichen und Projektteam, An-lage von Projektstammdaten, Prüfung von Machbarkeit und Projektanträ-gen in Genehmigungsprozessen. Erstellung von Lastenheften. Bei Auftragsfertigern entstehen Projekte häufig eng integriert in die Angebots- und Auftragsabwicklung. Dazu sollten Projekte direkt aus der CRM-Umgebung mit Bezug zu den dort vorhandenen Stamm- und Auftragsdaten angelegt werden können. Bei Serienfertigern ergeben sich Projekte oft aus Änderungsanforderungen oder neuen Produktideen. Hier ist eine enge In-tegration in die Tools des Ideenmanagements notwendig, um dort ausge-wählte Ideen und Konzepte weiterzuverfolgen und bereits vorliegende Ergebnisse ins Projekt zu übernehmen. Projektstrukturierung: sukzessive Grob- und Feinplanung, Detaillierung der Projektstammdaten wie Projektstrukturplan und Netzplan, Verwendung von Vorlagen. Planung von Meilensteinen, Arbeitszeit und Dauer für ein-zelne Vorgänge. Automatische Terminierung (meist in Varianten wie Vor-wärts- oder Rückwärtsterminierung, Terminierung mit Fixterminen). Planung von Kosten- und Erlösen, je nach Erfordernis in unterschiedlichen Detaillierungsstufen (von Grobplanung über die Feinplanung auf Kostenar-tenebene bis zur detaillierten Kalkulation). Planwerte können in ein Budget pro PSP-Element überführt, bei Bedarf genehmigt und dann vom System überwacht werden17 (Verfügbarkeitskontrolle). Staffing und Ressourcenplanung: Zuordnung von ausführenden Ressourcen (Arbeitsplätze, Maschinen, Personen, Abteilungen) zu den Projektaktivitä-ten. Einplanung auf konkrete Projekte in Abstimmung mit deren verfügba-ren Kapazitäten. Information an Mitarbeiter über die Planung, eventuell zuvor Abstimmung der Planung mit ihren Vorgesetzten18.Projektabwicklung: Der Einstieg in die Durchführung eines Projektes erfolgt durch Freigabe oder Aktivierung der Projektplanung. Meist wird diese Funk-tion durch ein Statuskonzept realisiert. Die Mitarbeiter werden über den Pro-jektbeginn und von ihnen durchzuführende Aktivitäten informiert, wobei eine ergänzende zeitnahe Information bei Beginn jeder Einzelaktivität sinn-voll ist, die auch bis dahin erfolgte Terminverschiebungen berücksichtigt.

17 Budgetüberwachung bedeutet, dass z. B. innerhalb eines ERP-Systems Buchungen auf das Projekt (beispielsweise Materialbeschaffung über eine Bestellung) nicht mehr zugelas-sen werden bzw. eine Information erfolgt, wenn kein Budget mehr verfügbar ist. 18 Man spricht dann von einer Trennung der Kapazitätsreservierung in soft booking (Anfra-ge einer konkreten Ressource) und hard booking (endgültiges Verplanen der Ressource nach Abstimmung mit zuständigem Vorgesetzten).

98 IT-B

austeine einer prozessorientierten PLM-Lösung

Projekt-start

Projekt-

strukturierung

Projekt-

abwicklung

Projekt-

monitoring

Projekt-

abschluss

Projekt-

reporting

Projekt-

abstimmung

Projekt-

staffing und

Ressourcenplanung

Projekt-

collaboration

Qualitäts-

sicherung

Anstoß /

Weiterleitung

Projekt

Multi-Projekt-

Management

Projekt-

marketing

Projekt-

dokumentation

Abb. 47. D

ie Phasen / Funktionen eines typischen Projektablaufs


Die Mitarbeiter erledigen ihre Tätigkeiten, dokumentieren sie und quit-tieren die Erledigung durch Rückmeldung. Die Rückmeldung umfasst den Abarbeitungsgrad und die geleistete Arbeit. Sie dient der Auftragsüberwa-chung, Dokumentation des Bearbeitungsstands und der Kostenerfassung. Eventuell ist ergänzend eine Abnahme des Arbeitsschrittes und Freigabe folgender Projektabschnitte notwendig oder erfolgt beim Erreichen von Projektmeilensteinen automatisiert.

Zur Steuerung dieses Prozesses hat sich die Kombination von Workflow-tools mit dem Projektmanagementsystem bewährt. Ein Workflow übernimmt die Koordination der Aufgabenbearbeitung, er kann sogar die Integration al-ler im Projekt involvierten IT-Anwendungen gewährleisten, indem er bei-spielsweise Systemfunktionen zur Erfassung der Produktstammdaten oder Projektdokumentation aufruft19. Ein detailliertes Beispiel hierzu findet sich im Projektbericht „Produktentwicklung bei einem Lebensmittelhersteller“.

Dokumente anlegenund

Objekte zuordnen

Abnahme vonArbeitsschritten

Projektbeteiligte Projektbeteiligte

Rückmeldung vonProjektabschnitten

Freigabe vonProjektabschnitten

Projektbeteiligte Projektbeteiligte

Projektmanager

Projektbeteiligteführt aus führt aus

BearbeitungAufgaben,

Checklistenpunkte

Collaborationmit externen

Partnern

führt aus führt ausführt aus

Abb. 48. Wertschöpfungskette – Detailbild Projektabwicklung

Projektdokumentation: Während der Abwicklung eines Produktentwick-lungsprojektes entsteht neben den Produktstammdaten eine Fülle von ergän-zenden Dokumenten. Ein bestmöglicher Informations- und Kommuni-kationsfluss innerhalb des Projektes und eine Verwertung der Informationen über das Projekt hinaus im Sinne eines umfassenden Knowledge-Manage-ments werden durch Funktionen zur Projektdokumentation ermöglicht.

Üblicherweise nutzt man hierzu ein Dokumentenmanagementsystem – möglichst direkt in das Projektmanagementtool integriert – das den Pro-jektbeteiligten die Ablage von Dokumenten und eine direkte Verknüpfung zum Projekt, den Projektelementen oder Projektphasen gestattet.

Die Dokumentation sollte als Aktivität direkt vom Workflow zur Steue-rung der Projektabwicklung eingefordert werden.

19 Diese und andere Funktionen der Projektkommunikation zwischen Projektleitung und Projektmitarbeitern sind wesentlich für eine erfolgreiche Projektdurchführung, werden aber oft vernachlässigt (beispielsweise auch in der Standard-Auslieferung des SAP Pro-jektsystems PS).


Projektkollaboration: Wie bereits in Abschnitt 5.1 erläutert, wird auch im Entwicklungsprozess zunehmend eng mit externen Partnern zusammenge-arbeitet, beispielsweise externen Konstruktionsbüros, Zuliefern für Kom-ponenten oder schlicht den Auftraggebern. Daher sollte ein Projekt-managementtool die Möglichkeit bieten, Projekte in virtuellen Teams zu planen und abzuwickeln. Unabhängig davon, ob diese Teams nur aus Mit-arbeitern des eigenen Unternehmens – eventuell global an verschiedenen Standorten verteilt – oder auch aus Unternehmensexternen bestehen.

Wichtig sind daher Funktionen, die den Kommunikationsfluss im Pro-jekt für das gesamte Projektteam sicherstellen: Externe Teammitglieder sind über den Projektplan und ihre Aktivitäten zu informieren, für diese Tä-tigkeiten muss ein Nachverfolgen des Status im Projektmanagementtool möglich sein. Meist stellt man Externen nicht die gesamten Projektinforma-tionen zur Verfügung, sondern ausgewählte Teile des Projektplanes und der Projektdokumentation. Diese Informationen müssen dann konsistent und aktuell gehalten werden, eventuell sogar in Form von Online-Kollabora-tionssitzungen gemeinsam bearbeitet werden. Projektmonitoring / Projektreporting: Eine erfolgreiche Projektsteuerung basiert auf einer genauen Beobachtung aller ablaufenden Projektaktivitäten. Durch Analysen müssen Abweichungen zwischen Ist und Soll (Soll gemäß Plan oder Soll gemäß Budget) erkannt und ihnen entgegengesteuert werden.

Dazu muss ein Projekt-Informationssystem Auswertungen und Analysen betreffend die Kosten-, die Termin- und die Ressourcensicht20 bieten.

Eine Fortschrittsanalyse setzt man beispielsweise ein, um den tatsächli-chen Fertigstellungsgrad mit dem geplanten Verlauf zu vergleichen und zu erwartende Termin- und Kostenabweichungen zu identifizieren. Eine Meilen-stein-Trendanalyse veranschaulicht die Terminsituation des Projektes. Weiter werden Berichte zur Kosten- und Erlössituation, Liquiditätsplanung, Forecast auf das Projektergebnis und Kapazitätsberichte auf verschiedenen hierarchi-schen Verdichtungsstufen (z. B. pro Mitarbeiter, Qualifikation) benötigt.

Das Reporting wird auch durch die mögliche Versionierung der Stamm-daten (z. B. Netzplan) unterstützt. Dadurch können Veränderungen im Lauf des Projektes festgestellt und mit aktuellen Daten verglichen werden21.

Um erkannte Abweichungen zu dokumentieren, ihre Konsequenzen zu analysieren und Folgeaktivitäten einzuleiten ist ein Maßnahmenmanage-ment / Meldungsabwicklung sinnvoll22.

Über die zusätzlichen Reporting-Anforderungen im Multi-Projektmanage-ment informiert der nächste Abschnitt.

20 Termin- und Ressourcensicht werden oft als logistische Sicht zusammengefasst (in Er-gänzung zur kaufmännischen Sicht). 21 Oft kann die Funktion der Versionierung auch zur Simulation von alternativen Planungen genutzt werden, insbesondere in Angebotsphase und zu Projektbeginn sinnvoll. 22 In SAP wird diese Funktion als Claim Management bezeichnet, sie dokumentiert gemäß [11] eine festgestellte Abweichung und sollte z. B. zur Durchsetzung von Nachforderungen gegenüber Vertragspartnern eingesetzt werden.

Projektportfoliomanagement 101

Zusammengefasst: Es können wesentliche Synergieeffekte erzielt werden, wenn der gesamte PLM-Prozess von früher Entwicklungsphase über Auftragsabwicklung und Engineering bis zur Produktionslogistik durch ein einheitliches Planungs- und Pro-jektmanagementtool mit einer zentralen Projekt-Datenbasis abgebildet wird. Für das Projektmanagementsystem ist neben Integration zum PLM-System auch die Integra-tion zum ERP-System wesentlich (z. B. zum Auslösen von projektbezogener Be-schaffung, Erfassen und Auswerten von Kosten zu Projekten). Hier bieten integrierte Lösungen wie SAP PLM wesentliche Vorteile, da Projektmanagementsystem, PLM-Funktionen und ERP-Funktion in einem System realisiert sind.

Konsequenz daraus ist aber auch, dass für eine prozessübergreifende Nutzung des Projektmanagementtools gerade die Projektmitarbeiter in den frühen Phasen der Produktentwicklung die Rahmenbedingungen – wie saubere Stammdatenpfle-ge, saubere Dokumentation der Ergebnisse – schaffen müssen. Die Nutzung eines Projektmanagementtools kann also beispielsweise für eine Entwicklungsabteilung durchaus Mehraufwand bedeuten und daher auf Widerstand stoßen. In Einfüh-rungsprojekten ist darauf zu achten, den Nutzen der Lösung für den Gesamtpro-zess aufzuzeigen und die Einführung durch Change-Management zu begleiten.

6.4 Projektportfoliomanagement 6.4.1 Abgrenzung Portfoliomanagement zu Projektmanagement

Die im vorhergehenden Abschnitt erläuterten Projektmanagement-Tools dienen zur operativen Steuerung von Projekten, dem operativen Projektmanagement, das sich am einzelnen Projekt, dessen Planung, Steuerung und Auswertung orientiert und damit ein Werkzeug für den Projektleiter und Projektcontroller darstellt.

Führt eine Organisation gleichzeitig eine Reihe von Projekten durch, muss sie auch die Konsolidierung, Planung, Ausrichtung und Steuerung des Gesamtportfo-lios der Projekte beherrschen. Dies wird umso wichtiger, als die Abhängigkeiten zwischen den einzelnen Projekten immer enger werden.

Managementaufgabe mit zunehmender Bedeutung ist die Planung und Steue-rung der Projekte insgesamt und Analyse ihre strategischen Konsequenzen. Werk-zeug hierzu (für die Unternehmensleitung und Multi-Projektmanager) ist das Projektportfoliomanagement. Es bietet einen Überblick, welche Projekte durchge-führt werden, wie diese zur Zielerreichung und Strategie des Unternehmens bei-tragen, welche Risiken und welcher Aufwand entstehen und wie erfolgreich die Projekte sind. Außerdem bietet es auch einen Überblick über die in den Projekten arbeitenden Ressourcen und hilft die Kapazitäten projektübergreifend zu steuern.

Da – wie bereits erläutert – auch die Produktentwicklung meist projektorientiert abläuft, ist das Projektportfoliomanagement ein wesentlicher Teil des Programm-managements (Gestaltung des Produktionsprogramms im Unternehmen)23. 23 Daher findet man in der Literatur statt Portfoliomanagement auch mit gleicher Bedeutung die Bezeichnung Programmmanagement, was aber andererseits auch weitere Funktionen wie Product Lifecycle Costing oder Strategic Enterprise Management umfassen kann.


Tabelle 1. Vergleich Projektmanagement / Projektportfoliomanagement

Projektportfoliomanagement Projektmanagement

Fokus strategisch (Entscheidung) Fokus operativ (Umsetzung)

„Die richtigen Projekte durchführen“ „Projekte richtig durchführen“

KPIs für das Projektportfolio KPIs für Einzelprojekte

Firmenweit, Multi-Projektmanagement, Top-Down-Ansatz

Orientiert am Einzelprojekt, Bottom-Up-Ansatz

Fokus zukünftige Planung + Strategie Fokus aktuelle Projektsituation: Projekt-aufgaben, Terminplan, kritische Pfade

Konsequenzen für das Gesamtunternehmen Konsequenzen für das Projektteam

Nutzung durch Unternehmensleitung, Finanzen + Controlling, Multi-

Projektmanager, Ressourcen-Manager

Nutzung durch Projektmanager, Projektmitarbeiter

Oft werden die Prozesse des Portfoliomanagements in spezifischen Anwendungen realisiert (z. B. Portalanwendung, Access-Datenbank), das operative Projektmana-gement hingegen im ERP- oder dedizierten Projektmanagementsystem (z. B. MS Project, Primavera). Bei einer solchen Implementierung resultieren eine Reihe von Prozess- und Systembrüchen. Diese erschweren es, im Portfoliomanagement stets über konsistente und aktuelle Daten zu verfügen und durchgängige Projektmana-gementprozesse zu gestalten. Denn tatsächlich sind die Prozesse des operativen Projektmanagements und des Projektportfoliomanagements eng miteinander ver-zahnt (siehe Abb. 49).

Projektstart /Projektidee

Projekt-strukturierung /Detailplanung

strategisches Projektportfoliomanagement

Projekt-abwicklung

Projekt-abschluß

Einzel-Projekt-controlling

Projektgrob-planung / Projekt-

beantragung

Projektportfolio-ContollingAbleitung von

Projektbedarf

Unternehmens-

strategie

Konsolidierung Priorisierung,

Projekt-

genehmigung

operatives Projektmanagement

Abb. 49. Verzahnung von operativem und strategischem Projektmanagement

Projektportfoliomanagement 103

Daher ist bei der Implementierung Wert darauf zu legen, eine enge Anbindung oder besser noch ein integriertes Tool für Portfoliomanagement und operative Projektsteuerung zu realisieren. Dies ermöglicht eine konsistente (und damit stets aktuelle) Datenbasis, dadurch verlässliche Analysen im Portfoliomanagement, durchgängige Prozesse und geringere Infrastrukturkosten. Der Prozess des Pro-jektmanagements mit Projektidee, Portfolioplanung, Projektgenehmigung und Projektdurchführung kann dann als stetiger Regelkreis abgebildet werden.

6.4.2 Funktionen des Projektportfoliomanagements

Portfolio-Monitoring und -controlling: Analyse der Projekte bezüglich verschiedener Dimensionen (z. B. Pro-duktbereiche) und Kennzahlen (z. B. externe und interne Einflussfaktoren wie Wirtschaftlichkeit, Marktanforderungen, finanzielle Restriktionen oder gesetzliche Auflagen) Multiprojekt-Reporting: Konsolidierung der aus dem Einzelprojekt-Controlling resultierenden Analysen zu verdichteten Projektportfolio-Statusberichten Portfolio-Analyse für Projekte nach klassischen Portfolio-Methoden (z. B. Portfolio-Matrix nach Projektrisiko und Projektnutzen; siehe [7], S.688 ff.)Alert-Management: Benachrichtigungsfunktion wenn bestimmte Indi-katoren Schwellenwerte überschreiten (z. B. Termine, Kosten, Risiko)

Portfolio-Management Unterstützung bei Portfolio-Definition, Priorisierung und Initiierung von Projekten Durchführung von Simulationen, Vergleich der simulierten Szenarien Genehmigung und Steuerung von Projektbudgets; gemeinsame Budge-tierung und Kostenüberwachung, übergreifende Planung von Projekt-phasen

Kapazitäts- und Ressourcen-Management24

Skill-Management: Verwaltung von Qualifikationen von Mitarbeitern25

Erfassung von Ressourcenbedarfen und benötigten Qualifikationen

24 Im Sinne eines Top-Level-Ressourcenmanagements: die genaue Einplanung einzelner Personen auf bestimmte Aktivitäten einschließlich der Terminierung erfolgt im operati-ven Projektmanagement. 25 Durch Verwaltung der Skills aller potenziellen Projektmitarbeiter entsteht eine „Wer kann was“-Wissensbasis; ein Expertenfinder kann dann zur Suche nach geeigneten Projektmitar-beitern dienen.


ProjectDashboard

PortfolioManagement

ProposalOverview

ScenarioModeling

PortfolioAnalytics Settings

Abb. 50. Kernfunktionen der Projektportfoliomanagement-Lösung xRPM der SAP (Funk-tionsbaum nach [39]).

Abb. 51. Darstellung des Projektportfolios in der Portfoliomanagement-Lösung xRPM (extended resource and program management) der SAP AG (Quelle: SAP AG)

Ermittlung geeigneter Ressourcen (Ressourcensuche) Workflows zur Ressourcengenehmigung Kapazitätsreporting, Konsolidierung von Kapazitätsangebot und -nach-frage, mittel- bis langfristige Kapazitätsplanung

Das Projektportfoliomanagement muss folgende Prozesse unterstützen:

Qualitätsmanagement 105

Entstehung, Bewertung und Genehmigung von Projekten: über eine Pro-jektidee (erfordert Integration der Tools zum Ideenmanagement), einen Projektantrag, eine Einordnung ins Projektportfolio bis zur Entscheidungs-unterstützung und Projektgenehmigung durch zuständige Gremien. Projektbesetzung: Einplanung von Kapazitäten auf Projekte, eventuell als zweistufiger Prozess aus vorläufiger Reservierung + Kapazitätsanfrage an Ressourcenmanager + endgültige Kapazitätsreservierung Stetiges Monitoring des Portfolios mit kontinuierlicher Optimierung Kollaboration: Informationsaustausch zwischen Projektbeteiligten und Management

Abschließend soll nochmals darauf hingewiesen werden, dass das Portfoliomana-gement nicht das operative Projektmanagement (mit detaillierter Projektstrukturie-rung, Projektplanung, Verteilung von Einzelaufgaben, Terminierung, Verfolgung des kritischen Pfades, Erfassen von Rückmeldungen, Sammeln von Aufwand und Kosten) ersetzt, sondern nur ergänzt.

6.5 Qualitätsmanagement

In fast allen Branchen sind Qualitätsmanagementsysteme, mit denen qualitätsrele-vante Aktivitäten beschrieben und zertifiziert werden, inzwischen weit verbreitet. Aktuell werden diese vielfach zu Prozessmanagementsystemen weiterentwickelt, was die Einbettung qualitätsrelevanter Abläufe in die Kerngeschäftsprozesse des Unternehmens betont. All diese Systeme zielen darauf ab, das Vorhandensein be-stimmter Abläufe und Prozesse nachzuweisen, die von relevanten Normen (ISO 9000 ff., ISO TS 16949…) gefordert werden.

Beim Aufbau eines Qualitätsmanagementsystems kann ein Dokumentenverwal-tungssystem zur strukturierten Speicherung von Anweisungen, Handbüchern und anderen QM-relevanten Dokumenten zum Einsatz kommen. Dies muss neben der Ablage auch die Lenkung der qualitätsrelevanten Dokumente (Verteilung, Ge-nehmigungs- und Freigabeprozesse sowie Änderungen) abbilden und dokumentie-ren (auch in Kombination mit Workflowfunktionen).

Ein Qualitätsmanagementsystem ist auch dadurch eng mit der Einführung von PLM-Systemen verbunden, das ein Qualitätsmanagementsystem und die ihm zugrunde liegenden Normen ganz spezifische Forderungen an die Umsetzung des Produktentwicklungsprozesses stellt:

Eine Design- und Entwicklungsplanung mit definierten organisatorischen und technischen Schnittstellen zu anderen Prozessen ist abzubilden und zu unterstützen (z. B. durch ein Projektmanagementsystem mit definierten Mei-lensteinen und Abnahmen).


Designvorgaben und ihre Umsetzung und Weiterentwicklung im Rahmen der Produktentwicklung sind zu dokumentieren (mit der Dokumentenver-waltung und Funktionen des Ideen- und Konzeptmanagements), ganz beson-ders bei Designänderungen (mit Hilfe des Änderungsmanagements) Die Ergebnisse der Produktentwicklung sind durch Einsatz von geplanten Qualitätsprüfungen und Dokumentation der Ergebnisse gegen die Vorgaben des Designs zu validieren.

Die Funktionen eines ganzheitlichen QM-Systems gehen jedoch weit über PLM hinaus und betreffen eine Vielzahl von logistischen Geschäftsprozessen, bei-spielsweise:

Beschaffungsabwicklung: Auswahl von Lieferanten, Überwachung und Be-urteilung von Lieferbeziehungen, Prüfung und Abnahme von eingegangener Ware, Führung von Qualitätsprüfbeständen und Chargen, Reklamationsab-wicklungProduktion: in die Arbeitsplanung integrierte Prüfplanung, Prüfung von Wa-ren in der Produktion, Steuerung der Prüfung, Verwaltung und Überwa-chung von Prüfmitteln Vertrieb: Warenausgangsprüfungen, Dokumentation / Zeugnisse, Verfolgung von Chargen, Kundenreklamationen Service: Abwicklung von Reparaturen und Retouren Instandhaltung: Lenkung und Planung der Montage- und Wartungsprozesse für Fertigungseinrichtungen und Prüfmittel

Zum Betrieb einer QM-Lösung sind folgende IT-Funktionen notwendig

Qualitätsplanung: Ziel ist eine abteilungsübergreifende Verbesserung der Produkt- und Prozessqualität. Die Planung der Produktqualität ist eng mit den Kernfunktionen des PLM verbunden. Dazu gehört, auf Basis von Spezi-fikationen realisierbare Produkte zu entwerfen, Fertigungsprobleme mög-lichst frühzeitig zu erkennen und voraus zu denken sowie Prüfungen bereits in der Produktentwicklung zu planen. Qualitätsplanung umfasst also insbe-sondere die Prüfplanung. Prüfplanung: Planung von Prüfvorgängen z. B. in der Fertigung oder im Wa-reneingang. Dazu sind IT-Funktionen wie Prüfmerkmalsverwaltung, Prüf-pläne, Prüfablaufsteuerung und Prüfmittelverwaltung bereitzustellen. In Katalogen werden Codierungen vorbereitet, mit denen Fehlerbeschreibungen oder Maßnahmen in der Qualitätsprüfung dokumentiert werden. Qualitätsprüfung: Dient der Umsetzung der in der Qualitäts- und Prüfpla-nung definierten Aktivitäten. Funktional werden Prüflose eröffnet und ver-waltet, Ergebnisse und Fehler erfasst und dokumentiert, Prüfberichte erstellt und dabei Prüfkosten verfolgt. Relevant sind hier Schnittstellen zu Mess-systemen zur Unterstützung der Messdatenerfassung (CAQ, LIMS).

Instandhaltung und Service 107

Prüfmittelverwaltung: Verlässliche Prüfmittel sind Voraussetzung für die Qualitätsprüfung und somit als Stammdaten oder als Dokumente zu verwal-ten. Sie sind zu beschaffen, zu überprüfen und zu kalibrieren und schließlich zum Einsatz zu bringen. Gerade bei komplexen Prüfmitteln kann deren War-tung, Instandhaltung und Kalibrierung den Einsatz der weiter unten be-schriebenen Funktionen der Instandhaltung erfordern. Qualitätslenkung: Umfasst die Abläufe, mit denen Ursachen für Fehler oder Qualitätsprobleme beseitigt werden und eine Wiederholung der Probleme verhindert werden soll. Dazu gehört die Dokumentation in Verwendungsent-scheiden, die Fortschreibung der Qualitätslage zur Dynamisierung von Prü-fungen, die Ableitung von Kennzahlen bis zur Lieferantenbewertung und die Erfassung und Steuerung von Qualitätsmeldungen und Reklamationen. Qualitätsinformationssystem: Als ein spezielles Führungsinformationssys-tem wird hier die Auswertung und Aufbereitung aller relevanten Daten des Qualitätswesens ermöglicht.

6.6 Instandhaltung und Service

Der Grundstein für eine funktionierende Instandhaltung wird bereits im Produkt-entstehungsprozess gelegt, wenn eine frühzeitige Berücksichtigung von wichtigen Instandhaltungsbedürfnissen erfolgt. Dies betrifft z. B. die Erstellung von elektro-nischen Ersatzteillisten, elektronischen Wartungsinformationen und die elektroni-sche Dokumentation von Anlagen.

Das Hauptaugenmerk einer modernen Instandhaltung liegt auf dem Wechsel von einer starren Auftragsverwaltung zu einer flexiblen und intelligenten Auf-tragssteuerung.

Im Folgenden werden zuerst die Stammdaten, danach die Funktionen der In-standhaltung beschrieben.

6.6.1 Stammdaten der Instandhaltung

Für eine Instandhaltungsabwicklung müssen folgende Stammdaten vom IT-System bereitgestellt werden:

Objekt-AnlagenverwaltungDurch eine unternehmensspezifische Abbildung der Werks- und Anlagen-struktur wird sichergestellt, dass alle aus Sicht der Instandhaltung, Anla-gensicherheit, Qualitätssicherung und Umweltschutz zu betrachtenden Objekte im System als Stammdatenobjekt repräsentiert sind.

Der Aufbau der Anlagenstruktur für die Instandhaltungsabwicklung kann nach unterschiedlichen Gesichtspunkten erfolgen und ist je nach Un-ternehmen einer der wichtigsten Bestandteile für die Optimierung der In-standhaltung.


Bei der individuenbezogenen Sicht wird jedes relevante Instandhaltungsob-jekt als Individuum abgebildet und verwaltet. Welche Objekte dabei genau abgebildet werden, richtet sich nach unterschiedlichen Kriterien. Zum Bei-spiel, wo eine Nachweispflicht über durchgeführte und geplante Maßnahmen innerhalb der Instandhaltung besteht, welche objektspezifischen Daten wie z. B. Garantie oder Baujahr zu verwalten sind oder wo eine objektabhängige Kostenverfolgung für Instandhaltungsmaßnahmen notwendig ist.

Bei der typbezogenen Sicht erhalten Einzelobjekte mit Hilfe einer Ob-jektgruppierung eine Gruppierungskennung, über die eine vereinfachte Su-che, Datenpflege und Auswertung erreicht werden kann. Dazu werden z. B. die Klassifizierung oder Unterteilung in Objekttypen wie Equipment oder Technischer Platz benutzt.

Dokumentenverwaltung Informationen zu Anlagen können direkt mit dem jeweiligen Objekt im In-standhaltungssystem verknüpft und jederzeit aufgerufen, geändert und aus-gedruckt werden. Durch diese Integration in eine Dokumentenverwaltung können wichtige Informationen schnell und aktuell allen am Prozess beteilig-ten Personen zur Verfügung gestellt werden.

Abb. 52. Anlagenstruktur im SAP PM mit technischen Plätzen und Equipements

Instandhaltung und Service 109

KlassifizierungMit Hilfe der Klassifizierung ist es möglich, allen Instandhaltungsobjekten Informationen mitzugeben (z. B. technische Eigenschaften), die zur Be-schreibung und Identifikation der Objekte dienen.

Außerdem können diese bei der Suche z. B. nach möglichen Austausch-objekten mit den gleichen oder ähnlichen technischen Ausprägungen ge-nutzt werden.

Ersatzteilverwaltung Kernstück einer funktionierenden Instandhaltung ist die Integration mit dem Ersatzteilmanagement. Um zur richtigen Zeit das richtige Material in der richtigen Menge verfügbar zu haben ist die Anpassung und Integration der Ersatzteilverwaltung und des technischen Einkaufs unumgänglich.

6.6.2 Funktionen der Instandhaltung

In der Instandhaltung treten neben den planmäßigen Tätigkeiten auch viele unge-plante Ereignisse auf. Um diese möglichst schnell und effizient abarbeiten zu kön-nen, bedarf es einer auf ihren Betrieb angepassten Instandhaltung. Diese muss folgende Funktionen anbieten:

Lückenlose Dokumentation: Ein nicht zu unterschätzender Aspekt in der Durch-führung von Instandhaltungstätigkeiten ist der Austausch von Anlagenteilen bzw. der Umbau von ganzen Anlagen, welche als Individuum (Technischer Platz oder Equipment) im Instandhaltungsplanungssystem angelegt wurden. Um immer den aktuellen Bauzustand z. B. einer Anlage und eine lückenlose Dokumentation der Laufzeiten und Einbauorte sicherzustellen, ist es notwendig, jede wichtige Struk-turänderung nicht nur physisch, sondern auch möglichst zeitnah systemtechnisch durchzuführen. Diese Pflege muss im Normalfall manuell im Instandhaltungssys-tem durchgeführt werden.

Meldungsabwicklung: Nicht nur für die schnelle und unkomplizierte Weitergabe und Dokumentation von Informationen z. B. zu ungeplanten Störungen oder für die Abwicklung des kontinuierlichen Verbesserungsprozesses (KVP) kann das Meldungswesen eingesetzt werden, sondern auch für die Rückmeldung von Tätig-keiten. Die Erfassung kann manuell durch einen Mitarbeiter oder automatisch über eine Schnittstelle in das Instandhaltungssystem erfolgen.

Geplante / ungeplante Instandhaltung: Die schnelle Behebung von Störungen an Anlagen ist trotz optimierter Wartungsprozesse immer noch eine wichtige Aufga-be innerhalb der Instandhaltung. Die Information über eine Störung erfolgt meist mündlich, wobei die Dokumentation des Problems in Form einer Instandhal-tungsmeldung bzw. eines Instandhaltungsauftrages im System angelegt werden sollte.


Auch für die Abbildung von geplanten Reparaturen und Umbauten ist der Ein-satz eines Instandhaltungs-Planungssystems hilfreich.

Im Gegensatz zur ungeplanten Instandhaltung kann bei geplanten Instandhal-tungsmaßnahmen die Integration in andere ERP-Prozesse voll ausgeschöpft wer-den. Dies sind z. B. die Beschaffung von Ersatzteilen, die optimierte Einsatz-planung (wann steht die Anlage planmäßig?), die externe Vergabe von Arbeiten und die parallele Durchführung von Reparaturen und Wartungsarbeiten.

Vorbeugende Instandhaltung / Wartung: Die Sicherstellung der Anlagenverfüg-barkeit durch den Einsatz von vorbeugender Instandhaltung ist einer der wesentli-chen Aufgaben einer modernen Instandhaltung. Grundlagen für die Planung, Terminierung und Tätigkeitsbeschreibung solcher Maßnahmen sind z. B. Empfeh-lungen des Herstellers, rechtliche Vorschriften, Anforderungen des Umweltschut-zes und Qualitätssicherung.

Um dieser Aufgabe gerecht zu werden bedarf es einer Instandhaltungsplanung, die nicht nur Zeit- sondern auch Leistungs- und Zustandsabhängig funktioniert. Z. B. kann über Betriebsstunden oder andere Messwerte, welche manuell oder via Schnitt-stelle in das Instandhaltungssystem gelangen, der jeweilige Wartungstermin automa-tisch den aktuellen Gegebenheiten angepasst und somit optimiert werden.

Kennzahlen und Analysen: Um die Instandhaltungsaktivitäten und -investitionen vorausschauend planen zu können, werden eine Vielzahl von Informationen benö-tigt. Diese Daten werden in einem modernen Instandhaltungssystem gespeichert und können in Form von Kennzahlen und Analysen unterschiedlichster Art aufge-rufen und innerhalb bzw. außerhalb des Instandhaltungsplanungssystems weiter aufbereitet werden.

Kennzahlen können beispielsweise die Anzahl von Schadensbildern und -ursachen oder die Anzahl erfasster Meldungen sein. Man unterscheidet organisa-torische und kaufmännische Kennzahlen, die jeweils automatisch bei jeder Bear-beitung von Objekten und Meldungen fortgeschrieben werden.

Mit Hilfe unterschiedlicher Instandhaltungsanalysen können individuelle Aus-wertungen z. B. zu Schäden, Objekten und Kosten erstellt werden. Diese können tabellarisch und grafisch dargestellt werden.

6.7 Workflow als Querschnittsfunktion im PLM

Ein Workflowsystem dient dazu, die in einem Geschäftsprozess zu erledigenden Arbeitsaufträge mit zugehörigen Objekten oder Dokumenten den zuständigen Mitarbeitern elektronisch zuzustellen. Es stellt keine weitere Einzelfunktion im PLM dar, sondern übernimmt die durchgängige Abbildung eines Geschäftsprozes-ses und damit die Prozessintegration mehrerer Funktionen, die eventuell auf ver-schiedene Anwendungssysteme verteilt sein können. Optimalerweise ruft das Workflowsystem die auszuführende Funktion im Anwendungssystem auf und stellt die zu bearbeitenden Daten oder Dokumente direkt am Bildschirm bereit.

Workflow als Querschnittsfunktion im PLM 111

Dabei können durchaus auch einzelne Funktionen, die vorher manuell ausgeführt wurden, automatisiert werden.

Mit einem Workflowsystem wird in einer Geschäftsprozessarchitektur die An-wendungssystemebene (die auszuführende Funktionen bereitstellt) um eine Steue-rungsebene ergänzt (siehe [42], Abschnitt D, House of Business Engineering).

Durch den Einsatz von Workflow werden folgende Nutzenpotenziale realisiert:

Prozess wird transparent, System stellt einheitliche Bearbeitung des Pro-zesses sicher Prozess wird durch Protokollierung und Monitoring nachvollziehbar, keine „verschwundenen Prozesse“, keine „nicht auffindbaren“ Unterlagen. (Die-ser Punkt ist in der Praxis oft das wesentliche Nutzenargument bei Einfüh-rung einer Workflowlösung.) Prozessbeschleunigung durch aktive Benachrichtigung der Benutzer bei eingetroffenen Arbeitsaufträgen und Wegfall von Transportzeiten durch elektronische Weiterleitung (Beispielsweise wurde in Projekten durch Ein-führung eines Änderungsworkflows pro Änderung 30 Minuten Bearbeiter-Zeit eingespart.) Optimierung des Prozesses durch Parallelisierung, automatische Termin-kontrollen und Eskalationsmechanismen Reduzierte Fehlerhäufigkeit und geringerer Schulungsaufwand durch Füh-rung des Benutzers. Häufig wird durch eine Workfloweinführung ein we-sentlich höheres Bewusstsein der Bearbeiter für den Gesamtprozess erreicht als ohne Workflow.

6.7.1 Kategorisierung von Workflow-Anwendungen

Je nach Typ des abzubildenden Prozesses muss ein Workflowsystem unterschied-liche Funktionen anbieten. Dadurch lassen sich folgende Systemkategorien unter-scheiden (nach [42], Abschnitt D.III):

Production-Workflow-System: Abbildung gut vorstrukturierter Prozesse mit hoher Wiederholfrequenz, Schwerpunkt ist die echte Integration der auszuführenden Anwendungsfunktionen. Ad-hoc-Workflow: Abbildung schwächer vorstrukturierter Prozesse, bei denen der geplante Ablauf während der Prozessbearbeitung individuell durch den Bearbeiter geändert werden kann. Wird oft als zusätzliche Funk-tion in Production-Workflow-Systemen realisiert. Collaborative Workflows / Groupware-Systeme: schwach strukturierte Pro-zesse, die nicht im Detail spezifiziert sind. Das System stellt nur Tools zur Verfügung (Collaboration-Anwendungen), die es einer Gruppe ermög-lichen, gemeinsam an einer Problemlösung zu arbeiten.


Mappenorientierte Workflowsysteme: Zu bearbeitende Objekte (meist Do-kumente) werden in einer Bearbeitungsmappe entlang des Prozesses weiter-gegeben; Schwerpunkt ist nicht die Integration von Applikationen (wie beim Production Workflow) sondern die Dokumentenverarbeitung. Erlaubt meist die Kombination von vordefinierten Workflows mit Ad-hoc-Weiterleitung.

In SAP ist die Komponente SAP Business Workflow / SAP Web Flow integriert, die ein echtes Production-Workflowsystem darstellt und in der Lage ist, alle SAP PLM-Anwendungsfunktionen optimal zu integrieren. Optional können Ad-hoc-Funktionen (wie Weiterleitung) genutzt werden.

Außerdem kann in SAP PLM die Komponente SAP Records Management ge-nutzt werden, dies ist eine mappenorientierte Akten- und Vorgangsverwaltung. Umlaufmappen mit Dokumenten und Geschäftsobjekten können in einen Work-flow integriert werden, dabei kann mit vorgegebenen Laufwegen oder nach dem Ad-hoc-Prinzip gearbeitet werden.

6.7.2 Kernfunktionen eines Workflowsystems

Folgende Funktionsblöcke sind in allen marktgängigen Workflowsystemen enthal-ten:

Definitionsumgebung: ermöglicht Definition des abzuwickelnden Geschäfts-prozesses. Mappenorientierte Workflows und Ad-hoc-Workflows können oft sehr einfach definiert werden, nahezu graphisch wie ein Prozessmodell. Bei echten Production Workflows wird durch die notwendige Integration der Anwendungssysteme die Workflowdefinition aufwendiger. Hier werden dann Skriptsprachen oder sonstige Programmiertechniken benutzt. Laufzeitumgebung: sorgt für Abarbeitung des definierten Workflow-Modells in Form konkreter Instanzen. Stellt dabei die Tätigkeiten den Be-arbeitern zu, protokolliert deren Aktionen und die Ergebnisse ihrer Tätig-keit. Überwacht mit Workflows verbundene Termine und realisiert ein Eskalationsmanagement. Eingangskorb: wird als Benutzerschnittstelle eingesetzt. Im Eingangskorb finden die Teilnehmer des Workflow die vom Laufzeitsystem an sie adres-sierten Arbeitsaufträge (Workitems) vor und können diese bearbeiten. In der Regel wird die Möglichkeit geboten, den Workflow-Eingang in den Standard-Mail-Client des Benutzers zu integrieren. Organisationsmodell: Erlaubt es die im Workflow angesprochenen Benut-zer, Benutzergruppen und Abteilungen in Form einer Aufbauorganisation darzustellen. Analyse und Auswertung: Zu einzelnen Workflowinstanzen werden genaue Verlaufsprotokolle geführt, damit ist jederzeit sichtbar, wo sich die Pro-zessinstanz in der Bearbeitung befindet und welcher Benutzer welche Ak-


Abb. 53. Workfloweingang mit 5 Arbeitsaufträgen im SAP Business Workflow

tionen durchgeführt hat. Einzelprozessübergreifende Auswertungen erlau-ben z. B. Aussagen über durchschnittliche Bearbeitungszeiten von Prozess-schritten und können damit wesentlicher Ansatzpunkt für die laufende Optimierung der Prozesse sein.

6.7.3 Workflow-Anwendungen im PLM

Im PLM existiert eine Reihe von Geschäftsprozessen, bei denen Workflowun-terstützung regelmäßig sinnvoll ist. Diese Prozesse und die Besonderheiten der Workflowintegration werden im Folgenden kurz vorgestellt.

6.7.3.1 Freigabeprozesse im PLM

Die Freigabe von Dokumenten oder Stammdaten durch einen Vorgesetzten oder Projektleiter wird durch relativ einfach strukturierte Workflows ermöglicht, auch wenn z. B. zur Abbildung eines Mehraugenprinzips eine mehrstufige Freigabe notwendig ist. Zu beachten ist, dass je nach Anwendung die Freigabe nicht am Einzelobjekt orientiert werden kann, sondern freizugebende Datenobjekte im Sachzusammenhang zusammengefasst werden müssen (z. B. ganze Baugruppe, alle Dokumente zu einem Projekt).

Solche Workflows werden in der Regel durch bestimmte Status gestartet (z. B.„zur Freigabe“), ebenso signalisiert ein Status die durchgeführte Freigabe. An den


Freigabeprozess können sich evtl. automatische Formatkonvertierungen, Transfers der Daten zwischen verschiedenen Systemen oder eine Datenverteilung anschließen.

Die Verantwortlichen für die Freigabe können in der Regel an den beteiligten Objekten direkt hinterlegt und dort vom Workflowsystem ausgelesen werden (z. B. Verantwortlicher für Projekt, Verantwortlicher für bestimmtes Dokument). Gerade in hierarchisch geprägten Prozessen und Organisationen wird oft die Zu-ständigkeitsermittlung anhand des Organisationsmodells notwendig. Die Ausprä-gung des Freigabeprozesses als Ad-hoc-Workflow ist in der Regel nicht sinnvoll, da damit der Zwangscharakter der Freigabe verloren geht.

6.7.3.2 Stammdatenpflegeprozesse

Der Produktentwicklungsprozess und die darin integrierte Stammdatenpflege be-zieht meist eine Reihe von Abteilungen ein. Verschiedene Stammdatenobjekte werden von verschiedenen Personen angelegt, meist tragen sogar mehrere Perso-nen jeweils Teile der Information eines Stammdatenobjektes bei. Dies gilt erst recht dann, wenn die Stammdatenpflege von typischen ERP-Informationsobjekten (z. B. Sichten des Materialstammes oder Kundenstammes) betrachtet wird.

Es handelt sich in der Regel um einen gut strukturierten Prozess mit hoher Wiederholrate, der sich für die Abbildung durch einen Production Workflow eig-net. Aufgabe des Workflows ist, die beteiligten Stellen in der richtigen Reihenfol-ge zur Dateneingabe aufzufordern und ihnen die Datenerfassungsmasken zur Verfügung zu stellen.

Wesentlich für den Erfolg einer Implementierung ist es, eine Lösung zu schaf-fen, die den Datenerfassungsprozess zwar standardisiert, trotzdem aber flexibel bleibt: das System muss bei Organisationsänderungen mit wenig Aufwand an-passbar sein. Ein Beispiel für einen solchen Stammdatenworkflow liefert der Pro-jektbericht „Stammdatenaufwuchs mit Workflow in der Konsumgüterindustrie“.

6.7.3.3 Änderungsprozesse

In vielen Unternehmen ist der Änderungsprozess der am häufigsten durchlaufene PLM-Prozess. Es bieten sich folgende Prozessabschnitte für eine Abbildung durch einen Workflow an:

Beantragung, Prüfung und Genehmigung einer Änderung: meist ausgehend vom Objekt Änderungsantrag, umfasst Aktivitäten wie Änderungsobjekte ermitteln, Machbarkeit der Änderung prüfen, Änderungskosten ermitteln. Involviert unter Umständen alle von der Änderung betroffenen Abteilungen

Durchführung einer Änderung: Ist relativ einfach strukturiert für Änderun-gen an Teilen, die noch in der Konstruktion bearbeitet werden. Kann aber sehr komplex werden bei bereits in Montage / Betrieb befindlichen Anla-gen oder Änderungen die laufende Serien betreffen. In diesen Fällen sind nämlich eine Vielzahl von Bereichen zu involvieren, bei Änderungen an Serienteilen auch eine Reihe von Aktivitäten auszuführen. Beispielsweise


Konstruk-tion

Konstruk-tion

Anlegen R/3Änderungsstamm

KonstrukteurKonstrukteurWOR

KF L

O WKonfigu-ration

Konfigu-ration

Arbeitsvor-bereitung


EinkaufEinkauf

Disposi-tion

Disposi-tionÄ N D E R U

NG

Rücksenden

Änderungswunsch/Änderungsantrag

Dokumentenverteilung

Notiz

Konstruk-tion

Konstruk-tion

Anlegen R/3Änderungsstamm

KonstrukteurKonstrukteurWOR

KF L

O WKonfigu-ration

Konfigu-ration



EinkaufEinkauf

Disposi-tion

Disposi-tionÄ N D E R U

NG

Rücksenden

Änderungswunsch/Änderungsantrag

Dokumentenverteilung

Notiz

Abb. 54. Ablaufschema eines workflowgesteuerten Änderungsprozesses im Anlagenbau, zeigt wie von Änderungsbeantragung bis abschließender Dokumentenverteilung eine Viel-zahl von Abteilungen involviert wird.

ist zu prüfen was mit Restbeständen passiert, wann die Einsteuerung der Änderung erfolgt und ob Werkzeuge umgearbeitet werden müssen. Änderungsverteilung: nach Abschluss (meist nach Freigabe) der Änderung sind zugehörige Dokumente und geänderte Objekte (Stücklisten, Zeich-nungen) an betroffene Abteilungen zu verteilen.

Änderungsworkflows arbeiten mit den beschriebenen Datenobjekten des Ände-rungsmanagements wie Änderungsantrag, Änderungsauftrag. Besondere Heraus-forderung ist es, einen flexiblen Workflow zu entwerfen, der zwar gewisse Abläufe erzwingt (Prüfungen, Freigaben sind einzuhalten) aber insgesamt eine flexible Prozesssteuerung erlaubt. Einzubeziehende Personen können meist nicht vollständig automatisch ermittelt werden (welche Konstruktionsabteilung ist in-volviert, welcher Einkäufer ist zuständig…). Daher integriert man in den Work-flow eine Funktion zur Ad-hoc-Steuerung des Ablaufs.

6.7.3.4 Steuerung des Produktentwicklungsprozesses

Die umfassendste Workflow-Anwendung im Rahmen von PLM ist die Steuerung des Produktentwicklungsprozesses. Anders als die bisher erläuterten Beispiele steu-ert man hier einen Gesamtprozess, nicht nur einzelne wesentliche Prozessabschnitte wie Freigaben oder Stammdatenerfassung. Damit ermöglich diese Workflow-Anwendung Kontrolle und Monitoring des gesamten Entwicklungsablaufs.


Dabei ist zu beachten, dass einzelne, kleinere Teile des Gesamtprozesses eher unstrukturiert, nicht in Einzelschritten vordefiniert, verlaufen. Für diese collabo-rativen Prozesse ist die Steuerung mittels einer Groupware-Plattform besser ge-eignet als die Definition eines Workflows. Beispiel für einen collaborativen Prozessabschnitt ist das Ideenmanagement in der frühen Entwicklungsphase.

Wesentliche Teile der Produktentwicklung hingegen verlaufen strukturiert mit immer wiederkehrenden identischen Arbeitsschritten. Wie zuvor mehrfach erläutert, kann man gerade deswegen vom „Projektcharakter“ der Produktent-wicklung sprechen. Der Entwicklungsprozess kann in Form von Projektablauf-plänen beschrieben werden, die sich – zwar in verschiedenen Ausprägungen aber doch nach identischen Mustern – wiederholen.

Wenn diese umfassende Abbildung des Entwicklungsprozesses in Form eines Ablauf- oder Netzplanes gelingt, lässt sich leicht dessen Steuerung mit einem Workflow konstruieren.

Der Workflow arbeitet Schritt für Schritt den Ablaufplan ab, stellt die zu erle-digenden Aktivitäten den zugewiesenen Bearbeitern zu und informiert sie über ihre Aufgaben im Projekt. Er sammelt Bestätigungen der Aktivitäten (Rückmel-dungen) ein und kontrolliert damit den Projektfortschritt. Der Workflow über-nimmt eine Terminkontrolle für die vorgegebenen Projekttermine und ein Eskalationsmanagement. Integriert mit einem operativen Projektmanagementtool (z. B. SAP PS, SAP cProjects) kann der Workflow auch die Neuterminierung des Gesamtprojektes bei Abweichungen (wie z. B. verspätete Erledigung einzelner Arbeitsschritte) übernehmen. Der Workflow kann während des Projektes jederzeit auf Änderungen des zugrunde liegenden Ablauf- oder Netzplanes reagieren, wo beispielsweise zusätzliche Schritte aufgenommen, Schritte weggelassen oder Ter-mine geändert werden.

Besonderen Benefit generiert diese Workflow-Anwendung dann, wenn nicht nur die Steuerung des Prozesses durchgeführt wird, sondern eine enge Anbindung der Produktstammdaten, die im Prozess entstehen, erfolgt.

Abb. 55. Ablaufschema eines netzplanbasierten Workflow


Eine ganzheitliche Workflow-Anwendung zur Steuerung des Produktentwick-lungsprozesses integriert also folgende Komponenten:

Zeit und Projektmanagement: Steuerung des Entwicklungsprojektes, in ei-nem Netzplan ist der Projektablaufplan zu Grunde gelegt Workflow- und Mailbenachrichtigung: Integration in die Standard-Mail-umgebung zur Benachrichtigung über anstehende Aufgaben Terminüberwachung und Eskalation: durch Monitoring der im Netzplan vorhandenen Termine Kosten- und Budgetüberwachung: durch Sammeln von Rückmeldungen und Verbuchung des projektbezogenen Aufwands Dokumentenmanagement: Sammeln aller Dokumente mit Bezug zum Ent-wicklungsprojekt oder Produkt und Ablage in einem DMS Stammdatenentstehung: Sammeln aller entstehenden Produktstammdaten (Spezifikationen, Dokumente, Artikel, Stücklisten) – eventuell in aus dem Projekt heraus angesteuerten separaten Stammdatenpflegeworkflows.

Weitere Details zu dieser umfassenden Workflowanwendung enthält der Projektbe-richt „Automatisierte Stammdatenpflege in der Konsumgüterindustrie“ (Kapitel 17).

7 Methoden und Trends

Eine integrierte PLM-Lösung ist gekennzeichnet von der Unterstützung durch-gängiger Prozesse über alle Lebenszyklus-Phasen eines Produktes hinweg, basierend auf konsistenten Datenstrukturen, klar definierten Zuständigkeiten und genau definierten Prozess-Schnittstellen. Insbesondere die Datenintegrität ist Grundvoraussetzung für den effizienten Einsatz neuer Methoden und Tech-nologien entlang des gesamten Lebenszyklus. In diesem Kapitel werden einige der wichtigsten Methoden mit ihrer Anwendung und Bedeutung im PLM-Umfeld erläutert:

1. Prototyping 2. Simultaneous / Concurrent Engineering 3. Digital Mockup 4. Collaborative Engineering 5. Digitale Fabrik 6. Virtuelle Realität

Hierbei geht es nicht um die Beschreibung der zugrunde liegenden Basistechnolo-gien, sondern vielmehr um die Anwendung und Vernetzung dieser Methoden im Rahmen einer integrierten, prozessorientierten PLM-Lösung.

Die hier vorgestellten Methoden unterstützen hauptsächlich den bereits in Abb. 18 dargestellten Ausschnitt der Produktentwicklung.

7.1 Prototyping

Die Prototypenentwicklung ist heute integraler Bestandteil moderner Entwick-lungsprozesse. Durch neue Materialien und Herstellungsverfahren können Muster bereits in den frühen Phasen des Entwicklungsprozesses für die unterschiedlichs-ten Fragestellungen hergestellt werden.

Unter dem Begriff „Rapid Prototyping“ werden additive oder generierende Herstellungsverfahren zusammengefasst. Die Form entsteht durch das Aneinan-derfügen inkrementeller Volumenelemente. In der Regel erfolgt ein schichtweiser Aufbau. Unterstützt wird dieser Aufbau evtl. durch Stützkonstruktionen. Man spricht auch von einem „Positiv-Modell“.

Im Gegensatz dazu erfolgt bei konventionellen Verfahren (Drehen, Bohren, Fräsen, Erodieren) die Formgebung durch Materialabtrag.

Der Sinn und Zweck von Prototypen ist:


Abb. 56. Verschiedene Prototypen – Proportions-/Ergonomiemodelle (Quelle: ZIP26)

Design zu verifizieren und zu optimieren Schwachstellen zu identifizierenFunktionalität zu testen Rasch und effizient mit Projektpartnern über konkrete Fragestellungen zu kommunizieren die Akzeptanz des künftigen Produktes im Markt zu eruieren Angebote für die Produktion einzuholen oder zu erstellen

Dabei werden die Prototypen grundsätzlich in verschiedene Modellklassen einge-teilt:

Proportionsmodell Zeigt die äußere Form und die wichtigsten Proportionen Dient der Kommunikation und der Motivation Ermöglicht den schnellen Konsens über die Produktidee Muss schnell, einfach und preiswert herzustellen sein Detaillierungsgrad: niedrig

26 ZIP – Zentrum für Innovative Produktion des Saarlandes; diese Modelle entstanden in Zusammenarbeit mit dem Kunststoffzentrum Ostfrankreich – Pôle de Plasturige de l’Est

Prototyping 121

Ergonomiemodell Unterstützt die schnelle Entscheidung über die Durchführbarkeit Zeigt wichtige Details für die Bedienbarkeit und Benutzbarkeit Zeigt ggf. auch wichtige Teilfunktionen Detaillierungsgrad: mittel

Designmodell Entspricht äußerlich möglichst vollständig dem Muster, aber geringe Maßgenauigkeit erlaubt Finish der Oberflächen in „Show Room“-Qualität Unterstützt die schnelle Entscheidung über Konstruktions- und Ferti-gungsmethoden Ermöglicht ein Urteil durch Dritte (Kunden, Vertrieb, Presse, Zulie-ferer) Detaillierungsgrad: hoch

Funktionsmodell Zeigt einige oder sogar alle Funktionen, ggf. auch unter Verzicht auf die Wiedergabe der äußeren Form Ermöglicht die Prüfung einzelner Funktionen (Montierbarkeit, Wartbarkeit, Kinematik) Liefert die Randbedingungen für den Werkzeug- und Formenbau Detaillierungsgrad: Hoch

Prototyp Entspricht dem (Serien-) Muster bereits weitgehend, ggf. sogar voll-ständig Wird nach erarbeiteten Fertigungsunterlagen erstellt Unterscheidet sich vom Serienprodukt nur durch das Produktionsver-fahren und/oder die ProduktionsanlageErmöglicht die Herstellung von Werkzeugen (Rapid Tooling) Detaillierungsgrad: wie Serienprodukt

Muster Stammt bereits aus der Serie (Null, Vorserie) Ermöglicht den vollständigen Test aller Produkteigenschaften Unterstützt die Ausbildung von Fertigungs- und Servicepersonal Ermöglicht den Abgleich bzw. die Optimierung der Fertigungs- und Montagefolge Unterstützt die Feinplanung von Kunden und Lieferanten


Abb. 57. CAD-Modell und Ableitung für STL-Modell

Rapid Tooling umfasst den Prozess zur Herstellung von Werkzeugen und Formen (Negativ) für nachgelagerte Gieß- oder Spritzgießverfahren. Typische Verfahren („Soft Tooling“) sind:

CNC-Fräsen in Aluminium MetallspritzenVakuumguss MetallgussMetall Laser Sintern Rapid Layer Milling HSC (High Speed Cutting)

Ausgangsdaten für Rapid Prototyping oder Rapid Tooling sind immer Computer-daten. Die Generierung dieser Daten erfolgt durch Konstruktion mit einem 3D-CAD-System oder Flächenrückführung auf der Basis digitaler Messwerte (Reverse Engineering). Die Verarbeitung der Daten erfolgt schichtweise durch die Diskreti-sierung der Geometrie in Dreiecksfacetten; in der Regel wird hierfür das STL-Format (STL = Stereolithographie) angewandt.

Simultaneous Engineering 123

RapidPrototyping

DefinitionZweck/Funk...

DefinitonWerkstoff

DefinitionOberfläche

DefinitionVerfahren

Daten-aufbereitung

Zusatz-konstruktion

Prototyping-Prozess

(HSC, Gus...

Übergabe,Abnahme

Muster

Daten-konvertierung,Datenausta...

Daten-aufbereitung

DefinitionDatenformat

DefinitionEinstellungen/Konventionen

Daten-übernahme

Prozess-Validierung

Fehlerkorrektur

Daten-speicherung

Daten-konvertierung,Datenausta...

FestlegungSpezi fizierungAustauschfo...

Spezi fikationStruktur, Inhalt

DefinitionKonventionen

DefinitionAustausch-

prozess

TestVerifikation

DefinitionAustausch-

partnerOptimierung

Rollout

VereinbarungAustausch-

Tool

DefinitionAbnahme

Abb. 58. Rapid-Prototyping-Prozesse mit der zugehörigen Datenkonvertierung und Daten-aufbereitung

Im Rahmen von PLM ist wichtig, dass Rapid Prototyping und Rapid Tooling ei-gene (Teil-) Prozesse in der gesamten Prozessarchitektur darstellen; die in diesen Prozessen erzeugten Daten unterliegen ebenfalls einem Freigabe- und Ände-rungswesen und müssen in Zusammenhang mit den originären Daten verwaltet werden. Ebenso haben diese Prozesse Schnittstellen zu anderen Unternehmensbe-reichen wie Produktentwicklung, Marketing, Einkauf, Vertrieb oder Qualitätsma-nagement.

Abb. 58 verdeutlicht die damit im Zusammenhang stehenden Prozesse. Dargestellt sind auch die detaillierten Prozesse zur Datenaufbereitung und Datenkonvertierung.

7.2 Simultaneous Engineering

Im Rahmen von EDM (Engineering Data Management mit dem Schwerpunkt auf der Prozessorientierung im Engineering) und PDM (Product Data Management mit dem Schwerpunkt auf der Datensicht im Engineering) wurde Simultaneous


Engineering (SE) als Strategie entwickelt, um durch die Parallelisierung der ein-zelnen Phasen des Produktentstehungsprozesses die Durchlaufszeit drastisch zu verkürzen. Der Begriff Concurrent Engineering wird als Synonym verwendet und betont die Gleichzeitigkeit der ablaufenden Aktivitäten innerhalb des Prozesses. Während zunächst nur voneinander unabhängige Prozessschritte zur Parallelisie-rung herangezogen wurden, werden heute auch miteinander in Zusammenhang stehende Vorgänge betrachtet und eng verzahnt.

Abb. 59 zeigt diese Parallelisierung, die prinzipiell zwei Ziele verfolgt:

1. Früherer Beginn der (Serien-) Fertigung 2. Reduzierung der Design-Änderungen durch Frontloading

Um Simultaneous Engineering effektiv durchführen zu können, bedarf es einer deut-lich höheren Abstimmung in den sich überlappenden Prozess-Phasen und dadurch einer höheren Kommunikationsrate; zum Thema Collaboration sei an dieser Stelle auf den Abschnitt zu Collaborative Engineering verwiesen. Die höhere Kommunika-tionsrate und Abstimmung führt dazu, dass Informationen aus eigentlich späteren Phasen bereits sehr früh in den Prozess einfließen und damit die Gesamtanzahl der Design-Änderungen reduzieren. Nach der sog. „Rule of 10“, die besagt, dass sich die Kosten für Design-Änderungen je Phase um den Faktor 10 erhöhen, reduzieren sich bei erfolgreicher Umsetzung dieser Strategie infolge der reduzierten Ände-rungsanzahl auch die Gesamtkosten in der Produktentstehung ganz beträchtlich, da insbesondere sehr späte Änderungen vermieden werden können.

Voraussetzung für eine Parallelisierung der Phasen ist, dass alle am Produktent-wicklungs- und Innovationsprozess beteiligten Organisationseinheiten, wie For-schung, Entwicklung, Konstruktion, Berechnung, Arbeitsvorbereitung, Fertigung, Vertrieb, Marketing etc. gleichzeitig auf konsistente Datenbestände zugreifen können. Die Art des Zugriffs und die Berechtigungen ergeben sich aus der aktuel-len Aufgabe und Rolle im Prozess.

Für die Projektorganisation bedeutet Simultaneous Engineering, dass Mitarbei-ter aus allen involvierten Bereichen interdisziplinäre Teams bilden, um die vielfäl-tigen und sehr komplexen Abhängigkeiten insbesondere bei der Entwicklung neuer Produkte frühzeitig und ganzheitlich erkennen und die Entwicklungsstrate-gie entsprechend beeinflussen zu können. Simultaneous Engineering stellt damit konzeptionell eine integrierte Vorgehensweise dar. Voraussetzung für eine gelun-gene Realisierung ist ein funktionierendes, am Prozess orientiertes Projektmana-gement, bei dem alle Phasen des Entwicklungsprozesses von der ersten Produktidee bis zur Betreuung der (Serien-) Produktion und des Service durch in-terdisziplinäre Teams begleitet werden. Dies betrifft übrigens nicht nur die interne Projektabwicklung, sondern bezieht über die gesamte Prozesskette externe Zulie-ferer, Design- und Ingenieurbüros sowie Dienstleister mit ein.

Als Folge dieser Parallelisierung werden sehr häufig Entwicklungsprojekte durch eine einhergehende Standardisierung von Vorgehensweisen und Integration der beteiligten IT-Werkzeuge optimiert. Die Standardisierung von Vorgehenswei-sen soll im Sinne von Best-Practice den Prozess kontinuierlich analysieren und

Simultaneous Engineering 125

Anforderungs-analyse

Anforderungs-management /Grobkonzept

Arbeits-vorbereitung Fertigung

Sequentielle Vorgehensweise

Parallele / Simultane Vorgehensweise

Produkt- undProzess-

Konzeption


Produkt-entwicklung





Konzeption

Produkt-entwicklung


Zeit

Zeitvorteil

Kosten je Design-Änderung: € 100 € 1.000 € 10.000 € 100.000 € 1.000.000 ….

Kommunikation+ Koordination+ Kooperation= Collaboration




Sequentielle Vorgehensweise

Parallele / Simultane Vorgehensweise


Konzeption


Produkt-entwicklung





Konzeption

Produkt-entwicklung


Zeit

Zeitvorteil

Kosten je Design-Änderung: € 100 € 1.000 € 10.000 € 100.000 € 1.000.000 ….

Kommunikation+ Koordination+ Kooperation= Collaboration

Abb. 59. Parallelisierung in der Produktentwicklung

dadurch verbessern, unabhängig von den beteiligten Einzelpersonen oder Organi-sationen. Die Integration der IT-Werkzeuge reduziert die Anzahl der System-schnittstellen und minimiert so das Risiko inkonsistenter Datenbestände.

Zusammenfassend bedeutet Simultaneous Engineering in der Praxis:

Fokussierung auf den gesamten Produktlebenszyklus mit Konzentration auf die wichtigen Kernprozesse Standardisierung von Abläufen beginnend mit der Anforderungsanalyse bis hin zur Produkt- und Prozess-Entwicklung Bildung interdisziplinärer Teams, um möglichst früh im Prozess über um-fassende Informationen verfügen zu können Systemintegration der von den beteiligten Organisationseinheiten genutzten IT-Systeme Collaboration, um Produkt- und Prozessinformationen zwischen allen Betei-ligten möglichst früh zu kommunizieren und daraus Lösungsstrategien ab-zuleitenInterdisziplinäre Teamorganisation von Technikern und Nicht-Technikern


7.3 Digital Mockup

Unter Digital Mockup (DMU) versteht man ganz allgemein die Repräsentation der ein Produkt definierenden Baustruktur bestehend aus mehrstufigen Baugruppen und Einzelteilen und deren geometrischer Definition (siehe Abb. 60) mit dem Ziel, Untersuchungen und Optimierungen auf der Basis geometrischer Informationen und Zusammenhänge durchzuführen.

Abb. 60. Produktstruktur und 3D-Baugruppendarstellung

Die Basis eines DMU sind neben den Strukturinformationen hauptsächlich CAD-Daten, die in der Regel in verschiedenen CAD-Systemen modelliert werden und daher in verschiedenen Formaten vorliegen. Beispiele für derartige Untersuchun-gen sind Ein-/Ausbauuntersuchungen, bei denen nicht nur die Passung der einzel-nen Teile-Paarungen eine Rolle spielt, sondern insbesondere auch die zur Montage benötigten Verfahrwege und Bewegungsräume sowie die Handhabung der Monta-gewerkzeuge berücksichtigt werden müssen.

Ein Vorreiter für DMU ist die Automobilindustrie. Hier beschreibt der Digitale Mockup den rechnerinternen Zusammenbau eines Fahrzeugs oder einer Fahr-zeugkomponente auf der Basis der CAD-Daten. Zu diesem Zusammenbau werden alle dazu benötigten CAD-Daten in einen zentralen Datenpool geladen und dort

Digital Mockup 127

gemeinsam visualisiert. In den DMU-Prozess sind insbesondere die Bereiche Konstruktion, Simulation, Analyse und Fertigungsplanung involviert.

Im Bereich Maschinen- und Anlagenbau gewinnt die auf DMU basierende Funk-tion des „Fly-Through“ besondere Bedeutung. Auf Basis eines geometrischen Zu-sammenbaus kann der Anwender sich durch eine komplexe Anlage navigieren.

Durch einen definierten DMU-Prozess wird gewährleistet, dass die Anwender immer auf den aktuell gültigen Entwicklungsstand der betrachteten Komponenten in der zur Erreichung des Prozess-Ziels notwendigen Qualität zugreifen. Hierzu werden die einzelnen geometrischen Bestandteile durch eine Zusammenbaustruk-tur logisch miteinander verknüpft.

Zur Berechnung der sehr aufwendigen graphischen Darstellungen werden mo-derne Methoden der Computergraphik und Computational Geometry eingesetzt. Ein Beispiel hierfür sind hochauflösende, realitätsnahe graphische Darstellungen, Advanced Rendering genannt. Neben der Visualisierung von Produkten ist auch die Simulation und Analyse von Platzverhältnissen eine wichtige Anwendung von DMU. In diesem Zusammenhang werden Kollisionsbetrachtungen innerhalb einer Baugruppe, sogenannte Clash-Analysen (siehe Abb. 61), und Freigängigkeits-untersuchungen während einer Bewegungssimulation, sog. Clearance-Analysen, durchgeführt.

Zur effizienten Analyse von Fragestellungen bzgl. Sicht, Komfort und Ergo-nomie wurden in Zusammenarbeit der Automobilindustrie 3D-CAD-Modelle von Menschen entwickelt. Damit lassen sich umfassende Package- und Designstudien

Abb. 61. Clash-Detection (Quelle: CoCreate Software GmbH)


unter Berücksichtigung der späteren Nutzung bereits in der Konstruktion bearbei-ten. Da Ergonomie zunehmend von den Endkunden als Qualitätsfaktor und bedeu-tendes Unterscheidungsmerkmal eingestuft wird, gewinnen die zugehörenden Analysen immer größere Bedeutung.

Analysen in Zusammenhang mit rechnerinternen Menschmodellen mit anthro-pometrischen Daten sind beispielsweise:

Translationen und Rotationen des Körpers, Gelenkanimationen und Ket-tenbewegungen von Körperteilen mit automatischer Zeitpunktanimation, Erreichbarkeitsanalysen Restriktionen aufgrund von Grenzkörperhaltung und Grenzflächen, Be-rücksichtigung von Selbstdurchdringungen Gesundheits- und Komfortanalysen mit Ermüdungsanalysen und orthopä-dischen Haltungsbewertungen Sichtanalysen unter Einbeziehung von Augen-, Hals- und Kopfbewegun-gen, Berücksichtigung von Sichtfeld und Sehentfernung sowie Simulation von Spiegelsichten

Abb. 62. Mensch-Modell RAMSIS (Quelle: Human Solutions GmbH)

Hierdurch lassen sich nicht nur funktionelle und ergonomische Aspekte untersu-chen, sondern auch Montage- und Demontageprozesse simulieren. Dadurch kön-nen die Prozess-Zeiten oder der Aufwand für Wartungs- und Reparaturarbeiten bereits während der Konstruktion analysiert und simuliert werden. Diese Untersu-chungen werden jedoch nicht nur statisch durchgeführt, sondern auch dynamisch, d. h. unter Belastung der Bauteile oder während Schwingungsvorgängen, z. B. bei der Fahrwerkauslegung.

Digital Mockup 129

Abb. 63. Anwendung des Mensch-Modells in der Fahrzeugkonstruktion (Quelle: Human Solutions GmbH)

Derartige geometrische Untersuchungen sind heute Hauptgegenstand der DMU-Anwendung. Dagegen ist die integrierte Simulation physikalischer oder chemi-scher Vorgänge, die beispielsweise bei der Produktion von Kunststoff-Teilen in Form von Schrumpfungen oder bei Klebeverbindungen eine sehr wichtige Rolle spielen, momentan Gegenstand der Forschung.

Wie bereits erwähnt, spielt das Thema Berechnung und Auslegung eine wichti-ge Rolle. Hier wird oft die Methode der Finiten Elemente (FEM) eingesetzt. Diese beruht auf der Zerlegung eines komplexen Bauteils in kleine Einheiten, deren Ei-genschaften, Verhalten und Wechselwirkung mit den benachbarten Elementen im System hinterlegt werden. Inkrementell wird nun die Wirkung auf das gesamte Bauteil berechnet. Dabei kann es sich um Belastungsberechnungen für eine Crash-Simulation, Erwärmungs- oder Abkühlungsprozesse bei einer Spritzguss-Simulation oder akustische Prozesse zur Analyse von Geräuschausbreitungen handeln. Quelle der Daten sind geometrische Bauteilbeschreibungen, die typi-scherweise von einem 3D-CAD-System geliefert und in einem ersten Schritt in die kleinen Einheiten zerlegt werden. Abb. 64 zeigt eine solche FEM-Simulation.

Im hier behandelten PLM-Kontext bedeutet ein solcher Analyse- und Simulati-onsprozess, dass die Prozessschnittstellen klar definiert und die zugehörenden Eingangs- und Ausgangsdaten ebenfalls in die Betrachtung des Daten- und Do-kumentenmanagements mit Statusmanagement und Versionierung eingebunden werden müssen.


Abb. 64. FEM-Belastungssimulation

Im Zuge der weiteren Produktentwicklung werden die Analysen immer komplexer. Abb. 65 zeigt am Beispiel einer PKW-Karosserie die Untersuchung einer Sitzver-stellung. Hier sind im PLM-Kontext beispielsweise das Konfigurations- und Än-derungsmanagement besonders wichtig, um auf die aktuell gültige Bauteile-struktur zu verweisen.

Abb. 65. DMU und Bewegungssimulation (Quelle: Tecoplan)

Collaborative Engineering 131

Abb. 66. DMU – Package- und Piping-Analyse (Quelle: Lehrstuhl für Konstruktionstech-nik/CAD der Universität des Saarlandes)

Wie hoch die Komplexität größerer Baugruppen ist, wird aus Abb. 66 ersichtlich. Hier ist ein Teil eines PKW-Motors mit den notwendigen Schlauch- und Rohrver-bindungen sowie Zusatzaggregaten und Abdeckungen gezeigt. Die hohe Anzahl an Bauteilen verlangt nicht nur nach einem ausgefeilten Strukturmanagement, sondern stellt auch in hohem Maße Ansprüche an die Performance der eingesetzten Lösung.

7.4 Collaborative Engineering

Der Begriff Collaborative Engineering oder Engineering Collaboration umfasst alle Prozesse, Anwendungen und Funktionen, mit denen die Zusammenarbeit von Anwendern zur Ausführung einer Aufgabe innerhalb des Produktlebenszyklus be-schrieben wird. Hierunter werden Aufgabenbereiche subsumiert wie:

Integriertes Projektmanagement zur Koordination von Prozess-Schritten CSCW (Computer Supported Cooperative Work) mit den Unterfunktionen

Co-Viewing – gemeinsames Betrachten einer 2D-Zeichnung oder eines 3D-ModellsMarkup, Redlining – Hinzufügen von Bemerkungen und Änderungen ohne Änderung der originalen Daten Co-Measurement – gemeinsames Messen auf einer Zeichnung oder an einem digitalen Modell Co-Modeling – gemeinsames Modellieren an einem 3D-Modell


Shared Files

Bulletin-Boards

Video-/Desktop-

Conferencing

PDM-

Systems

Task-Pads

Databases

DB-Management

Group-Editors

Decision-Support

Distributed

Hypertext FAX/Phone

Collaborative

Project-

Management

Common

Calendar-Tools

FTPShared Files

Bulletin-Boards

Video-/Desktop-

Conferencing

Workflow-

PDM-

Task-Pads

DB-

-Editors

-Support

Distributed

Hypertext FAX/Phone

E-Mail

CAx-Tools

PLM-

Systems

Collaborative

Engineering

Project-

Management

Common

Calendar-Tools

FTP

Shared Files

Bulletin-Boards

Video-/Desktop-

Conferencing

-

Management

PDM-

Systems

Task-Pads

DB-

-Editors

-Support

Distributed

Hypertext FAX/Phone

E-Mail

CAx-Tools

PLM-

Systems

Collaborative

Engineering

Project-

Management

Common

Calendar-Tools

CooperationCoordination

Communication

Collaboration

Decision

Databases

Management

Workflow

GroupManagement

Systems

Databases

Management Decision

Group

Abb. 67. Verknüpfung zweier Collaboration-Pyramiden

Kommunikation und Datenaustausch Dokumentation der Collaboration, der getroffenen Entscheidungen und der definierten Arbeitspakete Sicherheitsmechanismen zum Datenschutz Berechtigungskonzept und Rollen innerhalb einer Collaboration

Wenn man die auf dem Markt befindlichen Werkzeuge einordnen will, benötigt man eine weitergehende Kategorisierung. Collaboration setzt als Basiskomponen-te zunächst Kommunikation voraus; auf dieser Basis baut Koordination auf, die wiederum Voraussetzung für Kooperation ist. Diese Komponenten sind ihrerseits Ausgangspunkt für synchrone und asynchrone Collaboration.

In der Realität genügt es jedoch nicht, für eine bestimmte Aufgabe aus den zur Verfügung stehenden Komponenten eine Collaboration-Lösung zu konzipieren; vielmehr verlangt Collaboration die Zusammenarbeit von mehreren Personen oder Organisationen und daher die Integration zweier, in der Regel unterschiedlich ausgeprägter Collaboration-Konfigurationen. Abb. 67 illustriert die Einordnung verschiedener IT-Werkzeuge sowie die Herausforderung der Verknüpfung zweier Collaboration-Lösungen. Die jeweiligen Bausteine der Collaboration-Lösungen sind farblich hinterlegt.

Das abgebildete Beispiel zeigt exemplarisch die Zusammenarbeit eines Unter-nehmens mit einem seiner Zulieferer. Das erste Unternehmen setzt in einer integ-rierten Umgebung Mail, Datenaustausch und Terminplanung ein, integriert mit Hilfe des PLM-Systems Projektmanagement, hat eine Schnittstelle zur CAx-

Digitale Fabrik 133

Collaboration-Strategy

Collaboration-Preparation

Collaboration-Planning

Collaboration-Execution

Collaboration-Finishing

Messaging Calendering Distribution

Management-Processes

Core-Processes

Support-Processes

Show Case

CollaborationStart

Backend-Integrationinto SAP PLM

Templates

Project-Collaboration

Monitoring

Abb. 68. Prozesse innerhalb einer Collaboration (Projektbeispiel)

Umgebung sowie ein separates Collaboration-Tool für die interne synchrone Zu-sammenarbeit über mehrere Standorte hinweg implementiert. Beim Zulieferer fin-det man eine einfachere Umgebung vor, führendes System ist hier ein CAD-System, das in Zusammenarbeit mit einem Projekt-Management-Tool, einem ge-meinsamen Datei-Server und einem Mail-Server die Collaboration-Umgebung darstellt. In dem hier gezeigten Beispiel wurde die Umgebung des ersten Unter-nehmens um eine gemeinsame Austausch-Plattform und ein Realtime-Design-Collaboration-Tool ergänzt, um die unternehmensübergreifenden Prozesse unter-stützen und beschleunigen zu können. Um die Komplexität der Abläufe zu ver-deutlichen, sind in Abb. 68 die zu Collaboration notwendigen Prozesse dargestellt.

7.5 Digitale Fabrik

Das Ziel der Digitalen Fabrik besteht darin, ein Abbild der bestehenden oder ge-planten Produkte und der damit in Zusammenhang stehenden Produktionsstätte und -prozesse zu schaffen, in dem sämtliche realen Zusammenhänge digital erfasst und virtuell dargestellt werden. Damit können schon in der Planungsphase alle


Auswirkungen von beabsichtigten Veränderungen im eigentlichen Sinne des Wor-tes sichtbar gemacht werden. Die Digitale Fabrik ist damit ein realistisches, integ-riertes Computermodell einer Produktionsstätte: von der gesamten Fabrik bis hin zum einzelnen Bearbeitungsschritt. Dieses Computermodell lässt sich zu ver-schiedenen Zwecken nutzen:

In der Planungsphase evaluiert man anhand des Modells vorab das Fabrik-konzept bis auf die Detailebene und unterstützt damit die Prozess- und Produktentwicklung sowie die zugehörige Kommunikation. Das Modell dient der Entscheidungsfindung und Dokumentation. In dieser Phase wer-den alle vorhersehbaren und beeinflussbaren Anlaufschwierigkeiten simu-liert und bestmöglich eliminiert. In der laufenden Produktion gilt diese Zielstellung in gleichem Maße für die Serien betreuende Planung. Zukünftige Modifikationen werden in der Digitalen Fabrik vorweggenommen, simuliert, optimiert und erst nach Be-hebung eventuell aufgetretener Probleme in die Realität umgesetzt.

Die Idee der Digitalen Fabrik an sich kann darüber hinaus für folgende Zwecke verwendet werden:

Digitale Fabrik als Vision: Die Absicherung der gesamten technischen und logistischen Planung für eine neue Fabrik und die Produktion eines neuen Produkts erfolgt mittels virtueller Planungstechniken. Digitale Fabrik als Strategie: Die künftige sowie die laufende Fabrik werden mit ihren technischen und logistischen Prozessen in einem durchgängigen Datenmodell abgebildet. Es dient dem Aufbau einer verteilten Kommuni-kationsplattform inklusive der Einbindung externer Kooperationspartner sowie der benötigen Schnittstellenprozesse. Digitale Fabrik als Veränderungsprozess: Die Digitale Fabrik dient der Verzahnung von Produktentwicklung und Produktionsvorbereitung und eigentlicher Produktion zu einer integrierten Produkt- und Prozess-Entwicklung. Dieses integrierte Produkt- und Prozess-Engineering unter-liegt fortan auch einem integrierten Änderungswesen und wird nicht mehr isoliert betrachtet. Digitale Fabrik als Wissensspeicher: In der Digitalen Fabrik findet sich das gesammelte Fachwissen aller Fachbereiche der Produktion wieder. Da-durch wird in der Digitalen Fabrik das „Fabrikwissen“ dokumentiert und für die Weiterentwicklung genutzt. Digitale Fabrik als informationstechnische Lösung: Die Digitale Fabrik verknüpft flexibel und individuell unterschiedlichste Funktionsbausteine mittels intelligenter Schnittstellentechnologien.

Grundvoraussetzungen für die Digitale Fabrik sind:

Virtuelle Realität (VR) 135

Verfügbarkeit von digitalen Produktdaten für Erzeugnisse, Werkzeuge, Be-triebsmittel, Produktionsstätten etc. Hinterlegung digitaler Prozessdaten zur Abbildung des Herstellungsprozes-ses und der damit verbundenen Logistik-Prozesse Repräsentation der gegenseitigen Abhängigkeiten von Produkt, Produktion und Logistik Kooperation, Koordination, Kommunikation über alle Unternehmensberei-che hinweg, um die Digitale Fabrik umsetzen zu können Engineering Collaboration intern und extern zur Simulation und Entschei-dungsfindung auf der Basis der aufgestellten Rechenmodelle Prozess-Simulationen zur Evaluation verschiedener Lösungsmöglichkeiten und Optimierung

Zur Einführung der Digitalen Fabrik bedarf es zunächst der Strategie-Definition. Sie ist Grundlage der Ausrichtung der Digitalen Fabrik und Ausgangspunkt für das Design der benötigten Prozesse. Ergänzt wird die Strategie durch die Definition von Kennzahlen und die Identifikation von Störfaktoren, um die nachfolgenden Phasen zu steuern. In der Design-Phase werden die Prozesse für das Produkt- und Prozess-Engineering definiert. Auf dieser Basis werden Einführungsszenarien be-schrieben und anhand der hier konkreter zu spezifizierenden Kennzahlen und Stör-faktoren bewertet. Im Anschluss wird ein Szenario ausgewählt und implementiert. Über das Controlling werden der Regelkreis geschlossen und die Kennzahlen überprüft. Die Ergebnisse finden wiederum Eingang in den nächsten Design-Zyklus.

Das Thema Digitale Fabrik wird von führenden Analysten als das Thema der nächsten Jahre angesehen. Das Marktvolumen wird auf mehrere Milliarden Euro prognostiziert mit enormen Wachstumsraten. Vorreiter sind die Automobilindus-trie sowie der Maschinen- und Anlagenbau. Mittlerweile hat sich durch den Zu-sammenschluss der Anwender und Systemhäuser ein Fachkongress27 zu diesem Thema etablieren können.

7.6 Virtuelle Realität (VR)

Eng in Zusammenhang mit der CAD-Integration und Digitaler Fabrik steht die Virtuelle Realität. Im Grunde versteht man unter diesem Begriff eine weiterentwi-ckelte Mensch-Maschine-Schnittstelle. Ziel der virtuellen Realität ist es, eine künstliche Welt zu schaffen, die im Idealfall von der wirklichen Welt nicht zu un-terscheiden ist. Der Mensch, der in die Virtuelle Realität eindringt, kann sich dort

27 Internationaler Fachkongress: Digitale Fabrik in der Automobilindustrie, Ludwigsburg, MI-Verlag, Landsberg


bewegen, die abgebildeten Objekte inspizieren, mit ihnen interagieren und sie letztendlich sogar verändern.

Die Interaktion mit der Virtuellen Realität findet durch ein „Head-mounted-Display“, einer mit miniaturisierten Bildschirmen versehene Brille, durch einen Dataglove, einen mit Sensoren bestückten Handschuh oder einen Datasuit, einen mit Sensoren versehenen Anzug statt. Die Simulationen von Gleichgewicht, hapti-schem Feedback, Geruchs- und Geschmackssinn gestalten sich zwar heute noch technisch schwierig im Vergleich zur Vortäuschung akustischer und optischer Wahrnehmungen, es wird aber laut Prognosen der Experten auf dem Gebiet der Künstlichen Intelligenz nur eine Frage der Zeit sein, bis die Gesamtheit aller sinn-lichen Wahrnehmungen simuliert werden kann. Diese Möglichkeiten der Immer-sion unterscheiden die Virtuelle Realität substantiell von den bis dato genannten Technologien. Hier wird der Mensch selbst und nicht nur ein Mensch-Modell Be-standteil der rechnerinternen Simulation.

Einsatz findet VR vor allem in den Bereichen, in denen die tatsächliche Erpro-bung eines ganzen Systems in der Wirklichkeit technisch unmöglich, zu aufwen-dig oder zu gefährlich ist. Daher kann man heute VR allenfalls als modellhafte Darstellung oder Nachbildung einzelner Aspekte eines bereits vorhandenen oder noch zu entwickelnden kybernetischen Systems ansehen.

VR wird heute in der Praxis eingesetzt beispielsweise in der Fahrzeugentwick-lung zu Design-Studien, um verschiedene Alternativen wirklichkeitsnah persön-lich beurteilen zu können, die Fahrzeugkonstruktion auf Montage- und Demontage-Gerechtheit hin zu untersuchen, oder zu Simulationen in der Luft- und Raumfahrt, um den Aufwand für sehr kostspielige und gefährliche Erprobungen zu sparen. Allerdings sei an dieser Stelle nicht verschwiegen, dass VR in einem sehr großen Umfang Daten benötigt und erzeugt und dazu in der Regel besondere und kost-spielige Hardware benötigt wird.

Eine erste Voraussetzung ist die Erzeugung realitätsnaher Darstellungen der be-trachteten Produkte. Hierzu werden 3D-Daten um ihre optischen Darstellungspa-rameter erweitert und in einer Umgebung entsprechend den definierten Licht-verhältnissen dargestellt. Abb. 69 illustriert an zwei Beispielen die Möglichkeiten dieser photorealistischen Darstellung als erste Stufe einer virtuellen Darstellung und gibt damit auch einen Eindruck von der Komplexität.

Allerdings beschränkt sich die Darstellung nicht auf das Berechnen eines Bil-des für ein Produkt. Abb. 70 zeigt einen virtuellen Kontrollraum und gibt damit bereits in der Planungsphase einen realistischen Eindruck. Durch dieses Modell kann mit den oben genannten Technologien navigiert und interagiert werden.

Wird nun die virtuelle Realität mit der „echten“ Realität in Echtzeit verknüpft, so spricht man Augmented Reality (AR) oder Erweiterter Wirklichkeit. Dabei werden hauptsächlich visuelle Eindrücke miteinander verknüpft. Kennzeichnend für Augmented Reality sind dreidimensionale Darstellungen, mit denen in Echtzeit interagiert werden kann. Dabei ist die Interaktion nicht nur auf menschliche Sin-neswahrnehmungen beschränkt, sondern umfasst ebenfalls sensorisch erfassbare Eigenschaften wie Radar oder Infrarot.

Virtuelle Realität (VR) 137

Abb. 69. Rendering (Quelle: Lehrstuhl für Konstruktionstechnik/CAD, Universität des Saarlandes)

Abb. 70. Virtuelle Darstellung eines Kontrollzentrums (Quelle: Epro Software GmbH)

Bekannte Beispiele für eine AR-Anwendung sind, obgleich teilweise die Interak-tivität im engen Sinne fehlt, die in Echtzeit eingeblendeten virtuellen Marken bei Sportübertragungen: Verschiedene Entfernungen der Konkurrenten beim Ski-Springen, Überblendungen beim Eisschnelllaufen oder Formel 1 usw. Anwendun-gen für AR finden sich in vielen, auch alltäglichen Bereichen. Weitere Anwen-dungen sind beispielsweise:

Katastrophenmanagement, Hydrologie, Ökologie, Geologie zur Darstellung und interaktive Analyse von Karten und Geländemerkmalen, z. B. zur Aus-beutung von Bodenschätzen oder Vorhersage von Folgen eines Naturereig-nisses


Medizin zur Einblendung von nicht sichtbaren Körperteilen Simulation komplexer Aufgaben, z. B. zum Training von Monteuren oder Astronauten Wartung, Instandhaltung und Reparaturen (insbesondere bei komplexen Anlagen) (Video-) Konferenzen mit realen und virtuellen Teilnehmern Darstellung zerstörter historischer Gebäude Spiele

An dieser Stelle dürfen die mit VR und AR verbundenen Probleme nicht ver-schwiegen werden.

Performance: Nachführung der Bilder bei Bewegungen benötigt sehr viel Rechenleistung.Energieversorgung: Die momentan verfügbaren Akkus reichen noch nicht aus um AR-Systeme über eine längere Zeit hinweg autonom zu versorgen. Sensor: Rauschen bei Bewegung, Drift oder Abschattung des Tracking-systems (z. B. bei GPS) sind als Nebeneffekte sehr schwer online zu be-rechnen. Daten: Die Verfügbarkeit und hohe Komplexität der Daten bedingt an-spruchsvolle Hardware und sehr ausgefeilte Algorithmen. Visualisierung: Um die Einbettung der virtuellen Szene in die reale Szene möglichst überzeugend zu leisten, sind Daten notwendig, die die Umge-bung auch in ihrer Geometrie beschreiben. Darauf aufbauend können dann virtuelle Schnitte durch reale Objekte gezeichnet werden und die Verde-ckung der virtuellen Objekte durch die realen Objekte berechnet werden. Diese Geometriedaten sind jedoch nicht immer verfügbar oder aktuell. Benutzerschnittstelle: Insbesondere bei mobilen Anwendungen, zum Bei-spiel für Außenanwendungen, ist die Eingabe von Information durch Tasta-tur und Menüsteuerung durch Maus umständlich. Ergonomie: Die bisherigen Systeme sind noch relativ schwer.

Diese virtuelle und erweiterte Welt wird durch die Anbindung an lokale und globale Netzwerke unter Nutzung der Mittel und Techniken der Telekommunikation zum „Cyberspace“, in dem auch mehrere Personen miteinander interagieren können.

7.7 Zusammenfassung

Neue Technologien, wie Simultaneous Engineering, Digital Mockup oder Virtual Reality sind ideale Ergänzungen zu den heute eingeführten PLM-Prozessen. Sie ermöglichen das Vor-Denken und Vor-Simulieren neuer Lösungen und integrieren

Zusammenfassung 139

dabei Techniker und Nicht-Techniker. Die Grundlagen dieser Technologien sind neben geeigneten Anwendungsszenarien

abgestimmte PLM-Prozesse konsistente Produkt-Datenstrukturen digitale Daten für den jeweiligen Anwendungsfall definierte Prozess- und Daten-Schnittstellen kompetente Mitarbeiter

Diese Technologien selbst erfordern eigene Prozesse und Schnittstellen. Ihre Ein-bettung in konventionelle PLM-Prozesse und PLM-Architekturen fällt teilweise schwer, weil sie neue Paradigmen darstellen und daher auch neue Prozesse erfor-dern. Diese neuen Prozesse wiederum erfordern neue Softwarebausteine und Schnittstellen zur Implementierung.

Von diesem Standpunkt aus beginnt der in Abschnitt 3.1 aufgezeigte PLM-Regelkreis von neuem. Eine neue Strategie wie der Einsatz derartiger Technolo-gien zur Optimierung eines Unternehmens auf der Basis der Ergebnisse eines Pro-zess-Controllings bedingt ihrerseits neue Prozesse, die wiederum neue Implementierungen zur Unterstützung dieser Prozesse nach sich ziehen.

8 Zukünftige Strategien von PLM

Wie wir bis hierher gesehen haben, umfasst der Begriff PLM den gesamten Lebenszyklus von Produkten und das mit geringen Abweichungen oder Aus-prägungen in allen Branchen. Dennoch sollte man immer den Begriff „Pro-dukt“ im Fokus behalten, allerdings spielt es hierbei keine Rolle, ob wir von Serienprodukten oder Einzelfertigungen reden, es spielt auch keine Rolle, wo diese Fertigung örtlich angesiedelt ist. Um die zukünftigen Strategien zu be-trachten, müssen wir uns den Phasen der Produktentstehung, der Produktferti-gung, der Anwendung oder Benutzung sowie der Entsorgung etwas genauer widmen.

Produkt-entstehung

Produkt-fertigung

Produkt-entsorgung

Abb. 71. Phasen von Produktentstehung bis Produktentsorgung

Heute werden mit PLM-Systemen in erster Linie Dokumente, Strukturen und Prozesse verwaltet und reproduzierbar offen gelegt. Zur Unterstützung der Pro-zesse spielt der Begriff Workflow auch heute schon eine wesentliche Rolle und wird von den meisten Systemanbietern „als Wunderwaffe“ der Automatisierung für Geschäftsprozesse herangezogen. Für Prozesse wie Freigabeprozess oder Änderungsprozess eine wirklich nützliche Erfindung, aber für den Enginee-ringprozess in der frühen Phase der Produktentstehung sind Workflows, zu deutsch auch Arbeitsabläufe genannt, eher hinderlich.


8.1 Produktentstehung

„Deutschland braucht Innovationen“ ist einer der meisten Aussprüche unserer Manager und Politiker. Innovation braucht aber Freiheit und Kreativität, die in keinen Zwangsprozess oder Workflow zu zwängen ist. Innovation und Kreativität braucht verlässliche Daten, Informationen und technologische Zusammenhänge, die heute in den Köpfen der Mitarbeiter „zwischengelagert“ werden und je nach Tagesform der Entwickler neuer Produkte abgerufen werden. Bei immer komple-xeren Produkten und vielen existierenden Rahmenbedingungen und Seiteneffekten ein kaum beherrschbares Betätigungsfeld. Hier liegt eine der zukünftigen Anfor-derungen an PLM-Systeme: Die Speicherung von Wissen und deren Relationen. Was gemeinhin unter dem Begriff „Wissensmanagement“ bekannt ist, ist heute noch eher ein Forschungsgebiet mit dem Begriff „Knowledge Based Enginee-ring“. Hier steht die PLM-Gemeinde noch ganz am Anfang ihrer Entwicklung. Ob sich diese Investition lohnt? Ja mit Sicherheit, aber den Nutzen hiervon werden erst Ingenieure der nächsten Generation zu schätzen wissen.

Ein weiteres Betätigungsfeld von PLM-Strategien liegt im Umfeld von Colla-boration-Szenarien. Heute scheitern diese Prozesse in der Regel an physikalischen Grenzen (Netzwerken), veralteten Datenmodellen oder Sicherheitsaspekten. In der Regel ist es nicht ein Kriterium, sondern meistens von jedem etwas. Während die physikalischen Grenzen sicherlich in überschaubarer Zeit behoben werden kön-nen, ist der Sicherheitsaspekt kaum zu beherrschen. Heute werden Milliarden von Euro ausgegeben, um die Sicherheit globaler Netze wie dem Internet sicherzustel-len. Allerdings ist die kriminelle Energie einiger weniger ebenso hoch einzu-schätzen. Somit werden heute sensible Daten (Konstruktionen, Berechnungen, patentwürdige Entwürfe) selten an verteilten Standorten gehalten oder gar bearbei-tet. Welch ein Verlust an Innovation. Dieses zu beiseitigen ist eine der größten Herausforderungen, die sich im Zusammenhang mit PLM-Strategien in Zukunft stellen. Denn schon heute träumen die Unternehmen nach der ersten Globalisie-rungswelle von „Cross Enterprise Collaboration“.

Cross Enterprise Collaboration ist die zwangsläufige Erweiterung der Enginee-ring-Methoden, die sich aus den dramatischen Veränderungen des Engineering-Prozesses in den letzten 20 Jahren ergibt. PLM ist ein wesentlicher Beitrag, Cross Enterprise Engineering als IT-Lösung umzusetzen und zu administrieren. Der Ingenieur wird in die Lage versetzt, Informationen aus internen und externen Informationsquellen zusammenzustellen. Diese Art der Informationsbeschaffung verbessert den notwendigen Analyse- und Entscheidungsprozess des Ingenieurs.

Auch in diesem Fall ist der Nutzen unumstritten: Egal wo und wer in einem PLM-Prozess beteiligt ist, kann immer auf aktuelle und vollständige Daten und Informationen zugreifen und zum Produktlebenszyklus beitragen. Doch welche Dimension nimmt diese Vision an, wenn wir es mit unserer ersten These dem „Wissensmanagement“ verknüpfen? Undenkbar, wenn hier der Sicherheitsaspekt nicht berücksichtigt würde.

Produktfertigung 143

Entwickler

Collaboration-Plattform

System Vertrieb

PDM-System

Lieferant

PDM-System

Lieferant

ohne PDM-System

OEM

PDM-System 1

Standort A

PDM-System 3

Standort B

PDM-System n

Standort N

Abb. 72. PLM als Collaboration-Plattform

8.2 Produktfertigung

Der nächste Prozessschritt geht davon aus, dass alle Informationen und Daten zur Fertigung eines Produktes vorliegen. Hierbei spielt es auch eine unterge-ordnete Rolle, ob wir von Serienfertigung oder Einzelfertigung reden, lediglich die Ausprägung von Vorbereitungen, Qualitätssicherungen und detaillierter Planung (logistisch) sind unterschiedlich. Aber das sind nicht die wesentlichen Punkte bei der Betrachtung von PLM-Strategien, da diese Prozesse in den meisten Unternehmen schon seit Jahren mehr oder weniger gut beherrscht wer-den. Aber hier liegen schon die Chancen von PLM-Systemen: Die Planung von Fertigungsprozessen muss wesentlich früher beginnen, schon in der Produkt-entstehungsphase und nicht erst nach der Erstellung aller Unterlagen. Nur so kann man sicherstellen, dass schon in der frühen Phase der Entwicklung die Produktionskosten kalkuliert und produktionstechnische Änderungen rechtzei-tig berücksichtigt werden. In dieser zugegeben verkürzten Darstellung steckt eine wesentliche Anforderung an PLM-Systeme: Produktdatenintegration und zwar unabhängig vom Erzeugersystem und interner oder externen Daten bzw. Informationen. Auch an dieser Stelle sei wieder der Hinweis auf These 1 er-laubt: Diese Anforderung gepaart mit Wissensmanagement ist eine sehr kom-plexe Herausforderung. Denn die „Erfahrungen“ aus den Produktionsprozessen müssen wieder in den Produktentstehungsprozess zurückfließen und diesen Prozess maßgeblich beeinflussen, um einmal gemachte Fehler nicht zu wieder-holen. Nur so wird die Wertschöpfungskette in Entwicklung und Fertigung op-timiert.


Abb. 73. PDM Collaborator Approach

8.3 Produktentsorgung

Bis der Prozessschritt „Entsorgung“ eintritt, wird der Lebenszyklus eines Produk-tes von unterstützenden PLM-Prozessen wie Service bzw. Wartung begleitet. Ein Schwerpunktthema in diesem Umfeld wird auch noch die nächsten Jahre bestim-mend sein: Mobil Maintenance.

Serviceverträge, technische Beschreibungen, Ersatzteilkataloge, Ersatzteilbestel-lungen, Fehleranalyse bis hin zur Servicerechnung soll alles „mobil“, d. h. direkt vor Ort abrufbar oder pflegbar werden. So werden lückenlose Serviceberichte zu jedem Produkt und an jedem Ort möglich, die wiederum das „Wissensmanage-ment“ der PLM-Systeme um wertvolle Informationen anreichern.

Wird im Rahmen einer Serviceleistung erkannt, dass der Lebenszyklus beendet werden muss, so wird mit der Entsorgung des Produktes begonnen. Immer um-fangreichere gesetzliche Vorschriften, Umweltauflagen und Sicherheitsrichtlinienerfordern ein gezieltes Projektmanagement zur Entsorgung eines Produktes. Hier-bei ist es natürlich nicht ganz unerheblich, um welches „Produkt“ es sich handelt. Ein Kernreaktor stellt hierbei sicherlich höhere Anforderungen als ein Autoreifen. Doch in beiden Fällen sind entsprechende Nachweise aus Herstellung und Betrieb erforderlich, um ein Umwelt- und Sicherheitsrisiko bei der Entsorgung auszu-schließen.

PLM-Systeme werden in Zukunft aus diesem Grunde noch stärker zur Wis-sensdrehscheibe im gesamten Unternehmen werden. Werkstoffdatenbanken kom-biniert mit Wissensmanagement und Dokumentenarchiven bilden dann die Grundlage für eine gesicherte Entsorgung von Produkten.

Teil IIFallstudien aus der Fertigungsindustrie

9 PLM in der Schaeffler-Gruppe

Momme Stürken

In dieser Fallstudie erläutert der Autor die bisher erreichten Ergebnisse des PLM-Projektes in der Schaeffler-Gruppe und gibt einen Ausblick auf die nächsten Pro-jektschritte. Im Vordergrund stehen die Themen des Produktdatenmanagements, insbesondere Zeichnungs- und Modellverwaltung mittels einer CAD-Integration.

9.1 Überblick und Projektziele

Der Einsatz von SAP PLM führt in der gesamten Schaeffler-Gruppe zu einer ver-änderten Arbeitsweise beim Konstruktionsdatenmanagement. Künftig sollen die hier erzeugten Stamm- und Strukturdaten nicht nur Basis für den Konstrukteur oder Anwendungstechniker und deren Abläufe sein, sondern auch die Informa-tionsgrundlage für Kollegen aus Einkauf, Arbeitsvorbereitung, Qualitätssicherung, Vertrieb etc. bilden.

Zunächst konzentrierten sich die PLM-Bemühungen in der INA-Schaeffler KG darauf, das Erstellen der Angebots- und Auftragsunterlagen, die (zeitliche) Gültig-keitssteuerung der konstruktiven Grunddaten sowie den Prozess ihrer Bearbeitung

Sachstamm Sachmerk-malsuche

Zeichnung

I STÜCKLISTE BAUKAST. Sach-Nr 006-723-080 Var 0000 Seite 1 I N A Artbez HK F-234612 Datum 29.05.00 12:21

A Abmess 16X22X12 Anstoß Marschall KONSTRUKTION Status => 63/011100/028

---------------------------------------------------------------------------------------------------------------------------------------Ktr Teilefamilienschlüssel Pp Änd.Buchstabe Dissl Werk/Segment06000 000050 C 028 63/011100

---------------------------------------------------------------------------------------------------------------------------------------Wk/Sg Artikelbezeichnung Al Ab Sach-Nr Abmessung Var Mat-F St-Menge Bemerkung Tot Pos

63/011900 H F-234612-11 006-764-940 20X22X13,3 0000 1 ST 001 K63/011900 K HK 1612-52 001-063-928 16X20X9,93 0000 1 ST 002 K03/010800 NRB 2 X 7,3 G2 000-163-422 2X7,3 0000 18 ST 003 K60/000000 FETT 005-442-729 0000 0.4 G 030 K

-SYNTHESO-PRO-AA-2-K- FA. KLUEBER ---------------------------------------------------------------------------------------------------------------------------------------

Nr I Aemnr Stücklistenänderungstexte Aegr Vw Datum ---------------------------------------------------------------------------------------------------------------------------------------

001 A 0 HINZU PO30 FETT 0,4G 22 02 2000-05-29

I STÜCKLISTE BAUKAST. Sach-Nr 006-723-080 Var 0000 Seite 1 I N A Artbez HK F-234612 Datum 29.05.00 12:21

A Abmess 16X22X12 Anstoß Marschall KONSTRUKTION Status => 63/011100/028

---------------------------------------------------------------------------------------------------------------------------------------Ktr Teilefamilienschlüssel Pp Änd.Buchstabe Dissl Werk/Segment06000 000050 C 028 63/011100

---------------------------------------------------------------------------------------------------------------------------------------Wk/Sg Artikelbezeichnung Al Ab Sach-Nr Abmessung Var Mat-F St-Menge Bemerkung Tot Pos

63/011900 H F-234612-11 006-764-940 20X22X13,3 0000 1 ST 001 K63/011900 K HK 1612-52 001-063-928 16X20X9,93 0000 1 ST 002 K03/010800 NRB 2 X 7,3 G2 000-163-422 2X7,3 0000 18 ST 003 K60/000000 FETT 005-442-729 0000 0.4 G 030 K

-SYNTHESO-PRO-AA-2-K- FA. KLUEBER ---------------------------------------------------------------------------------------------------------------------------------------

Nr I Aemnr Stücklistenänderungstexte Aegr Vw Datum ---------------------------------------------------------------------------------------------------------------------------------------

001 A 0 HINZU PO30 FETT 0,4G 22 02 2000-05-29

Stückliste

Änderungsantrag-/Mitteilung

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


Materialstamm-verwaltung

Änderungsdienst

Konfigurationen

Projektsystem

Änderungs -dienst

Dokumenten-verwaltung

Dokumenten-verwaltung

Klassen-system

CAD-Schnittstelle

Stücklisten-verwaltung

SAP PLMSAP PLM

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 Systemviel-falt und Medienbrüche zu erreichen. Die konstruktive Beschreibung der Erzeug-nisse 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 Vereinheitli-chungsbemü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 Bau-gruppen 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 Schaeffler-Gruppe 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 ge-samten Logistikkette. Pro/Intralink wird also nur noch als Modellaufbewahrungs-system genutzt, die Prozesshandhabung findet komplett in SAP PLM statt. In den Konstruktionsabteilungen selbst führt diese Lösung, die in der gesamten Schaeffler-Gruppe eingesetzt wird, zu der gewünschten weltweit einheitlichen Anlage, Ände-rung, Freigabe von CAD-Zeichnungen und -Modellen sowie zur eindeutigen Zu-ordnung 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 Anwendun-gen referenziert (wie z. B. Arbeitsplan oder Bestellanforderung), so dass dieser Stammsatz den Grundbaustein für alle logistischen Prozesse im Unternehmen so-wie 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 Änderungs-informationen (siehe auch Abb. 76). Um dieser Bedeutung gerecht zu werden, gilt neuerdings eine Freigabesteuerung, nach der nur ein Produktgruppenverant-wortlicher 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 umfas-senden Ä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 produktbezoge-nen 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 Initia-tive von INA programmiert. Er ermöglicht eine komfortable Bearbeitung von CAD-Dokumentstrukturen im SAP-System. Insbesondere Zusammenhänge zwi-schen 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 Do-kumentinformationen, wie Status, Sachbearbeiter, Format, Materialverknüpfungen etc., anzuzeigen. Zudem bietet der CAD-Desktop einen direkten Zugriff auf die wichtigsten Verwaltungsbefehle und unterstützt Massenbearbeitungsfunktionen


Materialstamm500000042-0000F-550002 KIPHStatus: „F“

Materialstamm500000042-0000F-550002 KIPHStatus: „F“

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

Konstruktions-Stückliste500000042-0000 (2)Konstruktions-Stückliste500000042-0000 (2)

DokumenteninfoSatzEDD F-550002 A00 ABStatus: FreigegebenGültig: 1.12.04 bis ...Änderungsnr: 22

DokumenteninfoSatzEDD F-550002 A00 ABStatus: FreigegebenGültig: 1.12.04 bis ...Änderungsnr: 22

Änderungsstamm22

F-550002 /EDB/A00/ABStatus: AbgeschlossenGültig ab: 1.12.04

Änderungsstamm22

F-550002 /EDB/A00/ABStatus: AbgeschlossenGültig ab: 1.12.04

NetzplanRückmeldung: Aktualisierung derTermindaten (Änderungsnr. 22)

NetzplanRückmeldung: Aktualisierung derTermindaten (Änderungsnr. 22)

Objekt-verknüpfung

Projektstrukturplan-Element

Position desSalesDistribution-Beleg‘sPosition desSalesDistribution-Beleg‘s

Materialstamm500000042-0000-10F-550002 KIPH#vStatus: „F“

Materialstamm500000042-0000-10F-550002 KIPH#vStatus: „F“

Freigabe

OriginalOriginal

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

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

9.3 Ausblick

Wie geht es nun in der Zukunft weiter? Die zurzeit laufenden Weiterentwicklun-gen 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 Prozessvereinheitli-chung im gesamten Konzern. Im kommenden Jahr steht der Roll-Out des kon-zernweiten 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 An-strengungen, im Tagesgeschäft komfortable Arbeitsweisen für den Konstrukteur sicherzustellen. Jüngste Fortschritte im CAD-Desktop sind hier etwa die Schreib-tischfunktionalitä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 Ver-such 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 Engi-neering 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 Produktvarianten-management bei einem Serienfertiger

Diese Fallstudie stellt ein Projekt zur Einführung eines Komplexitäts- und Varian-tenmanagements in der Investitionsgüterindustrie vor. Es wird geschildert, wie durch Beherrschung der Produktkomplexität, Reengineering der damit verbunde-nen Prozesse in Kombination mit einer Lösung zur Variantenkonfiguration erheb-liche 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 Nie-derlassungen und Partnern in über 50 Ländern vertreten. Das mittelständische Tradi-tionsunternehmen 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 innova-tive 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 ver-zeichnen, d. h. die Produktvariantenanzahl stieg überproportional zur verkauften Bauteilstückzahl. Diese Situation stellte an die Unternehmensprozesse (z. B. Än-derungsmanagement, Logistik, integrierte Auftragsabwicklung etc.) besondere Anforderungen. Erfahrungswerte zeigen, dass mit jeder Verdopplung der Varianten-anzahl die Prozesskosten ca. 20-30 % steigen. Um das größtmögliche Varianten-

154 Komplexitäts- und Produktvariantenmanagement bei einem Serienfertiger

Vielfaltim Produkt und

der logistischen

Leistung

Unternehmenspotenzial

- techn. Fähigkeiten und

betriebliche Ressourcen

Marktbedingungen

- Kundenanforderungen

- Konkurrenzsituation

Unternehmensstrategie

- Produktpolitik/-Portfolio

- Marktpositionierung/

Marktdurchdringung

Extern

- Marktposition

- Umsatz

Intern

- Leistungsfähigkeit

- Unternehmens-

komplexität

Zukünftig

- Kundenbindung

- Marktanteil

- Reputation, Image

Varianten-

management

Varianten-

vermeidung

Varianten-

beherrschung

Varianten-

reduzierung

Abb. 77. Ausgangssituation und Zielsetzung

potenzial (Verhältnis zwischen Variantenkosten zu Variantennutzen) realisieren zu können, war die Einführung eines Komplexitäts- und Produktvariantenma-nagements als Bestandteil eines ganzheitlichen Product Lifecycle Management erforderlich.

Abb. 78 zeigt das Variantenoptimierungsportfolio in Form eines ABC/XYZ-Diagramms. Auf Basis einer Datenanalyse wurde nachgewiesen, dass sehr viele hochwertige und aktive Produktvarianten mit einer sehr unregelmäßigen Bedarfs-situation vorhanden waren. Zeigt man die Zusammenhänge zwischen den Pro-duktvarianten 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 (Plattformstra-tegie) zu erhöhen.

10.2 Ziele des PLM-Einsatzes

Das einzuführende Komplexitäts- und Produktvariantenmanagement sollte im Un-ternehmen folgende Ziele realisieren:

Ziele des PLM-Einsatzes 155

Variantenoptimierungsportfolio

Pro

dukt

wer

tigke

it

Bedarfsvarianz

Variantenoptimierungsportfolio

Pro

dukt

wer

tigke

it

BedarfsvarianzAbb. 78. Auswirkung von Varianten auf die Logistikprozesse

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


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

10.3 Vorgehensweise im Projekt

Der Projekterfolg zur nachhaltigen Reduzierung der Produktvarianz ohne wesent-liche Reduzierung der Auftragsvarianz konnte nur durch eine ganzheitliche Be-trachtung aller Prozesse des Komplexitätsmanagements erreicht werden.

Strategie zurVarianten-

beherrschung

Produkt-strukturierung

Markt-Wettbewerbsanalyse

Varianten-management

IntegrierteAuftragsabwicklung

Controlling

Strategie zurVarianten-

beherrschung

Produkt-strukturierung

Markt-Wettbewerbsanalyse

Varianten-management

IntegrierteAuftragsabwicklung

Controlling

Abb. 79. Ganzheitliches und integriertes Komplexitätsmanagement

Vorgehensweise im Projekt 157

Ausgehend von den Unternehmenszielen wurde mit Hilfe von Markt- und Wett-bewerbsanalysen 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 funktiona-len Eigenschaft der Maschine (z. B. Realisierung einer bestimmten Maschinen-Leistungskennlinie) lag, bestellt wurde jedoch die technische Produkteigenschaft (z. B. bestimmter Elektromotor eines Herstellers). Hier war der Vertrieb durch Bera-tungsleistung besonders gefordert. D. h. der Kunde musste von den Leistungspara-metern der Maschine überzeugt werden und nicht von den einzelnen Maschinen-Komponenten.

Daraus abgeleitet ergab sich in der Unternehmensführung eine Strategie zur Va-riantenbeherrschung (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 interdis-ziplinär definiert und konsequent durch ein entsprechendes Organisationskonzept zur Umsetzung gebracht. Das Variantenmanagement hatte dabei als zentrale Aufgabe die Produktkomplexität

zu reduzieren (z. B. Standardisierung von Baukästen), zu vermeiden (z. B. Modulkonzepte etablieren) undzu managen (z. B. integriertes Änderungsmanagement).

Produkt-

klassifizierungVarianten-

optimierung

Stücklisten-

optimierung

Produkt-

konfiguration

Abb. 80. Komplexitätsreduzierung


Bereinigung derMerkmalsausprägungenführt zur Reduzierung derVarianz

Abb. 81. Merkmalvariantenbaum

Im Rahmen einer kontinuierlichen Variantenanalyse wurden die Produkte (Pro-duktfunktionen und Produktstrukturen), Prozesse (Variantenprozesse) und Kosten (Prozesskosten) analysiert und optimiert. Dabei wurden mit einem Product-Lifecycle-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 Kon-figurationslösung in eine integrierte Auftragsabwicklung überführt. Dieser Ge-schäftsprozess wurde gemäß den Vorgaben des Variantenmanagements im Sinne eines Business Process Reengineerings neu gestaltet. Dabei wurde das Produkt-spektrum überarbeitet, in drei Klassen eingruppiert und entsprechende Logistik- und Product-Lifecycle-Management-Prozesse definiert:

Gruppe A (A-Anlagen): Bei A-Anlagen handelt es sich um Standard-Fertigprodukte, die jeweils kun-denauftragsanonym produziert (make-to-stock) werden und in der Regel im Lager zum sofortigen Verkauf bereitstehen. Gruppe B (B-Anlagen): B-Anlagen sind klassische Standard-Produktvarianten, die im Auftragsfall konfiguriert und danach kundenspezifisch montiert werden (assemble-to-

Projektfazit 159

A-Anlagen =

Lageranlagen

B-Anlagen =

Varianten

C-

Anlagen

A-Anlagen: Lageranlagen (anonyme Fertigung mit Materialnummer)

B-Anlagen: Varianten (in Kundeneinzelfertigung montiert)

C-Anlagen: Kundenspezif. Sonderanlagen (Auftragskonstr., Kundeneinzelfert.)

C-

Anlagen

A-Anlagen =

Lageranlagen

A-Anlagen =

Lageranlagen

B-Anlagen =

Varianten

C-

Anlagen

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“

C-

Anlagen

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 ver-zichtet werden kann.

Gruppe C (C-Anlagen): Bei C-Anlagen handelt es sich um Sondermaschinen, die im Auftragsfall kundenspezifisch entwickelt wurden (Engineer-to-order). Diese Sonderan-lagen 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 Product-Lifecycle-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


Abb. 83. Vorgehensmodell Variantenmanagement im ARIS-Scout

Reorganisation der Logistikstruktur und eine Erhöhung des Servicegrades nach-weislich erzielt werden. Die Komplexität der Produkte zu reduzieren ist dement-sprechend einer der besten Hebel beim Streben nach einfachen und leistungs-fähigen Prozessen.

Das eingesetzte Product-Lifecycle-Management-System hat hierbei einen we-sentlichen 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 we-sentlichen Erfolgen:

Während der Personalaufwand für die Angebots- und Auftragsabwicklung mit Einsatz des Variantenkonfigurators um ca. 30 % reduziert wurde, konn-te darüber hinaus die Durchlaufzeit von der Auftragsanlage bis zur Produk-tionsfreigabe um mehr als 50% verkürzt werden. Reduktion des Personalaufwandes in der Konstruktion um ca. 15% bei der Pflege von Produktstrukturen. Nach einer Reorganisation der Produktstruktur wurde die Anzahl der Konfigurationsmerkmale um 40% reduziert, die Anzahl der Materialien um ca. 30%. Mit ca. 30 konfigurierbaren Materialien werden zurzeit mehr als 60% des Umsatzes realisiert. Durch die Priorisierung und Fokussierung auf ertragreiche Produkte wur-den die Durchlaufzeiten über die gesamte Logistikkette verkürzt – von der

Projektfazit 161

Beschaffung über die Fertigung bis zum Versand – und die Planungsgenau-igkeit erhöht. Dies führte zu einer Reduktion der Bestände an Schnell-dreherprodukten 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. € er-wirtschaftet.

Im Fokus des Projektes stand die Verringerung der Störfaktoren in Zusammen-arbeit 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.


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 Ausstat-tungsvarianten angeboten. In Abhängigkeit von der Ausprägung des mit den An-lagen zu produzierenden Endprodukts entstehen zwangsläufig Varianzen, die nahezu alle Funktionsbaugruppen der Maschine betreffen. Zusätzlich werden auf-tragsspezifisch 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, auf-tragsübergreifende und auftragsunabhängige Prozesse. Auftragsspezifisch arbeiten die Auftragsklärung, ein Teil der Konstruktion/Entwicklung, die Montage und die Auftragsabwicklung. In Programmplanung, Produktionsplanung, Fertigung, Ein-kauf und Bevorratung laufen die Anforderungen aus allen Aufträgen zusammen.

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 Umset-zung der Ergebnisse erfolgt durch die Konstruktion. Nach erfolgreicher Er-probung werden die Neuerungen in das Standardprogramm aufgenommen. Die notwendigen Anpassungen an den Produktstammdaten führen dabei


Auftragsklärung

auftragsspezifisch

Grundlagen-entwicklung

auftragsübergreifend

KonstruktionEntwicklung

auftragsspezifisch

Fertigung


Montage

auftragsspezifisch

Auftrags-abwicklung

auftragsspezifisch

Bevorratung


Einkauf


Programmplanung


Produktions-planung


Abb. 84. Prozesslandschaft Anlagengeschäft

teilweise zu – aus technischer Sicht unnötigen – Varianten, da durch das Auf-tragsmanagement technisch identische Maschinen vor und nach dem Ände-rungstermin aufgelegt werden. Die eigentlich als Änderung durchführbare Modernisierung wird damit zu einer zusätzlichen Produktvariante, da sie pa-rallel zu der vorherigen Ausführung im System geführt werden muss.

Programmplanung Im Rahmen der Programmplanung werden unter Betrachtung vorhandener und erwarteter Aufträge auf Basis des Maschinentyps Teileumfänge zu ra-tionell zu fertigenden Losgrößen zusammengefasst und durch die Produkti-onsplanung vordisponiert. Die so erzeugten Bedarfe laufen entsprechend der Planung in den Beschaffungs- und den Fertigungsprozess ein und füh-ren zur Bevorratung von Baugruppen und Teilen.

Aus jedem Auftrag ergeben sich abhängig von der Maschinengrundvari-ante und von Vorstellungen des Kunden spezielle Anforderungen, die in der Umsetzung innerhalb eines meist sehr engen Zeitrahmens zur Entwick-lung von individuellen Sonderlösungen führen. Die entstehenden Produkt-varianzen 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ßer-planmäßig nachgearbeitet werden.

Die dem Angebot zugrunde liegende Vorkalkulation auf Basis der Pla-nung weicht dadurch oftmals entscheidend von den Erzeugungskosten ab.

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 Ab-stimmungsprozessen.


Konstruktion/Entwicklung Die Verantwortung für die notwendigen konstruktiven Anpassungen liegt bei den für die Bearbeitung eines Funktionsmoduls spezialisierten Fachab-teilungen. Diese Abteilungen sind gleichfalls für die Umsetzung der Neue-rungen aus der Grundlagenentwicklung zuständig. Die Einarbeitung von Modernisierungsmaßnahmen erfolgt oftmals im Rahmen der auftrags-spezifischen Anpassungen.

Die Konstruktion der mechanischen und elektrischen Baugruppen und die Erstellung der technischen Dokumentation erfolgt überwiegend CAD-gestützt. Fertigungsunterlagen und Dokumentation werden in einer jeweils eigenen Datenbankumgebung (PDM-System) verwaltet.

Die Produktstruktur ist für die Bearbeitung von Konstruktionsaufga-ben „am Brett“ ausgelegt. Unterschiedliche Ausführungen einer Bau-gruppe werden als Varianten geführt. Gleichteile in den Varianten sind nicht durchgehend als solche gekennzeichnet und sind innerhalb der kon-tinuierlich wachsenden Anzahl ähnlicher Baugruppen nur schwer auszu-machen.

Stammdaten / Produktdokumentation Die Stammdatenerfassung erfolgt durch eine zentrale Stelle, die von den Konstruktionsabteilungen in Papierform mit den erforderlichen Informatio-nen versorgt wird. Diese Funktion („Normenstelle“) ist gleichermaßen für die Kontrolle der Fertigungsunterlagen, deren Freigabe zur Veröffentli-chung 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 Ersatzteilkata-logen aus Einzelteilzeichnungen aufgebaut. Es existiert keine zentrale Vor-gabe für die Erstellung und Verwaltung von Konstruktions-/Entwurfs-zeichnungen.


Nach der länger zurückliegenden Einführung des SAP R/3 mit den Modulen FI (Fi-nance), CO (Controlling), MM (Materialmanagement), PP (Produktionsplanung) sowie SD (Sales and Delivery) im SAP Release 3.0f wird ein Projekt zur Umstel-lung auf das aktuelle SAP Release gestartet.

Neben der technischen Umstellung soll in diesem Projekt die Verzahnung der Produktentwicklung mit den Prozessen Produktion / Produktionsplanung und Be-schaffung / Beschaffungsplanung optimiert werden.

Als Projektziele werden definiert:


Verringerung des Klärungs- und Entwicklungsaufwands in der Konstruktion

Anpassung der Baugruppenstruktur an die veränderten operativen Belange durch den Einsatz von CAD-Systemen Reduzierung der Baugruppen auf die ‚lebenden’ Varianten Vermehrter Einsatz von Wiederholteilen

Erhöhung der Planungssicherheit

Reduzierung von Änderungen an laufenden Aufträgen und bereits dispo-nierten Komponenten Transparente Kennzeichnung von vorzuplanenden und vorplanbaren Teilen Optimierung der Auslastung von Montage und Fertigung durch vorgezoge-ne Herstellung und Bevorratung von Standardteilen Reduzierung der Fertigungs- und Beschaffungskosten durch Bündelung von Aufträgen

Verringerung der Auftragsdurchlaufzeit

Der Prozess der Auftragsklärung soll beschleunigt werden, um notwendige Anpassungen an bestehenden Konstruktionen und notwendige Entwicklun-gen früher bestimmen zu können Die Disposition soll beschleunigt werden um die Vorlaufzeiten der Ferti-gung zu maximieren Die Bereitstellungszeit für aktuelle Fertigungsunterlagen soll reduziert werden Durch Bevorratung von Standard-Baugruppen und Fertigungsteilen wird der Umfang der auftragsabhängigen Komponenten auf das technisch not-wendige 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 abge-grenzt 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ätssicherungssys-tem 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 pro-zessorientierte Projektorganisation mit vier Prozessteams eingerichtet: Prozessteam Entwicklung / Prozessteam Fertigung / Prozessteam Planung / Prozessteam Be-schaffung.

Die Projektleitung und Steuerung erfolgt durch ein übergreifendes Lenkungs-gremium 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, Ände-rungsdienst und Variantenmanagement werden aus den Mitarbeitern der Prozess-teams Arbeitsgruppen gebildet.

ProzessteamEntwicklung

ProzessteamBeschaffung

MAEntwicklung - M

MAArbeitsvorber.

ArbeitsgruppeProduktstruktur

MA oper.Einkauf MA Vorplanung

MA Feinplanung

MA Disposition

MASoftware-Entw.

MAFertigungsst...

ProzessteamPlanung

ProzessteamFertigung

MA Disposition

MAEntwicklung - E

Lenkungs-gremium

MA Disposition

zentraleSystem

-beratung

MAZentraleinkauf

ArbeitsgruppeÄnderungsdienst

MAEntwicklung - M

ArbeitsgruppeVar.Management

MAGrundlagenentw.

MA oper.Einkauf

MA Vorplanung

MA Vorplanung

MANormung

MAFeinplanung

Abb. 85. Auszug aus der Projektstruktur


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:

Prozessteam Fertigung: Die terminliche Steuerung der Fertigung bzw. Be-schaffung von Einzelkomponenten über die Baugruppenstruktur mittels statischer Wiederbeschaffungszeiten über den Kundenauftrag ist unzurei-chend. Es soll eine flexiblere, auftragsspezifisch terminierbare Methode er-arbeitet werden.Prozessteam Beschaffung: Wegen zum Teil widersprüchlichen Zielsetzun-gen und Maßnahmen des Zentraleinkaufs und der Entwicklung sollen Tei-lespektren definiert werden, für die ein zentralisierter Einkauf mittels Kontrakten und fixen Kontingenten lohnt. Prozessteam Planung: Es soll eine Identifizierung von Teilespektren erfol-gen, für die eine Vorplanung auf Basis von Aufträgen der vergangenen 5 Jahre lohnt und Strategien zur Vorplanung erarbeitet werden. Prozessteam Entwicklung: Es soll der vermehrte Einsatz von Wiederholtei-len ermöglicht werden sowie ein organisatorisches Konzept für eine be-schleunigte Datenpflege für Konstruktionsteile und Baugruppen sowie für Norm- und Kaufteile definiert werden.

Neben diesen prozessspezifischen Aufgaben werden folgende zentrale Heraus-forderungen erkannt und an die jeweilige Arbeitsgruppe übergeben:

Arbeitsgruppe „Produktstruktur“: Die bestehende Baugruppenstruktur ist nur für Experten zu durchschauen. Neue Funktionen sowie modernisierte Baugruppen sind überwiegend durch parallel geführte Varianten abgebil-det, 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. Arbeitsgruppe „Änderungsdienst“: Es wird nicht unterschieden zwischen auftragsbedingten Änderungen und Modernisierungen auf Basis der Grund-lagenentwicklung. Änderungen werden nach operativen Gesichtspunkten

Komponenten der PLM-Lösung 169

der jeweils ausführenden Abteilungen eingesteuert. Die Abstimmung zwi-schen den unterschiedlichen Unternehmensbereichen ist zeitaufwändig und fehlerbehaftet. Es ist ein durchgängiges Konzept zur Übernahme von Mo-dernisierungsmaßnamen unter Berücksichtigung bereits laufender Beschaf-fung und disponierten Aufträgen zu erarbeiten. Arbeitsgruppe „Variantenmanagement“: Einzelanfertigungen zur Erfüllung spezieller Kundenwünsche sind nicht von Standardbaugruppen zu unter-scheiden. Die Arbeitsgruppe erhält den Auftrag, Möglichkeiten zur Kenn-zeichnung 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, wel-che Produktelemente innerhalb dieser Gesamtstruktur in separaten Stücklistenstu-fen abzubilden sind und welche in Form einer Maximalstückliste angelegt werden. Darüber hinaus wird dort der zweckmäßige Einsatz von Materialvarianten, Aus-wahlpositionen, 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 Produkt-struktur beschlossen. Beziehungen zwischen einzelnen Baugruppen, wie zum Bei-spiel die Kombination einer bestimmten Trommelbaugruppe mit einer Antriebs-einheit, werden im Beziehungswissen abgelegt und sollen nicht mehr über eine Stücklistenstruktur abgebildet werden.

Baugruppen, die nicht vorgeplant werden und keine weiteren variablen Struktu-ren 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


Variante erzeugt. Im weiteren Ablauf werden durch die Planung spezifische Mate-rialvarianten ergänzt. Die Baugruppenstruktur ist für dieses Teilespektrum so zu gestalten, dass diese keine untergeordneten Strukturen mit weiteren vorzuplanen-den Teilen enthalten.

11.5.2 Klassifizierung

Um die Suche nach bereits vorhandenen Konstruktions- und Kaufteilen zu er-leichtern 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 Dar-stellungen und zugeordneten Maßtabellen. Die Maßtabellen werden als Merk-malswerte eingestellt. Zur Visualisierung der jeweils zu einer Klasse gehören-den 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 Klas-senstruktur werden durch ein Genehmigungsverfahren gewährleistet.

Die Materialnummern der klassifizierten Normteile werden, soweit dort vor-handen, 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 Norm-teilen 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 Auf-tragsmanagement möglich, Aufträge gezielt zum alten oder zum neuen Stand der Entwicklung zu terminieren. Die zu diesem Zweck anzulegenden Änderungs-nummern werden als Änderungspakete in einer Änderungshierarchie verwaltet. Auf Anforderung werden Änderungsnummern zentral durch die Disposition er-zeugt und nach abgeschlossener Bearbeitung gesammelt durch diese freige-geben.

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 Au-tomatisierung der Disposition. Die Auftragsstückliste wird ergebnisorientiert gene-riert, um Probleme mit nachfolgenden Änderungen innerhalb der teilweise langen Auftragsdurchlaufzeiten zu vermeiden. Es wird eine zweistufige Merkmalsbewer-tung durchgeführt: Der Vertrieb bewertet nach Kundenspezifikation im Kundenauf-trag 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 eingebun-den sind. Langläufer werden speziellen Netzplanvorgängen zugeordnet und so ge-trennt 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, ent-stehen zusätzliche Anforderungen an die Gestaltung der Produktstruktur.

11.6 Projektfazit

Zusammenfassend konnten durch das Projekt folgende Ziele erreicht werden: 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 erheb-lich reduziert. Es werden insgesamt weniger neue Kaufteile benötigt. Durch An-bindung der Cadenas-Datenbank mit den Normteilen an SAP steht der Normteil-fundus der Entwicklung direkt in ihrer Arbeitumgebung zur Verfügung.

Durch die im SAP abgebildete Vernetzung von Engineering, Fertigungs-steuerung und Programmplanung können Auswirkungen von Änderungen bes-ser abgeschätzt, im Vorwege abgestimmt und mittels Änderungsdienst sauber terminiert in den Produktionsablauf eingesteuert werden und verursachen ei-nen 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.


Erhöhung der Planungssicherheit Durch die Implementierung eins Änderungsprozesses mit Nutzung von Ände-rungszyklen 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 Bau-gruppendisposition erfolgen.

Durch den Einsatz der Materialvarianten können konfigurierbare Baugrup-pen 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 Projekt-systems für die Fertigungssteuerung, durch Pflege von Bezugsorten kann der erforderliche Beschaffungstermin exakter festgelegt werden.Verringerung der Auftragsdurchlaufzeit Wird einerseits durch organisatorische Maßnahmen erreicht (Stammdatenanlage erfolgt zeitnah durch die Konstruktion direkt im SAP, Strukturierte Pflegepro-zesse für Materialstämme mit Pflege durch erfahrene User, Abwicklung von Normteilanforderungen in zentraler Verantwortung), andererseits durch den Ein-satz 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 Konfigurationsstrate-gien in der Produktstruktur.Risiken im Rahmen der Realisierung Die Neuordnung der Produktstruktur und die vermehrt bereits bei der Datenan-lage 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 erfor-derte die rückhaltlose Unterstützung durch die Fachvorgesetzten. Potenziale nach Projektabschluss Offen blieb im Projekt die Neustrukturierung der Dokumentation für den Kun-den. Die zur jeweiligen Maschine ausgelieferten Handbücher werden baugrup-penübergreifend nach Funktionen zusammengestellt (z. B. Druckluftsystem, Hydrauliksystem) und lassen sich daher nicht mit denselben Methoden konfi-gurieren 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 Ausgangssi-tuation 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 inter-nationaler Marktführer in der Entwicklung und Herstellung von modernen 2-Takt- und 4-Takt-Motoren für motorisierte Freizeitgeräte wie Ski-Doo und Lynx-Schneeschlitten, 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


Langjährige Erfahrung, kombiniert mit einem ausgezeichneten Ruf, haben BRP-Rotax zu einem der renommiertesten und erfahrensten Motorenhersteller außer-halb der Automobilbranche gemacht.

Etwa 35 Prozent der über 215 000 Motoren, die jährlich produziert werden, ver-kauft die BRP-Tochter an Kunden außerhalb des Konzerns.

Im letzten Geschäftsjahr erzielte BRP-Rotax mit 1250 Mitarbeitern einen Um-satz 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, Bereit-stellung und Konsistenz zu SAP bzgl. Version und Status sicherzustellen war.

Ein manuelles Datenmanagement sowie die optimale Bereitstellung aller rele-vanten 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ög-lichkeit, alle im Produktlebenszyklus entstehenden Daten, weit über die traditio-nellen 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 In-formationsabläufe im gesamten Produktentstehungsprozess lässt sich zusammen-fassen 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“, be-fasst hatte, wurde die Zielausrichtung von PLM, nämlich alle Lebensphasen der Produktentstehung aus einer gesamtheitlichen Perspektive bestmöglich zu unterstüt-zen, sehr schnell erkannt, so dass ein PLM-Implementierungsprojekt initiiert wurde.

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



Standardisierung des Produkt- und Betriebsmitteldatenmanagements

Standardisierung der Datenstruktur (Namenskonventionen usw.) Neugestaltung der Freigabe- und Revisionsverwaltung Absicherung der Datenkonsistenz zwischen CAD und SAP Harmonisierung der Metadaten Bereitstellung der Geometriedaten intern als auch für Konzernpartner und Lieferanten über SAP Optimierung des Berechtigungskonzeptes für internen und externen Zeich-nungszugriff über SAP Workflowgesteuerte Zeichnungsfreigabeprüfung Verknüpfung der Produkt- und Betriebsmitteldaten zur Verwendungsnach-weisführung Interne Kundeneinbindung durch Collaboration & Redlining Tools (Front-loading)Altdatenintegration

SAP integriertes Ausgabemanagement

Umstellung zum digitalen Masterdokument für Zeichnungen Dezentrale Zeichnungsausgabe im Pull-System direkt aus SAP heraus Automatische Protokollierung der Ausgabe- und Verteilerattribute Automatische Identifikationsstempelung bei der Ausgabe Ausgabefunktion für Sammelaufträge (Stücklisten, KPL-Zeichnungen) Workflowsteuerung für Bereitstellungsinformationen (z. B. Zeichnungsfrei-gabe)

B2B-Lieferantenportal

Volle SAP-Integration über NetWeaver-Technologie Massive Reduktion der Prozesskosten und Reaktionszeiten Bedeutende Verbesserung der Prozessqualität Kostengünstige Anschlusslösung für Lieferanten Automatische Datenpaketierung und -komprimierung (ZIP) Automatische Protokollierung der Lieferanten-Downloads Eskalationsmeldung bei nicht erfolgtem Download Eindeutige Visualisierung des Download-Status


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

12.4 Projektvorgehen und Projektorganisation

07/0407/01 07/02 01/03 07/03 01/0401/02

Feb Feb Feb MarMarMar AprAprApr May May MayJun Jun JunJul Aug Sep Oct Nov Dec Jan Jul Aug Sep Oct Nov Dec Jan JulAug Sep Oct Nov Dec Jan

Release 3

Integriertes Ausgabemanagement

Release 1

Produktdatenmanagement

Release 4

B2B-Portal

Release 2Betriebsmitteldatenmanagement

Release 5

Stabilisierung & Optimierungen

Abb. 88. Projektverlauf / Umsetzungsphasen

Das Projekt wurde in mehrere Phasen (Releases) funktional gegliedert, folgende Meilensteine zeigen den Projektverlauf:

03 / 2000 PLM-Initialisierungs-Workshop 10 / 2000 SAP-Upgrade auf Version 4.6b, Entscheidung für mySAP PLM 07 / 2001 Kick-Off für PLM-Projekt 09 / 2001 Scoping: Projektinhalte definiert 12 / 2001 Implementierungs- und Releaseplanung abgeschlossen 01 / 2002 Systemarchitektur definiert 05 / 2002 SAP-Schnittstelle zu Pro/Engineering + Pro/Intralink beauftragt 09 / 2002 Start der Modultests durch Kernteam 11 / 2002 Start des Prototypentests durch 12 / 2002 Start eines Piloten mit 7 Anwendern (Dauer 1 Woche) 01 / 2003 Start der Anwenderschulungen (ca. 1700 Std.) 02 / 2003 Roll-Out des Release 1 (Produktdatenmanagement) und Kick-

Off für Release 2 (Betriebsmitteldatenmanagement) 03 / 2003 Kick-Off von Release 3 (Integriertes Ausgabemanagement) 04 / 2003 Altdatenintegration zu 90% abgeschlossen (ca. 1050 Std.)

Ergebnisse des Projektes 177

Abb. 89. Projektorganisation

08 / 2003 Kick-Off von Release 4 (B2B-Lieferantenportal) 11 / 2003 Roll-Out von Release 2 (Betriebsmitteldatenmanagement) 02 / 2004 Roll-Out von Release 3 (Integriertes Ausgabemanagement) 04 / 2004 Roll-Out von Release 4 (B2B-Lieferantenportal) 07 / 2004 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

Automatisierung und Dokumentation der Arbeitsabläufe Klare Zuordnung der Zuständigkeiten Vermeidung von Medienbrüchen und Insellösungen


Verbesserte Datennutzung und -extraktion eindeutige Daten- und Statusidentifikation einfacher, schneller Zugriff und Visualisierung von Produkt- und Vorrich-tungsdaten konsistenter und sicherer Informationsfluss Prozess-Monitoring

Besseres Wissens- und Qualitätsmanagement Detaillierte Produkt- und Prozessdokumentation Fehlervermeidung durch eindeutige Datenidentifikation digitale Bereitstellung von ergänzenden Engineering Informationen (Nor-men, Techn. Spezifikationen)

Förderung der Kooperation Zusammenarbeit der internen Prozesskette, Partner, Lieferanten und Kun-den (B2B-Portal)

Verkürzung der Produktentwicklungszeiten kürzere Reaktionszeiten weniger Iterationsschleifen 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 Erfah-rungen in der Vergangenheit besonderer Wert gelegt. Eine verantwortungsvolleund 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 BRP-Rotax 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)

Ist-AnalyseDefinition und Dokumentation des neuen Änderungs- und Konfigurations-managements Aufbau von Phasenschema und Statusidentifikation zum Änderungsprozess Verfügbarkeit erster Monitoring-Funktionen für Prozess- und Produktkosten Migration des Änderungsantrages von Notes nach SAP Nutzung des SAP-Konfigurationsmanagements SAP-integrierte Datenverwaltung von Produktdokumenten über den gesam-ten Änderungsprozess

Phase 2 (2005)

Fortsetzung des Prozess-Reengineering zur Umsetzung des Änderungsauf-tragesAusbau der Monitoring-Funktionen Migration von weiteren Notes-Applikationen nach SAP Integration des After-Sales-Bereichs Integration der Vorrichtungs- und Werkzeugorganisation (Terminsynchro-nisation und Kostenmonitoring) Integration von externen Partnern (Lieferanten, Kunden und Partner)

Die Umsetzung des NPCM-Projektes strukturiert sich nach den Anforderungsper-spektiven des Engineering Change Managements (ECM) und des Configuration Managements (CFM).


Die Ist-Analyse des Änderungsprozesses wurde mit der Prozessmodellierungs-software ARIS von der IDS Scheer AG durchgeführt und zeigte die Komplexität des bisherigen Änderungsprozesses. Anfänglich überraschte uns die Prozesskom-plexitä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 Be-nutzerfreundlichkeit zu erhöhen und SAP als Systembasis zu verwenden, entschie-den sich BRP-Rotax, den neuen Änderungsantrag ebenso über die NetWeaver-Technologieplattform abzubilden wie das vorher erwähnte B2B-Lieferantenportal. Zur Erfassung und weiteren Bearbeitung eines Änderungsantrages wurde das SAP-Objekt Meldung benutzt. Zudem wurden Funktionen aus dem SAP-Projektsystem zur Terminsteuerung und Auswertung von Prozess- und Produktkosten in den Än-derungsprozess eingearbeitet.

Im CFM-Teilprojekt wurden unsere Anforderungen zur Abbildung von histo-rien- bzw. zertifizierungspflichtigen Produkt- und Dokumentstrukturen sowie Pro-zessen realisiert.

In der ersten Phase wird das Configuration-Management-Modul der SAP für einen neuen Flugmotor eingeführt, um hier Rückverfolgbarkeit der Fertigungs- und Produktionsdaten in SAP zu gewährleisten. Über die Abbildung von Installa-tionen wird der tatsächliche Produktstatus mit allen vernetzten Daten und Doku-menten 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üf-losnummer erstellt und als Etikettenausdruck auf den jeweiligen Verpackungsein-heiten 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 Unterschie-de zwischen einzelnen Motoren programmiert, um Unterschiede einzelner Produk-te 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 befindli-chen 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 Kon-figuration 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 Markt-führer im Bereich Eismaschinen für Eis nach traditioneller Art, auch bekannt als „Eis nach italienischer Art“. Sie entwickelt und produziert an Standorten in Ita-lien, Spanien und Nordamerika, in weiteren Ländern weltweit unterhält man Ver-triebs- und Servicecenter. Die Notwendigkeit der Marktnähe erfordert die Globalisierung des Unternehmens und damit auch die weltweite Verfügbarkeit ak-tueller technischer Informationen. Aus diesem Grunde wurde im Rahmen eines PLM-Projektes insbesondere die CAD-Integration implementiert. In einem Folge-projekt werden auf dieser Basis Prozesse für Engineering Collaboration einge-führt. In diesem PLM-Projekt sind etwa 30 CAD-Benutzer aus Entwicklung, Konstruktion und Fertigung sowie weitere PLM-Benutzer aus Einkauf, Qualitäts-sicherung 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, technolo-gisch und organisatorisch zu wachsen. Der erste große Schritt dieses Wachstums war die Gründung der Carpigiani Group, angeführt durch Carpigiani, der zahlrei-che andere Betriebe des Bereichs Eismaschinen angehören.

Durch ein weit verbreitetes Vertriebsnetz (Direktvertrieb, angeschlossene Fir-men, 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 nordame-rikanischen Ländern durch den Aufkauf und die Eingliederung der Firma Electro Freeze (East Moline; Illinois – USA) wesentlich ausgebaut.


Die Carpigiani Group hat die Probleme, die durch die verteilten Entwicklungs- und 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-


blick auf die Harmonisierung der verschiedenen Standorte nur noch schwer durch-fü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 Zusammen-führung von betriebswirtschaftlichen und konstruktionsbedingten Daten zu ermög-lichen, 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 ferti-gen 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:

Engere Verzahnung der Entwicklung mit den anderen Unternehmensbereichen Globaler, kontrollierbarer Datenpool Harmonisierung des Produktportfolios Effizienteres Time-to-Market


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ög-lichkeiten 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: Verständnisphase: Am Anfang stand für alle Mitglieder des Projektes die Schaffung eines gemeinsamen Verständnisses der bisherigen Arbeitsweise und der sich er-gebenden 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 Produktions-standorte 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

Planungsphase: Die während der Verständnisphase gemachten Erfahrungen und die sich daraus bei Carpigiani ergebenden Anforderungen wurden nochmals kri-tisch hinterfragt, auf Machbarkeit (technisch und prozessorientiert) geprüft und dokumentiert. Die Dokumentation hat die Anforderungen und notwen-digen Änderungen im Prozess für alle Projektbeteiligten klar zusammenge-fasst 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 Kon-strukteur direkt aus der CAD Applikation in mySAP PLM angelegt wer-den. 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 Pla-nung der Umsetzungs- und Einführungsphase. 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 kla-re 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. 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 wur-de im Winter 2004 / 2005 erfolgreich abgeschlossen. Durch frühzeitige Ein-bindung der Fachabteilungen in den ersten Phasen des Projektes gelang es, das Wissen über SAP PLM frühzeitig im Unternehmen zu streuen. Da-durch konnte die Dauer von Trainingsmaßnahmen und des Rollouts insge-samt 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 zu-sammen. Die Umsetzungspartner hatten dabei jeweils eine ihrer Kernkompetenz entsprechende Aufgabe zu erfüllen. Im Einzelnen war dies:

die Betreuung der SAP-System durch die Firma SIDI-Società Italiana di In-formatica SpA (Mailand), die Betreuung der CAD-Systeme durch die Firma CDM Isigraf S.r.l. (Sorbolo) und die Beratung und Umsetzung der CAD-Integration durch die Strategic-Enterprise AG (Tübingen).



Projektschwerpunkt lag auf dem Einsatz der SAP-Dokumentenverwaltung, integ-riert in die bei Carpigiani eingesetzten CAD-Werkzeuge. Hierzu wurde die vom Hersteller der CAD-Werkzeuge angebotene SAP PLM-Integration an die Bedürf-nisse der Carpigiani Group angepasst, wobei auf höchstmögliche Releasesi-cherheit Wert gelegt wurde. CAD-Files werden an die Dokumentenverwaltung (DVS) übergeben, mit den Materialstammdaten automatisch verknüpft und klassi-fiziert.Carpigiani verwaltet innerhalb des SAP DVS die folgenden Daten:

2D-Zeichnungen3D-ModelleAbgeleitete 2D-Zeichnungen Neutrale Formate (JPEG, TIF, PDF) Dokumentationen der Entwicklung/Konstruktion

Hardwareseitig konnte die bestehende SAP-Infrastruktur genutzt werden. Als Plattform für die Dokumentenspeicherung musste ein neuer Server installiert wer-den. Softwareseitig war die Anschaffung weiterer Lizenzen für die CAD-Integrationen und die weiteren 3D-CAD-Arbeitsplätze notwendig.

Als wesentliche Erkenntnis kann festgehalten werden, dass sich die oben be-schriebene 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 Pro-zesse optimal einpassen.

Der sich durch die SAP PLM-Einführung ergebende hohe Grad an Automati-sierung der Datenverwaltung und die Verfügbarkeit von wichtigen Daten der Ent-wicklung 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 inter-kulturelle Zusammenarbeit. Dies lässt sich nicht nur an sprachlichen Aspekten sondern auch an den inhaltlich und fachlich unterschiedlichen Kompetenzen fest-machen.

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 vorge-sehen.

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 Projektver-lauf 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 cur-rent status of collaborative engineering based on experience from various engi-neering 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 prod-ucts 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 Zu-rich, 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 engineer-ing services providing system solutions for industrial processes. ABB’s hardware, software and service technologies help customers to improve productivity, effi-ciency, safety, and quality in plant or process operation. In power technologies, ABB offers comprehensive products and engineering services for high and me-dium 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 dis-tributed 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 organiza-tions, 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 develop-ers, manufacturers, service technicians, and suppliers – must have the right infor-mation, at the right time, and in the right format and be able to act on it quickly”

These initiatives are: Use of collaboration tools in project management and engineering Modularization and standardization of engineered products Standardization of default product information 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):

Collaboration for Design Collaboration for Manufacturing Collaboration for Service

For each of these blocks the involved person groups are responsible for a deliver-able which could be achieved either internally of externally. While within the con-cept 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 com-pletely 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 op-erations communicated over company borders. The amount of information is in-creasing 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. Collabora-tive 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 brainstorm-ing 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 re-lated 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 (Al-len, 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 al-lows 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. Confer-encing WebServices through Genesys counts 2200 users per month or 450 thou-sand minutes conferencing time, and video conference rooms have been installed in about 300 locations. The number of team rooms for project purposes is not re-corded, 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:

You need to distribute and install client software, which requires time and effort There is no depth collaboration with your suppliers


Databases/Groupware

E-mail

Fax

Phone

Shared screen

TODAY

Audio & Text Video

sending picturesfast information delivery

asynchronous data accesssynchronous screen displaying

synchronous data sharingvoice communication

Video conference

Chat

Virtual Reality

Immersion

Functionality

Real-time

NonReal-time

Sync

hron

izat

ion

1876 1971 1982 ~ 1990 ~ 1995 ~ 2000

Databases/Groupware

E-mail

Fax

Phone

Shared screen

TODAY

Audio & Text Video




Video conference

Chat

Virtual Reality

Immersion

Databases/Groupware

E-mail

Fax

Phone

Shared screen

TODAY

Audio & Text Video




Video conference

Chat

Virtual Reality

Immersion

Functionality

Real-time

NonReal-time

Sync

hron

izat

ion

1876 1971 1982 ~ 1990 ~ 1995 ~ 2000Functionality

Real-time

NonReal-time

Sync

hron

izat

ion

1876 1971 1982 ~ 1990 ~ 1995 ~ 2000

Fig. 92. Evolution of Collaboration Technologies

Dependence on availability of network and external providers There are still too many islands of information and documents Still there are too many CAD-Systems and formats used The bandwidth is limited as well as stable communication networks 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 organi-zations and to define a clear method of communication and collaboration it is es-sential 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:

Support of top management is required to get permission to exchange of sensitive information Training and software support is required for widely distributed users Security policy may block data exchange with externals Human resistance to changes in technology Designer’s willingness to keep developed things under the desk Overcome threshold for routine use of new technology Language barriers Political constraints between locations Lack of face-to-face contact Less adventure and pleasure when not travelling 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:

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


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 com-modity. 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 pro-ject 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 engi-neer solutions for customers.

Process PlantPulp and Paper PlantRolling MillPowertrain AssemblyOffshore


Body-in-WhitePainting & CoatingPress AutomationTransmission Lines


Large DrivesTurbinesOffshore Power PlantOEM Projects


TransformersMachinesOperator Stations


DrivesPower ElectronicsAutomation ProductsRobots


Small DrivesMotors

Small DrivesMotors

SwitchgearSubstationsSpecial MotorsValves and Actuators


FusesSwitchesMetersSensors


Standardization of DeliveryStandardization of Delivery

After SalesPlant Service


Small TransformersWellhead Systems


CablesLarge CapacitorsSensors


Installation MaterialCapacitors


Project/Plant Engineering

Engineer-to-Order

Assemble-to-Order

Off-the-Shelf

CommodityEngineeringService

Com

plex

ity o

f Del

iver

yC

ompl

exity

of D

eliv

ery

Low

High Process PlantPulp and Paper PlantRolling MillPowertrain AssemblyOffshore










Small DrivesMotors

Small DrivesMotors





Standardization of DeliveryStandardization of Delivery









Project/Plant Engineering

Engineer-to-Order

Assemble-to-Order

Off-the-Shelf

CommodityEngineeringService

Com

plex

ity o

f Del

iver

yC

ompl

exity

of D

eliv

ery

Low

High

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

Standardization of Default Product Information 191

Second it is a package of information such as datasheets, drawings, solid mod-els, cost calculation tools, reliability information, maintenance manuals and refer-ence 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 commission-ing 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 prod-uct 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 DetailedQuote Order Frozen

LayoutDesignReview Release Purchase Construc-

tion

ReduceEngineering

More time to shop& migrate to LCC

Quote provenquality

STD

CONV-01105CONV-03106

STAT-03112

STAT-10008

ROBO-02205ASSY-03201

TORQ-02007STD


STAT-03112

STAT-10008


TORQ-02007

Bill of Standards

Early release

Moresimultaneous work

Quote DetailedQuote Order Frozen

LayoutDesignReview Release Purchase Construc-

tion

ReduceEngineeringReduceEngineering

More time to shop& migrate to LCCMore time to shop& migrate to LCC

Quote provenquality

STD


STAT-03112

STAT-10008


TORQ-02007STD


STAT-03112

STAT-10008


TORQ-02007

Bill of Standards

Quote provenquality

STD


STAT-03112

STAT-10008


TORQ-02007STD


STAT-03112

STAT-10008


TORQ-02007

Bill of Standards

Early releaseEarly release



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

deliver continuous productivity improvement from ABB’s integrated op-erations, engineering and information management environment provide more efficient engineering through integrated tools for installation, operation, optimization and maintenance of every device


guarantees certified interoperability of ABB products using international bus-protocols and communications standards enables enhanced functions available in certified products enabling „plug and produce” installation in any Industrial IT system allow extension of ABB installed systems capabilities through system evo-lution or enhancement

The core of the ABB approach is the ABB Aspect Object Model, which has al-ready 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 pres-entation (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, installa-tion manual, maintenance manual, data sheet, process parameters and design pa-rameters.

Product Classification

Product Aspects

Product Aspect Presentation

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 in-formation 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 ser-vice phase. During design and engineering, collaboration requires detailed descrip-tion 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 stan-dards like IGES (ANSI IGES) and STEP (ISO STEP). Implementation of data ex-change with these standards requires commercially available interfaces to CAD-systems, 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 imple-mentation of processes, which all establish trust and confidence between the col-laboration partners.

While the picture in the design and engineering phase is quite clear, in the do-main 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 applica-tions, 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

Bill of material (BOM), Bill of Service parts, Electronic catalogs, Product process parameters, Tables of characteristics, Commercial information, Contractual information, and Installed base data


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 innova-tion.

The ABB Corporate Research Centers in Krakow and Ladenburg have been evaluating and defining new engineering methods for the new collaboration ap-proach. The tools that have been selected at this time are: Lotus Notes, Net-Meeting 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 col-laboration”. 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 Rat-ingen selected the enterprise collaboration approach. Furthermore both sites had been requested to select two suppliers each. They were free to decide which sup-plier 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 col-laboration 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: Real time co-work on design Integration of Suppliers Cost savings of travel Cost savings due to reduction of project time


Immediately decisions Quality improvement Reuse of parts 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 IIIFallstudien aus der Prozessindustrie

15 Produktentwicklung bei einem Lebensmittelhersteller

Dieses Kapitel berichtet von einem PLM-Projekt bei einem Konsumgüterherstel-ler. 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 Produkt-entwicklungsprozesses zu verbessern und durch Toolunterstützung eine Verbesse-rung 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 An-wendern in der Produktentwicklung und im Umfeld der Produktentwicklungspro-jekte genutzt.


Das Unternehmen setzte bereits vor einigen Jahren ein „auf die organisatorische Verbesserung von Prozessabläufen mit Hilfe der Informationstechnologie fokus-siertes Projekt“ auf. Nachdem die grundsätzliche Entscheidung für die Einfüh-rung von Standardsoftware gefallen war, wurde der Schwerpunkt dieses Projektes die unternehmensweite Einführung des integrierten Standard-Informationssystems SAP R/3 als strategisches System in den Bereichen Perso-nalwesen, Beschaffung, Finanzbuchhaltung, Controlling, Vertrieb, Materialwirt-schaft und Produktion.

Neben den Teilprojekten des Organisationsprojektes in den genannten Berei-chen wurden zwei weitere Teilprojekte aufgesetzt: die zentrale Stammdatenver-waltung für die verschiedenen Anwendungsbereiche und die Unterstützung der Produktentwicklung.

In der Produktentwicklung war zu Projektbeginn folgende Ausgangssituationvorzufinden:

Die Entwicklung neuer Produkte (Artikel) liegt in den Händen der verschiede-nen Sparten und wird in der Regel vom Marketing dieser Sparten verantwortet (nicht berücksichtigt sind Beteiligungen und kooperierende Unternehmen). Pro-duktentwicklung bedeutet zum einen Produktinnovationen, d. h. Produkte, die grundlegend neu sind, oder so genannte Line Extensions, also neue Produkte in-nerhalb bestehender Produktlinien. Zum andern fallen aber auch Produktrenovatio-nen, d. h. substantielle Änderungen bestehender Produkte, sowie Änderungen an


Rezeptur oder Verpackung unter die Produktentwicklung. Die Sparten unterschei-den sich wesentlich zum Beispiel hinsichtlich der Anzahl der Produktentwicklun-gen pro Jahr und der Laufzeit der Produktentwicklung, die von einigen Monaten bis zu mehreren Jahren reicht.

Die Ausgangssituation zu Projektbeginn ist einerseits durch die unternehmens-weiten Rahmenbedingungen gekennzeichnet:

Heterogene Systemlandschaft (unterschiedliche IT-Systeme auf unter-schiedlichen Plattformen für die operative Geschäftsabwicklung) Keine Integration der Produktentwicklung in die operativen IT-Systeme Entscheidung für den Einsatz von Standardsoftware SAP R/3

Andererseits sind die Produktentwicklungsprozesse selbst durch folgende Aus-gangssituation charakterisiert:

Unterschiedliche Entwicklungsprozesse in den verschiedenen Sparten: Dies ist einerseits durch die Verschiedenartigkeit der Produkte bedingt, anderer-seits auch Ausdruck der historisch innerhalb der Sparten gewachsenen Pro-zesse ohne übergreifende Abstimmung. Die Entwicklungsprozesse sind teils lückenhaft und stark technologisch geprägt. Unterschiedlicher Strukturierungsgrad: Während einzelne Sparten bereits mit definierten Entscheidungspunkten innerhalb des Produktentwicklungs-prozesses arbeiten, werden in anderen teilweise bereits weit reichende (und kostenintensive) Entwicklungstätigkeiten begonnen, bevor eine Entschei-dung über das weitere Vorgehen vorliegt. 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 verwen-det, allerdings ohne Abbildung der diversen Abhängigkeiten zwischen ein-zelnen Prozessschritten. Manuelle Projektsteuerung: Die Steuerung des Entwicklungsprojektes, d. h. der Anstoß weiterer Aktivitäten nach der Beendigung vorheriger liegt voll-ständig beim Projektleiter bzw. -koordinator. Als Kommunikationsmedien werden dafür Telefon und E-Mail eingesetzt. Dokumentation: Die Ergebnisse einzelner Tätigkeiten liegen in ganz un-terschiedlicher Form vor, teils als Papierdokumente, die per Hauspost verschickt werden, teils als elektronische Dokumente in Form von Word- oder Excel-Dateien, die per E-Mail, teils aber auch in ausgedruckter Form per Hauspost verschickt werden. Dadurch entsteht hoher Koordina-tions- und Administrationsaufwand. Zudem besteht die Gefahr, dass ver-schiedene Mitarbeiter mit unterschiedlichen Ständen der Dokumente arbeiten.


Intransparenz der Entwicklungsprojekte: Sowohl die Zahl als auch das Sta-dium der aktuellen Entwicklungsprojekte ist nicht in allen Sparten zu jeder Zeit transparent. Stammdatenerfassung: Während des Produktentwicklungsprozesses entsteht eine Reihe von Daten zum Produkt (Artikel), sowie Rohstoffen und Verpa-ckungen, die in nachgelagerten, operativen IT-Systemen als Stammdaten zur Verfügung stehen müssen. Die Stammdaten werden in einer Reihe von Pa-pierformularen 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 wer-den 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 Zeitpunk-ten an verschiedenen Stellen entstehen. Beispielsweise existiert die Produkt-bezeichnung (der Artikeltext) bereits mit der Produktidee, dagegen steht das Bruttogewicht der Verkaufseinheit erst nach dem Wiegen der ersten fertig produzierten Einheiten im Werk fest.


Ausgehend von den vorgenannten Problemfeldern, die sowohl in der Ausge-staltung des Entwicklungsprozesses an sich als auch in dessen systemtechnischer Unterstützung liegen, definieren sich die Ziele des Projektes in verschiedenen Be-reichen:

1. Prozesssicherheit Harmonisierung des Produktentwicklungsprozess über die verschiedenen Sparten Klare Strukturierung des Produktentwicklungsprozesses

2. Time to market Verkürzung des ProduktentwicklungsprozessesFrühwarnsystem für TerminüberschreitungenMöglichst starke Parallelisierung von EntwicklungstätigkeitenVerringerung von Liege- und Postlaufzeiten

3. Transparenz Verfügbarkeit vollständiger und aktueller Dokumentation Vergleichbarkeit der Projekte Soll-Ist-Vergleiche für Projekte


4. Arbeits- und Kosteneinsparung Entlastung von Terminverfolgungs-Aktivitäten Vereinfachung von Berichten Ablösen der Formularflut Reduzierung von Suchaufwand 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“ An-forderungsdefinition 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 Entwicklungs-projekten gewählt. Grundlage dieser Vorgehensweise ist zunächst eine ausrei-chend genaue Anforderungsdefinition für die erste Implementierung, die im Verlaufe des Projektes iterativ gemeinsam mit den Anwendern ergänzt und verfei-nert und vom Projektteam umgesetzt wird.

Nach Abschluss des Pilotprojektes und Konsolidierung der ersten Anwender-erfahrungen erfolgte die Einführung bei der größten Sparte als Rollout des Projektes.

Das Kern-Projektteam umfasste über den Einführungszeitraum neben dem Pro-zessverantwortlichen 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 vorgela-gert ist, wurde der Produktentwicklungsprozess analysiert und spartenübergreifend abgestimmt. Für den Gesamtprozess wurde ein gemeinsames Phasenkonzept ent-wickelt, das innerhalb der einzelnen Projektphasen in den verschiedenen Sparten unterschiedlich ausgestaltet sein kann.

E1 E2 E3 E4 E5 E6

Ideen-Phase Entwicklungs-Phase Kontroll-Phase

Phase 1 Phase 2 Phase 3 Phase 4

Abb. 99. Phasenkonzept der Produktentwicklung

Die einzelnen Phasen enden mit Entscheidungsmeilensteinen (E1 bis E6). Da-durch ist sichergestellt, dass am Ende jeder Entwicklungsphase explizit eine Ent-scheidung ü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 Entwicklungs-phasen 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 Kontroll-phase mit Softwareunterstützung bearbeitet werden. Die Einführung der Software-unterstü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 an-stelle eines starren Phasenkonzeptes gewählt. Zum Start des Roll-Out erfolgte eine Definitions- oder Konzeptionsphase, die sich über einen Zeitraum von zweiein-


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 SAP-Projektsystem und die Workflowunterstützung.

Für die Entwicklungsprozesse wurden Standards definiert, die als Vorlage-netzplä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 Ent-wicklung von Produkten verschiedener Produktlinien unterschiedliche Tätigkei-ten 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.

MPF,MPK,MPS

560

PGM/PM*

570

TP,TPM

580

TP

-

590TA*

-

600

MPF,MPK,MPS

610

ND-EK*, -EA*, ER*

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

640

WL-FV, WS-V

--/

660TP,TPM

650

TA*

820

MF*

860

PGM/PM*

870

MPF,MPK,MPS

620

TTS

830

TA*,TTS

840

TTS

850

PM*

690

PM*,KPA

780TPM

790

TP/TPM

810

WS-KK

730

PMF,PMK,P

880

TA*

700KP*

710

PM*

680

ND-EZ*

720PM*

740

TA*

670

ND-EZ*

750

WS-KK, WL-KK

760

WL-L, WS-L

770

TPM,WL-FV,WS-V

800

KE

785

PM*

815

Abb. 100. Detaillierter Ablaufplan der Tätigkeiten für die Phase 3 des Produktentwick-lungsprozesses 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

Umsetzung der definierten Entwicklungsprozesse in Form von Netzplänen Benutzerfreundlichkeit (Unterstützung bei Anlage operativer Projekte aus Standardvorlagen) Unterstützung der Anwender durch Vollständigkeitsprüfungen etc. Terminierung (nach Rückmeldung einzelner Tätigkeiten) Berechtigungskonzept für lesenden und schreibenden Zugriff auf Projekt-informationen Berichte über Projektfortschritt, Vergleiche von Projekten, sonstige Aus-wertungen (z. B. Vorgänge ohne Puffer, Arbeitsplatzauswertungen etc.) Ressourcen- und Kostenplanung sowie Kostenverfolgung sollen später als funktionale Erweiterung eingeführt werden

Anforderungen an die Workflowunterstützung:

Automatische Prozesssteuerung, d. h. automatische Benachrichtigung der Bearbeiter einzelner Tätigkeiten, wenn diese ausgeführt werden sollen, un-ter Berücksichtigung der im Netzplan definierten Abhängigkeiten MS-Outlook-Anbindung: Anwender sollen per Internet-Mail über anste-hende Tätigkeiten informiert werden Terminkontrolle und automatische Benachrichtigung der Projektverant-wortlichen bei Terminüberschreitungen (Frühwarnsystem)

2. Dokumentenverwaltungssystem

Im Bereich der Dokumentenverwaltung wurden die Anforderungen in folgenden Bereichen definiert:

Analyse und Festlegung der Dokumente, die zu Projekten verwaltet werden sollenDefinition der Zuständigkeiten für Einstellen und Aktualisieren von Doku-mentenFestlegung von verschiedenen Zuständen (Status) von Dokumenten und der erlaubten Aktivitäten (z. B. keine Änderung von freigegebenen Dokumenten) Berechtigungskonzept für den Zugriff auf sensible Dokumente wie Kalku-lationen oder Rezepturen Versionierung von Dokumenten zur Historisierung Ablage der Originaldateien in einem geschützten Bereich

3. Stammdatenverwaltung

Der Schwerpunkt der Anforderungsdefinition für die Stammdatenverwaltung war in erster Linie organisatorischer Natur:

Die Erfassung von Stammdaten soll dezentral erfolgen, d. h. jede organisato-rische Einheit pflegt die Daten, die von ihr erzeugt werden, selbst im System.


Festlegung der Zuständigkeiten für die Erfassung einzelner Stammdaten Einbettung der Stammdatenerfassung als einzelne Tätigkeiten in den ge-samten 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:

Rollenspezifische Erfassungsmasken, d. h. jeder Anwender sollte auf mög-lichst wenigen unterschiedlichen Masken Daten pflegen 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:

Customising des Systems: Festlegung von Prozessen durch Einstellung ent-sprechender Steuerparameter Einstellung von Stammdaten, die ebenfalls steuernde Funktion für den Pro-zessablauf bzw. auf die Ein- und Ausgabemöglichkeiten haben (z. B. Profi-le, Auswertungen) Erweiterung des Systems durch Nutzung von Programm-Exits oder User-Exits (d. h. Aufruf kundeneigener Programme bzw. Ergänzungen des SAP-Programmcodes an definierten Stellen) Programmierung von Workflowkomponenten 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 Benachrichti-gungsfunktionalitäten getestet, sowie Dokumente angelegt und mit Netzplan-Vorgä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 Gegen-satz dazu stehen beim Pilotprojekt etwa gleiche Anteile für die iterativ bearbeite-ten Bereiche Definition und Realisierung.


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

SAP-GrundlagenDokumentenverwaltungWorkflow

StammdatenerfassungInformationssystem DVSGrundüberblick PS

Detail PSInformationssystem PSBeispielprojekt gesamt

Beteiligte

SAP-GrundlagenDokumentenverwaltungWorkflow

Stammdaten/DVSGrundüberblick PSBeispielprojekt gesamt

1 Tag

1 Tag

1 Tag

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än-gen. Zunächst wurde ein Standard-PSP als Kopiervorlage für operative Projekte an-gelegt. Anschließend wurden Standard-Netzpläne eingestellt, die als Maximalpläne alle Tätigkeiten enthalten (vgl. Abb. 100), die in den einzelnen Phasen durchzufüh-ren sind. Diese Standard-Netzpläne enthalten bereits die Zuordnung der Netzplan-Vorgä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-


PSP

Phase 1 Phase 3Phase 2 Phase 4 Phase 5

Vorgang 1 Vorgang 5Vorgang 7

Vorgang 6

Vorgang 8Vorgang 2

Vorgang 3

Vorgang 4

Arbeits-platz

Arbeits-platz

Arbeits-platz Arbeits-

platz

Arbeits-platz

Arbeits-platz

Arbeits-platz

Entscheidungsphasen

Bearbeitungssschritte

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än-gen und Arbeitsplätze gepflegt. Sind all diese Arbeiten abgeschlossen, kann über ein Programm (Zusatzentwicklung) die Vollständigkeit geprüft werden. Dies um-fasst 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-Projekt-system.

Zum Vergleich von verschiedenen Projektzuständen, insbesondere bei Ände-rungen 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-


Abb. 103. Netzplandarstellung aus dem SAP-Projektsystem

Vorgang 5Vorgang 5

Systemstatus: EROF

Systemstatus: EROF

Vorgänge können noch nicht

bearbeitet werden

Vorgänge können noch nicht

bearbeitet werden

Vorgang 2Vorgang 2

Vorgang 3Vorgang 3Vorgang 4Vorgang 4

Systemstatus: EROF

Systemstatus: EROF

Systemstatus: FREI

Systemstatus: FREI

Systemstatus: EROF

Systemstatus: EROF

Systemstatus: FREI

Systemstatus: FREI

Vorgänge können bearbeitet werden

Vorgänge können bearbeitet werden

Vorgang 1Vorgang 1

Systemstatus: Frei

Systemstatus: Frei

Manuelle

Rückm

eldung

Benachrichtigungdurch den WORKFLOW

Statusänderungdurch Freigabe-

meilenstein

Abb. 104. Automatische Projektsteuerungsfunktion des Workflows


flow gestartet, der die Struktur des Netzplanes liest und den oder die nachfolgen-den Vorgänge „anstößt“ (vgl. Abb. 104). Außerdem werden durch die Freigabe-funktion 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:

Innerhalb des SAP-Systems wird ein Workitem in den Eingangskorb des-jenigen Anwenders geschickt, dessen Arbeitsplatz dem Vorgang zuge-ordnet ist. Für nicht regelmäßig in SAP arbeitende Projektmitarbeiter wird eine Inter-net-Mail an den Bearbeiter des Vorganges geschickt mit dem Hinweis, dass ein Workitem mit einer zu bearbeitenden Tätigkeit in seinem SAP-Eingangskorb 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. Abwesenheitsre-gelungen.

Durch diese Automatisierung wird der Projektleiter im Idealfall nach der Ein-richtung 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 Funktionali-täten implementiert:

Automatische Neuterminierung bei verspäteter / früherer Rückmeldung Benachrichtigung des Projektleiters bei verspäteter Rückmeldung Benachrichtigung des Projektleiters bei Zeitüberschreitungen Vorabinformation aller Beteiligten einer Projektphase

15.5.3 Projektinformationssystem

Für projektspezifische und projektübergreifende Auswertungen wird das SAP R/3-Projektinformationssystem 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 exempla-risch 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 ver-knüpftes Dokument (Blattsymbol).

Verknüpfte Dokumente können direkt aus dem Projektinformationssystem an-gezeigt werden (siehe auch nächstes Kapitel). Rückmeldedaten werden über die Aggregationsstufe verdichtet und auf den jeweiligen Stufen dargestellt.


Abb. 105. SAP R/3-Projektinformationssystem

Als Auswertungen wurden beispielsweise folgende Berichte eingerichtet:

Auswertung zeitkritischer Vorgänge (Vorgänge ohne Pufferzeiten) Liste sämtlicher Tätigkeiten aller Projekte für einen bestimmten Nutzer 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:

Automatische Ablage der Originaldateien in einem Sicherheitsbereich(SAP Content Server)Statusverwaltung mit Einschränkung der möglichen Operationen auf Do-kumenten in Abhängigkeit vom Status Versionierung freigegebener Dokumente bei Änderungen Verknüpfung mit Projekten Dokumentensuche über umfangreiche Selektionskriterien


berechtigte Stelle

Dokument Stel

le1

Stel

le2

Stel

le3

Stel

le4

Stel

le5

Stel

le6

Stel

le7

Stel

le8

Stel

le9

Stel

le10

Stel

le11

Stel

le12

Stel

le13

Stel

le14

Stel

le15

Stel

le16

Stel

le17

Dokument 1 x x x x x x x xDokument 2 x x x x x x x xDokument 3 x x x x x x xDokument 4 x x x x x x xDokument 5 x x x x x xDokument 6 x x x x x x x xDokument 7 x x x x x x x x xDokument 8 x x x x x x x xDokument 9 x x x x x x x xDokument 10 x x x x x x Dokument 11 x x x x x x x xDokument 12 x x x x x x xDokument 13 x x x x x x xDokument 14 x x x x x x xDokument 15 x x x x xDokument 16 x x x x xDokument 17 x x x x x xDokument 18 x x x x x

Dok

umen

tart

6 Dok

umen

tart

7Dok

umen

tart

5Dokumentart 1 Dokumentart 2

Dokumentart 3 Dok

umen

tart

4

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

Die Einführung des Dokumentenverwaltungssystems mit der Verknüpfung von Do-kumenten zu Netzplan-Vorgängen und der komfortablen Suche über beschreibende Dokumentendaten und Klassifizierung ändert die Informationsbeschaffung grundle-gend. Vor der Einführung der Dokumentenverwaltung war jeweils derjenige Projekt-mitarbeiter, 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 Produktentwicklungs-prozesses 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.



Deutliche Verbesserungen wurden in folgenden Bereichen erzielt:

Die Prozesstransparenz ist deutlich verbessert. Dies ist einerseits eine Auswirkung des standardisierten Entwicklungsprozesses mit klarer Pha-sengliederung. Andererseits wird der Zugriff auf Projektinformationen durch die neuen Auswertungsmöglichkeiten des Projektinformationssys-tems vereinfacht bzw. erst ermöglicht. 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. Die automatische Benachrichtigung der Projektmitarbeiter entlastet die Projektleiter von routinemäßigen Koordinationsaufgaben. Das Frühwarnsystem ermöglicht eine schnelle Reaktion des Projektleiters auf Verzögerungen. Alle Mitarbeiter haben (bei entsprechender Berechtigung) Zugriff auf die jederzeit aktuellen Projekt-, Material- und Dokumenteninformationen. Die Gefahr, dass mit veralteten Ständen von Informationen gearbeitet wird, ist deutlich verringert. 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ürze-ren Abständen innovative Produkte an den Markt zu bringen. Dieser Projektbe-richt 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 Mana-gement – realisiert beispielsweise im NPDI Prozesskonzept (New Product Deve-lopment and Introduction) – hilft, die Time to Market nachhaltig zu optimieren.

Das Unternehmen, bei dem das beschriebene Projekt durchgeführt wurde, ge-hö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 An-wender unterschiedlicher Bereiche (Marketing, Einkauf, F&E, Produktion, Logis-tik 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ärk-ter 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 effi-ziente Prozessintegration zwischen Forschung / Produktentwicklung und nachge-lagerten 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


© IDS Scheer AG Business Process Excellence www.ids-scheer.com16

Produktentwicklungszeiten

Wie lange dauert bei Ihnen im Durchschnitt die Produkt-

entwicklungszeit in Jahren für ein neues verkaufsfähiges

Endprodukt / Artikel?

3 ,8

2 ,8

1 ,6

0 ,80 ,5

1990 1995 2000 aktue ll 2010

Durchschnittlich in Jahren

Studie „Produktentwicklungsprozesse“ IDS Scheer 3/2004

bei 120 Industrieunternehmen

Abb. 107. Marktstudie zu Produktentwicklungszeiten

© IDS Scheer AG Business Process Excellence www.ids-scheer.com

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

Abb. 108. Marktstudie zu Produktlebenszeiten

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. Produkt-entwicklung ist als umfassendes Projekt zu begreifen und zu steuern, das auch die Aktivitäten des eigentlichen Produktlaunch mit umfasst und so oft noch vor-handene 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.


Die im vorhergehenden Abschnitt geschilderten Faktoren und Konsequenzen gal-ten auch bei dem hier betrachteten Duft-Hersteller. Bei einer detaillierten Betrach-tung der Prozesse rund um die Entstehung neuer Produkte wurden eine Reihe konkreter Schwachstellen identifiziert:

Eine einheitlich definierte, systemgestützte Projektsteuerung fand nicht statt, dementsprechend war es mühsam, Statusinformationen über einzelne Projekte zu bekommen. 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. Der Datenaustausch mit diesen externen Dienstleistern (z. B. Entwürfe im Rahmen der Verpackungsentwicklung) war nicht standardisiert und un-strukturiert, Datenaustausch erfolgt per Papier oder Mail, die Kommunika-tion und Ablieferung von Ergebnissen war fehleranfällig. Mangels Toolunterstützung taten sich die Projektverantwortlichen schwer, Termintransparenz herzustellen, zur Terminverfolgung wurden individuell konfigurierte Tools meist auf Excel-Basis eingesetzt. 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 Prognose-rechnung auf Ebene von Produktgruppen. Durch die schwierige Terminverfolgung kam es gerade an den Schnittstel-len zwischen Marketing, Produktentwicklung, Verpackungsentwicklung, Einkauf und Produktion oft zu Abstimmungsproblemen, aus denen verein-zelt Verzögerungen beim Markteintritt resultierten.


Aufgrund fehlender Dokumentationsstrukturen war die Übertragung von Ergebnissen zwischen den einzelnen Projekten, das Knowledge-Manage-ment, sehr vom individuellen Engagement abhängig. Als IT-Lösung wurde eine Vielzahl von nicht integrierten Tools benutzt: Für Dokumentation Microsoft-Office-Anwendungen mit einer jeweils indi-viduell 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. 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 zwi-schen 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 funktio-nell ausreichend, diese zu verwenden.


Als Ziele des Projektes wurden nach einer ersten Situationsaufnahme definiert:

Verbesserte Integration von Marketing, Produktentwicklung und Logistik Klar strukturierter Entwicklungsprozess für Launch und Relaunch Sicherheit, Prozesstransparenz und Projektsteuerung in den Entwicklungs-projekten verbunden mit einer Terminsteuerung und einem Frühwarnsys-tem bei Terminüberschreitungen Schaffung einer eindeutigen und möglichst einheitlichen Datenbasis für den Gesamtprozess Verbesserter Datenaustausch mit externen Lieferanten Verbesserung des Arbeitsflusses zwischen den Beteiligten durch aktive Steuerung des Prozesses

Die Lösung sollte mittels einfach zu bedienender Tools alle Elemente des Ent-wicklungsprozesses von der frühen Phase (Konzept- und Spezifikationsphase) bis zum Produktlaunch verwalten:

Dokumente, Konzepte und Briefings aus Marktforschung, Produktmanage-ment und Marketing projektbezogene Dokumente, die Verlauf und Inhalt der Produktentwick-lungsprojekte dokumentieren (Checklisten, Freigabedokumente) in Kollaborationen mit Lieferanten entstehende Dokumente und Daten

Vorgehen im Projekt 219

Lotus Notes

Produktent-

wicklung

Projekt-Timing

MS Excel

Monitoring

Soll - Ist

Checklisten

Sortimente /

Artikel

Datenaustausch

Lieferanten

FAXMarktforschung,

Marketing-

konzepte

MS Office

Fileablage

Freigabe- undÄnderungs-

ablauf

Reinzeichnungen

Korrekturabzüge

Technische

SpezifikationenMS Access

Datenbank

Artikelstamm-

datenSAP PDM

Produkt-

kalkulation

manuell /

papierbasiert

Fileserver

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

Daten und Auswertungen aus Projekt- und Produktcontrolling (Budgetie-rung, Soll-Ist-Vergleiche für Projekte, Analysedaten aus Laborinformati-onssystemen) die im Produktentwicklungsprozess entstehenden Stammdaten (Spezifika-tionen von Produkten und Verpackungen, technische Zeichnungen, Pro-duktstammdaten 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 (Dokumentenmana-gement, Projektsteuerung, Workflow, Stammdaten) die Umsetzung in SAP und


alternativ in Lotus Notes geprüft. Ergebnis war die Entscheidung, die von SAP im Rahmen der NPDI-Initiative (New Product Development and Introduction) integ-rierten 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 Do-kumente. Außerdem wurden die Prozesse zur Erstellung der Spezifikationen defi-niert und umgesetzt, auch mit Workflowunterstützung bei der Freigabe. Konzeption und Realisierung dieses Projektabschnitts erforderten einem Zeitraum von 6 Mona-ten. 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. Rezepturmanage-ment kann die Lösung in der Optimierungsphase noch ergänzen.

In Projektstufe 2 lag der Schwerpunkt auf Implementierung der Projektsteue-rung, Projektdokumentation und Datenaustausch mit Lieferanten (Kollaboration). Realisierung und Implementierung erforderten 8 Monate.

Es wurden die von SAP zum Projektmanagement angebotenen Lösungen Col-laboration Projects (cProjects: kollaborative, webbasierte Projektsteuerung) und das R/3 Projektsystem PS prototypisch implementiert und ausführlich miteinan-der verglichen (Vergleichsmatrix siehe Abb. 110). Schließlich wurde cProjects ausgewählt.

Die wesentlichen Arbeitspakete in dieser Phase waren:

Definition einer oder mehrerer generischer Projektstrukturen (Muster-Projektpläne) als Sollprozess der Projektabwicklung Realisierung der Projektsteuerung und Terminverfolgung elektronische Verwaltung von Projektdokumenten Prozesse und Tools zum strukturierten Austausch von Dokumenten mit ex-ternen Partnern Realisierung eines projektübergreifenden Management-Reporting

16.5 Das Prozesskonzept NPDI

Wesentlich für die Realisierung des Projektes war die Orientierung an dem so ge-nannten 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 opti-mieren. Produktentwicklung muss den gesamten Prozess von der Produktidee bis zur Einführung des Produktes am Markt beleuchten – nur dann wird sich ein Unter-nehmen durch Produktinnovation von seinem Konkurrenten differenzieren können.

Das Prozesskonzept NPDI 221

KriterienFaktor

SAP R/3 PSFaktor

cProjects Gewicht.

1 -5Erfüll.-gradSAP R/3 PS

Erfüll.-gradcProjects

KO-Krit.

Allgemeine KriterienOberfläche 0,6 0,9 4 2,4 3,6Berechtigungssystem 0,6 0,8 4 2,4 3,2Mehrsprachigkeit 1 1 3 3 3Weiterentwicklung 0,5 0,9 5 2,5 4,5Kosten 0,8 1 5 4 5IT Strategie 0,6 0,8 3 1,8 2,4Schulungsaufwand 0,4 0,8 3 1,2 2,4Funktionen eines ProjektsystemsProjektstruktur 0,8 0,8 5 4 4Arbeitsweise im Projekt 0,8 0,8 5 4 4Suchfunktionalitäten 0,6 0,8 5 3 4Arbeit mit Dokumenten 0,5 0,9 5 2,5 4,5Austausch von Dokumenten mit extern 0,5 0,9 5 2,5 4,5Terminierung 0,8 0,8 4 3,2 3,2Ressourcenplanung 0,7 0,9 2 1,4 1,8Workflow 0,6 0,8 5 3 4Projektcontrolling 0,9 0,5 1 0,9 0,5Auswertung / Reporting 0,8 0,6 5 4 3Kriterien der IntegrationIntegration mit SAP R/3 0,8 0,4 2 1,6 0,8Integration Rechnungswesen 0,8 0,5 1 0,8 0,5Integration Logistik 0,8 0,5 1 0,8 0,5Integration externer Anwendungen 0,4 0,8 3 1,2 2,4Summe 50,2 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 – erfolgskri-tisch 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 Marktein-fü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 NPDI-Konzeptes. Zur Gesamtlösung gehören nicht nur die in diesem Buch bereits erläu-terten Kernfunktionen des Produktdatenmanagements (Dokumente, Spezifikationen, Rezepte und Artikelstammdaten), sondern auch Ideen- und Konzeptmanagement.


Projektmanagement Produktentw.

Ideen- und Innovations-management

Ideenfindung undBewertung

€Kosten und Budget

Konzeptdefinition

MarkteinführungProduktionsanlauf

Stammdaten-management

Produktentwicklung im engeren Sinne

Zeit & Projektmanagement

Dokumenten-management

Markteinführung(CRM)

Produktion(SCM)

StrategischePlanung

PortfoliomanagementPortfolioplanung

Business Warehouse

Projektmanagement Produktentw.

Ideen- und Innovations-management

Ideenfindung undBewertung

€Kosten und Budget €Kosten und Budget

Konzeptdefinition

MarkteinführungProduktionsanlauf

Stammdaten-managementStammdaten-management

Produktentwicklung im engeren Sinne

Zeit & ProjektmanagementZeit & Projektmanagement

Dokumenten-managementDokumenten-management

Markteinführung(CRM)

Produktion(SCM)

StrategischePlanung

PortfoliomanagementPortfolioplanung

Business Warehouse

Abb. 111. Das NPDI Konzept

Über den gesamten Prozess sind Qualitätsmanagement, Projektmanagement und die Verwaltung des Projekt- und Produktportfolios sowie dessen strategische Pla-nung wesentlich. In der Phase der Markteinführung treten eine funktionierende Integration in die Supply Chain (Absatzplanung, Produktionsanlauf) und das Kun-denbeziehungsmanagement (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 Werk-zeugen gehören insbesondere die so genannten xApps (Packaged Composite Ap-plications). So hilft die Lösung xPD (xApp Product Definition) in der frühen Entwicklungsphase, Ideen und Konzepte strukturiert zu verwalten. Die Anwen-dung 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 Kollaborations-Plattform 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üh-rung eines Produktes am Markt. PLM hingegen ist weitgehender, beinhaltet z. B. auch Prozesse der Wartung und Instandhaltung oder der Marktentnahme eines Ar-tikels. 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-Kernanwen-dungen, die Markteinführung neuer Produkte effizient zu unterstützen. Zu beachten


ist allerdings, dass gerade bei der Verbindung der klassischen SAP-Applikationen mit den neuen Produkten an der ein oder anderen Stelle noch Schnittstellenprob-leme 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ösungsportfo-lio des SAP NPDI sukzessive mehr Tools zum Einsatz bringen.


SAP EHS

SAP cProjects

SAP cFolders

MS Excel

Produktent-

wicklung

Projekt-Timing

Monitoring

Soll - Ist

Checklisten

Sortimente /

Artikel

Datenaustausch

Lieferanten

Marktforschung,

Marketing-

konzepte

MS Office

Fileablage

Freigabe- und

Änderungs-

ablauf

SAP EHS +

Workflow

Reinzeichnungen

KorrekturabzügeSAP DMS

Technische

Spezifikationen

Artikelstamm-daten

SAP PDM

Produkt-

kalkulation

Multiprojekt-

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


16.6.1 Spezifikationsverwaltung

Die Spezifikationsverwaltung in SAP kann benutzt werden, um typische Eigen-schaften von Stammdatenobjekten in Form von Eigenschaftsbäumen – einer vor-definierten 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 Verpa-ckungsmaterialien beispielsweise mit dazugehörigen Artikelstämmen verknüpft, oder Spezifikationen werden in Rezepturen als Ein- bzw. Ausgangsstoffe aufge-nommen.

Bei dem hier betrachteten Projekt wurden mit Hilfe der Spezifikationsverwal-tung alle Verpackungsbestandteile des Endproduktes (Flasche, Pumpe, Sprühkopf, Verschluss, Faltschachtel etc.) detailliert beschrieben. Dazu dienten verschiedene Spezifikationsarten mit kundenindividuellen Eigenschaftsbäumen. Über Objekt-verknüpfungen erfolgte eine direkte Verlinkung einer Spezifikation mit dem zu-gehö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. ex-ternen 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 rol-lenbasiertem Zugriff.

Die Projekte des Kunden wurden analysiert und gemäß dem Datenmodell von cProjects neu strukturiert. Dabei gliedert sich ein Projekte hierarchisch in:

Projektdefinition, hier werden Daten verwaltet, die für das Gesamtprojekt gültig sind Projektphasen, welche das Projekt gliedern und optional eine streng pha-senorientierte 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), Pro-duktdesign und -kalkulation sowie Launch unterschieden. Projektaufgaben, welche Phasen zugeordnet werden und die tatsächlichen Tätigkeiten / Vorgänge eines Projektes repräsentieren und den Projektphasen


Abb. 113. Struktur einer Verpackungsspezifikation im SAP Spezifikationsmanagement

Abb. 114. Projektstruktur in cProjects


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 vorge-nommen. Checklisten, die abgearbeitet werden müssen, bevor eine Phase abgeschlos-sen wird. Diese Funktion kam bei dem konkreten Projekt nicht zum Einsatz.

Für die Projektstruktur wurden unterschiedliche Vorlagen hinterlegt, um den Be-sonderheiten 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:

Bei der Projektanlage wird eine Projektvorlage kopiert und das Launch-Datum festgelegt. Daraufhin terminiert das System automatisch die Pro-jektaktivitäten (Rückwärtsterminierung).Den Projektaufgaben (Aktivitäten) sind bereits in der Vorlage die für die Ausführung verantwortlichen Projektrollen (Marketing, Einkauf, Produkti-on etc.) hinterlegt. Im Rahmen der Projektplanung erfolgt die Besetzung der Rollen mit Ressourcen (Personen). Der Projektleiter gibt das Projekt frei, was durch einen entsprechenden Pro-jektstatus dokumentiert wird. Außerdem werden alle Projektmitarbeiter au-tomatisch per E-Mail über den Projektstart informiert. Sobald eine Projektaufgabe zur Bearbeitung ansteht (Erreichen des berech-neten frühesten Starttermins), werden die zur Ausführung verantwortlichen Personen durch einen Workflow per E-Mail informiert. Die Nachricht ent-hält einen Link zur konkreten Aufgabe in cProjects. Die Bearbeiter quittieren nach Erledigung ihre Aufgabe, Status im Projekt werden automatisch fortgeschrieben. Am Ende einer Phase startet der Projektleiter einen workflowgesteuerten Prozess zur Abnahme der Phase. Sobald alle Entscheidungsträger die Ab-nahme durchgeführt haben, wird die nächste Projektphase zur Bearbeitung freigegeben. In Einzelfällen kann eine Phase auch bereits freigegeben wer-den, obwohl die Vorgängerphase noch nicht abgeschlossen ist. Dokumente, die im Laufe des Projektes entstehen (z. B. Graphiken, Maß-blätter, Reinzeichnungen oder Korrekturabzüge), werden im SAP Doku-mentenmanagement 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 vor-gesehen.


16.6.3 Projektportfoliomanagement

Beim Reporting ist zu unterscheiden zwischen projektbezogenen und projektüber-greifenden Auswertungen. Erstere können direkt in cProjects ausgeführt werden (z. B. Aufwandsverteilung pro Projekt, Termine und Ressourcen pro Projekt, Pro-jektfortschritt, 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 Pro-gram 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 Kooperationsplatt-form, die eine unternehmensübergreifende Zusammenarbeit unterstützt. Das Sys-tem 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 Verpackungs-entwicklung mit Lieferanten auszutauschen (z. B. Maßblätter, Reinzeichnungen und Korrekturabzüge). Die Dokumente können direkt aus der Projektmanage-mentumgebung in Ordner (Collaboration Folders) abgelegt werden. Vom Projekt-leiter 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 zu-rü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äß Projektfort-schritt in den Informationsfluss einzubeziehen.


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

16.6.5 Dokumentenmanagement

Dokumente können auf drei Wegen in das System gelangen:

Dokumente mit direktem Projektbezug werden in der cProjects-eigenen Dokumentenmanagement-Umgebung gespeichert. Für den Gesamtprozess relevante Dokumente (technische Zeichnungen, Reinzeichnungen etc.) werden in der SAP Dokumentenverwaltung (DVS) abgelegt und direkt in cProjects bzw. cFolders integriert. 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) einge-setzt. Damit ist eine Integration in den Windows Explorer bzw. die Microsoft-Office Tools gegeben.


Das Projekt konnte termin- und aufwandsgerecht abgeschlossen werden. Insge-samt 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-


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:

Durch die Strukturierung mit Vorlageprojektplänen wird ein einheitlicher Produktentwicklungsprozess definiert. Mit dem Projektsteuerungstool wird dieser nachvollziehbar für alle Projektbeteiligten gesteuert – in einem fir-menweit einheitlichen Tool. Damit besteht Transparenz hinsichtlich Terminen / Ergebnissen / Projekt-besetzung über alle laufenden Produktentwicklungsprojekte. Durch die Integration in SAP BW wird eine projektübergreifende Auswer-tung und Analyse ermöglicht und somit dem Management, den Produkt-managern und den Portfoliomanagern eine schnelle Übersicht über das Projektportfolio geboten. 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. Die SAP-Integration der benötigten Stammdaten (Dokumente, Spezifikatio-nen) garantiert erhöhte Datensicherheit, -aktualität und -verfügbarkeit. 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 Ge-genmaßnahmen eingeleitet. Das Zusammenspiel der Entwicklung mit den nachge-lagerten logistischen Prozessen wird nicht nur durch die übergreifende Projektsteuerung verbessert, sondern auch dadurch, dass die für die späteren Pha-sen 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 Stammdaten-pflegeprozesse durch Workflowtools teilautomatisiert und optimiert werden kön-nen. 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 teilneh-men und durch das System unterstützt werden.


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 Material-stammes (allg. auch als „Artikel“ oder „Artikelstamm“ bezeichnet), wurden be-reits in dieser ersten Phase Werkzeuge entwickelt, die dem Anwender das Ausfüllen der relevanten Datensichten durch die Bereitstellung von Arbeits-listen erleichtern sollten. Diese haben sich in Anbetracht der erheblichen An-zahl 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 Unter-nehmens an optimierten Stammdatenprozessen gerecht zu werden, wurde ein Projekt aufgesetzt, dessen Aufgabe die Abbildung des Materialstammpflegepro-zesses und damit zusammenhängender Produktdaten mittels einer Workflow-Anwendung war. Zum Einsatz kam der von SAP ausgelieferte SAP Business Workflows. Hervorzuheben ist in diesem Zusammenhang, dass bei den zu errei-chenden Zielen den Faktoren „Prozesssicherheit“ und „Transparenz“ eindeutig der Vorrang vor „Geschwindigkeit“ eingeräumt wurde, was bei der Beschrei-bung der Ausgangssituation noch deutlicher wird. Somit war die Herausforde-rung klar formuliert, dass nicht beschleunigende repressive Mittel wie Deadlining und Eskalation sondern anwenderfreundliche Servicefunktionalitäten im Vordergrund standen.


Stammdatengenerierung

InternationaleStamm-

datenpflege

Nationale/LokaleStamm-

datenpflege

Stamm-daten-

verteilung

MonitoringStammdatenpflege

Stammdatengenerierung

InternationaleStamm-

datenpflege

Nationale/LokaleStamm-

datenpflege

Stamm-daten-

verteilung

MonitoringStammdatenpflege

Abb. 117. Systemübergreifender Pflegeprozess

17.1.1 Ausgangszustand der Stammdatenpflege

Um der organisatorischen Aufstellung des Unternehmens auch in der Stammda-tenpflege zu folgen, wurde bei der SAP-Einführung eine zweischichtige System-architektur gewählt, die sicherstellt, dass alle Stammdaten auf internationaler Ebene in Bezug auf ihre Schlüssel und Grunddaten einheitlich sind und sich den-noch regionale Ausprägungen entwickeln können:

Obere Schicht: Pflege des Grunddaten in einem SAP-PLM-System auf inter-nationaler Ebene Untere Schicht: Pflege der Detaildaten in einem lokalen SAP-System

Zwischen den beiden Schichten erfolgt der Datenübergang mittels einer automati-sierten Schnittstelle, wie auch das Prozessdiagramm in Abb. 117 zeigt.

Nachdem als erstes die Grunddaten in der oberen (internationalen) Schicht an-gelegt und in das lokale, europäische System eingespielt wurden, setzte der Pfle-geprozess 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

nicht personalisierten auf Grund der großen Anzahl unübersichtlichen und terminlich nicht gesteuerten

Listenform zur Verfügung. Obwohl dies im Vergleich zu einer völlig unkontrol-lierten Bearbeitung „auf Zuruf“ bereits eine erhebliche Verbesserung darstellte, war die Folge dieser Form der Pflege, dass Materialien

Ausgangssituation 233

nicht in der korrekten Reihenfolge oder 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 Prozess-controllings: Sowohl für den einzelnen Mitarbeiter als auch für die Produkt- oder Prozessverantwortlichen war zu keinem Zeitpunkt transparent, in welchem Pfle-gezustand sich ein Material befand.

Als ein weiterer negativer Aspekt dieses Pflegeprozesses wurde angesehen, dass der Materialstatus zur Steuerung der Verwendbarkeit eines Materials in ande-ren Prozessen nicht verlässlich eingesetzt werden konnte, da es keine klar definier-ten 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 scho-nungslos die Folgekosten von Verzögerungen und Pflegefehlern aufzeigt. Einige Beispiele aus der Praxis seien hier genannt:

Durch die schnelle Produktion werden Etikettenfehler erst nach ca. 10 000-15 000 Einheiten bemerkt, Vorkommen: ca. 6-7 Mal pro Jahr Falsche Formate von Verfallsdaten, bzw. falsche Verfallsdaten werden ca. 5 Mal pro Jahr erzeugt Jährliche Mietkosten für verschollene Paletten aufgrund von fehlendem Eintrag in der Stückliste fielen an in Höhe von € 50 000 Falsche, zu spät oder unvollständig gelieferte Stücklisten erzeugten jährli-che kalkulatorische Kosten in Höhe von € 200 000

Die prozentuale Verteilung der untersuchten Störfaktoren am Gesamtschaden er-gibt sich aus nachfolgender Tabelle:

Tabelle 2. Prozentuale Verteilung der Störfaktoren auf den Gesamtschaden durch fehler-hafte 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


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.


Ausgehend von den vorgenannten Problemfeldern, die sowohl in der Ausge-staltung des Pflegeprozesses an sich als auch in dessen systemtechnischer Unter-stützung liegen, definierten sich die Ziele des Projektes in verschiedenen Bereichen:

1. Prozesssicherheit

Alle Prozesse laufen nach klar definierten Regeln ab Keine „vergessenen“ Materialien Einhaltung der Pflegereihenfolge nach betrieblichen Notwendigkeiten Geordnete Statussteuerung (Materialstatus) durch den Workflow

2. Datenqualität

Die richtigen Mitarbeiter erhalten „ihre“ individuellen Arbeitsaufträge Die Daten können zeitnah erfasst werden

3. Transparenz

Die Mitarbeiter können den Pflegezustand der jeweiligen Materialien im Verlauf des bisherigen Prozesses einsehen Produkt- und Prozessverantwortliche können jederzeit nach unterschiedli-chen Strategien den Pflegeprozess überwachen und bei Bedarf eingreifen

4. Arbeits- und Kosteneinsparung

Reduzierung von Suchaufwand für den Bearbeiter Entlastung von Terminverfolgungs-Aktivitäten Übernahme von automatisierbaren Standardaktivitäten durch den Workflow Reduzierung des Aufwandes für Einarbeitung und Schulung

17.3 Projektmethoden und Projektorganisation

Nach Abschluss der grundlegenden SAP-Einführung sowie einer Stabilisierungs-phase 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 unter-stü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 Hintergrundaktivi-täten, identifiziert und in die Prozesse mit eingearbeitet werden. Konzeption, Rea-lisierung 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 Arbeitsunter-brechungen durch evt. Systemprobleme weitestgehend ausgeschlossen werden.

Die Aufteilung der Ressourcen in Wochen Aufwand während der Projektlauf-zeit erfolgte ungefähr nach Tabelle 3:

Tabelle 3. Aufwand (in Wochen) nach Projektphasen

Phase Phasen-Dauer

Anzahl MA extern

SummeAufwand

extern

Anzahl MA intern

SummeAufwand

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

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 zeitli-che Ablauf sondern die Besonderheiten des Projektes und spezielle inhaltliche As-pekte 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 wie-der verwendet und angepasst werden. Ein Modellierungsbeispiel für einen Teilpro-zess findet sich in Abb. 118. Die Arbeiten wurden weitestgehend von einem branchenerfahrenen Fachberater in Zusammenarbeit mit Key Playern des Kunden durchgeführt.


Die zusätzlich erhobenen Informationen beziehen sich z. B. auf

mögliche parallele Prozesszweige technische Verknüpfungen zu benachbarten Prozessen Details zu Schleifen und ähnlichen steuernden Konstrukten Präzisierungen bei der Zuweisung von Bearbeitern Zusammenfassung von technisch identischen Abläufen zu wieder verwend-baren Unterprozessen Identifikation von Automatisierungspotenzial

InternationaleVorgabedaten

pflegenFERT

Master DataCoordinatorInternational

InternationaleMaterialstammdaten

gepflegt

Materialanfrageliegt vor

MonitoringProzess Stufe 0

InternationaleEntwicklungsdaten

pflegen

ChangeControlStamm-daten

Stammdaten-pflegeprozess

initialisiert

Master DataCoordinatorInternational

informiert

Master DataPfleger

InternationalProduktions-

werkfestlegen

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


17.4.2 Konzeptionsphase

In diesem vier Wochen dauernden Abschnitt des Projektes wurden vom Fachbera-ter sowie einem Workflow-Spezialisten die umfangreichen Anforderungen geord-net und in ein schlüssiges Gesamtkonzept überführt.

Die Anforderungen gliederten sich in unterschiedliche Bereiche:

1. Betroffene Module

Materialwirtschaft (MM) Vertrieb (SD) Produktionsplanung Prozessindustrie (PP-PI) Lagerhaltung (WM) Qualitätsmanagement (QM) Controlling (CO)

2. Beteiligte Datenobjekte

Materialstamm StücklisteKonditionen Kundeneigene Objekte

3. Organisatorische Rahmenbedingungen

Einfache spätere Ergänzung weiterer Objekte und Prozessabschnitte Übersichtliches Erscheinungsbild der jeweiligen Arbeitsaufträge bei den BearbeiternWunsch nach einem hohen Automatisierungsgrad

4. Technische Rahmenbedingung

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) Viele (Steuerungs-) Daten liegen in Kundentabellen vor 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 ge-wä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


2. einer Detailebene, die sämtliche Funktionalitäten wie Dialogbearbeitung, Hintergrundbearbeitung, Bearbeiterfindung, Fehlerhandling in einem gene-rischen Subprozess kapselt. Hierzu folgen weitere Details im Abschnitt 17.5.

Durch dieses Design konnten vor allem die hohen Anforderungen an Erweiterbar-keit, Flexibilität und Wartungsfreundlichkeit erfüllt werden. Nicht verschwiegen werden sollen jedoch die sich aus dem speziellen Design notwendigerweise erge-benden 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 Anforde-rungen im SAP R/3 durch einen Entwickler und Workflow-Spezialisten. Die aus-geführten Aktivitäten waren:

Erstellung der Workflows Programmierung der Steuermechanismen zur Ablage der Regeln für Bear-beiterfindung, Hintergrundaufgaben, Statussteuerung, etc. Customising des Systems: Festlegung von Prozessen durch Einstellung entsprechender Steuerparameter. 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). Erstellung einer kundeneigenen Reporttransaktion, die die Ablaufinforma-tionen zu einem Prozess übersichtlich anonymisiert aufbereitet (im Rahmen der Betriebsvereinbarung mit dem Betriebsrat abgestimmt) 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 et-wa der Ausprägung des beschriebenen Projektes. Der erzielte Benefit entspre-chend der oben beschriebenen Projektziele muss dem folgenden Aufwand gegenübergestellt werden:

Erhöhter Programmieraufwand Hoher Customising- und Testaufwand Intensive Betreuung in der Optimierungsphase (siehe weiter unten)


generischexplizit

Technische Ausprägung

Custo

mis

ing A

ufw

and

nie

drig

ho

ch Projekt

Charakteristik

generischexplizit

Technische Ausprägung

Custo

mis

ing A

ufw

and

nie

drig

ho

ch Projekt

Charakteristik

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 Ge-samtprozesses dar. Ferner war durch den Einsatz der Standard SAP Inbox („Busi-ness 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 Customi-sing einzustellenden (fachlichen) Prozesssteuerung gemacht wurde, mussten sich die (fachlichen) Administratoren der Herausforderung stellen, die Prozesse in al-len 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 Pro-duktivbetriebs 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.


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 Reportingwerk-zeug, das sowohl dem am Pflegeprozess beteiligten Anwender als auch dem Pro-zesskoordinator 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 (ereignisge-steuerte 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 übersicht-lichen 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 zu-nä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 Identifi-kation der allgemeingültigen Prozessfragmente, zum anderen die Definition einer handhabbaren Benutzerschnittstelle, um das eigentliche Prozesswissen in techni-sche Regeln zu überführen. Sind diese beiden Voraussetzungen erfüllt, entstehen hieraus Systeme, die mit einem geringen Modellierungsaufwand für den Basispro-zess 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 Prozess-ablauf oder der Bearbeiterfindung vorgenommen werden, die bei einer 1:1-Modellierung 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.


Die beiden Modellierungsebenen sind (wie im Abschnitt 17.4.2 bereits erwähnt): Obere Ebene: Prozesssteuerungsebene oder Ablaufplan, in der z. B. festge-legt wird, in welcher Reihenfolge die verschiedenen Sichten des Material-stammes gepflegt werden, an welchen Stellen der Materialstatus gesetzt wird oder Stücklisten oder kundeneigene Objekte gepflegt werden sollen. Untere Ebene: In diesem Arbeitsprozess werden einmalig alle Arbeitsfunk-tionalitä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 abge-nommen 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, Bear-beiterfindung 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 Pro-zess, ausgeschiedener Mitarbeiter, etc.) zeitnah und fachkundig behoben werden kann. Hierdurch ist sichergestellt, dass kein Fehler übersehen wird. Hier wurde bewusst zwischen fachlichen und technischen Proble-men des Workflow unterschieden, letztere werden wie üblich von Basis-betreuern ü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 Anwen-dungsfall 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 Mate-rialart, Sparte, Werk, Ladegruppe, Berechtigungsgruppe, Produkthierarchie und weiteren auch etliche kundeneigene Datenfelder. Für jede der Stellgrößen Bearbei-terfindung, 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 er-kennen. In Abb. 121 ist die komplette untere Ebene (Arbeitsprozess) gezeigt, was einen Eindruck von der Prozesskomplexität gibt.


Abb. 120. Ausschnitt aus der Prozesssteuerungsebene

Abb. 121. Arbeitsprozess


17.5.2 Prozessmonitoring

Wie oben bereits erwähnt, sollte ein Reportingwerkzeug bereitgestellt werden, das zwei sich widersprechenden Anforderungen gerecht werden musste:

Das Werkzeug musste sowohl für den Anwender, der am Pflegeprozess be-teiligt ist, als auch für den Prozesskoordinator oder die fachlichen Administ-ratoren eine hohe Informationsdichte bereitstellen aber andererseits auch 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 ge-ben sie zu viele persönliche Daten der Anwender preis, so dass eine Eigenent-wicklung unabdingbar war.

Die gefundene Lösung zeigt nach bestimmten Selektionsparametern wie Mate-rialnummer, 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



Die folgende Zusammenfassung zeigt auf, in welchen Bereichen deutliche Ver-besserungen erzielt wurden:

Die Prozesssicherheit wurde erheblich gesteigert, Pflegereihenfolgen wer-den nun automatisch eingehalten und es werden keine Aktivitäten mehr übersehen. Die Möglichkeiten der Bearbeiter, die Pflegevorschriften ge-wollt oder ungewollt zu umgehen, sind stark eingeschränkt worden. Es wurde eine optimale Prozesstransparenz erreicht, da sowohl die Mitar-beiter im Rahmen des Pflegeprozesses als auch die Prozessverantwortli-chen 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). 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. Die Datenqualität konnte wesentlich verbessert werden, da die Arbeitsauf-träge immer zeitnah an den jeweils verantwortlichen bzw. am besten quali-fizierten Mitarbeiter gesendet werden. 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. Terminverfol-gung 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. Durch das effektive Fehlerhandling, bei dem jedes (inhaltliche) Problem automatisch bei den fachlichen Administratoren landet, ist eine kontinuier-liche Verbesserung der Prozesse sichergestellt, da sowohl Fehler im Pro-zess als auch solche durch falsche Bearbeitung unmittelbar auffallen. So können z. B. unsichere Mitarbeiter direkt angesprochen werden und Prob-leme frühzeitig durch Schulung oder Abstimmung beseitigt werden. Die klare Trennung zwischen technischer und fachlicher Administration des Systems sorgt dafür, dass weder die Prozessspezialisten mit techni-schen 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% Ver-besserung in der Stammdatenpflege bringt, berechnet sich die Amortisationszeit der Projektes mit einem ungefähren Aufwand von € 220 000 zu 7 Monaten.


Die Fehlerbehebung bei unpassendem Customising, z. B. durch geänderte Prozes-se, erfordert zwischen 1h und 3h pro Woche und wird durch den internen (fachli-chen) 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 stabi-les Workflow Design spricht.

18 Spezifikation von Produkten in der Stahlindustrie

Der hier im Fokus stehende Gesamtkonzern entstand durch den Zusammenschluss meh-rerer Einzelkonzerne. Er erwirtschaftet in mehr als 60 Ländern mit über 110 000 Be-schäftigten aktuell einen Umsatz von etwa 35 Mrd. Euro. Um dies zu erreichen, wer-den ca. 50 Mio. t Stahl erzeugt.

Um den Herausforderungen eines welt-weit operierenden Unternehmens mit den ebenfalls weltweit agierenden Kunden be-gegnen zu können, müssen insbesondere die Produktdaten und Stahlspezifikationen allen Unternehmensbereichen in einheitli-cher Form zur Verfügung stehen. Die Definition und Einführung eines solchen Produktkataloges sowie der damit in Zusammenhang stehenden Prozesse Produkt-spezifikation und Angebotserstellung werden in dieser Fallstudie dargestellt.


Insbesondere durch den Zusammenschluss der Unternehmen ergab sich die Not-wendigkeit, 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 produzier-ten Stahlsorten zu erlangen und gleichzeitig diese Informationen für die Entwick-lung zukünftiger Produkte zu verwenden.

Nachdem bereits in einzelnen Teilbereichen des Konzerns grundsätzliche Ent-scheidungen 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 Orga-nisationseinheit andocken kann.



Die Spezifikation neuer Stahl-Produkte durch die metallurgischen Experten findet in enger Abstimmung mit dem Kunden statt. Dabei bedeutet Spezifikation in erster Li-nie die Festlegung physikalischer Eigenschaften. Diese Spezifikation wurde teilwei-se zentral für weltweit operierende Großkunden durchgeführt, teilweise direkt von den lokalen Werken. Damit fehlte dem Unternehmen die Übersicht über das Pro-duktangebot. 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 Pro-duktkataloges definiert:

1. Prozesssicherheit

Standardisierung der Geschäftsprozesse für Anfrage- und Auftragsbearbeitung Standardisierung zur Klärung von technischer Machbarkeit Unterstützung bei der Suche nach vorhandenen Spezifikationen und deren Änderung

2. Transparenz

Unternehmensweit einheitliche Produktbeschreibung Verfügbarkeit vollständiger und aktueller Spezifikationen Vergleichbarkeit der Spezifikationen Austausch von Spezifikationen zwischen Werken Soll-Ist-Vergleiche für Ziel- und Angebotsspezifikation Einfache Machbarkeitsprüfung und Vergleich der Machbarkeiten

3. Kosteneinsparung

Übersicht über das angebotene und produzierte Produktspektrum als Basis für die zukünftige Produktstrategie Auswertung des Angebotsspektrums zur Entscheidung über Produktionsverlagerungen Zukunftsweisende Standardtechnologie zur Produktspezifikation

18.3 Projektablauf und Projektorganisation

Um eine effiziente Definition und Einführung des unternehmensweiten Produktka-taloges zu gewährleisten, wurde zunächst ein Business Blueprint erstellt. Im Rah-men dieses Blueprints wurden die Kernprozesse und Anforderungen analysiert.


Auf dieser Basis wurden SAP-Module ausgewählt und grob spezifiziert. Der Net-weaver-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, fachbe-reichsspezifischen sowie IT- und SAP-bezogenen Lasten- und Pflichtenheften und erfolgte nach dem im Konzern vorgegebenen Standard.

Das Projekt-Team setzte sich zusammen aus:

Fachbereichs-Experten Vertretern der Informatik-Abteilung Vertretern der IT-Abteilung SAP-Basisteam Externen Coachs

Darüber hinaus wurde ein Projektleitungsgremium gebildet, das aus dem Projekt-leiter aus der Informatik-Abteilung sowie dem externen Projektleiter des Coach-Teams und einem Assistenten bestand. In kritischen Fragen wurden die Fachbe-reichs-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 Auf-wands und der Konsequenzen wurde dann die beste Alternative ausgewählt und implementiert. Dieses Vorgehen ermöglichte eine schnelle Reaktion auf wech-selnde Randbedingungen.


Nachfolgende Graphik verdeutlicht die einzelnen Bausteine der PLM-Lösung:

Management des Kundenanfrage- und Angebotsprozesses mit der Verbin-dung von technischen und kaufmännischen Daten sowie der Spezifikationen Auswahl einer geeigneten Angebotsspezifikation aus einer Datenbank von Referenz-Spezifikationen Repräsentation der Zielspezifikation mit den werks- und kundenspezifi-schen Parametern, wie z. B. Gewicht, Abmessungen eines Coils etc. Repräsentation der neutralen Spezifikation ohne werks- und kundenspezifi-sche Parameter Abbildung von Machbarkeiten, d. h. der technischen Möglichkeiten der WerkeManagement von Regeln für Kundenverhalten und Abhängigkeiten der Produktspezifikation


Referenz-Datenbank

Technische

Ziel-Spezifikation

Näherungs-suche

Machbarkeit

Neutrale Produkt-

Spezifikation

Produktanfrage

Kunden-Spezifikation

Regeln bzgl. Kunden

und Produkten

Abb. 123. IT-Funktionsmodule im Spezifikationsprozess

Zur Umsetzung der Lösung wurden folgende SAP-Module ausgewählt:

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 ei-ner Spezifikationshierarchie werden etwa 600 Spezifikationsparameter ver-waltet.SAP iPPE: Zur Repräsentation der Kundenanfrage und der angebotenen Al-ternativen 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 verschie-denen Spezifikationen und Status abzubilden. SAP PLM DVS: Das Dokumentenmanagement wird zur Verwaltung der zu den Spezifikationen gehörenden Unterlagen wie Normen sowie zur Ablage


der Machbarkeitsdiagramme genutzt. Zusammen mit einer Klassifizierung und entsprechenden Objektverknüpfungen kann der Anwender sehr einfach auf alle Unterlagen zugreifen. WAS: Auf alle von SAP verwalteten Daten kann über den Web Application Server (WAS) zugegriffen werden. Der WAS ist Teil der NetWeaver-Architektur 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 Weite-ren war die Benutzerakzeptanz durch das bekannte Medium Internet direkt gegeben. 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 Spezifikatio-nen von der Regelmaschine generiert und ausgewertet werden.

Product Classes:automotive, construction, household appliances, packaging

as requestedspec_B

Steel

ApplicationAutomotive

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

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

as producedSite XYZ,

spec_C

as requestedspec_A

as orderedspec_B

ApplicationHousehold Appliance

Product Classes:automotive, construction, household appliances, packaging

as requestedspec_B

Steel

ApplicationAutomotive

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

Functional Structure:referential specification, commongeneric specification, ...

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

as producedSite XYZ,

spec_C

as requestedspec_A

as orderedspec_B

Documents:documents, diagrams, ...

ApplicationHousehold Appliance

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



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:

Der Katalog bietet eine Übersicht über das gesamte Produktspektrum. Die Standardisierung der Spezifikationen sorgt für eine verbesserte Stammdatenqualität, die generell Grundlage und Erfolgsfaktor für standar-disierte Geschäftsprozesse ist. Die um den Katalog implementierten Anfrage- und Spezifikationsprozesse liefern eine deutliche verbesserte Qualität der Angebote und reduzieren die Kosten für die Anfragebearbeitung. Die zentral verfügbare und standardisierte Datenbank für die Spezifikatio-nen der Referenzdaten und Produkte dient dem Unternehmen als Basis für strategische Entscheidungen. Die einheitliche Spezifikation sorgt für eine verbesserte Flexibilität in der Produktion und beschleunigte Kunden-Service-Prozesse. Durch die Standardisierung der Prozesse und Implementierung in SAP können die Anfrage- und Spezifikationsprozesse nachvollzogen werden. Durch den Coaching-Ansatz konnte das Kundenteam sehr schnell Aufga-ben 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 Fein-chemikalienhersteller, der mit etwa 4000 Mitarbeitern an 18 internationalen Produk-tions- und Entwicklungsstandorten vertreten ist. Als Teil eines großen internationa-len 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 Produkt-entwicklung eine besondere Herausforderung dar, die den Geschäftserfolg ent-scheidend beeinflusst. Die mangelnde Transparenz führte z. B. in der Vergangen-heit dazu, dass Kundenanfragen abgelehnt wurden, da an einem Standort keine passenden Produktionsstätten existierten, obwohl die Anfrage an anderen Stand-orten 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.


Der Geschäftserfolg bei der Herstellung von Feinchemikalien ist stark abhängig von der Schnelligkeit der Produktentwicklung und der Bearbeitung von Kunden-anfragen sowie von Kosteneffizienz, Transparenz und Qualität.

Der betrachtete Prozess ist eine kundenspezifische Auftragsabwicklung mit an-schließender Produktentwicklung und Herstellung. Nach der Kundenanfrage wird zunächst geprüft, ob der Auftrag abgewickelt werden kann. Entscheidende Fakto-ren 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 Produkt-entwicklung, falls nicht bereits der Kunde entsprechende Synthesewege zur Her-stellung liefert. Die Entwicklung / Produktion ist in der Regel dreistufig: Entwick-lung 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-


den sollte eine Verbesserung hinsichtlich Durchlaufzeit, Transparenz, Kosteneffi-zienz 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 Auf-tragsinformationen sowie die gesamte Dokumentation der Entwicklung und Pro-duktion 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 ge-währleistet werden, zu allen abgeschlossenen Projekten sollten die wesentlichen Projektinformationen zu jeder Zeit recherchierbar vorgehalten werden.


Die Projektdurchführung gliederte sich in die folgenden Phasen:

Definition und Priorisierung der Anforderungen Evaluierung verschiedener auf dem Markt befindlicher Standardsoftware Feinkonzept zur Erstellung einer Individuallösung Softwarespezifikation Implementierung TestsSchulung der Key User Pilotphase Rollout

Das Projektteam befasste sich zunächst mit der Definition und Priorisierung der Anforderungen. Diesem Projektteam gehörten Vertreter aus allen beteiligten Be-reichen 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 Software-entwicklern durchgeführt. Die Testphase untergliederte sich klassisch in die Ent-wicklertests, 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.


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


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 wur-den die Dialoge zur Bearbeitung eines Projektes von der Kundenanfrage bis zur Auslieferung programmiert. Die Business-Logik befindet sich in SAP R/3 und be-dient sich größtenteils der Standardmodule und -funktionen wie z. B. Projektver-waltung (SAP PS), Dokumentenverwaltung (SAP DVS), SAP Finance und Controlling (SAP FI/CO) sowie dem Modul SAP EH&S zur Verwaltung von Spe-zifikationen.

Anfrage / Idee Marketing Entwicklung + Produktion Auslieferung

?

Evaluation

Pilot-produktion

Produktions-linie

Kilolabor-phase

Labor-phase

!

Anfrage / Idee Marketing Entwicklung + Produktion Auslieferung

?

Evaluation

Pilot-produktion

Produktions-linie

Kilolabor-phase

Labor-phase

!

Abb. 125. Schematische Darstellung des Produktentwicklungsprozesses

Der Prozess gliedert sich in 7 Phasen, welche workflowunterstützt bearbeitet wer-den 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, Kunden-attraktivität oder technologischer Fit bewertet. Anhand verschiedener Checklisten


folgt die Bearbeitung der relevanten F&E-Phasen. Ein Steering Committee ent-scheidet softwaregestützt über alle Phasen eines Projektes (Zeit, Budget, Ressour-cen, 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 Dokument-management-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 Synthese-wege, welche mit dem integrierten Tool Chemdraw direkt in der HTML-Oberflä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ämtli-che Synthesewege nach der gewünschten Information durchsucht werden. Dies macht das Tool zu einem leistungsfähigen Knowledge-Management-System.


Folgende Verbesserungen wurden durch die Vereinheitlichung des Prozesses und durch das Tool erreicht:

Transparenz über alle Kundenanfragen und Projekte Vergleichbarkeit der Projekte Steuerung aller laufenden Projekte durch ein Steering Committee Ermöglichen eines Projekt-Portfoliomanagements Zentrale Dokumentation aller Projekte Schaffung einer Knowledge Base zu Recherchezwecken Kostenerfassung, Kostentransparenz

Literaturverzeichnis

[1] ANSI IGES. Initial Graphics Exchange Specification Version 6.0, ANSI Standard

[2] Allen, T. 1987. Managing the Flow of Technology, Cambridge, MA, MIT Press 1987

[3] Berth, R.: Der kleine Wurf, Manager Magazin 23/1993, S. 214 – 227 [4] Bratthall, L.; Hasselberg, J.; Hoffmann, B.;. Korendo, Z; Schilli, B; Gunder-

sen, L.: Component Certification – What is the Value?, 4th International Conference on Product Focused Software Process Improvement, Rovaniemi, Finland, December 2002

[5] Bullinger, H.J.: Forschungs- und Entwicklungsmanagement in der deutschen Industrie, in: A.-W. Scheer (Hrsg.), „Simultane Produktentwicklung“, Mün-chen 1992

[6] Bullinger, H.J.; Scheer, A.-W. (Hrsg.): Service Engineeering, Springer, Ber-lin 2003

[7] Corsten, Hans: Lexikon der Betriebswirtschaftslehre, 2. Aufl., R. Oldenbourg Verlag, München 1993

[8] 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

[9] 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

[10] Eigner, M.: Engineering Database – Strategische Komponente in CIM-Konzepten, Hanser Verlag, München 1991

[11] Eisert, U. et. al.: mySAP Product Lifecycle Management, SAPPress, Bonn 2000

[12] Franke, H.-J. et. al.: Variantenmanagement in der Einzel- und Kleinserien-fertigung, Hanser Verlag, München 2002

[13] Gochermann, Josef: Kundenorientierte Produktentwicklung. Marketingwis-sen für Ingenieure und Entwickler, Wiley-VCH, Weinheim 2003

[14] Grabowski, H.: Entwerfen in Konstruktionsräumen zur Unterstützung der Teamarbeit. in: A.-W. Scheer (Hrsg.), „Simultane Produktentwicklung“, München 1992

[15] Grabowski, H.; Lossack, R.; Weißkopf, J.: Datenmanagement in der Pro-duktentwicklung. 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 Wissenschafts-verlag, 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 Produkt-entwicklung

[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, Um-setzung, KGSt-Bericht, Köln 5/1993

[25] Klabunde, Steffen: Wissensmanagement in der integrierten Produkt- und Pro-zessgestaltung. 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 Wissenschafts-verlag, München 1999

[29] Langenwalter, G. A.: Enterprise Resources Planning And Beyond – Integrat-ing 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.: Re-search and Innovation in the Modern Corporation. Macmillan, London 1972

[32] Nowak, T. 2002, et. al. Synchronous collaborative design system – function-ality and architecture, 9th ISPE international conference on concurrent engi-neering, 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 Cam-pana & 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 computerge-steuerte Industriebetrieb. 4. Aufl., Springer, Berlin 1990

[41] Scheer, A.-W.: Wirtschaftsinformatik – Referenzmodelle für industrielle Ge-schä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: In-dustrie Management 01/2004, S. 14 – 21.

[44] Scheer, A.-W.; Thomas, O.; Seel, C.; Martin, G.; Kaffai, B.: Geschäftspro-zessorientierte Software-Architekturen: Revolution auf dem Softwaremarkt? In: Dadam, P., Reichert, M. (Hrsg.): Informatik 2004 – Beiträge der 34. Jah-restagung 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 sup-pliers 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“, Sprin-ger, 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ün-

chen 1999[51] W3C XML, World Wide Web Consortium [52] Woods, Dan: Packaged Composite Applications, O’Reilly & Associates, Se-

bastopol 2003

260 Literaturverzeichnis

[53] Zellner, Gregor: Beziehungsmanagement im Fokus – Ergebnisse einer empi-rischen Untersuchung, Universität St. Gallen (HSG), Institut für Wirtschafts-informatik