Why Your SME is the Wrong Person to Lead ERP Discovery

Here's a scenario that plays out in conference rooms across the enterprise world:

Leadership decides it's time to upgrade the ERP system. They assemble a discovery team led by Sarah, who's been running procurement for 18 years. Sarah knows the procurement process inside and out. She's trained dozens of new hires. She's optimized workflows that used to take days down to hours. She's the obvious choice to design the new system.

Eighteen months later, the project is $800,000 over budget, three months behind schedule, and the actual procurement team is still using Excel because "the new system doesn't work for real situations."

What happened? Sarah fell victim to the Curse of Knowledge.

What is the Curse of Knowledge?

The Curse of Knowledge is a cognitive bias where people who understand something deeply become unable to imagine what it's like not to know it. Once you know how something works, you can't unknow it, and you systematically underestimate how difficult it is for others.

In ERP discovery, this manifests in devastating ways:

Assumed Context: The SME designs workflows that assume everyone has their level of expertise. "Obviously you check the backorder report before submitting the PO." Obvious to whom? To Sarah, who's been doing this for 18 years. To the temp worker hired last Tuesday? Not obvious at all.

Invisible Steps: After 18 years, many process steps become automatic—muscle memory. When Sarah documents the process, she literally forgets to mention steps that are so ingrained they're unconscious. The new system launches missing critical steps that "everyone just knows."

Exception Blindness: Experts handle exceptions so smoothly they don't register them as exceptions anymore. "Oh, when the supplier is in Canada, you need to check the duty codes and route through the customs broker." Sarah does this automatically. Her documentation says nothing about it. The new system has no accommodation for it.

Workaround Normalization: Sarah has built 47 workarounds over the years. They're so normalized she doesn't even think of them as workarounds—they're just "how it's done." These never get documented, so the new system recreates the same gaps, and the workarounds simply migrate.

Why Leadership-Only Discovery Fails

The flip side of the SME problem is the leadership-only approach. Some organizations recognize that long-tenured employees might have too much baggage, so they limit discovery to directors and VPs who "understand the strategic picture."

This fails for the opposite reason:

Altitude Blindness: Leadership understands the intended process but is disconnected from operational reality. They design based on how work should flow, not how it actually flows. The gap between these two is where ERP projects die.

Political Process: Leadership-driven discovery becomes political. Departments fight for features and customizations based on perceived status rather than operational need. The loudest voice wins, not the most critical requirement.

Reporting Layer Bias: Leaders see the process through reports and dashboards. They don't see the three hours of manual data cleanup that happens before the report is accurate. They design for the output without understanding the input reality.

A director knows the procurement policy. Sarah knows the procurement process. The person who's been doing PO entry for six months knows the actual procurement process—including all the undocumented steps, edge cases, and workarounds that make it function.

What Bottom-Up Discovery Looks Like

Effective ERP discovery requires a bottom-up approach that systematically counteracts the Curse of Knowledge.

Interview the Doers: Talk to the people who execute the process 40 times a day, not just the people who designed it or manage it. Ask them to show you, not tell you. Watch what they actually do, including the steps they don't think to mention.

Map the Exceptions: Official process documentation covers the happy path. Real processes are 60% exception handling. Document the "what ifs" and "special cases." These aren't edge cases—they're the bulk of actual work.

Follow the Shadow Processes: Identify where people are using Excel, email, or personal systems to supplement the official process. These shadow processes reveal gaps in the current system that will become gaps in the new system unless explicitly addressed.

Test with Novices: Have someone unfamiliar with the process attempt to execute it using only the documentation. Where do they get stuck? What questions do they ask? These reveal the assumed knowledge that experts no longer see.

Capture Tribal Knowledge: Identify the "just ask Susan" moments. When documentation says "coordinate with supplier management," but everyone knows you really need to call Susan in Logistics because she has the actual contact list—that's tribal knowledge that needs to be systematized.

The Owner's Representative Approach

