Une Approche Pragmatique de la Gestion de la Performance IT

[avigneras]

Une Approche Pragmatique de la Gestion de la Performance IT

Avec l'adoption mondiale des processus de Gestion des Services IT basés sur ITIL comme référentiel de bonnes pratiques, les DSI sont í  la recherche de façons de mesurer les entrées, le déroulement et les sorties des processus ITSM.
Les mesures sont essentielles pour l'amélioration continue des Niveaux de Service IT et de la satisfaction client.

En conséquence, les projets de Gestion de la Performance IT ou les projets ITIL de reporting sur les KPI figurent désormais sur l'agenda de nombreuses DSI.

Au cours des dernières années, des livres ont été écrits sur les métriques ITSM et les KPI ITIL.
La plupart de ces livres contiennent des définitions des KPI, des métriques et des Facteurs Clés de Succès.

Bien que cette documentation soit précieuse, la plupart de ces livres restent encore théoriques. Ce qui manque dans ces livres sont les sujets pragmatiques telles que la relation avec les applications ITSM, les fréquences de mesure, la «faisabilité » des métriques, les relations entre les indicateurs (indicateurs guides et indicateurs témoins) et les interdépendances entre les indicateurs.

Dans cet article, nous aborderons ces sujets et donnerons au lecteur une approche pragmatique sur la Gestion de la Performance IT.

Fréquence de Mesure
Les métriques sont inutiles si vous ne pouvez pas mesurer fréquemment. La gestion de la performance c'est identifier les tendances afin de déterminer les points d'améliorations. Comme il faut vingt points de données pour établir une tendance statistiquement fiables, des mesures mensuelles pourraient être acceptables pour les "cycles de reporting des parties prenantes", mais í  peine suffisant pour exécuter n'importe quel type de programme d'amélioration.
Malheureusement, de nombreux livres parlent des KPI comme devant être produits í  intervalles mensuels ce qui, par expérience, n'a rien ou peu í  voir avec la Gestion de la Performance et de la mise en œuvre des cycles d'amélioration continues.

Pour gérer un programme d'amélioration, les organisations devraient viser des mesures quotidiennes analysées sur 7, 14 et 28 jours en exploitant des sommes ou des moyennes pour établir les tendances quotidiennes, filtrer les "résultats accidentels" et amener l'organisation í  prendre des mesures correctives.

Afin de pouvoir mesurer tous les jours, les données doivent être disponibles dans nos applications ITSM. Ce qui nous amène au second point.

Faisabilité
Les KPI définis í  partir de la théorie sont définis sans savoir quelles applications ITSM sont utilisées et comment ces applications ITSM sont configurées et personnalisées.
Cela pourrait aboutir í  un ensemble de KPI certes plus «souhaitables » pour l'entreprise, mais pas nécessairement "réalisables".
Sans un accès facile í  des données fiables, ces mesures ne peuvent souvent être produites qu'avec un exercice manuel intensif et sujet í  l'erreur humaine. La fréquence de ces mesures est une fois par mois au maximum, laissant l'entreprise dans le flou et frustrée parce qu'elle n'a ni tendances fiables ni d'aperçu réel sur la façon d'améliorer ses performances.

Un bon point de départ d'un programme de Gestion de la Performance IT est un ensemble de KPI réalisables en fonction du type d'applications ITSM que votre organisation utilise et la façon dont les applications ITSM sont configurées et personnalisées. Les indicateurs «souhaitables » peuvent servir de feuille de route sur la façon dont ces applications pourraient être modifiées í  l'avenir, mais ne doivent pas servir de point de départ.

Les Relations entre les Indicateurs : Indicateurs Guides et Indicateurs Témoins
La gestion de la performance couvre la notion d'indicateurs «guides » et d'indicateurs «témoins ». Les indicateurs témoins mesurent les résultats et décrivent la performance passée, alors que les indicateurs guides mesurent les activités et sont de bons indicateurs de la performance future.

