Ask the CFO how the ERP is going and you'll get a good answer. Month-end close is faster. The numbers reconcile. There's one version of the truth with an audit trail underneath it. By every measure finance uses, the project landed.
Ask sales. Ask support. You'll get a different answer, and it won't be about features — it'll be about time. What used to take two clicks takes eleven. The tool that fitted how they worked is gone, replaced by one that fits how finance works.
Both answers are true. That's not a contradiction, it's the design.
An ERP doesn't remove work. It moves it.
This is the part the business case never models.
Finance's single source of truth doesn't materialise. It gets typed in. The structured, validated, reconcilable data that makes month-end fast has to be entered by someone — and that someone is at the edge of the business, with a customer waiting on the phone.
The CFO's clean ledger and the sales rep's extra fifteen minutes are the same fact, viewed from two ends. The saving is real. So is the cost. They just land on different teams, and only one of those teams was in the room.
The consolidation pitch is always framed as removal: fewer systems, less duplication, one truth. Read it as relocation instead and it gets more honest — the work doesn't disappear, it transfers from the people who wanted the system to the people who didn't.
The room decides the outcome
Here's who is usually present when an ERP gets approved:
The CFO, and finance
The sponsor. The department with the clearest pain, the strongest business case, and a genuine problem that the ERP genuinely solves.
The C-suite
Assessing a decision framed in the language of the sponsor, because that's who built the paper it's written on.
The vendor
Demoing to the buyer. The buyer is finance. So the demo is a finance demo, and it's excellent.
Nobody from sales or support
The teams who'll touch the system most, every day, have no representative and no veto — and won't find out what changed until go-live.
Now notice who else isn't there: anyone technical whose job is to ask what this does to the people who didn't ask for it.
That's not a small omission. It's the whole mechanism. A decision made by one department, assessed in that department's language, sold by someone who only has to convince that department, will optimise for that department. Not through malice — through the simple physics of who is in the room.
What this actually looked like
A client of ours had no CTO. The ERP decision went through the C-suite, led by finance, with nobody technical in the room and nobody speaking for the teams at the edge.
And it worked. For finance and for management, the system did what they bought it for — that part deserves to be said plainly, because the temptation is to tell this as a story about a bad platform. It wasn't a bad platform.
For sales and support, it replaced tools that fitted their work with processes that served the ERP. More steps, more time, more frustration — to do the jobs they had been doing faster the week before. Nothing failed. No incident, no rollback, no line in a report. The cost just moved somewhere nobody was measuring, and stayed there.
That's the failure mode worth understanding: not an ERP that breaks, but one that succeeds exactly as specified, for exactly the people who specified it.
"You have too many systems" is not automatically true
The pitch that sells ERPs is that running several platforms is a mess to be cleaned up. Sometimes it is. Often it's just what a business looks like when each team has a tool that fits.
A sales team on a CRM built for sales, a support team on a helpdesk built for support, finance on an accounting system built for finance — that isn't fragmentation. It's fit. The cost of that arrangement is integration. The cost of consolidation is process overhead on every team the single system doesn't suit. Both are real, and one of them is much easier to see on a slide.
The honest question isn't "how many systems do we have?" It's "what does fragmentation actually cost us, and who pays it?" If the answer is re-keying between two systems, you have an integration problem, and an integration is a fraction of the price of an ERP — with none of the process cost.
The alternative to one big system isn't chaos. It's fitted systems that talk to each other properly: buy the platform each team actually needs, and build the edges between them.
What a technical person in the room would have asked
None of these are hard. They're just nobody's job when the chair is empty.
What does this system need from the people at the edge?
Every required field, every validation, every mandatory step is someone's time at the moment they're least able to spare it. Count them before you sign, not at go-live.
How many steps does a rep take now, and how many after?
Take a real, common task — quote a repeat customer, resolve a support ticket — and count clicks in the current tool versus the demo. Multiply by volume. That number is the project's actual cost.
Who loses a tool they like, and what did it do well?
If a team is giving something up, name it. A tool people like is a tool that fits, and fit is what you're about to trade away.
Could we integrate instead of replace?
If the pain is that two systems don't talk, that's a middleware question, not a licence question — and it leaves every team on the tool that suits them.
Who signs off on behalf of the people who didn't choose this?
Someone should have to. If nobody in the room is accountable for the sales and support experience, the decision has already been made and the meeting is theatre.
When an ERP is genuinely the right answer
This isn't an argument against ERPs. We review and implement them, and there are businesses where one is clearly correct:
- The fragmentation cost is real, large, and borne by everyone — not just the department that wants to consolidate
- The process genuinely should standardise, because the variation between teams is accident rather than advantage
- There's no source of truth at all, and the alternative isn't fitted tools — it's a wall of workbooks and an argument about whose number is right
- The integrations you'd need to avoid it would cost more than the platform, which does happen
The distinction is whether the pain is shared or sponsored. Shared pain justifies a shared system. Sponsored pain justifies an integration, and a conversation about who was going to pay for the ERP in hours.
The question to ask before you sign
Not "will this work?" — it will, for someone, and that someone is in the room telling you so.
Ask: which team is worse off after this, and have we heard from them?
If nobody is worse off, the business case is stronger than most. If someone is, that's fine too — it might still be the right call. But it should be a trade you made deliberately, with a number attached, and not a bill that arrives quietly in a department that never saw the invoice.
Frequently asked questions
The most common one isn't technical. It's that the ERP is approved by the department it suits — usually finance — and the process overhead lands on sales, support and operations, who weren't represented in the decision. The system does what it was bought to do; the cost simply moves to a team nobody was measuring.
Not automatically. Several tools that each fit their team isn't fragmentation, it's fit — and its cost is integration. One system's cost is process overhead for every team it doesn't suit. The honest question is what fragmentation actually costs you and who pays it, not how many systems you have.
Because an ERP's single source of truth is fed by data entry at the edge of the business. The structure and validation that make month-end fast for finance are entered by the person with a customer on the phone. That's not a bug — it's the same design decision viewed from the other end.
Someone accountable for the teams who didn't ask for it. If the only people in the room are the sponsor, the C-suite and the vendor, the decision optimises for the sponsor by default. That's the physics of the room, not anyone's bad faith — see what a virtual CTO actually does.
When the fragmentation pain is shared across the business rather than sponsored by one department; when process variation between teams is accident rather than competitive advantage; or when there's no source of truth at all and the alternative is a wall of spreadsheets.
Get someone technical in the room before you sign
An independent read on what a platform will cost every team — not just the one buying it.
Related reading
- Software Review & Implementation — independent assessment; we don't resell licences and carry no vendor quota, so the recommendation is whatever the assessment supports
- What a virtual CTO actually does — including being the person who asks what this does to everyone else
- How to choose business software without getting sold to — where this decision should start
- Wholesale & Distribution — what this looks like in distribution