De quelles composantes technologiques dépendent nos services TI? Voilà une question qu’un nombre croissant d’organisations se pose depuis un an ou deux.  Qu’il s’agisse de cybersécurité, conformité, continuité des affaires, gestion des pannes et de leurs impacts, évolution applicative accélérée (agile, DevOps), prise de décision éclairée selon le contexte et l’impact d’affaires… un référentiel reliant les services TI aux composantes technologiques devient vite incontournable.

Dans le quotidien, un tel référentiel peut porter plusieurs noms : système d’inventaire, Configuration Management Database (CMDB), Configuration Management System (CMS), etc. Cependant, le besoin auquel il répond demeure le même : mieux comprendre l’environnement pour mieux agir.

Souhaiter se doter d’un tel référentiel est une chose. Le déployer avec succès en est une autre. Voici ce que nous avons appris en l’implantant chez nos clients récents :

• L’implication et le support de la gestion sont cruciaux, comme pour toute transformation majeure
• L’amélioration continue est un ingrédient incontournable une fois le projet livré
• L’aspect humain est une composante essentielle au succès, et ce, à plusieurs niveaux : design de la solution, changement des comportements, transfert de connaissances, compréhension des concepts et des outils, prise en charge des responsabilités et engagement, etc.
• Il faut clairement distinguer gestion des configurations, gestion des actifs TI et gestion de l’inventaire :
  • Gérer un inventaire c’est gérer une liste simple d’éléments, sans contexte ni liens.
  • Gérer des actifs TI implique l’ajout d’un cycle de vie, de contrôles et d’un volet financier (coût, amortissement, contrats, etc.).
  • Gérer des configurations requiert l’ajout des liens entre les éléments pour démontrer comment ils contribuent à livrer un service TI à une ligne d’affaires. Ce faisant, la gestion des configurations établit une réelle cartographie orientée affaires de vos environnements.

 
Même avec ces considérations, la mise en place de la gestion des configurations demeure un travail complexe, de longue haleine et pavé de risques. Voici 8 pièges à éviter pour améliorer vos chances de succès.
 
1— Lancer l’initiative de mise en place d’une CMDB sans objectifs précis
Souvent, les organisations se lancent dans la mise en place d’une CMDB sans avoir au préalable clarifié leurs objectifs. Comprendre la contribution générale d’un tel référentiel au gain de maturité de processus telle la gestion des incidents ou des changements est une chose. Posséder des objectifs précis en est une autre.

Pour obtenir des bénéfices tangibles, il est nécessaire de clairement énoncer ce que l’on souhaite atteindre au moment de l’implantation. Par exemple, « nous devons être en mesure d’améliorer l’analyse de risque d’un changement », ou « nous avons besoin de comprendre le niveau de criticité d’un service afin de bien gérer la panne majeure » sont bien plus spécifiques et conditionneront la manière dont le déploiement de la CMDB sera abordé. En particulier, pendant l’implantation, ces objectifs aideront à trancher toute question concernant la portée ou l’inclusion de types d’éléments particuliers. On préviendra ainsi l’éparpillement qui est souvent le pire ennemi des projets de CMDB.
 
2— Croire qu’une CMDB est un projet principalement technologique
Le mythe est très fort : une CMDB serait uniquement un projet technologique. Certes, gérer les configurations requiert beaucoup de technologie : un système où se loge la CMDB, de l’automatisation (c.-à-d. de la découverte). Cette technologie rend la CMDB possible, mais n’est qu’un de ses aspects.

En effet, gérer des configurations requiert aussi une implication humaine importante. Pour que votre CMDB apporte les bénéfices escomptés, il vous faudra :

• Définir et maintenir un catalogue de service TI
• Comprendre et représenter les liens entre les services, les applications et les groupes qui les supportent
• Créer certains des éléments de configuration (tout ne peut être découvert automatiquement)
• Maintenir certains attributs
• Assurer la qualité des données de la CMDB
• Assurer la pérennité de la solution (évolution, gouvernance)

