Ein PLM-Talk – heute mit Prof. Jörg W. Fischer, Hochschule Karlsruhe – Technik und Wirtschaft

Nach einigen fachlichen Beitragen ist heute mal wieder ein PLM Talk dran. Ich freue mich sehr, für die heutige Episode einen exzellenten PLM-Experten gewonnen zu haben: Herr Prof. Jörg W. Fischer vom der Hochschule Karlsruhe – Technik und Wirtschaft und dem Steinbeis – Transferzentrum Rechnereinsatz im Maschinenbau (STZ-RIM) in Karlsruhe. Ich wünsche dem geneigten Besucher dieses Blogs viel Spaß beim Lesen dieses Interviews.

Herzlich Willkommen auf meiner virtuellen Blogcouch, Herr Prof. Fischer. Machen Sie es sich bitte recht bequem. Viele Leser dieses Artikels werden Sie von Ihrer Arbeit beim Steinbeis-Transferzentrum Rechnereinsatz im Maschinenbau (STZ-RIM) Karlsruhe und aus ihren zahlreichen Veröffentlichungen z.B. in Ihrem Youtube Channel kennen. Können Sie trotzdem bitte ein paar Worte zu Ihrer Person und ihren bisherigen beruflichen Stationen verlieren?

Ja Hallo Herr Golinski, ich freue mich, dass ich hier sein darf. 

Prof. Jörg W. Fischer

Im Gegensatz zu vielen anderen im PLM Bereich bin ich Produktionstechniker, d.h. ich habe Maschinenbau Produktionstechnik am KIT in Karlsruhe studiert. Damals, als das Internet und die objektorientierte Programmierung aufkam, wurde mir klar, dass die Schnittstelle zwischen Wirtschaftswissenschaften, Maschinenbau und Informationstechnik zukünftig von zentraler Bedeutung sein würde. Demzufolge habe ich eine Hiwistelle, in der ich C++ programmieren lernen konnte, gesucht. So bin ich dann, zuerst als Programmierhiwi und dann als Wissenschaftlicher Mitarbeiter, ans Institut für Arbeitswissenschaft und Betriebsorganisation (ifab) gekommen und habe geholfen, Simulationswerkzeuge für Produktionssysteme zu entwickeln. Diese haben wir damals auch in Industrieprojekten in der Praxis eingesetzt. Nach meiner Promotion habe ich 2004 bei Tecnomatix angeheuert, die dann bereit 2005 von UGS übernommen wurden. 

So bin ich von der Digitalen Fabrik zum PLM gekommen. Glücklicherweise war ich in der Zeit als Berater bei GM-Europe, also Opel, tätig. UGS hat immer großen Wert auf die Unterstützung von GM gelegt und so war es für mich leicht einen sehr starken Kommunikationskanal direkt in die UGS Entwicklung nach Nordamerika zu bekommen. Mit der Übernahme von UGS durch Siemens 2007 bin ich dann in das Team der Business Consulting Manager gewechselt und habe damit begonnen PLM-Methoden für die Automobilindustrie zu entwickeln. 2008 wurde ich zum Professor für Fertigungstechnik mit CAD-CAM-CNC an die Beuth Hochschule für Technik in Berlin berufen. Dass ein Teil der Siemens CAM und CNC Entwicklung in Berlin lokalisiert war hat mir dabei sehr geholfen. Das war die perfekte Möglichkeit, die Fertigungsprozesskette ganzheitlich zu erfassen. In dieser Zeit habe ich begonnen, das Thema Strukturtheorie im PLM zu entwickeln. Dazu gibt es aus der Zeit auch eine ganze Reihe von wissenschaftlichen Veröffentlichungen.

2012 hat mich Prof. Hoheisel, der damalige Dekan des Fachbereichs Maschinenbau an der Hochschule Karlsruhe für Technik und Wirtschaft gebeten, mich auf eine Professur für Produktionsmanagement und Digitale Fabrik in der Fakultät für Maschinenbau und Mechatronik (MMT) zu bewerben. So bin ich als Karlsruher wieder zurück nach Karlsruhe gekommen. Ende 2013 bin ich dann auch ins Steinbeis Transferzentrum – Rechnereinsatz im Maschinenbau (STZ-RIM), das schon 1985 von Prof. Hoheisel gegründet wurde, eingestiegen. 

Dahinter stand mein Wunsch, die entwickelten Methoden noch besser in der praktischen Anwendung einsetzen zu können. In dieser Rolle berate ich also seit 2013 vor allem große mittelständische Unternehmen auf dem Weg zur Digitalisierung. Das Themenfeld, das ich abdecke, ist dadurch viel breiter geworden. Heute berate ich Unternehmen ganzheitlich. PLM ist davon ein wichtiges Teilgebiet.

Blicken wir einige Jahre in die Anfänge des PDM/PLM zurück. Bei mir war es damals in meinem Maschinenbaustudium mein Professor für Konstruktionsmethodik, der mich im CAD-Labor mit dem Virus PDM infiziert hat. Was hat sie eigentlich damals motiviert, sich ausgerecht mit diesem Thema beruflich auseinanderzusetzen? 

Zu PLM bin ich eigentlich eher zufällig gekommen. Damals, 2005, als UGS Tecnomatix gekauft hat. Letztendlich hatte ich jedoch, ohne es zu wissen, schon viel früher Berührung mit PLM. Es gab so von 1990 bis 1995 am KIT den SFB 346 “Rechnerintegrierte Konstruktion und Fertigung von Bauteilen”, in dem das ifab mit meinem Doktorvater Prof. Zülch einige wesentliche Anteile hatten. Dort wurden Grundsteine für PLM gelegt. Viele der Technologien, die wir damals eingesetzt haben, waren und sind danach lange Bestandteile in PLM-Systemen gewesen. Viele der Mitstreiter im SFB 346 sind auch heute noch in der Branche unterwegs und ich freue mich immer, wenn ich auf einen treffe.  Demzufolge habe ich durch den SFB 346 den Einstieg ins PLM gefunden – obschon es damals noch nicht PLM hieß. 

Sie beschäftigen sich am STZ-RIM Karlsruhe intensiv mit der PLM Strategie- und Prozessberatung. Was hat sich in ihrer täglichen Arbeit bei den Unternehmen in den letzten 5-10 Jahren geändert? Erfahren Sie eine Verschiebung des Fokus ihrer Kunden in Bezug auf PLM? 

In den letzten 5-10 Jahren hat sich aus meiner Perspektive sehr viel sehr Positives getan. Das hat unglaublich viele Facetten da 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.

Bild von <a href="https://pixabay.com/de/users/geralt-9301/?utm_source=link-attribution&utm_medium=referral&utm_campaign=image&utm_content=4751659">Gerd Altmann</a> auf <a href="https://pixabay.com/de/?utm_source=link-attribution&utm_medium=referral&utm_campaign=image&utm_content=4751659">Pixabay</a>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.

Wenn Sie auf Ihre Projekte in den letzten Jahren zurückblicken, was war die größte Hürde für den Erfolg von PLM – Initiativen? War es eine rein kommerzielle Herausforderung, die Investition zu stemmen? Oder war es eher die veränderten Arbeitsweisen und die damit verbundenen neuen Werkzeuge, die den Mitarbeitern Veränderungen aufzwingen und der Kampf gegen die Haltung „das haben wir aber schon immer so gemacht”? Oder war es eine technische Hürde, weil die Technologie und Architektur der PLM-Systeme zu viel Grenzen und Limits hatte?

Die Hürden, die sie nennen, treffen alle zu. Ich denke, ein der vorrangigen Hürden, die in PLM-Projekten aufkommt, liegt in der mangelnden PLM-Bereitschaft der betreffenden Unternehmen. 

Einem PLM-bereiten Unternehmen sollte im Grundtenor nachfolgende Überzeugung vom Top Management bis auf die Arbeitsebene entwickelt haben:

  • Die Verfügbarkeit gut aufgebauter und richtiger Informationen wird als Grundvoraussetzung für die Geschäftsprozessfähigkeit und damit den Erfolg von Unternehmen gesehen.
  • Die Organisation und Gestaltung des Flusses der Produktinformationen im Unternehmen werden als ein Hebel zur Erreichung der Unternehmensziele verstanden. 
  • Es ist klar, dass die Gestaltung der Informationsarchitektur auch auf strategisch/taktischer Ebene stattfinden muss und nicht allein Sachbearbeitern auf der operativen Ebene überlassen werden kann.
  • Man ist sich bewusst, dass der Fluss der Informationen vom Markt/beim Kunden beginnend, durch das Unternehmen hindurch und dann zurück zum Kunden ganzheitlich betrachtet werden muss d.h. also End-to-End.
  • Es sind Maßnahmen ergriffen, dass die Gestaltung des Flusses der Informationen nicht an Abteilungsgrenzen Halt macht.
  • Es herrscht ein Bewusstsein, dass die frühe Verfügbarkeit von Informationen Upstream (zur Entwicklung hin) mehr Arbeit erzeugt, diese aber gut investiert ist, da sie Downstream (zur Produktion hin) eine Menge von Problemen vermeidet. Diese Mehrarbeit, die Upstream auftritt, wird dann auch kapazitiv berücksichtigt. 
  • Eine PLM Einführung wird nicht mit der Einführung einer Applikation im Sinne von Authoring Systemen verglichen, sondern man weiß, dass sie in eine Vielzahl zentraler Geschäftsprozesse des Unternehmens wirkt.

