What to Think About Before You Talk to a Single ERP Vendor

Before you buy a lounge for your house, you do some thinking first.

What colour scheme is the room? What dimensions will actually fit without crowding the doorway? What material — leather, fabric, something that survives kids and dogs? What style, against everything else already in the room? What’s the budget, the timeline, the warranty? You walk into the showroom with answers, not just appetite.

Now imagine going to market to buy a new lounge without thinking about any of that. You’d be at the mercy of whatever the salesperson shows you. You’d buy what looked good under showroom lighting and discover, three weeks later in your actual living room, that it doesn’t fit, doesn’t match, doesn’t work.

This is, more or less, how most organisations buy ERP systems.

When it comes time to write a BRP — a Business Requirements Plan — we just do it. We open a template, start listing functions, and start talking to vendors. Without knowing much about our own business architecture. Without a clear operating model. Without articulating our business vision and strategy. Without mapping the digital landscape we’re already operating in, including the other systems this new one will have to live alongside. Without naming what we actually expect this system to do for us — not next quarter, but three years from now.

Let me take those one at a time, because each one is a question worth sitting with before a vendor ever enters the room.

Business architecture. This is the shape of how your organisation actually works — not the org chart, but the real structure of decisions, accountabilities, and information flow. If you can’t describe how a decision moves from your frontline to your executive team today, you have no basis for judging whether a new system will support that movement or get in its way.

Operating model. How do you actually deliver value, day to day? Centralised or devolved? Standardised or locally adapted? A vendor will happily configure a system to whatever you tell them. The risk isn’t the configuration. The risk is configuring a system around an operating model you’ve never actually written down — and discovering, post-go-live, that you configured it around an assumption nobody agreed to.

Business vision and strategy. Where is the organisation going? Not the mission statement on the website — the actual five-year intent. A system bought to solve today’s pain will quietly constrain tomorrow’s direction if nobody checked the two against each other first.

Digital landscape, including other systems. What else is already running? What integrates with what, and what depends on what? A new system doesn’t arrive into a vacuum. It arrives into an ecosystem you’ve usually never fully mapped, and the gaps in that map become the integration problems you discover eighteen months in.

Our expectations from the new system, to support us in the future. This is the one most often skipped, because it requires imagining a version of the organisation that doesn’t exist yet. Most requirements documents describe the organisation as it is. Few describe the organisation it intends to become — and a system bought against the former will need replacing the moment the latter arrives.

Skip this thinking, and here’s what happens instead. Non-functional requirements — security, performance, scalability, the things that don’t show up in a demo — get outsourced entirely. We just push them across to the ERP vendors and ask them to tell us what we need, because we never worked it out ourselves. And then there are no surprises, in the worst sense: our decisions end up driven by emotion and by whatever we’re shown in the demo, rather than by what we actually need. We fall in love with a feature in a sales pitch and reverse-engineer a justification for it afterward.

The way out isn’t a better template. It’s going deep within the enterprise first — knowing who you are, and what you’d like to become as an organisation, before a single vendor conversation happens.

So here’s the real question, the one that should sit above every requirements register: how could your next BRP be a catalyst for that change — for the organisation working out who it wants to become — rather than just another procurement document on the way to a contract?