Those who have read my blog posts over the years will have seen the image to the left.
The people, processes and tools slogan points to the best practice of implementing (PLM and CM) systems.
Theoretically, a PLM implementation will move smoothly if the company first agrees on the desired processes and people involved before a system implementation using the right tools.
Too often, companies start from their historical landscape (the tools – starting with a vendor selection) and then try to figure out the optimal usage of their systems. The best example of this approach is the interaction between PDM(PLM) and ERP.
PDM and ERP
Historically ERP was the first enterprise system that most companies implemented. For product development, there was the PDM system, an engineering tool, and for execution, there was the ERP system. Since ERP focuses on the company’s execution, the system became the management’s favorite.
The ERP system and its information were needed to run and control the company. Unfortunately, this approach has introduced the idea that the ERP system should also be the source of the part information, as it was often the first enterprise system for a company. The PDM system was often considered an engineering tool only. And when we talk about a PLM system, who really implements PLM as an enterprise system or was it still an engineering tool?
This is an example of Tools, Processes, and People – A BAD PRACTICE.
Imagine an engineer who wants to introduce a new part needed for a product to deliver. In many companies at the beginning of this century, even before starting the exercise, the engineer had to request a part number from the ERP system. This is implementation complexity #1.
Next, the engineer starts developing versions of the part based on the requirements. Ultimately the engineer might come to the conclusion this part will never be implemented. The reserved part number in ERP has been wasted – what to do?
It sounds weird, but this was a reality in discussions on this topic until ten years ago.
Next, as the ERP system could only deal with 7 digits, what about part number reuse? In conclusion, it is a considerable risk that reused part numbers can lead to errors. With the introduction of the PLM systems, there was the opportunity to bridge the gap between engineering and manufacturing. Now it is clear for most companies that the engineer should create the initial part number.
Only when the conceptual part becomes approved to be used for the realization of the product, an exchange with the ERP system will be needed. Using the same part number or not, we do not care if we can map both identifiers between these environments and have traceability.
It took almost 10 years from PDM to PLM until companies agreed on this approach, and I am curious about your company’s status.
Meanwhile, in the PLM world, we have evolved on this topic. The part and the BOM are no longer simple entities. Instead, we often differentiate between EBOM and MBOM, and the parts in those BOMs are not necessarily the same.
In this context, I like Prof. Dr. Jörg W. Fischer‘s framing:
EBOM is the specification, and MBOM is the realization.
(Leider schreibt Er viel auf Deutsch).
An interesting discussion initiated by Jörg last week was again about the interaction between PLM and ERP. The article is an excellent example of how potentially mainstream enterprises are thinking. PLM = Siemens, ERP = SAP – an illustration of the “tools first” mindset before the ideal process is defined.
There was nothing wrong with that in the early days, as connectivity between different systems was difficult and expensive. Therefore people with a 20 year of experience might still rely on their systems infrastructure instead of data flow.
But enough about the bad practice – let’s go to people, processes, (data), and Tools
People, Processes, Data and Tools?
I got inspired by this topic, seeing this post two weeks ago from Juha Korpela, claiming:
Okay, so maybe a hot take, maybe not, but: the old “People, Process, Technology” trinity is one of the most harmful thinking patterns you can have. It leaves out a key element: Data.
His full post was quite focused on data, and I liked the ” wrapping post” from Dr. Nicolas Figay here, putting things more in perspective from his point of view. The reply made me think about how this discussion fits into the PLM digital transformation discussion. How would it work in the two major themes I use to explain the digital transformation in the PLM landscape?
For incidental readers of my blog, these are the two major themes I am using:
- From Coordinated to Connected, based on the famous diagram from Marc Halpern (image below). The coordinated approach based on documents (files) requires a particular timing (processes) and context (Bills of Information) – it is the traditional and current PLM approach for most companies. On the other hand, the Connected approach is based on connected datasets (here, we talk about data – not files). These connected datasets are available in different contexts, in real-time, to be used by all kinds of applications, particularly modeling applications. Read about it in the series: The road to model-based and connected PLM.
. - The need to split PLM, thinking in System(s) of Record and Systems of Engagement. (example below) The idea behind this split is driven by the observation that companies need various Systems of Record for configuration management, change management, compliance and realization. These activities sound like traditional PLM targets and could still be done in these systems. New in the discussion is the System of Engagement which focuses on a specific value stream in a digitally connected manner. Here data is essential.I discussed the coexistence of these two approaches in my post Time to Split PLM. A post on LinkedIn with many discussions and reshares illustrating the topic is hot. And I am happy to discuss “split PLM architectures” with all of you.
These two concepts discuss the processes and the tools, but what about the people? Here I came to a conclusion to complete the story, we have to imagine three kinds of people. And this will not be new. We have the creators of data, the controllers of data and the consumers of data. Let’s zoom in on their specifics.
A new representation?
I am looking for a new simplifaction of the people, processes, and tools trinity combined with data; I got inspired by the work Don Farr did at Boeing, where he worked on a new visual representation for the model-based enterprise. You might have seen the image on the left before – click on it to see it in detail.
I wrote the first time about this new representation in my post: The weekend after CIMdata Roadmap / PDT Europe 2018
Related to Configuration Management, Martijn Dullaart and Martin Haket have also worked on a diagram with their peers to depict the scope of CM and Impact Analysis. The image leads to the post with my favorite quote: Communication is merely an exchange of information, but connections tell the story.
Below I share my first attempt to combine the people, process and tools trinity with the concepts of document and data, system(s) of record and system(s) of engagement. Trying to build the story. Look if you recognize the aspects of the discussion above, and feel free to develop enhancements.
I look forward to your suggestions. Like the understanding that we have to split PLM thinking, as it impacts how we look at implementations.
Conclusion
Digital transformation in the PLM domain is forcing us to think differently. There will still be processes based on people collecting, interpreting and combining information. However, there will also be a new domain of connected data interpreted by models and algorithms, not necessarily depending on processes.
Therefore we need to work on new representations that can be used to tell this combined story. What do you think? How can we improve?
Jos Voskuil's Weblog 
3 comments
Comments feed for this article
February 27, 2023 at 6:47 pm
Lars Taxén
I suspect that there are more profound issues at stake here. For example, we seem to uncritically accept that information is some kind of package that we can collect, store and transmit between minds. But what if this is not so? What if the information is unique for each person, constituted by interacting with other people and the environment? If so, we need to rethink the very basis for our modelling, focusing on making them as efficient as possible for aligning individual lines of actions. We would still have People, Processes, Data and Tools of course, but now viewed from a new perspective.
Hi Lars, I agree there is a difference between defined information (a pre-defined collection of data) and knowledge (a potential personal collection of data – tacit knowledge). Historically information was stored in structured datasets (books, documents, drawings) – a data(base) driven approach is much more granular, like LEGO bricks allowing you to build your own information package – and when it is personal – your own knowledge package.
What do you think?
LikeLike
March 1, 2023 at 1:33 pm
jfvanoss
Jos,
Nice article, but the reality of companies is that they have huge investments in tools and lots of legacy data and processes wrapped around those tools. This can force a tools-process-people paradigm which as you point out is a BAD PRACTICE but a reality of implementation. most companies eventually figure out how to live with this reality but it often costs them time and money in the form of higher product costs and slower time to market.
One area to consider as you point out is the product innovation platforms getting to integrated (connected) platforms. This is where the real value is and it can overcome some of the handicaps imposed by forced tool usage. The other advantage of common tool usage is scale for large or widely dispersed enterprises which can get you back to tools-process-people for sites that have to change tools in favor of common tools which upsets the process apple cart (locally). The real trick is to implement (reasonably good) end to end tools with a minimal investment (or at least preserve past investment, which is not always possible), while the company continues to design, develop, produce and ship products. This is analogous to a heart transplant on someone running a marathon.
Thanks Jim, I agree with you that historically there was a kind of “use your legacy tools first”paradigm. It started with ERP. Can we do BOM design activities in ERP? Let’s make it happen and see. This is how we got SAP PLM in the market, disconnected from the design side. PDM systems most of the time never became PLM systems, because they were designed to optimize the engineering department. The result a difficult flow between “PLM/PDM”and ERP as the tools are established, we just need to fix the process & flow.
You are right, product innovation platforms are more designed for multidisciplinary collaboration (systems of engagement) and I believe a hybrid approach to merge them into your company is the smoothest part. The topic is closely related to my Time to Split PLM post. For me an interesting area to follow.
LikeLike
March 12, 2023 at 7:47 pm
Michael Christoffersen
Interesting discussion about part numbers and where they originate. Though there seems to be consensus about the EBOM and MBOM, the same does not go for the individual lines in the BOM. I never understand why you need to create a new CAD model just because there is a different color/paint. (Form/Fit/Function). But the dilemma is if it is not a different painting, but a different material with different density and other physical properties.
Also for “Buy” parts, it can be tricky to handle, as a given “buy” product can have different vendors/brands.
At least this is something we are struggling with, when deciding if a part number should originate from ERP system or PLM.
Thanks Michael for your inputs. I agree with you that the CAD model should not necessary contain the color as property, unless the color is affecting the Function of the part. When you consider the color a kind of packaging – the EBOM part could remain the same, where the MBOM part is EBOM part + packaging. In general I believe all part numbers should come from PLM (they are the source) and there needs to be a handshake with ERP when it comes to MBOM parts as both systems have their required datasets.
LikeLike