Build a useful ERP shortlist

Write the non-negotiables

Identify requirements that genuinely disqualify a product: a production process, entity structure, local output or operational constraint. Avoid declaring every requested improvement mandatory. Give each requirement an owner and a test so the team can distinguish an evidence gap from a confirmed limitation.

Filter by operating shape

Use business size, process type and deployment constraints to form an initial set. Directory categories are discovery tags, not evidence that every capability is included. Read the product profile and source material, then ask the vendor about the edition and implementation partner that would deliver your scope.

Use priorities openly

If scoring helps organize the decision, publish weights before demos and record the supporting evidence. Leave unknown items unknown. Do not assign a zero to a vendor simply because public documentation is thin, or a perfect score to a sponsor. Keep commercial terms and process fit visible as separate dimensions.

Make the next step a controlled pilot

Invite the remaining candidates to demonstrate the same connected scenario. List unresolved items, assign an owner and agree a resolution date. A useful shortlist is a manageable set of testable options. Our finder suggests products from directory tags and gives no commercial boost; it is not a final suitability assessment.

Define the decision that the shortlist must enable

A shortlist is a temporary set of plausible delivery options, not a public ranking of the market. State what the next stage must establish: perhaps a supported production method, a local finance output or the ability to replace an aging warehouse interface. Limit discovery to enough options to expose meaningful architectural and delivery differences. A product with extensive functionality can be unsuitable if the proposed team or operating model does not fit. Conversely, limited public detail is a reason to ask a focused question rather than invent a limitation. Keep the shortlist tied to a decision date and a manageable evidence plan so research does not become an indefinite substitute for testing.

Build a requirement hierarchy with consequences

Separate disqualifiers, important differentiators and preferences. For each disqualifier, describe the operational consequence of failure and identify a person who can verify it. 'Manufacturing support' is too broad; 'retain component-lot genealogy through outsourced processing and split shipments' is testable. A preference such as a familiar navigation pattern should not outweigh a critical stock-control gap merely because it is easy to score. Also record acceptable alternatives. An integrated external service might meet a requirement if responsibility and recovery are clear. Set these rules before speaking to vendors, then change them only through a recorded business decision applied consistently to every candidate.

Use evidence states without false precision

Track documented, demonstrated, pilot-verified, proposed and unresolved separately. Add the product release, deployment, module and proposed implementation partner. A vendor's documentation can establish a described mechanism; it cannot establish how well your users will operate the configuration. Microsoft's engineering change overview, for example, describes versions and readiness controls in one product. Use that specificity as a model for evidence requests rather than treating a general manufacturing tag as equivalent. If public material is missing, ask for a demonstration or written answer. Do not turn unknown into either a confirmed failure or an assumed pass. The decision record should preserve the difference.

Compare alternatives as operating packages

Request a named configuration for each candidate: core application, required modules, extensions, integrations, hosting and delivery organization. Capture system-of-record ownership and recurring administration. Two proposals using the same ERP may have materially different integration and localization responsibilities. Compare the same scope and time horizon in the cost model. Ask who handles a failed warehouse message and who maintains a custom report after updates. A useful package description is short enough for operations and finance to inspect together. It makes a complex suite and a simpler application with partner components comparable without assuming that either architecture is automatically preferable.

Use a structured elimination meeting

Illustrative example: four candidates enter discovery; one cannot demonstrate a launch-critical traceability flow, one needs an uncommitted future release, and two offer currently testable approaches. These are fictional findings, not directory ratings. Record why the first two leave the active set, the evidence and whether later information could change that decision. Invite the remaining two to the same pilot with agreed acceptance criteria. Avoid eliminating an option because one evaluator disliked a demonstration style while another evaluator never saw the relevant process. Ask each evaluator to distinguish observed behavior, inference and unanswered question before the group decides.

End with conditions, not a ceremonial winner

Identify what remains unresolved before a contract or implementation commitment. Assign each condition an owner, evidence required and due date. Typical conditions concern a localization output, complex migration or a plant-device interface. If weighting is used, show how a change in the most important assumptions affects the outcome. A narrow difference in a total score should not conceal a major unresolved dependency. Preserve the rejected options and reasons so the team can revisit them if the preferred package changes. The deliverable is a compact decision pack containing requirements, evidence states, proposed operating packages, common costs and pilot conditions. It helps the next stage proceed with clarity rather than creating an unsupported claim that one ERP is universally best.

Common questions

Continue your research

The following profiles provide a starting point for checking vendor-described scope. Inclusion is not a ranking or a statement that every requirement is supported.