Gemeinsam stärker: PLM und CMII

Eine zentrale Forderung, warum sich Unternehmen eigentlich mit PLM beschäftigen, ist die Effizienzsteigerung der wertschöpfenden Prozesse. Dies ist einer der wichtigsten Hebel in der ROI-Betrachtung eines PLM-Projekts.

Aber auch in den eigentlichen Geschäftsprozessen liegt oft ein gehöriges Optimierungspotenzial. In diesem Zusammenhang möchte ich gern auf die Reduced Rework Initiative” der Gesellschaft für Konfigurationsmanagement hinweisen. Im Mittelpunkt dieser Initiative steht das Vorgehensmodell nach dem CMII-Standard mit dem Ziel, die Kosten und Aufwände für unnötige Nacharbeit zu senken. Nacharbeit entsteht immer dann, wenn das Produkt nicht den Anforderungen des Kunden entspricht. Oftmals wird an dieser Stelle an die Prozesse „Problem Report“, „Enterprise Change Request“ und „Enterprise Change Notice“ gedacht. Diese Abläufe im Änderungswesen sind Bestandteil vieler PLM-Werkzeuge und werden auch „out-of-the-box“ oder mit Modifikationen für die Steuerung von Freigaben und Änderungen von Dokumenten eingesetzt.

CMII bietet aber noch ein ganzes Stück mehr und gerade im Zusammenhang mit PLM-Projekten lohnt ein Blick auf alle Elemente des CMII-Vorgehensmodells. Best Practices und Regeln wie „Anforderungen führen – Items folgen“; das effiziente Änderungsmanagement; klare, knappe und gültige Anforderungen an das zu produzierende Produkt, die fortwährende Überprüfung der Konformität der Ergebnisse mit den Anforderungen, all das führt zu einer Vermeidung von Kosten für die Beseitigung von Produktfehlern. Vereinfacht gesagt, wird das Übel des Produktfehlers an der Wurzel beseitigt und nicht an den Symptomen herumgedoktert. Das hilft dabei, jeden Fehler nur einmal zu machen und auszumerzen. Unternehmen, die diesem Paradigma folgen, haben die Chance, Kosten für die Fehlerbeseitigung einzusparen und diese Mittel in echte Produktinnovation zu stecken.

Richtig beherrschbar werden aber diese CMII-Prozesse erst mit einer ausreichenden Toolunterstützung. Gerade Analysen von Änderungsauswirkungen (im CMII-Kontext „Impact Matrix“ genannt) sind ohne Unterstützung vom PLM-Systemen nur mit hohem Aufwand möglich. Ein einfaches Beispiel ist die Mehrfachverbauung einer Baugruppe in verschiedenen Produkten, die mittels „Where used“-Abfrage schnell beantwortet werden kann. Oder es gibt Abhängigkeiten zu Bedienungsanleitungen oder Servicedokumenten. Der zuständige Konfigurations-Manager kann dann sicher entscheiden, welchen Einfluss eine Änderung hat und was zu tun ist, um diese konsistent umzusetzen.

Für eine effiziente Umsetzung von CMII-Elementen ist eine gute Unterstützung durch eine PLM-Software unabdingbar. Aber auch aus Sicht des PLM-Projekts gilt: PLM-Werkzeuge mit CMII- Prozessen, Formularen, Regeln und Rollen nutzen die Synergien aus einem interessanten Vorgehensmodell und können somit signifikant zum Gesamterfolg eines PLM-Projektes führen. PLM und CMII – da passt vieles zusammen.

Wir bleiben beim Standard – oder doch nicht?

Welcher Projektleiter, PLM-Verantwortliche oder Berater kennt das nicht: PLM soll endlich auf  professionelle Füße gestellt werden. Dafür wurden erste Geschäftsprozesse aufgenommen, über mögliche abzubildende Daten und deren Attribute und Abhängigkeiten gesprochen, mit verschiedenen Stakeholdern über Anforderungen diskutiert. Vielleicht entstand eine PLM Strategie und eine Roadmap mit einer ersten groben Zeit- und Ressourcenplanung. Das neue PLM-Projektteam hatte erste Meetings, die Kekse waren lecker. Man fand sich zusammen und  ging motiviert an die ersten Aufgaben. Nach gar nicht langer Zeit gaben sich dann erste PLM-Systemhersteller und -dienstleiter die Klinke in die Hand und stellten Ihre Softwarelösungen vor. Ein Benchmark wurde aufgesetzt, um Anbieter miteinander zu vergleichen und das beste System herauszufinden. Und spätestens hier fiel das erste Mal der Satz: Wir bleiben beim Standard! Der zukünftige PLM-Systemanwender möchte auf keinen Fall teure, ausufernde Anpassungen des PLM-Systems. Maximal sollen einige wenige Dinge konfiguriert werden, auf keinen Fall etwas individuell programmiert werden. „Zur Not ändern wir unsere Prozesse und passen uns dem PLM-System an!“. In wenigen Dingen besteht am Anfang einer PLM-Systemimplementierung mehr Einigkeit als über diesen Punkt: „Wir bleiben beim Standard –  keine großen Anpassungen der PLM-Software“.

