Home » Posts tagged 'implémentation'

Tag Archives: implémentation

ITIL – Les raisons d’échec dans votre organisation

Souvent la mise en oeuvre des meilleurs pratiques ITSM basées sur ITIL ne produit pas les bénéfices espérés. Nous analysons ici les raisons d’échec des « projets d’implémentation ITIL » parmi les plus courantes. Mais est-ce vraiment ITIL qui est en cause? N’est-ce pas plutôt votre organisation? Essayons de garder un esprit ouvert et d’analyser objectivement les choses.

ITIL : les raisons de l'échec d'implémentation des meilleurs pratiques ITSM dans votre Organisation
Crédit © AdobeStock & Zinkevych 2018

Tout d’abord il faut bien se souvenir de ce qu’est ITIL. ITIL est un cadre de bonnes pratiques pour l’amélioration des services informatiques dans l’entreprise. ITIL n’est pas prescription. Ce n’est pas une méthodologie. C’est simplement un ensemble des meilleurs pratiques recensées dans le monde entier au fil des ans. Ces pratiques se déclinent au travers de processus répartis dans les 5 phases du cycle de vie des services. Elles sont par essence génériques. Ils faut bien évidemment les avoir comprises et surtout avoir compris quels sont les objectifs visés. Ensuite elles doivent être adaptées au cas spécifique de chaque entreprise avant d’être mises en oeuvre. Et c’est là que se produit en général le problème. Nous l’avons d’ailleurs décrit dans deux articles précédemment publiés sur notre blog : ITIL – 5 erreurs majeures de mise en oeuvre et ITIL – 6 autres erreurs de mise en oeuvre.

ITIL : un constat d’échec dans beaucoup d’organisations

Il est clair que le cadre de bonnes pratiques ITIL, vieux maintenant d’une trentaine d’années, a largement fait ses preuves. Pourtant bon nombre d’organisations font un constat d’échec après avoir vainement tenter d’améliorer la qualité de leurs services IT en s’appuyant sur la bibliothèque de meilleures pratiques d’AXELOS. Les résultats ne sont souvent pas à la hauteur de leurs attentes.

Quelques constats entendus chez mes clients

Nous cherchions à réduire les coûts de notre informatique. Ce n’est pas l’objectif d’ITIL. L’objectif est d’améliorer la création de valeur pour les clients.

Nous avons investi dans un outil censé être « certifié » et cela nous a coûté très cher. Dans le meilleur des cas l’outil a coûté cher mais n’a rien amélioré du tout. Dans le pire des cas l’outil a coûté cher et notre informatique est encore moins performante qu’avant.

On a investi un gros budget dans la formation de tous les membres de l’équipe informatique mais rien n’a vraiment changé. Normal, on a formé les gens sur le niveau Foundation dont l’objectif est d’apprendre les concepts et le vocabulaire. C’est très insuffisant pour mettre en oeuvre quelque chose d’aussi complexe.

On a fait appel à un consultant à qui on fait entière confiance car il est certifié ITIL expert. Ca nous a coûté très cher mais tout ce qu’il a fait a échoué. Normal, les bonnes pratiques en gestion des services IT s’appuient sur une co-réalisation entre les métiers et la DSI. Généralement un « Expert ITIL  » est un informaticien, expert dans la maîtrise des processus ITIL sur le domaine de la DSI. Normal donc que cela échoue car il faudrait qu’il soit aussi un praticien certifié au minimum avec une grande expérience business..

Une même raison à ces échecs

Tous ces échecs ont donc une bonne raison. Mais cette raison ne se trouve pas au sein même des pratiques ITIL. Cette raison est toujours liée à la façon dont on a voulu les mettre en oeuvre, sans vraiment en comprendre les enjeux. Souvent cela aboutit à alourdir le fonctionnement de l’organisation et à lui ôter toute possibilité d’agilité. C’est là un comble car c’est ce dont les organisations ont le plus besoin en 2018!

Essayons donc de comprendre ce qui a bien pu se passer pour conduire à cette situation.

Les raisons de l’échec de la mise en oeuvre d’ITIL

Vous utilisez ITIL comme des recettes de cuisine

La première, et sans doute une des plus courantes, raison de l’échec de la mise en oeuvre est de considérer les publications ITIL comme des livres de recettes de cuisine. Ce n’est pas non plus l’évangile. C’est juste un guide et un cadre de bonnes pratiques. Or, dans certaines organisations, certains responsables, à un certain niveau, vraiment emballés par l’idée qu’ITIL pourrait être la solution à leurs problèmes, essaient de mettre en œuvre toutes les directives des livres. Cette approche ne fonctionnera jamais!

ITIL a été créé dans les années 1980 par l’agence centrale d’informatique et de télécommunications du gouvernement britannique. Il n’a jamais été conçu pour devenir un produit exclusif qui serait commercialisé et vendu. Le projet initial était censé rassembler les meilleures pratiques pour contribuer à ce que le gouvernement considérait comme une dépendance croissante à l’égard des technologies de l’information, combiné à un manque de pratiques standard entraînant une augmentation des coûts et des erreurs.

Si ITIL s’est ensuite développé dans les entreprises privées c’est tout simplement parce que cela fonctionne. Mais hélas, pas comme beaucoup d’organisations le pensent.

ITIL fonctionne parce qu’il inclut les meilleures pratiques du domaine. Mais il s’agit simplement d’un cadre. Il ne doit pas être suivi étape par étape. Ce n’est pas une méthode!

