Ask anyone who has helped rescue a struggling ERP rollout and you will hear the same story. The details differ, but the shape does not. Six months after go-live, finance is still running its old spreadsheets alongside the new system, the warehouse has found a way to work around it, sales does not trust the stock figures, and the managing director wants to know why the business paid for software that IT "still hasn't finished setting up".

That last phrase is the diagnosis. An ERP is not an IT system the business uses. It is the business's own operating model, written down in software. When the business hands the whole thing to IT, IT is forced to make business decisions it has no authority to make, and the system faithfully encodes those guesses.

How the hand-off happens

Nobody sets out to make IT own the ERP. It happens by default. The software is technical, the vendor speaks in modules and configurations, and IT is the department that understands those words. So IT is asked to "run the project". Department heads attend the kick-off, nod at the timeline, and go back to their day jobs, which have not been reduced by a single hour.

Then the questions start, and every one of them is a business question in technical clothing:

  • Should a sales order be able to go out if the customer is over their credit limit, and who can override that?
  • When stock is received short, do we pay the invoice in full, in part, or hold it?
  • Do we cost stock at average or at last purchase price?
  • Which of the four customer price lists is the real one?
  • Who approves a write-off, and up to what value?

IT sends the question to the department head, who is busy, and the answer comes back late or vague or not at all. The project has a go-live date, so the consultant configures something reasonable. Multiply that by several hundred decisions and you have a system that is technically sound and operationally wrong.

Every setting in an ERP is a business decision. If the business does not make it, someone else will, and the business will live with it every day.

What it looks like after go-live

The failure is not usually dramatic. The server does not crash. Instead, the system quietly loses the business's trust:

  • Shadow spreadsheets come back. Finance keeps the old debtors workbook "just to check". Within a month it is the real one again, and the ERP is a second set of records that must be kept in step.
  • Workarounds harden. The warehouse cannot receive a partial delivery the way it actually happens, so it receives the full order and adjusts later. Stock is wrong from that day on.
  • Old data poisons the new system. Duplicate customers, dead stock codes and unreconciled balances were migrated as they were, because nobody in the business was given time to clean them. See data migration for why that never works.
  • Staff do not know the "why". They were shown which buttons to press a week before go-live, but not why the process changed. Under pressure, they revert to what they know.
  • IT becomes the complaints desk. Every operational frustration is logged as a system fault, and IT is blamed for decisions it never had the authority to make.

Who should own what

The fix is not "less IT". IT's role is essential. It is a clear division of ownership, agreed at the start and visible on the project plan.

The executive sponsor owns the outcome

Usually the MD or a director. Not a figurehead: the person who breaks ties between departments, protects people's time, and tells the business that the old way is ending. A steering committee with real decision-making authority meets regularly and resolves what the project team cannot.

Department heads own their processes and data

The head of finance owns the chart of accounts, approval limits and month-end. Operations owns stock, receiving and dispatch. Sales owns customers, pricing and credit. Each one signs off the design for their area and the cleansed data that is migrated into it. Their signature means "this is how we will work", not "IT showed me a screen".

Key users design and test

One or two people from each area who actually do the work: the debtors clerk, the receiving supervisor, the person who builds the price lists. They sit in the design workshops, test with real scenarios, and later train their colleagues. They need protected time, which means someone else covers part of their normal job.

IT and the implementer own the platform

Infrastructure, security, integrations, user access, performance, backups and the technical side of migration. They advise the business on what the software does well and where customisation will be expensive. They do not decide the credit policy.

The workload test

Ask each department head a simple question: "What have you stopped doing so that your team can work on this project?" If the answer is "nothing", the project is being run by IT and the vendor, however the organisation chart describes it. Plan to backfill key users or move non-urgent work for the duration. It is the cheapest insurance an ERP project can buy.

What we would do differently every time

  1. Agree processes before configuration. Run workshops with the people who do the work, map how things happen today and how they should happen, and decide. The software is configured to the agreed process, not the other way round.
  2. Write the decisions down. A decision log with the question, the answer, who made it and when. It ends the "nobody told us" conversation after go-live.
  3. Make the business clean its data. IT can extract and load. Only the business can decide which of three customer records is the real one.
  4. Test with real scenarios, run by real users. A full order-to-cash and purchase-to-pay cycle, with the awkward cases: the short delivery, the credit note, the customer on hold. A clear brief makes these easy to list.
  5. Train on the process, not the screens. Explain why the process changed. People follow a process they understand far more reliably than one they were merely shown.
  6. Switch the old system off. Set a date after which the spreadsheets are archived and read-only. Parallel running that never ends is how the old way wins.
  7. Plan for the months after go-live. The first month-end, the first stocktake and the first audit are part of the project. Keep the team together until they have passed.

Our ERP rollout at a food producer shows this in practice: the timeline, the training and the investment, with the business owning each stage. As we argue in Adoption Is the Project, the go-live date is not the finish line; the day people stop reaching for the old spreadsheet is.

The question to ask before you sign

Before you sign an ERP contract, ask who in the business will make the decisions, and how much of their time the project will take. If the honest answer is "IT will sort it out", stop and fix that first. The software will do what it is told. Make sure the people telling it are the ones who run the business.