introduction a itil

Département de génie logiciel et des TI
Systèmes d’information dans
les entreprises (MTI515)
Chargé: JF Couturier
Cours 11
MTI515 Automne 2013 JF Couturier 1

Retour sur le dernier cours
 Différentes normes et cadriciels
 Plan directeur
 Architecture d’entreprise
 Audit et gestion des services
 Méthodologie de développement
 Gestion des applications
 Gestion de la maintenance

Plan
 Définition d’ITIL v3
 Service Management
 Phase Service Strategy
 Phase Service Design
 Phase Service Transition
 Phase Service Operation
 Phase Continual Service Improvement

Sources ITIL
 Ce cours est inspiré du document
An Introductory Overview of ITIL V3
De l’itSMF (IT Service Management Forum)
 Également le livre
Introduction to ITIL,
ITIL v3 Foundations Certification Training
disponible sur le site de ITPro.

Des ressources disponibles
 http://www.bestpracticelive.com/
 Il y a des livres portant sur ITIL dans la
librairie en ligne ITPro (24X24)
 Lien vers ITPro
 Site de la bibliothèque
 Recherche à la bibliothèque sur ITIL
 Un wiki ITIL
 Des checklists

ITIL
 ITIL pour
 Information Technology Infrastructure Library
 Ensemble de bonnes pratiques pour la
gestion des services TI d’une
organisation.
 Pas vraiment un standard, mais plutôt
des directives (guidances)

ITIL
 Produit par l’office britannique du commerce (OGC)
 Non-propriétaire
 En est à la version 3
 Est maintenant regroupé dans 5 livres (phases)
 Service Strategy (SS)
 Service Design (SD)
 Service Transition (ST)
 Service Operation (SO)
 Continual Service Improvement (CSI)

Philosophie
 Reconnaît que les TI sont étroitement liées à l’organisation et
que l’une ne va pas sans l’autre
 Propose une structure basée sur les processus à adapter à
n’importe quelle organisation (petite ou grande) et à toute
technologie
 Définit les services TI conformément aux attentes des
utilisateurs et des clients, basées sur un ensemble de
processus cohésif
 Identifie la manière la plus efficace d’utiliser les RH et la
technologie nécessaires pour exécuter les processus et pour
livrer les services attendus
Quality7, 1er mai 2009

Rappel
 “Les meilleures pratiques” sont des
activités ou des procédés éprouvés qui
ont été utilisés avec succès par
plusieurs organisations et qui sont
basées sur des procédures
reproductibles qui ont fait leurs preuves
au fil du temps pour un grand nombre
de personnes.

Définition d’un service
 Un service fourni à un ou plusieurs clients, par un fournisseur
de services IT. Un service TI est basé sur l'utilisation des
technologies de l'information et soutient les processus
d'affaires du client.
 Un Service est constitué d'une combinaison de personnes, de
processus et de technologie et doit être défini dans un accord
de niveau de service (SLA).
 IT Service (ITILv2): Un ensemble d'éléments connexes
fournis à l'appui d'un ou de plusieurs processus d'affaires. Le
service comprend une série d'éléments de configuration (CI),
mais sera perçu par les clients et les utilisateurs comme une
entité indépendante, unique et cohérente.

Rappel : Processus d’affaires
 Un processus d’affaires possède
certaines caractéristiques
 Mesurable- Nous devons être capables de mesurer le processus.
La performance du processus est d’une importance capitale. Les gestionnaires
voudront mesurer les coûts et la qualité. Les gens impliqués dans l’exécution des
processus seront intéressés par le temps requis ainsi que par le niveau de
difficulté.
 Résultats spécifiques – La raison d’être d’un processus est de produire un
résultat spécifique. Ce résultat doit être identifiable et quantifiable.
 Clients – Tout processus fournit son résultat à un client ou à un intervenant; Ils
peuvent être internes ou externes à l’organisation et le processus doit répondre à
leurs attentes.
 Répondre à un évènement spécifique – Même si un processus est continu ou
