Transformation by Type: How Knowledge Gaps Manifest Across Different Transformation Contexts
Avery Brooks
May 27, 2026
The transformation knowledge gap doesn’t just exist in theory. It shows up in every type of transformation - whether you’re implementing an ERP system, scaling an AI model, improving a process, integrating an acquisition, migrating to the cloud, or restructuring your organization. The gap is the same. The knowledge that needs to flow from one phase to the next is the same. But how it breaks is different depending on what you’re transforming.
An ERP implementation breaks because discovery didn’t capture the informal workarounds that the system needs to accommodate. An AI deployment breaks because the pilot team understood the model but enterprise deployment teams don’t. A merger breaks because the acquirer didn’t understand how the acquired company actually operates. A process improvement breaks because the improvement team optimized the happy path and ignored the exceptions that represent 30% of actual work.
Different transformations. Same root cause: knowledge didn’t flow from one phase to the next. Different consequences, different costs, different business impacts. But the underlying problem is identical.
Each transformation type has different actors, different timelines, different complexity. These differences shape where knowledge gaps appear and how costly they become.
ERP and CRM transformations break because implementation teams don’t understand how the current system actually works. They understand the formal process. They don’t understand the workarounds, the informal coordination, the system gaps that the organization has learned to manage. When the new system is implemented without accounting for operational reality, teams spend months in rework creating the workarounds again.
The knowledge gap: What’s the current operational reality? Who knows? What are they doing that’s not documented? Implementation teams rarely ask. The cost: 55% of ERP implementations and 55% of CRM implementations fail or significantly underperform.
AI pilots succeed because they’re controlled. The team understands the model. The data is clean. The use case is narrow. Enterprise scaling fails because the model was trained on one context and deployed in a different context. Teams don’t understand how the model will perform in their specific operational reality. They don’t know how to interpret the model’s recommendations. They don’t know when to trust it and when to override it.
The knowledge gap: How does the model behave in different operational contexts? Why is the model making these recommendations? How do we maintain this model as conditions change? Pilot teams know. Enterprise teams don’t. The cost: 60-70% of enterprise AI deployments fail to achieve adoption because teams don’t trust what they don’t understand.
Lean and Six Sigma teams optimize the documented process. But the documented process isn’t the actual process. Actual processes include exceptions (20-40% of work), informal coordination steps, and workarounds that manage constraints. When improvement teams design without accounting for these, improvements stick for a few months. Then the actual work reasserts itself, and the improvement erodes.
The knowledge gap: What’s actually happening on the shop floor? What exceptions are people managing? Why did they create those workarounds? What constraints are they managing? Improvement teams don’t ask. They optimize the documented process. The cost: 70% of process improvement initiatives fail to stick because they weren’t designed for the operational reality they needed to improve.
An acquisition closes. The acquiring company sends in integration teams. They ask: “How do you do X?” The acquired company explains. Integration planning proceeds. But the acquired company explained the documented process, not the actual process. By the time the acquiring team realizes what they didn’t understand, key people have left. The knowledge that would have shaped a successful integration is gone.
The knowledge gap: How does the acquired company actually operate? What informal structures and decision-making patterns exist? Who are the knowledge keepers? What undocumented dependencies will affect M&A integration? Acquiring teams don’t know. The critical 100-day window closes. The cost: 70-90% of M&A deals underperform due to integration failures because the acquirer didn’t understand operational reality.
A company decides to migrate from one platform to another. The business case is clear: new platform is more efficient. Migration planning begins. The team maps data, systems, integrations. But they don’t map the workflows that only exist because the old platform had gaps. When migration happens, those workflows break. Teams have to recreate them on the new platform. The migration that was supposed to be faster becomes a series of workarounds.
The knowledge gap: What workflows exist because the old platform required them? What manual processes compensate for system gaps? How does data flow in ways that aren’t documented? Migration teams don’t ask. The cost: Hidden workflow knowledge in transformation planning means platform migrations take longer and cost more than planned because teams have to rediscover what the old system’s limitations required.
An organization restructures. Reporting lines change. Team compositions change. The assumption is that the work remains the same; only who does it changes. But the work is embedded in relationships, informal decision-making patterns, and institutional knowledge about who knows what and how to get things done. When the structure changes, some of that knowledge is disrupted. New teams have to rediscover how things actually work.
The knowledge gap: How does the current organization actually make decisions? What informal networks enable work? How do team members currently coordinate? What institutional knowledge will be lost when people move? Restructuring planners don’t ask. The cost: Organizational transformations that don’t account for institutional knowledge create coordination gaps, slower decision-making, and lost productivity until teams figure out how to work in the new structure.
Different transformations. Different contexts. Same pattern:
The difference between transformations that succeed and those that underperform is whether knowledge about operational reality flows from discovery to design to execution. When it does, transformations account for the real world they’re changing. When it doesn’t, transformations are surprised by the real world they encounter.
Different transformation types need different operational knowledge. But they all need the same capability: visibility into how work actually gets done, what constraints exist, what informal processes are critical, and what knowledge is at risk.
ClearWork serves as the transformation intelligence layer across all transformation types. Rather than relying on formal processes and workshop discussions to understand how organizations work, ClearWork uses AI-driven asynchronous interviews to surface operational reality across different transformation contexts.
For ERP/CRM implementations, ClearWork surfaces the current state blind spot: informal coordination, workarounds, system gaps, and integration points that documentation misses.
For AI deployments, ClearWork captures how the model behaves across different operational contexts and identifies what operational teams need to understand to trust and use it.
For process improvements, ClearWork surfaces the exceptions, constraints, and informal steps that represent actual work and need to be designed for.
For M&A integration, ClearWork accelerates operational discovery in the critical 100-day window, capturing knowledge before key people leave.
For platform migrations, ClearWork identifies hidden workflows that exist because the old platform required them.
For organizational restructures, ClearWork captures institutional knowledge about how decisions are made and work gets coordinated.
The platform provides the operational intelligence that transformations of any type need to account for real-world complexity.
Often times it isn't the internal team leading these transformation efforts on the ground. If you are consulting firm and you need to rapidly understand a customer's true situation, learn how ClearWork for consulting can help you get there more rapidly and reliably.
A: The core methodology is the same: understand operational reality in discovery, design based on that understanding, execute with mechanisms to surface emerging issues. But the specific focus changes. ERP needs to focus on current state and workarounds. AI needs to focus on context variation and model behavior. Process improvement needs to focus on exceptions and constraints. M&A needs to focus on speed of knowledge capture. Platform migration needs to focus on hidden workflows. Organizational restructure needs to focus on institutional knowledge. Same methodology, different knowledge focus depending on transformation type.
A: M&A integration faces the most acute knowledge risk because of the time constraint (100-day window). But all transformation types face equally significant knowledge risks; they just manifest on different timelines. ERP implementations have 12-18 months to discover and address knowledge gaps. M&A integrations have 100 days. Process improvements need to maintain knowledge continuously. The worst knowledge risks are the ones that aren’t visible until execution when there’s no time or budget to address them.
A: The discovery process should be tailored to what knowledge matters for that transformation type. But the principle is the same: interview frontline staff about how work actually gets done, document informal processes and workarounds, identify constraints, map dependencies. For ERP, focus on system gaps and workarounds. For AI, focus on context variation and model performance. For process improvement, focus on exceptions and constraints. The discovery framework is consistent; the focus adjusts based on transformation type.
A: This is where organizational knowledge governance becomes critical. If an organization is doing an ERP implementation, a process improvement initiative, AND a restructuring at the same time, knowledge gaps in one transformation can block another. A PMO or transformation office should maintain a knowledge continuity function that ensures: (1) discoveries from one transformation inform other transformations, (2) key knowledge keepers are retained across all transformations, (3) integration points between transformations are understood. Without this, you get coordination gaps and rework multiplied across multiple initiatives.
A: No. Every transformation type needs operational discovery; it’s just a question of what gets discovered. The cost of skipping discovery shows up as execution rework, no matter what transformation type you’re doing. ERP implementations that skip discovery end up with 30-40% post-go-live customizations. AI deployments that skip discovery end up with low adoption. Process improvements that skip discovery end up eroding within 6 months. M&A integrations that skip discovery end up with integration failures. The discovery investment upfront always costs less than the rework that emerges when you skip it.
Different transformation types (ERP, AI, process improvement, M&A, platform migrations, and organizational changes) seem to have different failure modes, but they all break because organizations don’t understand how work actually gets done before designing the transformation. Whether knowledge gaps manifest as current-state blind spots in ERP, context gaps in AI deployment, exception gaps in process improvement, or 100-day knowledge loss in M&A, the root cause is identical: operational discovery either didn’t happen or didn’t capture operational reality. Organizations that apply consistent operational discovery principles across all transformation types - regardless of the transformation context - move from 30% success rates to 70%+ success rates.