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!

Grad noch Digital Twin, jetzt Digital Thread – Warum wir am Ende doch nur PLM machen

 

Gerade eben saß er noch auf der Blogcouch und hat ein Interview gegeben, jetzt teilt er sein Wissen und seine Erfahrungen auch in einem Gastbeitrag. Ich freue mich sehr darüber, Markus Ripping, global verantwortlich für das PLM bei Sartorius, als Gastautor für den PLM-Blog gewonnen zu haben. Aber jetzt genug der einleitenden Worte und viel Freude beim Lesen seines Artikels.

Insbesondere, weil PLM schwer zu erklären ist und sich noch schwerer im Innenverhältnis von Industrie-Betrieben wirtschaftlich verkaufen lässt, wird in der Branche in den vergaIst der Digital Thread das neue PLM?ngenen Jahren in der Hoffnung auf Aufmerksamkeit bei Entscheidern eine Buzzword-Sau nach der anderen durchs Dorf getrieben. An den wesentlichen Schwerpunkten der PLM-Arbeit und an der Wichtigkeit, insbesondere in Hinblick auf die für viele Industrien bitter nötige Digitalisierung, hat sich aber nichts geändert. Buzzwords schaffen Begehren auf der C-Ebene, welche aktuell bei der Trägheit und Change-Aversion bestehender Organisationen zum Scheitern verurteilt sind. PLM ist schon schwer genug. Wir sollten es nicht noch versuchen, sexy zu machen.

In den Jahren, in denen ich mich im PLM-Umfeld bewegt habe war der Begriff „Product Lifecycle Management“ nie stabil. Über die Jahre sind verschiedene Themenkomplexe hinein- und wieder herausinterpretiert worden. Aber der Terminus PLM war immer da. In den letzten Jahren hat sich das geändert. Zu meinem großen Bedauern.

Früher war es der nächste logische Schritt auf dem steinigen Weg eines professionalisierten Produktentstehungsprozesses. Man nannte es PLM, auch wenn man eigentlich noch PDM machte. Das war in einer Zeit, als es auch schon schwierig war, PLM zu verkaufen. Denn es war schon immer schwierig, PLM zu verkaufen. Ich komme aus der Beratung, aber ich meine nicht PLM-Beratung. Ich meine den Buy-In des Industrie-C-Level.

Warum wir uns das alles überhaupt antun? „PLM implementieren ist leichter, als es zu verkaufen“. Wir kennen alle die Sprüche. Man hat sich abgemüht, Gelder zu bekommen und hat komplexeste Systemlandschaften gebaut, alles basierend auf anfangs ziemlich dünnen Business Cases und mit optimistischen ROIs. Warum? Weil PLM Grundlagen schafft. Weil PLM vieles besser macht, aber fast nichts davon direkt. Im PLM-Umfeld gibt es eine Häufung von Berufs-Optimisten. Leute, die die Probleme von heute schon vorgestern gesehen haben. Und die versucht haben, Weichen zu stellen für eine Zukunft, die sie selbst noch nicht verstanden. Man kannte zwar nicht den Weg, aber zumindest hatte man eine Ahnung vom Ziel.

Wohin geht PLM?Heute kennen wir die Ziele. Die „hippen“ High-Tech-Unternehmen machen uns vor, wie man agil wird und durch Agilität weiterkommt. Wie man nicht mehr nur Produkte besser macht, sondern gleich komplett neue Business-Modelle schafft – am besten gleich ganz ohne lästige physische Produkte. Everything as a Service. Das schafft Begehrlichkeiten. Insbesondere bei den hochrangigen Entscheidern. Begehrlichkeiten, die PLM zwar nicht alleine befriedigen kann, für dessen Befriedigung in vielen Industrien PLM aber einer der Schlüssel-Enabler sein kann.

