ERP Questions to Ask
Twenty questions for choosing an ERP system and holding a vendor to their answers. They cover which processes the system has to support, your existing data, five-year cost, integrations, reporting, user permissions, legacy migration, guaranteed service levels, and how you will judge whether it worked.
The questions
Open any question for the note
Which of our processes is the current system actually failing at?
Why ask it
Start here rather than with vendors, because a list of complaints is not a requirement. If the honest answer is that finance wants better reporting, you may be shopping for a reporting tool rather than an ERP.
Which of our processes are we willing to change to match the software?
Why ask it
Answering this before demos decides your customization budget. Departments that say none should be asked which of their steps exist for a legal reason and which exist because someone set it up that way in 2011.
What would we still be doing in spreadsheets after this goes in?
Why ask it
Every implementation leaves some work outside the system, and knowing which in advance stops you being surprised by it later. A vendor answer of nothing is not credible and should be tested against a specific example.
Where does our data live today, and who owns each source?
Why ask it
Naming an owner per source is what makes migration possible, and it usually exposes two systems holding the same customer records differently. Sources with no owner are the ones that will stall the project.
What is the total cost over five years, including renewal increases?
Why ask it
Ask for the uplift cap in writing, since the initial discount often disappears at first renewal. A quote without stated assumptions about user count and transaction volume is not a five-year number.
How does your pricing change as we add users, transactions or legal entities?
Why ask it
Per-user pricing behaves very differently from consumption pricing as you grow, and the difference over five years can exceed the licence itself. Ask which units are metered and what happens when you exceed them.
Which modules do we actually need on day one?
Why ask it
Bundles encourage buying capability you will not configure for years while paying for it from month one. Ask what it costs to add a module later, since the answer is sometimes less than the bundle discount saves.
Can you run one of our real processes, with our own data, in the demo?
Why ask it
Scripted demos are built to look smooth. Handing over a genuine order with an awkward discount and a part-shipment is the fastest way to find out where the system is rigid.
Which of our other systems does it need to exchange data with, and in which direction?
Why ask it
Direction and frequency matter as much as the connection: nightly one-way is a different project from real-time both ways. Vendors often claim integration when they mean a file import someone runs manually.
How precisely can we control who sees payroll, margins and customer data?
Why ask it
Ask to see the permission screen rather than accepting that roles are configurable. Systems that only restrict at module level will force you to choose between blocking useful access and exposing salary data.
Which reports do our managers rely on now, and can this produce them without a developer?
Why ask it
Bring the five reports people actually open and ask for them to be built live. This is where the difference between the demo environment and daily use shows up most clearly.
How much of our history do we bring across, and where does the rest go?
Why ask it
Every additional year of history raises migration cost and slows the new system. Deciding to archive rather than migrate is normal, but it needs a plan for how someone answers a question about a five-year-old invoice.
How do we get our data out if we leave you?
Why ask it
Ask about format, completeness and cost, and check whether the export includes configuration and attachments or only tables. A vendor who has never been asked this will improvise, which is itself the answer.
What uptime and response times are you contractually committing to, and what happens when you miss?
Why ask it
Targets without remedies are marketing. Look for how availability is measured, whether planned maintenance is excluded, and whether the credit is large enough to matter against the fee.
How often do you release changes, and can we defer one?
Why ask it
On a cloud product you inherit the vendor's release cadence, so your regression testing effort per cycle is the real cost. Ask how much notice you get and what happened the last time a release broke something for customers.
How many customers of our size and industry are live on this version today?
Why ask it
The version detail is the point, since a large reference base on an older release tells you little. A small number is not disqualifying, but it means you will be finding the problems.
Which of our requirements does your product not do well?
Why ask it
Asked directly, and worth waiting through the silence. Vendors who name a genuine weakness are usually accurate about the rest; vendors who claim full coverage are describing a roadmap.
On the roadmap items we care about, what is committed and what is aspiration?
Why ask it
Ask for a date and a contractual mechanism. If a capability you need only exists on a slide, price the deal as though it will never arrive, because sometimes it does not.
Who else inside our organisation has to agree to this, and what will they object to?
Why ask it
Surfacing objections from finance, IT security and operations before selection is cheaper than discovering them during implementation. The department nobody consulted is the one that blocks go-live.
How will we know in eighteen months whether this was worth doing?
Why ask it
Agree two or three measures now, with today's baseline recorded, since afterwards nobody can remember what the old close took. Measures like faster reporting without a number attached cannot be evaluated.
Choosing a System
Practical guidance for the conversation itself
Do this before you talk to vendors
Write down your processes as they actually run
Not the documented version. The real one, including the spreadsheet a supervisor maintains and the approval that happens verbally. Software gets selected against the documented process and then fails against the real one.
Separate requirements from preferences
A short list of genuine constraints, statutory reporting, a union pay rule, a customer's labelling requirement, is more useful than two hundred scored line items where everything is rated important.
Fix a budget range internally first
Vendors size proposals to what they think you will spend. Knowing your own ceiling, including internal staff time, keeps the conversation about fit rather than financing.
Running demos that tell you something
- Send the same script to every vendor and make them work through it in the same order.
- Use your own awkward cases: the part-shipment, the credit note, the customer with three billing addresses.
- Have the people who will use it daily in the room, and let them drive for ten minutes.
- Count the clicks for your highest-volume transaction. Small differences multiply across a year.
- Ask what they just skipped. Demonstrators move quickly past the screens that need explaining.
- Ask for a sandbox afterwards, and see whether anyone on your team logs into it twice.
Common pitfalls in selection
Buying on demo polish
The smoothest demo often reflects sales investment rather than product depth. Weight what you saw in a sandbox with your own data far above what you saw in a presentation.
Letting the loudest department write the requirements
Finance usually leads these projects and operations usually lives with the result. If nobody from the warehouse or the service desk tested the workflow, expect the workaround culture to survive the new system.
Ignoring the exit before you sign
Data extraction terms, notice periods and post-termination access are easy to agree while a vendor wants your signature and impossible to negotiate later.
Choosing the product without choosing the partner
The same software delivered by different implementers produces very different outcomes. Evaluate both, and be willing to reject a good product offered with a weak delivery team.