Die PLM-Bereitschaft allein reicht jedoch nicht aus. Es gibt eine Reihe von Dingen, die lange im Verborgenen lagen und man einfach hoffen musste, das es richtig läuft. 

Heute können wir diese verborgenen Dinge viel präziser formulieren. PLM-Implementierungen liegen unterschiedlichen Prozessmustern der Informationsarchitektur zugrunde. Diese Muster hängen nicht, wie vielfach angenommen, vorrangig von der Industrie ab, sondern davon wie ein Unternehmen sich strategisch zum Markt hin positionieren will. Welche dieser Prozessmuster ein Unternehmen beherrschen will bzw. muss, ist damit eine strategische Managemententscheidung des Unternehmens selbst. Diese darf und kann nicht von einem Solution Architekt, der die PLM-Implementierung begleitet aus dem Bauch heraus getroffen werden.

Hinzu kommen dann noch die Schwächen der heutigen PLM-Systeme. Diese stammen ja von PDM-Systemen ab, die oft Material nicht kannten. Noch heute haben die meisten große Lücken im Umgang mit Material, insbesondere wenn die Modellierung des Materials im Werksbezug notwendig wird. Wenn ich sehe, wie das manchmal implementiert wird und welche Lösungen propagiert werden, sträuben sich mir die Haare. 

Das hat dann mitunter den Effekt, dass mache Solution Architekten den Kunden zu einer nicht passenden Lösung drängen, weil sie diese Lücke mit dem Material im Bauch fühlen und sie so proaktiv umgehen wollen. Der Kunde kann das dann oft nicht umreißen und geht den vorgeschlagenen Weg mit, bis es dann eben im Projekt kracht. 

Sie sehen, PLM-Projekte enthalten, ohne dass sich dessen jemand bewusst ist, einen sehr explosiven Mix. Wenn vor dem erläuterten Hintergrund eine Unzufriedenheit bei dem betroffenen Mitarbeiter aufkommt, geschieht dies natürlich zurecht, da das, was sie bekommen, nicht dem entspricht, was sie wirklich brauchen. 

Ich denke und propagiere, dass es notwendig ist die Implementierung von PLM grundsätzlich anders zu denken. Vor dem Projekt muss die Frage beantwortet werden, welche Prozessfähigkeit ein Unternehmen morgen und in der Zukunft erlangen will. Damit erübrigt sich auch die Aussage „das haben wir aber schon immer so gemacht”. Wenn diese Aussage richtig wäre, gäbe es das Projekt nicht, da die Prozessfähigkeit im Status Quo bereits vorhanden wäre. Der Antwort auf die notwendige Prozessfähigkeit folgt die Wahl des notwendigen Prozessmusters für die Informationsarchitektur. Ein solches Prozessmuster betrifft das Unternehmen gesamtheitlich, d.h. damit auch alle dort implementierten oder zu implementierenden Backbonesysteme, also CRM/PLM/ERP und MES. 

Die Prozessmuster können nun von den Unternehmen adaptiert werden, in dem daraus ein für das Unternehmen angepasstes Gesamtkonzept für Prozessfähigkeit und Informationsarchitektur entsteht, was zuallererst mit den wichtigen Stakeholdern im Unternehmen abgestimmt werden muss. Dabei geht es nicht nur darum, das Okay für das Konzept zu bekommen, sondern vielmehr die Akzeptanz der Veränderung, die damit einhergeht zu erzeugen. 

An diesem Punkt ist ein Stand erreicht, bei dem allen Stakeholdern klar sein sollte, was zu tun ist, warum man es tut und was das große Ziel hinter allem ist. Dann ist die wesentliche Basis geschaffen.

Nun muss die Konzeption ausdetailliert, auf die Backbonesysteme verteilt und in umsetzbare Scheiben geschnitten werden. Grundsätzlich empfehle ich, diese ausdetaillierte Konzeption an einer Shortlist der möglichen Backbonesysteme zu verproben. Es reicht nicht aus, sich eine Lösung zeigen zu lassen und dann anhand von langen Excellisten das Vorhandensein gewünschter Funktionen abzufragen. Das ist ein Vorgehen aus den 90er Jahren des letzten Jahrhunderts und wenn ich heute Beratungsunternehmen sehe, die das propagieren, kann ich nur mit dem Kopf schütteln. Die Erprobung in einer Art Digitalisierungslabor im Unternehmen dient dabei nicht nur dem Prüfen der Eignung des jeweiligen Systems. Man muss sie viel mehr als Ort der Entwicklung der zukünftigen Prozess- und PLM-Fähigkeiten eines Unternehmens verstehen. In diesem Digitalisierungslabor werden die Mitarbeiter an die Technologien herangeführt und ausgebildet. Darüber hinaus wird auch noch die für das Unternehmen passende Technologie evaluiert.

Flankiert man das Ganze mit einem geeigneten Change Management Ansatz, so dass auch die Kommunikation ins Unternehmen sauber läuft, wird die Implementierung sehr viel leichter. Das Problem bei diesem Vorgehen ist die Notwendigkeit eines größeren Budgetbedarfs. Wie auch immer man es dreht und wendet, letztendlich fallen die Kosten ohnehin an. Prozessfähigkeit ist eine Fähigkeit, die vom Selbstverständnis der eigenen Mitarbeiter getragen wird. Das ist nicht etwas, was man sich mit einem IT-System einkauft. Ignoriert man die Vorbereitung am Anfang und tut so, als seien diese nicht Notwendig, kommt später die böse Überraschung. 

Hierzu habe ich auch ein Beispiel, basierend auf einer wahren Geschichte. Es war einmal ein PLM-System Berater, der bei einem großen mittelständischen Unternehmen im PLM-Projekt beteiligt war. Dieser PLM-System Berater hatte das Problem, dass er Rechte und Rollen im System anlegen musste. Somit brachte er auf Sachbearbeiterebene die Frage auf, wer wann auf was zugreifen dürfe. Die Sachbearbeiter wussten das nicht und fragten ihren Manager. Der Manager war aufgebracht. Rolle und Rechte war etwas, was intern auf höhere Managementebene zu klären war und nicht auf Sachbearbeiterebene im PLM-Projekt. Als der PLM-System Berater zum nächsten Meeting kam, wunderte er sich, dass es sich anfühlte als würde er gegen eine taube, kalte Wand sprechen. Die notwendige Antwort bekam er nicht, seine Arbeit konnte er auch nicht weiter tun. Als dann über ein Jahr später Konzeptfolien mit der Sicht des Managements auf Rollen und Rechte, die, unterstützt von teuren Strategieberatern, im Projekt erstellt wurden, beim PLM-System Berater ankamen, war dieses Konzept in keiner Weise implementierbar. 

Schuld war zum Schluss der Systemanbieter mit seinen schlechten PLM-System Berater. Die Vertriebler des Systemanbieters krochen beim Kunden zu Kreuze und schenkten ihm ihren besten PLM-Methoden Berater für über ein Jahr. 

Ja, so war das damals. Zugegebenermaßen ist diese Geschichte ein klein wenig überspitzt, aber im Kern hat sie sich tatsächlich so zugetragen.

In den letzten Jahren kamen immer wieder neue Initiativen und manchmal hatte man schon das Gefühl, mit dem PLM zum Establishment zu gehören und die jungen Wilden, wie das Internet der Dinge oder Industry 4.0 rütteln draußen an der Tür der Digitalisierung. Aus ihrer persönlichen Sicht und Erfahrung: Sind diese neuen Konzepte und die Potentiale, die darin liegen, eine Konkurrenz zu unserem klassischen PLM-Gedanken – werden sich beide ergänzen müssen und dann mehr oder minder miteinander verschmelzen?

Hier würde ich die Frage gerne erweitern und bei den jungen Wilden unterscheiden wollen zwischen den Technologien und den Personen, die die Denkweisen des Silicon Valley – oder was davon bei uns angekommen ist – repräsentieren.

Zuerst zu den Personen: Ich erlebe öfters die „jungen Wilden“ als Berater oder als Mitarbeiter in Unternehmen. Sie wollen an allem und jedem rütteln, doch oft fehlt ein wenig das Verständnis für die komplexen Zusammenhänge. Ich glaube, es ist einfach die Frage, wo man sie einsetzt. Stellen sie sich eine vertikale Trennlinie zwischen Markt und Unternehmen vor. Die erste Frage, die sich ein Unternehmen zum Markt hin stellen muss, ist ob die bisherigen Geschäftsmodelle zukünftig tragfähig sind, ob sich neue Geschäftsmodelle ergeben und womit es zukünftig Geld verdienen will. Diese Frage muss unbedingt beantwortet werden. Dabei ist es durchaus sinnvoll, die „jungen Wilden“ auf die Beantwortung dieser Frage anzusetzen. Ergebnis müssen dann aber tragfähige Vorschläge für neue Geschäftsmodelle sein und nicht eine Ansammlung wilder Ideen. 

Entscheidet sich nun ein Unternehmen ein solches neues Geschäftsmodell umzusetzen, dann ist zu prüfen, inwieweit die interne Prozessfähigkeit entwickelt werden muss, um dieses Geschäftsmodell unterstützen zu können. 

