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.