You are currently browsing the category archive for the ‘Data centric’ category.
In the series learning from the past to understand the future, we have almost reached the current state of PLM before digitization became visible. In the last post, I introduced the value of having the MBOM preparation inside a PLM-system, so manufacturing engineering can benefit from early visibility and richer product context when preparing the manufacturing process.
Does everyone need an MBOM?
It is essential to realize that you do not need an EBOM and a separate MBOM in case of an Engineering To Order primary process. The target of ETO is to deliver a unique customer product with no time to lose. Therefore, engineering can design with a manufacturing process in mind.
The need for an MBOM comes when:
- You are selling a specific product over a more extended period of time. The engineering definition, in that case, needs to be as little as possible dependent on supplier-specific parts.
- You are delivering your portfolio based on modules. Modules need to be as long as possible stable, therefore independent of where they are manufactured and supplier-specific parts. The better you can define your modules, the more customers you can reach over time.
- You are having multiple manufacturing locations around the world, allowing you to source locally and manufacture based on local plant-specific resources. I described these options in the previous post
The challenge for all companies that want to move from ETO to BTO/CTO is the fact that they need to change their methodology – building for the future while supporting the past. This is typically something to be analyzed per company on how to deal with the existing legacy and installed base.
Configurable EBOM and MBOM
In some previous posts, I mentioned that it is efficient to have a configurable EBOM. This means that various options and variants are managed in the same EBOM-structure that can be filtered based on configuration parameters (date effectivity/version identifier/time baseline). A configurable EBOM is often called a 150 % EBOM
The MBOM can also be configurable as a manufacturing plant might have almost common manufacturing steps for different product variants. By using the same process and filtered MBOM, you will manufacture the specific product version. In that case, we can talk about a 120 % MBOM
Note: the freedom of configuration in the EBOM is generally higher than the options in the configurable MBOM.
The real business change for EBOM/MBOM
So far, we have discussed the EBOM/MBOM methodology. It is essential to realize this methodology only brings value when the organization will be adapted to benefit from the new possibilities. 
One of the recurring errors in PLM implementations is that users of the system get an extended job scope, without giving them the extra time to perform these activities. Meanwhile, other persons downstream might benefit from these activities. However, they will not complain. I realized that already in 2009, I mentioned such a case: Where is my PLM ROI, Mr. Voskuil?
Now let us look at the recommended business changes when implementing an EBOM/MBOM-strategy
- Working in a single, shared environment for engineering and manufacturing preparation is the first step to take.
Working in a PLM-system is not a problem for engineers who are used to the complexity of a PDM-system. For manufacturing engineers, a PLM-environment will be completely new. Manufacturing engineers might prepare their bill of process first in Excel and ultimately enter the complete details in their ERP-system. ERP-systems are not known for their user-friendliness. However, their interfaces are often so rigid that it is not difficult to master the process. Excel, on the other side, is extremely flexible but not connected to anything else.
And now, this new PLM-system requires people to work in a more user-friendly environment with limited freedom. This is a significant shift in working methodology. This means manufacturing engineers need to be trained and supported over several months. Changing habits and keep people motivated takes energy and time. In reality, where is the budget for these activities? See my 2016 post: PLM and Cultural Change Management – too expensive?
- From sequential to concurrent
Once your manufacturing engineers are able to work in a PLM-environment, they are able to start the manufacturing definition before the engineering definition is released. Manufacturing engineers can participate in design reviews having the information in their environment available. They can validate critical manufacturing steps and discuss with engineers potential changes that will reduce the complexity or cost for manufacturing. As these changes will be done before the product is released, the cost of change is much lower. After all, having engineering and manufacturing working partially in parallel will reduce time to market.
Reducing time to market by concurrent engineering
One of the leading business drivers for many companies is introducing products or enhancements to the market. Bringing engineering and manufacturing preparation together also means that the PLM-system can no longer be an engineering tool under the responsibility of the engineering department.
The responsibility for PLM needs to be at a level higher in the organization to ensure well-balanced choices. A higher level in the organization automatically means more attention for business benefits and less attention for functions and features.
From technology to methodology – interface issues?
The whole EBOM/MBOM-discussion often has become a discussion related to a PLM-system and an ERP-system. Next, the discussion diverted to how these two systems could work together, changing the mindset to the complexity of interfaces instead of focusing on the logical flow of information.
In an earlier PI Event in München 2016, I lead a focus group related to the PLM and ERP interaction. The discussion was not about technology, all about focusing on what is the logical flow of information. From initial creation towards formal usage in a product definition (EBOM/MBOM).
What became clear from this workshop and other customer engagements is that people are often locked in their siloed way of thinking. Proposed information flows are based on system capabilities, not on the ideal flow of information. This is often the reason why a PLM/ERP-interface becomes complicated and expensive. System integrators do not want to push for organizational change, they prefer to develop an interface that adheres to the current customer expectations.
SAP has always been promoting that they do not need an interface between engineering and manufacturing as their data management starts from the EBOM. They forgot to mention that they have a difficult time (and almost no intention) to manage the early ideation and design phase. As a Dutch SAP country manager once told me: “Engineers are resources that do not want to be managed.” This remark says all about the mindset of ERP.
After overlooking successful PLM-implementations, I can tell the PLM-ERP interface has never been a technical issue once the methodology is transparent. A company needs to agree on logical data flow from ideation through engineering towards design is the foundation.
It is not about owning data and where to store it in a single system. It is about federated data sets that exist in different systems and that are complementary but connected, requiring data governance and master data management.
The SAP-Siemens partnership
In the context of the previous paragraph, the messaging around the recently announced partnership between SAP and Siemens made me curious. Almost everyone has shared an opinion about the partnership. There is a lot of speculation, and many questions were imaginarily answered by as many blog posts in the field. Last week Stan Przybylinski shared CIMdata’s interpretations in a webinar Putting the SAP-Siemens Partnership In Context, which was, in my opinion, the most in-depth analysis I have seen.
For what it is worth, my analysis:
- First of all, the partnership is a merger of slide decks at this moment, aiming to show to a potential customer that in the SAP/Siemens-combination, you find everything you need. A merger of slides does not mean everything works together.
- It is a merger of two different worlds. You can call SAP a real data platform with connected data, where Siemens offering is based on the Teamcenter backbone providing a foundation for a coordinated approach. In the coordinated approach, the data flexibility is lower. For that reason, Mendix is crucial to make Siemens portfolio behave like a connected platform too.
You can read my doubts about having a coordinated and connected system working together (see image above). It was my #1 identified challenge for this decade: PLM 2020 – PLM the next decade (before COVID-19 became a pandemic and illustrated we need to work connected) - The fact that SAP will sell TC PLM and Siemens will sell SAP PPM seems like loser’s statement, meaning our SAP PLM is probably not good enough, or our TC PPM capabilities are not good enough. In reality, I believe they both should remain, and the partnership should work on logical data flows with data residing in two locations – the federated approach. This is how platforms reside next to each other instead of the single black hole.
- The fact that standard interfaces will be developed between the two systems is a subtle sales argument with relatively low value. As I wrote in the “from technology to methodology”-paragraph, the challenges are in the organizational change within companies. Technology is not the issue, although system integrators also need to make a living.
- What I believe makes sense is that both SAP and Siemens, have to realize their Industry 4.0 end-to-end capabilities. It is a German vision now for several years and it is an excellent vision to strive for. Now it is time to build the two platforms working together. This will be a significant technical challenge mainly for Siemens as its foundation is based on a coordinated backbone.
- The biggest challenge, not only for this partnership, is the organizational change within companies that want to build an end-to-end connected solution. In particular, in companies with a vast legacy, the targeted industries by the partnership, the chasm between coordinated legacy data and intended connected data is enormous. Technology will not fix it, perhaps smoothen the pain a little.
Conclusion
With this post, we have reached the foundation of the item-centric approach for PLM, where the EBOM and MBOM are managed in a real-time context. Organizational change is the biggest inhibitor to move forward. The SAP-Siemens partnership is a sales/marketing approach to create a simplified view for the future at C-level discussions.
Let us watch carefully what happens in reality.
Next time potentially the dimension of change management and configuration management in an item-centric approach.
Or perhaps Martijn Dullaart will show us the way before, following up on his tricky poll question
Two weeks ago, I wrote about the PLM Innovation Forum, a virtual conference organized by TECHNIA, where I described some of my experiences with the event and the different ways of interaction in a virtual conference.
The content remains available till May 31st, so I had time to stroll through the rich content offered. In particular, if you are already familiar with the Dassault Systèmes & TECHNIA offerings, the content is extremely rich.
From the “auditorium“, I selected four presentations that have a logical relation to each other. I believe they will help you understand some of the aspects of PLM independent of the PLM vendor. Let’s start.
Value-Driven Implementation
In this session, Johannes Storvik, you can identify three parts. In the first part, Johannes talks about how to select the best PLM-approach, discussing the various options from custom, standardized, or even fully Out-Of-The-Box, comparing these options with building types. An interesting comparison, however, there is a risk with this approach.
Many companies are now stating they only need a collection of Commercial of the Shelf (COTS) systems and prefer only OOTB. The challenge with this approach is that you start from the tools, constraining the business from the start.
I would state start from your business goals, and ultimately they will lead to requirements for the tools. And then, if available, you find solutions that require no or minor adaptation. Starting from the business is crucial, and Johannes elaborates more on that.
The second part discussing PLM benefits, and if you are looking for confirmation PLM brings value, have a look at the topics, areas, and numbers mentioned. Most benefits and areas are quite traditional, related to a coordinated organization (if you follow my coordinated to connected typology).
The last part, connecting the dots from business to enablers, a Benefits Dependency Network, is a methodology that I recommend. Originally developed by Cranfield School of Management, it allows you to connect your PLM-needs to the company’s business needs and strategies. You can read more about this methodology in this HBR article: A tool to map your next digital initiative.
Benefits Dependency Network: note the potential storyline you can build
My experience from this methodology is that it allows you to extract one, two perhaps three storylines. These storylines then help you to explain why the PLM enablers are needed connecting to a business case into one understandable storyline, suitable for all levels in the company
With Johannes, we went from PLM-characteristics towards connecting PLM to the business and exec management, making PLM implicit visible at the management level. Now the next step.
Industrialization of the Construction Industry
The theme of this session might be misleading. Arto Tolonen, from the LETHO group, has a long history in PLM as a practitioner and at the University of Oulu, where he specialized in Product Data Management and Product Portfolio Management.
The last part of his presentation is dealing with transformational thinking for the construction industry from a one-off construction towards thinking in repeatable processes, using PLM practices. With his dry humor, he asks:
“Why are all buildings prototypes ?” and more.
For many years, I have been preaching PLM practices to be valuable for other industries too. See this 2013 post: PLM for all industries? The most common challenge was to respond to the question: “What does your tool do?” PLM practices only become valuable if you think in repeatable processes.
The exciting part is when Arto talks about the disconnect between the exec level in an organization and reality in the field. Understanding how products are performing, and how each product contributes to the profit of the company, is usually blurred with subjective information. Your company’s love baby might be the worst performer but never dropped from the product portfolio for sentimental reasons.
Arto explains the importance of (digital) portfolio management, connecting the economic data with the technical data. And by doing so, use portfolio management to drive the development of new offerings based on market needs and numbers. Or to decommission products.
I am fully aligned with Arto and believe that a digital transformation should include a connected product portfolio management environment, driving new development projects. Product Portfolio management is not the same as BOM-management.
The portfolio items are facing the outside world, your customers. How the products are built, is defined in the inside world of BOMs and design data.
Now combining product portfolio management with product management makes a lot of more sense if you are going to use it to support the modularization of your products. Based on solution platforms, you can design your products to become modular, leading to a lot of business benefits.
With Arto, we discovered the need to have digital portfolio management connecting business performance and product development. Another implicit reason for PLM to your business explained with humor. Now the next step.
Modularization
Closely related to product portfolio management is the topic of modularization. If you want to optimize your offering with a great variety of choices for your customers, without spending more time to develop an individual solution, you need to implement modularization for your products.
Daniel Strandhammar van Brick Strategy explains this topic in his session. So many companies I am working with a claim that they want to move from and ETO (Engineering To Order) model to a CTO (Configure To Order) model. Unfortunately, many of them keep on talking about that without making steps towards more configurable products.
Although in many PLM-infrastructures, the capabilities exist to support the modularity of a product portfolio, it requires thinking and analysis outside the tools. The tools are there to support the modularization. Still, it depends on your engineering teams to transform the company’s portfolio step by step into a more modular product. Brick Strategy is typical such a company that can help you and coach you in a modularization process.
If you look at the benefits Daniel is mentioning related to modularization, these benefits are significant. However, as Daniel also explains per type of business, the effects of modularization might be different, still in every situation worth to invest.
It is interesting to know that many of the modularization methodologies come from Scandinavian countries. Perhaps a region, with companies like Scania (master of modularization), IKEA and others leading the ways towards modularization. Is it a surprise that LEGO is also a Scandinavian company?
Daniel continues by explaining how a roadmap for modularization could look like. If you are struggling with that point, have a look at the video. It is a crucial part of the story.
Note: There is also a presentation from Anders Malmberg fro Scania talking about their Starling project. Not particularly related to modularization, more related to how to organize significant PLM transformations.
With Daniel’s presentation, we see the relation between a product portfolio and modularization. Another implicit reason for PLM to improve your business explained. Now let’s do it.
Making Multi-view BOM a reality
My ultimate dream was that James Roche from CIMdata would complete the storyline. We went from business initiatives through product portfolio management and modularization through a flow of organizational topics to enhance your business outcome using PLM.
With James, I was hoping we now would get the final necessary part, the need for a multi-view BOM, and how to establish this. As I mentioned before with modularization, many companies started with a kind of ETO-approach to deliver solutions for their customers. The downside of this approach is that, when designing a product, the manufacturing process was already leading the way the BOM will be structured. Many of the companies that I work with are in this situation. There is no clear EBOM and MBOM, the situation is a kind of hybrid BOM, blocking modularity and multi-plant manufacturing.
James’s presentation unfortunate started with a 10 min technical delay, and then the next part is crucial to understand. He explains nicely what it means to have a “hybrid” single BOM and more to a multi-view EBOM/MBOM. James addressed this topic, both using an example looking at it from a technological and organizational view.
As James is the CIMdata Practice Director for Aerospace & Defense, this was the industry in focus and even example provided above is not necessarily the best solution for every A&D company. Organizational change and managing risks are crucial in such a transition, and that is where James spent even more time. It would be great, and I consider it one of my next blog options, to discuss and share best practices for other types of industries. Is there always a need for a multi-view BOM and are they all the same?
With James we concluded the PLM value story, making it my fourth pick of the PLMIF conference, giving you an end-to-end storyline why PLM is important and how it is connected to your business results.
Conclusion
The four presentations that I highlighted here show a storyline that is crucial to understand and pitch when you talk about the business value of PLM. It is not about technical features and functions. It is part of a business strategy, building the right portfolio, manage it in a modular manner, and use multiple BOM views to optimize the delivery of your products.
Note: two more weeks to see the full presentations of PLMIF – go and have a look in case you haven’t done so: http://www.plmif.org
Life goes on, and I hope you are all staying safe while thinking about the future. Interesting in the context of the future, there was a recent post from Lionel Grealou with the title: Towards PLM 4.0: Hyperconnected Asset Performance Management Framework.
Lionel gave a kind of evolutionary path for PLM. The path from PLM 1.0 (PDM) ending in a PLM 4.0 definition. Read the article or click on the image to see an enlarged version to understand the logical order. Interesting to mention that PLM 4.0 is the end target, for sure there is a wishful mind-mapping with Industry 4.0.
When seeing this diagram, it reminded me of Marc Halpern’s diagram that he presented during the PDT 2015 conference. Without much fantasy, you can map your company to one of the given stages and understand what the logical next step would be. To map Lionel’s model with Marc’s model, I would state PLM 4.0 aligns with Marc’s column Collaborating.
In the discussion related to Lionel’s post, I stated two points. First, an observation that most of the companies that I know remain in PLM 1.0 or 2.0, or in Marc’s diagram, they are still trying to reach the level of Integrating.
Why is it so difficult to move to the next stage?
Oleg Shilovitsky, in a reaction to Lionel’s post, confirmed this. In Why did manufacturing stuck in PLM 1.0 and PLM 2.0? Oleg points to several integration challenges, functional and technical. His take is that new technologies might be the answer to move to PLM 3.0, as you can read from his conclusion.
What is my conclusion?
There are many promising technologies, but integration is remaining the biggest problem for manufacturing companies in adopting PLM 3.0. The companies are struggling to expand upstream and downstream. Existing vendors are careful about the changes. At the same time, very few alternatives can be seen around. Cloud structure, new data management, and cloud infrastructure can simplify many integration challenges and unlock PLM 3.0 for future business upstream and especially downstream. Just my thoughts…
Completely disconnected from Lionel’s post, Angad Sorte from Plural Nordic AS wrote a LinkedIn post: Why PLM does not get attention from your CEO. Click on the image to see an enlarged version, that also neatly aligns with Industry 4.0. Coincidence, or do great minds think alike? Phil Collins would sing: It is in the air tonight
Angad’s post is about the historical framing of PLM as a system, an engineering tool versus a business strategy. Angrad believes once you have a clear definition, it will be easier to explain the next steps for the business. The challenge here is: Do we need, or do we have a clear definition of PLM? It is a topic that I do not want to discuss anymore due to a variety of opinions and interpretations. An exact definition will never lead to a CEO stating, “Now I know why we need PLM.”
I believe there are enough business proof points WHY companies require a PLM-infrastructure as part of a profitable business. Depending on the organization, it might be just a collection of tools, and people do the work. Perhaps this is the practice in small enterprises?
In larger enterprises, the go-to-market strategy, the information needs, and related processes will drive the justification for PLM. But always in the context of a business transformation. Strategic consultancy firms are excellent in providing strategic roadmaps for their customers, indicating the need for a PLM-infrastructure as part of that.
Most of the time, they do not dive more in-depth as when it comes to implementation, other resources are needed.
What needs to be done in PLM 1.0 to 4.0 per level/stage is well described in all the diagrams on a high-level. The WHAT-domain is the domain of the PLM-vendors and implementers. They know what their tools and skillsets can do, and they will help the customer to implement such an environment.
The big illusion of all the evolutionary diagrams is that it gives a false impression of evolution. Moving to the next level is not just switching on new or more technology and involve more people.
So the big question is HOW and WHEN to make progress.
HOW to make progress
In the past four years, I have learned that digital transformation in the domain of PLM is NOT an evolution. It is disruptive as the whole foundation for PLM changes. If you zoom in on the picture on the left, you will see the data model on the left, and the data model on the right is entirely different.
On the left side of the chasm, we have a coordinated environment based on data-structures (items, folders, tasks) to link documents.
On the right side of the chasm, we have a connected environment based on federated data elements and models (3D, Logical, and Simulation models).
I have been discussing this topic in the past two years at various PLM conferences and a year ago in my blog: The Challenges of a connected ecosystem for PLM
If you are interested in learning more about this topic, register for the upcoming virtual PLM Innovation Forum organized by TECHNIA. Registration is for free, and you will be able to watch the presentation, either live or recorded for 30 days.
At this moment, the detailed agenda has not been published, and I will update the link once the session is visible. My presentation will not only focus on the HOW to execute a digital transformation, including PLM can be done, but also explain why NOW is the moment.
NOW to make progress
When the COVID19-related lockdown started, must of us thought that after the lockdown, we will be back in business as soon as possible. Now understanding the impact of the virus on our society, it is clear that we need to re-invent ourselves for a sustainable future, be more resilient.
It is now time to act and think differently as due to the lockdown, most of us have time to think. Are you and your company looking forward to creating a better future? Or will you and your company try to do the same non-sustainable rat race of the past and being caught by the next crises.
McKinsey has been publishing several articles related to the impact of COVID19 and the article: Beyond coronavirus: The path to the next normal very insightful
As McKinsey never talks about PLM, therefore I want to guide you to think about more sustainable business.
Use a modern PLM-infrastructure, practices, and tools to remain competitive, meanwhile creating new or additional business models. Realizing concepts as digital twins, AR/VR-based business models require an internal transition in your company, the jump from coordinated to connected. Therefore, start investigating, experimenting in these new ways of working, and learn fast. This is why we created the PLM Green Alliance as a platform to share and discuss.
If you believe there is no need to be fast, I recommend you watch Rebecka Carlsson’s presentation at the PLMIF event. The title of her presentation: Exponential Tech in Sustainability. Rebecca will share insights for business development about how companies can upgrade to new business models based on the new opportunities that come with sustainability and exponential tech.
The reason I recommend her presentation because she addresses the aspect of exponential thinking nicely. Rebecka states we are “programmed” to think local-linear as mankind. Exponential thinking goes beyond our experience. Something we are not used doing until with the COVID19-virus we discovered exponential growth of the number of infections.
Finally, and this I read this morning, Jan Bosch wrote an interesting post: Why Agile Matters, talking about the fact that during the design and delivery of the product to the market, the environment and therefore the requirements might change. Read his post, unless as Jan states:
Concluding, if you’re able to perfectly predict the optimal set of requirements for a system or product years ahead of the start of production or deployment and if you’re able to accurately predict the effect of each requirement on the user, the customer and the quality attributes of the system, then you don’t need Agile.
What I like about Jan’s post is the fact that we should anticipate changing requirements. This statement combined with Rebecka’s call for being ready for exponential change, with an emerging need for sustainability, might help you discuss in your company how a modern New Product Introduction process might look like, including requirements for a sustainable future that might come in later (per current situation) or can become a practice for the future
Conclusion
Now is the disruptive moment to break with the old ways of working. Develop plans for the new Beyond-COVID19-society. Force yourselves to work in more sustainable modes (digital/virtual), develop sustainable products or services (a circular economy), and keep on learning. Perhaps we will meet virtually during the upcoming PLM Innovation Forum?
Note: You have reached the end of this post, which means you took the time to read it all. Now if you LIKE or DISLIKE the content, share it in a comment. Digital communication is the future. Just chasing for Likes is a skin-deep society. We need arguments.
Looking forward to your feedback.
It is the holiday season many groups, religions have their celebrations in this period, mostly due to the return of the light on the Northern hemisphere – Christmas, Diwali, Hanukkah, Kwanzaa and Santa Lucia are a few of them. Combined with a new decade upcoming, also a time for me to reflect on what have we learned and what can we imagine in the next ten years.
Looking back the last decade
Globalization is probably one of the most significant changes we have seen. Almost the whole world is connected now through all kinds of social and digital media. Information is instantly available and influences our behavior dramatically. The amount of information coming to us is so huge that we only filter the information that touches us emotionally. The disadvantage of that, opinions become facts and different opinions become enemies. A colorful society becomes more black and white.
These trends have not reached us, in the same manner, the domain of PLM. There have been several startups in the past ten years, explaining that PLM should be as easy as social communication with Facebook. Most of these startups focused on integrations with MCAD-systems, as-if PLM is about developing mechanical products.
In my opinion, the past decade has shown that mechanical design is no longer a unique part of product development. Products have become systems, full of electronics and driven by software. Systems Engineering became more and more important, defining the overall concept of a product, moving the focus to the earlier stages of the product design – see image below.
During Ideation and system definition, we need “social” collaboration between all stakeholders. To get a grip on this collaboration, we use models (SysML, UML, Logical, 2D, 3D) to have an unambiguous representation, simulation and validation of the product already in the virtual world.
Actually, there is nothing social about that collaboration. It is a company-driven demand to deliver competitive products to remain in business. If our company does not improve multidisciplinary collaboration, global competitors with less nostalgic thoughts to the past will conquer the market space.
Currently in most companies there are two worlds, hardware and software, almost 100 %-separated managed by either PLM or ALM (Application Lifecycle Management). It is clear that “old” PLM – item-driven with related documents cannot match the approach required for ALM – data-elements (code) based on software models (and modules).
In the hardware world a change can have a huge effect on the cost (or waste) of the product, however, implementing a hardware change can take months. Think about new machinery, tooling in the worst case. In the software domain, a change can be executed almost immediately. However here testing the impact of the change can have serious effects. The software fix for the Boeing 737 Max is not yet proven and delivered.
Therefore, I would like to conclude that in the past decade we learned in the PLM-domain to work in a Coordinated manner – leaving silos mostly in place.
Next week I will look forward to our challenging upcoming decade. Topics on my list for the next decade are:
- From Coordinated to Connected – Generation Change
- Sustainability of our Earth (and how PLM can help)
- Understanding our human behavior to understand how to explain PLM to your execs- PI PLMx London 2020
- All combined with restoring trust in science
I wish you all a happy and healthy New Year – take time to listen and learn as we need dialogue for the future, not opinions.
See you in 2020
In recent years, more and more PLM customers approached me with questions related to the usage of product information for downstream publishing. To be fair, this is not my area of expertise for the moment. However, with the mindset of a connected enterprise, this topic will come up.
For that reason, I have a strategic partnership with Squadra, a Dutch-based company, providing the same coaching model as TacIT; however, they have their roots in PIM and MDM.
Together we believe we can deliver a meaningful answer on the question: What are the complementary roles of PLM and PIM? In this post, our first joint introduction.
Note: The topic is not new. Already in 2005, Jim Brown from Tech-Clarity published a white-paper: The Complementary Roles of PIM and PLM. This all before digitization and connectivity became massive.
Let’s start with the abbreviations, the TLAs (Three-Letter-Acronyms) and their related domains
PLM – level 1
(Product Lifecycle Management – push)
For PLM, I want to stay close to the current definitions. It is the strategic approach to provide a governance infrastructure to deliver a product to the market. Starting from an early concept phase till manufacturing and in its extended definition also during its operational phase.
The focus with PLM is to reduce time to market by ensuring quality, cost, and delivery through more and more a virtual product definition, therefore being able to decide upfront for the best design choices, manufacturing options with the lowest cost. In the retail world, own-brand products are creating a need for PLM.
The above image is nicely summarizing the expected benefits of a traditional PLM implementation.
MDM (Master Data Management)
When product data is shared in an enterprise among multiple systems, there is a need for Master Data Management (MDM). Master Data Management focuses on a governance approach that information stored in various systems has the same meaning and shared values where relevant.
MDM guards and streamlines the way master data is entered, processed, guarded, and changed within the company, resulting in one single version of the truth and enabling different departments and systems to stay synced regarding their crucial data.
Interestingly, in the not-so-digital world of PLM, you do not see PLM vendors working on an MDM-approach. They do not care about an end-to-end connected strategy yet. I wrote about this topic in 2017 here: Master Data Management and PLM.
PIM (Product Information Management)
The need for PIM starts to become evident when selling products through various business channels. If you are a specialized machine manufacturer, your product information for potential customers might be very basic and based on a few highlights.
However, due to digitization and global connectivity, product information now becomes crucial to be available in real-time, wherever your customers are in the world.
In a competitive world, with an omnichannel strategy, you cannot survive without having your PIM streamlined and managed.
Product Innovation Platforms (PLM – Level 2 – Pull)
With the introduction of Product Innovation Platforms as described by CIMdata and Gartner, the borders of PLM, PIM, and MDM might become vague, as they might be all part of the same platform, therefore reducing the immediate need for an MDM-environment. For example, companies like Propel, Stibo, and Oracle are building a joint PLM-PIM portfolio.
Let’s dive more profound in the two scenarios that we meet the most in business, PLM driving PIM (my comfort zone) and PIM driving the need for PLM (Squadra’s s area of expertise).
PLM driving PIM
Traditionally PLM (Product Lifecycle Management) has been focusing on several aspects of the product lifecycle. Here is an excellent definition for traditional PLM:
PLM is a collection of best practices, dependent per industry to increase product revenue, reduce product-related costs and maximize the value of the product portfolio (source 2PLM)
This definition shows that PLM is a business strategy, not necessarily a system, but an infrastructure/approach to:
- ensure shorter time to market with the right quality (increasing product revenue)
- efficiently (reduce product-related costs – resources and scrap)
- deliver products that bring the best market revenue (maximize the value of the product portfolio)
The information handled by traditional PLM consists mostly of design data, i.e., specifications, manufacturing drawings, 3D Models, and Bill of Materials (physical part definitions) combined with version and revision management. In elaborate environments combined with processes supporting configuration management.
PLM data is more focused on internal processes and quality than on targeting the company’s customers. Sometimes the 3D Design data is used as a base to create lightweight 3D graphics for quotations and catalogs, combining it with relevant sales data. Traditional marketing was representing the voice of the customer.
PLM implementations are more and more providing an enterprise backbone for product data. As a result of this expansion, there is a wish to support sales and catalogs, more efficiently, sharing master data from creation till publishing, combining the product portfolio with sales and service information in a digital way.
In particular, due to globalization, there was a need to make information globally available in different languages without a significant overhead of resources to manage the data or manage the disconnect from the real product data.
Companies that have realized the need for connected data understood that Product Master Data Management is more than only the engineering/manufacturing view. Product Master Data Management is also relevant to the sales and services view. Historically done by companies as a customized extension on their PLM-system, now more and more interfacing with specialized PIM-systems. Proprietary PLM-PIM interfaces exist. Hopefully, with digital transformation, a more standardized approach will appear.
PIM driving the need for PLM
Because of changes in the retail market, the need for information in the publishing processes is also changing. Retailers also need to comply with new rules and legislation. The source of the required product information is often in the design process of the product.
In parallel, there is an ongoing market trend to have more and more private label products in the (wholesale and retail) assortments. This means a growing number of retailers and wholesalers will become producers and will have their own Ideation and innovation process.
A good example is ingredients and recipe information in the food retail sector. This information needs to be provided now by suppliers or by their own brand department that owns the design process of the product. Similar to RoHS or REACH compliance in the industry.
Retail and Wholesale can tackle own brands reasonably well with their PIM systems (or Excels), making use of workflows and product statuses. However, over the years, the information demands have increased, and a need for more sophisticated lifecycle management has emerged and, therefore the need for PLM (in this case, PLM also stands for Private Label Management).
In the image below, illustrates a PLM layer and a PIM layer, all leading towards rich product information for the end-users (either B2B or B2C).
In the fast-moving consumer goods (FMCG) world, most innovative products are coming from manufacturers. They have pipelines with lots of ideas resulting in a limited number of sellable products. In the Wholesale and Retail business, the Private Label development process usually has a smaller funnel but a high pressure on time to market, therefore, a higher need for efficiency in the product data chain.
Technological changes, like 3D Printing, also change the information requirements in the retail and wholesale sectors. 3D printing can be used for creating spare parts on-demand, therefore changing the information flow in processes dramatically. Technical drawings and models that were created in the design process, used for mass production, are now needed in the retail process closer to the end customer.
These examples make it clear that more and more information is needed for publication in the sales process and therefore needs to be present in PIM systems. This information needs to be collected and available during the PLM release process. A seamless connection between the product release and sales processes will support the changing requirements and will reduce errors and rework in on data.
PLM and PIM are two practices that need to go hand in hand like a relay baton in athletics. Companies that are using both tools must also organize themselves in a way that processes are integrated, and data governance is in place to keep things running smoothly.
Conclusion
Market changes and digital transformation force us to work in value streams along the whole product lifecycle ensuring quality and time to market. PLM and PIM will be connected domains in the future, to enable smooth product go-to-market. Important is the use of data standards (PLM and PIM should speak a common language) – best based on industry standards so that cross-company communication on product data is possible.
What do you think? Do you see PLM and PIM getting together too, in your business?
Please share in the comments.
The usage of standards has been a recurring topic the past 10 months, probably came back to the surface at PI PLMx Chicago during the PLM Leaders panel discussion. If you want to refresh the debate, Oleg Shilovitsky posted an overview: What vendors are thinking about PLM standards – Aras, Dassault Systemes, Onshape, Oracle PLM, Propel PLM, SAP, Siemens PLM.
It is clear for vendors when they would actively support standards they reduce their competitive advantage, after all, you are opening your systems to connect to other vendor solutions, reducing the chance to sell adjacent functionality. We call it vendor lock-in. If you think this approach only counts for PLM, I would suggest you open your Apple (iPhone) and think about vendor lock-in for a moment.
Vendors will only adhere to standards when pushed by their customers, and that is why we have a wide variety of standards in the engineering domain.
Take the example of JT as a standard viewing format, heavily pushed by Siemens for the German automotive industry to be able to work downstream with CATIA and NX models. There was a JT-version (v9.5) that reached ISO 1306 alignment, but after that, Siemens changed JT (v10) again to optimize their own exchange scenarios, and the standard was lost.
And as customers did not complain (too much), the divergence continued. So it clear vendors will not maintain standards out of charity as your business does not work for charity either (or do you ?). So I do not blame them is there is no push from their customers to maintain them.
What about standards?
The discussion related to standards flared up around the IpX ConX19 conference and a debate between Oleg & Hakan Kardan (EuroSTEP) where Hakan suggested that PLCS could be a standard data model for the digital thread – you can read Oleg’s view here: Do we need a standard like PLCS to build a digital thread.
Oleg’s opening sentence made me immediately stop reading further as more and more I am tired of this type of framing if you want to do a serious discussion based on arguments. Such a statement is called framing and in particular in politics we see the bad examples of framing.
Standards are like toothbrushes, a good idea, but no one wants to use anyone else’s. The history of engineering and manufacturing software is full of stories about standards.
This opening sentence says all about the mindset related to standards – it is a one-liner – not a fact. It could have been a tweet in this society of experts.
Still later,I read the blog post and learned Oleg has no arguments to depreciate PLCS, however as he does not know the details, he will probably not use it. The main challenge of standards: you need to spend time to understand and adhere to them and agree on following them. Otherwise, you get the same diversion of JT again or similar examples.
However, I might have been wrong in my conclusion as Oleg did some thinking on a Sunday and came with an excellent post: What would happen if PLM Vendors agree about data standards. Here Oleg is making the comparison with a standard in the digital world, established by Google, Microsoft, Yahoo, and Yandex : Schema.org: Evolution of Structured Data on the Web.
There is a need for semantic mapping and understanding in the day-to-day-world, and this understanding makes you realize the same is needed for PLM. That was one of the reasons why I wrote in the past (2015) a series of posts related to the importance of a PLM data model:
All these posts were aimed to help companies and implementers to make the right choices for an item-centric PLM implementation. At that time – 2015, item-centric was the current PLM best practice. I learned from my engagements in the past 15 years, in particular when you have a flexible modeling tool like SmarTeam or nowadays Aras, making the right data model decisions are crucial for future growth.
Who needs standards?
First of all, as long as you stay in your controlled environment, you do not need standards. In particular, in the Aerospace and Automotive industry, the OEMs defined the software versions to be used, and the supply chain had to adhere to their chosen formats. Even this narrow definition was not complete enough as a 3D CAD model needed to be exported for simulation or manufacturing purposes. There was not a single vendor working on a single CAD model definition at that time. So the need for standards emerged as there was a need to exchange data.
Data exchange is the driving force behind standards.
In a second stage also neutral format data storage became an important point – how to save for 75 years an aircraft definition.
Oil & Gas / Building – Construction
These two industries both had the need for standards. The Oil & Gas industry relies on EPC (Engineering / Procurement / Construction) companies that build plants or platforms. Then the owner/operator takes over the operation and needs a hand-over of all the relevant information. However if this information would be delivered in the application-specific formats the EPC companies have used, the owner/operator would require various software environments and skills, just to have access to the data.
Therefore if the data is delivered in a standard format (ISO 15926) and the exchange follows CFIHOS (Capital Facilities Information Hand Over Specification) this exchange can be done more automated between the EPC and Owner/Operator environment, leading to lower overall cost of delivering and maintaining the information combined with a higher quality. For that reason, the Oil & Gas industry has invested already for a long time in standards as their plants/platform have a long lifecycle.
And the same is happening in the construction industry. Initially Autodesk and Bentley were fighting to become the vendor-standard and ultimately the IFC-standard has taken a lot from the Autodesk-world, but has become a neutral standard for all parties involved in a construction project to share and exchange data. In particular for the construction industry, the cloud has been an accelerator for collaboration.
So standards are needed where companies/people exchange information
For the same reason in most global companies, English became the standard language. If you needed to learn all the languages spoken in a worldwide organization, you would not have time for business. Therefore everyone making some effort to communicate in one standard language is the best way to operate.
And this is the same for a future data-driven environment – we cannot afford for every exchange to go to the native format from the receiver or source – common neutral (or winning) standards will ultimately also come up in the world of manufacturing data exchange and IoT.
Companies need to push
This is probably the blocking issue for standards. Developing standards, using standards require an effort without immediate ROI. So why not use vendor-formats/models and create custom point-to-point interface as we only need one or two interfaces? Companies delivering products with a long lifecycle know that the current data formats are not guaranteed for the future, so they push for standards (aerospace/defense/ oil & gas/construction/ infrastructure).
3D PDF Model
Other companies are looking for short term results, and standards are slowing them down. However as soon as they need to exchange data with their Eco-system (suppliers/ customers) an existing standard will make their business more scalable. The lack of standards is one of the inhibitors for Model-Based Definition or the Model-Based Enterprise – see also my post on this topic: Model-Based – Connecting Engineering and Manufacturing
When we would imagine the Digital Enterprise of the future, information will be connected through data streams and models. In a digital enterprise file conversions and proprietary formats will impede the flow of data and create non-value added work. For example if we look to current “Digital Twin” concepts, the 3D-representation of the twin is recreated again instead of a neutral 3D-model continuity. This because companies currently work in a coordinated manner. In perhaps 10 years from now we will reach maturity of a model-based enterprise, which only can exist based on standards. If the standards are based on one dominating platform or based on a merger of standards will be the question.
To discuss this question and how to bridge from the past to the future I am looking forward meeting you at the upcoming PLM Roadmap & PDT 2019 EMEA conference on 13-14 November in Paris, France. Download the program here: PLM for Professionals – Product Lifecycle Innovation
Conclusion
I believe PLM Standards will emerge when building and optimizing a digital enterprise. We need to keep on pushing and actively working for meaningful standards as they are crucial to avoid a lock-in of your data. Potentially creating dead-ends and massive inefficiencies. The future is about connected Eco-systems, and the leanest companies will survive. Standards do not need to be extraordinarily well-defined and can start from a high-level alignment as we saw from schema.org. Keep on investing and contributing to standards and related discussion to create a shared learning path.
Thanks Oleg Shilovitsky to keep the topic alive.
p.s. I had not time to read and process your PLM Data Commodizitation post
Last week I read Verdi Ogewell’s article: PTC puts the Needle to the Digital Thread on Engineering.com where Verdi raised the question (and concluded) who is the most visionary PLM CEO – Bernard Charles from Dassault Systemes or Jim Heppelman from PTC. Unfortunately again, an advertorial creating more haziness around modern PLM than adding value.
People need education and Engineering.com is/was a respected site for me, as they state in their Engineering.com/about statement:
Valuable Content for Busy Engineers. Engineering.com was founded on the simple mission to help engineers be better.
Unfortunately this is not the case in the PLM domain anymore. In June, we saw an article related to the failing PLM migration at Ericsson – see The PLM migration dilemma. Besides the fact that a big-bang migration had failed at Ericsson, the majority of the article was based on rumors and suggestions, putting the sponsor of this article in a better perspective.
Of course, Engineering.com needs sponsoring to host their content, and vendors are willing to spend marketing money on that. However, it would be fairer to mention in a footnote who sponsored the article – although per article you can guess. Some more sincere editors or bloggers mention their sponsoring that might have influenced their opinion.
Now, why did the article PTC puts the Needle to the Digital Thread made me react?
Does a visionary CEO pay off?
It can be great to have a visionary CEO however, do they make the company and its products/services more successful? For every successful visionary CEO, there are perhaps ten failing visionary CEOs as the stock market or their customers did not catch their vision.
There is no lack of PLM vision as Peter Bilello mapped in 2014 when imagining the gaps between vision, available technology, and implementations at companies (leaders and followers). See below:
The tremendous gap between vision and implementation is the topic that concerns me the most. Modern PLM is about making data available across the enterprise or even across the company’s ecosystem. It is about data democratization that allows information to flow and to be presented in context, without the need to recreate this information again.
And here the marketing starts. Verdi writes:
PTC’s Internet of Things (IoT), Industrial Internet of Things (IIoT), digital twin and augmented reality (AR) investments, as well as the collaboration with Rockwell Automation in the factory automation arena, have definitely placed the company in a leading position in digital product realization, distribution and aftermarket services
With this marketing sentence, we are eager to learn why
“With AR, for example, we can improve the quality control of the engines,” added Volvo Group’s Bertrand Felix, during an on-stage interview by Jim Heppelmann. Heppelmann then went down to a Volvo truck with the engine lifted out of its compartment. Using a tablet, he was able to show how the software identified the individual engine, the parts that were included, and he could also pick up the 3D models of each component and at the same time check that everything was included and in the right place.
Impressive – is it real?
The point is that this is the whole chain for digital product realization–development and manufacturing–that the Volvo Group has chosen to focus on. Sub-components have been set up that will build the chain, much is still in the pilot stage, and a lot remains to be done. But there is a plan, and the steps forward are imminent.
OK, so it is a pilot, and a lot remains to be done – but there is a plan. I am curious about the details of that plan, as a little later, we learn from the CAD story:
The Pro/ENGINEER “inheritor” Creo (engine, chassis) is mainly used for CAD and creation of digital twins, but as previously noted, Dassault Systémes’ CATIA is also still used. Just as in many other large industrial organizations, Autodesk’s AutoCAD is also represented for simpler design solutions.
There goes the efficient digital dream. Design data coming from CATIA needs to be recreated in Creo for digital twin support. Data conversion or recreation is an expensive exercise and needs to be reliable and affordable as the value of the digital twin is gone once the data is incorrect.
In a digital enterprise, you do not want silos to work with their own formats, you want a digital thread based on (neutral) models that share metadata/parameters from design to service.
So I dropped the article and noticed Oleg had already commented faster than me in his post: Does PLM industry need a visionary pageant? Oleg refers also to CIMdata, as they confirmed in 2018 that the concept of a platform for product innovation (PIP), or the beyond PLM is far from reality in companies. Most of the time, a PLM implementation is mainly a beyond PDM environment, not really delivering product data downstream.
I am wholly aligned with Oleg’s technical conclusion:
What is my(Oleg’s) conclusion? PLM industry doesn’t need another round of visionary pageants. I’d call democratization, downstream usage and openness as biggest challenges and opportunities in PLM applications. Recent decades of platform development demonstrated the important role network platforms played in the development of global systems and services. PLM paradigm change from isolated vertical platforms to open network services required to bring PLM to the next level. Just my thoughts..
My comments to Oleg’s post:
(Jos) I fully agree we do not need more visionary PLM pageants. It is not about technology and therefore I have to disagree with your point about Aras. You call it democratization and openness of data a crucial point – and here I agree – be it that we probably disagree about how to reach this – through standards or through more technology. My main point to be made (this post ) is that we need visionary companies that implement and rethink their processes and are willing to invest resources in that effort. Most digital transformation projects related to PLM fail because the existing status quo/ middle management has no incentive to change. More thoughts to come
And this is the central part of my argumentation – it is not about technology (only).
Organizational structures are blocking digital transformation
Since 2014 I have been following several larger manufacturing companies on their path from pushing products to the market in a linear mode towards a customer-driven, more agile, fast responding enterprise. As this is done by taking the benefit of digital technologies, we call this process: digital transformation.
(image depicting GE’s digital thread)
What I have learned from these larger enterprises, and both Volvo Trucks and GE as examples, is that there is a vision for an end result. For GE, it is the virtual twin of their engines monitored and improved by their Predix platform. For Volvo Trucks, we saw the vision in the quote from Verdi’s article before.
However, these companies are failing in creating a horizontal mindset inside their companies. Data can only be efficiently used downstream if there is a willingness to work on collecting the relevant data upstream and delivering this information in an accessible format, preferably data-driven.
The Middle Management Dilemma
And this leads to my reference to middle management. Middle managers learn about the C-level vision and are pushed to make this vision happen. However, they are measured and driven to solve these demands, mainly within their own division or discipline. Yes, they might create goodwill for others, but when it comes to money spent or changing people’s responsibilities, the status quo will remain.
I wrote about this challenge in The Middle Management dilemma. Digital transformation, of course, is enabled by digital technologies, but it does not mean the technology is creating the transformation. The crucial fact lies in making companies more flexible in their operations, yet establishing better and new contacts with customers.
It is interesting to see that the future of businesses is looking into agile, multidisciplinary teams that can deliver incremental innovations to the company’s portfolio. Somehow going back to the startup culture inside a more significant enterprise. Having worked with several startups, you see the outcome-focus as a whole in the beginning – everyone contributes. Then when the size of the company grows, middle-management is introduced, and most likely silos are created as the middle management gets their own profit & loss targets.
Digital Transformation myths debunked
This week Helmut Romer (thanks Helmut) pointed me to the following HBR-article: Digital does not need to be disruptive where the following myths are debunked:
- Myth: Digital requires radical disruption of the value proposition.
Reality: It usually means using digital tools to better serve the known customer need. - Myth: Digital will replace physical
Reality: It is a “both/and.” - Myth: Digital involves buying start-ups.
Reality: It involves protecting start-ups. - Myth: Digital is about technology.
Reality: It’s about the customer - Myth: Digital requires overhauling legacy systems.
Reality: It’s more often about incremental bridging.
If you want to understand these five debunked myths, take your time to read the full article, which very much aligned with my argumentation, albeit that my focus is more on the PLM domain.
Conclusions
Vendor sponsoring at Engineering.com has not improved the quality of their PLM articles and creates misleading messages. Especially as the sponsor is not mentioned, and the sponsor is selling technology – the vision gap is too big with reality to compete around a vision.
Transforming companies to take benefit of new technologies requires an end-to-end vision and mindset based on achievable, incremental learning steps. The way your middle management is managed and measured needs to be reworked as the focus is on horizontal flow and understanding of customer/market-oriented processes.
In my previous post, the PLM blame game, I briefly mentioned that there are two delivery models for PLM. One approach based on a PLM system, that contains predefined business logic and functionality, promoting to use the system as much as possible out-of-the-box (OOTB) somehow driving toward a certain rigidness or the other approach where the PLM capabilities need to be developed on top of a customizable infrastructure, providing more flexibility. I believe there has been a debate about this topic over more than 15 years without a decisive conclusion. Therefore I will take you through the pros and cons of both approaches illustrated by examples from the field.
PLM started as a toolkit
The initial cPDM/PLM systems were toolkits for several reasons. In the early days, scalable connectivity was not available or way too expensive for a standard collaboration approach. Engineering information, mostly design files, needed to be shared globally in an efficient manner, and the PLM backbone was often a centralized repository for CAD-data. Bill of Materials handling in PLM was often at a basic level, as either the ERP-system (mostly Aerospace/Defense) or home-grown developed BOM-systems(Automotive) were in place for manufacturing.
Depending on the business needs of the company, the target was too connect as much as possible engineering data sources to the PLM backbone – PLM originated from engineering and is still considered by many people as an engineering solution. For connectivity interfaces and integrations needed to be developed in a time that application integration frameworks were primitive and complicated. This made PLM implementations complex and expensive, so only the large automotive and aerospace/defense companies could afford to invest in such systems. And a lot of tuition fees spent to achieve results. Many of these environments are still operational as they became too risky to touch, as I described in my post: The PLM Migration Dilemma.
The birth of OOTB
Around the year 2000, there was the first development of OOTB PLM. There was Agile (later acquired by Oracle) focusing on the high-tech and medical industry. Instead of document management, they focused on the scenario from bringing the BOM from engineering to manufacturing based on a relatively fixed scenario – therefore fast to implement and fast to validate. The last point, in particular, is crucial in regulated medical environments.
At that time, I was working with SmarTeam on the development of templates for various industries, with a similar mindset. A predefined template would lead to faster implementations and therefore reducing the implementation costs. The challenge with SmarTeam, however, was that is was very easy to customize, based on Microsoft technology and wizards for data modeling and UI design.
This was not a benefit for OOTB-delivery as SmarTeam was implemented through Value Added Resellers, and their major revenue came from providing services to their customers. So it was easy to reprogram the concepts of the templates and use them as your unique selling points towards a customer. A similar situation is now happening with Aras – the primary implementation skills are at the implementing companies, and their revenue does not come from software (maintenance).
The result is that each implementer considers another implementer as a competitor and they are not willing to give up their IP to the software company.
SmarTeam resellers were not eager to deliver their IP back to SmarTeam to get it embedded in the product as it would reduce their unique selling points. I assume the same happens currently in the Aras channel – it might be called Open Source however probably it is only high-level infrastructure.
Around 2006 many of the main PLM-vendors had their various mid-market offerings, and I contributed at that time to the SmarTeam Engineering Express – a preconfigured solution that was rapid to implement if you wanted.
Although the SmarTeam Engineering Express was an excellent sales tool, the resellers that started to implement the software began to customize the environment as fast as possible in their own preferred manner. For two reasons: the customer most of the time had different current practices and secondly the money come from services. So why say No to a customer if you can say Yes?
OOTB and modules
Initially, for the leading PLM Vendors, their mid-market templates were not just aiming at the mid-market. All companies wanted to have a standardized PLM-system with as little as possible customizations. This meant for the PLM vendors that they had to package their functionality into modules, sometimes addressing industry-specific capabilities, sometimes areas of interfaces (CAD and ERP integrations) as a module or generic governance capabilities like portfolio management, project management, and change management.
The principles behind the modules were that they need to deliver data model capabilities combined with business logic/behavior. Otherwise, the value of the module would be not relevant. And this causes a challenge. The more business logic a module delivers, the more the company that implements the module needs to adapt to more generic practices. This requires business change management, people need to be motivated to work differently. And who is eager to make people work differently? Almost nobody, as it is an intensive coaching job that cannot be done by the vendors (they sell software), often cannot be done by the implementers (they do not have the broad set of skills needed) or by the companies (they do not have the free resources for that). Precisely the principles behind the PLM Blame Game.
OOTB modularity advantages
The first advantage of modularity in the PLM software is that you only buy the software pieces that you really need. However, most companies do not see PLM as a journey, so they agree on a budget to start, and then every module that was not identified before becomes a cost issue. Main reason because the implementation teams focus on delivering capabilities at that stage, not at providing value-based metrics.
The second potential advantage of PLM modularity is the fact that these modules supposed to be complementary to the other modules as they should have been developed in the context of each other. In reality, this is not always the case. Yes, the modules fit nicely on a single PowerPoint slide, however, when it comes to reality, there are separate systems with a minimum of integration with the core. However, the advantage is that the PLM software provider now becomes responsible for upgradability or extendibility of the provided functionality, which is a serious point to consider.
The third advantage from the OOTB modular approach is that it forces the PLM vendor to invest in your industry and future needed capabilities, for example, digital twins, AR/VR, and model-based ways of working. Some skeptic people might say PLM vendors create problems to solve that do not exist yet, optimists might say they invest in imagining the future, which can only happen by trial-and-error. In a digital enterprise, it is: think big, start small, fail fast, and scale quickly.
OOTB modularity disadvantages
Most of the OOTB modularity disadvantages will be advantages in the toolkit approach, therefore discussed in the next paragraph. One downside from the OOTB modular approach is the disconnect between the people developing the modules and the implementers in the field. Often modules are developed based on some leading customer experiences (the big ones), where the majority of usage in the field is targeting smaller companies where people have multiple roles, the typical SMB approach. SMB implementations are often not visible at the PLM Vendor R&D level as they are hidden through the Value Added Reseller network and/or usually too small to become apparent.
Toolkit advantages
The most significant advantage of a PLM toolkit approach is that the implementation can be a journey. Starting with a clear business need, for example in modern PLM, create a digital thread and then once this is achieved dive deeper in areas of the lifecycle that require improvement. And increased functionality is only linked to the number of users, not to extra costs for a new module.
However, if the development of additional functionality becomes massive, you have the risk that low license costs are nullified by development costs.
The second advantage of a PLM toolkit approach is that the implementer and users will have a better relationship in delivering capabilities and therefore, a higher chance of acceptance. The implementer builds what the customer is asking for.
However, as Henry Ford said, if I would ask my customers what they wanted, they would ask for faster horses.
Toolkit considerations
There are several points where a PLM toolkit can be an advantage but also a disadvantage, very much depending on various characteristics of your company and your implementation team. Let’s review some of them:
Innovative: a toolkit does not provide an innovative way of working immediately. The toolkit can have an infrastructure to deliver innovative capabilities, even as small demonstrations, the implementation, and methodology to implement this innovative way of working needs to come from either your company’s resources or your implementer’s skills.
Uniqueness: with a toolkit approach, you can build a unique PLM infrastructure that makes you more competitive than the other. Don’t share your IP and best practices to be more competitive. This approach can be valid if you truly have a competing plan here. Otherwise, the risk might be you are creating a legacy for your company that will slow you down later in time.
Performance: this is a crucial topic if you want to scale your solution to the enterprise level. I spent a lot of time in the past analyzing and supporting SmarTeam implementers and template developers on their journey to optimize their solutions. Choosing the right algorithms, the right data modeling choices are crucial.
Sometimes I came into a situation where the customer blamed SmarTeam because customizations were possible – you can read about this example in an old LinkedIn post: the importance of a PLM data model
Experience: When you plan to implement PLM “big” with a toolkit approach, experience becomes crucial as initial design decisions and scope are significant for future extensions and maintainability. Beautiful implementations can become a burden after five years as design decisions were not documented or analyzed. Having experience or an experienced partner/coach can help you in these situations. In general, it is sporadic for a company to have internally experienced PLM implementers as it is not their core business to implement PLM. Experienced PLM implementers vary from size and skills – make the right choice.
Conclusion
After writing this post, I still cannot write a final verdict from my side what is the best approach. Personally, I like the PLM toolkit approach as I have been working in the PLM domain for twenty years seeing and experiencing good and best practices. The OOTB-box approach represents many of these best practices and therefore are a safe path to follow. The undecisive points are who are the people involved and what is your business model. It needs to be an end-to-end coherent approach, no matter which option you choose.
After my previous post about the PLM migration dilemma, I had several discussions with peers about why this PLM bad news creates so much debate. Of course, I can publish a failure story for every PLM vendor if I want. However, the reality is that the majority of PLM implementations do not fail.
Yes, they can cause discomfort or friction in an organization, as implementing the tools often forces people to work differently. And often, operating differently is not anticipated by the (middle) management and causes a mismatch in the people, process & tools paradigm.
So we love bad news in real life. We talk about terrorism, while meanwhile, many people are dying through guns, cars, and even the biggest killer, mosquitos.
Fear stories sell better than success stories, and in particular, in the world of PLM Vendors, every failure of the competition is enlarged. However, more actors are involved in a PLM implementation, and if PLM systems were that bad, they would not exist anymore and be replaced by ………?
Who to blame – the vendor?
Of cou
rse, it is the easiest way to blame the vendor as their marketing promises to solve all problems. However, from a distance to the traditional PLM vendor community, you see they are in a rat race to deliver the latest and greatest technology ahead of their competition, often driven by some significant customers.
Their customers are buying the vision and expect it to be ready and industrialized, which is not the case – look at the digital twin hype or AI (Artificial Intelligence).
Released PLM software is not at the same maturity compared to office applications. Office applications do not innovate so much and have thousands of users during a beta cycle and no dependency on processes.
Most PLM vendors are happy when a few customers jump on their latest release, combined with the fact that implementations of the most recent version are not yet a push on the button. However, this might change long-term if PLM Vendors can deliver cloud-based solutions.
PLM implementations within the same industry might look the same but often vary significantly due to existing practices, which will not change due to the tool. So there is a need for customization or configuration.
PLM systems with strong business rules inside their core might more and more develop towards configuration, whereas PLM toolkit-like systems might focus on ease of customization. But, of course, both approaches have pros and cons (in another blog post, perhaps).
Another topic to blame the vendor is the lack of openness. You hear it in many discussions. If vendor X were open, they would not lock the data – a typical marketing slogan. If PLM vendors were completely open, to which standards should they adhere? Every PLM has its preferred collection of tools together – if you stay within their portfolio, you have a minimum of compatibility or interface issues.
This logic started already with SAP in the previous century. For PLM vendors, there is no business model for openness. For example, the SmarTeam APIs for connecting and extracting data are free of charge, leading to no revenue for the vendor and significant revenue for service providers. They can build any type of interface/solution without any license costs.
In the end, when the PLM vendor has no sustainable revenue, the vendor will disappear, as we had seen between 2000 and 2010 when several stand-alone PLM systems disappeared.
So yes, we can blame PLM vendors for their impossible expectations – coming to realistic expectations related to capabilities and openness is probably the biggest challenge.
Who to blame – the implementer?
The second partner in a PLM implementation is the implementation partner, often a specialized company related to the PLM vendor. There are two types of implementation partners: strategic and system integrators.
Let’s see where we can blame them.
Strategic partners, the consultancy firms, often have a good relationship with the management; they help the company to shape its future strategy, including PLM. You can blame this type of company for their lack of connection to the actual business. What is the impact on the organization to implement a specific strategy, and what does this mean for current or future PLM?
Strategic partners should be the partner to support business change management as they are likely to have experience with other companies. Unfortunately, this type of company does not have significant skills in PLM as the PLM domain is just a tiny subset of the whole potential business strategy.
You can blame them that they help build a vision/strategy but fail to create a consistent connection to the field.
Implementation partners, the system integrators, are usually specialized in one or two PLM vendor’s software suites, although the smaller the implementation partner, the less broad their implementation skills. These implementation partners sometimes have built their own PLM best practices for a specific vendor and use this as a sales argument. Others blindly follow what the vendor is promoting or what the customer is asking for.
They will do anything you request as long as they get paid. The larger ones have loads of resources for offshore deliveries – the challenge you see here is that it might look cheap; however, it becomes expensive if there is no apparent convergence of the deliverables.
As I mentioned, they will never say No to a customer and claim to fill all the “gaps” in the PLM environment.
You can blame implementation partners that their focus is on making money from services. And they are right; your company needs to be profitable to remain in business. It is like lawyers; they will invoice you based on their efforts. And the less you take on your plate, the more they will do for you.
The challenge for both consultancy partners and system integrators is to find a balance between experienced people who make it happen and educating juniors to become experts. Often the customer pays for the education of these juniors.
Who to blame – your company?
If your company is implementing PLM, then probably the perception is that you made all the effort to make it successful. You followed the strategic consultants’ advice, selected the best PLM Vendor and system integrator, and created a budget – so what could go wrong?
This all depends on your company’s ambition and scope for PLM.
Implementing the as-is processes
This might work out if your PLM implementation is just there to automate existing practices and store data in a central location. And this is most of the time when PLM implementations are successful. You know what to expect, and your system integrator knows what to expect.
This type of project can run close to budget, and some system integrators might be tempted to offer a fixed price. I am not a fan of fixed-priced projects, as you never know exactly what needs to be done. The system integrator might raise the target price by 20 – 40 % to cover their risk, or you, as a company, might select the cheapest bid – another guarantee for failure. A PLM implementation is not a one-time project but an ongoing journey. Therefore your choice needs to be sustainable.
My experience with this type of implementation is that it is easy to blame the companies here too. Often the implementation becomes an IT project, as business people are too busy to run their day-to-day jobs. Therefore, they only incidentally support the PLM project. The result is that at a specific moment, users confronted with the system feel disconnected from the new system – it was better in the past. In particular, configuration management and change processes can become waterproof, leaving no freedom for the users. Then the blaming starts – first the software, then the implementer.
But what if you have an ambitious PLM project as part of a business transformation?
In that case, the PLM platform is just one of the elements to consider. It will be the enabler for new ways of working, enabling customer-centric processes, multi-discipline collaboration, and more. All are related to the digital transformation of the enterprise. Therefore, I mention the PLM platform instead of the PLM system. Future enterprises run on data through connected platforms. The better you can connect your disciplines, the more efficient and faster your company will operate. This as opposed to the coordinated approach, which I have been addressing several times in the past.
A business transformation combines an end-to-end understanding of what to change – from management vision connected to the execution in the field. And as there is not an out-of-the-box template for business transformation, it is crucial a company experiments, evaluates and, when successful, scales up new habits.
Therefore, it is hard to define all the effort for the PLM platform and implementation resources upfront. What is sure is that your company is responsible for that, not an external part. So if it fails, your company is to blame.
Is everyone to blame?
You might feel that everyone is to blame when a PLM implementation fails. I believe that is indeed the case. If you know in advance where all players have their strengths and weaknesses, a PLM implementation should not fail but be balanced with the right resources. Depending on the scope of your PLM implementation, whether it is a consolidation or a transformation, you should take care of all stakeholders participating in the anti-blame game.
The anti-blame game is an exercise where you make sure that the other parties in the game cannot blame you.
- If you are a vendor – do not over commit
- If you are a consultant or system integrator – learn to say NO
- If you are the customer – ensure enough resources are assigned – you own the project. It is your project/transformation.
This has been my job several times, where I was asked to mediate in a stalling PLM implementation. Most of the time, at that time, it was a blame game, missing the target to find a solution that made sense. Here coaching from experienced PLM consultants makes sense.
Conclusion
Most of the time, PLM implementations are successful if the scope is well understood and not transformative. You will not hear much about these projects in the news, as we like bad news.
To avoid bad news challenging, PLM implementations should make sure all parties involved are challenging the others to remain realistic and invest enough. Again, the role of an experienced external coach can help here.
I am writing this post during the Easter weekend in the Netherlands. Easter / Passover / Pascha / are religious festivities that happen around this time, depending on full moons, etc. I am not the expert here, however, what I like about Easter is that is it is an optimistic religious celebration, connecting history, the “dark days,” and the celebration of new life.
Of course, my PLM-twisted brain never stops associating and looking into an analogy, I saw last week a LinkedIn post from Mark Reisig, about Aras ACE 2019 opening with the following statement:
“Digital Transformation – it used to be called PLM,” said Aras CEO Peter Schroer, as he opened the conference with some thoughts around attaining sustainable Digital Transformation and owning the lifecycle.
Was this my Easter Egg surprise? I thought we were in the middle of the PLM Renaissance as some other vendors and consultants talk about this era. Have a look at a recent Engineering.com TV-report: Turning PLM on its head
All jokes aside, the speech from Peter Schroer contained some interesting statements and I want to elaborate on them in this post as the space to comment in LinkedIn is not designed for a long answer.
PLM is Digital Transformation?
In the past few years, there has been a discussion if the acronym PLM (Product Lifecycle Management) is perhaps outdated. PTC claimed thanks to IoT (Internet of Things) now PLM equals IoT, as you can read in Mark Taber’s 2018 guest article in Digital Engineering: IoT Equals PLM.
Note: Mark is PTC’s vice president of marketing and go-to-market marketing according to the bio at the bottom of the article. So a lot of marketing words, which strengthens the believers of the old world, that everything new is probably marketing.
Also during the PDT conferences, we discussed if PLM should be replaced by a new acronym and I participated in that discussion too – my Nov 2018 postWill MBSE be the new PLM instead of IoT? is a reflection of my thoughts at that time.
For me, Digital Transformation is a metamorphosis from a document-driven, sequential processes towards data-driven, iterative processes. The metamorphosis example used a lot at this moment, is the one from Caterpillar towards the Butterfly. This process is not easy when it comes to PLM-related information, as I described in my PI PLMx 2019 London Presentation and blog post: The Challenges of a Connected Ecosystem for PLM. The question is even: Will there be a full metamorphosis at the end or will we keep on working in two different modes of operations?
However, Digital Transformation does not change the PLM domain. Even after a successful digital transformation, there will be PLM. The only significant difference in the future – PLM boarders will not be so evident anymore when implementing capabilities in a system or a platform. The upcoming of digital platforms will dissolve or fade the traditional PLM-mapped capabilities.
You can see these differences already by taking an in-depth look at how Oracle, SAP or Propel address PLM. Each of them starts from a core platform with different PLM-flavored extensions, sometimes very different from the traditional PLM Vendors. So Digital transformation is not the replacement of PLM.
Back to Peter Schroer’s rebuttal of some myths. Note: DX stands for Digital Transformation
Myth #1: DX leverages disruptive tech
Peter Schroer:
It’s easy to get excited about AI, AR, and the 3D visual experience. However, let’s be real. The first step is to get rid of your spreadsheets and paper documentation – to get an accurate product data baseline. We’re not just talking a digital CAD model, but data that includes access to performance data, as-built parts, and previous maintenance work history for everyone from technicians to product managers
Here I am fully aligned with Peter. There are a lot of fancy features discussed by marketing teams, however, when working in the field with companies, the main challenge is to get an organization digital aligned, sharing data accessible along the whole lifecycle with the right quality.
This means you need to have a management team, understanding the need for data governance, data quality and understanding the shift from data ownership to data accountability. This will only happen with the right mix of vision, strategy and the execution of the strategy – marketing does not make it happen
Myth #2: DX results in increased market share, revenue, and profit
Peter Schroer:
Though there’s a lot of talk about it – there isn’t yet any compelling data which proves this to be true. Our goal at Aras is to make our products safer and faster. To support a whole suite of industrial applications to extend your DX strategy quite a bit further.
Here I agree and disagree, depending on the context of this statement. Some companies have gone through a digital transformation and therefore increased their market share, revenue, and profit. If you read books like Leading Transformation or Leading Digital, you will find examples of companies that have gone through successful digital transformations. However, you might also discover that most of these companies haven’t transformed their PLM-domain, but other parts of their businesses.
Also, it is interesting to read a 2017 McKinsey post: The case for digital reinvention, where you will get the confirmation that a lot of digital initiatives did not bring more top-line revenue and most of the times lead to extra costs. Interesting to see where companies focus their digital strategies – picture below:
Where only 2 percent of the respondents were focusing on supply chains, this is, according to the authors of the article, one of the areas with the highest potential ROI. And digital supply chains are closely related to modern PLM – so this is an area with enough work to do by all PLM practitioners– connecting ecosystems (in real-time)
Myth #3: Market leaders are the most successful at DX
Peter Schroer:
If your company is hugely profitable at the moment, it’s highly likely that your organization is NOT focused on Digital Transformation. The lifespan of S&P 500 companies continuing to shrink below 20 years.
How to Attain Sustainable Digital Transformation
– Stop buying disposable systems. It’s about an adaptable platform – it needs to change as your company changes.
– Think incremental. Do not lose momentum. Continuous change is a multi-phase journey. If you are in or completed phase I, then that means there is a phase II, a phase III, and so on.
– Align people & processes. Mistakes will happen, “the tech side is only 50% of DX” – Aras CEO.
Here I agree with Peter on the business side, be it that some of the current market leaders are already digital. Look at Apple, Google, and Amazon. However, the majority of large enterprises have severe problems with various aspects of a digital transformation as the started in the past before digital technologies became affordable..
Digitization allows information to flow without barriers within an organization, leading to rapid insights and almost direct communication with your customers, your supply chain or other divisions within your company. This drives the need to learn and build new, lean processes and get people aligned to them. Learning to work in a different mode.
And this is extremely difficult for a market leader – as market leader fear for the outside changing world is often not felt. Between the C-level vision and people working in the company, there are several layers of middle management. These layers were created to structure and stabilize the old ways of working.
I wrote about the middle management challenge in my last blog post: The Middle Management dilemma. Almost in the same week there was an article from McKinsey: How companies can help midlevel managers navigate agile transformations.
Conclusion: It is not (only) about technology as some of the tech geeks may think.
Conclusion
Behind the myths addressed by Peter Schroer, there is a complex transformation on-going. Probably not a metamorphosis. With the Easter spirit in mind connected to PLM, I believe digital transformations are possible – Not as a miracle but driven by insights into all aspects. I hope this post gave you some more ideas and please read the connected articles – they are quite relevant if you want to discover what’s below the surface.
Jos Voskuil's Weblog 
Hi Jos, Knowing your background in methodology and education, I wanted to share a longer article with you: “What is…
Interesting reflection, Jos. In my experience, the situation you describe is very recognizable. At the company where I work, sustainability…
[…] (The following post from PLM Green Global Alliance cofounder Jos Voskuil first appeared in his European PLM-focused blog HERE.) […]
[…] recent discussions in the PLM ecosystem, including PSC Transition Technologies (EcoPLM), CIMPA PLM services (LCA), and the Design for…
Jos, all interesting and relevant. There are additional elements to be mentioned and Ontologies seem to be one of the…