Gestion de tickets informatiques

L’event log de gestion de tickets informatiques est un log mis à disposition lors du Business Process Intelligence Challenge 2014 (BPI’14)4_{. Il est composé d’incidents liés à}

des perturbations du service IT d’une institution financière. Chaque incident est associé à une ou plusieurs interactions représentant les appels et e-mails reçus par les agents du service IT par rapport à l’incident. Lorsqu’un incident est notifié, il est assigné à un opérateur, qui soit le prend en charge et le résout, soit le réassigne à un autre opérateur plus qualifié. Pour chaque incident, plusieurs attributs sont enregistrés, tels que :

— Service Component WBS : le numéro d’identification du composant concerné par l’incident.

— Configuration Item : le type du composant concerné par l’incident ; e.g., ordi- nateur, serveur, application. Chaque service component WBS appartient à un seul configuration item.

— Impact : l’impact de la perturbation sur l’activité du client ayant rapporté l’inci- dent. La valeur de l’impact va de 1 à 5.

— Closure code : un code qui classe la cause de la perturbation ; e.g., erreur utilisa- teur (user error ), problème logiciel (software error ) ou problème matériel (hardware error ).

Chapitre 7

— Causedby : représente le composant à l’origine de la perturbation du composant concerné par l’incident.

— Number of interactions : le nombre d’appels et e-mails reçus par le service IT relatifs à l’incident.

— Number of reassignements : le nombre de fois où l’incident a été réassigné d’un opérateur à un autre.

Nous avons transformé le log pour grouper les events en fonction de leur numéro de service component WBS. Une trace est donc composée des incidents dans lesquels un composant est impliqué. Nous définissons le label des incidents par la concaténation des attributs closure code et causedBy, séparé par le caractère ’|’. Le log généré contient 944 activités distinctes et 313 traces d’une longueur moyenne de 93 events, la trace la plus petite et la trace la plus longue ayant respectivement 2 et 3595 events.

No error - works as designed | WBS000073: utility: 4/4 frequency: 4/4

User manual not used | WBS000073: utility: 7/7 frequency: 5/6

Software application | WBS000073: utility: 1164/1262 frequency: 1/89

No error - works as designed | WBS000095: utility: 14/17 frequency: 12/15

Data | WBS000095:

utility: 428/431 frequency: 399/402 User error | WBS000095:

utility: 62/63 frequency: 60/61

Figure 7.2 – Les deux LPMs avec le plus haut profit extraits depuis le log BPI’14 en utilisant l’attribut number of interactions dans la fonction de profit.

Supposons un analyste avec le besoin d’analyser les fragments de comporte- ments responsables d’un grand nombre d’appels et d’emails reçus par le service IT. Pour répondre à cette question, nous formulons la fonction de profit suivante : fe_{(events(L), events(Γ}

L,LPM)) = P_{g∈events(ΓL,LPM)}πnumber _of _interactions(g). L’extraction

des HU-LPMs sur cet event log prend 3 minutes, sur une machine équipée d’un processeur Intel i7 2,4GHz et 16Go de RAM.

Nous présentons dans la Figure 7.2 les deux HU-LPMs avec les plus hauts profits extraits à partir de ce log. Le premier HU-LPM a un profit de 1175, indiquant que les fragments de comportement représentés par ce HU-LPM expliquent 1175 des appels et e mails reçus par le service IT. Au total, 1262 appels et e-mails reçus sont associés à des incidents avec un closure code lié à une application logicielle (software application) et causés par le composant W BS000073, parmi lesquels 1164 représententent des events rejouables dans le LPM. Dans le log, il y a 89 incidents avec ce closure code et causé par le même composant, et un seul d’entre eux est rejouable dans ce HU-LPM. Cependant, il est à lui seul responsable des 1164 interactions sur les 1262 observées. Enfin, le HU- LPM se termine avec un incident ayant un closure code indiquant que le composant n’a pas d’erreur et fonctionne correctement (No error - works as designed ). Cela signifie que l’application possède une fonctionnalité qui marche normalement d’après le service IT mais perçue comme défaillante par les utilisateurs de l’institution, causant beaucoup de trafic dans le système de ticketing du service IT. Parce qu’un seul incident software application | WBS000073 est rejouable dans le HU-LPM, nous pourrions dire que le HU- LPM décrit une anomalie plus qu’un comportement. Il est à noter que l’extraction de ce type d’anomalies est le résultat de la fonction de profit que nous avons définie, qui permet l’analyse de profits inégalement répartis entre les différents events.

Section 7.1

Le second HU-LPM montre un fragment de comportement similaire , mais concerne les incidents causés par l’application logicielle d’un serveur W BS000095. Ce HU-LPM a un profit de 504, ce qui signifie qu’il décrit au total 504 appels et e-mails reçus par le service IT. Le HU-LPM montre que sur 61 erreurs utilisateur (user errors), 60 sont éventuellement suivies d’un incident avec un closure code indiquant que le composant n’a pas d’erreur et fonctionne correctement (No error - works as designed ). Ces 60 incidents ensemble génèrent 62 interactions avec le service IT. Il est à noter que 399 des incidents liés à cette application logicielle, responsable de 428 interactions avec le service IT, se terminent aussi avec un incident avec le même closure code.

Dans les deux HU-LPMs présentés, nous constatons que deux composants, le W BS000073 et le W BS000095, sont responsable de la majorité des appels et e-mails reçus par le service IT. De plus, pour chacun d’entre eux, il se trouve que la perturbation rapportée n’en est pas une, ce qui indique que de tels incidents pourraient être empêchés.