LinkedIn post 1
Enterprise Architecture Methods do not work with PLM & ERP!
It feels like heresy - sorry, I have to say it anyway!
Why? Here is my answer.
Have you ever bought expensive strategy or methodology consultants who threw around fancy names like Enterprise Architecture, TOGAF, ArchiMate? Have you drawn diagrams with them, especially huge capability maps? 🎨📊
Were they perhaps also methodological dogmatists (these are the worst 😉) and did not allow any deviations, any other methods? 😤
Well, you can save yourself the expense.
For PLM and also for large parts of ERP, EA methods have huge blind spots! 🚫👀
This does not mean that the methodology and the way of thinking behind it are not helpful.
It's just that if you have painstakingly modeled everything, you still don't understand your PLM case and can't adequately delineate the content of your projects.
It is therefore very likely that the same chaos that prevails in the majority of PLM projects will occur. ⚠️🔥
I therefore recommend limiting the use of EA to the bare minimum. ✅
Well, why do I see it that way? 🤔
When we talk about PLM and ERP, we are essentially talking about explicating the information framework of a company and mapping it cleanly in existing IT systems on the market. It is necessary to explain the business objects (part, document, design, material ...), their time behavior and the semantics of their aggregation in different structure types (EBOM, MBOM, TOS, classification trees ...). 🏗️📚
This is the core of the first discussion! After that, you can assign use cases, user stories, epics (you name it) and draw capability maps in all their beauty. 🎯📝
Well, most EA methods do not model the semantics of the information at all!
Many of you will probably reply that data modeling and data models are available in EA models. 📊💡
This is true, but the problem is that they are designed to prepare the implementation of a completely new data model and not to penetrate existing information structures from their meaningful perspective. 🧩🔍
What do you think?
Now I'm really looking forward to the discussion and your views on this. 💬🤓
And by the way, with our RIM Company Cubing we have developed a method that avoids blind spots in PLM and ERP implementations. 🌟🔧
LinkedIn post 2
What are typical Enterprise Architecture blind spots for PLM?
And how can we plan and implement PLM Blind Spot Free? 🤔
I was very pleased that my last post on the topic generated a great discussion. 🎉
Today I would like to explain a few more aspects of the topic from my perspective. 🤓
In consulting situations with customers, we are often called upon after they have tried to break down PLM from the EA perspective. The approach is typically as follows:
1️⃣ Capability maps were created,
2️⃣ then processes are recorded and
3️⃣ later discussed their vendor capability domains with the vendors.
Why doesn't it work well? Here are some reasons: 👇
🌟 Capability
What is a capability? The problem with capabilities is their multidimensionality. They contain process or use case snippets and also implicitly have a value in the sense of "can we/can't we". They are suitable for explaining the added value of a PLM strategy, but not for defining a PLM project or the PLM strategy for internal discussion.
🔄 Process
PLM is characterized by information structures and their semantics! Processes are of secondary importance in PLM! A process-focused approach to PLM projects generates high overheads and unnecessarily inflates projects at an early stage. 💡
🏷️ Vendor Capability Domains
The vendors organize their PLM systems according to functional units. The cut of the clusters focuses on increasing cash flow. The clusters can therefore often not be applied well to definable and implementable problems from the customer's perspective. 💸
We at RIM are convinced that the sequence of topics to be dealt with should be as follows! We have also anchored this in our RIM Company Cubing method. 📦
From our perspective, it is first and foremost necessary to clarify the respective process pattern for each product group (ETO, CTO, CTO+, STO). Process patterns are the strongest criterion for the implementation patterns to be selected! 🔍
PLM focuses on the creation of the product structures that fully describe a product. It is therefore necessary to define the structure supply sequence, i.e. the product structures and the sequence in which they are successively supplied with information, in the current and future state. 🚀
The use cases that are to be carried out on/with the respective structures can then be derived for each structure. ✅
Once this is done, a PLM project can be easily delimited.
After that, you can of course describe capabilities and processes etc.. However, this is often no longer necessary because the picture is already clear. 🖼️
Well, these are my thoughts on it. What do you think? Which aspects might be blind spots in my perspective? 🔍
#EnterpriseArchitecture #PLM #BusinessTransformation #Innovation #RIMCompany #ProcessOptimization