Le meilleur moyen de faire en sorte qu’ITIL fonctionne dans votre entreprise est d’adopter les directives et les pratiques qui conviennent à votre entreprise et d’oublier le reste. Cela signifie qu’il faut d’abord bien comprendre le contexte de l’entreprise, sa stratégie business et la capacité des ressources dont elle dispose, que ce soit au niveau humain, financier ou matériel. Il est donc indispensable que le projet de mise en oeuvre des pratiques préconisées soit le résultat d’une collaboration profonde et efficace entre la haute direction, les directions métiers et la DSI. Il ne s’agit pas d’un projet strictement « informatique » comme beaucoup le croient.

Vous vous focalisez beaucoup trop sur les processus

ITIL V3 décrit 26 processus organisés en cinq étapes de cycle de vie des services. Chaque étape du cycle de vie est décrite dans une publication spécifique – Stratégie des services, Conception des services, Transition des services, Exploitation des services et Amélioration continue des services.

Les descriptions de processus d’ITIL V3 incluent des exemples de flux d’activités typiques. Par exemple, la description de la gestion des changements comprend un diagramme intitulé «Exemple de flux de processus pour un changement normale». Mais bien que les livres contiennent beaucoup d’autres excellents contenus, les exemples de flux de processus semblent avoir acquis leur vie propre. Ils sont clairement identifiés comme des exemples de la manière dont vous pourriez effectuer le travail. Or il existe une fâcheuse tendance à les considérer comme des étapes obligatoires: « ITIL dit que c’est comme ça qu’il faut faire ». FAUX! Ce n’est pas du tout ce que les auteurs, à l’origine, voulaient dire.

Il y a aussi un second problème. La conception de services ITIL décrit «les quatre piliers de la conception de services»: personnes, processus, produits (services, technologie et outils) et partenaires (fournisseurs, fabricants et vendeurs). Or, la quasi-totalité de la littérature publiée concerne les processus. Il y a très peu de conseils sur les personnes, les produits et les partenaires.

Cette insistance sur les processus peut conduire à de très mauvaises utilisations ITIL. Certaines organisations se contentent de documenter les processus et pensent avoir dès lors « implémenté » ITIL! D’autres organisations se concentrent sur quelques processus spécifiques et sont souvent déçues des résultats. Certes on ne peut pas tout mettre en oeuvre mais certaines pratiques ne créent de la valeur qu’associées avec d’autres. Il est donc essentiel de les mettre en oeuvre ensemble. Séparément elles ne créeront pas beaucoup de valeur, voire même elles contribueront à la détruire.

Vous mettez en oeuvre les bonnes pratiques en SILOS

Lorsque les organisations adoptent ITIL V3, elles considèrent souvent chacun des processus comme un ensemble d’activités distinct. Chaque processus a flux d’activités et ces flux sont indépendants les uns des autres. Par contre, les activités nécessaires pour créer de la valeur pour nos clients payants dépendent rarement du bon fonctionnement d’un seul processus en particulier. Le plus souvent, pour satisfaire les clients, nous avons besoin d’une combinaison d’éléments issus de plusieurs processus. Par exemple, la résolution d’un problème qui affecte les utilisateurs d’un service peut nécessiter des activités provenant de:

  • La gestion des incidents pour diagnostiquer les incidents remontés par des utilisateurs individuels et proposer des solutions de contournement,
  • Mais aussi la gestion des problèmes pour analyser les causes sous-jacentes et élaborer des solutions à long terme,
  • Sans oublier la gestion des actifs de service et de la configuration pour fournir les informations nécessaires à la gestion des incidents et des problèmes (notamment pour évaluer les impacts),
  • Ni la gestion financière pour  allouer un budget pour pouvoir développer une solution,
  • Bien sûr la gestion de la disponibilité et la gestion de la capacité pour analyser des solutions alternatives et formuler des recommandations,
  • Ainsi que la gestion des mises en production et du déploiement pour planifier le déploiement d’un correctif logiciel ou d’un composant matériel,
  • Sous le contrôle de la gestion des changement pour évaluer, approuver et surveiller le déploiement du logiciel,
  • Avec le support de la coordination de la conception pour superviser la conception et le développement d’une solution,
  • Et potentiellement beaucoup plus…

Lorsque chacun de ces processus a son propre flux d’activités vu de façon indépendante, cela peut entraîner des délais très longs. Nous l’avons d’ailleurs décrit dans un de nos précédents articles: Les changements à l’heure de DEVOPS. Les très bonnes organisations comprennent comment gérer le flux d’activités entre plusieurs processus. Hélas, ITIL V3 ne fournit pas assez de conseils pour aider les autres à bien faire les choses. En réalité, la V3 ne préconise pas de créer un flux d’activités distinct pour chaque processus. Mais c’est l’approche la plus simple à adopter. C’est donc celle que de nombreuses organisations ont mis en place dans le cadre de leur «implémentation d’ITIL».

Vous n’incluez pas les métiers dans la mise en oeuvre

Les mots ITIL et ITSM commencent par «IT» mais cela ne signifie pas qu’elles ne s’appliquent exclusivement qu’à «des initiatives purement informatiques».

Les équipes informatiques ne peuvent plus travailler en silo et implémenter une ITSM basée sur ITIL sans obtenir l’assentiment de tous les membres de la direction ou de toute personne extérieure au département informatique. C’est une recette imparable pour aboutir à une catastrophe. Le service informatique interagit avec le reste de l’entreprise. Il vous faut donc déterminer ce dont les métiers ont besoin pour réussir. Il faut ensuite déterminer la capacité de l’informatique à répondre à ces besoins. C’est ensuite seulement que l’ITSM peut vous aider

