ERP Transformation Leadership — Volume 1 Edition 01

Organisations often describe ERP programmes in technology terms.

“We’re implementing Business Central.”

“We’re moving from NAV to the cloud.”

“We’re replacing our legacy ERP.”

“We need a new finance system.”

Those descriptions are understandable, but they can unintentionally narrow the programme too early.

An ERP implementation is ultimately a technology programme.

An ERP transformation is broader.

It asks how people, processes, data, technology and governance should work together in the future—and then determines how the ERP platform should enable that operating model.

That distinction is one of the reasons Automate Business Solutions uses a simple principle:

Discovery before configuration

Before implementation activity accelerates, organisations need sufficient clarity about the business they are trying to create.

1. Start with the transformation trigger

Every ERP programme begins because something has changed.

Typical triggers include:

an ageing Dynamics NAV or legacy ERP estate;
business growth;
acquisition or international expansion;
fragmented systems;
inconsistent processes between sites;
weak reporting;
manual spreadsheet dependency;
poor inventory visibility;
manufacturing or planning problems;
financial control weaknesses;
unsupported customisations;
cloud strategy;
inability to scale existing operations.

Identifying the trigger is useful.

But the trigger is not necessarily the transformation objective.

For example:

Trigger: NAV is approaching the end of its strategic life.

Transformation objective: Create a standardised, controlled and scalable operating platform across multiple business units.

Those are different statements.

The second provides a much stronger basis for design decisions.

2. Understand the real current state

Process documentation rarely tells the complete story.

A documented process may say:

Sales Order → Warehouse → Shipment → Invoice

The actual process might involve:

Sales creating an order.

A planner exporting demand into Excel.

Operations checking availability manually.

Warehouse receiving an emailed instruction.

Someone adjusting inventory because the system quantity is unreliable.

Finance performing a manual reconciliation at month-end.

All of these activities are part of the real process.

ERP discovery therefore needs to examine:

People

Who performs the process?

Who owns it?

Who approves exceptions?

Who has specialist knowledge that isn’t documented?

Process

What actually happens from beginning to end?

Where are delays, duplication and unnecessary hand-offs?

Data

Which information is required?

Where does it originate?

Who owns its quality?

Technology

Which ERP functions, spreadsheets, interfaces and peripheral systems support the process?

Governance

What controls, approvals, policies and decision rights apply?

Together, these provide a much more accurate picture of the current operating model.

3. Find the work happening outside the ERP

One of the strongest indicators of transformation opportunity is work that has escaped the core system.

Look for:

spreadsheets;
shared folders;
email approvals;
manual reconciliations;
duplicate data entry;
local databases;
shadow systems;
offline planning tools;
manually maintained reports;
repeated support workarounds.

These aren’t automatically bad.

Sometimes an external tool exists for a valid reason.

But every workaround deserves a question:

What problem is this solving that the ERP is not?

The answer may indicate:

poor configuration;
missing functionality;
poor usability;
inadequate training;
weak data;
an integration gap;
an inappropriate process;
or a genuinely specialised requirement.

That evidence is extremely valuable before target-state design begins.

4. Separate the requirement from the legacy solution

This is especially important during NAV-to-Business Central transformation.

Legacy ERP systems often accumulate years of modifications.

Some are essential.

Some were created because standard functionality did not exist at the time.

Some compensate for old organisational processes.

Some remain simply because nobody wants to remove them.

If requirements gathering begins with:

“Tell us everything you currently have in NAV,”

the project risks rebuilding the legacy estate.

A better approach is to ask:

“What business outcome does this functionality support?”

Consider this example.

Legacy statement

“We need the new ERP to reproduce our custom dispatch report.”

Business requirement

“The warehouse needs one controlled view of everything required to prepare today’s shipments.”

Once the requirement is expressed that way, several solution options become possible.

The historical custom report is only one of them.

This is why good requirements analysis is fundamental to fit-to-standard.

5. Apply a deliberate fit-to-standard hierarchy

At ABS, we favour a decision sequence that challenges unnecessary customisation.

Option 1 — Standard configuration

Can the requirement be satisfied using standard ERP capability correctly configured?

If yes, this is generally the strongest starting point.

Option 2 — Process change

If standard capability works differently, can the business process reasonably adapt?

This should be considered carefully rather than assumed.

Processes driven by genuine regulatory, customer or competitive requirements may need preserving.

Historical preference alone is a weaker reason.

Option 3 — Supported ISV or extension

Where the requirement is specialised, an established application may offer a supportable solution without creating unnecessary bespoke development.

Option 4 — Custom development

If the requirement remains material and no appropriate standard or supported solution exists, custom development may be justified.

But the decision should include:

business value;
implementation effort;
testing;
upgrade impact;
maintenance;
supportability;
documentation;
technical debt.

The question is not:

