Implementation guide

How To Implement ERP Without Becoming A Statistic

Choosing the right model, defining what you actually need, phasing the rollout sensibly, and understanding why an ERP project is a business program with a software workstream inside it, not the other way around.

Plan Your Project With UsWhy Projects Fail
ERP implementation
Step one

One system, several specialists, or a mix?

This is the first architectural decision and it shapes everything after it. Most companies assume they want one system for everything, and most end up somewhere in the middle once they see where the gaps really are.

Single integrated ERP

One system for the whole company.

  • One database and one source of truth
  • Lower learning curve, one interface to train on
  • Less technical complexity and fewer integrations
  • Easier and cheaper to maintain long term
  • No single vendor is best at everything
  • You may have to bend a process to fit the software
Best for: Younger or less complex companies, and anyone whose processes are close to standard.

Best of breed

The strongest system for each function.

  • The closest functional fit for each department
  • Deep capability where your business is genuinely unique
  • Multiple sources of truth to reconcile
  • Higher learning curve across several systems
  • Significantly more integration and maintenance
Best for: Companies with a genuinely distinctive process that is a competitive advantage.

Hybrid

A core ERP plus specialists where it matters.

  • Standard functions on one integrated core
  • Specialist tools only where they earn their place
  • The option most large vendors effectively sell anyway
  • Requires a clear architecture and discipline
  • Integration points must be owned by someone
Best for: Most established mid-size and large companies. This is where the majority land.
Worth knowing: the major vendors have spent years acquiring specialist products and selling them as one suite. Many companies who believe they bought a single ERP system are in fact running a hybrid, with the integration work simply hidden inside the vendor's bill.

Each phase closes before the next one opens

1
2
3
4

Phase 4 only gets scoped once phase 3 has shipped and been reviewed.

A phased rollout

A Plan Broken Into Phases You Can Actually Finish

Every workstream produces a reviewable result before the next one starts, so the programme stays visible to the business instead of disappearing into a project plan nobody reads.

Step two

Define what you need, before anyone demos anything

Business requirements are how you take control of the selection process. Without them you are evaluating sales presentations. With them, you are measuring every option against your own business.

  • Run workshops per department: what works, what hurts, what is missing
  • Describe the future state, not just an automated version of today
  • Prioritize every requirement as critical, important or nice to have
  • Use them to run the demos instead of watching a sales pitch
  • Keep using them during implementation as a governance tool
  • Trace them at go live: which were met, and can we live with the rest?
Two traps to avoid
Analysis paralysis

No system will meet every requirement. You are picking the best option, not a perfect one, and prioritization is what lets you decide quickly.

Abandoning them after selection

Most teams write requirements to choose software, then never look at them again. If you stop here, your partner will design the system the way they find comfortable.

If you do not document what you need, the default configuration becomes your business process by accident.
Step three

Build The Business Case, Then Keep Using It

A business case has three jobs: justify the investment, govern the hundreds of decisions made during the project, and measure the value afterwards. Most companies use it only for the first and wonder later why costs drifted.

Software licences
Low

The most predictable line. Usually an annual subscription per user.

Implementation services
High

Configuration, development and setup. Almost always underestimated in vendor proposals.

Data migration & integration
High

Cleaning, mapping and moving your data, plus connecting the systems you keep. Frequently forgotten entirely.

Change management & training
High

The first line executives cut, and the one most correlated with failure.

Program management
Medium

Someone has to own the whole program, not just the software workstream.

Internal staff time
Medium

Your key people cannot do the project and their day job at full capacity. Plan for backfill.

Operational disruption risk
Critical

What it costs if you cannot ship, invoice or run payroll for a month. Often larger than the entire project budget.

Use it as a decision tool. When someone requests a customization, the question is not whether you can, but whether this cost buys measurable value in the business case. That single habit controls scope creep better than any change request form.
Step four

Phase The Rollout Deliberately

