MES Requirements: Specification Structure, RFI/RFP & Pitfalls

What MES requirements actually are — and where most specifications go wrong

MES requirements are the functional, technical, organizational, and commercial criteria that a Manufacturing Execution System has to satisfy to fit a specific company's production processes, IT landscape, regulatory obligations, and long-term strategy. They are typically assembled into a formal document — variously called a requirements specification, Pflichtenheft, Lastenheft, or SRS (Software Requirements Specification) — that becomes the contractual and operational foundation for vendor selection (RFI/RFP), implementation planning, and post-go-live acceptance. The document is not bureaucracy. It is the mechanism by which a plant translates its actual operational reality into terms a vendor can bid against and that an implementation team can deliver against.

I have been sitting on both sides of this document for over three decades — first as the automation engineer trying to interpret what customers actually needed, and since 2019 as MES Consultant and project lead at SYMESTIC, guiding customers from initial inquiry through requirements workshops, technical scoping, vendor selection, and go-live. In that time I have read, written, and responded to dozens of MES specifications, from small mid-sized manufacturers' three-page internal notes to multi-plant automotive Tier-1 RFPs running to 300+ pages and 800+ line-item requirements. And the single observation that has held up across every one of those projects is the one that almost no one says out loud: the quality of the requirements specification predicts the outcome of the implementation far more reliably than the quality of the MES product being bought. A mediocre MES installed against a well-structured, clearly prioritized, operationally grounded specification will succeed. A world-class MES installed against a bloated, un-prioritized, integration-underspecified checklist will struggle. I have watched this pattern repeat, and this piece is my attempt to describe the discipline that separates the two outcomes.

The three formal contexts where MES requirements appear

The term "MES requirements" does not describe a single artefact. It shows up in at least three distinct procurement contexts, each with different information goals, different formality levels, and different vendor expectations. Confusing them is one of the most common and most expensive mistakes in MES procurement.

The RFP is where most of the requirements-specification work actually lives, and where most of the failure modes originate. The RFI is often skipped — which is usually a mistake, because the RFI is the cheapest mechanism to calibrate scope and surface fundamental architectural incompatibilities (cloud vs. on-premise, multi-tenant SaaS vs. single-tenant, process-industry-oriented vs. discrete-manufacturing-oriented) before anyone has invested months writing a detailed specification.

The functional-requirements layer — what the MES has to do

Functional requirements describe the production-management capabilities the MES must provide. The German reference framework, VDI 5600 (published in blätter 1–7, with the 2022 update of Blatt 1 defining the current MES task taxonomy), structures these into ten task areas: order management, operational fine-scheduling, resource management, material management, personnel management, data collection and processing, performance analysis, quality management, information management, and energy management. The international reference is ISA-95, whose Part 3 activity model covers four operations areas — production operations, quality operations, maintenance operations, and inventory operations — each broken down into eight activities (definition, resource management, detailed scheduling, dispatching, execution management, data collection, tracking, and performance analysis). These two frameworks cover roughly the same territory from different angles; most serious MES specifications in the German-speaking market reference VDI 5600 explicitly, while specifications written for global or multi-national scope use ISA-95.

The mistake that almost every first-time MES specification makes is to translate the full VDI 5600 or ISA-95 taxonomy into an exhaustive checklist of 300+ individual features, each rated independently against vendor responses. I call this The Feature Checklist Trap: the specification becomes a comprehensive enumeration of every function an MES could theoretically provide, with no meaningful priority, no linkage to actual business use cases, and no way for the vendor to distinguish what matters operationally from what is being asked because it sounded thorough. The checklist is measurable — you can count how many of the 300 items a vendor claims to support — but the measurement is worse than useless, because every vendor checks most boxes, and the real differences are in which functions are supported at what depth, integrated with what, and deliverable within which timeline.

The discipline that produces actually useful functional requirements is a prioritized, use-case-grounded structure organized around the plant's real operational problems:

The strong-requirement format does three things the checklist cannot: it specifies the operational context (what the plant is actually trying to achieve), it specifies measurable acceptance criteria (so "done" can be proven rather than negotiated), and it constrains the vendor's solution space enough to allow meaningful fit/gap assessment but not so much that it prescribes the implementation. The principle I apply in every requirements workshop I run: specify what and why; leave how to the vendor. Customers who specify how — "must use PostgreSQL", "must run on Ubuntu 22.04", "must use webhook-based integration to ERP" — are either accidentally excluding better solutions or specifying constraints they do not actually care about.

