La présentation est en train de télécharger. S'il vous plaît, attendez

La présentation est en train de télécharger. S'il vous plaît, attendez

ITIL, LES FONDAMENTAUX Et pour L’ITSMF responsable de la commission patrimoine, éducation et normalisation Thierry CHAMFRAULT Bouygues Telecom Responsable.

Présentations similaires


Présentation au sujet: "ITIL, LES FONDAMENTAUX Et pour L’ITSMF responsable de la commission patrimoine, éducation et normalisation Thierry CHAMFRAULT Bouygues Telecom Responsable."— Transcription de la présentation:

1 ITIL, LES FONDAMENTAUX Et pour L’ITSMF responsable de la commission patrimoine, éducation et normalisation Thierry CHAMFRAULT Bouygues Telecom Responsable QoS et sécurité Direction du développement Marketing

2 ITIL, LES FONDAMENTAUX Objectifs de cette formation
Présenter et apprendre les concepts ITIL Introduire le vocabulaire ITIL Décrire les processus Pour la certification, il est nécessaire de connaître et comprendre les notions de base.

3 ITIL, LES FONDAMENTAUX Sommaire: Introduction Service Desk
Gestion des incidents Gestion des problèmes Cas pratique Gestion des configurations Gestion des changements Gestion des versions S E R V I C U P O T ITIL distingue les services de support (configurations, traitement des problèmes, etc.) des services couvrant la production des services en tant que telle (gestion de la disponibilité des équipes, du niveau des services et de l'évaluation de leur coût, etc.) Exemple d’un utilisateur de voiture Service Desk : SAV et service technique Gestion des incidents : contournement panne pot d’échappement Gestion des pbs : on résout le pb de fond Gestion des configurations : Description de la voiture (Nomenclature) Gestion des changements : Dossier d’entretien) Gestion des versions : Voiture avec frein Bendix modèle xxx

4 ITIL, LES FONDAMENTAUX Sommaire: Gestion des niveaux de service
Y Gestion des niveaux de service Gestion des finances pour les services IT Gestion de la continuité des services Gestion de la disponibilité Gestion de la capacité Exemple d’un utilisateur de voiture Gestion des niveaux de service : Contrat d’entretien du véhicule, consommation telle que caractéristique Gestion des finances : Coût de l’entretien Gestion de la continuité de service : Accident : mis à dispo d’un véhicule Gestion de la disponibilité : Votre véhicule est apte à démarrer à -40° Gestion de la capacité : Voiture pour x personnes

5 ITIL, LES FONDAMENTAUX Sommaire: Compléments
Préparation à la certification: Examen blanc E X A M N S

6 Sommaire Introduction Service Desk Gestion des incidents
Gestion des problèmes Cas pratique Gestion des configurations Gestion des changements Gestion des versions Gestion des niveaux de service Gestion des finances pour les services IT Gestion de la continuité des services Gestion de la disponibilité Gestion de la capacité

7 Introduction: Généralités
Qu’est-ce que ITIL? Information Technology Infrastructure Library Collection de livres sur les différents aspects de la gestion de la production informatique. Code de bonnes pratiques pour la fourniture de services informatiques. Adoptée et reconnue par les grandes entreprises internationales. Adoptée comme standard de facto par les ministères et entreprises aux Pays-Bas, en Grande-Bretagne et autres. Bibliothèque ouverte et publique Le référentiel ITIL (Information Technology Infrastructure Library) est le produit de plusieurs années de réflexion et d’expérience pratique des problèmes posés par la gestion de la production informatique. ITIL est aujourd’hui beaucoup plus qu’une simple bibliothèque. C’est devenu un standard pour la gestion des services informatiques. Ces spécifications restent en effet assez générales. Elles présentent néanmoins un avantage de taille: leur extrême souplesse. Cette flexibilité permet de répondre à des contextes très différents en contribuant à mettre en valeur des solutions adaptées

8 Introduction: Généralités
Qu’est-ce que ITIL? Né en G.B., fin des années 80 Développée par le CCTA (Central Computer & Telecommunications Agency ) Élaborée par des professionnels de l’informatique (Consultants spécialisés, experts indépendants, responsables de production, formateurs), Essor rapide en G.B. à la suite du Market Testing, sous le gouvernement Thatcher Le référentiel ITIL est né à la fin des années 80 en Grande-Bretagne, à la suite de la politique de "market testing" (mise en concurrence systématique des prestations internes, notamment informatiques, avec l'offre du marché) imposée par le gouvernement Thatcher aux administrations et entreprises publiques britanniques. L’ensemble de ces recommandations a été élaboré par des professionnels sous l'égide de l’OGC (Office of Government Commerce), ex CCTA (Central Computer & Telecommunications Agency (CCTA), agence gouvernementale britannique chargée d’améliorer l’efficacité et la qualité des services informatiques centraux des ministères. Existe-t-il des méthodes similaires à ITIL ? Il existe de nombreuses méthodes ciblant le management des processus. Certaines, parmi lesquelles on compte COBIT, sont plutôt orientées vers l'audit et la qualité de services, en cherchant à évaluer la maturité d'une activité. D'autres se concentrent sur la gestion des sous-traitants (ISPL) ou encore la conduite de projets (Prince 2). Des concurrents d'ITIL tentent aussi de cibler des secteurs particuliers, comme celui des télécommunications (TOM). MOF (Microsoft Operations Framework) est plus large qu’ITIL et est ciblé vers les produits Microsoft.

9 Introduction: Institutions
Office of Government Commerce (OGC) Antérieurement connu sous le nom de « Central Computer and Telecommunications Agency » (CCTA) itSMF (Information Technology Service Management Forum) Groupe international d’utilisateurs (association dans 10 pays, dont la France) EXIN, ISEB et Loyalist College Instituts examinateurs indépendants gérant le processus de certification

10 Introduction : Le positionnement de l’ITIL
Source Gartner 2003 Spécifique TCO Référents de processus ITIL CoBit Général CMMI Pertinence pour l’ informatique Six Sigma ISO 9000 Global - Niveau d’abstraction +

11 Introduction : Le positionnement de l’ITIL
Source Gartner 2003 TCO (Total Cost of Ownership) : Modèle de justification des investissements et de l’optimisation des coûts liés au soutien d’une ressource informatique (coût total). CoBit (Control Objectives for information an related Technology - objectif de contrôle de l’information et des technologies associées) : «Il constitue un référentiel complet permettant de mettre sous contrôle l’ensemble des opérations liés à l’information. Il aide les dirigeants à comprendre et à gérer les risques relatifs à l’informatique ». Association Française Audit & Conseil Informatique ISO / BS 7799 Guide et recommandations pour la gestion de la sécurité. Couvre les différents domaines des risques informatiques CMMI (Capability Maturity Model Integration) : Adresse le domaine du développement et de la qualité de système dont les produits logiciels. De nombreux points communs avec l’ITIL notamment pour la « mise en production » SIX SIGMA Méthode applicable à l’ensemble des processus de l’entreprise afin de mesurer les écarts en terme de qualité de service ISO Pas spécifique à l’IT, son développement dans les entreprises incitera à l’utilisation de l’ITIL SIX SIGMA Pas spécifique à l’IT, son développement dans les entreprises incitera à l’utilisation de l’ITIL

12 Introduction: Normalisation et Certification
La BS15000, première norme de Gestion de Services Informatiques formelle et internationale, développée par le British Standards Institute (BSI) La spécification définit les conditions qu’une organisation doit remplir pour fournir des services d’infogérance de qualité acceptable à ses clients. Elle documente la liste des objectifs et des contrôles dont une organisation peut avoir besoin pour remplir les exigences de son activité certification des personnes

13 Introduction: Niveau de certification
Niveau de base  « ITIL Foundation » Concerne ceux qui s’intéressent à ITIL Vue générale et éléments essentiels de la gestion des services IT Niveau de praticien  « ITIL Practitioner » Concerne ceux qui pratiquent la gestion des services IT. Pré-requis: 2/3 années d’expérience en gestion du processus en question Niveau de gestionnaire  « ITIL Service Manager » Concerne ceux qui implémentent les processus Certificat de gestion des services IT Pré-requis: 2/3 années d’expérience en gestion des services IT Le premier niveau ne présente que le cadre ITIL (vocabulaire et processus).

14 Introduction: Notions de base
Qu’est-ce qu’un service ? 3 définitions : Service informatique au sens organisationnel (DSI) Service informatique au sens système d’information ou énergie informatique (SI) Service informatique au sens aide, support (rendre service), prestations délivrées, (SSII) Vision du service selon ITIL: ITIL entend par la gestion des services informatiques, la gestion des prestations (aide, support, exploitation, etc) délivrées pour permettre aux utilisateurs de disposer de l’énergie informatique dont ils ont besoin. SSII: Société de service en ingénierie informatique. Cela renvoie à la notion de prestations dans le domaine informatique.

15 Introduction: Notions de base
Ma Vision du service : Le service naît lorsqu’une organisation et son collectif passe du concept « centre de coûts » au concept « centre de profits » (business approch) Qu’est ce que j’ai à vendre !

16 Introduction: Notions de base
L’importance de la partie gestion des applications selon le Gartner Group

17 Introduction: Concepts (I)
4 concepts principaux sous-tendent la philosophie de l’ITIL: Customer focus et Business justified: On entend par « client » l’utilisateur. Le client et son métier doivent être au centre des préoccupations de la direction informatique. Cycle de vie: la gestion des services doit être prise en considération en amont des projets informatiques, dès la phase d’étude et de conception. Processus: la qualité de service se fonde sur une approche par les processus. Qualité: La mesure de l’excellence. La capacité à répondre aux attentes des clients en matière de produits et services en relation avec la pratique de leur métier et ce à un coût justifiable 1 2 ITIL est né, dans les années 80, en même temps que les concepts qualité de l’ISO Les principes de base sont donc communs avec l’approche qualité, à savoir : UNE ORIENTATION CLIENT dans les limites de ce qui peut être justifié par son métier : l’utilisateur est au centre des préoccupations de la direction informatique. Les besoins concrets sont décrits dans des contrats de services (SLA). UN CYCLE DE VIE : l’ensemble du cycle de vie de l’infrastructure est couvert de la conception à la mise en œuvre et à la gestion quotidienne (cycle DESIGN – BUILD – RUN). UNE APPROCHE PROCESSUS : La production informatique est vue comme un ensemble de processus visant à rendre, aux utilisateurs, les services définis dans les SLA. UNE AMELIORATION CONTINUE : La satisfaction du client passe par une remise en cause permanente des acquis. C’est la mise en application de la boucle qualité (Roue de DEMING « Plan Do Check Act »). 3 4

18 Introduction: Concepts (II)
CUSTOMER FOCUS S’assurer que les points de vue des clients sont pris en compte et justifiés par leur métier. Mettre en place une organisation de support et de conseil pour une meilleure utilisation des services informatiques. Assurer un suivi personnalisé des « plaintes » des clients. Mesurer la satisfaction des clients Encourager les "user groups" internes. Fournir un feedback au personnel informatique. Être à l’écoute de l’évolution des besoins des clients pour anticiper sur l’adaptation des services.

19 Introduction: Concepts (III)
L’IT au service des entités métier Objectifs : Aligner les services fournis avec la stratégie métier Améliorer la qualité des services Optimiser et justifier les coûts processus Service Organisation Technologie Stratégie métier SSII: Société de service en ingénierie informatique. Cela renvoie à la notion de prestations dans le domaine informatique. 4 DOMAINES AU SERVICE DE LA STRATEGIE DE L’ENTREPRISE

20 Introduction: Concepts (IV)
CYCLE DE VIE Ne pas aborder la notion de service management (gestion des services) uniquement dans la phase d ’exploitation Prendre en compte les besoins en termes de service dès la phase de préparation des projets Évaluer l’impact des nouveaux projets sur l’infrastructure existante Définir les conditions d’exploitabilité des nouveaux systèmes Préparation Exploitation Conception Déploiement

21 Introduction: Concepts (V)
Création de la VABE & Grille d’exploitabilité Projet d ’étude Projet de réalisation Vie du projet Signature du contrat de projet Signature du contrat de projet VABF signée Fin (Fin de VSR) Spécification des besoins et choix des solutions Production VSR Réalisation Qualification Pré-prod (VABF) Vérification de l ’aptitude au bon fonctionnement SBU Architecture SERVICE RECURRENT Mise en place du SLA Définition du service Devis détaillé de l ’élaboration du service Devis détaillé du service récurrent Description détaillée des services Suivi des services Surveillance des contrats de service Reporting Suivi client du contrat Gestion des plans d ’amélioration Vérification du niveau de service (VABE) Application du contrat (VSR) Proposition de prix du service MEP Proposition du Contrat de service (Volet technique + Volet économique) Vie du service La vie du service Signature du contrat de service

22 Introduction: Concepts (VI)
Référence(s) d’usage Communication(s) QoS attendue QoS voulue MOE Partenaires MARKETING (chefs de produit) Réf Technologie(s) Référence de service MOE (Constructeur de services) EB(U) Niveau de service Business 1 Technique Client Opérateur Satisfaction client SLA (service level agreement) Mesures Chef de produit Production Partenaires QoS offerte (production) QoS Perçue Service consommateur 2 Un cycle de vie Qualité de service

23 Des indicateurs (exemple SI)
Introduction: Concepts (VI) Des indicateurs (exemple SI) Disponibilité C’est le pourcentage de temps pendant lequel le système fonctionne Délai / Performance/Latence C’est le temps de traversée d ’un système ou le temps de mise à disposition du service à l ’utilisateur Fiabilité C’est le pourcentage de temps pendant lequel le système fonctionne sans erreur Capacité C’est la faculté d ’un composant de répondre à une demande de service de taille donnée pour un état interne donné de ce composant (conformité à la volumétrie contractuelle)

24 Introduction: Concepts (VI)
Des Modes Nominal Ce mode caractérise un service qui dispose de l ’ensemble de ses ressources et capacités Dégradé Ce mode caractérise le comportement d ’un service lors d ’une perte de capacité Croissance Ce mode caractérise le service lors d ’une augmentation des sollicitations ou volumes

25 Introduction: Concepts (VI)
Différentes visions QoS Supervision de service – pt de vue court terme alerter en temps réel sur une baisse ou rupture de QoS Mesure de QoS - pt de vue moyen terme Caractériser la performance d’un service sur une période significative (semaine, mois, …) – QoS Offerte, QoS perçue Qualification d’un service Evaluer avant une mise en ligne, la QoS offerte par un nouveau service. Respect d’exigences et référent pour le futur

26 ITIL – Chaîne de Maturité
Introduction: Concepts (VII) ITIL – Chaîne de Maturité Valeur Rapprochement Services et indicateurs Business Service Capacity Management, Service Level Management (SLA, OLA/UC) Proactif Problem Management, Change Management, Availability Management Réactif Service Desk, Incident Management, Configuration Management Chaos Plusieurs Help Desk, Découverte des problèmes, ….. Court terme Moyen terme Long terme

27 Positionnement de la maturité des entreprises (Gartner Group)
Introduction : Concepts (VII) Positionnement de la maturité des entreprises (Gartner Group)

28 ITIL et la Qualité de Service (QoS)
Introduction: Concepts (VIII) ITIL et la Qualité de Service (QoS) Le Client du Service raisonne en terme de qualité du contenu accessible depuis son terminal Valeur Il faut un pivot entre les deux visions Service Le Fournisseur du Service raisonne en terme de disponibilité du contenant sur son infrastructure Proactif Les opérationnels ont assez peu la vision du service délivré aux utilisateurs Réactif Les opérationnels sont souvent avertis des incidents par les utilisateurs Chaos Court terme Moyen terme Long terme

29 Propriétaire du processus
Introduction: Concepts (IX) Enchaînement d’activités réalisées avec des moyens et selon des règles en vue de générer un produit de sortie destiné à satisfaire et fidéliser les clients ou en vue d’atteindre un objectif. PROCESSUS Contrôle du processus Définition, objectifs et amélioration du processus Propriétaire du processus Objectif paramètres de qualité et indicateurs de performance PROCESSUS Entrée ACTIVITE 1 ACTIVITE 2 ACTIVITE 3 Sortie Pour chaque processus, on retrouve: des entrées prévisibles, des sorties prévisibles et définies Un propriétaire, celui qui conçoit le processus, Un manager ou responsable du processus, celui qui le fait fonctionner, Des mécanismes de mesure (ou contrôle). Procédure a Procédure b Procédure: Ensemble de tâches* indissociables faisant partie d’un processus Tâche: Action(s) à réaliser dans un temps fixé pour laquelle on connaît l’entrée et le résultat attendu Exécution et mise en œuvre du processus Rôles Ressources Manager du processus Contributeurs

30 ………. Selon les règles du monde industriel
Introduction: Concepts (IX) PROCESSUS ………. Selon les règles du monde industriel Efficacité: Résultats obtenus par rapport aux objectifs du processus Rentabilité et concurrence Efficience : Résultats obtenus par rapport aux moyens engagés Productivité Pour chaque processus, on retrouve: des entrées prévisibles, des sorties prévisibles et définies Un propriétaire, celui qui conçoit le processus, Un manager ou responsable du processus, celui qui le fait fonctionner, Des mécanismes de mesure (ou contrôle).

31 Introduction: Concepts (X)
QUALITÉ Plan Act Check Do Satisfaction des clients à des coûts acceptables Qualité Temps Structure des processus: ITIL est un gage de la gestion des services IT Roue de DEMING Roue de DEMING – vieux concept (50s). Plus on structure les services à rendre (prestations, aide, support), plus on augmente la qualité et la satisfaction des clients.

32 Introduction : Une évolution de la culture DSI
Aujourd’hui Hier Utilisateurs Tourné vers l'intérieur Centré sur les technologies "Faire son possible" Spécifique, interne Réactif Cloisonnement des compétences Exploitation des "machines" Clients Tourné vers l'extérieur Centré sur les processus Contrats, résultats Standard, externalisation Proactif Support de "bout en bout" Gestion des services

33 Introduction: Les acteurs
Client La personne qui paie l’énergie informatique et définit le niveau d’énergie dont il a besoin (disponibilité, capacité, niveaux de service, sécurité, coûts) Utilisateur La personne qui utilise le système d’information tous les jours. Fournisseur interne L’unité responsable de la fourniture de services (prestations). Fournisseur externe Tierce partie responsable de la fourniture ou du soutien des éléments des services (prestations). PDG Souligner la difference entre client et utilisateur

34 Introduction: Les Relations entre acteurs
Un exemple

35 Introduction : Principes à sa mise en vie
Mettre en perspective l’activité métier de l ’entreprise avec les services informatiques correspondants. Systématiser la démarche. Rechercher l’adhésion plutôt que de l ’imposer. Apporter une compatibilité avec une démarche qualité de type ISO 9001 (version 2000), Véritable approche de gestion de projet.

36 Introduction: Les domaines couverts (I)
"Cœur de la méthode" IT Service Management selon ITIL Delivery IT Service Capacity Management Financial Management for IT Services Availability Management Service Level Management IT Service Continuity Management Support IT Services Service Desk Incident Management Problem Management Configuration Management Change Management Release Management The Business Perspective Customer Relationship Management Business Continuity Management Partnerships and Outsourcing Surviving Change Transformation of business practice through radical Change Manage the Infrastructure Network Service Management Operations Management Management of Local Processors Computer Installation and Acceptance Systems Management The Business perspective - Eclairer le management sur : les spécificités des technologies informatiques et de communication, éléments clés au service des activités de l’entreprise Les activités opérationnelles qui assurent la fourniture des services L’intérêt d’organiser ces activités en se basant sur des standards et meilleures pratiques ICT infrastructure Management La gestion des infrastructures, depuis l’identification des exigences métiers, les tests, l’installation, le déploiement, la maintenance des infrastructures. Il décrit les principaux processus suivants : Conception et planification, Déploiement , Gestion des opérations, support technique Planning to implement service Management Les principaux obstacles à contourner lors de la mise en œuvre d’une gestion des services Les principales étapes trajectoires possibles pour l’amélioration progressive des services Les principes d’évaluation applicables pour la définition de niveaux de maturité de la gestion des services et des processus associés Application Management Chainon entre études et production, entre fonctionnel et infrastructures, entre projet et processus opérationnels Décrire les meilleures pratiques de la gestion des applications vues depuis la gestion des services Mettre en évidence la nécessité d’une approche intégrée dépassant les clivages historiques Montrer les bénéfices d’une telle approche dans les projets, du développement au déploiement Managing Applications Software Development Lifecycle Software Lifecycle Support Testing for IT Services Planning to implement Service Management Strategic Management of IS • Managing Performance Managing Change • Managing Services Acquisition

37 "Cœur" IT Service Management selon ITIL
Introduction: Les domaines couverts (II) "Cœur" IT Service Management selon ITIL Service Support Configuration Management Service Desk Incident Management Problem Management Change Management Release Management Service Delivery Service Level Management Capacity Management Availability Management Financial Management for IT Services IT Service Continuity Management En plus de cela, il en encore une quarantaine de volumes différents, dont la majorité était toujours bien entretenue. Les meilleurs collections et les plus fiables et utilisées sont présentées sur le slide. ICT Infrastructure Management Applications Management Planning to Implement Service Management Security Management The Business Perspective

38 Introduction : contenu Type d’un chapitre
Chaque module ITIL décrit un domaine / processus selon une approche projet Plan-type d'un module: étude implémentation post-implémentation et audit bénéfices, coûts et difficultés potentielles outils synthèse et recommandations Disponible en 2 CD: Service Support Service Delivery

39 Introduction: Les Processus ITIL (I)
DELIVERY ITSM entre Business et Fournisseurs. Tous les processus sont liées. Certaines relations sont plus importantes que d’autres. Plusieurs processus sont “plus Back office que Front office”. SD peut participer à plusieurs processus de Support et aussi de SLM. SUPPORT

40 La mise en œuvre d’ITIL : Le principe des « 3 P »
Métier de l’entreprise Processus Compétences et management Personnes Meilleures pratiques Outils et technologies Produits

41 ITIL – Les apports 1/2 Facilite le dialogue grâce à un langage commun
Compréhension des demandes clients et de notre capacité à répondre efficacement Efforts fournis vers le client, plutôt que vers la technologie Amélioration du ratio coût / service rendu Meilleure efficacité et réduction des activités répétitives

42 ITIL – Les apports 2/2 Amélioration de la performance et du moral des équipes Meilleure perception des clients Confiance dans la DSI vis-à-vis de ses propres fournisseurs de service (infogéreurs). Justification de la « Dépendance » de la société envers sa DSI/Infogéreur Formalisation de l’offre de services aux clients

43 Introduction: Les Processus ITIL (I)
MANAGEMENT NIVEAU «STRATEGIQUE » NIVEAU «STRATEGIQUE THE BUSINESS THE BUSINESS PERSPECTIVE PERSPECTIVE La conception des services Investment Service level Life Cycle Capacity Availability Business/IT Co $t Business Continuity Continuity etc. management management management management management Procurement management alignment management management CUSTOMER RELATIONSHIP MANAGEMENT SERVICE SERVICE DELIVERY DELIVERY NIVEAU «TACTIQUE » NIVEAU «TACTIQUE La gestion des services Service Service level level Capacity Capacity Availability Availability Financial Co $t Service Continuity Continuity management management management management management management management management management management SERVICE DESK SERVICE SERVICE SUPPORT SUPPORT NIVEAU «OPERATIONNEL» NIVEAU «TERRAIN» La gestion de l’exécution des services Service Support - Gestion des services signifie gestion des prestations Service Delivery - Gestion des services signifie gestion des systèmes d’information, de l’énergie informatique. RQ: Certaines personnes ont deux rôles. Par exemple, la gestion de la réalisation des services et la réalisation des services. Configuration Configuration Incident Incident Problem Problem Change Change Release Release management management management management management management management management management management BACK OFFICE SERVICE SERVICE OPERATIONS OPERATIONS NIVEAU «OPERATIONNEL» (TERRAIN) NIVEAU «TERRAIN» L’exécution des services et l’exploitation de l’infrastructure Manage the Manage the Managing Managing Infrastructure Infrastructure Application Application

44 Gestion des configurations Gestion des changements
ITIL – Bénéfices par niveaux Processus « SUPPORT » Stratégie Tactique Opérations Service Desk Réduire la pression sur les personnes en les re-concentrant sur leur cœur de métier Diminuer le TCO Augmenter le ROI Gérer les relations « clients » Gestion des incidents Diminution de l’impact des incidents sur l’entreprise Support de nouvelles applications Résolution de manière professionnelle et organisée des incidents Gestion des problèmes Diminution des défaillances et des failles de l’informatique Protection pro-active des services informatiques Réduction du nombre d’incidents Gestion des configurations Au delà de la gestion des amortissements, connaissance à tout moment de son référentiel et de son historique Évaluation immédiate de l’impact de tout incident sur l’ensemble du référentiel concerné Gain de 50% en temps pour la gestion des incidents (source : Gartner) Gestion des changements Contrôle de l’ensemble des éléments de changement Optimisation des ressources Contrôle du cycle, moins d’incidents Gestion des versions Meilleure distribution des nouvelles versions, donc impact négatif minimisé sur le métier de l’entreprise Optimisation des ressources Meilleures productivité Gestion du personnel amélioré (prise en compte en amont) Meilleur support des nouvelles versions

45 Gestion des niveaux de service Gestion financière pour les services IT
ITIL – Bénéfices par niveaux Processus « DELIVERY » Stratégie Tactique Opérations Gestion des niveaux de service Optimisation des coûts, meilleure qualité/prix Services informatiques adaptés aux besoins de l’entreprise à des coûts optimisés La comparaison entre le niveau rendu et le niveau prévu, permet de trouver des axes d’amélioration Gestion financière pour les services IT Les décisions sont prises en connaissant tous les coûts Les coûts sont identifiables, voir facturables Le budget est « taillé » de manière optimale et permet de traiter le quotidien Gestion de la continuité de service L’entreprise survit aux désastres Les nouveaux projets ne mettent pas en péril les plans de reprises, car ils sont intégrés . Les plans sont testés et fonctionnent. Le personnel est formé Gestion de la disponibilité Adéquation du SI à l’activité de l’entreprise, en optimisant les coûts de production Idem Stratégie Gestion des capacités Permet d’aider à décider de la stratégie à adopter (a t on les moyens de le faire ?) Les capacités sont gérées de manière optimales Les capacités sont prêtes à accepter des montées en charge sur le système EXISTANT

46 Un point de vue sur demain
Evaluation normalisée des processus et des best practices Un rapprochement entre CMMI (Capability Maturity Model Integration) et ITIL pour l ’évaluation de la maturité des organisations opérationnelles Une prise de conscience de l’efficacité des audits (COBIT) Une norme qualité de métier Questionnaires itSMF, OGC, pink elephant OGC a défini pour certains process (pb management) une évaluation par niveau (1, 1.5, 2, 2.5, 3, 3.5, 4, 4.5 et 5) Gartner a mis en place une échelle des maturités à 4 niveaux ITIL CMM 4 Valeur 5 Optimisation 3 Service 4 Mesure et contrôle 2 Proactive 3 Défini 1 Reactive 2 Reproductif 1 Non défini Intégration concrète « Développement - production »

47 LES PROCESSUS SUPPORT SUPPORT : On se concentre sur les opérations quotidiennes et le support aux services informatiques Questionnaires itSMF, OGC, pink elephant OGC a défini pour certains process (pb management) une évaluation par niveau (1, 1.5, 2, 2.5, 3, 3.5, 4, 4.5 et 5) Gartner a mis en place une échelle des maturités à 4 niveaux ITIL CMM 4 Valeur 5 Optimisation 3 Service 4 Mesure et contrôle 2 Proactive 3 Défini 1 Reactive 2 Reproductif 1 Non défini

48 Sommaire Service Desk Introduction Gestion des incidents
Gestion des problèmes Cas pratique Gestion des configurations Gestion des changements Gestion des versions Gestion des niveaux de service Gestion des finances pour les services IT Gestion de la continuité des services Gestion de la disponibilité Gestion de la capacité

49 Le Service Desk Définitions préalables
SUPPORT Définitions Typologies Objectifs Caractéristiques Bénéfices Ce n’est pas un processus mais une fonction au sens de l’organisation (= unité organisationnelle). Définitions préalables CALL CENTER: reçoit un volume important d’appels, les enregistre et les dirige vers les groupes compétents. Pas de traitement. HELP DESK: traite les incidents et les demandes aussi rapidement que possible. SERVICE DESK: fournit une gamme de services (prestations) plus étendue avec une approche « métier » : il est le point de contact unique pour les utilisateurs, il pilote le processus de gestion des incidents et fournit une interface avec tous les autres processus ITIL. Les noms des unités qui se chargent de contacts avec les clients sont nombreux, les objectif sont les mêmes: aider les clients le mieux possible et le plus vite que possible. Ajoutez les noms différents de votre expérience: Business Desk, Centre d’expertise informatique, Services Informatiques, User support, Business support, etc.etc.etc.

50 Le Service Desk Définitions Typologies Objectifs Bénéfices
Caractéristiques Bénéfices Call Center, Help Desk et Service Desk sont en fait trois niveaux organisationnels.

51 Le Service Desk Typologies Local Centralisé Virtuel SD Définitions
Objectifs Caractéristiques Bénéfices Local User Service Desk Desktop Support Network & Operations Application Third Party First line support Typologies Local Centralisé Virtuel Site 1 Site 2 Site 3 Centralised Service Desk Desktop Support Network & Operations Application Third Party Second Line Support La typologie est dictée par les circonstances et la nécessité. Elle est fonction des volumes traités, du périmètre couvert, des utilisateurs et de leurs attentes. Toulouse Service Desk Limoges Service Desk London Service Desk Modem WAN Velizy Service Desk SD Paris Service Desk CMDB

52 Le Service Desk Objectifs
Définitions Typologies Objectifs Caractéristiques Bénéfices Objectifs Être la principale interface entre la DSI et les utilisateurs. Filtrer les appels des utilisateurs. Assurer la prise en compte et le bon traitement des appels utilisateurs. Être l’interface avec tous les autres processus ITIL de l’organisation

53 Accessibilité convenue Bonne qualité d’accueil
Le Service Desk Définitions Typologies Objectifs Caractéristiques Bénéfices Le SD est accessible Accessibilité convenue Bonne qualité d’accueil Entrées diverses (mail, system, téléphone, Internet, messages automatiques, etc.) Le SD est compétent IT et métiers (infrastructure, service, applications, technique, organisation, etc.) Le SD doit être accessible et capable de répondre aux attentes des métiers.

54 Le Service Desk Bénéfices
Définitions Typologies Objectifs Caractéristiques Bénéfices Bénéfices Point de contact unique (SPOC) –> Gestion de l’image Propriétaire de l’incident –> Clarté de l’organisation du support Haute qualité de support pour atteindre les objectifs métiers Aide pour identifier les coûts réels de l’informatique Support et communication pour et sur les changements Amélioration de la perception des services IT (prestations) et de la satisfaction des utilisateurs – clients. Identification des opportunités métiers (process d’amélioration). le Service Desk est structurant pour l’ensemble de la production informatique  : ·         Parce qu’il est la vitrine vis-à-vis de l’utilisateur, il porte l’image des services informatiques. ·         Parce qu’il assure le reporting et le pilotage des activités, il porte la performance. ·         Parce qu’il est garant de la qualité, il « tire » tous les processus vers l’amélioration.

55 Centre névralgique de la traçabilité opérationnelle
Le Service Desk Définitions Typologies Objectifs Caractéristiques Bénéfices Activités Recevoir, enregistrer, établir des priorités et suivre les appels relatifs aux services Surveiller et suivre le statut de tous les appels enregistrés Transférer et escalader vers les bonnes organisations Générer des rapports sur les appels Fournir un support de premier niveau Tenir les clients informés du statut et évolution des demandes Coordonner les organisations niveau 2 et les prestataires externes Clôturer les incidents après avoir eu confirmation du client le Service Desk est structurant pour l’ensemble de la production informatique  : ·         Parce qu’il est la vitrine vis-à-vis de l’utilisateur, il porte l’image des services informatiques. ·         Parce qu’il assure le reporting et le pilotage des activités, il porte la performance. ·         Parce qu’il est garant de la qualité, il « tire » tous les processus vers l’amélioration. Centre névralgique de la traçabilité opérationnelle

56 Sommaire Gestion des incidents Introduction Service Desk
Gestion des problèmes Cas pratique Gestion des configurations Gestion des changements Gestion des versions Gestion des niveaux de service Gestion des finances pour les services IT Gestion de la continuité des services Gestion de la disponibilité Gestion de la capacité

57 Gestion des incidents Objectif
SUPPORT Définitions Objectifs Activités Objectif Restaurer(1) le niveau de service convenu avec l’utilisateur-client, aussi vite que possible et en accord avec ce qui a été convenu (engagement de service). (1) Restaurer ne veut pas dire trouver la cause. Ceci est l’objectif d’un autre processus Et s’il n’y a pas de niveau de service convenu? Alors l’objectif sera de résoudre les incidents le plus vite possible.

58 Gestion des incidents Définition d’un incident
Définitions Objectifs Activités Définition d’un incident Tout événement qui ne fait pas partie des opérations standard pouvant provoquer une interruption de service ou altérer sa qualité. Caractéristiques d’un incident Un incident est caractérisé par : Son impact, qui permet de mesurer le volume et l’ampleur de l’incident, l’effet produit sur l’organisation et le business son urgence, qui est fonction de la criticité de l’incident par rapport à l’activité de l’utilisateur Priorité = fonction de l’impact et de l’urgence Détermine l’ordre dans lequel les incidents doivent être traités. Nota : Ne faite pas de votre client ou de votre utilisateur, votre meilleur superviseur d’incidents

59 Gestion des incidents Activités principales
Définitions Objectifs Activités Activités principales Qualifier, enregistrer et documenter tous les incidents Classifier les incidents, trouver les correspondances par rapport aux événements déjà survenus Déterminer l’impact et l’urgence, donc la priorité Classifier et assurer le 1er niveau de diagnostic Assurer si possible une résolution immédiate Router vers les groupes support plus compétents ou ayant plus de pouvoirs (escalade) Suivre le processus de résolution Vérifier de la bonne correction de l’incident Informer l’utilisateur Clore l’appel (clôture technique et clôture administrative)

60 MTBF (Mean Time Between Failures) Temps moyen entre 2 pannes
Gestion des incidents Définitions Objectifs Activités Cycle de vie d’un incident MTTR (Mean Time To Repair) Temps moyen de réparation " Down-time"        Up-time Restauration Incident no.1 Temps de Temps de Incident no.1 est resolu Incident no.2 Réponse Restauration MTBF (Mean Time Between Failures) Temps moyen entre 2 pannes Mean - Moyenne est une unité de calcul de le gestion de disponibilité, puisqu ’elle donne de la statistique pour tous les services et CI. Détection Diagnostic Solution Correction Temps de Détection Temps de Réparation Vision technique de l’incident MTBSI (Mean Time Between System Incidents) Temps moyen entre 2 incidents système

61 Gestion des incidents Roles et responsabilité
Le Gestionnaire des incidents (incident manager) doit développer et compléter les besoins fonctionnels liés à la gestion du processus. Il en assure le reporting Le Service Desk de 1er niveau doit enregistrer les incidents, classifier, assigner, suivre, tracer, communiquer, traiter les incidents (non assignés au support 2e niveau) et clore les incidents après résolution). le Service Desk de 2e niveau doit contrôler les particularités des incidents, analyser et diagnostiquer les incidents, traiter et résoudre les incidents alloués.

62 Gestion des incidents Procédure d’escalade 2 types d’escalades :
Fonctionnelle Hiérarchique 2 objectifs liés à l’escalade : Informations et supports Affectation des ressources

63 Gestion des incidents Exemples d’indicateurs de performance
Nombre total et relatif d’incidents Temps entre l’enregistrement et la résolution % des incidents résolus dans les termes de SLA Coût moyen par incident % clôture par Service Desk sans escalade Nombre d’incidents par opérateur de Service Desk Exemples. N’exagérez pas. Pour que toute la performance du processus ne sera pas consommée par les actions de contrôle de soi même Réfléchissez aussi sur les Indicateurs de performance pour les autres processus ITIL au cour du training.

64 Sommaire Gestion des problèmes Introduction Service Desk
Gestion des incidents Gestion des problèmes Cas pratique Gestion des configurations Gestion des changements Gestion des versions Gestion des niveaux de service Gestion des finances pour les services IT Gestion de la continuité des services Gestion de la disponibilité Gestion de la capacité

65 Gestion des problèmes Objectifs
SUPPORT Définitions Objectifs Activités Objectifs Analyser et trouver les causes premières des incidents et apporter des solutions pour prévenir de nouveaux incidents et minimiser l’impact négatif sur le business. Trouver les causes et prévenir! Et non pas uniquement analyser, réfléchir et changer l’infrastructure, ou implémenter, conseiller un meilleur fournisseur, logiciel, solution technique.

66 Gestion des problèmes Définition d’un problème
Définitions Objectifs Activités Définition d’un problème Un problème est la cause inconnue d’un incident significatif ou de plusieurs incidents présentant les mêmes symptômes. Définition d’une erreur connue Le problème devient une erreur connue lorsque la cause du ou des incidents est trouvée, par contre la solution n’est pas encore implémentée. Les problèmes sont antérieurs (dans le temps) aux incidents puisqu’ils sont à l’origine des incidents. Mais la gestion des incidents intervient avant la gestion des problèmes.

67 Gestion des problèmes Activités principales
Définitions Objectifs Activités Activités principales Contrôler les problèmes (problem control) Identifier et enregistrer Classifier et allouer des ressources Diagnostic et analyser les causes premières Effectuer des revues sur les problèmes majeurs Contrôler les erreurs connues (error control) Evaluer l’erreur et allouer les ressources Rechercher une solution afin de les éliminer ou trouver une solution de contournement Émettre une demande de changement (RFC) Tracer et piloter Reporter Clôturer l’erreur connue Prévenir les problèmes 3 sous-processus différents.

68 Gestion des problèmes Appels Incidents Problèmes Erreurs Connues
Changements

69 Gestion des problèmes Comment être pro-actif ? Analyse des Tendances
Occurrence de problèmes particuliers après changements Problèmes récurrents par type ou par composant Action préventive Proposer les changements préventifs Initialiser la formation et la documentation S’assurer du respect des procédures Initialiser une démarche d’amélioration Fournir un feedback pour les tests, la formation et la documentation Est-ce que le management réserve assez d’argent pour ce genre d’activité?

70 Gestion des problèmes Rôles et responsabilité
Le Gestionnaire des problèmes (problem manager) doit développer et compléter les besoins fonctionnels liés à la gestion du processus. Il en assure le reporting Le Groupe de Support aux Problèmes a deux types de responsabilités: Réactives: identification, analyse, proposition des demandes de changement, suivi des erreurs, information au groupe de support de gestion des incidents pour les différentes solutions de résolution, participation aux résolutions des incidents pour identifier les causes réelles. Pro-actives: identification des sources de problèmes éventuels, proposition de solutions pour éviter la duplication des incidents. Est-ce que le management réserve assez d’argent pour ce genre d’activité?

71 Sommaire Cas pratique Introduction Service Desk Gestion des incidents
Gestion des problèmes Cas pratique Gestion des configurations Gestion des changements Gestion des versions Gestion des niveaux de service Gestion des finances pour les services IT Gestion de la continuité des services Gestion de la disponibilité Gestion de la capacité

72 Cas pratique: «Orientation client!» (1)
Environnement Messaging & Groupware, utilisateurs Organisation “Support Utilisateurs” 1 Propriétaire des processus Incidents et Problèmes 4 Business Desks (par métier) – pour les demandes Appels et plaintes tout ce qui n’est pas un incident selon utilisateur 4 Bases de données différentes par Business Desk Help desk – pour les incidents (1ère ligne) Priorité = impact Base de données Lotus Notes Service Desk – pour les problèmes (2ème ligne) Incidents priorité 1 Tout ce qui n’est pas résolu par HD Demandes et Incidents urgents selon utilisateurs Base de données ARS  Donnez 5 points faibles et 5 recommandations d’amélioration. S e r v I c D s k I n c i d e t M a g m P r o b l e m M a n g t Les points faibles: Il n’y a pas de single point of contact. Il y a plusieurs. L’utilisateur décide beaucoup trop. Il y a plusieurs bases de données. Deux processus ( problèmes et incidents) sont mélangés alors qu’ils n’ont pas les même objectifs. Le Service Desk récupère tous les appels si le Help Desk ne veut pas les traiter. Priorité = impact La deuxième ligne ne gère pas les problèmes. Elle constitue un niveau d’escalade pour les incidents. La propriété de deux processus dont les objectifs sont opposés ne peut pas être concentrée sur la même personne Un seul incident peut être enregistré trois fois (même 6) dans des bases de données différentes “Tout ce qui n’est pas resolu par HD est tranféré au SD! Si l’urgence n’est pas prise en compte dans les calculs des priorités, l’escalade hiérarchique est un danger réel. Urgence définie par l’utilisateur - dangereux, parce que pour l’utilisateur tout est urgent. Recommandations: Regrouper BD et SD pour faire un point de contact unique. Intégrer les bases de données. Formation, dialogue sur le SD. Urgence ne doit pas être défini par l’utilisateur, mais par le client avec SLM dans les SLA a la base d’analyse de criticite metiers et d’autres donnees Liez l’impact avec urgence pour en déduire la priorité, demontrez les avantages de ceci Les définitions du problème et de l’incident doivent être formulées en termes ITIL etc

73 Sommaire Gestion des configurations Introduction Service Desk
Gestion des incidents Gestion des problèmes Cas pratique Gestion des configurations Gestion des changements Gestion des versions Gestion des niveaux de service Gestion des finances pour les services IT Gestion de la continuité des services Gestion de la disponibilité Gestion de la capacité

74 Gestion des Configurations
SUPPORT Définitions Objectifs Activités Objectifs Maîtriser tous les composants de l’infrastructure nécessaire à la fourniture des services IT (référentiel) Assurer la précision et la fiabilité de cette information Vérifier l’adéquation entre le référentiel et la réalité Fournir une base solide pour la gestion des incidents et la traçabilité des changements Attention: gestion des actives ne fait que gérer du point de vue finances et coût seulement des actifs qui depassent un certain valeur, déterminé dans le budget.

75 Gestion des Configurations
Définitions Objectifs Activités Définitions Configuration Item (CI) : élément de l ’infrastructure du SI, nécessaire pour fournir un service, unique et identifiable, modifiable et gérable, documenté (HW, SW, procédures, organisation, SLA,…) Configuration Management Data Base (CMDB) : base de données contenant l’ensemble des informations relatives aux CI’s, à leurs relations et à leur historique. Le Niveau de Détail (CI Level) est le niveau auquel on arrête la décomposition en CI. Plus le niveau de détail est important, plus le suivi est complexe Il ne doit pas atteindre un niveau supérieur à ce qui est maîtrisable et contrôlable. Ne pas oublier la notion de variante, qui est une modification légère d’un CI.

76 Gestion des Configurations
Caractéristiques d’un CI (Configuration Item) Statut (obligatoire) Planifié, en commande, en développement, en test, en stock, en service, en maintenance, réformé… Attributs Nom, Numéro de série, Type, Modèle, Numéro de version,... Localisation, responsable, Fournisseur, Constructeur, Date de livraison, d’installation, date de mise au rebus. Relations Parent/enfant, un CI fait partie d‘un autre CI, de connexion, d’utilisation, est une version de ou une variante de…. Variante  même procédure de fabrication. Un ou plusieurs item de configuration change. Version  nouvelle procédure de fabrication.

77 Gestion des Configurations
Modélisation et Granularité : Modéliser par catégorie de CI Définir le niveau de détail Définir les relations entre les CI Serveur Poste de travail Périphériques UC Disques Application Master Processeur 1 Carte réseau 1 Application Poste de travail Bi-directionnel Application cliente

78 Gestion des Configurations
Définitions Objectifs Activités Activités principales Concevoir (mener la discussion sur le niveau de détail, élaborer la stratégie, rôles, interfaces, CMDB design, etc.)  Plan de Gestion de configuration Identifier les composants Vérifier que l’infrastructure ne contient que des composants autorisés Contrôler les modifications et changements Vérifier la conformité des informations (audit) Mettre à jour la CMDB Enregistrer et suivre les évolutions des CIs (statut) Recenser les informations sur tous les composants du SI, sous contrôle du processus de gestion des configurations Mettre en exergue les relations entre les différents composants Contrôler les changements Vérifier = auditer

79 Gestion des Configurations
Différence avec une gestion de biens (asset management): La CMDB contient les CI nécessaires à la fourniture de services, y compris la documentation. La CMDB contient les informations sur les relations entre les CI. Les liens avec les outils d’inventaire : Ils permettent l’identification des incohérences entre inventaire physique et CMDB. Les écarts sont traités par un processus de réconciliation. La mise à jour de la CMDB passe par une validation du changement.

80 Gestion des Configurations
Bénéfices attendus de la CMDB Informations précises sur les CI et leur documentation : Soutient les autres processus de gestion des services IT. Facilite le respect des obligations légales et contractuelles. Aide à la planification financière : identification des biens et des liens entre eux Améliore la gestion des logiciels : Rend les changements visibles. Améliore la sécurité sur les logiciels en contrôlant les versions autorisées. Facilite l’analyse de l’impact et des tendances lors d’incidents, de changements ou de problème .

81 Gestion des Configurations
Rôles et responsabilité Le Gestionnaire des configurations (configuration manager) doit développer et compléter les besoins fonctionnels liés à la gestion du processus. Il en assure le reporting Le Gestionnaire de la Bibliothèque des Configurations a pour rôle de développer et maintenir la CMDB (Configuration management Data Base). Est-ce que le management réserve assez d’argent pour ce genre d’activité?

82 Sommaire Gestion des changements Introduction Service Desk
Gestion des incidents Gestion des problèmes Cas pratique Gestion des configurations Gestion des changements Gestion des versions Gestion des niveaux de service Gestion des finances pour les services IT Gestion de la continuité des services Gestion de la disponibilité Gestion de la capacité

83 Gestion des Changements
SUPPORT Définitions Objectifs Activités Objectifs Appliquer des changements qui ont été autorisés, de manière efficace et avec un risque acceptable sur la QoS des services IT existants et les nouveaux services S’assurer, pour cela, de l’utilisation de méthodes et de procédures standards pour conduire rapidement et efficacement un changement. Eviter les incidents futurs provoqués/causés par les changements implementés. Un processus qui se situe entre niveau tactique et strat Utiliser les slides et tout le matériel du training au maximum pour la preparation des presentationsgique. Un pivot. Gestions des projets, maitrise d’ouvrage, developpement l’influencent beaucoup. Tenir compte des cycles de vie, don’t on a parlé dans l’introduction.

84 La nécessité de maîtriser les changements
Gestion des Changements La nécessité de maîtriser les changements SUPPORT

85 Gestion des Changements
Définitions Objectifs Activités Définitions Changement Tout changement de l ’infrastructure qui a pour conséquence un changement de statut d’un ou plusieurs CIs RFC Demande de changement CAB Comité Consultatif des Changements (Change advisory Board) PIR Post Implementation Review FSC Forwarded Schedule of Changes (détails de tous les changements planifiés et approuvés pour l’implémentation) PSA Projected Service Availability (disponibilité de service prévue: influence possible de tous les changements sur la disponibilité du service)

86 Gestion des Changements
Définitions Objectifs Activités Etendue de la gestion d’un changement Le hardware Le logiciel et équipements de communication Logiciels (OS, Base de données, …) Les applications en production La documentation et les procédures L’environnement

87 Gestion des Changements
Gestion des changements  Réalisation du changement (Maîtrise d’œuvre) Définitions Objectifs Activités Objectifs principaux de la maîtrise d’œuvre: La livraison des résultats convenus, dans les temps et en ne sortant pas des limites budgétaires et, surtout, Prévenir le “Project Board” à temps des risques de ne pas réussir.

88 Gestion des Changements
Exemples de meilleures pratiques Catégorie d’un changement Business Impact mineur Ressources et coûts faibles Décision administrateurs, Business Impact significatif Ressources, coûts et risques importants Décision comité de pilotage ou CAB Business Impact majeur Ressources, coûts et risques majeurs Décision comité directeur Priorité d’un changement Urgent Haut Moyen Bas Les pratiques existantes dans l’organisation sont ici dirigeantes.

89 Gestion des Changements
Définitions Objectifs Activités Activités principales Gérer les demandes de changement (Requests for Changes RFC) Estimer l’impact et les coûts du changement Évaluer les risques et influence sur la disponibilité des services Autoriser les changements Planifier les changements Mettre en œuvre les changements approuvés Piloter les changements Évaluer les changements Contrôler l’ensemble du processus

90 Gestion des Changements
Rôles Le propriétaire du processus Le manager du processus (gestionnaire des changements) CAB sous la présidence du gestionnaire Business manager Délégué des utilisateurs Études Fournisseur Gestionnaires d’autres processus, etc. Techniciens réalisant les changements Très important de choisir le niveau de responsabilité dans la structure hiérarchique d’organisation pour placer les activités du CAB. Trop haut - manque d’expertise, trop bas - manque de pouvoir. CAB virtuel, par mail, qui ne se voit pas souvent serait une bonne solution.

91 Sommaire Gestion des versions Introduction Service Desk
Gestion des incidents Gestion des problèmes Cas pratique Gestion des configurations Gestion des changements Gestion des versions Gestion des niveaux de service Gestion des finances pour les services IT Gestion de la continuité des services Gestion de la disponibilité Gestion de la capacité

92 Ne pas omettre de respecter les obligations légales
Gestion des versions SUPPORT Définitions Objectifs Activités Objectifs S’assurer que seules les versions autorisées et testées des logiciels et des matériels sont mises en production et distribuées Planifier et communiquer sur la disponibilité des nouvelles fonctionnalités avant, pendant et après leur implémentation. Constituer et assurer l’intégrité de la bibliothèque des logiciels utilisés (DSL: Definitive Software Library) et du stock (DHS: Definitive Hardware Store). Se distancier tout de suite du processus de développement, mais bien indiquer les relations très étroites. Ne pas omettre de respecter les obligations légales

93 Gestion des versions Définitions
Objectifs Activités Définitions DSL: Definitive Software Library. Stockage sécurisé des versions logicielles autorisées et installées de tous les SCI. DHS : Definitive Hardware Store. Stockage sécurisé des pièces de rechange. Ces matériels sont maintenus au même niveau que ceux en production. Références à DSL & DHS sont dans la CMDB Version (release) : ensemble des changements autorisés d’un service. 3 types : Full (service), Delta (CI), Package (périodique (4 fois par an)) Plan de retour arrière en cas d’échec de l’implémentation

94 Gestion des versions Activités principales
Définitions Objectifs Activités Activités principales Concevoir, construire et configurer les versions, Valider les nouvelles versions Planifier le déploiement Effectuer des tests Valider les tests et la version à mettre en place Communiquer, préparer et former Analyser les matériels et logiciels Distribuer et installer Produire les rapports et informations de gestion Réaliser des audits de conformité

95 Relations entre la gestion des versions et la gestion des changements
RFC Gestion des versions Mise en oeuvre Environnement de développement Politique de versions & conception Enregistrement & classification Concept., dev, commande & achat Build & configure release Environnement de qualification Accord Release testing & validation gestion des versions = mur entre l’univers du développement et l’univers de la production Autorisation Planification MeP Communication Formation Préparation Environnement de production Évaluation (e.g.PIR) Distribution & installation

96 MODELE DU PROCESS « SERVICE SUPPORT »
Business, clients, utilisateurs Gestion des incidents Gestion des problèmes Gestion des Changements Gestion des versions Rapports d’incidents, Statistiques, Audit… Rapports des problèmes, Statistiques, Tendances… Gestion des configurations Calendrier, Comptes rendus, statistiques… Calendrier, Comptes rendus, statistiques… Rapports, Statistiques, Politiques, normes… Incidents Problèmes Changements Nouvelles CI’s erreurs connues versions relations CMDB

97 Configuration management
Synthèse SUPPORT Client / utilisateur S E R V I C U P O T Network Control Service Desk Computer Operation Incident Problem management Incident management Configuration management CMDB CMDB RFC Change information Release management Change management DSL PRODUCTION

98 Synthèse S E R V I C U P O T Orientation client et business justified
CONCEPTS Orientation client et business justified Cycle de vie Approche par processus Qualité, amélioration continue SERVICE DESK Une fonction et non un processus Point de contact unique Propriété de l’incident et clarté du support Interface avec les autres processus GESTIONS DES INCIDENTS Objectif : Restaurer le niveau de service convenu avec le client-utilisateur L’impact et l’urgence déterminent la priorité. GESTIONS DES PROBLEMES Objectif : Rechercher la cause des incidents significatifs ou récurrents. Problème # erreur connue Peut déboucher sur une demande de changement (RFC) GESTION DES CONFIGURATIONS Objectif : Être la source primaire d’information sur l’infrastructure du SI Concevoir, identifier, contrôler, suivre. GESTION DES CHANGEMENTS Objectif : Minimiser l’impact négatif des changements Entrée dans le processus: la RFC (=demande de changement) Comité consultatif des changements (CAB) GESTION DES VERSIONS Objectif:Constituer une « bibliothèque » des versions utilisées. S E R V I C U P O T

99 Rappels des définitions
INCIDENT Tout événement qui ne fait pas partie des opérations standard pouvant provoquer une interruption de service ou altérer sa qualité. PROBLEME Cause inconnue d’un incident significatif ou de plusieurs incidents présentant les mêmes symptômes. ERREUR CONNUE Le problème devient une erreur connue lorsque la cause du ou des incidents est connue mais la solution n’est pas encore implémentée. CONFIGURATION ITEM Élément de l ’infrastructure du SI CMDB Base de données contenant l’ensemble des informations relatives aux CIs et à leurs relations. CHANGEMENT Tout changement de l ’infrastructure qui a pour conséquence un changement de statut d’un ou plusieurs CIs. RFC (Request For Change): Demande de changement VERSION Ensemble des changements autorisés d’un service. DSL Definitive Software Library. Stockage sécurisé des versions logicielles autorisées et installées. DHS Definitive Hardware Store. Stockage sécurisé des pièces de rechange. Ces matériels sont maintenus au même niveau que ceux en production. S E R V I C U P O T

100 Cas pratique : «Soucis d’un gestionnaire» (1)
Telecom company CMDB doit contenir les données sur : 400 serveurs NT, 5 machines UNIX, 120 types de logiciel système et métiers, 4000 postes NT, 17 SLA, + de 300 documents organisation, etc. Ressources: 1 personne = 1 équivalent Temps Plein Le gestionnaire des configurations est responsable pour: La mise à jour de la CMDB et la définition des niveaux de CI Les indicateurs de performance du processus Cohérence et maintenance de CMDB Monitoring de la capacité des CI’s Reporting Présence au CAB Explicitement hors de ses responsabilités: Réseau Projets Notebooks  Donnez 5 points faibles et 5 recommandations d’amélioration C o n f i g u r a t M e m C h a n g e M m t R e l a s M n g m t Points faibles: Définition des indicateurs par le gestionnaire Pas de planning d’implementation du processus Si le gerant de la configuration doit determiner les niveaux de CI tout seul, il choisira le chemin le plus court sans songer aux services IT en se basant sur le faisibilite technique. Mélange de deux processus: Monitoring capacite est une chose dynamique, qui va peser lourd sur le CMDB statique (photo). Risque d’utiliser une personne sur-qualifiée pour la fonction tres administrative et pas compliquee. CMDB =Photo. On ne peut pas piloter la capacité (données dynamiques). Absence des laptops et notebooks exclue tout le support des utilisateurs “mobiles”, dont la majorite puisse travailler dans les ventes (metier strategique). Présence au CAB: Sans contacts avec des projets une seule personne ne sera pas capable de suivre touts les changements de l’infrastructure pour mettre a jour la CMDB. Delegation des responsabilites n’est pas decrite. Les indicateurs de performance fabriqués par le gestionnaire des configurations tout seul emmeneront a des definitions tres/trop realistes, donc trop facile sans se relater au interets metiers Si le reseau n’est pas inclut dans la CMDB il n’y aura pas question de ce qu’on apelle End-to-end service provision. (De meme sur les laptops).On ne peut pas porter de jugement sur la qualité de service si ce n’est pas mesuré de bout en bout du processus. Recommandations: Trop de choses sont confiées à une seule et même personne.

101 LES PROCESSUS SUPPORT DELIVERY : La fourniture de service met l’accent sur la planification et l’amélioration à long terme des services Questionnaires itSMF, OGC, pink elephant OGC a défini pour certains process (pb management) une évaluation par niveau (1, 1.5, 2, 2.5, 3, 3.5, 4, 4.5 et 5) Gartner a mis en place une échelle des maturités à 4 niveaux ITIL CMM 4 Valeur 5 Optimisation 3 Service 4 Mesure et contrôle 2 Proactive 3 Défini 1 Reactive 2 Reproductif 1 Non défini

102 Sommaire Introduction Service Desk Gestion des incidents
Gestion des problèmes Cas pratique Gestion des configurations Gestion des changements Gestion des versions Gestion des niveaux de service Gestion des finances pour les services IT Cas pratique Gestion de la continuité des services Gestion de la disponibilité Gestion de la capacité

103 Sommaire Gestion des niveaux de services
Gestion des finances pour les services IT Gestion de la continuité des services Gestion de la disponibilité Gestion de la capacité Introduction Service Desk Gestion des incidents Gestion des problèmes Cas pratique Gestion des configurations Gestion des changements Gestion des versions

104 Gestion des niveaux de service
DELIVERY Définitions Objectifs Activités Objectifs Comprendre et définir les besoins de niveaux de service des utilisateurs Assurer une relation client/fournisseur entre le Service Informatique et les utilisateurs/clients Optimiser l’équilibre entre les exigences utilisateurs et les coûts d’exploitation, la disponibilité, la capacité et la continuité de fonctionnement. Contrôler et améliorer le niveau des services IT offerts et la perception de la qualité des services Générer des critères de mesure objectifs Le processus de gestion des niveaux de service définit les SLA. Les SLA constitue la base contractuelle sur laquelle devront se fonder les OLA. Pour que tout fonctionne, ce processus doit s’assurer de la cohérence contractuelle. Le SLA s’exprime en: capacité du SI Disponibilité du SI Coût du SI Continuité du SI Accès à la DSI

105 Gestion des niveaux de service
Définitions Objectifs Activités Définitions Convention de niveau de service (SLA): Accord écrit, entre un fournisseur de services (DSI) et un client, qui documente les niveaux de services (énergie informatique) convenus. Ces niveaux s’expriment en termes de disponibilité, de continuité, de coûts et de capacité. Catalogue de service: Ex: Pour un service de PAIE, la DSI va vendre les services délivrés par le logiciel de PAIE qu’elle a acquis. Underpinning contract - support légal d’une OLA passée avec un sous-traitant.

106 Gestion des niveaux de service

107 Gestion des niveaux de service
Définitions Objectifs Activités Définitions Catalogue de Service (CS) Liste des services disponibles (au sens d’énergie informatique) Service Level Requirement (SLR) Expression des besoins utilisateurs Service Level Agreement (SLA) Convention de niveau de service Operational Level Agreement (OLA) Convention de niveau de service opérationnel  passé en interne Underpinning Contract (UC) Contrat de sous-traitance Service Improvement Program (SIP) Programme d’amélioration de la qualité de service Catalogue de service: Ex: Pour un service de PAIE, la DSI va vendre les services délivrés par le logiciel de PAIE qu’elle a acquis. Underpinning contract - support légal d’une OLA passée avec un sous-traitant.

108 Positionnement des différentes conventions
Gestion des niveaux de service Définitions Objectifs Activités Positionnement des différentes conventions

109 Gestion des niveaux de service
Définitions Objectifs Activités Qualite Plan Act Check Do Satisfaction des clients à des couts acceptables Temps Structure des processus ITIL est un gage de la gestion des services IT Roue de Deming Faire le Catalogue de Service Implémenter Concevoir Brouillon SLA Négocier Revoir OLA & UC Signer les SLA Suivre Reporting Revoir SLA Revoir le processus Piloter plan do check act Coûts de départ, qualité, niveau de satisfaction 1ère chose à faire: Faire le catalogue de service, car il y a un existant. Dans une organisation où il n’y a rien, il faudrait commencer par faire le brouillon du SLA.

110 Gestion des niveaux de service
Définitions Objectifs Activités Activités principales Recueillir les besoins (SLR) des utilisateurs-clients Définir les services et le catalogue des services Négocier et formaliser les SLA, OLA et UC Créer et maintenir le SIP (Service Improvment Program) Piloter et suivre les niveaux de service Contribuer à la définition des Indicateurs de QoS Réaliser le reporting sur les niveaux des service Évaluer la fourniture des services (audits, enquêtes) Gérer la relation client

111 Gestion des niveaux de service
Définitions Objectifs Activités Remarques Votre exigence doit être à la hauteur de votre maturité et de vos moyens Mettez vos collaborateurs et partenaires dans une démarche de succès Ne changer pas ce qui fonctionne bien Un niveau d ’engagement c’est bien, le faire appliquer c’est rassurant, mais attention à ce qu ’il n ’y ait pas 2 perdants Un des plus grand échec d’engagement de service est la non définition du contexte d’exécution Minimiser le nombre d’indicateurs, vous faciliterez la décision ! Attention à vos coûts de gestion, le SLA doit être avant tout un outil opérationnel Privilégier la stabilité d ’un service plutôt que l ’obtention d ’un niveau

112 Gestion des niveaux de service
Rôles et responsabilités Le Gestionnaire des Niveaux de Service doit : Etablir et mettre à jour le catalogue des services Négocier, signer et suivre les Accords des Niveaux de Service (SLA – Service Level Agreement), les Accords des Niveaux Opérationnels (OLA – Operational Level Agreements) et les Contrats de sous-traitance (UC – Underpinning Contract) Présenter de nouveaux services et améliorer ceux existants.

113 Gestion des niveaux de service
Niveaux de signature Niveau « Entreprise » – convention générique décrivant les intentions en termes globaux, valable pour tous les clients de l’entreprise. Document pérenne. Niveau « Client » - couvre les aspects de SLM qui sont uniques ou pertinents pour certains groupes de clients (business unit), avec leurs particularités métiers. Les services (systèmes d’information) peuvent toujours être différents. Document fonction de l’évolution des métiers. Niveau « Service (organisation)» - les aspects spécifiques des services particuliers (systèmes d’information) dans le cadre d’un groupe de clients. Types de SLA Un service consommé par plusieurs clients Un client consomme plusieurs services

114 Gestion des niveaux de service
Convention de niveau de Service (SLA) Description des services couverts Horaires des services Disponibilité des systèmes d’information Performances des services Fonctionnalité des services Assistance sur ces services Description des procédures d’évaluation des services Contraintes de Sécurité Mesures de Continuité Restrictions Prix et Facturation Définition des indicateurs (tableaux de bord) Gestion des modifications du document

115 Gestion des niveaux de service
Exemple de SLA pour un service de paie  1-    Description du service délivré Impression des feuilles de paie Archivage pendant 5 ans de chaque feuille de paie Établissement du bilan social (Sécurité sociale) Établissement des disquettes pour les banques  2-    Disponibilité Du 01 au 20 de chaque mois : 80% des heures ouvrables Du 21 au 25 de chaque mois : 100% des heures ouvrables Du 26 à la fin de chaque mois : 50% des heures ouvrables  3-    Capacité Impression de 1000 feuilles par heure Établissement des disquettes en une heure Établissement du bilan social trimestriel en ½ journée (entre le 26 et la fin du mois)  4-    Continuité Reprise sous 5 jours à 100% des fonctionnalités quel que soit l’événement Reprise sous 2 jours à 70% des fonctionnalités quel que soit l’événement 5-    Coût 0,05 € par feuille de paye produite 1 € par disquette 15 € par bilan social 6-    Interface Le service desk au 7777 De 8h à 12h entre le 1er et le 20 de chaque mois De 7h à 19h entre le 21 et le 25 de chaque mois De 10h à 12h entre le 26 et la fin du mois Déclaration d’incidents, demandes de changements et demandes d’assistance

116 Exercice: Gestion des niveaux de service
Groupe 1: “Comment le processus de gestion des niveaux de service utilise-t-il les données produites par le processus de gestion des incidents?” Groupe 2: “Citez 5 différences entre UC, OLA et SLA“ Préparation : 10 min. Groupe 1 : Présentation et discussion (10 min). Groupe 2 : Présentations et discussion (10 min). Groupe 1 Analyser les données sur les incidents afin de déterminer si le niveau de service convenu est fourni ou atteint. Les attentes et les besoins du client à l'égard du service. On peut determiner quel service est le plus touché par les chutes et l’indisponibité Analyse des plaintes et des propositions d’amélioration fomuleés par les clients\utilisateurs Analyse des incidents contribue à identifier les goulot d’etranglement liés aux fournisseurs internes et externes qui peuvent etre mieux controlés en cas de problèmes avec les UC et OLA Groupe 2 Internes \ externes Aspects legaux Position de notre organisation IT OLA et UC sont formulés dans des termes beaucoup plus techniques que SLA Sélection des fournisseurs (UC) est possible. Cela permet de créer un cadre \ structure de sélection plus standard et coherente.

117 Sommaire Gestion des finances pour les services IT
Gestion des niveaux de services Gestion des finances pour les services IT Gestion de la continuité des services Gestion de la disponibilité Gestion de la capacité Introduction Service Desk Gestion des incidents Gestion des problèmes Cas pratique Gestion des configurations Gestion des changements Gestion des versions

118 Gestion des finances pour les services IT
DELIVERY Définitions Objectifs Activités Objectifs Contribuer à rendre les coûts informatiques visibles et contrôlables et pouvoir les réaffecter Faciliter la détermination des coûts informatiques Établissement des budgets Méthode de comptabilité Suivi des dépenses Communiquer sur la structure des coûts et des investissements

119 Gestion des finances pour les services IT
Définitions Objectifs Activités Définitions Budgétisation : Activités de prévision et de contrôle des dépenses au sein de l’entreprise (annuel) Comptabilité Informatique (costing) : Activité qui permet à l’organisation informatique de justifier la manière dont l’argent est utilisé. Elle mesure la rentabilité d’un service (mensuel ou trimestriel) Tarification (charging) : Activité nécessaire pour facturer un client au regard des services qui lui ont été rendus Cost center (on parle de coût) / profit center (on ne parle plus de coût mais d’investissement)/ service center (budget flexible alloué pour les services. Mais les services peuvent coûter plus ou moins. TCO est un des méthodes pour calculer les couts mais ce n’est pas une définition ITIL. Autres méthodes: ABC, itIM. TCO ne se réduit pas aux postes de travail. Et Ce processus ne se réduit pas à TCO. QUALITE, COUTS et BESOINS DES UTILISATEURS -- recherche de l’équilibre par le SLM.

120 Gestion des finances pour les services IT
Définitions Objectifs Activités Définitions Catégories des coûts directs/indirects (répartis par nb clients ou organisation) Fixes/ variables (pour une période/ à l’utilisation, au temps) Amortis/ non amortis (capital/operationnal cost) Types (éléments) des coûts Equipment Cost Units (ECU)  Coûts matériels Software Cost Units (SCU)  Coûts logiciels Organisation Cost Units (OCU)  Coûts de personnels Transfer Cost Units (TCU)  Coûts des prestations Accomodation Cost Units (ACU)  Coûts des locaux info Total Cost of Ownership (TCO) Coût total de possession Cost center (on parle de coût) / profit center (on ne parle plus de coût mais d’investissement)/ service center (budget flexible alloué pour les services. Mais les services peuvent coûter plus ou moins. TCO est un des méthodes pour calculer les couts mais ce n’est pas une définition ITIL. Autres méthodes: ABC, itIM. TCO ne se réduit pas aux postes de travail. Et Ce processus ne se réduit pas à TCO. QUALITE, COUTS et BESOINS DES UTILISATEURS -- recherche de l’équilibre par le SLM.

121 Gestion des finances pour les services IT
Activités Élaboration des budgets: Estimation des coûts des services informatiques. Prévoir le budget sur une période pour fournir les services. Comparer les dépenses réelles et prévisionnelles. Réduire le risque de dépassement du budget. S’assurer des moyens pour couvrir les prévisions de dépenses. Identification des coûts de services: suivi des dépenses des services fournis. Expliquer les dépenses. Calculer le coût par service. Calculer le retour sur investissement. Identifier les coûts des changements. Refacturation auprès des clients facturer les coûts des services auprès des clients du service. Considérer l’organisation comme un client. Influencer le comportement des utilisateurs et des clients en facturant les services demandés et utilisés.

122 Gestion des finances pour les services IT
Définitions Objectifs Activités Sous - processus Budgétisation = estimer, contrôler, négocier Concevoir Plusieurs formes (estimer, pronostiquer, calculer) Focus (€, actifs, processus, services, business) Comptabilité = justifier, consolider, analyser Enregistrement selon le plan comptable Reporting Analyse Benchmarking « Facturation et contrôle de gestion » = évaluer (combien?), allouer (qui?), facturer Scope & Focus Politique des prix Coûts Ajout de coûts Taux usuels internes Taux du marché Prix fixes (forfaits) Facturation Budgétisation Comptabilité Facturation

123 Gestion des finances pour les services IT
Budgétisation Comptabilité Facturation Définitions Objectifs Activités plan do check act Coûts de départ, qualité, niveau de satisfaction Plan Act Check Do Satisfaction des clients à des couts acceptables Qualite Temps Structure des processus ITIL est un gage de la gestion des service IT Roue de Deming Plus le processus fonctionne, plus il faut augmenter la qualité, plus il faut gérer les coûts, plus il faut gérer la satisfaction client.

124 Gestion des finances pour les services IT
Exemple de coûts de service (coûts par mois) Matériels 20 PCs 30 € Techniciens 30 pers. 2.000 € Logistique Bâtiment+ restauration Eléments de coûts INCIDENTS 20 pers.+12 PCs PROBLEMES 10 pers.+8 PCs Coûts amortis Bâtiment chacun € Centre de Internet I NC 75% PRB 25% INC 25% PRB 75% Coûts par domaine 27.797€ Coûts non amortis Restauration Augmentation: 10% + A mettre en français +

125 Exercice: Gestion des finances pour les services IT
« Un bon système de la gestion de finances vise à réduire les coûts de l’infrastructure » Groupe 1: Donnez 5 arguments justifiant cette affirmation. Groupe 2: Donnez 5 contre-arguments. Préparation : 10 min. Présentations : 5 min. Discussion : 10 min Pour S’il s’agit de contribution à la réduction des coûts Processus bien organisé et implémenté permet de réduire des coûts de processus lui même L’analyse des statistiques sur l’histoire de développement des prix d’achat du matériel et du logiciel permet de mieux coordonner les achats avec les autres processus ITIL (CAP, PRB) FIN conseille DSI sur les éléments ou sur la direction de réduction des coûts. L’analyse de l’aspect financier des actifs permet de définir la politique d’achat “en gros”. Contre L’objectif du processus n’est pas de “viser” mais de “contribuer”. Il ne faut pas confondre ce deux là. Ce sont des méthodes de comptabilité (TCO, ABC etc.) et non pas des procédures du processus qui contribuent à déterminer la politique de réduction des couts. Processus de gestion des finances n’influence pas le recrutement, les achats du logiciel ou d’équippement, sous-traitance etc. L’objectif des achat est de ne pas achetere le meilleur marché, mais de créer une valeur additionelle pour les affaires. Les conseilles des autres processus jouent le role plus important ici que le processus FIN. On ne fait que clculer ou budgetiser les couts des services. Mais on nèest pas obligé a defendre ni la composition ni la valeur ajoutée pour les métier\affaires des services. Pours S’il s’agit de contribution à la reduction des couts - d’accord Processus bien organisé et implémenté permet de reduird des couts de processus lui meme L’analyse des statistiques sur l’histoire de developpement des prix d’achat du matériel et du logiciel permet de mieux coordiner les achats avec dèautres processus ITIL (CAP, PRB) FINconseille DSI sur les éléments \ direction de réduction des couts. L’analyse de l’aspect financier des actifs permet de definir la politique d’achat “en gros”. Contres Ceci n’est pas l’objectif du procesus. Ne pas “viser” mais “contribuer”. Il ne faut pas confondre ce deux là. Ce sont des méthodes de comptabilité (TCO, ABC etc.) et non pas des procedures du processus qui contribuent à déterminer la politique de réduction des couts. Processus de gestion des finances n’influence pas le recrutement, les achats du logiciel ou d’équippement, sous-traitance etc. L’objectif des achat est de ne pas achetere le meilleur marché, mais de créer une valeur additionelle pour les affaires. Les conseilles des autres processus jouent le role plus important ici que le processus FIN. On ne fait que clculer ou budgetiser les couts des services. Mais on nèest pas obligé a defendre ni la composition ni la valeur ajoutée pour les métier\affaires des services.

126 Sommaire Gestion de la continuité des services
Gestion des niveaux de service Gestion des finances pour les services IT Gestion de la continuité des services Gestion de la disponibilité Gestion de la capacité Introduction Service Desk Gestion des incidents Gestion des problèmes Cas pratique Gestion des configurations Gestion des changements Gestion des versions

127 Gestion de la Continuité des Services
DELIVERY Définitions Objectifs Activités Objectifs Estimer les conséquences possibles de détérioration des systèmes informatiques Identifier les systèmes critiques et les priorités de leurs restauration en cas de désastre Déterminer des mesures préventives, identificatrices et correctives des désastres pouvant affecter les systèmes Créer, tester et maintenir le plan de reprise d’activités (plan de continuité de service ou secours) Après le 11.09, la problématique de la continuité de service se pose plus fréquemment. Ce processus diffère de la gestion de la sécurité qui est profondément orienté vers la protection des données et de l’information. Le processus de gestion de la sécurité est extrait du domaine delivery. Il touche tous les processus ITIL.

128 Gestion de la Continuité des Services
Définitions Objectifs Activités Définitions La continuité de service est l’aptitude d’une organisation à continuer à fournir un niveau convenu de services IT (systèmes d’information). Gestion de la continuité Affaires : Responsabilité PDG Son rôle est de déterminer la politique générale en matière de continuité métiers (incluant la priorité de restauration). Analyse des impacts Affaires BCM est la base de ITSCM Recovery: Options standby Cold – recoverabilité graduelle applicable dans les organisations qui sont capable de fonctionner sans restaration de complete capabilité IT pendant plus de 3 jours. Souvent c’est une batiment avec l’ électricité et les facilités habituelles. Souvent livré par des fournisseurs spécialisés. Warm – recoverabilité partielle applicable dans les organisations capable de fonctionner sans restauration complete entre un et trois jours. Des batiments mobile/portable en camions. Cette option parfois fait parti d’une description des solutions de contournement sérieux. Hot - recoverabilité immédiate applicable dans les organisations incapable de fonctionner sans restauration complete plus qu’un jour. Un variant a cela est un “mirrored service”, quand le service est effectuué en double redundance par des systemes completement egaux. On ne peut pas implémenter la continuité de service s’il n’y a pas de politique générale de continuité affaires. Cela est prévu pour les cas de force majeure. Autre méthode d’analyse des risques: AMDEC (analyse des modes de défaillance et d’évaluation de la criticité). Plus adaptée pour les systèmes techniques.

129 Gestion de la Continuité des Services
Définitions Objectifs Activités Définitions Risques et Vulnérabilités CCTA Risk Analysis and Management Method Analyse des risques CRAMM Vulnérabilités Activités Menaces Risques Gestion des risques Contre-mesures BCM est la base de ITSCM Recovery: Options standby Cold – recoverabilité graduelle applicable dans les organisations qui sont capable de fonctionner sans restaration de complete capabilité IT pendant plus de 3 jours. Souvent c’est une batiment avec l’ électricité et les facilités habituelles. Souvent livré par des fournisseurs spécialisés. Warm – recoverabilité partielle applicable dans les organisations capable de fonctionner sans restauration complete entre un et trois jours. Des batiments mobile/portable en camions. Cette option parfois fait parti d’une description des solutions de contournement sérieux. Hot - recoverabilité immédiate applicable dans les organisations incapable de fonctionner sans restauration complete plus qu’un jour. Un variant a cela est un “mirrored service”, quand le service est effectuué en double redundance par des systemes completement egaux. On ne peut pas implémenter la continuité de service s’il n’y a pas de politique générale de continuité affaires. Cela est prévu pour les cas de force majeure. Autre méthode d’analyse des risques: AMDEC (analyse des modes de défaillance et d’évaluation de la criticité). Plus adaptée pour les systèmes techniques.

130 Gestion de la Continuité des Services
Définitions Objectifs Activités Définitions Remise en place Plan de continuité de service ( 7 Paragraphes) - Administration (déclencheur, actions, organisation) - Infrastructure informatique - Procédure de gestion de l’IT - Personnel : rôles et responsabilités - Sécurité : détail des sites - Site de secours - Retour à l’état normal Vérification du Plan Restauration Cold (salle informatique + machine vierge)  72h Warm (espace configuré)  24h Hot (miroir de l’opérationnel)  10 mn BCM est la base de ITSCM Recovery: Options standby Cold – recoverabilité graduelle applicable dans les organisations qui sont capable de fonctionner sans restaration de complete capabilité IT pendant plus de 3 jours. Souvent c’est une batiment avec l’ électricité et les facilités habituelles. Souvent livré par des fournisseurs spécialisés. Warm – recoverabilité partielle applicable dans les organisations capable de fonctionner sans restauration complete entre un et trois jours. Des batiments mobile/portable en camions. Cette option parfois fait parti d’une description des solutions de contournement sérieux. Hot - recoverabilité immédiate applicable dans les organisations incapable de fonctionner sans restauration complete plus qu’un jour. Un variant a cela est un “mirrored service”, quand le service est effectuué en double redundance par des systemes completement egaux. On ne peut pas implémenter la continuité de service s’il n’y a pas de politique générale de continuité affaires. Cela est prévu pour les cas de force majeure. Autre méthode d’analyse des risques: AMDEC (analyse des modes de défaillance et d’évaluation de la criticité). Plus adaptée pour les systèmes techniques.

131 Gestion de la Continuité des Services
Activités principales Initialiser le processus de continuité business Analyser les besoins réels et la stratégie métier Analyser les impacts business Identifier les risques Déterminer la stratégie de Continuité Affaires Mettre en œuvre  Plan de continuité de service (secours) Concevoir Se mettre d’accord sur les astreintes, Déterminer les plans de restauration, Élaborer les mesures de réduction des risques, Rédiger les procédures et tester. Gestion opérationnelle Former, prendre conscience Réviser, auditer Tester et mettre à jour Gestion des changements Garantir (assurance) Définitions Objectifs Activités

132 Gestion de la Continuité des Services
Rôles pendant la crise Board (niveau de management le plus élevé) – Gestion de crises, Décisions normalement prises au niveau entreprise, Communication externe Senior Management (directeurs, responsables de départements, DSI, etc) - Coordination des plans, direction, autorisation ressources, communication interne Middle management – coordination de la restauration, gestion des opérations, reporting Personnel - exécution des procédures Au cours de distribution des roles il faut comprendre la source de “malheurs”. Une classification pareil peutaider a organiser la gestion du crise lpus efficacement. Rechercher la source du schéma!!!!!!!

133 Gestion de la Continuité des Services
Bénéfices Réduire la perte de temps lorsqu’il y a un désastre Bien piloter la restauration Faire baisser les coûts relatifs aux polices d’assurance Assurer la continuité des services touchés Avoir des avantages compétitifs Meilleure image Marketing positif Fidélité client Crédit et réputation Amélioration des relations affaires.

134 Sommaire Gestion de la disponibilité Gestion des niveaux de service
Gestion des finances pour les services IT Gestion de la continuité des services Gestion de la disponibilité Gestion de la capacité Introduction Service Desk Gestion des incidents Gestion des problèmes Cas pratique Gestion des configurations Gestion des changements Gestion des versions

135 Gestion de la Disponibilité
DELIVERY Définitions Objectifs Activités Objectifs Le processus de la gestion de la disponibilité a pour but d’optimiser la capacité de l’infrastructure et de la chaîne de support à fournir le niveau de service requis aux entités métier, en s’assurant que tous les services reposent sur des Cis suffisants, fiables et maintenus correctement Garantir les objectifs du SLA, OLA en terme de disponibilité, c’est Mesurer, Analyser, Concevoir, Optimiser, Améliorer Assurer la disponibilité n ’est pas l ’objectif de ce processus. Ce processus ne maintient pas la disponibilité. C’est la gestion des incidents et des problèmes qui le fait. CF source du schéma

136 Gestion de la Disponibilité
Définitions Objectifs Activités Définition La disponibilité est la capacité d’un composant ou d’un service à exécuter la fonction demandée à un moment donné et sur une période de temps définie. E800 : La disponibilité c’est le pourcentage de temps pendant lequel le système fonctionne sans erreur Quelque chose qui n’est plus serviciable est quelque chose d’obsolète, irréparable.

137 Gestion de la Disponibilité
Définitions Objectifs Activités Définitions Fiabilité: Aptitude d’un équipement, logiciel, service à fonctionner durablement avec un nombre minimum d’interruptions ou d’incidents. Maintenabilité: Aptitude d’un service ou d’un équipement à être remis en ordre de marche rapidement. Serviceabilité: Aptitude que l’on a à trouver des fournisseurs ou sous-traitants externes pour assurer la disponibilité, fiabilité et maintenabilité. Recoverabilité: Aptitude à s’auto-reconfigurer jusqu’au niveau d’avant la chute du système d’information. Résilience: Aptitude à continuer à fonctionner même si un ou plusieurs composants sont hors de fonctionnement. VBF Vital Business Functions: les fonctions vitales des métiers Security CIA: Confidentialité, intégrité et disponibilité des données. Quelque chose qui n’est plus serviciable est quelque chose d’obsolète, irréparable.

138 Gestion de la Disponibilité
Calcul Disponibilité: Pourcentage de temps pendant lequel le système fonctionne sans erreur % disponibilité = (AST-DT)/AST*100% AST (Agreed Service Time) = Temps de service convenu DT = Down time Exemple calculs de disponibilité E2E (end-to-end): unité centrale - 99,9998% réseau - 97,5555% serveur - 98,6666% PC - 95,2223% E2E disponibilité = 91,6557% Définitions Objectifs Activités Ce n’est qu’un exemple de calcul possible pour la presentation serielle. Puisque paralèlle sera calcule d’une autre maniere. Nota : ce calcul ne s’applique que dans le cas où le service sollicite chaque CI d’une manière synchrone

139 Gestion de la Disponibilité
Définitions Objectifs Activités Cycle de vie d’un incident MTTR (Mean Time To Repair) Temps moyen de réparation " Down-time"        Up-time Restauration Incident no.1 Temps de Temps de Incident no.1 est resolu Incident no.2 Réponse Restauration MTBF (Mean Time Between Failures) Temps moyen entre 2 pannes Mean - Moyenne est une unité de calcul de le gestion de disponibilité, puisqu ’elle donne de la statistique pour tous les services et CI. Détection Diagnostic Solution Correction Temps de Détection Temps de Réparation Vision technique de l’incident MTBSI (Mean Time Between System Incidents) Temps moyen entre 2 incidents système

140 Gestion de la Disponibilité
Définitions Objectifs Activités Activités principales Étudier et concevoir Définir les besoins en termes de disponibilité Définir les conditions optimales de disponibilité Gérer la recoverabilité (évaluer les options) Gérer la maintenabilité (période et contrôle) Mesurer et reporter Collecter les données permettant de mesurer la disponibilité Comparer ces résultats aux objectifs (SLA, OLA) Produire les indicateurs et tableaux de bord Créer et mettre à jour le Plan de Disponibilité Objectifs, niveaux de disponibilité convenus Analyse des indisponibilités Arrêts planifiés Définir la disponibilité des Services en construction Analyse des tendances et solutions Rechercher et éliminer les points uniques de rupture (SPOF – Single point of failure)

141 Gestion de la Disponibilité
Comment améliorer la disponibilité (Plan de disponibilité)? Réduire le « Downtime » Réduire le temps de détection (supervision, alarmes) Réduire le temps de diagnostic (gestion des incidents) Réduire le temps de réparation (conf. standards, dossiers systèmes, matériels disponibles) Réduire le temps de restauration (sauvegardes, master) Réduire la fréquence des incidents Systèmes à tolérance de panne (résilience) Redondance des services Réduire les arrêts de services Interventions préventives hors horaires de service Synchronisation des environnements Optionnel. S’il y a des questions. Ne pas confondre réduction de la fréquence des incidents et réduction du nombre d’incidents.

142 Gestion de la Disponibilité Architectures/Processus
Architectures à Redondance Totale Architectures de Haute Disponibilité Service Level Capacity Management Coût Availability Change Problem Incident Management Composants et Produits de base Disponibilité 100%

143 Gestion de la Disponibilité : Réactif/Proactif
Bureautique Applications Métiers Aviation Commandes Numériques Maintenance Préventive Coût Optimisation Coût/Disponibilité Maintenance Corrective Disponibilité 100%

144 Exercice: Gestion de la Disponibilité
“Citez 5 moyens permettant la réduction de l’indisponibilité” Préparation : 15 min. Présentation et discussion: 10 min. Moyens: Changer de fournisseur (cycle de vie) Changer un élément de l’infrastructure (SPOF) Optimiser, améliorer la procedure d’escalade hiérarchique\fonctionelle (Life cycle) Avec le client\utilisateur: Préciser et analyser la notion de disponibilité. Négocier la définition de disponibilité Planifier et inclure dans les SLA les temps d’indisponibilité (maintenance, tests, exercices au seins du processus de la gestion de la continuité des services, etc.)

145 Sommaire Gestion de la capacité Gestion des niveaux de services
Gestion des finances pour les services IT Gestion de la continuité des services Gestion de la disponibilité Gestion de la capacité Introduction Service Desk Gestion des incidents Gestion des problèmes Cas pratique Gestion des configurations Gestion des changements Gestion des versions

146 Gestion des Capacités Objectif
DELIVERY Définitions Objectifs Activités Objectif S’assurer que les ressources, matérielles, logicielles et humaines, sont en phase avec les besoins présents et futurs pour un niveau de coûts justifiables.

147 Gestion des Capacités Définition
Définitions Objectifs Activités Définition La capacité renvoie à la capacité (performance) de traitement et à la capacité de stockage des systèmes d’information. Repository  notion logique. Plus large qu’une base de données. Beaucoup plus chère et beaucoup plus complexe. Cycle de vie: il faut implémenter ce processus en fonction de cycle de vie des changements, de SLA etc.

148 Gestion des Capacités Définitions Plan de capacité
Objectifs Activités Définitions Plan de capacité CDB - Base de données de capacité (repository) Trois sous-processus Capacité business Anticipation et proactivité, équilibre entre offre (mise en place au bon moment) et demande de capacité pour le futur. Capacité service (SLA) Performance des services (énergie), équilibre entre ce que le service (énergie) exige actuellement et ce que IT peut proposer. Capacité ressource Composants, réseaux, tendances technologiques, charge de travail, débit... Repository  notion logique. Plus large qu’une base de données. Beaucoup plus chère et beaucoup plus complexe. Cycle de vie: il faut implémenter ce processus en fonction de cycle de vie des changements, de SLA etc.

149 Gestion des Capacités Plan de capacité
Définitions Objectifs Activités Plan de capacité Objectifs stratégiques de l’entreprise et par métier Scénarios affaires et hypothèses par métier Conséquences de ces scénarios pour les services Options pour l’amélioration de la qualité des services Revue des ressources Modèle des coûts Recommandations Capacité Affaire Capacité Service Option pour l’amélioration de la qualité: si le service est plus performant, coûte moins cher, on améliore la qualité Capacité Ressource

150 Gestion des Capacités Activités principales
Définitions Objectifs Activités Activités principales Surveiller la performance globale du système Surveiller et régler les performances Diagnostiquer et résoudre en cas de déviation Analyser la charge Modéliser l’utilisation des ressources par rapport à l’évolution de la charge Analyser les tendances Prévoir les ressources cohérentes avec la charge pour les nouvelles applications. Paramétrer les ressources Optimiser l’utilisation des ressources Réaliser la veille technologique Assurer le support au cycle de vie de la gestion des changements, maîtrise d ’ouvrage, développement Maintenir à jour le contenu de la CDB

151 MODELE DU PROCESS « SERVICE DELIVERY »
Business, clients, utilisateurs Questions, rapports, communications,… Gestion des Niveaux de service Gestion de la disponibilité Besoins Objectifs Réalisations Gestion des capacités Gestion Financière Pour les services IT Gestion de la continuité des services IT Alertes et exceptions, Changements Outils de gestion et infrastructure IT

152 Proposition d’évolution
Synthèse DELIVERY S E R V I C U P O T Financial management Changements annuels Autorisations CDB Taux d’utilisation Proposition d’évolution Problem management Capacity management Change management CMDB Services Adaptation Plan de secours Niveaux possibles service Continuity management Service level management Availability management Criticité applications DSL

153 Synthèse GESTION DES NIVEAUX DE SERVICE (SLA) Objectif: Définir avec les clients-utilisateurs des niveaux de services en terme de disponibilité, capacité, continuité et coût et des critères de mesures objectifs. SLA, SLR, OLA, UC, catalogue de service GESTION DES FINANCES Objectif: Avoir une visibilité sur les coûts. Budgétisation, comptabilité, facturation et contrôle de gestion. GESTION DE LA CONTINUITE Objectif: Identifier les risques de défaillances des systèmes d’information et prévoir un plan de reprise activité. Avantage: bien piloter la restauration, réduire la perte de temps et être plus compétitif. GESTION DE LA DISPONIBILITE Objectif: Améliorer la disponibilité des services. Fiabilité, maintenabilité, serviceabilité, recoverabilité, résilience. Plan de disponibilité. Single point of failure GESTION DE LA CAPACITE Objectif: S’assurer que les ressources sont en phase avec les besoins présents et futurs. Sous-processus: capacité affaire, capacité service, capacité ressource. Plan de capacité. S E R V I C D L Y

154 Rappels des définitions
CONVENTION DE NIVEAU DE SERVICE Accord écrit entre un fournisseur de services (DSI) et un client, qui documente des niveaux de services (énergie informatique) convenus. Ces niveaux s’expriment en termes de disponibilité, de continuité, de coûts et de capacité. OLA Convention de niveau de service opérationnelle. CONTINUITE Aptitude d’une organisation à continuer à fournir un niveau convenu de services IT (systèmes d’information). DISPONIBILITE Taux d’heures convenues pendant lesquelles l’élément ou le système d’information est disponible. CAPACITE La capacité renvoie à la capacité (performance) de traitement et à la capacité de stockage des systèmes d’information. S E R V I C D L Y

155 Sommaire Compléments Préparation a la certification
Passage de la certification

156 Objectifs des processus ITIL. Mots-clés.
GESTION DES INCIDENTS Restaurer le service le plus vite possible GESTION DES PROBLEMES Trouver la cause sous-jacente des incidents GESTION DES CHANGEMENTS Éliminer les incidents suite à un changement GESTION DES CONFIGURATIONS Avoir une image la plus complète de la configuration actuelle GESTION DES VERSIONS Avoir uniquement des versions autorisées GESTION DES FINANCES Assurer la transparence des coûts GESTION DES NIVEAUX DE SERVICE Trouver un équilibre qualité-prix des services GESTION DE LA CAPACITE Éviter les surprises d’achat GESTION DE LA DISPONIBILITE Améliorer la disponibilité des services GESTION DE LA CONTINUITE plan d’action exact pour les cas de force majeure. En bref.

157 Glossaire

158 Liens utiles The ITIL Alumni Group, http://www.itilalumni.com
The ITIL Tooling Site, IT Management, ITIL on line (OGC), EXIN, ISEB, The Stationery Office, ITSMF FRANCE, ITSMF UK, ITSMF USA, The Help Desk Institute, To order books,

159 Indicateurs de performance
Définition des Indicateurs Champs de mesure Sur quoi faire le point? Objectif(s) Que cherche-t-on à faire? Variables Que peut-on suivre par rapport à l’objectif? Paramètres Que peut on mesurer sur la variable? Indicateurs Comment combiner les paramètres mesurables? Tableau de Bord Comment visualiser les indicateurs? Ce sont des éléments dont on doit tenir compte en définissant les indicateurs de performance. Cette définition doit être faite avec des représantant des métiers ( utilisateurs), des clients, SLM et les propriétaires des processus concernés. Il faut commencer par définir les indicateurs (3 temps) 1 Facteurs clés de succès, 2 indicateurs de performance. 3 implémenter les processus permettant d’atteindre ces indicateurs

160 Les processus dans l ’organisation
IT Business Business/IT alignment Stratégique DSI PDG FIN SCM Clients Tactique AVA Contrats SLM CAP Relations et communication entre les niveaux différents sont essentielles. Souvent on ne voit pas l’état de choses chez des cients. Cela forme un probleme don’t la résolution pourrait etre trouvé an sein des processus decrti dans la Business perspective, mais c’est déja un autre histoire... CHG Opérationnel REL PRB INC Contacts Utilisateurs SD CFG

161 Sommaire Préparation a la certification
Implémentation IT Service Management Préparation a la certification Passage de la certification

162 L ’examen EXIN (Utrecht, Pays-Bas) 40 questions 1 heure
seule une réponse est bonne examinateur = PC (automatique) 26 bonnes réponse - OK!

163 Les « Meilleures Pratiques » d’ITIL
itSMF France Les « Meilleures Pratiques » d’ITIL Présentation du forum itSMF Et pour L’ITSMF responsable de la commission patrimoine, éducation et normalisation Thierry CHAMFRAULT Bouygues Telecom Responsable QoS et sécurité Direction du développement Marketing

164 itSMF France Objet L’itSMF France a pour objet la promotion en France des Meilleures Pratiques de la Gestion de Services Informatiques, notamment grâce à ITIL. Activités Organiser en réseau des experts et des acteurs de la Gestion de Services Informatiques, Traduire en français le capital documentaire existant, Capitaliser et mettre à disposition les expériences Animer des séminaires et conférences, Travailler à la normalisation de la fourniture des Services Informatiques, Rechercher des partenariats efficaces, … et conduire d’autres actions susceptible de contribuer à faire progresser la qualité des Services Informatiques.

165 itSMF dans le monde Plus de 1000 entreprises
Des dizaines de manifestations par an, Des commissions de travail, Des Groupes régionaux, Une publication mensuelle spécifique : Service Talk Publication et Mise à Jour des référentiels ITIL Site web Afrique du Sud, Allemagne, Australie, Autriche, Belgique, Canada, Danemark Hollande, Japon, Norvège Suède, Suisse, USA

166 itSMF France : Organisation
Commission Patrimoine, Normalisation, Education Faire le lien avec les autres pratiques du métier, avec les organismes de normalisation, être présent en amont dans le système éducatif Commission Traduction et publications Compléter et adapter les publications itSMF réalisées au niveau international Développer une base des bonnes pratiques « ITIL à la française » pouvant faire l’objet de publications Commission Marketing Faire connaître l’association auprès des professionnels et susciter leur adhésion Commission Communication et relations externes Faire reconnaître itSMF France comme un acteur incontournable de la gestion de services Groupes Régionaux Faire bénéficier le forum de la capitalisation et du dynamisme des acteurs « régionaux » !

167 Un retour d’expérience
ITIL Un retour d’expérience Et pour L’ITSMF responsable de la commission patrimoine, éducation et normalisation Thierry CHAMFRAULT Bouygues Telecom Responsable QoS et sécurité Direction du développement Marketing

168 ITIL chez Bouygues Telecom
Début des travaux 1998 Entreprise « jeune » avec une DSI en 1998 de 1200 personnes Existence à cette époque d’un référentiel de développement mais peu de choses sur la production Le concept de processus émergeant la notion de « Service management » inexistante Nous sommes dans une culture où l’infrastructure est propriété du développement En 1998, chaque trimestre, une relivraison totale de son SI

169 ITIL chez Bouygues Telecom
Le premier objectif : « Comment faire pour que la production existe au sens de son métier  » Le deuxième objectif : « Comment anticiper la création de nouvelles applications » Le troisième objectif : « Comment faire partager un langage commun et une expérience de métier»  Contexte de gestion dans l’urgence

170 ITIL chez Bouygues Telecom
ITIL n’a jamais été une finalité, mais un moyen Le Terme « ITIL » n’a pas vraiment besoin d’être mis en avant, mais quelque part c’est rassurant Une expérience personnelle sur ITIL commencée en 1992 Une volonté de faire que le développement et la production soient intégrés tout en conservant leurs propres identités - Continuité de service plutôt que rupture Enrichir « ITIL » des acquis « CMM » ( niveaux de maturité) ITIL une extraordinaire boite à outils

171 ITIL chez Bouygues Telecom
L’approche TOP – DOWN : Donner un cadre et une visibilité de l’outil de production - PARTAGER Un processus, c’est quoi? Référentiel Qualité (POQ) – formation, plaquette, BD Cartographie des processus - livret DOWN – UP : Concentrer son action opérationnelle sur les outils communs aux deux métiers (livraison, configuration, incidents, développement) et introduire le client dans ses préoccupations métiers (gestion des services – SLA, Gestion des capacités)

172 ITIL chez Bouygues Telecom
Quelques concrétisations

173 PROCESSUS D’INGENIERIE SYSTEME
Les métiers de la DSI Développement G OPERATIONNELS PROCESSUS Gestion des délégations juridiques Reporting Contrôle de gestion Audit Maîtrise des relations clients Gestion de la documentation des relations fournisseurs Maîtrise Contractualiser Livrer Commander Enregistrer Qualifier Acheter Réceptionner Payer Qualité Gestion des coûts Exécuter le contrôle budgétaire Gestion des règles budgétaires et de gestion Suivi PROCESSUS DE PILOTAGE PROCESSUS DE SUPPORT PROCESSUS DE MANAGEMENT PROCESSUS D’INGENIERIE SYSTEME P Accompagnement au changement Gestion des coûts Maîtrise des relations fournisseurs Maîtrise des Relations clients Risques configuration Gestion de Gestion de la documentation la sécurité Maîtrise du déroulement du projet Périmètre du projet Développement Maintenance Besoins Mise en exploitation Maîtrise architecture du SI Qualification Traçabilité des exigences CYCLE DE VIE Gestion Production S Gestion des ressources informatiques des logiciels la pérennité Support de l ’infrastructure architecture de Design et Gestion des contrats de service Maîtrise des relations clients HELP-DESK Qualité Reporting Maintenance équipement recette des Installation et exploitation Mise en Contrôle et distribution de logiciels problèmes Gestion des documentation Gestion de la la sécurité Gestion de de parc Gestion changements Maîtrise des des relations fournisseurs Maîtrise locaux CLIENTS Services FOURNISSEURS Produits PROCESSUS DE MANAGEMENT PROCESSUS D’EXPLOITATION PROCESSUS DE SUPPORT Gestion des postes de travail Gestion du réseau Exploitation Gestion de l ’infogérance Gestion des performances Gestion des coûts Gestion des disponibilités Gestion de configuration PROCESSUS D’ORGANISATION Maîtrise des processus Management des ressources technologiques Management des ressources humaines Audit d ’organisation Benchmarking Contribution des processus DSI à nos métiers GEN-5

174

175 Un cycle de vie Qualité de service
Référence(s) d’usage Communication(s) QoS attendue QoS voulue MOE Partenaires MARKETING (chefs de produit) Réf Technologie(s) Référence de service MOE (Constructeur de services) EB(U) Niveau de service Business 1 Technique Client Opérateur Satisfaction client SLA (service level agreement) Mesures Chef de produit Production Partenaires QoS offerte (production) QoS Percue Service consommateur 2

176 La vie du service Vie du projet Fin Vie du service Création de la VABE
& Grille d’exploitabilité La vie du service Projet d ’étude Projet de réalisation Vie du projet Signature du contrat de projet Signature du contrat de projet VABF signée Fin (Fin de VSR) Spécification des besoins et choix des solutions Production VSR Réalisation Qualification Pré-prod (VABF) Vérification de l ’aptitude au bon fonctionnement SBU Architecture SERVICE RECURRENT Mise en place du SLA Définition du service Devis détaillé de l ’élaboration du service Devis détaillé du service récurrent Description détaillée des services Suivi des services Surveillance des contrats de service Reporting Suivi client du contrat Gestion des plans d ’amélioration Vérification du niveau de service (VABE) Application du contrat (VSR) Proposition de prix du service MEP Proposition du Contrat de service (Volet technique + Volet économique) Vie du service Signature du contrat de service

177

178 ITIL chez Bouygues Telecom
Mon retour d’expérience Un processus pour qu’il devienne culture c’est : 6 mois de définition 2,5 ans de mise en vie, d’instrumentation 1 à 2 ans d’optimisation des activités et organisations ITIL offre une boite à outils très complète et détaillée, MAIS vous n’avez certainement pas besoin de tout. Ne faites que ce qui est UTILE et sachez conserver la personnalité et le métier de votre entreprise Il est très difficile de mesurer préalablement le niveau de maturité de nos organisations opérationnelles (qui sommes nous? , d’où partons nous?, où voulons nous aller?, …) – ITIL offre une pré évaluation

179 ITIL chez Bouygues Telecom
Mon retour d’expérience On est toujours trop méthodologue, trop ambitieux et pas assez TERRAIN. (le proverbe qui dit que « l’appétit vient en mangeant » mais ceci déborde vite en indigestion et engorgement) ITIL parle réellement du métier de la production de service, c’est une très bonne référence d’opération et d’opérationnels Chaque processus ce doit d’être traité par itération Partager le vocabulaire et vérifier que les livrables terrain sont connus et intégrés (boite noire) Ecrire des règles d’opération et de pilotage (dont les missions) puis les faire appliquer (boite blanche) Rentrer dans un processus d’amélioration et d’optimisation

180 ITIL chez Bouygues Telecom
Mon retour d’expérience L’intégration des hommes est primordiale. ITIL est perçu par le collaborateur comme un enrichissement de ses connaissances et une structuration de ses missions Il est très difficile de rendre le producteur propriétaire de son outil de production (et ceci est d’autant plus vrai que les changements sont fréquents) La mise en œuvre du concept de l’industrialisation dans la production, a été une première preuve concrète de l’évolution de son niveau de maturité métier Le client final a très bien intégré une démarche de mise en œuvre de contrats de service (généralisé à l’entreprise)

181 ITIL chez Bouygues Telecom
Mon retour d’expérience L’outillage d’un process peut être très bénéfique et gain de temps (Base de données des erreurs connues, incidents), mais dans d’autres cas il peut en être autrement …. Indicateurs de QoS avec des « garbage collector » automatisation des SLA, UN PARADOXE En production industrielle, ce qui est craint c’est le changement, …… nous le savons tous!!! et pourtant Quand nous mettons en place ce type de référentiel, nous créons un très fort changement et nous avons trop tendance à l’oublier ……

182 Une dernière réflexion
Le client (donneur d’ordre) aujourd’hui est aux 2 bouts de la chaîne. Du côté développement il génère des multitudes de changements qui un jour vont arriver en production, A l’autre bout de la chaîne il impose à ce qu’on lui offre une continuité et qualité de service (en oubliant bien souvent que la discontinuité est de son fait) Pourquoi ne pas mieux responsabiliser sur le service, c’est-à-dire rendre le producteur de service, interlocuteur unique du client et de ses utilisateurs? En tout état de fait, ITIL en serait un très bon référent de contribution…


Télécharger ppt "ITIL, LES FONDAMENTAUX Et pour L’ITSMF responsable de la commission patrimoine, éducation et normalisation Thierry CHAMFRAULT Bouygues Telecom Responsable."

Présentations similaires


Annonces Google