PLM gestern und heute

PLM gestern und heute – Was sich in PLM Projekten in den letzten 5-10 Jahren geändert hat

Früher war man im PDM sehr auf Features & Functions sowie die Return of Invest (ROI) Rechnung fixiert. Viele glaubten an den Messias Software. Es war, als ob der reine Kauf des PDM Systems alle Probleme, die die Unternehmen mit dem Erzeugen und Lifecyceln von Produktinformationen hatten, wegzaubern würde und sich der ROI, den die PLM Anbieter errechnet hatten, dann von selbst einstellen würde.

PLM gestern und heute – Was sich in PLM Projekten in den letzten 5-10 Jahren geändert hat

In den letzten 5-10 Jahren haben im Bereich PLM verschiedene Effekte eine Wirkung erzielt haben.

Früher war man im PDM sehr auf Features & Functions sowie die Return of Invest (ROI) Rechnung fixiert. Viele glaubten an den Messias Software. Es war, als ob der reine Kauf des PDM Systems alle Probleme, die die Unternehmen mit dem Erzeugen und Lifecyceln von Produktinformationen hatten, wegzaubern würde und sich der ROI, den die PLM Anbieter errechnet hatten, dann von selbst einstellen würde.

Die Situation ist in etwa vergleichbar mit einem Ordnungsproblem bei Ihnen zu Hause und Sie glauben nun, der Kauf eines neuen Schrankes würde das Ordnungsproblem von selbst lösen. Der richtige Schrank schafft die Grundvoraussetzung für eine gute Ordnung, aber das wars dann schon. Genau das ist eine der Einsichten, die sich endlich durchsetzt. Bei Kunden nutze ich gerne das Beispiel dieser Netflix Serie „Aufräumen mit Marie Kondo“. Ich sage dann, im Prinzip ist das, was wir im Projekt tun, nicht unähnlich zu dem was Marie Kondo tut.

Es gibt noch einige weitere Punkte, die sich geändert haben. Noch vor nicht allzu langer Zeit hat man das Einstrukturenkonzept gepredigt. Dem lag die Idee zugrunde, dass eine Produktstruktur ausreicht, alle Aspekte rund ums Produkt abzubilden. Es wurde bei diesem Ansatz davon ausgegangen, dass sich die notwendigen Sichten ad hoc bilden lassen. Die Idee des Einstrukturenkonzepts hat sich als nicht der Realität entsprechend herausgestellt. Sie ist nur für eine kleine Summe ganz besonderer Fälle geeignet. Bei allen anderen hat sie nur zu noch mehr Excellisten und Aufwand geführt.

Inzwischen wird das Mehrstrukturenkonzept propagiert. Oft wird dafür auch der Namen xBom verwendet. Das Mehrstrukturenkonzept erkennt die Tatsache an, dass in der Produktentstehung mehrere unterschiedliche Strukturen entstehen, die auch jeweils eine eigene, persistente Struktursemantik brauchen. Heute können wir sehr präzise sagen, in welchem Fall wir welche Strukturen etablieren müssen und wie diese von ihre Struktursemantik her aufgebaut sein sollten. Das ist schon ein enormer Schritt, der jedoch kaum gesehen wird, weil nur wenige Experten die Thematik durchdringen und sie dann auch noch verständlich aus Perspektive der Unternehmen erklären können.

Es gibt jedoch eine Veränderung, die aus meiner Sicht die wichtigste ist. Bisher war die vorherrschende Überzeugung, es reiche Werkzeugen der klassischen Prozessmodellierung einzusetzen, um die Abläufe im PLM modellieren und gestalten zu können. Aufgrund dieser Überzeugung entstehen in Unternehmen oft Tapeten von Prozesssequenzen, die über Jahre für viel Geld aufgebaut werden und dann nichts oder nur wenig nützen.

