The world of emergency call centers has changed dramatically in recent years. Most emergency control centers operate above their capacity limits: There are too many alarms, they stay longer in queues, workflows are poorly implemented, and in addition, the conversions of the European standards frameworks during the pandemic brought another challenge to the operators: One that is permanently aggravated by the existing staff shortage. For the end customer and the responsible specialist installer, these are serious problems that control centers must address to remain competitive.
This article breaks down 5 of the most common problems of control centers and shows their impact on security businesses' efficiency and how they can be measured and solved.
1. Too many alarms
Having too many alarms is the most widespread problem of alarm systems in control centers. But how many warnings are too many, and how can you measure if your control center needs to take action?
When are alarms too many?
While this depends on the nature of the processes and the complexity of the operator response required, a common rule of thumb says that 12 alarms per hour should be considered the maximum.
Methods of measurement:
- The best measurement for this problem is the average alarm rate: The number of alarms incoming per operator console (an operator's span of control or area of responsibility) in a specific time unit (e.g., per operator, per hour, over a month time), then averaged over the reporting period.
- To determine if they have too many alarms, security operation centers can alternatively look at the number of standing alarms and the percentage of time in flood.
What if each alarm was an accurate indicator of an abnormal condition requiring a response? With too many of them, it becomes almost impossible for the operator to respond to each of them adequately. And even if false alarms are among them, the operator becomes desensitized to alarms in general because he gets used to receiving (too) many notices, which then, in turn, has a negative effect when a real alarm occurs.
2. Chattering alarms
This phenomenon is often fueled by so-called chattering alarms, which are nothing else than nuisance alarms: Alarms that repeat excessively in a short time interval. Chattering alarms desensitize the operator and are the epitome of nuisance alarms. Therefore, according to industrial alarm standards, no chattering is acceptable. Talking alarms are often caused by poor alarm design, but device maintenance is also a common cause.
How do you measure chattering alarms?
Chattering alarms are defined by the number of times an alarm is reported to the operator twice within a specified time interval (usually 60 seconds).
3. Alarms that do not require a response
Alarms are audible and visible means of indicating to the operator that a piece of equipment is malfunctioning, a process is derivative, or another abnormal condition requires a response. However, if alarms are used only to notify the operator of situations, this results in further desensitization of the operator to alarms. The problem behind this widespread practice is the erroneous assumption that the alarm function is the only method of communication between the automation system and the operator.
How do you measure real alarms?
It's important to distinguish between alarms and alerts. Alerts are audible and visible means of indicating to the operator an equipment or process condition that requires awareness and does not meet the criteria for an alarm. Often, they are essential but not urgent and essential (as alarms).
The process of distinguishing between alarms and alerts is called alarm rationalization. With the ultimate goal of determining the most efficient number of alarms, this is done by reviewing, validating, and justifying alarms that meet the criteria of an alarm. During this often time-consuming rationalization, it is not uncommon for up to 50 percent of alarms to be eliminated because they do not require a response. However, this does not mean that the goal of rationalization is to eliminate alarms. Instead, it ensures that the alarms are in place with the correct threshold, priority, and documentation for operator training.
4. Alarms that stay alarms
Even after they stale. These alarms do not require a response (anymore): They once might have, but the answer is no longer needed. Measuring stale alarms is easy: The number of reported alarms is older than 24 hours. Alarms like these clutter the alarm summary and, again, desensitize the operator.
In practice, there are two common causes of stale alarms:
- Control system configuration practices
- Poor management of change
One study on that subject revealed that almost 30 percent of stale alarms were due to equipment that was not operating because it wasn't needed at the time. For example, the basic configuration practices created an alarm that a pump was not running – even when the pump was intentionally not running. That's why it is so important to have good basic configuration practices set up in the first place to prevent many alarms.
The second cause of obsolete alarms is the careless handling of changes. When devices are removed from operations, the alarms should be removed from the control system. It is not uncommon to find alarms at the bottom of the alarm summary for removed devices years ago.
5. Alarms with the wrong priority
Alarm priority is the ranking of alarms by severity and response time.
Although the alarm priorities should be based on how urgently the operator needs to take action, many alarms are assigned the wrong focus. Prioritization also includes considering consequences that the operator can avoid: The difference between scenarios in which the operator responds and those he does not. Having many alarms with the wrong priority makes priority less meaningful and possibly even meaningless to the operator. This can then lead to the operator responding with an inappropriate action when multiple alarms occur. A consistent method of prioritization based on the severity of consequences and response time can radically change alarm priorities. In some cases, 80 percent of alarm priorities have been changed, mainly to lower priorities.
Crystal-clear answers through a change of perspective
Why must there be so many organizational interfaces in a safety chain?
It is a common misconception that practically all procedures in the alarm service are "prefabricated." For each criterion and, if necessary, time of day and week, there are clear instructions on what must be done after an alarm is raised. The installer and the control center determine this in detail with the customer during the safety analysis. But in current processes, some contradictions remain:
- Every alarm is routed through the hands of a dispatcher first instead of directly forwarding it to the place/person carrying out the emergency response.
- After an intervention, operators often wait until they receive the alarm report. Instead, it could already be created by the intervention force with the DKG (digital communication device according to VdS 3138/2172) and directly imported into the integrated IT of the security chain.
- NSL specialists have to call hundreds/thousands of customers in the evening because their intrusion detection systems have not yet been activated at the specified time. They could still use an automated workflow that handles this in the background.
So, what is the solution?
The excellent news about common problems is that they are usually standard solutions. Many control centers across industries have already taken action to control their alarm systems to minimize common issues and adverse effects. In these control centers, alarm systems are an essential help for the operators, as they indicate the right time to take the right action and prevent undesirable consequences.
The answers to the addressed challenges in the security businesses' safety chain repeatedly come to a unanimous conclusion: The technical implementation of the security chain is in excellent hands with the cloud. All units entrusted with security can be optimally supplied with information from there. The connection to the security chain for specialist installers must be fast, simple, and transparent. They want to set up the transmission independently without the involvement of third parties, preferably already pre-assembled. All high-security protocols/security categories, such as SecurIP, must function without problems. How does this service work? The customer expects a well-founded analysis of his security needs, documented immediately. In addition to the structure of the alarm system and the selection of components, the performance of the safety chain is now also mapped. After all, this is an integral part of the performance promise. The relevant data is uploaded directly to the cloud and linked to standardized or customized procedures. Ideally, the processes are automated as much as possible, and the customer himself is involved, e.g., in verifying alarm images or alarm sounds.
Customers expect more than just a suitable alarm system from installers. They expect an end-to-end security service from consultation to intervention, regardless of whether it is the police, fire brigade, or private security service, provider. If customers can contribute to an efficient process themselves, e.g., by analyzing an alarm image on their smartphone, they are most likely happy. But if they are prevented from doing so, they need an automatic backup function that performs this task in their place. However, this bypass must only last seconds and delay the processes for danger prevention as little as possible.
Yes, the intervention is ultimately the biggest challenge in complete automation. Unfortunately, police and fire brigades cannot be activated by automatic calls; a security center had to be integrated. With Sitasys chosen as the system supplier for cloud-based alarm transmission, alarm management, and automated alarm service, a strong partner had to be found for the "last mile." With some support, a robust call center of a well-known provider could be won for these tasks. Of course, with bidirectional, automated reporting. All time-critical alarms need to run entirely automatically through the system until they are processed. This is both very safe and very fast. Nowadays, there is no reason for unnecessary manual interventions that slow down the data flow. More so, many control centers suffer from dramatic staffing problems.
Not to be underestimated is the typical installer's wish to receive system data of the alarm systems in real-time and process them to the customers' complete satisfaction within the scope of maintenance and emergency service. This is becoming an intellectual challenge because customers are increasingly operating innovative building technology systems with high automation. Logically, they expect the system performance of the smart devices to be used optimally in the security chain.
Changing perspectives and asking WHY: It's how change starts.
Simply because old processes no longer work. The cloud is the right and sustainable environment for alarm transmission and hazard management systems. IT/server/network and data center specialists take care of the technical processes and ensure continuous operation. Neither installers nor customers want to take care of this themselves. Many smaller control centers are hopelessly overburdened with this. Only the integration of third-party systems, e.g., for intervention control across company boundaries, can be set up quickly and securely. For security experts, the critical question is no longer whether other security chains will also move into the cloud, but only when.