Menschgeist

Traditional Organizational Change Management (OCM) typically drives toward a predefined target state. In contrast, Agile Organization (AO) treats the “target” as an evolving, adaptive organizational capability. This difference is clear when viewed through a BPM lens. Traditional OCM adjusts people around processes, while AO organizes processes around the people doing the work.

Short reminder: what BPM is

Business Process Management (BPM) is a management discipline. It involves analyzing, designing, implementing, monitoring, and continually improving end‑to‑end business processes. The goal is to enhance performance and customer outcomes. It treats processes as repeatable flows of activities that can be modeled, measured, and optimized across the organization. A classic BPM initiative focuses on mapping processes. It defines owners and standardizes work. Governance and tools are used to control and improve those flows over time.

Target solution: fixed state vs evolving capability

In traditional OCM, the target solution is usually a relatively fixed “to‑be” state defined upfront. This includes new processes, structures, roles, and systems. The change effort is about moving people from the current state to the target state. This creates a linear narrative. First, diagnose the gap. Next, define the future state. Then build the change plan. Finally, drive adoption until the new state is “embedded.” AO, by contrast, assumes the environment changes faster than any fixed blueprint. Therefore, it treats the “target” as an adaptive organization. This organization can continuously sense, decide, and reconfigure itself.

This leads to different questions. Traditional OCM asks, “How do we get everyone to the new operating model and keep them there?” AO asks, “How do we build structures, practices, and agreements that make continual reconfiguration safe, fast, and purposeful?” In OCM, you measure success by the degree of compliance with the designed target. In AO, you measure success by the organization’s adaptive capacity. This includes the speed of learning, the quality of decisions, and the ability to re‑shape work as conditions change.

Change logic: gap closing vs pattern evolving

Traditional OCM is gap‑closing. It involves defining the desired end‑state. Then, assess readiness and treat resistance. Afterward, roll out communications and training. Finally, stabilize into BAU. This often assumes relatively stable strategy, technology, and process architectures, even if they are complex. Governance, templates, and standardized toolkit become very important. The organization is encouraged to align with the one approved solution.

AO works with evolving patterns instead of final states. It creates conditions where multiple hypotheses can be tried in parallel. Teams experiment with structures, roles, cadences, and interfaces. The most effective patterns are then scaled. The focus changes from managing resistance to engaging people. They become designers of their own context. Explicit mechanisms help retire obsolete structures and practices. These prevent defending them as the “new normal.”

BPM lens: process‑centric vs people‑centric organization

Seen through BPM, traditional OCM tends to be process‑centric. You begin with the process map. You then define the optimal flow. Next, ask: “How do we align people, roles, and org structures around this process so it can run efficiently?” People play roles in predefined sequences. Change management ensures they execute the new process correctly. It also ensures they do it consistently. The process is the primary object; people are variables to be aligned to it.

AO almost inverts this perspective. It treats people as the core organizing principle. This includes teams, networks, and communities of practice. Processes are used as flexible instruments. These instruments can be shaped, combined, or dropped by the people. Instead of “adjusting people around business processes,” AO focuses on the people in the BPM. This includes who actually carries the work, who holds the knowledge, and how they collaborate to create value. Processes become boundary objects and agreements. They are not cages. Teams can adapt workflow, sequencing, and interfaces as they learn. They must respect purpose, constraints, and minimal interoperability standards.

Concretely:

• In traditional OCM+BPM, a process redesign project defines the new flow, roles, and KPIs. Then, OCM ensures training, communication, and adoption. This continues until variance is minimized.
• In AO+BPM, the teams that own the work continuously define and refine their processes. The BPM artifacts are deliberately kept light and revisable. This makes it possible to change them when the work or context changes.

Organizational design implications

You tend to get functional or process‑tower structures if you start from a fixed target and process‑centric BPM. This approach leads to strong central governance. There is also a heavy emphasis on standardization and control. This works well for high‑volume, low‑variety work and for environments where predictability matters more than innovation. However, it struggles when customer needs, technology, or regulations shift frequently. Every change implies a new “big” OCM program to move from one fixed state to another.