Si vous souhaitez réussir à tirer le meilleur parti d ITIL vous devez arriver à l’expliquer de façon compréhensible pour la haute direction. Mais faites attention, ils ne parlent ni le jargon ITIL ni le jargon informatique. Vous devez donc comprendre comment cela peut être bénéfique pour l’entreprise et être capable de le formuler en « termes commerciaux ». C’est à dire que vos arguments doivent porter sur les trois axes qui les intéressent : bénéfices, risques et ressources. Si vous réussissez à le faire, alors vous aurez le soutien et l’investissement des dirigeants. C’est la seule façon de pouvoir démarrer et réussir votre projet.

L’inclusion d’objectifs métier et la compréhension de la valeur métier par la DSI aideront votre équipe et votre entreprise à adopter ITIL afin de faciliter l’obtention de résultats. C’est bien là l’objectif!

Vous n’avez pas créé une feuille de route et un cas d’affaire pour l’adoption et l’adaptation d’ITIL

L’ITSM et ITIL ne concernent pas uniquement la mise en œuvre de processus pour avoir des processus. Trop d’organisations se concentrent tellement sur la mise en œuvre de processus qu’elles ignorent en quoi ces processus sont nécessaires pour atteindre l’objectif général.

L’objectif est de fournir des services qui apportent une valeur ajoutée à l’entreprise.

Créer une feuille de route et la relier à la valeur métier engendrée vous aidera à adopter les bonnes pratiques ITIL afin de prendre en charge les services et de ne pas mettre en œuvre des processus pour le plaisir de les mettre en œuvre.

Si vous êtes trop rigide et que vous essayez de tout mettre en œuvre en même temps sans autre raison que ce que vous estimez devoir faire, votre équipe résistera. C’est pourquoi tant de professionnels de l’informatique pensent que ITIL est trop bureaucratique. Un de mes clients me décrivait récemment ITIL « comme un monstre de bureaucratie« .

De même, si vous lancez de manière aléatoire certaines approches dans certains projets, personne ne sera en mesure de reconnaître en quoi ITIL améliore votre flux de travail.

Une feuille de route étape par étape vous donnera une idée précises de ce que vous devez faire pour adapter ITIL à vos besoins.

Vous pensez qu’un « bon » outil sera la solution à vos problèmes

Il existe beaucoup d’outils prétendument conçus pour aider à adopter ITIL et ITSM par les organisations.

Mais un outil ne va pas comprendre la valeur de l’informatique ni son incidence sur les résultats de votre entreprise. Un outil ne pourra pas comprendre les besoins spécifiques de chaque entreprise.

Un outil est juste un dispositif utilisé pour exécuter une fonction particulière. Les outils peuvent vous aider dans l’adoption des bonnes pratiques mais ils ne vont certainement pas faire le travail à votre place. Un outil vous servira seulement à automatiser certaines activités de vos processus et permettra la communication entre les activités. Vous devez donc faire tout le travail d’adaptation des bonnes pratiques à votre organisation d’abord. Ensuite vous pourrez regarder sur le marché pour trouver l’outil qui correspond le mieux à vos besoins spécifiques.

Vous n’investissez pas assez dans le conseil et la formation

Il existe de nombreux organismes  de formation proposant des cours ITIL Foundation. De nombreux professionnels de l’informatique réussissent leur certification ITIL. Les mêmes se présentent immédiatement comme des consultants ou des formateurs ITIL. Malheureusement une certification ne garantit absolument pas que vous sachiez appliquer les concepts ITIL.

La vérité est que tout le monde peut lire un guide de l’étudiant et apprendre les concepts ITIL, mais cela ne les mènera pas très loin, pas plus que leur organisation d’ailleurs. Comme nous l’avons dit, ITIL est un guide et non un évangile. Vous devez donc comprendre son impact et son intégration dans votre organisation. La seule façon de le faire est d’investir dans le cours de base ITIL avec un instructeur expérimenté qui peut montrer aux étudiants comment appliquer ITIL dans leur organisation. C’est pourquoi AXELOS préconise de suivre des formations auprès d’ATOs (Accredited Training Organizations) qui sont régulièrement auditées pour vérifier la qualité de leurs formations, bien au delà de la simple certification.

De même, de nombreuses organisations commettent l’erreur d’adapter ITIL sans aucune assistance qualifiée. Cela peut fonctionner pendant un petit bout de temps mais, sans aucun doute, au final le quotidien l’emportera et l’adoption échouera. Le résultat sera alors une perte d’argent et de temps sans retour sur investissement. Un consultant qualifié peut aider à éviter les erreurs courantes et à augmenter la vitesse d’adoption. Par contre un consultant qualifié aura un coût qu’il faut intégrer dans le cas d’affaire de votre projet. Ne vous focalisez pas uniquement les coûts mais essayez de voir la véritable création de valeur que peut vous apporter chaque consultant.

Conclusion : ITIL V4 résoudra-t-il vos problèmes?

ITIL V3 contient de très bons conseils, et de nombreuses organisations l’ont utilisé pour les aider à fournir des services informatiques de manière efficace. Toutefois, certaines faiblesses doivent être résolues pour lui permettre de rester pertinent dans un environnement technologique et commercial en rapide mutation. Il doit aider les organisations à créer une culture plus collaborative capable d’éliminer les silos de processus. Il doit prendre en charge les méthodes de travail modernes, en maintenant de bons processus. Mais il doit le faire en mettant davantage l’accent sur les personnes, la technologie et les fournisseurs.

