Vous êtes sur la page 1sur 263

Bienvenue

Massimo D’Antonio – Manager Ingénierie des systèmes d’information

Cours 614-1.6 ITIL


massimo.dantonio@he-arc.ch

https://www.linkedin.com/in/dantoniomassimo/

Support de cours (2022-2023) : cyberlearn


Contenu du cours

1. Introduction
2. Les principes de la gestion des Services
3. Stratégie des Services (Service Strategy)
4. Conception des Services (Service Design)
5. Transition des Services (Service Transition)
6. Exploitation des Services (Service Operation)
7. Amélioration continue des Services (Continual Service Improvement)
8. Différences entre ITIL V3 (2007 et 2011) et V4 (2019)
9. Révision - Examen
« c’est un standard ou plutôt ça l’est devenu, sans en être vraiment un et sans en avoir la prétention »
Introduction
Qu’est-ce que ITIL
• ITIL est un recueil des bonnes pratiques
• Ce n’est pas une technologie, ni une méthodologie, ni un standard, ni une norme.
L’OGC (Office of Government Commerce britannique) en est le fondateur.
• C’est une approche pragmatique de l’informatique, la démarche est ouverte, non propriétaire,
publique. Par contre elle est soutenue par des outils ou des logiciels qui eux, peuvent être
propriétaires.
• Il sert à rendre l’IT plus transparent à l’organisation (éviter l’effet boite noire).
• Se traduit par des processus efficaces et efficients pour soutenir la qualité et le cycle de vie des
services IT.
• Réduire à long terme les coûts des prestations de services
Introduction
Autres bonnes pratiques et normes/standards disponibles:
COBIT: bonnes pratiques d'audit informatique et de gouvernance des systèmes d'information
(source wikipédia)

CMMI : (Capability Maturity Model Integration) : évaluation selon un modèle par échelons de la
maturité des activités d’ingénierie informatique et en particulier les activités de développement des
applicatifs.
Six Sigma : basée sur la méthode en cinq étapes DMAIC (Define , Measure, Analyze, Improve,
Control)
ISO 9000 : gestion de la qualité en général
ISO 20000 : qualité des services informatiques
ISO 27001: sécurité des systèmes d’information
Définitions
Business
Une société dans son ensemble ou une organisation composée d’un certain nombre d’unités
Client (MOA – Maitrise d’ouvrage)
Personne qui achète des produits ou des services. Le client d’un fournisseur de services informatiques
(aussi appelé « TI ») est la personne ou le groupe qui définit et convient des cibles de niveau de
service. (SLA)
Utilisateur
Personne qui utilise le service IT au jour le jour. L’utilisateur est représenté par le client. Il remonte ses
exigences auprès du client. L’utilisateur utilise le service mais ne le paye pas. Ses relations avec
l’informatique sont réalisées uniquement via le centre de services.
Définitions
Fournisseur de Service
Une organisation qui fournit des services à un ou plusieurs clients internes ou externes.
Fournisseur des services IT (Type 1 : interne , Type 2 : service partagé, Type 3 : service externe)
Fournisseur / sous-traitant
Tierce partie responsable de la fourniture de biens ou de services qui sont nécessaires à la fourniture
des services IT.
Exemples: revendeurs de matériel et de logiciels, fournisseurs de réseaux et de télécoms.
Définitions
Un Service c’est:
Un moyen de fournir une valeur ajoutée à des clients en facilitant les résultats souhaités sans que
ces clients n’aient à assumer les coûts ou les risques associés.

• Facilitant les résultats: amélioration de la performance et réduction des effets de contraintes


• Exemple : vente en ligne, E-banking, logiciels hébergés dans le cloud

« Alors que la gestion d’infrastructure se focalise sur la disponibilité opérationnelle des composants, la
gestion des services se concentre sur les clients et leurs besoins métier »
Concept de valeur
Ce que le client obtient :
le service est adapté à mes besoins fonctionnels ?
Service
• étude des besoins (Business Analyse)
• Amélioration continue Utilité
Comment est-il fourni ?
• Enquête de satisfaction client
• Monitoring (disponibilité/performances) Garantie
Fournisseurs de services - Type 1

Dpt business Dpt business Usine


R&D Finance / Logistique
Facturation

Fournisseur de Fournisseur de Fournisseur de


services Type 1 services Type 1 services Type 1
Interne Interne Interne
Fournisseurs de services - Type 2 (partagé)

Dpt business Dpt business Usine Dpt IT


R&D Finance / Logistique
Facturation

Fournisseur de
services Type 2
Partagé
Fournisseurs de services - Type 3 (externe)
Entreprise

Dpt business Dpt business Usine


R&D Finance / Logistique
Facturation

Entreprise A Entreprise B Entreprise C


Fournisseur de Fournisseur de Fournisseur de
services services services

= Coûts externes
Actifs de service
Management
Actifs
Organisation
Processus Aptitudes
TYPES D’ACTIFS

Connaissance
Coordonne, Sans actifs, pas
Personnes d’offre de service
contrôle et possible !
Information déploie
Application
Infrastructure Ressources

Capital Financier
Concept de service - exemple
Processus business (ex: analyse financière)

Service ERP Help Desk


Ce que le client obtient Utilité Utilité

De quelle manière il est fourni Garantie Garantie

Personnel qualifié
Infrastructure (serveurs) Organisation (processus comptables)
(compétences)

Information (données comptables) Application (logiciel comptable)


Concept de service – à l’échelle de l’entreprise
Services business Service de Service de
comptabilité logistique

Processus business facturation emballage

Services IT

Utilité Utilité Utilité Utilité

Garantie Garantie Garantie Garantie

Ressources et aptitudes
Management Organisation Connaissance Processus
Personnes
Application Infrastructure Capital Financier Information
Débriefing - Réflexion - feedback

• Questions et remarques
Bienvenue
Massimo D’Antonio – Manager Ingénierie des systèmes d’information

Cours 614-1.6 ITIL


massimo.dantonio@he-arc.ch

https://www.linkedin.com/in/dantoniomassimo/

Support de cours : cyberlearn


Contenu du cours