Warum geht also PLM nicht ab wie ‘ne Rakete? Weil Entscheider PLM seit x Jahren kennen! „Wie kann etwas, das wir vor 15 Jahren schon versucht haben uns jetzt plötzlich in die goldene Zukunft bringen? Geht doch nicht!“ Eine genauso verständliche wie falsche Argumentation. Unsere Reaktion als PLM-Community? Anstatt PLM heute richtig zu machen mit den Mitteln, die uns 2018 frei zur Verfügung stellt und nicht mehr hilflos zu frickeln, wie es vor 15 Jahren zwangsweise nötig war, fallen wir auf die Argumentation herein und geben dem Kind einen neuen Namen. Wir nennen das ganze nicht mehr Produkt-Lifecycle-Management.  Neue Namen gibt es genug. Neue hehre Ziele ebenso.

PLM war zu abstrakt. Unter einem Digital Twin kann sich jeder etwas vorstellen – glaubt jeder, sich etwas vorstellen zu können. Aber für viele aktuelle Firmen ist ein (vollständiger) digitaler Zwilling heute genauso unerreichbar wie (noch) unnütz.

Genauso unstrukturiertes Datensammeln und -kippen in einen Data Lake. „Heute anfangen, keine Daten mehr verloren gehen lassen!“. Egal! Was ich heute im Zeitraum eines Jahres sammeln kann, kann ich in 5 Jahren in wenigen Tagen, vielleicht sogar Stunden sammeln.

Oder Künstliche Intelligenz, die heute noch weit, weit davon entfernt ist, intelligent zu sein. Man googele den Unterschied zwischen Korrelation und Kausalität.

Model Based System Engineering? AR/VR? Und nun Digital Thread? Aus Fäden macht meine Schwiegermutter warme Socken. Die sind toll, helfen aber der Industrie nicht weiter. Meiner zumindest nicht. Und sexy sind sie auch nicht.

Früher war jedes Ziel ein hehres Ziel. Heute bringen die Schritte auf dem Weg zu den Zielen die Organisation weiter. Nicht unbedingt das Ziel selbst. Dabei stelle ich immer wieder fest, dass Buzzwords eine magische Eigenschaft mit sich bringen. Sie werden nie hinterfragt. „Brauchen wir das überhaupt? Was bringt es uns? Welche heute unmögliche Wertschöpfung erreichen wir?“. Selbst „Was kost‘ der Spaß?“. Solche Fragen stellen sich bei den Buzzwords nicht. Aber für mich sind die Buzzwords von heute die Zielgerade eines Marathon. Wo stehen die Organisationen heute? Manche sind schon losgelaufen. Aber andere sitzen noch auf der Couch, shoppen Laufshirts bei Amazon und träumen vom Training – in dem Irrglauben, es würde schon nicht anstrengend sein.

PLM ist antrengend

Aber es wird anstrengend! In der Welt des Product Lifecycle Managements ist anstrengend gleich komplex. Oft genug sogar kompliziert -> komplex -> chaotisch! Da geht auch gern mal was schief. Bei Erfolg sind die Gewinner oft die anderen. Die Nutznießer der Systeme. Bei denen wurde ein abstrakter Case nach einer Zeit des Einschleifens plötzlich selbstverständliches Handwerkszeug. Ohne leben: undenkbar. Verlierer durfte man im PLM-Umfeld immer gern alleine sein. Deswegen jetzt ausweichen und zu weit in die Zukunft blicken und vom Thema ablenken zählt nicht. Dazu ist der Weg auch heute noch immer zu steinig. Und auch heute können wir genug Themen aufgreifen, die uns und unsere Organisationen jetzt weiterbringt. Nicht erst morgen. Weiterhin abstrakt. Aber doch auch konkreter, als das vor Jahren möglich war. Mit modernen Werkzeugen. Und vielleicht endlich mal wirklich End2End und nicht nur mit einem starken Fokus auf die Produktentwicklung. Dafür aber als das, was es ist: PLM.

