Der PLM-Talk – heute mit Markus Ripping

Veröffentlicht am , aktualisiert am von Christoph

 

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.

Geschnitten oder am Stück – Wie fange ich am besten an mit diesem PLM?

Veröffentlicht am , aktualisiert am von Christoph

„That’s one small step for man, one giant leap for mankind.“ Mit Neil Armstrongs berühmten Worten bei Betreten des Mondes möchte ich meinen heutigen Blogartikel beginnen. Wenn man vor einer Einführung oder vor dem Systemwechsel eines PLM-Systems steht, ist der erste Schritt auch sehr entscheidend. Jetzt vielleicht nicht für die gesamte Menschheit, aber doch für das jeweilige Unternehmen.

Ein PLM-System dient nunmal der Abbildung bzw. der Unterstützung aller produktrelevanten Prozesse von der ersten Idee bis zum Ende des Produktlebenszyklus. Klassisch werden dabei Prozesse aus den Unternehmensbereichen wie dem Vertrieb, Marketing, Produktmanagement, Konstruktion und Entwicklung, Fertigung, Qualitätsmanagement, Zulieferintegration und dem Service abgebildet bzw. berücksichtigt. Ablaufdiagramme und Beschreibungen aus diesen Bereichen und damit Anforderungen an ein PLM-System werden dann in ersten Dokumenten für die PLM-Systemauswahl aufgeschrieben. Ein oder zwei Bereiche dominieren dabei und setzen die wichtigsten Prioritäten – das sind dann auch diejenigen Anwender, die sich den größten Nutzen vom PLM-System versprechen. Und auf deren Kostenstelle werden dann auch die Aufwände dafür gebucht. Und wie sagt der Volksmund so schön: Wer die Kapelle bezahlt, bestimmt auch die Musik. Das führt dann im Benchmark verschiedener PLM-Systeme als auch in der Scopedefinition der ersten Einführungsphase zu einer Fokussierung auf die Anforderungen aus diesen Abteilungen.

Auch in meiner beruflichen Vergangenheit gab es viele Projekte, die aus dem Engineering und der Produktentwicklung getrieben wurden. Das sind ganz unbestritten äußerst wichtige Stakeholder. Die Anforderungen aus dem Vertrieb, QM und anderen Bereichen sollten dann in weiteren Projektphasen implementiert werden.

Dieser Fokus auf einen dominierenden Bereich und das Fokussieren auf dessen Anforderungen ist aber nicht ohne Risiko. Es führt zu einem nahezu perfekt ausgewählten und angepasstem PLM-System für diese Abteilung. Aber es ist nicht zwingend die beste Lösung, das beste System für den gesamtem PLM-Scope. Dafür sind die Anforderungen aus anderen Bereichen der PLM-Wertschöpfungskette doch zu unterschiedlich. Um es etwas konkreter darzustellen: Der Produktentwicklungsfokus in der PLM-Systemauswahl führt zur Auswahl eines Systems mit Stärken im Produktdatenmanagement und in der CAD-Integration. Schwierig wird es meist dann, wenn dieses System dann auch das Qualitätsmanagement oder den Service unterstützen soll. Ebenso kann es dazu führen, dass die Komplexität des Lizenzmanagements als auch die Aufwände bei Systemupgrades des PLM-Systems unterschätzt werden. PLM ist kein Tool für Spezialisten, sondern das Rückgrat eines Industrieunternehmens.
Aber wie kann man jetzt dieses Problem vermeiden? In der Softwareentwicklung gibt es seit Langem den Ansatz eines “Minimum-Viable-Produkt MVP“. Ich zitiere hier der Einfachheit halber aus der Wikipedia: „Ein Minimum Viable Product (MVP), wörtlich ein “minimal überlebensfähiges Produkt”, ist die erste minimal funktionsfähige Iteration eines Produkts, das entwickelt werden muss, um mit minimalem Aufwand den Kundenbedarf zu decken und Feedback zu gewährleisten.“ Dieser Ansatz kommt aus dem Konzept des Lean-Startups und aus meiner Erfahrung heraus kann es hervorragend in die PLM-Systemauswahl übertragen werden. Das PLM-MVP enthält die minimalsten Anforderungen und vermeidet so das oben geschilderte Problem einer zu starken Dominanz eines Bereiches. Aber wie erstellt bzw. definiert man ein PLM-MVP? Folgende Hinweise kann ich dabei aus meiner Praxis beisteuern:

Anforderungen MVP PLMDas richtige Produkt bzw. Projekt auswählen:

Für ein minimal-überlebensfähiges PLM benötigt man ein passendes Produkt und das dazu passende Entwicklungsprojekt. Stellen Sie sich die Frage nach einem ganz typischen Vertreter, nach Ihrem „Brot-und-Butter“ Produkt. An diesem wird dann die Prozesskette ihrer Wertschöpfung durchlaufen und die Anforderungen an ihr PLM definiert. Die Arbeit an einem konkreten Beispiel erleichtert die Anforderungsanalyse immens, da die Stakeholder weniger Abstraktionsvermögen aufbringen müssen und sehr konkret beschreiben können, wo der Schuh drückt.

