MES Proof of Concept

MES Proof of Concept: Make One Production Area Visible

Prove that live production data from your own machines can be trusted — captured automatically, reconciled against what your team counted, and turned into an OEE baseline and a loss Pareto nobody argues with. The result is a working pilot area plus the connection pattern for the rest of the plant.

Build my MES PoC plan Talk to a manufacturing engineer

Typical duration6–12 weeks

Pilot scopeOne line, cell or bounded area — typically 3–10 machines

Primary buyerPlant Manager

Decision at the endPlant rollout architecture, timeline and business case

Is this the problem you need to solve?

Output, downtime and scrap are known the next morning from a paper sheet, not now from the machine.
The OEE number exists but the people who have to act on it do not believe the inputs.
Machine stops are recorded as "breakdown" with no category behind them, so no Pareto is possible.
Every performance question ends in a manual data-collection exercise that takes a week.

Primary buyer: Plant Manager · Production Manager · Operational Excellence Manager · Manufacturing IT · Digital Transformation Manager

What this PoC will prove

Can machine and workstation status be captured live and correctly on your equipment, as it is today?

Do automatically captured good quantity, scrap, cycle and downtime reconcile with what your team counted by hand?

Can OEE and cycle time be calculated on definitions your operations and finance people both accept?

Will operators actually use the workstation flow — log in, report, classify a stop — every shift?

Does the connection pattern used on the pilot line scale to the rest of the plant, or only to these machines?

Recommended pilot scope

One line, cell or clearly bounded production area, typically 3 to 10 machines or workstations.
One or more representative product families, including at least one that changes over often.
Selected operators across the shifts that really run, including nights if they exist.
PLC, IIoT card, camera counting or manual panel data capture, whichever each machine actually allows.
Optionally one controlled ERP work-order loop, against a test environment.

What will be live during the PoC

Live machine and workstation status on a shop-floor screen your team can stand in front of.

Operator login, production reporting, downtime classification and scrap capture at the workstation.

OEE, availability, performance and quality per machine and per shift, on agreed definitions.

Downtime and scrap Pareto with the categories your maintenance and quality people use.

How this PoC runs

Week 1–2

Discovery and decision definitionShop-floor walkthrough of the candidate area, machine and signal survey, agreement on the pilot scope, the KPI definitions and the decision the PoC has to support.Exit gate: Scope, KPI definitions and the machine list are signed off in writing.

Week 2–4

Baseline measurementMeasure the current state the way you measure it today — output, downtime, scrap, reporting effort — so the comparison at the end is against a number both sides agreed on beforehand.Exit gate: Baseline accepted by your production and operations owners.

Week 3–6

Hardware and network installationConnect the pilot machines through PLC drivers, MSF IIoT cards or Smart I/O where no PLC is usable, install workstation panels, and set up users, roles and downtime and scrap code lists.Exit gate: Every pilot machine reports status and counts; installation window closed.

Week 5–10

Controlled live operationYour operators run the area on the system every shift. Counts are reconciled against manual records daily at first, then weekly; classification quality and adoption are tracked, not assumed.Exit gate: Count reconciliation and downtime classification hold at the agreed level for a full production week.

Week 10–12

Rollout decision and business caseResults against the scorecard, loss Pareto, the gap list, the plant-wide connection architecture, the bill of quantities and the ROI model, presented to the people who decide.Exit gate: Go, adjust or stop, with the numbers on the table.

Durations are typical, not guaranteed. What extends a schedule: missing or incomplete data, security and network approvals, hardware lead times, sample collection, installation access, the production schedule, ERP test access, and the time your team needs to review results.

No unplanned shutdown is expected. Any installation window or controlled interruption is agreed with you in advance and scheduled around production.

How success will be measured

How success will be measured
Metric	How it is defined	Where the number comes from	Type
Data completeness	Share of production time in the pilot area with a machine state recorded, excluding agreed non-production calendar time.	MSF platform data	Technical
Automatic capture ratio	Share of good and scrap quantities captured from machine or sensor signals rather than typed in by an operator.	MSF platform data	Technical
Count reconciliation accuracy	Deviation between system quantities and your own manual count for the same shift, measured over an agreed number of shifts.	Agreed baseline measurement	Technical
Downtime classification coverage	Share of recorded stop minutes that carry a real reason code rather than "unclassified".	MSF platform data	Operational
Reporting latency	Time between an event on the machine and it being visible on the dashboard, measured at the 95th percentile.	MSF platform data	Technical
Operator adoption	Share of shifts where the expected logins, reports and stop classifications were completed at the workstation.	MSF platform data	Adoption
Baseline OEE and top losses	Measured OEE for the pilot area on the agreed definition, with the loss categories ranked by lost minutes.	MSF platform data	Operational
Manual reporting effort removed	Hours per week previously spent collecting, typing and reconciling production data that the pilot no longer requires.	Observation and user interview	Financial

