An alarm is not a ticket

At 09:42:17, a compressor’s discharge-temperature alarm becomes active. Eight seconds later, the high-high alarm arrives. Then come high vibration, low flow, and a trip. Five alarm rows describe one event, but a rule that turns every alarm into a ticket creates five pieces of work.

The reverse mistake is just as common. If the trip clears after a restart, no ticket is raised at all. The shift remembers it; the maintenance planner never sees it; and the next failure begins without a record of the first.

Alarms and tickets are related, but they serve different purposes.

An alarm demands attention

An alarm reports that a configured condition is true. Its job is to help an operator recognize an abnormal situation and respond within the process timescale. Good alarm systems are intentionally terse: tag, state, priority, timestamp, and acknowledgment.

That record does not answer the questions a planner needs:

• Is physical work required?
• Is it safe to defer?
• Which asset and failure mode are involved?
• What evidence should the technician inspect?
• Did another open order already cover the problem?

A cleared alarm may need no work. A recurring alarm that clears every morning may deserve an investigation. A standing alarm may be a known instrumentation defect already scheduled for the next outage. State alone cannot decide.

A ticket commits resources

A work order is an agreement to inspect, repair, calibrate, or otherwise act. It needs an owner, scope, priority, and definition of completion. Creating one should therefore be a decision, not a side effect of an alarm bit changing.

The useful automation lies between the two systems. Related alarms can be grouped into an event. Millwright can attach the surrounding telemetry, identify the affected asset, find similar incidents, and show existing work. An operator or planner then decides whether to open a ticket.

For the compressor event, one ticket might carry:

• the first-out alarm and the subsequent trip sequence;
• ten minutes of discharge temperature, vibration, flow, and load;
• the operating state before the event;
• the applicable restart or inspection procedure; and
• the last comparable event and its confirmed cause.

That is far more actionable than “investigate compressor alarm.”

Alarm floods need compression, not multiplication

During a trip, one initiating condition can produce dozens of consequential alarms. Sending all of them downstream creates a second flood in the CMMS, where duplicate orders compete with planned work and distort backlog metrics.

Grouping is not the same as hiding. The original alarm records should remain intact for audit and sequence-of-events analysis. The work view should present them as one incident, preserve their order, and highlight the likely first-out condition without claiming certainty where timestamps or scan rates do not support it.

Closure should travel back

The link should survive after maintenance finishes. If a technician confirms a loose terminal, records the repair, and returns the asset to service, that finding belongs with the original event. The next recurrence can then be compared against a known case.

This is the practical loop: alarm to investigation, investigation to approved work, and completed work back to the event that justified it. Without those links, the alarm system keeps reporting symptoms and the work system keeps closing jobs, but the plant does not get better at recognizing the same failure twice.