Quelle mise en oeuvre d ITIL?

Transcription

1 Quelle mise en oeuvre d ITIL? Xavier Flez Novembre 2005 Propriété Yphise yphise@yphise.com 1

2 Plan Quelques rappels historiques utiles Réussir une mise en oeuvre intelligente 2

3 Quelques rappels historiques utiles 3

4 Ce qu est ITIL (IT Infrastructure Library) Au départ. Des livres qui proposent des réflexions sur les différentes activités (issues) d une Production (dont Infrastructure) pour voir comment les mettre en oeuvre efficacement. Le terme ITIL désigne couramment les activités regroupées dans 2 livres : Service Support (300 pages) et Service Delivery (370 pages) BOOK Service Support focuses on ensuring that the customer has access to appropriate services to support business functions ISSUES Service Desk Incident Management Problem Management Configuration Management Change Management Release management Service Delivery covers the service the business requires of the provider in order to enable adequate support to the business users Capacity Management Financial Management for IT Services Availability Management Service Level Management IT Service continuity Mngt 4

5 Rappel de l origine Cette réflexion est née au cours des années 80 dans l administration anglaise (OGC Office of Government Commerce) pour répondre aux exigences d efficacité voulues par le gouvernement Le résultat de ces réflexions a été publié au fur et à mesure dans une série de fascicules. Ceux-ci ont eu une large audience au Royaume Unis, aux Pays Bas, en Belgique et, plus largement, en Europe du Nord Naissance en 1991 de l itsmf (IT Service Mngt Forum) regroupement d entreprises, prestataires ou utilisatrices, intéressées par la promotion et le développement d ITIL (en êtes vous?) Restructuration en 2000 de cet ensemble de fascicules pour publication des livres Service Support et Service Delivery 5

6 Comprendre le contexte : la notion de processus (1/2) Jusque fin 2000, la principale référence en terme d efficacité de management est ISO 9001:1994. N utilise pas le terme processus. Le «management orienté processus» est l une des idées fondamentales apportées par ISO 9001:2000 En 2003 est publié le «Board Briefing on IT Governance» qui insiste sur la maîtrise des processus d une DSI En parallèle, se mettent en place différentes législations visant à renforcer dans les entreprises le contrôle interne, donc la capacité à tracer ce qui y est fait (en France les SA sont tenues à un rapport depuis 2003) 6

7 Comprendre le contexte : la notion de processus (2/2) ITIL s est développé avant que le management des processus ne soit défini et aussi mature qu aujourd hui D ailleurs les différents sujets (issues) ne sont pas tous qualifiés de processus. Ceux qui le sont ont des descriptions non homogènes : certains en terme d activités (ex Incident Mngt), parfois de sous-activités (ex Problem Mngt), d autres ne le sont pas (ex Service Mngt). Les autres sont des discussions de problématiques, avec parfois des chevauchements entre sujets 7

8 Comprendre le contexte : infrastructure et production ITIL est né à l époque du mainframe. C est-à-dire d une infrastructure et exploitation «gérées indépendamment» des projets applicatifs ; la production venant après le projet pour mise en production. On sait aujourd hui qu il faut remonter la prise en compte des problématiques techniques et de service en production dès l analyse /conception du projet compte tenu des environnements distribués et du fil de l eau. ITIL ne le fait pas De même, on s intéressait au niveau de service sur le mainframe. Ceci permettait, au réseau près, d apprécier le niveau de service au métier. Aujourd hui un processus métier traverse différentes couches applicatives et techniques. Gérer le niveau de service sur un serveur ne permet pas de garantir un engagement sur le processus métier. ITIL n a pas été conçu pour traiter cette problématique 8

9 Comment donc apprécier ITIL aujourd hui? ITIL a été incontestablement novateur en terme de réflexion structurée sur la maîtrise d une Production. Dès l origine a été comprise l importance du travail sur les processus, qui est au coeur d ISO 9001:2000 publié une quinzaine d années plus tard : c est brillant. Mais ITIL met-il vraiment l accent sur les processus aujourd hui utiles? Les livres ITIL constituent une base de réflexion extrêmement intéressante et variée (on y discute concepts, bénéfices, outils, éléments d organisation, métriques, points clés, rôles, etc.). Mais ITIL constitue-t-il un ensemble de pratiques opérationnelles à implémenter ou est-ce un guide de réflexion? L importance accordée à la maîtrise des processus fait que les éditeurs de logiciels se sont emparés d ITIL. Mais ITIL constitue-t-il le fondement adapté pour un outillage simple et efficace? 9

10 Réussir une mise en oeuvre intelligente 10

