The Future of Change Management

Efficient management of change is crucial to the success of product development. We’ve explored a number of topics around BOM management and configuration. I’ve been reading through some of the discussions about product variant management, release, and configuration management, guided product configuration, and several other BOM management topics. I also noticed one of my colleagues introduced concepts around PLM process execution, including product change management, in a recent discussion around product development process management.

In reviewing all these different topics, it occurred to me that “BOM Management” and “Change Management” are often relegated to separate conversations, when the reality is that they are critically intertwined. How do you control BOM change management? How do you manage change to your product definition to respond to market needs and deliver successful products?

Many companies I work with find that today’s change management solutions are limited:

• • Limited integration between change management and authoring applications

• • Limited support for concurrent, parallel, or alternative changes

• • Limited support for packaging and reviewing exact contents of a change

Future change management systems will help address these issues.

Integrated Change

In PLM, the change management system and the content authoring system will be tightly integrated. With this integration, additional automation becomes possible. One example of this automation is in setting up a working context to analyze or execute a change. If I am assigned a change, the system will set up a proper working context for me based on the scope of the change. This working context will include an understanding of impacts.

For example, a set of components is being moved. The components are valid for units 1 through 10 of a product. A design change to related content had already happened valid for only units 6 and up. The system will identify and load all affected components, considering connections, proximity, and validity of the affected components. The system will load sets of content for each unique configuration – in this case, there would be a set valid for units 1 through 5 and another for units 6 through 10. The system could also consider other natural dependencies based on function or system.

Once a proper working context is established, the engineer executes the change by modifying product content. The PLM system will understand that the engineer is working on a change. So as product content is modified, the edits will be automatically tracked for that change. This will apply across any PLM application, including CAD. Imagine if the CAD system understood the change to be executed. It could set up a working context for the designer and track edits against the change, eliminating much of the overhead in executing a change.

Isolated Change

Given the constant change, it is useful to isolate a given change. Essentially this means an engineer or team can work in their own ‘sandbox’, without affecting or being affected by other changes until they are ready to collaborate. This will remove some of the chaos associated with large product development and allow teams to focus on their tasks. Understanding the contents of a change package distinct from other working content is needed for proper execution, evaluation, and review.

Concurrent Change

With the isolated change, we will better support concurrent change, where content can be branched, without each branch corrupting the other. This will cleanly enable alternative studies, where reviewers can select among competing alternatives. The concurrent change will also enable fast-track changes to content while a longer lead time change to the same content is being executed.For example, in the software world, this is needed to complete a patch release while the next major version is being executed.

Collaborative Change

Since products can have many interdependencies, it is not always good to stay isolated. Engineers must be able to coordinate their changes. Change systems will support several types of collaboration. If changes are tightly coupled, they will have the ability to work on the same branch, always seeing the latest working versions of content in that branch.

In other cases, more ad-hoc collaboration is needed. An engineer is working on a change when the system identifies that some reference content (maybe a connected component) has an open change. The engineer will be able to pull the contents of that change into the current working context to ensure there are no conflicts.

There is also a need to share working content among several changes. Engineers will be able to ‘promote’ their working content into a sharable space, where other users may access all shared content. This can be used for virtual reviews, where the latest working content of the product or a system must be integrated.

Component-Based Change

Advanced PLM systems now support component-based modeling, where engineering product content is managed independently of assembly structures. This type of modeling will allow for finer grain control over change processes. Changes will be managed for specific components instead of branches in an assembly hierarchy. The following table summarizes the differences between assembly-based change and component-based change.

Summary

Next generation PLM systems will support more efficient change processes by supporting the following:

• • Better integration between change and engineering content authoring

• • A better definition of change packages

• • Better support for parallel concurrent changes

• • Better coordination and sharing among changes

• • More efficient modeling of engineering content