Write an MES RFP suppliers can actually price
Write a comparable MES request for proposal using testable production scenarios, explicit cost boundaries and a register of unresolved supplier gaps.
An MES RFP should describe production scenarios, acceptance evidence and commercial boundaries clearly enough for comparable proposals. A long feature checklist alone cannot establish that suppliers understand your workflow or have priced the same work.
Prepare the buyer’s evidence pack
Assemble a process map, representative product families, shift patterns, order volumes, interfaces, device inventory and constraints. Use sanitized examples instead of sending confidential recipes, employee information or customer records to every prospective supplier. Clearly identify what is known, assumed and still subject to discovery.
Define the business problem in a paragraph before listing requirements. A supplier should understand whether the priority is instruction control, traceability, production reporting or a combination. Name the decision owner and expected evaluation process. Do not imply a fixed implementation date when site readiness and interface feasibility have not been assessed. Ask for a plan with dependencies and an explanation of what could change it.
Write requirements that can be tested
Replace “supports genealogy” with a specific scenario: trace a hypothetical finished lot to its consumed material lots, including a split and an approved substitution, then trace forward from one suspect input. Specify the expected evidence without dictating unnecessary interface details.
| Requirement field | Purpose |
|---|---|
| Identifier and owner | Keeps decisions traceable |
| Production scenario | Explains why the capability matters |
| Expected result | Defines observable acceptance |
| Priority | Separates mandatory from preferred |
| Supplier response | Standard, configured, custom, partner, unsupported |
| Evidence reference | Connects the claim to a test or deliverable |
Ask suppliers to distinguish roadmap capabilities from available functions. An unsupported requirement should remain visible, even if a workaround is proposed.
Request a transparent commercial response
Give bidders a common cost structure: software, implementation, interfaces, devices, training, internal prerequisites, recurring operation, optional work and exit. Ask each bidder to identify quantities and assumptions. An empty cost cell should mean “not provided,” not automatically zero.
Require a statement of what triggers a change order. Examples include new transaction types, additional sites, data cleanup and a changed validation scope. Ask whether estimates include testing and correction of defects discovered during acceptance. Clarify payment milestones and the deliverables attached to them. A low headline proposal with unbounded buyer obligations is not directly comparable with a fully scoped delivery plan.
Run the same scenario demonstration
Send a concise test script to shortlisted suppliers. Include a normal order and several exceptions, such as an unavailable material lot, a revision change and a lost connection. Allow suppliers to explain configuration assumptions but distinguish a live configured result from a slide or future promise.
Have operators, quality, IT and OT observe the parts relevant to their responsibilities. Capture what happened, which steps required manual intervention and what evidence was retained. Avoid asking observers for an immediate overall score before discussing unresolved requirements. The team should first agree whether mandatory criteria were demonstrated and what further proof is needed.
Evaluate implementation and support capacity
Ask who will do the work, what knowledge must come from the buyer and how continuity is maintained if an assigned person changes. Request role descriptions and deliverables rather than assuming named résumés establish project quality. Verify references only through appropriate authorized contact; do not publish unverified testimonials.
Describe support needs in operational terms. A night-shift failure might need application triage, interface diagnosis and a production decision by different people. Ask who is available, how escalation works and which response commitments are contractual. Distinguish response from resolution. Request a sample handover pack showing architecture, configuration, backups, monitoring and known limitations without exposing another customer’s confidential material.
Close the decision with a gap register
Keep a register of unsupported functions, unpriced assumptions, security exceptions and buyer prerequisites. Assign each gap an owner, evidence needed and decision date. Do not let a supplier’s aggregate score hide a mandatory unresolved item. A sensible outcome can be a limited paid proof exercise with explicit deliverables and no automatic rollout commitment.
Before award, reconcile the final proposal against the RFP and demonstration notes. Ensure important statements are carried into contractual documents rather than left in presentation slides. Involve procurement and qualified counsel for the agreement. Preserve the evaluation record so future project members can understand why the selected scope and architecture were accepted.
Take this to the working meeting
Before sending the request, have a colleague who did not write it price the scope conceptually: what work would they include, exclude or ask about? Use the questions to remove ambiguity in interfaces, testing and internal prerequisites. The exercise does not establish a market price. It improves the chance that bidders will respond to the same production problem and that missing assumptions will be visible.
FAQ
How many requirements should an RFP contain?
Enough to make the workflow and hard constraints testable. More rows do not automatically produce a better decision.
Should suppliers receive the budget?
That is a procurement choice. Regardless of disclosure, use the same scope and require explicit assumptions so proposals can be normalized.
Can a demo replace a pilot?
A demo can eliminate unsuitable options. A pilot tests the plant’s data, people and operating conditions and may still be necessary.
Continue your decision
- MES cost: build a budget around the work
- Cloud, plant-hosted or hybrid MES?
- MES versus ERP: draw the responsibility boundary
- MES licensing: questions before signing
Use the pilot readiness to document your own inputs. Compare operating models on the comparison page.
Sources and scope
- NIST Smart Manufacturing — Official research context for manufacturing systems. The decision worksheets in this guide are editorial recommendations, not NIST requirements.
Examples are hypothetical and are not measured customer results, supplier quotations, or evidence of professional review. Prepared on October 30, 2026; confirm current requirements with the relevant official body and your responsible specialists.
