Why ERP Selection Mistakes Show Up at Go-Live - What Broke First, and Where It Was Decided

John Hannan

52 minutes ago

8 min read

Selecting an ERP this year? If you lead a multi-site or regulated company and need a full selection program - requirements, RFP, scripted demos, decision - rather than a quick answer, see how our ERP software selection program works, or talk to John.

Which go-live problems were really selection mistakes?

Most of them, in the programs we have supported. The first week after an ERP go-live breaks in the same five places - shipping labels and printers, scanners and handhelds, approval and security roles, inventory counts, and reports - and each one traces back to something that was vague in the RFP, assumed in the demonstration or missing from the statement of work. Software gets the blame. The decision was made months earlier, usually by people who did not know they were making it. Below are the five in the order they showed up, a sixth that is a scope gap rather than a breakage, and the point in a selection where each one gets decided.

Most companies start by solving the wrong problem

A lot of ERP projects start with the answer already decided. Leadership assumes the current system is the issue because reporting is weak, the teams live in spreadsheets, or the processes feel disconnected. Sometimes that is true. Often the deeper problem is inconsistent data, unclear ownership, or an expectation no system could meet on its own.

A manufacturer believes it needs a new ERP because inventory visibility is poor, when the real issue is that material movement, labeling and shop-floor transactions are handled three different ways on three shifts. A distributor blames aging software for order problems that come from pricing complexity and exception handling nobody ever wrote down. The first thing I do is sort what is actually broken from what is just annoying, and work out which of those is costing money or creating risk. That list becomes the requirements.

What broke first, ranked

Here is what broke first in the go-lives we have supported, in the order it showed up, and the place in a selection where each one gets decided. We did not run the selection for most of those programs, which is rather the point.

Labels and printers. Shipping labels, pick labels, lot labels, and the printers and label machines behind them. In one program the shipping-label work alone ran about 132 hours against 50 budgeted. Where it gets decided - the RFP asks whether the system supports labeling, the vendor says yes, and nobody puts a label on a demo screen, names the printers or puts label design in the SOW.
Scanners and handhelds. Pick, move, issue, receive and labor reporting on a device, which is where the warehouse and the shop floor actually touch the system. Where it gets decided - the demonstration runs on a laptop and the device flows are assumed. Confirm them with the vendor in the demo, on the device, and name them in the SOW.
Approval and security roles. Who can do what, and which approvals happen automatically. In the first week people discover that a purchase order approved itself, or that the one person who can release a job is on vacation. Where it gets decided - roles get left to the partner's template because nobody asked, during the selection, who does what. A role design session belongs before user acceptance testing, and the business owns it.
Inventory counts. Count variances are the first-week question in the warehouse go-lives we have supported - for example, the system says 12, the shelf says 9, and nobody knows which to believe. Where it gets decided - data readiness. Items, locations, units of measure and opening balances with a named owner and a readiness measure, reviewed weekly before cutover, with a count scenario in the demo script.
Reports. The month-end pack, the open order report, the shop schedule - the things people printed from the old system every morning. Where it gets decided - the RFP carries no Phase 1 report list, and the dashboards in the demo get taken as the answer. Dashboards are a distraction during a first phase, even now that AI can produce them cheaply, because the data underneath has to be right first. A list of the twenty reports the business cannot run without belongs in the RFP, and in the SOW with an owner.
Demonstrated but not there. Setup steps, revision control, quality checklists - features the committee saw in a demonstration and could not find at go-live. This is the one that produces the question I hear most often after a launch - did they lie to us, or did we set it up wrong? The honest answer is usually neither. The feature exists. It was never put in scope, so nobody configured it, nobody tested it, and nobody trained on it. Where it gets decided - the deferred-scope list. Every requirement is either in Phase 1 with an owner, or written down as deferred with an executive approval process for adding it back.

None of the six is really a software problem. Each one was a sentence that should have been in the RFP, the demo script or the SOW, and those three documents were the company's to write.

A yes in the RFP is not a configured feature

Any decent software looks good with clean data on the happy path. Nobody runs on the happy path. The real test is whether the software supports the workflows, exceptions, controls and hand-offs that drive your margin and your risk. In manufacturing that is how material moves through receiving, relabeling, conversion, quality checks and costing. In distribution it is pricing logic, customer hierarchy, chargebacks, rebates and the partner integrations that decide whether an order ships right.