Mehr in die Breite gehen – ein PLM-MVP darf ruhig einen hohen BMI haben
Es werden die Anforderungen nicht an den Grenzen der dominierenden Abteilung geschnitten, sondern es wird bewusst in die (Prozess-)Breite gegangen. Die wichtigsten Anforderungen aus allen wertschöpfenden Bereichen werden betrachtet. Das sieht zuerst einmal nach deutlich mehr Anforderungen aus, aber ich komme gleich noch dazu, wie man diese dann wieder auf erträgliche und in einem PLM-Systembenchmark handhabbare Anzahl reduzieren kann. Wichtig ist nur, dass eben alle Bereiche gleichberechtigt berücksichtigt werden und die Fokussierung auf einen vermieden werden.

Ecken und Freistösse – Standardsituationen
Eine bewährte Möglichkeit zur Reduzierung von Anforderungen ist die Beschränkung auf den Standardablauf in Ihren Prozessen. Beschränken Sie sich dabei einzig auf den normalen Ablauf ohne die ganzen Ausnahmen und Sonderfälle, die natürlich im realen Leben vorkommen können. Es ist also nicht wichtig, in einem PLM-MVP jede dieser Ausnahmen und Abzweigungen zu berücksichtigen. Oder, wenn diese Abbildung dieser „Sonderlocken“ sehr wichtig ist, beschränken sie sich auf ein prägnantes Beispiel. Es ist nicht notwendig, bei jeder Prozessaktivität zu prüfen, ob das zukünftige PLM-System eine Delegation dieser Aufgabe ermöglicht oder ob Eskalationspfade implementiert werden können. Das gleiche gilt für die Abbildung von parallelen Pfaden oder das Ansprechen von Sub-Workflows. Das muss maximal einmal geprüft werden und nicht in allen Bereichen.

Die Liebe zu Details
Die Konzentration auf den Standardablauf hilft Ihnen auch, sich nicht in Details zu verlieren. In der Bestimmung der Anforderungen für eine Systemauswahl benötigen man einen gewissen Mut zur Lücke. Die Details werden dann im Rahmen der Implementierung noch genügend gewürdigt. Ich habe sehr gute Erfahrung mit Story Maps gemacht und konnte mit diesem Hilfsmittel die notwenige „Flughöhe“ beim Betrachten der Anforderungen einhalten. Zu viele Details erhöhen nicht nur die Anzahl der Anforderungen und somit den Aufwand für die Verwaltung, sondern schränken auch den Lösungsraum der PLM-Systemhersteller ein. Vielleicht hat ja der ein oder andere eine viel bessere Lösung für das Erfüllen einer groben Anforderung, als das die Details dann zulassen würden?

Prioritäten setzen
Anforderungsmanagement ist selten demokratisch und das gilt noch in besonderer Weise in einer Systemauswahl. Einige Anforderungen sind eben wichtiger als andere und diese gilt es herauszufinden. Zwei Aspekte können dabei helfen:

  • Wie groß ist der Einfluss dieser Anforderung auf den weiteren Prozessablauf? Was würde passieren, wenn man diese Anforderung nicht implementiert? Mit diesen Fragen können Sie die Kandidaten identifizieren, die für einen Bereich vielleicht sehr wichtig sind, aber dessen Einfluss auf den gesamten PLM-Kontext eher gering ist.
  • Wie ist der Einfluss dieser Anforderung auf den PLM Business Case? Die Antwort auf diese Frage findet man bei User Stories recht schnell. Falls es schwierig ist, den Teil nach „so that …“ oder „um …“ zu formulieren, dann ist das genau eine Anforderung mit einem zweifelhaften Einfluss auf den Business Case. Und damit eher keine Anforderung für die Top-Charts. Auch wenn man nicht mit User Stories arbeitet, kann die Frage nach dem Business-Impact auch bei Use Cases oder jeder anderen Form der Anforderungsdefinition gestellt werden.

Es gibt mit Sicherheit noch weitere hilfreiche Methoden, um zu geeigneten Anforderungen für eine Systemauswahl zu kommen. Mein Artikel erhebt gar keinen Anspruch auf Vollständigkeit. Wichtig war mir aber auf die Probleme der Dominanz eines Bereiches in der Systemauswahl hinzuweisen und mit dem MVP-Ansatz eine Lösung dafür zu beschreiben.

Es wird technisch – Der Betrieb ihres PLM-Ökosystems

Veröffentlicht am von Christoph