1. Introduction
2. Les principes de la gestion des Services
3. Stratégie des Services (Service Strategy)
4. Conception des Services (Service Design)
5. Transition des Services (Service Transition)
6. Exploitation des Services (Service Operation)
7. Amélioration continue des Services (Continual Service Improvement) - Facultatif
8. Différences entre ITIL V3 (2007 et 2011) et V4 (2019) - Facultatif
9. Révision - Examen
Gestion des Services
• Ensemble d’aptitudes organisationnelles (fonctions, processus) qui fournissent
une valeur ajoutée supplémentaire à des clients sous la forme de services.
• ITIL est une méthodologie centrée sur la Gestion des Services
• Origines : compagnies aériennes, banques, hôtellerie et opérateurs
téléphoniques
Fonction, Rôle et Processus
Fonction
• Une équipe ou un groupe de personnes, ainsi que les outils qu’ils utilisent pour
exécuter les processus et activités dont ils sont acteurs
Rôle
• Un ensemble de responsabilités, d’activités et d’autorités accordées à une
personne ou une équipe.
Fonction, Rôle et Processus
Processus
• Ensemble structuré d’activités conçues pour atteindre un objectif spécifique
• Intègre une ou plusieurs entrées et les convertit en sorties définies
• Activé par un déclencheur
• Inclut des rôles, des responsabilités, des outils et des contrôles de gestion
Contrôle de Processus
• Activité consistant à planifier et réguler un processus, afin d’exécuter un
processus de façon efficace, efficiente et consistante.
Fonctions ITIL
Centre de Services (Service Desk) – Help Desk
• Point de contact unique – SPOC (single point of contact) entre le fournisseur de
services et les utilisateurs (gestion des incidents, des requêtes et de la
communication avec les utilisateurs).
Gestion Technique (Technical Management)
• En charge de fournir les compétences techniques nécessaires au support des
Services Informatiques et à la gestion de l’infrastructure informatique.
Fonctions ITIL
Gestion des applications (Application Management)
• Responsable de la gestion des applications au cours de leur cycle de vie.
Gestion des opérations informatiques (IT Operation Management)
• Accomplit les activités quotidiennes nécessaires à la gestion des Services
Informatiques et au support de l’infrastructure informatique(inclut le contrôle
des opérations informatiques (batch, jobs, backups) et la gestion des
installations (ex : imprimantes, câblage, refroidissement du data center, etc…)
Fonctions, (Rôles et Processus)

Développement
Gest. produit Opérationnel

Une mauvaise coordination entre les fonctions, combinée avec un regard tourné vers l’intérieur, mène à des
silos fonctionnels.

Processus de Maintenance applicative

Processus d’approvisionnement

Processus d’amélioration Infra.


Mise en situation

Par groupe de 2 personnes...

Vous êtes DSI (Directeur des services d’information) d’une entreprise de services financiers et vous devez
convaincre votre équipe d’adopter la culture service. (gestion des services)
Développez les motivations qui justifient votre démarche.

Pourquoi ?
Quels sont les enjeux qui justifient de s'orienter vers une approche service.
Du point de vue de l'entreprise, du métier mais aussi pourquoi pas les enjeux vus de la Direction Informatique.

Comment ?
Expliquez comment une telle approche peut elle se mettre en place dans l’organisation.
Quels changements et quels impacts sont à prévoir sur l'équipe informatique en place.

Quoi ?
Imaginez quelques bénéfices concrets de cette démarche.
Développez des exemples de non-qualité présents dans votre organisation qui pourraient être corrigés par cette
approche.
Processus

Fournit des changements et des transformations dirigées vers un but, et utilise le


feedback pour entreprendre des actions pour s’auto-renforcer et s’auto corriger.
Les processus sont mesurables, apportent aux clients des résultats spécifiques et
répondent à un évènement spécifique.
Rôles
Gestion des applications (Application Management)
• Responsable de la gestion des applications au cours de leur cycle de vie.
Gestion des opérations informatiques (IT Operation Management)
• Accomplit les activités quotidiennes nécessaires à la gestion des Services
Informatiques et au support de l’infrastructure informatique (inclut le contrôle
des opérations informatiques (batch, jobs, backups) et la gestion des
installations (ex : imprimantes, câblage, refroidissement du data center, etc…)
Matrice des responsabilités - RACI

Responsible Accountable Consulted Informed


Responsable
Autorité/Imput
• exécution able Consulté
correcte des Informé
processus et • Propriétaire • Implication via
le partage de • Tenu au courant
activités de la qualité de l’exécution
et du résultat connaissances
et de la qualité
du processus du processus
• Il y a une seule personne Accountable par processus.
• Il y a au minimum 1 personne Responsable par processus.
• Les 2 autres responsabilités sont optionnelles.
Exercice RACI Restaurant

Roles Directeur de Cuisine, Chef de cuisine, sous chef, Chef


de partie , Commis de cuisine

Taches • Gestion des réservations de l’établissement et


facturation
• Planification des menus
• Choix de l’ achats des ingrédients auprès des
fournisseurs
• Supervision de la partie garde-manger
• Préparer et laver les légumes
• Mise sur assiette lors d’un service
• Coordination et ordonnancement des commandes
lors d’un service
Propriétaire de Processus (Process Owner)
Responsable du déroulement du processus conformément aux accords et à la
documentation. Doit s’assurer que le processus remplit son rôle tel que défini
• Participe à la conception et mise en œuvre du processus, il est garant des résultats
• Documente et diffuse le processus
• Fournit les ressources suffisantes pour le bon fonctionnement du processus
• Définit les KPI (clé de performance) afin d’évaluer l’efficacité du processus
• Evalue les propositions d’amélioration
• Résout les anomalies et les disfonctionnements du processus
• S’assure que le personnel concerné a le niveau de formation requis et qu’il soit au
courant du rôle qu’il occupe dans le processus.
• S’assure de l’audit du processus (documentation, rôles, responsabilités)
Gestionnaire de Processus (Process Manager)
Responsable de la gestion opérationnelle du processus. Doit s’assurer que les
activités associées au processus soient exécutées conformément aux accords
• Collabore avec le propriétaire de processus sur la planification et coordonne les activités
• Gestion des ressources. Nomme les ressources aux rôles inclus dans les activités du
processus.
• Assure la liaison avec les autres gestionnaires de processus et propriétaires de services
tout au long du cycle de vie de la gestion des services.
• Sollicite les données, statistiques et rapports nécessaires à une surveillance efficace du
processus et de sa performance.
• Identifie des potentielles améliorations du processus
• Coordonne avec le propriétaire de processus la priorisation et l’implémentation des
améliorations
Practicien de Processus (Process Practitioner)
Responsable de l’exécution d’une ou plusieurs activités associées au processus
• Valide, avec le gestionnaire de processus, la finalité du rôle dans la fourniture du service
global et la création de valeur ajoutée
• Collabore avec les parties prenantes pour s’assurer que les actions entreprises soient
efficaces.
Propriétaire de service (service owner)
Responsable auprès du client pour la création, la transition, la maintenance et le
support d’un service donné
• Sert de contact privilégié auprès du client pour toute question et challenge relatifs au
service
• Fait en sorte que le service soit fourni et supporté selon les besoins convenus avec le
client
• Identifie les opportunités d’amélioration du service. Discute avec le client et soumet la
RFC (request for change) si approprié.
• Sollicite les données, statistiques et rapports nécessaires à une surveillance efficace du
service et de sa performance.
• Assure la liaison avec les autres propriétaires de processus tout au long du cycle de vie
de la gestion des services
Bienvenue
Massimo D’Antonio – Manager Ingénierie SI

Cours 614-1.6 ITIL


massimo.dantonio@he-arc.ch

https://www.linkedin.com/in/dantoniomassimo/

Support de cours (2021-2022) : cyberlearn


Contenu du cours

1. Introduction
2. Les principes de la gestion des Services
3. Stratégie des Services (Service Strategy)
4. Conception des Services (Service Design)
5. Transition des Services (Service Transition)
6. Exploitation des Services (Service Operation)
7. Amélioration continue des Services (Continual Service Improvement)
8. Différences entre ITIL V3 (2007 et 2011) et V4 (2019)
9. Révision - Examen
Stratégie des Services
 Création de valeur
 Processus
 Gestion du portefeuille de services
 Gestion de la demande (demand management)
 Gestion financière (financial management)
 Gestion de la relation business (business relationship management)
Accent sur la valeur
Les clients sont réticents à acheter lorsqu’il y a une ambiguïté dans la relation de cause à effet entre
l’utilisation d’un service et la réalisation de bénéfices.
Les clients n’achètent pas de services; ils achètent la satisfaction de besoins particuliers

Positionnement stratégique du fournisseur IT


Quel est notre business? Qui sont nos clients ?

Où est la valeur ajoutée aux yeux de nos clients ? Qui dépend de nos services ?

Comment utilisent-ils nos services ? Pourquoi nos services ont-ils de la valeur aux yeux
de nos clients ?
Création de valeur
Actifs de Service : créateurs de valeur
Actif :
 Toute ressource ou aptitude d’un fournisseur de service. Les biens d’un fournisseur de service
regroupent tout ce qui peut contribuer à fournir un service. Les actifs peuvent appartenir à une
des catégories suivantes : gestion, organisation, processus, connaissances, personnel,
information, applications, infrastructure, et capital financier.
Ressources :
 Toute ressource ou aptitude susceptible de contribuer à la fourniture d’un service
(management, organisation, processus, connaissance, personnel, information, application,
infrastructure, capital financier)
Aptitudes :
 Terme générique incluant l’organisation, le management, les processus, les connaissances
pouvant contribuer à la coordination, contrôle et déploiement de ressources pour produire de la
valeur
• Capacité d’une ressource ou fonction à accomplir une activité
• Sont développées au cours du temps, et améliorées par les expériences
Actifs de service

Management Unité Business Conditions cadres :


Perspectives
Organisation Concurrents
Régulateurs
Crée de la valeur Fournisseurs
Processus Aptitudes
TYPES D’ACTIFS

Connaissance

Influence
Personnes
Coordonne, Consomme des actifs
contrôle et Biens/Services
Information
déploie
Application
Demande
Offre
Infrastructure
Ressources
Capital Financier Clients
Génère des retours
(ou couvre les coûts)
Atelier Stratégie (20 minutes à disposition)

• Sur la base du schéma des actifs de service et de la création de valeur:


• Créer votre service informatique en expliquant:
1. Les actifs de services employés, la valeur créé pour le client (moins de contraintes ou/et
bénéfices)
2. La demande à laquelle ils répondent (voir positionnement stratégique des services)
– Quel est notre business ? Qui sont nos clients ?
– Tarifs / sous-traitants
– Durée de vie / améliorations futures
– Les éléments externes qui pourraient les influencer
Portefeuille de Services
Ensemble complet des services qui sont gérés par un fournisseur de services
Utilise des termes de valeur business

• Description / Bénéfices pour les clients


• Marchés cibles
• Options tarifaires Résultat -> Document : fiche de service
• Sous-traitants
• Durée de vie / Améliorations

Intégré au système de gestion des configurations (CMS = Configuration Management System),


lui-même intégré au système de gestion des connaissances des services (SKMS = Service
Knowledge Management System)
Objectifs
Obtenir un maximum de création de valeur tout en gérant les risques et les coûts.

Fournir une méthode dynamique pour la gouvernance des investissements dans la gestion des services
à travers l’entreprise.

 Clarifier les questions stratégiques suivantes:


 Pourquoi un client devrait-il acheter ces services ?
 Pourquoi devraient-ils vous les acheter ?
 Comment sont les prix et le modèle de remboursement ?
 Quels sont les forces et les faiblesses, priorités et risques ?
 Comment mes ressources et aptitudes doivent-elles êtres distribuées ?
Bienvenue
614-1.6 ITIL
Contenu du cours

1. Introduction
2. Les principes de la gestion des Services
3. Cycle de vie des Services
4. Stratégie des Services (Service Strategy)
5. Conception des Services (Service Design)
6. Transition des Services (Service Transition)
7. Exploitation des Services (Service Operation)
8. Amélioration continue des Services (Continual Service Improvement)
9. Révision - Examen
SKMS=Service Knowledge Management System
Le portefeuille des services est maintenu par la
conception de services, mais est sous la
responsabilité de la stratégie de services.
Le service pipeline est une sous-partie du
portefeuille des services
processus récurrent

Stratégie de Service

• Inventaires Faire l’inventaire des services,


Définir • Business Case sécuriser les business cases et
valider les données du portfolio

• Value Proposition Maximiser la valeur du


Analyser • Priorisation Portfolio, aligner, prioriser et
équilibrer l’offre et la demande

• Service Portfolio Finaliser le portfolio proposé,


Approuver • Autorisation autoriser les services et les
ressources
Communiquer les décisions,
• Communication
Mobiliser • Resource allocation
allouer les ressources et les
services

Tout service dans le portfolio doit inclure un business case, modèle décrivant ce
que le service doit accomplir
Gestion de la demande - Objectifs

Analyser et prédire aussi précisément que possible l’achat de services et, si


possible, le réguler
La consommation génère de la demande, laquelle est consommée par la
production lors d’un cycle fortement synchronisé

Fournir un modèle

Le cycle de Le cycle de
consommation Actifs production
Actifs
produit de la Client
de consomme de
Service la demande
demande

Répond avec de la capacité


Gestion de la demande - Schéma d’Activité Business

Schémas d’Activité Business (PBA: Pattern of Business Activity)


Les schémas d’Activité Business sont utilisés pour aider les fournisseurs de services
à comprendre et planifier les variations d’activités liées au business
Modèle de demande

Schémas Plan de
d’activité Processus Processus
Gestion de
Business Service
business Capacité
Courroie de transmission

Calendrier de fourniture
Gestion de la
Incitations et pénalités pour Demande
influencer la consommation
Gestion de la demande - Service Principal vs Soutien
Offre de Services
 Service principal
• Offre les services de base attendus par le client
• Constitue l’offre de valeur pour le client
 Service de soutien
• Permettent/améliorent l’offre
 Le groupe Services principaux/Services de soutien constitue un aspect
important de la stratégie du Marché

Service Principal

Service de Soutien 1 Service de Soutien 2 Service de Soutien 3


Gestion Financière - Défis
• Une demande mal gérée est source de risques pour les fournisseurs de services
à cause de l’incertitude qu’elle génère
• L’excès de capacité génère des coûts sans créer de valeur pouvant servir
de base pour le recouvrement de ceux-ci
• Dans certains cas, un surplus de capacité est nécessaire pour fournir les
niveaux de service souhaités
• Une capacité insuffisante a un impact sur la qualité des services
fournis et limite la croissance d’un service
• Production et consommation synchrones
Gestion Financière - But
• Gérer les besoins en relation avec le budget, la comptabilité et la facturation
d’un fournisseur de services informatiques
• Garantir l’obtention d’un financement correct pour la fourniture et l’achat de
services informatiques
• Traduire utilité et garantie en termes monétaires afin d’en calculer la valeur
• Refacturer les coûts des services + valeurs aux clients
Gestion Financière - Objectifs

• Prise de décision améliorée


 Notre stratégie de différentiation génère-t-elle de meilleurs profits, des coûts moindres, une
meilleure adoption des services ?

• Réponse rapide aux changements


 Sommes-nous toujours compétitifs (prix du marché, valeur ajoutée) ?

• Gestion du portefeuille de services


 Quels services coûtent le plus, le moins et pourquoi ? Est-ce justifié au regard de la valeur
ajoutée pour le business ?

• Conformité financière et contrôle


 Quels volumes et types de services sont consommés ? Est-ce cohérent avec les budgets ?

• Contrôle Opérationnel
 Nos coûts sont-ils alignés sur les risques business ?
Gestion Financière – Dossier Business (Business Case)

• Un dossier business est un outil de planning et d’aide à la décision qui


anticipe les conséquences probables d’une action business
• Il permet de préciser:
Objectifs business
 La raison qui justifierait de considérer une initiative de gestion des services

Impact business
 Financier
 Non-Financier

TCO (Total Cost of Ownership)


Retour / Valeur sur investissement
Risques & Bénéfices
Impact organisationnel
Gestion de la relation business - (Business Relationship management)
But
• Fournir un point de contact privilégié au client pour tout sujet stratégique,
tactique ou en rapport avec la gouvernance des services
• Etablir et maintenir une relation fournisseur – client forte basée sur la
connaissance du client, ses attentes présentes et ambitions futures
• Quels sont les besoins client ?
• Pourquoi exprime-t-il ces besoins ?
• Comment va-t-il utiliser ces besoins afin de créer de la valeur ajoutée business ?
Gestion de la relation business - (Business Relationship management)
Objectifs
• S’assurer que le fournisseur ait une compréhension claire de la perspective
service du client afin de positionner de manière optimale ses services
• S’assurer d’un niveau de satisfaction client irréprochable
 Besoins business sont traités
 Valeur ajoutée des services est contrôlée

• Identifier les changements dans l’environnement du client qui impacteraient


le type, niveau ou utilisation des services fournis
• Articuler les besoins business pour tout nouveau ou amélioration de service
existant
Gestion de la relation business - (Business Relationship management)
Gestionnaire des relations business (Account Manager)
• Rôle en charge du maintien des relations avec le clients
• Rôle souvent combiné avec celui du propriétaires des niveau de service (SLA)
• Aide à identifier les schémas d’activité business et valider les modèles de
demande et coût durant la phase de stratégie des services
• Aide à traduire les besoins business du client durant la phase de conception des
services
• Aide à gérer la mise en production des services d’un point de vue client durant la
phase de transition
• Point de contact pour toute demande d’escalade ou complainte du client
Débriefing - Réflexion - feedback

• Analyse de l’atelier
• Thèmes abordés
• Questions et remarques

• Prochain thème ->


Conception des Services
Bienvenue
614-1.6 ITIL
Contenu du cours

1. Introduction
2. Les principes de la gestion des Services
3. Cycle de vie des Services
4. Stratégie des Services (Service Strategy)
5. Conception des Services (Service Design)
6. Transition des Services (Service Transition)
7. Exploitation des Services (Service Operation)
8. Amélioration continue des Services (Continual Service Improvement)
9. Différences entre ITIL V3 (2007 et 2011) et V4 (2019)
10. Révision - Examen
Conception des services
Principes
Processus
• Coordination de la conception (Design coordination)
• Gestion du Catalogue de Services (Service Catalogue Management)
• Gestion des niveaux de service (Service Level Management)
• Gestion de la capacité (Capacity Management)
• Gestion de la disponibilité (Availability Management)
• Gestion de la continuité (IT Service Continuity Management)
• Gestion de la sécurité de l’information (Information Security Management)
• Gestion des fournisseurs (Supplier Management)
Principes
Amélioration du niveau de confiance lors de l’introduction de services
nouveaux ou modifiés dans l’environnement opérationnel
 Avec un niveau de satisfaction aligné sur les objectifs business (qualité,
conformité, risques, sécurité …)
 Sans impacter les autres services ou parties prenantes
Rappel: définition de service
Un moyen de fournir une valeur ajoutée à des clients en facilitant les résultats
attendus sans que ces clients n’aient à assumer les coûts ou les risques
spécifiques.
5 aspects majeurs de la conception de services
 Conception des solutions de service
 Basée sur les besoins fonctionnels, performances, ressources et aptitudes
 Conception des technologies et des architectures
 Conception des processus (…pour soutenir les services)
 Conception des techniques de mesures (KPI)
 Conception des systèmes de support et outils
 Principalement le portefeuille de service, incluant le catalogue de services
Principes de conception des services
 La conception des services doit considérer les:
 Processus business: pour définir les besoins fonctionnels
 Services
 SLAs/SLRs (Accord/Exigences sur les niveaux de services)
 Infrastructure: équipement informatique nécessaire pour fournir le service
 Environnement: nécessaire pour sécuriser et faire fonctionner l’infrastructure
 Données: nécessaires pour soutenir le service et fournir l’information demandée
 Applications: logiciels nécessaires pour manipuler les données
 Services de soutien: tout service supportant l’exploitation
 OLAs (Operational Level Agreements) and UCs (Underpinning Contract)
 Equipes de soutien: équipes internes fournissant un support de 2ème et 3ème niveau
 Fournisseurs: équipes externes fournissant un soutien de 3ème et 4ème niveau
Modification de processus business

Modification de Dev. du Implémentatio Réalisation


Exigences et Processus
Processus n du Processus d’avantages
Faisabilité Business Business
Business Business Business

Exigences IT Services IT

Cycle de vie des services IT

Personnes

Les 4 Ps Processus Produits

Partenaires
Question ?
 Lequel des énoncés suivants décrit les quatre Ps de la conception de services ?
a) Un processus pour la conception des services effectifs
b) Les aspects de la planification, perspective, positionnement et de personnes
lors de la conception des services
c) Les questions à poser lors de la révisions des spécifications
d) Les éléments de personnes, partenaires, produits et processus à prendre en
considération lors de la conception des services
Composition d’un service
Définitions
 Package de conception de service (SDP = Service Design Package)
 Document(s) définissant tous les aspects d’un service et ses besoins à chaque étape de son
