The first ninety days after ERP go-live

Most implementation plans end at go-live. Most implementation failures happen afterwards.

The three months following are when the system either becomes how the business runs, or becomes a thing people work around.

Weeks one to two: the dip

Expect productivity to fall. Everything takes longer, staff are uncertain, and mistakes are frequent. This is normal and temporary, and being surprised by it is what causes panic decisions.

The critical thing is support availability. Not a helpdesk email — someone reachable quickly who can answer a question at the counter while the customer waits.

Where that is missing, staff invent their own answers. Some will be wrong, and wrong answers become habits within days.

Week two specifically

Worth calling out. Week one runs on novelty and vendor presence. Week two is when the vendor is less visible, the novelty has gone, and staff meet cases the training never covered.

Planning your heaviest support for week two rather than week one is a small change with a disproportionate effect.

Weeks three to six: watching for the parallel system

The real risk in this window is not failure — it is quiet workaround.

Someone finds a case that is awkward in the system and handles it in a side sheet. It works. Others adopt it. Now the system holds partial data, its reports disagree with reality, and the disagreement justifies the side sheet.

Signs to look for: spreadsheets being maintained alongside, a step being done twice, reports nobody uses, a department noticeably behind on data entry.

Every one of those is a signal that something in the system does not fit, and it is fixable in week four in a way it is not in month six.

Weeks six to twelve: the first real cycle

Now a full cycle has run — a month-end, a payroll, a billing period. This is the first honest test, because it exercises processes that only occur periodically.

Expect problems here that did not appear in daily use, and expect them to feel like setbacks after things had settled. They are not; they are simply the first occurrence.

What to measure

• Transaction volume in the system against expected — the clearest signal of workarounds
• Time to complete common tasks, which should be improving after the first fortnight
• Support tickets by area, because clusters point at a genuine misfit rather than a training gap
• Data entry lag by department — a growing lag means someone has stopped
• Reports actually opened, since unused reports mean people are getting information elsewhere

Hold change requests until day thirty

Requests will start in week one. Most are training issues in disguise, and some are genuine.

Collecting them without acting for thirty days lets you see which recur. A request raised once by one person is usually unfamiliarity. One raised repeatedly by several is a real gap.

Building the first version of every request teaches people that complaining is faster than learning, and it is expensive.

The ninety-day review

Worth doing formally, with the vendor and the internal owner. What is working, what people are still avoiding, which requests recurred, and what phase two should contain.

Projects that hold this review tend to keep improving. Projects that do not tend to freeze in whatever state they reached, including the workarounds.

If you want support structured for this period rather than ending at go-live, see how we handle implementation and support or talk to us.