Ces tâches et responsabilités ne peuvent être assumées par des machines. Au-delà de la technologie, votre — plus grand défi -- sera de responsabiliser vos équipes et de les rendre imputables de la qualité et de la maintenance des données. Pour cela, vous aurez besoin de gouvernance (voir aussi le point 8).

Pour résumer, la mise en place de la gestion des configurations est avant tout un projet qui implique des humains et des responsabilités. Une gouvernance active sera une des clés du succès.  
 
3— Concevoir la solution CMDB en vase clos
La gestion des configurations (SACM) est au cœur de la gestion des services TI : la majorité des autres processus TI consomment l’information qu’encadre le processus SACM. Ainsi, c’est l’information-clé fournie par le processus SACM qui permet à l’organisation de s’assurer qu’elle livre bien les services conformément aux ententes
Parce que le processus SACM est essentiel à tant de processus qui en dépendent, le nombre de parties prenantes est important. Deux de ces parties prenantes doivent impérativement être impliquées dans le design de la solution :

• Les propriétaires de processus:
  • Pour eux, la CMDB est une source d’information incontournable. Par exemple, pour évaluer le risque qu’implique un changement sur un élément du service, il faut de l’information de qualité concernant l’élément et son rôle dans la chaîne de livraison du service. Les propriétaires de processus exprimeront donc des besoins spécifiques importants dont il sera essentiel tenir compte.
• Les propriétaires d’éléments de configuration (CI):
  • Les propriétaires de CI sont des équipes opérationnelles qui répondent de la qualité de l’information et en assurent la maintenance. Par exemple, l’équipe des serveurs Windows s’assure que tous ses serveurs sont représentés dans la CMDB au niveau de qualité d’information et de précision entendu. Les exigences des propriétaires de CI s’exprimeront donc à selon deux axes :
    •  livraison (données requises pour livrer le service),
    • faisabilité opérationnelle (capacité de l’équipe à maintenir l’information au niveau de qualité exigé).

Élaborer une CMDB en vase clos n’est donc pas recommandé. En particulier, les deux groupes mentionnés ci-dessus doivent être activement impliqués pour la durée du projet.
 
4— Croire en une super-CMDB monolithique
L’expérience de terrain démontre qu’une super CMDB unique centralisant toute l’information de l’entreprise n’est ni viable, ni souhaitable. Dans les faits, plusieurs systèmes contiennent déjà les informations en question. Pourquoi ne pas plutôt mettre en relation toutes ces sources autoritaires ?

En fait, la meilleure approche est de mettre en place une CMDB intégratrice (et non pas centralisatrice) qui :

• faire idéalement partie de votre système de gestion des services TI (ITSM)
• contient le minimum d’informations requis pour opérer les processus
• permet d’accéder si nécessaire au contenu détaillé des sources autoritaires externes

Par exemple, dans le contexte de la résolution d’un incident, avez-vous vraiment besoin que la centaine d’attributs propres aux serveurs réside directement dans la CMDB intégrée ? Le but est de garder dans la CMDB intégrée le strict minimum requis pour résoudre des incidents. Un lien vers l’outil d’autodécouverte permettra d’accéder aux autres détails.
 
 
5— Mettre en place une pyramide coupée : oublier les services et applications
Le modèle d’une CMDB ressemble à une pyramide dont chaque couche a son importance et ses spécialistes. Il est aujourd’hui assez simple de découvrir via des automatismes le contenu des couches du centre (infrastructure et infrastructure applicative). Plusieurs projets tombent donc dans le piège de s’y limiter et négligent les deux couches du haut (applications et services). Pourtant, c’est vraiment là que la valeur de la CMDB se concrétise !