Dazu ein Beispiel zum Verständnis: Zukünftig ist zu erwarten, dass der Anlagenentwickler in den IT-Werkzeugen, mit dem er die Anlage entwickelt, alle benötigten Komponenten von allen Herstellern mit allen notwendigen Daten findet. Bisher müssen die Anlagenhersteller sich im PLM solche Bibliotheken mühsam selbst aufbauen. Warum ist das so? Das könnten doch die Komponentenhersteller viel besser für all ihre Kunden tun. Dann müsste es nur einmal pro Komponentenhersteller und nicht jedes Mal für einen Anlagenbauer getan werden. Nun könnte man sagen, sie tun das ja schon, weil sie meist Cadenas 3D Daten auf ihren Webseiten anbieten und dazu auch Datenblätter. Das ist aber nicht das, was ich meine. Es geht um eine vollumfängliche klassifizierte Bibliothek, die vom PLM System abgerufen werden kann, so dass man drag and drop die Komponente ins 3D Modell zieht und dazu dann die E-Pläne, Fluidpläne und die Stücklisteninformationen im PLM verbaubar verfügbar sind. Würde ich die Digitalisierungsroadmap für einen Komponentenhersteller konzipieren, dann wären da eine Reihe von Projekten auf der Roadmap, die daran arbeiten die internen Prozesse so aufzustellen, dass die notwendigen Informationen für solche Kataloge zu meinen Produkten bereits in der Produktentstehung wie selbstverständlich mit erzeugt werden. Dafür wäre dann natürlich eine Anpassung der internen PLM-Prozesse notwendig. Diese würde sehr exakt dem klassischen PLM-Gedanken folgen, der nach wie vor hochaktuell ist. Die Umsetzung dieser würde ich dann den erfahrenen Experten und eben nicht den „jungen Wilden“ anvertrauen. Gut wäre es jedoch, wenn die „jungen Wilden“ für diesen Fall schon vorab tragfähige Konzepte zum Geld verdienen ausgearbeitet hätten.

Nun zum eigentlichen Aspekt der Frage, ob der klassischen PLM-Gedanke bestehen bleibt. Es gibt eine Reihe von Technologien, die PLM und die PLM-Systeme, wie wir sie kennen, langfristig grundlegend verändern können. Hier sehe ich z.B. das Thema Grafendatenbanken als ein zentrales Thema an. Produktstrukturen sind im Sinne der Graphentheorie Wurzelbäume (Roottrees). Es ist damit naheliegend, dass man mit Hilfe von Graphendatenbanken viel besser mit diesen umgehen kann. Wenn man die Geschwindigkeit, mit denen Graphendatenbanken Millionen von Konten in Millisekunden ausspucken, sieht dann ist das schon beeindruckend. 

Paart man diesen Gedanken mit verteilten dezentralen Datenknoten, deren Verrechtung im Sinne von Zugriff über Transaktionen mittels Blockchain abgewickelt wird, dann wären keine zentrale Datenbank mehr notwendig und damit würden ganz andere PLM-Szenarien möglich. Auf jedem Computer der Welt könnten geschützte Daten von Produkten und Komponenten liegen. Verteilte Teams und auch Freelancer könnten sehr komplexe Produkte gemeinsam entwickeln. Es könnte eine Art Open Source Katalog für Lösungsprinzipien und Komponenten geben, in die jeder, der eine gute Idee hat, sein Lösungsprinzip einbringt und wie bei Open Sorce Software eine entsprechende Lizenzbedingung vergibt. 

Wenn ein solcher Ansatz groß würde, dann könnten etablierte PLM-Hersteller durchaus ins Schwitzen kommen. Dieser Gedanken lässt sich nun weiterspinnen bis in die Produktion und die Supply Chains. Oft ist es bei physikalischen Produkten ja nicht nur die Entwicklung, sondern eben auch die Fähigkeit, diese zu produzieren. Wenn sich das noch lösen lassen würde z.B. durch additiv subtraktive Produktionsverfahren, dann hätte das das Potenzial, die Industrie und die Strukturen von Unternehmen, wie wir sie heute kennen, grundlegend zu verändern. Bisher habe ich solche Ansätze nur sehr eingeschränkt als zarte Pflänzchen wahrgenommen und daher denke ich, sie werden noch eine Weile auf sich warten lassen.

Zurück zu näherliegenden Themen: Eines das ich sehr interessant und erwähnenswert finde, ist das Thema Datenkrake, wie es mein lieber Kollege Martin Eigner gerne formuliert. Die Idee dahinter ist der Ansatz, die Altsysteme d.h. die implementierte Basis der Backbonesysteme unangetastet zu lassen und neue Prozesse auf einer sauberen darüberliegenden (PLM-)Plattform aufzubauen. Diese verbindet sich zu den Altsystemen und zieht sich die notwendigen Daten dort heraus. 

Häufig werden in der Diskussion darüber unterschiedliche Ansätze vermischt. Der eine ist es, Daten auf einer neuen Plattform zu persistieren und Geschäftsprozesse über diese Daten laufen zu lassen. Das ist dann letztendlich die Einführung eines neuen parallelen PLM-Systems und bringt große Herausforderungen in der Datensynchronisierung zwischen den Altsystemen und dem neuen System mit sich. 

Der andere fokussiert auf die besseren Datendarstellung und Datenanalyse, die zukünftig dringend notwendig sein wird. Hier sammelt man die Daten aus den Altsystemen lediglich, um sie im gemeinsamen Kontext für den Anwender darzustellen. Da die Daten unverändert bleiben und im Idealfall lediglich ad hoc gezogen werden ist die Synchronisationsproblematik in dem Fall nicht relevant.

Da viele Unternehmen in sehr alten Customizings ihres ERP gefangen sind und der Schritt dort heraus eine Neueinführung des ERP gleichkäme, ist der Ansatz der Datenkrake auf hoher Managementebene sehr verlockend, da die Meinung induziert wird, man könne alles beim Alten lassen. Daher denke ich, dass wir einen Trend in diese Richtung sehen werden. In wieweit der Ansatz trägt, lässt sich aus meiner Sicht heute nur schwer beurteilen. Wenn man ein solches Konzept mit einer flexiblen leicht PLM-Plattform aufsetzt, kann das in manchen Fällen sehr erfolgreich sein. Man muss dabei nur sehr genau hinschauen, was man macht.

Vor dem Hintergrund der zunehmend komplexer werdenden Datenwelt stellt sich die Frage, ob hier nicht auch neue Architekturen und Konzepte für das Produktdatenmanagement gedacht werden müssen. Sehen Sie dort vielversprechende Ansätze aus der Forschung und Wissenschaft?

Das mit Forschung und Wissenschaft ist aus meiner Sicht ein spezielles Thema. Es scheint mir, als würden viele in der Forschung glauben, dass das Strukturthema im Sinne der Informationsarchitektur, das es im PLM zu lösen gibt, bereits gelöst ist. Da es gar nicht so einfach ist aus diesen Fragen, die sich bei der PLM Einführung stellen, Forschungsfragen zu formulieren und noch viel schwerer, Gutachter zu überzeugen Gelder für Projekte zu mobilisieren, kann man diesen Standpunkt durchaus einnehmen. 

Die Folge ist dann, dass die Schlagwortthemen beforscht werden für die es Gelder gibt. Zu nennen wären Themen wie Model Based Systems Engineering (MBSE), Künstliche Intelligenz (KI) und Themen rund um die Internet of Things bzw. die Kommunikation zwischen Maschinen und Endgeräten etc. Es gibt eine Reihe von Forschungsprojekten in diese Richtung, die tolle Ergebnisse geliefert haben. Allen voran möchte ich das MecPro2 Projektvom Kollegen Eigner nennen, dessen Ergebnisse mir sehr gut gefallen haben.

Gehen wir aber zurück zum Thema neue Architekturen und Konzepte für das Product Lifecycle Management. Dieses Thema kann nur mit sehr guter Industrieerfahrung durchdrungen werden. Für ein Forschungsinstitut mit jungen wissenschaftlichen Mitarbeitern ohne die notwendige Erfahrung ist es daher sehr schwer, in die Tiefen dieses Themas zu gehen. Eine weitere Hürde ist die Problematik, dass Lifecycleeffekte sich im Labor nicht oder nur schwer nachbilden lassen. Daten im Labor unterliegen eben nicht der Dynamik der lebenden Daten von Unternehmen die z.B. tausende Aufträge in der Woche abwickeln müssen. 

Ich denke, das Ganze ist ähnlich gelagert wie damals beim ERP. Nachdem die Grundfunktionen des ERP, wie z.B. bei Hackstein definiert waren, war es aus Forschungssicht auch gut. Der Rest wurde von den Lösungsanbietern, allen voran natürlich im SAP-Umfeld umgesetzt. Noch heute kommen die meisten Bücher, in denen es um ERP z.B. um die praktische Disposition oder ähnliches geht, aus dem Umfeld der ERP Anbieter und sind in der Regel von Beratern und nicht von Professoren geschrieben. 

Eine leuchtende Ausnahme war und ist Professor Scheer, der mit der IDS-Scheer und dem Modellierungsansatz der ereignisgesteuerten Prozessketten echte Durchschlagskraft erzielt hat. Aus meiner Perspektive ist und war Scheer jedoch vielmehr Berater als Professor. In meinen jungen Assistentenjahren habe ich viele seiner Bücher gelesen und er hat mich damit sehr inspiriert.

Heute haben wir eine ähnliche Situation im PLM. Die komplexen Zusammenhänge lassen sich viel besser in der Praxis erforschen. Daher kenne ich kein Forschungsprojekt, das sich mit diesen Themen intensiv beschäftigt. Lediglich ab und an fällt mir eine Industriedissertation in die Hände, in der Aspekte des Themas behandelt werden.