11 Préambule Nous allons voir dans la suite certaines limites. Mais ceci ne doit pas faire oublier que nous sommes positifs sur ITIL. Nous recommandons en particulier à chaque manager de lire, relire et re-relire le(s) chapitre(s) qui le concerne(nt). Ils y a plein de bonnes idées ; il faut du temps pour les appréhender correctement En résumé les limites proviennent fondamentalement de l histoire 1/ Compréhension de ce qu est réellement une informatique distribuée (Java ; enchaînements serveur Web, d application, de données, d habilitation, etc.). Comment cela se gère, se maîtrise, évolue 2/ Intégration aux projets applicatifs. Sujet absent. On a l impression d un monde à part, alors que l essentiel de ce que l on peut analyser, concevoir, tester en terme d engagement ou de continuité de service l est à l occasion de ces projets 11

12 Centrer l effort sur des gains précis (1/2) La richesse d ITIL et certaines de ses lacunes font que le risque de s y perdre est élevé. ITIL n est pas une ensemble de pratiques dont la mise en oeuvre progressive garantit mécaniquement une efficacité accrue. ITIL est d abord un guide de réflexion pour avancer une fois que des objectifs précis sont définis Ce point peut paraître évident. Mais on voit aujourd hui des projets de type «mettre en oeuvre ITIL» qui ne vont pas bien, car se perdant dans la complexité ou le détail. On ne sait pas jusqu où il faut aller /s arrêter. On ne sait pas choisir les dispositifs simples et utiles dans le contexte. ITIL devient une nouvelle «forteresse» à l intérieur de la DSI Le risque est considérablement augmenté par la puissance des outils : jusqu à quel niveau de détail faut-il aller dans la CMDB? Comment garantir qu on n est pas en train de construire un Catalogue de Services ingérable? etc. 12

13 Centrer l effort sur des gains précis (2/2) Concrètement, la mise en oeuvre d ITIL n est pas un projet, mais des projets s inscrivant dans un cadre ou une stratégie ITIL Les deux livres Service Support + Service Delivery représentent pages particulièrement denses. L ensemble des dispositifs organisationnels (activités, livrables, rôles, méthodes) doit être simplifié selon la taille de la DSI. Quelques pages de description de processus doivent suffire dans une Production <100 personnes (ex on peut implémenter l essentiel de la gestion des problèmes en adaptant un processus de gestion des incidents) 13

14 L utilisation comme guide d autoévaluation périodique L itsmf a défini pour chaque processus un guide de scoring. Il reprend sur chaque processus les pratiques proposées en une cinquantaine de questions, classées en niveaux de maturité Ce guide constitue une bonne base pour réfléchir et gérer une progression à l intérieur d une DSI. Il permet une autoévaluation périodique de sorte à manager l efficacité. Nous insistons en effet sur l importance à formaliser une évaluation périodique de ses processus de sorte à éviter «l usure du temps» Level 1 Level 1.5 Level 2 Level 2.5 Level 3 Level 3.5 Level 4 Prerequisites Management Intent Process Capability Internal Integration Products Quality Control Management Information 14

15 Faire de l ITIL «sans le savoir» : Help-Desk et Incidents Les notions de Help Desk = point d accès unique + Gestion des incidents = enregistrement, escalade, gestion de la connaissance sont aujourd hui bien connues et très largement implémentées (même si ce n est pas toujours parfait) ITIL n est pas à l origine de ces notions, mais a fortement contribué à leur banalisation. En ce sens, beaucoup de DSI font de l ITIL «sans le savoir» La difficulté actuelle se trouve sur un sujet non traité par ITIL : comment dans une informatique distribuée faire un bon monitoring de production = avoir des alertes utiles au niveau 1 ; c est-à-dire interprétables en terme de procédure ou escalade à appliquer, la difficulté étant de ne pas prendre une conséquence pour une cause (ex problème base de donnée qui fait tomber un serveur d application) 15

16 La gestion des problèmes (1/2) La gestion des incidents a pour objectif de permettre la reprise de la production ou du travail de l utilisateur. Ceci peut amener des solutions de contournement ou des patchs. La gestion des problèmes vise à «résoudre proprement» c est-à-dire à éliminer les causes Dans une certaine mesure, la gestion des problèmes ITIL vise à prévenir les dysfonctionnements, en analysant les tendances. Mais cela est insuffisant pour traiter dans sa globalité l enjeu du préventif. Il faut pour cela une démarche fondée sur le risque (quelles vulnérabilités? Quelles menaces? Comment réduire les vulnérabilité?), positionnée dans la Gestion de la disponibilité (voir ce ) 16