Si votre entreprise a adopté ITIL V3 et trouve que cela fonctionne bien pour vous, vous n’avez pas besoin de jeter ce que vous avez fait, ni d’apporter des changements soudains et radicaux à votre gestion de l’informatique. Mais vous pensez probablement déjà aux changements que vous devez faire, en raison de l’évolution de votre culture organisationnelle et de l’environnement dans lequel vous opérez. Lors de la publication d’ITIL 4, vous constaterez que la version mise à jour est une excellente ressource pour aider votre organisation à réfléchir aux changements que vous devez faire et à la meilleure façon de les apporter. ITIL V4 vous aidera à réussir la difficile transformation numérique de votre organisation.

 

Crédits : Stuart Rance et Doug Tedder

ITIL – 6 autres erreurs de mise en oeuvre

Après la publication de notre article intitulé ITIL – 5 erreurs majeures de mise en oeuvre, nous vous proposons 6 autres erreurs parmi les plus importantes et les plus courantes commises pendant dans la phase d’implémentation.

ITIL - 6 autres erreurs de mise en oeuvre ou comment chaque erreur d'implémentation des meilleurs pratiques ITSM peut conduire votre organisation à l'échec
Crédit © Photo 5000 – 2018

Dans un précédent article, j’ai décrit cinq façons différentes de mal utiliser ITIL :

  • Vouloir absolument « implémenter » ITIL,
  • Se focaliser seulement sur les processus,
  • Miser sur un nouvel outil de gestion des services informatiques (ITSM) p
  • our résoudre tous les problèmes,
  • Démarrer la réalisation de projets (ou de programmes) volumineux et trop longs à générer de la valeur,
  • Et enfin assigner une personne pour chaque rôle.

Dans ce nouvel article, je propose six autres erreurs parmi les plus courantes dans le cadre de la mise en oeuvre des bonnes pratiques ITIL. Bien sûr je vous indique également ce que vous pouvez faire pour les éviter.

Il n’est pas nécessaire d’avoir lu mon précédent article. Cependant il peut vous aider à mieux comprendre tout ce qui pourrait empêcher votre organisation de tirer pleinement parti des avantages offerts par ITIL.

Il existe donc six autres façon de mal comprendre et de mal utiliser ITIL.

Erreur N° 6 : Mettre en place des SLA pour de mauvaises raisons

Un accord de niveau de service (SLA) est un accord signé entre un fournisseur de service et son client. C’est donc un « contrat » entre deux parties sur la fourniture d’un service dans lequel le fournisseur prend des engagements. La différence entre un SLA et un contrat c’est que dans le cas d’un SLA les deux parties peuvent appartenir à la même organisation. Il n’y a donc généralement pas de clause juridique dans un SLA. Cependant, tout comme un contrat, le SLA contient une description du service, ainsi que les mesures et objectifs convenus. Ce sont ces objectifs qui seront utilisés pour mesurer et consigner dans quelle mesure le fournisseur fournit le service.

Les accords de niveau de service sont des outils utiles pour formaliser la relation entre deux parties prenantes. Les conseils de meilleures pratiques ITIL suggèrent qu’ils sont très utiles. Toutefois, certains fournisseurs de services informatiques pensent que s’ils respectent les mesures du contrat de niveau de service, ils ont alors fait tout ce qui était nécessaire. Malheureusement, les SLA sont souvent rédigés par le service informatique avec très peu ou pas de participation des clients. Trop souvent, les clients sont totalement insatisfaits, même lorsque tous les paramètres SLA ont été respectés.

Les mauvaises raisons pour la mise en oeuvre des SLA

Le premier cas consiste à mettre un SLA en place à l’initiative du département informatique afin de montrer aux métiers que l’informatique est performante malgré leur mauvais ressenti. Les indicateurs et les métriques sont alors élaborés dans ce sens. Au final le client est toujours insatisfait, mais en plus il s’aperçoit qu’on a essayé de le tromper. Cela n’améliorera pas la relation.

A l’inverse, le SLA peut également être mis en oeuvre à l’initiative des clients qui ne sont pas satisfaits du service. Ils veulent ainsi démontrer de façon tangible que les services délivrés par le département informatique sont de mauvaise qualité. Le risque c’est qu’alors, afin de satisfaire les clients, le département informatique accepte des engagements de niveau de service irréalisables. Cela est souvent dû à un manque de ressources ou à une prise de risque trop importante.

La bonne approche pour les accords de niveau de service

Si vous avez convenu d’un accord de niveau de service avec votre client, il est important de respecter les engagements que vous avez pris. Mais il est bien plus important encore de satisfaire les besoins réels du client, même s’ils sont difficiles à mesurer et à consigner. Les clients sont tout à fait capables de vous dire ce qu’ils ressentent vraiment si vous leur demandez. Un accord de niveau de service peut être un outil utile si vous souhaitez fournir de bons services. Par contre, il est beaucoup plus important de parler à vos clients et de vous assurer qu’ils sont satisfaits de ce que vous livrez. C’est là l’objectif de la gestion de la relation client dont l’implémentation doit être réalisée en parallèle de la gestion des niveaux de service. Malheureusement, c’est rarement le cas dans les entreprises que j’ai pu conseiller.

Erreur N° 7 : Oublier les attentes des vrais clients de l’informatique

J’ai travaillé avec de nombreuses organisations informatiques constituées de groupes cloisonnés (on parle de silos) qui ne comprennent pas comment ils s’intègrent dans une chaîne de valeur globale. Chaque groupe effectue simplement le travail qui lui est assigné de la manière la plus logique. Il n’a aucune idée de la manière dont cela contribue à la création de valeur pour les clients payants. Cela aboutit le plus souvent à des activités inefficaces et peu rentables, qui n’apportent aucune valeur réelle pour l’organisation ou ses clients.