itératif, il doit être associé à un évènement déclencheur spécifique.

Pourquoi utiliser ITIL
 En tant que professionnel TI, avez-
vous des responsabilités identiques à
celles de l’ingénieur logiciel?
 Gérer les opérations?
 Associer les applications avec
l’infrastructure?
 Assurer le service aux clients?

Étude de cas pour cette
séance
 Une organisation doit se doter d’un système de reporting pour
répondre aux différents besoins d’affaires
 Présenter des informations provenant de sources diverses et
hétérogènes
 Acquérir / Maintenir l’infrastructure nécessaire
 Produire des rapports
 Publier des rapports sur le Web
 Produire et expédier des factures
 Créer des tableaux de bord (Decision Support System, BI)
 Maintenir ces rapports à jour
 Gérer les accès et les droits
 Former les utilisateurs

Diagramme d’ITIL V3

Cadre de référence ITIL
Amélioration continue des services
Technique Affaire
SKMS
Catalogues
de services
10%
10%
30%
30%
20%
Conception des services
SKMS
AMIS
Plan de
disponibilité
Plan de
capacité
SKMS
CMIS
Politiques de
sécurité
SKMS
ISMS
Gestion du risque
Gouvernance
Gestion du
catalogue de
services
Définition
Maintien
Publication
et mise à jour
Politiques
Portée
Gestion des
niveaux de
services
Planification
Production des SLA
Revue et mise à jour
des OLA (et UC)
Capture des requis
de niveaux de
service
Maintien du
catalogue Disponibilité
projetée de
service
Plan de
continuité
SLA
Description
Service
SLA
Soutien
Signature
Heures
Durée
SLA
Gestion de la
sécurité de
l’information
Définition des
politiques
Analyse
Surveillance
Implémentation
Stratégie des services
Gestion financière
des TI
Évaluation des
services
Retour sur
l’investissement
(ROI-VOI)
Facturation
Financement
Gestion du
portefeuille de
services
Définition
Mise en charte
Autorisation
Analyse
Gestion de la
demande
Activités et
comportements des
affaires
Organisation et grille de
responsabilité (RACI)
SKMS
Portefeuille
de services
Plans
financiers
Exploitation des services
Gestion des
incidents
Identification et
consignation
Résolution et
rétablissement
Diagnostic
Priorisation
Catégorisation
Fermeture
Libre-service
Centre de services
Modèles de
requêtes
Proposition
d’amélioration
de service
Traitement des
requêtes
Consignation de la
requête
Fermeture
Traitement
Automatisation du
flux de tâches
Modélisation
Gestion des
problèmes
Détection et
consignation
Résolution
Analyse et
diagnostic
Priorisation
Catégorisation
Fermeture
Revue
Gestion des
fournisseurs
Stratégies
Performance
Contrat
Évaluation
Politiques
Gestion de la
disponibilité
Requis
Rapports
Surveillance
Implémentation
Planification
Gestion de la
capacité
Surveillance et
ajustements
Maintien
Planification
Nouveaux requis
Amélioration
Gestion de la
continuité des
services TI
Analyse d’impact
d’affaires
Implémentation
Planification
Stratégies
Requis
Test, revue et
maintien
Déclenchement
Sondage de
satisfaction des
utilisateurs
Gestion des accès
Consignation de la
requête
Maintenir les
groupes et rôles
Retirer-restreindre
les droits d’accès
Fournir les droits
d’accès
Vérification de la
requête
Gestion des
événements
Conception
modélisation des
événements
Révision
Réponse et
fermeture
Surveillance des
systèmes
Configuration des
systèmes
Modèle de
requêtes
Rôles et
groupes
SKMS
Gestion des
changements
Consignation et
catégorisation
Mesures et rapports
Calendrier des
changements
Planification et
contrôle
Évaluation et
autorisation
Revue de post-
implémentation
Changements
urgents
Gestion des actifs
et des
configurations
Planification et
identification
Maintien
Vérification et Audit
Rapport d’état
Contrôle
Gestion des licences
Transition des services
Bon de
travail
Bon de
travail
CAB
Gestion de la
connaissance des
services
Consignation et
approbation
Surveillance
Gestion des mises en
production et
déploiements
Planification
Exécution du
déploiement,
transfert, retrait
Tests et pilotes
Cycles de
construction et de
tests
Préparation
Soutien de début de
vie
Revue de la mise en
production
Librairie
des médias
définitifs
CMDB’s
CMS
SKMS
Pièces de
rechange
et actifs
Plan de
validation et
de tests
Plans de
déploiement
Descriptifs
des mises en
productions
Gestion des
correctifs
Événements
et alertes
Demandes
de service
SKMS
Enregistrements
de problèmes
Enregistrements
d’erreurs
connues
Enregistrements
d’incidents
SKMS
1
1
Planification du
déploiement
Validation du
service et tests
Assurance qualité et
service
Évaluation
Planification de
l’évaluation
Stratégies de tests
Politiques de tests
Niveaux de tests et
modèles de tests
Approche de tests et
techniques
Effets attendus et
inattendus du
changement
Évaluation de la
performance
attendue
Évaluation de la
performance réelle
Gestion du risque
Plan de tests et
résultats
Calendrier des
changements
Lun
27
Mar
28
Revue de processus et
conformité
Revue de valeur et du
ROI
Stratégie et plans de
communication
Rapports d’informations de gestion
et de tendances
Rapport sur les services
Sondages de
satisfaction des clients
Implémentation du plan
de correction
Revue de services et
planification des améliorations
Génération de la stratégie
Création de valeur Actifs stratégiques
Développement de
l’offre
Définition du marché Approvisionnement
de service
Préparation pour
l’exécution
Outils de
découverte
Planification et soutien de la transition
Stratégie de
transition
Préparation de
la transition
Planification et coordination
de la transition
Soutien
2
2
Mesure des servicesProcessus d’amélioration en 7 étapes
SKMS
SLA
Rapports de
performance
Contrôle
Soutien initial
Qualiti7

