Vous êtes sur la page 1sur 64

Formaliser les processus

Pascal Delbrayelle Consultant pascal.delbrayelle@itilfrance.com
Version 1.0 du 29 novembre 2007

1

A propos ...
A propos du document
Ce document de référence est mis à la disposition de la communauté francophone ITIL pour diffuser les connaissances de base sur la formalisation des processus. Ce document peut être utilisé de manière libre à condition de citer le nom du site (www.itilfrance.com) ou le nom de l’auteur (Pascal Delbrayelle).

A propos de l’auteur
Pascal Delbrayelle est un consultant senior ayant plus de 20 années d’expérience dans le domaine de la production informatique en France. Il intervient comme consultant, formateur et animateur d’ateliers sur les projets techniques d’une production informatique et sur les projets ITIL. Ses différentes missions lui ont permis de coordonner des projets intervenant dans les différents domaines d’une production informatique (exploitation, interface entre les études et la production, gestion financière, capacité, etc.) et de travailler sur des projets de mise en œuvre de processus ITIL (évaluation de l’existant, modélisation de processus, choix et définition des indicateurs de performance et élaboration de tableaux de bord).

A propos de mission...
Si vous pensez que l’expérience de l’auteur sur le référentiel ITIL ou la formalisation de documents sur le sujet peut vous aider dans vos projets de production ou de mise en oeuvre des processus ITIL, n’hésitez pas à le contacter pour toute question ou demande : - par mail : pascal.delbrayelle@itilfrance.com - par téléphone : +33 (0)6 61 95 41 40 30/11/2004 2

Formaliser les processus
 Quelques rappels ITIL  L’approche traditionnelle des projets ITIL  Cartographier les processus
– La méthode – Les référentiels de processus – Savoir à quel niveau de détail s’arrêter

 Formaliser un processus
– Les concepts – Le livrable de formalisation du processus – Les procédures

 Les indicateurs de performance

Formaliser les processus Le référentiel ITIL Quelques rappels .

La version 1 Lancée par le gouvernement britannique fin années 1980 à début 1990 Production de 40 livres ITIL La version 2 Milieu des années 1990 à 2004 Production de 9 livres dont seulement 2 connus  Soutien des services (Service Support)  Fourniture des services (Service Delivery) ITIL Refresh et la version 3 Début 2004 et publication de 5+1 livres de mai à août 2007 5 .ITIL : de la version 1 à la version 3 ITIL pour Information Technology Infrastructure Library Collection de livres : les meilleures pratiques pour une DSI pour :  être le fournisseur de services basés sur l'informatique  plutôt que le traditionnel fournisseur de ressources informatiques.

La version 3 Mise à jour majeure lancée en 2004 et publiée en 2007 :   noyau de 1+5 livres puis livres complémentaires plus spécialisés sur des sujets donnés. Le noyau contient : Introduction au cycle de vie des services ITIL Stratégie des services (Service Strategy) Conception des services (Service Design) Transition (passage en production) des services (Service Transition) Exploitation des services (Service Operation) Amélioration permanente des services (Continual Service Improvement) 6 .

La version 3 7 .

Formaliser les processus

Document de formalisation : Un exemple traditionnel

8

L’approche traditionnelle en France
Les étapes

9

L’approche traditionnelle en France (suite)
Les responsables des processus :
– un propriétaire de processus (process owner) – peut-être un gestionnaire de processus par équipe intervenant dans le processus (process manager) Conséquences : – multiplication des responsables (par ex., 35 processus ou sous-processus donnent 35 propriétaires !) – définition floue du périmètre d’intervention et de responsabilité de chaque propriétaire – effet « remise de médailles » lors du lancement du projet et dilution des responsabilités

L'«ordre» d’implantation des processus
– un processus dépendant des autres processus, il ne peut pas être déployé de manière complète et indépendamment des autres
10

L’approche traditionnelle en France (suite) Les livrables (documents projet) : SGP (Spécifications Générales de Processus) SDP (Spécifications Détaillées de Processus) Procédures processus/étapes étapes/activités procédures conceptuel fonctionnel opérationnel 11 .