In meinem heutigen Blogartikel wird es wieder etwas technisch. Bei jeder PLM-Einführung muss man über die dafür benötigte IT-Infrastruktur nachdenken. Denn einfach das PLM-System installieren und dann in dieser produktiven Umgebung Änderungen vornehmen, ist eine ganz schlechte Idee und in regulierten Branchen wie der Medizintechnik auch gar nicht zulässig. Dieses Setup von verschiedenen Umgebungen wird nicht nur einmalig bei der initialen Einführung benötigt. Jeder PLM-Systemhersteller liefert in bestimmten Abständen neue Major Releases seiner Software und manchmal ist auch das Einspielen von Service Packs oder Hotfixes notwendig. Und dann gibt es natürlich noch die ganz normalen Änderungen aufgrund von Anwenderwünschen, die entweder von ihrem eigenen Implementierungsteam entwickelt werden oder die sie extern von einem Dienstleister erstellen lassen.

PLM ServerDaher lohnt sich bei einer Auswahl eines PLM-Systems ein kritischer Blick auf diese technischen und eher operativen Anwendungsfälle. Meine Erfahrung zeigt aber, dass darauf leider nicht genügend Augenmerk gelegt wird und viele von den Kosten für den Betrieb des PLM-Systems überrascht werden. Wie gesagt, ein PLM-System ist nicht „fertig“ und Änderungen an diesem System eine häufige Aufgabe. Und wenn sie einem agilen Projektmanagementansatz folgen, ist dieser Transfer und Wechsel zwischen den Umgebungen tägliches Brot.

Aber welche Bestandteile oder Umgebungen benötigt jetzt aber so eine PLM-Einführung?

Die Entwicklungsumgebung:

Wie der Name schon sagt, ist das die Umgebung, in der jeder Entwickler getrennt arbeitet und programmiert.  Dazu gehören natürlich auch erste Tests. Nachdem diese erfolgreich absolviert wurden, werden die Änderungen an Quellcode und Konfiguration des PLM-Systems in die Integrationsumgebung übertragen.

Die Integrationsumgebung:

In diese Umgebung werden alle Änderungen der einzelnen Entwickler integriert und können das erste Mal gegeneinander getestet werden. Da gerade in einem agilen Umfeld diese Integrationstest täglich passieren, lohnt ein Blick in Richtung einer Testautomatisierung. Gerade Berechtigungen in Abhängigkeit der DImensionen Rollen/Gruppenzugehörigkeit und Lifecyclestatus können aus meiner Erfahrung heraus sehr gut automatisiert getestet werden mit einem vertretbarem Aufwand für die Programmierung der Testcases. Eine weitere wichtige Überlegung ist auch, wann und wie der gemeinsame Stand der Integrationsumgebung in die einzelnen Entwicklungsumgebungen zurückgespielt wird. So wird dann sichergestellt, dass alle Entwickler gegen die identische Konfiguration programmieren.

Die Test- und Validierungsumgebung

Auch hier ist der Name Programm. Diese Umgebung dient dazu, dass zukünftige Anwender die Umsetzung ihrer Anforderungen testen. Falls Sie mit externen Dienstleistern zusammenarbeiten, kann diese Umgebung sich auch noch einmal in zwei Instanzen aufteilen. Zum eine die Testumgebung bei Ihrem Dienstleister als letzte Qualitätssicherungsinstanz vor der Übergabe einer neuen Konfiguration an den Kunden. Und auf der anderen Seite gibt es ihre Testumgebung für die Durchführung ihrer Anwendertest und in regulierten Industrien (z.B. Medizintechnik) für die Durchführung der Systemvalidierung.

Eine weitere besondere Form kann noch eine „simulierte Produktivumgebung“ sein. Hier ist nicht nur ein kleiner Auszug ihrer Daten (Dokumente, CAD-Modelle. Zeichnungen,…) vorhanden, sondern eine vollständige Kopie Ihrer Produktivdaten. In dieser Umgebung können Sie dann unter realen Bedingungen die Leistungsfähigkeit ihrer neuen Funktionen testen und so Performanceprobleme identifizieren.

Die Produktivumgebung

Nach erfolgreichen Anwendertest und gegebenenfalls einer Validierung können Ihre Systemänderungen dann in Ihre Produktivumgebung übernommen werden.

Die Trainingsumgebung

Neue Anwender des PLM-Systems müssen in der Anwendung dessen trainiert werden. Dabei ist es unerheblich, ob das in einem Präsenztraining erfolgt oder mittels neuer Ansätze wie einem e-learning passiert. Eine dedizierte Umgebung mit generischen Trainingsidentitäten unterstützt diese notwendige Ausbildung.

S ie sehen, dass es eine ganze Reihe von dedizierten Umgebungen benötigt werden, um schlußendlich eine produktive Instanz sicher, in möglichst guter Qualität und, wenn notwenig, validiert betreiben zu können. Das führt mich wieder zu meinem anfangs geschilderten Problem zurück. Sie übertragen Änderungen an der Konfiguration Ihres PLM-Systems häufig von einer Umgebung in die andere und der Aufwand, der damit verbunden ist, macht einen signifikanten Teil der Betriebskosten aus. Werfen wir daher noch einen genaueren Blick auf den Charakter der Daten, die hier übertragen werden müssen. Bisher habe ich ja immer nur diesen recht abstrakten Begriff „Konfiguration“ dafür benutzt.