IT Service Management
 Ensemble de fonctions
organisationnelles spécialisées
fournissant de la valeur au client sous
forme de services
 Processus d’affaires
 Rôles et activités
 Fonctions d’affaires
 Tout élément constituant le service

Définitions et exemples
 Fonction
 Le Service Desk est spécialisé dans la saisie
des incidents, c’est une fonction d’affaires.
 Processus d’affaires
 Saisir un incident dans le système.
 Activité - Tâche
 Définir la priorité de l’incident
 Rôle
 IT Support

Objectifs de Service Strategy
 Quels services devraient être
offerts?
 À qui les services devraient être
offerts?
 Comment les marchés interne et
externe devraient orienter le
développement de leurs services?
 La compétition, existante ou
potentielle, dans ces marchés et les
objectifs qui vont différencier la
valeur de ce que vous faites, ou
comment vous le faites
 Comment le client(s) et les
intervenants vont percevoir et
mesurer la valeur d’un service, et
comment cette valeur va être créée?
 Comment les clients vont orienter
ses choix d’impartition selon les
différents types de fournisseurs de
services?
 Comment la visibilité et le contrôle
de création de valeur se feront par la
gestion financière?
 Robustesse des « business case »
pour garantir un investissement
stratégique des services et dans la
gestion de la capacité des services
 Comment sera ajustée l’allocation
des ressources pour une gestion
optimale du portefeuille de service?
 Comment sera mesurée la
performance des services?

Les 4 « P » de la stratégie
 La stratégie implique une préparation et une
planification efficace des 4 P
1. Perspective – Vision et direction
2. Position – La situation actuelle
3. Plan – Comment réaliser la vision
4. Pattern – La façon de faire les choses,
décisions et actions à travers le temps

Service Strategy
 Le client n’achète pas un produit, il tente de
combler des besoins d’affaires.
 Valeur du service
 Utile - les fonctionnalités offertes par un produit ou un service du