Le résultat est généralement plus volumineux que celui des SGP  Les procédures Pour chaque activité du processus. à des consignes d’exploitation 12 .L’approche traditionnelle en France (suite)  Les SGP (Spécifications Générales de Processus) Permet de positionner le processus par rapport aux autres et de présenter succinctement les différentes étapes du processus  Les SDP (Spécifications Détaillées de Processus) Permet de détailler les différentes étapes en activités. Une procédure est assimilable. un document de procédure détaille et traduit en tâches concrètes UNE activité du processus. par exemple.

etc.L’approche traditionnelle en France (suite) Documents généralement écrits avec Wordmd et Visiomd Cohérence de la masse documentaire : – après un ou deux ans de rédaction : impossibilité de conserver la cohérence de la masse documentaire générée (rédhibitoire dans l’objectif d’une certification ISO 20000) – Modélisation préférable à l'aide d'outil de BPR (Business Process Reenginiering) Pas de remise en cause (ou très peu) de l’organisation : – on repart de documents existants (procédures.) en faisant le moins de modifications possibles 13 .

macro-tâche. etc. tâche. sous-phase. phase. 14 . macro-activité. sousprocessus.L’approche traditionnelle en France (fin) Cette approche ne précise pas le curseur de niveau de détail séparant les SGP des SDP : – apparition de termes tels que : macro-processus. étape.

Formaliser les processus Un exemple qui fonctionne : Cartographier puis formaliser les processus 15 .

outils  Relations entre rôles et organisation  Indicateurs de performance 3. livrables.Cartographier :  Périmètre de la cartographie  Choisir le ou les référentiels de processus  Identifier les processus de plus haut niveau  Identifier les processus secondaires 2.Puis revenir au niveau cartographie :  Indicateurs de performance et tableaux de bord globaux 16 . rôles. événements déclenchés  Activités.Puis formaliser chacun des processus  Objectifs.Document de formalisation : Un exemple qui fonctionne 1. périmètre  Evénements déclencheurs.

Cartographier les processus  Définir les objectifs et le périmètre étudié  Choisir un ou plusieurs référentiels de processus  Définir les processus de plus haut niveau  Définir les processus secondaires  A quels niveaux s’arrêter ? 17 .Formaliser les processus 1.

Cartographier les processus : Définir les objectifs et le périmètre étudié 18 .1.

tester le plan de secours ou réaliser un projet typiquement ceux décrit dans le référentiel suivre les délais des incidents ou suivre les projets point de raffinement des précédents.. de reporting et de gestion stricto sensu (management de projet. donc.) 19  les processus de gestion :  les processus administratifs :    . etc. Cartographier les processus : Remarques sur la nature des processus Trois natures différentes :  les processus opérationnels :      résoudre les incidents. souvent identifiés mais pas décrits dans le référentiel réfèrent aux activités de supervision. achats... hors de la compétence de l'informatique : DRH. comptabilité.) demander une ressource humaine ou passer une commande chez un fournisseur rarement identifiés et pour lesquels le département informatique n'est le plus souvent que le facteur déclenchant réfèrent aux activités qui ne sont pas du domaine de la gestion des services d'infrastructure et. contentieux.1. service juridique. direction.

Cartographier les processus : Le choix du ou des référentiels Il est utile de ne pas partir de zéro en utilisant des référentiels qui ont fait leurs preuves En fonction du périmètre à couvrir.1. il faut comprendre pour adapter 20 . il faudra utiliser un ou plusieurs référentiels de processus et s’en inspirer pour définir sa propre cartographie Il est inutile de « recopier » la cartographie et la formalisation des processus.