Um Themen rund um die Informationsarchitektur aufzuschlüsseln und zukünftige Konzepte für das Produktdatenmanagement weiterzuentwickeln, haben einige befreundete Berater, ausgewählte Unternehmen und unser STZ-RIM Team eine Art virtuelles Netzwerk gebildet. Unser großes Ziel ist die Definition und Systematisierung der Prozessmuster im PLM. Ein solches Prozessmuster bildet dann den Bezugsrahmen der Implementierung. Als Arbeitsergebnis wollen wir einen Katalog aus Prozessmuster formulieren, die wir Unternehmen je nach Bedarf zuordnen können. Die Zuordnung erfolgt dann Aufgrund von Merkmalen des jeweiligen Unternehmens selbst und Merkmalen der von den Unternehmen hergestellten Produkte. Da wir der Überzeugung sind, dass sich dieses Thema in Industrieprojekten besser lösen lässt, agieren wir nicht primär in Forschungsprojekten, sondernarbeiten mit unseren Industriepartnern an entsprechenden Konzepten. Da Konzepte nur einen Wert haben, wenn sie sich auch umsetzen lassen, begleiten wir auch die Umsetzung und passen notfalls die Konzepte entsprechend den Anforderungen der Umsetzung an.

Was ist das mit der Cloud? Ist das doch nur einfach ein Server, der „woanders steht“ oder ist das die Strategie und Lösung für das IT Infrastukturmanagement für eine Unternehmenssoftware wie PLM?

Die Cloud im Sinne von „Cloud und sonst nichts“ ist in einer ersten Stufe ein Thema für das Infrastrukturmanagement. Plötzlich ist es nicht mehr notwendig eine eigene Installation am Leben zu erhalten. Schon das wird große Auswirkungen auf die IT-Abteilungen in mittelständischen Unternehmen haben. Flapsig gesagt funktioniert IT im Mittelstand oft folgendermaßen: Die IT hängt unter dem kaufmännischen Geschäftsführer und ist kaputtgespart. Sie sieht ihre Aufgabe darin SAP am Laufen zu halten Z-Transaktionen zu schreiben und Laptops zu installieren. Das höchste der Gefühle ist dann ggf. noch ein Ticket System. 

Mit der Cloud kommen daher IT-Abteilungen mit einem derartigen Selbstverständnis schnell stark unter Druck, da einerseits der wesentliche Arbeitsinhalt wegfällt und andererseits ein Vakuum entsteht, weil sich niemand der Gestaltung einer durchgängigen Informationsarchitektur über die Backbonesyteme hinweg annimmt. Es entstehen dann strategische Abteilungen, deren Aufgabe es ist, die Prozesse und Informationsarchitektur End-to-End zu definiert und damit das Vakuum in den IT-Abteilung zu kompensieren. 

Ich sehe das schon heute bei vielen Unternehmen. Oft beginnt es an Stellen, an denen das Vakuum als erstes wahrgenommen wird z.B. in der Entwicklung oder in der Organisationsentwicklung – bei beiden ist das naheliegend. Schauen wir auf die Entwicklungsabteilung: Dort wird über neue Leistungen für den Kunden z.B. erweiterte Serviceangebote etc. nachgedacht. Diese sind oft mit den vorhandenen Prozessen und auf Basis der vorhandenen Informationsarchitektur nicht zu bewältigen. Damit entsteht aus dieser Richtung Druck, etwas zu verändern. Im Falle der Organisationsentwicklung verhält es sich ähnlich. Diese Abteilungen fangen an, Prozesse zu modellieren und schaffen damit Bewusstsein, Verständnis und Verantwortliche für eben diese Prozesse. Werden nun neue Anforderungen an die Prozesse gestellt, kommen diese häufig zuerst beim Prozessmanagement an und diese Abteilung nimmt dann das Heft in die Hand. 

Vor diesem Hintergrund denke ich, wir werden einen sehr interessanten Wandel in den IT-Abteilungen sehen, da die klassische System- und Installationsdenke keine Zukunft mehr hat. Die CIOs und IT-Leiter müssen sich dann schon, fragen was ihre zukünftige Rolle sein wird. 

In der Umsetzungsbegleitung von PLM Projekten heben Sie Ihre Erfahrung mit Siemens Teamcenter hervor. Handelt es sich hierbei um eine exklusive Partnerschaft oder betreuen Sie auch Projekte von anderen PLM-Systemherstellern?

Natürlich habe ich als ehemaliger Tecnomatix Mitarbeiter, der über UGS zu Siemens kam, Siemens viel zu verdanken. Zudem habe ich ein starkes Netzwerk in die Siemens Industrie Software und werde mit dieser immer sehr freundschaftlich verbunden sein. 

Es wäre jedoch für den Anspruch an meine Beratung unverzeihlich, wenn ich mich nicht intensiv mit unterschiedlichen PLM, ERP, MES und CRM-Systemen beschäftigen würde. 

Man darf auch nicht die Augen vor der Tatsache verschließen, dass es im Bereich PLM einige sehr gute Anbieter gibt die tolle PLM-Systeme haben. 

Meine Aufgabe sehe ich darin, meinen Kunden zu helfen für den jeweiligen Anwendungsfall das geeignete System zu finden. Dazu ist es notwendig die vielen ganz unterschiedlichen Kriterien die es als Grundlage für eine solche Entscheidung transparent zusammenzutragen um dann zu einer passenden Auswahl zu kommen.

Weil es gerade aktuell und in aller Munde ist, wie schätzen Sie die Kooperation zwischen Siemens und SAP ein? SAP, so steht es in manchen Veröffentlichungen, wird ja zukünftig Teamcenter verkaufen und sich nicht mehr so sehr auf die Entwicklung des eigenen SAP PLM fokussieren.

Insbesondere für die europäische Industrie freut es mich sehr, dass diese beiden großartigen Unternehmen nun mit dem Ziel kooperieren, durchgängige Digitalisierungslösungen anbieten zu können. Das ist eines der interessantesten und besten Dinge, die passieren konnten.

Für die Kunden kann das einzigartig werden. Dafür muss jedoch die methodisch technische Integration stimmen. Daher möchte ich das Thema hier aus dieser Sicht erläutern. 

 

Die Frage ist, wie die Verbindung zwischen einem PLM-System und ERP-System zukünftig realisiert wird und werden sollte. 

Bild von <a href="https://pixabay.com/de/users/geralt-9301/?utm_source=link-attribution&utm_medium=referral&utm_campaign=image&utm_content=1691275">Gerd Altmann</a> auf <a href="https://pixabay.com/de/?utm_source=link-attribution&utm_medium=referral&utm_campaign=image&utm_content=1691275">Pixabay</a>

Diese Frage muss man sowohl auf der Ebene Informationsobjekt beantworten als auch auf Strukturebene. Auf Informationsobjektebene stellt sich die Frage, welcher Objekttyp wo gehalten wird und wer wann den Master dafür hat. Dabei geht es konkret um die Typen CAx-Dokument und Material. Auf der Strukturebene stellt sich die Frage, welche der zentralen

 

Strukturen CAD-BOM, EBOM oder MBOM synchronisiert werden und wo der jeweilige Master liegt. Themen wie Konfiguration und die Notwendigkeit einer einheitlichen Konfigurations-Engine, Arbeitsplan, Montageanleitung, NC-Programmversorgung, die Digitalen Zwillinge as deliverd und as maintained sowie Servicebom weglassen, gibt es im Wesentlichen zwei Integrationsszenarien.

Szenario I:

Das PLM-System fungiert als Managementsystem zur Dokumentdatenablage und zum Lifecyceln der Daten der Authoringsysteme. Die Materialentstehung und die Reifegradentwicklung des Materials finden dann im ERP statt. In diesem Szenario wäre das Erstellen und Halten der EBOM im PLM in der frühen Phase der Entwicklung möglich. 

Szenario II:

Wie Szenario I wobei zusätzliche EBOM und alle werksspezifischen MBOM’s im PLM entstehen und von dort voll ins ERP synchronisiert werden. Die Struktur- und Reifegradentwicklung des Materials findet im PLM statt, die Pflege der Attributierung ist dann aufgrund der vollen Synchronität zwischen den Systemen in beiden Systemen jederzeit möglich.

Szenario I ist das, was sich heute zwischen ERP und den meisten PLM-Systemen gut implementieren lässt. PLM würde dabei allerdings nicht als PLM agieren, sondern lediglich als PDM/TDM System. In Wirklichkeit wäre dann die PLM Schicht im ERP und würde auf den heute vorhandenen Datenmodell und Funktionen von SAP ERP basieren. 

Das Szenario I hat jedoch den entscheidenden Nachteil, dass genau die Mehrwerte, die man durch die Kooperation ja erreichen will, nicht erreicht werden können. Das liegt darin begründet, dass PLM in diesem Szenario von den Downstreamänderungen der Werke abgekoppelt wäre und die Idee des Digital Threads bzw. der Feedbackloop Ansatz nicht funktionieren würde. 

Szenario II ist aus meiner Sicht die unbedingt zu wählende Option. Es ist aber auch der Königsfall im Hinblick auf die technische Umsetzung in den PLM-Systemen. 

