The CM Baseline is one of the foundations of the CM2 Model as it provides you with the correct information about the configuration. It also gives you insights into the changes to the configuration over time and enables the flexibility needed to deal with all these changes without losing configuration control. While there are many use cases, this post will highlight five ways how a CM Baseline brings value to your business.
1. Impact analysis across expert domain tools.
It also brings trace links between the various objects in the multiple information structures. When you do your impact analysis, you can traverse the entire information network to assess the impact—bringing experts closer as it is easier to figure out who is on the other end of a requirement or a work instruction documented in a different tool. It enables queries from top to bottom, left to right, and vice versa.
The value is that not only can we bring our experts together and collaborate on the impact of a change, but also the fact that impact becomes more straightforward to assess, in turn providing better input for the business case and reducing the risks of a change. In the end, we want more, not fewer changes, however, each change needs be value added. See also my post ‘More is More: Make every Change count!‘.
2. Scenario-based impact analysis based on the impact of planned changes
‘Intentions are the desire for new Stories’ shows how the CM Baseline can be used to analyze the impact of a change in the context of already running changes. The CM Baseline contains all the impact of all running changes. When we have a situation where many changes are processed in a relatively short period on the same items, we can use this to understand the impact of all the changes and how this will impact a new change being analyzed. It is almost like you become a fortune teller.
One can even work out different scenarios and compare the impact to decide which Implementation Strategy to follow. For instance, compare the impact based on the latest released versus the latest planned, as shown below. Based on the latest released, it seems as if it is an update of the Bill of Material of Part 3, whereas if based on the latest planned, it is an update of the Bill of Material of Part 7, which CN2 is implementing.
We can even take it one step further where you can also see the impact on other changes if a change would be introduced before or after an existing planned change. As shown in below. If CN5 will be implemented before CN4, it does not impact the to be updated deliverables of CR4/CN4, but it does matter to the impact of CR5/CN5. If CN5 goes first, it would reduce the amount of effort by the creation of 2 datasets and 1 part.
3. Providing key data to determine the best introduction date for a change.
4. What-if Analysis in case of disturbances or changing customer requests.
While a bit similar to the scenario-based impact analysis of changes, what-if analysis can be applied to disturbances or late changes in customer requests. Imagine we are already building a system and a supplier indicates the new assembly will be several weeks late or the new assembly is damaged during transport, and it takes weeks to repair or get a new one. What are our options? Can we use the previous assembly, or does it not meet the required performance? Can we temporarily build it with the old assembly and perform some of the tests and required calibration before shipping replaces it with the new assembly and finalizes the testing and calibrations.
What happens if our customer wants to change the order? Delivery 14 weeks earlier or a different configuration. What are our options? Fourteen weeks earlier will have an impact on the available parts. So we might need to do last-minute upgrades or upgrades after installation at the customer.
5. Commonality analysis from different perspectives.
Having insight into commonality from different perspectives is important as you most expert tools only provide limited insight into commonality. While you need to account for it when you have a change that potentially impacts the commonality. Or to assess the impact of introducing commonality.
Do you keep a certain assembly common or introduce a new one for the new product platform? From a function, logical, and physical perspective. What about tools used in the factory or in the field?
Or do you have functions defined in your MBSE model for a platform that has been copied to a different platform because the models do not allow reuse accords models in the current implementation of your MBSE tool?
Commonality has advantages as well as disadvantages. You need to understand the full scope of the impact to make the right decision.
To read more about the CM Baseline and its components, please check out the previous posts from the CM Baseline series:
- Understanding the Impact of Changes introduced the need for the CM Baseline.
- Connections tell the Story introduced the first component of the CM Baseline, the Business Object Graph.
- Intentions are the desire for new Stories, introduced the second component of the CM Baseline, the Impact Matrix.
- Dependencies limit the possible sequences of events, introduced the third component of the CM Baseline, Dependencies or a.ka. Change Dependencies.
- Timing is Everything, introduced the fourth and last component of the CM Baseline, Implementation Plans.
Header Photo by Uriel SC on Unsplash
Pingback: The benefits of NFTs for Configuration Management - MDUX
Pingback: One way to organize information for the CM Baseline - MDUX