The Future of PLM, ERP, CRM and PLM
In Diskussionen über die Zukunft von PLM, ERP etc. höre ich meist zwei Argumentationsstränge:
1️⃣ Bisherige Systemklassen (ERP…) sind durch kommende Microservices-Architekturen am Ende.
2️⃣ Bisherige Systemklassen werden in Zukunft zu einer Plattform verschmelzen.
Was verbirgt sich eigentlich hinter den dreibuchstabigen Abkürzungen ERP, PLM usw.?
Ich nenne diese Kategorie Systemklassen. Bisher wurden sie verwendet, um käufliche IT-Systeme nach der Art der von ihnen realisierten Geschäftsfunktionen zu gruppieren.
Sie kristallisierten sich aus einem spezifischen Geschäftsproblem heraus und wurden dann funktional erweitert. Heute gibt es eine teilweise Überschneidung und damit auch einen Kampf um die Vorherrschaft der Systeme in den Unternehmen.
Was bringt die Zukunft?
1️⃣ Die bisherigen Systemklassen sind heute schwerfällige On-Prem-Systemmonolithen, die sich kaum noch verändern lassen. Sie in ein gemeinsames Szenario zu integrieren, ist zeitaufwändig. Für native Cloud-Anwendungen hat sich die Idee der Microservice-Architekturen bzw. die davon abgeleitete Idee der Composable Architectures durchgesetzt. Ziel ist es, Dienste nach Bedarf kombinierbar zu machen. Wenn die bestehenden Systemklassen in Zukunft auf eine native Cloud-Architektur umsteigen, ist es sinnvoll, diese Paradigmen auch von ihnen zu fordern.
2️⃣ Bedeutet dies in Zukunft das Ende der Systemklassen? Die in den Systemklassen enthaltenen Fähigkeiten werden weiter bestehen. Sie werden sich aber von den bisherigen Klammern der Systemklassen lösen. Daher ist das Argument, dass die Systemklassen am Ende sind, aus dieser Perspektive gültig.
Nun zur praktischen Realität.
Ein Microservice bringt seine Informationen mit sich. Das ist der Schlüssel zum Verständnis!
Die IT-Systemklassen beruhen auf komplexen Informationsmodellen für das jeweilige Geschäftsproblem. Sie können nicht willkürlich geschnitten werden, da Informationsmodelle immer ihre semantische Konsistenz behalten müssen, um das Geschäftsproblem zu lösen. Beliebige Schnitte sind zum Scheitern verurteilt. Die Modelle müssen also sauber gefiltert werden.
Das Spannende daran ist, dass die Systemklassen gute Schnittlinien für die Filetierung bilden.
Deshalb verwende ich sie immer noch gerne 😊.
Mehr dazu in einem Folgebeitrag. Oder kontaktieren Sie uns von STZ-RIM Reshape Information Management (👉 https://lnkd.in/eei3UYdm)
Was meint ihr dazu?
Ich freue mich auf Ihre Kommentare. 🤔💬
Future PLM – Was ist der zukünftige PLM-Bereich? 🚀
Ich glaube, der PLM-Markt wird sich grundlegend verändern. Wir werden neue Player sehen, und unerwartete Akteure werden mehr in den Fokus rücken. 🧐
Um das auf den Punkt zu bringen, nutze ich gerne zwei Dimensionen. ✅
Dimension 1: PLM-IT-Architektur 🌐
Cloud und Composable Architectures sind in aller Munde. Nun, wenn man genau auf die Cloud-Angebote vieler PLM-Anbieter schaut, dann haben wir dort etwas, was man als „containerisierte Cloud“ bezeichnen könnte. Das bedeutet, dass die bisherige Code-Linie unverändert in einen Cloud-Container gepackt wird und das als Cloud-Angebot präsentiert wird.
Das ist natürlich weit entfernt von einer Cloud-nativen Applikation, die dann ggf. auch composable, also leicht mit anderen Cloud-Diensten integrierbar, ist.
Hier kommt die Dimension 2 ins Spiel. 🔍
Dimension 2: PLM-Layer 🛠️
Ich unterscheide gerne in verschiedene PLM-Layer und nutze als Layer 1 gerne TDM. Manchmal wird mir in Diskussionen entgegengebracht, dass diese Aufteilung in den 90er Jahren notwendig war, heute aber veraltet ist. Als Argumentation wird dann gerne auf Microservices verwiesen.
Nun, diese Aufteilung hat letztendlich einen methodischen Hintergrund. Eine der Kernideen der Microservices ist es, dass sie ihre Daten mitbringen. PLM-Prozesse beruhen auf dem Lifecycle von Daten. Wenn man diese also in Services aufteilen will, dann braucht man natürliche Schnittstellen. Diese Schnittlinien gehen m.E. entlang der PLM-Layer.
- Layer 1 – Team Data Management (TDM) Layer
Subsumiert das Datenmanagement von applikativen Daten. Diese werden sich von bisherigen File-basierten Systemen in Cloud-Native Services wandeln. An der Schnittstelle zu Layer 2 wird als Übergabeinformation ein zeitrichtiges (z.B. geometrisches) Dokument für eine oder mehrere Entitäten des Produkts weitergegeben. - Layer 2 – Multistructure PLM-Layer
Hat die Aufgabe, die Reifeentwicklung der produktrelevanten physischen Entitäten über eine Reihe von Strukturen (Anforderungsstruktur, System-/Funktionsstruktur, Bauraumstruktur, EBOM …) zu managen. Dabei werden die Dokumentationen aus Layer 1 zeitrichtig den Entitäten zugeordnet. Übergabe an Layer 3 ist eine vollständige Definition realisierter Produktentitäten aus Perspektive von R&D. - Layer 3 – ERP-naher PLM-Layer
Die Realisierungen der Ebene zwei müssen nun im Werksverbund industrialisiert werden. Dabei entstehen die implementierten Materialnummern und zusätzliche Dispositionsstufen.
Die drei genannten Layer für die Dimension 2 können zukünftig in unterschiedlichen Services getrennt werden und im Sinne von Packaged Business Capabilities gehandhabt werden.
Im Bild habe ich für euch mal einen PLM Space aus diesen Dimensionen aufgezeichnet. 📊
Wie es aus meiner Perspektive die heutigen PLM-Player einzuordnen sind, folgt im nächsten Post. Stellt eure Fragen oder Anmerkungen gerne in die Kommentare. Ich freue mich auf die Diskussion. 💬👀
Das Oligopol der großen 3 CAx-Anbieter im PLM wird enden 🛑 📆
Wir werden einen Aufstieg neuer und unerwarteter PLM-Anbieter erleben 🚀.
Here ist warum 📝.
👉Wie wir denken, ist es: Today Common View 🧐.
- PLM-IT-Architektur (Dimension 2).
Die großen PLM-Anbieter bieten heute On-Premise- und Cloud-Lösungen an ☁️. Wenn Sie sich die Cloud-Angebote genauer ansehen, haben wir etwas, das man als „containerisierte Cloud“ bezeichnen könnte. Das bedeutet, dass die bestehende Codezeile unverändert in einen Cloud-Container gepackt und als Cloud-Service angeboten wird. Dies ist weit entfernt von einer Cloud-nativen Lösung. - PLM-Schichten (Dimension 1)
Ich unterscheide zwischen der Schicht 1, in der sich die Engineering-Anwendungen (CAx-Apps) befinden, der Team Data Management (TDM)-Schicht 🌀, der Schicht 2, der Multistruktur-PLM-Schicht und der Schicht 3, der ERP-nahen PLM-Schicht, in der wir die M(RP)-BOM-Snippets (Youtubefilm) verwalten werden 🎬.
In der heutigen Common View gehen viele davon aus, dass die aktuellen PLM-Systeme der Big 3 CAx-Anbieter problemlos auf den Layer 3, den ERP-nahen PLM-Layer, ausgedehnt werden können und somit die ERP-Systeme hauptsächlich zu Durchlauferhitzern werden 🌡️.
👉 Wie es sein wird: Der Blick in die Zukunft 🔮.
- PLM IT-Architektur (Dimension 2).
Ich bin überzeugt, dass wir echte Cloud-Native-Angebote und während des Übergangs hybride Szenarien (d.h. Cloud gemischt mit Containerd Cloud) sehen werden ⚙️. - PLM-Schichten (Dimension 1)
Heute werden CAD-Systeme zu 3D-Plattformen mit einer Vielzahl von Automatisierungsmöglichkeiten erweitert ⚡️. Die neuen Möglichkeiten werden die großen Drei dazu zwingen, ihre CAD-Systeme viel tiefer in ihre klassischen PDM/PLM-Lösungen zu integrieren 🔄. Damit werden die PDM-Datenmodelle, deren Kern aus den 80er Jahren stammt, abgelöst 🕰️. Gleichzeitig wird es schwieriger werden, mit diesen Datenmodellen die Multi-Struktur-Schicht zu besetzen 🧩. Außerdem kristallisiert sich in Layer 3 die #erp nahe PLM-Schicht deutlich heraus ⭐️. Es ist bereits ersichtlich, dass die Schicht 3 mit den vorhandenen #PDM-Datenmodellen 🚧 sehr schwer zu besetzen ist!
👉 Fazit
Dies bedeutet, dass die drei großen PLM-Unternehmen vor mehreren Herausforderungen stehen 🌪️.
Sollten sie ihre PLM-Systeme cloud-nativ neu entwickeln?
Sollten sie nicht lieber CAx als cloud-native Lösung entwickeln?
Sind sie in der Lage, die dringend benötigten neuen Datenmodelle für Layer 2 und Layer 3 zu definieren?
Dies sind sehr komplexe Fragen, die beantwortet werden müssen 🤔.
Gleichzeitig sehen wir, dass bestehende Akteure und auch ganz neue Akteure, befreit vom CAx-Erbe, munter die PLM-Layer 2 und 3 🌟 in den verschiedenen Architekturen besetzen.
Ich denke, dass SAP und CONTACT Software das Potential haben, an der Spitze zu stehen 🥇. Aber auch bisherige Nischenanbieter wie z.B. Propel Software oder Oleg Shilovitsky mit seinem OpenBOM werden sicherlich ihre Rolle spielen und andere, die ich jetzt nicht genannt habe 🎭 (ihr könnt sie gerne in den Kommentaren nennen).
Sie sehen, die Zukunft wird super spannend 😃.
Natürlich sollten wir die großen 3 nicht abschreiben!
Sie sind stark, sie haben Top-Teams und natürlich die Fähigkeit, sich in die Zukunft zu entwickeln 🌱.
Interessant wäre, welchen Weg sie wählen.
Harter Tobak! 💪
Was meint ihr dazu? 📢💬
