Forecasting and prediction for manufacturing, specified by the lead time the decision needs and landed in the planning cycle rather than delivered to a dashboard.
A bearing failure predicted four hours ahead is interesting. If the spare has a two-week lead time and the maintenance slot is next Thursday, it is not actionable, and the plant will have the failure anyway with a record that says it was foreseen.
This table is the feasibility and value conversation in one place. If the required lead time exceeds what the data can support, or the person who would act cannot act in that window, the prediction has no value regardless of its accuracy.
Downtime that was not predicted
Or was, and nothing could be done in time.
Forecasts nobody compares to the naive one
So nobody can say whether they add value.
Inventory high and shortages frequent
Which is a bias problem rather than an accuracy one.
Maintenance that is reactive by habit
With capacity planned around breakdowns.
Quality that varies without a known cause
And a process nobody has correlated with it.
Capacity constraints discovered late
When the order has already been promised.
Supplier lead times that move
With a planning parameter that does not.
Models that work and never reach production
Because nothing in the plant consumes a prediction.
Compute the naive forecast for your top twenty products over the last year and compare it to your current forecast. One afternoon with a spreadsheet. In a meaningful number of cases the naive forecast is within a point or two of the planning forecast, which tells you where the improvement opportunity actually is and which series are worth a model. Programmes that skip this cannot demonstrate value and usually do not survive their first review.
Predictive projects usually begin with available data and a modelling technique. We begin with the decision, the lead time it needs, and whether anybody can act in that window, because those three determine whether the work is worth doing at all.
Where the answer is no, saying so early is more valuable than a model nobody can use.
Step 1
Define the decision and the lead time it requires
Step 2
Confirm somebody can act in that window
Step 3
Assess the historical data for the series or the failure mode
Step 4
Establish the naive baseline before any model
Step 5
Prioritise the use cases on value, feasibility and lead time
Step 6
Prepare features from process, maintenance and context data
Step 7
Develop the model, simplest adequate approach first
Step 8
Evaluate against the naive baseline and on bias separately
Step 9
Design how the output lands in the operating process
Step 10
Agree the thresholds with the people who will respond
Step 11
Pilot with the baseline and the response measured
Step 12
Monitor, retrain on trigger, and revalidate per plant
Count how many times each critical asset has actually failed in the way you want to predict. Pull it from the maintenance records. If the answer is twice in five years, no model will learn that signature from your data and the honest approach is anomaly detection or fleet pooling. This count takes a day and it prevents a predictive maintenance programme that was never statistically possible.
Grouped by what each part predicts. Every item is delivered with its lead time, its naive comparison and the process step that consumes it, which is what distinguishes a deployed model from a demonstrated one.
Equipment and maintenance
Predictive maintenance analytics on the assets where the lead time and the capacity make it actionable
Equipment failure prediction where the failure history supports it, and anomaly detection where it does not
Remaining useful life estimation where the degradation is observable and the failure mode is understood
Maintenance scheduling optimisation, which is frequently worth more than the prediction itself
Condition-based triggering into the maintenance system, so a prediction becomes a work order
Demand and production
Demand forecasting with the naive comparison reported alongside
Production volume forecasting at the horizon your planning cycle uses
Capacity forecasting, including the constraint that moves by product mix
Scenario analysis for planning: what happens under a demand or supply change
Forecast hierarchy reconciliation, so product, family and plant forecasts agree
Materials and supply
Inventory and material requirement forecasting against the actual lead times rather than the parameters in the system
Stockout risk prediction, which is a different and more useful output than a demand forecast
Supplier lead-time prediction from delivery history rather than from agreed terms
Supplier delay prediction, with an alternative action attached to be useful
Quality, energy and delivery
Quality and defect prediction from process conditions, with the honest limits in section 5
Energy consumption forecasting, including the demand peak question that affects tariffs
Predictive risk and scenario analytics for operational planning
Model deployment, monitoring and retraining pipelines, so the model is maintained rather than delivered
Integration into ERP, MES and CMMS, which is where a prediction becomes a decision
These are the common applications. The difficulty is named for each, because in this category the difficulty is rarely the algorithm.
Equipment failure risk prediction
Identifying assets at elevated risk of failure in a useful window.
Maintenance scheduling optimisation
Deciding what to do when, given capacity, criticality and production plans.
Demand-driven production planning
Aligning what is produced with what will be needed.
Raw material requirement forecasting
What will be needed, when, given the production plan and the bill of materials.
Inventory stockout risk prediction
Which items are at risk of running out, ranked by consequence.
Capacity and bottleneck forecasting
Where the constraint will be under the expected mix.
Product quality deviation prediction
Predicting a quality outcome from process conditions.
Energy demand forecasting
Predicting consumption, including the peaks that affect tariffs.
Supplier delivery delay prediction
Which deliveries are at risk, early enough to do something.
For the quality problem you most want to predict, ask engineering which parameter they believe causes it. Then ask whether that parameter is measured and at what rate. In many plants the answer is that the suspected cause is not instrumented, which makes the first piece of work instrumentation rather than modelling. That conversation takes an hour and it prevents a model built on whatever happened to be in the historian.
We work within your existing platform decisions. In manufacturing the deployment and monitoring of a model matter more than its sophistication, because an unmaintained model degrades and a distrusted one is ignored.
Data pipelines
Historical and current, from the joins the data platform page resolves.
Feature engineering
Including the context features: state, load, product, time since maintenance.
Feature store
Where several models share features and consistency matters.
Model development
Statistical first, machine learning where it earns the complexity.
Validation
Against the naive baseline, on bias, and out of time rather than at random.
Deployment
Into the process step that consumes it, per section 4.
Monitoring
Accuracy, bias, drift and whether anybody acted, per section 8.
Retraining
On trigger as well as on schedule, per our AI Strategy & Governance page.
Statistical and time-series methods first, because they are explainable, stable on short histories and frequently competitive
Machine learning where there is enough data and the relationship is genuinely non-linear, which is a smaller set of cases than usual practice suggests
Anomaly detection where failure examples are scarce, per section 3, rather than a classifier trained on four events
Out-of-time validation always, since random splits on time-series data produce optimistic results that do not survive production
Uncertainty expressed in the output, because a planner treats a range differently from a point estimate and should
And a simple model that planners trust in preference to a better one they do not, since an ignored model has no accuracy at all
A prediction in a plant becomes an input to somebody’s decision. The governance that matters is about that handover: who owns the number, who may override it, and whether the override is recorded.
Validation and acceptance
Against naive, on bias, out of time, with criteria agreed first.
Confidence and uncertainty
Expressed in the output rather than implied by a point estimate.
False alarm management
Thresholds set with the people who respond, per section 8.
Explainability
Enough that an engineer or planner can agree or disagree.
Data quality dependency
The model is as reliable as the signals behind it.
Human review and ownership
A named owner of the number, with the override recorded.
Versioning and change control
A retrained model is a change to a business input.
Cross-plant validation
Per plant, per our AI Strategy & Governance page.
Model monitoring usually reports accuracy. Four measures together say whether the model is working, and the fourth is the one that decides whether it survives.
ACCURACY at the horizon the decision needs, measured out of time, not at the horizon the model performs best at
BIAS, separately and per product family, because a consistent offset is correctable and is the one filling the warehouse
VALUE ADDED against the naive baseline, recomputed periodically, which is the only measure that says the model earned its existence
WHETHER ANYBODY ACTED on the prediction, which is the measure that decides whether the programme continues and the one almost nobody collects
Precision and recall at the operating threshold for anything that triggers an intervention, rather than at the statistically optimal point
Alert effectiveness: false alarm rate and attendance time together, per our Industrial IoT & Sensor Analytics page, since an alert nobody attends promptly has no effectiveness whatever its accuracy
Prediction lead time actually achieved, against the lead time the decision needs from section 2
Input drift and data distribution change, which arrives before accuracy moves
Forecast stability: how much the forecast for a given period changes as it approaches, since an unstable forecast is unplannable even when it ends up accurate
Override rate and whether overrides improved the number, per section 7
Business outcome: inventory, downtime, schedule adherence, against the baseline before deployment
And time since last retraining, with the triggers rather than only a schedule
For each prediction in production, ask what decision changed because of it last month. Name the decision and the person. If that cannot be answered for a model that has been live for six months, the model is producing output rather than value, and that is worth knowing before the next one is commissioned. It is also the measure that protects a programme that is working, because it produces evidence rather than accuracy figures.
Outcomes depend on your data history, your maintenance capacity and your planning cycle. These are the changes the work is aimed at.
Every prediction has a lead time that matches the decision and somebody who can act in that window
Every forecast is reported against the naive baseline, so value added is evidence rather than assertion
Bias is measured separately, which is the measure that shows up in inventory
Failure prediction is claimed only where the failure history supports it, with anomaly detection where it does not
Unplanned downtime risk falls on the assets where intervention was actually possible
Maintenance resource allocation improves, because work is scheduled against predicted condition and available capacity rather than around breakdowns
Decision-making becomes proactive where the lead time allows it, and explicitly reactive where it does not
Forecasts land in the planning cycle rather than in a dashboard, with a fallback when the model cannot run
Overrides are captured with a reason, so the planner becomes the most informative part of the process
Forecast stability is measured, because an unstable forecast cannot be planned with
Models are validated out of time, which is why the production performance matches the validation
And for every model in production, somebody can name a decision that changed because of it
Bring us one decision you want to make earlier, and we will establish the lead time it needs, whether anybody can act in that window, what the naive baseline is, and whether your data supports the prediction before any model is built.
CaliberFocus specifies every manufacturing prediction by the lead time the decision needs and whether somebody can act in that window. We compare every forecast against the naive baseline, measure bias separately from accuracy, validate out of time, and land the model in the planning cycle with a fallback, rather than on a dashboard.
- Every forecast reported against the naive baseline
- Bias measured separately, because it is the one filling the warehouse
- Anomaly detection where failure history cannot support prediction
- Models landed in the planning cycle, with overrides captured
Security & Compliance