Before implementation, MSF and your team agree how each metric is calculated, where the baseline comes from, what data is excluded, and what result supports a rollout decision. This page lists what gets measured; the actual targets belong in the written PoC scope, not in a marketing claim.

What you need to provide

Machine list with PLC brand and model, available backups and who is allowed to touch them.
Network and security rules for the shop floor, plus the person who can approve an exception.
Work orders, routings and BOMs where the ERP loop is in scope; shift calendars in every case.
Your current downtime codes, scrap codes, user and role lists, and the KPI definitions you use today.

Who does what

Meta Smart Factory provides

Discovery workshop and scope facilitation
Solution configuration for the agreed scope
Integration and connection work inside that scope
MSF hardware listed in the proposal
Training for the pilot users
The KPI definitions and validation method
Issue tracking and support during the pilot
The final result report and rollout design
PLC and protocol connection work for the pilot machines, including Smart I/O retrofit where no usable PLC exists.
The plant rollout architecture and bill of quantities derived from what the pilot actually proved.

You provide

A named business owner and a named technical owner
Timely access to users, the line, machines and approved systems
An accurate explanation of the process and the master data
Network, power, mounting and safety access
ERP, PLC and vendor documentation, plus the experts who know them
Representative samples or historical data
Validation that the baseline is fair
Feedback and the acceptance decision
Safe, scheduled access to the pilot machines and their control cabinets.
Manual production records for the same period, so automatic capture can be reconciled against them.

Defined in the written proposal

Panel PCs, tablets, servers and GPU servers
Cameras, lenses, lighting and enclosures
Scanners, printers, RFID readers, meters and sensors
Travel, installation, freight, import duty and local electrical work
Whether hardware is rented or purchased
Whether any PoC fee is credited against a rollout

Commercial terms, hardware ownership, travel, integration scope and any rollout credit are defined in the written PoC proposal. They are not the same for every product, and this page does not promise them.

What you receive at the end

A working MES pilot on your line, with your operators using it.
Machine connection map: what was connected, how, and what each method costs to repeat.
Baseline report and loss Pareto for the pilot area.
User feedback and the gap list — what did not work and why.
Plant rollout architecture, phased timeline and bill of quantities.
ROI model built on the losses actually measured, not on a reference percentage.

Dependencies, exclusions and limits

This PoC depends on

Physical and network access to the pilot machines within the agreed installation window.
Manual records for the baseline period being available and honest.

Not included in this PoC

Plant-wide rollout, second sites and machines outside the agreed pilot list.
ERP customisation on your side, and any production ERP write-back unless explicitly scoped.

What this PoC does not claim

A PoC measures your baseline OEE — it does not promise a specific OEE improvement percentage. Improvement comes from acting on the losses the pilot makes visible, which is a rollout and shop-floor management question, not a software one.

Go, adjust or stop — the decision gate

GoGo: data is trustworthy and the connection pattern scales — proceed to the phased plant rollout in the delivered architecture.

AdjustAdjust: capture works but a machine family, a code list or the operator flow needs rework before scaling — the gap list says exactly which.

StopStop: the area cannot be connected at acceptable cost, or the losses found do not justify a rollout. You keep the baseline analysis either way.

Frequently asked questions

How many machines should the pilot cover?

Enough to be representative, few enough to stay fast — typically 3 to 10. What matters more than the count is the mix: include at least one machine with a modern PLC, one older machine that needs a retrofit, and one manual workstation, because those are the three connection patterns the rollout will have to repeat.

Do we need ERP integration for an MES PoC?

No. Most MES PoCs prove data capture, OEE and the operator flow with no ERP connection at all. If you want the work-order loop proven too, it is scoped explicitly, runs against an ERP test environment, and adds to the duration.

What if a machine has no PLC or the vendor will not give us access?

That is a normal finding, not a blocker. Those machines are connected with MSF IIoT cards or Smart I/O modules reading existing signals — cycle contacts, lamps, counters — or with camera counting. The PoC deliberately includes at least one such machine so the rollout estimate is realistic.

Will you compare the system numbers against ours?

Yes, and it is a scorecard metric rather than an afterthought. Count reconciliation runs daily at the start of the live phase. If system and manual counts disagree, the cause is found before anyone is asked to trust a dashboard.

Request this Proof of Concept

Tell us the scope you have in mind and we will come back with a written PoC plan: what gets connected, what you provide, how success is measured and what the decision at the end looks like.