ITIL amorce un nouveau virage, pour se moderniser et s’adapter aux nouvelles réalités de notre industrie. Conçu dans les années 1990 comme une référence des bonnes pratiques TI, ITIL a gagné beaucoup de popularité au début des années 2000.  Il s’est adapté aux nouvelles réalités du marché par le biais d’évolutions. D’abord, ITIL v.3 (en réalité ITIL 2007) abandonna les bons vieux « red book » et « blue book » et adopta une approche holistique centrée sur les processus,  symbolisée par la « roue ». Ensuite, l’édition « 2011 » mit l’emphase sur le service  tout en restant très dépendante des  processus. La 4e version d’ITIL annoncée pour le début 2019 s’inscrit dans cette volonté constante d’amélioration continue et de modernisation.

Chez Groupe UNI-TI Conseil, notre métier est de transformer la manière dont nos clients gèrent leurs TI (IT Service Management ou ITSM). Pour nous, ITIL est un outil pour a) ne pas réinventer la roue; b) amener nos clients aux bonnes pratiques et à une terminologie marché; c) les aider à contrôler leurs coûts; d) leur permettre de facilement se comparer au marché. Notre expérience de terrain nous montre qu’il était temps qu’ITIL se modernise. LeanIT, DevOps, BRM et autres sont en voie de changer le fonctionnement des TI. Dans ce nouveau monde d’agilité, de simplicité, d’automatisation, ITIL devait se réinventer pour ne pas être perçu comme lourd et désuet. 

Dans ITIL 4 annoncé pour début 2019, Axelos (le parrain d’ITIL) propose donc une refonte importante des concepts en mettant l’accent sur la valeur des TI à l’organisation.  Le contenu détaillé d’ITIL 4 demeure encore relativement secret. Les firmes de formation et les spécialistes sont sous embargo jusqu’au lancement officiel. En revanche, certaines informations ayant filtré via Internet, voici un résumé de ce que l’on sait selon les axes suivants :  

• Pour les passionnés d’ITSM : un aperçu des grands changements
• Pour les gestionnaires : quels impacts et opportunités pour votre entreprise?
• Pour ceux qui veulent se certifier : un nouveau modèle de certification

Principales nouveautés dans ITIL 4 (connues jusqu’à maintenant)
La fameuse roue ITIL que l’on connaissait depuis ITIL v3 n’est plus. Elle est remplacée par un nouveau modèle : le « Service Value Chain » ou « SVS » (Service Value Chain System).
​

Ce modèle marque un virage très affirmé vers le principe de la valeur des TI pour l’organisation. ITIL renforce le fait que les organisations TI doivent toujours considérer leur contribution directe au succès de l’entreprise et non se percevoir comme une dépense d’entreprise.

En mettant plus d’accent sur la « demande » et « l’engagement » avec les parties prenantes, ITIL 4 s’aligne donc avec le BRM (Business Relationship Management) qui a le vent en poupe ces dernières années. Si ces concepts étaient déjà présents dans ITIL 2011, ils sont dorénavant centraux dans ITIL 4.
L’autre changement important est la reconnaissance et l’intégration de trois grands courants sur le marché, soit LeanIT et DevOps et OCM (Organizational Change Management). Avec ITIL 4, ces pratiques seront expliquées et intégrées au cadre de référence.

Depuis les débuts, ITIL s’exprimait par un échafaudage de processus. Le processus était donc l’unité de base de cette construction. Dans ITIL 4, et cela peut paraître choquant, le processus est supplanté par la pratique et rétrogradé au niveau d’une dimension de la pratique (ces dimensions étant People, Process, Procedures, Skills, Competencies, Tools, Systems, etc.).  

Plusieurs de ces changements s’annonçaient déjà dans le contenu de la certification ITIL Practitioner introduite il y a environ 2 ans. On y retrouve les « Guiding Principles », l’accent sur OCM, l’importance de travailler de façon globale plutôt qu’en silos, etc. Les détenteurs de certifications ITIL Practitioner ne devrait donc pas être trop dépaysés dans ITIL 4

Quels impacts et opportunités pour votre entreprise?