Es gibt das Sprichwort „den Wald vor lauter Bäumen nicht sehen“. Wir sehen den Wald! Wir sollten nur vor lauter Vorfreude auf den Wald das Bäume pflanzen nicht vergessen. Die fehlen oft genug noch oder sind zwar da, aber schon morsch!

Der PLM-Talk – heute mit Markus Ripping

 

Nachdem in der letzten Zeit die technischen Artikel wieder überwiegt haben, ist es jetzt mal wieder Zeit für eine weitere Episode des PLM Talks. Ich habe weder Kosten noch Mühe gescheut, um einen weiteren hochkarätigen Gesprächspartner zu gewinnen. Das heutige Interview führe ich mit Markus Ripping, beim Biotech- und Laborzulieferer Sartorius global verantwortlich für das Thema PLM. Ich wünsche dem geneigten Besucher dieses Blogs viel Spaß beim Lesen dieses Interviews.

Herzlich Willkommen auf meiner virtuellen Blogcouch, Herr Ripping. Machen Sie es sich bitte recht bequem. Viele Leser dieses Artikels werden sie aus ihren zahlreichen PLM-Projekten in mittlerweile über 15 Jahren kennen. Können Sie trotzdem bitte ein paar Worte zu ihrer Person und ihren bisherigen beruflichen Stationen verlieren?

PLM Experte Markus RippingMarkus Ripping: Gerne. Zu meiner Person: Baujahr 77, verheiratet, ein Sohn. Gelernter Dipl-Ing. Verkehrswesen, Luft- und Raumfahrt. Ich hatte am Anfang meiner Karriere die Chance, in einen militärisch beeinflussten Industriebetrieb zu schnuppern, was bei mir praktisch unmittelbar den Reflex ausgelöst hat, in ein Umfeld höherer Dynamik zugehen und erstmal nicht in der Industrie zu arbeiten. Ich hab mich dann rund 15 Jahre in der technologie-lastigen Unternehmensberatung rumgetrieben. In der Zeit habe ich das Spektrum von kleiner, lokaler Nischen-Beratung bis zum internationalen „Monster“ für mich ausprobiert.

PLM und Systems Engineering wird bei Raumfahrern mit der Muttermilch aufgesogen. Eine Konzentration auf das Thema war daher naheliegend. Anfangs waren das für mich Visualisierungs– und Kollaborationsthemen eher konzeptioneller Natur. Immer mit einem Fokus, das Business zu verstehen und Mediator Richtung IT zu sein. Aus den Extended Enterprise Fragestellungen ist dann irgendwann der Themenkomplex Business Process Outsourcing im PLM-Umfeld entstanden. Da ging es deutlich mehr um operatives Tagesgeschäft und wie man Konstruktions- und Qualitätssicherungsmaßnahmen im Design-Prozess sinnvoll nach offshore verlagert. Die letzten Jahre in der Beratung waren geprägt von eher strategischer Beratung und einem Fokus auf die Wechselwirkungen von PLM in Merger & Acquisition bzw. Divestment Situationen.

Als mein Sohn zur Schule kam hab ich mein Leben aus dem Koffer an den Nagel gehängt und bin in die Industrie und gleichzeitig meine alte Heimat gewechselt. Hier habe ich die Chance – dank dynamischen Wachstums in der Biotech-Branche – eine Reise in die PLM-Zukunft zu begleiten und dem Unternehmen mit meinem kleinen Beitrag zu helfen, den Sprung vom Familienunternehmen in die Global-Enterprise-Welt zu schaffen.

 

In ihren beruflichen Stationen in verschiedenen Unternehmensberatungen konnten Sie einen vielfältigen Einblick in das Thema PLM gewinnen. Was unterscheidet aus ihrer persönlichen Sicht heraus ein PLM Projekt im Jahr 2018 von einem PLM Projekt im Jahr 2008. Oder anders gefragt, was ist der Erkenntnisgewinn der letzten 10 Jahre PLM?

