You are currently browsing the tag archive for the ‘CM’ tag.
Image: waitbutwhy.com
Two weeks ago I wrote about the simplification discussion around PLM – Why PLM never will be simple. There I focused on the fact that even sharing information in a consistent, future proof way of working, is already challenging, despite easy to use communication tools like email or social communities.
I mentioned that sharing PLM data is even more challenging due to their potential revision, version, status, and context. This brings us to the topic of configuration management, needed to manage the consistency of information, a challenge with the increasingly sophisticated products or systems. Simple tools will never fix this complexity.
To manage the consistency of a product, configuration management (CM) is required. Two weeks ago I read the following interesting post from CMstat: A Brief History of Configuration Management Software.
An excellent introduction if you want to know more about the roots of CM, be it that the post at the end starts to flush out all the disadvantages and reasons why you should not think about CM using PLM systems.
The following part amused me:
The Reality of Enterprise PLM
It is no secret that PLM solutions were often sold based in good part on their promise to provide full-lifecycle change control and systems-level configuration management across all functions of the enterprise for the OEM as well as their supply and service chain partners. The appeal of this sales stick was financial; the cost and liability to the corporation from product failures or disasters due to a lack of effective change control was already a chief concern of the executive suite. The sales carrot was the imaginary ROI projected once full-lifecycle, system-level configuration control was in effect for the OEM and supply chain.
Less widely known is that for many PLM deployments, millions of budget dollars and months of calendar time were exhausted before reaching the point in the deployment road map where CM could be implemented. It was not uncommon that before the CM stage gate was reached in the schedule, customer requirements, budget allocations, management priorities, or executive sponsors would change. Or if not these disruptions within the customer’s organization, then the PLM solution provider, their software products or system integrators had been changed, acquired, merged, replaced, or obsoleted. Worse yet for users who just had a job to do was when solutions were “reimagined” halfway through a deployment with the promise (or threat) of “transforming” their workflow processes.
Many project managers were silently thankful for all this as it avoided anyone being blamed for enterprise PLM deployment failures that were over budget, over schedule, overweight, and woefully underwhelming. Regrettably, users once again had to settle for basic change control instead of comprehensive configuration management.
I believe the CMstat-writer is generalizing too much and preaches for their parish. Although my focus lies on PLM, I also learned the importance of CM and for that reason I will share a view on CM from the PLM side:
Configuration Management is not a target for every company
The origins of Configuration Management come from the Aerospace and Defense (A&D) industries. These industries have high quality, reliability and traceability constraints. In simple words, you need to prove your product works correctly specified in all described circumstances and keep this consistent along the lifecycle of the product.
Moreover, imagine you delivered the perfect product, next implementing changes require a full understanding of the impact of the change. What is the impact of the change on the behavior or performance? In A&D is the question is it still safe and reliable?
Somehow PLM and CM are enemies. The main reason why PLM-systems are used is Time to Market — bringing a product as fast as possible to the market with acceptable quality. Being first is sometimes more important than high quality. CM is considered as a process that slows down Time to Market as managing consistency, and continuous validating takes time and effort.
Configuration Management in Aviation is crucial as everyone understands that you cannot afford to discover a severe problem during a flight. All the required verification and validation efforts make CM a costly process along the product lifecycle. Airplane parts are 2 – 3 times more expensive than potential the same parts used in other industries. The main reason: airplane parts are tested and validated for all expected conditions along their lifecycle. Other industries do not spend so much time on validation. They validate only where issues can hurt the company, either for liability or for costs.
Time to Market even impacts the aviation industry as we can see from the commercial aircraft battle(s) between Boeing and Airbus. Who delivers the best airplane (size/performance) at the right moment in the global economy? The Airbus 380 seemed to miss its targets in the future – too big – not flexible enough. The Boeing 737 MAX appears to target a market sweet spot (fuel economy) however the recent tragic accidents with this plane seemed to be caused by Time to Market pressure to certify the aircraft too early. Or is the complexity of a modern airplane unmanageable?
CM based on PLM-systems
Most companies had their configuration management practices long before they started to implement PLM. These practices were most of the time documented in procedures, leading to all kind of coding systems for these documents. Drawing numbers (the specification of a part/product), Specifications, Parts Lists, all had a meaningful identifier combined with a version/revision and status. For example, the Philips 12NC coding system is famous in the Netherlands and is still used among spin-offs of Philips and their supplier as it offers a consistent framework to manage configurations.
Storing these documents into a PDM/PLM-system to provide centralized access was not a big problem; however, companies also expected the PLM-system to support automation and functionality to support their configuration management procedures.
A challenge for many implementers for several reasons:
- PLM-systems do not offer a standard way of working – if they would do so, they could only serve a small niche market – so it needs to be “configured/customized.”
- Company configuration management rules sometimes cannot be mapped to the provided PLM data-model and their internal business logic. This has led to costly customizations where, in the best case, implementer and company agreed somewhere in the middle. Worst case as the writer from the CM blog is mentioning it becomes an expensive, painful project
- Companies do not have a consistent configuration management framework as Time to Market is leading – we will fix CM later is the idea, and they let their PLM –implementer configure the PLM-system as good a possible. Still, at the management level, the value of CM is not recognized.
(see also: PLM-CM-ALM – not sexy ?)
In companies that I worked with, those who were interested in a standardized configuration management approach were trained in CMII. CMII (or CM2) is a framework supported by most PLM-systems, sometimes even as a pre-configured template to speed-up the implementation. Still, as PLM-systems serve multiple industries, I would not expect any generic PLM-vendor to offer Commercial Off-The-Shelf (COTS) CM-capabilities – there are too many legacy approaches. You can find a good and more in-depth article related to CMII here: Towards Integrated Configuration Change Management (CMII) from Lionel Grealou.
What’s next?
Current configuration management practices are very much based on the concepts of managing document. However, products are more and more described in a data-driven, model-based approach. You can find all the reasons why we are moving to a model-based approach in my last year’s blog post. Important to realize is that current CM practices in PLM were designed with mechanical products and lifecycles as a base. With the combination of hardware and software, integrated and with different lifecycles, CM has to be reconsidered with a new holistic concept. The Institute of Process Excellence provides CM2 training but is also active in developing concepts for the digital enterprise.
Martijn Dullaart, Lead Architect Configuration Management @ ASML & Chair @ IPE/CM2 Global Congress has published several posts related to CM and a Model-Based approach – you find them here related to his LinkedIn profile. As you can read from his articles organizations are trying to find a new consistent approach.
Perhaps CM as a service to a Product Innovation Platform, as the CMstat blog post suggests? (quote from the post below)
In Part 2 of this CMsights series on the future of CM software we will examine the emerging strategy of “Platform PLM” where functional services like CM are delivered via an open, federated architecture comprised of rapidly-deployable industry-configured applications.
I am looking forward to Part2 of CMsights . An approach that makes sense to me as system boundaries will disappear in a digital enterprise. It will be more critical in the future to create consistent data flows in the right context and based on data with the right quality.
Conclusion
Simple tools and complexity need to be addressed in the right order. Aligning people and processes efficiently to support a profitable enterprise remains the primary challenge for every enterprise. Complex products, more dependent on software than hardware, are requiring new ways of working to stay competitive. Digitization can help to implement these new ways of working. Experienced PLM/CM experts know the document-driven past. Now it is time for a new generation of PLM and CM experts to start from a digital concept and build consistent and workable frameworks. Then the simple tools can follow.
Recently i noticed two different discussions. One on LinkedIn in the CMPIC® Configuration Management Trends group, where Chris Jennings started with the following statement:
Product Lifecycle Management (PLM) vs CM
An interesting debate has started up here about PLM vs CM. Not surprisingly it is revealing a variety of opinions on what each mean. So I’m wondering what sort of reaction I might get from this erudite community if I made a potentially provocative statement like …
“Actually, PLM and CM are one and the same thing” ?24 days ago
It became a very active discussion and it was interesting to see that some of the respondents saw PLM as the tool to implement CM. Later the discussion moved more towards system engineering, with a focus on requirements management. Of course requirements management is key for CM, you could say CM starts with the capturing of requirements.
There was some discussion about what is the real definition of PLM and this triggered my post. Is the definition of PLM secured in a book – and if so – in which book as historically we have learned that when the truth comes from one book there is discussion
But initially in the early days of the PLM, requirements management was not part of the focus for PLM vendors. Yes, requirements and specifications existed in their terminology but were not fully integrated. They focused more on the ‘middle part’ of the product lifecycle – digital mockup and virtual manufacturing planning. Only a few years later PLM vendors started to address requirements management (and systems engineering) as part of their portfolio – either by acquisitions of products or by adding it natively.
For me it demonstrates that PLM and CM are not the same. CM initially had a wider scope than early PLM systems supported, although in various definitions of PLM you will see that CM is a key component of the PLM practices.
Still PLM and CM have a lot in common, I wrote about is a year ago in my post: PLM, CM and ALM; not sexy ! and both fighting to get enough management support and investments. There is in the CMIP group another discussion open with the title: What crazy CM quotes have you heard ? You can easily use these quotes also for the current PLM opinion. Read them (if you have access and have fun)
But the same week another post caught my interest. Oleg’s post about Inforbix and Product Data Management. I am aware that also other vendors are working on concepts to provide end users with data without the effort of data management required. Alcove9 and Exalead are products with a similar scope and my excuses to all companies not mentioned here.
What you see it the trend to make PLM more simple by trying to avoid the CM practices that often are considered as “non-value add”, “bureaucracy” and more negative terms. I will be curious to learn how CM practices will be adhered by these “New Generation of PDM” vendors, as I believe you need CM to manage proactively your products.
What is your opinion about CM and PLM – can modern PLM change the way CM is done ?
This time it is hard to write my blog post. First of all, because tomorrow there will be the soccer final between Holland and Spain and as a Virtual Dutchman I still dream of a real cup for the Dutch team.
Beside that I had several discussions around PLM (Product Lifecycle Management), CM (Configuration Management) and ALM (Asset Lifecycle Management), where all insiders agreed that it is hard to explain and sell the value and best practices, because it is boring, because it is not sexy, etc, etc.
So why am I still doing this job…..
Product Lifecycle Management (PLM)
If you look at trade shows and major events of PLM vendors, the eye-catching 
stuff is 3D (CAD).
Dassault Systemes introduced in 2006 3DLive as the 3D collaboration layer for all users with the capability to provide in a 3D manner (see what you mean) on-line role specific information, coming from different information sources. Recently Siemens introduced their HD PLM, which as far as I understood, brings decision making capabilities (and fun) to the user.
Both user interfaces are focusing on providing information in a user-friendly and natural way – this is sexy to demonstrate, but a question never asked: “Where does the information come from ? “
And this is the boring but required part of PLM. Without data stored or connected to the PLM system, there is no way these sexy dashboards can provide the right information. The challenge for PLM systems will be to extract this information from various applications and from users to have the discipline to enter the needed data.
Those software vendors, who find an invisible way to capture the required information hold the key to success. Will it be through a more social collaboration with a lot of fun, I am afraid not. The main issue is that the people who need to enter the data are not rewarded for doing it. It is downstream the organization, in the product lifecycle, that other people benefit from the complete information. And I even suspect in some organizations that there are people who do not want share data to assure being required in the organization – see also Some users do not like the single version of the truth.
So who can reward these users and make them feel important. I believe this is a management job and no sexy (3D) environment will help here
Configuration Management (CM)
Although it is considered a part of PLM, I added configuration management to my post as a separate bullet. Two weeks ago, I attended the second day of the CMII Europe conference in Amsterdam. What I learned from this event was that the members of the CMII community are a group of enthusiastic people with somehow the same vision as PLM missionaries.
Quoting the organization: “CMII is about changing faster and documenting better. It is about accommodating change and keeping requirements clear, concise and valid.”
And it was interesting to listen to speeches of the members. Like with PLM, everyone is convinced configuration management brings a lot of value to a company, they are also fighting for acknowledgement. Not sexy is what I learned here and also here those people who are responsible for data accuracy are not necessary the ones that benefit (the most).
Like PLM, but even more in Configuration Management, the cultural change should not be neglected. Companies are used to have a certain level of “configuration management”, often based on manual processes, not always as efficient, clear and understood and satisfactory for the management, till something happens due to incorrect information.
Of course the impact of an error differentiates per industry, a problem occurring due to wrong information for an airplane is something different compared to a problem with a sound system.
So the investment in configuration management pays of for complex products with critical behaviors and in countries where labor costs are high. It was interesting to learn that a CM maturity assessment showed that most companies score below average when it comes to management support and that they score above average when talking about the tools they have in place.
This demonstrates for me that also for configuration management, companies believe tools will implement the change without a continuous management push. I remember that in several PLM selection processes, prospects were asking for all kind of complex configuration management capabilities, like complex filtering of a product structure. Perhaps pushed by a competitor, as at the end it was never implemented 😦
Asset Lifecycle Management (ALM)
In some previous posts, I wrote about the benefits a PLM system can bring, when used as the core system for all asset related information. For nuclear plants, the IAEA (International Atomic Energy Agency) recommends to use configuration management best practices and I have met an owner/operator of a nuclear plant who recognized that a PLM system brings the right infrastructure, instead of SAP for example, which has more focus on operational data.
Also I had a meeting with another owner/operator, who was used to manage their asset data in a classical manner – documents in an as-built environment and changes of documents in various projects environments.
When discussing the ALM best practices based on a PLM system, it was clear all the benefits it could bring, but also we realized that implementing these concepts would require a conceptual revolution. People would need to start thinking asset centric (with lifecycle behavior) instead of document centric with only revisions.
This kind of change requires a management vision, clear explanation of the benefits and a lot of attention for the user. Only then when these changes have been implemented, and data is available in a single repository, only then the fun and sexy environments become available for use.
Conclusion
PLM, CM and ALM are not sexy especially for the users who need to provide the data. But they provide the base for sexy applications where users have instant access to complete information to make the right decisions. To get there a cultural change is required. The management needs to realize that the company changes into becoming proactive (avoiding errors) instead of being reactive (trying to contain errors); investing upfront and never be able to know what the losses would be in case an error occurred.
Not sexy, however the benefits this approach can bring allow employees and companies to continue to do their work for a secure future
And now … time to close as the final is near
Jos Voskuil's Weblog 
Hi Jos, Having been involved in multiple tool implementations, one other drawback to smart numbering is that tools need to…
Good day Jos, I was involved in many implementations over the years (including) Philips…. Indeed smart part numbers was a…
If one were starting out a brand new company, you could start a part numbering sequence at 100 and just…
Jos, as always a great report. Agree with you, the agenda and the presentations was a bit of Classic PLM…
Another Interesting article, I also see this kind of development in our company where terminology shifts and approach methods change.…