The MoSCoW prioritization — or, why the Must-Have Inflation kills procurement

A requirements specification without prioritization is operationally indistinguishable from having no requirements at all, because prioritization is the mechanism by which the buyer communicates what matters when (inevitably) tradeoffs have to be made during implementation. The standard framework for this is MoSCoW — Must have, Should have, Could have, Won't have — and its disciplined application is among the most reliable predictors of project success I have observed.

The failure mode I watch develop in almost every first-draft specification is what I call Must-Have Inflation — the pattern in which every stakeholder's pet requirement ends up marked "Must have" because no one wants to be the person whose concern gets downgraded. I have reviewed specifications in which 93 % of 600+ line items were classified Must-Have, which in operational terms means the specification has no prioritization at all. Vendors reading such a document have no way to propose a pragmatic phased rollout, project managers have no way to make the inevitable scope-vs-timeline tradeoffs during implementation, and the first major project crisis becomes a political fight rather than a management decision, because everyone's requirement is equally Must-Have. The discipline that prevents this is a single named owner for the requirements-prioritization decision — typically the sponsoring COO or plant manager — with explicit authority to overrule stakeholder preferences when the Must-Have share exceeds the target of roughly 60 %. Without that ownership, the specification becomes an accumulated wishlist rather than an operational plan.

Technical and integration requirements — the 5 % of the document that drives 50 % of the cost

The single most consistently undervalued section of every MES specification I have ever reviewed is the technical and integration-requirements chapter. It typically runs 3–8 pages in a 60-page specification — roughly 5–10 % of the document volume — and it drives somewhere between 40 % and 60 % of the actual implementation effort and cost. I call this pattern Integration Underspecification, and it is the single most reliable predictor of implementation overruns I have been able to identify across the projects I have worked on.

The reason integration drives so much cost and is so consistently underspecified is structural: the functional-requirements team (production managers, quality managers, plant controllers) does not see integration — it sees features. The technical-requirements team (IT, automation engineering) sees integration — but is usually not the team writing the specification. The specification inherits the blind spots of its authors, and the integration gap appears first during implementation, when every underspecified interface turns into an unbudgeted engineering project.

A properly scoped technical-and-integration-requirements section covers at least the following dimensions:

Every one of these dimensions has to appear in the specification with the same discipline as functional requirements — measurable, prioritized per MoSCoW, grounded in the actual IT/OT landscape. A plant that specifies "integrate with ERP" without specifying which ERP, which transactions, and what volume, has done zero integration specification. A plant that specifies "OPC UA compatible" without auditing its actual installed base of PLCs has ignored the brownfield problem entirely, which means discovery of fifty 1990s-era PLCs without OPC UA happens during implementation rather than during specification.