Going live with everything at once is faster and far riskier. Phasing reduces risk but adds interim integration work and takes longer. There is no free option, only a choice that should match your risk tolerance.

Business value first

Start with the process where the pain, and therefore the payback, is greatest.

How the modules fit

Some modules cannot sensibly be separated. Financials without inventory rarely works.

Organizational readiness

Begin where the team wants the change. Early momentum carries you through the harder departments.

Risk tolerance

Big bang is faster and riskier. Most established companies phase, and should.

Change fatigue

Too many phases and the organization loses faith before you finish. Phasing is not free.

Scope discipline

Deploying less, but properly, beats deploying everything and having half of it go unused.

Step five

Run A Program, Not A Software Project

This is the single biggest structural mistake we see. Your vendor proposal covers one of the five workstreams below. If you plan only for that one, everything else happens anyway, unplanned and unbudgeted.

Software project
Owner: Vendor / implementation partner

Design, configuration, technical testing and go live. This is the only workstream most vendor proposals actually cover.

Architecture, data & integration
Owner: Shared, usually under-scoped

How systems connect, where data lives, and the cleaning, mapping and migration of everything you have today.

Organizational change
Owner: You, with specialist support

Change readiness, impact analysis, communication, new roles and responsibilities, then training. Not just training.

Business process re-engineering
Owner: You

Current state, improvements, future state and the business case. Decided by you, not by whatever the software defaults to.

Program management office
Owner: You

The layer that ties the others together, holds the business case and keeps ownership of the project inside your company.

The workstreams most likely to delay your project are change management and business process re-engineering, not the technical build. Yet they are the ones with the least budget and the least senior ownership on most projects.

Data migration

Consistently the most underestimated task in the whole project. Years of accumulated records in old systems and spreadsheets have to be cleaned, mapped and moved.

  • Clean first: duplicates and dead records do not deserve a new home
  • Map old field names to new ones, which is rarely one to one
  • Decide what history to bring and what to archive
  • Import to a test database and have the business verify it

User acceptance testing

Nearly every famous ERP disaster would have been caught here. Testing is not the technical team confirming the software runs. It is your people confirming the business can run.

  • Test complete end-to-end processes, not isolated screens
  • Use real migrated data, not clean demo records
  • Let actual end users run it, not just the project team
  • Run several iterations and never trade them for the go live date

Frequently asked questions

Configure wherever possible. Configuration is settings, survives upgrades and costs little. Customization changes code, adds permanent cost and risk, and is sometimes genuinely necessary. Treat it as a deliberate decision with a business case, not a default answer.
It depends on scope and how standard your processes are, but the more useful answer is this: whatever timeline you were given, ask what happens if it slips. Projects fail because an unrealistic date forces teams to cut testing and training, not because they took an extra two months.
A short phase between selecting the software and starting to build it, where you fix the blueprint, the phasing, the resourcing and the change strategy. Teams skip it because momentum is high after selection. The time spent there is repaid many times over later.
Someone from the business with the authority to decide, not only from IT. An ERP project sets how the company will operate, so it needs an owner who can settle a disagreement between departments without escalating every time.
Most established companies should phase. Big bang suits younger, fast-moving organizations with a high risk appetite. Either way, never go live immediately before your busiest season, whatever the plan says.
ERP For Executives

The benefits, department integration, governance and the business case.

Why ERP Projects Fail

Five root causes and ten of the most expensive failures on record.

Our Implementation Method

How we apply all of this on a real Odoo project, in six stages.

Let's plan it properly before anyone starts building

A short planning phase is the cheapest part of the project and the one that decides how the rest of it goes.

Plan Your Project With UsSee All Modules

Related articles

Why ERP Projects Fail - and How to Avoid It

The most common reasons ERP projects fail, real-world cases, and practical tips to avoid them.

ERP for Executives: Business Value, Not Just Software

What executives need to know about ERP: business case, governance, costs and the value it unlocks.