Nearly every problem in an ERP project is a data problem or a people problem wearing a technical disguise.

ERP implementation: how to do it without losing a year

A realistic account of what implementation involves, where projects go wrong, and how to sequence the work so the business keeps running.

ERP implementations have a poor reputation, and it is partly deserved. The failures are rarely caused by the software being incapable. They are caused by data that was worse than anybody admitted, processes that were never actually agreed, and a business that did not have the people available to do its half of the work.

This guide describes the sequence we use and the parts that consistently take longer than planned. It is written to be useful whether or not you end up choosing CubeERP.

In this guide

  1. The five stages, and what each is really for
  2. Data migration is the project
  3. Where projects actually go wrong
  4. Phase it, but phase it sensibly
  5. Training that survives contact with go-live
  6. Go-live, and the fortnight after
  7. The three months afterwards

The five stages, and what each is really for

  • Discovery. Understanding how the business actually works, which is frequently different from how it is described. The output is a configuration plan and a list of decisions the business needs to make.
  • Configuration. Setting the system up around those decisions - structures, rules, documents, permissions. Mostly supplier-led, but every unresolved decision becomes a delay here.
  • Data migration. Extracting, cleaning and loading customers, suppliers, items, bills of materials, pricing and open transactions. Almost always the longest stage, and mostly your work.
  • Training and rollout. Training by role rather than by module, with a period of parallel running or a staged cutover.
  • Support and improvement. The first three months after go-live, when the real requirements finally surface because people are using it for actual work.

Data migration is the project

If you take one thing from this guide, make it this: the data is the project. Every implementation we have seen run late ran late because of data, and it was visible early to anybody willing to look.

The typical state of an established business’s data is duplicate customer records, part numbers with inconsistent conventions, bills of materials that are partly right, supplier prices last reviewed years ago, and stock figures that have not been verified. None of that is unusual and none of it is a criticism. It is simply work that has to happen, and it cannot be outsourced entirely because only your people know which of two similar part numbers is the real one.

Start data cleansing the week you sign, not the week configuration finishes. It is the only part of the project that can be brought forward.

Where projects actually go wrong

  • No internal owner with real authority, so decisions queue and the supplier waits.
  • Data cleansing started too late and underestimated by a wide margin.
  • Scope expanding quietly - "while we are at it" - until the original objective is a subplot.
  • Training delivered as a module tour weeks before go-live, so nobody remembers it when it matters.
  • Configuring around habits rather than requirements, which rebuilds the old system’s limitations inside the new one.
  • Going live on the busiest month of the year because the date was set before anybody checked.
  • Treating the shop floor as an afterthought, then being surprised when the shop floor does not adopt it.

Phase it, but phase it sensibly

Big-bang go-live is occasionally right and usually risky. Phasing reduces risk, but only if the phases are chosen around data dependencies rather than around organisational convenience.

A sequence that works for most manufacturers and distributors is: stock and purchasing first, because everything downstream depends on inventory being right; then sales orders and despatch; then production; then costing and reporting once there is enough accumulated data for the numbers to mean something.

Phasing by department - "sales first, then operations" - sounds tidy and tends to fail, because it splits processes that share data down the middle.

Training that survives contact with go-live

Train by role, not by module. A warehouse operative needs to be excellent at four transactions and does not need to know what a routing is. Training them on everything guarantees they retain nothing.

Train close to go-live rather than early - knowledge decays quickly when it is not used - and plan a second round six to eight weeks afterwards, when people have real questions rather than theoretical ones. That second round is the single highest-value day in most implementations, and it is the one most often cut.

Go-live, and the fortnight after

  1. 1Freeze scope well before the date. Anything new goes on a post-go-live list, without exception.
  2. 2Pick a quiet period. Not year end, not your peak season, not the week two key people are away.
  3. 3Count stock properly immediately before cutover. Going live on stock figures you do not believe undermines confidence in the system permanently.
  4. 4Have supplier support physically or immediately available for the first few days, not on a ticket queue.
  5. 5Expect a productivity dip for one to three weeks and plan capacity around it rather than pretending it will not happen.
  6. 6Hold a short daily review for the first fortnight to catch problems while they are still small.

The three months afterwards

The real requirements emerge after go-live, once people are using the system for real work rather than imagining how they might. Reports get requested that nobody thought of during discovery, and processes get refined because the data now shows something that was previously invisible.

Budget time and money for this period. Projects that treat go-live as the finish line end up with a system that works exactly as specified and not quite as needed.

In short

What to take away

  • Data is the project - start cleansing the week you sign.

  • You need one internal owner with authority and protected time.

  • Phase around data dependencies, not around departments.

  • Train by role, close to go-live, and again six weeks after.

  • Count stock before cutover, and pick a quiet month.

  • Budget for the three months after go-live; that is when real requirements appear.

Questions

Asked while people are working this out

  • For a mid-sized manufacturer, typically three to nine months depending on complexity and how clean the data is. Anybody quoting six weeks without seeing your data is guessing, and the guess will be wrong in one direction only.

  • Expect one person effectively full-time for the duration, plus meaningful input from finance, operations and the shop floor. If that is not available, delay rather than start understaffed.

  • For finance, often yes for a period. For operations, rarely - running two operational systems doubles the work at the worst possible moment and usually means neither is maintained properly.

  • Migrate open transactions and enough history to be useful - typically two to three years of sales for reporting continuity. Archive the rest as read-only. Migrating everything is expensive and rarely used.

  • Raise it immediately rather than working around it quietly. Configuration change during the project is far cheaper than a workaround that becomes permanent, and a good supplier would rather hear it early.

Relevant to this

Where CubeERP fits

Linked because they are relevant to the guide, not because this is where the sales pitch goes.

Next

Read these too

After reading

Bring the questions this raised

If the guide has made you think of something specific about your own business, that is exactly the conversation worth having. No obligation and no scripted demonstration.

Start a conversationCall 01234 672 617