Pour obtenir une version PDF de ce document, envoyez moi un mail à info@smartin-conseil.ch
Si cet article vous aide... n'hésitez pas à cliquer sur les annonces publiées...
Introduction
L’implémentation des processus ITIL s’est souvent réalisée avec succès dans les entreprises. Les premiers processus fonctionnent concernant les incidents, le change, la configuration ; parfois même le problème, le release.
Les autres processus de capacité, de facturation sont souvent absents ou simplement non formalisées. Et voila qu’est proposé la version ITIL V3.
En la regardant de plus prêt, elle parait totalement différente. Le référentiel semble différent, la logique semble différente. Et très souvent, les Services Managers ne voient pas comment aborder ces nouveaux concepts. Et surtout comment aller vendre cette évolution aussi bien au management qu’aux opérateurs.
Nous verrons dans ce document que des changements sont évidemment apparus dans cette nouvelle version des bonnes pratiques mais qu’une logique simple est sous-jacente. Ensuite, nous présenterons une approche possible pour migrer petit à petit d’une approche ITIL V2 vers ITIL V3 pour les processus existant. Enfin, nous verrons quelle démarche peut-être présenté pour implémenter les autres processus du framework.
Quelle différence en ITIL V2 et ITIL V3 ?
Comme nous le savons, ITIL V2 regroupe 10 processus et fonctions dont la répartition se fait en deux groupes : Support service et Service Delivery. C’est souvent le premier groupe qui a été abordé et implémenté. En effet, les processus d’incident, de change, de configuration étaient déjà plus ou moins existant et cette approche a permis surtout de formaliser ce domaine du support. Car une des erreurs qui a été communément réalisé est d’associer ITIL uniquement au monde du support et non au monde de la production. Par conséquence, tant que les processus n’impactaient que ce domaine, l’implémentation s’est réalisée et dès que le reste de la production devait s’approprier les autres processus. Il y a eu une fin de non recevoir car le chef de projet était issue du support.
Plus dans le détail, le référentiel sur lequel repose les processus ITIL V2 est la CMDB (Configuration Manager Data Base). Il s’agit de la représentation de l’infrastructure technique. C’est donc axé sur l’IT avant tout. Et le processus majeur reste l’incident pour les raisons invoquées précédemment.
Lorsqu’on détaille ITIL V3, on voit que le référentiel principal est le catalogue de service. Et les processus font tous référence aux services.
Attention, une erreur souvent commise est de traduire le catalogue de service comme étant le catalogue de Request fourni aux utilisateurs. De mon point de vue, il faut voir ce catalogue de service plus largement.
Si nous résumons :
Version | ITIL V2 | ITIL V3 |
Référentiel | CMDB | Catalogue de Service |
Processus majeur | Incident | Service Lifecycle |
Comment migrer en ITIL V3 depuis ITIL V2 ?
Pour comprendre la démarche
Comme vous l’aurez compris, la mise en place d’ITIL V3 n’est pas de tout remplacer et de tout remettre en cause. En effet, cette version est présentée comme la continuité. Il reste donc à mettre en place les améliorations continues nécessaires pour développer cette nouvelle approche.
Comme décrit précédemment, le catalogue de service n’est pas la liste des Request proposée aux utilisateurs. Il s’agit d’avoir une vision plus large et de voir dans ce catalogue l’ensemble des services fournies par l’informatique aux utilisateurs.
Ainsi, les utilisateurs vont être définis comme des consommateurs des services supportés par l’IT. Par exemple, la finance utilise une application particulière. Cette application est donc un service fourni. La DSI met à disposition un ordinateur avec des outils de base (logicielle bureautique, messagerie, accès aux imprimantes, accès internet…), il s’agit donc du service « Mise à disposition d’un environnement utilisateur ».
Avantage :
L’utilisateur ne consomme que les services qu’il utilise. Il peut, le cas échéant, être refacturé que sur ce qu’il utilise.
L’informatique doit connaître avec précision les services fournies, comment, à quelle prix…
Cette approche vous parait familière ? En effet, cette approche du client qui ne consomme que ce qu’il utilise, du fournisseur qui connait suffisant son service pour le packager correspond à l’approche SaaS, IaaS, PaaS. Pour rappel, cela correspond à Software as a Service, Infrastructure as a Service et Platform as a Service. On peut dire qu’ITIL V3 propose simplement une continuité dans cette approche et propose de mettre en place le SIaaS, soit Système d’Information as a Service.
La mise en place va alors consister à mettre en place les modifications nécessaires sur les processus existant et de définir les autres processus pour permettre cette logique. Il sera nécessaire de ne pas refaire la même erreur que l’implémentation ITIL V2 et de voir dans le framework une organisation de la production informatique et non simplement du support.
Impact sur le processus de configuration
La CMDB est le référentiel principal de ce processus. Elle contient le détail de l’infrastructure technique. Les éléments de configuration sont inter liés et possèdent des attributs. L’information est donc commune, unique et partagée.
Reposant sur cette connaissance, il s’agit de poursuivre cette description et de l’étendre sur l’organisation.
En effet, pour permettre le fonctionnement du système d’information, des équipes techniques tiennent différents rôles : gestion des serveurs, gestion de database, gestion d’application, surveillance… Ces activités sont généralement fournies pour les équipes qui opèrent sur les applications métiers. On a donc deux niveaux d’opérations distinctes :
° Des services dont les consommateurs sont d’autres équipes informatiques.
° Des services dont les consommateurs sont les utilisateurs métiers.
Définissons donc :
° Service technique : service dont le fournisseur et le client appartient à l’IT
° Service Business : service dont le fournisseur est IT et le client est Business
Détaillons les services Business
Le service Business correspond donc à une partie spécifique fournie par l’IT comme :
° Application financière
° Environnement locale
° Application RH…
Le découpage avec la meilleure granularité dépend de chaque environnement. Comme le service Business possède un unique SLA. Si vous avez par exemple des SLAs différents entre deux sites (usine, administration), ou entre deux populations d’utilisateurs (Management, technique…), on devra retrouver le nombre de service Business correspond.
Par analogie, dans un centre commercial, si vous souhaitez un paquet de pâte, vous avez différents de pâtes (spaghetti, coquillette…) qui correspondent donc à des besoins différents. Et pour chaque type de pâte, vous avez différentes marques (Lustucru, Panzani, distributeur…) et différentes quantités (500g, 1Kg…). Chaque paquet vous propose alors une recette différente (blé complet, aux légumes…), un temps de cuisson différent (3min, 8min…), un coût différent…
Cela risque de multiplier le nombre de service Business. Et cela correspondra à la description de la réalité de l’infrastructure. En effet, si culturellement, l’informatique se prête à de nombreuses exigences des différentes populations métier, cela sera mis en exergue par ce travail de définition.
Ce travail répondra à plusieurs questions :
° Que fourni le service informatique ?
° Que ne fourni pas le service informatique ?
° A qui est fourni quel service ?
° De quoi sont composés les services fournis ?
° Comment se décrit les services fournis ?
Les quelques attributs nécessaires pour décrire un service Business sont :
° Un titre (pas trop technique car il doit être commun entre l’IT et les utilisateurs)
° Une description détaillée (précisant ce qui est fourni, ce qui ne l’est pas)
° Un fournisseur : quelle équipe technique IT fourni ce service
° Un client : quelle population métier consomme ce service
° Un SLA : quels sont les engagements réciproque (IT pour le Business et Business pour l’IT)
° Un Service Manager : personnes responsable de ce service : dans la fourniture, la connaissance (équivalent chef de produit pour notre paquet de pâte)
D’autres attributs peuvent se retrouver :
° Une priorité : critique, standard…
° Un périmètre : de base, restrictif , VIP, boutique…
Le renseignement de ces informations ne doit pas et ne peut pas se faire du jour au lendemain. Comme conseillé pour la mise en place de la CMDB, il s’agit de commencer par un petit périmètre et de procéder par une logique récursive d’amélioration continue. D’autant plus que si des outils de télécollecte proposent d’alimenter les éléments de configuration, ce domaine décrit une organisation, il sera difficile d’automatiser son renseignement.
Détaillons les services techniques
L’équipe en charge de ce service ne fait pas tout elle-même. Par exemple, pour une application financière fournie, l’équipe en charge de gérer cette application fait appel à :
° Une équipe pour gérer les serveurs
° Une équipe pour surveiller les serveurs
° Une équipe pour gérer la base de données
° Une équipe qui pilote le processus de support
Ces équipes fournissent également des services mais ne sont pas en contact direct avec le métier. Ils fournissent alors des services techniques.
Si nous revenons sur notre paquet de pâte, l’agro-alimentaire ne s’occupe pas de tout (sauf d’une intégration verticale extrême). Il aura un fournisseur pour faire la boîte, un agriculteur pour le blé, un autre pour les œufs… Ces fournisseurs lui assurent des services techniques.
Dans la description de l’organisation IT, cela sera identique. Chaque équipe précédente supporte un service décrit avec des attributs semblables :
° Un titre (toujours compréhensible pour les deux parties)
° Une description détaillée (précisant ce qui est fourni, ce qui ne l’est pas)
° Un fournisseur : quelle équipe technique IT fourni ce service
° Un client : quelle équipe technique utilise ce service
° Un OLA : SLA qui lie deux équipes techniques entre elle
° Un Service Manager : personnes responsable de ce service : dans la fourniture, la connaissance (équivalent chef de produit de la boîte en carton du paquet de pâte)
D’autres attributs peuvent se retrouver :
° Une priorité : critique, standard…
° Une couverture : 24H/7J, 8H/7J, 8H/5J…
Les mêmes recommandations sont formulées :
La multiplication des services techniques correspond à l’organisation existante. Si rien n’est standardisé dans l’entreprise, cela se retrouvera rapidement.
Il est nécessaire de mettre en place une démarche récursive pour décrire l’organisation.
Il ne s’agit de décrire que les relations existantes. Si deux équipes travaillent ensemble mais que rien ne définit le service fourni (pas de SLA, pas de cahier des charges…), il sera très difficile de modéliser cette relation.
Impact sur le processus d’incident
Ce processus est souvent bien implanté et bien suivi. Les changements doivent donc rester minimes afin de ne pas casser cette dynamique.
C’est pourquoi, le seul changement sera d’intégrer le référentiel des Business Service dans la classification des incidents.
Chaque service – Business ou technique – possède ses spécificités. Les types de dysfonctionnements rencontrés par leurs utilisateurs peuvent donc différer. Il est donc nécessaire de définir une classification d’incident lié aux services.
Il faut donc ajouter sur l’incident la possibilité de classer les incidents sur le service puis sur un type d’erreur ressenti par l’utilisateur.
Le Service Desk sera reconnaissant car cela simplifie le traitement de l’incident :
Le service impacté contient les informations du/des groupes qui en ont la responsabilité. La base de connaissance contient cette classification. La recherche est également simplifiée.
L’incident manager sera reconnaissant car il sera quelles sont les services qui génèrent le plus d’impact pour les utilisateurs.
Les services managers seront reconnaissant car lorsque leur service est sur la liste précédent, ils sauront quel domaine précisément impactent le bon fonctionnement.
Si un système de self-service est proposé aux utilisateurs, il sera possible de leur présenter uniquement les services qu’ils consomment.
Impacte sur le processus de problème
Les modifications sont très semblables que sur le processus d’incident. Si ce processus a démarré qu’il a atteint sa légitimité, il s’agit d’impacter le processus simplement dans l’ajout du référentiel des services afin de déterminer quel périmètre est impacté.
Impact sur le processus de change
Le processus de change doit intégrer également le référentiel des services proposés par l’IT afin de définir l’impact du changement.
Compte-tenu de la description des différents services disponible au travers du processus de changement, la qualification et la définition des impacts des changes sont plus sures.
Impact sur la gestion des request
Les request doivent se lier aux services. En effet, un utilisateur s’abonne à un service. Il accède alors à un ensemble de request lié comme : demande de droit, demande d’upgrade, demande de restore…
Idéalement, un portail web présente à chaque utilisateur la liste des services auquel il a souscrit, avec les request disponibles. Il ne sera pas tenter de réaliser des demandes sans rapport avec son utilisation du système d’information.
Ce portail web sert aussi pour lui présenter la situation en temps réel du fonctionnement des services souscrits. En cas de services défectueux (programmé ou non), comme il est nécessaire et important de communiquer, cela se fait cibler.
Résumé sur les processus précédent
Comme détaillé, l’impact de la migration d’ITIL V2 en ITIL V3 réside principalement dans la structure de la CMDB pour lequel la connaissance de l’infrastructure s’étoffe pour s’approprier la connaissance organisationnelle.
Cette description se répercute alors sur les autres processus afin de placer au centre ce nouveau référentiel : le catalogue de service.
Les autres processus proposés sont, comme pour ITIL V2, des processus nécessaires pour garantir la production au delà du simple support.
Organiser la production pour implémenter SIaaS
Pour rappel, on appelle SIaaS : Système d’Information as a Service. C'est-à-dire fournir aux utilisateurs de l’organisation un système d’information consommable sous forme de service.
