Articles reliés

• Module Rapports et statistiques
• Création d'un rapport ponctuel

Introduction

Octopus propose des rapports et statistiques intégrés. Cet article Wiki a été conçu afin de s'orienter sur qu'est-ce qui doit être analysé, par qui et à quel moment.

En premier lieu, il est nécessaire de définir une stratégie de rapports, c'est-à-dire ce qui doit être mesurer et pourquoi. Cette stratégie changera dans le temps; au départ, il vaut mieux ne générer que quelques rapports, qui seront précis avec des objectifs clairs, suivre l'évolution des résultats et élaborer par la suite selon les besoins.

Saisie rigoureuse = rapports intègres

Lors des premières semaines d'utilisation d'Octopus, les intervenants ont à s'adapter au nouvel outil. Leur compréhension et leur aisance évoluent dans le temps, mais l'utilisation peut différer d'un intervenant à l'autre selon la perception de ce qui doit être fait. Ceci aura des conséquences sur le résultat des rapports. Ainsi, il est bon de vérifier si certaines règles d'utilisation importantes dans le contexte de l'organisation sont observées et leur objectif comprit.

Voici quelques exemples :

• La création des requêtes le jour même par le Centre de services (et non le lendemain).
• La prise en charge des requêtes et des tâches par les intervenants qui en ont la responsabilité pour un état à jour.
• L'utilisation adéquate des différents états, incluant la suspension et la mise en attente.
• La documentation suffisante des actions posées dans le journal d'activités.
• Etc.

La nature humaine étant ce qu'elle est, l'utilisation tend à changer imperceptiblement avec le temps. Des précisions ou des ajustements sont parfois nécessaires. Des vérifications régulières et du contrôle de qualité sont recommandés afin de maintenir un standard d'utilisation harmonisé.
Il est possible de documenter des règles simples qui assureront des rapports fiables et qui aideront davantage lorsque les résultats seront analysés.

Contrôle de qualité

Un contrôle de qualité sur la saisie de certains champs donne des pistes sur les faiblesses d'utilisation d'Octopus. La plupart du temps, les intervenants n'agissent pas de mauvaise foi. Une vérification périodique d'un échantillon de requêtes fermées donne une assez bonne idée sur ce qui doit être amélioré; ceci peut être fait globalement ou par intervenant, selon le cas.

Voici des exemples de ce qui pourrait être contrôlé :

Incidents

• Est-ce bien un incident ? Est-ce qu'on différencie bien les incidents des demandes de service ?
• Demandeur et utilisateur sont-ils bien identifiés ?
• Catégorie et sous-catégorie sont-elles exactes, et adaptées à la résolution de la requête ?
• CI en cause est-il celui qui a causé la défaillance ?
• Résolution - l'information saisie dans l'activité de résolution est-elle suffisante et adéquate ?
• SLA dépassé - pourquoi la cible a-t-elle été dépassée ? Peut-on le justifier, ou est-ce parce que la requête a été mal gérée, négligée, etc. ?
• Est-ce que les actions "en suspens" et "en attente" ont été correctement utilisées ?
• Autres.

Demandes de service

• Est-ce bien une demande de service ?
• Demandeur et utilisateur(s) sont-ils bien identifiés ?
• Est-ce que la SR implique plusieurs utilisateurs et aurait-il été préférable de créer plusieurs SR ?
• A-t-on utilisé le bon type de SR ?
• Est-ce que tous les CI impactés ont été reliés dans la SR ?
• SLA dépassé - est-ce que les tâches ont été correctement gérées, documentées, la date d'échéance respectée ?
• Est-ce que les actions "en suspens" et "en attente" ont été correctement utilisées ?
• Autres.

L'important n'est pas de vérifier chaque requête, mais plutôt de ramener les intervenants à une utilisation harmonisée. L'idée est d'identifier sur un échantillonnage les mauvaises tendances d'utilisation et communiquer à l'équipe les correctifs à apporter.

Que dois-je mesurer dans un premier temps?

Pour les personnes qui débute avec Octopus, ou si les rapports n'ont jamais été vraiment exploités, nous suggérons une approche qui permettra d'observer et d'analyser de quelle façon travaille l'équipe.
Ce sont les tendances qu'il faut observer, et ces tendances sont mesurées dans le temps.

Statistiques sur les incidents

