Ausgangssituation

Ein weltweit agierendes Medizintechnik-Unternehmen mit über 50.000 Mitarbeitern in Europa, Amerika und Asien verfügt über mehrere relativ unabhängige Geschäftsbereiche mit unabhängigen Produktlinien. Die Fertigung ist in allen Geschäftsbereichen aufgrund geringer Stückzahlen und hoher Produktwerte wenig automatisiert. Die Durchlaufzeiten in der Entwicklung und Fertigung sind durch administrative Abläufe und regulatorische Anforderungen sehr hoch. Daten sind im Unternehmen an vielen Orten verteilt. Informationen haben dabei an unterschiedlichen Ablageorten unterschiedliche Inhalte und Änderungsstände, wodurch es vor allem bei Fertigungsanläufen und Änderungen zu teuren Verzögerungen im Bereich vieler Monate bis hin zu Jahren kommt. Durch den hohen manuellen Arbeitsanteil kann die Fertigung nur im 2-Schicht-Betrieb ausgelastet werden. Die über alle Geschäftsbereiche zentralisierte Teilefertigung ist dabei ein Nadelöhr, das die Montage von Komponenten und auch die Endmontage immer wieder behindert, so dass Kundenaufträge verspätet ausgeliefert werden. Die Lieferzeiten sind für Kunden unakzeptabel hoch, so dass sich einige Kunden trotz hervorragendem Image beim Wettbewerb bedienen.

Eine weitere Herausforderung ist die Absicherung von Expertenwissen. Vor allem in einem Geschäftsbereich ist viele Jahre erfolgsrelevantes Wissen nicht im Unternehmen dokumentiert worden und mit dem Renteneintritt und Fluktuation unwiederbringlich verloren gegangen.

Zum Projektstart gibt es nur in einem der Geschäftsbereiche eine produktive PLM-Umgebung. Die anderen Bereiche nutzen nur die PDM-Funktionalität. Nur in der zentralisierten Teilefertigung ist ein MES-System im Einsatz. Trotzdem ist die Fertigung wenig automatisiert. Alle anderen Bereiche arbeiten ohne MES-Unterstützung. Das ERP-System ist in allen Geschäftsbereichen die zentrale Drehscheibe zur Datenhaltung und Prozessteuerung. Auch in diesem Bereich müssen viele Arbeitsprozesse manuell unterstützt werden. Das Fehlerpotenzial ist entsprechend hoch.

Über den Zustand und die exakte Konfiguration der im Markt befindlichen Produkte hat das Unternehmen keine Kenntnis, weil die Veränderungen durch Serviceeinsätze nicht dokumentiert werden. Aus diesem Grund kommt es immer wieder zu erfolglosen und teuren Einsätzen, weil die benötigten Teile für den Service nicht vorhanden sind.

Fragestellung

• Die Marktherausforderung lautet: wie können die Durchlaufzeiten deutlich reduziert, die Fertigung automatisiert und Expertenwissen im Unternehmen gesichert werden?
• Wie kann der Fehlerfaktor Mensch so unterstützt werden, dass Fehlerkosten reduziert werden?
• Wie können inkonsistente Informationen vermieden und manuelle Arbeitsabläufe reduziert werden?
• Und wie kann in Zukunft die Information über den aktuellen Zustand der im Einsatz befindlichen Produkte sichergestellt werden?
• Wie kann die Toolauswahl in den Bereichen so reduziert werden, dass idealerweise nur noch ein Tool mit dem aufgabenspezifischen Informationen pro Bereich genutzt werden muss?
• Wie kann die Mehrfacherfassung von daten in verschiedene Tools vermieden werden?
• Wie kann der Aufwand in die Wartung einer Vielzahl von Anwendungen und deren Schnittstellen untereinander reduziert werden?
• Und wie können die vielen alternativen Daten- und Informationsablagen beseitigt werden?

Lösung

