What actually goes wrong in an ERP implementation

What actually makes an ERP project run late?

Your data. Not the software and not the vendor's speed. Duplicate customers, items entered three times under different names, and an opening stock count nobody believes will each add weeks. Most delayed projects are sitting still, waiting on a cleanup that nobody scheduled and nobody owns.

The pattern repeats. Configuration finishes roughly on time. Then migration starts, somebody opens the customer list, and there are four versions of the same company with different payment terms on each. Deciding which one is correct means asking sales, and sales is busy. That question sits in an inbox for nine days, and so does the project.

Dirty data is slow to fix because the work is judgement rather than typing. Deciding that AL-100, AL100 and ALUM100 are the same product needs someone who knows the products. That person already has a full job, so the cleanup happens in the gaps between real work, and the gaps are small.

Start before the project does. A customer list, a supplier list, an item list with agreed codes and units, your open invoices reconciled, and a physical stock count. All of that can be cleaned inside your current system while the vendor is still writing the plan, and none of it is wasted if the timeline moves.

Who inside your company is actually running this?

One named person with the authority to decide how a process should work, and real time in their week to do it. Without that, every configuration question goes to the vendor, the vendor guesses, and you find out about the guess three months later when a report is wrong.

This person is not your IT contact and usually should not be. Most implementation questions are business questions. Who is allowed to approve a purchase over a certain value. Whether a delivery can leave before the invoice is raised. What happens when a customer goes past their credit limit. A vendor cannot answer any of those for you, and if you make them, they will answer with whatever their other clients do.

The owner needs a genuine allocation of time. Saying somebody owns the project while leaving their existing workload untouched is the same as having nobody. During configuration, expect this to be a real part of their week, and more than that around migration and go live.

The other half of the job is deciding when a request is refused. Somebody has to be able to say no to a department head who wants one more field, and mean it. That authority has to come from the owner of the business, out loud, at the start.

• Meetings keep getting postponed

  The clearest early warning. A project that cannot hold a weekly slot has already lost priority.

• The vendor is chasing you for answers

  Look at who is waiting on whom. If it is mostly them waiting, the delay is on your side.

• Decisions get recorded as 'to be confirmed'

  Unresolved items pile up quietly and then all land at once, usually the week before go live.

• Nobody can name the owner in one word

  Ask three people who is running the project. Three different answers is a real problem.

Why does the scope keep growing once configuration starts?

Because people only discover what they want when they see the screen. Every review session produces new requests, each one small on its own, and the project quietly becomes larger than what you agreed. The fix is a written phase one and a visible parked list for everything else.

The requests are usually reasonable, which is what makes this hard. A sales manager asks for one extra field on the order. Finance wants an approval step. Someone in the warehouse needs a label printed a specific way. Any one of them costs a day. Twenty of them cost your go-live date and put you into your busy season.

Write down what phase one includes before configuration starts, at the level of processes rather than features. Sales orders through to invoice. Purchases through to payment. Stock in, out and between locations. Monthly close. Anything outside that list goes onto a parked list with a name and a date, and gets reviewed after go live.

The question that settles most arguments is simple. What breaks if we do this in three months instead of now? If the answer is nothing, it is a phase two item. If the answer is that a legal or customer commitment fails, it belongs in phase one and the timeline should move to reflect it.

• Custom reports are the quiet one

  Each looks like an afternoon. A pile of them becomes its own project, usually discovered in the last two weeks.

• Approval chains multiply

  Every department wants a step. Build the ones you actually enforce today, not the ones you wish you enforced.

• Integrations get promised casually

  A link to your online shop or your bank is a project in itself. Give it its own phase and its own testing.

• Old habits get rebuilt as requirements

  Some requests exist only because the old system was awkward. Ask why the step exists before recreating it.

When should you switch over, and how long do you run both systems?

Switch in your quietest month, at the start of a financial period. Run both systems in parallel for one full close and no longer. Past that, parallel running stops being a safety net and becomes two sets of books that disagree, with nobody certain which one is real.

Going live in your busiest month is a decision people make for budget or contract reasons and regret for operational ones. Your team is being asked to learn new software during the weeks they have the least patience and the most customers. Delaying a quarter to hit a quiet period is almost always cheaper than the alternative, even when the licence has already started.

The opposite mistake is running both systems for months. Double entry is exhausting, so people stop doing it properly. Within a few weeks the old system is the one being kept accurate, because it is faster and familiar, and the new one fills with half-entered records that nobody trusts. At that point the project has failed without anyone announcing it.

