0-formalisation des processus

Formaliser les processus

Pascal Delbrayelle [email protected]

1

Version 1.0 du 29 novembre 2007

A propos ...

A propos du documentCe 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’auteurPascal 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 : [email protected] par téléphone : +33 (0)6 61 95 41 40

A propos du documentCe 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’auteurPascal 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 : [email protected] par téléphone : +33 (0)6 61 95 41 40

30/11/2004 2


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

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


Le référentiel ITIL

Quelques rappels

Le référentiel ITIL

Quelques rappels

ITIL pour Information Technology Infrastructure LibraryCollection 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 1Lancée par le gouvernement britannique fin années 1980 à début 1990 Production de 40 livres ITIL

La version 2Milieu des années 1990 à 2004Production de 9 livres dont seulement 2 connus Soutien des services (Service Support) Fourniture des services (Service Delivery)

ITIL Refresh et la version 3Début 2004 et publication de 5+1 livres de mai à août 2007

ITIL : de la version 1 à la version 3

ITIL pour Information Technology Infrastructure LibraryCollection 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 1Lancée par le gouvernement britannique fin années 1980 à début 1990 Production de 40 livres ITIL

La version 2Milieu des années 1990 à 2004Production de 9 livres dont seulement 2 connus Soutien des services (Service Support) Fourniture des services (Service Delivery)

ITIL Refresh et la version 3Début 2004 et publication de 5+1 livres de mai à août 2007

5

La version 3

Le noyau contient :Introduction au cycle de vie des services ITILStraté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)

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 ITILStraté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


Document de formalisation :

Un exemple traditionnel

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ésL'«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

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ésL'«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


Les livrables (documents projet) :

SGP (Spécifications Générales de Processus) processus/étapes conceptuel

SDP (Spécifications Détaillées de Processus) étapes/activités fonctionnel

Procédures procédures opérationnel

11

Procédures procédures opérationnel


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. Le résultat est généralement plus volumineux que celui des SGP

Les procéduresPour chaque activité du processus, un document de procédure détaille et traduit en tâches concrètes UNE activité du processus. Une procédure est assimilable, par exemple, à des consignes d’exploitation

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. Le résultat est généralement plus volumineux que celui des SGP

Les procéduresPour chaque activité du processus, un document de procédure détaille et traduit en tâches concrètes UNE activité du processus. Une procédure est assimilable, par exemple, à des consignes d’exploitation

12


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, etc.) en faisant le

moins de modifications possibles

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, etc.) en faisant le

moins de modifications possibles

13

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, sous-processus, étape, phase, sous-phase, macro-activité, tâche, macro-tâche, etc.

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, sous-processus, étape, phase, sous-phase, macro-activité, tâche, macro-tâche, etc.

14


Un exemple qui fonctionne :

Cartographier puis formaliser les processus

Un exemple qui fonctionne :

Cartographier puis formaliser les processus

15

Document de formalisation :Un exemple qui fonctionne

1.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 formaliser chacun des processus Objectifs, périmètre Evénements déclencheurs, événements

déclenchés Activités, livrables, rôles, outils Relations entre rôles et organisation Indicateurs de performance

3.Puis revenir au niveau cartographie : Indicateurs de performance et

tableaux de bord globaux

1.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 formaliser chacun des processus Objectifs, périmètre Evénements déclencheurs, événements

déclenchés Activités, livrables, rôles, outils Relations entre rôles et organisation Indicateurs de performance

3.Puis revenir au niveau cartographie : Indicateurs de performance et

tableaux de bord globaux16


1. Cartographier les processus

17

Définir les objectifs et le périmètre étudiéChoisir un ou plusieurs référentiels de processusDéfinir les processus de plus haut niveauDéfinir les processus secondairesA quels niveaux s’arrêter ?

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

18

1. Cartographier les processus :Remarques sur la nature des processus

Trois natures différentes : les processus opérationnels : résoudre les incidents, tester le plan de secours ou réaliser un projet typiquement ceux décrit dans le référentiel les processus de gestion : suivre les délais des incidents ou suivre les projets point de raffinement des précédents, souvent identifiés mais pas

décrits dans le référentiel réfèrent aux activités de supervision, de reporting et de gestion stricto

sensu (management de projet, direction,...) les processus administratifs : 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, donc, hors de la compétence de l'informatique : DRH, comptabilité, achats, service juridique, contentieux, etc.)

Trois natures différentes : les processus opérationnels : résoudre les incidents, tester le plan de secours ou réaliser un projet typiquement ceux décrit dans le référentiel les processus de gestion : suivre les délais des incidents ou suivre les projets point de raffinement des précédents, souvent identifiés mais pas

décrits dans le référentiel réfèrent aux activités de supervision, de reporting et de gestion stricto

sensu (management de projet, direction,...) les processus administratifs : 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, donc, hors de la compétence de l'informatique : DRH, comptabilité, achats, service juridique, contentieux, etc.) 19

