ERP and CRM Implementation: The Current State Blind Spot (And Why Discovery Determines Success)
Avery Brooks
July 3, 2026
Fifty-five percent of ERP implementations fail. Fifty-five percent of CRM implementations fail. The failure rate is consistent across industries, company sizes, and geographies. But the reasons for failure are rarely technical. They're almost always about one thing: the organization didn't understand the current state before attempting to change it. This is how the transformation knowledge gap manifests in system implementations—for a deeper look at how this challenge shows up across different transformation types, read "Transformation by Type: How Knowledge Gaps Manifest Across Different Transformation Contexts."
An organization decides to implement a new ERP system. The business case is strong: reduce manual data entry, eliminate spreadsheets, improve visibility. The vendor is selected. The team is assembled. Discovery begins. The discovery team maps the formal processes: create PO, approve PO, receive goods, match invoice. Straightforward. Design builds a solution around this formal process. Implementation runs according to plan. Go-live happens. And then reality collides with design.
A team that was doing manual reconciliation in the old system needs to continue doing reconciliation in the new system because the new system doesn't capture the data the way the old system did. A workflow that was documented as "finance approves purchase orders" was actually "finance approves purchase orders after operations checks feasibility." Operations wasn't in the design because discovery didn't know they were involved. A process that was described as "system-driven" actually required five manual handoff steps because the system had gaps that nobody documented.
These aren't technology failures. They're current-state failures. The organization designed a new system based on an incomplete understanding of the current state. And when the new system didn't match operational reality, implementation became a series of workarounds and customizations. By the time the project finished, it was over budget, behind schedule, and over-scoped.
Most ERP and CRM projects start with a formal process. "Here's how we enter orders." "Here's how we track customers." The formal process is documented. It's what the organization thinks it does. But it's not what it actually does.
A PO approval process is documented: "Submitted by requester → Reviewed by manager → Approved by finance → Released to vendor." But there are informal steps that aren't documented. A requestor calls the manager to get a heads-up before submitting. The manager checks feasibility with operations before approving. Finance asks procurement for historical spend before approving. These informal coordination steps aren't in the documentation because they're obvious to people who work there. But they're invisible to a design team building a new system.
When the new system is built without accounting for these steps, the workflow breaks. Teams do the new process and discover that they're missing critical information. They create workarounds to capture the missing information. The system becomes less efficient than the old system, not more.
A CRM system has a workflow for "lead to customer." Straightforward path. But there are exceptions. A lead who's already a vendor. A lead who's referred by a partner and needs special terms. A lead in a regulated industry who requires compliance documentation. These exceptions represent a significant portion of actual work, but they're invisible in formal documentation because documentation focuses on the happy path.
Design builds a system around the happy path. When exceptions show up during go-live, they either require manual workarounds or need to be customized into the system at great expense.
Most legacy systems have gaps. The system doesn't track a data element that the business needs. The system doesn't support a workflow that's critical. The system is too slow for real-time decisions. Organizations work around these gaps. A team manually maintains a spreadsheet because the system doesn't have the report they need. A workflow that the system doesn't support is managed by email. A calculation that's too complex for the system to handle is done outside the system.
A new ERP or CRM implementation should eliminate these workarounds. But if discovery doesn't find the workarounds, design can't design them out. The new system is built without accounting for the gap, and the workaround continues.
Most organizations have a system landscape: primary system, secondary systems, data warehouses, analytics platforms. Data flows between them. Integration points are either automated or manual. A lot of these integration points are undocumented. A team extracts data from the ERP into Excel, manually cleans it, and loads it into a data warehouse. No formal integration. Just a task somebody does every night.
When a new ERP is implemented, the team assumes these integrations will be handled by the new system. But the integration wasn't documented, so it was never added to the scope. The data flow breaks at go-live. The team is back to manual extraction.
A CRM is designed around how the organization is structured. Sales is structured as regions. But the actual sales process goes across regions. A team in region A works with a team in region B to serve certain customers. The CRM is designed with regional security and regional reports. But the actual workflow crosses regions.
Design didn't account for this because discovery mapped the formal organization, not the actual workflow. At go-live, the system creates barriers to how work actually gets done.
ERP and CRM implementations that succeed start with operational reality discovery, not process documentation.
A manager can describe the formal process. A front-line person describes what actually happens. A manager says "We enter orders into the system." A data entry clerk says "I enter orders into the system, but I first call logistics to check availability, and I talk to the accounting department if there's a credit hold, and I manually update a spreadsheet to track which orders are on back-order because the system doesn't show that."
Front-line staff knows the informal steps, the workarounds, the exceptions. They know what the manager thinks is simple actually has five steps.
Ask people what steps they take that aren't in the official process. Ask what spreadsheets they maintain outside the system. Ask what information they need that the system doesn't provide. Ask what they do when the system doesn't work the way they expect.
Document these thoroughly. Each workaround is evidence of a gap in the current system. A well-designed new system should eliminate the gap, not perpetuate it.
Ask how data flows between systems. Ask if any data movement is manual. Ask if any system outputs get used as inputs to other systems or processes. Ask if any reports are run manually because the system doesn't produce what's needed.
Document the full data landscape. Each manual integration is a candidate for automation in the new system. Missing integrations should be in scope before the new system goes live.
Ask what happens when a normal case doesn't apply. What happens when a customer is already a vendor? What happens when an order is for a customer in a regulated industry? What happens when there's a credit hold?
Don't assume exceptions are rare. In most organizations, exceptions are 10-30% of actual volume. A system designed without exception workflows will be inadequate.
Before implementation, test the design against real examples from the current state. Take actual cases—including exceptions—and run them through the proposed system design. Ask: "Does the new process handle this case?" If not, design change is needed before implementation, not during.
Organizations that discover operational reality before design see dramatically different outcomes:
60-70% reduction in post-go-live customizations. Workarounds and gaps that should have been designed out don't materialize at go-live because design accounted for them.
40-50% improvement in system utilization. Users adopt the system faster because it works the way they work, not the way the formal documentation says they work.
30-40% improvement in project timeline and cost. Projects don't discover major design gaps during implementation. Scope is locked earlier because it was more comprehensive.
Significantly higher user adoption. When the system is designed around how people actually work, adoption is faster and resistance is lower.
Effective ERP and CRM implementations require deep understanding of the current operational state before design begins. But discovering that state is difficult. Formal documentation is incomplete. Workshops capture what managers think happens, not what frontline staff actually do. Current state assessments typically miss the informal coordination, hidden dependencies, and workarounds that determine whether a new system will succeed.
ClearWork enables comprehensive current state discovery through AI-driven asynchronous interviews with frontline staff across the entire organization. Rather than relying on documented processes and workshop discussions, ClearWork surfaces the actual workflows, including informal coordination steps, workarounds, exceptions, and integration points that formal documentation misses.
The platform identifies what work people actually do (versus what documentation says), what gaps they manage through workarounds, what system constraints they've adapted to, what data they need that the current system doesn't provide, and what integration points are manual or undocumented. This intelligence becomes the foundation for current state discovery that actually reflects operational reality. Design teams can then build systems that account for real-world complexity from day one, rather than discovering gaps during implementation when they're expensive and disruptive to fix.
Learn more about ClearWork
A: For ERP implementations of typical organizational complexity, comprehensive current state discovery should take 12-16 weeks. This includes mapping organizational structure and decision flows, interviewing frontline staff, testing system capabilities against actual workflows, identifying all integration points, and validating discovered processes with broader stakeholder groups. Rushing this phase guarantees problems downstream; investing time upfront prevents costly rework.
A: Most ERP implementations fail because they're designed based on formal documentation, not operational reality. Organizations underestimate the gap between documented processes and actual workflows. They miss informal coordination steps, workarounds, exceptions, and system integration points. Then during go-live, these undiscovered realities cause major design gaps that require expensive customization, scope expansion, and timeline delays. The solution: invest in discovering the actual current state before design begins.
A: Comprehensive current state discovery discovers what's actually in scope before design and implementation begin. This prevents late-stage surprises that cause scope creep. When discovery finds informal steps, workarounds, exceptions, and integration points early, they can be designed for from the start—rather than discovered during implementation when they're expensive to address. Organizations that invest 12-16 weeks in current state discovery before design see 60-70% fewer post-go-live customizations and dramatically better timelines.
A: The best ERP implementation readiness approach is to test the designed system against real current-state examples before go-live. Take actual cases—including exceptions and edge cases—and run them through the proposed system design. Ask: "Does the new process handle this case? Does the system support all the data these workflows need? Are all the integration points covered?" Testing design against operational reality before implementation is cheaper than discovering gaps at go-live.
A: The best CRM implementation practices focus on understanding actual sales and customer processes, not just documented ones. Interview frontline sales and support staff, not just managers. Map exception workflows (special terms, partner deals, regulatory requirements). Identify system integration points. Understand organizational realities that don't match the org chart. Test design against real customer scenarios before implementation. The goal: design a CRM that works the way people actually work, not the way formal documentation says they work.
Before your next ERP or CRM design phase begins, invest two weeks interviewing frontline staff (not managers, not documentation) about how they actually do work. Ask about informal coordination, workarounds, exceptions, and system gaps. You'll discover operational reality that formal documentation completely misses—and that discovery will determine whether your implementation succeeds.
Fifty-five percent of ERP and CRM implementations fail because they're designed without understanding the current state. The other 45% succeed because they invested time in discovering operational reality before designing the new system.
The difference isn't the technology. It's the discovery process. The organizations that understand what people actually do, what workarounds they've created, what exceptions they manage, and what information they need—those organizations design systems that work. The organizations that design based on formal documentation design systems that require extensive customization and workarounds.
Understanding the current state isn't extra work. It's the work that determines whether the new system succeeds.
The current-state blind spot—the gap between how organizations think they operate and how they actually operate—is the primary driver of ERP and CRM implementation failure. Organizations that invest in discovering the actual workflows (including informal coordination, workarounds, exceptions, and integration points) before design begins see dramatically better outcomes: 60-70% reduction in post-go-live customizations, faster system utilization, and higher user adoption. When implementation teams understand the current operational reality, they design systems that work; when they design based on formal documentation, they design systems that require extensive rework.