Wie schon erwähnt, ist hier das zugrundeliegende Problem, dass alle heutige PLM-Systeme die ja von PDM-Systemen abstammen mit Material nicht so gut umgehen können. Ich weiß, einige unserer Leser werden einwenden, dass PLM-Systeme sehr wohl den Objekttyp Part oder Material haben und damit Material kennen. Diejenigen, die sich tiefer mit der Materie beschäftigen, wissen jedoch, dass es an dieser Stelle eine Reihe von Fragezeichen gibt, die ich hier nicht weiter darlegen möchte.

Die eigentliche Hürde ist die mangelnde Fähigkeit der meisten heutigen PLM-Systeme, Werksichten des Materials, Werksstücklisten und Stücklistenverwendungen abzubilden. Ein ERP das unterschiedliche Werke abbildet kann das natürlich. 

Etwas vergleichbares in PLM-Systemen mit Bordmitteln bei einer Implementierung aufzubauen ist zwar möglich, jedoch muss man dann mit durchaus schmerzlichen Einschränkungen leben. Meistens wird hierfür auf Partebene der Revisionsmechanismus genutzt. Dies widerspricht jedoch der eigentlichen Einsatzintension dieses Mechanismus und wirkt sich daher oft sehr störend auf die Implementierung aus. Dadurch droht dann jederzeit Gefahr, dass bei kleineren Erweiterungen des PLM das stark angepasste Datenmodell auseinanderfliegt und quasi das Tor zur Hölle aufgeht. 

Um hier zukünftig echte Abhilfe zu schaffen, wird es notwendig sein, tief in den Datenmodellen der PLM-Systeme grundlegende Änderungen einzubauen, so dass auch dort echte persistierbare Werkssichten abgebildet werden können. 

Das ist aus meiner Perspektive eine Hausaufgabe an alle PLM-Anbieter auf dem Markt. Ich denke der PLM-Anbieter, der es zuerst löst und damit eine volle Synchronität von EBOM und den MBOM’s zwischen PLM und ERP etablieren kann, schafft sich eine ausgezeichnete Marktposition. 

Wenn es diesem Anbieter darüber hinaus noch gelingt, den Kunden die Notwendigkeit und den Mehrwert, der sich daraus ergibt, nahezubringen, hat er große Chancen auf einen durchschlagenden Markterfolg.

Wenn Siemens das gemeinsam mit SAP in dieser Tiefe angeht, würde mich das sehr begeistern. Das wäre ein großer vermutlich auch der entscheidende Schritt in die Richtung Digitalisierung.

Herr Prof. Fischer, ich danke Ihnen sehr für dieses aufschlußreiche Gespräch und wünsche Ihnen für die kommenden Aufgaben sehr viel Erfolg.

Systemvalidierung von PLM-Systemen in der Medizingeräteindustrie

Wir leben in turbulenten Zeiten. Ein Effekt der ganzen Corona- und Covid-19-Gemengelage ist ein neue Wahrnehmung der Leit-Industrie in Deutschland. Wenn man heute im Familien- und Bekanntenkreis sich zum Video-Call verabredet, spricht man nicht mehr über die Anschaffung des neuen Familienautos oder die Assistenzsysteme des neuen Dienstwagens. Eine neue Industrie, die bisher nicht im Fokus der öffentlichen Wahrnehmung stand, rückt in die Mitte des Interesses: Die Hersteller von Medizintechnik und -geräten.
Laut der Angaben des statistischen Bundesamtes belief sich der Gesamtumsatz dieser Branche im Jahr 2018 auf ca. 30 Mrd. Euro. Man muss kein Hellseher sein, um den Unternehmen eine steigende Umsatzkurve zu prognostizieren.
In den letzten Jahren habe ich einige PLM-Implementierungsprojekte in dieser Branche begleiten und dabei auch die besonderen Herausforderungen kennen lernen dürfen. Und um eine besondere soll sich heute dieser Artikel drehen: Die Validierung des PLM Systems.
Bevor wir jedoch in die fachlichen Tiefen abtauchen, möchte ich aber noch einen Disclaimer einschieben: Dieser Artikel ist keine Rechtsberatung zum Bestehen von Audits der Aufsichtsbehörden. Er soll lediglich Anregungen und Hinweise zur Lösungsfindung geben, die auf meiner Projekterfahrung basieren.

Bild von <a href="https://pixabay.com/de/users/RobynsWorld-1577075/?utm_source=link-attribution&utm_medium=referral&utm_campaign=image&utm_content=2610509">Robyn Wright</a> auf <a href="https://pixabay.com/de/?utm_source=link-attribution&utm_medium=referral&utm_campaign=image&utm_content=2610509">Pixabay</a>

Doch fangen wir einmal am Anfang an und fragen uns, warum ein PLM-System nach Regeln der Medizintechnik validiert werden muss. Und wer bestimmt eigentlich die Regeln für diesen Vorgang?
Als eine wichtige Quelle sei die ISO13485:2016, Kapitel 4.1.6 genannt, in dem explizit gefordert wird, dass die Hersteller Verfahren zur Software-Validierung für Software festlegen müssen, die das Qualitätsmanagementsystem nutzt. Diese Validierung sei risikobasiert durchzuführen. Zur weiteren Recherche sei hier auf die exzellenten Webseiten des Johner-Instituts verweisen.

Taucht man etwas tiefer in diese Validierungsanforderungen ein, liegt der Verdacht nahe, das lediglich wasserfallbasierte Projektvorgehensmodelle diese erfüllen können und zu einer auditsicheren Systemvalidierung führen. Diese Vorgehensmodelle konnten aber nicht den Nachweis erbringen, zum Erfolg von PLM-Projekten beitragen zu können.
Agile und inkrementelle Vorgehensmodelle sind an deren Stelle getreten und seit Jahrzehnten Stand der Wissenschaft für die Einführung von PLM-Systemen. Schaut man sich aber diese Vorgehensmodell an, stehen diese teilweise im Widerspruch zu den Forderungen zur Systemvalidierung. Welche Methoden und Aktivitäten- in “agilisch“ Artefakte – können diesen gordischen Knoten zerschlagen? Dieser Blogeintrag liefert eine Antwort auf diese Frage.

Dokumentation von Anforderungen:

Auch bei agilen Projekten werden natürlich Anforderungen an das zukünftige PLM-System aufgenommen. Das fängt bei einer generellen Scope Definition an und wird dann immer weiter herunter gebrochen und weiter detailliert. Verfahren und Methoden zur Businessanalyse gibt es viele und ich möchte hier nicht weiter ins Detail gehen, um den Umfang des Artikels nicht zu sprengen.
Meine Erfahrung zeigt einen klare Tendenz zu “User Stories” als meistverwendete Methode zur Dokumentation von Anforderungen. Und genau diese Dokumentation wird auch für die Systemvalidierung verlangt. Somit ist das gar kein Mehraufwand außer dem, die User Stories ordentlich zu dokumentieren. Und das macht man auch im agilen Kontext im Product Backlog und später dann im Sprint Backlog.

Der Teufel steckt hierbei eher im Detail der Dokumentation. User Story ist nicht gleich User Story und die beiden folgenden Beispiele illustrieren das:

  • Als Anwender möchte ich meine Design Control Aktivitäten und Prozesse im PLM-System abbilden, um während eines FDA-Audits die geforderte Nachverfolgbarkeit nachweisen zu können
  • Als Testingenieur möchte ich die genauen Parameter für das Maximalgewicht meines Testproduktes angezeigt bekommen, um diese mit der Anzeige der Laborwaage vergleichen zu können.

Beides sind formal korrekt dokumentierte User Stories, aber es ist deutlich der unterschiedliche Detaillierungsgrad zu erkennen. Die erste User Story ist eher so etwas wie der Intended Use des PLM-Systems und beschreibt eine Hauptanforderung, warum ein Medizintechnikunternehmen überhaupt ein PLM-System einführt. Der Aufwand für die Implementierung liegt hier eher bei Monaten oder sogar Jahren und viele Details sind noch vollkommen unklar und müssen entwickelt werden. Die zweite User Story ist da deutlich kleiner und genauer. Es liegt in der Natur der Sache, dass in einem PLM-Projekt User Stories dynamischen Änderungen unterliegen und somit unterschiedliche Reifegrade haben.

Die Anforderungen müssen reifen

Am Anfang stand das Wort des zukünftigen Nutzers eines PLM-Systems – in Form von Prozess-Schaubildern, Funktionsbeschreibungen, Definition von gewünschten Features und Schnittstellen und noch vielem mehr. Im Branchenjargon entspricht das dem Intended Use und den User Requirements des PLM-Systems. Der Reifegrad dieser Anforderungen ist aber noch weit davon entfernt, die notwendigen Details für eine Implementierung zu liefern. Es fehlen die Beschreibung von Systemumgebungen, Eingangsgrößen und Vorbedingungen, Akteuren und Berechtigungen und noch vieles mehr.
Des Weiteren bringt ein erfahrener Implementierungspartner seine Expertise ein, wie bestimmte Herausforderungen gut gelöst werden können. Oft können hier erhebliche Einsparpotentiale gehoben werden, wenn auf vorkonfigurierte oder bewährte Lösungen zurückgegriffen und nicht das Rad neu erfunden wird.
Und zu guter Letzt fehlen auch noch eine Reihe von Informationen, die für die Systemvalidierung benötigt wird. Das sind in erster Linie die Akzeptanzkriterien, deren klare Definition unabhängig von einer Validierung in jedem PLM-Projekt eine super Idee ist. Aber auch über mögliche Testszenarien, wie diese Akzeptanzkriterien geprüft werden sollen, müssen hier besprochen und dokumentiert sein.
Gerade bei stark integrativen PLM-Projekten ist die kontinuierliche Pflege der IT-Landkarte angebracht. Je nach Technologie und Architektur des gewählten PLM-Anbieters und der Komplexität der Anforderungen kann die Checkliste noch deutlich mehr Kriterien enthalten, bevor eine Anforderung “implementierungsreif” genannt werden darf. In der Sprache der Agilität wird das die “Definition of Ready DoR” genannt.
Die Erfahrung zeigt, dass der Aufwand des Reifens einer Kundenanforderung bis zum Erreichen der DoR von Anwenderseite fast immer unterschätzt, manchmal sogar in den Budgetplanungen gar nicht berücksichtigt wird.
Aus Validierungssicht ist die DoR aber ein großartiges Quality-Gate, das bei sinnvoller Kriterienliste nebenher den ersten Schritt der Systemvaliderung erledigt. Die Anforderungen sind klar dokumentiert, Akzeptanzkriterien definiert und Testszenarien und -fälle spezifiziert. Es kann mit der Umsetzung und Implementierung begonnen werden