From more than three decades connecting machines to higher-level systems, and six years leading MES projects at SYMESTIC from inquiry to go-live: the single most consistent pattern I have observed across dozens of MES procurement projects is the relationship between how the brownfield connectivity section of the specification was written and how the implementation actually went. I have seen specifications in which the connectivity section consisted of a single sentence — "system must connect to existing machines" — and I have seen specifications in which there was a machine-by-machine inventory, per-machine PLC type and firmware version, per-machine available signals, per-machine acceptable retrofit approach, and per-machine named constraint (for example, "no PLC download during production weeks"). The implementation outcomes are not comparable. The first project — the single-sentence connectivity spec — spent the first four months of implementation doing the connectivity audit that should have been done during specification, discovered that a third of the machines had no meaningful data interface at all, and ended up adding nine months and €200,000 of unbudgeted engineering effort to get to an OEE measurement that was usable. The second project — the per-machine inventory — went live on the originally planned schedule because every connectivity decision had been made in advance, every gateway had been selected, and every no-PLC-intervention constraint was known before the first contractor arrived on site. The difference was not the MES product; both projects used capable platforms. The difference was the specification. Two specific patterns I now argue for in every specification workshop I run: first, the brownfield connectivity inventory must be done during the RFP phase, not after contract signature, because the results materially change which MES product is the right choice (some platforms handle legacy PLCs gracefully via retrofit gateways; others require greenfield-grade OPC UA servers that simply do not exist on a 1995 Siemens S5). Second, the connectivity section must be owned by someone who has actually connected a PLC to a higher-level system in the last 24 months — not by an IT architect who has read about OPC UA but never worked with a serial protocol or a proprietary Siemens PROFIBUS fragment. The specification authors who get this right are almost always people who grew up in the automation-engineering tradition, and who understand that the 1995 Siemens S5 in the heat-treatment line is not going to be replaced because the MES RFP says it should be replaced — it is going to keep running for another ten years, and the MES has to connect to it as it is. Writing a specification that assumes the machine park will be modernized to match the MES is writing a specification that will be overrun by reality within 60 days of implementation start. The third pattern, and the one I have seen most recently in 2025–2026 specifications, is the emerging weight of NIS2 and the upcoming Cyber Resilience Act obligations, which are turning cybersecurity from a side-issue in the technical-requirements section into a first-class procurement criterion. Plants designated as essential or important entities under NIS2 (the designation is broader than most plant managers initially assume — it covers significant parts of manufacturing, food production, and automotive supply) have direct supply-chain-security obligations that flow down to every software vendor they purchase from, including MES vendors. Specifications written in 2024 or earlier frequently did not include NIS2 provisions at all; specifications written from 2025 onward need to, or the compliance gap will appear during the vendor-approval step rather than during requirements.

The structure of a serious MES requirements specification

A requirements document that has been disciplined through the principles above typically has the following structure, in roughly the following proportions:

Specifications that run materially longer than 60–80 pages in total usually suffer from one of two failure modes: either they have drifted into prescribing implementation details that should belong to the vendor, or they have fallen into the Feature Checklist Trap. Specifications materially shorter than 30 pages usually suffer from Integration Underspecification. The right length is whatever it takes to cover the nine sections above with disciplined prioritization; in my experience that lands in the 40–60-page range for a typical mid-market multi-plant MES programme.

Fit/Gap assessment — the mechanism the specification exists to enable

The point of a requirements specification is to make possible a structured fit/gap assessment of vendor responses. Fit/Gap is the comparison of each requirement against what each vendor proposes, classified per requirement into one of four states: fully supported as standard (green), supported with configuration (yellow), supported with customization (orange), or not supported (red). A disciplined fit/gap for a 150-requirement specification produces a clear quantitative picture of which vendor fits which part of the scope at what cost, and gives the procurement team a defensible basis for vendor selection.

The fit/gap exercise only works if the requirements are properly prioritized. Must-Have requirements that fall in the red or orange column are deal-breakers or major-cost items; Should-Have requirements in red are acceptable with workarounds; Could-Have requirements in any color are essentially cost-comparison factors. A specification without MoSCoW prioritization cannot be fit/gap-analysed meaningfully, because every red cell becomes equally alarming, which is to say none of them do. The specification structure and the prioritization discipline are mutually reinforcing: neither works without the other.

Cybersecurity requirements in 2026 — NIS2, Cyber Resilience Act, and the new procurement reality

The regulatory landscape around cybersecurity for MES procurement has changed materially in the last 18 months, and requirements specifications drafted before October 2024 typically do not reflect the current reality. Three specific obligations now shape MES procurement for any manufacturer selling into or operating within the EU:

1. NIS2 Directive. The EU's Network and Information Security Directive 2 came into national-law effect from 17 October 2024 (though implementation timelines vary across member states). It designates manufacturers across broad sectors — including significant parts of manufacturing, food production, chemicals, and automotive supply — as either "essential" or "important" entities, with direct cybersecurity obligations that flow down to all software vendors in the supply chain. For MES procurement, this translates into specific requirements on vendor incident-reporting capabilities, supply-chain-security attestations, and ongoing security-governance evidence.
2. Cyber Resilience Act (CRA). Enters into force progressively through 2027, imposing mandatory cybersecurity requirements on products with digital elements sold into the EU — which includes MES platforms. For buyers, this means vendor statements of CRA compliance will become a standard RFP requirement from 2026 onward.
3. ISO 27001 certification. Long-standing requirement in enterprise procurement but now effectively mandatory for MES vendors selling to NIS2-regulated entities, because the certification provides the documented control framework that NIS2 supply-chain obligations reference.

