LinkedIn-Post 1
Enterprise Architecture Methods funktionieren bei PLM & ERP nicht!
Es fühlt sich an wie Ketzerei – entschuldigt, ich muss es trotzdem sagen!
Warum? Hier meine Antwort.
Habt ihr euch schon mal teure Strategie- oder Methodenberater eingekauft, die mit fancy Namen wie Enterprise Architecture, TOGAF, ArchiMate herumgeworfen haben? Habt ihr mit ihnen Diagramme, insbesondere riesige Capability Maps, gezeichnet? 🎨📊
Waren sie vielleicht auch noch Methodendogmatiker (das sind die schlimmsten 😉) und haben keine Abweichungen, keine anderen Methoden zugelassen? 😤
Nun, die Ausgaben könnt ihr euch sparen.
Für PLM und auch für große Teile von ERP haben die EA-Methoden riesige blinde Flecken! 🚫👀
Das heißt nicht, dass die Methodik und die Denkweise dahinter nicht hilfreich wären.
Es ist nur so: Wenn ihr alles mühevoll modelliert habt, versteht ihr dennoch euren PLM-Fall nicht und könnt darüber hinaus die Inhalte eurer Projekte nicht hinreichend abgrenzen.
Es wird demnach sehr wahrscheinlich dasselbe Chaos eintreten, das in der Mehrzahl der PLM-Projekte herrscht. ⚠️🔥
Ich empfehle daher, den Einsatz von EA aufs Nötigste zu beschränken. ✅
Nun, warum sehe ich das so? 🤔
Wenn wir über PLM und ERP sprechen, geht es im Kern darum, das Informationsgerippe eines Unternehmens zu explizieren und sauber in am Markt vorhandene IT-Systeme abzubilden. Dabei ist es notwendig, die Geschäftsobjekte (Part, Dokument, Design, Material …), deren Zeitverhalten und die Semantik ihrer Verdichtung in unterschiedlichen Strukturtypen (EBOM, MBOM, TOS, Classification Trees …) zu explizieren. 🏗️📚
Das ist der Kern der ersten Diskussion! Danach kann man Use Cases, User Stories, Epics (you name it) zuordnen und Capability Maps in aller Schönheit aufzeichnen. 🎯📝
Nun, die meisten EA-Methoden verzichten gänzlich darauf, die Semantik der Informationen zu modellieren!
Viele von euch werden vermutlich entgegnen, dass Datenmodellierung und Datenmodelle in EA-Modellen vorhanden sind. 📊💡
Das stimmt zwar, das Problem ist jedoch, dass diese darauf ausgelegt sind, eine Implementierung eines völlig neuen Datenmodells vorzubereiten und eben nicht darauf, vorhandene Informationsstrukturen aus deren Bedeutungssicht zu durchdringen. 🧩🔍
Was meint ihr dazu?
Nun bin ich sehr gespannt auf die Diskussion und eure Ansichten dazu. 💬🤓
Und übrigens mit unserem RIM Company Cubing haben wir eine Methode entwickelt, die blinde Flecken bei PLM und ERP Einführungen vermeidet. 🌟🔧
LinkedIn-Post 2
What are typical Enterprise Architecture blind spots for PLM?
And how can we plan and implement PLM Blind Spot Free? 🤔
Ich habe mich sehr gefreut, dass mein letzter Post zum Thema eine tolle Diskussion hervorgebracht hat. 🎉
Heute möchte ich ein paar weitere Aspekte zum Thema aus meiner Perspektive erläutern. 🤓
In Beratungssituationen bei Kunden werden wir oft gerufen nach dem diese versucht haben, PLM aus der EA-Perspektive aufzuschlüsseln. Die Vorgehensweise ist typischerweise folgende:
1️⃣ Capability Maps wurden erstellt,
2️⃣ dann Prozesse aufgenommen und
3️⃣ später mit den Vendoren deren Vendor Capability Domains diskutiert.
Warum funktioniert das nicht gut? Hier einige Gründe: 👇
🌟 Capability
Was ist eine Capability? Das Problem von Capabilities ist ihre Mehrdimensionalität. Sie enthalten Prozess- oder Use Case-Schnipsel und haben dazu implizit auch noch einen Wert im Sinne von „können wir/können wir nicht“ im Bauch. Sie eignen sich um den Mehrwert einer PLM-Strategie zu erläutern, jedoch nicht um ein PLM-Projekt oder die PLM-Strategie für die interne Diskussion abzugrenzen.
🔄 Prozess
PLM ist geprägt von Informationsstrukturen und deren Semantik! Prozess sind im PLM nachrangig! PLM-Projekte prozessfokussiert anzugehen, erzeugt hohen Overhead und bläht Projekte schon früh unnötig auf. 💡
🏷️ Vendor Capability Domains
Die Vendoren gliedern ihre PLM-Systeme nach funktionalen Einheiten. Der Schnitt der Cluster fokussiert auf Cash Flow Steigerung. Die Cluster lassen sich daher oft nicht gut auf abgrenzbare und implementierbare Problemstellungen aus Kundenperspektive anwenden. 💸
Wir vom RIM sind davon überzeugt, dass die Abfolge der zu bearbeitenden Themen wie folgt sein sollte! Das haben wir auch in unserer RIM Company Cubing Methode verankert. 📦
Aus unserer Perspektive ist es zuallererst notwendig, pro Produktgruppe das jeweilige Prozessmuster zu klären (ETO, CTO, CTO+, STO). Prozessmuster sind das stärkste Kriterium für die zu wählenden Implementierungsmuster! 🔍
Im PLM fokussiert auf die Entstehung der Produktstrukturen, die ein Produkt vollständig beschreiben. Daher ist es notwendig, die Strukturversorgungsfolge, d.h. die Produktstrukturen und die Folge, wie sie sich nacheinander mit Informationen versorgen, im IST und im Future State zu definieren. 🚀
Pro Struktur können dann die Use Cases abgeleitet werden, die an/mit den jeweiligen Strukturen durchgeführt werden sollen. ✅
Ist das erledigt, dann kann ein PLM-Projekt leicht abgegrenzt werden.
Danach kann man natürlich noch Capabilities und Prozesse etc. beschreiben. Oft ist das dann jedoch gar nicht mehr notwendig, weil das Bild bereits klar ist. 🖼️
Nun, das sind meine Gedanken dazu. Was meint ihr? Welche Aspekte sind ggf. in meiner Perspektive Blind Spots? 🔍
#EnterpriseArchitecture #PLM #BusinessTransformation #Innovation #RIMCompany #ProcessOptimization