cycle de vie. Un SDP est produit pour chaque nouveau service, changement majeur, ou retrait
de service
 Charte de service (description, utilité, garantie)
 Modèle de service
 Architecture de service
 Design détaillé de construction et intégration de service
 Plan de déploiement et mise en production
 Critères d’acceptation d’un service
 Critères d’acceptation d’un service (SAC = Service Acceptance Criteria)
 Ensemble des critères utilisés pour s’assurer qu’un service informatique remplit sa
fonction et ses exigences de qualité, et que le fournisseur du service est prêt à le faire
fonctionner une fois déployé
Question ?
 Le Package SDP devrait formuler en détail tous les aspects du service et ses
exigences pour le Cycle de Vie. Parmi la/les proposition(s) la/lesquelle(s) sont
valide(s) ?
1. Des exigences business validées et documentées
2. Une définition de service pour les opérations
3. Des exigences pour de nouveaux processus ou processus modifiés
4. Des métriques utilisées pour la mesure du service

a) 1 seulement
b) 2 et 3 seulement
c) 1,2 et 4 seulement
d) Toutes
Concevoir les architectures (Gouvernance)
 Architecture
 L’organisation fondamentale d’un système, matérialisée par ses composants, leurs relations et
celle avec l’environnement, et les principes déterminant sa conception et son évolution

 Système
 Un ensemble de composants organisés pour remplir une fonction ou un ensemble de fonctions

 Conception d’architecture
 Le développement et la maintenance au sein d’une organisation des politiques, stratégies,
conceptions, documents, plans et processus mis en place pour le déploiement, l’exploitation et
l’amélioration des services informatiques
Architecture d’Entreprise
Le processus de traduction d’une vision et stratégie business en changement effectif au sein de
l’entreprise, par la création, la communication et l’amélioration de principes et modèles clés, qui
décrivent l’état futur de l’entreprise et permettent son évolution [Gartner]

Architecture Business / Organisationnelle

Architecture d’entreprise
Architecture de service Architecture des
données / information
Architecture applicative
Architecture environnementale

Architecture de l’infrastructure technique


Architecture de gestion

Architecture des produits


Relations d’architecture

Modèles business
Architecture Business / Organisationnelle Processus business
Design organisationnel

Livraison
Feedback
Monitoring SKMS

Architecture de service Portefeuille de services


Soutenu
par

Architecture des
Architecture applicative Influencé par
données / information

Bâtiment / Site
Utilise
Salle d’équipement
Architecture environnementale Centres de données primaires
Centre de données secondaires
Architecture de l’infrastructure technique
Architecture de gestion

Architecture des produits


Contraintes définies par la stratégie

 Finances
 Engagement
 Propriété intellectuelle
 Clients
 Aptitudes
 Valeurs et éthique
 Concurrents
 Normes, lois
 Ressources
Important : les contraintes délimitent le périmètre du service
Débriefing - Réflexion - feedback

• Analyse de l’atelier
• Thèmes abordés
• Questions et remarques

• Prochain thème ->


Conception des Services
Bienvenue
Massimo D’Antonio – Spécialiste des systèmes de diffusion et responsable d’applications

Cours 614-1.6 ITIL


massimo.dantonio@he-arc.ch

https://www.linkedin.com/in/dantoniomassimo/

Support de cours (2021-2022) : cyberlearn


Contenu du cours

1. Introduction
2. Les principes de la gestion des Services
3. Stratégie des Services (Service Strategy)
4. Conception des Services (Service Design)
5. Transition des Services (Service Transition)
6. Exploitation des Services (Service Operation)
7. Amélioration continue des Services (Continual Service Improvement)
8. Différences entre ITIL V3 (2007 et 2011) et V4 (2019)
9. Révision - Examen
Conception des services
Principes
Processus
• Coordination de la conception (Design coordination)
• Gestion du Catalogue de Services (Service Catalogue Management)
• Gestion des niveaux de service (Service Level Management)
• Gestion de la capacité (Capacity Management)
• Gestion de la disponibilité (Availability Management)
• Gestion de la continuité (IT Service Continuity Management)
• Gestion de la sécurité de l’information (Information Security Management)
• Gestion des fournisseurs (Supplier Management)
Coordination de la conception (Design coordination)
 Assurer une conception consistante des services, de la gestion de l’architecture, les
techniques, les processus, l’information et métriques des services pour atteindre les
besoins business courants ou en évolution
 Coordonner les activités autours des projets, des changements, des fournisseurs
et des équipes de support.
 Gérer et planifier les ressources nécessaires à la conception des services nouveaux
ou modifiés
 Produire les Services Design Packages (SDPs) basés sur les critères de services
et requêtes de changement
 Gérer les critères de qualité (SACs) pour chaque étape de la conception,
stratégie et transition des services
 Améliorer l’efficacité et l’efficience des activités de conception et des processus
associés
 Assurer l’adoption de processus, systèmes et technologies standards et maitrisés
afin d’optimiser l’efficacité et l’efficience des activités de conception
Coordination de la conception - Périmètre
 Assistance et support aux projets et autres changements dans les activités et
processus du cycle de conception des services
 Maintenir la politique, guide, standard, budgets, modèles ainsi que les ressources et
aptitudes
 Coordonner, prioriser et planifier les ressources et gérer les conflits
 Planifier et faire les projections sur les besoins futur de ressources
 Revoir, mesurer et améliorer la performance des processus de conception
 Assurer que les exigences sont correctement adressées dans la conception en
particulier sur l’utilité et la garantie
 Produire les Services Design Packages (SDPs) et les transmettre à la
transition des services
 La coordination de la conception n’inclut pas :
• Responsabilité dans les activités des processus en dehors de la phase de conception

• Conception détaillée des solutions de service et des parties spécifiques de chaque SDPs, ceci étant à la
charge des différents projets
Conception des services
Principes
Processus
• Coordination de la conception (Design coordination)
• Gestion du Catalogue de Services (Service Catalogue Management)
• Gestion des niveaux de service (Service Level Management)
• Gestion de la capacité (Capacity Management)
• Gestion de la disponibilité (Availability Management)
• Gestion de la continuité (IT Service Continuity Management)
• Gestion de la sécurité de l’information (Information Security Management)
• Gestion des fournisseurs (Supplier Management)
Gestion du catalogue de services – Objet, But et Objectifs
 Objet
 Fournir une source unique d’informations cohérentes sur tous les services
approuvés, et s’assurer qu’elles sont largement disponibles à ceux qui sont
habilités à y accéder
 But
 Garantir qu’un catalogue de services est produit et maintenu, avec une
information exacte et précise sur tous les services opérationnels et ceux
destinés à l’être
 Objectifs
 Gérer l’information contenue dans le Catalogue de Services, et s’assurer
qu’elle est exacte et reflète les détails, statuts, interfaces et dépendances
courantes de tous les services qui sont exécutés, ou préparés à l’être, dans
l’environnement d’exploitation
Concept de base
Le Catalogue de services est un sous-ensemble du
portefeuille des services informatiques qui fournit des
informations centralisées et fiables sur tous les
services
Le catalogue des services vise à développer une
culture orientée service

Le Catalogue a 2 aspects:
• Le Catalogue de services business
• Le Catalogue de services techniques
Concept de base
Le catalogue de services business / technique

Processus Business Processus Business


1 2

Service IT Service IT Service IT


A B C

Service de soutien Matériel Logiciel Applications


QUIZ
 Un catalogue de services devrait contenir laquelle des propositions
suivantes ?

a) Les informations sur les versions de tous les logiciels


b) La structure organisationnelle de l’entreprise
c) Les informations sur les actifs
d) Les détails de tous les services opérationnels
Conception des services
Principes
Processus
• Coordination de la conception (Design coordination)
• Gestion du Catalogue de Services (Service Catalogue Management)
• Gestion des niveaux de service (Service Level Management)
• Gestion de la capacité (Capacity Management)
• Gestion de la disponibilité (Availability Management)
• Gestion de la continuité (IT Service Continuity Management)
• Gestion de la sécurité de l’information (Information Security Management)
• Gestion des fournisseurs (Supplier Management)
Gestion des niveaux de service – Objet, But et Objectifs
 Objet
 Faire en sorte que tous les services opérationnels ainsi que leurs performances
soient mesurées de manière cohérente et professionnelle dans toute
l’organisation informatique, et qu’autant les services que les rapports produits
remplissent les attentes du business et des clients.
 But
 Assurer la fourniture de tous les services informatiques au niveau convenu avec
le business
 Faire en sorte que les niveaux de services à venir soient réalistes
 Objectifs
 Fournir et valider des exigences niveau de services (SLR: Service Level
Requirements) pour les services planifiées (nouveaux ou modifiées)
 Etablir et maintenir les accords sur les niveaux de services (SLAs) pour tous les
services opérationnels
 Fournir un point de contact et de communication régulier aux clients et
représentants business
Gestion des niveaux de service – Périmètre
 Définir, documenter, s’entendre, mesurer, rapporter et réviser les niveaux
des services informatiques fournis
 Fournir et améliorer les relations et la communication avec le business et
les clients
 Assurer le développement de cibles spécifiques et mesurables pour tous les
services informatiques
 Monitorer et améliorer la satisfaction des clients quant à la qualité des
services fournis
 S’assurer que l’informatique et les clients ont des attentes claires et sans
ambiguïté quant aux services à fournir
 Si les coûts sont justifiés: Assurer l’implémentation de mesures proactives
pour l’amélioration des niveaux de service
Gestion des niveaux de service – Définitions
 SLR: Exigences de niveau de service (Service Level Requirement)

 SLA: Accords sur les niveaux de service (Service Level Agreement)

 OLA: Accords sur les niveaux opérationnels (Operational Level Agreement)

 UC: Contrat de sous-traitance (underpinning contract)

 SIP: Plan d’amélioration de service (service improvement plan)


Types de SLA
 SLA de Service

 Le SLA couvre un service, quels que soient les clients de ce service

 SLA Client

 Accord avec un groupe de clients couvrant tous les services que ce groupe utilise

 SLA multi-niveaux Niveau Entreprise

 Niveau Entreprise (Corporate Level) Niveau Client


Niveau Service
 Niveau Client (Customer Level)

 Niveau Service (Service Level)


Notions Clés
 Déterminer, documenter et s’accorder sur les exigences des nouveaux
services et produire les SLRs

 Structurer des SLAs d’après le catalogue de services

 S’assurer que tous les autres processus soient consultés

 Produire un SLA pilote

 Etablir des procédures pour l’accord sur les exigences de service (SLR)

 Graphique de Monitoring des SLAs (SLAM)

 Produire des rapports de service


Notions Clés 2
 Revue de Services
 Revue avec les clients sur une base régulière
 Pour améliorer les maillons faibles
 Se concentrer sur chaque rupture de niveau de service

 Plan d’amélioration de services (SIP)

 Revoir et réviser les SLAs, le périmètre de service et les accords de sous-


traitance

 Développer contacts et relations


Diagramme SLAM (Exemple)

Attention : Anomalie 4 mois de suite


Facteurs critiques de succès (CSF) et Indicateurs clé de
performance (KPIs)

 CSF: Pertinence des SLA


 KPI: Nombre de services qui ont des SLA à jour
 KPI: Nombre de services qui sont à jour du point de vue du
contrôle
 CSF: Atteinte des objectifs définis
 KPI: Nombre ou pourcentage des objectifs de services atteints
 KPI: Nombre et gravité des défauts de service
 KPI: Satisfaction client
Défis

 Identification de représentants clients adaptés

 Identification d’objectifs réalistes et atteignables

 Diffusion et communication des SLAs à tous le personnel concerné

 Obtenir le soutien du management de l’IT mais aussi du Client

 Utilisation d’un processus pro-actif et non bureaucratique pour pouvoir


disposer d’avantages mesurables
QUIZ
 La gestion des niveaux de services (SLM) est responsable de laquelle des
activités suivantes ?

a) Concevoir le système de gestion des configurations avec une perspective


business
b) Créer des métriques technologiques alignées sur les besoins du client
c) Discuter des services fournis avec les clients
d) Former le personnel du centre de services sur comment gérer les plaintes
clients sur le service
QUIZ
 Laquelle des propositions suivantes est la MEILLEURE description d’un
accord sur les niveaux opérationnels (OLA) ?

a) Un accord entre un fournisseur de services TI et une autre partie de la même organisation


qui soutient la livraison des services
b) Un accord écrit entre le fournisseur de services des TI et le(s) client(s) TI qui spécifie les
cibles clés et les responsabilités des deux parties
c) Un accord entre deux fournisseurs de services sur les niveaux de service exigés par le client
d) Un accord sur les délais de correction et de réponse entre un centre de services d’une tierce
partie et le client des TI
QUIZ
 Quel processus effectue les revues des accords sur les niveaux
opérationnels (OLA) de façon régulière

a) La gestion des fournisseurs


b) La gestion des niveaux de service
c) La gestion du portefeuille de service
d) La gestion de la demande
Débriefing - Réflexion - feedback

• Analyse de l’atelier
• Thèmes abordés
• Questions et remarques

• Prochain thème ->


Conception des Services
Bienvenue
614-1.6 ITIL
Contenu du cours