Das hat seine Vergangenheit: Prozessmodellierung wurde/wird im Wesentlichen im Kontext der ERP-Einführung genutzt. Dort funktioniert es auch aus einigen Gründen sehr gut. Im ERP liegen sehr formale Prozesse vor, die auf einer Hierarchiestufe transaktional verlaufen. Das ist ein perfekter Anwendungsfall für die Prozessmodellierung und dort hat sie auch ihren Ursprung.

Über 90% der kreativen Tätigkeiten, die im Produktlebenszyklus Informationen zum Produkt erzeugen, sind nicht hinreichend formal, so dass eine ausschließlich auf Prozesse fokussierte Modellierung versagt. Um diese Abläufe zu gestalten, ist es notwendig, das Fließen der Produktinformationen über die unterschiedlichen Produktstrukturen zu modellieren. Wir nennen das die Informationsarchitektur. Um hier Licht ins Dunkle bringen zu können, haben wir in unserem Steinbeis Transferzentrum (STZ-RIM) Werkzeuge zur Modellierung des Flusses der Informationen über die Informationsarchitektur hinweg, sowie zur Modellierung der Struktursemantik entwickelt.

Als ich früher diese Ansätze zeigte, haben mich die Menschen aus den Unternehmen mit vielen Fragezeichen in den Augen angeschaut. Heute sind sie oft begeistert und begierig danach, die Methoden zu lernen, um diese Themen diskutieren, verstehen und eigenständig umsetzen zu können.

Der Druck zur Digitalisierung, der heute vorherrscht, erzwingt das natürlich. Früher standen die Themen rund um digital verfügbare Informationen eben nicht im Vordergrund. Alles drehte sich um das zumeist auftragsbezogene Entwickeln und Bauen des physikalischen Produkts. Nachdem es von der Rampe ging und beim Kunden abgenommen war, hat man sich dann um den nächsten Auftrag gekümmert.

Im beschriebenen Szenario reichte es aus, dass wesentliche Träger der Information die Menschen waren, die sich die Dinge zugerufen haben. Oft gab es in Maschinenbauunternehmen die Künstler und Helden Mentalität. Da waren dann die Helden in der Produktion, wir nennen sie mal Kalle und Paule. Kalle und Paule konnte man „was heißen“ – so sagen wir das im Südwesten. Hier ist es das Höchstlob über jemanden zu sagen: „denn kann man was heißen“. Man meint damit, dass man diesen Personen eine beinahe unlösbare technische Aufgabe geben kann und sie diese dann perfekt und auch noch pünktlich schaffen. Kalle und Paule bekamen also oft von den Künstlern aus der Entwicklung grobe Zeichnungen und Seitenweise E-Pläne zugeworfen und haben das dann schon hinbekommen. Zum Schluss kam das Produkt pünktlich zum Kunden und alle waren zufrieden.

Dass hat sich grundlegend geändert. Heute erwarten die Kunden die notwendigen digitalen Informationen zum Produkt im aktuellen Änderungsstand, zudem erwarten Sie auch nach dem Kauf viel umfassendere Serviceleistungen als früher. Wenn erst ein Servicemitarbeiter vor Ort kommen muss, um herauszubekommen welche Komponenten verbaut und welche Software aufgespielt wurde, trifft dies zunehmend auf Unverständnis. Durch den Druck, der sich aus dieser Richtung aufbaut, setzt sich zunehmend die Erkenntnis durch, dass ein durchgängiges Management von Produktinformationen und insbesondere das saubere, explizite, digitale Ablegen dieser Informationen in Backbonesystemen einen zentralen Enabler für die Geschäftsprozessfähigkeit von Unternehmen darstellt.

Für Berater wie mich macht das viele Dinge leichter, da viel Aufwand, der früher in Überzeugungsarbeit gesteckt werden musste, wegfällt und man die wesentlichen Themen direkter angehen kann.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert

Weitere Artikel

Im Beitrag werden Bezeichnungen und Kategorisierungen von Stücklisten (BOMs) sowie das RIM-360°-Multi-Structure-Model vorgestellt....