One month end in parallel gives you what you need. You close the same period in both, compare the trial balance, the stock valuation and the receivables ageing, and investigate every difference until you understand it. Then you stop writing to the old system on an announced date and keep it readable.

Why does the training never seem to stick?

Because it happens once, before anyone has real work to do in the system, and usually for whoever was free that day. People learn software at the moment they need it. Training that works is short, repeated, tied to the tasks someone actually performs, and given again a month after go live.

A two-day session in week six is almost entirely wasted. By go live people remember the login screen and little else. Better to run short sessions per role, close to the switch, then be present in the building or on a call for the first two weeks when the questions are real and specific.

Write down the ten things each role does every day, step by step, with screenshots. This is dull work and it is the highest-value document in the whole project. New staff use it, the person covering a holiday uses it, and it survives when the vendor's consultant moves to another client.

Then there is the failure that shows up a year later. One person absorbs the system, becomes the person everyone asks, and quietly becomes the only one who knows how anything is configured. When they resign or go on leave in month end, you discover how much of the process lived in their head. Two people per function who can work without help is the minimum, and it costs almost nothing to arrange at the start.

• Everything routes through one name

  If the same person answers every question in the group chat, the dependency already exists.

• Nothing is written down

  No procedure documents means the process only exists as habit, and habits leave with people.

• Only one person has full access

  Convenient during setup, dangerous afterwards. Agree who else holds administrator rights.

• Configuration changes have no record

  Keep a simple log of what was changed and why, or you will be reverse engineering it later.

How much slower will your team be after go live?

Slower for a while, and almost nobody warns you about it. Work that took two minutes takes ten while people hunt for the right button. Expect several weeks of reduced output and rising complaints. Plan for it, warn your customers if delivery times are affected, and start nothing else that quarter.

The dip itself is normal and temporary. The danger is what management does with it. Around week two, someone senior looks at the delays and concludes the new system is wrong, pressure builds to go back, and the project dies in the exact window where it was always going to look worst.

So decide in advance how you will tell a normal dip from a genuine problem, and write it down before go live while everyone is still calm. A slow, complaining team is expected. A team that has quietly gone back to Excel is not.

Practical cover helps more than encouragement. Approve some overtime for finance during the first close. Push non-urgent projects out of that quarter. Tell your largest customers that order confirmations may be a day slower for a few weeks, because saying it in advance costs you nothing and saying it afterwards costs you credibility.

What does go live actually mean?

It means the day you stop entering transactions in the old system, and nothing more. It is the start of the hard part rather than the end of the project. Treat it as the finish line and you will be on your own in the month you need help most.

Most people picture go live as a handover. In practice the first real test comes at the first month end, weeks later, when finance tries to close a period inside a system they have used for three weeks. That is when the missing configuration, the wrong tax setup and the stock differences all appear at once.

Check what your agreement says about the period after the switch. If support hours or the consultant's involvement end on the go-live date, you have bought help for the easy part and none for the difficult one. Negotiate cover through the first closed month, in writing, before you sign anything.

Define what finished means in a list you can tick, and agree it with the vendor early rather than arguing about it later. Until every line is true, the project is still running, whatever the invoice says.

• One month end closed inside the system

  Not exported to a spreadsheet and finished there. Closed in the system, reconciled and signed.

• Stock counted and matching

  A physical count against the system figure, with the differences explained rather than adjusted away.

• Two people per function working unaided

  Test it by having the usual person take a day off during a normal week.

• Daily tasks written down

  Step by step, in the language your team uses, stored somewhere they can find it.

• Support arrangement agreed for the first quarter

  Named contact, response times, and what counts as included versus billed.

Where does Wizard fit into this?

Wizard Cloud ERP is built and implemented by the same company, Wizard Solutions in Lebanon, which removes the argument about whose problem a bug is. It does not remove any of the work above. If your data is a mess and nobody inside owns the project, no vendor rescues you from that.

The parts we can genuinely take off you are the ones that depend on being close by. Support in your hours, someone who can come and sit with your finance team during the first close, and one company accountable for both the software and the setup. The parts we cannot take off you are the data cleanup, the decisions about how your processes should work, and finding the person inside your business who owns them.

If you have not chosen a system yet, the buying guide covers what to test in a demo and what to negotiate. If you are still on accounting software and unsure whether it is time, the guide on moving off it is the more useful place to start.