1) Änderungen des PLM-Systems zur Abbildung von Anwenderanforderungen

Das ist sowas wie das „täglich Brot“ Ihrer PLM-Administratoren und -Systemmanager. So ein PLM-System ist ja nie fertig und somit gibt es immer eine Reihe von Anwenderwünschen, die umgesetzt werden müssen. Dabei möchte ich die Daten, die dabei geändert werden, noch einmal ein wenig unterteilen:

  • Administrative Daten wie z.B. User und dazugehörige Rechte oder Reportvorlagen (z.B. für KPIs basierend auf den PLM-Daten)
  • Konfigurationsdaten, wie z.B. neue oder geänderte Businessobjekte, Erweiterungen des Datenmodells, Attribute, elektronische Workflows, Rollen und Berechtigungen, …
  • Erweiterungen und Anpassungen durch individuelle Programmierung
  • PLM-Daten, wie z.B. Dokumente, Parts, Requirements, Spezifikationen ,…

Je nach Anwendungsfall müssen diese Daten einfach, schnell und vollständig in eine andere Umgebung transferiert werden können. Dabei ist es nicht in jedem Fall so, dass alle Daten immer und vollständig übertragen werden müssen. Ein schönes Beispiel dafür sind User. Ich glaube kaum, dass die generischen User aus Ihren Entwicklungsumgebungen sich in ihrer Produktivumgebung wiederfinden sollen. Das wäre doch eher seltsam, gerade wenn die produktiven User eigentlich aus einem AD oder LDAP gespeist werden. Anders ist dies aber vielleicht beim Update des Trainingssystems. Dort wäre es hilfreich, generische User automatisch übertragen zu können und diese nicht per Hand „nachklicken“ zu müssen.

Für die Konfigurationen und die programmierten Erweiterungen des PLM-Systems fällt mir kein Anwendungsfall ein, wo dieser Übertrag nicht vollständig sein muss. Es ist also immens wichtig zu überprüfen, ob die Mechanismen und Tools ihres (zukünftigen) PLM-Systems wirklich vollständig alle Objekte übertragen können oder ob es nicht doch welche gibt, die sie dann jedesmal manuell nachpflegen müssen. Dieser Aufwand ist nicht zu unterschätzen und das Fehlerpotenzial dafür ebenfalls nicht. Denken Sie daran, dieses eventuelle manuelle Übertragen von Konfigurationen fällt häufig an.

2) Neue Major Releases Ihres PLM-Systemherstellers

Jeder PLM-Systemhersteller entwickelt sein System auch weiter und bringt in regelmäßigen Abständen neue Releases seiner Software heraus. von diesen neuen Funktionen möchten sie natürlich profitieren und damit ist es wichtig zu erfahren, wie diese neue PLM-Systemversionen in ihre Umgebungen eingespielt werden können. Hier ändert sich ja nicht nur die Konfiguration ihres System, sondern die Basis, auf der ihre Konfiguration beruht. Sie müssen eine genaue Kenntnis darüber haben, welche Strategien und Werkzeuge ihr PLM-Systemhersteller anbietet, um sie bei dem Upgrade ihres Systems zu unterstützen. Wie wird zum Beispiel mit den Anpassungen umgegangen, die sie am System vorgenommen haben, wenn ein neues Softwarerelease eingespielt wird? Was passiert mit Ihrem Datenbestand und müssen eventuell sogar Daten migriert werden, weil sich Datenmodelländerungen sich nicht anders abbilden lassen? Eine gute Idee ist es, hier in die entsprechenden Anwendercommunities hineinzuhören und Erfahrungen mit anderen Anwendern zu teilen. Es gibt ja dafür seit kurzem dieses Internet, vom dem man in letzter Zeit so viel hört und liest.

3) Hotfixes und Servicepacks Ihres PLM-Systems

Fehler im PLM-SyetemFehlerfreie Software gibt es nicht und somit rutschen es auch bei sorgfältigster Qualitätssicherung Bugs in die Softwarereleases hinein. Das kann mit vertretbarem Aufwand nicht verhindert werden. Wie reagiert der Hersteller ihres Systems auf diese Fehler? In welchem Zeitraum liefert er Hotfixes und Service Packs?. Und sie müssen prüfen, wie diese Hotfixes und Servicepacks dann in Ihre Umgebungen eingespielt werden können. Das ähnelt dann den Herausforderungen, sie sie auch bei neuen Major Releases meistern müssen.

4) Lizenzen

Und zu guter Letzt git es bei einigen Herstellern noch zu berücksichtigen, dass sie Lizenzen kaufen müssen. Wie großzügig ist dann aber die Regelung für die eher generischen Anwender für Ihre Entwicklungs-, Integratiins- und Validierungsumgebungen?