Specifications drafted in 2026 should include these three as first-class requirements in the technical-and-integration section, with evidence requirements (named certifications, copies of attestations, incident-response-process documentation) rather than self-attestation. Vendors that cannot produce the evidence will not pass procurement screening at NIS2-regulated customers, regardless of functional fit.

Common MES specification failures — a field taxonomy

Across the MES specifications I have reviewed in the last six years, the failure modes cluster into a consistent taxonomy. Recognizing them early is much cheaper than discovering them during implementation:

How this fits into the SYMESTIC platform

SYMESTIC is the cloud-native MES platform that I and the SYMESTIC implementation team deploy across automotive, metal-processing, food, building, and general manufacturing customers. The platform is designed to satisfy the MES requirements landscape I have described — VDI 5600 and ISA-95 functional coverage, API-first integration via REST and OPC UA, native multi-site rollout with shared-template governance, and ISO 27001-certified operation with documented NIS2-alignment evidence. The implementation approach follows the requirements-discipline principles I argue for in every specification workshop I run: per-machine brownfield connectivity inventory during the pre-contract phase, measurable acceptance criteria per Must-Have requirement, and phased-rollout scoping with named go-live dates. For plants writing their first MES specification, I typically recommend a 4–6-week requirements workshop approach rather than a cold RFP; the workshop produces a better specification in less time than a cold-authored document because the vendor's engineering team (in this case, mine) participates in the brownfield and integration scoping before the specification is finalized. For plants that already have a finished specification, SYMESTIC responds to the standard RFP format and produces fit/gap documentation per requirement. Relevant product modules and supporting glossary material: production metrics, production control, production planning, alarms, process data; background on specific capabilities via process documentation, E2E traceability, change control, shop floor control, predictive quality, alarm management, industrial data historian, recipe management, and composable MES for the architectural framework that underlies how SYMESTIC satisfies the full VDI 5600 scope.

FAQ

What are MES requirements?
The functional, technical, organizational, and commercial criteria an MES must satisfy to fit a specific manufacturer's production processes, IT landscape, regulatory obligations, and strategy. They are typically assembled into a formal requirements specification (Pflichtenheft, Lastenheft, or SRS) that becomes the contractual and operational foundation for vendor selection, implementation planning, and acceptance.

What is the difference between an RFI, RFP, and RFQ?
An RFI (Request for Information) is an early-stage market scan used to build a vendor shortlist. An RFP (Request for Proposal) is a detailed specification against which shortlisted vendors submit binding proposals. An RFQ (Request for Quotation) is a narrow commercial exercise when the technical solution is already decided and only pricing is being negotiated. The RFP is where most requirements-specification work lives.

What reference frameworks structure MES functional requirements?
In the German-speaking market, VDI 5600 (blätter 1–7) is the definitive reference, structuring MES functions into ten task areas. Internationally, ISA-95 Part 3 defines the activity model for Level 3 operations management across production, quality, maintenance, and inventory. For process industries, NAMUR NE 159 provides a process-specific MES requirements profile. Most serious MES specifications reference one or more of these explicitly.

What is MoSCoW prioritization?
MoSCoW stands for Must-have, Should-have, Could-have, Won't-have. Must-have requirements are go-live-blocking; Should-have are important but not go-live-blocking; Could-have are desirable if low-cost; Won't-have are explicitly out of scope for this release. A healthy distribution puts roughly 60 % of requirements in Must-have, 20 % in Should-have, 15 % in Could-have, and 5 % in Won't-have. More than 80 % Must-have is Must-Have Inflation and means the specification is effectively unprioritized.

What is The Feature Checklist Trap?
The failure mode in which an MES specification becomes an exhaustive 300+ item enumeration of every conceivable function, with no linkage to actual business use cases, no prioritization, and no acceptance criteria. Vendors check most boxes, the specification cannot distinguish meaningful fit, and the checklist becomes worse than useless as a selection basis. The corrective discipline is to rewrite the specification around 15–25 concrete operational use cases and derive requirements from them.

