Our client is a world leader in security solutions. They offer a wide range of solutions to numerous sectors and customer segments, from small businesses to large industrial complexes.

One of its most prominent services is the Operations Centre, also known as SOC, which aims to provide cutting-edge and differentiating solutions through the use of the most innovative technologies and continuous monitoring of its customers.
 

Challenge

The SOC managed by our customer is responsible for receiving and managing the fault notifications in the monitoring devices they have installed. Within the notification management process, there is an operator who decides where to send the notification.

This notification can be sent to a room technician who tries to solve the problem remotely, or to a field technician who solves the problem by physically moving to the location of the damaged device.

The fact that a SOC operator makes an incorrect dispatch decision comes at a cost to our client. An example of a wrong decision could be the case of dispatching a field technician when the fault could be resolved remotely.

Solution

ANALYSIS OF INFORMATION AND DATA SOURCES

Of the three data sources originally received, we concluded that only one would be relevant, which is the information available to the operator at the time of decision making. This matter allowed us to simplify both the data collection and the generation of the model itself.

During the analysis, some variables were identified as having very high percentages of null values, which allowed us to initiate processes to refine and improve the data collection for these variables.
On the other hand, the data analysis led us to suspect that there might be mislabelling in some cases as field or room incidents, which hindered the subsequent learning process.

DETAILED ANALYSIS OF THE DATA COLLECTED

The "top 10" list of installations, panels and locations that have generated the most technical incidents. In the case of installations and locations, no relevant or representative patterns were found. Although we saw that the set of incidents of the 10 panels for which we have the most technical incidents represents more than 50% of the total number of incidents. In other words, more than half of them were concentrated in just 10 panels, if, in the first iteration, we had around 7,500 incidents. It might make sense to study and analyze this subset in more detail and try to generate a model that focuses only on these 10 panels (and, therefore, it is valid only for them). In the end, this was the solution. 

PREDICTIVE MODEL

We worked to improve the predictive model by restricting the individual variables available at the time of the operator's decision.
After several iterations testing different datasets, variable sets and different learning methods we found that the result we get with the current data is around 66% reliability.
However, looking at the results obtained in the descriptive analysis, we opted to work with the "top 10" subset of panels discussed above to get more reliable models.
 

Results

In order to provide field operators with a solution that will help them in their decision-making process, we created an interface in which the operator first enters the data of an incident and immediately receives a prediction on the evaluated incident with an associated reliability percentage.

Before starting the incident evaluation system, the operator decided that approximately 50% of the incidents could be resolved in the room (remotely) and the other 50% by physically bringing a technician to the incident place. In this regard, the number of incorrectly dispatched incidents was approximately 30%. 

Once the system we proposed was set up, the operator started to follow his criteria when selecting where to send an incident. The result was that the number of incidents sent incorrectly had been reduced to 10%. This implied a cost-saving for our client.