The Forgotten Phase of Every ERP Implementation: Value Realization

Picture of Denise Fuchs

Denise Fuchs

VP of Delivery & Customer Success

Your ERP implementation was declared a success. Everyone got trained. The proverbial ribbon was cut.

But your planners continue to live inside Excel. And that report you used to run in five minutes now takes 25 (often even if you’ve layered on AI, because it doesn’t have the right data.)

Executives don’t invest millions in ERP systems to create better spreadsheet. They invest to improve profitability, increase operational visibility, and build an organization that can sacle.

We’ve written before about the gap between going live and getting the value you paid for. In this article I want to walk through what to do about it once you realize you’re there.

The good news: It’s not an ERP issue. You probably made a good choice with the software. The problem is that optimizing the platform was never defined as a phase. Your project may have had a go-live date, but it never had a “Now let’s actually get our money’s worth” date.

The implementation may have ended, but the transformation never did.

It’s time to fix that.

Why this happens

Most under-performing ERPs we’ve run into are ultimately a function of a rushed implementation.

There were usually good reasons for it at the time. Perhaps it was a licensing deadline, or the person who owned the technical debt was retiring, or you have an impending acquisition.

Often it’s a budget thing. You deliberately implement an “MVP” with the idea you’ll figure out the rest later. But that phase never gets a concrete plan, or a budget, or an owner. So your consultants move on, the employees who were closest to it leave, you realize you have little to no documentation, and you end up running the new system the same way you did on the first day. Sometimes for years.

Every month this continues, the organization accumulates operational debt. Workarounds become standard operating procedures, institutional knowledge replaces process, and the cost of fixing the problem continues to increase.

How do you know you have an issue? Some of the signs we see most often:

  • Users keep saying some version of “there has to be a better way to do this.”
  • The real system of record is still Excel, and the ERP is where data goes afterward.
  • Reporting isn’t giving leadership what it needs, or different departments are consistently reporting different numbers.
  • Integration and EDI errors keep piling up.
  • Users are shopping for add-on products to do things they assume (incorrectly) the ERP can’t.
  • You’re growing, doubling, adding a facility or acquiring a company, and you’re not confident the current setup will scale.
  • You’re talking about AI, but most of your processes are still manual and your data isn’t in a place to do anything useful with it.

These are not simply technology problems. They affect working capital, throughput, customer service, operating cost, employee producivity, and the organization’s ability to scale.

The Five Phase ERP Value Realization Process

Once leadership decides to do something about it, the temptation is to simply start fixing things. But I’d like to humbly suggest you resist that.

I’ve learned this the hard way. When you don’t have a structured look at where you actually stand, things quickly devolve into bug triage. Finance wants their thing fixed, manufacturing wants theirs, etc. It becomes a glorified ticketing queue rather than a strategic optimization process.

Instead, run a formal process. The one we like to use at Doppio has five distinct phases:

  1. Discover. Map the gaps across the full system – configuration, processes, integrations, data quality, reporting, training and documentation, support. It’s also helpful to take a look at your business process maturity and organizational readiness at the same time. If the maturity isn’t there yet, it probably makes sense to get help building it first.
  2. Prioritize. Score everything and let the math build the sequence (more on this below).
  3. Protect. Separate production support from optimization work. You never want live operations to take a hit.
  4. Optimize. Deliver improvements in measurable sprints. Each should have acceptance criteria, test coverage, and business validation.
  5. Scale. Once you have a stable foundation you can start to look at layering automation and AI on top. My colleague Prem wrote a great piece on this here. AI does not fix broken processes, it scales them. Organizations that rush into AI without first optimizing their ERP often automate ineffeciency instead of eliminating it.

Why “must have / should have / could have” breaks down

That prioritization step is where things can go off the rails. It’s very common to use the MoSCoW model, or “must have, should have, could have, won’t have.”

It totally makes sense on its face. But practically it collapses almost immediately. Everyone will insist their item is a must-have. So you either end up ranking it based on who has the most political capital, or who is the loudest.

It also lends itself to a situation where “optimization” is just a catch-all for every annoyance, regardless of how important it is to the business. You want to focus on the critical things, the most valuable things, and stay disciplined about what you’re not doing right now.

We’ve found a weighted scoring model to be more useful for this. It gives you a more principled way to say “not yet” without saying “never.” You define a set of criteria with weighting for each. For example:

  • Business impact – 25%
  • Operational risk – 20%
  • User adoption impact – 15%
  • Integration dependency – 15%
  • Reporting and data impact – 15%
  • Effort and complexity – 10%

Each potential optimization then gets scored against each criterion (except effort) on a simple scale, with each level anchored to a concrete definition. That last bit is critical – you want a 4 to mean the same thing whether finance or manufacturing is doing the scoring. The scores then get multiplied by each criterion’s weight, rolled up into a single value score, and plotted on one axis.

Effort is on the other. Simply going off the value scores without considering effort can give you items with identical scores, but one is a quick win and the other is a money pit.

What results should be a pretty accurate representation of the landscape. Fixing EDI integration errors might be a quick win. A full integration rewrite might be a strategic bet you schedule deliberately, or something you defer entirely. Either way, the decision is now at least somewhat objective and defensible.

The importance of running two tracks at once

The single biggest fear companies have about optimization is that they might break what already works. And it’s a legitimate fear – I’ve seen it happen. The answer is to run two tracks in parallel.

Track one protects live operations. It runs continuously, monitors production stability, and handles emergency fixes outside the sprint cycle. It also feeds regression and smoke testing into every sprint so nothing breaks upstream.

Track two works the optimization backlog. Generally this is sprint-based and time-boxed, working through functionality roughly based on the prioritization matrix from above.

What the wins usually look like

Every company’s roadmap is different. But after doing many of these, certain patterns have emerged. The highest-value optimizations tend to cluster in a few areas:

  • Manufacturing process improvements, like finding production bottlenecks and improving scheduling.
  • Better financial reporting, including a faster month-end close and numbers leadership actually trusts. (The close is a diagnostic all by itself – my colleague Arend went deep on it here.)
  • Integration stability. Connections to CRM, EDI, and other external systems that throw constant errors. Getting error monitoring in place and cleaning up the worst offenders is often a fast, visible win.
  • Training. You probably had the crash course when the ERP went live. But getting the most out of your system requires actual role-based training on how the team should use the system now.
  • Business process verification. Using the ERP to step back and asking the question, “Is this really how we should be doing this?”

Where to start

The first step in the Discover phase is (you guessed it) an optimization assessment. You want to dig into where the value actually is in a structured way, and come away with a prioritized roadmap that the optimization step of the process can run. A quality assessment shouldn’t simply identify problems. It should answer things like:

  • Where is value being lost?
  • What is causing it?
  • What should leadership invest in first?
  • What can wait?
  • What measurable business outcomes should be expected?

It’s pretty typical to come away with a phased roadmap covering the next 8-12 months, focused on the highest value initiatives that minimally disrupt daily operations.

If your ERP went live but you think there’s more value to unlock, we’re happy to be a second set of eyes. An optimization assessment can be a low-risk way to find out where you stand and what’s worth doing first. If that sounds interesting, don’t hesitate to reach out.

More To Explore