Case study · Manufacturing

Predictive maintenance on production equipment

Maintenance planning moved from the calendar to the condition of the equipment, and the shift engineers get a ranked list each morning with the reasoning attached rather than an alert they have to take on trust.

All case studies

Challenge

A manufacturer was running maintenance to a fixed calendar. Machines that were healthy came off the line for servicing they did not need, and the ones that failed did so between scheduled visits, taking the line down with them. The sensor history that would have distinguished the two was being logged and then discarded.

Approach

We built the pipeline that retains and aligns the machine telemetry, then trained failure models per equipment class against the maintenance log so the target was a real recorded fault rather than a proxy. Predicted failures surface as ranked work orders in the maintenance system the engineers already open each morning, with the contributing signals shown next to each one.

Outcome
Maintenance planning moved from the calendar to the condition of the equipment, and the shift engineers get a ranked list each morning with the reasoning attached rather than an alert they have to take on trust.

More work

Related case studies

Manufacturing simulation

Digital twin of the production line

Challenge: Every proposed change to the line, whether a new product mix, a reordered station or a shift pattern, had to be argued from experience, because the only way to test it was to try it on the real line and accept the cost of being wrong.
Approach: We built a simulation of the line calibrated against its own historical throughput, cycle times and failure rates, so its baseline behaviour matches what the plant actually did. Planners run a proposed change against it and get throughput, bottleneck and utilisation figures before anything is moved, with the model re-calibrated as new production data arrives.

4×

improvement

faster to evaluate a proposed line change

Python
SimPy
Databricks
Azure
Next.js
PostgreSQL

Outcome

Line changes are now argued with a simulated result attached, and the debate has moved from whose experience to trust to which assumption in the model to examine.

Sector: Manufacturing

Read the case study

E-commerce application

E-commerce application with demand-aware merchandising

Challenge: A fast-moving consumer goods business was running promotions on instinct. Best sellers went out of stock mid-campaign while slower lines were discounted into a loss, and nobody could say which decision had caused which result.
Approach: We built the storefront and order platform, then wired a demand model into the merchandising layer. Sales, stock position and campaign calendar feed a forecast that ranks what to surface and flags lines heading for a stockout before the promotion goes live.

32%

reduction

fewer mid-campaign stockouts

Next.js
Python
Databricks
PostgreSQL
AWS
Kubernetes

Outcome

Merchandising decisions moved from a weekly meeting to a daily ranked list, and the stockouts that used to end campaigns early became a pre-campaign warning instead of a post-mortem.

Sector: FMCG

Read the case study

Your problem next

Does this look like your situation?

Tell us which part of this case study sounds familiar. Starting from a problem we have already solved is the fastest call we have.

Book a consultation hello@post-ql.com

We reply to every enquiry within one business day.

Challenge

Approach