Understanding the Impact of Changes

Imagine a world in which we do not have air traffic control, we do not have flight plans or track the progress against these flight plans, but we do have all the flights we have pre-covid19 and we only have line of sight. Every 45 seconds, a plane arrives or departs at any given major airport. How would you prevent catastrophic plane crashes in such a world?

Probably flying would no longer be the safest way to travel.

Flying blind

Now imagine developing products with all its complexity in hardware, software, variability, regulatory compliance, maintainability, and upgradeability. Time to market is short but achieving the next sellable iteration takes time. Concurrent engineering is the way to go. But you have to manage many changes before the product is ready to ship. You are flying blind because you do not have the insight into the impact of each change being processed on all the other changes.
The data is not connected so that this insight can be easily generated and visualized. How do you plan changes if each change competes for the same resources?

The CM2 Baseline

CM2 has a solution for this; they call it the CM2 Baseline or also known as the As Planned/As Released Baseline. This baseline not only contains the latest Released and the Effective configuration, but it also contains all planned changes against the configuration (in context). And not just as a tag that the item/node or dataset will change, it will allows you to show how the delta will impact the item, its structure, and its related datasets.

Sounds good, doesn’t it!

Easier said than done

But it is easier said than done. In most organizations, this information resides in different systems like PLM, ERP, ALM, etc. These systems have different data models that are often difficult to map. In some cases even multiple objects are used in the source tools to describe one business object. For instance depending on your implementation of an Engineering BoM and Manufacturing BoM, you might have implemented it using 2 items with references to one and another.  These 2 items from a business perspective are one and the same. But for people working on them in the expert tools, these have specific meaning. 

See the example below where in a PLM tool, the objects are called ‘Item’ and there is a engineering phantom item I5 in the Engineering BoM of I1, whereas the Manufacturing Item (I1_M) that represents the Manufacturing BoM view of I1, does not have this phantom. The ERP tool has objects called ‘Material’.  The business talks about Parts and recognizes 2 types of BoMs (the engineering BoM and manufacturing BoM) as shown in the Business Object Model (Graph).

Secondly, most impact analysis tools can’t record impact against a planned item or planned dataset.
In a plan, you can define deliverables that can have dependencies with other deliverables. These deliverables can either still be planned, in progress, or completed. While for one change, one plan, it is easy to manage these dependencies, when it comes to managing dependencies across changes, it becomes more difficult.

What can we learn?

Coming back to my example of flights and how it links to managing change. Each flight is like a change with an implementation plan, a.k.a. the flight plan. Flights have dependencies on other flights because you use the same plane or there are passengers on the flight that have connecting flights at the airport of arrival. Each flight has to arrive on time to reach its effectivity, the gate. Thanks to the flight plans being submitted and air traffic control’s ability to track flights and to manage the available runways and airspace, you now have a system to manage any deviations to these plans, including their dependencies.
If you arrive too early, you either have to hold, wait on the tarmac till the reserved slot on the gate becomes available, or you are assigned a new gate.
Same with changing a part of a product, when you complete the deliverable earlier, you might have to wait for the change to become effective. But if you are lucky and dependencies permit, you might be able to make the change effective earlier or lift along with the effectivity of another change. If you’re late, you might not achieve the desired effectivity and have a delay on your hands.

How do you achieve such a capability? In one of my next posts, I will dive into this.