Da gibt es vielfältige Antwortmöglichkeiten. „Standards“ wäre eine. Vor 10 Jahren waren in PLM-Umgebungen vieles noch selbstgebaut. Aus der Not heraus geboren. Heute haben wir akzeptiert, dass wir keine monolithischen Systeme bauen müssen, unter anderem auch dank offener Standards und einfach erreich- und implementierbarer Interfaces. Themen wie cpo sind wichtig und intensiv voranzutreiben.

Eine andere Perspektive ist die Anwendung von PLM im Unternehmen. Vor 10 Jahren waren PLM-Projekte ehrlicherweise oft noch PDM-Projekte. PLM war die Spielwiese der Produktentwicklung. Das hat sich geändert. Die ersten waren die Manufacturing-Leute, die die Mehrwerte einer harmonisierten Landschaft neben ERP verstanden haben. Heute unterhalten wir uns mit Marketing und Service und nähern uns einer echten End2End-Abdeckung. Damit werden wir endlich dem „Lifecycle“ in PLM gerechter.

 

Wenn Sie heute auf ihre erste berufliche Station zurückblicken und heute in ihrem Team Nachwuchskräfte sehen, was können sie jungen Ingenieure und Ingenieurinnen raten, die sich für dieses Thema interessieren. Wir sind beide aus der Generation, die noch die klassischen Diplomstudiengänge absolviert haben. Sind die jungen Kollegen und Kolleginnen heute besser oder „nur“ anders vorbereitet auf die Herausforderungen des PLMigen Berufslebens?

Ich hab mich damals eigentlich schon nicht schlecht vorbereitet gefühlt. Aber in der Tat hat sich seitdem vieles verändert. Mir hat man noch Wasserfall beigebracht als wäre es die einzige Möglichkeit, Software-Projekte abzuwickeln. Mein Ratschlag an junge Leute: Über den Tellerrand schauen. Der Ingenieur darf heute kein reiner Technik-Experte sein.

In meinen Teams gibt es immer auch Spezialisten u.a. für Change Management. Man muss die Leute mit ihren Ängsten und Sorgen abholen. Das haben wir früher vernachlässigt. Eine weitere Erkenntnis: Gute Dinge tun reicht nicht. Man muss sie auch verkaufen können. Daher muss heute mehr Wert auch auf das interne Marketing von PLM-Aktivitäten gelegt werden. Das bedarf eines ganz anderen Skillsets als an den technischen Lösungen zu arbeiten. Diese Interdisziplinarität ist einer der Schlüssel zum Erfolg. Daher helfen heute eher Generalisten als Spezialisten.

 

Sie blicken auf eine langjährige Erfahrung als PLM-Experte und Berater zurück. Ich möchte zuerst nach den positiven Dingen fragen: Was hat sich Ihrer Meinung nach verbessert in den PLM Projekten über diese Zeit?

Heute verfügbare Technologie und die Fähigkeiten, Komplexität zu managen machen aktuelle PLM-Projekte mit höherer Wahrscheinlichkeit erfolgreich, als das am Anfang meiner Karriere der Fall war. Da ist deutlich häufiger auch Geld in den Sand gesetzt worden. Außerdem hat sich die Erkenntnis deutlich breiter durchgesetzt, dass PLM nicht nur ein System ist, sondern eine Strategie des Unternehmens sein muss und viel mehr von Prozessen als von IT-Tools lebt.

 

Und wo stehen wir immer noch vor den gleichen Problemen wie vor 15 Jahren?