AO’s adaptive target and people‑centric BPM logic lead to modular, networked structures. These consist of small, semi‑autonomous units. They are linked by minimal essential constraints, such as common principles, standards, and interfaces. AO embeds change into the operating model, instead of running a sequence of large OCM initiatives. Local changes are expected and supported. BPM provides just enough shared scaffolding for coherence and coordination. This reduces the dependency on central change programs and increases the organization’s ability to reconfigure itself from the edges.

Examples of companies using Traditional OCM successfully

Several well‑known companies have used traditional, plan‑driven OCM successfully, especially for large technology and process roll‑outs.​​

Illustrative company examples

• A leading retail pharmacy chain introduced a new point‑of‑sale system. It used a classic OCM playbook. This included early stakeholder involvement, structured communications, and role‑based training. Within six months, it achieved 70% faster transactions. Customer satisfaction increased by 25%. This success shows how traditional OCM can work well for clearly bounded system changes.​
• A global pharmaceutical company implemented a new data management platform and faced strong initial resistance. By applying a standard methodology (sponsor coalition, communication plan, training, and incentives for early adopters), significant progress was made. It reached 80% user adoption in the first year. Data quality and decision speed improved. ​
• A Fortune 500 chemical company followed a structured, multi‑phase ERP change management approach with defined phases, deliverables, and KPIs. The program delivered around a 25% gain in operational efficiency. Another firm in the same material reduced month‑end closing time from 15 to 5 days. This was achieved after optimizing ERP usage under a traditional OCM framework.​
• A public‑sector agency (the U.S. General Services Administration) migrated to Google Workspace using extensive up‑front training, communication campaigns, and a phased cut‑over. Within weeks, help‑desk call volume dropped below the prior baseline. Most users who attended training adapted quickly. This illustrates how standard OCM tools can smooth a large collaboration‑suite rollout.​

These cases all share the typical traditional OCM characteristics. They include a predefined target solution such as POS, ERP, data platform, or collaboration suite. The methodology is structured for change. They have strong executive sponsorship. Success is measured as stable adoption of the designed end state.

Implementation steps for Adaptive OCM emphasize less on delivering a single change project. They focus more on building a system capable of continuous change. Here is a concise step set you can reuse and adapt.

1. Diagnose adaptiveness, not just readiness

• Assess current culture, leadership behaviors, and structural constraints for adaptability (decision speed, psychological safety, learning habits, autonomy).​
• Map change fatigue, existing OCM practices, and where people already self‑organize successfully; treat these as seeds to amplify.​

2. Define adaptive intent and guardrails

• Clarify why you need an adaptive organization now (market volatility, digital pace, etc.) and what “more adaptive” means in concrete behavioral terms.
• Set a small number of non‑negotiable constraints. These include principles, ethics, compliance, and customer promises. Within these, local units are free to experiment and redesign.

3. Create distributed change roles and capabilities

• Shift from a central “OCM team that implements change” model. Develop a distributed network of change agents embedded in teams. Provide these teams with coaching from OCM specialists.​
• Design targeted training on adaptability skills (experimentation, feedback, conflict, facilitation) rather than only “how to use the new process/system.”​

4. Implement iterative change planning and delivery

• Replace big upfront change plans with rolling, lightweight plans that are revisited every few weeks based on feedback and impact.​
• Use small experiments like pilots or A/B testing in ways of working. Implement micro‑structural tweaks and scale what works. Do this instead of committing early to a single solution.​

5. Build continuous feedback mechanisms

• Install regular pulse checks, retrospectives, and qualitative sensing (focus groups, open forums) as a permanent feature, not just during “projects.”
• Close the loop visibly. Show what was heard. Indicate what is being changed. Explain what will not change and why. This approach will maintain trust in the adaptive process.​

6. Align operating model elements with adaptiveness

• Adjust governance to allow faster local decisions, clear accountabilities, and simple escalation paths; avoid over‑complex approval chains.​​
• Rework structures, roles, and BPM artifacts. This allows teams owning the work to modify processes within agreed boundaries. They can do this without launching a major program each time.​​

7. Reinforce and normalize adaptive BEHAVIORS

• Recognize and reward experimentation, constructive challenge, and cross‑boundary collaboration, not only short‑term efficiency.​
• Integrate adaptive OCM practices into BAU. Use quarterly sense-and-respond cycles and establish standing change communities of practice. This ensures that “doing change” becomes “how we work.”