Manuel d'implémentation › Exemples d'étude de cas › Exemples de modélisation de données › Etude de cas 8 : Performance du centre d'assistance

Etude de cas 8 : Performance du centre d'assistance

Voici un cas d'étude typique sur la performance du centre d'assistance.

Considérant la source de données affichée ci-dessous :

La source de données affichée ci-dessus liste en détails des tickets du centre s'assistance, tickets gérés pour chaque client aux différents emplacements où le client opère. Un emplacement unique peut également être partagé entre plusieurs clients.

Lors de l'utilisation de cette source de données, les trois conditions suivantes sont requises pour générer un rapport :

• % de tickets de priorité 1 résolus dans les quatre heures pour le client CM3.
• % de tickets de priorité 1 résolus dans les quatre heures pour le client CM3 à chaque emplacement.
• % de tickets de priorité 1 résolus dans les 24 heures pour le client CM3 à chaque emplacement.

Les conditions requises susmentionnées indiquent que les événements doivent être filtrés par :

• priorité
• client
• emplacement

Vous devez spécifier quel critère de filtration doit être converti en type d'événement et lequel en ressource appropriée.

Comment puis-je sélectionner un type d'événement ?

Des trois critères de filtration requis, la priorité du ticket est le plus à même à être converti en type d'événement, ce pour les raisons suivantes :

• Il décrit le type d'événement en cours de traitement (ticket de priorité 1).
• Le nombre de priorités existantes est relativement restreint (priorité 1, 2, 3).
• Le type d'événement lui-même est relativement constant (le centre d'assistance ne change que rarement la priorité selon laquelle le ticket est traité).

Comment puis-je sélectionner une ressource ?

Les deux autres critères de filtre requis, client et emplacement, sont les plus petites entités nécessitant un rapport. Par conséquent, la ressource est la combinaison du client et de l'emplacement.

Le client et l'emplacement sont des entités relativement fixes et qui ont un cycle de vie défini, de sorte que les nouveaux clients ou emplacements puissent être ajoutés. En outre, la relation entre un site et un client peut changer.

Il est également possible d'utiliser plus d'un champ depuis la source de données à des fins de conversion. Tandis que le champ de serveur des études de cas précédents était traduit en une ressource CA Business Service Insight, la ressource dans ce cas est la combinaison de deux champs. Chaque permutation produit par conséquent une nouvelle ressource.

La liste de ressources est affichée ci-dessous :

La ressource de sortie est une combinaison des champs client et emplacement qui utilise le symbole "+" pour les combiner. Il est important d'être conscient du nom de la ressource car il est extrait de la source de données et apparaît plus tard dans les rapports. Les capacités de génération de rapports doivent répondre aux attentes.

Remarque : Une des erreurs les plus courantes lors de la modélisation d'un centre assistance, ticket ou système d'incidents et de définir un seul incident comme ressource.

Les suppositions suivantes sont incorrectes et mènent souvent à des erreurs :

1. L'unique incident est celui qui est signalé. Ne définissez pas l'entité à signaler comme entité pour laquelle les calculs sont générés, de sorte que ce seul incident ne soit pas la base des calculs pour le site du client. En général, le SLA se base sur la performance globale et non la performance spécifique du traitement de ticket.
2. La garantie s'effectue par niveau de ticket. Il s'agit d'une erreur car les garanties sont périodiques, ce qui est calculé est une agrégation dans le temps.

Paramétrage des allocations pour les ressources

Pour la première condition de calcul :

1. % de tickets de priorité 1 résolus dans les quatre heures pour le client CM3.
   • Les événements de tickets attribuables à un client spécifique doivent être reçus. Le client fait partie de cette Ressource qui indique également le site du client. Il existe par conséquent deux options pour capturer tous les événements liés aux ressources et attribuables à ce client :
   • Dans les cas où le client de la source de données représente un contractant, les ressources peuvent être attachées au contractant approprié. Cela permet l'enregistrement par contractant. Lorsqu'elle est possible, cette solution est toujours préférable.
   • Créer un groupe de ressources pour chaque client de la source de données et y grouper toutes les Ressources appropriées. En utilisant cette méthode, l'enregistrement se fait par groupe de ressources.

   Concernant les deux conditions de calculs suivantes :

2. % de tickets de priorité 1 résolus dans les quatre heures pour le client CM3 à chaque emplacement.
3. % de tickets de priorité 1 résolus dans les 24 heures pour le client CM3 à chaque emplacement.

Vous devez, pour ces conditions, regrouper les Ressources en groupes de ressources. Les métriques nécessitent d'être groupées car les calculs doivent être faits individuellement pour chaque site.

Remarque : Même si les allocations de ressources pour le modèle actuel et les conditions ne sont pas nécessaires, il est important de les créer en gardant à l'esprit de futures conditions requises. Cette procédure permet d'éviter les frais généraux au cours développement futur du système.

Choisir le champ Horodatage

Comme indiqué précédemment, l'horodatage est très important dans la manière dont le Moteur de corrélation traite les Evénements. Les métriques calculent toujours le niveau de service par période, et les événements qui sont traités dans cette période sont ceux dont l'horodatage tombe dans la période.

Dans la première étude de cas, la source de données n'avait qu'un champ de temps. Cette fois, le cas comporte trois champs pouvant être paramétrés comme horodatage. Examen des deux premiers enregistrements :

Le calcul du temps de résolution requiert le temps Date d'ouverture et Date de résolution. Pour les besoins de l'événement, il est possible de n"y attacher qu'un horodatage. Vous pouvez alors utiliser l'autre comme valeur dans les champs de valeur.

Si la valeur Date d'ouverture est utilisée comme horodatage, le ticket est inclus dans les résultats de décembre. Si la valeur Date de résolution est utilisée comme horodatage, alors le ticket est inclus dans les résultats de décembre. Les deux options sont viables. La sélection doit simplement indiquer où les tickets doivent s'afficher dans les rapports.

Il s'agit d'un point très important à considérer durant l'implémentation car il détermine quand les événements sont utilisés pour des calculs. Par exemple, si un ticket est levé en novembre mais n'est pas clôturé avant décembre, quand doit-il contribuer au résultat de SLA ? Est-il inséré dans les données de novembre ou de décembre ?

Dans ce cas, puisque que le ticket n'est signalé à la source de données qu'une fois clôturé, vous ne pouvez capturer les données qu'une fois le ticket clôturé. La date de clôture se situe généralement après les dates d'ouverture et de résolution. Dans le cas où la date d'ouverture a été choisie pour être l'horodatage, celui-ci doit être traité comme faisant partie des résultats de décembre. Le fait que la date de clôture était en janvier signifie que le ticket a été rapporté une fois décembre passé. Les résultats de décembre avaient donc déjà été publiés. Le moteur de corrélation remarque alors que l'événement est au passé car l'horodatage appartient à décembre, il déclenche ainsi de nouveaux calculs. Par conséquent, les résultats de décembre changent rétroactivement.

Ces conséquences doivent être parfaitement comprises afin de pouvoir définir quel champ de temps doit être choisi comme horodatage. Généralement, la date de clôture est choisie afin d'éviter que les rapports finaux ne changent rétroactivement.

En revanche, l'utilisation de la date de clôture comme Horodatage permet de disposer de davantage de temps pour entrer des calculs. Un ticket résolu ne peut être clôturé que bien plus tard.

Sachez toutefois que cette utilisation de la date de clôture pourrait également déclencher un processus dans l'organisation qui accélère le temps de clôture des tickets.

La dernière suggestion est alors :