CONTACT Software Blog

PLM-Einführung ist ein Mannschaftssport

Man sollte meinen, dass die PLM-Einführung dank vorkonfigurierter Software-Lösungen und standardisierter Middleware-Technologie für die Integration der Anwendungen einfacher geworden sei. Wenn man einigen Herstellern glauben darf, funktionieren ihre Lösungen sozusagen out of the box, das heißt man braucht sie nur noch auszupacken und einzuschalten. Leider sieht die Realität anders aus: „Der Leidensdruck hat eher noch zugenommen“, urteilte Prof. Martin Eigner der auf dem diesjährigen PROSTEP iViP-Symposium einen Workshop zum Thema „Future PLM“ koordinierte. Im Rahmen dieses Workshops wurden die Teilnehmer aus der Automobil- und Luftfahrtindustrie befragt, wo sie der Schuh am meisten drückt: Ein wunder Punkt ist und bleibt die Implementierung, das heißt die vielen Systeme, Schnittstellen, Migrationen oder Inkompatibilitäten.

Der Grund für den scheinbaren Widerspruch ist relativ simpel: Zwar lassen sich die PLM-Lösungen heute einfacher und schneller implementieren, aber gleichzeitig haben Umfang und Komplexität der Implementierungen deutlich zugenommen, weil die Lösungen mehr leisten und mehr leisten sollen als noch vor zehn Jahren. Die Kunden sind anspruchsvoller geworden: Es geht nicht mehr nur ein bisschen lokale CAD-Datenverwaltung, sondern um die Unterstützung des gesamten Entwicklungsprozesses unter Einbeziehung verschiedener Disziplinen (Stichwort Mechatronik-Entwicklung), Standorte und gegebenenfalls auch der externen Partner. Das untermauern die anspruchsvollen PLM-Projekte, die heute in der Industrie realisiert werden.

Vor kurzem habe ich einen renommierten Automobilzulieferer besucht, der gerade seine alte Zeichnungsverwaltung durch eine umfassende PLM-Lösung ersetzt hat. Multi-CAD-Datenmanagement, Stammdatenverwaltung mit ERP-Anbindung, Dokumentenmanagement mit Office- und Email-Integrationen, Projektverwaltung, Freigabe- und Änderungswesen etc. wurden auf einen Schlag an mehreren Standorten weltweit eingeführt, weil die Anwender bei vielen Projekten standortübergreifend zusammenarbeiten. Ein riesiger Berg an CAD-Daten und anderen Unterlagen musste dazu in die neue PLM-Umgebung übernommen werden, was natürlich mehr Zeit in Anspruch nahm als geplant. Der Aufwand für die Datenmigration wird bei PLM-Implementierungen immer noch gerne unterschätzt.

PLM-Projekte dieser Größenordnung mit Beteiligten aus unterschiedlichen Abteilungen, Standorten und Ländern und Kulturkreisen erfordern ein effizientes Projektmanagement, um sie erfolgreich umzusetzen. Der Zusammenhalt des Projektteams, der Rückhalt im Management und die kompetente Unterstützung durch den Systemlieferanten sind wichtige Erfolgsfaktoren. Als ich den Projektleiter fragte, was er beim nächsten Mal anders machen würde, sagte er, er würde es stärker in Teilprojekte mit separaten Projektverantwortlichen unterteilen, um die parallel laufenden Aktivitäten besser koordinieren zu können. Und er würde die ausländischen Kollegen noch frühzeitiger ins Boot holen. Ein gut funktionierendes Team ist für den Projekterfolg fast wichtiger als die beste Software, so einfach sie auch zu implementieren sein mag. Und der gemeinsame Erfolg stärkt das „Wir-Gefühl“ im Unternehmen – über die PLM-Implementierung hinaus.

Dieses „M“, das doch eigentlich viel sein sollte, als heiße Luft…

Der Begriff [‘mänätschmänt] blickt auf eine langjährige Karriere als inhaltsleere Füllwortmasse in allen Bereichen des Lebens zurück. Im Wesentlichen ist sie dazu da, das Ausatmen bei der Vertonung komplexer Wortgebilde zu erleichtern. Und auch unser aller Lieblingsabkürzung wurde leider nicht davon verschont – wo sie doch mit „P“ und „L“ so einen schmissigen Anfang genommen hat.

