Innovative Schulungskonzepte im PLM: E-Learning

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ß.

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

 

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.

 

Der PLM-Talk – heute mit Leon Lauritsen, Minerva Group A/S

 

Mein Blick über den Tellerrand schaut heute Richtung Norden, genau gesagt nach Dänemark. Leon Lauritsen, VP und Partner der Minerva Group A/S gibt diesem Blog ein gewisses internationales Flair und blickt aus Skandinavien auf das Thema PLM.

Mr. Lauritsen, I am very happy to welcome you. Some of the readers of this blog will know you from conferences or projects. Could you say a few words to introduce yourself and how you came into contact with PLM?

Leon Lauritsen: I have had a long experience with optimizing manufacturing companies primarily through implementing ERP solutions. In dealing with many of those companies over the years I found that one areas that hadn’t really been optimized and still was very fragmented and operating in silos was all the processes and data for getting the product ready to be manufactured, which was the start of looking into optimizing this area as well.

You look back on a long and successful PLM history. What milestones in your personal PLM history are particularly worth mentioning? Which experiences and encounters with PLM protagonists has remained in your memory?

Leon Lauritsen: It is hard single them out, but of course winning the first project in a new domain since we had no history or reputation in PLM was an important step. As was the major global rollout we did at Phillips Healthcare. Most significant was properly when we more than 8 years ago we decided to shift out a good and safe business with one of the existing PLM software vendors, putting all our focus on  a new software vendor (“Aras”) and a very different business model. This has then been followed by many new customers both very large and small and expanding geographically very considerably.

PLM is continually changing. From your perspective, which developments and innovations push PLM the most today? In current projects, what are the most challenging issues for your customers?

Leon Lauritsen: The complexity in products. They are in many cases not products but systems with so many elements so the good “old” way of managing an eBOM structure is not at all enough. On top of that many companies have already invested in PLM which means that for many parts of the business they have PLM. The issue is that they have a PLM system – Yes, but this doesn’t mean that they do PLM and understand that there is a huge difference from where they are and where they need to go. That their investments most times cannot support that journey is very difficult for companies to comprehend. In implementation for handling systems companies are playing catch-up and are just starting to look into MBSE, so they are not certain of how they will work in the future.

The term “Industry 4.0” has been flavor of the month for some time. As you can read on the website of the German Federal Ministry of Education and Research, Industry 4.0 stands for the 4th revolution in the industry history and is a synonym for the digitalisation of industrial processes. In your opinion what are the main PLM challenges in the next 10 years? Is Industry 4.0 the new PLM? What problems will be solved in that time frame?

Leon Lauritsen: I have a hard time predicting the future for the next 10 years, if I look back just 5 years and what was the belief then. What I though can state is the old belief that everything should be centralized in one PLM system that can handle everything will not be possible and as both Gartner Group and Cimdata are stating PLM must become more an innovation platform. This will require a certain software architecture to be able to support that and several of the existing large players don’t have the solutions that really can support this, which will be one of the interesting developments to follow what is happening here.

From your point of view what are the differences between PLM projects in Scandinavia and the rest of the world (i.e. Germany)? Does a regional culture influence the technical focus of a PLM project? And since I ask for the technical and not that is the cultural focus, is that question typically “German”? I am an engineer and a leopard can’t change his spots. 

Leon Lauritsen: I believe a lot of research is being done into how business and decisions are being done in Scandinavia which differs from many other places throughout the world and this general cultural difference then also is reflected in a PLM project. In general, it is much accepted to challenge authorities, getting to challenge decisions and wanting to get everyone on board instead of forcing a top-down decision. This on one hand results in good adoptions of the solutions, but decision making in the project can also be a challenge.

And if we are already in the context of corporate culture. Is there a Scandinavian way of doing PLM projects? What is the difference between Minerva’s PLM methodology and others?

Leon Lauritsen: I believe that we have a well proven implementation methodology where we have adopted the good things we have learned over the more than 75 PLM implementations we have done over the years. Explaining the exact differences would require a lengthy description, but key is that experience from our many successful implementations has been built into the methodology and very importantly we have an exceptional team of people which we can see as customer from other parts of the world or customers of other consulting companies are contacting us to get access to our expertise and people.