Prenons l'exemple de la perte de poids. La perte de poids est une métrique facile í  mesurer. Nous pouvons nous fixer un objectif et tout simplement monter sur une balance et comparer notre poids actuel par rapport í  notre poids cible. Comme notre poids actuel n'est pas un indicateur de notre poids futur, la perte de poids est considérée comme un «indicateur témoin ». Il est le résultat de notre alimentation et de nos activités physiques des jours précédents.
Les indicateurs guides pour la perte de poids sont le «nombre de calories avalées » et le «nombre de calories brûlées ». Ces indicateurs mesurent les activités qui ont un impact sur notre probabilité de perte de poids et sont de puissants indicateurs de notre poids futur. Malheureusement, ces indicateurs guides sont souvent plus difficiles í  mesurer.

C'est également vrai pour les métriques IT. Un objectif commun pour de nombreuses DSI est de maximiser le pourcentage d'incidents résolus dans le cadre fixé par le SLA.
Il s'agit de manière évidente d'un KPI témoin car il mesure le résultat des activités passées.

Comment pouvons-nous déterminer les indicateurs guides?
Nous devons nous demander quelles activités de notre équipe informatique influence ce KPI.
Peut-on mesurer ces activités?

Cela pourrait conduire aux indicateurs guides suivants :

• Pourcentage d'incidents non mis í  jour dans les dernières 48 heures.
• Pourcentage d'incidents ouverts il y a plus de 48 heures
• Croissance de la charge de travail (incidents nouveaux / incidents clos)
• Délai moyen pour résoudre les incidents

Ces indicateurs guides sont de bons indicateurs du respect ou non-respect des SLA í  venir.
Les KPI guides sont les indicateurs de performance que les DSI devraient mesurer quotidiennement afin de comprendre leurs tendances et mettre en œuvre l'amélioration continue.

Interdépendances
La clé de la réussite des programmes d'amélioration consiste í  fixer des objectifs réalistes et comprendre sur quels KPI se concentrer et í  quel moment se concentrer sur ces mêmes KPI.

Un exemple : Le temps moyen pour résoudre les incidents est un indicateur guide pour un pourcentage de ticket résolus dans le cadre fixé par le SLA. Toutefois, ce n'est pas toujours un mauvais signe quand cet indicateur augmente temporairement.

Voici pourquoi : Dans la première phase de votre programme de performance vous fixerez des métriques de référence pour déterminer des objectifs réalistes. Neuf fois sur dix, le point de départ d'un programme de Gestion de la Performance IT est l'analyser de votre charge de travail concernant les incidents ouverts.

• Quel est le volume de cette charge de travail ?
• Est-il structurellement en croissance, stable ou en régression ?
• Quel est l'âge moyen des incidents dans la charge de travail ?
• Qui travaille sur les incidents ?
• Quel est le pourcentage d'incidents ouverts depuis plus de X jours ?
• Quel est le pourcentage d'incidents pour lesquels il n'y a pas eu d'activité depuis X jours ?

Une fois que vous avez une mesure quotidienne pour ces indicateurs de performance clés et que vous pouvez analyser 30 jours de données, vous pouvez identifier les points d'amélioration. Les points d'amélioration communs sont : certains groupes d'affectation ne passent pas assez de temps sur la gestion des incidents et ont de vieux travaux en cours, simplement trop d'incidents sans activité pendant 48 heures, ou la charge de travail est structurellement en croissance ce qui indique que vous êtes en sous-effectif ou que votre personnel n'est pas assez formé.

L'objectif premier est de réduire ou de stabiliser la charge de travail. Lorsque les DSI réussissent cela, ils ferment des incidents qui ont été ouverts pendant une longue période et cela entraîne une évolution négative de certains autres indicateurs importants tels que : le «temps moyen de résolution des incidents » et «le pourcentage d'incidents résolus dans les délais du SLA".

