If you haven’t noticed, the nature of change management in PLM is, well, changing due to exploding product complexities. It used to be that PLM was focused on changes to physical parts or physical assemblies (BOM). That was because PLM solutions and configuration management were originally designed to manage the mechanical domain. However, with the increasing importance of systems engineering and Model-based Systems Engineering (MBSE) tools, the context of a single change is drastically expanding. That expanded context is what must be considered to evaluate the impact of this change.
Some may remember the fatal and costly 2014 debacle that General Motors (GM) got into with a faulty ignition switch design (see here for a root cause discussion). Notwithstanding the fact that the GM design engineer failed to follow the company’s change management procedures (by changing the design of a part without changing the part number), there is another interesting element to the story. GM did not have the ability for engineers to quickly and automatically use the parameters derived from the modified part to rerun system-level analyses and simulations to evaluate the impact of the change. Nor did they run an analysis that would automatically compare the results generated by the previous design and related requirements. That highlights the challenge of PLM change management which I discussed in a previous blog. Had such an automatic connection existed the whole situation might have been avoided because the analysis would have been done easily and automatically (e.g., without an additional time investment by the engineer), taking into account the entire system context of that change.
It turns out that I’m not the only one who thinks this way. Consider the following quote from the new INCOSE Vision 2035 report: "By 2035, a family of unified, integrated MBSE-Systems Modeling and Simulation (SMS) frameworks exist. They leverage digital twins and are fully integrated into the enterprise digital thread foundation." I would add that these frameworks would be completely integrated with the PLM platforms (for the “big” SE), as well as with domain-specific design tools (for the “small” SE) – see the explanation of the “big” vs “small” SE in the graphics below. Similar points are made by Dr. Martin Eigner in his new book, System Lifecycle Management.
System models enable design intent driven traceability of relationships &
dependencies between design data and across domains.
Solution providers are not waiting. Domain-specific tool vendors are actively pursuing integration of MBSE for small SE, the wiring harness design tool E3 and GENESIS system modeling tool being good examples. Aras' low-code platform has already released foundational elements of this framework allowing big SE and small SE to be managed as part of a single digital thread.
There is another aspect of the change management process that needs attention because of the expanding impact of change. It has to do with the need for that process to dynamically adapt to a design’s maturity level. Initial changes are driven by design space exploration and have a minor impact. As design maturity increases, changes become more impactful because of prior decisions on reuse, requirements flow down, and information already shared internally or with partners. I call that Dynamic Change Management. It automatically streamlines change requests, assessments, and orders in accordance with the design’s maturity. This ensures that users throughout the extended supply chain have easy and early visibility into engineering status changes throughout the product lifecycle where change histories are automatically captured and recorded. Again, the Aras Innovator platform is already providing that functionality.
Dynamic change management is also critical because specific design domains execute at different timelines and cadences while still relating to the same overall system design. Application Lifecycle Management (ALM, e.g., software development) vs. electronic CAD vs. PLM are good examples of that. In fact, ALM is a true stand-out because many OEMs agree that their goal is a complete decoupling of software design from hardware design, while maintaining the same overall system design context.
While the ideas discussed here can be forward-looking for your organization, there is one aspect of the change management process that should never be left unattended. That is compliance with CM2 by IpX - the Institute for Process Excellence. Whatever solution you use or intend to use to manage product changes, “Is it compliant with CM2 by IpX - the Institute for Process Excellence?” is the first question to ask. If the answer is no, it’s time to look for a different solution provider.
To find out more about Aras Innovator’s low-code platform and Aras Enterprise SaaS visit www.aras.com.