Many thanks for your time and good luck with Minerva.

Der PLM-Talk: Heute mit Tim Weilkiens (oose Innovative Informatik eG)

Es geht Schlag auf Schlag im PLM-Talk. Gerade erst wurde noch über die Unterschiede und Gemeinsamkeiten zwischen PLM und ERP gefachsimpelt, wird es heute wieder methodischer. Mit Tim Weilkiens, Vorstand der oose Innovative Informatik eG steht ein ausgewiesener Fachmann für ingenieurige Modelle Rede und Antwort.

Hallo Herr Weilkiens, herzlich willkommen auf meiner Blog-Couch zu einer weiteren Episode des PLM-Talks. Ich hoffe, Sie sitzen gemütlich. Man kann davon ausgehen, dass fast alle Leser dieses Blogs bereits eine Publikation von Ihnen in der Hand gehabt haben. Aber können Sie trotzdem ein paar Worte zu Ihrer Person und Ihrem Werdegang verlieren?

PLM Experte Tim Weilkiens

Tim Weilkiens

Ursprünglich bin ich Informatiker. Schon bei meinem ersten Arbeitgeber in den 90er-Jahren bin ich mit der UML in Berührung gekommen. Seitdem hat mich die Modellierung nicht mehr losgelassen. Mit der Entwicklung der neuen UML-Version 2.0 habe ich angefangen, in den Arbeitsgruppen der OMG mitzuwirken. Neben der UML, habe ich auch an der BPMN mitgewirkt sowie an den zahlreichen Zertifizierungsprogrammen der OMG. Und natürlich an der Entwicklung der SysML. Aktuell leite ich gemeinsam mit Airbus und der NASA, die Arbeitsgruppe zur nächsten Version SysML 1.6. An der nächsten großen Version 2.0 arbeiten wir ebenfalls bereits schon.

Sprachen sind das eine, viel wichtiger sind noch die Methoden. Hier gibt es allerdings wenig Standards. Ich betrachte mich mehr als ein Sammler als Erfinder von Methoden. Es sind erprobte Vorgehensweisen, denen ich in unterschiedlichen Firmen und Domänen begegne. So ist beispielsweise meine MBSE-Methodik SYSMOD (Systems Modeling Toolbox) oder VAMOS (Variant Modeling with SysML) entstanden.

Seit 2001 bin ich beim Beratungs- und Trainingshaus oose als Berater tätig. Seit 2010 zusätzlich auch als Geschäftsführer bzw. Vorstand seit wir uns in eine Genossenschaft umgewandelt haben.

Ihr Name ist untrennbar mit der System Modeling Language SysML verbunden. Aus welcher Motivation heraus entstand die Initiative zur Entwicklung dieser Erweiterung der UML? Was war das verbindende Element dieser doch recht unterschiedlichen Aktivisten der ersten Stunde der SysML?

Das verbindende Element war sicherlich die Überzeugung, dass Modellierung notwendig ist, um erfolgreich immer komplexer werdende Systeme entwickeln zu können. Die Konzepte der SysML war für die Beteiligten auch nicht wirklich Neuland. Alle haben schon Modellierung im Systems-Engineering-Umfeld eingesetzt. Nur eben keine SysML, sondern beispielsweise eine angepasste UML. Die Definition der SysML war dann „nur“ noch die Standardisierung bewährter Ansätze.

Für die Nichtinformatiker unter uns: Was ist eigentlich genau der Unterschied zwischen der UML und der SysML? Was kann SysML jetzt besser?

Die UML ist eine Modellierungssprache für Softwareanwendungen. Die SysML ist eine Modellierungssprache für Systeme bestehend aus Software, Elektronik, Mechanik, usw. Das sind zunächst scheinbar zwei verschiedene Paar Schuhe. Nun ist die UML sehr allgemein definiert, also statt konkret Softwaretechnologien anzusprechen, geht es vereinfacht gesagt darum, Dinge geschickt zu strukturieren und ihr Verhalten und Zusammenspiel zu beschreiben. Das lässt sich dann auch auf Systeme über Software hinaus übertragen.