Damit komme ich auch schon zum Ende dieses eher technischen Artikels. Vielleicht konnte ich Ihnen einige Hinweise geben und meine Erfahrungen mit Ihnen teilen. Für Kommentare und Ergänzungen steht Ihnen die Kommentarfunktion zur Verfügung.

Innovative Schulungskonzepte im PLM: E-Learning

Veröffentlicht am , aktualisiert am von Christoph

PLM E-LearningNachdem die Rubrik “PLM-Talk” in der letzten Zeit diesen Blog dominiert hat, möchte ich jetzt wieder etwas aus dem Erfahrungsschatz der Projektarbeit teilen. Wir sprechen ja alle von der Digitalisierung und den ganzen “xyz 4.0”, die als Marketingschlagworte dafür dienen. Das macht natürlich auch nicht vor der Wissensvermittlung halt. Gerade in den regulierten Branchen wie der Medizintechnik oder der Luftfahrtindustrie ist es unabdingbar, dass vor der Nutzung von Geräten, Methoden und Prozessen die Mitarbeiter trainiert und eingewiesen werden. Das betrifft natürlich auch das PLM Toolset, denn im diesen sind ja viele Engineeringsprozesse abgebildet und die Software ist Begleiter der täglichen Arbeit. Und unabhängig von der normativ geforderten Schulungsquote ist es auch sonst eine gute Idee, zukünftige Anwender eines neuen PLM Moduls zuerst darauf zu schulen, bevor man es in die produktive Nutzung entlässt.

Neben den klassischen Trainings in einem Schulungsraum mit einem mehr oder minder gut vorbereiteten Trainer und einer überschaubaren Anzahl von Teilnehmern setzt sich in den letzten Jahren eine digitale Form der Wissensvermittlung durch: das E-Learning. Ich gebe unumwunden zu, dass ich sehr skeptisch war, ob so ein komplexes Thema wie z.B. ein Change-Prozess mit ein paar automatisch animierten Powerpoint-Folien ausreichend gut geschult werden kann. Aber ich musste mich eines besseren belehren lassen. Ein E-Learning ist ganz sicher nicht nur ein “Folien-Film” und man kann auch PLM im E-Learning vermitteln. Aber was ist dabei unbedingt zu beachten?

Qualität des E-Learnings

Aus meiner Erfahrung heraus ist auf diesen Punkt das größte Augenmerk zu legen. Professionell erstellte E-Learnings haben mit animierten Powerpoint-Folien oder abgefilmten “ich klickmalhierhinunddanndahin”-Screencasts so gar nichts zu tun. Ein E-Learning für ein PLM-Modul soll nicht unterhalten wie ein youtube-Letsplay, sondern Wissen vermitteln. Unser Auge ist geschult darin, visuelle Unzulänglichkeiten sofort zu erkennen und diese dann als störend zu klassifizieren. Gute E-Learnings zeichnen sich durch eine kreative grafische Umsetzung aus und durch etwas, was bei den E-Learningsprofis “pixelgenaues Arbeiten” heisst. Erst beides gemeinsam ergibt einen ansprechenden Gesamteindruck. Nutzen Sie doch diese künstlerische Freiheit auch für ein wenig Motivation für die zukünftigen Anwender. Haben sie keine Angst, hier auch mal richtig auf die Pauke zu hauen und Wege, wie man sie eher aus der Werbung kennt, zu gehen.

Der zweite sehr gern vernachlässigte Teil des E-Learnings ist die Tonspur. Achten Sie hier auf die sprachliche Qualität der Sprechertexte. Ich konnte dabei lernen, dass sich geschriebene Texte   nicht immer gesprochen auch gut anhören. Man neigt dazu, in der Schriftform eher längere Sätze zu schreiben und in Schachtelsätzen zu formulieren. E-Learning-Profis werden Ihnen dabei helfen, das in einen gut sprech- und hörbaren Text zu wandeln. Und verwerfen sie den Gedanken, den Text selber sprechen zu wollen (es sei denn, sie sind nebenberuflich Synchronsprecher oder lesen im Radio die Nachrichten vor). Die qualitative Aufwertung des E-Learnings durch eine professionellen Sprecher und durch eine Aufnahme in einem Tonstudio ist immens.  Das war für mich der größte Lerneffekt mit diesem E-Learningszeug, wie wichtig die Qualität der Tonspur ist. Erst sie macht das Produkt E-Learning zu etwas, was gern von den zukünftigen “E-Learnern” angeschaut und angehört wird. Und ein kleiner Hinweis noch: Nutzen Sie doch die Tonspur als Projektmarketingmaßnahme. Kein Mensch weiß in Deutschland, wie sich die echte Stimme von Bruce Willis anhört. Seine Synchronstimme kennt aber fast jeder. Und jetzt stellen Sie sich vor, dass “ihr” Change-Management E-Learning von Bruce Willis gesprochen wird. Yippie Yah Yei Schweinebacke!

Der Business Case

