ERP Modernization Needs Executive Alignment First

Before an ERP program deserves a project plan, it needs a leadership decision record.

That sounds less exciting than selecting a cloud suite, announcing a transformation, or showing a generative AI assistant that can explain a purchase order. But large business systems do not fail only because the software is weak. They fail when the organization has not decided how much standardization it can tolerate, who has authority to change processes, which exceptions are worth preserving, and how much disruption the business is willing to absorb.

ERP modernization is one of the clearest examples of technology work that is not mainly technology work. Finance, procurement, inventory, supply chain, manufacturing, projects, HR, and reporting all carry years of local habits. Some of those habits are necessary. Some are outdated workarounds. Some exist because the old system forced them. Some exist because a powerful group protected them.

A new ERP system makes those choices visible.

The modern version is even more complicated because leaders are not only replacing old software. They are also being sold cloud ERP, embedded analytics, low-code extensions, workflow automation, and AI agents that promise to make business operations more intelligent. Oracle describes its cloud ERP around AI, analytics, automatic updates, and finance automation. Microsoft says Dynamics 365 implementations are business transformation projects, not just technical projects, and that governance should connect business goals, roles, risk, testing, and deployment. That is the right framing.

The system matters. The implementation partner matters. The architecture matters. But the first risk is leadership ambiguity.

If executives have not agreed on the operating model, the ERP program becomes a negotiation machine. Every department asks for its old process to be preserved. Every exception becomes urgent. Every customization sounds reasonable in isolation. The project team is left to make business decisions through configuration meetings, and technology becomes the place where unresolved leadership conflict gets stored.

That is not a software problem. It is an alignment problem.

ERP is where business preferences become system rules

ERP projects are uncomfortable because they turn vague preferences into hard rules.

A sales team may prefer a special approval path. Procurement may have local supplier practices. Finance may want consistent controls. Operations may depend on a warehouse exception that nobody documented properly. A regional office may have a legitimate legal requirement. Another region may simply have a habit it does not want to lose.

In the old system, these differences may have survived through manual work, spreadsheets, local databases, email approvals, and quiet heroics from experienced employees. In a modern ERP program, the differences have to be classified. Should this become a standard process? Should it become a configuration? Should it become an approved extension? Should it disappear? Should it remain outside ERP because the process is too unique or too immature?

This is why a serious ERP decision is not only “which vendor should we choose?” It is “which kind of company are we willing to become operationally?”

The difficult part is that standardization often creates local pain before it creates enterprise value. A standard chart of accounts helps reporting, but it may force teams to change familiar accounting habits. A standard procurement workflow improves controls, but it may slow down a group that used to operate informally. A standard inventory process improves visibility, but it may expose weak master data that people had worked around for years.

Leadership has to own that tradeoff. If the CIO or implementation team is the only group defending standardization, the program will be treated as an IT imposition. The business will comply publicly and resist privately.

That is how ERP programs become expensive collections of exceptions.

AI makes the core more important, not less

The current market adds a new pressure: leaders want AI-enabled operations.

That is understandable. Modern ERP vendors are embedding AI into finance, procurement, project management, risk monitoring, analytics, and workflow support. Oracle’s ERP materials describe AI used to automate manual processes, support analytics, and strengthen risk management. Microsoft talks about cloud business applications that integrate with low-code and no-code technology, receive regular updates, and require governance suited to cloud delivery.

The direction is clear. ERP is no longer only a system of record. It is becoming a platform where data, workflow, automation, and AI meet.

But AI does not make a weak operating core disappear. It often amplifies the weakness.

If supplier data is inconsistent, an AI assistant will explain inconsistent data faster. If approval rules are political, an agent will inherit the politics unless the rules are clarified. If product definitions differ across regions, analytics will produce polished disagreement. If permissions are messy, AI features create a larger access-control problem. If business processes rely on undocumented exceptions, automation will either break them or silently encode them.

This is why ERP modernization and AI readiness are connected. A company that wants useful AI over finance, procurement, inventory, or operations needs dependable business objects, clear process ownership, trusted data, readable audit trails, and explicit authority boundaries. Otherwise, the AI layer becomes a more fluent interface over confusion.

I would rather see a company delay one ambitious AI feature and fix the process ownership beneath it than launch a beautiful assistant nobody can trust.