Und das wurde ja auch schon bereits vor SysML-Zeiten mit der UML gemacht. Ich kenne neben Softwaremodellierung auch den Einsatz der UML, um Systeme zu beschreiben, Geschäftsprozesse und Unternehmen zu modellieren, bis hin zu biologischen und sozialen Systemen. Letzteres ist aber schon recht exotisch.

Man kann nicht sagen, dass die SysML etwas besser als die UML kann. Sie erfüllt einfach einen anderen Zweck. Die SysML ist formal ein Dialekt der UML. Elemente aus der UML, die softwarespezifisch sind oder keinen erkennbaren Nutzen für Systems Engineering haben, wurden entfernt. Dafür wurden neue Elemente und Begriffe ergänzt, wie beispielsweise Requirement oder Block.

Können Sie uns an einem Beispiel den Einsatz eines neu hinzugekommenen bzw. modifizierten Diagrammtypen aus der SysML schildern? So wird es vielleicht noch deutlicher, wie die SysML angewendet werden kann.

Ein zentraler Diagrammtyp der SysML ist das interne Blockdiagramm. Es zeigt, wie ein System aufgebaut ist. Rechtecke stehen für Systembausteine und die Linien dazwischen, dass es zwischen den Bausteinen einen Austausch gibt. Das kann eine softwarebasierte Kommunikation sein, eine mechanische Verbindung, der Austausch von Wärme oder eine beliebig andere Art. Zusätzlich kann noch dargestellt werden, dass die Kommunikation zwischen zwei Bausteinen über definierte Schnittstellen erfolgt.

Sie finden solche Darstellungen überall in Büros von Systemingenieuren auf Flipcharts und Skizzenblöcken. Die SysML hat das mit dem internen Blockdiagramm einfach nur standardisiert. Es ist eine intuitive und abstrakte Darstellung einer Systemstruktur.

Welche Vorteile sehen Sie durch den Einsatz von SysML in der Praxis – jetzt auch gerade im Bezug auf das Produkt-Lifecycle-Management? Ist SysML die neue Sprache im Requirements Engineering? 

Die SysML fördert die Kommunikation zwischen verschiedenen Ingenieursdisziplinen und Stakeholdern. Das ist für viele Projekte ein großer Sprung nach vorne und oft auch ein „low hanging fruit“. Für den ersten großen Sprung, muss man gar nicht so viel Anlauf nehmen. Eine Bereitschaft zu springen, sollte natürlich schon da sein.

Ohne SysML fehlt eine formalisierte Grundlage disziplinenübergreifend zu kommunizieren und man landet automatisch bei Word, Powerpoint und Visio. Die Systems-Engineering-Informationen sind viel zu wertvoll, um sie monolithisch in einem Office-Dokument abzulegen. Systems-Engineering mit Word zu machen, ist wie Mechanical Engineering mit Paint. What you see is what you get – und mehr auch nicht.

Ich würde SysML nicht als die neue Sprache des Requirements Engineerings bezeichnen. Es ist die Sprache des Systems Engineerings. Gleichzeitig hat es durch die SysML einen großen Schub im Requirements Engineering gegeben. Wir wissen seit Jahrzehnten wie wichtig Requirements Engineering für den Erfolg eines Projekts ist und trotzdem gelingt es nicht, es richtig einzusetzen. Requirements Engineering gehört sowohl zu den TOP5 der Erfolgsfaktoren eines Projekts als auch zu den TOP5 der Gründe für das Scheitern eines Projekts. Die SysML hat vor allem eine Bewegung angestoßen, Anforderungen nicht nur rein textuell zu betrachten, sondern sie wirklich zu modellieren. Ein modellierter Zustandsautomat kann eine Anforderung (oder eine Menge an Anforderungen) sein und muss dafür nicht in Text übersetzt werden.

Der Sprung von einer eher dokumentzentrierten und natursprachlichen Form der Produktdefinition zu einer Modellierung in SysML ist aber schon ein Paradigmenwechsel, gerade wenn es um mechanische oder mechatronische Systeme geht. Was hilft aus Ihrer Erfahrung heraus, diesen Paradigmenwechsel vollziehen zu können? 