So ein E-Learning ist nicht kostenlos zu bekommen, das ist klar. Daher muss betrachtet werden, in welchem Verhältnis Kosten und Nutzen gegenüberstehen und ob sich ein E-Learning auch kommerziell rechnet.

An einmaligen Kosten und Aufwänden (intern oder extern) fallen an:

  • Erstellung des Storybords und der Sprechertexte
  • Animation/Programmierung der grafischen Umsetzung
  • Lizenzen für Video und Foto
  • Professioneller Sprecher und die Tonstudiomiete
  • Hosting and Lizenzen für das Trainingsmanagementsystem
  • Infrastruktur für e-Learner (Rechner mit Kopfhörer)
  • Opt: Kosten für Übersetzung bei mehrsprachigen E-Learnings

An Nachfolgekosten müssen sie an Änderungen im Produktlebenzyklus des E-Learnings denken. Prozesse und Tools können sich ändern, dann muss auch das E-Learning angepasst werden.

Aus der Seite des Einsparpotentials gegenüber dem klassischen Präsenztraining steht:

  • Keine Limitierung bei der Anzahl der Teilnehmer
  • Keine zeitliche und örtliche Einschränkung der Teilnehmer
  • Lerntempo kann von jedem E-Learner selbst bestimmt werden
  • Kein Vorhalten von Trainingsräumen und sonstiger -infrastuktur
  • Kein externer oder interner Trainer nötig
  • Einsparung im Support (E-Learning kann beliebig oft wiederholt werden, dient als Knowledgebase)
  • Barrierefreiheit ist gegeben, wenn Tonspur auch als Untertitel eingeblendet werden kann
  • Erhöhung der Prozessischerheit durch höhe Schulungsquote (nur wer das E-Learning absolviert hat, bekommt Freischaltung für das Modul)
  • Positive Effekte für das Projektmarketing

Was es sonst noch zu sagen gibt

Der klassische Nachteil eines E-Learnings soll natürlich nicht unerwähnt bleiben. Die direkte Kommunikation zwischen einem Trainer und der Schüler ist nicht möglich. Folgende Maßnahmen können dieses Manko aber mildern.

PLM SprechstundeRichten Sie regelmäßige Sprechstunden ein, in denen sie persönlich für Fragen von E-Learnern zur Verfügung stehen. Damit fangen sie diejenigen auf, deren Fragen nicht vollständig im E-Learning beantwortet werden konnten.  Machen Sie keine Kompromisse in der Qualität des E-Learnings, weder in der Grafik, noch beim Ton. Niemals. Arbeiten Sie in die E-Learnings an passenden Stellen Verständnisfragen ein, die der E-Learner beantworten muss. Er bekommt dann anhand der Ergebnisse eine Rückemeldung darüber, ob er den Stoff verstanden hat.  Schließen Sie das E-Learning mit einer eher anspruchsvollen Prüfung ab. Verschenken Sie nicht einfach das Trainingszertifikat. Das sorgt dafür, dass das E-learning nicht nur schnell durchgeklickt wird. Sie haben mit Ihrem E-Learning ein Premiumprodukt, das sollte sich auch in der Prüfung wiederspiegeln.

Das waren meine Erfahrungen mit E-Learnings im PLM-Bereich. Ich wünsche Ihnen viel Erfolg bei der Umsetzung Ihrer Schulungen in die digitale Welt. Und ich kann ihnen versprechen: Das macht auch noch Spaß.

Follow my blog with Bloglovin

Der PLM-Talk – heute mit Prof. Martin Eigner, Lehrstuhl für Virtuelle Produktentwicklung, TU Kaiserslautern

Veröffentlicht am , aktualisiert am von Christoph

 

Herzlich willkommen auf meiner virtuellen Blogcouch, Herr Prof. Eigner. Ich freue mich sehr, dass Sie sich ein wenig Zeit für dieses Interview nehmen. Sie selbst muss ich dem geneigten Leser nicht mehr vorstellen, Ihr Name ist untrennbar mit dem PLM verbunden. Aber können Sie vielleicht zum Einstieg ein paar Worte zu Ihrem Lehrstuhl für virtuelle Produktentwicklung an der Universität Kaiserslautern sagen?

Prof. Martin Eigner PLM