Il y a de nombreuses années, un manager très sage m’a dit: « Je veux que vous arrêtiez ce que vous faites au moins une fois par jour et que vous vous demandiez: « Si les clients payeurs savaient qu’ils finançaient cette activité, que ressentiraient-ils? « . C’est un exercice fabuleusement simple que tout le monde peut faire. Et cela aide vraiment les gens à se concentrer sur la création de valeur pour les clients réels.

Une autre façon d’éviter les comportements cloisonnés consiste à rassembler des personnes appartenant à différentes équipes informatiques. Par exemple, organisez un atelier où les participants font un suivi détaillé de leur travail. L’objectif est de voir comment chacun contribue à la réalisation des objectifs généraux. Un exercice comme celui-ci peut aider à identifier les principales opportunités d’amélioration. En effet, il indique les domaines dans lesquels il ya un gaspillage important et où certaines équipes peuvent difficilement obtenir des résultats.

Erreur N° 8 : S’intéresser uniquement à la transition et à l’exploitation

Certaines personnes pensent qu’ITIL conseille uniquement sur la gestion des incidents, des problèmes et des changements. Ces éléments sont importants, certes, mais ils ne peuvent en aucun cas suffire à créer de la valeur pour vos clients. Si vous ne gérez pas le cycle de vie complet du service, il manquera des éléments essentiels.

ITIL 2011 décrit très précisément le cycle de vie des services qui est composé de 5 étapes :

  • La stratégie de service consiste à comprendre les marchés, à engager le dialogue avec les clients, à définir une orientation, à définir un portefeuille de services et à gérer les finances nécessaires pour offrir la valeur requise.
  • La conception de services consiste à collecter des exigences détaillées et à concevoir tout ce qui est nécessaire pour que les services nouveaux ou modifiés répondent aux besoins des clients.
  • La transition de service consiste à concevoir, créer le service nouveau ou modifié, à s’assurer qu’il est adapté à son usage et à son utilisation, et à le mettre en production tout en gérant les risques associés.
  • L’exploitation du service consiste à garantir que le service continue de fournir la valeur attendue aux clients et aux utilisateurs.
  • L’amélioration continue du service consiste à surveiller et à améliorer tout ce que vous faites dans l’informatique, pas seulement les processus, mais également les services, les compétences, la conception de l’organisation, les rapports, etc.

La mise en oeuvre de chacune de ces phases est absolument nécessaire dans votre implémentation ITSM. A défaut il y aura des « trous dans la raquette » et vos ne satisferez pas les besoins de vos clients. Est-ce vraiment le cas donc votre organisation?

Erreur N° 9 : L’Obsession d’avoir des mesures positives

Les praticiens ITSM comprennent l’importance de mesurer ce qu’ils font. Les métriques sont idéales pour signaler les tendances et pour déclencher des actions. Mais dès que la métrique devient l’objectif, peu importe la qualité de ces métriques, elles cessent d’avoir du sens.

La loi de Goodhart (du nom de l’économiste Charles Goodhart) dit que « lorsqu’une mesure devient une cible, elle cesse d’être une bonne mesure« . Cela est aussi vrai dans l’ITSM que dans l’économie. Si vous dites à quelqu’un que sa prochaine augmentation de salaire dépend de l’obtention d’un indicateur spécifique, fera tout ce qui est nécessaire pour que ce objectif soit correct. Mais cet objectif correspond-il vraiment à ce que vous ou votre client souhaitez qu’il fasse.

Une chose que je fais toujours lorsque je définis des indicateurs de performance clés (KPI) est de demander: «Quel comportement les gens adopteront-ils pour s’assurer que cet indicateur de performance clé est respecté?». C’est souvent suffisant pour me dire que l’indicateur causera un comportement que je ne veux pas encourager. C’est donc un indicateur que je ne devrais PAS mesurer ni signaler. Deux questions sont essentielles. Vos clients sont-ils satisfaits des métriques que vous utilisez? Et savez-vous quels types de comportement sont induits par vos indicateurs de performance clés?

Erreur N° 10 : Déléguer l’amélioration continue à quelqu’un d’autre

Certaines organisations ignorent complètement en quoi consiste l’amélioration continue. D’autres désignent un responsable de l’amélioration continue. Alors le plus souvent,  tous les autres présument qu’ils ne sont pas obligés de participer, car «c’est le travail de quelqu’un d’autre».

C’est bien d’avoir un responsable de l’amélioration continue qui facilite et encourage l’amélioration continue. Mais cela suppose que tout le monde s’attende à assumer la responsabilité de certains aspects de l’amélioration continue. Il est essentiel que chaque processus, chaque service, chaque technologie, chaque équipe et chaque individu contribue à une amélioration continue. Et cela ne peut être fait que par des personnes qui connaissent, comprennent et s’approprient ce qui doit être amélioré.

Par exemple, je pense à mes propres compétences et à mon expérience et j’identifie les choses que je peux faire pour améliorer. Il peut s’agir de lire un livre ou un blog, d’assister à un cours de formation, de travailler avec un mentor, de télécharger et de essayer un outil logiciel, etc.

Erreur N° 11 : Investir uniquement sur des formations ITIL de base

Il existe de nombreux cours de formation ITIL Foundation et de nombreux professionnels de l’informatique réussissent leur certification ITIL. Malheureusement ces cours ne permettent pas, le plus souvent, de faire progresser la compétence de leurs étudiants. Nombreux sont ceux qui deviennent des professionnels certifiés ITIL mais ne savent absolument pas comment appliquer les concepts ITIL.

