You are currently browsing the tag archive for the ‘Product lifecycle management’ tag.
After the first episode of “The PLM Doctor is IN“, this time a question from Helena Gutierrez. Helena is one of the founders of SharePLM, a young and dynamic company focusing on providing education services based on your company’s needs, instead of leaving it to function-feature training.
I might come back on this topic later this year in the context of PLM and complementary domains/services.
Now sit back and enjoy.
Note: Due to a technical mistake Helena’s mimic might give you a “CNN-like” impression as the recording of her doctor visit was too short to cover the full response.
PLM and Startups – is this a good match?
Relevant links discussed in this video
Marc Halpern (Gartner): The PLM maturity table
VirtualDutchman: Digital PLM requires a Model-Based Enterprise
Conclusion
I hope you enjoyed the answer and look forward to your questions and comments. Let me know if you want to be an actor in one of the episodes.
The main rule: A single open question that is puzzling you related to PLM.
First of all, thank you for the overwhelming response to the survey that I promoted last week: PLM 2021– your goals? It gave me enough inspiration and content to fill the upcoming months.
The first question of the survey was dealing with complementary practices or systems related to a traditional PLM-infrastructure.
As you can see, most of you are curious about Digital Twin management 68 % (it is hype). Second best are Configuration Management, Product Configuration Management and Supplier Collaboration Management, all with 58% of the votes. Click on the image to see the details. Note: you could vote for more than one topic.
Product Configuration Management
Therefore, I am happy to share this blog space with Configit’s CTO, Henrik Hulgaard. Configit is a company specialized in Product Configuration Management, or as they call it, Configuration Lifecycle Management (CLM).
Recently Henrik wrote an interesting article on LinkedIn: How to achieve End-To-End Configuration. A question that I heard several times from my clients. How to align the selling and delivery of configurable products, including sales, engineering and manufacturing?
Configit – the company / the mission
Henrik, thanks for helping me explaining the complementary value of end-to-end Product Configuration Management to traditional PLM systems. First of all, can you give a short introduction to Configit as a company and the unique value you are offering to your clients?
Hi Jos, thank you for having me. Configit has worked with configuration challenges for the last 20 years. We are approximately 200 people and have offices in Denmark, Germany, India, and in the US (Atlanta and Detroit) and work with some of the world’s largest manufacturing companies.
We are founded on patented technology, called Virtual Tabulation. The YouTube movie below explains the term Virtual Tabulation.
Virtual Tabulation compiles EVERY possible configuration scenario and then compresses that data into a very small file so that it can be used by everyone in your team.
Virtual Tabulations enables important capabilities such as:
- Consolidation of all configuration data, both Engineering and Sales related, into single-source-of-truth.
- Effortless maintenance of complicated rule data.
- Fast and error-free configuration engine that provides perfect guidance to the customer across multiple platforms and channels..
As the only vendor, Configit provides a configuration platform that fully supports end-to-end configuration processes, from early design and engineering, over sales and manufacturing to support and service configurable products.
This is what we understand by Configuration Lifecycle Management (CLM).
Why Configuration Lifecycle Management?
You have introduced the term Configuration Lifecycle Management – another TLA (Three Letter Acronym) and easy pronounce. However, why would a company being interested to implement Configuration Lifecycle Management (CLM)?
CLM is a way to break down the siloed systems traditionally found in manufacturing companies where products are defined in a PLM system, sold using a CRM/CPQ system, manufactured using an ERP system and serviced by typically ad-hoc and home-grown systems. A CLM system feeds these existing systems with an aligned and consistent view of what variants of a configurable product is available.
Organizations obtain several benefits when aligning across functions on what product variants it offers:
- Engineering: faster time-to-market, optimized variability, and the assurance to only engineer products that are sold
- Sales: reducing errors, making sure that what gets quoted is accurate, and reducing the time to close the deal. The configurator provides current, up-to-date, and accurate information.
- Manufacturing: reducing errors and production stoppages due to miss-builds
- Service: accurate information about the product’s configuration. The service technician knows precisely what capabilities to expect on the particular product to be serviced.
For example, one of our customers experienced a 95% reduction in the time – from a year to two weeks – it took them to create the configuration models needed to build and sell their products. This reduction meant a significant reduction in time to market and allowed additional product lines to be introduced.
CLM for everybody?
I can imagine that companies with products that are organized for mass-production still wanting to have the mindset of being as flexible as possible on the sales side. What type of companies would benefit the most from a CLM approach?
Any company that offers customized or configurable products or services will need to ensure that what is engineered is aligned with what is sold and serviced. Our customers typically have relatively high complexity with hundreds to thousands of configuration parameters.
CLM is not just for automotive companies that have high volume and high complexity. Many of our customers are in industrial components and machinery, offering complex systems and services. A couple of examples:
Philips Healthcare sells advanced scanners to hospitals and uses CLM to ensure that what is sold is aligned with what can be offered. They also would like to move to sell scanners as a service where the hospital may pay per MR scan.
Thyssenkrupp Elevators sell elevators that are highly customizable based on the needs and environment. The engineering rules start in the CAD environment. They are combined with commercial rules to provide guidance to the customer about valid options.
CLM and Digital Transformation
For me, CLM is an excellent example of what modern, digital enterprises need to do. Having product data available along the whole lifecycle to make real-time decisions. CLM is a connecting layer that allows companies to break the siloes between marketing, sales, engineering and operations. At C-level get excited by that idea as I can see the business value.
Now, what would you recommend realizing this idea?
- The first step is to move away from talking about parts and instead talk about features when communicating about product capabilities.
This requires that an organization establishes a common feature “language” (sometimes this is called a master feature dictionary) that is shared across the different functions.
As the feature codes are essential in the communication between the functions, the creation and updating of the feature language must be carefully managed by putting people and processes in place to manage them.
- The next step is typically to make information about valid configurations available in a central place, sometimes referred to as the single source of truth for configuration.
We offer services to expose this information and integrate it into existing enterprise systems such as PLM, ERP and CRM/CPQ. The configuration models may still be maintained in legacy systems. Still, they are imported and brought together in the CLM system.
Once consuming systems all share a single configuration engine, the organization may move on to improve on the rule authoring and replace the existing legacy rule authoring applications found in PLM and ERP systems with more modern applications such as Configit Ace.
Customer Example: Connecting Sales, R&D and ERP
As can be seen from above, these steps all go across the functional silos. Thus, it is essential that the CLM journey has top-level management support, typically from the CIO.
COVID-19?
Related to COVID-19, I believe companies realized that they had to reconsider their supply chains due to limiting dependencies on critical suppliers. Is this an area where Configit would contribute too?
The digital transformation that many manufacturing companies have worked on for years clearly has been accelerated by the COVID-19 situation, and indeed they might now start to encode information about the critical suppliers in the rules.
We have seen this happening in 2011 with the tsunami in Japan when suddenly supplier could not provide certain parts anymore. The organization then has to quickly adapt the rules so that the options requiring those parts are no longer available to order.
Therefore, the CLM vision also includes suppliers as configuration knowledge has to be shared across organizations to ensure that what is ordered also can be delivered.
Learning more?
It is clear that CLM is a complementary layer to standard PLM-infrastructures and complementary to CRM and ERP. A great example of what is possible in a modern, digital enterprise. Where can readers find more information?
Configit offers several resources on Configuration Lifecycle Management on our website, including our blog, webinars and YouTube videos, e.g., Tech Chat on Manufacturing and Configuration Lifecycle Management (CLM)
Besides these continuous growing resources, there is the whitepaper “Accelerating Digital Transformation in Manufacturing with Configuration Lifecycle Management (CLM)” available here among other whitepapers.
What I have learned
- Configuration Lifecycle Management is relevant for companies that want to streamline their business functions, i.e., sales, engineering, manufacturing, and service. CLM will reduce the number of iterations in the process, reduce costly fixing when trying to align to customer demands, and ultimately create more service offerings by knowing customer existing configurations.
- The technology to implement CLM is there. Configit has shown in various industries, it is possible. It is an example of adding value on top of a digital information infrastructure (CRM, PLM, and ERP)
- The challenge will be on aligning the different functions to agree and align on one standard configuration authority. Therefore, responsibility should lie at the top-level of an organization, likely the modern CIO or CDO.
- I was glad to learn that Henrik stated:
“The first step is to move away from talking about parts and instead talk about features when communicating about product capabilities”.
A topic I will discuss soon when talking about Product & Portfolio Management with PLM.
Conclusion
It was a pleasure to work with Configit, in particular, Henrik Hulgaard, learning more about Configuration Lifecycle Management or whatever you may name it. More important, I hope you find this post insightful for your understanding if and where it applies to your business.
Always feel free to ask more questions related to the complimentary value of PLM and Product Configuration Management(CLM)
In the last two weeks, three events were leading to this post.
First, I read John Stark’s recent book Products2019. A must-read for anyone who wants to understand the full reach of product lifecycle related activities. See my recent post: Products2019, a must-read if you are new to PLM
Afterwards, I talked with John, discussing the lack of knowledge and teaching of PLM, not to be confused by PLM capabilities and features.
Second, I participated in an exciting PI DX USA 2020 event. Some of the sessions and most of the roundtables provided insights to me and, hopefully, many other participants. You can get an impression in the post: The Weekend after PI DX 2020 USA.
A small disappointment in that event was the closing session with six vendors, as I wrote. I know it is evident when you put a group of vendors in the arena, it will be about scoring points instead of finding alignment. Still, having criticism does not mean blaming, and I am always open to having a dialogue. For that reason, I am grateful for their sponsorship and contribution.
Oleg Shilovitsky mentioned cleverly that this statement is a contradiction.
“How can you accuse PLM vendors of having a limited view on PLM and thanking them for their contribution?”
I hope the above explanation says it all, combined with the fact that I grew up in a Dutch culture of not hiding friction, meanwhile being respectful to others.
We cannot simplify PLM by just a better tool or technology or by 3D for everybody. There are so many more people and processes related to product lifecycle management involved in this domain if you want a real conference, however many of them will not sponsor events.
It is well illustrated in John Stark’s book. Many disciplines are involved in the product lifecycle. Therefore, if you only focus on what you can do with your tool, it will lead to an incomplete understanding.
If your tool is a hammer, you hope to see nails everywhere around you to demonstrate your value
The thirds event was a LinkedIn post from John Stark – 16 groups needing Product Lifecycle Knowledge, which for me was a logical follow-up on the previous two events. I promised John to go through these 16 groups and provide my thoughts.
Please read his post first as I will not rewrite what has been said by John already.
CEOs and CTOs
John suggested that they should read his book, which might take more than eight hours. CEOs and CTOs, most of the time, do not read this type of book with so many details, so probably mission impossible.
They want to keep up with the significant trends and need to think about future business (model).
New digital and technical capabilities allow companies to move from a linear, coordinated business towards a resilient, connected business. This requires exploring future business models and working methods by experimenting in real-life, not Proof of Concept. Creating a learning culture and allowing experiments to fail is crucial, as you only learn by failing.
CDO, CIOs and Digital Transformation Executives
They are the crucial people to help the business to imagine what digital technologies can do. They should educate the board and the business teams about the power of having reliable, real-time data available for everyone connected. Instead of standardizing on systems and optimizing the siloes, they should assist and lead in new infrastructure for connected services, end-to-end flows delivered on connected platforms.
These concepts won’t be realized soon. However, doing nothing is a big risk, as the traditional business will decline in a competitive environment. Time to act.
Departmental Managers
These are the people that should worry about their job in the long term. Their current mission might be to optimize their department within its own Profit & Loss budget. The future is about optimizing the information flow for the whole value chain, including suppliers and customers.
I wrote about it in “The Middle Management Dilemma.” Departmental Managers should become more team leaders inspiring and supporting the team members instead of controlling the numbers.
Products Managers
This is a crucial role for the future, assuming a product manager is not only responsible for the marketing or development side of the product but also gets responsibility for understanding what happens with the product during production and sales performance. Understanding the full lifecycle performance and cost should be their mission, supported by a digital infrastructure.
Product Developers
They should read the book Products2019 to be aware there is so much related to their work. From this understanding, a product developer should ask the question:
“What can I do better to serve my internal and external customers ?”
This question will no arise in a hierarchical organization where people are controlled by managers that have a mission to optimize their silo. Product Developers should be trained and coached to operate in a broader context, which should be part of your company’s mission. Too many people complain about usability in their authoring and data management systems without having a holistic understanding of why you need change processes and configuration management.
Product Lifecycle Management (PLM) deployers
Here I have a little bit of the challenge that this might be read as PLM-system users. However, it should be clear that we mean here people using product data at any moment along the product lifecycle, not necessarily in a single system.
This is again related to your company’s management culture. In the ideal world, people work with a purpose and get informed on how their contribution fits the company’s strategy and execution.
Unfortunately, in most hierarchical organizations, the strategy and total overview get lost, and people become measured resources.
New Hires and others
John continues with five other groups within the organization. I will not comment on them, as the answers are similar to the ones above – it is about organization and culture.
Educators and Students
This topic is very close to my heart, and one of the reasons I continue blogging about PLM practices. There is not enough attention to product development methodology or processes. Engineers can get many years of education in specific domains, like product design principles, available tools and technologies, performing physical and logical simulations.
Not so much time is spent on educating current best practices, business models for product lifecycle management.
Check in your country how many vendor-independent methodology-oriented training you can find. Perhaps the only consistent organization I know is CIMdata, where the challenge is that they deliver training to companies after students have graduated. It would be great if education institutes would embed serious time for product lifecycle management topics in their curriculum. The challenge, of course, the time and budget needed to create materials and, coming next, prioritizing this topic on the overall agenda.
I am happy to participate to a Specialized Master education program aiming at the Products and Buildings Digital Engineering Manager (INGENUM). This program organized by Arts Et Metiers in France helps create the overview for understanding PLM and BIM – in the French language as before COVID-19 this was an on-site training course in Paris.
Hopefully, there are more institutes offering PLM eductation – feel free to add them in the comments of this post.
Consultants, Integrators and Software Company Employees
Of course, it would be nice if everyone in these groups understands the total flow and processes within an organization and how they relate to each other. Too often, I have seen experts in a specific domain, for example, a 3D CAD-system having no clue about revisioning, the relation of CAD to the BOM, or the fundamentals of configuration management.
Consultants, Integrators and Software Company Employees have their own challenges as their business model is often looking for specialized skills they can sell to their clients, where a broader and general knowledge will come from experience on-the-job.
And if you are three years working full-time on a single project or perhaps work in three projects, your broader knowledge does not grow fast. You might become the hammer that sees nails everywhere.
For that reason, I recommend everyone in my ecosystem to invest your personal time to read related topics of interest. Read LinkedIn-posts from others and learn to differentiate between marketing messages and people willing to share experiences. Don’t waste your time on the marketing messages and react and participate in the other discussions. A “Like” is not enough. Ask questions or add your insights.
In the context of my personal learning, I mentioned that I participated in the DigitalTwin-conference in the Netherlands this week. Unfortunately, due to the partial lockdown, mainly a virtual event.
I got several new insights that I will share with you soon. An event that illustrated Digital Twin as a buzzword might be hype, however several of the participants illustrated examples of where they applied or plan to apply Digital Twin concepts. A great touch with reality.
Another upcoming conference that will start next week in the PLM Roadmap 2020 – PDT conference. The theme: Digital Thread—the PLM Professionals’ Path to Delivering Innovation, Efficiency, and Quality is not a marketing theme as you can learn from the agenda. Step by step we are learning here from each other.
Conclusion
John Stark started with the question of who should need Product Lifecycle Knowledge. In general, Knowledge is power, and it does not come for free. Either by consultancy, reading or training. Related to Product Lifecycle Management, everyone must understand the bigger picture. For executives as they will need to steer the company in the right direction. For everyone else to streamline the company and enjoy working in a profitable environment where you contribute and can even inspire others.
An organization is like a human body; you cannot have individual cells or organs that optimize themselves only – we have a name for that disease. Want to learn more? Read this poem: Who should be the boss?
This time it is again about learning. Last week, I read John Stark’s book: Products2019: A project to map and blueprint the flow and management of products across the product lifecycle: Ideation; Definition; Realisation; Support of Use; Retirement and Recycling. John, a well-known PLM consultant and writer of academic books related to PLM, wrote this book during his lockdown due to the COVID-19 virus. The challenge with PLM (books) is that it is, in a way boring from the outside. Remember my post: How come PLM and CM are boring? (reprise) ?
This time John wrapped the “boring” part into a story related to Jane from Somerset, who, as part of her MBA studies, is performing a research project for Josef Mayer Maschinenfabrik. The project is to describe for the newly appointed CEO what happens with the company’s products all along the lifecycle.
A story with a cliffhanger:
What happened to Newt from Cleveland?
Seven years in seven weeks
Poor Jane, in seven weeks, she is interviewing people on three sites. Two sites in Germany and one in France, and she is doing over a hundred interviews on her own. I realized that thanks to relation to SmarTeam at that time, it took me probably seven years to get in front of all these stakeholders in a company.
I had much more fun most of the time as you can see below. My engagements were teamwork, where you had some additional social relief after work. Jane works even at the weekends.
However, there are also many similarities. Her daily rhythm during working days. Gasthaus Adler reflects many of the typical guesthouses that I have visited. People staying there with a laptop were signs of the new world. Like Jane, I enjoyed the weissbier and noticed that sometimes overhearing other guests is not good for their company’s reputation. A lot of personal and human experiences are wrapped into the storyline.
Spoiler: Tarzan meets Jane!
Cultural differences
The book also illustrates the cultural difference between countries (Germany/France/US) nicely and even between regions (North & South). Just check the breakfast at your location to see it.
Although most of the people interviewed by Jane contributed to her research, she also meets that either for personal or political reasons, do not cooperate.
Having worked worldwide, including in Asian countries, I learned that understanding people and culture is crucial for successful PLM engagements.
John did an excellent job of merging cultural and human behavior in the book. I am sure we share many similar experiences, as both this book and my blog posts, do not mention particular tools. It is about the people and the processes.
Topics to learn
You will learn that 3D CAD is not the most important topic, as perhaps many traditional vendor-related PDM consultants might think.
Portfolio Management is a topic well addressed. In my opinion, to be addressed in every PLM roadmap, as here, the business goals get connected to the products.
New Product Introduction, a stage-gate governance process, and the importance of Modularity are also topics that pop up in several cases.
The need for innovation, Industry 4.0 and AI (Artificial Intelligene) buzz, the world of software development and the “War for Talent” can all be found in the book.
And I was happy that even product Master Data Management was addressed. In my opinion, not enough companies realize that a data-driven future requires data quality and data governance. I wrote about this topic last year: PLM and PIM – the complementary value in a digital enterprise.
There are fantastic technology terms, like APIs, microservices, Low Code platforms. They all rely on reliable and sharable data.
What’s next
Products2019 is written as the starting point for a sequel. In this book, you quickly learn all the aspects of a linear product lifecycle, as the image below shows
I see an opportunity for Products2020 (or later). What is the roadmap for a company in the future?
How to deal with more data-driven, more agile in their go-to-market strategy, as software, will be more and more defining the product’s capabilities?
How to come from a linear siloed approach towards a horizontal flow of information, market-driven and agile?
Perhaps we will learn what happened with Newt from Cleveland?
Meanwhile, we have to keep on learning to build the future.
My learning continues this week with PI DX USA 2020. Usually, a conference I would not attend as traveling to the USA would have too much impact on my budget and time. Now I can hopefully learn and get inspired – you can do the same! Feel free to apply for a free registration if you are a qualified end-user – check here.
And there is more to learn, already mentioned in my previous post:
- November 4th, the DigitalTwin Conference in the Netherlands – a one day conference in the Central European Timezone – mainly virtual, there will be a small local audience
- November 17-18-19, the CIMdata PLM Road Map & PDT Fall 2020 conference – entirely virtual with short Q&A sessions, targeting both the European as American timezone.
Conclusion
John Stark wrote a great book to understand what is currently in most people’s heads in mid-size manufacturing companies. If you are relatively new to PLM, or if you have only been active in PDM, read it – it is affordable! With my series Learning from the past, I also shared twenty years of experience, more a quick walkthrough, and a more specialized view on some of the aspects of PLM. Keep on learning!
I believe we are almost at the end of learning from the past. We have seen how, from an initial serial CAD-driven approach with PDM, we evolved to PLM-managed structures, the EBOM and the MBOM. Or to illustrate this statement, look at the image below, where I use a Tech-Clarity image from Jim Brown.
The image on the right describes perfectly the complementary roles of PLM and ERP. The image on the left shows the typical PDM-approach. PDM feeding ERP in a linear process. The image on the right, I believe it is from 2004, shows the best practice before digital transformation. PLM is supporting product innovation in an iterative approach, pushing released information to ERP for execution.
As I think in images, I like the concept of a circle for PLM and an arrow for ERP. I am always using those two images in discussions with my customers when we want to understand if a particular activity should be in the PLM or ERP-domain.
Ten years ago, the PLM-domain was conceptually further extended by introducing support for products in operations and service. Similar to the EBOM (engineering) and the MBOM (manufacturing), the SBOM (service) was introduced to support product information for products in operation. In theory a full connected cicle.
Asset Lifecycle Management
At the same time, I was promoting PLM-practices for owners/operators to enhance Asset Lifecycle Management. My first post from June 2010 was called: PLM for Asset Lifecycle Management and Asset Development introduces this approach.
Conceptually the SBOM and Asset Lifecycle Management have a lot in common. There is a design product, in this case, an asset (plant, machine) running in the field, and we need to make sure operators have the latest information about the asset. And in case of asset changes, which can be a maintenance operation, a repair or complete overall, we need to be sure the changes are based on the correct information from the as-built environment. This requires full configuration management.
Asset changes can be based on extensive projects that need to be treated like new product development projects, with a staged approach that can take weeks, months, sometimes years. These activities are typical activities performed in PLM-systems, not in MRO-systems that are designed to manage the actual operation. Again here we see the complementary roles of PLM (iterative) and MRO (execution).
Since 2008, I have worked a lot in this environment, mainly in the nuclear and process industry. If you want to learn more about this aspect of PLM, I recommend looking at the PLMpartner website, where Bjørn Fidjeland, in cooperation with SharePLM, published a course on Plant Information Management. We worked together in several projects and Bjørn has done a great effort to describe the logical model to be used instead of a function-feature story.
Ten years ago, we were not calling this concept the “Digital Twin,” as the aim was to provide end-to-end support of asset information from engineering, procurement, and construction towards operation in a coordinated manner. The breaking point in the relation between the EPCs and Owner/Operators is the data-handover – how much of your IP can/do you expose and what is needed. Nowadays, we would call striving for end-to-end data continuity the Digital Thread.
Hot from the press in this context, CIMdata just published a commentary Managing the Digital Thread in Global Value Chains describing Eurostep’s ShareAspace capabilities and experiences in managing an end-to-end information flow (Digital Thread) in a heterogeneous environment based on exchange standards like ISO 10303-239 PLCS. Their solution is based on what I consider a more modern approach for managing digital continuity compared to the traditional approach I described before. Compare the two images in this paragraph. The first image represents the old/current way with a disconnected handover, the second represents ShareAspace connected approach based on a real digital thread.
The Service BOM
As discussed with Asset Lifecycle Management, there is a disconnect between the engineering disciplines and operations in the field, looking from the point of view of an Asset owner/operator.
Now when we look from the perspective of a manufacturing company that produces assets to be serviced, we can identify a different dataflow and a new structure, the Service BOM (SBOM).
The SBOM provides information on how a product needs to be serviced. What are the parts that require service, and what are the service kits that are possible for that product? For that reason, service engineering should be done in parallel to product engineering. When designing a product, the engineer needs to identify which the wearing parts (always require service in time) and which parts might be serviceable.
There are different ways to look at the SBOM. Conceptually, the SBOM could be created in close relation with the EBOM. At the moment you define your product, you also should specify how the product will be services. See the image below
From this example, it is clear that part standardization and modularization have a considerable benefit for services downstream. What if you have only one serviceable part that applies to many products? The number of parts to have in stock will be strongly reduced instead of having many similar parts that only fit in a single product?
Depending on the type of product, the SBOM can be generic, serving many products in the field. In that case, the company has to deal with catalogs, to be defined in PLM. Or the SBOM can be aligned with the As-Built of a capital product in the field. In that case, the concepts of Asset Lifecycle Management apply. Click on the image to see a clear picture.
The SBOM on its own, in such an environment, will have links to specific documents, service instructions, operating manuals.
If your PLM-system allows it, extending the EBOM and MBOM with an SBOM is not a complex effort. What is crucial to understand is that the SBOM has its own lifecycle, which can even last longer than the active product sold. So sometimes, manufacturing specifications, related to service parts need to be maintained too, creating a link between the SBOM and potential MBOM(s).
ECM = Enterprise Change Management
When I discussed ECM in my previous post in the context of Engineering Change Management, I got the feedback that nowadays, everyone talks about Enterprise Change Management. Engineering Change Management is old school.
In the past, and even in a 2014 benchmark, a customer had two change management systems. One in PLM and one in ERP, and companies were looking into connecting these two processes. Like the BOM-interaction between PLM and ERP, this is technology-wise, never a real problem.
The real problem in such situations was to come to a logical flow of events. Many times the company insisted that every change should start from the ERP-system as we like to standardize. This means that even an engineering change had to be registered first in the ERP-system
Luckily the reach of PLM has grown. PLM is no longer the engineering tool (IT-system thinking). PLM has become the information backbone for product information all along the product lifecycle. Having the MBOM and SBOM available through a PLM-infrastructure allows organizations to streamline their processes.
Aras – digital thread through connected structures
And in this modern environment, enterprise change management might take place mostly in a PLM-infrastructure. The PLM-infrastructure providing a digital thread, as the Aras picture above illustrates, provides the full traceability to support configuration management.
However, we still have to remember that configuration management and engineering change management, first of all, are based on methodology and processes. Next, the combination of tools to be used will vary.
I like to conclude this topic with a quote from Lee Perrin’s comment on my previous blog post
I would add that aerospace companies implemented CM, to avoid fatal consequences to their companies, but also to their flying customers.
PLM provides the framework within which to carry out Configuration Management. CM can indeed be carried out without PLM, as was done in the old paper-based days. As you have stated, PLM makes the whole CM process much more efficient. I think more transparent too.
Conclusion
After nine posts around the theme Learning from the past to understand the future, I walked through the history of CAD, PDM and PLM in a fast mode, pointing to practices and friction points. In the blogging space, it is hard to find this information as most blog posts are coming from software vendors explaining why their tool is needed. Hopefully, these series have helped many of you to understand a broader context. Now I want to focus on the future again in my upcoming blog posts.
Still, feel free to contact me and discuss methodology topics.
Picture by Christi Wijnen – a good friend and photographer in the Netherlands
In the previous seven posts, learning from the past to understand the future, we have seen the evolution from manual 2D drawing handling. Next, the emerge of ERP and CAD followed by data management systems (PDM/PLM) and methodology (EBOM/MBOM) to create an infrastructure for product data from concept towards manufacturing.
Before discussing the extension to the SBOM-concept, I first want to discuss Engineering Change Management and Configuration Management.
ECM and CM – are they the same?
Often when you talk with people in my PLM bubble, the terms Change Management and Configuration Management are mixed or not well understood.
When talking about Change Management, we should clearly distinguish between OCM (Organizational Change Management) and ECM (Engineering Change Management). In this post, I will focus on Engineering Change Management (ECM).
When talking about Configuration Management also here we find two interpretations of it.
The first one is a methodology describing technically how, in your PLM/CAD-environment, you can build the most efficient way connected data structures, representing all product variations. This technology varies per PLM/CAD-vendor, and therefore I will not discuss it here. The other interpretation of Configuration Management is described on Wiki as follows:
Configuration management (CM) is a systems engineering process for establishing and maintaining consistency of a product’s performance, functional, and physical attributes with its requirements, design, and operational information throughout its life.
This is also the area where I will focus on this time.
And as-if great minds think alike and are synchronized, I was happy to see Martijn Dullaart’s recent blog post, referring to a poll and follow-up article on CM.
Here Martijn precisely touches the topic I address in this post. I recommend you to read his post: Configuration Management done right = Product-Centric first and then follow with the rest of this article.
Engineering Change Management
Initially, engineering change management was a departmental activity performed by engineering to manage the changes in a product’s definition. Other stakeholders are often consulted when preparing a change, which can be minor (affecting, for example, only engineering) or major (affecting engineering and manufacturing).
The way engineering change management has been implemented varies a lot. Over time companies all around the world have defined their change methodology, and there is a lot of commonality between these approaches. However, terminology as revision, version, major change, minor change all might vary.
I described the generic approach for engineering change processes in my blog post: ECR / ECO for Dummies from 2010.
The fact that companies have defined their own engineering change processes is not an issue when it works and is done manually. The real challenge came with PDM/PLM-systems that need to provide support for engineering change management.
Do you leave the methodology 100 % open, or do you provide business logic?
I have seen implementations where an engineer with a right-click could release an assembly without any constraints. Related drawings might not exist, parts in the assembly are not released, and more. To obtain a reliable engineering change management process, the company had to customize the PLM-system to its desired behavior.
An exercise excellent for a system integrator as there was always a discussion with end-users that do not want to be restricted in case of an emergency (“we will complete the definition later” / “too many clicks” / “do I have to approve 100 parts ?”). In many cases, the system integrator kept on customizing the system to adapt to all wishes. Often the engineering change methodology on paper was not complete or contained contradictions when trying to digitize the processes.
For that reason, the PLM-vendors that aim to provide Out-Of-The-Box solutions have been trying to predefine certain behaviors in their system. For example, you cannot release a part, when its specifications (drawings/documents) are not released. Or, you cannot update a released assembly without creating a new revision.
These rules speed-up the implementation; however, they require more OCM (Organizational Change Management) as probably naming and methodology has to change within the company. This is the continuous battle in PLM-implementations. In particular where the company has a strong legacy or lack of business understanding, when implementing PLM.
There is an excellent webcast in this context on Minerva PLM TV – How to Increase IT Project Success with Organizational Change Management.
Click on the image or link to watch this recording.
Configuration Management
When we talk about configuration management, we have to think about managing the consistency of product data along the whole product lifecycle, as we have seen from the Wiki-definition before.
Wiki – the configuration Activity Model
Configuration management existed long before we had IT-systems. Therefore, configuration management is more a collection of activities (see diagram above) to ensure the consistency of information is correct for any given product. Consistent during design, where requirements match product capabilities. Consistent with manufacturing, where the manufacturing process is based on the correct engineering specifications. And consistent with operations, meaning that we have the full definition of product in the field, the As-Built, in correct relation to its engineering and manufacturing definition.
Source: Configuration management in aerospace industry
This consistency is crucial for products where the cost of an error can have a massive impact on the manufacturer. The first industries that invested heavily in configuration management were the Aerospace and Defense industries. Configuration management is needed in these industries as the products are usually complex, and failure can have a fatal impact on the company. Combined with many regulatory constraints, managing the configuration of a product and the impact of changes is a discipline on its own.
Other industries have also introduced configuration management nowadays. The nuclear power industry and the pharmaceutical industry use configuration management as part of their regulatory compliance. The automotive industry requires configuration management partly for compliance, mainly driven by quality targets. An accident or a recall can be costly for a car manufacturer. Other manufacturing companies all have their own configuration management strategies, mainly depending on their own risk assessment. Configuration management is a pro-active discipline – it costs money – time, people and potential tools to implement it. In my experience, many of these companies try to do “some” configuration management, always hoping that a real disaster will not happen (or can happen). Proper configuration management allows you to perform reliable impact analysis for any change (image above)
What happens in the field?
When introducing PLM in mid-market companies, often, the dream was that with the new PLM-system configuration, management would be there too.
Management believes the tools will fix the issue.
Partly because configuration management deals with a structured approach on how to manage changes, there was always confusion with engineering change management. Modern PLM-systems all have an impact analysis capability. However, most of the time, this impact analysis only reaches the content that is in the PLM-system. Configuration Management goes further.
If you think that configuration management is crucial for your company, start educating yourselves first before implementing anything in a tool. There are several places where you can learn all about configuration management.
- Probably the best-known organization is IpX (Institute for Process Excellence), teaching the CM2 methodology. Have a look here: CM2 certification and courses
- Closely related to IpX, Martijn Dullaart shares his thoughts coming from the field as Lead Architect for Enterprise Configuration Management at ASML (one of the Dutch crown jewels) in his blog: MDUX
- CMstat, a configuration and data management solution provider, provides educational posts from their perspective. Have a look at their posts, for example, PLM or PDM or CM
- If you want to have a quick overview of Configuration Management in general, targeted for the mid-market, have a look at this (outdated) course: Training for Small and Medium Enterprises on CONFIGURATION MANAGEMENT. Good for self-study to get an understanding of the domain.
To summarize
In regulated industries, Configuration Management and PLM are a must to ensure compliance and quality. Configuration management and (engineering) change management are, first of all, required methodologies that guarantee the quality of your products. The more complex your products are, the higher the need for change and configuration management.
PLM-systems require embedded engineering change management – part of the PDM domain. Performing Engineering Change Management in a system is something many users do not like, as it feels like overhead. Too much administration or too many mouse clicks.
So far, there is no golden egg that performs engineering change management automatically. Perhaps in a data-driven environment, algorithms can speed-up change management processes. Still, there is a need for human decisions.
Similar to configuration management. If you have a PLM-system that connects all the data from concept, design, and manufacturing in a single environment, it does not mean you are performing configuration management. You need to have processes in place, and depending on your product and industry, the importance will vary.
Conclusion
In the first seven posts, we discussed the design and engineering practices, from CAD to EBOM, ending with the MBOM. Engineering Change Management and, in particular, Configuration Management are methodologies to ensure the consistency of data along the product lifecycle. These methodologies are connected and need to be fit for the future – more on this when we move to modern model-based approaches.
Closing note:
While finishing this blog post today I read Jan Bosch’s post: Why you should not align. Jan touches the same topic that I try to describe in my series Learning from the Past ….., as my intention is to make us aware that by holding on to practices from the past we are blocking our future. Highly recommended to read his post – a quote:
The problem is, of course, that every time you resist change, you get a bit behind. You accumulate some business, process and technical debt. You become a little less “fitting” to the environment in which you’re operating
Already five posts since we started looking at the roots of PLM, where every step illustrated that new technical capabilities could create opportunities for better practices. Alternatively, sometimes, these capabilities introduced complexity while maintaining old practices. Where the previous posts were design and engineering-centric, now I want to make the step moving to manufacturing-preparation and the MBOM. In my opinion, if you start to manage your manufacturing BOM in the context of your product design, you are in the scope of PLM.
For the moment, I will put two other related domains aside, i.e., Configuration Management and Configured Products. Note these domains are entirely different from each other.
Some data model principles
In part five, I introduced the need to have a split between a logical product definition and a technical EBOM definition. The logical product definition is more the system or modular structure to be used when configuring solutions for a customer. The technical EBOM definition is, most of the time, a stable engineering specification independent of how and where the product is manufactured. The manufacturing BOM (the MBOM) should represent how the product will be manufactured, which can vary per location and vary over time. Let us look in some of the essential elements of this data model
The Product
The logical definition of the product, which can also be a single component if you are a lower tier-supplier, has an understandable number, like 6030-10B. A customer needs to be able to order this product or part without a typo mistake. The product has features or characteristics that are used to sell the product. Usually, products do not have a revision, as it is a logical definition of a set of capabilities. Most of the time, marketing is responsible for product definition. This would be the sales catalog, which can be connected in a digital PLM environment. Like the PDM-ERP relation, there is a similar discussion related to where the catalog resides—more on the product side later in time.
The EBOM
Related to the product or component in the logical definition, there is an actual EBOM, which represents the technical specification of the product. The image above shows the relation represented by the blue “current” link.
Note: not all systems will support such a data model, and often the marketing sides in managed disconnected from the engineering side. Either in Excel or in a specialized Product Line Engineering (PLE) tools.
We discussed in the previous post that if you want to minimize maintenance, meaning fewer revisions on your EBOM, you should not embed manufacturer-specific parts in your EBOM.
The EBOM typically contains purchase parts and make parts. The purchased parts are sourced based on their specification, and you might have a single source in the beginning. The make parts are entirely under your engineering control, and you define where they are produced and by whom. For the rest, the EBOM might have functional groupings of modules and subassemblies that are defined for reuse by engineering.
Note: An EBOM is the place where multidisciplinary collaboration comes together. This post mainly deals with the mechanical part (as we are looking at the past)
Note: An EBOM can contain multiple valid configurations which you can filter based on a customer or market-specific demand. In this case, we talk about a Configured EBOM or a 150 % EBOM.
The MBOM
The MBOM represents the way the unique product is going to be manufactured. This means the MBOM-structure will represent the manufacturing steps. For each EBOM-purchase-part, the approved manufacturer for that plant needs to be selected. For each make-part in the EBOM, if made in this plant per customer order, the EBOM parts need to be resolved by one or more manufacturing steps combined with purchased materials.
Let us look at some examples:
The flat MBOM
Some companies do not have real machinery anymore in their plants, the product they deliver to the market is only assembled at the best financial location. This means that all MBOM-parts should arrive at the shop floor to be assembled there. As an example, we have plant A below.
Of course, this is a simplified version to illustrate the basics of the MBOM. The flat MBOM only makes sense if the product is straightforward to assemble. Based on the engineering specifications, the assembly drawing(s) people on the shop floor will know what to do.
The engineering definition specifies that the chassis needs to be painted, and fitting the axles requires grease. These quantities are not visible in the EBOM; they will appear in the MBOM. The quantities and the unit of measure are, of course, relevant here.
Note: The exact quantities for paint and grease might be adjusted in the MBOM when a series of Squads have been manufactured.
The MBOM and Bill of Process
Most of the time, a product is manufactured in several process steps. For that reason, the MBOM is closely related to the Bill of Process or the Routing definitions. The image below illustrates the relationship between an MBOM and the operations in a plant.
If we continue with our example of the Squad, let us now assume that the wheels and the axle are joined together in a work cell. In addition, the chassis is painted in a separate cell. The MBOM would look like the image below:
In the image, we see that the same Engineering definition now results in a different MBOM. A company can change the MBOM when optimizing the production, without affecting the engineering definition. In this MBOM, the Axle assembly might also be used in other squads manufactured by the company.
The MBOM and purchased parts
In the previous example, all components for the Squad were manufactured by the same company with the option to produce in Plant A or in Plant B. Now imagine the company also has a plant C in a location where they cannot produce the wheels and axle assembly. Therefore plant C has to “purchase” the Wheel-Axle assembly, and lucky for them plant B is selling the Wheel+Axle assembly to the market as a product.
The MBOM for plant C would look like the image below:
For Plant C, they will order the right amount of the Wheel+Axle product, according to its specifications (HF-D240). How the Wheel+Axle product is manufactured is invisible for Plant C, the only point to check is if the Wheel+Axle product complies with the Engineering Definition and if its purchase price is within the target price range.
Why this simple EBOM-MBOM story?
For those always that have been active in the engineering domain, a better understanding of the information flow downstream to manufacturing is crucial. Historically this flow of information has been linear – and in many companies, it is still the fact. The main reason for that lies in the fact that engineering had their own system (PDM or PLM), and manufacturing has their own system (ERP).
Engineers did their best to provide the best engineering specification and release the data to ERP. In the early days, as discussed in Part 4, the engineering specification was most of the time based on a kind of hybrid BOM containing engineering and manufacturing parts already defined.
Next, manufacturing engineering uses the engineering specifications to define the manufacturing BOM in the ERP system. Based on the drawings and parts list, they create a preferred manufacturing process (MBOM and BOP) – most of the time, a manual process. Despite the effort done by engineering, there might be a need to change the product. A different shape or dimension make manufacturing more efficient or done with existing tooling. This means an iteration, which causes delays and higher engineering costs.
The first optimization invented was the PDM-ERP interface to reduce the manual work and introduction of typos/misunderstanding of data. This topic was “hot” between 2000 and 2010, and I visited many SmarTeam customers and implementers to learn and later explain that this is a mission impossible. The picture below says it all.
We have an engineering BOM (with related drawings). Through an interface, this EBOM will be restructured into a manufacturing BOM, thanks to all kinds of “clever” programming based on particular attributes. Discussed in Part 3
The result, however, was that the interface was never covering all situations and became the most expensive part of the implementation.
Good business for the implementing companies, bad for the perception of PDM/PLM.
The lesson learned from all these situations: If you have a PLM-system that can support both the EBOM and MBOM in the same environment, you do not need this complex interface anymore. You can still use some automation to move from an EBOM to an MBOM.
However, three essential benefits come from this approach
- Working in a single environment allows manufacturing engineers to work directly in the context of the EBOM, proposing changes to engineering in the same environment and perform manual restructuring on the MBOM as programming logic does not exist. Still, compare tools will ensure all EBOM-parts are resolved in the manufacturing definition.
- All product Intellectual Property is now managed in a single environment. There is no scattered product information residing in local ERP-systems. When companies moved towards multiple plants for manufacturing, there was the need for a centralized generic MBOM to be resolved for the local plant (local suppliers / local plant conditions). Having the generic MBOM and Bill of Process in PLM was the solution.
- When engineers and manufacturing engineers work in the same environment, manufacturing engineering can start earlier with the manufacturing process definition, providing early feedback to engineering even when the engineering specification has not been released. This approach allows real concurrent engineering, reducing time to market and cost significantly
Conclusion
Again 1600 words this time. We are now at the stage that connecting the EBOM and the MBOM in PLM has become a best practice in most standard PLM-systems. If implemented correctly, the interface to ERP is no longer on the critical path – the technology never has been the limitation – it is all about methodology.
Next time a little bit more on advanced EBOM/MBOM interactions
Three weeks ago, I closed my PLM-twisted mind for a short holiday. Meanwhile, some interesting posts appeared about the PLM journey.
- Is it a journey?
- Should the journey be measurable?
- And what kind of journey could you imagine?
Together these posts formed a base for a decent discussion amongst the readers. I like these discussions. For me, the purpose of blogging is not the same as tweeting. It is not about just making noise so others will chime in or react (tweeting), it is about sharing an opinion, and if more people are interested, the discussion can start. And a discussion is not about right or false, as many conversations happen to be nowadays, it is about learning.
Let’s start with the relevant posts.
How to measure PLM?
The initial discussion started with Oleg Shilovitsky’s post about the need to measure the value of PLM. As Oleg mentions in his comments:
“During the last decades, I learned that every company that measured what they do was winning the business and succeeded (let’s count Google, Amazon, etc ..)”
This is an interesting statement, just measure! The motto people are using for digital businesses. In particular for the fast-moving software business. Sounds great, so let’s measure PLM. What can we measure with PLM? Oleg suggests as an example:
“Let’s say before PLM implemented a specific process, sales needed 2 days to get a quote. After PLM process implementation, it is 15 min.”
So what does this result tell us? Your sales can do 64 times more sales quotes. Do we need fewer salespeople now? We do not know from this KPI what is the real value for the company. This because there are so many other dependencies related to this process, and that makes PLM different from, for example, ERP. We do not talk about optimizing a process as Oleg might suggest below:
“Some of my PLM friends like to say – PLM is a journey and not some kind of software. Well, I’m not sure to agree about “journey,” but I can take PLM as a process. A process, which includes all stages of product development, manufacturing, support, and maintenance.”
Note: I do not want to be picky on Oleg, as he is provoking us all many times with just his thoughts. Moreover, several of them are a good points for discussion. So please dive into his LinkedIn posts and follow the conversation.
In Oleg’s follow-up post on measuring the value, he continued with Can we measure the PLM-journey which summarizes the comments from the previous post with a kind of awkward conclusion:
What is my conclusion? It is a time for PLM get out of old fashion guessing and strategizing and move into digital form of thinking – calculating everything. Modern digital businesses are strongly focused on the calculation and measurement of everything. Performance of websites, metrics of application usage, user experience, efficiency, AB testing of everything. Measurement of PLM related activity sounds like no brainier decision to me. Just my thoughts…
I think all of us agree that there needs to be a kind of indicative measurement in place to justify investments in place. There must be expected benefits that solve current business problems or bottlenecks.
My points that I want to share with you are:
- It is hard to measure non-comparable ways of working – how do you measure collaboration?
- Do you know what to measure? – engineering/innovation is not an ERP process
- People and culture have so much impact on the results – how do you measure your company’s capability to adapt to new ways of working?
Meanwhile, we continue our journey…
Is PLM a never-ending journey?
In the context of the discussion related to the PLM journey, I assume Chad Jackson from Lifecycle Insights added his 3 minutes of thoughts. You can watch the video here:
Vlogging seems to become more prevalent in the US. The issue for me is that vlogs only touch the surface, and they are hard to scan for interesting reusable content. Something you miss when you are an experienced speed-reader. I like written content as it is easier to pick and share relevant pieces, like what I am doing now in this post.
Chad states that as long as PLM delivers quantified value, PLM could be expanding. This sounds like a journey, and I could align here. The only additional thought I would like to add to this point is that it is not necessary expanding all the time, it is also about a continuous change in the world and therefore your organization. So instead of expanding, there might be a need to do things differently: Have you noticed PLM is changing.
Next Chad mentions organizational fatigue. I understand the point – our society and business are currently changing extremely fast, which causes people to long for the past. A typical behavior I observe everywhere: in the past, everything was better. However, if companies would go back and operate like in the past, they would be out of business. We moved from the paper drawing board to 3D CAD, managing it through PDM and PLM to remain significant. So there is always a journey.
Fatigue comes from choosing the wrong directions, having a reactive culture – instead of being inspired and motivated to reach the next stage, the current stage is causing already so much stress. Due to the reactive culture, people cannot imagine a better future – they are too busy. I believe it is about culture and inspiration that makes companies successful – not by just measuring. For avoiding change, think about the boiling frog metaphor, and you see what I mean
Upgrading to PLM when PDM falls short
At the same time, Jim Brown from Tech-Clarity published a PTC-sponsored eBook: Upgrading to PLM when PDM fall short, in which as he states:
This eBook explains how to recognize that you’ve outgrown PDM and offers several options to find the data and process management capabilities your company needs, whether it’s time to find a more capable PDM or upgrade to PLM. It also provides practical advice on what to look for in a PLM solution, to ensure a successful implementation, and in a software partner.
Jim is mentioning various business drivers that can drive this upgrade path. Enlarge the image to the left. I challenge all the believers in measurable digital results to imagine which KPIs they would use and how they can be related to pure PLM.
Here the upgrade process is aiming at replacing PDM by PLM something PLM vendors like. Immediate a significant numbers of licenses for the same basic PDM functionality – for your company hard to justify there is no additional value.
In many situations, I have seen that this type of PDM upgrade projects became advanced PDM projects – not PLM. The new PLM system was introduced in the engineering department and became an even bigger silo than before as other disciplines/departments were not willing to work with this new “monster” and preferred their own system. They believe that PLM is a system to be purchased and implemented, which is killing for a real PLM strategy.
Still, if you are interested and have time for a puzzle, follow this discussion and add your thoughts
Conclusion
During my holidays, there was a vivid discussion related to the PLM value and journey. Looking back, it is clear we are part of a PLM journey. Some do not take part in the journey and keep on hanging to the past, those who understand the journey are all seeing different Points Of Interests – the characteristics of a journey
Unfortunate one more time and old post with some new comments in green as I am not yet able to type at regular speed. I promise this will be the last reprise as I am sure in one week from now I will be double-handed again. The reason I chose this six-year-old post is that the topic is still actual, however, at that time, digital transformation was not yet in fashion for PLM.
If you look at the comments to the article at that time (Feb 2013), you will see some well-known names and behaviors. What I can state for the moment – there are still people doubting there is a need for PLM, there are still people blaming technology for the lousy perception of PLM, and there is a large group of silent companies out there that have implemented the basics of PLM, perhaps not as advanced as vendors/consultants have suggested, and they are reaping the benefits.
The main question in upcoming blog posts; “Is this enough ?” Happy rereading!
How come PLM is boring? – Feb 2013
PLM is a popular discussion topic in various blogs, LinkedIn discussion groups, PLM Vendor web sites, and for the upcoming Product Innovation Congress in Berlin. I look forward to the event to meet and discuss with attendees their experience and struggle to improve their businesses using PLM. (Meanwhile, PI PLMx London has passed – for a review look here –The weekend after PI PLMx London 2019)
From the other side, talking about pure PLM becomes boring. Sometimes it looks like PLM is a monotheistic topic:
- “What is the right definition of PLM ?” (I will give you the right one)
- “We are the leading PLM vendor” (and they all are)
- A PLM system should be using technology XYZ (etc., etc.)
- Digital Transformation and IoT have come into the picture now
Some meetings with customers in the past three weeks and two different blog posts I read recently made me aware of this ambiguity between boring and fun.
PLM dictating Business is boring
Oleg Shilovitsky´s sequence of posts (and comments) starting with A single bill of materials in 6 steps was an example of the boring part. (Sorry Oleg, as you publish so many posts, there are many that I like and some I can use as an example). When reading the BOM-related posts, I noticed they are a typical example of an IT- or Academic view on PLM, in particular on the BOM topic.
Will these posts help you after reading them? Do they apply to your business? Alternatively, do you feel more confused as a prolific PLM blogger makes you aware of all the different options and makes you think you should use a single bill of materials?
I learned from my customers and coaching and mediating hundreds of PLM implementations that the single BOM discussion is one of the most confusing and complicated topics. Moreover, for sure if you address it from the IT-perspective.
The customer might say:
“Our BOM is already in ERP – so if it is a single BOM, you know where it is – goodbye !”.
A different approach is to start looking for the optimal process for this customer, addressing the bottlenecks and pains they currently face. It will be no surprise that PLM best practices and technology are often the building blocks for the considered solution. If it will be a single BOM or a collection of structures evolving through time, this depends on the situation, not on the ultimate PLM system.
Note: meanwhile Oleg has further materialized his thinking through OpenBOM, and he has not lost his speed of publishing
Business dictating PLM is fun
Therefore I was happy to read Stephen Porter´s opinion and comments in: The PLM state: Penny-wise Pound Foolish Pricing and PLM (unfortunate this post has disappeared) where he passes a similar message like mine, from a different starting point, the pricing models of PLM Vendors. My favorite part is in his conclusion:
A PLM decision is typically a long term choice so make sure the vendor and partners have the staying power to grow with your company. Also make sure you are identifying the value drivers that are necessary for your company’s success and do not allow yourself to be swayed by the trendy short term technology
Management in companies can be confused by starting to think they just need PLM because they hear from the analysts, that it improves business. They need to think first to solve their business challenges and change the way they currently work to improve. Moreover, next look for the way to implement this change.
Not:e Stephen wrote at that time an interesting series of post and promised a revival. However I haven’t seen new posts. Did anyone of my readers see new materials that I missed?
Changing the way to work is the problem, not PLM.
It is not the friendly user-interface of PLM system XYZ or the advanced technical capabilities of PLM system ABC, that will make a PLM implementation easier. Nothing is solved on the cloud or by using a mobile device. If there is no change when implementing PLM, why implement and build a system to lock yourself in even more?
This is what Thomas Schmidt (VP Head of Operational Excellence and IS at ABB’s Power Products Division) told last year at PLM Innovation 2012 in Munich. He was one of the keynote speakers and surprised the audience by stating he did not need PLM!
He explained this by describing the business challenges ABB has to solve: Being a global company but acting around the world as a local company. He needed product simplification, part reduction among product lines around the world, compliance, and more.
Note: Thomas Schmidt meanwhile moved forward in his career, identifying himself as Experienced “Change Leader”, digital transformation, mentor and coach
Another customer in a whole different industry mentioned they were looking for improving global instant collaboration as the current information exchange is too slow and error-prone. Besides, they want to capitalize on the work done and make it accessible and reusable in the future, authoring tool independent. However, they do not call it PLM as in their business nobody uses PLM!
Both cases should make a PLM reseller´s mouths water (watertanden in Dutch), as these companies are looking for critical capabilities available in most of the PLM systems. However, none of these companies asked for a single BOM or a service-oriented architecture. They wanted to solve their business issues. Moreover, for sure, it will lead to implementing PLM capabilities when business and IT-people together define and decide on the right balance.
Unfortunate here we still see a function-feature approach – if it is not there, we will build it
Management take responsibility
Combining PLM and new business needs is the responsibility of management in these companies. It is crucial that a business issue (or a new strategy) is the driving force for a PLM implementation. PLM is not about automating what we have.
In too many situations, the management decides that a new strategy is required. One or more bright business leaders decide they need PLM (note -the strategy has now changed towards buying and implementing a system). Together with IT and after doing an extensive selection process, the selected PLM system (disconnected from the strategy) will be implemented.
I believe we read something about such a case recently
Moreover, this is the place where all PLM discussions come together:
- why PLM projects are difficult
- why it is unclear what PLM does.
PLM Vendors and Implementers are not connected anymore at this stage to the strategy or business. They implement technology and do what the customer project team tells them to do (or what they think is best for their business model).
Successful implementations are those where the business and management are actively involved during the whole process and the change. Involvement requires a significant contribution from their side, often delegated to business and change consultants.
PLM Implementations usually lead to a crisis at some moment in time, when the business is not leading, and the focus is on IT and User Acceptance. In the optimal situation, business is driving IT. However, in most cases, due to lack of time and priorities from the business people, they delegate this activity to IT and the implementation team. So here it is a matter of luck if they will be successful: how experienced is the team?
Will they implement a new business strategy or just automate and implement the way the customer worked before, but now in a digital manner? Do we blame the software when people do not change?
Some notes here: I believe the disconnect between management/PLM vendors and on the other side meanwhile, people in business has become more prominent, due to the digital transformation hype. The hype is moving faster than the organization. Second point: I will not talk about people change anymore – organizations can change – people can adapt within a specific range. It is up to the organization where to push the limits.
Back to fun
I would not be so passionate about PLM if it was boring. However looking back the fun and enthusiasm does not come from PLM. The fun comes from a pro-active business approach knowing that first the motivating the people and preparing the change are defined, before implementing PLM practices
I believe the future success for PLM technologies is when we know to speak and address real business value and only then use (PLM) technologies to solve them.
PLM becomes is a logical result not the start. And don´t underestimate: change is required. What do you think – is it a dream ?
????
This time a post that has been on the table already for a long time – the importance of having established processes, in particular with implementing PLM. By nature, most people hate processes as it might give the idea that their personal creativity is limited, where large organizations love processes as for them this is the way to guarantee a confident performance. So let’s have a more in-depth look.
Where processes shine
In a transactional world, processes can be implemented like algorithms, assuming the data to be processed has the right quality. That is why MRP (Material Requirement Planning) and ERP (Enterprise Resource Planning) don’t have the mindset of personal creativity. It is about optimized execution driven by financial and quality goals.
When I started my career in the early days of data management, before it was called PDM/PLM, I learned that there is a need for communication-related to product data. Terms are revisions, and versions started to pop-up combined with change processes. Some companies began to talk about configuration management.
Companies were not thinking PLM along the whole lifecycle. It was more PDM for engineering and ERP for manufacturing. Where PDM was ultimate a document-control environment, ERP was the execution engine relying on documented content, but not necessarily connected. Unfortunate this is still the case at many companies, and it has to do with the mindset. Traditionally a company’s performance has been measured based on financial reporting coming from the ERP system. Engineering was an unmanageable cost in the eyes of the manufacturing company’s management and ERP-software vendors.
In de middle of the nineties (previous century now ! ), I had a meeting with an ERP-country manager to discuss a potential partnership. The challenge was that he had no clue about the value and complementary need for PLM. Even after discussing with him the differences between iterative product development (with revisioning) and linear execution (on the released product), his statement was:
“Engineers are just resources that do not want to be managed, but we will get them”
Meanwhile, I can say this company has changed its strategy, giving PLM a space in their portfolio combined with excellent slides about what could be possible.
To conclude, for linear execution the meaning of processes is more or less close to algorithms and when there is no algorithm, the individual steps in place are predictable with their own KPIs.
Process certification
As I mentioned in the introduction, processes were established to guarantee a predictable outcome, in particular when it comes to quality. For that reason, in the previous century when globalization started companies were somehow forced to get ISO 900x certified. The idea behind these certifications was that a company had processes in place to guarantee an expected outcome and for when they failed, they would have procedures in place to fix these gaps. The reason companies were doing this because no social internet could name and shame bad companies. Having ISO 900x certification would be the guarantee to deliver quality. In the same perspective, we could see, configuration management, a system of best practices to guarantee that product information was always correct.
Certification was and is heaven for specialized external auditors and consultants. To get certification you needed to invest in people and time to describe your processes, and once these processes were defined, there were regular external audits to ensure the quality system has been followed. The beauty of this system – the described procedures were more or less “best intentions” not enforced. When the auditor would come the company had to play some theater that processes were followed., the auditor would find some improvements for next year and the management was happy certification was passed.
This has changed early this century. In particular, mid-market companies were no longer motivated to keep up this charade. The quality process manual remained as a source of inspiration, but external audits were no longer needed. Companies were globally connected and reviewed, so reputation could be sourced easily.
The result: there are documented quality procedures, and there is a reality. The more disconnected employees became in a company due to mergers or growth, the more individual best-practices became the way to deliver the right product and quality, combined with accepted errors and fixes downstream or later. The hidden cost of poor quality is still a secret within many companies. Talking with employees they all have examples where their company lost a lot of money due to quality mistakes. Yet in less regulated industries, there is no standard approach, like CAPA (Corrective And Preventive Actions), APQP or 8D to solve it.
Configuration Management and Change Management processes
When it comes to managing the exact definition of a product, either an already manufactured product or products that are currently made, there is a need for Configuration Management. Before there were PLM systems configuration management was done through procedures defining configurations based on references to documents with revisions and versions. In the aerospace industry, separate systems for configuration management were developed, to ensure the exact configuration of an aircraft could be retrieved at any time. Less regulated industries used a more document-based procedural approach as strict as possible. You can read about the history of configuration management and PLM in an earlier blog post: PLM and Configuration Management – a happy marriage?
With the introduction of PDM and PLM-systems, more and more companies wanted to implement their configuration management and in particular their change management inside the system, as the changes are always related to product information that can reside in a PLM-system. The change of part can be proposed (ECR), analyzed and approved, leading to and implementation of the change (ECO) which is based on changed specifications, designs (3D Models / Drawings) and more. You can read the basics here: The Issue and ECR/ECO for Dummies (Reprise)
The Challenge (= Problem) of Digital Processes
More and more companies are implementing change processes fully in PLM, and this is the point that creates the most friction for a PLM implementation. The beauty of digital change processes is that they can be full-proof. No change gets unnoticed as everyone is forced to follow the predefined procedures, either a type of fast track in case of lightweight (= low risk) changes or the full change process when the product is already in a mature state.
Like the ISO-900x processes, the PLM-implementer is often playing the role of the consultancy firm that needs to recommend the company how to implement configuration management and change processes. The challenge here is that the company most of the time does not have a standard view for their change processes and for sure the standard change management inside PLM s not identical to their processes.
Here the battle starts….
Management believes that digital change processes, preferable out-of-the-box, a crucial to implement, where users feel their job becomes more an administrative job than a creative job. Users that create information don’t want to be bothered with the decisions for numbering and revisioning.
They expect the system to do that easily for them – which does not happen as old procedures, responsibilities, and methodologies do not align with the system. Users are not measured or challenged for data quality, they are measured on the work they deliver that is needed now. Let’s first get the work done before we make sure all is consisted defined in the PLM-system.
Digital Transformation allows companies to redefine the responsibilities for users related to the data they produce. It is no longer a 3D Model or a drawing, but a complete data set with properties/attributes that can be shared and used for analysis and automation.
Conclusion
Implementing digital processes for PLM is the most painful, but required step for a successful implementation. As long as data and processes are not consistent, we can keep on dreaming about automation in PLM. Therefore, digital transformation inside PLM should focus on new methods and responsibilities to create a foundation for the future. Without an agreement on the digital processes there will be a growing inefficiency for the future.
Jos Voskuil's Weblog 
Your Miele story caught my attention… My 15-year-old Miele dishwasher (which I loved) was failing to wash dishes, and I…
Jos, great thoughts about BOM management. Here are some of my thoughts. I can see how BOM management will evolve…
As a complement, even if more and more of the diversity of a product is managed at the software level…
1) A wiring diagram stores information (wires between ports of the electrical components) that does not exist in most of…
BOM has NEVER been the sole "master" of the Product. The DEFINITION FILE is ! For example the wiring of…