Es hilft, diesen Sprung auch wirklich als Paradigmenwechsel zu behandeln. Es genügt nicht, ein paar Lizenzen für ein Modellierungswerkzeug zu kaufen und eine Schulung zu besuchen. Es ist ein Veränderungsprozess in der Organisation und muss entsprechend umgesetzt werden.

Meine letzte Frage zielt ein wenig in die Zukunft. Gibt es schon Pläne zur Weiterentwicklung von SysML? Oder gibt es bereits Ideen und Visionen zur Entwicklungen nach SysML?

Am Horizont geht gerade langsam die SysML V2 auf. Aktuell arbeiten wir an den Anforderungen für die neue Version der SysML. Ende dieses Jahres soll der zugehörige Request for Proposal veröffentlicht werden. Danach geht es an die Umsetzung. Nach 10 Jahren Erfahrung mit der SysML V1 hat sich genug angesammelt, um die nächste Generation der Sprache zu entwickeln. Zu den Plänen gehören beispielsweise eine Unterstützung der Modellierung von Varianten und der Austausch von Modellinformationen.

Herr Weilkiens, ich danke Ihnen für dieses informative Gespräch und wünsche Ihnen weiterhin viel Erfolg und gutes Gelingen in Ihren Projekten. 

Der PLM-Talk – heute mit Sven Mahn und Wolfgang Enking (Sven Mahn IT – The AX Authority)

Auf meiner virtuellen PLM-Couch haben wieder zwei hochkarätige Gesprächspartner Platz genommen: Sven Mahn, Inhaber der Sven Mahn IT GmbH & Co KG und Wolfgang Enking, Verantwortlich für das Business Development im gleichen Unternehmen sprechen über Gemeinsamkeiten und Unterschiede zwischen PLM- und ERP-Projekten.

Herzlich willkommen auf meiner virtuellen Blog-Couch, Herrn Mahn und Herr Enking. Ihre Namen sind mit dem Tool Microsoft Dynamics AX verbunden und man kennt Sie hauptsächlich aus dem ERP-Umfeld. Können Sie ein paar Worte zu Ihrem Werdegang verlieren?

ERP-Experte Sven Mahn

Sven Mahn

Sven Mahn: Moin moin von meiner Seite. Ich bin vor 40 Jahren in Hamburg geboren, bin hier groß geworden und habe nach dem Abitur eine Lehre zum Beton- und Stahlbetonbauer abgeschlossen. Mit Computern und Software habe ich mich seit dem zehnten Lebensjahr beschäftigen dürfen, neben den Klassikern auf C16 und C64 habe ich bereits in dem Alter angefangen zu programmieren. Das hat mich im weiteren Verlauf zur Wirtschaftsinformatik in einem pharmazeutischen Produktionsbetrieb getrieben. Nach einem Verkauf des Unternehmens habe ich die vermeintliche Sicherheit im Konzern gegen die Selbstständigkeit getauscht. Seit 2005 sind wir nun erfolgreich am Markt, mittlerweile mit annähernd 50 Mitarbeitern.

Wolfgang Enking: Bevor ich bei Sven und seiner Sven Mahn IT GmbH & Co. KG anfing, hatte ich vier Jahre lang die Verantwortung für die Microsoft Dynamics AX Consulting-Organisation in EMEA. Dies war eine der interessantesten Aufgaben in meiner 20-jährigen Laufbahn bei Microsoft. Ich war bei Microsoft im Consulting und Service tätig und hatte dort die unterschiedlichsten Leitungsaufgaben. Vorher habe ich bei verschiedenen Unternehmen im Umfeld der Bürokommunikation gearbeitet. Auch nach über 30 Jahren Berufserfahrung bin ich immer noch begeistert über die Möglichkeiten, die moderne IT für die Evolution, also die Weiterentwicklung, der Unternehmen bietet.

Hatten Sie in Ihren Projekten bereits Berührungspunkte zum Thema PLM?

Sven Mahn: Regelmäßig. Letztendlich ist eine PLM-Software die Vorstufe des ERP-Systems. Eine enge Verzahnung der Prozesse ist nicht auszuschließen. Da wir keinen Branchenfokus haben, sind wir bereits in allen Arten der Produktion unterwegs gewesen, mit unterschiedlichstem Grad an Professionalität des PLM. Am spannendsten ist eine ERP-Implementierung immer dann, wenn PLM-Prozesse weder softwaregestützt noch dokumentiert sind, sprich die Kopfmonopole der Unternehmen, deren Rezepturen, Stücklisten oder Produktionsprozesse inklusive Attributverwaltung auf einzelne Mitarbeiter abzielen und von diesen abhängig sind.

