Converting Repeated BMS Faults into One CMMS Case

Most maintenance systems are very good at the individual job and structurally blind to the pattern. A work order is raised, attended, closed. The next one is a new record with no memory of the last. Over a year a single misbehaving damper actuator can consume thirty visits, close every one of them inside its response target, and never once appear in a report as a problem, because at the level the system models the world, nothing went wrong. Thirty jobs were completed on time.

The message up front: you need a layer above the work order. Call it a case, a problem record, a chronic fault, the name does not matter; what matters is that it persists across repairs, accumulates every related work order and alert beneath it, and stays open while the underlying condition keeps returning. Without it, recurrence is invisible to every report you run, and your maintenance strategy is permanently stuck at repair. With it, a small number of assets will immediately stand out, and they are almost always where the wasted hours are.

1. This is not the same problem as duplicate alerts

Worth separating clearly, because the two get conflated and the solutions are different.

Duplicate alerts are many signals from one incident, usually within minutes or hours: a chattering contact, a repeated re-send, a cascade from one root cause. The fix is a deduplication key and a time window, and it belongs at integration time. That is covered separately in alert deduplication between BMS and CMMS.

Recurrence is many separate incidents over weeks or months, each one genuinely a new occurrence, each one legitimately closed. There is nothing to suppress. The fault really did come back. The problem is not noise, it is that the maintenance record has no concept of "again", so the history is there but the pattern is not.

The practical test: if collapsing the events would lose real information about separate visits, it is recurrence and needs a case. If collapsing them loses nothing except noise, it is duplication and needs a rule.

2. Why recurrence stays hidden in a CMMS

It is not usually a missing feature. It is a set of ordinary practices that each make sense alone and combine to erase the pattern.

• The work order is the unit of everything. Reporting, targets, compliance and cost all hang off it. Anything that is not a work order attribute is effectively invisible to management reporting.
• Closure is an achievement. A closed job is a good job. Nothing in the normal flow asks whether the same job was closed last month, and nothing penalises closing it again.
• Free-text descriptions defeat grouping. "AHU3 fault", "AHU-03 not cooling", "third floor air handler issue" and "AHU3 again" are the same chronic problem and will not group by any query anyone actually runs. This is the strongest practical argument for structured failure codes on a problem, cause and action model.
• Asset references are inconsistent. Jobs raised against a location on Monday and against the asset on Thursday cannot be counted together. Where BMS alerts feed the system automatically, this depends entirely on point-to-asset mapping being correct.
• Reactive work is not reviewed as a population. Planned maintenance gets compliance reporting. Reactive work gets counted, and occasionally costed, but rarely analysed for repetition. The habit is covered more broadly in the reactive maintenance guide.

3. The case layer, and what belongs in it

A case sits above work orders and below the asset. One case represents one persistent problem on one asset. Work orders hang off it; so do the BMS alerts that triggered them.

Many maintenance systems have something that can serve this role already, under a name like parent work order, problem record or job folder. Using an existing construct is usually better than inventing a parallel one, as long as it can stay open across multiple completed jobs and can be reported on independently.

4. Detecting recurrence automatically

Manual spotting does not scale and depends on one experienced person staying in the role. The rules worth automating, in increasing order of usefulness:

• Same asset, same condition class, within a rolling window. The baseline rule. The window should reflect the expected interval between genuine independent failures of that class of equipment, which means it differs between a door closer and a chiller.
• Reopening shortly after closure. A new occurrence within a short period of the last job being completed is a failed repair, and deserves a stronger signal than an ordinary recurrence. This is the highest-value rule on the list and the cheapest to implement.
• Same asset, different condition classes, high total volume. An asset generating varied faults repeatedly is often approaching the end of its useful life, and that pattern is invisible to any rule keyed on a single condition.
• Count against a criticality-weighted threshold. Three recurrences on a critical asset matter more than ten on a non-critical one, so the trigger should be scaled by the classification described in asset criticality classification.
• Recurrence relative to the asset class, not an absolute number. The most informative version: flag assets whose fault rate sits well above others of the same type in the same estate. It needs a decent population to be meaningful, but it separates "this equipment is inherently maintenance-heavy" from "this particular unit is a problem".

5. Escalating from repair to something else

The point of making recurrence visible is to change what happens, and the change is a progression through states rather than a single decision.

