You are currently browsing the tag archive for the ‘Business process’ tag.
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?
I don’t know if it is the time of the year, but suddenly there is again in the PLM world a discussion which is related to the theme of flexibility (or the lack of flexibility). And I do not refer to some of the PLM supplier lock-in situations discussed recently. In a group discussion on LinkedIn we talked about the two worlds of PLM-ERP and that somehow here we have status quo do to the fact companies won’t change the way they manage their BOM if they are not forced to do or see the value.
Stephen Porter from Zero Wait-State in his blog wrote an interesting post about using PLM to model business processes and I liked his thoughts. Here the topic, flexibility was brought into the discussion by me.
Then Mark Lind from Aras responded to this post and referred to his post on Out-Of-The-Box (OOTB) PLM which ended in a call for flexibility.
However, reading this post I wanted to bring some different viewpoints to Mark’s post and as my response became too long, I decided to post it in my blog. So please read Stephen’s post, read Mark’s post and keep the word flexibility in the back of your mind.
My European view
As I have been involved in several OOTB-attempts with various PDM / PLM suppliers, I tend to have somehow a different opinion about the purpose of OOTB.
It is all about what you mean with OOTB and what type and size of company you are talking about. My focus is not on the global enterprises – they are too big to even consider OOTB (too many opinions – too much politics).
But the mid-market companies, which in Europe practice a lot of PLM, without having a PLM system, are my major target. They improve their business with tools fitting in their environment, and when they decide to use a PLM system; it is often close related to their CAD or ERP system.
In this perspective, Mark’s statement:
Now stop and think… the fundamental premise of OOTB enterprise software is that there’s an exact match between your corporate processes and the software. If it’s not an exact match, then get ready to customize (and it won’t be OOTB anymore). This is why the concept of OOTB enterprise PLM is absurd.
I see it as a simplification – yes customers want to use OOTB systems, but as soon as you offer flexibility, customers want to adapt it. And the challenge of each product is to support as much as possible different scenarios (through configuration, through tuning (you can call it macros or customization) Microsoft Excel is still the best tool in this area
But let’s focus on PLM. Marc’s next statement:
It doesn’t matter if we’re talking about Industry Accelerators or so called ‘best practice’ templates
Again is simplifying the topic. Most of the companies I have been working with had no standard processes or PLM practices as much of the work was done outside a controlled system. And in situations that there was no Accelerator or Best Practice, you were trapped in a situation where people started to discuss their processes and to-be practices (losing time, concluding the process was not so easy as they thought, and at the end blame the PLM system as it takes so long to implement – and you need someone or something to blame). Also her Stephen promotes the functionality in PLM to assist modeling these processes.
PLM is a learning process for companies and with learning I mean, understanding that the way of working can be different and change is difficult. That’s why a second, new PLM implementation in the same company is often more easy to do. At this stage a customer is able to realize which customizations were nice to have but did not contribute to the process and which customizations now could be replaced by standard capabilities (or configured capabilities). A happy target for PLM vendors where the customer changes from PLM vendor as they claim the success of the second implementation. However I have seen also re-implementations with the same software and the same vendor with the same results: faster implementation, less customization and more flexibility.
I fully agree with Marc’s statement that PLM implementations should be flexible and for me this means during implementations make sure you stay close to the PLM standards (yes there are no ‘official’ standards but every PLM implementation is around a similar data model.)
As the metadata and the created files represent the most value for the customer, this is where you should focus. Processes to change, review, collaborate or approve information should always be flexible as they will change. And when you implement these processes to speed up time-to-market or communication between departments/partners, do an ROI and risk analysis if you need to customize.
I still see the biggest problem for PLM is that people believe it is an IT-project, like their ERP project in the past. Looking at PLM in the same way does not reflect the real PLM challenge of being flexible to react. This is one of my aversions against SAP PLM – these two trigrams just don’t go together – SAP is not flexible – PLM should be flexible.
Therefore this time a short blog post or long response, looking forward to your thoughts
As a follow-up of my holiday thoughts, I want to discuss this time the various interpretations of PLM that exist. Of course we have the ‘official’ definitions of the consultancy companies like CIMdata and 2PLM ( I took an American and European example). They describe clearly that it is a business approach, not necessary a set of technologies and tools to implement.
Then we have the PLM vendors, where Dassault Systems and Siemens claim their visionary leadership. Looking at their websites, it is hard to find an explicit message. They both claim PLM brings innovation (how ?) , where Dassault Systemes has a strong message around 3D and virtual product development and Siemens focuses more on efficiency and better collaboration benefits. I am not going in depth into PTC and Aras or other PLM vendors as I am only taking two examples per type of company, but look at their websites and find out how (and if) they describe PLM as a business approach.
For a PLM definition at SAP you have to dig a little deeper and I got even more surprised when searching through the Oracle web site. Here it was difficult to find a generic PLM message. There was the list of acquisitions (which make me wonder if this means they are all integrated) and there was the list of industries and only when drilling down into the industries, you will find PLM related information. Here I still have the feeling that these companies understand there is a need for PLM, but that it is not in their veins, they want to manage product data as a ‘single version of the truth’ – which is not a bad idea and I will come back on that later – but they want to manage different data.
Also upcoming are the generic PLM on-line solutions (Arena and PLM+), which for me still are somehow a contradiction to what consultancy companies describe as PLM. Instead of a bussiness approach it is an IT-solution. In parallel there are more dedicated on-line solutions that support a specific business process (where PLM practices are embedded) – like for Apparel, CPG.
For these type of solutions, I have a more positive opinion as they are lowering the threshold to implement PLM in a certain industry. However the biggest skepticism I have for these types of solutions is the degrees of flexibility it will offer the implementing company to be different from standard best practices. As all companies have their uniqueness in being competitive, will they be able to support this ?
And then there was the press release from Zero Wait-State which struck me:
Zero Wait-State is launching a new website that will provide a central location for Product Lifecycle Management software and partner reviews. This site will be a valuable resource for companies trying to assess different PLM solutions and which partners to work with. The site will be driven by users and allow them to share their experiences with different software products and implementation partners.
See the full press release here: Zero Wait-State Announces New Website for PLM and Service Provider Reviews.
I believe in these times of product selection and reviews certainly a good initiative. Where do we find vendor independent reviews of various PLM products ? Bringing PLM to social communities.
But ……
Here I want to take a step back. What is the essence of PLM and how do you know as a company you want to implement PLM ?
The majority of mid-market companies are not looking for a PLM system. Most of the mid-market companies have the impression that PLM is complex and expensive and typical mid-market vendors like Autodesk or SolidWorks are not pushing PLM (try for fun to search for PLM on their websites).
So will a mid-market company be able to select a PLM product through communities in the same manner as you select a consumer product ?
I believe the main challenge for a PLM implementation is not the software, but the business change.
In a company where most people are thinking (and rewarded) departmental, it is difficult to implement a new system that affects all departments. Creating the single version of the truth for product data is one of the basics for PLM. Try to get an agreement with sales, engineering, production and service who will be responsible for which part of the BOM. SAP’s single version of the truth is much more a statement from an IT-infrastructure point of view not focusing and pushing a change of business processes.
I believe, and this is also based on discussions and comments from colleagues focusing on the mid-market, that many mid-market companies are implementing basics of PLM, not always using a ‘certified’ PLM system or PLM vendor, but a pragmatic solution (customization / piece of software) which connects parts of the product information. These solutions are usually extensions on top of the CAD data management environment or the ERP system.
And here PLM vendors have a mission. Provide building blocks (services) that allow mid-market companies to connect data between departments based on known standard authoring tools. For classical PLM industries (Automotive/Aero/Fabrication & Assembly) the major CAD systems and virtual product development plus analysis software are major disciplines to manage. Other industries also have their authoring tools. Connecting them through services and provide an easy to implement backbone for product information. This should be not a big-boom effect in the mid-market, but more an evolution – moving to PLM 2.0 or beyond ?
Will this come from PLM providers or IT-providers ?
Conclusion:
For the mid-market it is not about which PLM, but more about who can provide a gradual business change from sequential and departmental business processes towards company-wide processes, where people share and collaborate around the single version of data. So which PLM should be called which provider …..
I am looking forward to your opinion.
Jos Voskuil's Weblog 
Jos, great thoughts about BOM management. Here are some of my thoughts. I can see how BOM management will evolve…
As a complement, even if more and more of the diversity of a product is managed at the software level…
1) A wiring diagram stores information (wires between ports of the electrical components) that does not exist in most of…
BOM has NEVER been the sole "master" of the Product. The DEFINITION FILE is ! For example the wiring of…
Interesting discussion about part numbers and where they originate. Though there seems to be consensus about the EBOM and MBOM,…