How to Run an ERP Selection Process Without a Forty-Tab Requirements Matrix.
The standard ERP selection process produces a spreadsheet. Forty tabs, nine hundred rows, one row per requirement, a column per vendor, a score in every cell. It takes three months to build and it has one structural flaw: every vendor answers yes to every row. The matrix cannot tell the products apart, because the products were built to pass it.
We run selections differently, and the difference is where the discrimination comes from. Not from how many features a product has, but from how it handles the six operations that actually run your company. This is that process.
Why the matrix cannot choose.
A requirements matrix asks whether a product can do something. Can it handle multiple warehouses. Can it consolidate entities. Can it bill by milestone. Every modern suite can, in the sense that a configuration exists somewhere in it that produces the result. So the vendor marks yes, truthfully, and the score is the same across the shortlist.
What the matrix does not ask is how. How many steps, how many screens, how many workarounds, how many of your people have to remember to do something manually for the yes to be true. That is where ERP implementations go wrong, and it is invisible in a cell.
The matrix has a second cost. Building it consumes the three months that should be spent understanding the business, and it produces a document that describes the software market instead of the company. We have seen selections where the requirements document was longer than the eventual contract and nobody could say which twelve rows mattered.
Start from the operations that decide it.
Our selection starts with a different question: which six operations, if the new system handles them badly, would make the project a failure. Not six hundred requirements. Six scenarios. For most operationally complex mid-market companies the list is close to this.
One order, quote to cash. A real customer, a real quote with a discount, the order, the fulfilment, the invoice, the payment, the credit note when something was wrong. Walked through end to end, in the product, with the vendor's hands on the keyboard.
One month-end close. Where the numbers come from, how the subledgers roll up, what has to be reconciled by hand, how long it takes.
One return or one exception. A shipment that comes back, a job that overruns, a partial delivery. The happy path is the same everywhere; the exception path is where products differ.
One build or one project. For a manufacturer, an assembly from components with the stock movements it causes. For a services firm, a project from proposal to invoice with time against it.
One multi-entity or multi-site report. If you have two companies or three warehouses, a report across them, and what had to be true for it to be right.
One integration. The connection to the system that stays: the storefront, the help desk, the sales system. In which direction the data moves, what the record of truth is, and what happens when the two disagree.
These six are chosen from the business, which is the point. They take a week to write down and they are the whole requirements document.
Walk them through, live, with the vendor driving.
The selection then becomes six demonstrations per shortlisted vendor, each one scripted by you. The vendor is not allowed to show the product. The vendor is asked to run your scenario in it, with your data, your discount, your return.
What you are watching for is not whether it works. It is the shape of the path. Count the screens. Note every point where the presenter says "and then you would just" and describes a step outside the product. Note every field that had to be added, every report that had to be built, every rule that had to be configured on the spot. Those are the workarounds, and workarounds are the implementation budget.
Score each scenario on three things: did the product do it, how many manual steps were in the path, and which of those steps your people would actually perform every day. A product that handles the multi-entity report with two clicks and the return with eleven steps and a spreadsheet has told you something no matrix cell contains.
We wrote about the six evaluation criteria that decide an ERP outcome; the scenarios are how you apply them without reading a vendor's own description of its product.
What the scenarios reveal that the estimate hides.
A selection run this way produces a second output beyond the choice: it shows the implementation cost before the estimate does. Every workaround you counted is a configuration task, a data decision, or a process change. The vendor's estimate will have a line for licences and a line for configuration; the scenarios tell you how much process design and integration sit behind the configuration line, which are the two lines that overrun.
This is also where you find out whether your own company is ready. If the quote-to-cash scenario cannot be scripted because nobody agrees how a discount is approved, the problem is not the software. It is one of the three decisions that have to be made before kickoff, and a selection that surfaces it in week two has saved the project.
The four-week version.
Week one: write the six scenarios with the people who perform them. Not the IT lead; the warehouse manager, the controller, the person who does the close. Each scenario is a page: the starting state, the steps, the expected end state, the exception.
Week two: send the scenarios to the shortlist, three vendors at most, and give them two weeks to prepare. A vendor who declines to run your scenarios has told you how the implementation will go.
Weeks three and four: the walkthroughs, one vendor per session, two sessions each. Score them the day of, while the workarounds are fresh. Then the reference calls, where you ask about the scenario that scored worst, not about satisfaction in general.
Four weeks, and the output is a choice with a reason attached, a list of workarounds that becomes the implementation plan, and a set of process decisions the company has to make regardless of vendor.
Where this leaves the matrix.
Keep a short one. Thirty rows of hard constraints that would disqualify a vendor outright: the data residency you need, the accounting standard, the integration that must exist. Use it to build the shortlist and then put it away. The selection is made on the scenarios.
The companies that run selections this way sign later than the ones with the matrix and go live earlier, because the implementation plan was written during the selection instead of discovered after it. That is the trade, and it is the one that decides whether the system runs the business or the business runs around the system.
Our ERP Readiness Review runs the six scenarios with you before any vendor is in the room, so the first conversation with a vendor is already about your operations. Discovery is no-risk: you pay only if you go ahead.
Know whether your business is ready for an ERP before you sign for one.
The ERP Readiness Review is a 90-minute working session plus a written scorecard across master data quality, documented exceptions, integration scope and data ownership. Fixed scope, no obligation. Or see how we approach it.
More on the same problem:
Comments