Intentions are the desire for new stories

In the CM Baseline series, I have?used the analogy of flights, flight plans, gates, control towers to explain how difficult it becomes to manage changes and their dependencies to explain the need for the CM2 Baseline, a.k.a. As Planned/As Released Baseline (?'Understanding the Impact of Changes').?

In 'Connections tell the Story,' I explained how a Business Object Graph connecting the data from a business perspective across the expert domain tools could help tell the story.?Which is the first component of the CM Baseline.

If Connections tell the Story, then Intentions are the desire for new Stories.

That is why this post will focus on the second component: the Impact Matrix where intentions describe the intend of a change.

Pyramid graphic by?Martijn Dullaart. Picture of the Impact Matrix: Copyrights by?IpX?- Institute for Process Excellence from the?CM2 courses. Pictures of the Business Object Graph, Dependencies, and Planning by?Martin Haket.

The Impact Matrix

When I talk about the Impact Matrix, I do not mean how the information is visualized in a matrix (table format), but as a carrier of the information about the impact of a change and the decisions about the intention of the change. E.g., re-identification decisions or part dispositions or proposals for some of the key data elements or relationships. Decisions that require the assessment and agreement of a cross-functional team.?

Basically, what you record in an Impact Matrix is the intention of the change for an affected object. The intention captures the re-identification decision, the part disposition in case the object is a part that requires a new number, but also proposals for some key data elements (e.g. a name/description or if a part is a Make or a Buy). So, in other words, the Impact Matrix is a collection of affected objects, relations, and intentions.

Not every change is the same

Depending on the type of change, there is a difference in the amount of detail you capture in the Impact Matrix as part of a change request to come to a business case versus the amount of detail you need to plan an approved change request.?

If you change parts, you only need to know that you will introduce a new part and how many parents will be affected,?assuming the change fades out in the immediate parent(s). You do not have to indicate that you need to create all kinds of documentation and that you need to update the work instructions etc. Because for the business case estimate, it is sufficient to know that a part will be replaced.

How to show a change in a business object Graph

In below (simplified) business object graph example based on the one from my?previous?post, you can see that Part1 has an EBOM revision AA that contains Part5 and Part4 both with quantity 1 and that Part1 also has an MBOM revision AA that contains Part2, Part3 and Part4 all with quantity 1. When the impact of Change 1 is depicted in red, you can see that 3 intentions have been defined:

• Intention1 of type Part intends to supersede Part4
• Intention2 of type EBOM intends to supersede EBOM1 rev AA as the EBOM for Part1. Where the it intends to contain Part5 and the new Part as defined by Intention1, both with quantity 1.
• Intention 3 of type MBOM intends to supersede MBOM1 rev AA as the MBOM for Part1. Where it intends to contain Part2, Part3 and the new Part as defined by Intention1, all with quantity 1.

However if you do a more detailed analysis soon you will see that more is impacted. As you can see in below, as the process to make Part1 is now impacted as well as the work instruction. And Part4 can be reworked to the new Part which requires a new process, operation and work instruction. Also disposition information about Part4 for the factory and field are part of Intention1.

If the change is just about updating a work instruction, you might need to indicate this impact immediately. You might even allow the users to process these types of changes based on their own discretion. Naturally, the criteria for when this can be done need to be set by a change board.

Naturally, you sometimes need a conceptual design as input to analyze the impact. The conceptual design is not the impact definition; it is a solution direction. Decisions on whether or not you need a new part number are not yet critical, as more inputs will be needed to come to such a decision.?The conceptual design information can still be used to generate the initial proposals for the impact analysis. To maximize the reuse of information.?Read also more about re-identification in the following articles:

• It's about Interchangeability and Traceability?
• Re-Identification

Defining impact on 'planned' changes

Affected objects can be Items/Parts, Requirements, functions, logical components, and any other relevant dataset for a change. The affected objects are part of the Business Object Graph in most cases. However, if you work in an environment with a very high volume of changes on certain objects (typically in the top levels of the product structure), it could be that you have defined an intention in one change for that affected object, but the intention is not yet implemented. Do you assess the impact of your change only against the latest released, or do you also take into account the intentions that are part of approved changes and possibly already planned to be implemented??

In the below example, you can see that there is an Intention1 that introduces a new assembly that reuses Inention2 of type Part which is replacing Part4 in the EBOM and MBOM of Part1. But the change is planned but not yet implemented. A new change request is initiated and impacts the assembly as well. Do you also assess the change against the New Part/Intention or not?

In a graph visualization the information in above picture would look something like:

During the planning of a change, it could be that you are able to combine certain changes and hence reduce the need for additional re-identifications. Which can easily be indicated by combining the intentions of the changes into one.?

Visualization of the Impact Matrix

An important aspect of the Impact Matrix is the visualization. The traditional way is to visualize it in a table/matrix format. While this can still be useful, it does not really support Impact Analysis. But a Graph style visualization can help easily see the context of the impact on other objects and relationships. In the case of a 3D Model, the impact can be visualized within the model.?

Example of a table format for visualization based on the earlier used graph representation of the impact:

It is important that one can edit the affected objects in context to support a collaborative, effective, and efficient impact analysis.?

Next to having different types of viewing the impact, it is important that users can filter based on the type of content and are supported in finding impact even though they might not have queried every possible object or filtered out certain content. The Impact Matrix must allow the user to interact to make the user aware of potential impact.

The next post in this series will be about the changes and their dependencies. In the meantime, feel free to share your thoughts or reach out if you would like to discuss this topic.

This article was originally published on?mdux.net.

Header Photo by Tim Mossholder on Unsplash.

Disclaimer