The technical implementation of the supervision is the first phase of a project to set up the supervision of one's own IS or the IS of one's customers. It is done quickly enough, thanks to all the tools provided in ServiceNav (Census, equipment model, service model,...), but it is not enough to produce a quality service.
The monitoring, operation and processing of alerts and incidents remain the major points of supervision and the work of the men and women in charge of operating the supervision is real. It is thus normal to want to follow the work carried out thanks to the supervision tools.
What are the performance indicators to be monitored?
Natively and naturally, the main indicator monitored in monitoring tools is the availability rate of a service, equipment or, even better, of a user service.
It is indeed on this uptime that most of the teams in charge of IS operations are measured.
The availability rate is directly derived from the downtime of the source element.
We must therefore ask ourselves what the components of this downtime are:
⁃ Time of consideration,
⁃ Creation time in the ticketing tool and assignment to the correct resolution group,
⁃ Actual processing of the incident.
It is on the first two points that the activity report provides an answer and a follow-up.
The activity report in ServiceNav
The report is composed of 3 parts that can be activated or not as needed.
Analysis of incidents over the period
The objective here is simple: a macro view of the activity for a customer, the service center (depending on the settings).
The number of critical and warning incidents, the number of incidents that resulted in an acknowledgement or a ticket and the time taken to process them.
8 figures for a quick and easy analysis of the service provided.
For an end customer: does my outsourcer take good care of my infrastructure and equipment? In case of a problem, is it reactive?
For a service center manager: are my teams responsive? Do they open tickets in my ticketing tool to ensure follow-up and possibly billing?
The history
Having the figures for a period is a necessity but being able to put them in perspective with past data and follow the evolution over time is also a strong need.
That is precisely the purpose of this second part of the report!
Up to 12 months of data to see the evolution of the number of incidents, the time taken to respond and the rate of acknowledgment and opening of tickets. All this of course according to the criticality of the incident.
Are my teams improving? Do the different actions taken on the processes have an impact?
What if we went into detail?
It is sometimes essential to understand why an average has jumped, which incident took a long time to be taken into account,...
The list of incidents gives you a list of all the incidents with the start, acknowledgement and end dates. The time of taking into account and the duration of the incident, the action taken....
In short, all the elements necessary for a detailed study.
In conclusion
Out of beta since version 3.14, this report is now fully usable to allow our users to better track their service desk activity or to bring value to end customers by providing metrics on their service excellence.
