The One Requirement That Decided It - Six ERP Selections, Six Capabilities

John Hannan

2 hours ago

7 min read

Selecting an ERP this year? If you lead a multi-site or regulated company and need a full selection program - requirements, RFP, scripted demos, decision - rather than a quick answer, see how our ERP software selection program works, or talk to John.

What single capability decided real ERP selections?

The six capabilities were a customer-facing configurator, truck inventory with promotion credits, chargebacks with landed cost, component-level lot traceability, outside processing with engineering changes in progress, and weight.

Never finance. In the six selections below the requirements workbooks ran to two or three hundred lines, the finalists that mattered scored within a few tenths of each other on finance, and one capability shaped the decision each time. The rule that follows from the record is simple. Find that capability before the RFP goes out and script it as a must-pass demonstration scenario. It is going to decide the selection either way, so plan for it.

Six selections, six capabilities

The companies are not named. The capabilities are exactly as they were. A capability can span a few connected requirements. In one case it settled whether to keep the existing system, and in another both finalists passed it and price decided.

1. A build-to-order manufacturer - the configurator. Seven vendors responded in writing and three demonstrated, four to six hours each, scored by the people who would use the system. Finance scored 5.0 and 4.8 for the two leaders. It separated nobody. The configurator did - the preferred vendor scored 5 of 5 on configurator flexibility and 4.8 on integration with the website configurator, against scores of 1 to 3 for the platform that had led on engineering depth. Our readout to the committee said it was the only option that met both the back-end logic and the front-end configurator goals out of the box. We generally tell clients not to be dazzled by an attractive screen. This was the exception, because customers needed to configure the product on a web page. The screen was the requirement.

2. A route-based distributor - truck inventory and promotion credits. Every ERP in the field could take an order and invoice it. The business runs on trucks that are warehouses, routes that change daily, promotions that land as credits in both receivables and payables, and proof of delivery at the door. The deciding capability was whether the system and its mobile companion could treat the truck as a stocking location, carry the promotion credits through receivables and payables, and prove the delivery at the door. That is what the demonstrations were scripted around, and it chose the platform and the mobile product around it. Nobody asked about the general ledger.

3. An importing distributor - pre-packs, chargebacks, available-to-sell and landed cost. Two finalists, both credible, both with retail customers that charge back for every labeling miss. The four tests were a pre-pack sold as a unit and received as pieces, an EDI chargeback traced to its cause, an available-to-sell number the sales team would believe, and landed cost that reached the margin report. Both finalists passed all four. When that happens the deciding capability has done its job, and the decision came down to price. That is the right order - capability first, as a gate, then cost.

4. A manufacturer under a quality system - component-level lot traceability. The question was not which new system to buy. It was whether the system the company already ran could carry lot traceability down to the component level under its quality system, because if it could, the right answer was to stay and upgrade rather than to call eight vendors. It could, with a project. The company chose an on-premise upgrade over a move to the cloud, knowing exactly what it was buying, and the deciding capability settled the stay-or-switch question before it ever became a selection.

5. A multi-site manufacturer - outside processing and engineering changes in progress. The business sends work out to subcontractors mid-routing and changes engineering while jobs are open. The RFP carried seven must-pass scenarios, and the one we called the worst day - a rush order arrives, a machine goes down, a subcontractor slips, and a partial shipment has to go out anyway - was the one that showed the difference between the finalists. How each team handled subcontract work in progress and an engineering change on an open job was part of the committee's reason, together with the demonstration scores and the cost. The platform it chose was not the one with the strongest written response, which is the next section.

6. A metal service center - weight. Theoretical weight on the order, actual weight at receipt and at invoice, the remnant back to stock at a sensible cost. Four written responses, three demonstrations, and after them neither broad platform led. The straw poll went to a metals specialist, and a third specialist that entered the process later won it, after business cases and a reference call. We have told that story in full in our metals service center note.

When the scorecard and the decision disagreed

If you run scorecards you should know what happened to them in these selections.

In the outside-processing selection the strongest written RFP response produced the lowest demonstration scores, 3.0 against 4.5 and 4.2, and the highest cost, and it was not selected. In a partner selection the firm with the highest score on both the RFI and the RFP went home and the firm that had scored fourth on the RFI was preferred, after the finalist presentations and the reference calls. In the chargeback and landed-cost selection both finalists scored as adequate on every line that mattered, and the scorecard could not decide, so price did.

Our decision document template now says it in writing - the decision should not be made on score alone. When we present demonstration scores we ask the committee to compare the numbers to its own gut feel on each vendor, and to write down the reason wherever the two disagree. The numbers get the right finalists into the room. They do not get to vote. If the reason is a deciding capability, the delivery team, the support model, a reference or the price, the decision is sound. If the reason is that one salesperson was more likable, the scorecard just earned its keep.

How to find your deciding capability before the RFP

Every business has one, and the people who do the work know what it is. The job during requirements is to get it out of them before the vendors arrive.

Ask every function the same question - what is the one thing that, if the new system cannot do it the way we need, means we walk away? Finance will say the close. Operations will name the thing that actually runs the business.
Look at where the spreadsheets are. The deciding capability is almost always the process that left the current system years ago and lives in a workbook someone guards.
Look at what the customer touches. The configurator, the proof of delivery, the chargeback, the certificate of analysis. Anything the customer sees is a candidate.
Script it as a must-pass scenario with your data, and run it in every demonstration in the same order. A must-pass is not scored one to five. It is passed or it is not.
Weight it. In one selection a function that had told us it had no big need was carrying 21 percent of the scorecard weight until we noticed. Set the weights by what decides the business, not by headcount in the room, and use them to compare the vendors that pass. A high weighted score does not turn a failed must-pass into a pass.
Put it in the RFP as a scenario, not a line item. "Supports lot traceability" draws a yes from everyone. "Trace this component lot from receipt through three assemblies to the customer and back in under five minutes" draws a plan, an add-on or a withdrawal, and all three are useful answers.

Our note on how requirements shape the RFP and the demo covers the mechanics of turning that one scenario into the workbook, the RFP and the script.

What this means for a selection

A three-hundred-line workbook is still worth writing, because the 299 other lines are what the implementation is built from. But the selection is decided by the one. Find it first and the vendor count, the demonstration script and the scorecard all get simpler, because you know what you are looking for before anyone shows you a dashboard.

If you can name your one requirement, or need help finding it, talk to John about your ERP program.

Frequently asked questions

What requirement usually decides an ERP selection?

In our selections it has been an operational capability - a customer-facing configurator, truck inventory, chargebacks and landed cost, lot traceability, outside processing or weight. It has never been finance. It is usually the process closest to the customer, and it has never been the general ledger.

Should the highest-scoring vendor win?

Not automatically. In two of our selections it did not - the strongest written response in one, the top-ranked partner in the other - and in a third the scores could not separate the finalists. The scorecard's job is to get the right finalists into the room with the right scenarios. The decision should account for the deciding capability, the delivery team, the support model, references and price, with the reason written down wherever it differs from the score.

How do we test a must-pass requirement in a demo?

With your own data and a scripted scenario run in every demonstration in the same order. A must-pass is passed or failed, not scored, and a vendor that needs an add-on or a workaround to pass should say so in the RFP response before the demo.