ERP und PLM sind in vielen Fertigungsunternehmen zwei Seiten der gleichen Medaille. Die Einführung eines Softwarewerkzeugs dieser Art ist immer eine besondere Herausforderung. Wo sehen Sie aus Ihrer Erfahrung heraus die größten Stolpersteine, ein Softwarewerkzeug dieser Tragweite in einem Unternehmen einzuführen?

Sven Mahn: In erster Linie sind es die Menschen, die sich selbst Stolpersteine in den Weg legen. Setzt man voraus, dass jeder Mitarbeiter auch am Erfolg und Erhalt seines Arbeitsplatzes interessiert ist, können diese Typen von Software dazu dienen, Arbeitsplätze zu vernichten. So die Wahrnehmung im ersten Schritt. Die Kommunikation des Ziels und der Ausrichtung des Unternehmens mit der neuen Software und den damit verbundenen Visionen ist unerlässlich. Hier wird häufig – wie man das heute so schön formuliert – nicht jeder gleich gut abgeholt. Nun gibt es in Unternehmen auch die bereits erwähnten Kopfmonopolisten, die sich eigentlich nicht um das Wohlergehen des Unternehmens, sondern den Erhalt der eigenen Spezies durch Wissensmonopole sorgen. Hier zeigt die Implementierung sehr schnell Grenzen auf bzw. bringt eine eventuell nicht auf Gegenliebe stoßende Transparenz in die Unternehmensabläufe. Dass mit dieser geschaffenen Standardisierung die Energie und das vermeintlich freiwerdende Kapital in Forschung und Entwicklung gesteckt werden können, erschließt sich nicht jedem, bzw. wird so auch selten kommuniziert. In der Implementierung selbst ist die Frage nach Qualitätssicherung eine der wesentlichen. Wie verifiziere ich, dass das angestrebte System und die abgebildeten Prozesse meinen Vorstellungen entsprechen und die Umsetzung durch den Implementierter auch verstanden wurde? Die Vorgabe von festen Implementierungszeitpunkten durch die Geschäftsführung erinnert mich immer an die Diskussionen mit meinen Töchtern, die doch bis zu einem bestimmten Zeitpunkt in der Woche ihr Zimmer aufgeräumt haben sollten. Schon 10- und 13-Jährige wissen, dass es darauf ankommt, zu definieren, was „aufgeräumt“ bedeutet. Bevor das nicht klar ist, wird kein

ERP-Experte Wolgang Enking

Wolfgang Enking

Termin gehalten werden. Zu guter Letzt ist die schiere Komplexität der Systemlandschaften und deren Ablösung durch ein oder zwei Systeme eine Herausforderung für sich. Hier gilt es aus unserer Sicht, bereits in der Implementierung besonderen Wert auf Transparenz und Qualität zu setzen.

Wolfgang Enking: Man sagt: „Qualität ist das Produkt aus Nutzen x Akzeptanz“. Bei den Projekten unserer Kunden orientieren wir uns gerne daran, denn es bringt die wesentlichen Erfolgsfaktoren eines Projektes in eine simple Formel. Wenn ein neues Softwarewerkzeug auch viel Nutzen für ein Unternehmen erzeugen kann, so ist die Akzeptanz der Anwender am Ende doch ein entscheidender Faktor für den Gesamterfolg.

In den letzten Jahren werden verstärkt agile Projektmanagementmethoden wie Scrum für PLM- und ERP-Einführungen benutzt. Wie sind Ihre Erfahrungen mit Methoden dieser Art? Ist das ein Lösungsansatz, um diese Stolpersteine zu vermeiden?