Prof. Martin Eigner: Der Lehrstuhl für Virtuelle Produktentwicklung (VPE) verfügt über umfangreiche Erfahrungen in der Entwicklung und Bereitstellung von Methoden und Konzepten zur Optimierung aller Phasen des Engineeringprozesses und adressiert mit seinen Arbeiten insbesondere Anforderungen, die sich aus der Umsetzung des „Industrial Internet“ (Industrie 4.0 sowie Internet der Dinge und Dienste) ergeben. Hierbei sind alle Lebenszyklusphasen eines Produkts einzubeziehen, wie zum Beispiel die interdisziplinäre und integrierte Entwicklung, Prozessplanung, Fertigung und Montage sowie Dienstleistungen. Zukünftig werden intelligente, über das Internet und andere Dienste miteinander vernetzte und kommunizierende Produktsysteme alle Industrien erfasst und viele der herkömmlichen, mechanischen und mechatronischen Produkte abgelöst haben. Das Interesse an weiteren Funktionen und Applikationen für künftige Software-Lösungen zur Verwaltung der Daten solcher Systeme wächst ständig und eine effektive Ausgestaltung des Lebenszyklus der Systeme ist zwingend erforderlich. „System Lifecycle Management (SysLM)“, ein Begriff, der sich mehr und mehr national und international durchsetzt, wird hierzu auch vom VPE als nächste Stufe von Product Lifecycle Management (PLM) auf- und ausgebaut und als Schlüsselkonzept zur detaillierten Ausgestaltung nach dem Ansatz des Industrial Internet angesehen. Dabei geht der Trend eindeutig in flexible, föderierte und leichtgewichtige Backbone Lösungen, die mit RDF/REST Technologien mit der Autoren- und TDM-Systemebene vernetzt sind.

Welche Schwerpunkte in der Lehre und Forschung setzen Sie gerade aktuell? Gibt es die ein oder andere Promotion oder eine andere Veröffentlichung, die besonders erwähnt werden sollte?

Prof. Martin Eigner: Das VPE stellt seine Kompetenzen in vielen Projekten mit Partnern aus der Industrie und Forschung zur Verfügung. Die Forschung innerhalb aller Kompetenzfelder des Lehrstuhls zeichnet sich durch eine hohe Anwendungsorientierung aus. Die Aktivitäten von VPE haben Themen aus dem System Lifecycle Management zum Schwerpunkt. Eng damit verknüpft sind die Themengebiete „Model-Based Systems Engineering (MBSE)“ sowie „Vernetzte IT-Toolketten und Standards“. Arbeiten zu den Themengebieten „Industrial Internet“ und „Nachhaltigkeit“ adressieren aktuelle Herausforderungen an eine moderne, interdisziplinäre und integrierte Entwicklung smarter Produktsysteme sowie Dienstleistungen. Als Beispiele solcher Arbeiten seien die erste Integration eines SysML Systems mit einem handelsüblichen PLM-System und die Entwicklung eines Prototyps für einen vernetzten Engineering Backbone auf der Basis eines handelsüblichen PLM Repositories und WEB Technologien genannt. Beide Prototypen wurden von Partnerfirmen (XPLM und Aras) industrialisiert. Der Engineering Backbone wird gerade von Aras bei Schaeffler mit 20.000 Arbeitsplätzen installiert.

Auf den PLM-Tagungen und Konferenzen des letzten Jahres war der von Ihnen geprägte Begriff des „Digital Model“ und „Digital Twin“ in aller Munde. Können Sie den Lesern erläutern, was sich hinter diesen Begriffen verbirgt?

Prof. Martin Eigner: Ein digitales Model ist ein digitales Abbild aller Produkt-relevanten Informationen über den Produktlebenszyklus über alle Disziplinen und die Zulieferkette. Das digitale Modell umschließt verschiedene IT-Infrastrukturebenen:

  • Autorensystemebene, z.B. SysML-, CAD-, CAM-, CAE-Systeme, die im Wesentlichen die Informationen generieren.
  • Team Data Management (TDM) Ebene, die die autorensystemnahe Verwaltung der Daten ermöglicht. Je nach TDM-Klasse sind die Systeme bereits mit Administrationsfunktionen ausgestattet, z.B. einfaches Revisions- und Versionsmanagement.
  • PLM Backbone, der die Integration der verschiedenen Modelphasen und IT-Infrastrukturebenen integriert und die typischen Engineeringprozesse (ERM, ECM, CM) umsetzt. Er ist damit auch der sogenannte Digital Thread, der die Produktkonfiguration und damit die Rückverfolgbarkeit des Produktes garantiert.

Zwischen den Ebenen und den Produktlebenszyklusphasen liegen vielfältige Formen der Kommunikation vor. Bei der digitalen Modellierung werden zwei Begriffe unterschieden:

  • das auftragsneutrale Digitale Modell bzw. der Digital Master (Man spricht beim digitalen Master auch häufig von einem sogenannten 150% Modell, um auszudrücken, dass das digitale Modell i.d.R. nicht auftragsspezifisch ist, sondern alle Komponenten über alle Baukästen und Varianten einschließt) und
  • der auftragsspezifische und vereinzelte bzw. instanziierte Digitale Zwilling bzw. Digital Twin