17 La gestion des problèmes (2/2) Les bonnes pratiques de gestion des problèmes (au sens éliminer les causes) sont simples : on part des incidents qu il faut suivre dans une boucle d analyse /action plus large. La résolution du problème va induire en général un changement, traité en Gestion des changements Nous constatons une tendance à faire de la gestion des problèmes quelques choses de compliqué. En particulier, on part souvent trop vite sur la nomination d un Problem Manager et d une équipe dédiée, ce qui est en général trop lourd et souvent relativement inefficace, car ces personnes ont du mal «à trouver leur place» 1/ La qualification des problèmes et le suivi de l efficacité de leur résolution peuvent se faire dans une gestion d incident 2/ La résolution est à piloter en Gestion des changements (voir ce ) 17

18 La CMDB (Configuration Management DataBase) (1/3) L ensemble Help Desk, Incidents, Problèmes constitue ce qui est largement appliqué d ITIL. Avec la notion de CMDB, nous abordons ce sur quoi portent aujourd hui les efforts La CMDB = la description de l infrastructure avec le middleware et les applications installées ; au delà la gestion de l ensemble des informations liées aux incidents, changements, engagements de service sur ces éléments La notion de CMDB n est pas en elle même très originale ; il s agit d un inventaire. D ailleurs les livres ITIL ne la mettent pas en avant de manière très lisible. Le concept original est d appuyer les différents processus sur cette CMDB : gestion des changements, des engagements de service, des incidents et problèmes, financière. Elle est ainsi le référentiel de la configuration 18

19 La CMDB (Configuration Management DataBase) (2/3) Il y a aujourd hui une volonté de la part de différents éditeurs d investir ce marché (BMC, HP, Peregrine, Mercury, Tivoli, etc). Au delà de la fondation qu il constitue pour les différents processus, ce référentiel permet aussi le contrôle du client Ceci conduit à attirer l attention sur trois difficultés 1/ ITIL ne propose pas de modèle de données d une CMDB. Il se contente d énumérer ce qu il faudrait y mettre. Cette absence de modèle de référence ne facilite pas l ouverture. Elle introduit aussi un risque d échec important pour tout projet construisant une CMDB 2/ ITIL ne guide pas sur le bon niveau de détail d une CMDB efficace. La théorie est de «tout y mettre». Mais on sait bien que mettre à jour et garantir l intégrité d un référentiel est toujours compliqué, même si on a des utilitaires automatiques d inventaire. Il est essentiel dans un projet de mise en oeuvre ITIL de ne pas se perdre dans des rêves de référentiel parfait 19

20 La CMDB (Configuration Management DataBase) (3/3) 3/ Enfin, la lacune la plus essentielle. L analyse des impacts d un incident ou d un changement dans un SI nécessite de comprendre les enchaînements entre applications selon les opérations (use case) métier ; c est ce qu on appelle une vue logique ou une architecture applicative. C est une réflexion d architecture ou d urbanisme Compte tenu de son positionnement, ITIL traite superficiellement ce sujet. La problématique de gestion d une vue logique d un point de vue d architecture est également différente en terme d outil de celle de gestion d une CMDB Concrètement un projet CMDB fournira la puissance d analyse nécessaire s il s intègre à un projet de représentation de l architecture applicative du SI. ITIL ne traite pas ce sujet pourtant fondamental. Ce sujet est en outre difficile compte tenu des différences de problématiques, de responsabilités et d outils 20

21 La maitrise des changements et des releases (1/2) La gestion des changements insiste sur l analyse, la maîtrise opérationnelle et l enregistrement. ITIL insiste aussi avec raison sur la notion de release Le problème d ITIL est de ne pas distinguer correctement les différents types de changements. Il induit de fait un mode de fonctionnement qui ne peut pas donner satisfaction. Il préconise un Change Advisory Board (CAB) qui représente les différents centres de compétences de la DSI pour évaluer, approuver et prioriser les changements. En pratique cela ne marche pas Il faut en fait revenir sur les trois types de changements (qu ITIL esquisse d ailleurs correctement) 1/ Les changements standards (bureautique, déménagement, déploiement). Une RFC (Request for Change) passant par un Change Manager qui vérifie avec la CMDB puis déclenche le workflow correspondant est un bon process (pas besoin de CAB). Les outils de gestion des changements automatisent très bien ce type de process 21

22 La maitrise des changements et des releases (2/2) 2/ Les changements de version de middleware ou progiciels. Le risque est de régression. Ce sont des changements qui sont toujours non standards mais qui vont réutiliser différents «morceaux» standardisés (ex comment tester ce middleware, les contrôles de mise en production, etc.). Il s agit donc de monter le plan de changement adapté. Les outils de gestion des changements permette aujourd hui cette approche. ITIL ne la traite pas. ITIL se contente de dire qu il faut un Change Builder 3/ Les changements d envergure ou qui touchent l applicatif. Il faut alors un projet avec une vrai analyse /conception Lorsque qu il s agit d un projet applicatif qui touche l infrastructure, le plan de production ou les engagements de service opérationnels, il faut un processus d industrialisation tout au long du projet qui traite ces aspects. ITIL ne traite pas (et le dit explicitement). Or notre expérience montre l importance aujourd hui de ce processus 22