Construction projects solved this problem decades ago with the Owner's Representative model. When you're building a hospital, you don't let the construction company design the facility and manage the project without oversight—that's a conflict of interest. You hire an Owner's Rep who works for you, understands construction, and advocates for your interests against vendor incentives to cut corners or pad scope.

ERP implementations need the same model.

An Owner's Representative for ERP implementations serves as the counterweight to both the Curse of Knowledge and vendor conflicts of interest:

Neutral Facilitator: The Owner's Rep isn't Sarah and isn't Sarah's boss. They have no emotional attachment to "how we've always done it" and no political incentive to preserve departmental turf. They can ask the naive questions that reveal hidden assumptions.

Process Archeology: The Owner's Rep conducts systematic discovery that surfaces both official and shadow processes. They interview at all levels, observe actual work, and map the gap between documented and practiced processes.

Vendor Accountability: The Owner's Rep holds the implementation partner accountable for delivering what was promised, not what's easiest for them. When the vendor says "that's out of scope," the Owner's Rep determines whether it was truly out of scope or should have been caught in proper discovery.

Change Translation: The Owner's Rep translates between leadership vision, SME expertise, and frontline reality. They ensure the system serves all three constituencies, not just the loudest one.

Real-World Anti-Patterns

Let's look at what happens when these principles are ignored:

The Expert-Designed Disaster: A manufacturing company let their most experienced production scheduler design the new production planning module. She designed workflows that assumed everyone had her encyclopedic knowledge of machine capacities, maintenance schedules, and supplier lead times. The result: a system that only she could use effectively. When she retired 18 months after go-live, the company had to bring her back as a consultant because nobody else understood the logic she'd built.

The Leadership Fantasy: A distribution company designed their new WMS based on director-level vision of "optimized picking routes" and "dynamic slotting." It looked beautiful in the demos. In practice, the warehouse team couldn't use it because it didn't account for the reality that forklift #3 has a broken steering column, slot B-47 has a leak so we don't store anything there, and Jimmy is the only one certified on the reach truck so routes need to minimize reach truck requirements. The system was redesigned 14 months after launch at a cost of $400,000.

The Undocumented Dependency: An ERP implementation for a chemical distributor launched without discovering that Jane in Customer Service maintained an Access database with customer-specific packaging requirements, hazmat certifications, and delivery constraints. This database wasn't in scope because nobody thought to ask Jane about her tools—she wasn't senior enough to be interviewed. The new system launched, Jane's database wasn't migrated, and customer shipments started failing compliance checks. Total cost: $180,000 in rush fixes and delayed shipments.

The Discovery Process That Works

Effective discovery follows a structured approach that systematically defeats the Curse of Knowledge:

1. Map the Official Process: Start with documentation and leadership interviews to understand the intended workflow.

2. Map the Actual Process: Interview and observe the people doing the work to understand the practiced workflow. Note every divergence from the official process.

3. Identify Shadow Processes: Use Deadweight Diagnostics to find the Excel trackers, email workflows, and personal databases that supplement the official system.

4. Reconcile the Gap: For every divergence and shadow process, determine: Is the official process wrong? Is there a legitimate gap? Is this a workaround that indicates a missing feature?

5. Design for Reality: Build requirements based on how work actually happens, not how it's supposed to happen. If 40% of orders require manual intervention for pricing, that's not an exception—that's a core requirement.

6. Test with Novices: Before finalizing the design, walk through scenarios with people who don't have expert knowledge. Where they get confused is where the Curse of Knowledge is still hiding.

The Path Forward

Your most experienced people are invaluable—but not for the reasons you think. Sarah's 18 years of procurement expertise makes her an incredible resource for understanding edge cases, validating requirements, and training users. But leading discovery? That requires someone who can see the process with fresh eyes, ask naive questions, and systematically surface the assumptions that experts no longer know they're making.

This is why operational integrity requires an external perspective. You can't fix the Curse of Knowledge from inside it. You need someone who can bridge the gap between leadership vision, expert knowledge, and frontline reality.

That's where an Owner's Representative becomes essential.

Ready to run discovery that actually works? Let's talk.