desert-1045893_1920Connaissez-vous le mythe de Sisyphe ? Ce malheureux avait osé défier les dieux de l’Olympe. Pour le punir, Zeus l’exila dans le Tartare et annonça qu’il ne serait libéré que lorsqu’il aurait réussi à faire sortir un énorme rocher d’une dune. Cependant, chaque fois que Sisyphe arrivait au sommet de la dune, il glissait et le rocher retombait. C’est un peu ce que l’on retrouve dans la mise en oeuvre des progiciels de gestion des services.

De nombreuses DSI n’ont pas compris l’impact de la mise en oeuvre d’un tel progiciel. Sans doute par méconnaissance de ce qu’ils sont réellement, ils sont souvent considérés comme des logiciels simplement plus compliqués et plus difficiles à mettre en place… C’est une erreur grave ! En effet, un progiciel à la particularité d’être structurant, surtout s’il se base sur un référentiel tel qu’ITIL. Essayez donc d’intégrer SAP sans changer aucun des processus ni de l’organisation de votre entreprise… À la limite, on pourrait se dire que cette incompréhension n’est pas tellement critique et que beaucoup d’entreprises fonctionnent avec ce type de progiciel sans pour autant avoir changé leur manière de travailler. C’est vrai !  Mais c’est vrai seulement à court terme.

La particularité des progiciels de gestion des services, tels que Remedy, ServiceNow ou HP SM est qu’ils se basent sur les meilleures pratiques de l’industrie informatique, donc sur ITIL. Mais la plupart des entreprises ne fonctionnent pas selon ITIL. Elles utilisent l’aspect marketing d’ITIL, mais en réalité leurs pratiques n’ont pas changé par rapport à l’époque où le progiciel n’était pas utilisé. Dans ce cas, on assiste alors à un cycle basé sur une durée de 5 ans (Sisyphe monte sa pierre) :

  • Première année : le progiciel est mis en oeuvre et de nombreux développements spécifiques sont utilisés. Les différentes équipes de la fourniture des services ne veulent pas changer leurs manières de travailler, il est donc nécessaire de tordre le fonctionnement de l’outil pour qu’il colle à la réalité du terrain. C’est la première grosse erreur : l’outil ne correspond pas à la réalité du terrain, mais aux bonnes pratiques ITIL. Il aurait donc été nécessaire de revoir les pratiques du terrain de manière à les aligner avec ITIL.
  • Deuxième année : certains champs du progiciel ne sont pas utilisés (par exemple la notion de priorité), ils vont donc être dévoyés pour une autre utilisation. Ceci va provoquer une perte de connaissance sur l’utilisation des champs et sur leur finalité. Dans le pire des cas, certains champs qui ne sont pas utilisés actuellement vont le devenir dans une version future, et ils sont ici utilisés pour autre chose.
  • Troisième année : Il commence à être question d’une montée en version, mais le progiciel fonctionne toujours. Par contre les clients internes commencent à demander des services qui ne sont pas prévus. Le développement de nouvelles fonctionnalités s’accélère et s’éloigne de plus en plus des pratiques ITIL. On assiste souvent au développement de processus de changements standards, puis d’un autre processus de changement urgent, puis un nouveau processus de changement normal. En réalité, il ne devrait y avoir qu’un seul et unique processus de gestion des changements.
  • Quatrième année : le progiciel commence à donner des signes de fatigue. La montée en version a été abandonnée, car elle nécessiterait de redévelopper toutes les spécificités qui ont été mises en place. Les pratiques de l’informatique ne sont plus du tout basées sur ce que souhaitent les clients, mais sur ce que le progiciel est capable de faire, ce qui limite beaucoup le champ d’action de l’IT et génère de l’insatisfaction.
  • Cinquième année : le rocher arrive en haut de la dune… et chute ! L’IT jure au grand dieu que ce progiciel était un mauvais choix, car non adapté aux besoins de l’informatique, il est donc décidé de passer à la concurrence et à un logiciel qui « sera vraiment basé sur ITIL ». Le choix est fait et un projet est lancé. Il semble cependant que le progiciel ne corresponde pas exactement à la manière de travailler de l’IT… Ce n’est pas grave, car il est possible de faire du développement spécifique… Retour à la première année !

 

L’erreur qui est effectuée dans ce cas est de se passer d’un spécialiste ITIL. Tous les progiciels de gestion des services sont alignés avec le référentiel de bonnes pratiques. Si l’informatique ne change pas sa manière de travailler, son organisation et ses processus de manière à ce qu’ils collent aux bonnes pratiques alors il faut s’attendre à devoir changer de progiciel tous les 5 ans, dans la douleur, et avec un surcoût énorme. Un expert ITIL va pouvoir vous former et vous expliquer la raison des choix implémentés dans le progiciel, il va aussi vous aider à modéliser vos nouveaux processus et à vous organiser pour éviter cette boucle infernale. Grâce à lui, vous allez pouvoir faire des montées en version sereines et éviter de changer de progiciel tous les 5 ans.