A week ago, Martijn Dullaart and Martin Haket, both well skilled in configuration management, published a post on MDUX.net and LinkedIn where they pledged for standardization across domains, first of all when supporting processes between PLM and ERP – read the full article here: We need a cross-platform interface for impact analysis!
In the article, some standards with various scopes related to product information are mentioned (PDX, ISO 10303, ISO305:2017), and the article suggests that impact analysis should be done in an overarching domain, the CM domain, outside PLM. See the image on the left. I have several issues with this approach, which I will explain here.
PLM and/or CM are overarching domains
The diagram puts CAD, SW, PLM, and ERP as verticals, where I would state PLM is responsible for the definition of the Product, which means governing CAD and SW and publishing towards ERP for execution. You might discuss if CM is part of PLM or that CM is a service on top of PLM.
We had this discussion before: PLM and Configuration Management – a happy marriage? and one of my points was that in aerospace, defense, and automotive companies actively invest in CM. If you go to other industries and sizes of business, CM becomes more an intention than a practice.
Somehow the same challenge PLM has when it comes to full lifecycle support.
Now let’s look at impact analysis
During my personal PLM lifecycle, I discussed with many companies how a PLM system could provide a base for impact analysis. These scenarios were mainly based on a Where-Used analysis in the context of an engineering change, which PLM should be able to offer.
PLM would provide the information in which actual running products or upcoming products are impacted by a potential change – this would provide the technical answer and the impact on production.
To support the financial case, a more advanced impact analysis was required. This is often a manual process. In more advanced cases customization is used, to provide real-time information about the current warehouse stock (scrap?) and potential ordered parts/materials.
I could imagine some other potential impacts to analyze, for example, the marketing/sales plans, but haven’t come across these situations in my projects.
To start from a well-thought approach, I expected more from the article, Martijn and Martin wrote:
A good candidate to be used as interface between the expert domains and CM domain is, in our opinion, the CM2 impact matrix. This captures the information on an aggregate level like a part, or document or dataset. This aggregate level can be used by other expert domains to identify impact within their scope or by the CM domain to support cost estimation and implementation planning.
So I followed the link to discover and digest the CM2 impact matrix. However, the link leads to CM2 training, not directly useful information – the impact matrix. Should I get CM2 trained before to gain access to the information?
This is the same lock-in where a PLM Vendor will state:
Buy our system and use our impact analysis.
I believe every respectable PLM system has a base for impact analysis and probably a need to be customized for outside data. Martijn and Martin agree on that, as they write:
This interface is currently not existent in the offerings of the various vendors. If an impact matrix is available, it is to support the impact analysis within the tool of a vendor not to support impact analysis within a business. That is why Martin and I challenge the vendors in the various expert domains to come with a standard to allow businesses to perform a high-quality cross-functional impact analysis that improves the quality of decision making.
Vendors coming with a standard?
In particular, the sentences challenging the vendors to come with a standard is a mission impossible, to my opinion.
A vendor will never come with a standard unless THEY become the standard.
CATIA in Aerospace/Automotive, DXF in 2D mid-market CAD, IFC for the building market, Excel for calculations, are all examples where one vendor dominates the market. I do not believe there will be in any R&D department of a software company, people working spontaneously on standards,
Companies have to develop and push for standards
Standards have always been developed because there was a need to exchange information, most of the time needed for an exchange between companies – OEMs – Suppliers – partners. In the case of impact analysis, the target might be slightly different. Impact analysis is mainly focusing on internal systems within the organization that is planning a change.
And this makes the push for standardization again more complicated.
Let me explain why:
First, there is ERP – the image above shows Management of Change in the SAP help environment.
In most companies, the ERP-system is the major IT-system and all efforts to automate processes were targeted to be solved within ERP.
Therefore, you will find basic impact analysis capabilities, mainly related to the execution side: actual stock, planned production orders, and logistics in ERP. The rest of impact analysis is primarily a manual task.
Next, with the emergence of PLM-systems, impact analysis shifted towards the planning side: Where Used or Where Related became capabilities related to engineering change request. In my SmarTeam days we developed templates for that:
Where the Analysis was still a manual action, where the PLM-system would provide Where Used support and potentially a custom ERP-connection would give some additional information.
Nowadays, I would state all PLM vendors have the technical capabilities to create an impact analysis dashboard. Aras by rapid customization, Dassault Systemes by using Exalead, PTC by using Navigate and Siemens by using Mendix – so technology exists, but what about standards?
In the comments section to the LinkedIn post, Martijn mentions that the implemented change behavior in PLM is not exactly as he (or CM2 methodology) would propose. – the difficulty in the happy marriage between PLM and CM. See his comment here.
For me, these comments are change requests to the PLM vendors, and they will be only heard when there is a push from the outside world.
Therefore my (simplified) proposal:
- Start an Impact Analysis community outside CM2 as there are many companies not following CM2; still they have their particular ways of working. Perhaps this community exists and lacks visibility – I am happy to learn.
- Describe the potential processes and people involved and collect/combine the demands – think tool independent as this is the last step.
- Publish the methodology as an open standard and have it rated by the masses. The rating will influence the software vendors in the market.
Conclusion
Asking vendors to come with a cross-platform interface standard for impact analysis is a mission impossible. Standards appear when there is a business need that needs to come from the market. Impact Analysis has an additional difficulty as it is mostly a company-internal process.







First of all, as long as you stay in your controlled environment, you do not need standards. In particular, in the Aerospace and Automotive industry, the OEMs defined the software versions to be used, and the supply chain had to adhere to their chosen formats. Even this narrow definition was not complete enough as a 3D CAD model needed to be exported for simulation or manufacturing purposes. There was not a single vendor working on a single CAD model definition at that time. So the need for standards emerged as there was a need to exchange data.
















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




























PLM implementations within the same industry might look the same but often vary significantly due to existing practices, which will not change due to the tool. So there is a need for customization or configuration.

Strategic partners should be the partner to support business change management as they are likely to have experience with other companies. Unfortunately, this type of company does not have significant skills in PLM as the PLM domain is just a tiny subset of the whole potential business strategy.
If your company is implementing PLM, then probably the perception is that you made all the effort to make it successful. You followed the strategic consultants’ advice, selected the best PLM Vendor and system integrator, and created a budget – so what could go wrong?


You might feel that everyone is to blame when a PLM implementation fails. I believe that is indeed the case. If you know in advance where all players have their strengths and weaknesses, a PLM implementation should not fail but be balanced with the right resources. Depending on the scope of your PLM implementation, whether it is a consolidation or a transformation, you should take care of all stakeholders participating in the anti-blame game.







When you look at the significant wins Aras is mentioning in their customer base, GM, Schaeffler or Airbus, you will probably discover Aras is more the connection layer between legacy systems, old PLM or PDM systems. They are not the new PLM replacing old PLM. A connection layer creates a digital thread, connecting various data sources for traceability but does not provide digital continuity as the data in the legacy systems is untouched. Still it is an intermediate step towards a hybrid environment.







Hi Jos, Knowing your background in methodology and education, I wanted to share a longer article with you: “What is…
Interesting reflection, Jos. In my experience, the situation you describe is very recognizable. At the company where I work, sustainability…
[…] (The following post from PLM Green Global Alliance cofounder Jos Voskuil first appeared in his European PLM-focused blog HERE.) […]
[…] recent discussions in the PLM ecosystem, including PSC Transition Technologies (EcoPLM), CIMPA PLM services (LCA), and the Design for…
Jos, all interesting and relevant. There are additional elements to be mentioned and Ontologies seem to be one of the…