Incident > KPI (indicateurs clé de performance)

C’est un incontournable. Ce rapport démontre l’ensemble des indicateurs pour les incidents dans une période donnée. Il est également possible d'appliquer un filtre par site.

Les informations intéressantes à regarder sont :

• Nombre total d’incidents.
• Nombre total d’incidents résolus.
• Incidents résolus avec respect du SLA.
• Incidents résolus sans déplacement (le déplacement doit être saisi dans une activité, le cas échéant).
• Incidents résolus par le Centre de services.
• Incidents rouverts.
• Incidents par priorité.
• Incidents par source.

Incidents par mois

Pour voir le comparatif par mois du volume qui entre et ce qui est résolu, ainsi que le respect des cibles de résolution, afficher le nombre d’incidents (nouveaux, résolus, ouverts ou avec dépassement SLA) et comparer de mois en mois le nombre obtenu. L’analyse de ce rapport peut démontrer : les périodes de l’année qui sont plus occupées, les périodes où il y a moins de personnel pour les traiter (vacances, par exemple) et si on arrive à résoudre les incidents dans les temps requis. 

Le rapport indique toujours des incidents dont la cible de résolution est dépassée (bris de SLA) - l'important est de pouvoir le justifier. Par exemple, en période de vacances, il se peut qu'une réduction de personnel ait un impact sur la résolution des incidents. 

Un trop grand nombre de dépassements pourrait vouloir dire plusieurs choses : l'organisation des façons de faire doit être révisée, les cibles ont été sous-évaluées, autres. Il faut aller analyser plus en détail le déroulement de ces requêtes. 

Statistiques sur les demandes de service

Demande de service > KPI (indicateurs clé de performance)

C’est aussi un incontournable.

Surveillez :

• Nombre total de demandes de services.
• Nombre total de demandes de services résolues.
• Demandes de services résolues avec respect du SLA.
• Demandes de service par type.
• Demandes de service par source.

Demandes de service par mois

Même que ci-dessus. 

Demandes de service par catégorie

Donne une excellente idée des types de demandes de service qui sont le plus utilisés. 

Statistiques sur les problèmes

Problème > CI les plus problématiques

Permet d’identifier les CI sur lesquels il y a le plus d’incidents, donnant ainsi des pistes sur les faiblesses de l’infrastructure.

Feuille de temps des activités

Dans Fichiers / Rapports se trouve un rapport qui se nomme Feuille de temps des activités. Ce rapport indique le nombre d'heures d'effort saisi dans les activités pour un intervenant dans une période donnée. Il faut se rappeler que l'effort est associé à un coût estimé du groupe d'intervention, et permet d'évaluer le coût moyen d'un incident, par exemple, ou le TCO (coût total de possession) d'un actif. La saisie de l'effort, représentant l'effort réel, est aussi nécessaire pour mieux analyser si les méthodes de travail sont efficaces si on le compare à un effort estimé. On détient alors des pistes d'amélioration dans l'organisation du travail, ou si certaines ressources ont besoin de formation, etc. 

Il est aussi possible d'inscrire les efforts mis dans des tâches administratives internes qui ne touchent pas les incidents, SR, problèmes ou changements, tels que des réunions, des formations, des réunions. Une SR interne peu être créer avec une tâche pour chaque intervenant, permettant d'inscrire les efforts mis sur les activités administratives de l'équipe. 

L'objectif premier de saisir l'effort est de mesurer l'efficacité de l'organisation en tant que service. L'analyse des efforts au niveau de l'individu est subjective; par exemple, certains intervenants vont travailler sur les incidents / SR les plus simples et les plus rapides à résoudre, tandis que d'autres seront stimulés par les requêtes ayant un taux de difficulté plus élevé. On cherche avant tout à mesurer le service, et non l'individu. Les intervenants, tout comme les gestionnaires, doivent comprendre la portée de saisir l'effort dans Octopus, et les bénéfices qui en découlent dans l'amélioration du service.

Conclusion

Ne pas perdre de vue les objectifs fixés, tels que :

• Améliorer les façons de faire.
• Être capable d'exposer et de transmettre les performances de l'équipe informatique.
• Avoir en main les arguments pour l'embauche de personnel additionnel.
• Faire évoluer les besoins en rapports à mesure que l'équipe s'améliore.
• Etc.