I have watched ERP go-lives from the support side, which is a particular vantage point. You do not see the ribbon-cutting. You see the queue.
What is interesting about post-go-live support is that the tickets are not distributed the way you would expect. They do not cluster around the hardest parts of the system. They cluster around whoever is least sure of themselves. The same unremarkable screen behavior will produce zero tickets from one department and eleven from another, and the difference is almost never the screen.
Two users hit the same small surprise. The first one clicks around for ninety seconds, works out what the system is telling them, and carries on with their day; you never hear about it. The second one concludes the system is broken, stops, and tells six colleagues that the system is broken. Now you have one ticket and six people who have pre-decided that the thing they are about to use does not work.
Confidence is contagious in both directions. That is why I have stopped treating training completion as a readiness measure. Training teaches people the path. Confidence comes from having stepped off the path once and found their way back.
Before a go-live date is confirmed, I would rather have honest answers to these three questions than a green project status.
Not “is the data complete,” but “is the data trusted.”
Complete-but-wrong data is more dangerous than obviously missing data, because obviously missing data gets fixed and plausible-but-wrong data gets planned against.
In a manufacturing context, this bites hardest in planning. Lead times copied across from a legacy system without being questioned, parts assigned to the wrong warehouse, costing that has never been reconciled against what the shop floor actually does: none of that stops the first MRP run from producing output. It just makes the output wrong in a way that looks entirely reasonable. And users learn very fast. If the first planning run they see is visibly nonsense, they will distrust the second one even after you have fixed it.
There is a straightforward test for this, and hardly anyone runs it. In the test environment, hand your users a deliberately awkward scenario and do not tell them the answer. A shipment that has to go out partial. An order line the customer cancelled after allocation. A work order that needs splitting halfway through. Then watch.
You are not testing whether they get it right. You are testing what they do when they are unsure: whether they explore, or whether they stop and escalate. The ones who explore will be fine on day one. The ones who stop need a different kind of preparation than another training session, and it is much cheaper to discover that four weeks out than on go-live day.
Yours and ours. Day one is not the day for a super-user to be on vacation, and it is not the day to discover that the person who knows how your entity is configured is in back-to-back meetings.
A go-live date is a commitment made months earlier by people who could not have known what they would find. Readiness is a state of the organization. When those two disagree, the date is the thing that should move, and the reason it usually does not is that nobody wants to be the person who says so. Make that easier by agreeing on the three questions up front, so that when the answer to one of them is “no,” it is a criterion being applied rather than somebody losing their nerve.
Not sure how your organization would answer those three questions? Our team has supported go-lives from the inside, and we know where readiness tends to break down. Talk to a Visibility expert before you commit to a date, and go live knowing your data, your people, and your support are ready.