Why do ERP implementations fail?

The most common cause is that the project is handed to a vendor or a consultant and the shop waits for the result. Decisions about how items are coded, what a work order status means and who may change a price belong to the shop, and they stall when no one is responsible for making them. The fix is one named owner with hours set aside each week and the authority to decide. In a 10 to 50 person shop that is usually the owner, the plant manager or the planner, and the project moves at the speed of that person's attention.

An ERP exposes every shortcut the spreadsheets allowed. Two codes for one part, BOMs with the wrong revision, opening stock copied from a running balance that nobody counted. From day one the system reports numbers the floor knows are wrong, people stop trusting it and go back to their own sheets. Clean the active items, choose the current BOM revision, and load stock from a physical count. The cleaning is dull and takes weeks, and it is where projects are won or lost.

Going live with every module at once overwhelms a small team and makes every problem urgent. Customising before the standard process has been run bakes old habits into new software and makes upgrades painful. Both come from treating the ERP as a one-time event rather than a sequence.

• Start with stock and work orders, add purchasing, then accounting
• Run the standard process for a month before changing it
• Use custom fields and workflow rules before custom code
• Say no to a feature request until it has been asked for twice

A one-hour demo to the whole team is not training. People learn a screen by doing a real transaction on it under supervision, once, with a one-page guide they can keep. Train by role and keep each session short. Expect a dip in speed for the first two weeks, and plan for it rather than treating it as proof the system is wrong. After go-live, hold a short daily stand-up for a month and fix the data causes of problems rather than teaching workarounds.