This article is part of the How Do YOU CM2? blog series in collaboration with the Institute for Process Excellence (IpX). Although I receive compensation for writing this series, I stand behind its content. I will continue to create and publish high-quality articles that I can fully endorse. Enjoy this new series, and please share your thoughts!
Every change process is fundamentally the same. You have a Request phase and an Implementation phase. During the Request phase, you handle registration and intake of the request, proposal development, impact analysis, and disposition. During the Implementation phase, you plan the change, align resource commitments, and execute the implementation.
It does not matter if you change a product or an organization; the basic steps are the same.
🥇That means you only need ONE closed-loop change process to handle any change in your organization.
That does not mean:
- that all the people involved are always the same;
- that there is only one form and set of attributes;
- that there is only one route through the change process.
The CM2 Closed Loop Change Process is one change process that supports:
🔀Multiple tracks.
By default, it recognizes fast- and full-track, but you can design multiple tracks to help your organization. However, every track has the same basic steps.
🪸Multiple types of changes
Each type of change can have its own form and related attributes that align with the baseline it impacts. If you impact multiple baselines, the change form must be extended to include the relevant attributes for each baseline.
🎯Multiple Impact Matrices
For each impacted baseline, an Impact Matrix will be available to capture the impact of the change.
🥷Dedicated Change Leaders
CM2 promotes the use of dedicated change leaders and fit-for-purpose change boards to support efficient execution of the change process and robust decision-making. Because efficiency isn’t just about the process, it’s about people.
The takeaway?
You don’t need fragmented, siloed processes for every type of change. Lack of standardization and integration results in rework, missed opportunities, and a lack of traceability. With CM2, you extend the same process to cover different baselines, teams, and initiatives, scaling governance without creating complexity. So, when improvements are made, the entire organization can benefit.
💡 Here’s my question for you:
When your organization implemented a change process, did you adopt a single unified process or multiple processes? What worked, and what lessons did you learn along the way?
👇 Drop your thoughts in the comments, your experience could be the insight another leader needs today.
Change isn’t the problem. Inefficient data models are.
A data model is a representation of the way data is defined and structured in a database. The ability to change your product documentation efficiently highly depends on the data models of the tools you use.
📄 If you are still working on a document-based approach, you need to create a new revision of the entire document and release it accordingly. You take a copy of the latest released revision of your Word document and process the update.
🧩 On the other hand, if you’ve adopted a model-based approach and broken the document into smaller, manageable elements, such as making each requirement its own object, you can now potentially release individual requirements.
But can you always release an individual data element, such as a requirement or a single line in the bill of materials?
👉A dataset is a set of information that must be released as a whole and can be released separately from any other dataset.
⚙️So, replacing one part in a bill of materials with another is a new revision of the BoM. Even if the BoM line is a separate data element, you cannot release it independently from the other BoM lines in the same BoM.
🏭Or suppose you have Product Manufacturing Information (PMI) embedded in your 3D model, and the information is stored in the same revision as the geometry. In that case, you cannot revise the PMI without also revising the 3D model.
But you can change the BoM of a part without having to change its attributes. That means that the attributes of a part are not the same dataset as the BoM. However, in many PLM systems, the revision of a part or item is used to manage both the BoM and attributes. This data model makes changes less efficient.
It is essential to consider data models in the context of change. Creating an initial version is relatively easy, but changing data is always more challenging. Design your data models in a way that allows them to support changes and the release of new revisions efficiently.
💡 How CM2 helps:
The CM2 framework helps standardize your data by providing the blueprint for designing change-ready data models. It teaches us to separate datasets logically, so attributes, BoMs, and requirements can evolve at the pace they need, linked but without unnecessary hard-coupling. The result? Faster, cleaner changes with less disruption.
So I’ll leave you with this:
👉 Is your data model truly supporting change, or making it harder? Share your thoughts in the comments below.
When organizations talk about going model-based, most think about tools, data structures, and integration.
But here’s another real roadblock: tribal knowledge.
For decades, many companies have relied on tribal knowledge, the one engineer who knows why a certain design decision was made, the veteran program manager who “just remembers” why a requirement was skipped, the unwritten rules everyone follows but nobody documents.
👉 In a model-based governance environment, there is no place for tribal knowledge.
Why? Because models don’t guess. Models don’t “just know.” Models need precision, traceability, clarity, and a single source of truth. In other words models need to be clear, concise, and valid!
Here’s where the CM2 standard becomes the bridge:
1️⃣ Define before you design. Governance first, modeling second. A model built on unclear rules is just a prettier version of chaos.
2️⃣ Kill the “expert memory” culture. Replace it with accessible, documented decision logic that anyone can trace and trust.
3️⃣ Shift mindset, not just software. Transitioning to model-based governance is not about digital tools replacing documents, it’s about replacing assumptions with accountability.
And here’s the uncomfortable truth:
- Legacy habits will resist. People like being the keeper of knowledge. However, these experts are crucial in translating their tribal knowledge into models and sharing it with everyone.
- Model-based governance exposes gaps. What was once hidden in coffee corner conversations now demands formal resolution.
But the payoff? 🚀
- Faster impact analysis and planning of changes. Get more done with the same amount of time and resources.
- End-to-End traceability baked-in, that allows you to innovate and be more agile.
- The ability to scale your organization’s knowledge, not just its headcount and without depending on who’s retiring next year.
The organizations that succeed don’t just “install” a new tool; they lead a cultural transformation. They make it safe for people to let go of tribal knowledge, and they prove that documented, model-based governance is not bureaucracy, it’s freedom. Freedom from firefighting, rework, and guessing.
Transitioning from a document-based to model-based isn’t a technology challenge; it’s a leadership challenge.
So I’ll leave you with this:
💡 When your organization says it’s going “model-based,” are you tackling tribal knowledge head-on or just deploying a new tool?
Check out the other How Do YOU CM2? posts.
Copyrights by the Institute for Process Excellence.