utilisé maintenant pour mesurer la maturité de n’importe quel processus (et la capacité d’une organisation à fonctionner en processus) 21 . Cartographier les processus : Le choix du ou des référentiels Cadres de référence  ITIL : guide sur la structuration. l’intégration et l’amélioration des services des TI et les processus  COBIT (Control OBjectives for Information and related Technology) : à l’origine.1. V2) : méthodologie de gestion structurée de projets (OGC) Modèles  CMMI (Capability Maturity Model Integration) : à l’origine pour démontrer la maturité des processus de développement logiciel . est devenu un cadre complet de gestion des TI  PRINCE2 (PRojects IN Controlled Environments. un cadre d’audit des systèmes d’informations .

1. 1986) : mesure des défauts et amélioration de la qualité et méthodologie pour réduire les défauts  Lean Manufacturing ou Lean production (Toyota. Cartographier les processus : Le choix du ou des référentiels Standards  ISO/IEC 20000:2005 : approche processus ITIL pour délivrer les services répondant aux besoins des organisations métiers  ISO/IEC 27001:2005 : gestion de la sécurité des systèmes  ISO/IEC 17799:2005 : gestion de la sécurité des informations  .. mi-90s) : système qualité élaborant des séquences d’activités avec valeur ajoutée pour délivrer le produit 22 .. Systèmes qualité  Six Sigma (Motorola.

Cartographier les processus : Le choix du ou des référentiels Que choisir ?  IBM : ITIL + CMMI + Lean + Six Sigma  ISACA (Information Systems Audit and Control Association) et OGC: COBIT + ITIL + ISO 17799  Autres organisations : ITIL + CMMI + Six Sigma La confusion règne.1. Comment sauter cet obstacle ? Beaucoup d’organisations sont paralysées sur cette question L’expérience montre que la meilleure approche est une approche simultanée (démarrer simultanément par le haut et par le bas) La bonne question est : Que choisir d’implanter en premier ? 23 ...

24 . par exemple. la gestion des incidents ou la gestion des relations clients) – il répond à des exigences sur un thème donné et possède plusieurs objectifs (un objectif par exigence) – il sera découpé en processus secondaires pour faciliter la modélisation (un processus de plus haut niveau peut être très complexe et couvrir de nombreuses activités) – ils n’ont pas d’activités communes – l’ensemble de ces processus couvre toutes les activités répondant à l’ensemble des objectifs de l’organisation des TI devant être atteints par le projet. Cartographier les processus : Identifier les processus de plus haut niveau Un processus de plus haut niveau a les caractéristiques suivantes : – il couvre une discipline (regroupement logique d’activités autour d’un thème donné .1.

pour chaque processus de premier niveau.1. il faut procéder de la manière suivante : – prendre les exigences de chacune des disciplines (objectifs) : ne pas hésiter à les affiner et à les compléter (en particulier pour ITIL) – sélectionner les objectifs concrets au projet en relation avec la discipline couverte – les combiner pour définir l’ensemble des objectifs détaillés de la discipline couverte 25 . Cartographier les processus : Identifier les processus de plus haut niveau De manière concrète.

 Découper chaque processus de plus haut niveau : chacun des processus secondaires ne répond qu’à UN SEUL objectif du processus de plus haut niveau  Ensuite. il y aura un souci lors de la mise en place des processus secondaires (efficacité diminuée) alors même que les processus auront été correctement implantés 26 . vérifier que tous les objectifs du processus de plus haut niveau sont couverts par les processus secondaires Si l’un des objectifs du processus de plus haut niveau n’est pas couvert.1. Cartographier les processus : Identifier les processus secondaires  Faciliter la formalisation des processus : découper chaque processus de plus haut niveau en processus secondaires aussi appelés sous-processus il s’agit dans tous les cas de vrais processus complets (avec leurs indicateurs de performance par exemple).

Cartographier les processus : A quels niveaux s’arrêter ? 27 .1.

Cartographier les processus : Exemples du référentiel ITIL Service Support (Support des services) Service Desk Incident Management Problem Management Configuration Management Change Management Release Management Centre de services (fonction) Gestion des incidents Gestion des problèmes Gestion des configurations Gestion des changements Gestion des mises en production Service Delivery (Fourniture des services) Service Level Management (SLM) Financial Management for IT Services Capacity Management Availability and Security Management IT Service Continuity Management (ITSCM) Gestion des niveaux de service Gestion financière des services des TI Gestion de la capacité Gestion de la disponibilité et de la sécurité Gestion de la continuité des services des TI 28 .1.

1. Cartographier les processus : Exemple du référentiel ITIL : la gestion des incidents 29 .

1. Cartographier les processus : Exemple du référentiel ITIL : la gestion des mises en production Avec beaucoup d’imagination. il faut partir du schéma suivant : 30 .

2. participants et livrables Cycle de vie d’un livrable Le livrable formalisant le processus Les procédures Indicateurs de performance : Mesurer l’atteinte des objectifs 31 . Formaliser un processus        Formaliser un processus : Les concepts La dynamique d’un processus Activités.

Formaliser un processus : Les concepts La modélisation d’un processus nécessite de formaliser les éléments du schéma : 32 .

Formaliser un processus : Les concepts  Déclencheur : quels sont les événements déclencheurs qui vont activer le processus ?  Vers un autre processus : Quels résultats ou activations de processus le processus va-t-il fournir ou déclencher en sortie ?  Activités : Quels enchaînements d’activités vont permettre de dérouler le processus jusqu’au bout ? 33 .

Formaliser un processus : Les concepts  Rôles (participants) : Quels rôles vont intervenir dans chacune des activités et quels seront leurs responsabilités ? Comment regrouper les rôles pour définir les profils de poste ?  Techniques et outils : Quels sont les techniques et outils que les participants vont appliquer et qui vont permettre de supporter les activités du processus ? 34 .

Formaliser un processus : Les concepts  Livrables : Quels livrables sont créés ou modifiés par les participants dans le cadre des activités du processus et formalisés par les techniques et outils ?  Principes : Quelles sont les fondamentaux du processus dans lesquels il faut s’incrire pour toute décision sur le fonctionnement et toute amélioration du processus 35 .

La dynamique d’un processus Un processus est déclenché par la création d’un livrable (ou son arrivée) ou par le changement d’état d’un livrable existant Un processus a pour résultat la création de nouveaux livrables et/ou le changement de statut de livrables existants 36 .

Activités. participants et livrables Cette représentation (déclenchement et résultat) est aussi valable à l’intérieur d’un processus pour les activités 37 .

la base de connaissances pour savoir s’il existe déjà une solution référencée à l’incident en cours de traitement)  les rôles (réalisés par des éléments de l’organisation) qui interviennent dans la réalisation de l’activité Lorsque le résultat est complexe.Activités. l’activité va avoir besoin d’éléments extérieurs appelés participants :  les livrables dans lesquelles l’activité va puiser des informations (par ex.un devis détaillé) 38 . participants et livrables Une activité produit toujours un résultat. le changement d’état d’un livrable peut être « accompagné » d’un livrable complémentaire (par ex. elle décrit un traitement inutile Pour produire ce résultat. sinon.

Formalisation d’une activité Une activité est déclenchée par : – l’apparition d’un livrable – le passage d’un livrable dans un état donné (la fin d’une autre activité ou un événement déclencheur) Une activité. pour produire le résultat. utilise : – des livrables (qui ne seront pas modifiés) – des intervenants au travers d’un ou de plusieurs rôles Un livrable en sortie peut être : – un nouveau livrable (l’activité a créé le livrable) – un livrable existant qui change d’état (le résultat de l’activité est le changement d’état du livrable) (déclenchant une autre activité ou la sortie du processus) 39 .

Formalisation d’une activité 40 .

etc.Formalisation d’une activité Une activité peut regrouper plusieurs autres activités (sous-activités. tâches.) qui suivent les mêmes règles que les activités du niveau supérieur dans la modélisation Les intervenants dans une activité sont positionnés sur deux niveaux :  opérationnel : ceux qui vont participer à la production des livrables  tactique : ceux qui effectuent le suivi et le reporting Eviter de définir trop de niveaux (modélisation complexe et difficilement maintenable même avecun outil spécialisé) 41 .

il est alors appelé élément déclencheur du processus  il est un élément représentatif des flux de données  il possède un cycle de vie représenté par l’état du livrable. 42 .Formalisation d’un livrable Un livrable possède les propriétés suivantes :  c’est le produit tangible d’une activité  il permet de vérifier la complétude de l’activité qui l’a créé ou modifié  s’il est produit par une activité extérieure au processus modélisé.

Ce cycle de vie est matérialisé par une donnée appelée « Etat » Un changement d’état est provoqué par :  un événement déclencheur  la fin d’une activité Un changement d’état provoque :  un événement  une activité déclenché La formalisation des cycles de vie des livrables permet la mise en place d’outils de workflow 43 . ITIL (et la formalisation des processus) définit la notion de cycle de vie du livrable.Cycle de vie d’un livrable Afin de suivre son évolution dans le flux d’activités du ou des processus.

Les livrables du processus Chaque livrable a un cycle de vie : – enchaînement d'états (de Nouveau à Cloturée par ex.) – enchaînement linéaire : pas de boucle ! 44 .

Les livrables du processus Chaque livrable a un cycle de vie : – en cas d'apparition de boucle dans le raisonnement. il faut utiliser un livrable secondaire et son cycle de vie – le livrable principal reste dans un état unique pendant le déroulement de cette "boucle" – un livrable secondaire est créé à chaque occurrence de la boucle et ses changements d'état permet de déclencher les activités cycliques 45 .

Exemples de cycle de vie d’un livrable Demande de retrait Licences logiciellesDemande d'audit 46 .

Un exemple de cycle de vie plus complexe 47 .

Exemple de représentation d’une activité Processus : Retirer une somme en espèces au guichet Activité : Réceptionner et vérifier la demande de retrait 48 .

Exemple de représentation d’une activité Processus ITIL : Gérer les mises en production Activité : Réaliser les tests d’installation et d’exploitabilité et valider la partie support 49 .

Le livrable formalisant le processus Le livrable de la formalisation du processus : – Composante principale de la partie « Principes du processus » – Doit faire l’objet d’une large diffusion (ou formation) auprès des intervenants en même temps que : • la formation sur le référentiel (ITIL par exemple) • la formation sur les techniques de modélisation de processus (pour ceux qui interviendront sur cette partie) – Souvent livré sous la forme d’un document Word ou PDF Il s’agit du document de référence permettant – de baser la documentation procédures et le choix et le paramétrage des outils supportant le processus et – de garantir une cohérence de l’ensemble des projets et documents touchant au processus 50 .

Le livrable formalisant le processus Le plan du document comporte généralement : – Positionnement du processus dans son environnement (cartographie des processus) : • • • • • • • • • • objectifs du processus périmètre : technique. organisationnel. temporel risques opérationnels contrôles internes indicateurs de performance du processus (IPP) événements déclencheurs événements déclenchés [groupes d’activités] livrables consultés par le processus livrables créés et mis à jour par le processus – Résumé du contenu du processus 51 .

Le livrable formalisant le processus Le plan du document comporte généralement : – Support du processus • Documentations • Outils • Profils de poste intervenant dans le processus – Détail des activités • cartographie des activités (diagramme(s) du processus) • pour chaque activité : diagramme et détails – Détail des livrables • pour chaque livrable : préciser s’il s’agit d’un livrable principal (et son cycle de vie) ou d’un livrable secondaire (livrable détaillant ou accompagnant le changement d’état d’un livrable principal) 52 .

Le livrable formalisant le processus  Sert ensuite : – de référence pour toute décision sur le fonctionnement ou l’amélioration du processus – en phase de réflexion : l’ensemble des livrables de modélisation (et la cartographie des processus) permet d’élaborer : • les expressions de besoins pour les outils qui seront en support de ces processus • les profils de poste des intervenants dans ces processus • une ébauche d’organisation répondant au mieux pour l’efficacité de ces processus 53 .

très complexes. Casewise. très coûteux devront ensuite pouvoir générer une version lisible du livrable de modélisation de chacun des processus 3 grands du marché : Aris Toolset. Mega Process 54 .Le livrable formalisant le processus La forme de base des documents : – Très souvent Microsoft Word et Visio forme impossible à utiliser lorsque l’on envisage de mettre en place un cycle d’amélioration continue des processus forme très difficile pour établir et maintenir une cohérence sur l’ensemble des livrables – Forme conseillée : utiliser un outil de BPM (Business Process Management) pour gérer l’ensemble des informations inconvénients de ces outils : très lourds.

Les procédures La notion de procédure est une notion opérationnelle très floue Beaucoup de méthodes définissent la procédure comme décrivant le détail d’une activité (enchaînement des tâches de l'activité) 55 .

Les procédures De manière pragmatique : – décrit un déroulement de bout en bout pour traiter un sujet spécifique: traitement d’un incident majeur définition de l’impact. un à plusieurs processus (tout en restant dans le périmètre de la cartographie) – précise de manière opérationnelle les activités et les tâches à réaliser – inclut généralement un diagramme d’activités (ou un MOT) – complété par les modes opératoires des outils employés (documentations utilisateurs détaillées) 56 . de l’urgence et de la priorité d’un incident déploiement d’une version SAP – recouvre une à plusieurs activités.

Les procédures Exemple de procédure : traiter un incident majeur  couvre (partiellement) 3 processus (et en cite 2 autres) :  gérer les incidents  gérer les incidents majeurs  gérer les problèmes  inclut un diagramme des activités 57 .

une notion. concrète et mesurable d’un objectif Indicateur Information associée à un critère et destinée à en observer les évolutions à intervalles définis Note : un indicateur nécessite parfois un agrégat de données de mesure et l’utilisation d’une formule de calcul à partir de ces données 58 . de porter un jugement d’appréciation Traduction opérationnelle. signe qui permet de distinguer une chose.Les indicateurs de performance : Mesurer l’atteinte des objectifs Quelques définitions : Objectif Une organisation se propose d'atteindre un but précis au cours d'une période déterminée Critère (ou critère de succès) Caractère.

gestion des incidents.Les indicateurs de performance : Mesurer l’atteinte des objectifs Tableau de bord Outil de pilotage et d’aide à la décision regroupant une sélection d’indicateurs dépendant : du périmètre du tableau de bord (par ex. gestion des mises en production. ensemble des processus ITIL) du destinataire du tableau de bord 59 .

Les indicateurs de performance : Mesurer l’atteinte des objectifs Sans objectif. adapté) ☻ Temporel (limité dans le temps et revu régulièrement) 60 . pas de mesure ! Un objectif est un but visé : L’objectif peut porter sur : L’objectif doit être : – La satisfaction du client – (POUR QUI) – La conformité du produit ou service (QUOI) – La performance interne du processus (COMMENT) ☻ Simple (explicite. concret) ☻ Mesurable (facilement) ☻ Atteignable (réalisable) ☻ Réaliste (pertinent.

Indicateurs 61 . Le processus est efficace s’il atteint son objectif. pas d’amélioration ! Fréquence Mesures Taille Pour savoir où en est le processus par rapport à un objectif il faut mesurer ses caractéristiques et en surveiller l’évolution dans le temps.Les indicateurs de performance : Mesurer l’atteinte des objectifs Sans mesure. Pour y arriver il faut le piloter et engager des actions d’amélioration.

Les indicateurs de performance : Mesurer l’atteinte des objectifs Les trois types d’indicateurs : 62 .

Les indicateurs de performance : Mesurer l’atteinte des objectifs 63 .

Lister les objectifs à atteindre pour le processus 2. Définir les indicateurs de performance associés :  Description  Données de base et formule de calcul (en se basant sur la modélisation du processus si elle existe)  Périodicité des mesures 4. Traduire les objectifs en critères de succès (mesurables) 3. (Définir les tableaux de bord) :  Destinataires.Les indicateurs de performance : Mesurer l’atteinte des objectifs En pratique : 1. contenus et présentations 64 .