Machen wir das Beste draus, wagen wir das Experiment, das „M“ einmal ernst zu nehmen. Was wäre denn die Quintessenz vom „managen“ beim „productlifecyclen“? Kosten im Griff behalten – ja klar, zentral wichtig, aber im Kern die Ägide des Controllings. Termine? Macht das Projektmanagement (hoffentlich). Last but not least: Der Kern des „PL-“ Managements liegt für mich darin, den Reifegrad des Produktes unter Kontrolle zu haben.

Reifegrad hat dabei zwei Perspektiven:

1. Der Grad, in dem ein Produkt das macht, was es soll.

2. Der Grad, in dem das Produkt so hergestellt werden kann, wie man es haben will.

Diese beiden Sichtweisen werden gerne als Produkt- und Prozessreifegrad bezeichnet

Um so einen Reifegrad zu bestimmen oder gar zu steuern, ist es von Vorteil, erst einmal zu beschreiben, wogegen man messen will. Ich hätte dazu noch einen Begriff mit Füllwortende im Angebot: Anforderungsmanagement. Mit dem Vehikel „Anforderung“ beschreibe ich klassisch, was ein Produkt machen soll. Reicht aber nicht! Ich muß auch beschreiben, wie ich ein Produkt herstellen will! Das nennt sich dann „Front-Loading“ und hilft ganz gewaltig, den Zielraum für eine Produktentwicklung zu konkretisieren.

Wie aber das Wort „Entwicklung“ schon sagt, steuere ich hier gegen ein bewegliches Ziel, Produkt und Prozess wachsen weiter, machen manchmal auch einen Schritt rückwärts. Der Reifegrad muß also auch ein Ausdruck dafür sein, wie erfolgreich meine verschiedenen Konzeptalternativen sind bzw. wie weit ich den Trichter möglicher Optionen schon eingeengt habe (letztes Buzzword für heute: Set-Based Engineering).

So ergibt sich ein Korridor von Fakten, gegen den die Produktentwicklung reflektiert werden kann: Hat meine Entwicklung alle Anforderungen im Blick (Abdeckungsgrad)? Kann ich die Anforderungen auch bedienen (Erfüllungsgrad)?

Zum Thema „Abdeckungsgrad“ empfehle ich den Blog-Beitrag von Michael Wendenburg zum Systems Engineering, das ist eine Frage der intelligenten Verdrahtung von Informationen untereinander. Der Erfüllungsgrad wiederum ist eine Frage der Absicherung – und hier wird’s jetzt ein bißchen heterogen…

Absicherung stand lange Zeit synonym für den guten alten Versuch: Hält es noch, wenn man dran rüttelt? Läuft irgendwo Öl ‘raus? Entschuldigung an alle Kollegen aus dem Versuch für die saloppe Formulierung. Was ich damit verdeutlichen will, ist die Krux, daß der Versuchsplan sich in Ermangelung an klar formulierten Anforderungen auch nicht an solchen orientieren kann. Was man im Versuch herausfindet, wird klassischerweise so gut wie möglich gegen einzelne Teile oder Baugruppen dokumentiert und daraus ein (Produkt-) Reifegrad interpretiert.

Das Gleiche gilt grundsätzlich auch für die Absicherung der anderen Reifegrad-Perspektive. Aber Herstellbarkeitsprüfungen, Verbauuntersuchungen, Try-Outs zur Prozess-Stabilität… müssen eher noch ein härteres Schicksal tragen: Ergebnisse wie „läßt sich nicht mit dem Schrauber erreichen“ können wenigstens noch auf einen Bauraum bezogen werden, aber „zu breit für die Lackierkabine“ ist schon deutlich schlechter aufzulösen. Und es geht ja auch noch weiter: Sind die Logistik-Prozesse reif, klappt die IT-Versorgung für die Produktion und und und …

Nun existiert dazu auch noch eine veritable Parallelwelt: Simulation hat Ihren Platz in den Entwicklungsorganisationen gefunden, sowohl für Produkt-, als auch Prozessthemen. Allerdings ringen viele Beteiligte noch mit der Verdrahtung doch unterschiedlicher Prozesswelten. Typische Rückmeldungen aus der Simulation lauten in etwa „würde halten, wenn Du den Radius etwas kleiner machst“ – und das womöglich in sehr frühen Konzeptphasen, wo es kaum eine ausgegorene Produktstruktur als Referenz gibt.

Spätestens hier wird also der Zusammenhang zwischen Reifegrad und Alternativen besonders deutlich: Messe ich das eine, bewerte ich das andere.