1. Introduction
2. Les principes de la gestion des Services
3. Cycle de vie des Services
4. Stratégie des Services (Service Strategy)
5. Conception des Services (Service Design)
6. Transition des Services (Service Transition)
7. Exploitation des Services (Service Operation)
8. Amélioration continue des Services (Continual Service Improvement)
9. Révision - Examen
Conception des services
Principes
Processus
• Coordination de la conception (Design coordination)
• Gestion du Catalogue de Services (Service Catalogue Management)
• Gestion des niveaux de service (Service Level Management)
• Gestion de la capacité (Capacity Management)
• Gestion de la disponibilité (Availability Management)
• Gestion de la continuité (IT Service Continuity Management)
• Gestion de la sécurité de l’information (Information Security Management)
• Gestion des fournisseurs (Supplier Management)
Gestion de la capacité (Capacity Management)
 Objet
 Fournir un point central de réflexion et de gestion pour tous les aspects associés à la
capacité et à la performance, tant du point des services que des ressources

 But
 Assurer l’existence d’une capacité d’un coût justifiable dans tous les domaines de
l’informatique
 Assurer que la capacité est adaptée aux besoins actuels du business, tels qu’ils ont été
convenus
 Anticiper les besoins futurs du business et adapter la capacité lorsque le moment est venu

 Objectifs
 Plan de Capacité
 Conseil et orientation
 Assurer que la performance effective satisfait ou dépasse les objectifs convenus
 Gestion des incidents et problèmes liés à la capacité
 Evaluation d’impact
 Mesures proactives
Processus

Revue de la capacité et
performance actuelle
Rapport et données de
capacité et performance
Amélioration de la
capacité actuelle des
services et composants

Evaluation, accord &


documentation des
nouvelles exigences Prévisions

Plan de capacité
Planifcation

CMIS : Capacity Management Information System


Sous-processus
 Gestion de la capacité business (BCM)
 Compréhension des besoins et plans business, et traduction en exigences de services et
d’infrastructure informatique
 (ex: besoin de facturer 300x/jour / besoin de stocker les données pendant 10 ans)

 Gestion de la capacité des services (SCM)


 Compréhension de la performance et de la capacité bout-à-bout des services
informatiques
 (ex: le service de backup peut stocker x années de données / le logiciel de facturation peut
facturer 500x/jour)

 Gestion de la capacité des composants (CCM)


 Compréhension de la capacité, utilisation et performance des éléments de configuration
(CI)
 (ex: notre SAN peut stocket 3 pétabytes de données, notre module ERP de facturation a telle ou
telle fonctionnalité qui permet d’effectuer tant de d’opérations comptables)
CMIS (Capacity Management Information System)
 Contenu du CMIS
 Données Business: plans, prévisions, transaction business
 ex. nombre de factures établies, nombre de lignes de produit

 Données liées à l’usage des Services:


 ex. temps de réponse des transactions, nombre de transaction/temps, Charge…

 Données liées à l’usage des Composants:


 Ex. limite de capacité, taux d’utilisation actuel/passé des composants

 Données financières
Plan de capacité
 Sert à gérer les ressources nécessaires à la fourniture des services
informatiques

 Contient des scénarios correspondants à différentes prévisions


d’exigences du business ainsi que des options cotées pour répondre aux
objectifs de niveau de service convenus.

 Contient des détails sur l’utilisation actuelle en historique des services


et composants, et toute initiative d’amélioration continue
Conception des services
Principes
Processus
• Coordination de la conception (Design coordination)
• Gestion du Catalogue de Services (Service Catalogue Management)
• Gestion des niveaux de service (Service Level Management)
• Gestion de la capacité (Capacity Management)
• Gestion de la disponibilité (Availability Management)
• Gestion de la continuité (IT Service Continuity Management)
• Gestion de la sécurité de l’information (Information Security Management)
• Gestion des fournisseurs (Supplier Management)
Gestion de la disponibilité – Objet, But et Objectifs
 Objet
 Fournir un point central de réflexion et gestion pour tous les aspects reliés à la
disponibilité, tant du point de vue des services que des ressources
 Garantir la mesure et la satisfaction des objectifs de disponibilité
 But
 Garantir que le niveau de disponibilité fourni par tous les services satisfait ou
dépasse les besoins négociés avec le business, et ce à un coût efficace
 Objectifs
 Plan de disponibilité
 Conseil et orientations
 Garantir la satisfaction ou le dépassement des cibles de disponibilité
 Incidents et problèmes liés à la disponibilité
 Evaluation d’impact (Risques)
 Mesures proactives
Gestion de la disponibilité – Principes
 La disponibilité des services est au cœur de la satisfaction client et du succès
business
 Même en cas d’interruption du service, il est encore possible de satisfaire le
business, les clients et les utilisateurs
 Améliorer la disponibilité n’est possible qu’après avoir compris comment les services
informatiques soutiennent le business
 Il est meilleur marché de concevoir le bon niveau de disponibilité d’un
service dès le départ
 C’est le maillon faible de la chaîne qui détermine la disponibilité de celle-ci
Gestion de la disponibilité – Définitions
 Risque
 Tout événement qui pourrait causer du tort ou des pertes au service, ou
diminuer la capacité à atteindre les objectifs. Le risque se calcule comme
fonction d’une menace, de la vulnérabilité de ses composants à cette menace,
et de l’impact qu’aurait l’événement s’il se produit
Risque = Impact x probabilité
 Gestion de Risque
 Le processus responsable de l’identification, évaluation et contrôle des risques
 Evaluation de Risque
 Phase initiale de la Gestion de risques:
 Analyse de la valeur des actifs pour le business
 Identification des menaces planant sur les actifs
 Evaluation de la vulnérabilité des actifs
 Peut être qualitative ou quantitative
MTBSI : Mean Time Between Service Incidents
Définitions et calculs MTBF : Mean Time Between Failures
MTRS: Mean Time to Restore Service
 Disponibilité
(𝑡𝑒𝑚𝑝𝑠 𝑐𝑜𝑛𝑣𝑒𝑛𝑢 −𝑡𝑒𝑚𝑝𝑠 𝑑′ 𝑖𝑛𝑡𝑒𝑟𝑟𝑢𝑝𝑡𝑖𝑜𝑛)
 La capacité d’un service, = x 100
𝑇𝑒𝑚𝑝𝑠 𝑐𝑜𝑛𝑣𝑒𝑛𝑢
composant ou CI à remplir sa
fonction quand c’est exigé [%]

 Fiabilité 𝑡𝑒𝑚𝑝𝑠 𝑐𝑜𝑛𝑣𝑒𝑛𝑢


MTBSI (h) = 𝑁𝑜𝑚𝑏𝑟𝑒 𝑑𝑒 𝑝𝑎𝑛𝑛𝑒𝑠 [𝑛]
 Temps moyen de fonctionnement
sans interruption d’un service, (𝑡𝑒𝑚𝑝𝑠 𝑐𝑜𝑛𝑣𝑒𝑛𝑢 −𝑡𝑒𝑚𝑝𝑠 𝑑′ 𝑖𝑛𝑡𝑒𝑟𝑟𝑢𝑝𝑡𝑖𝑜𝑛)
MTBF (h) =
composant ou CI 𝑁𝑜𝑚𝑏𝑟𝑒 𝑑𝑒 𝑝𝑎𝑛𝑛𝑒𝑠 [𝑛]

 Facilité de Maintenance
σ(𝑡𝑒𝑚𝑝𝑠 𝑑′ 𝑖𝑛𝑡𝑒𝑟𝑟𝑢𝑝𝑡𝑖𝑜𝑛 𝑝𝑜𝑢𝑟 𝑛 𝑝𝑎𝑛𝑛𝑒𝑠)
MTRS (h) =
 Temps moyen de restauration d’un 𝑁𝑜𝑚𝑏𝑟𝑒 𝑑𝑒 𝑝𝑎𝑛𝑛𝑒𝑠 [𝑛]
service, composant ou CI
Gestion de la disponibilité – Définitions
 Serviçabilité (serviceability)
 La capacité d’un fournisseur tiers à satisfaire les termes de son contrat.
Habituellement, le contrat contient des niveaux de disponibilité, de
fiabilité et/ou de facilité de maintenance
 Résilience
 Capacité d’un élément de configuration (CI) ou d’un service
informatique à résister à une défaillance ou à avoir une reprise rapide
suite à une défaillance (Tolérance de panne)
Exercice
Un service 24/7 a fonctionné pendant une période de 5’020 heures avec 2
interruptions
Une première de 6h après 3’000 heures de fonctionnement
Une seconde de 14h après 2’000 heures de fonctionnement

3’000 h 6h 2’000 h 14h 20 h


Calculez
– La disponibilité globale
– La fiabilité en termes de MTBSI et MTBF
– La facilité de maintenance en termes de MTRS
Vital Business Function (VBF)
 Haute disponibilité
 Approche ou conception tendant à réduire (minimiser…) ou à cacher les effets d’une
défaillance d’un élément de configuration (CI) sur les utilisateurs d’un service des TI
(incidents: non tolérés, interruptions planifiées: tolérées)
 Tolérance aux pannes
 Capacité d’un service informatique, composant ou CI à continuer à fonctionner
correctement après une défaillance d’une partie d’un composant (incidents et
interruptions planifiées: tolérées)

 Exploitation continue
 Approche ou conception visant à éliminer les périodes d’indisponibilité planifiées d’un
service des TI (incidents: tolérés, interruptions planifiées: non tolérées)
 Disponibilité continue
 Approche ou conception visant à obtenir une disponibilité totale. Un service des TI à
disponibilité continue n’a pas de période d’indisponibilité, qu’elle soit planifiée ou non
(incidents et interruptions planifiées: non tolérés)
Source - Présentation : ITIL, LES FONDAMENTAUX Et pour L’ITSMF responsable de la commission patrimoine, éducation et normalisation Thierry CHAMFRAULT Bouygues Telecom
QUIZ
 Le but principal de la gestion de la disponibilité est :

a) Surveiller et établir des rapports sur la disponibilité des services et des composants
b) Assurer que toutes les cibles des accords sur les niveaux de services sont atteintes
c) Garantir les niveaux de disponibilité pour les services et les composants
d) Assurer que la disponibilité des services atteint ou dépasse les besoins validés du business
Conception des services
Principes
Processus
• Coordination de la conception (Design coordination)
• Gestion du Catalogue de Services (Service Catalogue Management)
• Gestion des niveaux de service (Service Level Management)
• Gestion de la capacité (Capacity Management)
• Gestion de la disponibilité (Availability Management)
• Gestion de la continuité (IT Service Continuity Management)
• Gestion de la sécurité de l’information (Information Security Management)
• Gestion des fournisseurs (Supplier Management)
Gestion de la continuité – Objet, But et Objectifs
 Objet
 Maintenir la capacité de restauration des services informatiques et de leurs
composants
 But
 Soutenir le processus global de gestion de la continuité business en
garantissant que les installations informatiques, tant du point de vue technique
que des services peuvent reprendre dans les délais requis et convenus avec le
business
 Périmètre
 Systèmes informatiques, réseaux, applications, bases et dépôts de données,
télécoms, environnement, support technique et centre de services
Gestion de la continuité – Objectifs
 Maintenir un ensemble de plans de continuité et de reprise des services
informatiques qui supportent les plans de continuité business (BCPs) de
l’organisation
 Conduire des exercices réguliers d’Analyse d’Impact Business (BIA)
 Conduire des exercices réguliers d’Analyse et gestion de risques
 Fournir conseil et information
 S’assurer que les mécanismes appropriés de continuité et restauration sont
en place
 Evaluer l’impact de tous les changements sur les plans de continuité et de
restauration des services informatiques
 Si le coût est justifié : Garantir l’implémentation de mesures proactives
pour améliorer la disponibilité des services
 Négocier et valider les contrats nécessaires avec les fournisseurs
Gestion de la continuité – Analyse d’impact Business (BIA)
 Objet
 Quantifier l’impact sur le business de la rupture ou perte de service
 Perte de réputation, perte financière, perte humaine

 Identifie
 La forme que le dommage ou la perte pourrait prendre
 Les conséquences d’une perte prolongée de service
 Le recrutement, les compétences, les installations et les services (services informatiques
inclus)
 Le temps de restauration
 La priorité relative de restauration pour le business

 Les objectifs de restauration business devraient s’exprimer en termes de :


 Délai de restauration d’une équipe prédéfinie d’employés clés et d’un minimum prédéfini
d’installations
 Le calendrier de restauration pour le reste des employés et installation
Gestion de la continuité – Analyse de Risques (RA)
 Objet
 Identifier la probabilité d’occurrence d’une catastrophe ou autre rupture
sévère de service
 Evaluation du niveau de menace et de la vulnérabilité de l’organisation à
cette menace

Actifs Menaces
Vulnérabilités

Analyse des risques


Risques
Gestion des risques

Contre-mesures
Conception des services
Principes
Processus
• Coordination de la conception (Design coordination)
• Gestion du Catalogue de Services (Service Catalogue Management)
• Gestion des niveaux de service (Service Level Management)
• Gestion de la capacité (Capacity Management)
• Gestion de la disponibilité (Availability Management)
• Gestion de la continuité (IT Service Continuity Management)
• Gestion de la sécurité de l’information (Information Security Management)
• Gestion des fournisseurs (Supplier Management)
Gestion de la sécurité de l’information – Information security management

 Information
 Terme général qui inclut banques, base de données, et métadonnées
 Politique de sécurité de l’information
 La politique qui gouverne l’approche sécurité de l’entreprise
 Système de gestion de la sécurité de l’information (SMIS)
 Le framework de politiques, processus, standards, recommandations et outils