Sven Mahn: Werden sie? Wirklich? Oder bezeichnet man „Versuch und Irrtum“ als agil? Letzteres ist leider häufig der Fall. Als Feuerwehrmann kann ich nur sagen, eine enge Führung und Struktur sowie absolute Transparenz und Offenheit schützen nicht vor Fehlern oder ungeplanten Ereignissen, aber sie lassen einen auf diese kurzfristig reagieren und Entscheidungen fundiert führen. Es kommt für mich stark auf das Team und die Unternehmensphilosophie an, ob ein Projekt nach SCRUM oder anderen agilen Methoden durchgeführt werden kann. Gibt es einen hohen Grad an Disziplin und wird dem Team oder den Teams eine Selbstverwaltung zugetraut? Dann ist Agilität sicher ein Gewinn, da man so zumindest zu den Sprint-Results klar weiß, welche Funktionen vorhanden sein sollten, inklusive definierten erfolgreichen Unit-Test. Bei Wasserfallmethoden ist die lange Zeit des Wartens hinderlich, wird das Projekt nicht selten von äußeren Aktivitäten und Ereignissen ein- meistens gar überholt. Das macht teure Nacharbeiten oder das Justieren der Prozesse notwendig. Eine Dokumentationsflut kann zudem die Komplexität ins Unermessliche ausufern lassen und führt am Ende zu Frust und einem forcierten Go-Live, der dann eventuell weder dem Qualitätsanspruch genügt noch die ursprünglich angedachte und geforderte Funktionsumfänge bereitstellt.

Wolfgang Enking: In ERP-Projekten wird noch häufig mit dem Wasserfallmodell gearbeitet. Eine der Ursachen liegt sicher in der Ausstrahlung, die ein ERP-System auf so viele Prozesse in einem Unternehmen hat. Es ist schwierig, eine ERP-Umstellung „agil“ zu gestalten, gerade wenn es um die Schnittstellen und Verzahnung von verschiedenen Systemen in das neue ERP-System geht. Dennoch haben wir bereits bei einigen Kunden die agile Methode erfolgreich zum Einsatz gebracht und wir sehen darin eine attraktive Vorgehensweise, gerade wenn es um die Cloud-Technologien geht.

Da ERP- und PLM-Systeme das „offene Herz“ eines Fertigungsunternehmens sind, kommt der Qualitätssicherung bei der Tooleinführung eine große Rolle zu. Können Sie hier ein wenig aus dem Nähkästchen plaudern, wie sie in Ihren Projekten mit dieser Herausforderung umgehen?

Sven Mahn: Qualitätssicherung fängt bei der Auswahl des Systems in Kombination mit dem Anbieter/Implementierungspartner an und hört bei der Abnahme und dem Feiern des erfolgreichen Go-Lives auf. Als Anbieter für Dynamics AX und bekennender Qualitätssicherer stehen wir für offene und transparente Kommunikation und Dokumentation. Egal ob agil oder nach Phasenmodell, sobald ich die Anforderung kenne, können Testfälle erstellt oder die Akzeptanzkriterien definiert werden. Das fordern wir in unseren Projekten auch vom Kunden ein. Dies ist ein eklatanter Vorteil für die Arbeit der Entwickler, die bei identifizierten Gaps nicht nur gegen die Definition entwickeln, sondern auch unter Zuhilfenahme der Testfälle eine höhere Qualität ausliefern können – zumindest meistens. Menschen spielen immer eine intensive Rolle dabei, der eine mag genauer sein, der andere ist dafür innovativer und hat gute Ideen. Beide Typen in einem Projekt die richtige Qualität liefern zu lassen, ist die große Kunst. Dies versuchen wir bei der Rollenvergabe in Projekten zu beachten.

Wolfgang Enking: Nichts ist so teuer wie ein Fehler, der erst nach dem Go-Live entdeckt wird, denn dann hat der Schaden oft schon „Wellen geschlagen“. Leider wird dem Testen der Software noch immer eine zu geringe Wertigkeit eingeräumt. Dies führt dann zu sehr kurzen Zeiträumen für das Testen und oft zu sogenannten „Shortcuts“, in denen gewisse Funktionen erst gar nicht getestet werden. Wir thematisieren die Qualität bereits bei Beginn eines Engagements und gehen mit einer Methode vor, in der die Standardprozesse von Dynamics AX als Testfälle bereits im Design einer Lösung einfließen. Unterschiede zu kundenspezifischen Anforderungen werden so frühzeitig erkennbar. Der Fokus auf die Nutzung von Standardprozessen wird verstärkt und manchmal führt das dann zu einer guten Diskussion, ob ein Unternehmen damit nicht besser fährt als mit den gewohnten Prozessen.

