ERP screening and an ERP demonstration are not interchangeable steps. Screening starts with an organisation's processes, data, responsibilities and problems. A demonstration tests whether a specific solution can address already defined priorities. When the demonstration comes first, the team may compare a supplier's persuasive presentation rather than the system's real fit.
When preparing for ERP supplier selection, it is useful to separate two fundamental questions:
The first question belongs to screening. Its subject is not the screens of a particular product, but the way the organisation operates. Screening can cover the order flow, production planning, inventory records, procurement, cost calculation, accounting postings, reporting, user roles and integrations. The important task is to identify where manual entry occurs, where traceability is lost, which data is unreliable and who makes decisions based on that data.
The second question belongs to the demonstration. The supplier then shows specific functions, configuration, user-role workflows, possible extensions and an implementation approach. A useful ERP demonstration is not a general tour of modules. It responds to pre-prepared business scenarios.
ERP and process screening can help structure this first step before discussions turn to an individual solution.
A demonstration without a clear framework can easily create the wrong impression. A supplier will naturally show the workflow that is cleanest, most familiar or most attractive for a presentation. The organisation may then fail to raise the questions carrying the greatest operational risk: production exceptions, inventory corrections, procurement approvals, returns, period close, data transfer or responsibility for master data.
Screening is not about selecting functionality for its own sake. It creates a shared description of the problem and the decision criteria. Without it, different team members may ask suppliers for different things. Finance may seek a faster close, production better control of work orders, sales a reliable delivery status, and management a clearer overview. All of these needs are valid, but their importance, links and constraints should be expressed before offers are compared.
A sound sequence is therefore:
This sequence does not remove the need for expert judgement. It reduces the risk of comparing presentations that are not comparable.
The most useful input for a demonstration is a small set of everyday-work scenarios. Each scenario should have a triggering event, required data, participating roles, an expected outcome and a known exception. There is no need to show the entire organisation in one session. A few well-chosen scenarios reveal more than a long list of features.
An example for a manufacturing organisation could include this sequence:
A supplier does not need to show a fully completed configuration at every point. However, it should clearly distinguish a standard capability, configuration, development, work outside the system and assumptions about input-data quality. This distinction supports a realistic assessment of implementation scope.
For organisations with different business areas, it is useful to check how ERP connects with relevant business functions. An overview of Business modules connected to ERP can help build an area list, but it does not replace the organisation's own scenarios.
Questions are more valuable when they follow the workflow rather than a module catalogue. The following sequence keeps the discussion relevant.
Who creates the record, which source provides the data and who may change it? How does the system distinguish master data from data specific to a transaction? This question often reveals whether the new solution will reduce manual work or simply move it elsewhere.
How does the system guide a user from the triggering event to the result? Which controls, approvals and statuses are mandatory? Ask to see the work of the person who actually performs the task, not only a report after the transaction has been completed.
What happens when material is missing, a deadline changes, a customer changes an order, a quantity differs or a document must be reversed? Exceptions often determine whether a system is accepted in practice. It is worth asking who may make a correction, how it is recorded and what effect it has on connected processes.
Which data enters from other systems, when is it transferred and how are errors identified? The demonstration should show the business purpose of an integration, not only the technical possibility of connecting systems. Pay particular attention to data ownership and the workflow when a transfer fails.
Which person sees which indicator, which records produce the report and how current is the data? It is useful to connect every important report to a specific decision. This avoids collecting reports without a clear operational purpose.
What is not covered by the approach shown? What requires configuration, additional development, process change, data cleansing or the involvement of another party? A direct answer about solution boundaries is more useful than a broad promise of adaptability.
ERP supplier selection is not limited to the number of capabilities shown. During the demonstration, also record the quality of answers to open questions, understanding of the business context, clarity of assumptions and the partner's willingness to distinguish fact from an estimate.
It is useful to agree on one shared record for all suppliers. For each scenario, note:
Build assessment on evidence from the demonstrated scenario rather than on general impression. Still, a demonstration has natural limits. It cannot on its own confirm the quality of a future implementation, the completeness of data migration or system behaviour in every real situation. Those conclusions require a clearer scope, responsibilities, a test plan and further work with the selected partner.
A smaller organisation with simpler processes may prepare scenarios quickly through internal work. Complex manufacturing, multiple locations, many integrations or unreliable data increase the value of structured screening. Screening is not a project specification for every click. Its purpose is to establish priorities clearly enough for a demonstration and offer to be relevant.
If a demonstration has already taken place, screening can still be useful. The team can separate what it saw from what it actually needs to verify, then prepare additional scenarios and the same questions for remaining suppliers.
Before the next ERP demonstration, bring together process owners, choose several real situations and agree what an acceptable answer would look like for each one. For support in structuring that starting framework, talk to the ORKA team .