Vous livrez déjà des services TI aujourd’hui.

À moins que vous soyez présentement en situation de crise, il n’y a pas urgence de révolutionner vos façons de faire. Utilisez deux des « Guiding principles » dans votre approche à ITIL 4:

• Progresser par itérations
• Éviter le dogmatisme

Commencez par prendre connaissance des ajustements inclus dans ITIL 4 et évaluez comment ils pourraient s’appliquer dans votre organisation.

Identifiez les nouveaux concepts qui semblent répondre à une problématique ou un enjeu que vous vivez et tentez d’appliquer graduellement les bonnes pratiques en petites implantations ciblées. Donnez-vous des objectifs et mesurez les résultats.

Si votre projet de transformation ITSM est déjà en cours, voici l’opportunité de revoir votre cible et d’intégrer certains concepts. Soyez opportuniste et non dogmatique. Les bonnes pratiques d’hier seront encore la base de celles de demain. Si votre initiative repose sur une fondation solide, elle sera encore valide avec ITIL 4.

La principale réflexion à faire suite à ITIL 4 sera au niveau de la relation entre votre « business » et les TI. Les organisations qui démontrent une synergie TI / Business sont plus productives, plus proactives et répondent mieux aux changements du marché. En 2018, les technologies jouent un rôle central dans la majorité des domaines d’affaires. Si ces technologies sont gérées en silo, sans comprendre comment elles contribuent directement à la croissance et l’efficacité, l’entreprise est vouée à l’échec. Nous vous encourageons donc de profiter de l’arrivée d’ITIL 4 pour entreprendre cette réflexion capitale.
​
Un nouveau modèle de certification
ITIL 4 est accompagné d’une nouvelle approche de certification :
​

Source : Axelos
 
On remarque au premier coup d’œil un changement philosophique important : le nom des certifications reflète l’accent sur la valeur qu’ITIL apporte à l’organisation.
La certification contient encore 4 niveaux : fondation, intermédiaire (spécialiste/stratégiste), expert (professionnel/leader) et master. Selon votre situation, voici vos options selon Axelos :
J’ai la certification « ITIL Foundation » seulement :

• La recommandation est de reprendre la certification avec ITIL 4. Les cours seront disponibles dans les premiers mois de 2019.

J’ai une certification intermédiaire (moins de 6 crédits) :

• Option 1 : Recommencer avec le nouveau plan de certification
• Option 2 : Poursuivre à court terme la formation sous ITIL 2011 et atteindre 17 crédits. À ce niveau, vous serez éligible pour prendre le « Management Professional Transition » qui vous donnera la certification « ITIL Management Professional ».

J’ai une certification intermédiaire (plus de 6 crédits) :

• La recommandation d’Axelos est de poursuivre à court terme la formation sous ITIL 2011 et d’atteindre 17 crédits. À ce niveau, vous serez éligible pour prendre le « Management Professional Transition » qui vous donnera la certification « ITIL Management Professional ».

Je suis un ITIL Expert :

• Vous devrez prendre le « Management Professional Transition », pour obtenir la certification « ITIL Management Professional ». La date de la disponibilité de cette formation n’est pas confirmée. On mentionne « plus tard en 2019 ».
• Pour obtenir « ITIL Strategic Leader », vous devrez aussi suivre la certification « ITIL Strategist – Direct, Plan & Improve ».

Je suis un ITIL Master :

• Bravo, car vous êtes plutôt rares. Pour le moment, nous ne savons pas si un « Bridge » sera disponible pour les ITIL Master.

 
 
Références :

• ITIL 4 foundation course – Pink Elephant
• ITIL 4 Update – Pink Elephant
• What is the ITIL 4 Service Value Chain? – Mark Hilard
• ITIL Update- Axelos
• What’s Coming in ITIL 4? – Stuard Rance
• ITIL 4 is Coming Soon — But Don’t Put Your ITIL Journey on Hold - Alison Beadle