ERP and MES requirements: what to agree before talking to vendors

System selection often starts with demonstrations. A vendor shows scheduling, traceability and reports while the team imagines the same features in its own factory. The feature list grows, but the central question remains unanswered: which decision should the new system help people make better than they do today?

Before comparing ERP, MES or individual manufacturing modules, agree the process, data and accountability behind that decision. This separates a genuine operating requirement from an attractive function that changes little in daily work.

Start with the decision that is missing today

“We need better production management” leaves a vendor too much room to guess. Useful starting questions are specific. What information is missing when the planner changes a priority? When does the shift manager first see a deviation? Who approves replanning, and where is that decision recorded?

For each need, record the situation, accountable role, required information and expected outcome. If nobody has authority to change a priority, another screen will not close the gap. Settle the accountability first and then decide how the system should support it.

Draw the boundary between ERP, manufacturing operations and equipment

An order begins in a business system, becomes a production job, gains actual data on the shop floor and may receive a machine signal. If each system's role is unclear, the same field starts being maintained in several places.

ISA-95 / IEC 62264 distinguishes business planning from manufacturing operations management and describes the information exchanged between them. A project does not need to reproduce the entire standard. It does need a primary source, owner, change authority and exchange rule for every important object: order, product, operation, equipment and material.

Describe daily exceptions, not only the standard path

Demonstrations almost always show a clean order. The value of a production system is more likely to emerge when something changes: material is missing, a deadline moves, an operation is partially completed, an item is sent for rework or the job moves to another workstation.

Prepare short scenarios with an initiating event, decision authority, required information and desired result. Ask the vendor to show the complete flow, not merely the final report. This reveals the manual work, configuration and integration required. Choose exceptions by frequency and effect rather than by drama.

Assess data quality before migration

An old system may contain plenty of data and still be a poor source. Check whether product codes, operation statuses, equipment names and downtime reasons are consistent. Decide which history is needed, what can remain archived and what should not be migrated.

The European Commission’s Digital Maturity Assessment treats data governance as a distinct area of digitalisation. Buying a feature is not enough if nobody owns master data, corrects errors or resolves disagreements over meaning. Record missing rules as project risks instead of leaving them for migration.

Define an integration as an information contract

“Integrate with ERP” is too broad to be useful. A workable description identifies what is exchanged, which system is authoritative, how often the information changes, what happens after an error and who owns the interface.

The technical protocol does not need to be final before selection. The business rule does. Can a production job be changed on the shop floor, or only in ERP? Does actual consumption return after each operation, at the end of a shift or when the order is closed? Which status is treated as confirmed? These answers shape daily work more than the label attached to the integration.

Write acceptance criteria that can be demonstrated

“The system must be easy to use” cannot be tested. “In one view, the shift manager can see today’s jobs, their priority, status and unapproved deviations” is a scenario that can be demonstrated and accepted.

For every major requirement, identify the user role, starting condition, action, expected result and test data. Distinguish standard functionality, configuration and custom development. This affects upgrades, support and the cost of future change.

Limit the pilot to a real operating flow

A pilot should not be a miniature copy of the entire programme. Choose one flow with a genuine decision, several user roles and at least one common exception. Agree the baseline, what will be observed and who will decide whether the scope can be expanded.

The first stage tests whether the operating model works, the data is dependable and the team can use the system without continuous project support. Only then should the wider scope be refined.

Agree the operation before discussing the screen

If you are considering ERP, MES or manufacturing monitoring, bring one process, its present information flow and a decision the team cannot make reliably today. UAB Nėra-Bus can help test the need, structure the requirements and prepare a consistent basis for vendor evaluation.