Anforderungen werden zum Funktionen und Features

Das Implementierungsteam nimmt die DoR-reifen User Stories und Anforderungen auf und setzt diese um. Analog zur DoR gibt es auch eine Checkliste, deren Kriterien zur erfolgreichen Umsetzung der Anforderung erreicht werden muss: Die “Definition of Done DoD“.
Bild von <a href="https://pixabay.com/de/users/geralt-9301/?utm_source=link-attribution&utm_medium=referral&utm_campaign=image&utm_content=3382521">Gerd Altmann</a> auf <a href="https://pixabay.com/de/?utm_source=link-attribution&utm_medium=referral&utm_campaign=image&utm_content=3382521">Pixabay</a>Ein offensichtliches Kriterium ist das erfolgreiche Passieren der Testszenarien und Erreichen der Akzeptanzkriterien aus der DoR. Bei der Spezifikation der Testdaten sollten Sie nicht nur vom besten Fall ausgehen, auch falsche Eingaben ausprobieren. Des Weiteren ist das Beschreiten von alternativen Prozesspfaden eine gute Idee. Auch Code-Reviews oder die Prüfung auf Coding-Rules sind Mittel zu Steigerung der Softwarequalität. Die Dokumentation der Testergebnisse und dem Erreichen aller Kriterien der DoD genügt dann in der Regel als Nachweis für die Softwarevalidierung.
Hinweise und Empfehlungen zur richtigen Organisation und Toolunterstützung des Testens füllen Fachartikel und -Bücher. Als wichtige Erfahrungswerte sollte auf den Umstand hingewiesen werden, dass diese Tests keine einmalige Sache sind, sondern dass diese regressiv bei erneuten Änderungen am PLM-System erneut durchgeführt werden müssen. In der Praxis haben sich folgende Maßnahmen zur Reduzierung des wiederkehrenden Testaufwandes bewährt:

Risikobewertung

Die Risikobewertung hinsichtlich der Patientengefährdung ist ein Standardverfahren der Medizingeräteentwicklung und das gilt auch für die Validierung an das PLM-System. In den Projekten wird immer wieder intensiv über die reale Patientengefährdung bei einer Fehlfunktion des PLM-Systems diskutiert. Sicher kann man Szenarien herleiten, aber in diesen sind es immer einige Schritte vom der Benutzung des PLM-Systems hin zur Benutzung des Medizingeräts. Man sollte hier den gesunden Menschenverstand nicht außer Acht lassen und mit Augenmaß dieses Risiko bewerten. In einem vergangenen Projekt stellte dazu ein QM-Verantwortlicher mal fest, dass das Risiko aufgrund einer Fehlfunktion im PLM-System ernsthafte Probleme im Audit zu bekommen um Zehnerpotenzen höher ist als das einer Patientengefährdung.
Die Risikobewertung ist aber nicht nur ein erhöhter Aufwand ohne wirklichen Nutzen. Man kann dieses Werkzeug gut einsetzen, um kritischen Anwendungsfälle und Funktionen zu identifizieren und somit den Testaufwand zu skalieren. Und das Testen ist auch nicht die einzige risikominimierende Maßnahme. Schulungen und Awareness-Sessions oder zusätzliche Prüfschritte in den jeweiligen Prozessen können unter bestimmten Voraussetzungen deutlich günstiger als ein Softwaretest sein.

Das richtige Level finden

Wie vorhin an den beiden User Stories gezeigt, können Anforderungen unterschiedlich umfangreich und komplex sein. Eine Umsetzung in einem Sprint ist nicht möglich. Es ist somit notwendig, diese Anforderungen in kleinere Stücke zu schneiden und aufzuteilen. Die Risikobewertung wird dann für alle diese Anforderungs-Stücke vorgenommen, was zu einem doch recht erheblichen Aufwand führen kann.
Es kann daher sinnvoll sein, über das richtige Level nachzudenken, auf dem die Risikobewertung durchgeführt wird. Es erscheint wenig zielführend, auf granularem Detaillevel der Anforderungen eine Evaluierung durchzuführen. Ein Erkenntnisgewinn ist nicht gegeben und lediglich der Aufwand für die Erstellung und Pflege steigt.

Testautomatisierung

Bild von <a href="https://pixabay.com/de/users/geralt-9301/?utm_source=link-attribution&utm_medium=referral&utm_campaign=image&utm_content=3075837">Gerd Altmann</a> auf <a href="https://pixabay.com/de/?utm_source=link-attribution&utm_medium=referral&utm_campaign=image&utm_content=3075837">Pixabay</a>

Wie schon oben erwähnt, ist die Systemvalidierung bei jeder Systemänderung erneut vorzunehmen. Ein bewährtes Mittel zur Reduzierung des Aufwandes für wiederkehrende Testfälle ist die Testautomatisierung, die mit Augenmaß eingesetzt werden kann. Es ist abzuwägen, bei welchen Testfällen sich der Aufwand zur Erstellung und Pflege der Automatismen gegen die Ersparnis der manuellen Testausführung lohnt. In diese Rechnung müssen auch die Anschaffungs- und Pflegekosten der Testwerkzeuge berücksichtigt werden.

Testreport der PLM-Systemhersteller

Einige PLM-Systemhersteller bieten sogenannte Validierungspakete an. Diese Dokumente erbringen den Nachweis der Systemvalierung für die Standardfunktionen des Systems. Diese Aussagen können natürlich herangezogen werden und sorgen somit für eine Verringerung des Validierungsaufwandes beim Medizingerätehersteller.
Das gilt aber nur, solange diese Standardfunktionen nicht angepasst, konfiguriert, ergänzt oder erweitert wurden. Auch Seiteneffekte sind dabei zu beachten und daher sind die Einspareffekte meist geringer als man sich das auf den ersten Blick erhofft hatte.

Was es noch zu beachten gilt

PLM-Systemhersteller und -Implementierungspartner bringen meist Wissen und Erfahrung zur Systemvalierung mit, aber verantwortlich ist das Medizingeräteunternehmen dafür. Somit ist es dafür zuständig, die Anforderungen an sein PLM-System zu dokumentieren und die Prozesse, die zu deren Reifung und Umsetzung führen. Ebenso sind es auch seine  DoR- und DoD Kriterien. Eine Herausforderung ist dabei mit Sicherheit die Dynamik, die eine PLM-Systemeinführung nunmal mit sich bringt. Neben der Hilfe und Unterstützung des Implementierungspartners gibt es auch sehr gute Softwarewerkzeuge, die dabei helfen und unterstützen können.

Guten Tag, mein Name ist PLM und womit kann ich helfen?

Als PLM Consultant ist es ja ein wenig wie mit der Polizei, man wird nur dann gerufen, wenn etwas im Argen liegt. Bei der Polizei geht es da eher um gesellschaftliche und rechtliche Konflikte, bei uns PLM-lern eher um betriebswirtschaftliche oder technische Probleme. Und genau um diese Auslöser, die zu einem Anruf bei uns führen, geht es in meinem heutigen Artikel.

Bild von <a href="https://pixabay.com/de/users/geralt-9301/?utm_source=link-attribution&utm_medium=referral&utm_campaign=image&utm_content=257882">Gerd Altmann</a> auf <a href="https://pixabay.com/de/?utm_source=link-attribution&utm_medium=referral&utm_campaign=image&utm_content=257882">Pixabay</a>

Auslöser gibt es derer viele und oftmals spielt das Thema PLM zu diesem Zeitpunkt noch gar keine Rolle. Eine industrieübergreifend recht oft genannte Herausforderung ist, dass die Produktentwicklung im Vergleich mit den Mitbewerbern zu lange dauert und/oder dass die Kosten dafür zu hoch sind. Die Konkurrenz kann das einfach schneller, besser und zu geringeren Kosten, was im Wettbewerb ein klarer Nachteil ist.

Wie gesagt, diese Erkenntnis wird nicht aus einem ingenieurigen PLM-Kontext heraus gewonnen, sondern ist eher eine aus den üblichen betriebswirtschaftlichen Auswertungen und Bilanzen. Und die Inhaber, Geschäftsführer und CXOs dieser Welt wollen natürlich dieses Problem gelöst haben. Und noch immer denkt niemand an den Kauf von PLM-Software.