1. 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, 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, il faut comprendre pour adapter

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, 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, il faut comprendre pour adapter

20


Cadres de référenceITIL : guide sur la structuration, l’intégration et

l’amélioration des services des TI et les processusCOBIT (Control OBjectives for Information and related

Technology) : à l’origine, un cadre d’audit des systèmes d’informations ; est devenu un cadre complet de gestion des TI

PRINCE2 (PRojects IN Controlled Environments, V2) : méthodologie de gestion structurée de projets (OGC)

ModèlesCMMI (Capability Maturity Model Integration) : à l’origine

pour démontrer la maturité des processus de développement logiciel ; utilisé maintenant pour mesurer la maturité de n’importe quel processus (et la capacité d’une organisation à fonctionner en processus)

Cadres de référenceITIL : guide sur la structuration, l’intégration et

l’amélioration des services des TI et les processusCOBIT (Control OBjectives for Information and related

Technology) : à l’origine, un cadre d’audit des systèmes d’informations ; est devenu un cadre complet de gestion des TI

PRINCE2 (PRojects IN Controlled Environments, V2) : méthodologie de gestion structurée de projets (OGC)

ModèlesCMMI (Capability Maturity Model Integration) : à l’origine

pour démontrer la maturité des processus de développement logiciel ; utilisé maintenant pour mesurer la maturité de n’importe quel processus (et la capacité d’une organisation à fonctionner en processus)

21


StandardsISO/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èmesISO/IEC 17799:2005 : gestion de la sécurité des

informations...

Systèmes qualitéSix Sigma (Motorola, 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, mi-90s) : système qualité élaborant des séquences d’activités avec valeur ajoutée pour délivrer le produit

StandardsISO/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èmesISO/IEC 17799:2005 : gestion de la sécurité des

informations...

Systèmes qualitéSix Sigma (Motorola, 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, mi-90s) : système qualité élaborant des séquences d’activités avec valeur ajoutée pour délivrer le produit

22


Que choisir ?IBM : ITIL + CMMI + Lean + Six SigmaISACA (Information Systems Audit and Control

Association) et OGC: COBIT + ITIL + ISO 17799Autres organisations : ITIL + CMMI + Six Sigma

La confusion règne...

Comment sauter cet obstacle ?Beaucoup d’organisations sont paralysées sur cette questionL’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 ?

Que choisir ?IBM : ITIL + CMMI + Lean + Six SigmaISACA (Information Systems Audit and Control

Association) et OGC: COBIT + ITIL + ISO 17799Autres organisations : ITIL + CMMI + Six Sigma

La confusion règne...

Comment sauter cet obstacle ?Beaucoup d’organisations sont paralysées sur cette questionL’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

1. 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é ; 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.

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é ; 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.

24

1. Cartographier les processus : Identifier les processus de plus haut niveau

De manière concrète, pour chaque processus de premier niveau, 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

De manière concrète, pour chaque processus de premier niveau, 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

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-processusil s’agit dans tous les cas de vrais processus complets (avec leurs indicateurs de performance par exemple).

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, vérifier que tous les objectifs du processus de plus

haut niveau sont couverts par les processus secondairesSi l’un des objectifs du processus de plus haut niveau n’est pas couvert, 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

Faciliter la formalisation des processus : découper chaque processus de plus haut niveau en processus secondaires

aussi appelés sous-processusil s’agit dans tous les cas de vrais processus complets (avec leurs indicateurs de performance par exemple).

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, vérifier que tous les objectifs du processus de plus

haut niveau sont couverts par les processus secondairesSi l’un des objectifs du processus de plus haut niveau n’est pas couvert, 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

1. 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 Centre de services (fonction)Incident Management Gestion des incidentsProblem Management Gestion des problèmesConfiguration Management Gestion des configurationsChange Management Gestion des changements

28

Release Management Gestion des mises en production

Service Delivery (Fourniture des services)Service Level Management (SLM) Gestion des niveaux de serviceFinancial Management for IT Services Gestion financière des services des TICapacity Management Gestion de la capacitéAvailability and Security Management Gestion de la disponibilité et de la sécuritéIT Service Continuity Management (ITSCM)

Gestion de la continuité des services des TI

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. Formaliser un processus

Formaliser un processus : Les concepts La dynamique d’un processus Activités, 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

Formaliser un processus : Les concepts La dynamique d’un processus Activités, 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 : Les concepts

La modélisation d’un processus nécessite de formaliser les éléments du schéma :

32


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


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


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

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

Activités, participants et livrables

Une activité produit toujours un résultat, sinon, elle décrit un traitement inutile

Pour produire ce résultat, 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. 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, le changement d’état d’un livrable peut être « accompagné » d’un livrable complémentaire (par ex.un devis détaillé)

Une activité produit toujours un résultat, sinon, elle décrit un traitement inutile

Pour produire ce résultat, 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. 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, le changement d’état d’un livrable peut être « accompagné » d’un livrable complémentaire (par ex.un devis détaillé) 38

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)

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


