Most ERP projects do not fail on launch day. They fail quietly, around the third month, when the novelty wears off and people start going back to their spreadsheets. We have learned to design for that month from the very first workshop.
The month-three problem
Launch week is usually fine. The vendor is on call, managers are watching, and everyone is willing to try the new system. The real test comes later, when the first month-end close lands on top of normal work, when a new hire joins and nobody has time to train them, and when a report that used to take five minutes in Excel now takes three clicks and a filter nobody remembers.
That is when a parallel spreadsheet appears. Then another. By month six the ERP holds half the truth and the business runs on the other half. Nobody decided to abandon it. It simply stopped being the easiest way to get the job done.
An ERP is not adopted at go-live. It is adopted, or abandoned, in the weeks after everyone stops paying attention.
Why it happens
When we look at struggling rollouts, including ones we were brought in to rescue, the causes are rarely technical. They tend to be the same handful of design decisions:
- The system was designed for the manager, not the person entering the data. Dashboards look great in the demo, but the clerk, storekeeper or field supervisor who feeds them was an afterthought.
- Everything was launched at once. Finance, inventory, HR and sales all went live on the same day, so every team was learning at the same time and nobody could help anyone else.
- The old way was never switched off. If the paper register or the shared spreadsheet still works, people will use it whenever the new system feels slower.
- Month-end was never rehearsed. Daily entry was tested thoroughly. Closing the books, billing every customer and reconciling stock were tested once, with clean sample data.
How we design around it
1. Start with the busiest screen
Before we draw a single dashboard, we find the screen that will be used most often by the person with the least time. On a farm that is daily attendance. In a cold store it is the gate pass. In a shop it is the sale. We make that screen faster than the paper or spreadsheet it replaces, and we prove it by timing it with the actual staff. If the busiest screen is slower than the old way, nothing else matters.
2. Roll out in modules, not in one big bang
We split the system into modules that each solve one problem on their own, then launch them one at a time. This is exactly how we built FarmOS: a cold store can start with Cold Storage alone, and add Labour or Sales later. Each launch is small enough that the team can absorb it, and every module that works builds trust for the next one.
3. Rehearse month-end before go-live
We run at least one full month-end close on real, messy data before launch: billing every customer, reconciling every lot, paying every worker. It is the single most useful week in any ERP project, because it surfaces the edge cases that daily testing never touches.
4. Make the reports people already use
Every business has three or four reports that someone builds by hand each week. We ask for copies on day one, rebuild them inside the system, and make sure they come out the same. When the familiar report appears with one click, the spreadsheet loses its reason to exist.
5. Plan the switch-off
We agree with the client, in writing, which registers and spreadsheets will be retired and when. Then we check, at week two, week six and week twelve, whether anything has crept back. If it has, that is not a training problem. It is a design problem, and we fix the system.
What to measure
Go-live is not the finish line, so it is not the metric we report on. In the first ninety days we watch three things:
- How much of the daily work is entered on the day it happens.
- How many reports are still built outside the system.
- How long the month-end close takes compared with before.
If those three numbers improve through month three, the rollout has worked. If they flatten or slip, we know exactly where to look.
The short version
ERP rollouts fail when the system is harder to use than the workaround. Design for the person entering the data, launch in small steps, rehearse the hardest week before it arrives, and keep watching after everyone else has moved on. That is how software becomes the way a business runs, rather than one more tool it tolerates.