assurant qu’une organisation atteigne ses objectifs de gestion de la sécurité de
l’information
Gestion de la sécurité de l’information – Information security management

 Objet
 Assurer que les risques relatifs à la sécurité de l’information sont gérés de
manière appropriée et que les ressources informatiques de l’entreprise sont
utilisées de manière responsable
 Fournir un focus sur tous les aspects de la sécurité informatique et gérer toutes
les activités de celle-ci
 But
 Aligner la sécurité informatique avec celle du business et assurer que la sécurité
de l’information est gérée efficacement pour tous les services et activités de
gestion des services
Gestion de la sécurité de l’information – Information security management

 Objectifs

 Protéger les intérêts de ceux qui dépendent de l’information et des systèmes qui
l’acheminent, des dommages résultants de pertes de disponibilité,
confidentialité et intégrité
 Pour la plupart des organisations, l’objectif de sécurité est atteint quand:
 La disponibilité: l’information est disponible et utilisable
 La confidentialité: seuls ceux qui ont le droit de la connaître ont accès
 L’intégrité: l’information est complète, exacte et protégée contre des
modifications non autorisées
 L’authenticité et la non-répudiation: les transactions business et les
informations échangées entre les entreprises, ou avec les fournisseurs, sont
dignes de confiance
…sont effectives
Gestion de la sécurité de l’information – Information security management

 Politique de sécurité informatique

 Doit se concentrer sur, et être motivée par une politique générale de sécurité de
l’information et un ensemble de politiques de sécurité spécifiques sous-jacentes
 Doit avoir le soutien inconditionnel de la direction informatique et idéalement le
soutien de la direction d’entreprise
 Doit couvrir tous les domaines de la sécurité (systèmes, apps, bâtiments)
 Doit être largement disponible à tous les clients et utilisateurs, et leur
conformité devrait être référencée dans tous les SLRs, SLAs, contrats et
accords. (Ucs et OLAs)
 Doit être passée en revue et, si nécessaire, révisée au moins annuellement
…les menaces et les risques évoluent vite
QUIZ
 La politique de sécurité de l’information devrait être disponible à quels
groupes d’individus ?

a) Les gestionnaires sénior du business et tout le personnel informatique


b) Les gestionnaires sénior du business, les dirigeants du SI et le gestionnaire de la sécurité
c) Tous les clients, les utilisateurs et le personnel informatique
d) Le personnel de gestion de la sécurité de l’information seulement
Conception des services
Principes
Processus
• Coordination de la conception (Design coordination)
• Gestion du Catalogue de Services (Service Catalogue Management)
• Gestion des niveaux de service (Service Level Management)
• Gestion de la capacité (Capacity Management)
• Gestion de la disponibilité (Availability Management)
• Gestion de la continuité (IT Service Continuity Management)
• Gestion de la sécurité de l’information (Information Security Management)
• Gestion des fournisseurs (Supplier Management)
Gestion des Fournisseurs – Supplier Management

 Objet
 Obtenir des fournisseurs un bon rapport qualité – prix et s’assurer que les
fournisseurs atteignent les cibles de performances spécifiées dans les contrats
et accords, tout en respectant tous les termes et conditions
 But du processus
 Gérer les fournisseurs et les services qu’ils fournissent, fournir au business des
services IT d’une qualité homogène, s’assurer que la valeur sur investissement
est obtenue (ROI)
Gestion des Fournisseurs – Supplier Management

 Objectifs

 Obtenir des fournisseurs un bon rapport qualité-prix


 S’assurer que les contrats de sous-traitances avec les fournisseurs soient alignés
sur les besoins business et qu’ils soutiennent les cibles convenues dans les SLRs
et SLAs, en accord avec le SLM (Service Level Management)
 Gérer les relations fournisseurs
 Gérer la performance des fournisseurs
 Négocier et signer des contrats avec les fournisseurs et les gérer à travers les
différentes étapes de leur cycle de vie
 Maintenir une politique de fournisseurs et le système d’information de la gestion
des fournisseurs et des contrats (SCMIS)

SCMIS : Supplier & Contract Management Information System


Débriefing - Réflexion - feedback

• Analyse de l’atelier
• Thèmes abordés
• Questions et remarques

• Prochain thème ->


Transition des Services
Bienvenue
Massimo D’Antonio – Spécialiste des systèmes de diffusion et responsable d’applications

Cours 614-1.6 ITIL


massimo.dantonio@he-arc.ch

https://www.linkedin.com/in/dantoniomassimo/

Support de cours (2021-2022) : cyberlearn


Contenu du cours

1. Introduction
2. Les principes de la gestion des Services
3. Stratégie des Services (Service Strategy)
4. Conception des Services (Service Design)
5. Transition des Services (Service Transition)
6. Exploitation des Services (Service Operation)
7. Amélioration continue des Services (Continual Service Improvement)
8. Différences entre ITIL V3 (2007 et 2011) et V4 (2019)
9. Révision - Examen
Transition des services
Principes
Processus
• Planification et support à la transition (Transition Planning and Support)
• Gestion des changements (Change Management)
• Gestion des actifs de services et des configurations (Service asset and configuration
management)
• Gestion des déploiements et des mises en production (Release & deployment
management)
• Gestion des connaissances (Knowledge management)
But & Objectifs
 Assurer une transition efficace des services dans l’environnement de production, en
collaboration avec toutes les parties prenantes
 Coordonner les activités autour des projets, des changements, des fournisseurs et des équipes
de support
 Gérer et planifier les ressources nécessaires au support opérationnel des services nouveaux
ou modifiés
 Contrôler que les activités de transition soient exécutées selon l’échéance, budget et niveau de
qualité exprimé par le client
 Assurer l’adoption de processus, systèmes et technologies standards et maitrisés afin
d’optimiser l’efficacité et l’efficience des activités de transition
 Identifier, gérer et contrôler les risques
 Suivre et améliorer la performance de la phase de transition
Périmètre
 Maintenir la politique, les standards et modèles soutenant les activités de transition
 Guider les efforts de transition au travers de tous les processus associés
 Gérer les conflits de ressources, échéances, scope
 Planifier et faire des projections sur les besoins futurs de ressources
 Revoir, mesurer et améliorer la performance des processus de transition
 Assurer que l’étape de transition soit alignée avec la gestion des projets et programmes qui s’y
réfèrent
 Produire les plans de transition et les transmettre à l’exploitation des services
 La coordination de la transition n’inclut pas :
 Responsabilité dans les activités des processus en dehors de la phase de transition
 Planification détaillée de la construction, test et déploiement des changements
Transition des services
Principes
Processus
• Planification et support à la transition (Transition Planning and Support)
• Gestion des changements (Change Management)
• Gestion des actifs de services et des configurations (Service asset and configuration
management)
• Gestion des déploiements et des mises en production (Release & deployment
management)
• Gestion des connaissances (Knowledge management)
Gestion des changements
 Des changements peuvent se produire pour différentes raisons
 Proactive: afin de réduire les coûts, améliorer le service ou l’efficacité
 Réactive: afin de résoudre des erreurs, s’adapter à un nouveau contexte, etc..

 On gère les changements pour:


 Optimiser l’exposition au risque
 Minimiser la sévérité de tout impact ou rupture
 Réussir du «premier coup»

Maintenir l’équilibre entre les besoins de changements et leurs impacts


Objet, but
 Objet
 Garantir l’utilisation de méthodes et procédures standards pour une prise en charge efficace et
rapide de tous les changements
 Tous les changements apportés aux actifs de service et CIs sont enregistrés dans le système de
gestion des configurations (CMS)
 Le risque business global est optimisé
 But
 Répondre à l’évolution des exigences business du client, tout en maximisant la valeur apportée
et en réduisant incidents, ruptures et corrections
 Répondre aux demandes de changements business et IT qui permettront d’aligner les services
et les besoins business
Objectifs
 Garantir que les changements sont
 Enregistrés et évalués

 Autorisés

 Planifiés

 Testés

 Implémentés

 Documentés

 Revus

Toujours de manière contrôlée


Périmètre
 Recouvre les modifications de l’intégralité des actifs et Cis (éléments de configuration)
sur l’ensemble de leur cycle de vie
 Doit être définit pour chaque organisation
 Le processus de changement des services IT est distinct de celui des services business
mais ils doivent cependant être interfacés
Définitions
 Demande de Changement (RFC: Request For Change)
 Proposition formelle pour faire un changement
 Changement
 L’ajout, la modification ou le retrait de tout ce qui peut avoir un effet sur les services informatiques (incluant
Cis, processus, documentation, …)
 Modèle de processus de changement
 Manière de prédéfinir les étapes à franchir pour exécuter un processus (type particulier de changement)
d’une manière approuvée
 Changement urgent
 Un changement devant être introduit dès que possible (procédure spécifique)
 Comité consultatif sur les changements (CAB: Change Advisory Board)
 Un groupe de personnes qui conseille le gestionnaire des changements pour l’évaluation, la priorisation et le
calendrier des changements
 ECAB (Emergency CAB) : Prend des décisions sur les changements urgents à fort impact
 Planification du retour en arrière
 Aucun changement ne devrait être approuvé sans avoir explicitement traité la question des actions à
entreprendre s’il échoue
Concept de base

initiateur
Demande de Demande de changement
changement (business) (informatique)

Lancement
RFC Centre de Services de projet

Processus de gestion des changements


• Politiques
• Aspects conception et planning
• Types de demandes de changements
• Modèles et workflow du processus de changement
• Changements standards
Types de changements
 Changement de Service
 L’ajout, modification ou retrait de services ou composants de services autorisés,
planifiés ou pris en charge, et de leur documentation associée
 Types de changement de service
 Changement normaux (pas urgent et pas standards)
 Ex: Changement de technologie de base de données (de oracle à SQL Server)
 Changements urgents
 Ex : Pour cause de faille de sécurité, il faut «patcher» le serveur SGBD
 Changements standards
 End of Life du support pour Oracle 10g (après 10 ans de service) , on
migre sur Oracle 11g
Activités du processus
 Créer et enregistrer la RFC
 Revoir la RFC et la proposition de changement
 Evaluer le changement (catégorisation de risque, évaluation, allocation des
priorités, planification et agenda, …)
 Autoriser le changement (validation par le CAB)
 Planifier les mises à jour
 Coordonner l’implémentation du changement
 Effectuer la revue (PIR) et clore le changement
 PIR = Post Implementation Review
Modèle et flux du processus de changement
 Un modèle de processus est une suite d’étapes prédéfinies à suivre pour gérer un
processus
 Il inclut
 Les étapes
 L’ordre chronologique
 Les responsabilités
 Des échelles de temps et des seuils
 Des procédures d’escalade
Changements standards (pré - autorisé)
 Changements apporté à un service ou une infrastructure, pour lequel l’approche est
préautorisée par la gestion des changements, qui fournit une procédure acceptée et
établie pour satisfaire une demande de changement spécifique (mise à jour de PC,
déplacement de machine de bureau, changement de routine, … )

 Déclencheur défini
 Les tâches sont connues, documentées et validées
 L’autorité effective est données par avance
 Le budget est pré-approuvé ou dans la marge de manœuvre du demandeur du
changement
 Le risque est habituellement faible et toujours bien compris

Certains changements standards seront déclenchés par le processus


d’exécution des requêtes, et directement enregistrés et transmis pour action
par le centre de services
Changement normal (exemple de flux)
Le Changement Urgent
 Uniquement réservé pour des changements devant réparer une erreur qui a
un fort impact négatif sur le business
 Géré par un comité consultatif sur les changements urgents (ECAB)
 Le test peut être réduit ou, dans des cas extrêmes, totalement supprimé
 La réalisation de la documentation peut être différée
La planification du rattrapage
 Plan de retour à l’état initial (Rollback Plan)
 Le recours au plan de continuité business peut s’avérer nécessaire

Aucun changement ne devrait être autorisé sans que la question de la procédure à


suivre en cas d’échec n’ait été traitée
Les 7 R de la gestion des changements
 Il faut répondre aux questions suivantes pour TOUS les changements
 C’est essentiel pour les évaluations d’impacts
1. Qui a REQUIS le changement RFC
2. Quelle est la RAISON du changement
3. Quel RETOUR est attendu du changement ?
4. Quels sont les RISQUES impliqués dans le changement ? CAB
5. Quelle est la RELATION entre ce changement et d’autres ?
6. Qui est RESPONSABLE pour la construction, le test et l’implémentation du
changement ?
7. Quelles RESSOURCES sont requise pour fournir le changement ?
CAB et ECAB
 CAB (comité consultatif sur les changements)
 Entité organisationnelle servant à soutenir l’autorisation des changements et à assister la
gestion des changements dans l’évaluation et la priorisation des changements

 ECAB (comité consultatif sur les changements urgents)


 Une entité organisationnelle réduite avec l’autorité de prendre des décisions urgentes
 Généralement Management, Business et IT prennent part à ce board
Catégorisation des Risques (exemple)

Matrice d’évaluation de sévérité d’un risque

Fort Impact Fort Impact


Faible Probabilité Forte Probabilité
Catégorie de risque : 2 Catégorie de risque : 1

Impact
Faible Impact Faible Impact
Faible Probabilité Forte Probabilité
Catégorie de risque : 4 Catégorie de risque : 3

Probabilité
Modèle d’autorisation de changement (exemple)
Si l’évaluation des changements détectes à un niveau 2,3 ou 4 des niveaux de risques plus élevés,
la demande d’autorisation est escaladée au niveau supérieur approprié