Um managen zu können, brauchen ich ein gemeinsames Raster für Entwicklung und Absicherung, an dem Ergebnisse der sehr unterschiedlichen Aktivitäten gespiegelt werden. Egal ob Simulation oder physische Absicherung, frühe Konzepte oder B-Muster – ich benötige eine vereinheitlichte Aussage über den Reifegrad meiner Ergebnisse. Und nur auf der Ebene von Anforderungen habe ich ein hinreichend abstraktes Vehikel, um so ein Raster darzustellen und alle genannten Fraktionen abzuholen.

Wenn man „Management“ ernst nehmen will, dann sind wir hier – glaube ich – an einer guten Stelle dafür angelangt.

Pleiten, Pech, Pannen und PLM

„Alles was schief gehen kann, wird auch schief gehen“, lautet das wohl bekannteste von Murphys Gesetzen. Wo der Mensch seine Hände im Spiel hat, sind Fehler unausweichlich. Für die Unternehmen heißt das, dass sie die Fehlerquote reduzieren, aber Fehler nie ganz eliminieren können. Worauf es ankommt, ist ein effizienter Umgang mit den auftretenden Fehlern, um sie möglichst schnell zu beheben und ihre Wiederholung zu vermeiden. Das gilt vor allem für jene Fehler, die den Gebrauch eines Produktes beeinträchtigen, sprich Mängel.

Das Problem mit Fehlern ist, dass sie in vielen Formen auftreten – als Produkt- oder Qualitätsfehler, als Prozessfehler, als (meist unverständliche) Error-Meldung einer Software etc.. Manchmal verkleiden sie sich auch als Serviceanfragen oder Verbesserungsvorschläge. Einige fallen in der Entwicklung auf, andere in Fertigung und Montage bzw. in der Qualitätssicherung. Wieder andere entdecken die Servicetechniker oder – schlimmer noch – die Kunden, was Gewährleistungen, Reklamationen oder Beschwerden nach sich zieht.

Je nachdem, wo und wann sie auftreten bzw. auffallen, werden Fehler mit unterschiedlichen Werkzeugen wie Excel, eigene Datenbanken etc. verwaltet, was ihre strukturierte Bearbeitung nach einer einheitlichen Methodik (z. Bsp. der 8D Methode) erschwert. Das ist weder effizient noch effektiv, denn bei allen diesen Vorgängen geht es letztlich darum, sie systematisch zu erfassen, auszuwerten, entsprechende Maßnahmen zu ergreifen und diese nachvollziehbar zu dokumentieren. Deshalb liegt es nahe, die Bearbeitung aller fehlerrelevanten Vorgänge in einer einheitlichen IT-Systemumgebung zusammenzuführen. Die Frage ist, ob PLM dafür die geeignete Plattform ist bzw. was sie leisten muss, um diese Funktion zu erfüllen?

Für die Integration des Mängelmanagements in PLM sprechen verschiedene Gründe:

Mängel, Reklamationen etc. haben normalerweise einen engen Bezug zu einem Produkt oder Projekt, deren Unterlagen mit PLM verwaltet werden;
für die Bearbeitung der Vorgänge können einheitliche Vorgehensweisen in Form von elektronischen Workflows abgebildet werden;
die Rechteverwaltung des PLM stellt sicher, dass nur autorisierte Personen zu den Informationen über Mängel, Reklamationen etc. haben;
PLM unterstützt die Umsetzung von Maßnahmen zur Fehlerbehebung durch formale Workflow-Prozesse;
die vorhandenen Projektmanagement-Funktionen können für die Umsetzung von größeren Verbesserungsvorhaben genutzt werden;
die Nutzung einer einheitlichen Plattform spart Schnittstellen und Kosten für Anschaffung bzw. Wartung einer separaten Reklamationsmanagement-Anwendung.

Alle Vorgänge, die mit der Behandlung von Fehlern zu tun haben, in die PLM-Lösung zu packen, ist also keine schlechte Idee. Einheitliche Bearbeitungsmethoden unter einer einheitlichen Oberfläche sorgen dafür, dass die Mitarbeiter Mängel, Reklamationen etc. schneller erledigen können. Das spart Kosten, erhöht die Zufriedenheit der Kunden und bindet sie an das Unternehmen. Wem bei einer Reklamation schnell und unbürokratisch geholfen wird, der kauft gerne wieder.