Alle Beteiligten haben erkannt, dass die Datenhaltung vereinheitlich werden muss, indem sich die zukünftigen 3 Hauptsysteme der Lösung in den Bereichen ERP, PLM und MES abgleichen und damit einen Closed Loop bilden. Im Zuge einer Toolkonsolidierung soll die Funktionalität der Mehrzahl aller Tools in diese 3 Hauptanwendungen integriert werden. Ziel dabei ist, dass für jede Information in jedem System ein einheitlicher Datenstand entsteht. Die bestehenden PDM-Systeme der Geschäftsbereiche werden vereinheitlicht und im ersten Schritt zu einem vollwertigen PLM-System ausgebaut, das die Disziplinen Systems Engineering, CAD-Daten Management, Produktdaten Management, BOM-Management (Engineering BOM und Manufacturing BOM), Release sowie Change Management und Konfigurationsmanagement umfasst. In einem parallelen Schritt wird das Material Management und das Service Management (inkl. Service BOM) ergänzt. Das bestehende MES-System wird auf alle Geschäftsbereiche ausgerollt und in allen Fertigungsdisziplinen besser ausgenutzt. Dazu gehören auch die Einführung der digitalen Arbeitsanleitung und die Qualitätssicherung in der Montage durch elektronische Drehmomentschrauber, deren Drehmomentwerte automatisch abgespeichert und damit nachvollziehbar gemacht werden. Dafür ist es notwendig, die Manufacturing BOM inklusive Produktdatenvisualisierung an das MES-System zu übergeben. Außerdem muss die Prozessstückliste (BOP) aufgrund der Anforderungen beim Qualitätsmanagement für jede einzelne Schraube deutlich granularer und deshalb im PLM-Bereich definiert, gepflegt und dann direkt an das MES-System übertragen werden. Die teure und aufwendige Definition und Pflege der Prozessstückliste (BOP) im ERP-System entfällt. Die Ressourcenstückliste (BOR) wird aufgrund der Personal-, Anlagegut- und Beschaffungsverwaltung im ERP-System belassen. Im Servicebereich werden Einsätze im PLM-System digital dokumentiert und in die Service BOM übernommen, so dass die aktuelle Konfiguration bekannt ist. Zusätzlich soll die Service BOM für zukünftige Add-On-Services als digitaler Zwilling dienen. Alle 3 Hauptsysteme sind über Schnittstellen verbunden und es wird sichergestellt, dass die Datenstände in allen Systemen einheitlich bleiben. Das Change Management über alle 3 Hauptsysteme wird über gegenseitiges Triggern und einen Webclient des PLM-Systems realisiert.

Umsetzung

Für die Architektur des Closed Loop ist es notwendig, das führende System zu definieren. Da das ERP-System die meisten Bestandsdaten hat und bereits unternehmenskritische Prozesse steuert, wird das ERP-System als führendes System und die Materialnummer als führender Index in den anderen beiden Systemen festgelegt. Die CAD-Datenanbindung ist durch die bereits  bestehende PDM-Funktionalität gegeben. Im ersten Schritt wird aus der Design BOM anhand eines Beispielprodukts die Engineering BOM abgeleitet und die dafür notwendigen Anpassungen umgesetzt. Im nächsten Schritt wird die Engineering BOM mit allen möglichen Varianten und Optionen überladen und über eine professionelle Konfigurationsmanagement-Lösung verwaltet. Über das Konfigurationsmanagement wird die Manufacturing BOM definiert.

Eine parallele Aufgabe ist der Aufbau der generischen BOM im Bereich Systems Engineering, in welcher die Spezifikationen, Zertifizierungen, die Material Compliance und die Softwareentwicklung einzubinden sind. Aus Inhalten der generischen BOM und der Design BOM wird die Engineering BOM abgeleitet. Geometriedaten aus dem ECAD-Bereich werden über das Mechanische CAD-System in die Design BOM übernommen. Produktdaten aus dem ECAD wurden grundsätzlich nicht übernommen. Die über das ECAD PDM gesteuerte unternehmensweite Standardteileverwaltung ist bereits mit der CAD-Lösung verbunden, ebenso die branchenspezifische Klassifizierungslösung zum Auffinden von Einzelteilen und Komponenten. Diese Klassifizierungslösung muss allerdings im PLM-System verfügbar gemacht und Workflows zur Anlage neuer Standardteile müssen im PLM-System zur Verfügung gestellt werden.

Die bestehende Anbindung des PDM-Systems an das ERP-System wird im Laufe des Projekts immer weiter ausgebaut, so dass nach und nach alle automatisierbaren Prozesse umgesetzt werden.

Das Projekt hatte mit der erfolglosen Ableitung der Manufacturing BOM aus der Engineering BOM allerdings einen herben Rückschlag zu verkraften, weil damit auch die Vollendung des Closed Loop Richtung MES-System unterbrochen war. Die Entwicklungsarbeit des PLM-Lieferanten zur Lösung der Ursache hat 2 Jahre in Anspruch genommen und das Projekt wurde in dieser Zeit eingefroren. Die Wiederaufnahme läuft noch und der weitere Verlauf lässt vermuten, dass die geplante Lösung letztendlich umgesetzt werden kann.

Projektmethode

