Case study: the sensors were fine. Nobody could act on them.

What they had

A mid-sized discrete manufacturer, three plants, roughly 60 critical assets under some form of condition monitoring. They were not data-poor. They had a historian with a decade of PLC tags. They had vibration sensors on the big gearboxes, some retrofitted, some OEM. They had a monthly PDF from their vibration analysis vendor that arrived a week after the readings were taken.

The reliability engineer had a spreadsheet. The planners had the CMMS. The mechanics had tribal knowledge. None of these three things talked to each other.

The failure pattern was the one you'd expect: a bearing would trend badly for weeks in the vendor portal, the PDF would land on a Tuesday, and by then the asset had either already failed or been nursed through the weekend on a hunch. When a mechanic finally opened the machine, nobody could easily pull up the last twelve months of trend data alongside the last twelve work orders. The information existed. It was just in four systems and one person's head.

This is the shape of most maintenance data problems we see. The Mutually Human case study on predictive maintenance with Microsoft Fabric describes the same pattern from a different angle: telemetry was flowing, the operational path from signal to action was missing.

What we built

Nothing exotic. A small managed pipeline that pulled from the historian, the vibration vendor's API, and the CMMS on a schedule. One asset-centric data model, so a gearbox had its tags, its readings, its work orders, and its criticality in one place.

On top of that, three things:

1. A rules layer for the boring cases (temperature over threshold for N minutes, RMS velocity trending up week-over-week against the asset's own baseline). No models yet. The rules covered the majority of what the vendor PDF was already telling them, just faster and in context. 2. Alert routing that opened a draft work order in the CMMS with the trend chart, the last three work orders on that asset, and the mechanic's notes from the last teardown attached. The planner still approved it. 3. A single dashboard the reliability engineer could open in a meeting without exporting anything.

We did not replace the vibration vendor. We did not touch the PLCs. We built the layer between what they already owned and what the team actually did on Monday morning.

What changed

We are careful about claiming numbers we cannot back up. Qualitatively: the monthly PDF stopped being the trigger for action. Draft work orders started showing up in the planner's queue with enough context that they were not rewritten from scratch. Two recurring failure modes that had been rediscovered every few months got standing inspection tasks instead. The reliability engineer got her Fridays back.

The boring lesson, again. The sensors were fine. The algorithm was not the problem. The plumbing was.