ITIL V3
Amélioration continue des services
Création : janvier 2008 Mise à jour : juin 2013
2
A propos
A propos du document
Ce document de référence sur le référentiel ITIL V3 a été réalisé en se basant directement sur les 5 livres ITIL de la version 3 : Service Strategy, Service Design, Service Transition, Service Operation et Continual Service Improvement parus en 2007.
Il est mis à la disposition de la communauté francophone ITIL pour diffuser les connaissances de base sur ce référentiel.
Ce document peut être utilisé de manière libre à condition de citer le nom du site (www.itilfrance.com) ou le nom de l’auteur (Pascal Delbrayelle).
A propos de l'auteur
Pascal Delbrayelle intervient avec plus de 25 ans d'expérience comme consultant sur les projets d'une direction informatique ayant comme facteur de succès la mise en oeuvre des bonnes pratiques ITIL comme, par exemple, la mise en place d'un site de secours, la mise en place d'un outil de gestion des configurations ou la définition des normes et standards techniques des environnements de production.
Ces projets requièrent :
la connaissance des différents métiers du développement et de la production informatique
la pratique de la conduite de projets techniques de la direction informatique
la maîtrise de la définition et de la mise en place de processus pour rationaliser et adapter les méthodes de travail au sein de la direction informatique
A propos de mission et de formation
Si vous pensez que l’expérience de l’auteur sur le référentiel ITIL ou la formalisation de documents sur le sujet peut vous aider dans vos projets de production ou de mise en oeuvre des processus ITIL, n’hésitez pas à le contacter pour toute question ou demande :
par mail : pascal.delbrayelle@itilfrance.com
par téléphone : +33 (0)6 61 95 41 40 Quelques exemples de mission :
Modélisation simple des processus de gestion des changements, des projets et des mises en production en vue de la sélection, l'achat et l'implantation d'un outil de gestion de projets avec planification, gestion des ressources, des budgets, des livrables et des connaissances
Accompagnement avec la réorganisation d'un DSI passant d'une organisation en silos techniques vers une organisation inspirée du référentiel ITIL et la mise en oeuvre d'outils pour institutionnaliser les processus ITIL
Accompagnement d'une DSI dans la formulation de l'appel d'offres au futur centre de services en se basant sur les processus et la fonction centre de services du référentiel ITIL
3
Table des matières
1. Objectifs, règles de base et bénéfices ... 5
1.1. Raison d'être de l'amélioration continue des services ... 5
1.2. Objectifs ... 5
1.3. Règles de base ... 5
1.4. Déclencheurs principaux ... 5
1.5. Bénéfices ... 6
2. Principes de base ... 6
2.1. Estimer la valeur apportée aux affaires ... 6
2.1.1. Amélioration ... 6
2.1.2. Bénéfices ... 6
2.1.3. ROI (Return On Investment) ... 6
2.1.4. VOI (Value On Investment) ... 6
2.2. La gouvernance ... 6
2.2.1. La gouvernance d'entreprise ... 6
2.2.2. La gouvernance informatique ... 7
3. Cadres, modèles, normes et systèmes de qualité ... 7
3.1. Liens avec l’amélioration continue des services ... 7
3.2. ITIL ... 7
3.3. COBIT (Control OBjectives for Information and related Technology) ... 7
3.4. PMBOK (Project Management Body of Knowledge) ... 7
3.5. PRINCE2 (PRojects IN Controlled Environments V2)... 8
3.6. CMMI (Capability Maturity Model Integration) ... 8
3.7. La norme ISO/IEC 20000:2005 ... 8
3.8. La norme ISO/IEC 27001:2005 ... 8
3.9. La norme ISO/IEC 17799:2005 ... 8
3.10. La norme ISO/IEC ou SPICE (Software Process Improvement and Capability dEtermination) .... 8
3.11. La norme ISO/IEC 19770:2006 ... 8
3.12. Le système qualité Six Sigma ... 8
3.13. eSCM-SP (eSourcing Capability Model for Service Providers) ... 9
3.14. SOX (Sarbanes-Oxley Act)... 9
4. Le cycle de Deming ... 9
5. L’approche d'amélioration continue des services en six étapes ... 11
7. Le processus d'amélioration en 7 étapes ... 11
7.1. Quand déclencher ce processus ?... 11
7.2. Les sept étapes ... 12
4
7.2.1. Définir ce qu’il faudrait mesurer ... 12
7.2.2. Définir ce qu’il est possible de mesurer ... 12
7.2.3. Collecter les données de base (Extract)... 12
7.2.4. Ajuster les données de base (Transform) ... 12
7.2.5. Analyser les données ... 12
7.2.6. Présenter et utiliser l’information ... 12
7.2.7. Mettre en place les actions correctives ... 13
8. Mesures et métriques ... 14
8.1. Les 4 intérêts majeurs à mesurer ... 14
8.2. Principes pour les concevoir ... 14
8.3. Les trois domaines à mesurer ... 15
5
1. Objectifs, règles de base et bénéfices
1.1. Raison d'être de l'amélioration continue des services
L'amélioration continue des services a pour but d'aligner et de réaligner en permanence les services informatiques sur les besoins d’affaires en perpétuelle évolution, ceci en identifiant et en implantant les améliorations sur les services informatiques supportant les processus d’affaires.
1.2. Objectifs
Pour cela, l'amélioration continue des services a pour objectifs :
de revoir, d'analyser et de faire des recommandations sur les opportunités d’amélioration sur chaque phase du cycle de vie des services : de la stratégie à l’exploitation
de revoir et d'analyser les résultats sur l’atteinte des niveaux de services
d'Identifier et d'implanter des activités individuelles pour améliorer la qualité des services informatiques et améliorer l’efficience et l’efficacité des processus informatiques
d'améliorer les coûts de fourniture des services informatiques sans renoncer à la satisfaction client
d'assurer que des méthodes de gestion de la qualité sont utilisées pour supporter les activités de l’amélioration continue
1.3. Règles de base
Elles sont au nombre de trois :
Vous ne pouvez pas gérer ce que vous ne pouvez pas contrôler
Vous ne pouvez pas contrôler ce que vous ne pouvez pas mesurer
Vous ne pouvez pas mesurer ce que vous n'avez pas défini
Sans objectifs clairs et sans systèmes de mesure :
les résultats ne seront pas au rendez-vous ET
il ne sera pas possible de lancer des améliorations
1.4. Déclencheurs principaux
Les déclencheurs principaux sont les suivants :
les affaires : évolution des besoins et de la stratégie des organisations d'affaires et, plus globalement, de l'organisation dans son ensemble
les technologies : évolution des technologies et apparition de nouvelles technologies permettant d’optimiser le fonctionnement du fournisseur de services
Les processus qui vont principalement déclencher des initiatives d'amélioration sont :
la gestion des niveaux de service dont la mise en uvre est un principe clé de l’amélioration continue des services
la gestion des problèmes
6
1.5. Bénéfices
Les principaux bénéficiaires seront les clients et les affaires : en terme d'innovation, nous aurons une meilleure flexibilité du fournisseur.
D'autres bénéfices sont aussi attendus en interne à l’organisation informatique.
2. Principes de base
2.1. Estimer la valeur apportée aux affaires 2.1.1. Amélioration
L'amélioration sur un périmètre donné va se concrétiser et se mesurer par l'augmentation d’une métrique désirée ou la diminution d’une métrique indésirable.
L'appréciation de l'amélioration se fera par la mesure de résultats qui sera comparée à la situation d’avant.
2.1.2. Bénéfices
Les bénéfices sont des gains obtenus après la réalisation des améliorations. Ils sont souvent mais pas uniquement exprimés en termes financiers.
2.1.3. ROI (Return On Investment)
Il s'agit de la différence entre les bénéfices (ou les économies) et le coût des améliorations (en pourcentage).
2.1.4. VOI (Value On Investment)
Il s'agit d'une notion plus étendue que le ROI puisqu'elle inclut les résultats non-financiers ou à long terme.
2.2. La gouvernance
A l’origine, la gouvernance était simplement le contrôle des opérations quotidiennes.
Depuis le début des années 90 sont apparus de nouveaux modèles et technologies comme, par ex. :
les applications n-tiers
internet
le stockage
la virtualisation
Ces contrôles ont été abandonnés petit à petit au moment où il y en avait le plus besoin !
Plus récemment, des fraudes de grandes entreprises ont été mis au jour ce qui a eu pour conséquence le retour de la gouvernance.
La gouvernance nécessite pour l’informatique de se conformer à un nombre croissant de règlementations.
2.2.1. La gouvernance d'entreprise
Elle se décompose en deux parties :
7
la gouvernance corporate ou corporative (lire : institutionnelle) qui définit l'ensemble des règlementations et lois que l'organisation va respecter mais aussi des principes fondamentaux de l'organisation (principe d'égalité homme-femme par ex.)
la gouvernance business ou d'affaires qui définit l'ensemble des performances que l'organisation doit atteindre
2.2.2. La gouvernance informatique
La gouvernance informatique est la déclinaison de la gouvernance d'entreprise appliquée à l'organisation informatique.
A ce titre, on retourve ici les deux composantes gouvernance institutionnelle et gouvernance d'affaires.
3. Cadres, modèles, normes et systèmes de qualité
3.1. Liens avec l’amélioration continue des services
L'amélioration continue des services recouvre globalement la gestion des services informatiques (ITSM) et chacun des cadres, modèles, normes et systèmes de qualité cités supportent complètement les concepts portés par l’amélioration continue des services.
3.2. ITIL
Créé en 1989, ce cadre est un guide sur la structuration, l’intégration et l’amélioration des services et des processus informatiques.
Le propriétaire est toujours le propriétaire intellectuel à l'origine : le Bureau du Conseil des Ministres (Cabinet Office) du gouvernement de Grande-Bretagne.
Il s'agit de l'ensemble de principes pour la gestion des services informatiques le plus adopté dans le monde.
3.3. COBIT (Control OBjectives for Information and related Technology)
Créé en 1995, il s'agit d'un cadre d’audit des systèmes d’information qui a évolué vers un cadre global de gestion IT.
Les processus et principes COBIT sont souvent utilisés par les auditeurs informatiques et SOX (loi Sarbanes-Oxley aux Etats-Unis d’Amérique).
Le propriétaire intellectuel est l'IT Governance Institute.
3.4. PMBOK (Project Management Body of Knowledge)
Le propriétaire et gestionnaire est le Project Management Institute (PMI).
Il s'agit d'un ensemble de connaissances dans les professions de la gestion de projets. Il inclut des pratiques traditionnelles et éprouvées largement utilisées et aussi des pratiques innovantes qui émergent dans ces professions.
8
3.5. PRINCE2 (PRojects IN Controlled Environments V2)
Il s'agit d'une méthode structurée de gestion de projet.
Le propriétaire intellectuel est le même que celui d'ITIL : le Bureau du Conseil des Ministres (Cabinet Office) du gouvernement de Grande-Bretagne.
Le principe est qu'un projet est géré par une suite logique et organisées d’étapes.
3.6. CMMI (Capability Maturity Model Integration)
Ce modèle a été créé en 1991 par le SEI (Software Engineering Institute) à l’université de Carnegie Mellon.
A l’origine, le modèle CMM a été créé pour démontrer la maturité des processus de développement logiciel dans l’idée que de meilleurs processus de développement logiciels donnaient de meilleurs logiciels.
Depuis, le CMMI permet de mesurer la maturité de tout processus.
Les organisations peuvent être certifiées en utilisant le SCAMPI (Standard CMMI Appraisal Method for Process Improvement).
3.7. La norme ISO/IEC 20000:2005
Il s'agit de l'adoption d’une approche intégrée de processus pour fournir et gérer efficacement des services afin de satisfaire à des besoins clients et d’affaires.
Elle est basée sur les processus ITIL.
3.8. La norme ISO/IEC 27001:2005
Elle spécifie les exigences pour l’établissement, l’implantation, l’exploitation, la surveillance et l’amélioration d’un système de gestion de la sécurité (ISMS ou Information Security Management System) dans le contexte global des risques d’affaires d’une organisation.
Elle couvre tous types d’organisation et permet de sélectionner les contrôles de sécurité appropriés et proportionnés et de faire confiance à l’organisation.
3.9. La norme ISO/IEC 17799:2005
Elle définit les guides et principes généraux pour initier, implanter, maintenir et améliorer la gestion de la sécurité de l’information dans une organisation.
Elle permet de répondre à des besoins identifiés dans une analyse de risque.
3.10. La norme ISO/IEC ou SPICE (Software Process Improvement and Capability dEtermination)
Il s'agit d'un cadre permettant d’évaluer les aptitudes d’un processus.
Il peut être utilisé par les organisations impliquées dans la planification, la gestion, le contrôle et l’amélioration de l’acquisition, la fourniture, le développement, l’exploitation, l’évolution et le support de produits et services.
3.11. La norme ISO/IEC 19770:2006
Elle permet à une organisation de prouver qu’elle gère ses actifs logiciels (SAM ou Software Asset Management) de manière à satisfaire les exigences de la gouvernance institutionnelle (Corporate Governance).
Elle permet aussi d’assurer un support efficace pour la gestion des services informatiques (ITSM) et est prévue pour s’aligner et supporter la norme ISO/IEC 20000.
3.12. Le système qualité Six Sigma
Ce système qualité a été établi par Motorola en 1986 comme :
la définition des métriques permettant de mesurer les défauts et d’améliorer la qualité et
une méthodologie pour réduire les niveaux de défaut en dessous de 6 x écarts types (six sigma)
En 1995, ce système a été adopté par General Electric et depuis, il s'agit du système de qualité le plus reconnu et accepté dans le monde.
9 Avec un intervelle de tolérance de 2 x écart-type :
Avec un intervelle de tolérance de 6 x écart-type :
3.13. eSCM-SP (eSourcing Capability Model for Service Providers)
Il s'agit de bonne pratiques en matière d'hébergement de centres informatiques.
3.14. SOX (Sarbanes-Oxley Act)
Il s'agit d'une réponse règlementaire à l’érosion de la confiance des investisseurs imposant des contrôles et audits internes prouvant la conformité de l’entreprise aux règlementations.
La Loi Sarbanes-Oxley de 2002 sur la réforme de la comptabilité des sociétés cotées et la protection des investisseurs est une loi fédérale imposant de nouvelles règles sur la comptabilité et la transparence financière.
Elle fait suite aux différents scandales financiers révélés dans le pays aux débuts des années 2000, tels ceux d'Enron et de Worldcom. Le texte est couramment appelé loi Sarbanes-Oxley, du nom de ses promoteurs le sénateur Paul Sarbanes et le député Mike Oxley. Ce nom peut être abrégé en SOX, Sarbox, ou SOA. (source : Wikipedia).
4. Le cycle de Deming
Le cycle de Deming est le cycle minimaliste d'amélioration continue. Néammoins, les 4 étapes PDCA (Plan->Do-
>Check->Act) sont fondamentales.
Les deux autres cycles proposés par ITIL dans le cadre de l'amélioration continue des services sont des cycles plus détaillés.
10
11
5. L’approche d'amélioration continue des services en six étapes
7. Le processus d'amélioration en 7 étapes
7.1. Quand déclencher ce processus ?
Lorsque une ou plusieurs personnes ressentent que, sur un périmètre donné quelconque (méthode de travail, niveaux de service ou l'utilisation d'une technologie par ex.), les choses pourraient être améliorées et que, pour l'instant, personne ne voit ce qu'il faudrait lancer comme initiative d'amélioration.
Dans ce cas, il va falloir respecter une séquence d'étapes que l'on pourraient appeler préliminaires au plan
d'actions et qui vont permettre d'identifier de manière factuelle et chiffrée les problèmes et les solutions à mettre en place pour améliorer ce périmètre.
12
Ces premières étapes sont concrètes et permettent d'utiliser une approche ETL (Extract, Transform and Load) pour les données afin de les intégrer dans une base centralisée permettant de les analyser pour en tirer de l'information utile pour la suite des réflexions.
7.2. Les sept étapes
7.2.1. Définir ce qu’il faudrait mesurer
Qu’est-ce qui est important pour les organisations d'affaires et la direction informatique ?
Quoi mesurer : service, processus, outil, organisation, item de configuration
Quoi mesurer : efficacité, efficience, conformité des résultats (par rapport à ce qui est attendu) satisfaction des utilisateurs, etc.
7.2.2. Définir ce qu’il est possible de mesurer
Inventorier les outils existants
Etablir la liste des mesures possibles avec ces outils (bruts et avec développement)
Faire une analyse d’écart entre les listes « ce qu’il faudrait » et « ce que l’on peut faire »
Décider éventuellement de la mise en place nouveaux outils ou développements (autres projets d’amélioration) si l'écart est trop important et que l'existant ne donnera pas d'information significative dans cette démarche d'amélioration
7.2.3. Collecter les données de base (Extract)
Attention à la volumétrie importante des données de base.
L’exploitation des services et l’amélioration permanente doivent s’entendre sur ce qui doit être surveillé et pourquoi (sous peine de mauvais départ de tout processus de mesure).
7.2.4. Ajuster les données de base (Transform)
Transformer dans le format correct
Grouper les valeurs
Calculer les données composées (disponibilité d’un service à partir de la disponibilité technique de ses composantes)
Deux alimentations :
automatique
manuelle avec le risque que les personnes ne mettent pas à jour les données (pas le temps, pas son travail, etc.) ou chronophage (avec des coûts cachés)
7.2.5. Analyser les données
Les deux objectifs sont :
Comparer les résultats avec les objectifs : vérifier l’atteinte des objectifs et l’ajout de valeur
Examiner la tendance (se rapproche-t-on de l’objectif ?)
Pour cela, il est nécessaire de produire des tableaux et des graphiques. Ces derniers sont peut-être très jolis à regarder mais la vraie question est : « qu’est-ce que cela signifie ? »
Ces tableaux bruts, aussi jolis soient-ils, ne sont pas suffisants : il est nécessaire de documenter ces informations, leur interprétation et les conclusions.
Cela nécessite des profils d’analystes qui ont quelque chose à analyser
Par exemple, la conclusion « Nous pouvons constater une baisse du nombre d’incidents par rapport au mois précédent » n'apporte pas d'explication complémentaire ou d'interprétation aux chiffres bruts, ce qui n'a donc aucun intérêt et alourdit encore plus la présentation des résultats.
Se préoccuper plutôt de : est-ce bon ? est-ce mauvais ? est-ce attendu ? est-ce en accord avec la cible ?
7.2.6. Présenter et utiliser l’information
Il faut présenter :
les informations (tableaux de bord)
le résultat des analyses (interprétation mais aussi proposition de plan d’actions, d'opportunités, etc.) Point très important : il est impératif de prendre en considération les audiences cibles :
les données sont collectées au niveau opérationnel, souvent techniques
nécessité de les transformer en informations pouvant être appréciées à tous les niveaux de l’organisation et comparées aux besoins et attentes de chacun
ITIL distingue 4 niveaux très différents parmi les destinataires :
13
Il est nécessaire de présenter « utile » pour l’audience. Il faut faire en sorte que les personnes recevant l’information puissent prendre des décisions stratégiques, tactiques et opérationnelles.
On constate souvent le trop-plein d’informations pour les responsables.
Toutes les organisations fournissent des rapports de données mais mal : les données brutes sont mises en tableaux et graphiques et le (même) tout est envoyé à tout le monde sans explications comme, par exemple, le tableau de bord du respect de l'accord de niveau de service (SLA ou Service Level Agreement) envoyé à tout le monde :
7.2.7. Mettre en place les actions correctives
Il faut utiliser la connaissance acquise pour optimiser, améliorer et corriger les services fournis.
Les responsables doivent identifier les problèmes et proposer des solutions.
Il faut toujours expliquer en quoi les actions correctives vont améliorer la situation.
14
8. Mesures et métriques
8.1. Les 4 intérêts majeurs à mesurer
8.2. Principes pour les concevoir
Il est nécessaire de :
développer un cadre global de génération et de diffusion des rapports et tableaux de bord
construire les rapports sur les services (niveaux de service) à partir des mesures sur les composants et d’autres mesures
détailler la démarche entre chaque objectif à mesurer et les mesures opérationnelles associées en passant par la définition des facteurs critiques de succès (CSF ou Critical Success Factors) et la définition des indicateurs-clés de performance (KPI ou Key Performance Indicators)
La construction des métriques et mesures passent par différentes étapes :
15
8.3. Les trois domaines à mesurer
Les trois domaines pour lesquels il faut définir des mesures et des métriques afin d'être exploités dans toute la discipline ITSM sont les suivants :
la technologie : les composants et, plus généralement, les ressources
les services : les services eux-mêmes (utilité) et les niveaux de service (garantie)
les processus : volumétrie, risques, efficacité, efficience, etc.