That is why broad feature checklists rarely protect the business. Almost every vendor can answer yes in some form. What matters is whether they can prove it against the work that matters, on your scenarios, in the demonstration, and whether the proof then makes it into the statement of work as scope. The RFP response tells you how each requirement will be met - standard, configured, an add-on, an integration, custom development, or a process change - and that answer is what gets priced and tested. Our note on how requirements shape the RFP and the demo covers the mechanics.

Requirements expire, and some settings cannot wait

Two things about requirements that nobody mentions during a selection.

First, they age. A requirements set approved by a dozen stakeholders in one program had, two years later, become an ERP plus three more systems around it, because the business had moved and an 18-month planning horizon had been missed in the gathering. If the selection and the implementation are more than a year apart, re-read the workbook before design starts.

Second, a handful of settings cannot still be under discussion at kickoff. Lot versus serial control. The fiscal calendar. The chart of accounts. The unit of measure structure. These are decided once, early, and everything else is built on them. Change one of them late and the build stops while everything on top of it is redone. The place to force those four decisions is before the contract is signed, when they cost a meeting rather than a rebuild.

Ask for a plan, not a date

Vendors asked "when do you want to go live" hear "tomorrow", and they quote to it. For one scope in one of our selections the finalists estimated four to six months and eight to twelve months. Same requirements, same company. In another, the decision document found no credible path to a four or five month go-live, and the two credible plans at about six months each assumed a full-time project manager on the client's side. My rule is simple. Do not give the vendors a date. Make them give you a plan, with the client hours by role and by week, and compare the plans. The spread tells you what each vendor is counting as Phase 1 and who it thinks is doing the data and the testing.

Then plan a window rather than a date. Go-lives move for testing and for calendars - a plant's summer vacations, a fiscal year-end, a peak season - and the companies that plan a window with a fallback come through it. The ones that give the board a date end up explaining the slip to the board.

Software choice and partner choice are not the same decision

A sound platform can still produce a troubled implementation if the partner lacks industry depth, staffs the project with people who were not in the demo, or runs a delivery model that does not fit the way the company operates. And software takes the blame for problems that were really weak project leadership or shallow discovery. Selection should evaluate both the product and the people, as its own scored decision. We published the scorecard we use for that in our note on choosing the implementation partner.

The commercial assumptions, and the pace

A great deal of go-live risk sits in what was assumed before the project started - who owns the integrations, who owns testing, who owns data migration, how long hypercare runs, which environments exist, who the named people are. If those are vague at signature they are settled later, when the company's bargaining position is gone and the cost of change is high. The eight areas we review before signature are in our pre-signature decision check.

And a system can be right and a project can still fail, usually because the organization tried to do too much, too fast, with too little internal capacity. Sometimes the right answer is a narrower first phase, or a phased rollout, or holding a secondary system until the core is stable, or admitting that the internal team is too thin and hiring the system owner before go-live rather than after. I do not see realism as negativity.

Good selection work carries into the implementation

A good selection keeps paying after the decision. The requirements become design inputs. The demonstration scripts become the test scripts. The risks are already in a log instead of surprising everyone in month three. The deferred-scope list exists. The report list exists. The role design has an owner. We now close every selection with a written decision document so that what was decided, and why, survives the hand-off to the partner and the arrival of a new executive who was not in the room.

I am an advocate for the client in that process, not a salesperson for anyone's software, and the job does not end at the recommendation. It ends when the system is live and the labels print.

If you are choosing a system and want the go-live decided now rather than discovered later, talk to John about your ERP program.

Frequently asked questions

What breaks first after an ERP go-live?

In the programs we have supported, in order - shipping labels and printers, scanners and handhelds, approval and security roles, inventory count variances, and the reports people ran every morning on the old system. All five are decided in the RFP, the demo script and the statement of work. The sixth, a demonstrated feature that never made it into scope, is a scope gap rather than a breakage.

Did the vendor lie about the feature we cannot find?

Usually not. The feature exists and was shown in a demonstration, but it was never put in scope, so it was never configured, tested or trained. A deferred-scope list with an approval process for adding items back prevents the argument.

How long should an ERP implementation take?

It depends on the scope, the delivery approach and the time your own team can give it, so ask for a plan, not a date. For one scope our finalists estimated four to six months and eight to twelve. In the one decision document where we compared the plans line by line, the credible ones ran about six months for a first phase and each assumed a full-time project manager on the client's side.

Which settings must be decided before kickoff?

Lot versus serial control, the fiscal calendar, the chart of accounts and the unit of measure structure. Everything else is built on those four, and changing one late stops the build.