PLM verkauft sich auf der Management-Ebene weiterhin nicht gut. Das Thema ist abstrakt, für Manager ohne technischen Hintergrund schwer greifbar und es fällt uns auch heute noch schwer, gute Business Cases aufzustellen. Die technologische Komponente ist eher ein Enabler für Andere als eine sich selbst tragende Geschichte. Wenn Sie sich ein optimales PLM Projekten backen könnten, welche Zutaten sind unabdingbar für den Erfolg des Projektes? Was sind die Randbedingungen und Voraussetzungen, ohne die kein PLM Projekt zu den gewünschten Ergebnissen führt?

 

  1. Management-Buy-In. Wenn es kein Commitment der Entscheider gibt, es wirklich durchzuziehen, braucht man gar nicht erst anfangen.
  2. Begehrlichkeit wecken. Die Menschen auf der Arbeitsebene müssen die Lösungen wollen. Ein klassisches Change Management Thema.
  3. Descoping. Die eierlegende Wollmilchsau braucht niemand und erreicht auch niemand. Iterativ oder besser noch agil vorgehen und eine kleine Baustelle nach der anderen integrieren. Dabei das große Ganze und die Zukunftsvision nicht vergessen.

 

Blicken wir einmal auch ein wenig in der Zukunft und versetzen uns mal in das Jahr 2028. Was denken Sie, was wird dann aus diesem PLM geworden sein. Ist das dann ein gelöstes Problem, das wenig Überraschungen mehr bietet? Oder welche Herausforderungen werden wir dann lösen müssen?

Sicher wird PLM kein final gelöstes Problem sein. In den letzten Jahren sind immer mal wieder Dinge in PLM rein- und wieder rausdefiniert worden. Das wird auch in Zukunft so gehen. Insofern ist das „Problem“ PLM nicht statisch beschrieben. Eine große Herausforderung, die ich sehe ist das Thema Definition von Produktdaten.

Heute machen wir PLM oft im Kontext diskreter Fertigung. Wie sieht das ganze aus, wenn das Produkt nur noch eine Dienstleistung ist? Wie gehen wir mit immer mehr Prozessdaten um? Was machen wir mit den Daten eines Asset Network? Und weitere neue Business-Modelle stehen in den Startlöchern, die wir heute nicht verstehen. Das iPhone ist 10 Jahre alt. Die Veränderung der letzten 10 Jahre hätte doch so kaum jemand vorhergesehen.

Abseits inhaltlicher Fragestellungen sehe ich einen gefährlichen Trend, dem Kind neue Namen umzuhängen, um PLM sexy zu machen. Das klappt meist leider nicht, weil es nur nicht erfüllbare Erwartungshaltungen schürt. Es wird neue Herausforderungen geben. Wir werden Sie mit PLM lösen. Ob wir es dann noch PLM nennen – ich hoffe schon!

 

Eine letzte Frage, die den Blick in Richtung der Softwareunterstützung richtet. Was wünschen Sie sich konkret von den PLM-Systemhäusern und auch den Dienstleistern? Wo können und müssen diese ihren Beitrag leisten, PLM zukunftsfähig zu machen?

Wie ich oben schon erwähnte: Offene Standards. Kaum jemand kauft sich eine fertige Suite und ersetzt in einem Schlag seine ganze Produktentstehungslandschaft. Darüber hinaus wünsche ich mir eine andere Dimension der Modularität. Ich polarisiere etwas: Heutige Systeme wirken wie funktionsüberfrachtete Monster. Man steckt mehr Geld hinein, vorhandene Funktionalität vor experimentierfreudigen Anwendern zu verstecken, als nützliche Funktionen bereitzustellen. Ich möchte nicht One-Size-Fits-All. Ich will einen Maßanzug. Aber bitte ohne stundenlang beim Schneider stehen zu müssen.

Vielen Dank für dieses Gespräch und weiterhin viel Erfolg bei Ihren Projekten.

Es wird menschlich – die Organisation rund um ihr PLM System

