Davisa
Contact

DAVISA AI STUDIO · USE CASE

AI-driven industrial scrap prediction

For plant managers, quality managers and operations directors at mid-market industrial companies losing between 2% and 8% of annual revenue to scrap and rejects. Machine Learning models trained on your Business Central history that predict the probability of scrap per production order before releasing it to the shop floor and propose in-shift parameter adjustments.

The pain we solve

An average mid-market industrial company loses between 2% and 8% of annual revenue to scrap and quality rejects. The exact figure depends on the sector (plastic injection sits at 3 to 6%, precision machining at 1 to 3%, process chemistry can hit 10% during plant start-up), but the pattern is the same: a very significant portion of industrial margin goes down the scrap drain and nobody sees it in real time.

The problem is not lack of data. If you have BC with dvscrap, dvquality and dvproduction live, the data is there: order history, material lots, routing parameters, operator entries, inspection and non-conformity records, reject codes, OEE by machine and shift. The problem is that this history is only reviewed at month-end close, when scrap has already happened and the lot has been shipped or thrown away. The information consistently arrives too late.

The quality manager knows it: there are correlations that explain a big share of recurring scrap (a specific supplier lot dragging issues, an ageing machine that combined with a specific shift does not perform, an SKU that jams when a certain operator runs it on a certain day), but spotting them by eye in spreadsheets is unfeasible. They are multivariate patterns with dozens of combinations. Exactly what a Machine Learning model is good at and a human is bad at.

The added hidden cost is the reactive one. Every time a lot turns out defective, the plant stops, reschedules, reassigns, reworks or scraps. OEE falls, delivery times erode, the customer gets served late. Depending on volume, the indirect cost of scrap is usually 1.5 to 2 times the direct cost of rejected material. That real number rarely shows up on the dashboard.

What the AI does here

The core of the case is a supervised Machine Learning model trained on Azure Machine Learning. The target variable is the probability of scrap per production order (or per lot, depending on the sector), expressed as expected percentage of non-conforming parts or as a risk category. Predictor variables are extracted from BC and the dv* extensions: material lot, supplier, machine, shift, operator, SKU, routing parameters, start conditions, day of week, recent OEE, previous quality records on the same combination.

The model is trained with standard gradient boosting techniques (XGBoost, LightGBM) or tabular neural networks, depending on cross-validation performance. The important part is not the specific algorithm but the data pipeline: we ingest BC history, clean inconsistent records, balance classes (scrap is usually a minority event), validate against a recent time window and deploy the model as a service. Retraining is periodic, monthly or quarterly depending on drift.

At inference time, when the planner is about to release a production order, the system queries the model with that specific order parameters and returns a risk score. If the score exceeds the configurable threshold, the planner receives an alert with the most likely cause and the recommendation: change the material lot, move the release to a different shift, adjust parameter X, or request prior quality validation. If there are IoT signals on the machine (temperature, pressure, vibration), the model refines the recommendation during execution itself.

The entire infrastructure runs inside your Azure tenant. Production data does not leave to public models. The trace of every prediction is logged: which order, what score the model gave, what it recommended, what decision the responsible person took and what the actual result was. That feedback feeds the next retraining cycle.

An honest note. This case requires a meaningful volume of history for the model to learn solid patterns: at least 12 months, ideally 24, with dvproduction, dvquality and dvscrap properly configured and clean data. If your company has been on BC for a short time, this case is not viable yet. It is better to consolidate the capture first and tackle the AI when there is a statistical base.

Before and after

