Supply Chain Planning Proof of Concept

Prove a More Reliable Supply and Inventory Plan

Take selected product families and suppliers, load real demand, lead times and inventory policy, and see which shortages the plan catches early, how much stock the service target actually requires, and where the excess is hiding. Scenario-driven, with an agreed back-test method if forecasting is in scope.

Scope my supply chain PoC Talk to a manufacturing engineer

Typical duration6–10 weeks

Pilot scopeSelected product families and suppliers, one plant or a small network

Primary buyerSupply Chain Manager

Decision at the endPlanning policy, cadence and rollout case

Is this the problem you need to solve?

Shortages surface when the line stops, not when the supply plan first showed the risk.
Inventory is high and service is still unreliable, which usually means the stock is in the wrong places.
Expedites and air freight have become a routine cost nobody budgets for.
Supplier constraints — MOQs, order calendars, lead times — live in a buyer’s head, not in a plan.

Primary buyer: Supply Chain Manager · Operations Director · Procurement Manager · Inventory Manager · Production Planning Manager

What this PoC will prove

How much earlier would this plan have detected the shortages you actually had?

What service level is realistically achievable on the current inventory and supplier constraints?

Where is coverage excessive, and where is it thin enough to be the next stoppage?

Which supplier constraints are actually driving the plan, once they are all modelled together?

If forecasting is in scope, does the model beat your current method on a fair back-test?

Recommended pilot scope

Selected product families — enough volume and variety to be representative, not the whole catalogue.
The suppliers that genuinely constrain those families, with their real lead times and MOQs.
One plant, or a limited plant network where transfers matter.
An agreed planning horizon and an agreed service target to plan against.
A back-test window held back from configuration, if forecast quality is part of the question.

What will be live during the PoC

Projected supply, demand and inventory position across the agreed horizon.

Shortage and excess exception lists, with the constraint that caused each one.

Scenario comparison: demand shift, supplier delay, changed safety-stock policy.

Supplier constraint visibility — MOQ, calendar and lead time shown where they bite.

How this PoC runs

Week 1–2

Discovery and decision definitionAgree the product and supplier scope, the service target, the planning cadence and the decision the PoC supports; identify which historical incidents will be used to test detection.Exit gate: Scope, service target and the incident list agreed.

Week 2–4

Site, process and data readinessLoad and review demand history, forecasts, customer orders, supplier lead times, MOQs, order calendars, inventory, safety-stock rules and capacity. Data gaps are reported as findings, not worked around silently.Exit gate: Data is representative enough for the scope; back-test window is held back and untouched.

Week 4–6

ConfigurationConfigure the planning model, inventory policies and exception rules; run the historical incidents to see how early the plan would have raised each one.Exit gate: Model reproduces known history plausibly, including the incidents you remember.

Week 6–9

Parallel run or simulationRun the agreed scenarios and the policy comparisons, and, where forecasting is in scope, the back-test against the held-back window.Exit gate: Scenario and back-test results are complete and reproducible.

Week 9–10

Rollout decision and business casePresent the scenario model, the risk and exception list, the data-quality report, the recommended policies and cadence, the integration design and the rollout case.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
Shortage detection lead time	How many days earlier the plan raises a shortage that actually occurred, compared with when your team found it.	Agreed baseline measurement	Operational
Projected service level	Share of demand the plan expects to satisfy on time, on the agreed horizon and constraints.	MSF platform data	Operational
Inventory coverage	Days of cover per family under the recommended policy versus the current one.	MSF platform data	Financial
Excess and obsolescence exposure	Value of stock projected to exceed the horizon’s demand under each policy.	Your ERP or existing system	Financial
Expedite frequency	Number of expedited or emergency orders in the baseline period that the plan would have flagged in time to avoid.	Agreed baseline measurement	Financial
Forecast error	Only where forecasting is in scope: error on the held-back back-test window against your current method, same measure both sides.	Held-back validation set	Technical
Planning effort	Hours per planning cycle to produce and maintain the plan today versus in the pilot.	Observation and user interview	Operational

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

Demand history, forecasts and open customer orders for the scoped families.
Supplier lead times, MOQs, order calendars and any contractual constraints.
Inventory positions, safety-stock rules, production capacity and transfer rules.
The service targets you are actually measured on, and the incidents you want tested.

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, scenario runs and, where in scope, a documented back-test method.
Policy recommendations tied to the measured trade-off between inventory and service, not to a benchmark.

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
Someone who can confirm which supplier constraints are contractual and which are habit.
Agreement, before the run, on how the back-test window is defined and kept out of configuration.

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 scenario model for the scoped families and suppliers.
Risk and exception list with the constraint behind each entry.
Data-quality report naming what would block a rollout.
Inventory and supplier policy recommendations with their measured trade-offs.
Proposed planning cadence and the integration design to support it.
Rollout business case for the wider product network.

Dependencies, exclusions and limits

This PoC depends on

Representative demand history for the scoped families — a short or heavily disrupted history limits what can be concluded.
Supplier constraints being available as data, not only as buyer knowledge.

Not included in this PoC

Detailed shop-floor scheduling and sequencing, which is the APS PoC.
Supplier onboarding, EDI implementation and contract renegotiation.

What this PoC does not claim

No forecast improvement is promised without a representative history and a back-test method agreed in advance. Where history is short or the period was disrupted, the honest deliverable is a shortage-detection and policy result, not a forecast-accuracy claim.

Go, adjust or stop — the decision gate

GoGo: detection and policy results justify rolling the planning model out to the wider network and cadence.

AdjustAdjust: the model works but master data, supplier constraints or the service target need to be fixed first.

StopStop: the data available cannot support planning at this level yet — the data-quality report becomes the roadmap.

Frequently asked questions

Is this the same as the APS PoC?

No. SCP answers what to buy and hold, and when, across suppliers and horizons. APS answers what to run on which machine in which order this week. They connect, but they are different data, different buyers and different evidence.

Can you prove better forecast accuracy?

Only where a representative history exists and a back-test window is agreed and held back before configuration. Without that, any accuracy number is fitted to the data it was built on, and this program will say so instead of publishing it.

How many product families should be in scope?

Enough to include your different supply behaviours — a long-lead-time imported item, a local short-lead item, a seasonal one — rather than the highest-volume ones only. Breadth of behaviour matters more than volume for what this PoC has to prove.

Do you need our ERP connected?

Not for the PoC. Extracts are enough to build and run the model. The integration design is a deliverable of the PoC, and the connection itself belongs to the rollout or to the ERP Integration PoC.

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.