Psst, bloß nicht laut von PLM reden!

Puhh, als PLM-Fan musste man in der vergangenen Woche tief Luft holen: Gleich zwei bekannte Blogger senkten in den Überschriften ihren Daumen nach unten: Joe Barkai: „Why I Don’t Do PLM“ und Oleg Shilovitsky: „Are PLM conferences dead?“.

Kurioserweise ziehen beide an den entgegengesetzten Enden des Seils. Für Barkai greift die klassische Sichtweise von PLM als „single version oft the truth“ zu kurz, während Shilovitsky die Basics hinter der PLM-Idee beschwört.

Barkai: „I find it fascinating that traditional PLM software vendors are not realizing how the Internet of Things and the connected enterprise are breathing a new life into the PLM space that does not quite know how to reinvent itself. After decades of using enterprise PLM software, it is still common to hear at a PLM conference a speaker announcing, “Let me give you my definition of PLM.” Or those never-ending debates about eBOMs and mBOMs and where PDM ends and PLM begins.“

Shilovitsky: “I know many people struggling with their PLM decisions and fighting alone to balance tools, budgets, organizational and cultural changes and timelines. Companies are struggling with very basics things – Part Numbers, Change Management, Revisions, and others. To discuss the real problems, can be an opportunity. This is the foundation – the story. This is a single unit… If a single unit doesn’t sell, making it broader or scaling it up won’t solve the problem.”

Ehrlich gesagt, je nachdem mit welchen Kollegen ich bei uns spreche, könnte es ähnlich ausgehen. Bei einer Sache sind wir uns dabei aber alle ziemlich sicher: PLM groß auf eine Einladung oder eine Anzeige zu schreiben, dazu gehört heute schon etwas Mut.

Sind die besten Zeiten von PLM also vorbei?

Unternehmen bestehen deshalb am Markt, weil sie ihren Kunden zuhören und ihr Angebot immer wieder rechtzeitig an neue Anforderungen und Möglichkeiten anpassen! Ja, die Basics sind immer noch die low hanging fruits,  und die Vorreiter kümmern sich um die anspruchsvolleren Potentiale im Produktlebenszyklus, wo es um die Integration von Disziplinen, Tools und Prozessen geht. Einige PLM-Anbieter nutzen zum Beispiel ihre Erfahrung und ihr bisheriges Portfolio rund um das virtuelle Produkt, um ihr Angebot Richtung Internet of Things und den digitalen Zwilling zu erweitern.

Dies macht das Dilemma deutlich: PLM war im Gegensatz zu ERP oder auch der Finanzbuchhaltung nie ein Selbstläufer. Immer schon musste die PLM-Idee bei den Geldgebern besonders überzeugend motiviert werden.

Und das ist oft nicht gut gelungen, wie mein Kollege Rolf Stübbe es in seinem Blog-Beitrag „20 Jahre PLM: Warum zweifeln Viele noch immer am Nutzen?“ auf den Punkt bringt: „Trotz der wieder steigenden Aufmerksamkeit für PLM bemerke ich, dass dem Begriff unverändert die Geschmacksnoten groß, schwerfällig, langwierig, unwirtschaftlich anhaften.“ Vermeintliche Leuchtturmprojekte wie die schier endlose Teamcenter-Einführung bei VW und Dassaults Lizenzpolitik, die mit ursächlich für die Code of PLM Openness Initiative war, stehen stellvertretend für die vielen Nadelstiche, die den Ruf von PLM mit der Zeit ramponiert haben.

Fazit

Man kommt sich vor wie bei Monty Python in der Fawlty Towers Folge “The Germans“: „Don‘t mention the war!“. PLM: Jeder denkt dran, aber alle versuchen, dem Begriff aus dem Weg zu gehen. 