Der geneigte Leser mag sich noch an meinen Artikel über die infrastrukturellen Voraussetzungen eines erfolgreichen PLM-Projekts erinnern. Aber leider ist es mit der reinen IT Infrastruktur nicht getan und deshalb wende ich mich heute dem Aspekt der Organisation zu. Konkret geht es mir genau um den Übergang von der Implementierungsphase in den produktiven Betrieb des PLM-Systems und das weniger aus technischer Sicht, sondern aus dem Blickwinkel der Unternehmensorganisation und den damit zusammenhängenden menschlichen Faktoren. Wie bekommen Sie als Eltern des PLM-Systems diesen gerade der Pubertät entwachsenen Sprössling gut und sicher in den Ernst des Lebens, nämlich in den produktiven Betrieb? 

Als Erstes möchte ich mit einem noch oft gehörtem Trugschluss einer PLM-Einführung ausräumen. Vergessen Sie den Gedanken, dass so ein PLM-System jemals “fertig” ist. Ihre Produkte müssen sich ständig neuen Markterfordernissen anpassen oder sie setzen neue Trends und Innovationen auf Ihrem Markt.

PLM Innovation

Des Weiteren ziehen gerade in der Produktentwicklung immer mehr agile Methoden ein. Dieses Internet, von dem man in den letzten Monaten so viel hört, bringt vollkommen neue Geschäftskonzepte hervor und lässt komplette traditionelle Produkte verschwinden.Das zwingt jeden Marktteilnehmer zur Anpassung.

Vor diesem Hintergrund kann und darf ein PLM-System nicht statisch sein. Die Anpassung dieses System zur Unterstützung Ihrer Produktinnovation ist nicht die Ausnahme, es ist der Regelfall. Daher muss sich auch jeder PLM-Systemlieferant daran messen lassen, wie einfach und durchgängig Änderungen an seinem System vorgenommen werden können. Für mich als Verantwortlicher eines PLM-Systembenchmarks wäre diese Adaptionsfähigkeit das allerwichtigste Kriterium. Den Gedanken an ausreichende oder sogar vollständige Out-of-the-box Funktionalität legen sie besser beiseite. Wenn alles OOTB funktionieren soll, was was unterscheidet sie dann von Ihrer Konkurrenz? Des Weiteren kann in ein paar Jahren die OOTB Funktion von heute vom Stand der Technik überholt worden sein. Oder wer benutzt heute noch ein Nokia 3210 oder bringt noch analoge Filme zu entwickeln? Und wer weiß, was diese Digitalisierung in den nächsten Jahren noch an neuen Konzepten und Innovationen hervorbringt, die mit Sicherheit Einfluss auf ihr PLM-System haben werden. 

Was heißt das jetzt aber für Ihre Unternehmensorganisation? Die Schlussfolgerung liegt auf der Hand: Sie benötigen Mitarbeiterinnen und Mitarbeiter, die mit dieser Herausforderung der ständigen Änderung umgehen können. Und sie müssen sich natürlich Gedanken über Prozesse und Methoden machen, die dies unterstützen.

Das ist einfacher gesagt als getan. Im Implementierungsprojekt hat ihr PLM Systemhaus diese Aufgaben übernommen. Er hat Ihre Anforderungen aufgenommen, das PLM-System ihrer Wahl dahingehend angepasst, die Ergebnisse in regelmäßigen Sprints vorgestellt, Feedback eingesammelt und so das erste produktive Release des PLM-System erstellt. Für diese Implementierungspartner ist das tägliches Brot, sie haben entsprechende Prozesse und Infrastruktur am Start und deren Mitarbeiter sind darauf geschult und trainiert. Genau aus diesem Grund haben Sie ja auch diese externe Unterstützung eingekauft. 

Basierend auf Ihren guten oder nicht so guten Erfahrungen während der Implementierungsphase können sie dann eine erste Entscheidung treffen: Wollen sie alle weitere Änderungen am produktiven PLM-System von Ihrem Implementierungspartner durchführen lassen? Der Vorteil dieser Lösung liegt auf der Hand: Es ist die Fortführung von mittlerweile eingespielten Prozessen und Verantwortlichkeiten und sollte ein beherrschbares Risiko beinhalten.