La vérité est que tout le monde peut lire un guide de l’étudiant et apprendre les concepts ITIL. Malheureusement cela ne les mènera pas très loin, pas plus que leur organisation. ITIL est un guide et non un évangile. Vous devez donc comprendre son impact et son intégration dans votre organisation. La seule façon de le faire est d’investir dans le cours de base ITIL Foundation avec un instructeur expérimenté qui peut montrer aux étudiants comment appliquer ITIL à leur organisation. Mais surtout, vous ne devez pas vous limiter à apprendre par coeur des concepts du vocabulaire (ce qui est l’objet du cours Foundation).

Vous devez approfondir ces concepts et apprendre à les mettre en pratique. C’est l’objet des formations Intermediate Capability et du niveau Practitioner. Dans la réalité peu de professionnels de ‘ITSM (moins de 5%) suivent ces cours et obtiennent les certifications correspondantes. Ils restent donc sur le bord de la route à parler de sujets qu’ils ne comprennent pas en profondeur. Lorsqu’ils essaient de les mettre en oeuvre, l’échec est souvent au bout de la route.

En conclusion…

ITIL peut être extrêmement utile si ses concepts sont soigneusement adoptés et adaptés. Et si vous envisagez de l’utiliser pour soutenir votre organisation, rien ne remplace la réflexion sur ce que vous faites. Évitez les erreurs que j’ai décrites dans cet article. Adoptez et adaptez avec soin les meilleurs pratiques. Dès lors, vous et vos clients obtiendrez une réelle valeur ajoutée grâce à ITIL. Parlez nous de votre expérience!

La version Française du Guide de mise en oeuvre COBIT 5 est disponible

Ca y est enfin!! Le guide « COBIT 5 Mise en oeuvre » est désormais disponible en Français. De longues semaines d’investissement personnel de l’équipe de traduction auront été nécessaires. Il n’est jamais simple de traduire un guide de bonnes pratiques ou de mise en oeuvre. L’Anglais est une langue typiquement orientée « business » et donc assez rigoureuse. A l’opposé, le Français est une langue plus orientée vers la littérature ou la diplomatie et dans laquelle, soit les termes anglais n’ont pas d’équivalent ou, pire encore, sont le plus souvent traduits par des termes erronés (les fameux faux-amis sur lesquels tous les élèves ont trébuché pendant leur parcours scolaire).

COBIT 5 Mise en Oeuvre

Bon, en ce qui concerne cette publication, l’honnêteté nous impose d’admettre que ce n’est pas réellement une version Française. C’est plutôt une version Québécoise, car réalisée par l’équipe du chapitre (tiens, encore un mot qui n’a pas d’équivalent direct en Français) ISACA de Québec, avec seulement deux contributions externes, l’une d’un expert en Gouvernance de Montréal (toujours au Québec) et l’autre de votre serviteur, seul Français (encore que résident en Côte d’Ivoire) à avoir participé à la préparation de cette version Française.

Les raisons d’une absence totale de la France

Mais pourquoi donc une version Française dans laquelle aucun Français (de France) ne s’implique? La question mérite d’être posée. Les réponses sont multiples et malheureusement assez désespérantes:

  • Une incompréhension totale, en France de ce que sont la Gouvernance et le Management, et donc un intérêt très faible pour le sujet,
  • Une mauvaise interprétation de la notion de création de valeur, comprise uniquement comme une valeur financière et focalisée majoritairement sur une réduction des coûts,
  • Un contexte légal basé sur un modèle hérité à la fois de systèmes monarchiques et « communistes » qui conduit irrémédiablement à la destruction de valeur au lieu de la création, qui ne favorise pas l’adoption du cadre COBIT,
  • Des structures organisationnelles et gouvernementales ne permettant pas de séparer la gouvernance du management,
  • Une culture, une éthique et des comportements inadéquats (particulièrement visibles en France en cette période électorale),
  • Une gouvernance et une gestion anarchique de l’information conduisant à des excès et induisant des conséquences catastrophiques,
  • Une technologie mal utilisée et mal exploitée pour la création de valeur et laissée entre les mains de techniciens et d’ingénieurs,
  • Un modèle éducatif et une gestion de la formation continue déconnectés des réalités et des besoins des organisations.

Nous reviendrons plus en détail sur ces raisons avec un autre article dans les prochains jours. Cependant les lecteurs connaissant COBIT® 5 auront reconnu là des faiblesses au niveau des facilitateurs (en Anglais on les nomme « enablers » ce qui est beaucoup plus fort que  facilitateur mais n’a pas de traduction littérale) d’une bonne gouvernance et d’un management efficaces qui manquent cruellement à la France.

A cela, il faut bien rajouter, mais peut-on encore leur en vouloir après ce que nous venons de dire, une absence totale de volonté de l’AFAI (chapitre Français de l’ISACA) de s’investir de quelque façon que ce soit dans la promotion de COBIT® 5 qui n’assure pas, aujourd’hui, compte tenu du modèle économique imposé par ISACA HQ, un bénéfice suffisant pour les membres Français. Or, en France, il est d’usage que la création de valeur s’évalue au niveau personnel et non au niveau d’une organisation. En d’autres termes, si je participe à ces travaux, qu’est-ce que j’y gagne personnellement?

Le marché pour une version Française des bonnes pratiques

