I have walked through enough ERP implementations to know that the failures are not dramatic. There is no single moment of collapse. There are six quiet decisions, each reasonable in isolation, that together produce a go live nobody trusts and a system nobody wanted. The value of listing them is that they are all visible in advance. None of the six below is a mystery, and none of them is technical.
Mistake 1: scope that grows quietly
The project starts with a sensible scope: finance, stock, purchasing, orders. Then a retail director sees the system and asks for a reporting suite the platform was never sold on. A warehouse manager asks for a custom pick screen. A buying manager wants a bespoke allocation rule. Each request is small, and each one lands in the budget as "minor change". By month six the project is running a second, undocumented project alongside the first.
The countermeasure is a change control process that prices every request before it is approved, in weeks and pounds, with a named owner signing off the impact on the go live date. The project calendar shows how customisation inflates duration, and the build versus buy decision shows where that path ends. Scope is decided by a change board, or it is decided by nobody.
Mistake 2: data work started too late
The project plan says data migration happens in the last two months, because that is when the vendor's template is ready. The team extracts the product master, discovers 12,000 duplicate SKUs and three years of unposted adjustments, and the schedule stops while the business scrambles. The stock accuracy explains why the data is in this state, and the fix is timing: start the data audit during selection, run the cleaning during configuration, and arrive at migration with data that is ready rather than data that is hopeful. Data work does not need the new system to start, it needs the old data.
Mistake 3: testing without the real users
User acceptance testing is scheduled, and the people who attend are the people who are available: the finance manager's deputy, the warehouse supervisor's assistant. The real users stay in the business because the business cannot spare them. The system passes testing and fails in production, because the testers did not know what the real work looks like.
The countermeasure is uncomfortable but simple: the people who will use the system every day do the acceptance testing, and the business covers their day jobs for the testing window. There is no cheaper insurance in the whole project. The Chartered Institute of Procurement & Supply makes the same point about change programmes generally: user involvement decides adoption, and adoption decides whether the investment pays back.
Mistake 4: integrations without owners
The marketplace connector is configured, the web platform is connected and the carrier integration is tested. Then the go live happens and the integrations start failing in rotation, and nobody knows whose job it is to notice, diagnose and fix them. The marketplace setup guide describes the five flows per channel; the implementation mistake is treating them as vendor deliverables rather than ongoing responsibilities.
Every integration needs a named owner before go live, a monitoring check and a fallback process. The owner does not need to be a developer. They need to be the person who notices when the sync has not run, and who knows who to call. That person is usually the same person who was copying data between systems before the project, and they are the first hire you should make, not the last.
Mistake 5: go live on the calendar, not the readiness
Go live dates get chosen for reasons that have nothing to do with readiness: the vendor's quarter, the lease on the old system, the board's patience. The result is a cutover in the middle of peak season, or a go live with three of six integrations still unproven, or a launch on the Friday before a bank holiday with no support cover. Each of these is a decision that the selection questions article tells you to probe before signing, because the contract usually fixes the date before the readiness exists.
Run a formal go no go review a month before the date, with a written checklist and a veto that any workstream lead can exercise. It is easier to explain a slipped date than a failed launch, and the retailers who use the veto almost never regret it.
Mistake 6: training as a slide deck
Training is delivered in two hour sessions with slides, three weeks before go live, and forgotten by week one. The users then improvise, the improvised workarounds become the process, and the system is quietly abandoned in favour of the old habits and the old spreadsheets. The Information Commissioner's Office and every regulator that audits retail operations would add the same warning: untrained users create uncontrolled processes, and uncontrolled processes create the errors that show up in audits later.
Training should be scenario based, in the system, with the user's own data, and repeated after go live, not just before it. The best implementations treat training as a habit that continues for the first quarter, with floorwalkers in the warehouse and the office in week one, not a course that ends.
The habits that prevent all six
Notice what the six mistakes share: they are governance failures, not software failures. The habits that prevent them are a change board that prices requests, a data workstream that starts early, real users in testing, named integration owners, a go no go review with teeth, and training that happens in the system. None of these is expensive. All of them are boring, which is exactly why they get skipped.
The architecture comparison and readiness for an omnichannel ERP cover the decisions that come before implementation, and the go live schedule covers the calendar that holds it all. Read those three, run the six countermeasures, and the implementation becomes the reliable part of the programme, which is what it should have been all along.