In vielen vergangenen Artikeln haben wir die Komplexität eines PLM-Projekts und die Stolpersteine auf dem Weg zu einer funktionierenden PLM-Toollandschaft beschrieben. Mein Kollege Bernd hat eine Lanze für die Offenheit der PLM-Systemarchitektur gebrochen, Hendrik hat die CAD-Integrationen besprochen und Steffen das Zusammenspiel zwischen ERP und PLM beleuchtet. Eine weitere, 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. Wo diese Effekte aus Tool-Sicht zu finden sind, erläutert Hendrik in seinem Artikel in der IT&Production.
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 „Dokumente 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. 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.



1 Kommentar
1 Ping
Guido Weischedel sagt:
17. Juni 2011 von 17:01 (UTC 1)
Vielen Dank für die knackige Zusammenfassung des CMII-Standards und den Hinweis auf die R2 (Reduced Rework) Initiative. In der Zwischenzeit gibt es auch eine eigene Webseite zu R2 (http://www.r2initiative.org) – dort kann man auch kostenlos Mitglied werden um das Thema “weniger Nacharbeiten” zu unterstützen und sich mit anderen Mitgliedern auszutauschen.
Der PLM-Blog » DataSquare goes CMII - Der PLM-Blog sagt:
6. Dezember 2011 von 12:40 (UTC 1)
[...] Beiträgen in diesem Blog bereits betrachtet. Insbesondere sei dabei auf zwei Artikel verwiesen: PLM & CMII, in dem der generelle Zusammenhang zwischen dem Organismus PLM und dem Rückgrat CMII beschreiben [...]