Aspect Before (reactive) After (predictive)
Problem detection Scrap is discovered when the production order is closed, when there is no way back. The model warns of high scrap probability before release or during execution.
Root cause analysis Monthly quality meeting on already-cold history, causes attributed by intuition. The model identifies the material + machine + shift + parameter mix that triggers rejects.
Corrective action Reaction after month-end close, with the lot already shipped and the loss already booked. Parameter adjustment or material lot change before the part comes out rejected.
Shop floor visibility The plant manager finds out about scrap in the dashboard the following Monday. Near real-time alert on the plant panel and push notification to the responsible person.
Cost of non-quality Known as a monthly aggregate figure, with no breakdown by order or root cause. Scrap cost avoided per order, with traceability of the alert that prevented it.
Organisational learning Knowledge stays with the veteran operator who senses when a lot is going wrong. The model captures that knowledge and makes it available across the whole plant.
Reporting to management Last month scrap figure, with qualitative explanation. Real vs predicted scrap KPI, alerts acted upon, cumulative savings of the year.

How we deliver

1

Discovery

5 days

Audit of BC + dvscrap + dvquality + dvproduction history. Validation of data quality and volume. Selection of the product family with the most traction. Definition of target KPI (% scrap reduction) and baseline against the previous 12 months. Identification of available IoT signals if any.

Deliverable: pilot roadmap with target family, KPI and baseline.

2

Pilot

8 weeks · fixed scope

Dataset construction, model training, validation against a recent time window, deployment as an Azure ML service, integration with the BC planning screen and the plant panel. Training for the quality manager and the plant manager.

Deliverable: live model, active alerts, monitoring panel.

3

Scale-up

ongoing

Extension to more product families, integration with additional IoT signals, periodic model retraining, drift analysis, expansion to adjacent cases (demand forecasting, predictive maintenance, scheduling optimisation).

Deliverable: new models per family, monthly KPI, ongoing support.

Tech stack

When this case is NOT a fit

Honesty weighs more than the sale here. This case is not for everyone.

Keep exploring

Frequently asked questions

How much historical data do we need for the model to work?

As a rule of thumb, between 12 and 24 months of clean history in Business Central, with dvproduction, dvquality and dvscrap active and properly configured. We need enough volume for the model to find statistical patterns across machine parameters, material lots, shifts, operators and quality results. If you have been live on BC for less than 12 months, the honest answer is not to start this case yet: the model would not have enough base and the results would be anecdotal.

What kind of manufacturing fits this case best?

Manufacturing with repeated orders (recurring lots, frequent SKUs) and measurable process parameters works very well: injection moulding, machining, stamping, extrusion, blow moulding, rolling, process chemistry. Pure project-based one-off manufacturing (custom heavy fabrication under single drawings) has less traction because each order is statistically unique. We assess this in the discovery with your real data before committing to a pilot.

What KPI actually improves?

The primary KPI is the scrap rate as a percentage of manufacturing cost. An average mid-market industrial company loses between 2% and 8% of revenue to scrap, depending on the sector. A 15% to 30% reduction in that rate is reachable in the first year with this case once consolidated. Secondary KPIs: OEE (rises with fewer corrective stops), mean time between quality failures, cost of non-quality, plant lead time. Everything is measured against the baseline we set in the discovery.

Do we need IoT on the machine for this to work?

Not mandatory, but it helps a lot. With BC data alone (production order, production journal, routing, material lots, quality results and scrap entries) we can already train useful models, especially for anticipating material-supplier-shift-machine mix problems. If we add real-time IoT signals (temperature, pressure, vibration, speed), the model gains resolution and can recommend in-shift parameter adjustments, not just preventive alerts.

How long until we see measurable results on the shop floor?

The pilot delivers a model in production in eight weeks, with an initial prediction over the SKUs with the most history. The real scrap reduction curve becomes visible between the third and sixth month, once the plant starts acting systematically on the alerts and the model has been retrained with post-pilot data. Industrial patience matters: this is not a two-week-result case and we do not sell it as such.

Next step

Already a Davisa customer?

We frame the case within your current BC and dv* extensions stack. Your usual advisor coordinates the AI Studio entry with no new onboarding.

Talk to the team →

New to Davisa?

We start with the 5-day discovery. In one week we validate whether your history has the base for the model and we size a realistic pilot.

Request AI discovery →
Message us on WhatsApp