40


Une activité peut regrouper plusieurs autres activités (sous-activités, tâches, etc.) 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é)

Une activité peut regrouper plusieurs autres activités (sous-activités, tâches, etc.) 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

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é, 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.

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é, 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

Cycle de vie d’un livrable

Afin de suivre son évolution dans le flux d’activités du ou des processus, ITIL (et la formalisation des processus) définit la notion de cycle de vie du livrable.

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 déclenché une activité

La formalisation des cycles de vie des livrables permet la mise en place d’outils de workflow

Afin de suivre son évolution dans le flux d’activités du ou des processus, ITIL (et la formalisation des processus) définit la notion de cycle de vie du livrable.

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 déclenché une activité

La formalisation des cycles de vie des livrables permet la mise en place d’outils de workflow

43

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 !

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

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

46

Licences logicielles-Demande d'audit

Un exemple de cycle de vie plus complexe

47

Exemple de représentation d’une activité

Processus : Retirer une somme en espèces au guichetActivité : 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

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

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 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)

– Résumé du contenu du processus• é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

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)

– Résumé du contenu du processus• é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

51


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)

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


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

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


La forme de base des documents :– Très souvent Microsoft Word et Visioforme impossible à utiliser lorsque l’on envisage de mettre en place

un cycle d’amélioration continue des processusforme 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 informationsinconvénients de ces outils : très lourds, très complexes, très

coûteuxdevront ensuite pouvoir générer une version lisible du livrable de

modélisation de chacun des processus3 grands du marché : Aris Toolset, Casewise, Mega Process

La forme de base des documents :– Très souvent Microsoft Word et Visioforme impossible à utiliser lorsque l’on envisage de mettre en place

un cycle d’amélioration continue des processusforme 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 informationsinconvénients de ces outils : très lourds, très complexes, très

coûteuxdevront ensuite pouvoir générer une version lisible du livrable de

modélisation de chacun des processus3 grands du marché : Aris Toolset, Casewise, Mega Process

54

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 majeurdéfinition de l’impact, de l’urgence et de la priorité d’un incidentdéploiement d’une version SAP

– recouvre une à plusieurs activités, 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)

De manière pragmatique :– décrit un déroulement de bout en bout pour traiter un sujet

spécifique:traitement d’un incident majeurdéfinition de l’impact, de l’urgence et de la priorité d’un incidentdéploiement d’une version SAP

– recouvre une à plusieurs activités, 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

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

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

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, signe qui permet de distinguer une chose, une notion, de porter un jugement d’appréciationTraduction opérationnelle, concrète et mesurable d’un objectif

IndicateurInformation associée à un critère et destinée à en observer les évolutions à intervalles définisNote : 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

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, signe qui permet de distinguer une chose, une notion, de porter un jugement d’appréciationTraduction opérationnelle, concrète et mesurable d’un objectif

IndicateurInformation associée à un critère et destinée à en observer les évolutions à intervalles définisNote : 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


Tableau de bordOutil 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

incidents, gestion des mises en production, ensemble des processus ITIL)du destinataire du tableau de bord

Tableau de bordOutil 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

incidents, gestion des mises en production, ensemble des processus ITIL)du destinataire du tableau de bord

59

L’objectif doit être :☻Simple (explicite, concret)☻Mesurable (facilement)☻Atteignable (réalisable)☻Réaliste (pertinent, adapté)☻Temporel (limité dans le

temps et revu régulièrement)


Sans objectif, pas de mesure !

Un objectif est un but visé :

L’objectif peut porter sur :– La satisfaction du client – (POUR QUI)– La conformité du produit ou

service (QUOI)– La performance interne du

processus (COMMENT)

L’objectif doit être :☻Simple (explicite, concret)☻Mesurable (facilement)☻Atteignable (réalisable)☻Réaliste (pertinent, adapté)☻Temporel (limité dans le

temps et revu régulièrement)

Sans objectif, pas de mesure !

Un objectif est un but visé :

L’objectif peut porter sur :– La satisfaction du client – (POUR QUI)– La conformité du produit ou

service (QUOI)– La performance interne du

processus (COMMENT)

60


Sans mesure, pas d’amélioration !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.

Le processus est efficace s’il atteint son objectif.

Pour y arriver il faut le piloteret engager des actions d’amélioration.

Fréquence

61

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.

Le processus est efficace s’il atteint son objectif.

Pour y arriver il faut le piloteret engager des actions d’amélioration.

TailleMesures

Indicateurs


Les trois types d’indicateurs :

62


63


En pratique :1. Lister les objectifs à atteindre pour le processus2. Traduire les objectifs en critères de succès

(mesurables)3. 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. (Définir les tableaux de bord) : Destinataires, contenus et présentations

En pratique :1. Lister les objectifs à atteindre pour le processus2. Traduire les objectifs en critères de succès

(mesurables)3. 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. (Définir les tableaux de bord) : Destinataires, contenus et présentations

64