Maintenance Proof of Concept

Make Critical Maintenance Work Measurable Before Scaling

Start with the workflow that is failing today — notification, response, execution, documentation — on your critical assets. Condition monitoring is added only where sensors and enough observation time genuinely exist, and failure prediction is only claimed where labelled failure history does.

Assess my critical assets Talk to a manufacturing engineer

Typical duration6–12 weeks

Pilot scopeSelected critical assets and one maintenance team

Primary buyerMaintenance Manager

Decision at the endRollout plan and, where justified, a monitoring roadmap

Is this the problem you need to solve?

Breakdown handling runs on phone calls and a whiteboard, so response time is unknown.
Preventive plans exist on paper and slip quietly whenever production is busy.
The same failure repeats and nobody can prove it, because the history is in notebooks.
Spare parts are found missing at the moment the technician needs them.

Primary buyer: Maintenance Manager · Reliability Manager · Plant Manager · Engineering Manager · Operational Excellence Manager

What this PoC will prove

Can notification, response, execution and documentation run digitally on every shift, including nights?

What is the real MTTR and response time once they are measured rather than estimated?

How much of the team’s work is emergency work, and how much preventive work is actually overdue?

Do technicians complete the documentation, or does adoption collapse in week three?

Where sensors are in scope: does the alarm arrive early enough to be worth acting on?

Recommended pilot scope

Selected critical assets — the ones whose failure actually stops production.
One maintenance team, with the failure and notification workflow they use today.
Preventive plans, work orders and, where relevant, the spare parts behind them.
Asset hierarchy, criticality and the failure history that exists.
Sensors for agreed condition-monitoring use cases only, never as a blanket assumption.

What will be live during the PoC

Digital failure notification with response, assignment and escalation.

Preventive plans generating work orders on schedule and meter readings.

Work-order execution with documentation, parts used and time booked.

Baseline maintenance dashboard: emergency ratio, overdue work, repeat failures.

How this PoC runs

Week 1–2

Discovery and decision definitionReview the asset hierarchy and criticality, map the current notification and execution workflow, and agree which assets and which KPI definitions the PoC will use.Exit gate: Asset scope, workflow and KPI definitions agreed.

Week 2–4

Baseline measurementEstablish the current MTTR, response time, emergency ratio and preventive compliance from whatever records exist, and state honestly where the baseline is an estimate rather than a measurement.Exit gate: Baseline agreed, with its uncertainty written down.

Week 3–6

ConfigurationConfigure assets, plans, work-order types, roles and mobile execution; where condition monitoring is in scope, install and validate the agreed sensors.Exit gate: Technicians complete a real work order end to end on their own devices.

Week 6–11

Controlled live operationThe team runs maintenance on the system. Response, execution and documentation completeness are tracked; sensor data accumulates towards a usable observation window.Exit gate: A full maintenance cycle including at least one real breakdown has been handled in the system.

Week 11–12

Rollout decision and business casePresent the measured baseline versus pilot period, the criticality and gap report, the sensor findings where included, and the rollout plan.Exit gate: Go, adjust or stop.

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
Notification-to-response time	Time from a failure being reported to a technician accepting it, measured on the pilot assets.	MSF platform data	Operational
MTTR	Mean time to repair for the pilot assets during the live period, on the definition agreed in discovery.	MSF platform data	Operational
MTBF baseline	Mean time between failures established for the pilot assets — a baseline, not a target, over this observation window.	Agreed baseline measurement	Operational
Emergency work ratio	Share of maintenance hours spent on unplanned work versus planned work.	MSF platform data	Operational
Preventive compliance	Share of due preventive work completed within its window, and the overdue backlog at period end.	MSF platform data	Operational
Documentation completeness	Share of work orders closed with cause, action and parts recorded rather than closed empty.	MSF platform data	Adoption
Repeat failures	Failures on the same asset and cause within the period — the evidence a fix did not hold.	MSF platform data	Operational
Alarm lead time	Only where sensors are in scope: time between a condition alarm and the event it warned about, with false alarms counted separately.	Sensor, meter or device data	Technical

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

Asset hierarchy, criticality ranking and the failure history that exists, in whatever form it exists.
Current maintenance plans, meter readings and spare-parts data where relevant.
Technician roles, shift coverage and the devices they will realistically use.
Access and safety rules for any sensor installation in scope.

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
Configured asset structure, preventive plans and mobile work-order execution for the pilot team.
An honest classification of which condition-monitoring use cases the available data can actually support.

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
Technicians who will use the system during real breakdowns, not only in training.
Whatever failure history exists — even incomplete, it decides what can be claimed.

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 live maintenance workflow used by your team on real breakdowns.
Configured asset hierarchy, criticality and preventive plans.
Baseline versus pilot dashboard on the agreed KPI definitions.
Sensor findings and a data-baseline assessment where condition monitoring was in scope.
Criticality and gap report — what the pilot could not cover and why.
Rollout plan for the remaining assets and teams.

Dependencies, exclusions and limits

This PoC depends on

Technician availability during the live period, including on the shifts that actually break down.
For condition monitoring: safe sensor mounting points and enough observation time to mean anything.

Not included in this PoC

Plant-wide asset data cleansing and historical record digitisation.
Spare-parts procurement and warehouse implementation, which is the WMS PoC.

What this PoC does not claim

Where labelled failure history or sufficient observation data does not exist, this PoC is positioned as condition monitoring, anomaly detection and data-baseline creation — not failure prediction. A predictive claim without failures to learn from is not a claim, it is a hope.

Go, adjust or stop — the decision gate

GoGo: the workflow holds under real conditions and the measured gaps justify rollout to the remaining assets.

AdjustAdjust: adoption or asset data needs work first; the gap report is the work package.

StopStop: the constraint is maintenance capacity or spare-parts availability, which a system makes visible but cannot fix.

Frequently asked questions

Can you prove predictive maintenance in a PoC?

Only where there is enough labelled failure history and a long enough observation window, and both are checked before anything is promised. Where they are missing, the honest program is condition monitoring plus building the data baseline that makes prediction possible later.

Do we need sensors?

Not for the workflow half of this PoC, which is where most of the measurable value sits. Sensors are added for specific condition-monitoring use cases agreed in discovery, on specific assets, for a specific question.

Our failure history is in notebooks. Is that a blocker?

No, and it is very common. It limits what can be claimed about prediction, not what can be measured about response, compliance and repeat failures. The PoC starts the structured history that a later predictive step would need.

How do you measure MTTR fairly against our current number?

By agreeing the definition in discovery, including what counts as start, what counts as stop, and which stoppages are excluded. Two organisations can measure MTTR three different ways; the comparison is only honest if both sides use the same one.

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.