What is Integration Underspecification?
The pattern in which the technical-and-integration-requirements section of an MES specification runs 3–8 pages (5–10 % of document volume) but drives 40–60 % of actual implementation effort and cost. Root cause: functional-requirements authors don't see integration; technical-requirements authors are often not the team writing the specification. Corrective discipline: expand the technical section to 10–20 pages with per-machine brownfield connectivity inventory, explicit ERP-integration scope, and first-class cybersecurity-and-compliance treatment.

How long should an MES requirements specification be?
Typically 40–60 pages for a mid-market multi-plant MES programme. Specifications materially longer than 80 pages usually suffer from prescribed implementation or the Feature Checklist Trap. Specifications materially shorter than 30 pages usually suffer from Integration Underspecification. The right length is whatever it takes to cover the nine standard sections (executive summary, scope, operational context, functional, technical/integration, non-functional, implementation, commercial, response template) with disciplined prioritization.

What cybersecurity requirements belong in an MES specification in 2026?
Three regulatory regimes now materially shape MES procurement: NIS2 Directive (EU, effective October 2024) with supply-chain-security obligations for essential/important entities; Cyber Resilience Act (progressive rollout through 2027) mandating cybersecurity requirements for products with digital elements sold into the EU; and ISO 27001 certification as an effectively mandatory vendor requirement for NIS2-regulated customers. Specifications drafted before October 2024 typically do not address these and need to be updated.

Should each plant have its own MES specification?
No. The working pattern is a shared core specification (typically 80–90 % of requirements) with per-plant annexes for genuinely local specifics (typically 10–20 %). A fully separate specification per plant produces vendor and implementation fragmentation; a single specification with no local flexibility produces rollout friction. The balance is a core-and-annex structure with named governance over what belongs in core vs. annex.

Is specifying functional requirements or integration requirements more important?
In practice, integration requirements and the brownfield connectivity inventory are more predictive of implementation success than functional-requirements detail. Most modern MES platforms cover the bulk of VDI 5600 / ISA-95 functionality adequately for most use cases; the differences that matter operationally are in how cleanly the MES integrates with the specific ERP, with the specific machine park, and with the specific regulatory environment. Plants that under-specify integration end up with MES functionality they cannot actually use because the data it needs doesn't flow into it.

Related: MES: definition, functions & benefits · OEE: definition, calculation & practice · MES software compared · OEE software · Composable MES (architecture frame) · Process documentation (ISA-95 baseline) · E2E traceability · Change control · Recipe management · Alarm management · Shop floor control · Predictive quality · Industrial data historian · Schedule adherence · On-Time Delivery · Rolled Throughput Yield · Scrap rate vs. rework rate · A3 problem solving · MDE (machine data acquisition) · BDE (production data acquisition) · Production metrics · Production control · Production planning · Alarms · Process data · Automotive · Metal processing · Food & beverage · For COOs & plant managers · For operational excellence. External references: VDI 5600 Blatt 1 (German MES functional standard) · ISA-95 standard committee (international activity model) · NAMUR (process-industry MES working groups including NE 159) · NIS2 Directive portal (European Commission) · ISO/IEC 27001 (information security management).

About the author

Martin Brandel

MES Consultant and Project Manager at SYMESTIC since 2019. Dipl.-Ing. Nachrichtentechnik. Connecting machines to higher-level systems since 1991 — from Simatic S5 with COROS visualization, through painting-line commissioning in Eastern Europe and China at Hermos AG, through eleven years building the automation department at SYMESTIC (formerly ODEVIS GmbH) including the software standard for process-industry installations in beverage and wood processing, to current MES implementations connecting mixed brownfield/greenfield machine parks via OPC UA, MQTT, and digital I/O gateways. Guides customers end-to-end from initial inquiry through requirements workshops, vendor-selection support, technical scoping, brownfield connectivity inventory, and go-live. Expertise: machine data acquisition (MDE), production data acquisition (BDE), machine connectivity, PLC programming (Simatic S5, S7, TIA Portal), retrofit, OPC UA, IoT-gateway integration, brownfield connectivity, process control systems, material-flow control, industrial automation, MES project management, process engineering, CE conformity. · LinkedIn