La Francophonie compte aujourd’hui un peu moins de 280 millions de personnes dans le monde, réparties de la façon suivante (source: organisation internationale de la Francophonie)

  • environ 8% en Amérique du Nord (majoritairement au Canada)
  • 37% en Europe (majoritairement en France)
  • près de 54% en Afrique (où la culture et les institutions sont calquées sur la France, héritage de la colonisation)
  • autour de 1% dans le reste du monde.

Qu’est-ce qui fait la différence entre le Canada (ou plus précisément le Québec) et les pays francophones européens et africains? J’apporterai deux réponses:

  • La culture nord-américaine fortement ancrée au Canada, intégrant les bonnes pratiques de Gouvernance et de Management largement répandues dans cette partie du monde,
  • Des lois imposant l’usage de modèles intégralement francisés dans les organisations Québécoises, ce qui n’est pas le cas en Europe, ni en Afrique francophone.

Il est donc clair que l’environnement légal favorise l’adoption des bonnes pratiques décrites par COBIT 5 au Canada et qu’au contraire l’environnement local défavorise et décourage les bonnes pratiques basées sur COBIT 5 en Europe et en Afrique Francophones.

Il apparaît ainsi clairement que le marché pour une traduction Française du cadre COBIT 5 et de son guide de mise en oeuvre se situe majoritairement en Amérique du Nord. C’est donc fort logiquement que ce sont les Québécois qui font l’effort. Malheureusement, cela décourage encore un peu plus les Français d’adopter COBIT 5 et de s’appuyer sur le guide de mise en oeuvre pour lancer des initiatives d’amélioration de la Gouvernance et du Management car ils voient ces pratiques comme étant issues de la culture Américaine. De plus ils considèrent que le Québécois n’est pas le Français tel qu’il est parlé en Europe et en Afrique. Et ce n’est pas faux…

 COBIT 5 Mise en Oeuvre – Juste une référence indispensable

La publication de la version française du guide de mise en oeuvre vient complèter le référentiel et le modèle de référence des processus COBIT 5 déjà traduits par la même équipe qu’il convient de féliciter pour leur excellent travail.

Toutefois, il faut bien rappeler que ce guide ne décrit pas la mise en oeuvre du cadre de gouvernance et de management COBIT 5 mais la mise en oeuvre des sept facilitateurs soutenant la gouvernance et management de l’information dans l’Entreprise. Il s’agit en fait de la méthodologie extrêmement efficace et efficiente de gestion d’un programme de mise en oeuvre ou d’amélioration continue, décrite par COBIT et basée sur trois composants hérités des normes et bonnes pratiques du marché :

  1. l’amélioration continue en sept étapes (similaire à ITIL)
  2. la facilitation du changement (héritée des bonnes pratiques de Change Management)
  3. la gestion de programme et de projets (issue de PRINCE2, PMBok et M_o_P)

Gageons que la version Française du guide de mise en oeuvre sera une aide efficace pour les utilisateurs francophones et sera un réel succès.

Implémentation d’ITIL: bien commencer

Implémentation d'ITIL - Raisons d'échecL’implémentation d’ITIL dans votre organisation n’est pas une partie de plaisir. Lorsque vous envisagez de mettre ITIL en œuvre, les premières questions qui vont inéluctablement se poser seront où commencer? Comment dois-je commencer? Qu’est-ce que je cherche à atteindre? Quelles informations me sont nécessaires pour y arriver, quelles personnes dois-je impliquer, et que doit produire ce projet?

Si vous ne disposez pas des réponses complètes à vos questions, votre implémentation d’ITIL va inéluctablement échouer. Nous allons dans cette série d’articles essayer d’identifier les causes d’échecs et vous donner quelques conseils pour pouvoir les éviter.

Implémentation d’ITIL, ça veut dire quoi?

Tout d’abord il est important de souligner qu’on n’implémente pas ITIL®. ITIL® est un référentiel de bonnes pratiques de gestion des services informatiques, publié par AXELOS®, basé, dans sa version 2011, sur les 5 étapes du cycle de vie des services, et couvrant 25 processus et 4 fonctions. Il est totalement impensable, même pour une très grande Entreprise, de tenter d’implémenter la totalité des bonnes pratiques décrites dans les cinq publications de base d’AXELOS®. De plus cela ne ferait absolument aucun sens. L’objectif est de décider, en accord avec les orientations portées par le Conseil d’Administration de l’Organisation et traduites en stratégies par le Comité de Direction, qu’est-ce qui pourrait, parmi les 25 processus et les 4 fonctions décrits dans ITIL®, améliorer le soutien de l’informatique au Business et lui permettre d’atteindre plus facilement les objectifs fixés par les stratégies de l’Entreprise. L’informatique a un rôle de « facilitateur » mais elle ne crée pas de valeur directe pour les parties-prenantes. Ca c’est le rôle des métiers de l’Entreprise.

Prenons le cas, par exemple, d’une banque. Tous les services bancaires s’appuient sur l’informatique qui est un élément clé du fonctionnement quotidien de la banque. Lorsque l’informatique s’arrête, la banque est dans l’impossibilité totale de délivrer ses services à ses clients. Cependant l’informatique ne crée aucune valeur directe pour la banque. L’informatique PERMET aux directions métiers de la banque d’élaborer des services financiers qui seront ensuite vendus aux clients de la banque et créeront de la valeur pour les parties-prenantes. Les véritables créateurs de valeurs sont les directions métiers qui vont « embarquer » des services informatiques dans les services qu’elles vendent et délivrent à leurs clients. Il est donc important que le département informatique soit en permanence aligné avec les besoins des directions métiers et en même temps suffisamment flexible pour leur permettre, dans un environnement extrêmement concurrentiel de créer de nouveaux services financiers afin de rester leaders sur leur marché en fonction des attentes nouvelles des clients.