Dabei waren Zeiten für die PLM-Idee nie besser als heute. Der Druck in den Unternehmen ist hoch und steigt weiter, um die Chancen der Digitalen Transformation zu nutzen. Aber das Storytelling muss besser werden. Da taugen die alten Geschichten und komplizierten Definitionen sicher nicht mehr, und der PLM-Begriff als Werbeträger nur noch bedingt. Storytelling und Projektmarketing gehören von Anfang an zusammen. Das fängt mit den Zielen an. Da bin ich bei Oleg Shilovitsky: Wir sollten das Kind nicht mit dem Bade ausschütten. Krude Versprechungen und obskure Visionen, die zum Scheitern verurteilt sind, helfen nicht, im Gegenteil. Lieber die low hanging fruits attraktiv verpacken, dem Projekt einen sinnstiftenden Namen geben und alles dafür tun, dass die ersten, überschaubaren Ziele auch erreicht werden.

Physische Produkte agil entwickeln?

In meinem letzten Blog-Beitrag ging es um Teams, die erst durch Erfahrung wirklich agil werden. Heute stehen die Herausforderungen im Mittelpunkt, die die Agilität gerade im Engineering mit sich bringt.

Agile Softwareentwicklung hat sich fast 20 Jahre nach dem Agilen Manifest weitgehend durchgesetzt. Es geht nicht mehr um das Ob, sondern nur noch um die Best Practices im Detail sowie agile Skalierbarkeit. Der Erfolg und die einfache Anwendbarkeit etwa von Task Boards haben dazu geführt, dass agiles Vorgehen auch außerhalb der Software-Entwicklung begeisterte Nutzer findet, wo Aufgaben im Team bearbeitet werden.

Dies mündete schließlich in die zunehmend intensiv diskutierte Frage, ob auch physische Produkte effizienter mit agilem Vorgehen entwickelt werden könnten.

Warum eigentlich?

Es gibt seit vielen Jahren etablierte Produktentstehungsprozesse, die eine große Reife erlangt haben und eine erfolgreiche Entwicklung unterstützen. Warum davon abgehen und die Risiken eines komplett neuen Ansatzes auf sich nehmen?

Je unklarer die Anforderungen an das Produkt sind und je unbekannter die zu verwendende Technologie ist, desto weniger sind klassische Projektmanagement-Methoden geeignet, weil sie sehr stark vorausplanend sind. Genau diese Tendenz, Projekte trotz zunächst unvollständiger Anforderungen zu starten, beobachten wir aber zunehmend. Digitalisierung und neue Technologien erfordern neue Geschäftsmodelle oder neue technologische Fähigkeiten. Dies spricht für ein agiles Vorgehen, da es für den Umgang mit Unklarheit und Noch-Nicht-Wissen erfunden wurde.

Geht das überhaupt?

Die entscheidende Frage lautet dabei: Sind agile Methoden aus der Softwareentwicklung überhaupt geeignet, die Herausforderungen in der „klassischen“ Produktentwicklung zu bewältigen? Physische Produkte werden im Unterschied zu Software deutlich arbeitsteiliger entwickelt. Die Produktion von fehlerhaften Komponenten verursacht hohe Folgekosten und die Absicherung ist auf physische Prototypen angewiesen. Es ist nicht möglich, alle zwei Wochen einen neuen, funktionierenden und potenziell auslieferbaren Stand zu präsentieren. Lösungen für solche Probleme erfordern eine kreative Weiterentwicklung der bekannten agilen Vorgehensmodelle. Ein sehr einfaches Beispiel dafür: Die Teams verschiedener Domänen benutzen unterschiedliche Sprintdauern. Während das Software-Team alle 2 Wochen liefert, gilt für das Mechanik-Team ein 6-Wochen-Rhythmus. Wichtig ist, die Sprints so zu synchronisieren, dass alle 6 Wochen ein gemeinsames Inkrement erreicht wird.

Die Herausforderung

Die Herausforderung bei der Einführung agiler Methoden ist damit eine doppelte: Einerseits ist es erforderlich, die agilen Methoden aus der Software-Entwicklung an die Bedingungen in der Produktentwicklung anzupassen. Andererseits benötigt man – damit komme ich wieder zu meinem vorigen Beitrag zurück – viel agiles Erfahrungswissen, um solche Anpassungen erfolgreich hinzubekommen. Um diesen Widerspruch aufzulösen, sollte man die Pioniere, die sich auf das neue Terrain wagen, zusammenbringen mit erfahrenen „Agilikern“, die ihr Handwerk aus der Software-Entwicklung beherrschen. Das wechselseitige voneinander Lernen und Teilen von Wissen führt zu einer besseren Beherrschung der Produktentwicklung unter den sich rasant ändernden Randbedingungen.

