Who Owns a BMS Alarm? Assigning Accountability by Rule

Look at any estate with a mature BMS integration and you will find a handful of alarms that have been active for months. Not hidden: visible on the dashboard, in the reports, discussed in meetings. The controls contractor believes it is a plant issue for the maintenance team. The maintenance team believes it is a sensor or configuration issue for the controls contractor. IT has looked at the network and found nothing wrong. The energy manager raised it because it distorts a report. Everybody has engaged with it, nobody owns it, and it will still be there next year.

The message up front: ownership has to be a recorded attribute of the alarm itself, assigned by rule at the point of raising, held by exactly one named role at a time, and transferred by an explicit act that leaves a record. Separate the three things that get called ownership, which are responsibility for the alarm's configuration, accountability for responding to an occurrence, and ownership of the underlying asset. They often sit with different people, and most disputes are an argument between two of them.

1. Three different things called ownership

Almost every ownership argument dissolves once these are named separately.

• Configuration ownership. Who decides that this alarm should exist, at what limit, with what severity. Usually the controls engineer or contractor, sometimes nobody since commissioning. This is the owner of the question "should this alarm be here at all", and a surprising number of long-running alarms are configuration problems rather than plant problems.
• Response accountability. Who is answerable for acting when it occurs. This is the one that needs to be unambiguous at every moment, and it is the one usually left implicit.
• Asset ownership. Who is accountable for the equipment's condition and cost over its life. Relevant because it decides who cares about recurrence, and it is frequently a different person from either of the above.

The pattern that stalls is an alarm whose response accountability is clear but whose configuration ownership is vacant. The responder attends, finds nothing wrong with the plant, correctly concludes that the alarm is misconfigured, and has nobody to hand that to. So they close the job, the alarm recurs, and the cycle repeats until somebody suppresses it.

2. Assign at the moment of raising, by rule

Ownership assigned by a person reading an alert queue is ownership assigned late and inconsistently. It should fall out of the same mapping that already classifies the alarm.

The mapping table described in alarm codes to fault categories already holds the source identity, the asset and the problem code. Adding an owning role to each row costs nothing and means every raised alert arrives with an owner rather than waiting for one. Three rules make that assignment robust.

• Assign to a role, never to a person. People take leave and leave jobs; roles do not. A named individual in a mapping table is a guaranteed future gap.
• Derive from the fault's nature, not only the asset. A communications failure on an air handling unit belongs with controls or IT, not with the mechanical trade that owns the unit, which is the routing argument in the connectivity loss playbook.
• Have one default owner for the unmapped case, and make it a real role that reviews them, not a queue. An unowned alarm is the failure mode this whole exercise exists to prevent.

3. A role map that covers the real cases

4. When the owner is a contractor

On most estates at least one of these roles sits outside the organisation, which changes the mechanics in three ways worth designing for.

Ownership has to be expressible in the system the contractor actually uses, or it is a note in your system and a verbal expectation in theirs. Where there is no shared system, the handover needs a recorded act with an acknowledgement, because an alarm transferred to a contractor who never accepted it is still yours and the report will not say so.

Second, the boundary between scopes becomes the place alarms accumulate. The device-not-responding case is the clearest example: the mechanical contractor owns the plant, the controls contractor owns the controller, and the network between them belongs to whoever signed for it, which is often nobody. Naming an owner for the boundary itself, in advance, is worth more than refining either scope.

Third, ownership and measurement must line up. If a contractor owns a class of alarm, their SLA has to be measured on the clock that starts when they could have acted, which is the design problem in alert SLA design.

5. Finding the alarms nobody owns

Whatever the design says, some alarms will slip through, and a few queries find them reliably.

• Alarms active longer than any reasonable response window, regardless of whether a work order exists. The duration is the signal, and the usual cause is not neglect but ambiguity.
• Alarm sources with recurrence but no closed work order in the period. Something is happening repeatedly and nothing is being recorded against it, which is the pattern in repeated faults as one case.
• Work orders closed with no cause recorded, on recurring sources. Frequently the signature of a responder who attended, found nothing, and had nowhere to send it.
• Alarms landing on the unmapped default owner, as a count and a trend. This is the leading indicator and the cheapest one to watch.
• Suppressed alarms with no end date. Suppression used as a disposal route rather than a temporary measure, which is the misuse warned about in suppression during planned shutdowns.

6. The review that keeps it working

Ownership design decays without a forum, and the forum does not need to be elaborate.

A periodic review of the longest-standing active alarms, attended by the maintenance, controls and integration owners together, resolves most of what accumulates, because the great majority of these cases need a decision rather than an investigation and the decision needs the three parties in one place. Two outputs make it worthwhile: a disposition for each alarm reviewed, which is either an owner who accepts it or a decision to change the configuration, and an amendment to the assignment rules wherever the discussion revealed that the default routing was wrong. That second output is what stops the same cases returning.

It is also the right venue to challenge whether an alarm should exist. An alarm that has been active for a year, that nobody acts on, and that no responder has ever found a fault behind, is a configuration decision waiting to be taken, and taking it is a legitimate outcome rather than an admission of failure.

The idea to walk away with

Long-standing alarms are usually an accountability gap rather than a visibility gap, and the gap is most often between response accountability and configuration ownership, where the second is vacant.

Separate the three kinds of ownership, assign a single owning role by rule at the moment the alert is raised, make transfer an explicit recorded act, name an owner for the boundaries between contracts, and review the oldest active alarms with all three parties in the room.

Final thoughts

Try one question at your next operations meeting: for the alarm that has been active longest, who owns it.

If one person answers without hesitation, the design is working and the alarm is a genuine piece of difficult work. If the room looks at each other, you have found both the specific problem and the general one, and the assignment rule is a cheaper fix than the conversation that currently substitutes for it.

Related reading: Alarm codes to fault categories, Alert SLA design, Severity and escalation design, Connectivity loss playbook, RBAC design for CAFM, Data governance.