Donc on implémente seulement des processus et des fonctions les plus indispensables pour permettre à l’Entreprise de créer de la valeur, c’est à dire ce qui est strictement nécessaire dans le cadre des stratégies de l’Entreprise. La décision relève donc des mêmes personnes en charge de valider les stratégies de l’Entreprise et « comptables » (Accountable) des ressources notamment humaines et financières de l’Organisation devant les parties-prenantes. C’est à dire que la décision se prend au niveau du Conseil d’Administration. Ce ne doit jamais être une décision prise par le DSI, ce qui conduirait inévitablement le projet à l’échec après avoir dépensé en pure perte beaucoup de temps, d’argent et gaspillé les ressources humaines disponibles au détriment d’autres projets plus importants. C’est la raison pour laquelle il est important de mettre en place une Gouvernance du SI et d’établir une stratégie informatique claire et validée.

Pour les processus et les fonctions, dans la mesure où il existe des bonnes pratiques reconnues de façon universelle pour la fourniture des services informatiques, on pourra bien sûr s’appuyer utilement sur ITIL®. Seul bémol, les processus et les fonctions ne suffiront pas. Il va également falloir travailler sur les ressources humaines et notamment leurs compétences techniques, bien sûr, mais, plus important encore, leur aptitude à adopter un comportement adéquat basé sur l’éthique de l’Organisation et la création d’une véritable culture du service. Et cela ne fait pas partie directement du périmètre d’ITIL® version 2011 même si les changements culturels et organisationnels sont effleurés dans la publication sur la transition des services.

Où commencer?

La première étape consiste à commencer par faire le constat d’un besoin de mise en oeuvre ou d’amélioration de la fourniture des services informatiques aux métiers de l’Entreprise et à obtenir le consentement à une telle initiative. Il faut cerner les points sensibles et les déclencheurs actuels, et créer un véritable désir de changement au sein de la haute direction.

Il est important de ne pas se focaliser uniquement sur comment on va s’y prendre mais de bien définir ce qui doit être fait pour soutenir les stratégies de l’Entreprise. Ce qui doit être fait doit entrer dans un cadre d’amélioration continue de l’Organisation en vue de créer davantage de valeur en alignement avec les stratégies de l’Entreprise et s’appuyer sur des points sensibles (« là où ça fait mal ») pour le business ou bien des déclencheurs tels que le remplacement de membres du Comité de Direction ou bien le résultat d’un audit externe ou bien encore un changement important sur notre marché ou une nouvelle exigence légale ou réglementaire à laquelle on ne pourra pas échapper. Les points sensibles sont des points de douleur ressentis par l’Entreprise vis à vis de son département informatique tels que par exemple l’incapacité de l’informatique à répondre favorablement à des demandes de nouveaux services IT correspondant à un besoin marché ou bien la perception par le business que la qualité des services IT qui lui sont livrés ne sont pas en adéquation avec ses besoins et sont finalement beaucoup trop chers comparativement à la valeur qu’ils permettent de créer.

Dans tous les cas il va falloir sensibiliser le top-management sur ces aspects pour arriver à transformer le besoin d’agir, dont tout le monde est bien conscient au niveau de l’Entreprise, en désir de changement en vue d’obtenir un sponsoring par au moins un des membres du Comité de Direction pour pouvoir lancer un pré-projet. Nous appellerons cette phase incontournable la « facilitation du changement ». C’est seulement lorsque vous aurez un sponsor pour ce projet que vous pourrez le démarrer, et cela commencera toujours par l’élaboration d’une ébauche de business case. Il s’agit d’un projet comme n’importe quel autre et il devra être géré comme tel, en s’appuyant sur une méthodologie de projet, comme par exemple PRINCE2®.

L’étape suivante se concentre sur la définition de la portée de l’initiative de mise en oeuvre ou d’amélioration et la mise en correspondance des objectifs de l’entreprise, des objectifs liés à l’informatique et des processus IT connexes, et en tenant compte des scénarios de risque qui pourraient également mettre en évidence des processus clés à cibler. Pour réaliser cela, on pourra utiliser par exemple la cascade d’objectifs décrite par COBIT® 5 et expliquée dans notre article sur la stratégie informatique.

Des diagnostics de haut niveau seront également utiles pour cerner la portée du projet et comprendre les domaines à prioriser. Une évaluation de l’état actuel doit ensuite être effectuée, de même qu’une évaluation de l’aptitude des processus existant pour cerner les problèmes ou lacunes. Les initiatives à grande échelle doivent être structurées sous forme d’itérations multiples du cycle de vie ne dépassant pas chacune une durée de six mois maximum. En effet, pour toute initiative de mise en oeuvre s’échelonnant sur plus de six mois, il existe un risque d’essoufflement, de perte de concentration et de démotivation des parties prenantes qui risque fort de conduire votre projet à l’échec.

Notre prochain article traitera des points suivants :

  1. Comment s’y prendre?
  2. De quoi ai-je besoin pour réussir une telle initiative?

Pour plus d’informations ou pour vous inscrire à notre newsletter, merci de compléter le formulaire de contact :

COBIT® is a trademark of ISACA® registered in the United States and other countries.
ITIL® is a registered trade mark of AXELOS Limited.
PRINCE2® is a registered trade mark of AXELOS Limited.

Catégories

Archives

Calendrier

mars 2019
L M M J V S D
« Fév    
 123
45678910
11121314151617
18192021222324
25262728293031
%d blogueurs aiment cette page :