Communication Communication
Décisions Escalades Niveau de
Niveau
Autorité configuration
d’autorisation
impacté
Exécutif business Changement complexe,
1 coût et risques élevés

DSI Changement impactant


2 plusieurs fonctions /
dpts
CAB ou ECAB Changement impactant
3 des fonctions locales

Gestionnaire de Changement standard


4 changement ou
préautorisé
Question ?
 Lequel des exemples d’outils suivant pourraient soutenir l’étape de transition
des services du cycle de vie ?
1. Un outil pour sauvegarder des versions définitives de logiciels
2. Un outil de flux (workflow) pour gérer les changements
3. Un outil automatisé de distribution de logiciel
4. Les outils de test de validation

a) 1, 3 et 4 seulement
b) 1, 2 et 3 seulement
c) 2, 3 et 4 seulement
d) Toutes ces réponses
Question ?
 Quel est le rôle de l’ECAB ?
a) D’assister le gestionnaire des changements afin qu’aucun changement urgent
ne soit réalisé pendant les périodes où le business est particulièrement volatile
b) D’assister le gestionnaire des changements en implémentant les changements
urgents
c) D’assister le gestionnaire des changements dans l’évaluation des changements
urgents et de décider si le changement devrait être approuvé
d) D’assister le gestionnaire des changements pour accélérer le processus des
changements urgents afin qu’aucun retard inacceptable n’ait lieu
Question ?
 Quels types de changements ne sont généralement pas inclus dans le
périmètre de la gestion des changements ?
1. Les changements d’un ordinateur mainframe
2. Les changements d’opérations business
3. Les changements d’un accord sur les niveaux de service (SLA)
4. Le retrait d’un service
Question ?
 Lequel des énoncés suivants à propos d’un changement standard est
INCORECT ?
1. L’approche d’un changement standard est préautorisé par la gestion des
changements
2. Chaque changement standard est consenti par son autorité désignée
3. Les changements standards sont généralement de faible risque et bien
compris
4. Les changements standards ne sont demandés que par le processus
d’exécution des requêtes
Transition des services
Principes
Processus
• Planification et support à la transition (Transition Planning and Support)
• Gestion des changements (Change Management)
• Gestion des actifs de services et des configurations (Service asset and configuration
management)
• Gestion des déploiements et des mises en production (Release & deployment
management)
• Gestion des connaissances (Knowledge management)
Définitions
 Elément de Configuration (CI)
 Tout composant devant être géré afin de fournir un service informatique (Services
IT, matériel, logiciel, bâtiments, personnes, documentation, processus, SLAs, …)

 Base de données de configuration (CMDB)


 Base de données servant à rassembler les éléments de configuration tout au long
de leur cycle de vie, avec leurs attributs et leurs relations

 Configuration Management System (CMS)


 Une série d’outils et de bases de données, qui sont utilisés pour la gestion des
données de configuration d’un fournisseur de services IT
 Est composé d’une ou plusieurs CMDBs
Objet, But
 Objet
 Identifier, contrôler, enregistrer, auditer et vérifier les actifs de service et Cis avec
leurs attributs et relations
 S’assurer que seuls les composants autorisés sont utilisés et que seuls les
changements autorisés sont réalisés

 But
 Fournir les éléments d’information nécessaire à la construction et au maintien d’une
infrastructure stable et performante
 Soutenir des processus de gestion des services efficaces et efficients, en fournissant
une information de configuration exacte et précise, afin de permettre des prises de
décisions opportunes (autorisation de changements et déploiements, résolution
accélérée d’incidents et problèmes, …)
Objectifs
 Définir et contrôler les composants de services et l’infrastructure

 Maintenir une information de configuration exacte sur l’état actuel, passé et


planifié des services et de l’infrastructure

 Assurer l’intégrité des actifs et configurations requises pour contrôler les


services et l’infrastructure informatique en établissant et maintenant un CMS
complet et exact
Concepts de base
 Le CMS maintient toutes les relations entre les composants de services et tous
les objets associés : incidents, problèmes, erreurs connues, changements et
documentation de mise en production

 Le CMS peut aussi contenir des données d’entreprise sur les employés, les
fournisseurs, les unités business et leur localisation, les clients et les
utilisateurs

 CMDB (Base de données de configurations)

 Utilisée pour stocker les enregistrements des Cis tout au long de leur cycle de vie

 La Bibliothèque des supports définitifs (DML) = Definitive Media Library

 Stocke les versions autorisées de tous les CIs logiciels et documentaires

Le tout fait partie du SKMS


Question ?
 Lequel des éléments suivants seraient stockés dans la Bibliothèque des
supports définitifs (DML) ?
1. Des copies de logiciels achetés
2. Des copies de logiciels développés en interne
3. Les documents de licence pertinents
4. Le calendrier des changements

a) 1 et 2 seulement
b) 2, 3 et 4 seulement
c) 1, 2 et 3 seulement
d) Toutes ces réponses
Question ?
 Parmi les propositions suivantes laquelle est une activité du processus de
gestion des actifs et de configurations ?
1. Rendre des comptes pour tous les actifs financiers de l’organisation
2. Spécifier les attributs de chaque élément de configuration (CI)
3. Construire des modèles de service pour justifier les mises en place d’ITIL
4. Implémenter ITIL à travers l’organisation
Question ?
 Quel processus est responsable d’enregistrer les relations entre les composants
de services ?
1. La gestion des niveaux de services
2. La gestion du portefeuille de services
3. La gestion des actifs de services et des configurations (SACM)
SACM = Service Asset Configuration Manager

4. La gestion des incidents


Question ?
 Lesquels des éléments suivants ne seront PAS stockés dans la bibliothèque des
supports définitifs (DML)
1. Les copies de référence des logiciels
2. Les sauvegardes des données applicatives
3. Les licences logicielles
4. Les copies de référence de la documentation contrôlée
Bienvenue
Massimo D’Antonio – Spécialiste des systèmes de diffusion et responsable d’applications

Cours 614-1.6 ITIL


massimo.dantonio@he-arc.ch

https://www.linkedin.com/in/dantoniomassimo/

Support de cours (2021-2022) : cyberlearn


Contenu du cours

1. Introduction
2. Les principes de la gestion des Services
3. Stratégie des Services (Service Strategy)
4. Conception des Services (Service Design)
5. Transition des Services (Service Transition)
6. Exploitation des Services (Service Operation)
7. Amélioration continue des Services (Continual Service Improvement)
8. Différences entre ITIL V3 (2007 et 2011) et V4 (2019)
9. Révision - Examen
Transition des services
Principes
Processus
• Planification et support à la transition (Transition Planning and Support)
• Gestion des changements (Change Management)
• Gestion des actifs de services et des configurations (Service asset and configuration
management)
• Gestion des déploiements et des mises en production (Release & deployment
management)
• Gestion des connaissances (Knowledge management)
But
 Construire, tester et donner la capacité de fournir les services spécifiés par la phase de
conception afin de répondre aux besoins des parties prenantes et d’atteindre les objectifs
attendus
 Déployer des mises en production et mettre en œuvre une utilisation efficace du service,
fournissant de la valeur au client et permettant de passer la main à la phase d’exploitation des
services
Objectifs
 S’assurer que
 Les plans de déploiement et de mise en production sont clairs et complets, et qu’ils
permettent au client et aux projets de changement business de s’aligner
 Un package de mise en production peut être construit, installé, testé et déployé efficacement,
par un groupe de déploiement ou dans un environnement cible, avec succès et dans les
temps impartis
 Un service nouveau ou modifié – avec ses systèmes, sa technologie et son organisation – est
capable de remplir les besoins convenus, par ex : utilités, garanties et niveaux de service
 Les impacts imprévus sur les services en production, l’exploitation et le support sont
minimisés
 Les clients, les utilisateurs et le personnel de gestion des services sont satisfaits des pratiques
et productions de la transitions des services, par ex : la documentation utilisateurs et les
formations
Objet
 Définir et s’accorder avec les clients et les parties prenantes sur les plans de
déploiement et de mise en production
 S’assurer que chaque package de déploiement contient un ensemble d’actifs et
de composants de service liés entre eux et compatibles les uns avec les
autres
 S’assurer que l’intégrité d’un package de mise en production et ses
composants constitutifs soit maintenus tout au long des activités de transition,
et soit enregistrés correctement dans le CMS
 S’assurer que tous les packages de mise en production et déploiement soient
traçables, puissent être installés, testés, vérifiés, et/ou désinstallés si
nécessaire
 S’assurer que les changements sont gérés durant les phases de mise en
production et déploiement
Objet (suite)
 Enregistrer et gérer les déviations, risques, problèmes liés à des services
nouveaux ou modifiés, et prendre l’action corrective appropriée
 S’assurer du transfert de connaissances nécessaire pour permettre aux
clients et utilisateurs d’optimiser leur utilisation du service pour soutenir leurs
activités business
 S’assurer que les compétences et les connaissances sont transférées
vers les équipes d’exploitation et de support, afin qu’ils puissent fournir,
soutenir et maintenir efficacement le service selon les garanties et niveaux de
services requis
Concepts de base (1)
 Mise en production (Release)
 Ensemble de matériel, logiciel, documentation, processus ou autres composants requis
pour l’implémentation d’un ou plusieurs changements autorisés (de service IT). Le contenu
de chaque mise en production est géré, testé et déployé comme une seule et même
entité
 Unité de mise en production (Release Unit)
 La partie d’un service ou infrastructure informatique qui est normalement mise en
production en une fois, selon la politique de mise en production de l’organisation
 Package de mise en production (Release Package)
 Peut être constituée d’une seule unité ou d’un ensemble structuré d’unités misent en
production
Concepts de base (2)
 Mise en production majeure
 Contient normalement des portions importantes de fonctionnalités nouvelles, parmi
lesquelles certaines peuvent éliminer des correctifs temporaires de problèmes
 Mise en production mineure
 Contient normalement des améliorations mineures et des correctifs
 Mise en production d’urgence
 Contient normalement des corrections à un petit nombre d’erreurs connues, ou parfois une
amélioration destinée à satisfaire des besoins prioritaires du business
Politiques, principes et concepts de base
 Identification des unités de mise en production

 Option de conception et considérations de mise en production

 Conception des packages de mise en production

 Comprendre l’architecture concernée afin de pouvoir planifier, packager, construire et tester

 Considérer la chaîne complète d’éléments

 Modèles de mise en production et déploiement


Politique
Service Release Definition Naming/numbering Frequency/ Release Window
Occurrence
Store Service Type A SS_X Annual (feb) Wednesday 01:00 – 04:00 hours
Type B or C SS_1.x or SS_1.1.x Quarterly Not holiday weekends
Emergency SS_1.1.1.x As required Not 1 September to 31 January

E-Store Web service Type A ESWnnn_x 6 months 01:00-02:00 hours


Type B or C ESWnnn_1.x Monthly Not holiday weekends
Emergency ESWnnn_1.1.x As required Not 1 October to 10 January

E-Store Delivery service Type A ESDnnn_x 6 months 01:00-02:00 hours


Type B ESDnnn_1.x Quarterly Highest level of authorization required
Type C ESDnnn_1.1.x Monthly During holiday weekends
Emergency ESDnnn_1.1.1.x As required

Release Definition
Type A Something that impact the whole system/service
Type B A release that will impact part of the system, e.g. single sub-system of sub-service
Type C Correction to a single function
Emergency A change required to restore or continue service to ensure the SLA is maintained
Question ?
 Lesquels des éléments suivants sont des buts du processus de la gestion des
déploiements et des mise en production ?
1. S’assurer qu’il existe des plans clairs de mise en production et de déploiement
2. S’assurer que les clients sont satisfaits des pratiques et des sorties de la
transition des services
3. S’assurer quel impact imprévu sur les services en production, les opérations et
le support et minimisé
4. Fournir de la capacité informatique économiquement justifiée répondant aux
besoins du business
a) 1, 2 et 3 seulement
b) 1 et 3 seulement
c) Toutes ces réponses
d) 1,3 et 4 seulement
Transition des services
Principes
Processus
• Planification et support à la transition (Transition Planning and Support)
• Gestion des changements (Change Management)
• Gestion des actifs de services et des configurations (Service asset and configuration
management)
• Gestion des déploiements et des mises en production (Release & deployment
management)
• Gestion des connaissances (Knowledge management)
Objectifs
 Améliorer la qualité des décisions prises par le management en garantissant que des
connaissances fiables et sécurisées ainsi que des informations et données sont disponibles tout
au long du cycle de vie du service
 Rendre le fournisseur de service plus efficace et améliorer la qualité du service, accroitre la
satisfaction et réduire le coût du service en réduisant la charge de redécouverte des données
 S’assurer que le personnel a une compréhension claire et commune de la valeur que leur
service procure au client et la manière dont les bénéfices sont réalisés à travers l’utilisation de
ses services
 Maintenir un système de gestion des connaissances des services (SKMS) qui fourni un
accès contrôle aux connaissances, informations et données adaptés à tous les profils
 Recueillir, analyser, stocker, partager, utiliser et maintenir la connaissance, les informations et
données tout au long du cycle de vie de l’organisation du fournisseur de service
Périmètre
 La gestion de la connaissance est un processus global au cycle de vie
d’un service car il est utilisé toutes les phases du cycle ITIL
 La gestion de la connaissance inclut le suivi de la gestion des connaissances,
informations et données depuis lesquels la sagesse est dérivée
Méthode Data-to-Information-to-Knowledge-to Wisdom
structure (DIKW)
 Recueille des données exactes, identifie les données pertinentes, maintient l’intégrité