This connects to a broader DataTweets theme: AI strategy has to become operating discipline. In AI Strategy Works When Teams Share Direction, I wrote about turning AI ambition into signals teams can use in daily decisions. ERP modernization needs the same discipline because the decision surface is wider and the cost of ambiguity is higher.

The alignment ledger should come before the configuration backlog

One practical artifact I would use before a major ERP commitment is an alignment ledger.

It is not a project plan. It is not a requirements document. It is a leadership record of the process decisions that must not be pushed down into configuration workshops.

The ledger should be short enough to maintain and specific enough to prevent confusion.

This table is deliberately not technical at first. The technical design should follow the answers. If a team cannot answer who owns supplier master data, no integration pattern will rescue supplier analytics. If leaders cannot say who may approve a process exception, the project will accumulate custom work under pressure. If nobody can name the business outcome, the program will measure activity instead of value.

The ledger also protects the implementation team. It gives consultants, product owners, architects, data leads, and change managers a way to say, “This is not a configuration preference; it changes a leadership decision.”

That distinction matters. ERP projects fail slowly when every business conflict is translated into a ticket.

Standard does not mean careless

There is a lazy version of ERP advice that says every organization should simply adopt the standard process and stop arguing.

That is too simple.

Some exceptions are real. A pharmaceutical manufacturer, a hospital, a government contractor, a bank, a multinational distributor, and a professional services firm do not all have the same operating constraints. Local tax rules, regulatory controls, supply-chain requirements, data residency, union rules, customer contracts, and safety requirements can justify process variation.

The danger is not exceptions. The danger is unmanaged exceptions.

A mature ERP program separates four categories:

• Standard process: The default way the company will work because consistency matters more than local preference.
• Configured variation: A controlled difference supported by the ERP product without damaging the upgrade path.
• Approved extension: A deliberate addition built outside or beside the core because the business value justifies ownership.
• Retired workaround: An old habit that should not survive the modernization.

This classification is more useful than arguing in general about customization. It lets leaders preserve important business differences without letting every team recreate the old system inside the new one.

It also fits the cloud ERP era. Cloud suites are updated continuously. Heavy customization that once felt like control can become a tax on upgrades, testing, security review, and vendor support. In AI-enabled ERP, the tax can be larger because custom logic may affect data meaning, automation behavior, model context, and auditability.

The question is not whether customization is morally bad. The question is whether the organization is willing to own the consequences.

Change management is not a launch-week communication plan

Microsoft’s Dynamics 365 change-management guidance makes a useful point: change management should be proportional to risk and complexity, not treated as a theoretical exercise or a slide deck at the end. That is especially important for ERP because users are not adopting a side tool. They are changing how everyday work is recorded, approved, measured, and controlled.

The change effort should start when process decisions start.

People resist ERP changes for different reasons. Some resist because the new process is genuinely worse for their work. Some resist because the old process gave them autonomy or status. Some resist because they do not trust leadership to stay committed after go-live. Some resist because the data cleanup exposes errors they did not create but now have to fix. Some resist because training is too generic for the job they actually do.

Treating all resistance as “people do not like change” is careless. Treating all resistance as valid veto power is also careless.

Good change management listens for the type of resistance and routes it properly:

• If the new process is weaker, revisit the design.
• If the process is better but locally painful, explain the enterprise tradeoff and support the transition.
• If the issue is data quality, assign ownership and time for cleanup.
• If the issue is authority loss, leadership has to decide whether the old authority should remain.
• If the issue is skill, training must become role-specific and workflow-specific.

This is where executives matter. A project team can train users. It cannot make the organization accept a new operating model if leaders keep making exceptions for their own departments.

The implementation partner should bring pattern memory, not borrowed authority

Experienced implementation partners can be valuable because they have seen the traps before. They know where data migration gets underestimated. They know which customizations become expensive. They know where testing needs business participation. They know why a process that looks small in design can become painful after launch.

That pattern memory is useful.

But a partner cannot substitute for executive alignment. Consultants can recommend standard processes, show industry patterns, challenge bad requirements, and warn about risks. They cannot decide how the company should balance global consistency against local autonomy. They cannot enforce adoption after the contract ends. They cannot own the credibility cost if the program promises transformation and delivers only a new interface.

