The First 90 Days After Go-Live
Go-live is the start of the work, not the end of the project. The three numbers to record before you switch on, the reports to open weekly, and the four signs that a system is being used rather than merely populated.
Implementation plans end at go-live because that is where the vendor's obligation ends. Yours starts there. The first ninety days decide whether you own a working record of your operations or an expensive filing cabinet that people update on Tuesdays, and almost none of what decides it is technical.
Record three numbers before you switch on
Do this in the last week before go-live, while you are still capable of being disappointed by them. Afterwards, everybody becomes invested in the project having worked, and the definition of success quietly drifts to fit whatever happened.
| Number | How to get the "before" figure | What good looks like by day 90 |
|---|---|---|
| Stock count variance, as a percentage of counted value | The opening count is your baseline. Write it down. | The second count, at day 60 or 90, is materially lower. Under 2% on a repeat count is a well-run store. |
| Committed spend you cannot see | Ask finance what has been ordered and not yet invoiced. If they cannot answer, that is the baseline: unknown. | A number, on screen, updated when an order is approved. Going from "unknown" to "a number" is the whole win. |
| Days to close a month | How long after month end before the figures are agreed? Most SMEs say two to four weeks. | Fewer days, and the reason is fewer arguments about stock rather than faster arithmetic. |
Three is the right count. One is not enough to distinguish a working system from a lucky quarter; six means nobody reads any of them.
The weekly rhythm, thirty minutes
One person, same day each week, four reports. The point is not analysis — it is that somebody looks, and that people know somebody looks. Most of the value of an operations system is created by that second fact.
-
Open purchase orders, aged, oldest first
Approved and not fully received. Short in a healthy business, and it catches the supplier who took a deposit and went quiet, the duplicated order, and the delivery that arrived and was never receipted. If you adopt one habit from this article, adopt this.
-
Adjustments made this week, with reasons
Read the reasons, not the quantities. A reason code appearing more often than the others is a process problem wearing a stock costume — and if the reasons are all blank, you have a policy to write.
-
Anything received without an order
Every one of these is either an urgent purchase your process does not accommodate or a control being routed around. Both are worth knowing, and the two look identical until you ask.
-
Yesterday's entries, checked for lag
Not the content — the timestamps. Work recorded the same day by the person who did it is the single best predictor that this will still be working in a year.
The reports do not create the discipline. Somebody visibly reading them creates the discipline, and the reports are how they do it.
Day 30, day 60, day 90
Three checkpoints, each with one job
Boring is the completion criterion. A module is finished when there is no weekly meeting about it, no parallel record, and the questions have stopped being about how. Adding a second module before the first is boring means owning two unfinished things, which is how a good rollout becomes a stalled one.
Thresholds are guesses until day 60
Everything numeric you set at configuration was a guess: the value above which an adjustment needs a second approver, the reorder point on four hundred items, the number of days before stock counts as dead. They were reasonable guesses and they were made without data. At day 60 you have data.
How to read a threshold at day 60
Never triggered
The threshold is too high to be a control. Lower it until it catches something, or delete it and stop pretending.
Triggers occasionally, and each one was worth catching
Correct. Leave it alone. This is what a working threshold looks like and it is rarer than you would think.
Triggers constantly, always approved
Too low. It has become a queue rather than a check, and staff are learning that approval is a formality.
Being bypassed
Worse than having none, because it teaches people that the controls are decorative. Raise it to where it is defensible and enforce it there.
The middle position is the target and the two extremes are equally bad, which is unintuitive — a threshold nothing ever hits feels safe and is simply absent.
Four signs it is genuinely working
Look for these rather than for satisfaction
- Someone argues with a report. They think a figure is wrong, and they came with a specific record. That is trust — nobody argues with a system they have written off.
- A question is about the model, not the buttons. "Should a sample sent to a customer be an issue or a write-off?" means somebody has internalised how the records work.
- A control caught something and was not overridden. A blocked payment, a refused over-receipt, an adjustment that needed a second signature and got one.
- Somebody outside the project opens a report on their own. Not because they were asked. This is the point at which the system belongs to the business rather than to the rollout.
And one sign it is not
Everybody says it is going fine and nobody has any questions. In the first ninety days, silence is not adoption — it is either a system nobody is touching, or one where the workarounds have already settled and stopped generating friction. Go and look at the timestamps.
Our take
Write down three numbers before you switch on, spend thirty minutes a week on four reports — starting with aged open orders — and treat every threshold as a guess to be re-tuned at day 60. Then judge at day 90 on one question: is this boring yet? If not, the next module can wait, and saying so is the most useful thing an owner ever does.
The first ninety days are the implementation
Aged open orders, adjustments with reasons, receipts without an order and entry timestamps — the four things worth thirty minutes a week, and the honest reason they matter more than any dashboard.
See plans & pricingFrequently asked questions
What should we measure after go-live?
Three numbers, recorded before you switch on: stock count variance as a percentage of counted value, the shilling value of approved-but-not-yet-received purchase orders, and the number of days it takes to close a month. Record them while you can still be disappointed by them — after go-live everyone becomes invested in the project having worked and the definition of success drifts.
Which reports should we open weekly?
Four, thirty minutes, same day each week: open purchase orders aged oldest first, adjustments made this week with their reasons read rather than their quantities, anything received without an order, and yesterday's entry timestamps. Aged open orders alone catches the supplier who took a deposit and went quiet, the duplicated order and the unreceipted delivery.
When should we adjust the thresholds we set at configuration?
Day 60. Everything numeric you configured was a reasonable guess made without data, and by day 60 you have some. Raise thresholds that are triggering constantly and always being approved — those have become queues, and they teach staff that approval is a formality. Lower or delete any that have never triggered, because a threshold nothing ever hits feels safe and is simply absent.
How do we know when a module is finished?
When it is boring: no weekly meeting about it, no parallel handwritten record, and the questions have stopped being about how to do things. Adding the next module before the current one is boring means owning two unfinished things, which is the most common way a good rollout stalls.
What are the signs the system is genuinely being used?
Somebody argues with a report and brings a specific record — nobody argues with a system they have written off. A question arrives about the model rather than the buttons. A control catches something and is not overridden. And somebody outside the project team opens a report without being asked, which is the point the system belongs to the business rather than the rollout.
Is it a good sign if nobody has any questions?
No. In the first ninety days silence usually means either that nobody is touching the system, or that the workarounds have already settled and stopped generating friction. Both look like calm from a distance. Go and check the entry timestamps — whether work is recorded the same day by the person who did it will tell you which one you have.