Lorsque vous fermez des incidents plus anciens, ces indicateurs sont affectés négativement. Bien sûr il s'agit d'une situation temporaire.
Il est important de comprendre et de réfléchir í  ces dépendances. Sans cette compréhension, les DSI prennent le risque de se focaliser sur les mauvais indicateurs et risquent d'en tirer des conclusions erronées.

C'est pourquoi nous pouvons identifier quatre grandes phases pour le succès des implémentations de Gestion de la Performance IT :
Phase 1 : Fixer les Mesures de Référence
Au point de départ, vous devez créer au moins une tendance de vingt points de données pour chaque indicateur. Sur la base de la tendance de ces vingt points de données, vous pouvez analyser la volatilité et fixer des objectifs réalistes fondés sur la performance réelle. Au cours de cette phase, on identifie souvent des gains rapides pour réduire la charge de travail. L'objectif de cette phase est de mesurer les «activités » des membres de la DSI avec les indicateurs guides et changer leur comportement, pour fonctionner sur la base de métriques et ainsi que vous puissiez espérer de futurs résultats.

Phase 2: Réduire les Heures de Production Perdues
Une fois que les indicateurs de la phase 1 sont stables, vous devriez voir les premiers résultats. Maintenant, il est temps de commencer í  se focaliser sur l'amélioration de la perspective de l'IT par le client et optimiser la charge de travail interne. Les indicateurs comme la Durée Moyenne de Réparation (MTTR), le temps de réponse, le temps de prise en charge et d'assignation d'un incident sont devenus très importants. L'objectif de cette phase est d'optimiser le temps total du cycle de résolution des incidents.
En conséquence, les «heures de production perdues » causées par des incidents sont réduites et un plus grand pourcentage d'incidents sont résolus en respectant le SLA.

Phase 3: Devenir Innovant
Une fois que les indicateurs de la phase 2 sont stables, commencez í  vous concentrer sur le transfert de temps et de ressources des «activités réactives" aux "activités proactives ». Combien de temps consacrer í  la résolution des incidents par rapport aux travaux sur les changements. Plus les DSI passent de temps í  travailler sur les changements, plus l'environnement informatique est stable et plus les capacités d'innovation de la DSI se développent. Un plus grand nombre de changements devrait conduire í  des interruptions de services moins nombreuses, mais des changements mal mis en œuvre pourrait également conduire í  des interruptions de service supplémentaires. L'objectif devrait être d'avoir un processus de changement efficace et stable. Les indicateurs importants pour améliorer sont le pourcentage des changements urgents et le pourcentage des incidents urgents tout en conservant la stabilité des indicateurs de la phase 1 et 2.

Phase 4: Relever la Barre
Une fois que les indicateurs de performance clés de la phase 3, de la phase 2 et de la phase 1 sont tous stables, il est temps de relever la barre : fixer de nouveaux objectifs réalistes (améliorations 5-10%) basés sur la performance historique, aiguiser votre SLA, et en faire plus avec moins de personnel IT. Dans cette phase, vous pouvez commencer í  communiquer vos KPI avec toutes les parties prenantes IT, y compris les clients puisque vous êtes maintenant devenu une DSI de prédiction qui est capable d'améliorer en permanence sa performance. Ce nouveau niveau de transparence permettra d'améliorer encore la satisfaction du client et de vous permettre de devenir un partenaire de confiance.

Bénéfices
Les bénéfices d'un programme de Gestion de la Performance IT pour des processus ITSM réussi sont les suivants :

1. Forte réduction du nombre d'heures de production perdues pour l'entreprise
2. Plus forte orientation client par le personnel IT et une satisfaction client améliorée
3. Amélioration du processus décisionnel par les DSI
4. Amélioration de la maîtrise des risques
5. DSI devenant plus innovantes
6. Amélioration de la transparence et accroissement du moral des équipes

 
 

Merci í  Karel van der Poel pour son retour d'expérience.

Si vous souhaitez des conseils personnalisés ou de plus amples informations sur votre Gestion de la Performance IT, n'hésitez pas í  nous laisser vos coordonnées (agathe.vigneras[at]imakumo.fr).