Ein Digitaler Zwilling (DZ) eines Produkts stellt ein virtuelles instanziiertes Abbild eines realen Produktes dar. Er enthält Informationen über die real konfigurierten Produktfunktionen (dient der klaren Differenzierung von Produktvarianten untereinander), die überwachbaren Produkt- und Umgebungsparameter, die aktuell gemessenen Parameterwerte sowie den Zustand der einzelnen Produktfunktionen inkl. deren Restdauerabschätzungen. Der DZ existiert im Prototypen- und Produktionsbereich schon immer, ohne so genannt zu werden. Interessant ist heute der DZ im Bereich serviceorientierter Geschäftsmodelle. Dort dient er vor allem der Rückverfolgbarkeit von Änderungen durch Wartung und Aufrüstung. Es werden nur Informationen im servicerelevanten DZ abgelegt, die vom Produzenten als relevant für die Nachverfolgung definiert werden. Er ist immer ein verkürzter aktueller Snapshot des physischen Produktes.

Was ist die größte Herausforderung, dieses „Digital Model“ und diesen „Digital Twin“ in das tägliche PLM-Leben zu überführen? Wo sehen Sie hier die Protagonisten der PLM-Community gefordert?

Prof. Martin Eigner: Wenn man sich heutige PLM Implementierungen anschaut, sind diese nicht immer vom Erfolg gekrönt. Es sieht eher nach dem Motto „als Tiger springen und als Bettvorleger landen“ aus. PLM Systeme sind komplex zu customisieren – werden vielfach übercustomisiert – und müssen bei jedem Upgrade der PLM Basisversion nachcustomisiert werden. 80% der „PLM“ Einführungen decken die Phase Entwicklung und Konstruktion mit dem Schwerpunkt der M-CAD Verwaltung ab. Daran erkennt man das Problem: Die Differenz zwischen Istzustand und Vision. Mit der deutschen Übergründlichkeit bei der Systemanpassung und den heutigen PLM Technologien und Geschäftsmodellen wird es schwierig sein, die genannten Zielsetzungen zu erreichen.

Aus Ihrem universitärem Blickwinkel heraus betrachten Sie das Thema PLM unabhängig von Systemherstellern oder Dienstleistern. Welche Entwicklung in den letzter Zeit fanden sie aber besonders bemerkenswert oder was hat sie eventuell sogar überrascht?

Prof. Martin Eigner: Ansätze wie “bimodale PLM / IT” (Gartner, 2016) oder “Digital PLM” (Accenture, 2016) deuten in ähnlicher Weise wie SysML (VPE) die Notwendigkeit einer Evolution an:

  • Von Dokument-basiert zu Modell-basiert
  • Von hierarchischen- (herkömmlichen Stücklisten der Hardware) bis hin zu Netzwerk- (MBSE) und linearen Strukturen (Software)
  • Aufteilung der Anwendungsdaten und Metadaten auf Basis eines objektorientierten Repository
  • Von monolithischen zu föderierten und leichtgewichtigen Systemen, die auf referenzierte bzw. verknüpften Daten. Die dazu notwendigen IT-Technologien basieren auf dem objektorientierten Repository und REST
  • Bereitstellung auf unterschiedlichen Cloud-Level (IaaS, PaaS und SaaS)
  • Unterstützung der typischen Engineering Prozesse wie z.B.  Engineering Change Management (ECM) und Configuration Management (CM) für Mechanik, Elektrik / Elektronik und Software sowie Ableitung von Digitalen Zwillingen für Einsätze in Produktion und Service
  • Agile Einführung und betriebliche Anpassung durch überwiegend interaktive Konfiguration anstatt durch prozedurales Customizing
  • Automatischer Übernahme aller betrieblicher Anpassungen (Konfiguration und Customizing) bei Upgrade des Basissystems
  • Neue flexible Geschäftsmodelle auf Basis von Subscriptions anstatt Lizenzen

Gartner (Marc Halpern) zählt Aras und Onshape zu den Bimodalen Systemen (PDT Europe 2016).

Denken wir mal fünf bis zehn Jahre voraus. Ist dann der Begriff „ PLM” in diesem „Digital xyz“ oder Industrie x.0 aufgegangen oder wo werden wir dann damit stehen?

Prof. Martin Eigner: Die Komplexität heutiger PLM-Architekturen und Einführungsstrategien ist bereits sehr hoch und die zu erwartende weitere Zunahme durch cybertronische Produkt- und Produktionssysteme wird diesen Trend verstärken. Die Nachvollziehbarkeit über den gesamten Produktlebenszyklus, über die Disziplinen und die Lieferkette muss jederzeit gewährleistet sein, um den Engineering Prozess zu beherrschen und zu dokumentieren. Als Erweiterung von PLM sehe ich das System Lifecycle Management (SysLM) als nächsten Schritt. Bimodales SysLM ist das Engineering-Backbone-Konzept für Produktentwicklung und Lifecycle Management im Rahmen des Industrial Internet und für integriertes und interdisziplinäres Model Based  Systems Engineering (MBSE), Product Line Engineering (PLE) und Service Lifecycle Engineering (SLE).

Prof. Eigner, ich möchte Ihnen für dieses aufschlussreiche Gespräch danken und wünsche Ihnen weiterhin viel Erfolg und gutes Gelingen bei Ihren Projekten.