Der Nachteil ist aber auch klar: Die schnelle Verfügbarkeit der Consultants ist nicht garantiert, sie machen sich ein Stück weit abhängig von ihm und die Kostenseite muss natürlich auch betrachtet werden. 

Alternativ können Sie auch darüber nachdenken, diese Aufgabe zumindest teilweise intern zu lösen. Die großen neuen Module vergeben sie weiterhin an Ihren Partner, aber die alltägliche Maintenance lösen sie mit internen Ressourcen. Oder sie befähigen ihr Team, zukünftig alle Anpassungen ihres PLM-Systems vorzunehmen.

PLM Team

Beides bedingt, dass sie bereits während der Implementierungsphase Gedanken über die Organisation, die Ressourcen und die Methoden und  Prozesse machen müssen. Es gibt natürlich auch Industriestandards wie ITIL, die sie dabei unterstützen können, gute Lösungen zu finden. 

Aber eigentlich reicht auch der gesunde Menschenverstand, um über die Frage nachzudenken, was nach der Produktivsetzung passieren muss. Prinzipiell müssen sie die Methoden, Prozesse und die Infrastruktur Ihres Implementierungspartners auf sich selbst adaptieren.

Zur Infrastruktur hatte ich mich bereits in einem anderen Blogartikel ausgelassen. Aber das ist nur eine Seite der Medaille, die andere betrifft ihre Mitarbeiter und Unternehmensorganisation. Ich möchte hier nur einige Aspekte ansprechen:

Support

Auch wenn ihre Anwender intensiv trainiert und geschult werden, trotzdem wird es im laufenden Betrieb Fragen geben. Wer übernimmt diesen first und second level Support bei Ihnen? Sollen das Ihre Key User aus dem Implementierungsprojekt sein oder richten sie eine dezidierte Supportmannschaft ein?

Instandhaltung

Wer kümmert sich um die Kommunikation von Issues, die an den Hersteller des PLM-Systems weitergeleitet werden müssen? Und wer verfolgt das weiter? Daraus ergeben sich auch Fragen, wie die Änderungen (Hotfixes, Patches) in ihr Produktivsystem gelangen sollen. Wer übernimmt Verantwortung für das Aufsetzen und die Wartung Ihrer Integrationsumgebung und ihres Testsystems.

Tests und Qualitätssicherung

Wer kümmert sich um die Organisation von Testaktivitäten, ohne die Änderungen an einem Produktivsystem auf keinen Fall vorgenommen werden dürfen? Wer übernimmt Verantwortung für die interne Freigabe von neuen Releases?

Anpassungen und tägliche Wartung

Und dann gibt es noch diese ganz normalen Anpassungen, die ständig anfallen werden. Wer übernimmt die notwendigen Pflegearbeiten am PLM-System? Das geht von der Anlage von Benutzeraccounts und der Vergabe von Berechtigungen über einfache Änderungen an den Businessobjekten (z.B. neue Klassifikationen ihrer Dokumente) bis hin zu komplexen Änderungen an den implementierten Geschäftslogiken. 

Diese Liste von Fragen und Aspekte erhebt keinen Anspruch auf Vollständigkeit. Dafür ist dieses Thema auch zu individuell und zu unternehmensspezifisch.

Eine gute und bewährte Strategie, die richtigen Fragen zu stellen und auch passende Antworten darauf zu finden, ist es, die zukünftige Supportorganisation frühzeitig in das Implementierungsprojekt einzubinden. Denken sie daran, es ist IHR PLM-System und nicht das Ihres PLM Systemhauses. Lernen sie aus den Erfahrungen ihrer Implementierungsphase und profitieren sie vom Wissen, dass Ihr Partner mit Ihnen dabei teilt. Nicht jedes Rad muss neu erfunden werden.