Black Box IoT?

Wer kauft schon gerne die Katze im Sack? Zumal wenn damit komplettes Neuland betreten wird… Der erste Kinderwagen zum Beispiel: Man ist sich zwar schon darüber im Klaren, dass man ihn braucht, aber die Entscheidung, ob es ein kleines Packformat oder doch lieber die Fahrradanhänger-Kombi sein soll, ist da schon schwieriger.

Der letzte Kinderwagenkauf ist jetzt schon einige Zeit her (mittlerweile bin ich Experte im Kauf von Skateboards). Falls Sie aber gerade vor der Wahl stehen, empfehle ich Ihnen ein dunkles Modell, da sieht man den Dreck nicht so deutlich.

Ein IoT-System ist zwar in der Regel nicht so dreckempfindlich, seine Auswahl ist dafür aber umso komplexer. Zumal viele Unternehmen damit Neuland betreten und schon an der Auswahl der richtigen Kriterien schier verzweifeln können. 

Hier habe ich zwei gute Nachrichten. Erstens: Welche IoT-Lösung passt, lässt sich einfach ausprobieren. Ein Proof of Concept ist eine sehr gute Möglichkeit, eine Lösung ohne große Risiken zu testen, bevor Sie sich für ein System entscheiden. Und zweitens: So sehr IoT auch neue Chancen bietet – so sehr basieren smarte Geschäftsprozesse auf guten alten Tugenden:

  1. Sind Sie sich sicher, wie Ihr IoT-Geschäft aussehen wird und das es auf lange Zeit so bleibt? Wahrscheinlich nicht. IoT ist ein sehr volatiler Markt, in dem gerade eine ganze Menge passiert. Also muss Ihr IoT-System reaktionsstark sein und am besten von der Fachabteilung selbst angepasst werden können. Das Stichwort dahinter heißt „low code„, das heißt keine aufwändige Programmierung, um Ihre Prozesse abzubilden. Und wenn das nicht reicht, sollte das System so modular sein, dass man zusätzliche Komponenten einfach „nachladen“ kann.

  2. Entsteht Ihr IoT-Geschäft auf der grünen Wiese oder erweitert es Ihr bestehendes Business? Wenn Letzteres der Fall ist, dann sollte Ihr IoT-System mit der übrigen IT-Welt in Ihrem Unternehmen sprechen können: Ersatzteilbestellungen zum Beispiel sollten ja in aller Regel einmal bei der Finanzbuchhaltung vorbeigekommen sein. Offene oder sogar zertifizierte Schnittstellen sind auch hier das A und O.

  3. Stellen Sie Industriegüter her? Haben Sie auch mal mit Ersatzteilen und Wartung zu tun? Dann wird Ihr neuer bester Freund im IoT-Neuland der „Digitale Zwilling„. Aber nur, wenn er auch industrietauglich ist: Er muss die Komponenten Ihrer Anlage detailliert abbilden können (am besten mit zugehörigem 3D-Modell), die aktuellen Parameter wie Software-Stände kennen und insbesondere Veränderungen nach Wartung oder Umbau dokumentieren können.

Die Anbindung von Geräten ist ehrlich gesagt meist nur eine Frage von Fummelarbeit, in aller Regel aber kein grundsätzliches Problem. Schritt für Schritt setzen sich hier Standardprotokolle für die Machine-to-Machine (M2M)-Kommunikation wie MQTT (Message Queuing Telemetry Transport) oder OPC/UA (Unified Architecture) durch und machen allen Beteiligten das Leben leichter.

Also: Probieren Sie es mit einem Proof of Concept einfach aus! Wenn Sie dabei auch noch auf die drei Prüfsteine achten, sind Sie gut im Rennen. Dann stehen Ihnen die Möglichkeiten von „Analytics“, „Big Data“, „Data Driven Processes“ oder „Predictive Maintenance“ offen.