ITSM… La guerre des standardsVendredi 23 Octobre 2009
Différents référentiels, différents éditeurs… et différentes perceptions de l’IT Service Management
Amélioration du service client (27%) et réduction des coûts informatiques (22%).
Fin 2008, selon une étude d’IDC pour HP Software, c’étaient les deux principales priorités du responsable informatique. Elles le sont toujours. La crise a confirmé la tendance: plus de concurrence et moins de ressources…
De là, l’intérêt croissant pour l’ITSM (IT Service Management) dont la vocation est de permettre d’automatiser, au travers d’un moteur de workflow, des processus (incidents, problèmes, changements…), de suivre les engagements de services et de fournir les tableaux de bords… Dans ce contexte, le centre de service (Service Desk) devient SPOC (Single Point of Contact); il devient le principal utilisateur des outils d’ITSM qui vont lui permettre de recevoir et enregistrer tous les appels, de traiter les demandes conformément aux SLA, d’assurer l’interface avec les opérationnels, de suivre les demandes et les incidents, d’informer les utilisateurs, de produire les métriques permettant le suivi des utilisateurs, etc. Reste à sélectionner la solution. Et, ensuite, à la déployer -un processus souvent long et complexe dans la mesure où il doit s´interfacer avec plusieurs autres entités du système d´information.
Si ITIL est -de loin- le premier référentiel ITSM, d’autres existent comme Agile, ISO, CMMI ou PRINCE2 pour ne citer qu’eux. De là une certaine confusion. Le 6 octobre 2009, l’ITSMF Luxembourg l’a rappelé explicitement en centrant sa cinquième conférence annuelle sur «la guerre des standards»….
Exemple, l’ISO/IEC 20000 apparue pour donner un cadre (en 13 processus dont les 11 d’ITIL) et fixer des exigences minimales, tout en apportant une dimension stratégique. Cette certification atteste non seulement d’une haute qualité des services informatiques dans l’entreprise, mais surtout d’une démarche constante visant à améliorer son niveau. ITIL plus ISO/IEC 20000. Ou ITIL plus… Plusieurs combinaisons sont possibles. Ainsi, eBRC a fait le choix d’associer ITIL et PRINCE2. Les deux référentiels partagent un certain nombre de points: justification business, approche par processus, vocabulaire commun client/utilisateur… N’empêche, ITIL reste la référence. Parce que son développement et ses révisions périodiques sont réalisées par un groupe d’experts indépendants des fournisseurs, explique Dimension Data. Autre atout: il n’est pas nécessaire d’adopter chacune des parties du référentiel pour augmenter les bénéfices y afférents; certains experts vont même jusqu’à recommander une approche progressive, par étapes.
ITIL est également le choix des grands acteurs de l’ITSM. Dont HP. Pour ses spécialistes, les organisations qui s'intéressent à ITIL v3 sont de deux natures: certaines y voient une stratégie à long terme, d'autres privilégient des bénéfices rapides. C’est le cas de la ZithaKlinik. Au cœur de la solution, HP Service Manager 7.0 automatise la gestion du cycle de vie des services d'un point de vue utilisateur. Non seulement le logiciel permet d'accélérer la détection et la correction des problèmes, mais il aide aussi à surveiller, mesurer et améliorer en permanence la valeur ajoutée apportée aux métiers tout en renforçant l'efficacité de la fourniture des services.
Bref, différents référentiels, différents éditeurs… et différentes perceptions! Certains considèrent l'ITSM comme une façon de penser et d'opérer, alors que d'autres définissent l'ITSM comme un moyen de gérer une organisation IT toute entière (les processus, les hommes, la technologie) et d'autres, encore, disent simplement que l'ITSM est le moyen de gérer une organisation IT «comme un business»… Communiquer, clé de succès d’un projet d’outsourcing
«Démontrer par le détail ce que l’on fait, énumérer les problème résolus, chiffrer le nombre d’incidents gérés et sous quels délais… Quand une entreprise confie tout ou partie de son système d’information à un prestataire, il est sain qu’elle sache, quelle comprenne et, à tout le moins, qu’elle ait une visibilité sur la situation.» Selon Candi Carrera, Director Client Service Operations, eBRC, le succès d’un outsourcing repose pour une bonne part sur la communication.
Communiquer régulièrement -sur la planification, sur les résultats, sur les concepts en tâchant de les expliquer de manière simple et compréhensible par tout un chacun. C’est la meilleure façon de contrer l’estimation du Gartner selon laquelle trois projets d’outsourcing sur cinq seront qualifiés de «succès partiel». Si les causes d’échec sont multiples, le manque d’échange entre prestataire et client serait criant. Certes, comme le recommande d’ailleurs le même cabinet de conseil, on peut formaliser le suivi du processus d’externalisation par la tenue de réunions périodiques entre prestataire et client afin d’évaluer les progrès réalisés au regard des objectifs initialement définis. Mais rien ne vaut une démarche volontaire, anticipative, voire participative.
Communiquer pendant, mais aussi -et prioritairement- avant de s’engager. De fait, il s’agit d’emblée de bien cadrer les besoins, assimiler les objectifs du projet. «Cadrer le champ d’application avant même qu’on ne parle de due diligence, assure Candi Carrera, autrement dit avant qu’on ne vérifie les données du cahier des charges, avant qu’on identifie les éventuels écarts d’inventaire -nombre d’applications, nombre et type de serveurs, nombre de postes de travail... En somme, partir sur des baises claires, des objectifs compris et partagés.»
C’est à ce stade qu’on évaluera les niveaux de flexibilité et d’agilité escomptés, les principaux facteurs de différenciation, qu’on traduira ensuite en livrables. Le due diligence prépare l’implémentation. De là, aussi, l’importance de la CMDB, ce référentiel qui mémorise chaque élément du système d'information et son état (serveur, routeur, PC, stockage, onduleur, logiciel, utilisateur, processus métiers et niveaux de service), qui enregistre aussi les dépendances (quels logiciels ou services sur quelles machines). Comme il faut s’entendre sur les termes, le langage est important. Le modèle de maturité d’ITIL permet d’évaluer le positionnement d’une organisation informatique. Le modèle propose d’évaluer chaque processus et de les situer sur un des niveaux de maturité. eBRC -dont 80% du personnel est certifié ITIL- est qualifié «niveau 3» -le processus possède des objectifs, un propriétaire et des ressources lui sont allouées; des rapports et des résultats sont disponibles et mis à disposition pour consultation. Pour la conduite de projet, eBRC a adopté PRINCE2 (PRojects IN Controlled Environments) -une méthode de gestion et de certification de projet structurée centrée sur trois points: organisation, gestion et contrôle du projet.
«La gestion de services inhérente à ITIL et la gestion de projet propre à PRINCE2 sont deux compartiments adjacents, assure Candi Carrera. Dans ITIL v3 sont définies les cinq étapes du cycle de vie du service et PRINCE2 s’insère dans de nombreux points de ce cycle…»
Intéressez-vous davantage au mode opératoire, conseille encore Candi Carera. Autrement dit aux rôles et responsabilités des deux parties sur base d’objectifs précis et mesurables, tant sur les délais et la sécurité, que sur les livrables attendus. A ce titre, un comité de pilotage doit être créé rassemblant maîtrise d’ouvrage et maîtrise d’oeuvre. Du papier à la pratique, il y a encore un pas. La gestion du changement est assurément la phase de tous les dangers. Celle ou certains collaborateurs n'acceptent pas de changer leur façon de faire, celle où certains ne comprennent pas la nécessité de changer ce «qui marche bien». C'est pourquoi il est nécessaire d'impliquer les collaborateurs dans la description des processus (tâches, rôles, livrables, etc.). Le pragmatisme doit toujours l'emporter sur la théorie.
Ce qui veut dire, encore, que la communication sera tout autant -et nécessairement- formelle qu’informelle. «L'apport, ici, des meilleurs pratique favorise l'émergence d'une culture de l'écrit, renforcée par la traçabilité et autres preuves exigées par les normes».
In fine, ce sont des garanties pour le client d'avoir un langage commun avec son fournisseur. Et donc un moyen de s'entendre sur une prestation, des rôles, un périmètre donné. A défaut, le recours à l'outsourcing peut vite se transformer en calvaire si clients et fournisseurs n'ont pas un niveau de langage commun d'un point de vue technique et métier. «On comprend d’autant mieux pourquoi il y a tant d’échecs en offshore, conclut Candi Carrera. La signification d’un ‘oui’ n’a pas la même signification ici qu’à six ou huit mille kilomètres. Trop souvent encore, on sous-estime le choc culturel.» |
|
|
|
|





Des investissements qui repartent, un retard à combler…




