The result of an ERP screening is a decision based on a clearer view of operations, not a completed ERP implementation. After screening, management should see how processes, data, systems and responsibilities work today, where risks arise, and which scenarios deserve further work first. Its value is not a list of problems. Its value is the ability to prioritise investments, changes and decisions that still lack an owner or a confirmed direction.
A well-run screening turns an ERP discussion from broad assumptions into a set of reviewable findings. It does not answer only whether a system should be replaced. It helps establish what needs to be addressed before change, what can remain, which integrations carry business risk, and where work depends on an individual, manual effort or unreliable data.
In practice, the result of an ERP screening usually includes several connected outputs:
This package does not replace a project specification, solution selection or an implementation plan. It creates a basis for those steps. Management can therefore distinguish an urgent operational issue from a requirement that appears important only because it has been present in internal discussions for a long time.
ERP process analysis starts with the business flow, not with a module list. It needs to follow how an order, material, service, document or financial entry moves through the organisation. In a manufacturing environment, this may cover planning, procurement, warehousing, production, quality control, shipping, invoicing and accounting close. In other operating models, the emphasis may be on sales, contracts, services, projects or payroll.
A process map does not need to show every click in a current tool. It should show:
Alongside the process map, a system map takes shape. It connects business activities with the current ERP, specialised applications, spreadsheets, documents and communication channels. This view helps management see where one business decision relies on several disconnected sources and where the same data is maintained in multiple places.
This is not simply documentation of the current state. Discussion around the map often reveals the gap between the official process and the actual way of working. The gap may reflect a legitimate business need, but it may also point to a lack of control, unclear responsibility or a system constraint.
Screening needs to separate a system issue from a data issue. A new ERP will not by itself organise item, customer, supplier, bill of materials, work order or chart of accounts master data. It will also not automatically decide who can create a new record, change a status or confirm data as correct.
Data findings commonly address questions such as:
The same approach applies to integrations. It is important to record what is exchanged, by which route, how often, and what happens when a transfer fails. An integration may be a direct application connection, a file exchange, a manual import or an activity performed by one person according to an unwritten rule. Each pattern may be acceptable at a particular scale, but screening should set out its cost, risk and dependency.
It is particularly useful to distinguish an integration required for business continuity from one that would only improve convenience. Without this distinction, a project can expand its scope too early or overlook a connection that matters for accounting, traceability, delivery or management reporting.
A risk list without context can easily become one more document. A more useful finding connects each risk to a process, consequence, owner and possible decision.
Risk may arise from manually re-entering orders, a lack of control over price changes, disconnected inventory balances or reliance on a spreadsheet maintained by one person. A dependency may relate to an external application, a business rule that nobody has formalised, the availability of a key employee or the quality of data from another system.
For every significant item, four questions are useful:
This framework avoids two common extremes: attempting to solve everything in the first wave and postponing issues that could disrupt essential work after a system change.
Screening should identify business scenarios against which the organisation will assess future options. A scenario is not a functional label such as procurement or production. It is a specific business flow with inputs, rules, exceptions and an expected outcome.
For example, a manufacturing organisation may set an order-to-delivery flow as a priority scenario: availability check, material planning, work order creation, consumption recording, due-date change, shipping and financial posting. Another scenario may cover a customer complaint and inventory adjustment. These are not recommendations for every operating model. They illustrate the level of specificity needed for assessment.
Priority can be considered through several criteria:
The final priority is not a mathematical result on its own. It is a management decision that considers strategy, available capacity and acceptable risk. Screening provides the basis for that decision, but it cannot make it in place of management.
An ERP roadmap does not need to begin with dates and a long list of functions. At an early stage, it is more useful to organise work around decisions and dependencies. A possible sequence may look like this:
This type of ERP roadmap shows an order of thinking. It does not promise a fixed implementation plan in advance. Some organisations may confirm the need for a broader ERP project after screening. Others may first improve data, change process ownership, stabilise an integration or address a limited part of the operation. Both outcomes can be reasonable when they follow the findings and clearly defined priorities.
Screening has limits. It does not replace detailed future-process design, system configuration, migration rehearsals, integration development, testing or change management. It also cannot remove disagreement among process owners. It can make disagreement visible, describe its consequences and prepare the ground for a decision.
Sometimes a finding will show a need for further work before the next step. This may involve a more detailed analysis of cost accounting, a master-data quality review, work on specific production rules or discussion with an external system provider. Such a conclusion is not a screening failure. It protects the organisation from entering a project with unresolved assumptions.
The value of screening should therefore be assessed through the quality of questions management can now answer: what are we changing, why, in what order, who takes responsibility, and what still needs confirmation?
After screening, a working session with management and process owners is useful. The purpose is not to revisit every finding. It is to confirm priorities, assign owners to open decisions and establish what moves into the next phase.
For organisations that are still defining this type of work, ERP and process screening can provide a starting point for discussing the appropriate scope. When findings are already available, Talk to the ORKA team for a structured review of processes, data, integrations and possible next steps.