Das Projekt wurde von Anfang an agil aufgesetzt und mit SAFe bis auf Programm-Ebene skaliert. Eingebundene Mitglieder von Lösungs- und Steuerungsteams wurden mustergültig geschult und durch erfahrene Agile Master unterstützt. Für mich war es die erste Berührung mit dem Skalierungsframework SAFe. Lösungsteams haben mit einer Mischung aus Scrum und Kanban gearbeitet (Scrumban). Ein Sprintzyklus umfasste 2 Wochen und ein Product Increment umfasste 5 Sprints. Der 5. Sprint diente dabei zum konzentrierten Bugfixing und zur Vorbereitung, Durchführung und Nachbereitung des PI Meeting. Ein Business Analyst hat jeweils zwei Unternehmensbereiche bei der Definition von Anforderungen unterstützt und Mitglieder der Fachbereichsteams geschult. Die Anforderungsermittlung wurde zu Beginn anhand eines MVP und in der Folge mit dem jeweils aktuellen Release durchgeführt.

Herausforderung

Die Unabhängigkeit der Geschäftsbereiche führte zu sehr unterschiedlicher Projektunterstützung bis hin zur Verweigerung. Während die ersten Geschäftsbereiche Standards setzten, mussten sich Nachzügler durch ein aufwendiges Change Management quälen und die kaum vorhandene Motivation wurde dadurch weiter reduziert. Vorreitende Geschäftsbereiche haben ihre Lösungen bei Änderungswünschen maximal verteidigt, weil sich diese bereits im Produktivbetrieb befunden haben.

Das Unternehmen hat die Mitarbeiter aus den Fachbereich größerer Geschäftsbereiche (vor allem Nachzügler) nicht anhand notwendiger HR-Programme auf die Veränderungen vorbereitet. Dadurch fand weder eine Anpassung der Unternehmensprozesse noch eine Entwicklungszielplanung für die betroffenen Mitarbeiter statt – geschweige denn die dann notwendigen Zielgespräche mit den Mitarbeitern. Aus diesem Grund haben diese Geschäftsbereiche und deren Fachbereiche Mitarbeiter nicht für die Lösungsdefinition freigestellt. Die Lösungsermittlung erfolgte deshalb über ein Prozess-Mapping von Wertstromanalysen mit den Zielprozessen. Eine Mitarbeiterakzeptanz war nie herzustellen. Auf der anderen Seite haben die vorreitenden Geschäftsbereiche Fachbereich-Projektteams mit erfahrenen Key-Usern gebildet und Ziele vorgestellt, welche dann von Projektteammitgliedern erarbeitet, in den Fachbereichen abgesichert und letztendlich mit großer Akzeptanz anhand von Pilotprojekten eingeführt wurden.

Die Nutzung der ERP-Materialnummer als Teilenummer im PLM-System hat dazu geführt, dass wichtige PLM-Standardfunktionalität nicht mehr funktioniert hat. Ursache war auch, dass die Teilenummer der CAD- und Produktbestandsdaten im PDM-Bereich (Design BOM) sich von der neuen Teilenummer der Engineering BOM (Materialnummer aus dem ERP-System) unterschied. In der Gesamtarchitektur des Closed Loop war das allerdings das kleinere zu akzeptierende Übel.

Sowohl das PLM-System als auch das MES-System haben im Laufe des Projekts noch nicht die notwendige Funktionalität zur Verfügung gestellt. Das PLM-System konnte Altdaten nicht korrekt visualisieren, weil in den Altdaten entweder die absolute “oder” die relative Transformationsmatrix zur Verfügung stand. Die Visualisierung der Baugruppen in der logistisch neu sortierten Manufacturing BOM war deshalb unkorrekt. Die Anreicherung der Altdaten war unpraktikabel, weil diese häufig wiederverwendet und dabei in unterschiedlichen Versionen geändert wurden und das Ergebnis einer Anreicherung über mehrere Versionsstände hinweg zu einem unakzeptabel schlechten Ergebnis geführt hätte. Auch das Handling von zusätzlichen Stückzahlen im Vergleich zu den Konstruktionsdaten wie. z.B. bei Normteilen (z.B. Befestigungskits) war eine unerwartete Herausforderung. Aus diesem Grund konnte im ersten Anlauf keine Visualisierung des Fertigungsauftrags aus der Manufacturing BOM in das MES-System zur Verfügung gestellt werden. Die Folge war, dass weder die digitale Arbeitsanleitung noch die Qualitätssicherungslösung mit den elektronischen Drehmomentschraubern in Betrieb genommen werden konnte. Stattdessen musste die Manufacturing BOM wie bisher ohne Visualisierung im ERP-System von der Engineering BOM aus dem PLM-System abgeleitet werden. Dadurch wurde die Prozessstückliste (BOP) nicht wie ursprünglich geplant im PLM-Bereich, sondern wie bisher in abgespeckter Form im ERP-Bereich erzeugt und dann zusammen mit der Ressourcenstückliste (BOR) an das MES-System weitergegeben. Die beabsichtigte Optimierung der Fertigung war zu diesem Zeitpunkt nicht möglich. Erst in einem 2 Jahre späteren Schritt könnte diese Herausforderung vom PLM-Anbieter gelöst und damit der Weg für eine direkte Übergabe von PLM zu MES eröffnet werden. 