Vor einigen Tagen hat mir Bernd Ebert, der hier auch schon auf der PLM Couch saß, einen weiteren vielversprechenden Ansatz zur Lösung dieses Problems vorgestellt.

Es geht dabei um DevOps, einen Prozessverbesserungsansatz aus dem Bereich Softwarentwicklung und Systemadministration. Das ist definitiv einen Blick wert – aber das soll in einem anderen Blogartikel passieren.

 

Ein PLM-Reisebericht: The curse of isolated data islands

Reisen bedeuten oft das Verlassen ausgetretener Pfade und dieser Artikel tut das gleich in zweifacher Hinsicht. Zum einen gibt es eine Premiere: Ich freue mich sehr, dass Thomas Skogen, Director Product Management bei der Minerva Group AS, als erster Gastautor meinen Blog bereichtert. Zum anderen begibt sich Thomas in seinem Artikel auf eine Reise über die einsamen Inseln in der PLM-Welt. Ich wünsche Ihnen viel Spaß beim Lesen.

The curse of isolated data islands

The other PLM islandsday I was enjoying a very nice ocean view. I was standing on the top of a hill and I could spot a few islands on the horizon. As I was trying to single out that island I was going to visit later that day, the whole experience made me think of the concept of isolated data islands.

What is a data island?

  • When product quality data is stored in a spreadsheet on a laptop with no connectivity to the rest of the department.
  • When customer data is stored in the sales database and the rest of the organization cannot access the customer data.

Isolated data islands are like those islands I could spot on the horizon because the distances in between those islands are like the disconnect between various databases. And while the view from above is nice and scenic, things start to become complicated once you need access to one of these islands because:

  • Islands are difficult to get to as access is limited or rigidly defined.
  • It also costs a lot more to “get to” the island.
  • Once you get to the island, you find out that you don’t speak the same language (file types are different and/or difficult to work with).
  • You also have to learn how to live (operate) in the island’s environment that will most likely feel very foreign, perhaps even intimidating.

Isolated data islands exist in all organizations

PLM Chaos

This scenario essentially reflects the situation that exists in companies of all sizes across the globe. Companies have been using a wide variety of point solution applications and tools to support daily operational tasks such as change management, quality, tooling and requirements management etc. By following this pattern, companies develop isolated data islands which are not shared nor maintained very well across the enterprise.

The curse of isolated data islands

The are several issues here.

  • If data is not easily available to those who need it within the organization, they will waste an unnecessary amount of time searching for that data.
  • Without a clear central data source, the risk of finding the incorrect version of that data increases dramatically.

The end result of data islands is that staff as well as managers makes decisions based on incorrect data.

Departments turn to the Excel solution

Used by many, the Excel solution reflects the cheapest and most common solution utilized across companies. This “powerful” tool provides the basic business functionality of being readily available, holding data, and providing the option to write simple code. As a result, it is used to implement  “business applications” that is comprised of a combination of data governed by “business rules”.

The problem with the Excel solution

In time, the basic functionality of Excel will no longer suffice, due to the overwhelming size and complexity of the file. What is more important. There is no traceability, no history and no collaboration tools integrated in Excel.But it doesn’t stop there. Because multiple departments exist within a company, a number of database products exist, as well. Sometimes, these products have simple functionalities and every so often, they even hold the same data across departments. This creates islands of data with duplicate data within a company. It leaves the question, where is the correct master file? When each department or division possesses its own Excel, without any cross-departmental communication, data is shared without a centralized database to keep it normalized. While new versions of Excel may be able to hold near 65,000 records, the bigger the file, the slower the access speed to data, which is delayed even further when complex codes are utilized.

How a proper data management system can help

A data management system  can provide the configuration simplicity of an Excel solution with a centralized location for data that is authorized and scalable. It covers all drawbacks that generally accompany customized applications. In addition, it offers the security of a backup feature and a notification mechanism that links up to the enterprise.