September 21, 2026 • 5 Min Read

But that is not usually where the time goes.

ERP programs lose time when something important turns up later than it should. A process everyone assumed was standardized turns out to work five different ways across the business. A data dependency surfaces after design has started. A customization that seemed minor affects three other workstreams. Or a decision sits unresolved long enough that teams begin building around different assumptions.

That is when a project that looked fast starts slowing down.

The better question is not simply, “How do we move faster?” It is, “What can we resolve earlier so we do not have to do the work twice?”

That shifts the focus to a few things that have an outsized effect on speed: getting the enterprise aligned around the same outcomes, understanding how the business actually works before design gets too far along, and making the decisions that could otherwise hold up multiple parts of the program.

None of those sounds as dramatic as cutting six months from an implementation schedule. But in practice, they are often what makes that kind of acceleration possible.

Get the Enterprise Moving in the Same Direction

ERP touches almost everything: finance, technology, data, controls, operations and the business itself. If those groups are working toward slightly different versions of the transformation, the differences eventually show up in the project.

One team assumes a process will be global. Another is designing for regional variation. Finance expects one definition of the data while the business is working from another. A customization is approved in one workstream without anyone fully understanding what it changes somewhere else.

Each decision may make sense on its own. Together, they create rework.

Research from MIT CISR has shown the importance of clear decision rights and giving cross-functional teams the authority to act within defined guardrails. That idea is especially relevant in ERP, where dozens of decisions made in one part of the program can affect another.

The practical work starts early. Which processes really need to be global? Where is local variation justified? Who owns master data? Which customizations are worth preserving? What reporting requirements truly cannot change?

These questions are easy to postpone because they are difficult. But postponing them does not make the complexity disappear. It usually means somebody encounters it later, after more work has already been done.

See How the Business Really Works

Most ERP programs begin with interviews, workshops and process maps designed to establish the current state.

Those are necessary. They are also imperfect.

There is often a meaningful difference between the process people describe and the process that actually happens every day. Over time, organizations accumulate workarounds, local practices, configuration changes and exceptions that may never make their way into formal documentation.

This is one area where AI can be genuinely useful.

Organizations can increasingly analyze transactions, workflows, system configurations and process variations to see where actual behavior differs from the documented process. That can bring things to the surface much earlier: unusual transaction patterns, unexpected customizations, inconsistent data, integration dependencies or regional differences that nobody realized were significant.

A finance organization may believe it has one common process, for example, only to discover that five regions are handling the same activity differently.

That is valuable information to have before design, not during testing.

AI does not have to decide which version is right. The bigger opportunity is using it to see the reality of the business sooner.

In a large transformation, finding the problem earlier can be far more valuable than solving it faster once it has already become a project issue.

Make the Hard Calls Earlier

Of course, seeing a problem does not resolve it.

Someone still has to decide what to do.

Some ERP decisions have consequences far beyond the workstream where they first appear. A change to the chart of accounts can affect consolidation, planning, reporting, controls, integrations and analytics. A decision about a customization can change downstream processes. Data ownership can become a design issue, a controls issue and a reporting issue at the same time.

These are the decisions worth pulling forward.

Gartner has pointed to unclear escalation protocols, ineffective stakeholder engagement and ambiguous accountability as common obstacles in finance transformation. That is why governance matters—but not governance for its own sake.

Good governance should make it easier to get an answer.

When a consequential decision comes up, everyone should know who owns it, who needs to be involved and when the decision has to be made. And once it is made, teams should be able to see what was decided and why.

A simple decision log can do more for project speed than another layer of meetings if it keeps the same issue from being debated three times.

Look at How Much You Are Doing Twice

Transformation teams are very good at measuring milestones: design complete, testing started, cutover scheduled.

There is another measure that may tell leaders just as much about whether the project is actually moving quickly:

How much work are we doing twice?

A requirement discovered after design creates rework. A decision reopened during testing creates rework. A process problem uncovered after go-live creates even more of it.

A program can hit its milestones and still be accumulating these problems underneath.

That is why reopened decisions, late requirements, exceptions and rework are worth watching alongside the traditional project plan. They show whether the organization is truly accelerating or simply moving problems further down the road.

The fastest ERP transformations are not necessarily the ones where every team works faster. They are the ones that eliminate more of the work that never needed to be repeated in the first place.

That takes alignment across the enterprise. It takes better visibility into what is really happening in the business. It takes governance that gets difficult decisions made before they become implementation problems. And it takes experienced people who can recognize which differences matter, which ones do not and where a seemingly small decision may have consequences elsewhere.

For finance leaders, a few questions can reveal a lot:

What are we likely to discover too late?

Which unresolved decisions could hold up more than one part of the program?

And where are we doing work over because we did not answer those questions soon enough?

The answers may tell you more about the true speed of the transformation than the project schedule does.