Réf. ITSM-M0103-V010-001
Définition d’un processus et utilisation #
Réf. ITSM-M0103-V010-002
Cette définition est commune à un certain nombre de référentiels.
Un processus peut être vu comme une boîte noire contenant des activités s’inscrivant dans une thématique spécifique (la mission ou l’objet du processus) qui doit réussir si l’organisation informatique veut réussir sa stratégie ITSM.
Chaque processus doit fournir de la valeur à un client (celui qui a demandé quelque chose de la part du processus).
La thématique du processus doit être claire et simple : en une ou deux phrases. Un inventaire de thèmes à la Prévert n’aiderait pas à comprendre l’intérêt de la boîte noire.
Pour que le processus réussisse, il sera nécessaire de concevoir et de mettre en place ce qu’on appelle le système de gestion (Management System) du processus, constitué de l’ensemble des politiques et moyens mis en œuvre pour structurer les activités et faire réussir le processus. Cela peut contenir un logiciel de gestion de flux de travail (workflow), des modèles de documents, des procédures, etc.
Réf. ITSM-M0103-V010-003
A l’origine, un processus est un élément tactique qui peut être considéré comme un facteur critique de succès de la statégie adoptée, dans le sens où la transformation de l’organisation informatique en fournisseur de services nécessite de réussir la mise en place de chaque élément tactique.
En conséquence, il faut définir une boîte noire constituée des activités relatives à un thème donné, lui préciser exactement son but (le pourquoi ou le thème des activités), ses objectifs concrets et ses résultats attendus.
Il faut ensuite mettre en place un système de mesure de la performance de cette boîte noire afin de pouvoir remonter ces mesures de performance vers les personnes qui s’occupent de la stratégie pour qu’elles puissent suivre la réussite de ces facteurs critiques de succès au niveau de la stratégie.
Cela nécessitera de définir les indicateurs de performance du processus et les rapports et tableau de bord tactique utilisés par la direction informatique.
Réf. ITSM-M0103-V010-004
Les acteurs opérationnels d’un processus voient cette boîte noire de manière très différente.
Rappelons tout d’abord que la documentation décrivant un processus N’est PAS un document opérationnel. Pour pouvoir l’utiliser de manière concrète, cela nécessite une interprétation et il est préférable d’utiliser des documents plus concrets appelés procédures (ou modes opératoires) qui vont décrire de manière utilisable simplement certaines parties du processus (flux de travail ou workflow) et, peut-être, dans des cas spécifiques d’utilisation (sur un déclencheur spécifique).
La norme ISO/IEC 9000 définit ces éléments comme étant des modèles de processus (difficilement traduits en français de Process Model).
Toutes les procédures doivent respecter le processus et les différentes étapes qui y sont décrites.
Cela permet, surtout si un système de gestion du processus et un logiciel de gestion de flux de travail sont en place sur le processus, de générer des données de gestion sur le traitement de ces procédures qui soient cohérentes entre elles et aggrégeables pour calculer les indicateurs de performance du processus (transformation facilitées des mesures en métriques).
Le gestionnaire du processus (Process Manager) peut, de son côté, ajouter des indicateurs de performance opérationnels qui lui faciliteront son travail de supervision et de contrôle sur les différentes activités du processus, traduites en activités de procédures.
C’est d’ailleurs ces procédures qui seront la base du paramétrage des logiciels de gestion de flux de travail.
Enfin, il est intéressant d’utiliser l’approche Lean et Lean IT pour formaliser ces procédures car elles représentent les processus au sens Lean IT.
Le Lean IT propose un formalisme simple mais efficace pour concevoir et documenter ces procédures (par exemple, le modèle SIPOC pour Supplier-Input-Process-Output-Customer).
Caractéristiques d’un processus #
Réf. ITSM-M0103-V010-005
L’efficacité est une mesure permettant de savoir si les objectifs d’un processus, d’un service ou d’une activité ont été atteints. Un processus ou une activité efficace est celui ou celle qui atteint les objectifs convenus.
L’efficience est une mesure permettant de savoir si la bonne quantité de ressources a été utilisée pour un processus, un service ou une activité. Un processus efficient atteint ses objectifs avec l’utilisation d’un minimum de temps, d’argent, de personnel ou autres ressources.
Quel que soit la nature et l’enchaînement de ses activités (cyclique, permanent, linéaire, etc.), le processus doit être déclenché par un événement spécifique qu’il faut décrire.
Un processus n’a d’intérêt que s’il produit des résultats (toujours les mêmes) à spécifier à la conception du processus. Ces résultats doivent pouvoir être mesurés afin d’être comparés aux objectifs du processus. Ces résultats doivent toujours apporter de la valeur à celui qui l’a demandé.
Un processus peut être visible des clients (gestion des incidents par ex.), dans ce cas, le bénéficiaire des résultats est un client.
Certains processus peuvent être internes à l’organisation informatique. Dans ce cas, le bénéficiaire n’est pas un client mais une « partie prenante » (stakeholder), terme générique incluant les clients et tout personne interne ou chez un fournisseur externe déclenchant le processus (gestion des configurations par ex.).
Référentiels de processus #
Réf. ITSM-M0103-V010-006
ITIL® n’est pas le seul référentiel de processus du marché. Il décline des éléments tactiques à mettre en place (les aptitudes) avec un découpage proposé par ITIL®.
Les processus proposés devraient décrire l’exhaustivité des activités de l’organisation informatique.
ITIL® englobe aussi toutes les aptitudes (schémas tactiques) nécessaires pour réussir une stratégie ITSM.
Réf. ITSM-M0103-V010-007
ITIL® propose 26 processus regroupés en cinq grands domaines, appelés étapes du cycle de vie des services.
Il propose aussi 4 fonctions couvrant la presque totalité des équipes et des métiers informatiques.
Bien que proposant les mêmes activités opérationnelles, Cobit a une autre approche stratégique : celle de la maîtrise de la gouvernance et du management des systèmes d’information.
Il propose 37 processus regroupés en 5 grands domaines.
Un processus en pratique #
Réf. ITSM-M0103-V010-008
Sur un niveau tactique, un processus est une approche permettant de systématiser et de formaliser une manière de faire pour produire les mêmes résultats à chaque fois que cela est demandé.
D’une manière simple, la formalisation va porter sur :
les enchaînements d’activités : un processus contient plusieurs enchaînements d’activités
qui fait quoi dans ces activités : la notion de rôle et des modèles permettent d’aider à concevoir cette partie
les résultats à générer : ils doivent être formalisés de manière précise et mesurable
les déclenchements du processus : ils doivent aussi être formalisés, ce qui permet de préciser qui a le droit de déclencher, quelles sont les informations à passer lors du déclenchement de processus, quels sont les canaux de communication (mail, téléphone, machine à café, etc.)
les ressources consommées par les activités du processus pour produire les résultats
les différents contrôles pour surveiller, réguler et faire fonctionner le processus correctement, à commencer par les mesures et les indicateurs de performance
les moyens utilisés en soutien, le système de gestion du processus, etc.
tout ce qui peut se révéler utile dans la vie du processus comme, par exemple, la liste des risques opérationnels, leur mesure et les contre-mesures à mettre en place.
Réf. ITSM-M0103-V010-009
D’une manière plus détaillée, un processus s’élabore en différentes étapes.
La documentation ITIL® et les supports de formation accrédités proposent toujours cette séquence dans la présentation de chacun des processus.
But, objet, raison d’être : la thématique du processus #
Elle doit être présentée en une ou deux phrases synthétiques. C’est ce qui va rendre visible de manière claire à l’extérieur du processus l’intérêt de cette boîte noire.
Par exemple, pour le processus ITIL® de gestion des incidents, il s’agit de rétablir le fonctionnement normal d’un service aussi rapidement que possible et de minimiser l’impact négatif sur les activités business, assurant ainsi que le niveau de qualité des services est maintenu.
Objectifs : ce que produiront les différents flux de travail (workflows) du processus #
Ils sont plus détaillés que le but du processus car ils précisent les objectifs de chaque flux de travail opérationnel. Ils précisent donc aussi les différents résultats produits par le processus, chaque résultat étant produit par un flux de travail.
Pour continuer sur l’exemple de la gestion des incidents, il y a cinq objectifs, donc cinq flux de travail qui se dessinent pour ce processus :
assurer que des méthodes et procédures standardisées sont utilisées pour répondre, analyser, documenter, suivre et faire des rapports de manière efficiente et rapide sur les incidents
accroître la visibilité et la communication sur les incidents envers les équipes clientes et informatiques
améliorer la perception qu’ont les clients de l’informatique à travers l’utilisation d’une approche professionnelle en résolvant rapidement et en communiquant rapidement sur les incidents lorsqu’ils surviennent
aligner les activités de gestion des incidents et leurs priorités sur celles des clients
maintenir la satisfaction des utilisateurs avec la qualité des services informatiques
Activités opérationnelles et de contrôle #
Chaque enchaînement d’activités doit être détaillé avec le déclencheur et le résultat produit.
Rôles et responsabilités dans le processus #
Un rôle est une notion abstraite permettant de relier les activités aux parties prenantes. Ce point est détaillé plus loin dans le document.
Système de gestion du processus et ressources nécessaires #
Il est aussi indispensable de préciser quelles sont les ressources utilisées dans chacune des activités.
En plus de tout cela, il sera aussi nécessaire de dimensionner les ressources du processus en estimant la volumétrie du processus (nombre d’occurrences simultanées du processus pour commencer) et leur impact sur la volumétrie de chacune des ressources consommées.
Ceci sera utilisé, par exemple, dans une démarche Lean IT appliquée au processus pour améliorer sont fonctionnement opérationnel.
Réf. ITSM-M0103-V010-010
Outre son aspect tactique (suivre la performance du processus au niveau stratégique afin de réussir la stratégie ITSM), le processus présente aussi un intérêt opérationnel direct : il se présente sous la forme d’une boîte noire avec des déclencheurs définis et des résultats définis. De plus, la boîte noire peut aussi s’engager sur des niveaux de performance comme un délai de traitement garanti.
Si quelqu’un a besoin de quelque chose produit par un processus, il sait comment le déclencher et ce qu’il va obtenir comme résultat, ce qui est garanti par la boîte noire.
Il n’a pas besoin de connaître ni de s’intéresser au détail du traitement, ce qui correspond parfaitement à son besoin.
Exemple de la gestion du catalogue de services #
Réf. ITSM-M0103-V010-011
Les objectifs ITIL® du processus sont :
Gérer l’information contenue dans le catalogue
S’assurer que le catalogue de services est à jour et reflète les détails, statuts, interfaces et dépendances actuelles de tous les services en production ou qui arrivent en production, en accord avec les politiques établies
S’assurer que le catalogue de services est accessible à toute personne autorisée sous une forme qui supporte leur utilisation du catalogue de services de manière efficace et efficiente
S’assurer que le catalogue de services supporte les besoins en constante évolution de tous les processus de gestion des services en matière d’informations dans ce catalogue incluant toutes les informations d’interfaces et de dépendances.
De manière simplifiée, les objectifs du processus sont :
Gérer l’information contenue dans le catalogue de services
S’assurer que le catalogue de services est à jour
S’assurer que le catalogue de services est accessible à toutes les parties prenantes
S’assurer que le catalogue de services supporte les évolutions des processus clients et informatiques
Rôle de processus et RACI #
Réf. ITSM-M0103-V010-012
Un rôle est, au final, rempli par une équipe, une personne ou un comité dans l’organisation. Cette relation devra être établie dans un second temps en associant à une personne ou une équipe un rôle de processus.
Bien sûr, une personne ou une équipe sera associée à plusieurs rôles issus de plusieurs processus différents et cela permettra de définir des fiches de poste en partant de processus établis.
Le rôle dans un processus est l’équivalent d’un profil utilisateur dans une application : l’application est développée sur ces profils utilisateurs (menus, écrans, possibilités fonctionnelles pour chacun des profils) et, lors de sa mise en production puis tout au long de son exploitation, les utilisateurs ayant un droit d’accès à l’application se voit attribuer le profil utilisateur approprié.
Les logiciels de flux de travail (workflow) fonctionnent de la même manière avec les rôles : ils sont utilisés pour définir les activités et ensuite associés aux utilisateurs ayant un droit d’utilisation de chaque processus.
Différents modèles de rôles facilitent la conception du processus.
Le modèle le plus connu est le modèle RACI.
Modèle RACI #
R (Responsible) : est Responsable de la conduite de l’activité, notamment la coordination et le pilotage des différents intervenants si l’activité est réalisée par plusieurs personnes
A (Accountable) : est la personne imputAble du succès ou de l’échec de l’activité, il est notamment responsable du résultat de l’activité
C (Consulted) : personne ou groupe qui sera Consulté pour le bon déroulement de l’activité (leur avis est obligatoire)
I (Informed) : personne ou groupe qui sera Informé soit de l’avancement de l’activité, soit du résultat de l’activité
Il est possible de compléter ces quatres types de responsabilité par un cinquième : le S pour Supportive, rôle qui intervient dans l’activité sous la responsabilité du Responsable de manière à n’avoir qu’un seul R même s’il y a plusieurs intervenants dans l’activité.
On parle alors de modèle RASCI.
Il existe d’autres variantes de ce modèle de base.
Réf. ITSM-M0103-V010-013
La matrice de responsabilités RACI ou RASCI permet aussi de présenter de manière claire les rôles et les responsabilités de chacun dans le processus. Cela est largement utile lors de la formation des parties prenantes sur l’utilisation du processus qui va être mis en place.
Les lignes représentent les activités du processus et les colonnes les rôles cités dans le processus.
Aux intersections, si le rôle est cité dans l’activité, le type de responsabilité (R, A, S, C ou I) sera précisé.
Les parties prenantes voient alors qui fait quoi à chacune des étapes du processus.
Conception détaillée d’un processus #
Réf. ITSM-M0103-V010-014
Evidemment, la conception d’un processus embarque beaucoup plus d’éléments que ceux qui ont été présentés jusqu’à présent.
Procédures et modes opératoires
Sur la partie centrale du processus, les activités ont besoin d’être détaillées et décrites plus finement sous la forme de procédures et de modes opératoires.
La description du processus est un document tactique, difficilement utilisable directement dans un flux opérationnel. Dans certains cas d’utilisation (notamment sur des utilisations fréquentes), il sera intéressant de décrire de manière opérationnelle sous la forme de procédures et de modes opératoires les activités du processus. Ce sont alors des documents opérationnels directement applicables par les acteurs du processus sans nécessité d’interprétation.
Dans certains cas, une séquence d’activités sera déclinée en procédure ou mode opératoire pour traiter un cas particulier qui arrive souvent. On parle alors de modèle de processus, notion ISO/IEC 9000 introduite dans ITIL® avec la version 2007. Cette notion sera abordée plus loin dans le document.
Métriques du processus
Les métriques sont des mesures brutes transformées pour être utilisables dans le calcul des indicateurs de performance (notamment pour pouvoir avoir des valeurs comparables sans mélanger « des choux et des carottes »).
Cette notion est abordée dans le processus ITIL® de gestion des connaissances et dans l’amélioration continue des services.
Tout ce qui doit être mesuré sur la performance du processus (objectifs, résultats, qualité, délais de traitement, etc.) doit être décrit au préalable avec :
la mesure des données de base (et les outils et applications contenant ou permettant de faire les différentes mesures)
la transformation des mesures de base en métriques
Amélioration sur le processus
La politique et les actions permettant l’amélioration du processus doivent être décrits. Cela peut inclure, par exemple, une réunion mensuelle ou trimestrielle pour examiner les informations recueillies à chaque clôture de ticket (l’enregistrement qui suit de bout en bout une occurrence de processus) et déterminer ce qui devrait être amélioré dans le processus.
Cette partie est extrêmement importante car :
un processus est très complexe à concevoir et il est impossible de sortir rapidement une conception de processus et d’être exhaustif et parfait du premier coup
la première version du processus sera ensuite complétée et améliorée par ces activités d’amélioration du processus ; cette partie est facilitée par les concepts et les techniques développées dans le Lean IT
Ne pas mettre en place immédiatement une partie amélioration du processus entraînera systématiquement un abandon du processus au bout d’un certain temps (mais qui finira par arriver) par manque de résultats.
Alimentation du processus
Les ressources qui seront consommées par le processus doivent être précisées ainsi que les aptitudes nécessaires au bon fonctionnement du processus. Ces aptitudes portent sur l’optimisation des ressources mises en œuvre comme, par exemple, la compétence et les connaissances nécessaires aux différents acteurs du processus (déterminant par ailleurs les formations nécessaires pour avoir des acteurs à niveau, indépendamment de leur niveau actuel).
Objectifs du processus
Ils sont à définir et permettent d’identifier les flux de travail (workflows) qui seront à mettre en place au niveau opérationnel.
Ils permettent aussi de définir les indicateurs de performance à mettre en place pour mesurer l’atteinte de chaque objectif, calculé à partir des métriques du processus.
L’amélioration continue des services donne une approche classique pour déterminer les indicateurs-clés de performance (KPI ou Key Performance Indicator) en définissant les facteurs critiques de succès (CSF ou Critical Success Factor) dans le cheminement.
Politique et documentation du processus
La politique (les principes à respecter, ce qu’il est possible de faire et de ne pas faire, etc.) du processus est aussi à définir préalablement aux éléments opérationnels.
La documentation du processus doit aussi être rédigée, le plus souvent à partir d’un modèle de document fourni par l’équipe qualité afin d’avoir une uniformité sur l’ensemble des descriptions de processus. Elle devra aussi être maintenue à jour en permanence et être disponible au moins pour toutes les parties prenantes du processus.
Réaction sur le processus
Les facteurs externes influençant le fonctionnement du processus sont à décrire ainsi que des actions appropriées pour y répondre, le plus souvent par une analyse d’impact sur les éléments du processus et la réaction appropriée pour adapter le processus.
Peuvent y figurer les facteurs de risque du processus avec les mesures de risque et les contre-mesures éventuelles.
Propriétaire du processus
Ce dernier élément est en réalité le premier à définir pour le processus.
Il s’agit de définir la personne qui a la lourde tâche de concevoir le processus, donc de définir tous les éléments qui ont été présentés précédemment.
Il aura aussi la responsabilité de fournir les ressources nécessaires pour un fonctionnement opérationnel correct du processus.
C’est un rôle qui est extérieur au fonctionnement opérationnel du processus. Généralement, son nom apparaît dans le cartouche ou la première page de la documentation décrivant le processus.
Système de gestion d’un processus et outillage logiciel #
Réf. ITSM-M0103-V010-015
Un système de gestion à mettre en place
Nous avons vu précédemment qu’il y avait beaucoup d’éléments dans la conception du processus. Ceci représente une charge de travail :
initiale pour la mise en œuvre du processus
permanente pour la mise à jour continuelle du processus afin qu’il reste optimal
Nous allons aussi demander aux différents acteurs dans le processus :
de tracer tout ce qu’il font en mettant à jour des enregistrements permettant de suivre toutes les occurrences en cours et celles clôturées, avec tout le détail de ce qui a été réalisé
de rédiger de la documentation (voici donc les gros mots) à chaque fois que cela sera nécessaire
De plus, pour permettre de stocker, de gérer et de consulter ces enregistrements et documentations générés par l’ensemble des activités du processus au fil du temps, il va falloir concevoir, mettre en place et exploiter au quotidien des outils logiciels.
Ceci fait partie du système de gestion du processus.
Toutes ces actions supplémentaires et la mise en place d’un environnement de gestion coûtent.
Premiers bénéficiaires du système de gestion : les acteurs du processus
Néammoins, ce système de gestion devrait faciliter le travail des acteurs du processus. Cet effet sera plus ou moins marqué selon les processus.
Ainsi, dans la gestion des incidents par exemple, la saisie dans un ticket d’incident de la description d’une solution de contournement permettra par la suite, lors du traitement de nouveaux tickets d’incident similaires, de pouvoir appliquer une solution déjà décrite et documentée dans le système.
Les bénéfices les plus importants sont à l’extérieur du processus
Cependant, pour une grande partie des processus, les avantages sont plus importants à l’extérieur du processus qu’à l’intérieur.
Ainsi, un processus est une charge de travail supplémentaire pour les acteurs dans le processus mais elle ne leur bénéfie que très peu.
Ce sont des collègues au sein de l’organisation informatique, intervenant dans d’autres processus qui vont le plus en bénéficier.
L’effet sera d’autant plus important si ces personnes extérieures au processus peuvent aussi consulter facilement les enregistrements et les documents générés par le processus.
Par exemple, dans la gestion des changements, lorsqu’un chef de projet déclenche l’évolution fonctionnelle d’une application (montée de version), il peut consulter tous les incidents clôturés en lien avec l’application pour savoir s’il peut intégrer dans sa montée de version quelques modifications qui permettront d’améliorer l’application en plus d’apporter des nouveautés fonctionnelles.
Cependant, si aucune trace ou élément exploitable sur ces incidents n’est disponible ou si le chef de projet n’a simplement pas accès au logiciel de gestion des tickets d’incidents, il fera l’impasse sur cette action qui participe malgré tout à la satisfaction des utilisateurs de l’application.
Dans certains cas, il demandera aux personnes traitant les incidents de leur sortir une extraction de l’outil avec ce qui l’intéresse et, très souvent, ne recevra rien en retour car cela sera considéré comme une intrusion dans leur domaine d’activités ou une charge de travail supplémentaire n’ayant aucun intérêt pour eux.
C’est pour cela qu’il est nécessaire d’ouvrir les enregistrements et les documents générés par le processus aux personnes extérieures au processus (sous réserve de la confidentialité de ces éléments) afin qu’elles puissent consulter rapidement ces derniers, les analyser, en faire des statistiques, etc. sans qu’ils aient à « déranger » les acteurs du processus.
Des activités complémentaires dans le processus devront donc gérer les accès des personnes externes au processus aux données et documents du processus.
Très souvent, la rentabilisation de la charge de travail supplémentaire imposée aux acteurs et du système de gestion sera réelle lorsque les personnes externes au processus pourront accéder aux enregistrements et documents du processus.
L’étape ultime : la gestion des connaissances #
Si les données et documents de l’ensemble des processus sont abordés selon ce principe, cela permet à quiconque au sein de l’organisation d’accéder à des traitements (consultation, analyse, corrélation, rapport, etc.) sur ces éléments pour n’importe quel processus mis en place, permettant alors de tirer des bénéfices plus importants que la somme des bénéfices apportés par chacun des processus en leur sein.
ITIL® décrit cette approche et la formalise dans le processus de gestion des connaissances sur les services.
Réf. ITSM-M0103-V010-016
Les définitions suivantes sont extraites de la norme ISO/IEC 20000 :
Management System : system to establish policy and objectives and to achieve those objectives
System : set of interrelated or interacting elements
Dans l’accompagnement d’un processus, son système de gestion permet la traçabilité de toutes les activités du processus, de faire des mesures, de produire des rapports (donc d’être en mesure de contrôler, de piloter et de coordonner) et d’identifier des opportunités d’amélioration.
Le système de gestion d’un processus est donc constitué de la documentation, des outils et des moyens nécessaires pour supporter et faciliter la gestion du processus afin qu’il puisse supporter ses activités et atteindre ses objectifs.
Chaque processus possèdera son propre système de gestion mais, pour éviter d’avoir des silos de processus (chacun gérant ses données internes de manière isolée), l’ensemble des systèmes de gestion sera intégré dans un système global appelé système de gestion des connaissances sur les services.
Dans ITIL®, la gestion de ce système global est confié au processus de gestion des connaissances (transition des services).
Cela permet, par exemple, de rapprocher des données sur les incidents et les mises en production afin de corréler des mises en production ayant eu des effets de bord indésirables qui ont provoqué la création d’incidents.
Procédures et modes opératoires #
Réf. ITSM-M0103-V010-017
Contrairement à la documentation du processus, qui est un document tactique, les procédures et modes opératoires sont des documents plus opérationnels, directement utilisables au quotidien par les équipes intervenant dans le processus.
La difficulté d’un document tactique est sa nécessité d’être intérprété en fonction du contexte, ici pour un processus, du type de l’élément traité. Par exemple, pour la gestion des changements, la décision d’autoriser ou non un changement est habituellement de la responsabilité du rôle de l’autorité du changement. Cependant, cette notion tactique doit être interprétée en fonction de la nature de la demande de changement :
pour une correction applicative mineure : ce peut être le chef de projet avec le client qui décident ensemble
pour une montée de version majeure d’une application : il faut impliquer dans la décision d’autres parties prenantes comme le centre de services (le support), les opérations (l’exploitation), la direction générale, etc.
pour un projet d’infrastructures : la décision pourra être prise par le responsable de la production et certains responsables d’équipes techniques
Le processus de gestion des changements prévoit une étape préliminaire (l’évaluation du changement) comprenant l’identification des personnes désignées sous l’appelation autorité du changement.
Cependant, la pratique courante permet de dire que nous avons des cas de figure fréquents se terminant avec l’identification des mêmes personnes.
Cette remarque s’étend à l’ensemble des activités du processus de gestion des changements. Un type particulier de changement permet de donner toujours la même interprétation des activités du processus et des notions reliées.
Lorsqu’un type particulier de changement avec l’interprétation spécifique des activités du processus est identifié et spécifié, nous sommes en présence de ce que la norme ISO/IEC 9000 appelle un modèle de processus. Cette notion a été reprise dans ITIL® à partir de 2007.
Un modèle de processus est un ensemble d’étapes prédéfinies permettant de traiter un type particulier de demande.
Lorsque le processus détecte que la demande à traiter correspond à l’application d’un modèle de processus, c’est ce modèle qui sera déroulé pour la suite du traitement de la demande.
Nous avons donc ainsi des modèles de changement. Cette notion se retrouve dans d’autres processus ITIL® et nous aurons des modèles de mise en production et de déploiement, de modèles d’incident, de modèles de demande de service, etc.
Concrètement, un modèle de processus se présente sous la forme d’une procédure ou d’un mode opératoire à appliquer.
La différence entre procédure et mode opératoire est floue et dépend des référentiels complémentaires appliqués à la formalisation des processus. La définition des deux termes est donc à préciser avant la formalisation des processus.
Dès qu’une procédure à appliquer est identifiée, les équipes n’ont plus à interpréter la documentation du processus mais appliquent directement les instructions de la procédure. Comme la procédure a été conçue dans le respect du processus, les équipes suivent néammoins et indirectement le processus.
L’avantage d’une procédure est que tous les termes tactiques nécessitant une interprétation en fonction de la nature de la demande sont tous précisés de manière concrète et opérationnelle, permettant de gagner du temps et évitant les erreurs d’interprétation.
Les processus ITIL 3 #
Réf. ITSM-M0103-V010-018
Les 26 processus du référentiel ITIL® sont regroupés en cinq grands thèmes appelés étapes du cycle de vie des services.
Le cycle de vie des services parle en réalité non pas de services mais de processus. S’il s’était appelé cycle de gestion de la vie des services, cela aurait évité une question discutable dans l’examen Fondamentaux de ITIL®.
La stratégie des services (Service Strategy) permet :
d’aligner les stratégies d’affaires et informatique
de définir les objectifs et les politiques, allouer les ressources et préciser les contraintes, établir un plan global et le piloter
La conception des services (Service Design) permet :
de concevoir les architectures et les normes, les processus informatiques, les outils internes de gestion pour répondre efficacement à la demande et fournir les niveaux de services convenus, gérer les relations clients et fournisseurs
La transition des services (Service Transition) permet :
d’élaborer et gérer les plans de transition, les risques et les critères d’acceptation, tester et valider les solutions, déployer, capitaliser les connaissances
L’exploitation des services (Service Operation) permet :
d’appliquer les plans opérationnels, les procédures et modes opératoires au quotidien pour fournir la qualité de service convenue, surveiller et générer des rapports
L’amélioration continue des services (Continual Service Improvement) permet :
de produire des rapports et analyser le fonctionnement de ce qui a été mis en place (solutions, processus, organisation, etc.)
de définir, lancer et piloter les plans d’amélioration
Réf. ITSM-M0103-V010-019
La stratégie des services #
Elle regroupe les activités informatiques permettant :
de relier les besoins et stratégie de l’entreprise ou de l’organisation dans son ensemble (business) et des clients à la stratégie informatique, assurant un alignement des stratégies clientes et informatique
d’intégrer l’approche stratégique de l’informatique qui est de fournir de la valeur aux clients sous la forme de services informatiques
de réagir de manière adéquate côté informatique lors d’évolutions de stratégies clientes afin de réévaluer la stratégie informatique qui doit rester alignée de manière optimale avec les besoins clients
La conception des services #
Elle regroupe les activités de conception de quoi que se soit à l’informatique : les solutions de service, les infrastructures, les systèmes de gestion des processus, les architectures techniques et applicatives, les système de mesure et de création de rapports, etc.
Elle inclut évidemment les évolutions et les améliorations de conception de tous ces éléments.
Toutes les activités de conception sont regroupées dans ces processus afin de garantir :
que toute conception sera réalisée dans les règles de l’art (les bonnes pratiques)
que toutes les conceptions seront cohérentes les unes avec les autres, ce qui évite de donner l’impression qu’il y a des équipes autonomes qui décident des solutions et des technologies à mettre en œuvre chacune de leur côté sans cohérence globale
que l’ensemble des conceptions sera conforme et ira dans le sens de la stratégie informatique, ce qui évite des divergences entre la stratégie et l’opérationnel
que l’usage de l’ensemble des ressources informatiques sera optimisé par la réutilisation maximale de ressources existantes (ressources techniques en production)
L’ensemble des processus de conception sont globalement utilisés dans deux cas de figure :
le cas que l’on pourrait appeler pro-actif, c’est-à-dire des actions réalisées AVANT le lancement du premier projet destiné à mettre en place un service pour un client
le cas que l’on pourrait appeler réactif, c’est-à-dire des actions de conception réalisées PENDANT un projet de transition de service destiné aux clients
Le premier cas permet de lancer des projets d’infrastructure en amont des projets applicatifs et de toujours avoir le plus possible de solutions standard pour mettre en œuvre les solutions de service et prendre en compte rapidement des besoins récurrents, notamment en matière de niveau de service.
Le second cas est l’appel aux processus de conception pendant un projet (étape de transition des services) afin de libérer le chef de projet de la prise en compte de toutes les contraintes de conception de la solution qu’il doit mettre en place (besoins clients, alignement avec la stratégie, complétude de la conception, etc.).
La transition des services #
Cette étape intègre toutes les activités pour mener à bien une transition, c’est-à-dire passer de l’état d’idée à quelque chose qui est en exploitation. Cela inclut la conduite de tous les projets.
La colonne vertébrale de cette étape est le processus de gestion des changements qui va piloter, coordonner et réguler tous les changements dans la fourniture des services.
Pour bien comprendre, il est intéressant de comparer la transition des services à une méthodologie projet :
la conception : le chef de projet doit déclencher les processus de conception des services pour obtenir un dossier de conception complet
le développement et les tests : la gestion des changements pilote ces étapes qui sont réalisées soit dans le cadre d’ITIL® avec des processus de transition des services, soit dans le cadre strict de la gestion de projet (hors périmètre ITIL®)
le déploiement et la phase pilote : réalisés sous le contrôle exclusif d’un processus ITIL®
D’autres processus de transition sont des activités de fond soutenant et facilitant la réussite des processus impliqués directement dans les changements. Ils profitent à l’ensemble des processus ITIL®.
L’exploitation des services #
Dans ITIL®, seules les activités orientées services sont formalisées sous la forme de processus. L’exemple le plus connu est la gestion des incidents qui intervient dès qu’une interruption de service ou la dégradation d’un niveau de service est constatée.
Les autres activités, activités techniques réalisées par les équipes d’opérations (sauvegarde & restauration, ordonnancement, gestion des consoles de supervision, etc.) sont citées dans ITIL® mais non formalisées sous la forme de processus.
Traditionnellement, les fonctions ITIL® sont décrites dans cette partie car elle sont intégrées dans le livre d’exploitation des services. Ceci est trompeur car les fonctions ITIL® réalisent des activités de l’ensemble des processus ITIL® et pas uniquement celles de l’exploitation des services.
L’amélioration continue des services #
Cette partie, apparue en 2007 avec l’arrivée dans ITIL® des concepts ISO/IEC 9000, ne comprend qu’un seul processus ITIL® à appliquer dans un contexte particulier.
Les autres éléments décrits dans cette partie sont des rappels de gestion de la qualité et d’amélioration continue en provenance d’autres référentiels.
Le concept fondamental d’ISO/IEC 9000 et de beaucoup de normes est le cycle de Deming (PDCA pour Plan-Do-Check-Act).
Cette partie rappelle aussi les bonnes pratiques en matière d’élaboration des mesures, des métriques, des indicateurs-clés de performance et des facteurs critiques de succès.