ERP- und PLM-Systeme selber unterliegen ja auch einem Lebenszyklus. Neue Major Releases vom Softwarevendor oder Erweiterungen des Funktionsumfangs verlangen vor dem Einspielen in das Produktivsystem beim Kunden ebenfalls nach Qualitätssicherung. Welche Strategien und Methoden wenden Sie hier an?

Sven Mahn: Allerdings, die Zeiträume zwischen den Major Releases werden auch noch immer kürzer. In der Regel zieht hier die Dokumentationskarte. Je besser wir im Projekt dokumentiert haben, desto einfacher ist ein Releasemanagement. Letztendlich sind doch die Themen „Prozesse“, „Datenstand“ und „Softwarereleases“ in Kombination mit den Ständen der Testfälle ein zusammenhängender Komplex, der aus den Projekten heraus häufig zum Erliegen kommt. Dabei sind Implementierungsprojekte die Keimzelle definierter Prozesse für die Einhaltung eines Releasemanagements und der Dokumentation von Abweichungen, die durch eigene erforderliche Anpassungen entstanden sind. Die Verzahnung der Daten-, Software-, Testfall- und Konfigurationsreleases ist ein guter Lösungsansatz, um kontinuierliche Integration und Updatezyklen in kleineren Etappen durchzuführen. Je länger ein Update auf sich warten lässt und je weniger Dokumentation in den besagten Objekten vorliegt, desto grausamer wird ein Release. Eine Besonderheit sind hier die von den Unabhängigen Softwarelieferanten (ISV) angebotenen horizontalen und vertikalen Lösungen. Je nach Integrationsgrad und Alter der originären Lösung sollte eine genaue Begutachtung erfolgen. Nicht jeder ISV ist in der Lage, seine Branchenlösung kontinuierlich an die neuen Updates des Herstellers anzupassen; manche sind zwar in der aktuellsten Version verfügbar, weisen aber eine ungeeignete, weil veraltete Architektur aus. Man hat schlichtweg nicht die Zeit, die eigene Lösung an die neuen Funktionen und Architekturen komplett anzupassen, macht es manchmal auch den Nutzen der Branchenlösung selbst zunichte.

Wolfgang Enking: Die heutige Dynamik in der IT ist der wesentliche Grund für den schnellen technologischen Fortschritt. Insbesondere Cloud-Technologien bieten viele neue Möglichkeiten. Die Unternehmen werden damit vor enorme Herausforderungen gestellt, denn einerseits will man den Zug ja nicht verpassen, aber Schritt zu halten mit der Flut von Neuerungen ist extrem schwierig. Wie Sven schon sagte: Die akkurate Dokumentation der Prozesse und der damit verbundenen Daten ist der Schlüssel zum Erfolg. Je besser die Systemlandkarte, desto einfacher gelingt es, neue Technologien und Erweiterungen zu nutzen oder auszusperren.

Blicken wir zum Abschluss noch einmal in die Zukunft. Wie geht es für PLM-/ERP-Systeme weiter?

Wolfgang Enking: Wir erwarten eine zunehmende Akzeptanz von Cloud-Systemen auch in Deutschland. Damit sind viele neue Möglichkeiten verbunden, Prozesse im Unternehmen neu zu gestalten und zu vereinfachen. Wir werden uns immer mehr damit befassen, zu überlegen, welche Prozesse durch Systeme, Assistenten oder Roboter umgesetzt werden sollte und welche Aufgaben und Entscheidungen durch die Mitarbeiter verantwortet werden sollten. PLM- und ERP-Systeme spielen hier eine zentrale und wesentliche Rolle. Wir sind bereit, die Brücke in die Zukunft gemeinsam mit unseren Kunden zu bauen. Es bleibt spannend, was wir in diesem Umfeld in den kommenden Jahren erleben werden …

Vielen Dank an Sie beide für dieses informative Gespräch. Ich wünsche Ihnen noch viel Erfolg und gutes Gelingen in Ihren Projekten.