point de vue du client (Qu'est-ce que le client obtient / aptitude à
l'emploi)
 Garantie - Garantie qu'un produit ou service sera conforme aux
exigences (Comment il est livré / aptitude à l'emploi)
 Création d’un SLA

Identification des
fournisseurs de service
 Type de fournisseur de services:
 Type I: Fournisseur interne qui délivre un
service à une unité d’affaires spécifique.
 Type II: Fournisseur interne qui délivre un
service à plusieurs unités d’affaires. (services
partagés)
 Type III: Fournisseur de service externe
desservant une multitude de clients externes.

Prestation de service
 Modèles de prestation de services
1. Service géré: Une unité d’affaires payant pour la
prestation d’un service et en être le seul bénéficiaire.
2. Service partagé: Prestation de service pour un grand
nombre d’unités d’affaires par le biais d’une infrastructure
et des ressources partagée.
3. Utilité: La prestation du service est offerte sur la base du
besoin de chaque client; Combien le client en veut-il?
Quand le client le veut-il?
 Exemples?
 Courriel, stockage, hébergement, serveur Web, serveur
d’authentification…

Processus et activités
 Définir le marché
 Pour qui?
 Développer l’offre
 Quoi?
 Préparer l’exécution
 Comment?

Processus et activités
 Assurer la gestion financière
 Financer, budgétiser, facturer (comment,
à qui?)
 Gérer la demande
 Comprendre la demande du client
 Analyser les activités d’affaires et le profil
des utilisateurs

Conclusion SS
Qualiti7

L’étude de cas
 Que faire dans la phase SS dans le
cadre du projet de reporting?
 Quel type de prestation de service?
 Géré, partagé, utilité?
 Qu’est-ce que la phase de stratégie
nous permet d’éviter comme
problèmes?

L’étude de cas
 Identifier le « qui »
 Comptabilité
 Gestion de projet
 Identifier le « quoi »
 BI, Facture, DSS
 Identifier le « comment »
 Acheter, Développer, Sous-traiter

Service Design
 Objectif
 La conception (design) de services TI, incluant
l’architecture, les processus, les règles et la
documentation, afin de combler les exigences
d’affaires courantes et futures

Les 4 « P » de la conception
 La mise en œuvre d’ITIL implique une
préparation et une planification efficace des
4 P de la conception
1. People – Les gens et leurs compétences
2. Products – La technologie
3. Processes – Les processus, rôles et activités
4. Partners – Vendeurs, manufacturiers et
fournisseurs

Service Design
 Valeur ajoutée
 L’amélioration des performances d’un service est réalisée
en intégrant les aspects de capacité et de disponibilité, de
la finance ainsi que de la continuité de service.
 Compréhension des impacts d’un nouveau service (ou
d’un changement) avant sa mise en production
 Une meilleure conception permet de
 Réduire le TCO
 Améliorer la qualité et l’uniformité du service
 Permettre un alignement et des performances adéquats
 Offre des processus IT efficaces

Aspects de la phase de design
 Est-ce un nouveau service ou l’amélioration d’un service
existant?
 Nouveau développement ou amélioration?
 Revoir le plan d’architecture technologique
 Revoir les processus, les rôles, les fonctions et la
capacité
 Identifier les méthodes de mesures et les métriques qui
permettront d’évaluer le service

Processus clefs
 Service Catalogue Management (SCM)
 Mettre à jour le catalogue de service
 Service Level Management (SLM)
 Mettre à jour les ententes de service
 Gestion de la capacité
 Évaluer la performance nécessaire
 Gestion de la disponibilité
 IT Service Continuity Management (ITSCM)
 Analyser les risques, identifier les besoins en continuité
 Information Security Management (ISM)
 S’assurer d’avoir une information disponible, utile, complète et fiable
 Gestion des fournisseurs

Activités liées à la conception
 Obtenir des exigences d’affaires
identifiées et documentées
 Concevoir et développer la solution
 Gérer le risque
 Revoir les processus de conception

Livrables de SD
 Politiques de sécurité du service
 Plan de continuité
 Plan de disponibilité
 Plan de capacité
 SLA

Qualiti7

L’étude de cas
 Que fait-on dans la phase de
conception?
 Que faire dans la phase « SD » dans
le cadre du projet de reporting?
 Qu’est-ce que la phase de conception
problèmes?

L’étude de cas
 C’est un nouveau service
 Certains éléments sont achetés
 Serveur, BD SQL, licences
 D’autres sont développés
 Les rapports
 Disponibilité minimale; 10 licences concurrentes pour 100
employés; risque limité sauf pour la facturation
 Mise à jour de notre architecture, de notre portfolio
 Ententes de service avec les départements impliqués

Service Transition
 Objectif
 Le rôle de la phase Service Transition est la livraison des
services exigés dans un mode opérationnel. C’est la mise en
production. Très similaire à l’esprit de la phase de transition de
RUP pour le logiciel.
 Service Transition reçoit un Service Design Package en
provenance du Service Design et transfert tous les éléments
nécessaires à son fonctionnement et à son support.
 Si les circonstances d'affaires, les hypothèses ou les exigences
ont changé depuis le design, alors des modifications peuvent
être faites au cours de la phase de transition afin d'offrir le
service requis.

Valeur ajoutée
 Amélioration du taux de réussite des changements et des
livraisons pour les entreprises
 Confiance dans le degré de conformité avec les exigences
d'affaires et la gouvernance au cours du changement
 La capacité à s'adapter rapidement aux nouvelles exigences
 Gestion des fusions, des défusions, des acquisitions, du
transfert de services
 Prédictions des niveaux de service et les garanties pour les
nouveaux / modifiés services

Concepts clefs
 Comprendre tous les services, leurs
utilités et leurs garanties.
 Établir une politique formelle et un
cadre pour l’implémentation de tout
changement.
 Anticiper et gérer les corrections
 Assurer l’évolution

Processus clefs et Activités
 Planifier et supporter la transition
 Ressources disponibles
 Gérer le changement
 Gérer les actifs et la configuration
 Livrer et déployer
 Valider et tester
 Évaluer le déploiement
 Parfois juste un petit coucou…
 Gérer les connaissances (Knowledge Management)
 Qu’est-ce qui est arrivé? Documenter…

Qualiti7

L’étude de cas
 Que faire dans la phase « ST » pour le
projet de reporting?
 Qu’est-ce que la phase de transition
problèmes?

L’étude de cas
 Préparer le déploiement
 Avertir les utilisateurs
 Former les utilisateurs
 Expliquer les limites, les contraintes
 Déployer
 Tester
 Évaluer le déploiement

L’étude de cas
 Sans gestion de la transition…
 Mauvais déploiement
 Pleins de bogues
 Des clients furieux
 Des utilisateurs perdus
 Des services en production qui tombent en panne
 Des complications, car il y a également une autre mise en
production la semaine suivante
 Un grand nombre d’appels de service
 Un échec…

Service Operation
 Objectif
 L’objectif de Service Operation est d’assurer le niveau de
service adéquat aux clients, et de gérer les applications,
la technologie et l’infrastructure qui supportent le
fonctionnement du service.
 C’est uniquement pendant cette phase du cycle de vie
que le service apporte une valeur et c’est la responsabilité
de l’équipe des opérations de s’assurer que cette valeur
est bel et bien livré

Objectifs contradictoires
 Vue interne (Les TI comme un ensemble de
composantes technologiques) VS vue externe (Les
TI comme un groupe de services)
 la stabilité vs la réactivité
 QoS vs Coût du service
 Réactif (Éteindre les feux) VS Proactif.

Valeur ajoutée
 "C’est dans la phase Service Operation que l’on voit la valeur."
 La valeur du service est modélisée dans Service Strategy.
 Le coût du service est élaboré, prédit et validé dans Service
Design et Service Transition.
 Les mesures d’optimisation sont identifiées dans Continual
Service Improvement (voir plus loin).
 Mais SO est la phase où la valeur est enfin réalisée!
 Jusqu’à la livraison du service, il n’y a pas de valeur de créée
 Les Services fonctionnent dans les budgets et les prévisions de ROI
 Erreurs de conception fixer et exigences manquantes corrigées
 Gains d'efficacité réalisés
 Optimisation des services

Processus clefs et activités
 Event Management Process
 Incident Management Process
 Request Fulfillment Process
 Access Management Process
 Problem Management Process

Event Management Process
 Un évènement est toute occurrence détectable ou
discernable qui a un impact significatif sur l’infrastructure
ou la livraison du service.
 Pas nécessairement un souci
 Une alerte est un avertissement qu’un seuil a été atteint,
que quelque chose a changé où qu’une défaillance se
soit produite.
 Information – Opération régulière
 Warning – Non usuel, mais pas exceptionnel
 Exception – Requiert une intervention

Incident Management Process
 Un Incident est:
 Une interruption non planifiée du service
ou une réduction dans la qualité du
service.
 La défaillance d'un élément de
configuration qui n'a pas encore eu un
impact sur un service est aussi un
incident, par exemple, la défaillance d'un
disque dans un raid miroir.

Incident management

Incident majeur
Un incident majeur est le
résultat d’une interruption
significative des activités
d’affaires.
Des procédures spéciales
doivent être prises pour
s’assurer que toutes les
ressources sont disponibles
pour résoudre l’incident
rapidement.
C’est l’organisation qui
définit ce qui constitue un
incident majeur.

Exemples de métriques
 Nombre d’incidents
 Répartition par niveau (1, 2, 3)
 Retard ou délais dans la résolution d’un incident
 Nombre et pourcentage d’incidents majeurs
 Temps moyen de résolution (MTTR)
 Pourcentage d’incident traité dans les temps (SLA)
 Nombre et pourcentage de résolution à distance
 Nombre d’incidents par type d’incident

Request Fulfillment Process
 Le terme Service Request décrit diverses demandes faites par les
utilisateurs. Plusieurs sont des demandes de changement mineur –
risques faibles, occurrences fréquentes, faibles coûts, etc.
(changement de mot de passe, installation sur un pc) - ou information
requests.
 Puisque les Service Requests sont fréquentes et ont un risque faible,
ils sont mieux traités comme un processus distinct. Cela élimine la
pression sur la gestion des incidents et la gestion du changement
(Incident and Change Management).
 Objectifs
 Fournir un canal pour demander et recevoir des requêtes simples
 Fournir des informations sur la disponibilité du service et son accès
 Maintenir et offrir des composantes de services standards
 Répondre aux questions générales, aux plaintes et aux commentaires

Problem Management Process
 "La cause inconnue d’un ou plusieurs incidents"
 Le processus de Problem Management gère les problèmes à
travers son propre cycle de vie.
 Ce cycle de vie inclus toutes les activités nécessaires à
l’identification de la cause racine des incidents, déterminer et
implémenter une solution via un changement et en assurer le
déploiement.
 Le gestionnaire de produit est responsable de la
documentation du problème (source, contournement,
résolution)
 Le gestionnaire de produit surveille de près la gestion des
incidents.

 Problem Models - mesures prédéfinies pour le traitement de types
de problèmes récurrents
 Workaround - Un moyen temporaire de contourner un incident, sa
réduction ou son élimination, là où une résolution n'est pas encore
disponible
 Known Errors - Le diagnostic est complété et un contournement ou
une résolution permanente est trouvé
 Known Error Database – Conserve les erreurs connues dans une
base de données; disponible pendant le diagnostic des incidents et
des problèmes
 Resolution - Mesures prises pour réparer un incident, un problème
ou mettre en œuvre une solution de contournement

1. Détection
2. Journalisation (logging)
3. Catégorisation
4. Priorisation
5. Diagnostic
6. Créer un enregistrement KE (Known Error)
7. Résolution

Incident vs problème
 Une secrétaire n’arrive pas à accéder à
une imprimante pour imprimer un
document pour le PDG.
 Le technicien reçoit l’appel. Il offre à la
secrétaire une solution de rechange en
configurant une autre imprimante.
 L’incident est réglé, pas le problème.
D’autres incidents risquent de survenir.
http://www.itilcommunity.com/modules.php?name=Forums&file=viewtopic&t=103

Access Management Process
 Access Management (aussi connue
comme Rights ou Identity Management)
est le processus d'octroi aux utilisateurs du
droit d'utiliser un service tout en empêchant
l'accès non autorisé.
 La gestion des accès s’assure de
l’application de ces politiques.

Access Management Process
 Processus
1. Demande d’accès
2. Vérification
3. Fournir les droits
4. Surveillance du statut des identités
5. Journalisation et suivi des accès
6. Enlever et restreindre les droits

Fonctions clefs du SO
 Service Desk
 Technical Management
 Application Management
 IT Operations Management

SO - Service Desk
 Le Service Desk devrait être un Single
Point Of Contact (SPOC) pour les
utilisateurs, traitant tous les incidents et
toutes les requêtes de service.
 Les opérations normales sont visées par les
SLA, des procédures, etc.
 A pour objectif de rétablir le fonctionnement
normal aussi rapidement que possible

SO - Service Desk
Local –À l’intérieur ou à proximité de la communauté desservie
Centralisé –Un lieu desservant plusieurs sites
Virtuel - Étalé sur une grande zone
géographique.
Exige un contrôle de la cohérence et de
l'uniformité;
Le Service Desk virtuel permet un soutien
dispersé "off shore" et le travail à domicile
SKMS : Service Knowledge Management System

SO - Service Desk
 Satisfaction des Client/Utilisateurs
 Taux de résolution à la première ligne
 Temps moyen de résolution d’un
incident (MTTR)
 Temps moyen d’escalade d’un incident
 Coût moyen de traitement d’un incident
 Pourcentage de mise à jour compléter
dans les temps
 Temps moyen à examiner et à fermer
un appel résolu
 Ventilation du nombre d'appels par
heure / jour
 Il est facile et tentant de mesurer de
nombreux éléments sur un service de
support, car il est une source de
données primaire.
 Malheureusement, de nombreux
éléments mesurables n'ont pas
vraiment de valeur dans la
détermination de la façon dont le
service desk performe ou quelles sont
les améliorations qui pourraient être
apportées.
 En effet, certains paramètres vont
encourager les comportements qui sont
contraires aux objectifs d'un bon
service d'assistance.
 Par exemple, suivre uniquement le
nombre d'appels traiter par un agent ne
vous indique pas le nombre d'appels
clôturer.
 Si les personnes sont évaluées (ou ont
des incitations) sur des nombres purs,
ils auront tendance à rechercher le
volume plutôt que la valeur.
Métriques

SO - Technical Management
 Technical Management est une fonction qui couvre les groupes, les équipes
et les départements qui fournissent une expertise technique et qui assure la
gestion de l’infrastructure.
 Elle est la gardienne des connaissances techniques et de l'expertise relatives
à la gestion de l'infrastructure IT. Elle possède toutes les connaissances
requises pour concevoir, tester, gérer et améliorer les services des TI, les
identifier, les développer et les raffiner.
 La gestion technique offre les ressources pour soutenir la gestion du cycle de
vie IT. Elle veille à ce que les ressources soient effectivement formées et
déployées.
 Technical Management est responsable de
 Maintenir l’infrastructure technique
 Documenter et maintenir les compétences requises pour gérer et support
l’infrastructure TI
 Diagnostiquer et réparer une défaillance technique

SO - Application Management
 La gestion des applications est similaire à la gestion
technique, mais elle gère les applications tout au long de leur
cycle de vie.
 Plus de détails sur la gestion des applications dans le cours
portant sur l’Application Service Library (ASL)

SO - IT Operations Management
 La fonction de gestion des opérations concerne les
groupes/équipes/départements qui réalisent les activités
opérationnelles au jour le jour (day-to-day).
 Ces activités concernent la gestion quotidienne du
fonctionnement de l'infrastructure de TI pour fournir des
services au niveau convenu.
 La fonction d’IT Operations :
 Exécute les activités et les procédures nécessaires à la gestion et à
l'entretien de l'infrastructure des TI de manière à fournir un soutien et
des services TI aux niveaux convenus

 Objectifs
 Maintenir le "statu quo" pour parvenir à la
stabilité de processus et des activités
quotidiennes de l'organisation
 Régulièrement examiner et améliorer les
services au moindre coût, tout en maintenant la
stabilité
 Rapidement appliquer leurs compétences
opérationnelles pour diagnostiquer et résoudre
les pannes informatiques qui se produisent

 L’Operations Management a 2 fonctions
 IT Operations Control:
 Assure les tâches opérationnelles de routine
 Fournir une supervision centralisée et des activités de contrôle
 Facilities Management (gestion des installations):
 Couvre la gestion de l'environnement physique
 Désigne les centres de données, les salles d'ordinateurs

Qualiti7

l’étude de cas
 Que faire dans la phase « Service
Operation » pour le projet de reporting?
 Qu’est-ce que la phase d’opération
problèmes?

L’étude de cas
 Gestion des évènements, des
requêtes, des accès, des incidents et
des problèmes
 Mauvaise gestion des incidents, accès
non autorisé ou incorrect, incidents et
problèmes traités sans évaluation des
impacts

Continual Service Improvement
 Le Continual Service Improvement
(CSI) est préoccupé par le maintien de
la valeur pour les clients par le biais de
l'évaluation continue et l'amélioration
de la qualité des services et de
l'ensemble de la maturité du cycle de
vie et des processus sous-jacents.

Valeur ajoutée
 Définition
 Amélioration- Comparer le résultat avant et après
pour illustrer l’amélioration (ou non)
 Bénéfice- Un gain doit suivre l’amélioration
 Retour sur l’investissement(ROI) - montant du
gain en prenant en compte l'investissement
nécessaire
 Valeur sur l’investissement (VOI) - valeur ajoutée
des avantages non financiers

Continual Service Improvement

Processus clefs et activités
 Plan
 Goals, objectives, scope
 Setting out what is to be achieved
 Who will be required
 Process development, techniques,
and tools
 How it will be done
 Do
 Financial Requirements
 Funding and budgets
 Documented and resourced roles and
responsibilities
 Policies, plans, procedures
 Communication and training
 Strategy Design Transition and
Operation
 Check
 Monitor measure and review:
 CSI objectives and plans achieved
 Reporting against plans
 Review documentation
 Process assessments and audits
 Allows identification of improvement
opportunities
 Act
 Enhancements identified could relate
to all aspects of the process, required
changes could be in:
 Policies
 Procedures
 Roles and responsibilities
 Improvements are implemented in
this stage

L’étude de cas
 Que faire dans la phase « CSI » pour
le projet de reporting?
 Revoir le fonctionnement du service,
son utilisation et voir s’il y a des
améliorations à apporter…

L’étude de cas
 Opportunité d’intégrer l’outil de
reporting dans le portail Sharepoint de
l’entreprise
 Opportunité d’intégrer d’autres
processus avec l’outil de reporting

Retour sur le diagramme

ITIL et les autres normes
 PRINCE 2
 PMBOK
 CMMi
 COBIT
 ISO 20 000
 Une façon d’être certifié ITIL, puisqu’ITIL
n’est pas une norme pour les entreprises

Prochain cours
 La maintenance
 Lecture
 Lessons Learned in ITIL Implementation Failure
 Essential ITIL what you need to succeed

introduction a itil

Recomendados

Recomendados

Más contenido relacionado

La actualidad más candente

La actualidad más candente (20)

Destacado

Destacado (10)

Similar a introduction a itil

Similar a introduction a itil (20)

introduction a itil