Test APS Against Your Real Production Plan
Not a Gantt chart demo. MSF APS is loaded with your real orders, routings, setup matrix and capacity constraints, then run in parallel with the way you plan today — including the disruptions that break a plan in practice. Both plans are compared on the same measures.
Test APS with my production dataTalk to a manufacturing engineerIs this the problem you need to solve?
- The schedule lives in a spreadsheet only one person can maintain, and it is out of date by mid-morning.
- A rush order or a machine breakdown means re-planning by hand for the rest of the day.
- Setup and changeover time is lost because sequencing is done by intuition, not by the setup matrix.
- Nobody can answer "can we accept this order for that date?" without a meeting.
Primary buyer: Production Planning Manager · Supply Chain Manager · Operations Director · Plant Manager · ERP Manager
What this PoC will prove
Recommended pilot scope
- One plant or one value stream, with the work centres that actually constrain it.
- A meaningful order horizon — long enough to contain real due-date conflicts, typically several weeks.
- Real routings, operation times, machine alternatives, setup matrix and shift calendars.
- A defined scenario set: normal plan, rush order, machine breakdown, material delay, labour shortage, changed customer priority.
- Your current planner output for the same period, as the comparison baseline.
What will be live during the PoC
How this PoC runs
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
| Metric | How it is defined | Where the number comes from | Type |
|---|---|---|---|
| Planning effort | Planner hours per week to produce and maintain the schedule, measured the same way on both sides. | Observation and user interview | Operational |
| Schedule generation time | Wall-clock time to regenerate a full schedule after an input change, per scenario. | MSF platform data | Technical |
| Projected lateness | Total and average days late across the order horizon, and the number of orders that miss their due date. | MSF platform data | Operational |
| Setup and changeover time | Total sequence-dependent setup minutes in the plan, from your own setup matrix. | MSF platform data | Operational |
| Capacity utilisation and WIP | Planned utilisation of the constraining work centres and the WIP implied by the sequence. | MSF platform data | Operational |
| Plan stability | How many operations move when one disruption is injected — a plan that reshuffles everything is not usable on a shop floor. | MSF platform data | Operational |
| Manual interventions | Number of times the planner had to override the generated schedule to make it executable. | Observation and user interview | Adoption |
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
- Open and historical orders, routings, operation times, work centres and machine alternatives.
- Setup matrix, shift calendars, labour and skill restrictions, tooling and material availability.
- Due dates, priorities and outsourcing rules — including the informal ones planners apply from memory.
- The current planner output for the same period, so there is something honest to compare against.
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
- The configured planning model and every scenario run, reproducible rather than hand-tuned per demo.
- A data-quality report naming which fields would block a rollout and which are merely untidy.
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
- A planner with real authority who will judge whether a generated schedule is executable.
- Honest constraints, including the ones that are not written down anywhere.
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 configured planning model of your plant or value stream.
- Baseline comparison against your current planning method, on agreed measures.
- Results for all six disruption scenarios, with what each cost on both sides.
- Data-quality gap list, ranked by whether it blocks a rollout.
- ERP integration design and planner feedback.
- Rollout recommendation with the scope of the first production release.
Dependencies, exclusions and limits
This PoC depends on
- Planning data that reflects reality — a routing nobody maintains produces a schedule nobody trusts.
- A named planner available for review sessions during the parallel run.
Not included in this PoC
- Machine connection, shop-floor data capture and live feedback — that is the MES PoC.
- Writing the generated schedule back into your ERP in production.
An APS PoC compares plans, not outcomes. It can show that a better schedule exists on your own data; it cannot prove on-time delivery improved until the plan is actually executed, which needs shop-floor feedback and a rollout.
Go, adjust or stop — the decision gate
Frequently asked questions
Do you need to connect our machines for an APS PoC?
No. This program runs entirely on planning data. Machine connection matters for feeding real progress back into the plan, which is the MES PoC — a common second step, but not a prerequisite for proving the scheduling logic.
What if our routings and operation times are wrong?
Then that is the finding, and it is worth knowing before you buy planning software. The readiness step reports data quality explicitly. Where times are unreliable, scenarios are run with ranges so the comparison is not built on a number nobody believes.
Is the comparison fair to our current planner?
It is designed to be. The same order horizon, the same constraints, the same measures, and the planner defines what "executable" means before the run starts. A benchmark the planner does not accept as fair proves nothing to anyone in the room.
Can we test our own scenario instead of the standard six?
Yes. The six are the ones most factories recognise, but the scenario list is agreed in the discovery step — if your real pain is a specific customer’s expedites or a single bottleneck machine, that becomes the scenario.
Related products and PoC programs
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.