Few projects have a worse reputation than an ERP implementation, and for good reason. They are expensive, they run long, and a large share of them underdeliver or quietly stall halfway through. Founders and operations leaders often walk into one hopeful and come out wary, having spent a serious budget to end up roughly where they started, only more tired.
The interesting thing is that ERP projects rarely fail for technical reasons. The software mostly works. They fail for operational reasons, which means they are avoidable if you run them the right way.
Why they go wrong
The process was never fixed first. An ERP does not fix broken operations. It encodes whatever process you point it at. If you automate a messy, undocumented way of working, you get a faster, more expensive version of the same mess, now locked into a system that is hard to change.
Scope runs away. Every team wants their edge case handled, every "while we are at it" gets added, and the project balloons. What could have been a focused rollout becomes a multi year programme that outlives everyone's patience and budget.
Nobody owns it from the operations side. The vendor owns the software. But if no one on your side owns the business outcome, the decisions that actually matter, what to standardise, what to drop, what good looks like, either do not get made or get made by people optimising for the wrong thing.
Adoption is treated as an afterthought. A system that is live but not used is not a success, it is a liability. When training and change management are bolted on at the end, people quietly keep working the old way alongside the new one, and you now maintain two systems instead of none.
The operator's way to run one
The fix is not a better vendor or a bigger budget. It is running the project as an operations initiative that happens to involve software, rather than a software project that happens to touch operations.
Fix and document the process before you automate it. Decide how the business should actually run, then choose a system to fit it. Not the other way round.
Scope to what you need, and defend it. Start from the outcome you want and cut ruthlessly back to it. Every addition should have to earn its place. A tight scope that ships beats a perfect one that never does.
Put one accountable owner on your side. Someone who owns the business outcome, makes the calls, keeps the vendor honest, and does not disappear when the hard trade offs arrive. This is the single biggest predictor of whether a rollout lands.
Design for adoption from day one. Involve the people who will use it, build the training and the new operating rhythm into the plan, and measure success by whether the business actually runs on the system, not by whether it went live.
Where the line sits
There is a useful distinction worth holding onto. Selecting the right system, scoping it, and leading the rollout is operations work. It needs someone who understands how your business runs and can make honest trade offs on your behalf. The heavy build and configuration is delivery work, and when it needs a full team, it should run through people set up to deliver it, under that same operational oversight.
Keeping those two roles clear, the operator who leads and protects the outcome, and the team who builds, is most of what separates an ERP project that lands from one that stalls.
The outcome to aim for
A good ERP implementation is quiet. The right system goes live, people actually use it, the business runs more smoothly than before, and six months later nobody is talking about the project because it simply worked. That is achievable. It just requires treating the rollout as an operational problem with a software component, and putting someone accountable in the seat to run it that way.
If you are weighing up an ERP move, or you are partway into one that has stalled, that is exactly the kind of thing I lead. Tell me where you are and I will tell you straight whether I can help.