Einige Wochen/Monate/Jahre später wird beim ersten großen Releasewechsel oder einem anderen passenden Anlass die Implementierung und die Systemänderungen gereviewt. Wäre das PLM-System ein Fahrzeug, wäre mit einem bisschen Glück noch die Markenidentität zu erkennen. Aber sonst? Zusätzliche Navigationsgeräte, Leichtmetallfelgen (manchmal auch als Lenkrad!), Sportauspuffanlagen, an allen Fahrzeugseiten Anhängerkupplungen und der Motor ist nur getunt oder gegen einen Warp-Antrieb ausgetauscht. Dass das Fahrzeug in einigen Situationen beim Rechtslenken nach links fährt und der Rückwärtsgang nicht mehr funktioniert, dafür aber einen hervorragenden Kaffee kocht – geschenkt.

Döbernitz, Reparatur eines Traktors

Bundesarchiv, Bild 183-68283-0001 / CC-BY-SA [CC BY-SA 3.0 de (http://creativecommons.org/licenses/by-sa/3.0/de/deed.en)], via Wikimedia Commons

Das blieb also übrig von „Wir bleiben beim Standard“. Wenig bis fast gar nichts. Auch diese Situation ist vielen nicht ganz unbekannt sein, oder?

Warum kommt es aber dazu, dass das viele Vorteile bietende Ziel des Nutzens von Standardfunktionen nicht getroffen wird? Mir fallen drei Gründe ein.

Zum einen ist es nur mit größten Anstrengungen möglich, dass sich Unternehmensorganisationen, -prozesse und -abläufe an Software anpassen. PLM-Prozesse sind das „offene Herz“ von Industrieunternehmen, die ändert man nicht eben mal so schnell ab, nur weil Software nicht so tickt wie sie soll. Die etablierten Zuständigkeiten und Abläufe sind ja auch oft bewährt und funktionieren gut.

Der zweite Grund ist, dass es gar keine unternehmensübergreifenden Standards gibt bzw. sie so generisch definiert sind, dass konkrete Implementierungen gar nicht möglich sind. Jeder, der mal vor der Aufgabe stand, QM-Vorschriften in Software zu gießen, wird ein Lied davon singen können. Sicher gibt es aber auch Bemühungen und Anstrengungen, Standardisierung voranzutreiben. Ein Beispiel wäre das Konfigurationsmanagement CMII oder Analysetechniken wie eine FMEA.

Der dritte Grund ist, dass es ja nur bedingt im Interesse von Dienstleistern und Herstellern ist, Standards „out-of-the-box“ anzubieten. Die Implementierungsprojekte sorgen für zusätzlichen Ertrag, der traditionell beim Preiskampf im Lizenzverkauf in die Binsen ging. Dienstleister und Softwarehersteller betreiben PLM nicht nur aus rein akademischem Interesse wie ich ;-), sondern müssen am Ende des Tages Umsatz machen.

Meine persönliche Erfahrung gibt kein einziges PLM-Projekt her, an dem nicht an der PLM-Software konfiguriert und programmiert wurde. Mich würde es aber brennend interessieren, ob es andere Erfahrungen gibt. Über eine Diskussion in den Kommentaren zu diesem Artikel würde ich mich sehr freuen. Übrigens, ERP-Consultants dürfen sich auch wiedererkannt haben und können auch gern mitdiskutieren.

Ein Plädoyer für die Anforderungsanalyse

Über die Einführung eines PLM-Systems und der Herausforderungen, denen sich das Projektteam dabei stellen muss, ist schon viel geschrieben und debattiert worden. Ein Punkt wird dort immer wieder genannt, der als einer der größten Hemmschuhe für den Erfolg von PLM-Projekten gesehen wird: die mangelnde Benutzerakzeptanz. Ich möchte in meinem heutigen Blogbeitrag einen weiteren Aspekt dieser Diskussion beifügen, der am Anfang eines PLM-Projektes steht: Die Anforderungsanalyse.

In ihr sollen die funktionalen und nicht-funktionalen Anforderungen der künftigen Benutzer des PLM-Systems aufgenommen werden. Sie wird oft etwas stiefmütterlich behandelt, da sie noch wenig konkrete und benutzbare Ergebnisse für die späteren PLM-Anwender bringt. Mit virtuellen Datenmodellen, Anwendungsfalldiagrammen, Prozessbeschreibungen und weiteren Dokumenten kann noch kein Lebenslauf eines realen Produktes gemanagt werden.

Ich möchte aber eine Lanze für eine genaue und saubere Anforderungsanalyse brechen. Sie definiert, wie das PLM-System den Anwendern zur Verfügung stehen wird. Mit der Anforderungsanalyse wird die Basis gelegt, die später in Funktionen und Methoden im PLM-System abgebildet wird und dann für eine deutliche Optimierung des gesamten Engineeringprozesses sorgen soll. Denn aus diesem Grund „macht man ja PLM“, oder?

Somit sind diese Diskussionen und Workshops am Anfang des Projektes nicht vertane Zeit, an der nur die externen Berater verdienen. Der Aufwand für Nacharbeiten, die durch falsch interpretierte Anforderungen des Kunden nötig werden, ist deutlich höher als der für die Erarbeitung eines eindeutigen Verständnisses im Rahmen einer Anforderungsanalyse. Und eine Funktion im PLM-System, die am zukünftigen Endanwender „vorbeiprogrammiert“ wurde, trägt keinesfalls zur Akzeptanz des Systems bei. Und hier schließt sich der Kreis von den ersten Schritten im PLM-Projekt zur Benutzerakzeptanz im laufenden Betrieb.