23 La gestion des engagements de service La gestion des engagements de service vise le service au métier. Elle distingue pour cela le SLA (Service Level Agreement) avec le métier, des OLA (Operational Level Agreement) internes à la DSI La grande difficulté de ce sujet est la construction d un Catalogue de Services. Il doit définir des OLA sur 1/ les processus d incidents et changements, 2/ l exploitation des applications, 3/ les applications et 4/ l infrastructure ; ces OLA doivent permettre le respect des SLA tout en restant simples et compréhensibles. ITIL n est pas suffisant sur la construction d une architecture (ou nomenclature) de services Notons que ceci nécessite aussi une vue logique (voir CMDB) Aussi, constatons nous des dérapages sur les projets de SLM liés à une réflexion insuffisante en terme d architecture de services. La puissance des outils a tendance à amplifier ce phénomène 23

24 La gestion de la continuité de service (1/2) La gestion de la continuité de service vise à aller du métier à la technologie informatique Nous pensons que le processus défini par ITIIL comporte de bonnes idées, mais n est plus adapté aux réalités de l informatique distribué. Il est fait pour un environnement mainframe Il est dans ce contexte possible de réfléchir, indépendamment des projets, à la mise en place et au test d un plan de secours 24

25 La gestion de la continuité de service (2/2) En informatique distribuée, il faut savoir réfléchir sur les risques et solutions, et savoir tester à l occasion des projets applicatifs. Il ne suffit pas de remonter un serveur ou une base, il faut la garantie de cohérence par rapport à l ensemble des flux entre serveurs ; il faut maîtriser la reconfiguration selon des paramétrages souvent complexes La conception du projet doit évaluer et prendre en compte le besoin de reprise. Il faut une réflexion tout au long du projet, or le processus ITIL ne remonte pas dans les projets Nous constatons qu il est aujourd hui urgent pour de nombreuses DSI d approfondir ces méthodes. Nous voyons régulièrement des applications avec des flux entre serveurs ou des paramétrages sur des serveurs dont personne ne sait garantir un délai de reprise 25

26 La gestion de la disponibilité (1/2) La gestion de la disponibilité traite l analyse et la conception de l infrastructure et des différents processus pour la maîtriser ITIL liste des méthodes intéressantes pour comprendre le besoin de performances et les points à améliorer. Quelques exemples CFIA (Component Failure Impact Analysis) = grille d impact CI (Configuration Item) /Service CRAMM = méthode d analyse de risque UK SOP (Service Outage Analysis) = analyse des situations d indisponibilité pour détecter les maillons faibles TOP (Technical Observation Post) = «task force» etc. 26

27 La gestion de la disponibilité (2/2) Une première limite est une description trop générale de ces méthodes. On est plus sur du principe que de la méthode. Notons que nous en avons sélectionné et approfondi certaines pour traiter les besoins suivants (cf nos publications série Manager l Informatique) 1/ Arbitrer sur les engagements de service utiles en fonction des coûts très tôt dans les projets 2/ Identifier et suivre tout au long du projet le risque d exploitabilité La seconde limite, qui est la plus fondamentale, est la non remontée dans les projets. Nous appelons cette analyse, conception, réalisation, vérification selon les aspects d exploitabilité le processus d industrialisation. Nous rappelons son importance (voir gestion des changements) 27

28 La gestion des capacités La gestion des capacités cherche à aller du métier à l infrastructure, en passant par les services. Il s agit donc de réfléchir sur les besoins d évolution à ces différents niveaux. Les données sur ces capacités sont appelées CDB (Capacity Management Data) ; le processus produit et gère un Capacity Plan La réflexion ITIL est intéressante. Nous constatons cependant qu elle est peu mise en oeuvre. La réflexion sur les capacités reste en pratique au niveau de l administration système Cette situation s explique par la nécessité de disposer d une CMDB + une vue logique + gérer des données de charge à ces différents niveaux. La plupart des DSI n ont tout simplement pas cette maturité 28

29 La gestion financière Nous abordons le dernier volet d ITIL. Nous avons vu précédemment les processus opérationnels pour maîtriser le service rendu. ITIL prévoit aussi un volet financier Le chapitre sur la gestion financière discute de l élaboration de budgets, le calcul de coûts et la refacturation. C est une réflexion intéressante mais qui ne fait pas référence car trop succincte. Elle se contente de rappeler des principes de base Par contre, on pourrait s attendre à ce qu ITIL développe la gestion de l actif informatique (asset management) : gestion des durées de vie, des remplacements, optimisation des contrats de maintenance, gestion de l efficacité des fournisseurs, stratégies de financement. ITIL ne comporte pas l asset management (nous n avons jamais compris pourquoi) 29

30 Merci 30