• Repairing. Normal response. Each occurrence gets a job. Appropriate for the first few, because some things genuinely do fail twice for unrelated reasons.
• Investigating. Triggered by count, by duration, or by cumulative cost crossing a threshold you set in advance. The output is not a repair, it is a cause. This is where a structured method earns its keep rather than another reset: the approaches are set out in root cause analysis methods, and for a quick first pass the five whys is often enough to get past the symptom.
• Awaiting decision. The cause is known and the remedy needs money, a shutdown window, a design change or a contractual conversation. Cases stall here, which is exactly why the state should be explicit and reported: an invisible stall looks like ongoing work.
• Monitoring. The remedy is applied and the case stays open through a defined quiet period. Closing at the moment of repair is how chronic cases get closed eleven times.
• Resolved. Closed with the quiet period evidenced. The case remains searchable against the asset, because the next person needs the history.

Set the escalation thresholds before you start, and write them down. Thresholds decided after the fact are always set just above whatever the current worst offender is doing.

6. What the investigation usually finds

Stated as a general pattern rather than a claim about any particular site, chronic faults on building plant tend to resolve into a small number of categories, and recognising them early shortens the investigation:

• An instrumentation defect rather than a plant fault. The equipment is fine and the sensor, switch or wiring reporting on it is not. Common, cheap to fix, and frequently missed because every visit is dispatched to the plant. The signal-integrity checks in BMS points lists and field devices are the relevant diagnostic ground.
• A control sequence fighting itself. Thresholds, delays or interlocks that produce a repeating condition under particular circumstances. Looks like a plant fault, is a configuration problem, and will recur forever until someone reads the sequence.
• A maintenance task that is not doing its job. The planned routine exists, is signed off, and does not address the thing that keeps failing. Visible only when recurrence is set against PM compliance, because high compliance plus high recurrence is a specific and informative combination.
• An operating condition outside the design. Load, hours, ambient conditions or occupancy that the equipment was never selected for. The remedy is a decision rather than a repair.
• Genuine end of life. Diagnosed by cumulative cost and failure rate rather than by age, which is why the cost rollup on the case matters.

The first two account for a large share of BMS-originated chronic cases in my experience of maintenance data, and both are cheap to resolve once someone is actually looking for a cause rather than dispatching another visit.

7. Reporting that makes anyone act

A chronic case list that nobody reads changes nothing. What tends to get attention:

8. The ways this goes wrong

• The case becomes a dustbin. Without a condition class, everything on an asset lands in one case and the distinction between a chronic fault and ordinary maintenance disappears. Condition class is not optional.
• Cases are closed to keep the list short. Predictable wherever open-case count becomes a target. Close on evidence of a quiet period, and report open cases by stage so that a long investigation does not look like neglect.
• Recurrence is masked by inconsistent coding. The same fault logged under three different codes will never group. This is the practical reason failure coding discipline matters more than the coding scheme chosen.
• Failed-repair reporting is used punitively. It is a genuinely useful measure and it will be gamed within a month if it is attached to individuals before the data is trusted. Start it as an aggregate, confirm it is measuring what you think, then narrow.
• Retrofitting cases over years of history. Tempting and usually disappointing, because the historical descriptions are free text and the asset references are inconsistent. Start the case layer from a date, and treat history as context rather than as a dataset.
• Nobody owns the cases. The most common failure of all. A chronic case list with no named owner per case becomes a report that gets circulated and never actioned.

The idea to walk away with

A maintenance system that only models jobs can only ever manage jobs. Add one persistent record above the work order, keyed on asset plus condition, and the same data you already collect starts answering a different and much more valuable question: not "was this fixed" but "is this still happening".

That shift is what moves an operation from reactive to improving. It does not need new sensors, a new platform or a new budget. It needs a case object, a condition vocabulary, a rule that spots the repeat, a threshold agreed in advance, and a named owner per case.

Final thoughts

If you want to know whether this is worth building, the test takes an afternoon with the data you already have. Pull twelve months of reactive work orders, group them by asset, and sort by count. The distribution is almost always steep, with a small number of assets accounting for a disproportionate share of jobs. Then read the descriptions on the top ten.

What that exercise usually reveals is not a maintenance failure but an information failure: every one of those jobs was done properly, by people who had no way of knowing it was the eleventh. The case layer exists to give them that one piece of context, and most of the benefit follows from the context rather than from anything clever built on top of it.

Related reading: Alert deduplication between BMS and CMMS, When a fault clears before the technician arrives, The alert-to-work-order audit trail, Failure codes: problem, cause, action, Root cause analysis methods, Asset criticality classification.