For CFOs and leadership teams, a new enterprise resource planning (ERP) system represents hope. Hope for cleaner data, clearer workflows, faster closes and a single source of truth that finally brings the organization into alignment. It is a compelling vision, and one we have watched companies invest millions to pursue. But too often, the result falls short. Not because the technology failed, but because the organization was not ready for what the technology would reveal.

Here is the uncomfortable truth about ERP implementations: The system does not fix your problems. It reflects them. Think of it as organizational therapy you did not know you were signing up for. The ERP is not the solution. It is the mirror. And for companies operating with broken processes, poor documentation or a culture of workarounds, that reflection can reveal more than leadership expected to see.

The Mirror You Didn’t Ask For

In several cases we have worked on, companies selected a system without first conducting a sufficient assessment of their data and business requirements, processes, maps and operational constraints. The gap only became visible after go-live, when it became clear the system could not handle the organization’s data needs.

The result was a familiar cascade: month-end close delays stretching from weeks into months, manual workarounds becoming necessary to keep the books moving, and audit risk increasing with every cycle.

Rather than using the implementation as an opportunity to rethink existing workflows, the system was configured to reflect them without first questioning whether they still made sense. When the system could not accommodate certain requirements, management was forced to implement manual controls to address compliance gaps.

Underneath what looks like a technology failure, we consistently find an organizational one. The system did not create these problems. It exposed processes that were poorly documented, unnecessarily complex or dependent on workarounds long before implementation began.

The Cost Of ‘We’re Different’

Why weren’t those processes challenged before implementation? More often than not, it begins with a familiar assumption: “Our business is unique.” The argument usually sounds reasonable: Our business is complex, our workflows are specialized, the out-of-the-box solution will not work for us. Sometimes that is true. More often, it is a way of avoiding the harder conversation about which processes need to change.

It is also, frequently, the result of having the wrong people in the room at the wrong stage. IT and finance leadership tend to be present from the start, but operations and middle management are often brought in too late. Their early involvement matters, not to preserve existing processes, but to provide an honest picture of how work actually gets done before the design phase begins. Without that visibility, the project proceeds on untested assumptions, and by the time the gaps surface, customization can feel like the only option when process redesign was the better one all along.

The consequences are predictable. We have seen clients abandon extensive customizations after significant time and investment because the modifications never delivered the promised efficiencies. Others over-customize their ERPs to the point they can no longer explain their own system functionality without a consultant present.

And the costs don’t stop there: Every customization creates something auditors need to understand, test and get comfortable with, and those costs recur annually. Even when a customization delivers real efficiency gains, those gains need to be weighed against the recurring audit burden they create. Organizations that choose customization over process redesign often pay for it twice: once during implementation, and again when the audit surfaces the underlying issues those customizations failed to solve.

What Right Looks Like

In one engagement, IT worked directly with business teams from the outset, not to replicate what existed, but to redesign how controls would work in the new environment. Operational users were brought into testing before the configuration was locked in, surfacing issues while they were still inexpensive to fix. Documentation was treated as a deliverable, not an afterthought, and the project team remained disciplined to the design decisions made during planning.

The result was an implementation that came in on time and on budget, with a finance team that could confidently explain its controls to auditors.

The difference between that engagement and the troubled ones was not the technology. It was the questions the organization was willing to ask before a single line of configuration was written:

• Why do we do it this way?
• What is the simplest version of this process?
• What would this look like if we designed it without the constraints of how we have always done it?
• Is this a true business requirement, or simply how we have always done it?

These questions sound simple. In practice, they are among the hardest an organization can ask, because answering them honestly requires confronting the gap between how the business thinks it operates and how it actually operates.

The CFO’s Real Job In An Implementation

If a new system is a mirror and implementation forces an organization to confront what it sees, then the CFO’s job is to prepare the organization for that reflection and to ensure the difficult decisions made during planning remain intact throughout implementation. This includes ensuring customization is reserved for genuine business requirements, rather than used to preserve processes the organization was unwilling to challenge.

These projects expose gaps, challenge assumptions and surface conflicts that have been quietly sitting beneath the surface of daily operations. That discomfort is not a sign of failure, it is the work. The organizations that resist it, customize their way around it, or hand it off to IT and hope for the best tend to find themselves wondering why the system ultimately did not deliver what was promised.

The ones that lean into it come out with something more valuable than a new ERP. They come out with a clearer picture of who they actually are as an organization and a stronger foundation to build on.