des données et archive et purge les données

Contexte

 Données: un ensemble de faits isolés


 Information: données contextualisées
Sagesse
 Connaissance: intègre l’expérience, les Pourquoi
idées et points de vue, les valeurs et
Connaissance
jugement des individus
Comment
 Sagesse: utilise la connaissance pour
Information
créer de la valeur à travers des décisions
Qui, quoi,
correctes et bien informées quand, où
Données
Compréhension
SKMS-Système de gestion des connaissances services

 Concept couvrant une large base de connaissances


 Le portfolio des services, le système de gestion des configurations (CMS), La librairie des médias définitifs
(DML), l’accord sur les niveaux de service (SLAs), les accords sur les niveaux opérationnels (OLAs), La politique
de sécurité de l’information, Le système de gestion des informations de contrats et de fournisseurs (SCMIS),
incluant les exigences, capacités et attentes des partenaires et fournisseurs

 Budgets
Système de gestion
 Modèles de coûts Support aux décisions
des connaissances
des services
 Business Plan Support au delivery des services

 Registre d’amélioration des services


Système de gestion des configurations (CMS)
 Plans d’amélioration des services
 Informations personnelles des utilisateurs et clients
pour supporter par exemple un utilisateur mal voyant
qui a besoin d’un support spécifique du service desk Base de données de gestion des
configurations
Question ?
 Lequel des énoncés suivants sur le rapport entre le système de gestion des
configurations (CMS) et le système de gestion des connaissances (SKMS) est
CORRECT ?

a) Le SKMS fait partie du CMS


b) Le CMS fait partie du SKMS
c) LE CMS et le SKMS sont identiques
d) Il n’y a aucun rapport entre le CMS et le SKMS
Débriefing - Réflexion - feedback

• Analyse de l’atelier
• Thèmes abordés
• Questions et remarques

• Prochain thème ->


Exploitation des services
Bienvenue
Massimo D’Antonio – Spécialiste des systèmes de diffusion et responsable d’applications

Cours 614-1.6 ITIL


massimo.dantonio@he-arc.ch

https://www.linkedin.com/in/dantoniomassimo/

Support de cours (2021-2022) : cyberlearn


Contenu du cours

1. Introduction
2. Les principes de la gestion des Services
3. Stratégie des Services (Service Strategy)
4. Conception des Services (Service Design)
5. Transition des Services (Service Transition)
6. Exploitation des Services (Service Operation)
7. Amélioration continue des Services (Continual Service Improvement)
8. Différences entre ITIL V3 (2007 et 2011) et V4 (2019)
9. Révision - Examen
Exploitation des services
Principes
Fonctions
• Centre de service (Service Desk)
• Gestion technique, gestion des applications, gestion des opérations IT
Processus
• Gestion des évènements (Event Management)
• Gestion des incidents (Incident Management)
• Exécution des requêtes (Request Fulfilment)
• Gestion des problèmes (Problem Management)
• Gestion des accès (Access Management)
Service IT versus composants technologiques

Vision business sur l’IT :


Ensemble de service IT

Vue interne IT:


Ensemble de composants technologiques
Service TI contre composants technologiques
 Voir l’IT comme un ensemble de services IT (vue externe du business) ou comme un
ensemble de composants technologiques (vue interne de l’informatique) ?
 La vue externe est la manière dont les services sont vus et vécus par les utilisateurs et les
clients
 La vue interne est la manière dont les composants et systèmes informatiques sont gérés pour
fournir les services

Les deux vues sont nécessaires pour fournir des services


Il faut trouver le juste équilibre
Services ou composants ?

Une organisation ici est


Une organisation ici est
déséquilibrée et en
équilibrée mais tend à
danger de ne pas
sous délivrer les
achever les besoins
besoins business
business

Focalisation interne Focalisation externe


extrême extrême

Ne pas tenir les Promettre et ne pas


attentes des clients tenir
Stabilité ou Agilité ?

Une organisation ici est


Une organisation ici est
déséquilibrée et en
équilibrée mais tend à
danger d’ignorer les
surinvestir dans des
changements des
changements
besoins business

Focalisation extrême Focalisation extrême


sur la stabilité sur la réactivité

«Ne pas voir» les Trop dépenser / trop


changements de changements
nécessaires au business
Qualité ou Coût ?

Une organisation ici est


Une organisation ici est
déséquilibrée et en
équilibrée mais tend à
danger de perdre la
surinvestir pour délivrer
qualité de ses services
des services qui vont
par un sous
au-delà du nécessaire
investissement

Focalisation extrême Focalisation extrême


sur les coûts sur la qualité

«Ne pas répondre» aux Trop dépenser pour


besoins nécessaires du des besoins
business secondaires ou
inutiles
Réactivité ou proactivité ?

Une organisation ici est


Une organisation ici est
équilibrée mais tend à
déséquilibrée et n’est
réparer des services qui
pas en capacité de
ne sont pas cassés
supporter la stratégie
engendrant un volume
business
supérieur de changement

Extrêmement réactif Extrêmement proactif

Support de la stratégie Changement de


business difficile services qui
fonctionnent
Exploitation des services
Principes
Fonctions
• Centre de service (Service Desk)
• Gestion technique, gestion des applications, gestion des opérations IT
Processus
• Gestion des évènements (Event Management)
• Gestion des incidents (Incident Management)
• Exécution des requêtes (Request Fulfilment)
• Gestion des problèmes (Problem Management)
• Gestion des accès (Access Management)
Objectifs
 Restaurer le service normal (SPOC = single point of contact)
 Pour les incidents connus
 Enregistrer (journaliser) tous les incidents/demandes de service détails pertinents, avec une
catégorie et une priorité
 Fournir un support de premier niveau
 Résoudre / escalader et fermer les incidents et les demandes de service
 Communiquer
 Réaliser des enquêtes de satisfaction
 Eventuellement mettre à jour le CMS sous la direction de la gestion des configurations
Rôles
 Améliorer le service, la perception et la satisfaction des clients
 SPOC (Single Point Of Contact)
 Meilleure qualité et solution de contournement plus rapide
 Améliorer le travail d’équipe et la communication
 Réduire l’impact des incidents
 Mieux gérer (contrôler) les incidents et les demandes de services
 Améliorer l’utilisation et la productivité
 Améliorer la qualité des informations fournies au management
Structure de la fonction

Service Desk

Technical Application IT Operations


3rd Party Support Request Fulfilment
Management Management Management
Structure de la fonction
Customer Site 2

Customer Site 1 Customer Site 3

Service Desk

Second Line Support

Technical Application IT Operations


3rd Party Support Request Fulfilment
Management Management Management
Structure de la fonction

London Service Desk

Paris Service Desk

Sydney Service Desk

Virtual Service Desk

SKMS

Rome Service Desk


Follow the sun
Débriefing - Réflexion - feedback

• Analyse de l’atelier
• Thèmes abordés
• Questions et remarques

• Prochain thème ->


Exploitation des services
Bienvenue
Massimo D’Antonio – Spécialiste des systèmes de diffusion et responsable d’applications

Cours 614-1.6 ITIL


massimo.dantonio@he-arc.ch

https://www.linkedin.com/in/dantoniomassimo/

Support de cours (2021-2022) : cyberlearn


Contenu du cours

1. Introduction
2. Les principes de la gestion des Services
3. Stratégie des Services (Service Strategy)
4. Conception des Services (Service Design)
5. Transition des Services (Service Transition)
6. Exploitation des Services (Service Operation)
7. Amélioration continue des Services (Continual Service Improvement)
8. Différences entre ITIL V3 (2007 et 2011) et V4 (2019)
9. Révision - Examen
Exploitation des services
Principes
Fonctions
• Centre de service (Service Desk)
• Gestion technique, gestion des applications, gestion des opérations IT
Processus
• Gestion des évènements (Event Management)
• Gestion des incidents (Incident Management)
• Exécution des requêtes (Request Fulfilment)
• Gestion des problèmes (Problem Management)
• Gestion des accès (Access Management)
Recouvrement organisationnel
Gestion des Opérations Informatiques

Centre de Gestion Gestion des


Services Contrôle des
Technique Applications
Opérations IT

Console
Management Financial
Mainframe Job Scheduling Apps
Backup and
Restore
Print and Output

Opérations Server HR Apps


Informatiques:
L’ensemble des activités Moyens
effectuées lors de l’exploitation généraux
Business
quotidienne de Network
Data Centers Apps
l’infrastructure informatique,
Recovery Sites
afin de fournir des services aux
Consolidation
niveaux convenus pour remplir Contracts
les objectifs business Storage

Database
Gestion Technique
 Objectifs
Planifier, implémenter et maintenir une infrastructure technique stable et répondant aux besoins business
 Organisationnel
Groupes, départements ou équipes qui fournissent une expertise technique sur un domaine particulier
 Rôle double
 Fournir une expertise technique / connaissances et une gestion générale de l’infrastructure IT
 S’assurer du niveau de formation et compétences des intervenants
 Support technique opérationnel
 Conseil stratégique, design, transition
 S’assurer que les ressources sont déployées efficacement durant les phases de conception,
construction, transition, exploitation et amélioration des services
Gestion des Applications
 Objectifs
Planifier, implémenter et maintenir les applications business répondant aux besoins client
 Organisationnel
Groupes, départements ou équipes impliqués dans la gestion et le support des applications opérationnelles
 Rôle double
 Fournir une expertise technique / connaissances et une gestion générale du parc applicatif
 S’assurer du niveau de formation et compétences des intervenants
 Support applicatif opérationnel
 Conseil stratégique, design, transition
 S’assurer que les ressources sont déployées efficacement durant les phases de conception,
construction, transition, exploitation et amélioration des services
Gestion des opérations informatiques
2 sous-fonctions
 Moyens généraux (Facilities Management)
 Contrôles des opérations (Operation Control)

Objectifs
 Activités opérationnelles au jour-le-jour : surveillance, vérification, résolution de
panne et amélioration

Organisationnel
 Fonction distincte, ou
 Fonction constituées partiellement du personnel de la gestion technique et applicative

Rôle Double
 Exécuter les activités en suivants les normes de performance définies
 S’adapter continuellement aux besoins et à la demande business
Question ?
 Les fonctions sont le MIEUX décrites comme…

a) Une structure de connaissance


b) Un système à boucle fermé
c) Des unités organisationnelles autonomes
d) Des projets se focalisant sur la transformation
Question ?
 Lequel des énoncés suivants à propos du centre de service est CORRECT ?

1) Le centre de service est une fonction qui permet la communication entre les TI
et ses utilisateurs pour toutes les questions opérationnelles
2) Le centre de service est toujours le propriétaire du processus de gestion des
incidents

a) 2 seulement
b) 1 seulement
c) Les deux
d) Aucun
Question ?
 Parmi les éléments suivants, auquel fait référence le terme «contrôle des
opérations informatiques» ?

a) La gestion des fonctions gestion technique et gestion des applications


b) Superviser l’exécution et la surveillance des activités répondant aux
évènements opérationnels
c) Un ensemble d’outils utilisés pour surveiller et afficher l’état de l’infrastructure
et des applications informatiques
d) Un centre de service surveillant l’état de l’infrastructure quand les opérateurs
ne sont pas disponibles
Exploitation des services
Principes
Fonctions
• Centre de service (Service Desk)
• Gestion technique, gestion des applications, gestion des opérations IT
Processus
• Gestion des évènements (Event Management)
• Gestion des incidents (Incident Management)
• Exécution des requêtes (Request Fulfilment)
• Gestion des problèmes (Problem Management)
• Gestion des accès (Access Management)
Définitions
Evènement
 Toute occurrence détectable ou discernable, ayant une signification pour la gestion de
l’infrastructure informatique ou la fourniture de services IT

Alerte
 Avertissement qu’un seuil (lié à un SLA) a été atteint, que quelque chose a changé, ou qu’une
panne s’est produite
 Notification d’une personne ou d’une équipe pour intervention humaine
Objectifs
 L’aptitude à détecter des événements, leur donner un sens et déterminer l’action de
contrôle appropriée est fournie par la gestion des événements, qui constitue la base
pour la surveillance et le contrôle opérationnel

 La gestion des événements fournit donc le point d’entrée pour l’exécution de


nombreux processus et activités d’exploitation des services

 Exemple: Détecter tout changement d’état significatif dans la gestion des CIs et service
IT
Politique/principes/concepts de base
 Il y a différents types d’événements:

 Information: signifie un fonctionnement normal

 Avertissement: fonctionnement inhabituel, mais pas exceptionnel

 Exception: fonctionnement anormal

 Qu’est-ce qui constitue un fonctionnement normal par rapport à inhabituel, ou à une


exception ?

 Perception utilisateur (Subjectif)

 (Non-) Respect des OLAs /SLAs

 Tout événement repose sur l’émission ou la réception d’un message d’un


certain type
Question ?
 Lequel des énoncés ci-dessous décrit le MIEUX l’objet de la gestion des
évènements ?

a) La capacité de détecter des évènements, les interpréter et déterminer l’action


de contrôle appropriée
b) La capacité d’implémenter les outils de surveillance
c) La capacité de surveiller et de contrôler les activités du personnel technique
d) La capacité de produire un rapport sur la fourniture réussie des services en
vérifiant le temps de fonctionnement des équipements d’infrastructure
Exploitation des services
Principes
Fonctions
• Centre de service (Service Desk)
• Gestion technique, gestion des applications, gestion des opérations IT
Processus
• Gestion des évènements (Event Management)
• Gestion des incidents (Incident Management)
• Exécution des requêtes (Request Fulfilment)
• Gestion des problèmes (Problem Management)
• Gestion des accès (Access Management)
Définition
 Incident

 Interruption non prévue ou non planifiée, ou réduction de la qualité d’un


