Your ERP Project Has Two Sets of Metrics. Only One of Them Is Yours.

When you approved this project, you committed to something. Efficiency. A capability you don't have. A platform you can grow on. Whatever it was, it's yours — you're the one accountable for it landing.

Your solution partner committed to something too. Go live on the date. Hit the milestones. Close the scope. Those are real, and they're reasonable, and they are not the same as yours.

Most of the time the two run together and nobody notices the difference. But at the points where they diverge, one set of metrics wins — and it usually isn't yours. Not because anyone set out to shortchange you. Because in the room where the project actually gets built, the partner's metrics are the ones with someone paid to defend them. Yours aren't.

That's the truth no one in that room will say out loud, and it's worth sitting with before you sign anything.

How your metric quietly gets lost

It rarely goes wrong in a big, visible way. It goes like this.

Deep in the project, one process surfaces that nobody detailed properly up front. It got a sentence in a workshop when it needed a page. Rather than stop the project to understand it, the partner does the sensible thing for their metric — they build assumptions around it to make it fit their best-practice template. Milestone stays green. Everyone moves on.

Here's the pattern, and I've watched it from both sides of the table: the process that gets assumed away is, more often than not, one that mattered. There's a reason. The parts of your business that work like everyone else's are easy to describe, so they never get forgotten. The parts that are genuinely yours — the ones that give you an edge — are the hard ones to explain. They grew up over years, they live half in people's heads, they don't reduce to a tidy diagram. Which makes them exactly the ones most likely to be glossed, under-specified, and then backfilled with someone else's assumptions.

So the project's blind spot points straight at your advantage. And the cost doesn't show up as a failed go-live. It shows up as the thing you were known for getting harder to do — long after the money's spent.

You may not blend formula. It doesn't matter.

Two quick examples, because the shape is easier to see in someone else's business than your own.

A baby formula manufacturer, on paper, had a process any ERP handles in its sleep: blend, then can. But that's not how the plant ran. Every blend is quality-tested, and the test result decides what happens next — pass and it moves on, fail and it goes back to be re-blended and tested again, however many times it takes. It isn't a sequence. It's a loop gated by quality. A standard ERP models fixed steps in a line and has nowhere to put that. The real choice was a custom solution — or forcing the way they make the product to fit the way the software wants it made. One of those protects the business. The other quietly rebuilds it around a template.

Now the opposite corner. In New Zealand forestry, finance — the function everyone treats as the place you just use the standard — has to account for the growth and harvesting of standing timber, with accrual treatment no off-the-shelf module assumes. Get it wrong and your numbers stop reflecting the actual economics of the business. It's as far from the plant floor as you can get, and it's the same trap exactly.

You may not blend formula or grow timber. Every business has its version — the process that's yours, hard to explain, that a generic template can't hold. The only question that matters is whether you know which one it is before someone assumes it away.

Where it lives is a decision, not a default

Once you know your handful of genuinely-yours processes, the question isn't whether the ERP can swallow them. It's where each one belongs — and that's a choice you make on purpose, not one the software makes for you.

Some, you keep outside the system entirely and run your own way. Others are too central to leave out; they get embedded, either in the ERP or in a specialist system wired into it. And here's what's changed, because it's the objection that used to force everyone's hand: integration is no longer the expensive problem child it once was. Modern systems are built to connect, and wiring a specialist tool into your ERP is now routine, not a bespoke ordeal. Losing the ability to run a process the way your business needs, though — that cost is exactly as real as it ever was, and you pay it for years. The trade companies still flinch at is the cheap one. The trade they should fear is the one they take without noticing.

What actually protects your number

Your team knows the business. They know where the edge lives, even if they've never written it down. What they don't necessarily have is the second thing — the discipline of defending that knowledge through a live build. Surfacing the right process at the right moment, insisting it gets detailed instead of assumed, spotting when a template is quietly swallowing something it shouldn't. That's a different skill from running the company, and most internal teams have never had reason to build it.

That's the whole case for a fractional Solution or Enterprise Architect. Not a full-time seat you can't justify. Someone brought in at the stages that decide the outcome — the RFP, the selection, the build — with no software to sell and no implementation to win, whose only job is to hold the project to your metrics rather than the partner's. It works no matter the platform: Microsoft, Infor, Oracle, SAP, any of them.

And it matters for a plain reason. Solution partners field genuinely capable salespeople — that's their job, and they're good at it. Making their solution sound like the answer to everything is exactly what they're paid to do. Which is simply why it helps to have one person in the room whose incentive runs the other way.

The project will go live either way. Whether it delivers the outcome you signed up for, or the one your partner did, comes down to whether anyone was protecting yours.