Das MES-System war als Standardsystem mit unterschiedlichen Branchenlösungen ausgelegt. Das Unternehmen hatte jedoch alle Fertigungsdisziplinen inklusive Einzelteilefertigung, Elektronikfertigung und Montage in einem Haus vereint und muss dabei strenge Compliance-Vorgaben einhalten. Trotzdem soll das bestehende MES-System aufgrund der bereits vorgenommenen Implementierungen übernommen werden. Erst spät hat sich der Anbieter der MES-Lösungen dazu bereit erklärt, die Software im Projekt so an die Kundenbedürfnisse anzupassen, dass nahezu alle Anforderungen erfüllt werden können. Inzwischen hatte das Unternehmen bereits die Implementierung der im ERP-System enthaltenen MES-Lösung begonnen. Der Ausgang ist offen und das Ziel des Closed Loop Manufacturing gemäß ursprünglicher Zielsetzung ist bis heute nicht erreicht.

Eine neue Plattformstrategie des PLM- und MES-Anbieters zeigt jedoch eine vielversprechende Lösung auf.

Projektinformationen

Projektdauer: 1,5 Jahre bis zum Project Freeze

Projektteam: Start mit 1 Solution Architekten, 18 Mitglieder in 2 Teams kurz vor Project Freeze

Projektbudget: Beauftragung im 3-Monats-Abstand auf Basis des Projekterfolgs

Fazit

Dieses Projekt ist ein gutes Beispiel dafür, dass eine mustergültige Projektvorbereitung und Projektdurchführung kein Garant für einen positiven Projektausgang ist. Agile Projektmethoden empfehlen sich immer dann, wenn der Weg zum Ziel unbekannt ist. Das schließt auch mit ein, dass für das Projektziel notwendige Lösungen und Werkzeuge nicht zur Verfügung stehen. Genau das ist hier passiert. Ganz am Ende des Projekts hätte das Projekt möglicherweise schneller eingefroren werden müssen, um Budget und Ressourcen zu schonen. Meiner Ansicht nach war dies der einzige Punkt, bei dem der Solution Manager in alte Verhaltensweisen einer Planungsorganisation zurückgefallen ist und das Projekt durch eine Verzögerung der Freeze-Entscheidung und Hoffnung auf eine Lösung nicht mustergültig gehandelt hat. In der Agilität ist ein Freeze oder Stopp kein Versagen, sondern elementarer Erfolgsbestandteil zur optimierten Mittelverwendung.

Mein Arbeitgeber

Mein Arbeitgeber hat die Lösungsteams für die PLM-Implementierung, die Business Analysten und einen Solution Architect auf Solution Ebene für den gesamten Closed Loop gestellt.

Meine Rolle

Ich hatte im Projekt die Rolle als Business Analyst und war dabei für die Ermittlung der Anforderungen, die Beratung mit Good Practices anhand des MVP und die Lösungsermittlung zusammen mit den Technical Architects auf Team-Ebene und dem Abgleich mit dem Solution Architect auf Solution Ebene zuständig. Die Anforderungsermittlung habe ich teilweise mit Kunden-Projektteams und teilweise auf Basis von Wertstromanalysen sowie davon abgeleiteter Prozess- und Daten-Mappings durchgeführt, die in der Folge durch mehrere Workshop-Runden verifiziert und angepasst wurden. Zusätzlich habe ich die Fachbereich-Teams für die Anwendung geschult, dafür notwendige Schulungsunterlagen erstellt, die Technical Architects beim Daten- und Prozess-Mapping unterstützt, einige kleine Anforderungen implementiert, die Abstimmung mit dem ERP-Team übernommen und das Solution Management bei der Vorbereitung und Durchführung der PI-Meetings unterstützt. Meine indischen Kollegen habe ich beim Einleben und Behördengängen unterstützt.