service IT. La défaillance d’un élément de configuration
But
 Restaurer le fonctionnement normal du service aussi vite que possible en minimisant les
effets néfastes sur le business, assurant ainsi les meilleurs niveaux de disponibilité et de
qualité de services possibles

 Note: ‘fonctionnement normal du service’ signifie ‘fonctionnant dans les


limites fixées dans les SLAs’
Périmètre
 Tout événement qui interrompt, ou qui peut interrompre, un service

 Les incidents peuvent être également identifiés et/ou enregistrés par :

 La plateforme de surveillance

 Les utilisateurs

 Les équipes de support techniques et applicatives

Beaucoup d’incidents ne sont pas nouveaux !


Concept de base
 Délais de résolution
 Doivent être formalisés et acceptés pour toutes les étapes (en fonction de la priorité)
et basés sur les cibles fixées dans les SLAs / OLAs et UC
 Modèles d’incident
 Moyen de prédéfinir les étapes autorisées à suivre (pour un type particulier
d’Incident)
 Les étapes du traitement
 Les individus et équipes impliqués dans le traitement
 Les délais de résolution
 Les escalades

 Incident Majeur
 La plus haute catégorie d’impact pour un incident
 Provoque une interruption significative du business
 La définition de ce qui est considéré comme un incident majeur est à définir avec les
clients et à intégrer dans les système de codage
Activité
 Identification
 Enregistrement / journalisation
 Catégorisation
 Priorisation
 Diagnostic initial
 Escalade
 Fonctionnelle
 Hiérarchique

 Investigation & Diagnostic


 Résolution & Reprise
 Clôture
Catégorisation

Location Application
impacted impacted

Service Database
impacted impacted
OR
System Server
impacted impacted

Application Disk Drive


impacted impacted
Définition
 Impact
 Mesure de l’effet d’un incident sur les processus et services business
 Urgence
 Mesure de temps que met un incident à avoir un impact significatif sur le
business (définit le plus souvent dans les SLAs)
 Priorité
 Basé sur l’impact et l’urgence, et utilisé pour identifier les délais acceptables
pour réaliser des actions menant à la résolution de l’incident
Priorisation (exemple)
 Système de codage simple

Impact
Haut Moyen Bas
Haut 1 2 3
Urgence Moyen 2 3 4
Basse 3 4 5

Priorité Description Temps de


restauration
1 Critique 1 heure
2 Haute 8 heures
3 Moyen 24 heures
4 Basse 48 heures
5 Planifié Planifié
Question ?
 Laquelle des propositions suivantes est un bénéfice de l’utilisation d’un modèle
d’incident ?

a) Il rend les problèmes plus facilement identifiable et diagnosticable


b) Il signifie que les types d’incidents connus ne se reproduisent jamais
c) Il établit des étapes prédéfinies pour le traitement de certains types d’incidents
d) Il s’assure que tous les incidents sont faciles à résoudre
Question ?
 Parmi les séquences d’activités suivantes pour le traitement d’un incident,
laquelle est CORRECTE ?

a) Identification, journalisation, catégorisation, priorisation, diagnostic initial,


escalade fonctionnelle, investigation et diagnostics, résolution et reprise,
clôture
b) Identification, priorisation, journalisation, catégorisation, diagnostic initial,
escalade, investigation et diagnostic, résolution et reprise, clôture
c) Identification, journalisation, diagnostic initial, catégorisation, priorisation,
escalade fonctionnelle, investigation et diagnostic, résolution et reprise, clôture
d) Identification, investigation, journalisation, catégorisation, escalade
fonctionnelle, priorisation, diagnostic initial, résolution et reprise, clôture
Exploitation des services
Principes
Fonctions
• Centre de service (Service Desk)
• Gestion technique, gestion des applications, gestion des opérations IT
Processus
• Gestion des évènements (Event Management)
• Gestion des incidents (Incident Management)
• Exécution des requêtes (Request Fulfilment)
• Gestion des problèmes (Problem Management)
• Gestion des accès (Access Management)
Définition
 Demande de Service
 Une demande d’utilisateur pour de l’information, un conseil, un changement
simple ou pour l’accès à un Service IT
 Généralement traitée par le centre de services et ne nécessite pas la
soumission d’une RFC
 Qualifiée de «changements simples» - peu de risques, fréquents, faibles
coûts, préautorisés, etc…
Objectifs
 L’exécution des requêtes est le processus de traitement des demandes de
service en provenance des utilisateurs, qui:
 Fournit un canal de communication pour que les utilisateurs demandent et
bénéficient de services standards pour lesquels un processus prédéfini
d’approbation et de qualification existe
 Fournit de l’information aux utilisateurs et clients sur la disponibilité des
services et les procédures pour les obtenir
 Approvisionne et fournit les composants des services standards requis
(par ex. Licences et media logiciels)
 Fournit de l’assistance aux demandes d’informations générales, plaintes
ou commentaires
Politique/principes/ concepts de base
 Beaucoup de demandes de services sont récurrentes, de sorte qu’un processus
prédéfini (un modèle) peut être établi, avec les étapes d’exécution de la
requête, les individus ou groupes de support impliqués, les échéances et les
chemins d’escalade
 Les demandes de service sont généralement réalisées en implémentant un
changement standard
 Le centre de services est le propriétaire des demandes de service, et
surveille, escalade et souvent exécute la demande utilisateur
Modèles de demande
 Les étapes du traitement
 Les individus et équipes impliqués dans le traitement
 Des délais de livraison cibles
 Des escalades
Question ?
 Quel est l’objet du processus d’exécution des requêtes ?

a) Traiter les demandes de service des utilisateurs


b) Assurer l’exécution de toutes les requêtes provenant d’une organisation
informatique
c) Assurer l’exécution des demandes de changement
d) Assurer le respect de l’accord sur les Niveaux de Services (SLA)
Exploitation des services
Principes
Fonctions
• Centre de service (Service Desk)
• Gestion technique, gestion des applications, gestion des opérations IT
Processus
• Gestion des évènements (Event Management)
• Gestion des incidents (Incident Management)
• Exécution des requêtes (Request Fulfilment)
• Gestion des problèmes (Problem Management)
• Gestion des accès (Access Management)
Définitions
 Problème
 Cause inconnue d’un ou plusieurs incidents
 Solution de contournement
 Action ayant pour but de réduire ou éliminer l’impact d’un incident ou d’un
problème pour lequel une résolution complète n’est pas encore disponible
 Erreur connue
 Problème ayant une cause première et une solution de contournement
documentée
 Base de données des erreurs connues (KEDB = Know errors DB, inclus
dans le SKMS)
 Base de données contenant tous les enregistrements des erreurs connues.
Créée par la gestion des problèmes et utilisée par la gestion des incidents et
des problèmes
Objectifs
 La gestion des problèmes est le processus responsable de la gestion du
cycle de vie de tous les problèmes. Les objectifs principaux de la gestion des
problèmes sont:

 D’éviter l’apparition de problèmes et d’incidents résultants

 D’éliminer les incidents récurrents

 De minimiser l’impact d’incidents qui ne peuvent pas être évités


Concepts
 Modèles de problème

 Tout comme la création des enregistrements des erreurs connues dans la


KEDB pour assurer des diagnostiques plus rapides, il peut être utile de créer
des modèles de problème pour suivre des problèmes «dormants» ou sous-
jacents

 Les étapes du traitement


 Les individus et équipes impliqués dans le traitement
 Les délais de résolution
 Les escalades
Concepts
 La base de données des erreurs connues (KEDB), comme le CMS, fait partie du
système de gestion des connaissances des services (SKMS)

 La gestion réactive des problèmes fait généralement partie de l’exploitation


des services

 La gestion proactive des problèmes est initiée dans l’exploitation des services,
mais est généralement conduite dans le cadre de l’amélioration continue
des services
Question ?
 Un technicien utilise une technique prédéfinie afin de restaurer le service car
cet incident s’est déjà produit dans le passé. Ceci est un exemple de :

a) Une solution de contournement


b) Un changement standard
c) Une aptitude de service
d) Une alerte
Question ?
 Lequel/Lesquels des énoncés suivants sont corrects?
1. La gestion des problèmes peut soutenir le centre de services par la fourniture
des erreurs connues afin d’accélérer la résolution des incidents
2. La gestion des problèmes fournit de l’information à la gestion des niveaux de
service sur les impacts des changements

a) 1 seulement
b) 2 seulement
c) Tous
d) Aucun
Question ?
 Lequel/Lesquels des énoncés suivants sont corrects?
1. La gestion des problèmes peut soutenir le centre de services par la fourniture
des erreurs connues afin d’accélérer la résolution des incidents
2. La gestion des problèmes fournit de l’information à la gestion des niveaux de
service sur les impacts des changements

a) 1 seulement
b) 2 seulement
c) Tous
d) Aucun
Question ?
 Laquelle ou lesquelles des propositions suivantes sont correctes ?
1. La gestion des problèmes s’assure que toutes résolutions et solutions de
contournement nécessitant un changement d’un élément de configuration (CI)
sont soumis à la gestion des changements
2. La gestion des problèmes fournit à la gestion financière de l’information de
gestion sur le coût de résolution et de prévention des problèmes

a) 1 seulement
b) 2 seulement
c) Les 2
d) Aucune
Question ?
 Laquelle ou lesquelles des propositions suivantes sont correctes ?
1. La gestion des problèmes s’assure que toutes résolutions et solutions de
contournement nécessitant un changement d’un élément de configuration (CI)
sont soumis à la gestion des changements
2. La gestion des problèmes fournit à la gestion financière de l’information de
gestion sur le coût de résolution et de prévention des problèmes

a) 1 seulement
b) 2 seulement
c) Les 2
d) Aucune
Question ?
 Lequel des énoncés suivants est la MEILLEURE action à entreprendre
lorsqu’une solution de contournement pour un problème est trouvée?

a) L’enregistrement du problème est fermé


b) L’enregistrement du problème reste ouvert et les détails de la solution de
contournement y sont documentés
c) L’enregistrement du problème reste ouvert et les détails de la solution de
contournement sont documentés dans tous les enregistrements des incidents
liés
d) L’enregistrement du problème reste ouvert et les détails de la solution de
contournement sont documentés dans une Demande de Changement (RFC)

examen
Exploitation des services
Principes
Fonctions
• Centre de service (Service Desk)
• Gestion technique, gestion des applications, gestion des opérations IT
Processus
• Gestion des évènements (Event Management)
• Gestion des incidents (Incident Management)
• Exécution des requêtes (Request Fulfilment)
• Gestion des problèmes (Problem Management)
• Gestion des accès (Access Management)
Objectifs
 La gestion des accès est le processus qui consiste à accorder aux
utilisateurs autorisés le droit d’utiliser un service, tout en empêchant l’accès
aux utilisateurs non-autorisés

 Parfois appelé gestion des droits ou gestion des identités

 La gestion des accès donne aux utilisateurs le droit et la possibilité d’utiliser un


service ou un groupe de services. Elle est donc la réalisation concrète des
politiques et actions définies dans la gestion de la sécurité et de la
disponibilité
Politique/principes/concept de base
 Accès

 Niveau et étendue des fonctionnalités ou données d’un service qu’un


utilisateur est en droit d’utiliser

 Identité

 Information qui distingue un utilisateur en tant qu’individu, par laquelle on


peut vérifier son statut au sein de l’organisation. Par définition, chaque
utilisateur est défini de manière unique par son identité

 Droits (aussi appelés privilèges)

 Paramètres qui déterminent les droits d’accès d’un utilisateur à un service


ou à un groupe de services. Parmi les droits typiques, on trouve lire, écrire,
exécuter, changer, supprimer
Politique/principes/concept de base
 Services ou groupes de services

 La plupart des utilisateurs ont accès à plus d’un service, et des utilisateurs
ayant des activités similaires utilisent un ensemble de services similaires. Il
est plus efficace de donner accès à un utilisateur ou à un groupe
d’utilisateurs à l’ensemble des services qu’ils sont autorisés à utiliser
simultanément

 Services d’annuaire (directory service)

 Outil dédié utilisé pour gérer droit et accès


Question ?
 Lesquels des concepts de base suivants font partie de la gestion des accès ?

a) Vérifier l’identité des utilisateurs qui demandent l’accès à des services


b) Attribuer les droits d’accès aux systèmes afin de permettre l’accès aux
utilisateurs autorisés
c) Définir les politiques de sécurité pour l’accès aux systèmes
d) Surveiller la disponibilité des systèmes auxquels les utilisateurs devraient avoir
accès
1) 2 et 4 seulement
2) 1 et 3 seulement
3) 2 et 3 seulement
4) 1 et 2 seulement
Question ?
 Lesquels des objectifs suivants n’est PAS un objectif de l’exploitation de
services?

a) Entreprendre des tests afin de s’assurer que les services sont conçus pour
répondre aux besoins business
b) Fournir et gérer les services informatiques
c) Gérer la technologie utilisée pour fournir les services
d) Surveiller la performance de la technologie et des processus
Débriefing - Réflexion - feedback

• Analyse de l’atelier
• Thèmes abordés
• Questions et remarques

• Prochain thème ->


Amélioration continue des
services

Vous aimerez peut-être aussi