“How do we avoid all customisation?”

The question is:

“Which customisations genuinely deserve to exist?”

6. Bring data into discovery—not just migration

Data is frequently treated as an implementation workstream.

It should also be a discovery workstream.

Poor data can distort almost every process in an ERP environment.

Examples include:

duplicate customers or vendors;
obsolete items;
inconsistent units of measure;
incorrect lead times;
poor costing information;
unused dimensions;
inconsistent product structures;
incomplete routings;
unreliable inventory;
duplicate chart-of-account structures;
uncontrolled local master data.

Migrating poor-quality data accurately still produces poor-quality data.

Discovery should therefore establish:

What data matters?

Who owns it?

How reliable is it?

What should be cleansed?

What should be archived?

What genuinely needs migrating?

How will migrated balances and stock be reconciled?

This becomes particularly important in multi-entity and international programmes.

7. Follow processes end-to-end

ERP transformations often fail at the interfaces between departments.

Each individual module may appear correctly configured while the end-to-end business process remains broken.

Manufacturing is a good example.

Production does not exist independently.

It connects:

Demand → Planning → Procurement → Inventory → Production → Warehouse → Costing → Finance

A design decision in one area may affect several others.

The same applies to:

Order-to-Cash

and:

Procure-to-Pay

and:

Record-to-Report

This is why discovery and later UAT need to examine complete business scenarios rather than isolated system transactions.

8. Define the future operating principles

Discovery should not only document the present.

It should establish principles for the future.

Examples might include:

standardise processes across entities unless a justified local requirement exists;
use standard Business Central functionality before approving extensions;
establish clear global and local master-data ownership;
reduce spreadsheet dependency;
automate controls where appropriate;
maintain one source of truth for core operational data;
require evidence for material design decisions;
design reporting requirements alongside the transactional process;
ensure each critical end-to-end process has an accountable owner.

These principles become valuable later when difficult design questions emerge.

Without them, each decision can become a negotiation from scratch.

9. Convert discovery into a roadmap

Discovery should produce decisions and direction.

A practical sequence might be:

Mobilise

Define scope, decision authority, stakeholders and evidence.

Discover

Understand strategy, drivers, pain points and operating context.

Map

Document critical end-to-end current-state processes.

Diagnose

Identify weaknesses, risks, controls, duplication and value leakage.

Fit-Gap

Compare the required operating model with standard ERP capability.

Define Target State

Establish future processes, ownership, data and design principles.

Prioritise

Separate critical transformation requirements from lower-value preferences.

Roadmap

Turn the findings into workstreams, dependencies, phases, governance and investment decisions.

The result should allow leadership to answer:

What are we changing?

Why are we changing it?

What should be standard?

Where are the genuine gaps?

What risks need managing?

What should happen first?

10. Why this saves time rather than wasting it

There is sometimes pressure to reduce discovery because implementation teams want to demonstrate progress quickly.

Configuration feels tangible.

Workshops about business outcomes may feel less so.

But unresolved discovery decisions do not disappear.

They move downstream.

They reappear during:

solution design;
development;
data migration;
integration;
SIT;
UAT;
training;
cutover;
or post-go-live support.

And decisions become progressively more expensive to reverse.

Changing a proposed process during discovery might require a conversation.

Changing it after development and UAT may require redesign, configuration changes, code changes, new test scripts, regression testing and retraining.

This is why we use the principle:

Discovery is cheaper than rework.

11. Business Central is an enabler—not the transformation itself

Dynamics 365 Business Central can provide a strong cloud ERP foundation across finance, manufacturing, supply chain, warehousing, purchasing, sales and other operational areas.

But the platform cannot decide:

which processes should remain different;
which should be standardised;
who owns master data;
which legacy behaviours should disappear;
which controls leadership requires;
how users should work;
which customisations are commercially justified;
how implementation success should be measured.

Those are transformation decisions.

The technology should enable them.

That is the difference between approaching ERP as a software implementation and approaching it as a business transformation.

The ABS perspective

Automate Business Solutions approaches ERP transformation through a broader lifecycle:

Diagnose → Decide → Deliver → Assure → Optimise

Business Central is a core technology within our work, particularly for organisations operating across manufacturing, distribution, finance and complex operational environments.

But the outcome we are ultimately interested in is wider:

better processes, stronger control, trusted data, effective technology, clear ownership and measurable business value.

Business Central is the platform. Business transformation is the outcome.

Planning an ERP or NAV-to-Business Central programme?

If your organisation knows change is needed but the scope, priorities or transformation path are not yet clear, an independent discovery and roadmapping exercise can help create a stronger basis for the programme before major implementation commitments are made.

Automate Business Solutions — ERP Transformation Leadership

People + Process + Data + Technology + Governance

Why ERP Transformation Must Start Before ERP Configuration