The best use of a partner is to make tradeoffs visible early.

Ask them where clients in the same industry usually over-customize. Ask which data objects cause go-live pain. Ask which reports become political. Ask which integrations should be delayed until after core stabilization. Ask which process variations are common and which are warning signs. Ask what the first 90 days after go-live usually reveal.

Then make the business own the answers.

This is also important for AI-enabled ERP. A vendor or partner may show impressive automation, but the organization has to decide the authority model. Can an agent create a purchase requisition? Can it recommend a supplier? Can it approve an invoice match? Can it draft a financial explanation for executives? Which of those actions need human review, and which need audit logs? The answers belong to the business, security, finance, risk, and technology together.

A smaller first phase may be more ambitious

Large ERP programs often suffer from a strange form of ambition. Leaders try to include too much in the first release because the program is expensive and politically difficult. They want the big bang to justify the disruption.

Sometimes that is necessary. Often it is a trap.

A narrower phase can be more ambitious if it creates a stronger operating foundation. For example, a first phase that standardizes core financial processes, cleans master data, establishes approval rules, creates reliable reporting, and defines extension governance may produce more long-term value than a broader release that preserves too many old habits.

This is especially true when AI is part of the roadmap. The organization may want predictive insights, natural-language analytics, invoice automation, procurement agents, or finance copilots. Those capabilities depend on trust in the core. If the first phase creates dependable data and process discipline, later AI work has a better base. If the first phase only moves old confusion into a new platform, AI will inherit that confusion.

The useful question is not, “How much can we include?” It is, “What foundation must be true before expansion becomes safe?”

That question changes scope discussions. It also makes progress easier to explain. The first release is not a small version of the dream. It is the operating base that makes the dream less reckless.

What leaders should decide before saying yes

Before approving an ERP modernization program, I would want leadership to answer a few questions in writing.

Which business outcomes justify the disruption? Cost reduction may be one answer, but it should not be the only one. Better reporting, stronger controls, faster close, cleaner procurement, improved inventory visibility, easier acquisitions, better compliance, and AI readiness may all matter. Name the outcomes.

Which processes will become standard? Avoid vague statements about harmonization. Name the process families where the company will accept a common model.

Which local differences are legally, operationally, or strategically necessary? Force exceptions to make a business case. Protect the ones that matter. Retire the ones that do not.

Who owns critical data? Customer, vendor, product, employee, account, project, asset, and inventory data need business owners, not only technical stewards.

What is the boundary for customization and extension? Define what belongs in the core, what belongs in platform extensions, what belongs in surrounding applications, and what should not be built.

Where will automation stop? For AI and workflow automation, decide which actions require human approval, which outputs need citations or evidence, and which logs must exist.

Who will enforce adoption? If senior leaders continue to reward old behaviors after go-live, the system will lose authority.

How will benefits be measured after launch? Go-live is not the outcome. It is the moment the new operating model starts being tested.

These questions are not meant to slow the program indefinitely. They are meant to prevent slow failure disguised as progress.

The real risk is moving before the organization has chosen

ERP modernization requires courage, but not the theatrical kind. The courage is not in announcing a large program. The courage is in making specific choices before the project machinery starts moving.

It takes courage to tell a department that its preferred process will not survive. It takes courage to preserve a local exception when standardization would be simpler but wrong. It takes courage to delay an AI feature until data ownership is clear. It takes courage to make executives responsible for adoption instead of letting them sponsor the program from a distance.

Modern ERP systems can be powerful. Cloud delivery can reduce some operational burden. Embedded AI can make workflows faster and more adaptive. Analytics can make performance visible. Automatic updates can keep capabilities current. But none of that replaces the old leadership work: decide how the business should run, make the tradeoffs explicit, and stand behind the new way of working.

An ERP program should not begin with lonely technical bravery. It should begin with shared executive ownership.

The practical takeaway is simple: do not ask the project team to discover the operating model by surviving the implementation. Define the core decisions early, write them down, revisit them when evidence changes, and make sure the people with authority are visibly committed.

ERP modernization is not just a software replacement. It is a test of whether the organization can turn strategy into process, process into data, data into trustworthy automation, and automation into work people can actually use.

That test is worth taking. But it should be taken together.