The data was there.
The insight wasn’t.

Downhole tools — perforating guns, logging tools, packers — fail under extreme pressure and temperature. Maintenance was reactive: run a tool until it failed, or until it came back from a job visibly worn. Prediction relied on engineer intuition and calendar-based schedules that ignored actual usage intensity.

SAP PM held years of maintenance history. Nobody had ever built a model over it. The data existed; the insight did not.

Any solution also had a hard adoption constraint: field engineers were not going to open a second system. A dashboard nobody logs into produces exactly zero operational value.

We extracted structured maintenance history from SAP PM going back five years — 12,000+ maintenance orders, tool run records, failure codes and repair actions — and built Python pipelines to clean, normalise and feature-engineer it into model-ready form: run counts, cumulative pressure-hours, failure-to-repair gaps, and tool class clusters.

Gradient-boosted classifiers were trained on failure precursors, producing a risk score per tool per week. The scores surface through a .NET dashboard for planners — but critically, at threshold risk the system writes a preventive maintenance order straight back into SAP.

That closing of the loop is the whole design. Field engineers receive a standard PM work order in the system they already live in. Nothing about their day changes except the source of the order.

1. SAP data is not analysis-ready Maintenance history is entered by humans under time pressure across years and sites. Free-text failure descriptions, inconsistent coding and duplicated orders all had to be reconciled before any model could learn anything real.
2. Feature engineering is the actual work The model’s power came from derived features — cumulative stress exposure, time-since-overhaul, intensity of recent duty — not from algorithm choice. Getting those right required understanding what physically wears these tools out.
3. Validating on history without leaking the future Testing against past failures is trivially easy to get wrong. The evaluation had to respect time ordering strictly, so the model was never scored on information it would not have had at prediction time.
4. Writing back into a production ERP safely Auto-generating work orders in a live SAP system demands correct integration and conservative thresholds — a model that floods planners with false positives is switched off within a fortnight.

35% reduction in unplanned downtime within the first operational quarter. The model reliably flagged high-risk tools 48–72 hours ahead of failure events confirmed in the historical test set. Maintenance shifted from reactive repair to planned intervention.

Adoption was immediate precisely because there was nothing to adopt — the intelligence arrived as an ordinary SAP work order. This is the pattern we now apply by default: put the model output where the work already happens, not in a new interface.