Eine Antwort auf die Thesen von Jörg W. Fischer
Prof. Jörg W. Fischer hat sich intensiv mit der gegenwärtigen Entwicklung der Automatisierung beschäftigt und in zwei aufeinander aufbauenden Artikeln sehr wertvolle Thesen formuliert, welche Auswirkungen diese Entwicklung auf die großen Standard-IT Systeme hat, mit denen die Industrie ihre Prozesse steuert und organisiert.
Das ist ein wirklich großes Thema. Kein Wunder, dass es – aus meiner Sicht – nicht auf Anhieb gelingt, alle Aspekte in vollem Umfang zufriedenstellend zu erfassen. Jörg W. Fischer gelingt es auch nicht, auf diesem großen Feld eine Prophezeiung zu machen, der ich mich ohne zu zögern anschließen kann. Ich versuche, seine Thesen zusammenzufassen. Und entwickle gleichzeitig eine Kritik an der von ihm entworfenen Perspektive.
Prof. Jörg W. Fischer ist, nach fünfeinhalb Jahren als Lead Principal PLM Architect bei Siemens Digital Industries Software, seit 2013 Professor an der Karlsruhe University of Applied Sciences, wo er an der Fakultät für Mechanical Engineering & Mechatronics die Themen Produktionsmanagement, Digitalisierung und PLM im Visier hat.
These 1:
PLM statt ERP an der Spitze der
Automatisierungspyramide
Die erste These lautet in meinen Worten: Die seit mehr als 30 Jahren relativ stabile Führungsposition von ERP in der IT der Fertigungsindustrie beginnt zu bröckeln. Dies könnte dazu führen, dass PLM stattdessen an die Spitze der Automatisierungspyramide rückt.
Das geschieht laut Fischer nicht etwa, weil ERP-Software ihre Aufgabe nicht mehr erfüllt. Vielmehr wird die Industrie seit einigen Jahren von ihrer Kundschaft getrieben, zunehmend individuelle Produkte zum Preis und im Tempo der Serienfertigung zu liefern, bekannt als Thema „Losgröße 1“.
Genau das erfordert andere Prozesse als bisher. Und diese Prozesse brauchen andere Daten, als sie das ERP mit seinem Datenmodell liefern kann.
Gleichzeitig wird die Industrie wie die gesamte Wirtschaft grundsätzlich in ungekanntem Ausmaß geschüttelt. „Die jüngsten Technologiesprünge und globalen Krisen haben ein Potenzial für multidimensionale Disruption geschaffen, das in der Form vermutlich noch nie vorhanden war. Dadurch entsteht für Unternehmen die Notwendigkeit, sich in allen Bereichen zu hinterfragen, Agilität in ihren Prozessen zu verankern, schnell und effektiv auf sich ändernde Kundenwünsche reagieren zu können und sich darüber hinaus mit datenbasierten Geschäftsmodellen auseinanderzusetzen.“ (Jörg W. Fischer, „ERP, PLM, MES und CRM – eine neue Perspektive – ein neues Universum – Teil 1“, April 2023)
Spürbare Auswirkungen hat diese Entwicklung auf die Rolle von ERP, von dem sich über Jahrzehnte der Eindruck halten konnte, dass fast alle Unternehmensfunktionen darüber zu steuern seien. Vor allem die Produktion als wichtigster Kostenblock in der Industrie schien optimal zu laufen, wenn die Stückliste aus dem ERP kam und für Auftragsabwicklung und damit zusammenhängende Transaktionen genutzt werden konnte. Seit einigen Jahren trifft dies immer offensichtlicher nicht mehr zu.
Wenn erst während eines Auftrags endgültig zu entscheiden ist, welche Standardprodukte kundenspezifisch um welche Komponenten ergänzt oder verändert werden, dann muss sehr dynamisch auf Produktdaten in ihrem gesamten Lebenszyklus zugegriffen werden können. Eine nur schwer überschaubare Vielfalt von Varianten und Produktfamilien, wie man sie vor allem aus der Automobilindustrie kennt, werden in immer mehr Branchen zum Normalfall. Und damit müssen Unternehmen eine unmittelbar aus dem Engineering gefüllte 150%-Stückliste als Engineering Bill of Material (EBOM) haben, die im konkreten Auftrag zu einer 100%-Stückliste der Fertigung, zur Manufacturing Bill of Material (MBOM) werden kann.
ERP-Systeme sind damit grundsätzlich überfordert, weil es ihrem formalen, stabilen Datenmodell widerspricht, das davon ausgeht, dass Produktdaten nach dem Ende des Designprozesses unveränderlich sind. PLM-Systeme, die ja im Engineering entstanden und mit dem dynamischen Wachsen der Produktdaten vertraut sind, wurden nach Auffassung von Fischer dagegen bereits vielfach auf das Management von EBOM und MBOM eingestellt.
Fischers nachvollziehbare Schlussfolgerung: Im PLM entsteht eine EBOM, die im Auftragsfall in eine MBOM verwandelt werden kann. Der Produktentstehungsprozess basiert weder auf reiner Serie noch auf reiner Auftragsentwicklung. Das Produkt wird vielmehr weitgehend konfiguriert. Aus der Konfiguration bekommt die Fertigung ihre MBOM, mit der das ERP-System die Auftragsabwicklung starten kann. Configure to Order (CTO) wird zum gängigen Prozessmuster.
In der bisherigen Welt und der alten Automatisierungspyramide stand das Manufacturing Execution System (MES) zur Produktionssteuerung unter dem ERP. Künftig steht es, so Fischer, unterhalb von PLM und beliefert seinerseits das ERP mit der MBOM. Das ist in der Tat eine Perspektive, die so nach meiner Kenntnis noch niemand formuliert hat.
„Zusammenwirken von Informationsentstehung und -nutzung bei unterschiedlichen Prozessmustern“, Bild 3 in „ERP, PLM, MES und CRM – eine neue Perspektive – ein neues Universum – Teil 1“, Jörg W. Fischer, April 2023
These 2:
Neue Schicht „Digital Information Architecture“ oberhalb der Auftragsabwicklung
Mit der zweiten These begibt sich Fischer im zweiten Artikel auf das Feld der Vorhersage. Weil im Zuge der Digitalisierung immer mehr Produkte als Systeme unter Systemen entwickelt werden, stößt das traditionelle, aus der Mechanik kommende PLM häufig an seine Grenzen. Künftig, so Fischer, „ist die Entstehung und das Lebenszyklusmanagement (xLM) der Informationen von der Nutzung dieser in den Abwicklungssystemen getrennt. Die xLM-Schicht versorgt die Abwicklungssysteme mit den notwendigen, versions- und zeitrichtigen Stammdaten.“
xLM wird von ihm hier ungefähr so benutzt wie der Begriff SysLM, den ich 2012 geprägt habe: als Management der Daten aller Engineering-Fachdisziplinen über ihren Lebenszyklus.
Diese Management wird derzeit je nach Fachgebiet über ein PLM oder auch über ein Application Lifecycle Management (ALM) für Software oder über noch andere Systeme organisiert.
Fischer spricht von einer Schicht und nicht von einem System, denn: „Bei der neuen xLM Schicht wird es sich erwartungsgemäß nicht um ein klassisches monolithisches IT-System handeln. Vielmehr ist davon auszugehen, dass sich zur Implementierung dieser Schicht zukünftig unterschiedliche, verteilte, Microservice-basierte Lösungsansätze herausbilden werden.“ (Jörg W. Fischer, „ERP, PLM, MES und CRM – ein Blick in die Zukunft – Teil 2“, Juni 2023)
Fischer führt parallel noch einen weiteren Begriff ein, um auch alle nicht strukturierten Daten eines Unternehmens, die mit Produkt und Produktion zu tun haben, erfassen zu können. Die Schicht dieser Daten nennt er Industrial Data Science Layer (IDSL). Sie taucht nach seiner Definition derzeit auch auf als „Digital Core, Data Mesh, Data Lake, Knowledge Graph etc.“ Fischer schreibt: „Ihre Aufgabe ist es, die Plattform bzw. Komponenten bereitzustellen und ganz neue Zusammenhänge, Erkenntnisse und Werte aus den Datenschätzen von Unternehmen zu generieren.“ Und schließlich: „Konsequent weitergedacht entsteht eine neue intelligente Steuerungsschicht für Unternehmen.“ (Jörg W. Fischer, „ERP, PLM, MES und CRM – ein Blick in die Zukunft – Teil 2“, Juni 2023)
Richtige Analyse, aber strittige Prognosen
Fischer hat meiner Meinung nach richtig erkannt, dass der generelle Trend zu immer individuelleren Produkten – und damit zur Dominanz der Kundenanforderungen – in den Prozessen zu einem ebenso generellen Trend von Configure to Order führt, was die meisten ERP Systeme überfordert und zu einer neuerlichen Steigerung der Rolle von PLM führt.
Richtig scheint mir auch die Analyse, dass die historisch sehr auf die Mechanik ausgerichtete Funktonalität von PLM hier ebenfalls an Grenzen stößt. Um den Wert aller Daten von Produkt und Produktion schöpfen zu können, werden Funktionalitäten in Form von Microservice-basierten Lösungen hinzukommen müssen, denn die Integration aller Daten in die herkömmlichen PLM-Datenmodelle ist unrealistisch.
An zwei Stellen allerdings scheinen mir die Thesen in die Irre zu führen.
- In der Automatisierungspyramide ändert sich nicht einfach die Rangfolge der großen IT-Systeme. In der Smart Factory der Zukunft kann diese Pyramide die Realität gar nicht mehr abbilden.
- Ob man der heute meist noch fehlenden Schicht zur Datenerfassung und -auswertung einen eigenen Namen gibt, ist nicht wichtig. Sie entsteht in jedem Unternehmen sehr spezifisch als Microservice-basierte Lösung.
Zu Punkt 1:
Bereits als 2011 die Initiative Industrie 4.0 ins Leben gerufen und die Standardisierung einer Referenzarchitektur und schließlich der Verwaltungsschale in Angriff genommen wurde, war klar: Ein zentraler Aspekt dieser digitalen Transformation ist die Zerlegung der Automatisierungspyramide und die Dezentralisierung der Entscheidungen in den industriellen Prozessen. Und zwar so weit, dass letztlich Entscheidungen auf der Ebene einzelner Maschinen mehr oder weniger von diesen automatisch getroffen werden. Heute könnte man sagen, als Werkzeugkasten dafür haben sich über die Jahre Cloud-Technologie und standardisierte Container als Microservices erwiesen.
Die sich gerade ändernde Rolle von PLM- und ERP-Funktionalität spielt sich also nicht mehr innerhalb einer hierarchischen Pyramide ab, sondern in diesem agilen, sich schnell verändernden Umfeld von zunehmend zusammensetzbaren Softwarekomponenten, also Composable Software.
Es gibt übrigens neben dieser generellen Entwicklung auch noch eine andere Möglichkeit, die in Fischers Thesen gar nicht vorkommt. Bluestar PLM ist dafür ein interessantes Beispiel. Dieses System ist vollständig in das ERP von Microsoft Dynamics eingebettet. Und damit lässt sich exakt der von Fischer beschriebene CTO-Prozess abbilden, wie ich kürzlich bei einem Kunden lernen durfte.
Innerhalb von Bluestar PLM kann man eine 150%-EBOM in eine 100%-MBOM verwandeln, und erst dann gehen die Daten an das ERP, mit dem nun die weitere Abwicklung des Auftrags organisiert wird. Wobei hier PLM und CRM als Funktionen derselben Gesamtlösung erscheinen. Auch diese Embedded-Version kann also das benannte Problem lösen.
Zu Punkt 2:
Das Prägen eines neuen Begriffs für neue, intelligente IT-Schichten scheint mir unnötig. Schaut man sich aktuelle Smart Factories an, sind die althergebrachten Systeme ebenso wenig von Bedeutung wie solche Begrifflichkeiten.
Beispielsweise in der Vorzeigefabrik von Rittal für Kompaktschaltschränke in Haiger werden Daten aus der Produktentstehung und aus der Produktionsplanung und -steuerung mit Daten von Sensoren aus der Produktion und sogar aus der Energieversorgung verknüpft. Im Endergebnis ist auf den großen Dashboards in der Fertigungshalle für jedermann in Nahe-Echtzeit zu sehen, welche Roboterlinie gerade wie gut produziert und wo unter Umständen die Instandhaltung gefragt ist. Auch das konnte ich kürzlich in der Praxis sehen.
Von einer neuen Schicht in Sachen PLM und ERP ist dort nicht die Rede. Im Mittelpunkt steht das Microservice-basierte, Cloud-native Produktionssystem ONCITE Digital Production System vom Schwesterunternehmen German Edge Cloud, das mit allen benötigten Daten versorgt wird. Es wäre spannend, von Rittal beziehungsweise German Edge Cloud zu hören, wie sie diese neuartige Lösung hinsichtlich ERP, PLM und MES einordnen.
Mein Fazit:
Ja, die Individualisierung der Produkte und zahlreiche weitere Herausforderungen verändern die Art und Weise, wie die Industrie insbesondere die Automatisierung plant und steuert. Herkömmliches ERP, MES und PLM geraten an ihre Grenzen und ändern ihre Beziehung zueinander.
Aber eine neue, für alle Industrien funktionierende Datenverarbeitungsschicht ist eher unwahrscheinlich. Es zeichnet sich ab, dass Unternehmen künftig mit alter wie neuer Software, vermutlich überwiegend Microservice-basiert, mit vielen einzelnen Lösungen die unzähligen Use-Cases in Angriff nehmen, die sich auftun.
Die Links zu den beiden Artikeln von Prof. Jörg W. Fischer auf Deutsch:
ERP, PLM, MES und CRM – eine neue Perspektive – ein neues Universum – Teil 1
Ich stimme voll und ganz zu: „…denn die Integration aller Daten in die herkömmlichen PLM-Datenmodelle ist unrealistisch“.
Meiner Meinung nach sind neue Methoden und Strukturen für die Anwender notwendig.
Punkt 1: Modellierung (Model Based Engineering)
Das V-Diagramm zeigt den Automotive-Prozess:
Das spezifische daran ist die Fertigung erst nach dem Systemtest. Es gibt keinen Einfluss aus dem Kundenauftrag auf die Entwurfsphase, Entwicklungsphase und Konstruktionsphase. Die Varianz aus dem Kundenauftrag entsteht ohne Beteiligung der Konstruktion. Deshalb ist eine Verknüpfung von PLM und MES im Bereich Automotive vernünftig.
Im Maschinen- und Anlagenbau definiert der Kunde das Produkt während des Kundenauftrags sowohl in der Konstruktions- als auch in der Produktionsphase. Daher ist es nützlich den Auftragsprozess mit der Modellierung (SysML) der Funktionen einer Anlage und der Einheiten (Funktionen) zu beginnen ( ohne Materialstämme). Aus dem Modell und in Kombination mit einer Maximalstückliste werden kunden- und werksspezifische eBom und mBom entwickelt. Dazu sind PLM System ungeeignet. Deshalb ist im Maschinen und Anlagen bau eine Verknüpfung von ERP und MES vernünftig. Produktionsbedarfe könne täglich neu terminiert werden.
Punkt 2: Konfigurieren (SVC)
Produktvarianten sollten in einer Solver-basierten Auftragskonfiguration entlang des Kundenauftrags konfiguriert werden. Moderne Systeme ermöglichen diese Konfigurationen über alle Produktebenen sowohl material(teile)stammlos als auch mit Materialstämmen. Die gleiche Konfiguration kann eBom, mBom (standortspezifisch), Service-Bom und andere entwickeln.
Punkt 3: Informationsnetz (EKG)
Für die Verbindung von unstrukturierten Daten und Informationen sind EKG Enterprise Knowledge Graphen nützlich. Sie sind in der Lage, Vertriebsinformationen, Engineering und Serviceinformationen aufgabenspezifisch zu verbinden. Sie ersetzen meiner Meinung nach keine Variantenkonfiguration, verknüpfen aber Systeme und Informationen über der Ebene der Schnittstellen und nicht in ihnen. EKG können ohne Programmierung aufgebaut und angepasst werden.
Meiner Meinung nach die Verknüpfung von Information aus der Schnittstellenebene in die App Ebene verlagert, kombiniert mit einer Struktur und Methodenunterstützung. Funktionen modellieren (MBSE), Produkte strukturieren PSM), Varianten konfigurieren (SVC) und Informationen Vernetzen (EKG) sind die Basis für eine umfassende weitere Digitalisierung von Verknüpfungswissen und damit die Basis des digital Thread und der Aufbereitung durch KI.
Punkt 4: Produktstrukturmanagement ( PSM):
Der zukünftige Nutzen liegt in der Reduzierung der informationellen Rüstzeiten in den Phasenübergängen des Produktlebenszyklus . Der Aufwand um Strukturen des konstruierten technischen Prozesses (Entwicklungsphase der Typen) den Strukturen des Geschäftsprozesses (Herstellungsphase der Instanzen) anzupassen und mit den Daten des Betriebsprozesses (Betrieb der Maschinen und Anlagen) zu kombinieren stellt das zukünftige Einsparpotential dar. Methodisch ist das mit einem automatisierten Produktstrukturmanagement zu unterstützen.
Methodenebene: MBSE – SVC – PSM – EKG