Die Ursachenforschung beginnt und das jeweilige Unternehmen stellt sich die Frage nach den Gründen. Warum sind wir langsamer und  später dran als unsere Mitbewerber? Warum müssen wir deutlich mehr Geld in die Hand nehmen, um unsere Produkte auf den Markt zu bringen? Warum adaptieren unsere Mittbewerber eher neue Trends und gehen in neue Märkte? Und wo geht unsere Effizienz in die Binsen? Noch immer hat niemand das Wort PLM in den Mund genommen.

Die Antworten auf diese Fragen können sehr vielfältig sein und sind natürlich abhängig von der konkreten Situation. Aber es gibt natürlich einige Beispiele:

A) Unsere Mitarbeiter benBild von <a href="https://pixabay.com/de/users/AbsolutVision-6158753/?utm_source=link-attribution&utm_medium=referral&utm_campaign=image&utm_content=2636259">Gino Crescoli</a> auf <a href="https://pixabay.com/de/?utm_source=link-attribution&utm_medium=referral&utm_campaign=image&utm_content=2636259">Pixabay</a>ötigen sehr viel Zeit, um Informationen für ihre täglichen Aufgaben zu finden und müssen zusätzlich Aufwände investieren, um die Gültigkeit und Aktualität dieser Daten zu überprüfen. In regulativen Branchen wie der z.B. Medizintechnik fällt so etwas auf, wenn in der Verifikation gar nicht klar ist, gegen welche Anforderungen geprüft und getestet werden soll. Oder in der Simulation müssen sich die notwendigen CAD Daten mühsam zusammengesucht werden, die im Entwicklungsprozess auch noch ständigen Änderungen unterliegen. Oder das Supply Chain Management hat Schwierigkeiten nachzuvollziehen, welche Daten jetzt in welchem Stand an Zulieferer gegangen sind.

B) Unsere Produkte müssen vor dem Markteintritt von Aufsichtsbehörden zugelassen werden und wir bekommen diese Erlaubnis immer sehr spät. Eigentlich zu spät, da wir technisch bereits in der Lage wären, diese Produkte zu produzieren und auszuliefern. Die Gründe sind vielschichtig. Es kann sein, dass wir erst sehr spät im Produktentwicklungsprozess in der Lage sind, die notwendigen Unterlagen den Aufsichtsbehörden zu überlassen. Oder die Aufsichtsbehörde hat Rückfragen oder bemängelt den Inhalt.

C) Unsere Marktanteile sinken, weil unsere bisherigen Kunden den höheren Innovationsgrad der Wettbewerbsprodukte honorieren. Die Ursache für das Verpassen von Trends kann in der fehlenden Weiterbildung der Mitarbeiter aus der Produktentwicklung liegen. Sie waren lange nicht mehr auf Tagungen oder haben lange keine Messen mehr besucht. Sowohl die interne als auch die externe Weiterbildung wurden vernachlässigt.

Wenn wir uns diese drei Antworten mit der PLM-Brille ansehen, dann kann ein PLM-System bei A) und B) eine wertvolle Unterstützung zur Lösung dieser Herausforderungen sein. PLM-Systeme sind prädestiniert dafür, den Informationsfluss rund um die Produktdaten zu verbessern und Menschen, Systeme, Prozesse und Daten zusammenzubringen. Somit könnten Analyseergebnisse wie diese der Start für eine PLM-Initiative sein und gleichzeitig definieren sie auch die ersten Erfolgsfaktoren.

Bei C) ist das eher nicht der Fall, hier sollten andere Maßnahmen zur Abstellung und Lösung ergriffen werden. Das Erarbeiten von Weiterbildungskonzepten oder die Bereitstellung von Budget für den Besuch von Tagungen und Messen – PLM kann vieles, aber hier ist es eher nicht so wirksam.

Die Out-of-the-box Lüge in PLM-Systemauswahlen

Nach zwei wirklich aufschlussreichen Artikeln des Gastautors Markus Ripping bin ich jetzt mal wieder dran mit einem Blogpost. Und der provokant gewählte Titel deutet auch schon die Richtung an. Es wird wieder etwas praktischer und geht und die Auswahl des richtigen PLM-Systems – wenn es das eine “richtige” überhaupt gibt.

PLM Änderungen sind notwendig

In den letzten 20 Jahren konnte ich an vielen Projekten mitarbeiten, die sich mit der Auswahl eines geeigneten PLM-Systems beschäftigt haben. Dabei habe ich beide Seiten kennengelernt, sowohl die des Kunden als auch die des potenziellen Software-Lieferanten. In den allermeisten Fällen wird im Rahmen einer mehr oder minder ausführlichen Analysephase ein Kriterienkatalog erarbeitet, in dem basierend auf den aktuellen Geschäftsprozessen Anforderungen an das zukünftige Wunschsystem zusammengefasst werden.

Dieser Fragebogen kann auch gerne mal eine mehrere Quadratmeter große Exceltabelle sein mit den Antwortmöglichkeiten “Out-of-the-box”, “Anpassung mit geringem Aufwand”, “Anpassung mit höherem Aufwand” und “Individuelle Entwicklung”.

In einigen, wenigen Fällen wird auch nach nicht funktionalen Anforderungen (z.B. notwendige Infrastruktur, Integrationsfähigkeiten, Anbindung verteilter Standorte, …) gefragt, um diese ebenfalls zu bewerten. Das passiert aber eher seltener, meistens bleibt es beim Abfragen Funktionen und Features.

Die nach besten Wissen und Gewissen von den potenziellen Softwarelieferanten gelieferten Antworten werden dann verglichen und gewichtet und übrig bleiben dann die Systeme, die in die engere Auswahl kommen. An dieser Stelle möchte ich dem geneigten Leser, der sich hier wiedererkennt, zwei Fragen stellen:

Denken sie bitte 3-5 Jahre zurück. Wie hätte dort ihr Fragenkatalog ausgesehen? Ist er komplett identisch mit dem, den sie heute entwickelt haben und Ihre Geschäftsprozesse und Daten haben sich in den letzten 3-5 Jahre nicht weiterentwickelt?

Denken Sie einmal 3-5 Jahre voraus. Wird der Kriterienkatalog in der Zukunft komplett identisch sein mit dem, den sie heute haben? Lesen Sie dazu auch den Artikel von Markus zum Thema Dynaxity.

Wenn sie in beiden Fällen absolut sicher sind, das sich Ihre Anforderungen an ihr PLM-System über 6-10 Jahre nicht ändern werden, dann bringt dieser Artikel ihnen keinen Erkenntnisgewinn. Dann werden Sie mit der oben geschilderten Auswahl das perfekte System für sie finden.

Es ist natürlich überhaupt nichts falsch daran, nach einer möglichst großen Schnittmenge zwischen eigenen Anforderungen und Out-of-the-box-Features zu suchen, ganz im Gegenteil. Natürlich gibt es eine ganze Reihe Anwendungsfälle, die eher stabil sind und bleiben und die wollen Sie natürlich möglichst “ready for use” vorfinden.

Aber mit an Sicherheit grenzender Wahrscheinlichkeit werden sich die Anforderungen an Ihr PLM-System ändern, einige werden hinzukommen, andere werden gar nicht mehr so wichtig sein und vielleicht ganz wegfallen. Daran besteht kein Zweifel. Und genau dieses immens wichtige Kriterium spielt in fast allen PLM-System Benchmarks überhaupt keine Rolle und wird immer “vergessen”: Wie gut, wie einfach, wie schnell und mit welchen Wissen kann ich mein System an zukünftige Anforderungen anpassen? Es ist schließlich ihr PLM-System und nicht das PLM-System, das ein PLM-Systemhersteller für geeignet für sie hält. Und im Gegensatz zu anderer Unternehmensoftware reden wir hier von Daten und Prozessen rund um ihr Produkt. Exakt dem “Ding”, mit dem sie ihr Geld verdienen, das etwas einzigartiges beinhaltet, dass sie von Ihrem Wettbewerb unterscheidet. Und wir sprechen über Daten und Prozesse, die das Herz, Wirbelsäule und Nervenbahnen Ihres Unternehmens bedeuten und diese gehorchen eher nicht vordefinierten Features, die auch Ihre Marktbegleiter einsetzen.

PLM Systemvergleiche vollständig durchführenDas sie ihr PLM-System an Ihre individuellen Bedürfnisse anpassen werden, ist unausweichlich. Und genau für diese Fall schauen sie genau hin, was ihre potenziellen Anbieter können. Vertrauen sie nicht auf schicke Powerpoints oder vorgefertigte Presales-Szenarien. Probieren Sie es aus, wie es sich anfühlt, das PLM-System zu verändern, anzupassen, neue Anforderungen an Daten und Prozesse abzubilden. Was müssen Sie dafür in Ausbildung investieren? Werden spezielle Entwicklungsumgebungen und besondere Kenntnisse dafür benötigt? Kann ich Anpassungen überhaupt selbst vornehmen oder muss ich immer einen Spezialisten dafür beauftragen? All diese Fragen werden sehr schnell sehr wichtig für einen PLM-Systemanwender und müssen daher in meinem Benchmark eine signifikante, wenn nicht sogar die signifikanteste Rolle spielen.

Warum machen wir nicht PLM End2End?

Markus Ripping, der Autor des letzten Gastbeitrags, greift in seinem neuen Artikel weitere Aspekte der Digitalisierung und der vor uns stehenden Herausforderungen im PLM Business auf und teilt diese Gedanken mit der geneigten Leserschaft. Vielen Dank dafür. Ich selbst habe einige neue Erkenntnisse gewinnen können. Aber genug der Vorrede, hier ist der Artikel:

Bild von <a href="https://pixabay.com/de/users/geralt-9301/?utm_source=link-attribution&utm_medium=referral&utm_campaign=image&utm_content=3746923">Gerd Altmann</a> auf <a href="https://pixabay.com/de/?utm_source=link-attribution&utm_medium=referral&utm_campaign=image&utm_content=3746923">Pixabay</a>

Bild von Gerd Altmann auf Pixabay

PLM ist ein in der Industrie seit Jahrzehnten etablierter Begriff. Dennoch sieht man erst in den letzten Jahren eine tatsächliche Bewegung hin zum Managen eines kompletten Lifecycles. Vorher war der unbestrittene Fokus auf Engineering-Themen und viel PLM war eigentlich nur PDM. Was wird es uns bringen, wenn wir unser Produkt wirklich von der Wiege bis zur Bahre oder besser noch – um beim Bild des Lebens zu bleiben – von der Zeugung bis zur abgeschlossenen Kompostierung begleiten? Wie wird sich PLM verändern, wenn wir Marketing-Aspekte an einem der Enden und Service & MRO-Aspekte am anderen Ende sowie alles dazwischen wirklich integrativ erfassen würden wollen? Wie schließen wir den Kreis und lassen frühe Phasen der Produktentstehung an Erkenntnissen späterer Phasen nutznießend teilhaben?

Zum Ende meines letzten – etwas ketzerisch geschriebenen – Blogbeitrages hatte ich die Frage in den Raum gestellt, warum wir PLM eigentlich nicht mal wirklich End2End machen. Ganz einfach: Weil es nicht ganz einfach ist.

Die Digitalisierung schreitet voran, kaum eine Industrie kann sich ihr verschließen. Neue Produktkategorien, neue Geschäftsmodelle, neue Vertriebswege und –strategien. Dynaxity ist King. Interessant ist, dass wir im PLM heute weiterhin im Wesentlichen Strategien und Werkzeuge sehen, die Struktur und Ordnung schaffen wollen. Das sind im Bild des Dynaxity-Modells alles Maßnahmen für die zweite, also dynamische Zone. Befragt man eine Suchmaschine nach dem Begriff Management, ist der erste Vorschlag die Definition „The process of dealing with or controlling things or people“. Struktur und Ordnung ist Kontrolle. Das „Management“ in PLM verkommt damit zu einem reinen Verwalten.

Realität ist aber, dass wir uns auf die Zukunft einstellend damit abfinden müssen, dass Digitalisierung turbulent (Dynaxity Zone 3) ist. Bei Turbulenzen muss man anpassungsfähig sein. Liebgewordenes über Bord werfen. „Dealing with“ scheint also der Knackpunkt zu sein. Leo schlägt als erste Übersetzung für „to manage“ vor: „etwas bewältigen“. Bewältigen werden wir aber in größeren Firmen sicher nichts allein. Teamarbeit ist gefragt.

PLM wird damit für mich zu einem Kommunikations- und Collaborations-Enabler. Nicht mehr und nicht weniger.

Wie finde ich in einem komplexen und sich stetig verändernden System immer wieder neu die Personen und Informationen, die ich zur Bewältigung meiner Aufgabe benötige? Und welche Informationen benötige ich überhaupt? Für mich fallen seit geraumer Zeit die Grenzen, die PLM früher auf Engineering-Aspekte eingeschränkt haben. Heute muss ich noch während der Entwicklung wissen, ob der Markt mein Produkt überhaupt noch nachfragt. Ich muss Wartbarkeit definieren, noch bevor ich weiß, ob ich das Produkt verkaufe oder als Service anbiete. Fundamentale Fragen eines Wertschöpfungsprozesses verändern sich, während der Prozess durchlaufen wird. Nichts kann mehr schön in Ruhe seriell abgearbeitet werden.

Deswegen muss ich in Zukunft alle Silos durchbrechen. Ich muss im Marketing verstehen, was Corporate Development macht. Denn nur so, kann ich einen Development Funnel sicherstellen, der mir die richtigen Produkte zur richtigen Zeit marktfertig bereitstellt. Ich muss aber auch mein eigenes Product Portfolio Management mit der Zulieferkette in der Fertigung und Produktion verbinden. Immerhin drehen sich die Uhren auch bei unseren Lieferanten immer schneller. Und Druck können wir da auch nicht mehr wie früher ausüben. Mit IIoT bekommen wir Zugriff auf Erkenntnisse aus dem Betrieb unserer Produkte, die von unschätzbarem Wert für R&D sind und noch vor 5 Jahren undenkbar waren. Gleichzeitig wird der Product Ideation Prozess immer schnelllebiger und braucht Erkenntnisse aus der Marktforschung. usw. usw. usw.

Bild von Gerd Altmann auf Pixabay

Plötzlich müsste eigentlich jeder mit jedem sprechen. Aber man kennt sich gar nicht persönlich. Und man wird sich auch nicht kennen, denn Dynamik und Wachstum schaffen auch selbst auf der HR-Front neue Hürden. Früher kannte man sich, arbeitete Jahre lang mit- und nebeneinander. Im heutigen Markt ist das Wachstum enorm, die Fluktuation größer, Platz nach oben für Beförderungen gegeben und Job-Hopping innerhalb von Konzernen ebenfalls in Mode. „Corporate Social Networks“ werden wichtig und basieren nicht mehr auf alten Seilschaften. Eins eint alle Beteiligten: Produktdaten.

PLM wird damit für mich zu einem Kommunikations- und Collaborations-Enabler. Nicht mehr und nicht weniger.

Aber was sind eigentlich Produktdaten? Die Frage bietet Raum, ein ganzes Buch darüber zu schreiben. Und eine ganze Reihe schlauer Leute hat das bereits getan. Doch auch diese Grenzen verschwimmen mit der Zeit. Ich arbeite bei einem Hersteller diskreter Produkte, die bei unseren Kunden in der Prozessindustrie eingesetzt werden. Ich denke heute darüber nach, wie ich die erzeugten Prozessdaten meiner Kunden „tesseliere“ und in unseren R&D und Portfolio Management Prozess zurückfädele. Vor 5 Jahren hipper Zukunftskram, heute aus meiner Sicht nötige Maßnahme, mich auf die nahe Zukunft vorzubereiten. Das schafft aber ganz neue Herausforderungen auf der Zusammenarbeitsebene. Infrastruktur ist da noch das trivialste Problem. Wir brauchen juristische Vereinbarungen, um überhaupt Zugriff auf Relevantes zu bekommen. Das geht meist nicht gut im Kunde/Lieferant-Verhältnis, besser schon wenn man als Partner auf Augenhöhe kooperiert. Aber auch bei Partnern macht man sich Gedanken über den Wert von Daten. Wir wollen lernen. Unsere Kunden wollen aber nicht, dass wir gleich ihr ganzes Geschäft mitlernen und dem nächsten Konkurrenten anbieten. Intellectual Property wird da plötzlich bis auf Attribut- und Transaktions-Ebene ein relevantes Thema, mit dem sich auch Legal & Compliance auseinandersetzt. Noch ein Player im Boot.

PLM wird damit für mich zu einem Kommunikations- und Collaborations-Enabler. Nicht mehr und nicht weniger.

Ich mag daher auch nicht mehr die traditionelle Abgrenzung ERP <-> PLM mit überschaubarem Overlap. PLM sollte mehr Strategie, ganzheitliches Konzept oder von mir aus auch Vision sein und nicht auf das reine Toolset reduziert werden. Am Toolset und dessen Implementierung halten sich eh zu viele Leute auf. Die eierlegende Wollmilchsau gibt es nicht und wird es auch entgegen der Beteuerung der einschlägigen Anbieter nicht geben. Außerdem wird es weniger denn je eine statische IT-Landschaft sein. IT-Individualismus auf die eigenen Bedürfnisse ist gefragt. Die lässt sich mit dem Wissen über Informationsflüsse aber besser kleinteilig bewerkstelligen, als mit monolithischen Single-Point-Of-Truth Strukturen. Ich bin schon seit jeher Freund von Single-Source-Of-Truth in Abgrenzung zu Single-Point. Pro Information eine Quelle ist entscheidend, um Redundanzen aus dem System zu nehmen, manuelle Prozesse zu reduzieren und Fehleranfälligkeit in den Griff zu bekommen. In wie vielen Systemen die Information eines einzelnen Ursprungs konsolidiert und konsumiert werden hat für mich keine besondere Relevanz. Für die Endabnehmer aber schon. Die mögen es, in Ihnen vertrauten Systemen zu arbeiten. Alles ablösen und die PLM/ERP Rundum-Sorglos-Lösung bereitstellen wird massive Change-Management-Schockwellen auslösen. Minimalinvasiv ist das Stichwort. Kleinteilige, individuelle Lösungen, im Zweifel im Eigenbau und gerne proprietär – denn wo steckt Intellectual Property nicht in Zukunft, wenn nicht im Wissen um die sinnvolle Bearbeitung und Verwendung der eigenen Daten. Und ganz praktisch: Der Ansatz ist auch noch super kompatibel mit einem der vielen anderen Buzzwords der Digitalisierung: Agile! Auch bei Agile geht’s im Übrigen um Kommunikation und Collaboration.

PLM wird damit für mich zu einem Kommunikations- und Collaborations-Enabler. Nicht mehr und nicht weniger. Das kann man gar nicht oft genug wiederholen!