La Gestion Des Processus Métiers

La gestion
des processus métiers

L’alignement des objectifs stratégiques de l’entreprise
et du système d’information par les processus
�
étude numéro 9
La gestion
des processus métiers
L’alignement des objectifs stratégiques de l’entreprise
et du système d’information par les processus
par Jean-Noël GILLOT
étude numéro 9
La gestion des processus métiers - mars 2011 - N° 9 - Best Practices Reseach • 3

www.processus-metier.fr
Imprimé en Italie : Pixart.it

BEST PRACTICES INTERNATIONAL
SARL au capital de 21 000 euros – RCS Versailles 503 117 988 RCS
Pavillon Sisley, rue de la Croix-Rouge, 78430 LOUVECIENNES
Tél. : +(33) (0)6 75 64 63 97 – Email : information@bestresearch.fr
© Navigacom, Best Practices International, 2010
Reproduction interdite – Tous droits réservés
Toute utilisation des informations contenues dans cette étude à des fins commerciales ou de
communication est interdite sans un accord écrit de Best Practices International.
Le code de la propriété intellectuelle n’autorisant, aux termes de l’article L. 122-5, d’une part, « les copies
ou reproductions strictement réservées à l’usage privée du copiste et non destinées à une utilisation
collective » et, d’autre part, que les analyses et les courtes citations dans un but d’exemple et d’illustrations,
« toute représentation ou reproduction intégrale, ou partielle, faite sans le consentement des auteurs ou
de ses ayants droits ou ayant cause, est illicite » (Article L. 122-4). Cette représentation ou reproduction,
par quelque moyen que se soit constituerait donc une contrefaçon sanctionnée par les articles L. 335-2 et
suivants du code de propriété intellectuelle. »
4 • Best Practices Research - N° 9 - mars 2011 - La gestion des processus métiers

« Dans toute idée, il faut chercher à qui elle va et de qui elle vient ;
alors seulement on comprend son efficacité »
Bertolt BRECHT

Sommaire
Remerciements 12
Preface 13

1. Introduction 14
A qui s’adresse cet ouvrage 15
Définitions 15
Un peu d’histoire 16
Ce qu’est le Business Process Management 17

2. Du processus metier au bpm 22
Les 4 perspectives du Business Process Management 22
La perspective : « Métier » 23
La perspective : « Organisationnelle » 23
La perspective : « Processus» 23
La perspective : « Technologies » 24
L’adoption du BPM 24
La maîtrise des enjeux 25
L’agilité 26
L’adaptabilité 26
L’optimisation 27
Le reengineering de processus 27
La rentabilité 27
L’alignement de la stratégie et du Système d’Information 28
Le positionnement compétitif 28
L’amélioration ou l’adhésion à des critères de qualité 28
Les bénéfices du Business Process Management 29
Augmenter les bénéfices 29
Améliorer la gestion de l’entreprise 29
Diminuer les coûts et accroître l’efficacité 30
Améliorer la qualité de service 30
Augmenter l’adaptabilité, la flexibilité et l’agilité 30
Diminuer les coûts de développement et de support 31
Diminuer les risques liés à l’implémentation de nouveaux systèmes 31
Améliorer la gouvernance 32
Faciliter la mise en conformité 32
Stabiliser certains processus de l’entreprise 32
Identifier les processus candidats à l’externalisation 32
Analyser le comportement des clients et des partenaires 33
L’organisation de l’entreprise 33
Rôles et responsabilités nécessaires au BPM 34
Les responsabilités du métier 34
Les responsabilités de l’IT 35
Les responsabilités partagées entre le métier et l’IT 35
Les nouveaux rôles nécessaires au BPM 36
La conduite du changement 36
L’efficacité du pilotage opérationnel 37
Le « Sponsorship » et le « Leadership » 38
La résistance au changement 38

La démarche de la conduite du changement 39
La phase de cadrage 41
L’actuel 41
La Cible 41
La stratégie d’accompagnement 41
La conception de l’accompagnement 42
La réalisation 42
Le pilote 42
La pérennisation 42
Les composants de la conduite du changement 43
Quelques bonnes pratiques 43
Pas de succès sans démarche processus pragmatique 44
Les 4 grandes familles de processus 44
Les processus d’ « intégration » 45
Les processus « humains » ou « collaboratifs » 45
Les processus « décisionnels » 46
Les processus « documentaires » 46
Processus verticaux et horizontaux ou transverses 46
Les approches Top-Down et Bottom-Up 47
Approche Top-Down 48
Approche Bottom-Up 49
Approche mixte : Topup 49
La candidature des processus 51
Le Cycle de vie du BPM 51
Conception & formalisation 51
Exécution des processus 53
Gestion & supervision 53
Analyse et optimisation 54
Des itérations successives 55
3. Amelioration et qualite des processus 56

TQM : Total Quality Management 57
HPT : Human Performance Technology 59
SCOR: Supply Chain Operations Reference model 60
LEAN Manufacturing 61
CMM : Capability Maturity Model 63
Six Sigma 65
La définition d’un processus par Six Sigma 66
Les rôles nécessaires à Six Sigma 67
Les types de processus 68
La démarche DMAIC 69
Phase « Define » 71
Phase « Measure » 72
Phase « Analyse » 73
Phase « Improve » 76
Phase « Control » 76
Les points d’accostage entre Six Sigma et le BPM 77
Lean Six Sigma 78
Les normes ISO9000 80
Les niveaux de maturités 80
Le degré de maturité global 80
Le degré de maturité des processus 82
Le degré de maturité de l’intégration du SI 83
4. Modelisation, analyse & optimisation 84

Les étapes de la formalisation des processus 84
Le référentiel des processus 85

La cartographie des processus 86
La conception d’un processus 87
La modélisation 89
L’organisation 90
Le processus et ses exceptions 90
Les fonctions 91
Les données 91
L’outil de BPM 91
La représentation UML 91
La représentation BPMN 93
Les représentations spécifiques 94
La documentation 94
La fiche d’identité d’un processus 95
Le descriptif détaillé 95
La nature des activités 95
La notion de temps 95
Les documents attachés 96
Les données 96
L’organisation 96
Processus courts ou processus longs ? 97
La fréquence, volumétrie et disponibilité 97
Le niveau de détail de la documentation 97
L’analyse et optimisation 97
Le benchmarking de processus 100
L’architecture des processus 101
L’implémentation 102
Reengineering ou amélioration de processus ? 103
La classification des processus 104
5. Integration, workflow et BPM 106

L’intégration et le concept de l’EAI 106
Le B2B et le B2C 107
L’automatisation des processus métiers 111
Complémentarité EAI/BPM 111
Les outils de Workflow 112
La définition des processus 114
La corbeille de tâches 115
Le transfert de tâches 115
Les fonctions d’intégration 116
La gestion des utilisateurs, des rôles et des groupes 116
Les outils de modélisation et de simulation des processus 117
Le référentiel de processus 117
Les règles métiers 117
Exceptions 118
Procédures de compensation 118
Le rôle de la simulation de processus 118
Les moteurs de règles 118
Les outils de BPM 119
Le BPM et le modèle OSI 119
Les évolutions du marché 120
Le BPM et le logiciel libre 122
Les standards de notation, référentiel et exécution 122
Les processus : véritable patrimoine de l’entreprise 124
La qualité des données des processus 124
6. Le pilotage des processus 125

Le pilotage des processus 125
La mesure des processus 125

La prédictibilité des indicateurs 126
Le suivi des processus 127
Les indicateurs clés de performance (KPI) 128
A chacun ses indicateurs 130
Identification et pertinence des KPI’s 131
Les tableaux de bord 132
Les 3 types majeurs de tableaux de bord 133
Tableaux de bord opérationnels 133
Tableaux de bord tactiques 134
Tableaux de bord stratégiques 135
La « Balanced Scorecard » 135
Balanced Scorecard ou Tableau de bord ? 137
Les technologies OLAP 137
Le CEP, le BEM et EDA 138
Le CEP 138
Le BEM 139
Le drill-down, drill-up et drill-through 139
L’ergonomie des tableaux de bord 140
Le pilotage de la performance opérationnelle 141
Le pilotage opérationnel des services métiers 142
SLA et SLM 143
7. Les solutions de BPM 144

Les principaux avantages d’une suite BPM 144
Le Moteur de BPM 145
Les Typologies d’outils 145
L’outil de BPM : Accompagnateur de la démarche 146
Le choix d’un outil de BPM 146
Les fonctionnalités d’un outil de BPM 147
L’intégration 147
Le routage 148
Les formats des messages 148
Les formats pivots 148
La transformation 149
Le transcodage 149
La traçabilité de bout en bout 150
Un interfaçage normalisé (connecteurs & adaptateurs) 150
La gestion des messages (Message Broker) 151
La publication/souscription de messages 151
La supervision 152
L’Administration 153
La sécurité 153
Les patterns de processus 153
La séquence 153
Le Split 154
La jointure 154
La jointure synchronisée 154
Les choix multiples 155
Le XOR 155
La notion de Cycle 155
Fin de processus explicite ou implicite 156
Annulation du processus 156
Annulation d’une activité du processus 156
Activités multiples sans synchronisation 157
événement remarquable 157
Multi instances d’activités 157
Activités parallèles non ordonnancées 158

Choix manuels 158
L’automatisation des processus 158
Les sous processus 159
La gestion de corbeille 159
Les Modes de routage 159
Procédures de « rollback » ou de compensation 160
Le support d’API et de Framework 160
Les outils de développement 160
Modélisation de processus 161
Interface de création de pages et formulaires 161
Outil de Mapping 161
éditeur de Code 162
Outil de tests 162
Gestion de version 162
Outil de documentation 162
Moteur de règles 163
Le référentiel des processus 164
Gestion des exceptions 165
Les interfaces utilisateurs 165
Les interfaces d’administration 165
Les interfaces utilisateurs 166
L’environnement de développement 166
Une architecture web 167
La supervision 167
Le suivi et pilotage des processus 167
La gestion d’agenda 168
Le lien entre le BPM et la SOA 168
La cohabitation du BPM, de la SOA et de l’ancien 169
Les services Web 169
L’annuaire de services 171
La granularité des services web 172
L’orchestration de Services Web et le BPM 172
L’évaluation de la solution 173
Les critères d’évaluation 173
Les activités manuelles 173
La modélisation et simulation de processus 174
Patrons, modèles, flux, services et règles 174
Interface utilisateur et gestion de contenu 174
Support de travail collaboratif 174
Intégration au système informatique 175
Supervision de la performance opérationnelle 175
Simulation en mode réel, optimisation et modélisation prédictive 175
Gestion des règles et polices métiers 175
Matrice d’évaluation 175
L’outil de BPM 176
La suite BPM 176
La zone de différenciation 176
Méthodologie d’évaluation 177
La pondération des catégories 177
8. La valeur de la gestion des processus 178

Le ROI et TCO 179
Le « Total Cost of Ownership » : TCO 179
Le « Return On Investment » : ROI 180
Les sources de ROI 181
L’automatisation 182
L’optimisation 182
Le management 183
La qualité 183
La conformité 183
L’Activity Based Costing (ABC) et le BPM 184
La démarche ABC 184
Analyser les activités 185
Collecter les coûts 185
Lier tous les coûts aux activités 185
Définir les mesures 186
Analyser les coûts 186
L’analyse de la valeur et les processus 186
L’alignement du métier et du système d’information 187
La gouvernance des processus 188
Le positionnement concurrentiel 190
Glossaire 192
Table des illustrations 199

Bibliographie 202
Ouvrages 202
Sites web 202

A propos de l’auteur 204

Remerciements
Il est compliqué de savoir dans quel ordre et comment remercier toutes les personnes qui ont
contribué à l’aboutissement de mon projet. Ce fut une expérience riche d’enseignements et
d’échanges.
Je tiens à remercier tout particulièrement :
• Patrick Duboisset, Directeur Général de la Société NeoVision Group, avec qui j’ai eu le plaisir de
partager des aventures très enrichissantes et qui m’a d’une part supporté dans mon projet et d’autre
part relu et challengé.
• Zine El Abidine El Amrani, qui de son œil critique, vérifie certains éléments très techniques et
avec tout son tact, m’a fait partager des accords et désaccords.
• Patricia Jardin, qui a certainement eu du mal à me relire tellement mes idées, mal formulées au
départ, ont dû être difficiles à comprendre d’autant que l’informatique lui est presque inconnue. Mais
surtout, merci de sa patience pour les soirées et week-ends que nous n’avons pas partagé pour que je
puisse rédiger cet ouvrage.
A toutes ces personnes, je dis un grand merci. Cette aventure a été pleine d’imprévus mais très
constructive. Ce que je retiens tout particulièrement, c’est le partage qui a eu lieu de ma passion, de
mes craintes, de ma vision.
Toutes les idées, graphiques et tableaux n’engagent que moi et ne sont que la représentation de ma
vision totalement personnelle.
Préface
La gestion des processus métiers existe depuis longtemps. La forte compétitivité demandée aux entreprises
leur impose d’optimiser leurs processus. Oui mais, avant d’en permettre leur optimisation il faut bien
les connaître.
Une chose qui m’a toujours frappée, c’est le manque de méthodologie et de maîtrise de projets autour
de la gestion des processus. Mais y a-t-il une méthode miracle ? Non, bien évidemment et sans aucun
doute, sera-t-il nécessaire de choisir des parties de méthodes pour couvrir les besoins de son entreprise.
Un autre point important est le facteur humain. C’est d’ailleurs le plus important. Lorsque vous devez
comprendre comment un processus de l’entreprise fonctionne vous devez avant tout avoir une démarche
collaborative. Je viens de vivre une expérience où certains acteurs se plaisaient à penser que nous allions
remplacer une partie d’un département existant. Bien au contraire, il a fallu accompagner les acteurs
et les faire travailler ensemble pour comprendre et avoir une vision partagée du processus et de son
fonctionnement. Le mode très « collaboratif » que nous avons utilisé nous a été bénéfique lorsque nous
avons été confrontés aux résistances d’acteurs et que nous les avons utilisées comme vecteur d’adhésion.
Mais ne croyez pas non plus que le concept soit miraculeux.
Un autre exemple. Un client nous choisit pour formaliser, analyser, optimiser et contrôler ses processus
métiers. A la base le choix est principalement fondé sur quelques exemples d’outils présentés. Erreur ! Les
outils ne sont rien s’ils ne sont pas un minimum adaptés au contexte dans lequel ils doivent être utilisés.
Par ailleurs, l’interprétation faite peut s’avérer inadéquate sans prendre un minimum de recul.
Institutionnaliser une démarche de gestion des processus est également important. Certaines entreprises
aujourd’hui le font en communiquant sur les chantiers lancés à cet effet. D’autres s’appuient sur la mise
en place de centres de compétences dédiés à cette gestion.
C’est pourquoi ce livre est tout d’abord un guide permettant de comprendre et de démystifier toutes les
facettes de cette discipline complexe. Trop d’écrits ont apportés une certaine confusion, chacun des acteurs
prônant sa méthode plutôt qu’une autre. Probablement que chacun d’entre eux a un peu raison.
Que vous débutiez par le pilotage de la qualité de service de vos processus, ou par l’optimisation de
certains de vos processus voir de l’externalisation de certains d’entre eux, vous aurez, par la force des
choses, à utiliser des techniques et des méthodes s’adaptant à votre contexte. De votre qualité d’écoute
dépendra le succès de vos projets. Tout le monde n’a pas la une capacité d’écoute de qualité. Un jour, un
des consultants d’un projet me dit : « on a l’impression d’être un psychologue qui écoute les problèmes
de son patient ». C’est tout à fait ça ! Il faut mettre à l’aise les acteurs avec qui on doit d’une part écouter
individuellement les acteurs tout en proposant des solutions par consensus. Compliqué non ? Vous
pouvez avoir toutes les meilleures méthodes du monde, votre projet peut être voué à l’échec.
Cet ouvrage n’est pas constitué de remèdes miracles. C’est avant tout un guide qui vous permettra de
comprendre comment gérer le cycle de vie d’un processus de bout en bout et d’identifier des alternatives
à son optimisation. Pour terminer, vous pourrez utiliser des techniques et outils permettant d’identifier
les technologies et techniques les plus appropriés à votre contexte.
Bien entendu, les technologies évoluent rapidement, mais n’oubliez jamais qu’elles ne sont qu’un
facilitateur de la démarche. C’est pourquoi j’ai tenté de mêler des exemples de mes expériences pour
apporter tout le pragmatisme nécessaire à cet ouvrage. La gestion des processus fait partie des chantiers
de ces prochaines années et prendra toute sa place dans la culture de l’entreprise. Sans elle, les entreprises
ne pourront rester compétitives ni « mettre en valeur » leur talent.
Jean-Noël GILLOT

1. Introduction
Le Business Process Management (Gestion des processus métiers) existe depuis bien des années, sans
être nommé en tant que tel. Les nouvelles méthodes, les nouveaux outils et les nouvelles technologies
qui existent aujourd’hui font que cette discipline a bien évolué. Elle va désormais jusqu’à la gestion
du cycle de vie complet des processus. Cet ouvrage décrit ce qu’est le BPM(*), les principales étapes
de cette discipline, les outils associés et leur provenance ainsi que leur contribution à l’alignement des
objectifs stratégiques de l’entreprise et du système d’information.
Devant l’accroissement de la concurrence, qui peut réduire à néant toute entreprise quelle qu’en soit
la taille, les dirigeants cherchent la manière d’améliorer l’efficacité de celle-ci tant sur un point de vue
financier que sur sa capacité à être réactive pour faire face à l’évolution très rapide de son écosystème
et des aléas du marché.
De plus, des méthodes d’amélioration de la qualité ont vu le jour ces 20 dernières années. Nous allons
survoler ces méthodes et tenter de voir comment elles peuvent être complémentaires d’une démarche de
BPM. Un des principes de base du management est de ne pouvoir apprécier que ce qui est mesurable et
le BPM apporte non seulement la traçabilité et le pilotage des processus de l’entreprise mais également
le niveau de mesure nécessaire à l’identification de problèmes potentiels au sein d’un ou plusieurs
processus de l’entreprise. Certains produits du marché pourront même apporter un certain niveau de
prédictibilité(*) permettant ainsi d’alerter des acteurs de dysfonctionnements (ou dégradations) en cours
d’un processus pouvant entraîner la rupture totale d’un des critères qualité mesuré et potentiellement
apprécié directement par les clients et donc impactant soit le chiffre d’affaire, soit la marge de l’entreprise
ou bien encore, la satisfaction client.
Nous allons tenter d’expliquer ce qu’est le Business Process Management et comment une entreprise
peut en tirer le meilleur parti. Vous trouverez de premières pistes d’investigations sur le retour sur
investissement probable (ROI(*)) du BPM ainsi que les pistes pour le maximiser. Pourquoi probable ?
Tout simplement parce qu’en fonction de la conduite de la démarche de BPM dépend le niveau de ROI
effectivement constaté. Nous verrons que le BPM implique de s’appuyer sur une démarche complète
et que des outils doivent accompagner cette démarche tout en utilisant de la méthodologie à plusieurs
niveaux (processus, tableaux de bord, implémentation technique, etc.).
• Certaines briques technologiques au sein du système d’information existent-elles déjà ?

• Comment les différentes technologies utilisées au sein du système d’information se trouvent
être complémentaires ?
• Comment peuvent-elles contribuer à une meilleure efficacité de l’entreprise, et à une
meilleure qualité des produits et services ?
• Comment peuvent-elles contribuer à une meilleure satisfaction client ?
L’informatique occupe une place prépondérante dans l’entreprise et la mise en place d’outils de BPM
doit se faire sans oublier qu’ils doivent pouvoir s’adapter aux besoins des utilisateurs qui, au jour le
jour, doivent adresser au mieux les besoins des clients et partenaires de l’entreprise.
Le Business Process Management répond en tout premier lieu à 3 objectifs majeurs que sont :
• La Qualité : Le BPM permet tout d’abord d’aligner la qualité de ce qui est proposé par l’entreprise
par rapport aux besoins de ses clients et partenaires en termes de qualité de ses produits et services,
et si ceux-ci ne correspondent pas, permet une réduction de l’inadéquation par rapport à ces mêmes
besoins.
• Le Délai : Les clients, aujourd’hui habitués à tout avoir dans des temps très courts, ne comprennent
pas certains délais qui sont fréquemment injustifiés. C’est pourquoi un autre des objectifs du BPM est
de réduire les délais : - d’attentes - de livraisons ou de mise à disposition sur le marché (ce que nos (*) voir glossaire
confrères américains appellent le « time to market(*) ») de nouveaux produits ou services. page 192
• Les Coûts : L’entreprise, face à ses concurrents, se doit d’être performante tant au niveau de
ses revenus qu’au niveau de sa marge. Certaines doivent même faire preuve d’efficience vis-à-vis de
leurs actionnaires au risque d’être gravement sanctionnées en bourse, et on a pu voir des entreprises
perdre plus de la moitié de leur capitalisation boursière en quelques jours, faute de bons résultats
financiers (marges, trésorerie, …). Le BPM permet de diminuer, voire d’éliminer certaines activités
classées d’improductives et d’optimiser l’utilisation de certaines ressources en les faisant contribuer à
des activités à plus forte valeur ajoutée.
Cet ouvrage a pour objectif de vous aider à maximiser les bénéfices lors de la mise en place d’une
démarche de Business Process Management et des outils associés au sein de votre entreprise.
Bien entendu, la mise en place d’une telle démarche n’est pas simple en soi, car elle fait appel à divers
ingrédients qui, comme pour une recette de cuisine, lorsqu’ils sont apportés en trop forte ou trop faible
quantité, peuvent faire échouer la démarche. Néanmoins, ce qui vous est présenté est basé aussi bien :
sur des réussites que sur des échecs; et c’est certainement ce pragmatisme qu’apporte cet ouvrage.
A qui s’adresse cet ouvrage

Il s’adresse tout d’abord à toute personne qui souhaite savoir ce qu’est le Business Process Management
et quels outils on peut y associer.
Ensuite, il apporte des réponses sur les principes qui permettent d’aligner le métier et le système
d’information pour répondre au mieux à la stratégie de l’entreprise permettant ainsi d’atteindre
les objectifs stratégiques visés; l’informatique servant de véritable levier. Nous allons voir que la
communication entre maîtrise d’ouvrage et maîtrise d’œuvre est essentielle ; et que sans accompagnement
minimum, les délais de mise en œuvre de la démarche pourraient être beaucoup plus longs que ce qui
est escompté.
Ce Chapitre S’adresse à
1. Introduction DG, DSI, Directeur métier ou fonctionnel, architectes,
consultants
2. Du processus métier au BPM DSI, Directeur métier ou fonctionnel, architectes,
consultants
3. Amélioration et qualité des processus DSI, Directeur métier ou fonctionnel, responsable qualité,
architectes, consultants
4. Modélisation, analyse et optimisation Directeur métier ou fonctionnel, architectes, consultants
5. Intégration, Workflow et BPM Architectes, consultants
6. Le pilotage des processus DG, DSI, Directeur métier ou fonctionnel, architectes,
consultants
7. Les solutions de BPM DSI, Responsable fonctionnel, architectes, consultants
Erreur ! Source du renvoi introuvable.de DG, DSI, Directeur métier ou fonctionnel, consultants,
la gestion des processus responsable des achats
Figure 1 : Profils des lecteurs par chapitre
Il était important également de positionner le BPM car par trop de battage médiatique, une grande
confusion règne et il fait faire la distinction entre outils et discipline. Par ailleurs, il est nécessaire de
bien définir ce à quoi nous allons nous rapporter : Est-ce de la modélisation ? de la performance ? ou
des processus de l’entreprise ? Nous croyons trop souvent à tort que nos interlocuteurs connaissent les
termes et acronymes employés.
Définitions
Le BPM est avant tout une discipline : Ensemble des règles, des obligations qui régissent certains corps
ou collectivités ; règlement. La discipline militaire. Manquer, se plier à la discipline (définition issue
du Larousse).

Un processus(*) métier est un enchaînement ordonné d’activités, qui se déroulent en série ou en
parallèle, qui sont exécutées par des personnes ou par des applications (activités manuelles, semi-
automatiques ou automatiques) et qui aboutissent à un résultat attendu. Un processus se caractérise
par un événement déclencheur en entrée, suivies d’activités permettant de construire un résultat et le
résultat final (sortie) attendu par le bénéficiaire.
Le Business Process Management (gestion des processus métiers) est une discipline qui comprend
4 axes principaux :
• La modélisation des processus : représentation graphique des processus
• L’automatisation des processus : pour ce qui est automatisable et intégrable
• La gestion des processus : états des processus et cycle de vie
• L’optimisation : amélioration des processus basée sur des métriques réelles de performance
des processus
Cette discipline permet de gérer et d’améliorer les processus de l’entreprise durant leur cycle de vie,
et s’accompagne de la mise en place d’outils permettant de modéliser, intégrer, superviser et analyser
le fonctionnement des processus. Le BPM apporte une méthode permettant de comprendre comment
optimiser ces processus. Elle nécessite des profils pluridisciplinaires tels que l’expertise métier, le
développement d’applications en passant par de l’architecture et le conseil en technologies.
Une démarche de Business Process Management doit permettre, à minima, un accompagnement ayant
pour objectif de garantir une bonne profitabilité d’une activité de l’entreprise voire de l’améliorer et
même d’améliorer l’efficacité de l’entreprise dans son ensemble.
Un peu d’histoire
L’histoire des processus a débuté avec Frederick Winslow Taylor qui développa en 1903 sa théorie de
l’organisation scientifique du travail dans son ouvrage « Shop Management ». Henry Ford s’en inspire.
Il devient le premier à lancer l’industrialisation de la fabrication des automobiles. A cette époque, une
automobile était un produit de luxe, et Henry Ford a souhaité la voir se démocratiser, à condition
que son prix et le volume de fabrication, soient en adéquation avec la taille du marché d’une part, et
le pouvoir d’achat des classes plus modestes d’autre part. Il est vrai que d’un modèle « sur mesure » il
fallait passer à une production « à la chaîne » permettant ainsi de produire dans des quantités nettement
plus importantes. Si l’on revient à la théorie du Taylorisme, l’idée principale était de décomposer les
activités, de minuter les gestes des employés et d’en trouver de nouveaux permettant de diminuer les
délais d’exécution des activités. Cela ne vous rappelle rien ? Bien entendu, le Taylorisme va largement
au-delà de l’optimisation des simples activités pour aller jusqu’au Management de l’entreprise. Toujours
dans sa théorie, il soutient le fait que l’implication de chaque individu concourt au bon fonctionnement
général de l’entreprise. Donc, quand Henry Ford comprend tous les bienfaits que peut apporter cette
théorie au secteur de l’automobile, il décide de lancer la Ford T fabriquée en grande série et sans aucune
possibilité de modifier les options. Henry Ford ne vend pas moins de 15 millions de véhicules entre
1908 et 1927.
C’est à ce moment que de nombreux industriels décident de prendre les méthodes de Henry Ford
comme exemple et de les généraliser à leurs propres industries et appliquent le principe d’optimisation
des activités répétitives.
Depuis, les principes sont restés les mêmes. On prend le processus, quel qu’il soit, on le décompose en
activités, on identifie les indicateurs de performance permettant de le mesurer et de le piloter, et après
un certain temps de fonctionnement, on analyse ses possibilités d’optimisation. Mr Taylor a utilisé
cette démarche. Depuis, les outils et les méthodes ont évolués pour aller vers des niveaux de perfection
rarement égalés auparavant.
Le Docteur Armand V. Feigenbaum écrit alors un livre en 1951 sur le contrôle de la qualité de ce qui
est produit et de l’optimisation des processus associés : “Quality Control: Principles, Practice, and
Administration”. Il sera réédité en 1961 sous le titre « Total Quality Control ». En 1980, W. Edward
Deming va tenter d’introduire le sujet du Total Quality Management aux Etats-Unis en se basant sur des
travaux de qualité initiés en 1946 au Japon mais dont la traduction a été critiquée. Un peu plus tard, (*) voir glossaire
sa cousine Six Sigma a vu le jour pour également permettre d’améliorer les processus de l’entreprise page 192
et est basée sur un niveau de qualité calculé à partir de statistiques. Les années 80 voient naître des
méthodes qualité comme TQM puis Six Sigma un peu plus tard qui apportent la notion de mesure
de la qualité. Nous reviendrons d’ailleurs sur les méthodes qualité qui sont importantes dans notre
discipline du BPM. Hammer et Champy écrivent un livre 1993 : « Reengineering the corporation » qui
traite de la reconsidération de l’organisation et des processus associés pour atteindre des améliorations
de performance, de qualité de service et de rapidité avec des réductions de coûts très importants. Nous
sommes dans l’ère du reengineering de processus métiers.
En 2002, Smith et Fingar écrivent un livre « Business Process Management : The Third Wave » et
expliquent que le Business Process Management de troisième génération est né et qu’il consiste en trois
composants que sont : l’automatisation, les processus métiers et la gestion de la qualité. Ils expliquent
notamment que les trois composants doivent être conduits ensemble pour garantir l’efficacité des
processus métiers.
Aujourd’hui le BPM prend de l’essor, et les entreprises peuvent bénéficier d’une démarche complète et
outillée qui, si elle est bien menée, peut permettre une meilleure compétitivité et un niveau d’excellence
opérationnelle jusqu’alors rarement atteint.
Cequ’est le Business Process Management

Toute entreprise utilise aujourd’hui des processus, appelés procédures et souvent à tort, qui décrivent
comment l’entreprise effectue ses diverses activités. Certains de ces processus sont très critiques voire
essentiels au fonctionnement d’une entreprise et sont clés dans la compétitivité de celle-ci. D’autres
sont moins critiques, mais tout aussi importants pour ceux qui les utilisent au sein de l’entreprise. Ils
peuvent avoir besoin d’être optimisés pour permettre d’améliorer les conditions de travail, l’efficacité
des collaborateurs, ou encore pour leur permettre ainsi de se concentrer à des activités à plus forte
valeur ajoutée.
Néanmoins, un grand nombre d’entreprises n’a pas formalisé ses processus métiers et doit passer
par une phase dite de « modélisation » et de documentation avant d’utiliser un outil de BPM pour le
pilotage des processus.. C’est le cas en particulier lorsque l’entreprise est confrontée à des problèmes
de croissance, de rentabilité, et de compétitivité. La formalisation va également pouvoir se faire lors de
la mise en place d’une démarche de Business Process Management.
Nous verrons également qu’au sein de ces processus nous pouvons avoir des activités qui sont exécutées
soit par des personnes (internes ou externes à l’entreprise), soit par des applications et que ces parties de
processus appelés « sous-processus » sont soit manuels, soit semi-automatiques ou encore automatiques
(pour certains). La bonne définition des processus métiers est vitale à la bonne marche de l’entreprise
comme la bonne santé l’est au corps humain pour le bien être de toute personne. Il est donc nécessaire
que les processus et leurs composants soient clairement définis, qu’ils soient réactifs, que les données
véhiculées soient pertinentes et qu’ils soient suffisamment agiles pour permettre d’êtres optimisés dans le
futur. Bien entendu ceci implique que la démarche soit itérative et permette une constante amélioration
de ces processus.
L’agilité de l’entreprise, pourra se mesurer à sa capacité de faire face au changement, et à sa réactivité

pour changer ses processus et ce afin de répondre à ses pré-requis économiques.
Des exemples de processus métiers pourraient être :

• La prise de commande - Comment les commandes des clients sont prises en compte du début à
la fin et quels produits on peut proposer au client en association avec celui demandé
• La gestion des sinistres - Comment les sinistres automobiles sont traités au sein d’une
compagnie d’assurance et quels services associés sont proposés en fonction du niveau de garantie
que le client a souscrit (véhicule de remplacement, rapatriement, …)
• La souscription de crédits à la consommation - Comment une banque traite une demande
de crédit avec ses règles et ses sous-processus d’approbation. Quelles sont les règles de
dérogation ? Quelles offres sont proposées en fonction de quels montants ?
• La gestion des congés - Comment une entreprise traite les demandes de congés depuis leur
saisie par les employés jusqu’au décompte en passant par la validation par la hiérarchie

• L’activation d’une ligne Internet haut débit - Comment un opérateur Télécom traite une
activation de ligne : depuis sa commande par un utilisateur final, jusqu’à la mise en route de la
ligne, en passant par les installations et paramétrages nécessaires.
Ces quelques exemples de processus métiers permettent de comprendre la valeur ajoutée du BPM et
les possibilités d’évolutions que proposent ses outils par l’amélioration et l’optimisation des processus
métiers de l’entreprise qui jusqu’à aujourd’hui ont rarement été à ce niveau de concrétisation.
La formalisation des processus métiers va permettre d’identifier des activités, règles, acteurs et systèmes
qui sont utilisés pour rendre un service, créer un produit, produire de l’information à destination de
clients et gérer les partenaires. Le Business Process Management va permettre, par l’utilisation d’une
démarche et des outils associés, de formaliser, de documenter et d’automatiser tout ou partie de processus
métiers, afin d’apporter flexibilité, traçabilité et mesure. De l’outil choisi dépendra également la qualité
de service rendu pour l’exécution et la mesure de l’efficacité des processus. Bien sûr, on pourra simuler
les processus métiers par le biais d’outils, mais rien ne pourra remplacer la mise en place d’un outil
paramétré dans l’environnement de production pour recueillir des données historiques et permettre
ainsi d’être plus proche de la réalité.
La méthodologie permettant de gérer et d’améliorer les processus a une place prépondérante et la difficulté
résidera dans le choix de celle-ci qui, très probablement, sera au final un mixe de plusieurs méthodes ou
proviendra de l’allègement de certaines parties d’une méthode. Dans ce vaste choix de méthodologies
pour la qualité et l’amélioration des processus, on peut citer des méthodes comme CMMI (Capability
Maturity Model Integration), Six Sigma, Lean, SCOR (Supply Chain Operations Reference-model), HPT
(Human Performance Technology) sans oublier ISO 9000 et ses dérivées.
Toutes ces méthodologies traitent de qualité ou d’amélioration de la qualité des processus, ou proposent
un référentiel de processus normalisés dans un domaine particulier (comme SCOR). Elles peuvent être
utilisées dans un spectre plus large mais nécessiteront, très certainement, des travaux pour permettre
leur application au contexte de l’entreprise car trop souvent génériques. Nous verrons quelles méthodes
sont les plus courantes et nous ferons d’ailleurs un zoom sur Six Sigma qui est, certainement, l’une des
méthodes qui se trouve la plus souvent utilisée dans la discipline du BPM. Elle traite de l’amélioration
continue des processus métiers de l’entreprise.
Une autre chose à ne pas oublier dans le BPM : le B de Business (le métier). Souvent une confusion
règne entre des processus techniques d’échanges et des processus métiers. N’oublions pas que l’objectif
principal du BPM est de définir et documenter les processus métiers de l’entreprise en utilisant des outils
logiciels pour comprendre comment les processus fonctionnent et comment ils pourront être améliorés.
Les processus d’échanges, même si des règles, plus ou moins complexes, sont mises en œuvre, ne
concernent qu’une gestion de données, leurs transformations et leur transport d’un point à un autre.
C’est ce que l’on appelle « l’intégration par les données de l’entreprise ». Cette notion de transport de
données est une des composantes de tout outil de BPM, mais le plus important reste l’objectif métier
du processus, les moyens de l’améliorer et de le rendre plus efficace. Par ailleurs, les processus métiers
ne pourront être améliorés qu’en maîtrisant les enjeux métiers associés et c’est certainement l’une des
difficultés car trop souvent les enjeux sont peu ou pas maîtrisés. Mais dans un marché où la multitude
d’outils rend plus complexe le choix de l’outil de BPM le plus approprié à son contexte, il est important
de faire appel à une démarche ayant pour objectif un choix d’outil approprié tout en prenant en compte
correctement et sans superflu des besoins métiers et des contraintes du système d’information et c’est
là toute l’essence de l’alignement du métier et du système d’information par les processus.
Nous allons passer en revue des outils comme le workflow(*), l’EAI(*), les outils de supervision et
de tableaux de bord ainsi que les outils de Business Process Management qui intègrent tout ou partie
de ces outils, de manière à décrire leurs différences et comprendre quelles fonctionnalités ils mettent
à disposition pour gérer les processus de l’entreprise. De plus, nous allons voir que tous ces outils
convergent vers des outils de Business Process Management plus complets appelés « Business Process
Management Suites », pour leur large spectre de fonctionnalités et en particulier pour la gestion du
cycle de vie des processus de bout en bout.
(*) voir glossaire
page 192
Une suite BPM est constituée de 4 éléments principaux que sont :
• La modélisation pour décrire les processus, les documenter et les simuler
• L’intégration pour s’intégrer au système d’information et bénéficier de l’accès aux
informations nécessaires aux processus (données, état d’avancement informatique des activités,
la gestion des exceptions, …)
• Le workflow dit « humain » (on parle également de travail collaboratif) pour permettre la gestion
d’activités manuelles ou semi-automatiques et accessibles, voire administrables, via une interface
utilisateur de type « client léger(*) »
• Les tableaux de bord qui apportent le suivi d’un processus métier et de ses activités ainsi que
des tableaux de bord et indicateurs associés.
n
n In
tio
io té
In
at gr
sa
té
lis at
é
gr
io
éli
od n
at
od
M
io
M
n
BPM
M
ét
riq
ue
ta
M au
n
s
bl
ét x d
io
e w
e
riq e
bo t ta lo
at
rd ble kf
or
gr
ue b
té
au W
et ord
In
x
de
Figure 2 : Composants d’une suite BPM
Voyons maintenant les différents composants d’une suite BPM.
La Modélisation : ce composant est certainement celui qui est le plus visible car il reflète ce que l’éditeur
de la solution propose : de l’ergonomie, de sa compréhension des processus et de la façon de les
modéliser dépendront la qualité de la solution et la couverture des besoins. Le niveau et la qualité du
support technique nécessaire pour utiliser l’outil seront également importants dans le choix de l’outil.
Bien entendu, celui qui va intégrer plus de fonctionnalités qu’un autre va ajouter de la complexité et
impacter sur sa facilité d’utilisation ; mais il faut trouver un juste milieu. Un outil trop simple pourrait
augmenter les chances de non adéquation aux besoins, ou impliquer trop de développements spécifiques
pour assurer l’adéquation à ce besoin.
L’Intégration : ce composant, aujourd’hui plutôt bien connu (car provenant souvent d’outils d’EAI et
d’outils d’ETL(*)), permet d’accéder aux applications du système d’information. Il propose également
des fonctions pour transformer les données de manière à permettre des échanges entre les applications
du système d’information voire avec des partenaires de l’entreprise. C’est grâce à ce composant que l’on
a également à disposition toutes les données utilisables dans la brique « métriques et tableaux de bord »
de la solution de BPM puisque c’est lui qui permet la mise en place des sondes récupérant toutes les
données nécessaires. Cette brique permet également la manipulation de données au sein des applications.
Néanmoins, de plus en plus d’applications proposent des fonctions qui sont exposées sous forme de
« services» réutilisables et accessibles par cette couche d’intégration voire même, des accès à des services
métiers accessibles directement au niveau de l’outil de modélisation des processus de la solution, pour
permettre une meilleure intégration. On parle alors d’orchestration de services métiers.
Le Workflow : ce composant comporte plusieurs fonctionnalités principales qui sont :

• La gestion des activités manuelles : interface utilisateur permettant de visualiser les données
d’une activité et d’effectuer des actions sur cette activité (changement d’état par exemple : de
« en cours » à « terminée »)
• L’automatisation simple d’activités répétitives
• La gestion d’utilisateurs, de rôles et de droits (pouvant s’appuyer sur des outils déjà en place
(*) voir glossaire au sein du système d’information comme les annuaires LDAP(*) par exemple)
page 192

• Un « portail web(*) » permettant à un utilisateur d’accéder à toutes les informations afin
d’assurer la gestion des activités
• La gestion de la disponibilité des acteurs avec une gestion d’agenda complète : gestion des
absences et escalade vers des superviseurs disponibles, etc.
Les Métriques et tableaux de bord : ce composant est celui qui va permettre d’une part de calculer les
indicateurs définis sur des critères et données concrets avec lesquels on pourra mettre en place des
seuils d’alertes minimum et maximum à ne pas dépasser et d’autre part d’afficher ces indicateurs par
le biais de tableaux de bord contenant une représentation graphique et alphanumérique répondant à
une ergonomie définie, permettant aux utilisateurs de piloter les processus, sous-processus et activités
qui leur incombent avec tout le niveau de qualité requis.
Certaines parties non visibles nous font penser à un iceberg, dont la partie la plus visible est généralement
la plus petite. Néanmoins, et pour faciliter la mise en place de la démarche de BPM, il est primordial
de s’appuyer sur une démarche structurée d’une part, et, sur des retours d’expériences, d’autre part. Il
est vrai que le Business Process Management est plus sûr que de précédentes démarches d’amélioration
des processus puisqu’il est beaucoup mieux outillé que ses prédécesseurs, mais il est également vrai
que l’implication et la mobilisation des acteurs au sein du projet, ainsi que les moyens apportés pour
atteindre les objectifs et enjeux, sont pour beaucoup dans le succès d’un tel projet.
L e s entiment, la perc eption

T a ble a ux de bord
Indic a te urs
Inte rfac e
U tilis a te ur
D oc um e nta tion
Mod é lis a tion
Adm inis tra tion Int é gra tion

L a r é alité
S upe rvis ion

Optim is a tion
S im ula tion
C onduite du c ha nge m e nt
Figure 3 : Sentiment et réalité du BPM
Des exemples existent où une démarche qui a d’ailleurs déjà été éprouvée dans d’autres contextes
n’a eu que des retours mitigés voire désastreux, faute du manque de mobilisation d’acteurs et/ou de
sponsoring des projets. Ensuite, les technologies ont évolué et sont donc plus appropriées aux besoins
des entreprises, même si, et on le verra, il faudra faire la part des choses. Il y a encore bien des différences
entre ce qui est proposé sur le papier et la réalité du produit.
Maintenant la démarche est importante, mais il faut également faire attention à ne pas se retrouver
enfermé dans des « framework(*) » propriétaires desquels ont aurait du mal à se défaire sans des
surcoûts prohibitifs le jour où cela s’avérerait nécessaire. Un autre point important est que, bien souvent,
le Business Process Management paraît être simplifié à un niveau démesuré. Il ne faut pas confondre
simplifier et promouvoir, qui pour le second est plutôt du domaine d’un acte marketing, pratiqué avec
excellence par les éditeurs de logiciels et le premier, d’un acte de démystification de ce qu’est réellement
le Business Process Management pour bien en comprendre les tenants et les aboutissants. Pour finir, une
démarche de Business Process Management doit faire appel à des personnes extérieures à l’entreprise,
en particulier pour animer et aider à faire passer des idées, des directions et ce sans entamer le crédit
de la direction ou des collaborateurs de l’entreprise vis-à-vis du Management Exécutif.
Le Business Process Management est parfois mal compris car souvent identifié comme n’étant que de
la technologie alors que la technologie seule ne peut rendre les services escomptés.
(*) voir glossaire
page 192
Mais aussi certains éditeurs ne voient le Business Process Management que comme la modélisation
des processus ; or c’est une discipline toute entière qui comprend la modélisation mais également la
simulation, l’intégration, et l’exécution des processus. Pour terminer, vous aurez certainement à faire
face à des consultants qui vont vous parler de Business Process Management et qui, en fait, ne penseront
que Business Process Reengineering et c’est là encore une vision bien restrictive.
Mais la démarche ne s’arrête pas là. La démarche quadrangulaire consiste en la prise en compte des 4
axes que sont le métier et le fonctionnel, l’organisationnel, les méthodes et les technologies.
Le « métier et fonctionnel » permet de prendre en compte les besoins métiers et de les transcrire, en
suivant des méthodes, en fonctions macroscopiques. Un découpage en fonctions élémentaires permettra
ensuite de vérifier d’une part la pertinence de celles-ci, et d’autre part d’orienter d’une certaine manière
l’utilisation des technologies, qui ne sont ne l’oublions pas, que le moyen d’arriver à une intégration des
processus au sein du système d’information, et de donner les moyens appropriés pour les piloter.
Métier & Fonctionnel
Organisationnel
Méthodes
Technologies
Figure 4 : Démarche Quadrangulaire
L’organisation aura toute son importance dans le dispositif du projet, certes, mais également tout au
long du cycle de vie des processus.
Les méthodologies intègrent l’axe organisationnel et humain de manière à donner toutes les chances de
succès à la démarche, et ce, dans les délais et les coûts initialement fixés. Mais elles permettent également
de cadrer la mise en œuvre des produits.
Pour terminer, les technologies apportent toutes les fonctions nécessaires à l’intégration des processus
métiers au sein du système d’information.

2. Du processus métier au BPM
Toute entreprise utilise aujourd’hui des processus métiers (ou des procédures) même si, souvent ils
ne sont pas formalisés voire identifiés en tant que tels. Si les processus ne sont pas formalisés, une
phase d’analyse, de recueil et de documentation est conduite afin de comprendre comment l’entreprise
réalise ses activités, et comment les processus sont structurés. Les processus métiers sont en général à
un niveau d’abstraction où l’on ne parle pas du système d’information mais de l’activité des processus
et sous processus, des activités, des acteurs ainsi que des rôles et responsabilités qui sont nécessaires à
l’accomplissement du métier de l’entreprise. La démarche comprend la prise en compte de 3 facteurs
essentiels et incontournables que sont :
• Les acteurs
• Les processus
• Les technologies
Si le tout est agrémenté d’une méthodologie, ou à minima d’une démarche qualité, le projet de
mise en place du BPM, devrait alors prendre en compte les facettes qui composent l’urbanisme et la
rationalisation des processus de l’entreprise, pour optimiser ceux-ci et rendre l’entreprise plus agile et
plus efficiente.
Les 4 perspectives du Business Process Management

Le Business Process Management nécessite une approche selon 4 perspectives permettant d’avoir
une visualisation de l’organisation de l’entreprise et sa manière d’être gérée. Elles sont toutes aussi
importantes les unes que les autres. Dans la démarche du BPM, elles doivent toutes les quatre êtres
adressés simultanément.
Cette discipline nécessite que les maîtrises d’ouvrages et maîtrises d’œuvre échangent entre-elles et
travaillent de concert de manière à maximiser l’accompagnement du SI dans la mise en place du
cadre BPM au sein de l’entreprise ou entité concernée.
Ces quatre perspectives sont :

• Le métier
• L’organisation
• Les processus
• Le système d’information (en particulier les technologies)
m é tie r
orga nis a tion

Business Process
proc es s us
Management
te c hnologie s
Figure 5 : Les 4 perspectives du BPM
La perspective : « Métier »
Elle comprend trois axes que sont la stratégie d’entreprise, les obligations envers la régulation des marchés
ou l’obligation de conformité, et pour terminer le positionnement de l’entreprise sur un segment de
marché donné, que celui-ci soit nouveau ou pas.
La stratégie d’entreprise est mise en place pour permettre à l’entreprise de croître et la démarche de
BPM peut faciliter cette stratégie dans des cas comme :
• Les fusions/acquisitions : La croissance externe permet à une entreprise de se positionner
rapidement sur un segment de marché, voire un marché mais nécessite, pour permettre un
déploiement des nouvelles offres de manière plus large, une intégration rapide.
• Le pilotage des procédures : Il est nécessaire, au sein de l’entreprise, de donner les moyens de
piloter le bon fonctionnement des procédures que celles-ci soient en internes ou étendues vers
des fournisseurs et partenaires.
• L’externalisation : L’entreprise peut souhaiter garder une activité en particulier mais la rendre
plus lucrative en diminuant les coûts d’exécution et de production et en externalisant tout ou
partie des procédures.
La régulation d’un marché et la conformité : Les obligations que peuvent avoir certaines entreprises
nécessitent des aménagements de procédures et souvent des modifications au sein du système
d’information pour les prendre en compte.
Le positionnement de l’entreprise sur un segment de marché : La vision des clients sur l’entreprise se
fait au travers de ses offres de produits et services. L’amélioration, la mise à disposition sur le marché
de produits et services nécessite de l’agilité à répondre aux demandes qui impactent tous les niveaux de
l’entreprise qui se doivent d’être suffisamment réactifs pour proposer les meilleurs produits et services.
Plus l’entreprise est réactive aux demandes, plus sa position sur le marché peut être bonne. La flexibilité
des processus peut permettre d’obtenir ce niveau d’exigence.
La perspective : « Organisationnelle »
L’organisation de l’entreprise a toujours beaucoup compté dans l’efficience de celle-ci au regard de ses
clients, de ses actionnaires et de ses collaborateurs. Une entreprise agile qui dispose d’une organisation
qui l’est également, aura beaucoup plus de facilité à mettre en place une organisation centrée sur les
processus de l’entreprise.
Le but de l’agilité de l’organisation sera de permettre d’atteindre une meilleure performance et de

permettre à la fois certaines améliorations.
Pour la performance on peut citer :
• Les objectifs financiers et non financiers
• Le « time to market »
• Le SLA(*)
Pour les améliorations possibles on peut indiquer

• La réduction des coûts
• L’amélioration des processus de l’entreprise
• La mise en place d’outils de pilotage
La perspective : « Processus»
Toutes les entreprises ont des processus métiers et les utilisent tous les jours. Ces processus font la
richesse mais également la pauvreté d’une entreprise. La richesse quand la substantifique moelle est
correctement utilisée et la pauvreté quand ces processus sont peu ou pas performants.
Les processus métiers sont utilisés à tous les niveaux de l’entreprise et son activité économique est
composée de multiples processus : fabrication de produits, proposition de services et gestion des
(*) voir glossaire prospects et clients.
page 192

Il est vrai qu’avec les technologies d’intégration et d’automatisation certains des processus, plus ou moins
nombreux, sont automatisés et donc moins visibles. Mais ils n’en restent pas moins stratégiques et un
quelconque dysfonctionnement peut engendrer des pertes de production plus ou moins importantes.
La perspective : « Technologies »
Au niveau du système d’information, vous allez vous trouver face à un très grand nombre d’applications
qui peuvent contribuer à la gestion des processus métiers. Certaines d’entres elles utilisent déjà des
processus comme les progiciels de CRM(*) (passer du prospect au client suite à des modifications de
critères).
Les systèmes au sein de l’entreprise participent à ses succès ou à ses échecs. L’expérience a déjà démontré que
l’ouverture et la capacité d’une application peut, en fonction du niveau de couverture des fonctionnalités,
participer aux succès mais également aux échecs dans la mise en œuvre de processus.
Cette perspective « technologies » a également toute son importance. Elle se situe d’ailleurs, à plusieurs
niveaux.
• Le premier réside dans la capacité du système d’information existant, à faciliter la mise en
œuvre des processus, et de les accompagner tout au long du cycle de vie.
• Le second niveau réside en l’impact des technologies, sur la pérennité des processus
mis en œuvre.
On sait d’expérience que certaines technologies peuvent venir perturber celles déjà en place. Il sera
important d’avoir une vision à moyen terme des nouvelles technologies et leurs impacts sur l’existant.
Les technologies doivent accompagner la stratégie d’entreprise et non la freiner voire l’impacter.
La complexité du SI a un impact non négligeable pour une intégration des processus. Si le SI est très
complexe l’intégration sera plus difficile.
Une architecture SOA(*) peut servir comme levier de mise en place d’outils d’intégration des processus
et de pilotage de la performance.
L’adoption du BPM
Le marché des outils de BPM est un marché qui a beaucoup évolué au cours de ces dernières années. La
plupart des outils de BPM sont construits à partir d’outils déjà existants comme le Workflow et l’EAI, par
exemple. C’est pourquoi nous allons retrouver des acteurs déjà connus du monde de l’EAI notamment.
Par contre nous allons également trouver des acteurs provenant du monde du Workflow et même de
nouveaux acteurs spécialisés dans l’ « orchestration de services(*) ». Pour finir, des acteurs majeurs,
connus dans le domaine de l’architecture d’entreprise et de la modélisation, se veulent des acteurs du
domaine du Business Process Management mais ne sont en fait que des « acteurs de niche » des outils
de modélisation. Ils sont d’ailleurs, aujourd’hui, assez souvent complémentaires de Suites BPM, même
si ils ne souhaitent pas êtres engagés dans la compatibilité entre la modélisation et l’exécution des
processus. Pourtant ils auraient fort intérêt à avoir cet « accostage » entre la modélisation/documentation
des processus métiers et l’exécution de ceux-ci.
Les éditeurs de solutions provenant de marchés dérivés (EAI, Workflow, …) font bénéficier de leurs
retours d’expériences dans leurs domaines respectifs et permettent de tirer parti des bonnes pratiques
mises en œuvre chez bon nombre d’entreprises. Néanmoins, l’adoption des outils de BPM se fait de la
même manière que les autres technologies et passe par les mêmes étapes, même si celles-ci peuvent
parfois être plus courtes.
On traite d’ailleurs le niveau de maturité des technologies en utilisant une courbe de battage médiatique
ainsi que sa courbe d’adoption associée. Cette courbe comporte 4 niveaux que sont : les innovateurs, les
précurseurs, la majorité et les retardataires. Ceci permet de comprendre quel est le niveau de maturité
d’une technologie.
(*) voir glossaire
page 192
N ive a u d ’a doption
ba tta ge m é dia tique
L e s innova te urs L e s pr é c urs e urs L a m a jorit é L e s re ta rda ta ires
Figure 6 : Courbe d’adoption des technologies
Les Innovateurs : certaines entreprises vont adopter le BPM bien avant toutes les autres, au risque de
rencontrer des difficultés faute de compétences pointues sur les outils et démarches. Certaines vont
pourtant tirer des bénéfices de la mise en place de ces outils. Maintenant le partage de connaissances avec
d’autres qui ont mis en place une démarche et des outils est souvent difficile, bien que pour le marché
français, les exemples étrangers ne manquent pas en particulier aux Etats-Unis, pays d’où proviennent
généralement la grande majorité des outils.
Les Précurseurs : Les produits apportent déjà un bon nombre de fonctionnalités mais sont souvent
confrontés à des problèmes de jeunesse et certaines technologies, devenues obsolètes, peuvent obliger
un éditeur à effectuer une rupture technologique. Par ailleurs, c’est la période où l’on s’aperçoit que
les méthodes « prêtes à l’emploi » doivent être adaptées au contexte. Si les risques ne sont pas, dans
cette phase, clairement identifiés et correctement suivis, on pourrait vivre une très forte désillusion qui
probablement pourrait conduire à l’arrêt total de certains projets déjà lancés.
La Majorité : les technologies sont, à ce stade, plus matures et se sont beaucoup plus standardisées que
leurs prédécesseurs. Un très grand nombre d’entreprises conduisent des projets de BPM.
Les Retardataires : On peut également les appeler les « suiveurs ». Ce sont les entreprises qui vont
intégrer en dernier un outil de BPM au sein de leur système d’information.
Aujourd’hui on constate que les projets de BPM qui ont eu le plus de succès, sont ceux qui ont été
mise en œuvre par une approche métier. L’approche par les données ou sur un point de vue purement
intégration, n’a que très rarement eu du succès et n’a de toute façon, pas su démontrer un bon niveau
de retour sur investissement. C’est une des raisons pour lesquelles les projets de BPM ont toujours mis
du temps à voir le jour.
L’autre raison est que les mentalités par rapport aux processus de l’entreprise n’ont que peu changé.
Un processus, dans l’esprit des dirigeants d’entreprise, reste assez figé alors que cela devrait être tout
le contraire. Un processus doit être évolutif et ses règles associées également (voire surtout !). De la
conception des processus dépendront plusieurs critères : la flexibilité, la performance et la supervision.
C’est pourquoi l’entreprise orientée processus a toutes les chances de faire partie de celles les plus
compétitives du marché. Les autres, qui n’auront pas adopté à temps une telle démarche auront,
très probablement, beaucoup plus d’efforts à fournir dans un délai plus court afin de redevenir plus
compétitives.
Le BPM est aujourd’hui au début de la phase de maturité et est de plus en plus utilisé. Les outils eux se
situent entre « les précurseurs » et la « majorité » ; entre l’innovation et la stabilité !
La maîtrise des enjeux

Un des points clés dans le Business Process Management est la compréhension des enjeux de l’entreprise
et du pourquoi elle met en place cette démarche. Bon nombre de projets de BPM ont eu des résultats
mitigés du fait de la mauvaise compréhension de ces enjeux sous-jacents.

Il y a quelques temps, un client dans le domaine de la finance m’a demandé comment je pouvais l’aider
à justifier un projet de BPM poussé uniquement par la DSI(*). Ma réponse a été simple et sans appel :
impossible sans comprendre les enjeux et sans travailler avec le métier !
Les enjeux sont fixés avec les représentants métiers de l’entreprise et ceux-ci doivent être correctement
identifiés et validés par l’exécutif et même sponsorisés. Il doit en être de même pour la démarche de
BPM qui, sans réel sponsor, peut s’avérer totalement inefficace.
La méthode doit également permettre de mettre en place un cadre de travail qui devrait aider à passer
outre les barrières naturelles des organisations et des hiérarchies de l’entreprise. Ce cadre devra faciliter le
dialogue transversal entre les organisations, de manière à accroître les chances de succès de la démarche
dans son ensemble. Par contre, il doit être également clairement identifié, que le cadre de travail va, très
certainement, bousculer les habitudes de travail et que, par conséquent, les acteurs majeurs doivent
tous adhérer au projet. Par ailleurs, il est important que la démarche de BPM au sein de l’entreprise soit
proactive et indépendante de toutes technologies en place au niveau du système d’information. N’oublions
pas que l’outil de BPM ne sera qu’un moyen d’accompagner la démarche dans son ensemble.
Les principaux enjeux que l’ont rencontre sont les suivants :
• L’agilité
• L’adaptabilité
• L’optimisation
• Le reengineering de processus
• La rentabilité
• L’alignement de la stratégie et de l’IT(*)
• Le positionnement compétitif
• L’amélioration ou l’adhésion à des critères de qualité
Voyons maintenant ces enjeux un à un pour comprendre leur importance au sein de l’entreprise.
L’agilité
L’agilité c’est la capacité d’une entreprise à anticiper ou créer le changement. Donc pour faciliter la prise
en compte de cet enjeu, on doit prendre en compte quelques principes de base comme :
• Tout changement, si petit soit-il, peut avoir un effet domino au sein de l’entreprise
• La chaîne de valeur de l’entreprise est aussi forte que son maillon le plus faible
• Une entreprise agile est une entreprise qui a la capacité de programmer le changement ou
d’y répondre.
L’adaptabilité
Le premier moteur de l’adaptabilité est très certainement et de très loin la concurrence à laquelle
l’entreprise doit faire face. Une entreprise qui ne sait pas s’adapter à son environnement économique
est une entreprise en péril. L’adaptabilité est certainement, et de manière générale, complexe à mettre
en œuvre car elle influence les méthodes de travail qui sont utilisées depuis un temps certain au sein
de l’organisation.
De manière générale, l’adaptabilité dont l’entreprise doit faire preuve, provient :

• Des coûts
• Des délais (comme des délais de livraison par exemple)
• Des moyens mis à disposition pour traiter les commandes (y compris des canaux directs
comme un site Internet)
• Du packaging des produits proposés
• De la valeur ajoutée des services qui sont proposés
• De caractéristiques qui évoluent en fonction des besoins changeants des consommateurs.
Aujourd’hui toute entreprise qui ne sait pas s’adapter à son écosystème (marché, besoins des clients,
partenaires,…) est vouée à une mort quasi certaine.
(*) voir glossaire
page 192
L’optimisation
Nos confrères américains disent souvent « more with less » (faire mieux avec moins). Paradoxal mais
néanmoins une dure réalité. Aujourd’hui les entreprises doivent faire de plus en plus pour leurs clients
pour des coûts souvent très bas ce qui, d’ailleurs, conduit à des baisses de qualité qui sont perceptibles.
Les délais deviennent également très courts. Aujourd’hui il serait impensable de sortir d’une boutique
de téléphones mobiles et que le téléphone acheté ne soit mis en fonction que quelques jours plus tard.
Les clients, et par voie de conséquence « nous », demandons à avoir tout, tout de suite et c’est ce qui
demande d’optimiser les procédures ou processus de mise à disposition. Les axes d’optimisation peuvent
être nombreux et conduire à l’automatisation et au suivi d’activités conduites par des populations de
collaborateurs voire jusqu’à de l’externalisation d’activités. L’optimisation consiste en une réduction de
coûts tout en augmentant les revenus. Bien entendu, on peut percevoir des zones d’améliorations, mais
celles-ci peuvent ne pas être si intéressantes. Il est donc judicieux d’analyser les pistes d’améliorations
possibles avant de les mettre en place. N’oublions pas que l’optimisation doit produire une réelle valeur
ajoutée et qui de plus doit être en phase avec la stratégie d’entreprise.
Le reengineering de processus
Dans les années 1990, les besoins des consommateurs en efficacité des produits et des services ont poussé
les entreprises à lancer des projets de reengineering des processus métier. C’est ce que l’on appelle le
BPR(*). Le reengineering de processus consiste en une remise en cause fondamentale et une redéfinition
complète des processus afin d’améliorer, de manière très significative, les performances en termes :
• De coûts
• De qualité de service
• De délais
L’objectif principal du BPR est d’obtenir des améliorations significatives et ce à court terme. On va
donc réorganiser complètement le processus et le découpage des activités afin d’en réduire les délais
d’exécution et les efforts associés. On repense ce qui existait. Par contre, le BPR n’est pas un remède
miracle. Dans cette démarche on recherche avant tout des pistes permettant d’obtenir des rendements
importants, de diminuer les budgets nécessaires pour rendre des services équivalents ou des produits
de qualité identique, de diminuer les effectifs sur des activités avec peu ou pas de valeur ajoutée et de
diminuer certains coûts.
La complexité du BPR réside dans le fait de devoir analyser une quantité d’informations très importante
mais également dans le fait de devoir mettre en place une période de transition permettant d’améliorer
en mode continu les processus.
Nous verrons d’ailleurs que l’implication du management de l’entreprise sera primordiale au succès du
BPR. Sans cette implication, l’échec est quasi certain. Dans le cas de réduction de personnel, une partie
des collaborateurs deviendront des freins à ce changement et l’importance de la mise en place d’une
conduite du changement appropriée sera d’autant plus importante.
Par contre, ce reengineering favorise l’innovation et oblige de se transposer vers l’avenir. Ceux qui ont
besoin de changement se trouveront plus à l’aise. Il permet également d’anticiper des changements
structurels impliqués par les modifications des marchés, des organisations au sein de l’entreprise voire
d’impacts dus à des nouvelles technologies.
Les structures d’aujourd’hui se tournent de plus en plus vers une vision processus qui permet d’être
plus orienté vers la satisfaction du client.
La rentabilité
Nous en avons déjà parlé, mais si nous prenons l’exemple des ventes par Internet, il est aujourd’hui
clair qu’elles poussent à la baisse des prix. Il ne reste plus qu’à soit réduire les coûts pour que les marges
soient acceptables ou d’augmenter la valeur ajoutée du produit ou du service pour en garantir une
(*) voir glossaire bonne rentabilité. Dans le cas de la rentabilité, il est impératif d’utiliser la bonne approche. On peut
page 192 prendre des décisions pour réduire les coûts, mais ces décisions n’ont-elles pas des impacts en interne

ou en externe ? Avant de prendre une quelconque décision arbitraire, on se doit d’identifier les besoins
et de déterminer les mesures pour ensuite prioriser les actions à mettre en œuvre ainsi que les moyens
de les piloter. Si l’analyse du besoin a été correctement effectuée, l’érosion des profits doit être dans le
temps minime sauf si une cause extérieure impacte fortement le coût de production d’un produit par
exemple (on le voit en particulier en fonction de matières premières qui varient au gré des cotations
boursières) et les résultats se doivent d’être, si possible, prévisibles.
L’alignement de la stratégie et du Système d’Information
La stratégie de l’entreprise est définie au niveau de l’exécutif de l’entreprise et donc le projet d’alignement
doit être, à minima, sponsorisé par un membre du comité exécutif ou assimilé. Dans le cadre de la
mise en place de la stratégie, des objectifs ont été définis et ceux-ci doivent être pris en compte par
le projet d’une part, mais également correctement compris d’autre part. C’est ici toute l’importance
des enjeux et de leur compréhension par l’équipe projet. Nous n’allons pas maintenant déterminer les
étapes permettant d’aligner le système d’information à la stratégie de l’entreprise, mais il est important
de comprendre que la mise en place d’un projet BPM a des impacts à tous les niveaux de l’entreprise,
et permettra de se poser toutes les questions facilitant les choix de mise en œuvre.
Par mise en œuvre on entend une mise en œuvre d’une organisation, de formalisme, d’implémentation,
… des processus cibles.
Le positionnement compétitif
La perception du client de l’entreprise qui propose le produit ou le service est intimement liée à la
qualité des processus. Il est donc normal de voir des clients acheter un produit chez un constructeur
plutôt qu’un autre ou un service dans une entreprise plutôt qu’une autre. L’amélioration des processus
va donc permettre également d’améliorer la qualité des produits et services proposés.
L’entreprise doit se poser la question suivante : qu’est ce que ma société fait de mieux pour ses clients
que mes compétiteurs ne font pas ?
Les fondements du positionnement compétitif sont au nombre de 3 :

• Ce que l’entreprise fait
• Ce que les compétiteurs font mal ou pas du tout
• Ce qui apporte de la valeur ajoutée au client
Le positionnement compétitif est fonction de :

• La tarification : les prix peuvent varier en fonction du coût des activités d’un processus
• La qualité du produit ou du service
• Les caractéristiques du produit ou du service proposé
• L’adéquation aux besoins des clients
• La disponibilité
• La livraison (modes, délais, …)
• Du service proposé
De manière générale, s’il y a un marché il y a compétition. L’entreprise doit communiquer sur

ses points en particulier en interne, car les collaborateurs pourront associer leurs propres actions.
L’amélioration ou l’adhésion à des critères de qualité
Dans le cadre de l’adhésion à des critères qualité, comme ISO 9001 par exemple, il est nécessaire que les
processus principaux (cœur de métier ou dit « core »), soient formalisés et pilotés de manière à assurer la
qualité de ce qui est produit en termes de produits ou services. Pour ce faire, il est nécessaire de bien définir
les processus et la manière de les piloter. Des documents ou preuves peuvent être nécessaires pour démontrer
la qualité ainsi affichée. La mise en place d’une solution de BPM peut permettre de formaliser, exécuter et
piloter les processus de l’entreprise et permettre ainsi de faciliter le suivi d’une norme qualité.
Autre niveau, l’amélioration de la qualité de ce qui est produit. Dans certains cas, les processus
correctement optimisés peuvent donner un sentiment de qualité. Si par l’optimisation d’un processus
vous êtes capable de garantir à un client qu’il sera livré en 24 heures au lieu de 5 jours, pour le client
vous avez un excellent niveau de qualité. Autre exemple, un client attend un article qui n’arrive pas. Vous
êtes capable de lui dire pourquoi (livraison retardée suite à surcroît de colis, grève ou non disponibilité)
et là, le client aura également un sentiment de qualité malgré la non disponibilité du produit.
Les bénéfices du Business Process Management

Aujourd’hui les entreprises cherchent des moyens d’améliorer leur fonctionnement global pour en
augmenter les bénéfices à plusieurs niveaux. Par la mise en place d’une gestion des processus métier de
l’entreprise et des outils associés, les entreprises ont la possibilité de formaliser, exécuter, automatiser
et tracer tout ou parties de leurs processus, et ce bien que certaines parties soient encore manuelles et
qui ne seront d’ailleurs, très probablement, jamais automatisables.
Nous allons voir les raisons pour lesquelles une entreprise va adopter une démarche de BPM et se doter
des outils nécessaires.
La liste suivante (non exhaustive) permet d’avoir une vision des principaux bénéfices apportés par une
démarche de Business Process Management comme :
• Augmenter les bénéfices
• Améliorer la gestion de l’entreprise
• Diminuer les coûts et accroître l’efficacité
• Améliorer la qualité de service
• Augmenter l’adaptabilité, la flexibilité et l’agilité
• Diminuer les coûts de développement et de support
• Diminuer les risques liés à l’implémentation de nouveaux systèmes
• Améliorer la gouvernance
• Faciliter la mise en conformité
• Figer certains processus de l’entreprise de manière à permettre une compatibilité ou
certification au regard d’une norme ou d’une législation
• Identifier les processus candidats à l’externalisation
• Analyser le comportement des clients et des partenaires
Augmenter les bénéfices
Toutes les entreprises souhaitent pouvoir trouver un moyen d’augmenter les bénéfices. Cela peut s’avérer
possible par réduction des cycles de vie, par augmentation de la productivité, par augmentation de la
satisfaction client ou par la fidélisation de la clientèle existante.
Pour cela les outils de BPM, peuvent permettre de diminuer les cycles de vie en parallélisant certaines
activités de processus y compris si celles-ci sont effectuées par des collaborateurs de l’entreprise et non
des applications ou systèmes informatiques. Cependant, il y a, bien entendu, des cas où le fait de mettre
plus de personnes, ne fera pas pour autant avancer les choses plus vite.
L’augmentation des bénéfices peut se calculer plus facilement dans le cas où l’on va influer sur la
satisfaction du client. Prenons l’exemple des télécoms. A la fin des années 90, nous pouvions acheter
un téléphone portable dans une boutique ou chez l’opérateur directement, mais il fallait une demi-
journée (au mieux) pour qu’il soit activé et pour que nous puissions l’utiliser. Depuis, les processus
d’activation à partir de la prise de commande, la saisie des informations client, jusqu’à l’activation du
téléphone, se fait en grande partie de manière automatisée. Résultat : nous sortons de la boutique avec,
bien souvent, notre téléphone activé dans la demi-heure qui suit, voire déjà activé. Le résultat final
pour les opérateurs téléphoniques est que les clients consomment plus, plus rapidement, et le chiffre
d’affaire a, par voie de conséquence, augmenté.
Améliorer la gestion de l’entreprise
Dans le cas de l’amélioration de la gestion (de l’entreprise), on va adresser l’amélioration par une radicale
modification de pensée qui va passer :
• de la pensée départementale (limitée à un domaine ou une activité de l’entreprise)

• à une pensée orientée client obligeant une meilleure fluidité entre les départements
(ou domaines) de l’entreprise, et par conséquent, entre ses différents domaines fonctionnels.
On le voit aujourd’hui. Les entreprises qui ont du succès, l’obtienne parce qu’elles sont orientées client,
et c’est pourquoi on peut en voir de plus en plus nommer des responsables de processus, d’autant qu’avec
l’avènement d’Internet, ceux-ci se sont étendus aux clients et aux partenaires. Ces acteurs deviennent
alors de fait, des utilisateurs de ces processus et il est donc nécessaire de nommer un responsable et
de lui donner les moyens de les piloter par la mise en place de fonctions lui permettant de les tracer
par l’accès à des statistiques, mais également en lui permettant d’interagir sur ces processus en cas de
dysfonctionnement ou en cas de dégradation des indicateurs qui y sont associés.
Une autre partie très importante est la restriction par un renfort du mode de gestion. Un processus peut
renforcer la gestion et limiter, par exemple :
• La fraude
• Les accès non autorisés
• La modification de données non autorisée (qui ont des règles de gestions particulières
par exemple)
La dernière partie pour la gestion est que le BPM apporte la mesure et la présentation d’indicateurs
par la mise en place de tableaux de bord. Le management de l’entreprise peut alors visualiser le bon
fonctionnement des processus, visualiser les indicateurs associés et être alerté dans le cas ou des seuils,
définis par avance, sont approchés, atteints, voire dépassés. Cette partie est souvent apparentée à des
outils de BAM(*).
Diminuer les coûts et accroître l’efficacité
A produit ou service équivalent, le consommateur va très vraisemblablement choisir celui qui sera le
plus avantageux économiquement. Le grand challenge des entreprises aujourd’hui, est donc de pro-
poser des services leur permettant de se différencier par rapport à leurs concurrents. Elles cherchent
donc, de plus en plus, à améliorer leurs processus par la mise en place d’outils leur permettant ainsi
de les piloter plus efficacement et de manière opérationnelle, d’identifier correctement les points né-
vralgiques, voire de dysfonctionnement de leurs processus, d’y remédier plus rapidement, et donc de
démontrer plus de réactivité. L’efficacité ne s’en trouvera qu’améliorée et les acteurs de ces processus
pourront, très probablement, se focaliser sur des activités à plus forte valeur ajoutée. Dans certains
cas, les activités automatisables seront identifiées permettant alors d’en diminuer les coûts.
Il n’est pas rare que les gains ne soient pas visibles au premier coup d’œil et que la mise en place d’un
outil de pilotage de ces processus permette de les mettre en valeur. Par ailleurs, on verra, lors d’une
analyse fonctionnelle plus approfondie, que certaines fonctions pourront être purement et simplement
abandonnées faute d’une utilité reconnue.
Améliorer la qualité de service
La qualité de service est liée à l’efficacité et de plus en plus de clients demandent à leurs fournisseurs
des engagements de qualité, en particulier de qualité de service, et vont même jusqu’à mettre en
place des systèmes de bonus/malus en fonction du niveau de qualité réellement constaté, et par
rapport à des engagements préalablement contractualisés. Si on améliore l’efficacité d’un processus,
on améliorera la potentielle qualité de service et plus l’entreprise sera confiante dans la qualité de
service de ses processus plus elle pourra utiliser cette qualité comme argument différenciant de son
offre ou produit et se rémunérer en fonction des niveaux de qualité de service qu’elle est capable de
proposer. Aujourd’hui on entend beaucoup parler de SLA et de SLM(*). En fait le Business Process
Management et les outils associés peuvent permettre un réel pilotage de ces niveaux d’engagement.
Augmenter l’adaptabilité, la flexibilité et l’agilité
De plus en plus d’entreprises découvrent que leur capacité pour lancer et supporter de nouveaux
produits et/ou services est drastiquement limitée du fait de leurs systèmes existants, de leurs processus (*) voir glossaire
ainsi que de leurs structures organisationnelles. Il devient complexe, voire quasi impossible, de changer page 192
l’une des briques du système tellement elles sont soit obsolètes, soit non adaptables. La mise en place
d’une démarche et d’un outil de BPM va apporter beaucoup plus de flexibilité à l’entreprise dans la
mise en œuvre et l’amélioration de processus. Le système sera plus adaptable et dans le cas de briques
en cours de changement ou d’évolution, il sera possible de faire en sorte que les impacts, notamment
des processus transverses, soient minimisés au mieux.
Les principaux services proposés par les applications vont être encapsulés soit via une connectivité soit
via des services laissant ainsi le loisir de permettre une meilleure réutilisation des fonctions proposées par
les applications dans de nouveaux processus. Cela va permettre également un meilleur décloisonnement
des applications, laissant ainsi plus de latitude lors de mise en place de nouvelles versions de ces
applications, voire de nouvelles applications.
L’agilité est un critère très important dans la réduction des demandes d’évolutions et donc, par voie de
conséquence, des coûts induits par ces évolutions. Le fait de faire évoluer le système d’information plus
facilement lors de la prise en compte de nouveaux besoins opérationnels (lancement de nouvelles offres ou
produits par exemple) permet de diminuer le budget de la DSI nécessaire à la maintenance du système.
Agilit é
Agilit é
Demandes d ’é volutions
temps
Figure 7 : Lien entre agilité et évolutions du SI(*)
On comprend alors que plus le système d’information sera agile moins il y aura d’évolutions complexes
et coûteuses à traiter et à prendre en charge pour supporter les besoins opérationnels.
Diminuer les coûts de développement et de support
Les outils de BPM proposent des modes qui s’apparentent plus à du paramétrage que du pur développement.
Ils garantissent ainsi une meilleure productivité lors de leur mise en place. Dans certains cas, les coûts
et les délais de mise en œuvre peuvent être diminués de manière importante.
Par ailleurs, une fois que l’application BPM est mise en production on constate souvent que les utilisateurs
commencent à demander des évolutions. Celles-ci peuvent être prises en compte dans des délais très
courts.
Diminuer les risques liés à l’implémentation de nouveaux systèmes
L’implémentation d’un nouveau système est suffisamment complexe pour avoir des exemples concrets
de projets qui n’ont jamais aboutis. Aujourd’hui si un de ces projets devait revoir le jour, il est fort
probable que le fait de l’appréhender sous un angle orienté processus permettrait que les besoins des
utilisateurs soient mieux pris en compte et que la mise en œuvre au sein de l’application (ou système)
soit faite de manière à travailler sous forme de petites itérations. Autre avantage : ceci permettrait ainsi
de mieux prendre en compte les évolutions demandées par les utilisateurs. Il ne faut jamais oublier que
(*) voir glossaire les utilisateurs auront probablement un œil critique, et demanderont une certaine flexibilité à prendre
page 192 en compte leurs besoins. Ne sont-ils pas les premiers utilisateurs de ces systèmes ?

Améliorer la gouvernance
Les outils de BPM permettant d’imposer une façon de travailler aux employés d’une entreprise par un
contrôle des modes de décisions - en fonction d’événements survenant au quotidien - doivent surtout
apporter un moyen de comprendre ce qui se passe et, par conséquent, d’ajouter un mode de gouvernance
plus efficace permettant de capitaliser les bonnes pratiques et ce, afin de palier aux problèmes survenant
lors de l’exécution de processus.
Faciliter la mise en conformité
De nos jours et en particulier au sein de l’Union Européenne, de plus en plus de gouvernements

imposent aux entreprises la mise en application de régulations comme BALE II, Sarbanes-Oxley, IFRS,
SOLVENCY II, etc. Il est encore gravé dans les mémoires des financiers et des actionnaires, les affaires
qui ont ébranlé notre économie faute de transparence financière. Outre le simple fait de la mise en
place d’une régulation, les entreprises qui doivent se mettre en conformité avec la législation doivent
souvent lancer des projets plus ou moins coûteux. Ces régulations sont souvent liées aux principes,
à la politique et aux procédures qui régissent une entreprise et à sa façon de publier des informations
(relatives à sa santé financière par exemple). Celles utilisant des outils de BPM pour piloter leurs
processus ont une meilleure garantie d’application de ces conformités. Même si des déviations sont
constatées, elles sont immédiatement identifiées et donc adressées, de manière à éviter des pertes
parfois significatives.
Stabiliser certains processus de l’entreprise
La mise en place d’une démarche de Business Process Management permet de stabiliser certains
processus critiques de l’entreprise. Ces processus formalisés, sont alors instrumentés et la direction a
alors la quasi certitude de leur application et dispose des indicateurs associés permettant de valider la
qualité de ceux-ci. Cette démarche peut faciliter la certification de l’entreprise vis-à-vis d’une norme
(Certification ISO(*) par exemple).
Identifier les processus candidats à l’externalisation
Certaines entreprises mettent en place une démarche de BPM pour permettre une externalisation
ultérieure de tout ou partie de processus. Ils doivent alors faire l’objet d’une formalisation précise qui
doit comprendre : non seulement le fonctionnement du processus, mais également tous les indicateurs
associés qui permettront de le piloter. Alors il pourra être externalisé. C’est ce que l’on appelle le BPO(*).
Les indicateurs de suivi permettront de vérifier la qualité d’exécution du ou des processus externalisés.
Bien évidemment, l’entreprise va devoir qualifier les processus à externaliser selon 2 possibilités :
• Les processus qui coûtent à l’entreprise et apportent peu de valeur ajoutée
• Ceux qui n’enlèvent pas l’essence de l’entreprise, et surtout pas de contrôle sur le métier de
l’entreprise.
L’avantage du BPM est d’apporter au BPO la démarche et les outils nécessaires à un pilotage de ces
processus qui seront ainsi externalisés. Il permet également de les formaliser tous, avant même de vouloir
les externaliser. Bien connaître ses processus avec leurs forces et leurs faiblesses a toute son importance.
Des exemples montrent des externalisations de la comptabilité générale ou de gestion administrative

du personnel. L’analyse des processus va permettre d’identifier les activités qui peuvent être ainsi
externalisées. Les processus sont souvent à forte composante SI. Ce qui sera important c’est de pouvoir
les piloter même si ceux-ci sont à l’extérieur de l’entreprise.
Des études ont fait ressortir les principales raisons d’externalisation de processus comme :
• La réduction des coûts
• L’augmentation de la productivité
• L’amélioration de la qualité et de la performance des processus
• La transformation de l’activité métier
• L’apport de métriques permettant de quantifier la qualité (*) voir glossaire
• L’amélioration de la relation client page 192
• La facilitation de la mise en conformité face à des obligations légales
• La réduction des risques
Un autre aspect du BPO est le partenaire vers lequel on va externaliser le ou les processus. Ce partenaire
doit bien comprendre le fonctionnement du processus, ses métriques et le niveau de service associé.
Il est important également de ne pas externaliser n’importe quel processus métier. Externaliser un
processus « cœur de métier » (ou dit « core ») peut impacter la maîtrise de la stratégie de l’entreprise.
Les principaux risques du BPO peuvent résider en une perte de contrôle du ou des processus, de se
reposer sur une instabilité financière du partenaire, de la perte d’expertise de l’entreprise sur une partie
de son métier, et de failles potentielles quant à la confidentialité des données traitées.
Analyser le comportement des clients et des partenaires
L’analyse comportementale des clients et partenaires de l’entreprise lui permet d’avoir un marketing plus
ciblé et de se différencier de sa concurrence. Les données collectées lors de l’exécution des processus
métiers doivent permettre une étude plus détaillée du comportement des ses clients, comme proposer
une option bien adaptée à la demande initiale d’un client, ou encore proposer un produit complémentaire
à celui que le client vient de commander. Une multitude de sites de commerce électronique propose
aux clients des produits complémentaires.
Cette analyse doit permettre de mieux cibler les produits et services en fonction des demandes des
clients et des partenaires et permettre un taux de transformation des ventes plus important.
L’organisation de l’entreprise
L’organisation de l’entreprise est aujourd’hui primordiale pour son succès. Il est vrai que la hiérarchie est
particulièrement importante dans la majeure partie des entreprises, à ceci près que le pilotage est trop
souvent orienté en fonction de cette hiérarchie, avec en dernier, le client. Avec les pressions exercées
par les clients et consommateurs, donc par le marché, il est nécessaire que l’entreprise s’oriente de
plus en plus vers les besoins des clients, sans pour autant prendre au pied de la lettre le vieil adage du
« Client est Roi ».
L’organigramme reflète la structure de l’entreprise. Cela revient également à définir comment le travail
est organisé et coordonné.
Les structures organisationnelles sont de 2 sortes : les structures traditionnelles et les structures dites
« nouvelles ». Le service rendu est important et la satisfaction du client l’est d’autant plus. Les structures
« nouvelles » sont plus tournées vers le client et le marché et sont plus flexibles. Néanmoins, il n’existe
pas de structure organisationnelle universelle.
L’organisation de l’entreprise doit être fonction de ses particularités comme sa taille, sa stratégie, son
écosystème… Certaines technologies du système d’information peuvent influencer cette organisation.
Dans le cas de la gestion des processus métiers, des impacts au niveau de l’organisation de l’entreprise
sont à prévoir. Le fonctionnement ne peut plus se faire uniquement en silos, mais doit faire collaborer
les équipes entre elles.
Des nouvelles structures comme celle dite de la « pyramide inversée », qui organise l’entreprise de
manière à être en capacité de traiter les actions qui sont fonction des impératifs du marché, seront plus
flexibles et répondront mieux aux attentes des clients. Cette structure est plus spécifiquement orientée
vers les clients et leurs besoins.

C lients
E x é c utif
C ollaborateurs
Mid Management
Mid Management
C ollaborateurs
E x é c utif
C lients
Figure 8 : Organisation et pyramide inversée
Dans le cadre du Business Process Management, l’organisation de l’entreprise doit être prise en compte
de manière à bien comprendre les procédures d’escalade qui seront à mettre en œuvre au sein des
processus et de correctement définir tous les groupes et rôles correspondant à cette organisation. Les
rôles et responsabilités des acteurs devront être correctement établis.
Rôles et responsabilités nécessaires au BPM

Le BPM a été vu par certaines entreprises comme une autre technologie mise en place pour rendre
un service. Erreur ! Toutes ces entreprises n’ont pas obtenus les résultats escomptés. Un projet de
BPM n’est pas un projet Informatique ! C’est avant tout une stratégie et un mode de gouvernance qui
implique d’avoir une organisation orientée processus. Ces processus et activités font appel à des règles
métiers bien précises. Par conséquent, il est nécessaire de travailler avec les responsables métiers, et
ce, dès le début du projet. On comprend alors que le simple fait de définir ces rôles et responsabilités
facilite l’alignement du métier et du système d’information et le faire au moment de la mise en place
d’une démarche de Business Process Management sera bénéfique à l’entreprise et aura plus facilement
l’adhésion des acteurs métiers et des acteurs de l’informatique.
La gestion des processus métiers nécessite désormais de faire travailler de concert métier et IT. Pour
arriver à cet objectif, il est important de correctement définir les rôles et responsabilités de chacun,
afin que le projet puisse se dérouler normalement sous l’œil avisé d’un des membres de la direction de
l’entreprise, qui jouera un rôle de sponsor. A nouvelles techniques nouveaux rôles et à ces nouveaux
rôles des responsabilités en rapport avec la discipline du Business Process Management. On comprend
plus facilement qu’impliquer tous les acteurs dès le début du projet, facilitera l’adhésion du plus grand
nombre d’entre eux, si ce n’est de tous.
Les responsabilités du métier
Au sein de l’entreprise, le métier continue à gérer des activités qui jusque là lui incombaient, mais également
de nouvelles inhérentes à la mise en place de la démarche de Business Process Management.
A c tiv ités
Développement de la stratégie
Identification des métriques et indicateurs de performance
Formalisation des macro-processus
Spécifications fonctionnelles des processus
Création des simulations, optimisations et différents scénarii
Analyse et Supervision métier des processus
Gestion des règles métiers
Mise en place du modèle "business"
Figure 9 : Activités et responsabilités du métier
Le tableau ci-dessus indique les principales activités qui sont et restent sous la responsabilité du métier.
Les responsables métiers savent correctement adresser ces sujets. Ils savent les définir, rapidement,
analyser et optimiser les processus afin qu’ils soient en correspondance avec la stratégie de l’entreprise.
On distingue bien que les activités qui sont sous la responsabilité du métier sont en relation directe
avec la stratégie de l’entreprise.
Les responsabilités de l’IT
Pour les responsabilités au niveau de l’IT, on comprend que celles-ci sont en relation directes avec le
système d’information.
A c tiv ités
Evaluation technologique de l'outil de BPM
Intégration des processus au sein du système d'information
Modèles et framework de composants de la solution de BPM
Définition des niveaux de sécurité des processus et activités
Définition d'une architecture évolutive
Définition de bonnes pratiques
Définition des procédures d'administration et d'exploitation
Définition des niveaux de redondance nécessaires
Mise en place de politiques de balancement de la charge
Figure 10 : Activités et responsabilités de l’IT
Par contre, on peut apercevoir dans le tableau ci-dessus, que le choix de l’outil de BPM est également
sous la responsabilité de l’IT. Il est très important que, lors de l’identification des solutions, les besoins
métiers soient pris en compte, mais également les directions technologiques prises par l’IT et ce de
manière à capitaliser au mieux sur ce qui se pratique au sein de l’informatique. Même si, et nous le
verrons plus tard, le métier devra indiquer tous ses pré-requis, l’IT reste maître sur le choix de l’outil,
et il sera très certainement nécessaire de conduire une expérimentation pour valider son choix final.
Les responsabilités partagées entre le métier et l’IT
Maintenant passons aux rôles et responsabilités partagées entre le métier et l’IT.
A c tiv ités
Communication
Modélisation des processus
Spécifications détaillées des processus
Création du référentiel de processus et règles métiers
Procédures de gestion opérationnelle
Exécution des processus
Performance des processus
Formation
Analyse et gestion des événements
Gestion des versions de processus
Figure 11 : Activités et responsabilités partagées entre le métier et l’IT
La communication est probablement un des éléments clés du succès de la démarche. Il est plus qu’important
de communiquer sur la mise en place de la démarche orientée « processus » et de bien indiquer que
tous les acteurs seront impliqués à un moment du cycle de vie de ces processus. Communiquer est une
activité difficile bien qu’aujourd’hui nous fassions communiquer les acteurs de l’entreprise par le biais de
moyens électroniques, il est devenu encore plus difficile de les faire communiquer oralement, alors que
c’est pourtant le moyen le plus efficace. Il est également important d’avoir une communication construite
et de choisir le message principal que l’on souhaite faire passer auprès de ses interlocuteurs. Plus le
discours sera complexe et détaillé, plus la probabilité d’un échec de la communication sera importante.
Les auditeurs ne sont pas tous du même niveau, et il faudra donc avoir un discours adapté.
Les experts métiers sauront modéliser les processus jusqu’à un certain niveau de détail. Pour la partie
système d’information, l’informatique reprendra la main sur ces processus et travaillera de concert avec
le métier de manière à être capable d’en comprendre le fonctionnement. Il existera, parfois, plusieurs
façons de traiter la règle ou activité en tenant compte des contraintes liées à l’informatique d’une part,
mais aussi au métier d’autre part. Sans travail conjoint, on aura toutes les chances de répondre à côté
des besoins des utilisateurs.

Les nouveaux rôles nécessaires au BPM
De nouveaux rôles émergeants voient le jour au sein des entreprises pour aider à la mise en place
de la démarche de Business Process Management ainsi que pour garantir la bonne utilisation des
processus.
Pour leur mise en place, on voit aujourd’hui des analystes métiers experts des processus d’entreprise
qui apportent leur savoir-faire au niveau de la formalisation et optimisation des processus. Ils sont
également les garants de la bonne utilisation du référentiel de processus mis en place. Ils sont formés
à l’outil de BPM choisi et connaissent principalement les fonctions de modélisation et de simulation
des processus.
La toute première responsabilité de ces nouveaux rôles sera de mettre en place une terminologie
commune. Trois rôles principaux seront à mettre en place : le responsable des processus (aux Etats-
Unis, le CPO : Chief Process Officer), le rôle de responsable d’un processus ainsi que le rôle d’analyste
des processus métiers (ou Business Process Analyst).
Le responsable des processus (au sens global) a pour responsabilités :

• De veiller au respect des processus
• D’identifier les gains tangibles par la mise en place ou l’optimisation de processus
• D’identifier les modifications au niveau de l’organisation à mettre en place pour supporter
les processus métiers
• De définir la granularité des processus pour en permettre une meilleure réutilisation si cela
s’avère nécessaire.
Le responsable d’un processus (Process owner) a pour responsabilités principales :

• De concevoir le processus dont il est responsable
• D’en piloter les performances
• De garantir les gains dans la durée
• Et de proposer les améliorations futures du processus
L’analyste des processus métiers a pour responsabilités

• De valider les méthodes à utiliser lors de la formalisation des processus
• De valider les standards à utiliser
• De définir les bonnes pratiques
• De mettre en place les outils et procédures pour partager la connaissance des processus
Bien entendu, le fait de rajouter ces fonctions ne fera pas tout. A son niveau, l’exécutif se devra d’être le
sponsor pour cette démarche. Il facilitera le travail entre métier et IT ce qui, dans certains cas, améliorera
la prise de décisions permettant ainsi d’atteindre les objectifs fixés par la stratégie de l’entreprise.
La conduite du changement
Le changement est un des fondements de toute activité d’une entreprise. Une entreprise qui change est
une entreprise qui s’adapte au marché. Certaines entreprises américaines dans les années 90 cultivaient
le changement. Une entreprise qui réussit est une entreprise qui sait anticiper le changement. Elle
est constituée d’hommes et de femmes qui en font sa richesse mais également le principal frein au
changement ; et par conséquent au développement. A cette période, le Président d’une société américaine
de logiciels prônait le changement en indiquant que tout collaborateur devait être capable d’accepter de
changer de poste voire de métier, à condition que son accompagnement soit en phase avec l’ampleur
du changement. Dans le Business Process Management, la problématique est similaire car la modification
des processus métiers de l’entreprise, peut bousculer plus ou moins fortement les méthodes de travail
des collaborateurs de l’entreprise.
C’est d’ailleurs la principale cause d’échecs de mise en place de projets de BPM avec une autre facette
qu’est la culture de l’entreprise et qui se trouve un peu oubliée. C’est pourquoi les acteurs de ces processus,
ou leurs représentants, doivent être impliqués dans la communication interne, mais également externe,
permettant d’obtenir une meilleure adhésion lors de la mise en place du projet de BPM. Il est important
de bien comprendre que les objectifs même du projet peuvent avoir un impact sur la culture de
l’entreprise. L’innovation a toujours fait peur, mais si une conduite du changement appropriée est mise
en place et que ces acteurs sont correctement mobilisés, la résistance à ces changements sera limitée.
Avoir envie de mettre en place une démarche orientée processus est simple et lancer le projet en soi
également. Mais son déroulement s’avérera d’autant plus complexe, que l’accompagnement n’aura pas été
correctement dimensionné. Le facteur humain est certainement le plus difficile à traiter et le plus imprévisible.
Un mauvais accompagnement sera préjudiciable à l’amélioration des processus de l’entreprise.
Aujourd’hui la conduite du changement a un coût, mais celui du non accompagnement est encore
plus important.
L’efficacité du pilotage opérationnel
Une autre partie de la conduite du changement est l’amélioration de la performance opérationnelle.

Lorsque de nouvelles technologies, voire plus simplement de nouvelles versions d’applications sont
introduites, on observe des baisses de productivité. Dans la figure ci-après nous montrons 3 courbes : La
courbe A qui est ce que l’on souhaite en termes de performance opérationnelle, la courbe C représente
la réalité sans conduite du changement et la courbe B représente ce qui est généralement constaté en
mettant en place une conduite du changement appropriée.
P ilotage
O p é rationnel
A
D
C
temps
Figure 12 : Efficacité du pilotage opérationnel
On observe régulièrement une baisse de la performance opérationnelle qui se situe, le plus souvent,
au moment de la mise en production du système. Par la suite, la performance s’améliore (Courbe C),
sauf à un certain moment où elle peut augmenter, mais cela ne représente que 5% des cas (plus par
chance qu’autre chose). Ce qui risque de se passer, c’est que la performance stagnera, mais encore plus
probablement, régressera car l’efficience du système résidera en la perception qu’auront les utilisateurs
de celui-ci, mais également en la manière de l’utiliser.
La courbe B est ce qui est perçu avec une conduite du changement appropriée et l’on voit aisément que
les résultats sont sensiblement améliorés et pérennisés.
Il est vrai que bon nombre de DSI se pose la question sur l’utilité ou non de la conduite du changement
et voient, en tout premier lieu, son coût. Ou alors, la conduite du changement n’est interprétée que
comme la mise en place de formations. Oui Mais ! Quels seraient les coûts si aucune conduite du
changement appropriée n’était intégrée au dispositif ? Les collaborateurs et le middle management de
l’entreprise seront-ils à même de conduire ce changement ? De manière générale la réponse est Non !
La conduite du changement est un métier en soi, et bien évidemment utiliser des experts en ce domaine
lors de la mise en place d’une démarche de Business Process Management ne serait que bénéfique et
facilitera la mobilisation et donc l’adhésion des acteurs impliqués. Néanmoins, il est nécessaire d’avoir
du « Leadership » au sein du dispositif de mise en place.

Le « Sponsorship » et le « Leadership »
Pour que l’initiative BPM soit un succès il est nécessaire d’avoir un bon niveau de « Leadership ». Le
niveau le plus courant est la direction de programme/projet qui, on le comprendra aisément, doit
être mobilisée, adhérer et agir de manière à être un vecteur fort de communication des projets de
BPM et qui sera également un sponsor de la conduite du changement. Néanmoins, il est également
important d’avoir le bon niveau de langage car de la simplicité des messages dépendra l’adhésion des
unités métiers (ou domaines métiers) qui est primordiale au succès des projets. Ces « leaders » ont
un rôle prépondérant dans la communication et doivent donc jouer un rôle d’orchestrateur dans la
communication au sein du programme ou projet. Ils sont généralement choisis pour leurs capacités à
influencer les équipes. Bien entendu, si vous avez un passionné du sujet, ce n’en deviendra que plus
facile, l’engouement étant un sentiment qui se diffusera et fera apparaître des personnes, au sein de
l’organisation, qui seront probablement de bons alliés dans la communication du projet.
Sponsorship
Leadership
s s
é é
Initiative BPM
Unit Unit
P rojet P rojet
A X
Figure 13 : La communication et la notion de leader
Autre niveau, le « Sponsorship » : il se place au niveau exécutif de l’entreprise (Direction Générale,

Senior management, …) et joue un rôle de sponsor du projet tout en influençant les différentes parties
de l’entreprise. Mais il ne faudra pas oublier une chose essentielle : l’implication du sponsor, véritable
moteur du projet, devra être en relation avec l’importance du projet.
Si des changements au niveau de l’organisation sont nécessaires, seul le « Sponsor » pourra aisément
communiquer sur ces changements, car légitime.
Les aspects sociaux doivent être pris en compte dans ces types de projets. Par exemple, un collaborateur
qui ne voit pas pourquoi sa fonction doit évoluer. Le Sponsor devra lui expliquer aidé par des experts
de la conduite du changement.
La résistance au changement
La résistance au changement est souvent consécutive à un sentiment perçu par des personnes. Elle
naît suite à des craintes de personnes au regard de leur environnement qui risque de changer, ou qui
est changé. Après analyse, ces craintes sont souvent justifiées au regard de chaque personne, mais
il est nécessaire de mener des actions en fonction du niveau de sentiment perçu par chacune de ces
personnes.
La figure ci-après, montre les sentiments ou raisons de la résistance au changement et leurs niveaux
respectifs d’importance.
La
e Complexit
é P eu r
L e s entim ent
d’ im puis s anc e é
à
g
L e s entim ent é
rer
quence rencontr d ’avoir à fournir
é
Fr trop d ’efforts et
dans la douleur
P as d ’int é rêt pers onnel
Figure 14 : Les sentiments et la résistance au changement
Il est très important que la résistance, qu’elle qu’en soit la cause, soit anticipée. La plus grande partie
des échecs passés se situent au niveau des collaborateurs impactés, qui, par manque ou bien souvent
absence de conduite du changement, se sont retrouvés être la source de résultats catastrophiques de
projets. De plus, le facteur humain est, de loin, le plus complexe à gérer. Des consultants expérimentés
en conduite du changement sauront comment appréhender les résistances rencontrées. On voit d’ailleurs
qu’une identification en amont est bénéfique. Elle est effectuée par le biais de questionnaires de la ou
des personnes qui pourraient s’avérer être des freins au projet. C’est par leur approche négativiste
du sujet et surtout par leur incompréhension des impacts au niveau de l’entreprise sur son efficience
économique, qu’elles sont identifiées.
Une des techniques permettant de réduire cette résistance est de faire comprendre aux acteurs que leurs
propos sont pris en compte avec toute la considération nécessaire.
En ce qui concerne la résistance au changement, les impacts se situent à deux niveaux différents :
• au niveau de la proposition de changement à opérer pour rendre la partie de l’entreprise concernée
plus efficace, et
• au niveau de l’efficacité de la mise en place du changement.
La démarche de la conduite du changement

Partons du principe que le changement doit s’opérer au sein de l’entreprise, de l’entité ou toute autre
partie de l’entreprise et de son écosystème et ce pour le bien de tous. Cette conduite est primordiale
à la bonne marche de l’entreprise et ceci doit être clairement expliqué. Il est nécessaire de viser la
mobilisation des acteurs et non pas des moyens techniques qui devront suivre de toute manière. Trop
souvent une focalisation sur la solution technique est faite et l’accompagnement au changement est
alors oublié. Ceci a bien souvent pour conséquence de créer des formations jugées « trop tardives »
pour tenter de palier au manque d’accompagnement initialement prévu.
C’est pourquoi une démarche simple de conduite du changement doit être définie. Par ailleurs cette
démarche ne doit pas être disproportionnée avec le projet impliquant les changements, faute de quoi
le déséquilibre pourrait avoir un effet néfaste.
C’est également pourquoi la démarche de la conduite du changement doit s’appuyer sur 4 axes.

t
SStrat men
tra ne
téégie
gie p ag
om
A cc
Accompagnement
C onduite du
C hangement
hip AAppropriation
pp
rs rop
a de riat
LeLeadership ion
Figure 15 : Les 4 axes de la conduite du changement
La stratégie, portée par les décideurs, permet d’analyser la situation et de définir les objectifs
associés.
La notion de Leadership fait référence au « Sponsorship et Leadership » précédemment expliqués.
L’accompagnement fait référence aux utilisateurs et les actions vont de la gestion des impacts
humains à la communication en passant par l’organisation, l’ergonomie des applications, la formation,
la documentation et l’assistance sous diverses formes.
L’appropriation, fait également référence aux utilisateurs et sera l’axe leur permettant d’avoir envie
du changement imposé et surtout d’avoir envie de ne plus revenir en arrière.
La démarche doit prendre en compte ces quatre axes.
La figure ci-dessous donne un exemple d’une démarche simple et pragmatique de conduite du

changement.
A na lys e
S tra t égie
du
d’ a c c o mpa gnement
c ha ngement
P ha s e de c a dra ge
C o nc eptio n de
R éa lis a tio n
l’ a c c o mpa gnement
P ilo te P é rennis a tio n
Figure 16 : Les phases de la conduite du changement
Cette démarche n’est pas à appliquer au pied de la lettre, car comme tout changement n’a pas le même
effet d’une entreprise à l’autre, il sera nécessaire de l’adapter au contexte. Il faudra également l’adapter au
fur et à mesure de la mise en œuvre du changement et en fonction des avancées effectuées. Les acteurs
seront également différents en fonction de l’entreprise mais également en fonction des populations
visées au sein de celle-ci. La conduite du changement se base sur un plan d’actions lesquelles doivent
être correctement suivies. C’est ce suivi qui permettra pour partie, de mesurer la progression associée
à des objectifs mesurables.
La phase de cadrage
La phase de cadrage permet de prendre en compte tous les éléments de contexte, d’en faire une analyse :
« l’actuel », d’exprimer une « cible » et d’en faire découler la « stratégie d’accompagnement ».
L’analyse lors de la phase de cadrage doit permettre d’étudier :

• les enjeux du changement
• les gains escomptés
• la solution technique pressentie
• les métiers et populations concernées
• les contraintes associées
L’actuel
C’est ce qui est appelé communément le « As-Is ». Dans cette partie on procède à un diagnostic, au
contraire d’un audit qui aurait ici une connotation négative, alors que l’objectif est bien d’identifier les
points positifs et négatifs de la situation actuelle.
On décrit alors :
• comment fonctionne l’entreprise,
• quels sont les problèmes rencontrés dans le fonctionnement et quelles en sont les causes possibles
L’analyse effectuée peut conduire à des divergences au niveau des points de vue des problèmes identifiés.
Il sera nécessaire de bien les lister et de conduire des ateliers permettant d’avoir une vision commune
à tous les acteurs.
La Cible
Cette partie consiste en une formalisation des changements et permet de trouver les solutions
d’accompagnement les plus adaptées. Il est également nécessaire de conduire des ateliers sur ces sujets
pour impliquer les acteurs et les sponsors, car ils permettent une meilleure adhésion aux solutions
trouvées. Parfois certaines visions restent divergentes et les sponsors devront jouer leurs rôles pour
aider dans le choix de la solution et pour favoriser l’adhésion. La finalité de cette partie doit permettre
d’avoir des prescriptions, des solutions associées et les éléments de décision associés. Ces solutions
doivent être alors clairement formalisées pour que la phase « Stratégie d’accompagnement » puisse être
démarrée, ce qui veut dire que toutes les parties concernées par le changement et impliquées dans cette
conduite doivent être d’accord sur la nature du changement à apporter et sur les solutions envisagées.
Il n’y a pas de place pour le « Oui, mais … ». Il est important que la vision de tous les acteurs converge
vers la cible ainsi identifiée.
La stratégie d’accompagnement
Cette phase est celle de la mise en œuvre du changement. A ce stade, il est nécessaire de préparer
un planning détaillé de la conduite du changement. On doit indiquer les tactiques pressenties pour
y parvenir et les points restés en suspens qui nécessitent des réponses pour que cette conduite soit
appropriée. Probablement que cela conduira à de nouveaux ateliers, voire même des formations pour
des populations d’acteurs supplémentaires.
Les sponsors auront également leur rôle à exercer pour faciliter la mise en place du changement.
N’oublions pas les enjeux du projet de BPM qui est mis en place. C’est essentiel dans la démarche
globale ! Il faudra également conduire de nouvelles enquêtes pour évaluer le niveau de mise en place
du changement et les « nouveaux » points de résistances.
Le suivi des actions recommandées pour cette mise en place est important. Il ne faut pas perdre de vue
que la conduite du changement est un projet en soi qui doit être traité en tant que tel ! Le suivi des
actions et les enquêtes successives sont les meilleurs moyens de vérifier sa mise en place.

Cette phase donne lieu à la définition des outils nécessaires pour conduire le changement :
• Identification des solutions en termes de formations et de documentations à produire,
• Niveau d’assistance nécessaire,
• Définition du plan de communication,
• Formalisation de premières préconisations.
Lorsque tous les éléments qui devront composer l’outillage de la conduite du changement sont identifiés,
on peut passer à la phase suivante.
La conception de l’accompagnement
Cette phase consiste en la formalisation de tous les documents et supports nécessaires, identifiés lors
de la stratégie d’accompagnement.
C’est alors que l’on conçoit tous les outils qui seront utilisés lors de la phase de réalisation de la conduite
du changement comme :
• La définition des contenus des documentations et supports nécessaires pour dérouler le plan
de communication et dispenser les formations
• La définition des processus de validation des actions suivies et des outils associés nécessaires
ainsi que de leurs fonctionnalités
• La définition du contenu du glossaire de termes communs
• La définition de l’organisation à mettre en place pour garantir un bon accompagnement
La réalisation
La phase de réalisation consiste en la rédaction et la préparation de tous les documents et supports ainsi
que de la mise en œuvre de l’organisation nécessaire.
Les profils sont définis, identifiés et interviewés de manière à ce que les équipes soient rapidement au
complet, s’il est nécessaire d’en créer.
Le plan d’actions est exécuté et toutes les actions sont mises à jour pour garantir un bon suivi. On utilise
tous les outils identifiés et utiles.
Le pilote
L’objectif du pilote est de valider les documents et supports produits lors de la phase de réalisation, ce
qui permet d’ajuster certains points de la démarche en vue de la phase de pérennisation.
La pérennisation
La pérennisation a pour principal objectif de s’assurer que la conduite a eu tous ses effets dans le temps.
Des activités devront avoir lieu pour valider qu’elle est faisable dans l’état actuel, sans pour autant avoir
à mener trop d’actions pour la garantir.
Les principales activités à conduire sont :

• la formation continue induite par du turn-over par exemple,
• effectuer des bilans des formations,
• mettre à jour le plan de communication avec des éléments rafraîchis,
• informer les utilisateurs de toutes les évolutions,
• suivre l’ergonomie des interfaces qui avaient besoin d’évoluer,
• procéder à la mise à jour des documentations,
• etc.
Toutes ces activités permettront de veiller à ce que la conduite du changement soit correctement adressée
dans la durée et d’accompagner correctement les évolutions à venir.
Les composants de la conduite du changement
L’expérience a démontré que la conduite du changement n’est pas que de la formation ou de la simple
communication, et que les projets qui se sont limités à ces activités ont eu des succès plus mitigés que ceux
qui étaient espérés. Le fait d’adresser plus largement et en prenant en compte des aspects sociologiques
(comportement humain, comportements en société, écosystème, organisation, etc.) a toujours porté
ses fruits. Pour que cette conduite se déroule correctement, il est important de comprendre que les
composants majeurs de cette conduite seront les suivants :
• Le planning de la conduite du changement en fonction des temps forts du projet de BPM
(planning jalonné),
• L’identification du changement, ce qui sera produit et quelles informations seront nécessaires
pour l’utiliser à bon escient,
• Lister :
~ les avantages qui vont être tirés de ce changement et à quels niveaux,
~ les impacts sur l’organisation de l’entreprise et comment on va amener
ces changements d’organisation,
~ les personnes clés de l’entreprise pour conduire ce ou ces changements,
• L’identification claire des liens entre le programme/projet et la stratégie de l’entreprise
• L’identification :
~ des points différenciant
~ des nouveaux rôles et/ou fonctions nécessaires au bon déroulement des nouvelles
méthodes de travail impliquées par le changement des processus de l’entreprise
• La définition :
~ d’un plan de communication global et détaillé en fonction des populations impactées
et les différents supports utilisés (ateliers, réunions, newsletter, …)
~ des formations à dispenser de manière à valider la bonne compréhension du changement
Quelques bonnes pratiques
Le succès de la conduite du changement réside, entre autre, dans le fait d’anticiper les résistances qu’il
va susciter. Il est donc important d’avoir une bonne perception de la population qui sera rencontrée
et si possible que les managers aient déjà introduit le sujet auprès de cette population, de manière à
bénéficier d’un premier retour sur la mise en place de l’orientation processus.
Pour anticiper ce changement, les leaders devront se poser les questions suivantes et obtenir les réponses
associées, comme par exemple :
• Pourquoi le changement est-il nécessaire ?
• Quelles seront les conséquences du changement au niveau organisation, puis au niveau individuel ?
L’expérience nous montre quelques bonnes pratiques comme :

• La participation à l’élaboration : Un seul maître mot : l’implication ! Il faut que les acteurs
soient tous correctement impliqués pour garantir une bonne adhésion au changement.
• La mise en situation : Transposer et mettre les acteurs en situation très rapidement, permettra
de mieux anticiper les problèmes et d’apporter les solutions adéquates. Par ailleurs, le pilote est
important pour réitérer sur les supports et documents avant de généraliser la solution
• Testimoniaux et communication sur les premiers résultats obtenus : Il est important de
bien communiquer sur les résultats et d’apporter des témoignages et retours d’expériences.
Cela facilite l’adhésion au changement
• Coaching : La notion d’entraînement peut apporter beaucoup. Les athlètes s’entraînent avant
une épreuve ; pourquoi les collaborateurs et acteurs ne pourraient-ils pas s’entraîner avant une
généralisation ? Avoir un coach ou un sachant peut les aider à se sentir plus confortables lors
des entraînements.
• Communiquer largement sur la cible/Vision : Donner une bonne visibilité de l’objectif à
atteindre, et de l’avancement des actions permettant d’arriver à la cible.
Une démarche pragmatique prévaut à toute autre. N’hésitez pas à échanger, à comparer les expériences.
Quand un problème se pose, montez un groupe de travail. La créativité en groupe est dix fois supérieure
à celle de réunions face à face avec les mêmes personnes.

Pas de succès sans démarche processus pragmatique
La démarche est un élément clé, certes, mais elle doit être pragmatique. On trouve différentes
méthodologies permettant d’améliorer les processus, mais il n’en existe aujourd’hui aucune qui puisse
être un remède miracle. Au contraire d’une méthodologie, une démarche se doit d’être illustrée par des
exemples réels nommés « bonnes pratiques ». Le réel pragmatisme de la démarche fera des projets des
succès incontestables et faisant office de référence au sein de l’entreprise. Elle se doit d’être une démarche
d’ensemble qui prend en compte tout le cycle de vie des processus, du métier aux technologies, et en
prenant en compte les moyens de pilotage nécessaires à un bon niveau de réactivité et d’agilité.
Conseils avisés ou retours d’expériences, les bonnes pratiques permettent soit de donner des exemples sur
la mise en place de projets de BPM dans un contexte précis, soit de démontrer comment certains écueils
peuvent être évités. Les écueils sont bien souvent sources de déconvenues qui peuvent avoir un coût,
parfois non négligeable, au niveau du projet voire de l’activité économique de l’entreprise. Néanmoins, ils
font partie des meilleurs enseignements à tirer. Ces coûts, qui peuvent résulter de mauvaises estimations,
de surcoûts non anticipés ou de délais non respectés, sont souvent dus à des risques mal identifiés et
surtout mal adressés depuis le démarrage du projet. La gestion des processus n’est pas nouvelle en soi. Ce
qui est nouveau, c’est le fait de pouvoir gérer leur cycle de vie complet : de la modélisation à l’exécution
et l’optimisation. Les outils doivent permettre d’avoir l’accostage nécessaire entre la modélisation métier
et l’implémentation, point pour lequel, il n’existait aucune solution jusqu’alors.
Il apparaît donc important que les bonnes pratiques soient d’une part formalisées mais d’autre part
soient capitalisées pour permettre à d’autres acteurs de les retrouver et de les réutiliser. L’une des
méthodes consiste à mettre en place un portail de gestion de la connaissance (knowledge management)
permettant ainsi à tous les acteurs, qu’ils soient métier ou technique, de partager leurs savoir-faire, leurs
expériences sur des projets similaires, d’échanger entre eux, et ce dans l’unique but d’accélérer la mise
en œuvre des projets suivants.
L’objectif des bonnes pratiques est d’améliorer la fiabilité des projets, le respect des délais initialement
prévus et la réduction des coûts estimés pour des projets similaires.
Les 4 grandes familles de processus

Pour commencer nous pouvons identifier les processus en fonction de leur cible.
Pour cela on distingue 4 grandes familles de processus qui chacune d’entre elle, est fonction d’un
besoin précis. Ces besoins peuvent être cumulés et le choix de l’outil dépendra des types de processus
à supporter faisant apparaître parfois l’utilisation nécessaire de plusieurs produits différents.
P roces s us P roces s us
d’ intégration humain
BPM
P roces s us
décis ionnel P roces s us
documentaire
Figure 17 : Les familles de processus
Le Business Process Management adresse les 4 familles de processus suivantes :
• Les processus d’intégration : Orientés vers l’intégration de systèmes, ils permettent d’automatiser
des activités et d’intégrer les applications internes ou externes de l’entreprise.
• Les processus humains (ou collaboratifs) : Ils sont utilisés pour le suivi des activités réalisées
par des collaborateurs, partenaires et même des clients. Ils permettent de définir les modes de
collaboration entre tous les acteurs et les enchaînements successifs des activités.
• Les processus décisionnels : Ils apportent des informations à des acteurs leur permettant ainsi
de prendre des décisions.
• Les processus documentaires : Ils permettent de gérer des documents (contrats,
formulaires,…) qu’ils soient structurés ou non (électroniques ou manuscrits).
Les processus d’ « intégration »
Les processus orientés intégration sont ceux qui vont permettre d’automatiser « au mieux » la chaîne
de traitement avec un minimum d’interaction humaine. La particularité de ces processus est qu’ils
permettent un volume de traitements important. Dans le domaine de la finance, ces processus concernent
souvent les moyens de paiements, la gestion de titres voire de valorisation de portefeuilles boursiers.
Ces processus orientés intégration vont donc nous permettre d’intégrer une application particulière
avec le reste de l’écosystème, qu’il soit interne ou externe.
Dans l’automatisation et l’intégration des processus il va être nécessaire que la solution puisse
apporter :
• des fonctionnalités d’intégration et de modélisation de processus,
• un environnement de développement,
• une gestion de version et du cycle de vie du processus,
• une orientation SOA,
• une capacité à s’intégrer dans un portail voire d’intégrer une fonctionnalité de portail d’accès web,
• d’avoir une gestion et suivi des processus et sous processus (au sens transactions),
• d’apporter des mécanismes pour gérer des partenaires et permettre leur intégration,
• d’apporter un moyen de tracer et superviser les processus pour permettre d’en ressortir des
statistiques qui seront utilisées pour analyser les axes d’optimisations possibles de ceux-ci.
La principale différenciation pourra alors se faire sur la capacité à simuler les processus et le support à
l’intégration de règles métiers ce à quoi, les outils d’EAI (par exemple) n’étaient pas voués et ce qui a
été d’ailleurs, l’une des raisons principale d’échecs dans leur mise en place.
Dans les principaux exemples de processus d’intégration on peut citer l’exécution de commande, la
« Supply Chain(*) » et tous les processus intégrant des bases de données, des applications ou des
partenaires. Les processus d’intégration mettent en œuvre des échanges inter applications et dans le
cas de processus automatisés on va parler d’intégration de processus (BPI(*)).
Les processus « humains » ou « collaboratifs »
Ces processus sont ceux qui vont permettre de piloter des activités humaines ou des processus
collaboratifs. Par exemple, on peut citer la chaîne d’accueil de nouveau personnel, la gestion des
sinistres dans l’assurance, les processus d’ « Order to Cash ». Ces processus sont focalisés sur le service
à des personnes ou clients ou permettent de router, sur contenu ou événement, des requêtes vers des
cibles diverses. Ces processus ont, en général, besoin de gérer une corbeille d’activités accessible via
un portail web, et permettront aux utilisateurs de suivre et d’exécuter leurs activités, de les router, de
changer leur état, le tout en prenant en compte la disponibilité des acteurs du processus via une gestion
d’agenda. Ces processus sont appelés en anglais : « Human Centric Processes ».
On comprendra aisément, que ces processus doivent pouvoir s’appuyer sur des outils qui proposent :
• une gestion de corbeilles avec une gestion des droits et des agendas associés,
• un portail d’accès web avec gestion d’utilisateurs/mot de passe associé,
• une interface de développement des écrans utilisateurs,
(*) voir glossaire • une gestion :
page 192 ~ de l’organisation en place (utilisateurs et niveaux hiérarchiques) pour permettre une

gestion de groupe d’acteurs avec des possibilités d’escalades selon des critères bien définis
~ de formulaires
• une couche d’intégration permettant de s’intégrer avec le reste du monde que ce soit des couches
techniques (bases de données par exemple) ou des applications métiers (ERP(*), CRM, SCM(*),…).
Cette couche d’intégration se devra d’être compatible avec une architecture SOA.
Les outils de BPM doivent également s’intégrer à des portails tiers car bien souvent on va devoir fédérer
différentes applications de l’entreprise et permettre l’accès à des utilisateurs en fonction de leur profil.
Les processus « décisionnels »
Dans le cadre de la définition des processus métiers, des indicateurs sont définis. Ils sont de diverses
natures permettent de superviser les processus, sous-processus, activités à partir de tableaux de bord.
Ces indicateurs peuvent également servir à superviser des seuils qui, lorsqu’ils sont atteints vont alerter
un superviseur du dysfonctionnement du processus. Ces alertes permettent au superviseur de prendre
des décisions.
Vous le constaterez aisément, mais on peut utiliser les outils de BPM au même titre que des outils de
Business Intelligence pour permettre la prise de décision au regard d’indicateurs. Nous verrons d’ailleurs
que les outils décisionnels peuvent être complémentaires de solutions de Business Process Management.
On parle ici de pilotage opérationnel des processus.
Parmi les processus orientés décisionnel, on peut citer comme exemple l’octroi de prêts, de crédits
immobiliers, etc.
Les processus « documentaires »
Les processus de gestion de documents sont très souvent utilisés dans le cas de point de validation
de documents, de prise de décision et d’exécution de plan d’actions en rapport avec le contenu de
documents scannés, d’images ou de documents de type texte. Ces processus permettent de gérer le
circuit de diffusion de l’information.
Les processus de validation d’un contrat par exemple, font partie des processus orientés gestion
documentaire. Ces processus sont bien souvent mis en œuvre dans le cas de projets de GED(*). Les outils
de Workflow ou les fonctionnalités de Workflow des outils de BPM sont utilisés dans ce cadre.
On parle également de dématérialisation qui consiste en la transformation de documents réels (papier par
exemple) en documents numériques, ce qui en facilite le traitement d’une part, et augmente la sécurité
d’autre part. La dématérialisation est souvent préconisée dans les procédures permettant de garantir
à une entreprise la continuité d’activité en cas de sinistre important, de par la sauvegarde numérique
rendue alors possible, et la sous-traitance de l’archivage. Elle permet également de limiter la duplication
papier de documents et un traitement immédiat de la gestion de leur contenu.
Processus verticaux et horizontaux ou transverses

Il existe 2 types de processus métiers : les processus verticaux et les processus horizontaux. Pour
les processus verticaux, ils font appel à un domaine unique. On peut prendre pour exemple dans la
« Figure 8 : Processus verticaux et horizontaux », le processus au niveau des ressources humaines qui
est un exemple de processus de recrutement. Ce processus est déclenché par le besoin d’embaucher un
candidat à un poste vacant pour lequel une fiche de profil de candidat sera définie. Une fois cette fiche
établie, des profils sont recherchés par divers moyens, des entretiens sont conduits jusqu’à la sélection de
celui-ci. On reste bien dans un processus au niveau des ressources humaines. Les processus horizontaux
(ou appelés processus transverses) vont au contraire, faire intervenir des acteurs de plusieurs domaines
de l’entreprise. Une commande fera appel au domaine des ventes pour traiter des commandes de clients,
au domaine logistique pour vérifier la disponibilité de produits, en finissant par la comptabilité pour
éditer la facture et suivre le paiement de la commande.
(*) voir glossaire
page 192
On comprend que dans le second cas, les processus plus complexes vont faire appel à un consensus
entre des personnes, des systèmes et des clients. Libre à l’entreprise de choisir les procédés à utiliser
pour le traitement des demandes des clients. La qualité de traitement visible du client sera fonction de
la qualité du processus transverse et de son mode de pilotage de bout en bout.
Figure 18 : Vision client d’un processus
Les processus verticaux mettent en avant la hiérarchie (managers et collaborateurs) et les mesures
associées alors que le processus horizontal prend en compte la chaîne de valeur de l’entreprise et apporte
une vision cohérente avec la vision du client.
R es s ourc es C om pta bilit é

V entes L ogis tique
Hum a ines F ina nc e
P os tes va ca nts C lie nts c ibles
R ec herc he de c a ndida ts C om m a ndes D is ponibilit é
L ivra is on de s produits
E ntre tie ns E dition de la fa c ture
e t/ou s e rvice s
S é lec tion du c a ndida t R ece voir le pa ie m e nt
Processus Processus horizontal

vertical
Figure 19 : Processus verticaux et horizontaux
Le consensus est incontournable du fait des contraintes liées aux différents domaines. Il sera nécessaire
de trouver le meilleur moyen de répondre aux entrants de chacun des domaines pour réaliser les
activités nécessaires, et de livrer au domaine suivant toutes les informations qui lui permettront, à son
tour, d’effectuer ses activités, le tout en respectant au mieux les besoins du client. Assez simple quand
on fait intervenir un domaine unique, plus complexe dans le cas de domaines multiples.
Les approches Top-Down et Bottom-Up

Pour mettre en œuvre des projets qu’ils soient d’intégration ou de processus métiers, il existe 3 approches
possibles :
• Top-Down
• Bottom-Up
• Mixte Top-Down/Bottom-Up ou “Topup”

Quelle que soit l’approche choisie, il sera utile voire indispensable de correctement prendre en compte
certaines contraintes de conception comme :
• minimiser les impacts au niveau de l’outil mis en œuvre
• garantir les délais d’implémentation courts
• utiliser une approche reproductible.
Approche Top-Down
L’approche Top-Down ou descendante, procède comme son nom l’indique de haut en bas et consiste
en une démarche où les processus sont décrits par le métier ou par un domaine fonctionnel.
Les impacts sont, en général, fonction de l’importance des modifications apportées au processus. Si
les modifications ont trait aux activités du processus, alors l’impact peut être important. Par contre,
si les modifications sont au niveau de règles simples de fonctionnement ou de décisions, alors les
modifications du processus seront plus simples à prendre en compte et seront fonction de la conception
des processus.
T op-Dow n
Figure 20 : Approche Top-Down

On voit bien souvent qu’une mauvaise conception a des impacts importants en termes d’évolutions
futures.
Cette approche permet, par contre, de mieux garantir que l’implémentation des processus correspondra
aux attentes du métier.
On va donc commencer par définir les grandes lignes du processus et descendre, pas à pas, dans les
détails, jusqu’à arriver aux données et aux systèmes. Les systèmes disposent des données et des formats
permettant d’y accéder.
Au niveau conception on va indiquer les activités et détailler leur fonctionnement. Plus tard, lors du
développement des processus, les fonctions unitaires seront alors conçues et devront être conformes
aux besoins métiers tout en garantissant un bon niveau de réutilisation.
Les principaux avantages de l’approche Top-Down sont :

• Les équipes de développement restent focalisées sur l’objectif
• Les membres de l’équipe de développement ont un découpage de leurs activités très clair
• D’expérience, il y a moins de questions à propos du fonctionnement des tâches de processus
(sous réserve que le besoin soit correctement exprimé)
• Il est plus simple de reprendre un code existant.

Les principaux inconvénients de l’approche Top-Down sont :
• Les tests sont plus complexes et ne pourront avoir lieu que quand tous les développements
seront terminés
• Les décisions prises sont basées sur les objectifs du projet et pas en fonction de descriptions
réalisées ultérieurement (sauf pour les spécifications détaillées qui sont structurantes)
Cette approche est donc orientée « utilisateur ». On va d’abord comprendre comment les utilisateurs
se servent des systèmes et effectuent leurs tâches de tous les jours.
Approche Bottom-Up
L’approche Bottom-Up ou montante, procède comme son nom l’indique de bas en haut et consiste en
une conception du système qui débute de la conception technique de services dans tous ses détails
(bas niveau) pour arriver à la conception fonctionnelle du système et aux blocs principaux qui sont
constitués à l’aide de ces composants bas niveau.
Par analogie, une maison est construite sur une démarche « Bottom-Up ».
B ottom -U p
Figure 21 : Approche Bottom-Up
Cette approche est plus risquée car elle fait peu appel au métier et donc, a plus de chances de ne pas
bien répondre aux besoins exprimés. C’est ce qui peut se produire quand l’initiative d’un projet ne
provient que des services techniques et pas des services métiers. Un autre risque est de s’apercevoir au
bout d’un certain temps que des détails techniques sont manquants et qu’il est nécessaire de refaire une
partie de la conception pour garantir l’adéquation avec les besoins métiers.
Une approche Bottom-Up permet plus facilement le déroulement des tests unitaires. Elle est focalisée
sur le contenu. On va identifier les données nécessaires et mises à disposition au niveau des systèmes
pour remonter vers les utilisateurs. Cette approche est bien souvent plus éloignée des besoins, mais
permet de bien connaître les informations accessibles aux utilisateurs.
Approche mixte : Topup
L’approche mixte (ou que l’on peut appeler Topup), consiste en une combinaison entre les approches Top-
Down et Bottom-Up. Dans cette approche, le métier et le fonctionnel définissent les processus métiers,
les fonctions métiers et les données associées dont ils ont besoin pour le bon déroulement de l’activité.
Les services techniques définissent les fonctions techniques et comment elles seront accessibles.

Figure 22 : Approche mixte Top-Down/Bottom-Up
Le curseur peut varier en fonction du niveau de responsabilité de chacun des groupes. Les travaux vont
consister en une correspondance entre les fonctions métiers nécessaires, et les fonctions techniques
associées et mises à disposition par le système d’information pour permettre aux équipes techniques
de créer les services manquants, d’assembler tous les services et processus, et de les tester avec les
responsables métiers.
Quoi de plus naturel que d’utiliser la gestion des processus métiers pour faciliter l’alignement des objectifs
stratégiques avec le système d’information. Cette approche demande une très forte collaboration entre
les maîtrises d’ouvrage et les maîtrises d’œuvre, mais augmente les chances de succès des projets et par
voie de conséquence contribue à la bonne conduite de la stratégie de l’entreprise.
de
de la
la strat
strat
Ex
Ex
Strat
Strat ééggie
ie
mm é Nouveaux produits
Nouveaux produits et
et services
services Ex
é Exééccutif
utif
éé cution Augmenter la
Augmenter la proposition
proposition de
de valeur
valeur
tier cution
tier
Amé liora tion de la pe rforma nce op
Am é liora tion de la pe rforma nce op ééra
rationnelle
tionnelle
éé
gie
gie
PPerfo
erform
rman
ance
ce op
op ératio
é rationnnnelle
elle
Supervision
Supervision de
de la
la performance
performance desdes processus
processus de
de AAna
nalys
lyste
tess
bout
bout en
en bout
bout m
méétie
tiers
rs
Contrôle temps
Contrôle temps rr éel
éel
A g ilit é Gestio
Gestionn ddes
es ppro
rocessu
cessuss m
m éétiers
tiers Co
Conc
nceepte
pteurs
urs
M é tier Mise àà disposition
Mise disposition rapide
rapide de
de nouveaux
nouveaux services
services de
de
Automatisation et
Automatisation et optimisation
optimisation de
de processus
processus pro c e s s us
pro c e s s us
Gestio
Gestionn ddes
es services
services
l’l Tirer
Tirer parti
parti de
de A
Arc
rchite
hiteccte
tess
’IT
IT Standardisation des
Standardisation des services
services eett
Réduction
Ré duction des
des coco ûts
ûts dd ’int
’int égration
égration
existant
existant urba
urbanis
niste
tess
Garantir ll ’évolutivit
Garantir ’é volutivit éé du
du syst
syst èème
me
IInnttég
égratio
rationn dduu syst
syst èèm
m ee
Interop éérabilit
Interop rabilit éé du
du syst
syst ème
ème IIng
ngéénie
nieurs
urs
Standardisation de
Standardisation de lo
logic
gicie
iels
ls
l’architecture
l’architecture et
et des
des services
services dd ’infrastructure
’infrastructure
Figure 23 : Démarche Topup
Les résultats sont plus probants. On travaille en parallèle sur les besoins et les moyens techniques. Bien
entendu, la collaboration joue un rôle essentiel. Néanmoins, les terminologies employées des uns et
des autres peuvent s’avérer très différentes. Il sera de bon augure de bâtir un dictionnaire des termes
employés et de mettre en place un atelier permettant aux MOA(*) et MOE(*) de trouver les définitions
communes de ces termes. Toute définition doit être sans équivoque et dès le tout début du projet.
(*) voir glossaire

page 192
La candidature des processus
Tous les processus ne sont pas de bons candidats pour être intégrés au sein d’une solution de BPM, mais
tous devraient être au moins formalisés. C’est pourquoi, il est nécessaire d’identifier les processus candidats
par l’utilisation d’une méthode appropriée. Bien sûr, cette méthode générique doit pouvoir s’adapter au
contexte et en fonction des enjeux et objectifs de l’entreprise ainsi que de ses produits et/ou services.
Une méthode qui a déjà fait ses preuves est la méthode Six Sigma qui permet d’identifier les processus
cœur de métier et les processus dit de « support » et de procéder à leur formalisation pour en définir
les axes d’améliorations.
L’objectif étant de prioriser les processus, on pourra alors concentrer les efforts sur les processus les
plus prioritaires mais également en fonction de la nature des dysfonctionnements constatés par le
management de l’entreprise.
De manière générale, on constate qu’une entreprise qui a mis en place une démarche de BPM pour
palier à des dysfonctionnements, finit par utiliser la même solution pour d’autres processus.
Chaque entreprise a ses propres objectifs stratégiques et en fonction de ces objectifs peut varier la
priorité des processus à intégrer et optimiser.
Le Cycle de vie du BPM

Pour accompagner la démarche, les responsables de processus de l’entreprise, utilisent un outil de
BPM permettant de cadrer et accompagner leurs tâches et veiller à ce que les éléments essentiels de la
démarche soient correctement appliqués. Le cycle de vie du BPM impose une vue itérative permettant
de veiller à ce que les processus puissent évoluer et être optimisés dans des cycles courts.
Les quatre principales étapes du cycle de vie sont :

• Conception & formalisation
• L’exécution des processus
• La gestion et la supervision
• L’analyse et l’optimisation
Conception & formalisation
Analyse Exécution
& des
optimisation processus
Gestion & Supervision
Figure 24 : Cycle de vie du BPM
Chacune de ces étapes adresse des points particuliers que nous allons un peu plus détailler.
Conception & formalisation
Les processus sont en général modélisés à l’aide d’un outil graphique que les experts métiers et/ou
fonctionnels maîtrisent ou, tout du moins, qu’ils peuvent prendre en main dans des délais relativement
courts.

Ce qui sera le plus important au niveau de l’outil de modélisation sera sa capacité à permettre la
réutilisation des modèles dans un outil de BPM si ceux-ci sont séparés. Il est alors possible que les
experts métiers utilisent l’outil de BPM avec une vue qui leur soit propre et compréhensible pour les
modéliser. La différence des outils de BPM se fera sur la capacité en termes de modélisation et de
simulation ainsi que de l’utilisation ou non de standards graphiques de représentation.
L’expert métier doit avoir également la capacité à simuler son processus. L’expert technique le fera
également, mais avec la différence qu’il voudra simuler en exécutant des instances multiples alors que
l’expert métier voudra connaître la capacité que des chargés de clientèle, par exemple, auront à traiter
des commandes, si ils sont 5 puis 10, puis 15. Par cet exemple, on comprend certainement mieux ce
sur quoi ces 2 populations d’utilisateurs vont se focaliser. Maintenant, la simulation pourrait être plus
efficace si l’outil pouvait permettre l’utilisation de données provenant des systèmes qui sont en production
au lieu de données créées dans l’unique but de tester ces processus. D’ailleurs, la pertinence des tests
influera directement sur l’efficacité des processus conçus.
Donc si nous résumons, la phase de conception doit permettre de :

• Modéliser les processus en utilisant un outil graphique,
• Définir les activités et règles métiers associées,
• Définir les éléments de coûts du processus pour chacune des activités (si cela est possible),
• Simuler les processus au plus près de la réalité, avec les éléments de coûts identifiés et quand
cela est possible, en utilisant des données provenant de la production. On pourra à ce moment
effectuer un premier niveau d’optimisation.
Il ne faut pas oublier que ce qui est primordial c’est de pouvoir correctement documenter les processus
de manière à permettre d’échanger avec tous ces acteurs. Les échanges doivent permettre de modifier
rapidement ces processus, de les simuler pour démontrer les alternatives possibles et leur efficacité
pour finaliser la version à implémenter au sein de l’outil.
fournir • Concevoir les processus m étiers

à Niveau 4
•G érer les processus m étiers
•Piloter la performance
•Utiliser un r éférentiel de processus
Niveau 3
• Automatiser les tâches
• Analyser les écarts dans la cha îne de
valeur
Niveau 2
Niveaux des efforts
• Eliminer les d éfauts
• Eliminer les tâches sans valeur ajout ée
• Réduire le d élai entre les activit és
Niveau 1
Figure 25 : Efforts à fournir
Le niveau des efforts à fournir peut varier. On peut classer ces niveaux d’efforts en 4 catégories :
• Niveau 1 : A ce niveau, on se concentre sur l’élimination de défauts, de tâches sans valeur ajoutée
apportées à un produit ou service, ou de réduction de délais de traitement. On sous-entend que les
processus sont connus et formalisés.
• Niveau 2 : L’automatisation des tâches va impliquer de manière plus forte l’intégration au système
d’information et réduire, par exemple, les saisies de données dans de multiples applications. A ce
niveau, les processus sont également connus et formalisés sauf pour la partie intégration au système
d’information. Pour ce qui concerne l’analyse des écarts dans la chaîne de valeur, on va comparer le
niveau de service rendu par les processus pour atteindre les objectifs stratégiques sans regarder, de
manière très détaillée, les indicateurs de qualité.
• Niveau 3 : Ce niveau ajoute toute la notion de gestion du cycle de vie de bout en bout des processus
ainsi que de la mise en place de tableaux de bord pour piloter la performance des processus.
• Niveau 4 : A ce niveau, aucun des processus de l’entreprise n’est formalisé. La démarche dans son
ensemble sera appliquée et le délai pour atteindre une gestion des processus sera plus long. Néanmoins il est
important de bien travailler sur des itérations de courtes durées pour apporter visibilité et accroître l’efficacité.
En fonction du niveau dans lequel on se trouve, la démarche pour atteindre une bonne conception
des processus sera plus ou moins longue et nécessitera d’utiliser une ou plusieurs méthodes pour
y parvenir. L’important est qu’une personne qui arrive au sein du projet, doit pouvoir comprendre
comment fonctionnent les processus et quels en sont les tenants et les aboutissants. D’où l’importance
du formalisme.
Exécution des processus
Une fois que les processus ont été conçus, documentés et simulés, on va les intégrer au système
d’information. Les outils de BPM permettent de passer de la phase de conception à la phase de réalisation
et d’exécution des processus en utilisant les mêmes ateliers logiciels.
L’implémentation des processus fait appel aux outils permettant de mettre en œuvre :
• L’automatisation des processus
• Les fonctions de Workflow
• L’intégration aux applications
• Les règles métiers
En fonction de la cible des processus (humain, intégration,...), l’un des 4 axes cités précédemment sera
plus ou moins important et fera basculer le choix vers un produit qui offrira la meilleure couverture
en termes de fonctionnalités.
Généralement à cette phase, le projet d’implémentation récupère les modèles des processus pour les
intégrer au sein de la solution en commençant par un niveau plus détaillé de découpage. L’implémentation
est alors faite avec l’interfaçage aux différents systèmes nécessaires au fonctionnement du processus.
Gestion & supervision
Une fois les processus testés, ils sont alors déployés dans un environnement d’exécution réel
(système de production) et doivent être gérés et supervisés.
La partie gestion englobe l’administration et la maintenance corrective des processus. Les processus
peuvent comporter des anomalies qui doivent être corrigées rapidement pour ne pas impacter l’activité
de l’entreprise. On parle de gestion du cycle de vie. Les outils de BPM doivent apporter les fonctions
nécessaires y compris la gestion de version des processus. Maintenant, on peut avoir les meilleurs
outils du monde, si la conception des processus a été mal faite, la correction et l’évolution de ceux-ci
pourraient être bien plus complexes que ce qui était prévu.
Pour la partie supervision, on distingue deux types de supervision que sont :

• La supervision du déroulement des processus,
• La supervision de la performance des processus.
La supervision du déroulement se décompose en 2 parties essentielles :

• La supervision technique : elle permet d’identifier la ou les causes techniques du dysfonctionnement
du processus. On peut avoir par exemple, un serveur qui est tombé en panne, des données qui ne sont
plus accessibles, une application qui pose des problèmes divers, un problème de réseau, etc. Cette
supervision s’adresse plus particulièrement aux exploitants de la solution et doit leur apporter tous
les éléments nécessaires leur permettant d’analyser la nature du problème et de réaliser les actions
correctives correspondantes. Dans le contexte de l’outil de BPM, un workflow peut être mis en place
pour permettre la journalisation des problèmes et événements.
• La supervision fonctionnelle : elle permet d’identifier les erreurs fonctionnelles survenues lors de
l’exécution des processus. Par expérience, on récupère des erreurs de toutes provenances et l’exercice
consiste en une séparation des erreurs fonctionnelles et des erreurs techniques et de ne montrer aux
superviseurs de processus que les erreurs qu’ils doivent gérer. En l’occurrence, les erreurs fonctionnelles.
Ce sont ces superviseurs qui relanceront les processus restés en erreur, voire d’interrompre un processus à
la demande d’un client. Par processus, on entend ici une instance d’un processus, des milliers d’instances

pouvant s’exécuter en parallèle. Pour finir, le superviseur aura besoin d’avoir des mécanismes qui vont
lui permettre de rechercher si une instance particulière est bien présente et si elle est en erreur que l’on
puisse en identifier la nature. On doit permettre de rechercher les erreurs en se basant sur des critères
comme le nom du client, l’heure de déclenchement, l’heure d’erreur, et bien d’autres encore.
F onc tionnelle
S upervis ion
T ec hnique
T ableaux de bord
Figure 26 : Les 3 axes de la supervision
La supervision de la performance est le second niveau. Ce niveau de supervision met en œuvre des
tableaux de bord. Les processus ont tous des indicateurs qui permettent de connaître leur niveau de
performance. Ces tableaux de bord montrent les indicateurs permettant à un responsable fonctionnel
ou métier de connaître tout problème de performance des processus dont il a la responsabilité, mais
également de visualiser l’efficacité des activités et tâches du processus. Ce niveau doit pouvoir aller
jusqu’à la supervision opérationnelle des processus, et des indicateurs clés associés.
Analyse et optimisation
Après un certain temps de fonctionnement des processus, les données collectées vont pouvoir servir à
analyser leur fonctionnement.
Que ce soit au niveau des indicateurs de performance, ou au niveau des données véhiculées, l’analyste
va pouvoir identifier les zones du processus qui sont peu ou pas performantes.
Toutes les données collectées sont également très importantes pour les indicateurs et leur suivi historique.
Prenons l’exemple d’une société qui a pour habitude d’avoir un carnet de commande journalier d’un
certain montant et à 11h00 du matin. Si un jour, ce n’était pas le cas, comment pourrions-nous, sans
données historiques, savoir que l’indicateur est dégradé par rapport au fonctionnement normal de
l’activité ? Nous allons voir que les indicateurs, pour être efficaces, doivent être basés sur des cas concrets
et faciliter la définition de limites inférieures et supérieures au-delà desquelles on considère que les
performances du processus ne sont pas atteintes.
L’analyse va se faire au niveau de la performance de chacune des activités du processus, mais également
en étudiant le délai de traitement de chacune de celles-ci, ainsi que du délai de traitement global du
processus.
Autre point, l’analyse peut identifier que les procédures d’escalade ne sont pas efficaces. Cela peut provenir
du processus, mais également des groupes d’utilisateurs vers lesquels les activités sont escaladées. C’est
également durant cette phase que l’on va revisiter les tâches répétitives pour identifier si elles peuvent
être mieux automatisées, voire dans certains cas, supprimées. L’analyse qui va s’en suivre va permettre
de vérifier si les améliorations envisagées peuvent être raisonnablement mises en place et passer par une
première validation en utilisant des fonctions de simulation. Idéalement et pour avoir un bon niveau
de qualité des simulations, on utilisera des données provenant du système de production.
Une fois l’analyse effectuée, on pourra dresser un plan d’investigation qui permettra de trouver les
causes, qu’elles soient conjoncturelles, humaines ou système. Un plan d’action est alors dressé pour
permettre l’amélioration du processus.
Des itérations successives
L’avantage du BPM est de permettre de travailler par itérations courtes et successives. La première
itération consistera en la mise en œuvre du processus tel que vu lors de sa conception initiale et les
itérations suivantes permettront de revoir les parties qui ne sont pas au niveau de fonctionnement ou
de performance attendu.
Un des points positifs est la possibilité, de par ces itérations courtes, d’afficher de la visibilité pour
démontrer que dès les premières itérations, on en tire déjà des bénéfices. On utilise ces premiers retours
comme vecteur de communication au sein de l’entreprise ou vis-à-vis de ses partenaires.
Les itérations courtes peuvent permettre également d’éviter d’avoir des processus trop complexes et peu
évolutifs. N’oubliez pas que même si les outils simplifient la mise en œuvre et permettent de découper
le processus en composants réutilisables, leur conception sera plus qu’importante car c’est sur la base
de celle-ci que sera réalisée leur implémentation.
Pour finir, si vous optez pour une méthodologie d’amélioration continue des processus, la modularité
des composants, la documentation de ceux-ci et la facilité de gérer leur cycle de vie ne pourra que
faciliter le travail.

3. Amélioration et qualité
des processus
Dans le contexte de la qualité, il est important de lier les processus aux besoins des clients. Par ce lien,
l’entreprise va pouvoir tirer parti de 4 bénéfices majeurs que sont :
• L’alignement entre le métier et le système d’information de l’entreprise : Ce critère se
retrouve en tête en termes des tendances du marché, des styles, des technologies émergeantes
mais à condition que le processus soit en adéquation avec les attentes des clients.
• La diminution des défauts : Plus on connaît les besoins des clients, plus les produits et
services proposés correspondent à leurs besoins et moins ils les rejetteront.
• La conception des processus s’en retrouve améliorée : Quand on connaît le résultat que doit
produire un processus, il sera alors plus facile de le concevoir. Le but n’est-il pas d’atteindre les
objectifs métiers fixés ?
• L’amélioration continue des processus : Accepter une amélioration continue de ses processus
permet de mieux garantir que les produits ou services seront conformes aux attentes des clients.
On va voir que parmi les éléments essentiels de la gestion des processus, il y a :
• Un niveau d’intelligence marché (adéquation aux besoins du marché),
• Une amélioration de l’atteinte des objectifs de la stratégie de l’entreprise,
• Des métriques permettant de piloter et mesurer efficacement les processus de l’entreprise.
Les nombreuses méthodologies de contrôle qualité ou d’amélioration de la qualité rendent le choix de

l’une d’entre elles plus difficile. Dans toute cette myriade de méthodes et démarches, lesquelles sont
les mieux adaptées au BPM ? Comment choisir ? Les éditeurs d’outils de BPM proposent également
des méthodologies, mais qu’en est-il ? Sont-elles fiables ? N’allons-nous pas nous enfermer dans une
méthode trop propriétaire si nous sélectionnons l’une d’entre elle ?
Aujourd’hui, pour un domaine comme le BPM nous pourrions nous appuyer sur des méthodologies
comme :
• TQM : Total Quality Management
• Six Sigma : Amélioration continue des processus
• HPT (Human Performance Technology)
• SCOR (Supply Chain Operations Reference) qui est plus un référentiel qu’une méthode
• CMMI (Capability Maturity Model Integrated)
• Lean
• Lean Six Sigma
• Etc.
Toutes ces méthodes traitent de l’amélioration de la qualité, de processus ou de la performance de

l’entreprise ou bien encore, proposent un référentiel de processus.
SCOR
Lean
Six Sigma
B u s ines s P ro c es s
Ma na gement
HPT TQM
CMMI
Figure 27 : Méthodes et BPM
Par contre, ces méthodes ou référentiels sont tous génériques même si certains sont sectorisés. Ils ne
peuvent pas être utilisés en l’état. Il est nécessaire de les adapter à son propre contexte. Une autre
alternative consisterait à prendre une démarche simple et d’y introduire des parties de ces méthodologies
permettant ainsi de garantir une bonne adéquation au besoin et surtout, une bonne adaptation à la
culture de l’entreprise.
Cette démarche, qui utilisera tout ou partie d’une méthode, adaptée d’une part à la discipline du Business
Process Management et d’autre part au contexte dans lequel le BPM va intervenir au sein de l’entreprise,
peut nécessiter du temps pour sa mise en œuvre surtout si aucun accompagnement n’est prévu pour
en assurer un démarrage efficace mais aussi un déroulement dans la sérénité.
Aujourd’hui, la démarche d’optimisation la plus largement utilisée mais aussi la plus adaptée à
l’optimisation de processus dans l’entreprise, est probablement la méthode Six Sigma. Cette méthode,
de plus en plus répandue, permet d’identifier pourquoi et comment on pourra améliorer le processus.
La méthode va également permettre d’identifier des indicateurs clés (KPI(*)) qui, tout au long du cycle
de vie des processus, vont permettre d’identifier les dysfonctionnements et leur causalité de manière
précise, et participer à une meilleure garantie de la qualité d’exécution.
Nous allons voir également, qu’il sera nécessaire d’avoir des sponsors et « responsables » de ces processus.
La mise en place d’un management par les processus implique de créer de nouvelles fonctions spécifiques
au sein de l’entreprise. Il existe déjà des exemples aujourd’hui où de telles fonctions ont été mises en
place et ce afin d’avoir un garant de la bonne mise en place et du bon pilotage des processus.
TQM : Total Quality Management

La méthode TQM, ou également Management par la Qualité Totale, a vu le jour dans les années 1950
avec une utilisation plus soutenue à partir des années 1980. Elle a amené un concept de management
par la qualité totale du produit ou service. Pour être en totale adéquation avec le besoin utilisateur, un
produit ou un service doit répondre à tous les besoins de tous les utilisateurs. On parle, d’ailleurs, de
notion de « zéro défaut ».
Cette méthode est tournée vers le travail en équipe. La démarche se concentre sur l’ensemble des
processus au sein de l’entreprise ou de l’organisation sans dominante autour des managers ou des
collaborateurs de l’entreprise.
Le TQM s’intéresse à 6 critères principaux de l’entreprise pour en qualifier son niveau de qualité :
• Le coût de ses produits/services
• La durée de vie de ses produits/services
(*) voir glossaire • La satisfaction de ses clients
page 192 • Ses parts de marché

• Sa productivité
• Ses résultats financiers
Introduite par le statisticien W. Edwards Deming, le management préconisé par cette méthode se base
sur les principes suivants :
• L’objectif est de se mettre en capacité d’améliorer, de manière continue, les produits et
services pour rester compétitif, être un acteur du marché et créer des emplois
• être en capacité de changer de philosophie et faire en sorte que le changement soit vécu
de manière favorable
• Ne pas effectuer d’inspection systématique de la qualité des produits et services
• Tout membre de l’entreprise doit participer à la mise en œuvre de la transformation
• Conduire le changement afin d’effacer les craintes naissantes
• Supprimer le management par les objectifs ou quotas
• Supprimer les barrières entre les services de l’entreprise. Le travail doit être un travail d’équipe
• Ne pas aller vers un mode d’achats au plus bas prix. Traiter la relation envers le partenaire comme
une relation unique et durable basée sur la confiance
• Mettre en situation
• Dynamiser les directions et créer la notion de leadership pour motiver le personnel
• L’encadrement responsable s’exerce sur la qualité et non sur les chiffres. Mettre en valeur la fierté
du savoir-faire.
Basé sur ces principes et dans cette quête de la qualité des processus, il est important que l’entreprise
puisse évaluer son niveau global de qualité, les attentes du marché, le coût que pourrait avoir une
mauvaise qualité sur les résultats de l’entreprise, et le niveau d’implication des collaborateurs permettant
d’atteindre une meilleure qualité.
On parle d’ailleurs de mise en place d’un PAQ(*). Ce plan doit définir les critères qualité ainsi que les
responsabilités des acteurs pour atteindre ces critères. Une feuille de route permettant de définir les
différents niveaux de qualité que l’entreprise va devoir atteindre est formalisée. Un plan d’action est
défini avec les acteurs responsables de ces actions pour assurer un bon suivi. Pour finir, des indicateurs
sont identifiés et suivis pour valider l’amélioration de la qualité globale.
Cette méthodologie se concentre sur l’amélioration continue de la façon de travailler et à tous les niveaux
de l’entreprise. De cette manière, on cherche à prévenir les défauts qui pourraient intervenir sur les
produits ou services. Dans la méthode TQM, on parle d’amélioration des résultats mais également des
méthodes de travail et de la capacité à produire de meilleure qualité. On part du principe que si des
acteurs font des erreurs c’est parce que des systèmes ou processus sont en cause.
Pour palier à cela, la méthode utilise trois mécanismes de prévention, que sont :
• L’anticipation des défauts,
• Si les défauts ne peuvent être évités, les détecter avant qu’ils n’aient eu le temps de passer toute
la chaîne de valeur,
• Là où les défauts interviennent systématiquement, stopper toutes les opérations en cours pour
régler les défauts et ne redémarrer qu’avec la certitude qu’ils sont définitivement fixés.
Pour mettre en place TQM, il est primordial que l’organisation de l’entreprise soit saine et qu’il y ait la
volonté de la financer.
Bien entendu et comme toute démarche qualité, la conduite du changement et la communication sont
importants. La mobilisation des énergies est nécessaire pour assurer le niveau de qualité requis et surtout
le niveau de satisfaction des clients.
Il n’y a pas qu’une théorie de mise en œuvre de TQM, mais c’est une discipline et une philosophie qui
s’efforce d’appliquer un processus d’amélioration continue de la qualité qui s’applique à l’entreprise et
à ses moyens de produire.
(*) voir glossaire

page 192
HPT : Human Performance Technology
HPT est une méthodologie qui a vu le jour dans les années 1990. Cette méthodologie utilise, comme
les autres, divers moyens pour atteindre un niveau de performance élevé dans la création de valeur.
Elle est tournée vers un apport de valeur au client. Le principe de la méthode consiste en une analyse
rigoureuse de la performance actuelle, de celle que l’on désire et une évaluation de l’écart entre les deux.
Cette méthode est focalisée sur les hommes et leur performance pour apporter cette valeur ajoutée.
Figure 28 : Human Performance Technology
Elle est axée sur l’identification et la suppression des freins à une meilleure performance individuelle,
et organisationnelle pour délivrer une solution de qualité.
Elle considère que la performance est évaluée de manière identique à la performance d’un système, et
de sa manière d’être l’amélioré.
Elle se base sur 10 principes majeurs que sont :

• Se concentrer sur les résultats : Pour évaluer les résultats, on se focalise sur ce qui sera perceptible
par le client, les indicateurs associés et la manière de collecter les informations, qui permettront de
calculer ces indicateurs.
• Avoir une vue système : du processus, consiste en l’identification des composants et leurs interactions
comme un système même ci ces composants sont du type humain, marché, système d’information, etc.
Cette vue permettra d’utiliser une démarche systémique pour l’amélioration des performances. On prend
en compte les entrées du processus mais également des facteurs comme les pressions (acteurs clés, les
managers, les conformités diverses, etc.), les attentes, les contraintes et les conséquences associées.
• Ajouter de la valeur : La méthode indique que la solution doit apporter de la valeur ajoutée au
client. Pour cela elle n’hésite pas à impliquer le client pour mesurer sa satisfaction, et valider l’apport
de valeur réalisé.
• établir des relations de partenariat : Pour les établir, il est impératif d’avoir une approche collaborative.
Ces relations sont vitales à la méthodologie. Les partenaires sont identifiés en fonction de leur apport
dans le contexte d’application. Ils doivent tous savoir quel rôle ils vont jouer. Par ailleurs, le partenariat
s’effectue également avec l’informatique qui doit comprendre pourquoi les processus doivent être
exécutés ainsi ou être améliorés.
• Avoir une approche systématique
~ lors de l’évaluation des besoins : Ce principe est complexe car il demande d’analyser
fonctionnellement un grand nombre de domaines différents : analyse des tâches, processus, environnement
de travail, utilisateur et audience, modes de communication, marché et données du système.
~ dans l’analyse du travail réalisé pour identifier les causes ou les facteurs qui limitent la
performance : Dans ce cas, on doit analyser les causes systématiques de non atteinte de la performance.
Pourquoi ces écarts existent-ils ? On trouvera probablement des causes comme par exemple le manque
de personnel.
~ dans la conception et la spécification des besoins de la solution : La spécification des
besoins doit décrire la solution choisie, le niveau de performance souhaité, les modifications apportées

et l’accompagnement dans la conduite du changement qui sera nécessaire. La méthode de déploiement
de la solution en découlera alors naturellement. Pareillement, la méthode qui permettra une amélioration
continue devra être spécifiée pour le futur.
~ dans le développement de tout ou partie de la solution : Basée sur les spécifications des
besoins, (la ou) les solutions sont implémentées. Les composants de la solution sont mis en œuvre
par des équipes ou des personnes. Le résultat de ces travaux sera, dans notre cas, des processus et
une solution de BPM paramétrée selon les besoins. Ne pas oublier d’impliquer des experts pour éviter
certains écueils qui peuvent avoir un coût financier et un impact sur les délais de mise à disposition de
la solution. Tous les éléments physiques nécessaires sont spécifiés de manière détaillée.
~ lors du déploiement de la solution : La solution doit pouvoir être déployée simplement
et le déploiement doit être industrialisé. Ceci est encore plus vrai avec des processus. Le premier
déploiement concerne celui de la plate-forme de gestion des processus et d’un ou plusieurs premiers
processus. On parle de processus pilotes. Lors de déploiements ultérieurs de processus, la procédure
doit être systématiquement identique à quelques exceptions près. Tous les outils de déploiement seront
décrits à ce moment.
~ lors de l’évaluation du processus et de ses résultats : L’approche permettant d’évaluer les
processus et leur performance consiste en l’accès aux données des processus et en particulier des indicateurs
permettant de les évaluer. Ces indicateurs sont soigneusement choisis. Dans le cas d’une solution de
BPM, on va afficher tous les indicateurs au sein de tableaux de bord. Ces tableaux de bord affichent la
performance des activités unitaires des processus mais également des processus bout en bout.
Pour finir, HPT insiste sur des pratiques éthiques et fait appel à des ressources expérimentées. Ces
ressources s’engagent à respecter les 6 principes de base de HPT que sont :
• Ajouter de la valeur,
• Utiliser des pratiques qui sont validées,
• Travailler en mode pleinement collaboratif,
• Avoir une approche d’amélioration continue,
• être intègre vis-à-vis de toutes les parties impliquées,
• Maintenir le niveau de confidentialité nécessaire vis-à-vis du projet.
Aujourd’hui la méthode HPT est encore peu utilisée mais est en plein développement.
SCOR: Supply Chain Operations Reference model

SCOR (Supply Chain Operations Reference model) est, comme son nom l’indique, un modèle de
référence créé par un organisme spécialisé du nom SCC (Supply Chain Council) et concerne la gestion
de la chaîne logistique.
En fait, le modèle SCOR décrit des processus du domaine de la Supply Chain et met à disposition :
• Des descriptifs standardisés de processus métiers
• Un framework de relations entre les processus standardisés
• Des métriques prédéfinies permettant de mesurer la performance des processus
• Des concepts de management provenant de « bonnes pratiques » et permettant d’obtenir une
meilleure performance des processus
• Un alignement entre les caractéristiques et les fonctionnalités des processus
Le modèle SCOR repose sur 5 familles de processus « cœur de métier » que sont :
• Plan (planification) : Planification et gestion de la Demand/Supply
• Source (approvisionnement) : Gestion des fournisseurs permettant de choisir le bon
fournisseur du produit, gérer sa performance, gérer les inventaires, gérer l’arrivage des produits,
gérer les procédures d’import/export, …
• Make (fabrication) : Gérer les activités de production des produits, de tests, de packaging.
Gérer tout le réseau de production. Suivre la conformité à des régulations, etc.
• Deliver (livraison) : Gérer les commandes des clients y compris les expéditions. Facturer
les clients. Installer les produits, les inventorier, …
• Return (les retours) : Gérer le retour des produits suite à des défauts, pour maintenance, etc.
Gérer les expéditions et les modes de transports/enlèvements …
Les processus sont décrits à un niveau macroscopique.
De plus le modèle SCOR décrit les processus selon 4 niveaux :
• La famille de processus : plan, source, make, deliver et return
• Les catégories de processus qui donnent les processus pour chacun des types
F a mille de proc es s us
C a t é gories de proc es s us
É l é ments des proc es s us
D é c ompos ition des é l é ments
Figure 29 : Décomposition des processus SCOR
• Les éléments pour chacun des processus comme leurs définitions, les entrées/sorties,
les métriques permettant d’en mesurer la performance, …
• La décomposition des éléments permettant l’implémentation des processus au sein de
l’organisation et des systèmes. C’est à ce niveau que les activités voire les tâches sont décrites.
L’objectif de ce référentiel est d’implémenter les processus de la chaîne logistique en utilisant des
processus normalisés et référencés. On doit adresser 4 axes principaux lors de l’implémentation ou de
l’optimisation des processus au sein de l’organisation que sont :
• L’axe stratégique : Consiste en une analyse concurrentielle permettant d’identifier
le positionnement nécessaire sur le marché,
• L’axe opérationnel : Analyse des flux opérationnels pour vérifier leur répartition entre
les différents acteurs,
• L’axe « vision systémique » : Description des processus dans leur ensemble, et analyse
permettant d’identifier les points de dysfonctionnements. La cible est alors décrite, et les écarts
identifiés, pour formaliser les étapes permettant d’atteindre la cible.
• L’axe « implémentation » : Cette partie consiste en la mise en œuvre des processus par le
déploiement de l’organisation, des procédures et du système qui composent la solution globale.
Le référentiel comprend également des bonnes pratiques en termes de conception et met à disposition
des cas concrets où le référentiel a été implémenté.
LEAN Manufacturing
La méthode Lean Manufacturing, originaire du Japon et principalement axée sur l’industrie manufacturière,
est basée sur le principe qu’une entreprise est agile si elle est en capacité constante de modifier ses
processus, et si ceux-ci sont performants; le tout dans des délais très courts. On dit que les processus
doivent être « Lean » (maigre), c’est-à-dire que l’on ôte des processus toutes les opérations inutiles.
Les 5 principes de la pensée « Lean » sont les suivants :

• Spécifier ce qui apporte ou créé de la valeur pour le client
• Identifier le flux de valeur
• Favoriser l’écoulement du flux
• Tendre les flux (stocks par exemple)
• Viser la qualité totale

Par rapport à ces principes, « Lean » se focalise sur les processus et part du principe que :
• La vitesse d’exécution de tous les processus indique le niveau de qualité global
• Les processus lents sont des processus coûteux
• La métrique principale de Lean est l’efficience du cycle de vie d’une instance d’un processus
• 95 % des délais des processus concerne des temps d’attente
Lean permet une amélioration continue par éliminations, principalement, des gaspillages (le « muda »
en japonais).
Il existe 7 catégories de gaspillages selon Lean :

• Les temps d’attentes
• Les productions excessives d’où résulte un excès de stocks disponibles
• Les manutentions inutiles
• Les transports inutiles
• Les tâches inutiles
• Les productions
• Les mouvements inutiles
• Les produits défectueux
• L’inexactitude de l’inventaire des pièces, permettant la fabrication du produit final
Le pilotage de la performance est basé sur le suivi d’indicateurs qui permettent à une personne d’identifier
les dysfonctionnements. Ils doivent être en cohérence avec les principes suivants :
• Les indicateurs sont simples à construire et à mettre à jour,
• Les indicateurs simples n’indiquent pas la source du problème, mais cela fait partie du principe.
Ils permettent d’alerter sur le fait que des dysfonctionnements ont eu lieu.
• Ils sont limités en nombre (entre 3 et 6). S’ils sont trop nombreux, alors ils ne seront pas utilisés
• On doit pouvoir effectuer un zoom sur les indicateurs, c’est-à-dire, d’accéder à toutes les données
permettant de les calculer en facilitant la mise en valeur du dysfonctionnement. Ces données
devront également être collectées pour permettre l’analyse approfondie de la source du problème.
Figure 30 : Les 4 axes de la pensée « Lean »
Pour effectuer une analyse selon « la pensée Lean » on doit adresser les 4 axes suivants :
• Le Management : Le management aidé des collaborateurs doit trouver les causes des problèmes
et les éliminer. Le travail d’équipe pousse les collaborateurs à trouver des solutions pour palier
à ces problèmes (c’est la méthode de Kaizen). Le management doit rester opérationnel pour être
en capacité de réagir immédiatement aux situations de crise. Les décisions pour remédier aux
problèmes sont décidées par consensus.
• La Production : La production doit produire ce qui est nécessaire pour répondre à la demande
du marché. Les tâches de production sont standardisées, facilitant ainsi l’amélioration continue
des processus de fabrication et la suppression des tâches inutiles. La relation entre l’entreprise et
ses fournisseurs se fait sur un mode partenarial, avec incitation à utiliser des méthodes
permettant la mesure de la qualité.
• La Valeur : La valeur est définie d’un point de vue client pour permettre un écoulement des
stocks en continu.
• La Stratégie : La stratégie est établie à long terme et l’objectif à atteindre est partagé. Pour
atteindre cet objectif, l’entreprise se place en mode d’amélioration continue de ses processus.
L’expérience a démontré dans certaines entreprises japonaises par exemple, que les collaborateurs sont
incités à trouver des solutions aux problèmes, à les formaliser et si la solution envisagée est sélectionnée
pour résoudre le dysfonctionnement, le collaborateur est alors récompensé sous forme d’une prime
supplémentaire. Pour l’avoir vu s’appliquer dans le secteur de l’électronique grand public, je peux vous
assurer de l’efficacité du dispositif.
On voit désormais des méthodes dérivées arriver sur le marché comme :

• Lean Office : amélioration des services administratifs
• Lean Development : amélioration du développement de produits
• Lean Six Sigma : méthode qui allie Six Sigma à Lean pour l’amélioration continue des processus
et dans la durée (apport de ce dernier par Lean)
• …
Lean apporte également un certain nombre d’outils à la démarche comme :

• Le « Value Stream Mapping » : Il consiste en une cartographie descriptive des flux au niveau du
processus étudié. Pour décrire le processus, ont doit identifier les tâches, la nature et la quantité des
informations qui sont échangées, les temps d’attentes, les cycles, les taux de qualité et de non qualité, les
ressources humaines affectées, la productivité,… Une fois les informations collectées, une cartographie
doit représenter le processus actuel et sa cible. Ensuite, on doit dresser le plan d’actions permettant
d’atteindre la cible. Ce travail de cartographie doit être le plus exhaustif possible.
• Le « HEIJUNKA » : Le principe du Heijunka est le lissage pour permettre une meilleure maîtrise
de la charge de travail et éviter toutes variations importantes.
• Les « 5S » : Les 5S font référence aux mots japonais d’origine : Seiri - Ranger, Seiton – Arranger,
Ordonner, Seiso - Nettoyer, Seiketsu - Propreté, Shitsuke – Eduquer). La méthode des 5S permet
de supprimer l’inutile (les gaspillages), de situer (entendre par là où se trouvent les objets utiles à
l’accomplissement des tâches du processus), de nettoyer (nettoyer régulièrement et durablement),
standardiser les nouvelles règles établies, suivre et faire évoluer par la mise en place d’indicateurs de
suivi ainsi que des rappels réguliers des règles mises en place.
• La démarche « TPM » (Total Productive Maintenance) : L’objectif de cette démarche est
d’améliorer le rendement des machines par un maintien en condition opérationnelle des machines et
par leur potentielle amélioration.
• Le SMED (Single Minute Exchange of Die) : Principe permettant d’arriver à un changement
d’outil en moins de 10 minutes. Ceci doit permettre à un fabricant de gérer les changements de série
dans un délai n’excédant pas ces 10 minutes.
• Et d’autres outils encore : Internet regorge d’outils Lean accessibles.

Lean est, à la base, pensé pour la manufacture et donc plus souvent utilisé dans l’industrie. L’un des
avantages de la méthode Lean est de se concentrer sur les délais pour les réduire au maximum. Nous
allons voir qu’aujourd’hui, on parle de plus en plus souvent de la méthodologie Lean Six Sigma.
Lean apporte également une approche basée sur les bonnes pratiques et sur de la capitalisation. De par
ces bonnes pratiques on estime la durée d’un projet Lean pouvant aller de 1 semaine à 3 mois.
CMM : Capability Maturity Model

Le Capability Maturity Model (CMM) a vu le jour en 1991. Créé par le Software Engineering Institute
(SEI), il avait pour objectif principal, d’apporter un modèle de référence de bonnes pratiques dans le
domaine du génie logiciel.
CMM doit aider à garantir que les logiciels produits seront d’un bon niveau de maturité (et donc de
stabilité) et qu’ils répondent aux critères identifiés lors des expressions de besoins des utilisateurs ou
des clients.

Les processus de génie logiciel comportent des activités, méthodes et pratiques que les ingénieurs
utilisent pour développer et maintenir les logiciels et les livrables associés (plan projet, spécifications,
développements, tests, …). Plus les processus d’une entreprise pour délivrer un logiciel sont matures,
plus le logiciel aura de la capacité, de la performance et donc de la stabilité.
Mais les besoins ne s’arrêtent pas au développement de logiciel. En 2001, le SEI propose une nouvelle
version de son modèle nommé Capability Maturity Model Integration (CMMI) qui englobe les bonnes
pratiques de différents modèles comme :
• SW-CMM (Software CMM)
• SE-CMM (System Engineering CMM)
• IPD-CMM (Integrated Product Development)
• SS-CMM (Supplier Sourcing)
• SA-CMM (Software Acquisition)
Le CMMI définit des bonnes pratiques qui décrivent des macros processus et qui dépendent d’un niveau
de maturité bien défini. La maturité des processus est alors définie comme suit :
Am élioration c ontinue Performance

des proc es s us
Niveau 5
O ptimis é
Mes ure et
pr évis ion
Niveau 4
Ma îtris é
S tandardis ation des

proc es s us Niveau 3
Défini
Risques
Niveau 2
P roc es s us s truc tur é R eproduc tible
et dis c iplin é
Niveau 1
Initial
Figure 31 : Niveaux de maturité CMMI
• Niveau 1 - Initial : Le processus de développement n’est pas défini. L’entreprise peut ne pas
être capable de proposer un environnement de développement et de maintenance stable. Bien souvent
les entreprises à ce niveau ont de grandes difficultés à tenir les engagements. Cela ne veut pas dire que
les logiciels ne fonctionnent pas. Souvent le processus est maîtrisé par seulement quelques personnes
clés. Sans formalisme correctement défini, le savoir-faire n’est pas partagé.
• Niveau 2 - Reproductible : Le processus de développement est défini. L’entreprise est capable
de reproduire des projets identiques basés sur des expériences similaires. Le processus est documenté,
maintenu, amélioré et mesuré. Des outils de pilotage sont utilisés et les problèmes sont escaladés et
traités au fur et à mesure de leurs arrivées. La planification et le suivi sont standardisés. Le projet est
maîtrisé. Toutes les règles sont connues et appliquées à la lettre.
• Niveau 3 - Défini : Les processus de génie logiciel et de gestion de projet sont définis,
documentés et suivis. Un groupe de travail est créé et les activités sont réparties sur différents acteurs.
Ces acteurs sont formés pour garantir qu’ils seront en capacité d’assumer leur rôle au sein de ce groupe.
Les bonnes pratiques sont utilisées.
• Niveau 4 - Maîtrisé : Des objectifs quantitatifs sont définis aussi bien au niveau des
produits que des processus. La productivité et la qualité sont mesurées tout au long des processus.
Une base de données contient l’historique de la performance des processus et en autorise leur analyse
d’efficacité. La qualité des processus est atteinte par la minimisation des variations des indicateurs pilotés.
Cela permet également de prédire le niveau de qualité, ces indicateurs devant rester dans des limites
inférieures et supérieures définies comme acceptables. La mesure du processus permettra également une
meilleure identification de la cause en cas de son dysfonctionnement. Nous verrons dans le pilotage de
la performance des processus que la possibilité de prédire peut éviter un scénario catastrophe.
• Niveau 5 - Optimisé : Ce niveau indique que les processus sont maîtrisés mais également
en amélioration continue. On est alors en capacité d’identifier les forces et faiblesses d’un processus
et de les corriger dans des délais très courts. Les données collectées sont utilisées pour permettre des
calculs d’impacts en particulier dans le cas de l’utilisation de nouvelles technologies. Pareillement, toutes
les causes de gaspillages sont identifiées et adressées pour être soit améliorées soit supprimées. On peut
également améliorer les processus par l’apport de nouvelles méthodes. L’optimisation des processus
fait alors partie des activités récurrentes de l’organisation.
Le niveau de maturité donne le niveau de capacité des processus. Ces niveaux contiennent des
domaines clés qui doivent permettre d’atteindre les objectifs visés. Ces domaines clés sont organisés en
caractéristiques communes qui permettent d’implémenter les processus. Ces caractéristiques communes
font appel à des pratiques qui décrivent des activités ou l’utilisation d’outils.
Chaque niveau fait appel à des pratiques ou domaines spécifiques dans le domaine du génie logiciel.
Au niveau 2, on adresse :
• la gestion de la configuration,
• le plan d’assurance qualité,
• la gestion des sous-traitants,
• le suivi et le management du projet,
• la planification du projet,
• la gestion des exigences.
Au niveau 3, on adresse :
• les pratiques du niveau 2,
• les processus organisationnels (y compris les rôles et responsabilités) pour permettre des
améliorations futures,
• la formation pour maintenir un bon niveau des compétences,
• la description du processus de création d’un logiciel,
• la coordination entre groupes,
• les revues faites par les pairs.
Au niveau 4, on adresse
• la gestion de la qualité logicielle,
• la gestion quantitative des processus (indicateurs).
Au niveau 5, on adresse
• la prévention des défauts,
• la gestion des évolutions,
• l’amélioration continue des processus.
On comprend alors aisément que plus le niveau de maturité sera élevé plus les risques identifiés seront
faibles et plus la performance des processus et des produits ou services en sortie sera élevée.
La mise en place de CMMI a un coût non négligeable mais la conformité à un certain niveau apporte
un gage de qualité. Il est déconseillé de vouloir se conformer à un niveau sans avoir passé le niveau
précédent.
La maturité peut être auto évaluée, ce qui n’est pas forcément le cas de toutes les méthodes. Néanmoins,
il est nécessaire de prévoir un accompagnement pour se conformer à un des niveaux de CMM. Pour
chacun des niveaux, des disciplines et objectifs sont formalisés par CMMI. Certains d’entre eux sont
optionnels et d’autres obligatoires.
Les principes restent les mêmes et CMM évolue pour s’adapter à d’autres disciplines que l’ingénierie
logicielle. Le niveau de maturité des processus dans le cadre du BPM est d’ailleurs calqué sur CMM.
Six Sigma
Six Sigma est une méthodologie ayant pour objectif principal l’amélioration continue des processus.
Elle a été créée par Motorola puis rendue plus populaire par General Electric au début des années 80.
Un exemple des années 70 : une entreprise japonaise rachète une usine de téléviseurs de Motorola et
applique des changements au niveau du fonctionnement interne. Conséquence : diminution de plus de
20 fois du nombre de défauts sur ces mêmes téléviseurs. La satisfaction des clients a été fortement perçue
et les ventes ont été augmentées. La méthodologie Six Sigma a été mise en œuvre dans cet exemple.

Cette méthodologie est utilisée pour adresser deux objectifs principaux :
• Gérer les processus
• Maximiser l’efficience de l’entreprise par l’amélioration continue de ses processus
L’une des particularités de Six Sigma est de faire en sorte que les processus aient peu de variations ce
qui a pour conséquence d’améliorer leur performance. Le but sera d’identifier les causes de variations
de ces processus. Plus les variations seront faibles, plus la performance du processus sera bonne.
Var
ia
Variations
tion
s
ance
rform
PePerformance
Figure 32 : Variations et performance
L’entreprise orientée « client », va alors vouloir augmenter sa connaissance des besoins clients de manière
à ne se concentrer que sur les parties de processus qui permettent d’améliorer la qualité en adéquation
avec ce que les clients attendent.
Les principaux avantages de Six Sigma en tant qu’outil pour la gestion des processus sont :
• Réduire les coûts (et surtout éviter certains gaspillages)
• Améliorer la qualité des produits, services et processus
• Augmenter la profitabilité
• Procurer à l’entreprise des avantages compétitifs
Six Sigma, à la différence de programmes qualité plus classiques, apporte une démarche qui maximise
la valeur des parties prenantes de l’entreprise au sein des processus. Si un produit ou processus a un
niveau de consistance Six Sigma, alors son taux de défauts est de 3,4 sur un million d’occurrences. On
parlera d’ailleurs, d’instances de processus.
A la base, le sigma est un terme statistique qui mesure de combien le processus varie de la perfection (ou
combien de fois au maximum un processus peut être défaillant). Il est basé sur un nombre de défauts
par million d’unités. Si nous prenons l’exemple des morts par accident de la route, cela reviendrait
à dire que pour un pays comme la France et pour être au niveau Six Sigma, le nombre de morts ne
doit pas dépasser 222. Plus improbable encore, cela reviendrait à dire qu’un golfeur ne raterait le trou
qu’une seule fois tous les 163 ans !
La définition d’un processus par Six Sigma
De manière générale un processus est composé de 3 éléments que sont :

• Les entrées,
• La fonction,
• La sortie (le résultat)
Fonction Sortie
Entrée(s)
Figure 33 : Vision Six Sigma d’un processus
Dans le cas de la méthodologie 6 Sigma, les entrées peuvent être de deux types :
• Les entrées contrôlées : On se trouve en capacité de traiter l’entrée d’une certaine manière.
Exemple : remplir le réservoir de son véhicule.
• Les entrées incontrôlées : On ne se trouve pas en capacité de traiter. C’est un impondérable.
Exemple : une route fermée.
Dans le cas des fonctions, on distingue en 2 types :

• La fonction principale : elle créé le produit ou service. C’est cette fonction qui permet la
création de la valeur. Comme exemples de processus, on peut citer la vente, le service client,
l’ingénierie, le marketing, etc.
• La fonction de support : Cette fonction sert de support à une fonction principale. Elle est une
fonction dite d’« enabler » (ou de facilitatrice). Cette fonction apporte les ressources ou entrées
nécessaires à l’exécution de la fonction principale. Comme exemples, on peut citer les achats,
la comptabilité, le senior management, etc.
Pour ce qui concerne la « sortie » (ou output), Six Sigma en définit de deux types :
• Les KPOV: Key Process Output Variables. Ce sont les caractéristiques des sorties des processus
(outputs) qui sont importantes pour le client. Il est absolument nécessaire de comprendre ce que
le client attend de l’entreprise et en particulier des produits ou services.
• Les CTQ : Critical To Quality. Ce sont les besoins oraux des clients. Ils doivent avoir des limites
hautes et basses en relation avec la qualité du produit ou service.
Six Sigma permet d’identifier les éléments d’un processus qui nécessite des améliorations pour produire le
produit ou service désiré. Bien identifier les éléments d’un processus permet de décomposer le processus
d’une manière logique. C’est le point de départ pour améliorer un processus.
Maintenant, la mise en œuvre nécessite une organisation en adéquation avec la méthode.
Les rôles nécessaires à Six Sigma
Lors de la mise en place de la méthodologie Six Sigma, On doit mettre en place une organisation
permettant de garantir la bonne application de ses principes et méthodes. En premier, on identifie les
rôles qui permettront de mettre en place une organisation efficace dans le cadre du projet. L’objectif
étant de bâtir une stratégie métier basée sur l’amélioration continue des processus.
Pour cela, les profils définis au sein de l’organisation vont se concentrer sur les parties métiers qui
adressent directement les besoins des clients et qui produisent du ROI. Le succès dépendra de l’efficacité
de l’organisation d’une part et d’autre part de la pertinence des profils au regard des rôles nécessaires
et composant cette organisation.
L’organisation Six Sigma définit 5 rôles :

• L’exécutif : Il est un supporter visible de la méthodologie et surtout des projets. Il doit, en outre,
motiver et faire adhérer les acteurs autour d’une vision commune. Pour avoir une vision des avancées,
il va utiliser des indicateurs dits de « haut niveau » (ou encore appelés indicateurs macros).
• Le Champion : Il a pour principale mission de communiquer et mettre en place la vision commune.
C’est lui qui doit identifier et prioriser les projets candidats. Il doit également supprimer tous les freins
au succès des projets.
• Le Master Black Belt : C’est lui qui apporte l’expertise aux projets Six Sigma : outils statistiques,
conduite du changement, résolution des conflits. Il apporte également la stratégie de conception des

processus métiers. Pour finir, il dispense les formations Six Sigma et coache les « Black Belt » et les
« Green Belt ».
• Le Black Belt : Il doit s’assurer de la bonne utilisation de la méthodologie et de l’utilisation des
outils associés. C’est lui qui a la responsabilité de développer les plans projets et de calculer les gains
potentiels que vont engendrer ces projets.
• Le Green Belt : Il doit piloter les projets Six Sigma. Il dialogue constamment avec les Black Belt,
connait la démarche Six Sigma et sait utiliser les différents outils de la méthodologie. Il exécute les
activités au sein du projet.
Exécutif
Champion
Master Black Belt Master Black Belt
Black Belt Black Belt Black Belt
Green Belt Green Belt Green Belt Green Belt
Figure 34 : Organisation d’un projet Six Sigma
Il n’y a pas de notion d’évolution d’un rôle vers un autre. On peut très bien devenir un Master Black
Belt sans passer par une certification Black Belt.
Les types de processus
Les processus « cœur de métier » délivrent de la valeur au client sous forme d’un produit, d’un service,
d’un support ou d’information. Bien souvent les types de processus ne sont pas correctement identifiés
et les gains ne sont pas au rendez-vous.
Management de
Marketing & vente
l ’entreprise
Administration Conception des

et finance produits & services
Services généraux Production
Achats Support
Processus Processus
« Support » « coeur de métier»
Figure 35 : Processus «Cœur de métier « et «support»
Il est important de distinguer les processus « cœur de métier » des processus de « support ». Pour
permettre de les identifier correctement, la méthode indique qu’il faut des réponses positives aux
3 questions suivantes :
1. Le processus est-il transverse à de multiples départements/services ?
2. Le processus génère t-il du revenu ?
3. Le processus est-il orienté client ? Apporte t-il de la Valeur Ajoutée au client ?
lie nt
o nc
cti
sfa
ati fits
S Satisfaction Client roProfits
P
Figure 36 : Lien satisfaction client et profits
Par expérience, on sait que les entreprises ont des processus différents. Ils sont dépendants de la
culture et du secteur d’activité, mais en général, toute entreprise a entre 1 et 3 processus dits « Cœur
de métier ».
Plus la satisfaction client sera bonne plus les profits seront potentiellement meilleurs. Pour garantir une
meilleure satisfaction des clients, il est nécessaire que l’on soit à même de collecter correctement les
retours de ses clients. C’est ce que l’on appelle le VOC(*) dans le jargon Six Sigma.
Collecter le VOC peut être fait de plusieurs manières :

• Des interviews conduites auprès d’un échantillon de clients. Ces interviews peuvent être en face
à face, par téléphone, par visioconférence
• Des enquêtes réalisées pour confirmer une théorie
• Des groupes de travail créés pour collecter une vision commune de plusieurs clients sur un
même produit
• Par de l’observation de l’utilisation des produits ou services.
Un exemple de VOC serait : votre café est très mauvais. Suite à une enquête réalisée auprès d’un
échantillon de clients, on identifie que le café est très mauvais de 8h00 à 10h00 du matin et parce que
dans cette tranche horaire le café est servi presque froid.
Par ailleurs, ce qui est important dans la méthode, c’est le fait de pouvoir mesurer la qualité des pro-
cessus et donc d’identifier les indicateurs clés de performance. Ces indicateurs doivent être de « haut
niveau ». Il est inutile d’aller trop dans le détail. Le détail ne sera nécessaire que pour identifier la
cause réelle du dysfonctionnement du processus. D’expérience, trop d’indicateurs trop détaillés ne
sont jamais utilisés.
La démarche DMAIC
Pour atteindre cet objectif, la démarche utilisée par Six Sigma se repose sur les 5 phases que sont : D,
M, A, I et C (Define, Measure, Analyze, Improve et Control). La démarche se doit d’être itérative pour
garantir une amélioration continue des processus métiers. Chacune des étapes du DMAIC impose des
activités et livrables associés permettant d’améliorer continuellement les processus métiers.
Autres it érations
Define Meas ure Analys e Improve C ontrol
Autres it érations
Figure 37 : La démarche Six Sigma DMAIC
(*) voir glossaire

page 192

• Define : Définir la zone qui pose problème et formaliser les objectifs
• Measure : Mesurer la performance du ou des produits (ou processus)
• Analyze : Analyser les problèmes pour en déterminer leur causalité
• Improve : Améliorer les résultats en re-concevant les processus et en réduisant les variations
• Control : Contrôler le processus pour valider le fait que les améliorations sont permanentes
Le délai d’un projet Six Sigma de bout en bout va de 2 mois à 6 mois.
Un bref descriptif de ces différentes phases est effectué dans les sections suivantes. L’objectif de la mise
en place de la démarche est bien entendu d’améliorer le niveau de sigma et donc de qualité.
Mais à quoi correspond le niveau de sigma ? Le tableau ci-dessous donne un aperçu des niveaux de
sigma (ou de défauts par unité).
Niveau de Sigma Défauts par million d’unité Coût sur les ventes
1 690 000
Non applicable : Entreprise non compétitive
2 308 537
3 66 807 25 à 40 %
4 6 210 15 à 25%
5 233 5 à 15%
6 3,40 <1%
Figure 38 : Les niveaux de sigma
Le niveau 6 (Six Sigma) ne permet que 3,4 défauts (ou dérivations) par million d’unités.
On peut corréler le niveau de sigma à des coûts sur les ventes de l’entreprise. Par exemple, une entreprise
qui se trouve au niveau de Sigma 1 ou 2 est une entreprise qui n’est absolument pas compétitive alors
que la majorité des entreprises sont au niveau 4 de Sigma. Les pistes d’améliorations sont donc multiples
et significatives.
Un dernier point important, est que pour permettre une réactivité voire une prédictibilité des potentiels
dysfonctionnements, l’entreprise doit tendre vers une entreprise « temps réel » et donc avoir le système
informatique en adéquation pour permettre un pilotage temps réel ou quasi temps réel.
C’est pourquoi la méthodologie « Six Sigma » se prête plutôt bien à une démarche de BPM car elle amène
des principes, des étapes, des livrables qui, s’ils sont bien suivis, permettront d’améliorer la qualité des
processus, objectif principal de Six Sigma.
Le tableau ci-après présente les principaux livrables de la démarche Six Sigma pour chacune des
phases.
P h a s e S ix S ig m a P rin c ipa u x L iv ra bles

_ La Charte projet
D efin e _ L'expression des besoins
_ Le Macro processus
_ Le plan de collecte des données
M ea s u re
_ Le niveau de Sigm a actuel
_ Analyse des données
A n a ly s e _ Analyse du processus
_ Analyse de la cause principale
_ Descriptif de la solution
Impro v e
_ Im plém entation de la solution
_ Définir la solution technique perm ettant de contrôler
C o n tro l
_ Décrire le plan com plet de m ise en œuvre à la cible
Figure 39 : Principaux livrables de Six Sigma
Nous allons regarder un peu plus dans le détail les différentes phases de Six Sigma et les livrables
associés.
Phase « Define »
Cette phase permet de définir les objectifs et périmètre du projet. Les objectifs doivent être basés sur
ceux du métier, sur les besoins des clients, ainsi que sur la connaissance des processus qui doivent être
améliorés et dans l’unique but d’atteindre le niveau de Sigma désiré.
Cette phase a pour principal objectif de cadrer le projet avec l’élaboration d’une vision commune et
partagée à l’ensemble de l’équipe et de ses sponsors. Les objectifs ainsi que le niveau de performance à
atteindre (sur les points de vues efficacité et financier en particulier) doivent être compris de tous.
Dans le cadre de la définition des objectifs du projet (résultats attendus à la cible), chacun d’entre eux
doit être conforme aux critères SMART :
• Spécifique : Ils doivent être clairs, simples, spécifiques et les actions à entreprendre
correctement définies
• Mesurable : Il est important de permettre de mesurer l’atteinte des objectifs par la mise en place
de jalons et indicateur correctement identifiés. Il est souvent trop facile d’atermoyer.
• Atteignable : Ils ne doivent pas être trop ambitieux. Il faut permettre leur atteinte. Trop souvent
les objectifs ne sont pas réalistes et sont donc des sources d’échecs car non atteints.
Bien entendu, les objectifs doivent rester ambitieux pour garder la notion d’effort.
• Réaliste : Ils doivent être réalistes.
• Temporel : Ils doivent permettre de définir des jalons, même si ceux-ci sont intermédiaires.
On comprend que la clarté de ces objectifs est vitale au bon démarrage de la méthodologie Six Sigma et
leur partage avec l’ensemble des acteurs est important. Les experts de la conduite du changement pourront
être des aides précieuses pour passer les messages nécessaires et aider à la mise en application.
La phase « Define » donne lieu à un certain nombre de livrables.
La « charte projet » doit comprendre :

• Le Business case : identification des raisons principales du lancement de ce projet avec
éléments financiers et identification des points d’apports de valeur. Inutile de trop en faire,
il est important de synthétiser.
• La nature du problème : Bref descriptif du problème rencontré en indiquant depuis combien
de temps il est rencontré, son impact et sa cause en toute objectivité.
• Les objectifs du projet : Identifier les objectifs du projet. Les objectifs répondent-ils aux
critères SMART ? Comment l’équipe va-t-elle mesurer l’atteinte de ses objectifs ?
• La matrice des rôles et responsabilités : Qui est impliqué dans ce projet et quels seront les
rôles et responsabilités de chacun des acteurs ? Identifier le Champion, le ou les Master Black
Belt, les Black Belt et les Green Belt. Qui participe au projet, quand, sous quelle forme et à
quelle échéance ?
• Le périmètre du projet : Un document doit décrire ce qui fait partie du projet et ce qui n’en
fait pas partie. Les échecs sont souvent dus à un problème de périmètre.
• Le planning et les jalons associés : Quels sont les délais pour chacune des phases (DMAIC)
du projet ?
• Le plan de communication : Un support qui doit permettre de communiquer sur les points
essentiels du projet en particulier les objectifs, le planning et les jalons.
L’ « expression de besoins » doit en tout premier lieu prendre en compte les besoins des clients.
Un processus « Cœur de métier » a toujours un impact sur les clients et il est donc normal de bien
comprendre les attentes de ses clients. Trop souvent on oublie ces besoins. Un exemple concret qui
touche une majorité de personne est le virement des salaires. Quoi de plus important, pour le salarié,
que le salaire soit viré sur le bon compte et le plus rapidement possible ! De manière générale on va
définir les besoins en utilisant un arbre des besoins. Le premier niveau est le virement des salaires et le
second niveau comprendra les critères : numéro de compte bancaire, délai de virement et montant. Il
est donc important de bien distinguer 2 niveaux distincts.

Le « macro processus » décrit les principales activités conduites pour permettre le virement du salaire.
Le descriptif concerne le processus actuel. Généralement, le processus est représenté sous forme d’un
graphique simple. Pour décrire le processus, on doit connaître les entrées, les sorties, les fonctions et
les acteurs principaux. Ce descriptif fait généralement apparaître les quelques activités principales du
processus.
Phase « Measure »
La phase « Measure » doit permettre d’identifier la source des problèmes en construisant les
connaissances sur les processus tels qu’ils sont en conditions opérationnelles. Cette phase commence par
l’apprentissage du système existant. Elle doit permettre d’identifier les problèmes qui peuvent survenir
et les moyens permettant d’améliorer les processus. Cette amélioration passe par la collecte notamment
des données qui permettront de construire les indicateurs nécessaires au pilotage et permettant d’offrir
ainsi le moyen de contrôler l’atteinte des objectifs identifiés lors de la phase « Define ».
Lors de cette phase, on va devoir s’attacher aux données, à leurs descriptions et leur analyse.
Cette phase permet de déterminer les zones de mesure. Ces zones, au nombre de trois, sont :
• La mesures des entrées : comment on mesure la qualité des entrants (fournisseurs)
• La mesures du processus : comment on mesure l’efficacité du processus (délai global,
coût, valeur,…)
• La mesures des sorties : comment on mesure le niveau d’atteinte des objectifs
Partant de ces principes de base, la première partie consiste en la construction du « plan de collecte des
données ». Pour que ce plan soit efficace, il est nécessaire de définir à minima les éléments suivants :
• Ce qui est à mesurer : Cet élément provient de la phase « Define » et principalement de
l’expression des besoins
• Le type de mesure : On va indiquer les mesures à effectuer aux entrées, sorties et au niveau du
fonctionnement global du processus. Il n’est pas nécessaire de trop mesurer mais il faut mesurer
à bon escient. Généralement on indique 2 ou 3 mesures en entrées, 2 ou 3 en sortie et une
mesure au niveau du processus. Parfois plus, mais encore une fois, ce qui est juste nécessaire.
• Le type de données : Il faut distinguer 2 types de données : les binaires et les autres. Les
binaires sont du type marche/arrêt, 0 ou 1. Les autres ont une magnitude et apporte beaucoup
plus de pertinence pour l’analyse des données des dysfonctionnements. On utilise d’ailleurs plus
souvent cette dernière catégorie de données.
• Les définitions : Il est important que les équipes aient des définitions partagées de termes,
abréviations, etc. On va donc définir ce que représente la mesure de manière à ce que tout le
monde en ait la même compréhension.
• La cible : On définit ici la mesure cible à atteindre. Par exemple, le virement du salaire doit
avoir été effectué au plus tard 24 heures après l’ordre.
• Les formulaires de collecte : Pour chacune des données collectées, il est important de récupérer
des informations comme par exemple, la fréquence. Le salaire est viré une fois par mois.
• L’échantillonnage : Pour terminer, l’échantillonnage est important. Prenons un autre exemple.
Un fabricant de gommes vend 500 gommes entre 9h00 et 12h00, 100 entre 12h01 et 15h00 et
700 entre 15h01 et 18h00. Cet échantillonnage permet d’identifier plus finement les
dysfonctionnements pouvant impacter chacune des tranches.
L’autre livrable consiste au calcul du « Sigma actuel » du processus et donc de son niveau de qualité.
Pour permettre le calcul du sigma il est important de définir ce qu’est
• l’unité
• un défaut
• une opportunité
Pour reprendre notre exemple de virement, cela consisterait à calculer le nombre de virements qui ne
sont pas effectifs dans les 24 heures.
Le Sigma du processus se calcule de la manière suivante :
Nombre de d éfauts
Sigma = X 1 000 000
Nombre d ’unit és X Nombre d ’opportunit és
Figure 40 : Formule de calcul du Sigma d’un processus
Le résultat obtenu permet de connaître le niveau de sigma effectif du processus. Un niveau 6 de

Sigma consiste à dire que l’on a que 3,4 rejets par million de virements.
Phase « Analyse »
La phase « Analyse » consiste en l’analyse

• du processus,
• des données,
• des causes de dysfonctionnements.
De la qualité des données collectées dépend au plus haut point, la qualité de l’analyse. Les données et
leur qualité sont importantes et la phase « Measure » influe sur la suite du projet Six Sigma. Bien souvent
la phase d’analyse est bâclée. L’humain est ainsi fait que l’on part souvent avec une solution préconçue
qui s’avère généralement mal adaptée pour remédier aux dysfonctionnements. D’où l’importance de
cette phase et des outils qui seront utilisés pour analyser. Il est fait souvent cas où des membres du
projet ont tendance à chercher les solutions avant d’analyser, voire même de proposer des solutions.
Lors de la collecte des données, on a distingué les données binaires des autres données. Il en est de
même pour l’« analyse des données ». L’analyse des données binaires est assez simple en soi et nous
n’allons pas nous y attarder. Par contre, l’analyse des données à magnitude est plus complexe et nécessite
l’utilisation d’outils. Les outils sont généralement des graphiques (tableaux de bord) qui ont tous des
utilisations différentes.
4 Série1
0% 10% 20% 30% 40%
Figure 41 : Exemple de Diagramme
On identifie, par des données collectées et représentées graphiquement, les axes d’amélioration les
plus importants.
En fonction des données à représenter, on utilisera des graphiques différents. Autre point important
est la collecte, dans le temps, des données. On procède alors par échantillonnage.

90
80
70
60
50
Série1
40
30
20
10
0
8h00 10h00 12h00 14h00 16h00 18h00
Figure 42 : Graphique pour représenter un échantillonnage
Dans l’exemple ci-dessus, on constate des « pointes » à 12h00 et à 16h00. On peut alors corréler des
dysfonctionnements.
Prenons un exemple concret. Notre société vend des vélomoteurs à des distributeurs. La journée démarre
à 8h00 et se termine à 18h00. On collecte des données comme les unités vendues, le nombre de
commerciaux présents pour vendre ces unités et pour des plages horaires définies. Le dysfonctionnement
est identifié suite à des plaintes des distributeurs pour non traitement des commandes le jour même
ou à défaut le lendemain matin. Un projet Six Sigma est mis en place. Les données à collecter sont
identifiées et collectées.
Suite à la collecte des informations, on analyse les données et on constate que (voir tableau ci-après), on
vend le plus d’unités à 16h00, mais que peu de commerciaux sont présents. D’où des dysfonctionnements
pour traiter les commandes. Le raccourci consisterait à dire qu’il faut ajouter des commerciaux à
16h00.
H ora ires U nités v endues C om m erc ia ux

8h00 10 2
10h00 40 4
12h00 60 5
14h00 30 4
16h00 80 3
18h00 40 4
Figure 43 : Exemple de dysfonctionnement
On pourrait alors dire qu’il faut embaucher des commerciaux supplémentaires. Erreur ! Il faut tout
d’abord analyser. Nous pourrions avoir par exemple l’étrange coïncidence que 2 des commerciaux sont
en réunion tous les jours à cette heure précise. Nous pourrions également avoir le fait qu’à 16h00 un
distributeur passe toutes ses commandes et que celles-ci comportent des erreurs. Un des commerciaux
passe tout son temps à traiter les erreurs plutôt que de prendre des commandes supplémentaires. D’où
l’importance de l’analyse.
Les données collectées peuvent faire l’objet d’une représentation graphique comme ci-dessous qui nous
permettrait, en un clin d’œil, de comprendre la nature du dysfonctionnement. N’oubliez pas qu’un
tableau de bord doit, avant tout, servir d’outil de prise de décision.
C’est exactement ce qui se passera lors de la mise en place d’outils de supervision continue de l’efficacité
des processus.
80
70
60
50
40 Série1
Série2
30
20
10
0
8h00 10h00 12h00 14h00 16h00 18h00
Figure 44 : Représentation graphique du dysfonctionnement
Autre partie importante, l’ « analyse du processus ».
L’analyse du processus consiste en une étude des étapes d’un processus macroscopique pour mettre
en évidence celles qui sont à faible valeur ajoutée, voire dans certains cas, totalement inutiles. Par
exemple, imaginez que dans notre processus de commande de vélomoteurs nous avions mis une étape
de négociation commerciale. Il serait probablement plus utile de parler d’options qui ajouteraient de la
valeur au vélomoteur. Maintenant l’analyse est souvent plus complexe que cela.
L’équipe qui doit analyser le processus va devoir valider la conformité des activités par rapport à des
critères qui peuvent être parmi les suivants :
• les activités ne sont pas exécutées plusieurs fois
• on se focalise sur les dysfonctionnements constatés par les clients
• on limite, voir élimine les temps de latence de certaines activités du processus
• on évite les contrôles trop fréquents de la bonne exécution d’activités précédentes à celle en cours
• on identifie l’effort pour la préparation des activités
• on identifie les déplacements
• les activités sans valeur ajoutée mais obligatoires pour le bon fonctionnement sont mises en valeur
La phase d’analyse est toujours plus complexe qu’il n’y paraît.
Maintenant il est nécessaire de vérifier l’ampleur des dysfonctionnements. Si par analyse on constate que
le pourcentage est très faible, on pourra alors passer à une autre activité, qui elle mettra en évidence des
besoins d’optimisation plus important car plus impactant sur le bon fonctionnement du processus.
Le dernier point de la phase « Analyse » est l’« analyse de la cause principale » des dysfonctionnements.
Rappelez vous mon exemple et méfiez vous des raccourcis car ils sont souvent cause d’échecs d’optimisation
de processus.
Six Sigma définit d’ailleurs trois étapes importantes dans l’analyse de la cause :
• L’ « Open Step » : il consiste en un travail d’équipe qui énumère toutes les causes possibles
du dysfonctionnement constaté
• Le « Narrow Step » : il consiste en l’élimination de la majeure partie des causes possibles
identifiées dans l’étape précédente
• Le « Close Step » : il consiste en la validation des causes de dysfonctionnements du processus
et leur explication.
C’est une démarche qui procède par élimination.
On constate, par expérience, que l’on favorise le travail d’équipe. Ce travail d’équipe et plus exactement
ces ateliers, sont ce qu’il y a de plus efficace si on se donne comme conduite, de ne pas se censurer
durant l’élaboration de la liste de raisons envisageables, y compris vis-à-vis de causes qui paraîtront
très incongrues.

Phase « Improve »
C’est certainement la phase qui apporte le plus de satisfaction personnelle car elle permet d’identifier
des solutions possibles avant de sélectionner celle qui sera la plus pertinente.
Toutes les solutions sont envisagées et les avantages et inconvénients de chacune d’entre-elle sont
identifiés (coûts, complexité, délais, …). Une fois les critères identifiés, on peut les appliquer de manière
à effectuer le choix. Généralement, le comité de pilotage en effectuera le choix final car les impacts sur
la stratégie de l’entreprise peuvent être parfois importants.
Il sera important de correctement prioriser les fonctions à mettre en œuvre. Le projet est dans un cycle
d’amélioration continue, donc on doit prendre en compte les effets les plus visibles et perceptibles et
en particulier ceux qui ont un impact direct sur les clients.
Une fois le choix de la solution réalisé, on doit décrire la solution.
Ce descriptif consiste en des spécifications fonctionnelles voire techniques de la solution, pour en permettre
l’implémentation. Cette solution doit comporter un lotissement dans le cas où son implémentation serait
trop conséquente. Il ne faut pas oublier que le projet est visible par le management de l’entreprise,
mais avant tout, par les clients. Réaliser dans des délais courts, quitte à travailler par itérations, ne sera
qu’une sage décision.
L’une des pratiques de Six Sigma lors de la phase « Improve » est le DOE(*). Elle permet d’expérimenter
la conception par la modification de paramètres permettant :
• De déterminer s’il existe des solutions plus efficaces que celle (s) envisagée (s)
• D’identifier des causes ayant des effets plus ou moins incontrôlables sur le processus
• De mieux minimiser les variations du processus
• De diminuer les délais de développements
• De choisir des solutions robustes
• De concrétiser la production finale du processus
• De valider ce qui est ou reste à améliorer
Souvent, cette expérimentation est concrétisée par un projet pilote qui va permettre de valider un certain
nombre de concepts et de faire évoluer la solution au plus près des besoins. C’est là toute la puissance
de la phase Improve car on peut, à ce moment, mieux identifier les paramètres extérieurs et donc ceux
potentiellement incontrôlables qui pourraient influencer les résultats obtenus.
Pour terminer, l’implémentation de la solution permettra de voir concrètement le processus s’améliorer

et donc de potentiellement mieux satisfaire les clients.
N’est ce pas l’objectif principal de la mise en œuvre de la méthodologie Six Sigma ?
Phase « Control »
Cette dernière étape de la démarche Six Sigma, permet de mettre en place les moyens de contrôler le
fonctionnement des processus.
Il existe 2 étapes principales de la phase « Control » que sont :

• Définir la solution technique permettant de contrôler le processus.
• Décrire le plan complet de mise en œuvre de la solution cible
« Définir la solution technique permettant de contrôler » le processus doit faciliter le contrôle de la

qualité des processus au jour le jour et en quasi temps réel. Ce contrôle continu va également permettre
de mettre en place un pilotage des processus par l’utilisation de tableaux de bord qui vont apporter une
vue des données et apporter les moyens d’alerter les acteurs lors de dysfonctionnements (voir chapitre
« 6. Le pilotage des processus » page 125).
(*) voir glossaire
Pour terminer, le « plan complet de mise en œuvre » doit faire apparaître : page 192
• Le processus tel qu’il devrait être au final
• Les mesures associées au processus cible
• Les critères de qualité d’exécution du processus
• Les modes de collecte des données et surtout d’où les données proviennent
• Les méthodes qui permettent de contrôler les indicateurs de performance du processus
• Les améliorations à mettre en œuvre pour que le processus fonctionne mieux.
On peut alors repartir dans des itérations successives pour un même processus et ce afin d’en effectuer
son amélioration continue.
Les points d’accostage entre Six Sigma et le BPM
Déjà pourquoi la combinaison Six Sigma et BPM est elle intéressante ? Tout simplement parce que le
BPM est orienté suivi, optimisation et automatisation de processus et que la méthodologie Six Sigma
est orientée analyse des processus afin de générer de la valeur financière par leur amélioration. Si on
regarde comment le BPM s’inscrit au niveau des phases « Six Sigma », on constate que le BPM apporte
tout l’outillage et le support nécessaire pour étayer la plupart des phases.
Pour les phases « Define » et « Improve », on comprend que le BPM apporte peu car on fait appel soit à
de l’outillage en dehors du périmètre d’un outil de BPM (comme des rapports financiers par exemple),
soit à des comparaisons par analyse. Lors de la phase « Improve », on effectue des comparatifs entre
plusieurs simulations financières ou bien on analyse des situations probables pour, par bon sens, choisir
la situation qui correspondra au mieux à la réalité.
Lors de la phase « Measure », le BPM apporte un accès aux données que celles-ci soient historiques ou
collectées en « temps réel » et permet également d’avoir accès à des métriques qui sont déduites voire
calculées automatiquement par l’outil de BPM.
Pour la phase « Analyse », les outils graphiques simplifient la mise en place du suivi des processus
car si on utilise souvent des outils pour collecter les données, avoir une représentation graphique du
processus et savoir de quelles étapes proviennent les données collectées qui permettront d’améliorer le
processus, assure une analyse plus rapide et plus fiable. Autre point intéressant, ce sont les règles métiers.
En effet, les règles métiers sont définies au sein de l’outil de BPM et on a ainsi la possibilité de les tester
avec différentes valeurs avant de les mettre en place dans l’environnement réel. Les ajustements sont
ainsi vus en temps réel par l’utilisation de briques de simulation. Dernier point, ce sont les composants
réutilisables. Une solution de BPM permet de créer des composants. Ces composants, comme par exemple
des formules de calculs, règles, sous-processus sont souvent mutualisés. Ceux-ci permettent de diffuser
des modifications à l’ensemble des processus qui les utilisent. Les composants de collecte d’information
sont mis à jour dès que la modification est mise en œuvre. Le déploiement est également simplifié.
Pour finir, la phase « Control » bénéficie, grâce aux outils de BPM, de toute l’infrastructure permettant
de contrôler la bonne exécution des processus, notamment pour leur suivi et leur supervision. Le BPM
apporte également, une forme de standardisation même si les outils n’utilisent pas tous des standards
en tant que tels. Ils cadrent le formalisme des processus, des indicateurs, des modes de suivi et de
supervision qui font que toutes les opérations sur les processus en sont simplifiées car faisant appel
à des procédures mutualisées et ce quels que soient les processus visés. Le suivi et la supervision des
processus sont certes, une des fonctions de base de tout outil de BPM, mais ce n’est pas pour autant
que les procédures sont industrialisées. Imaginons un instant, l’effort qui serait nécessaire pour avoir de
telles fonctions pour des processus implémentés en utilisant des langages de programmation et ce, peu
importe le langage utilisé. D’ailleurs les fonctionnalités ne sont pas limitées au suivi mais également à la
relance à différents stades d’un processus. Le dernier point est le lancement d’instances de processus. Ceci
est vrai que l’on soit au moment de la modélisation et simulation pour en connaître le comportement
ou que l’on soit lors de l’exécution du processus dans l’environnement de production. On peut avoir
besoin de lancer une instance de processus en particulier.
Le tableau ci-après résume la complémentarité entre Six Sigma et la discipline du Business Process
Management et détermine les apports d’un outil de BPM à cette méthodologie.

Phase Six Sig m a Apports du B PM
Define -
_ Accès au x données des processu s
M easu re _ M étriq u es
_ Ou tils g raphiq u es
_ Règ les m étiers
Analyse _ Com posants réu tilisables
Im prove -
_ Infrastru ctu re de contrôle
_ Standardisation
_ Su pervision et su ivi des processu s
Control _ Lancem ent d' instances de processu s
Figure 45 : Complémentarité Six Sigma et BPM
Mais la complémentarité ne s’arrête pas à ces points là. De manière plus globale, on pourra, par exemple,
automatiser tout ou partie de processus et l’outil de BPM, intégré au système d’information, donne accès
aux applications et facilite donc la mise en œuvre de cette automatisation. Par ailleurs et toujours du fait
de son intégration au système d’information, l’outil de BPM apporte une facilité d’accès aux données et
donc aux métriques utilisées pour analyser et suivre les indicateurs de pilotage identifiés pour chacun
des étapes et composants d’un processus.
Bien entendu, il faut surtout se défaire de l’idée que la mise en place de la méthode Six Sigma est
systématiquement très coûteuse, car si elle implique rigueur et outillage, elle a toujours été source de
gains, que ces gains soient directs ou indirects. D’ailleurs, si on regarde de nouveau les avantages de Six
Sigma et de la mise en place d’une démarche outillée de BPM, on se rendra rapidement compte qu’ils
sont similaires et parfois complémentaires pour, au final, un meilleur résultat.
L’accès aux données proposé par les outils de BPM combiné aux méthodes d’analyses de ces données
par Six Sigma, laisse penser que méthodologie et l’outillage de BPM vont naturellement de paire. Le
BPM a tous les points d’accès aux applications du système d’information et permet de mettre en place
toutes les formules de calculs nécessaires pour piloter les processus et permettre d’analyser les axes
d’améliorations possibles.
La fusion de Six Sigma avec les outils et la discipline du BPM permet d’adresser de bout en bout tout
le cycle de vie d’un processus métier.
Lean Six Sigma

La combinaison de Lean et de Six Sigma se voit de plus en plus. Si bien que l’on entend parler de
« Lean Six Sigma ».
L’approche Lean Six Sigma se fait selon 3 axes principaux que sont :
• Une méthodologie autour de l’amélioration continue des processus
• Une démarche basée sur la résolution de problèmes (DMAIC)
• Des outils pour accompagner la démarche (Lean)
Pour comprendre mieux les différences entre ces 2 méthodes, nous allons comparer quelques points
clés.
S ix S igm a L ean
Réduire les variations des
P rinc ipe Eliminer les gaspillages
processus
Tous les processus Plutôt les processus de
D om aine d'applic ation
métiers l'industrie manufacturière
Approche générique de
Implémentation basée sur
A pproc he résolution des problèmes
les bonnes pratiques
basée sur les statistiques
Divers modes mais

principalement basé en Utilisation du Value
Mode de s élec tion d'un projet
fonction de l'importance du Stream Map
processus
D élai d'un projet de 2 à 6 mois de 1 semaine à 3 mois
O rientation Problèmes Flux
Figure 46 : Comparaison entre Six Sigma et Lean
Six Sigma a une approche plus théorique que Lean qui elle est basée principalement sur des bonnes
pratiques. Mais Lean a ses limites lorsque les problèmes deviennent complexes à résoudre alors que Six
Sigma va permettre, de par son niveau de détail, d’approfondir l’analyse permettant ainsi d’identifier la
cause de manière plus fiable que Lean.
Le « Value Stream Mapping » de Lean apporte la vision cible et le plan d’action pour y parvenir.
Les techniques Six Sigma permettent d’analyser n’importe quel processus de n’importe quel secteur
alors que Lean est focalisé sur les processus de fabrication (manufacturing).
Six Sigma apporte la démarche DMAIC avec un certain nombre d’outils. Lean va compléter les outils
de cette démarche.
Un principe reste vrai dans l’application des méthodes : la formation. Cette formation doit être dispensée
à toutes les personnes qui doivent intervenir dans le cycle de vie du projet. Bien entendu, les niveaux
de formation seront différents, mais l’introduction à la méthode est un vecteur de communication
important.
O utils
P has e S ix S igm a 6 S igm a L ean
D efine - -
Cartographie du
processus
Meas ure Outils de mesure
Collecte de données
Etudes Value Stream Mapping
Analyses statistiques
A nalys e Niveau approfondi Identification des
d'analyse statistique gaspillages
5S
Im prove
DOE TPM
Processus de contrôle Processus de contrôle
C ontrol
de statistiques de statistiques
Figure 47 : Complémentarité des outils Six Sigma et Lean
Un dernier point également très important : on implique des acteurs tout au long du processus pour
les questionner, collecter des données et tester des solutions possibles. La moindre des choses est, à
minima, de les tenir informés des résultats obtenus voire de trouver un moyen de les récompenser.
La reconnaissance a toujours payé, surtout si vous souhaitez utiliser ultérieurement les mêmes acteurs qui la
première fois ont très probablement mis beaucoup de bonne volonté. La bonne volonté s’entretient.

Les normes ISO9000
Le panorama n’eut été complet si nous n’avions évoqué les normes qualités ISO9000. Ces normes sont
publiées par l’ISO (Organisation internationale de normalisation). Il existe plusieurs séries :
• ISO9000 : constitue le vocabulaire relatif aux normes qualité
• ISO9001 : définit toutes les exigences d’un système de management par la qualité
• ISO9004 : décrit des lignes directrices pour l’amélioration de la performance
Nous pourrions citer encore bien d’autres normes dont la plupart sont à destination de secteurs spécialisés
comme l’aéronautique, l’automobile, etc., mais là n’est pas notre objectif.
Néanmoins, il est important de noter que toutes les normes ISO font appel à un processus de certification
qui passe par une société accréditée pour préparer cette certification et pour réaliser les audits nécessaires
et passer la certification de l’entreprise. Le lien entre le BPM et les certifications ISO se fait sur un point
de vue formalisation des processus et sur leur mise en œuvre. Le pilotage viendra ensuite et surtout
pour accompagner la démarche de pilotage de la performance des processus critiques de l’entreprise.
Les niveaux de maturités

Le niveau de maturité d’une entreprise et de ses processus est important dans la mise en place d’une
démarche de Business Process Management. Son évaluation doit permettre de définir son niveau actuel
de maturité, le niveau vers lequel elle souhaite aller et les étapes nécessaires pour atteindre le niveau
désiré.
Facile ? Pas tout à fait ! En fait si l’on regarde les niveaux de maturité du modèle CMM, un principe est
vrai : il ne faut pas sauter des étapes. Par contre des modèles comme CMM ne prennent pas en compte
certains aspects comme le niveau d’implication du Management, le niveau de formation à dispenser,
les outils à utiliser, la conduite du changement à mettre en place, etc.
Pour évaluer correctement le niveau de maturité de l’entreprise, il est nécessaire d’évaluer les 3 niveaux
que sont :
• Le degré de maturité global
• Le degré de maturité des processus
• Le degré de maturité de l’intégration du système informatique
Ces degrés vont permettre de définir la trajectoire permettant d’atteindre le niveau de maturité suffisant
pour l’efficience de l’entreprise. Ce niveau de maturité reste, bien évidemment, dépendant des objectifs
stratégiques de l’entreprise.
Le degré de maturité global
Des exemples ont démontré que certains facteurs non réunis peuvent conduire à l’échec de projets
BPM. C’est pourquoi, il est important de faire l’état des lieux et évaluer le degré de maturité global de
l’entreprise et de ses organisations pour conduire toutes les actions nécessaires permettant de garantir
la bonne marche du ou des projets.
Le degré de maturité global dépend de critères comme :

• Le niveau d’implication du management de l’entreprise : C’est la notion de sponsor. Si le
sponsor n’a aucun intérêt ou si son intérêt est très limité alors le projet ne pourrait avoir que peu de
sens. Par contre, il se pourrait que le sponsor souhaite savoir comment faire en sorte de communiquer
sur les projets, l’avancement et les gains constatés. Le niveau maximum serait que le sponsor intègre la
culture de l’amélioration continue des processus.
• L’organisation envisagée pour le projet BPM : Pour cette organisation, cela ira de l’organisation
qui n’est pas du tout définie vers une organisation définie et un comité de pilotage stratégique créé.
Ceci pour aller à un niveau où l’amélioration des processus fait partie intégrante de la culture et des
activités au quotidien des membres de l’organisation.
• Le niveau de formation des membres du projet (côté client en particulier) : Les membres de
l’équipe ne sont pas formés et les méthodes ne sont pas choisies. La formation des équipes est effectuée
pour aller à un niveau de formation tel que les méthodes et outils sont choisis. Le management est
également formé.
• Les objectifs en termes de performances : Dans ce cas, on se situe au niveau du pilotage de la
performance. Le niveau va d’objectifs de performance non définis vers des objectifs quantifiés. Pour
la partie outillage, le niveau va d’outils de pilotage non sélectionnés pour aller au niveau où les outils
sont choisis, les objectifs sont définis et le pilotage de la performance fait partie intégrante des activités
quotidiennes de l’équipe.
• Le mode de fonctionnement des équipes dédiées à l’amélioration des processus : Ce niveau
va de la non définition des équipes à la définition des équipes pour aller à un mode de fonctionnement
où les équipes identifient systématiquement le plan d’action à dérouler pour garantir l’amélioration des
processus.
• Les outils et les techniques mises en œuvre : Ce niveau consiste à identifier les outils à utiliser
et leur implémentation. On démarre de l’identification des outils en passant par une short-list(*)
à la mise en place du ou des outils sélectionnés afin de permettre une instrumentation complète et
systématique de tous les processus.
• Les parties prenantes : Il faut comprendre les utilisateurs des processus. En clair, cela consiste
en une évaluation du niveau d’implication des différents acteurs des processus. Il est de bon augure
que les utilisateurs soient très impliqués dans le dispositif projet. Le niveau le plus élevé serait que les
utilisateurs revoient toutes les spécifications fonctionnelles.
• Le niveau d’intégration du système d’information : Ce niveau correspond au degré de mise
en œuvre des outils permettant de supporter la démarche de BPM. L’outil de BPM est sélectionné et
déployé de manière à ce que tous les processus soient supportés par le système d’information.
• Le niveau d’accréditation : Ce niveau correspond à la mise en place d’un degré d’accréditation
qui commence par une accréditation interne pour aller jusqu’à un niveau d’accréditation externe pour
ne pas dire un niveau de certification.
L’utilisation de graphiques peut faciliter la lecture de la matrice. N’oublions pas un autre principe de
la matrice de maturité qui est de disposer d’informations permettant de prendre des décisions. Plus la
lecture en sera facile plus les décisions pourront êtres rapides.
Figure 48 : Exemple de radar pour le degré de maturité global
Notre exemple de graphique démontre que l’écart est important entre l’actuel et la cible. Il sera donc
nécessaire de dresser un plan d’action qui permettra de sécuriser la trajectoire vers la cible.
Bien souvent, et l’expérience l’a démontré à mainte reprises, les acteurs des projets ont tendance à
prendre des raccourcis (préjuger d’une solution par exemple) qui peuvent paraître intéressants pour
(*) voir glossaire l’amélioration des processus mais qui, au final, nécessiteront des efforts beaucoup plus importants que
page 192 si une analyse préalable était réalisée.

Le degré de maturité des processus
Le degré de maturité des processus est important et il est composé du niveau de maîtrise des processus
et du niveau de performance des processus.
Lors de la représentation graphique, il est également souhaitable d’identifier :

• la liste exhaustive des processus : Tous les processus doivent être identifiés pour permettre de
les représenter sur la matrice de maturité. Ces processus sont codifiés (lettres dans les bulles
de notre graphique ci-après).
• le degré d’importance de chacun des processus : Pour chacun des processus identifié, on
évalue le degré d’importance. Là, Six Sigma, par exemple, peut déjà nous aider à nous poser les
bonnes questions et séparer les processus « cœur de métier » des processus « support ».
L’importance, dans notre exemple de graphique ci-après, est représentée par la grosseur de la bulle.
• le niveau de maîtrise de chacun des processus : Ce critère permet d’indiquer le niveau de
connaissance du processus, son niveau de formalisme, la connaissance de ses indicateurs, etc.
• le niveau de performance de chacun des processus : Ce dernier critère permet d’indiquer si
le processus est performant ou non.
N ive a u de m a turit é
N ive a u 1 N ive a u 2 N ive a u 3 N ive a u 4 N ive a u 5
Idéal
Idéal
JJ
BB LL
KK
CC
AA O
O
M
M
N
N
Niveau de performance
D Q
Q
D
RR
PP
N ive a u de Ma turit é
Figure 49 : Graphique de maturité des processus
D’ailleurs les 5 niveaux peuvent se reposer sur les niveaux de maturité de CMM et les définitions de
la norme ISO 9004 :
• Niveau 1 : Le processus n’est pas maîtrisé et est inadapté aux besoins opérationnels. Les performances
du processus sont insuffisantes. La norme ISO 9004 détermine ce niveau comme étant une approche
« non formelle ». De plus, l’entreprise n’a pas d’outil de BPM.
• Niveau 2 : La maîtrise est insuffisante. Le niveau de performance du processus est très médiocre.
Ce processus n’a qu’une faible adéquation aux besoins opérationnels. L’entreprise possède un ou
plusieurs outils de BPM mais ceux-ci sont mal utilisés. La norme ISO 9004 indique que ce niveau est
une approche « réactive ».
• Niveau 3 : La maîtrise et les performances du processus sont à améliorer. L’entreprise possède un
outil de BPM. Son utilisation est planifiée et un ou plusieurs processus « cœur de métier » sont identifiés
pour être implémentés. La norme ISO indique que l’approche est une approche « formelle stable ».
• Niveau 4 : Le processus est efficace et maîtrisé. La performance approche du niveau attendu.
L’outil de BPM est généralisé et supporte la majorité des processus. L’outil est utilisé pour gérer les
processus métiers et non pas pour l’automatisation de processus IT. La norme ISO nomme ce niveau
l’ « amélioration continue accentuée ».
• Niveau 5 : Le processus est totalement maîtrisé. On utilise des bonnes pratiques pour l’améliorer et
le contrôler. L’outil de BPM est entré dans la culture de l’entreprise. Tous les collaborateurs ou presque
l’utilisent. Les données collectées sont utilisées en quasi temps réel pour piloter la performance des
processus. La norme ISO indique que ce niveau est celui des « performances optimales ».
Pour définir les niveaux de maturité, on fait appel à des questionnaires qui sont passés en revue pour
chacun des processus.
Le degré de maturité de l’intégration du SI
Pour terminer, le degré de maturité de l’intégration du Système d’Information doit être évalué afin de
définir le plan d’action associé permettant d’intégrer les applications du SI. Cette intégration doit apporter
toutes les briques nécessaires pour permettre des échanges internes et externes et permettre l’utilisation
des services mis à disposition au sein du SI, pour intégrer tout ou parties de processus.
Pour ce faire, le plus simple est de se baser sur les niveaux définis par l’« Integration Consortium(*) »
qui en définit 5.
• Niveau 1 – Générique : Approche Chaotique. Les techniques d’intégration ne sont pas
documentées et la plupart sont obsolètes. La connaissance est détenue par quelques individus.
Certaines fonctions sont effectuées manuellement.
• Niveau 2 – Point à point : Basé sur les besoins. Les besoins simples sont pris en comptes et
les techniques sont basées sur une intégration point à point peu évolutive. La maintenance
est coûteuse.
• Niveau 3 – Défini : Approche Structurée. La documentation existe et des technologies de
type EAI en mode « Hub and Spoke(*) » sont utilisées. Il existe un référentiel avec les modèles
des processus métiers. Des principes clairs de gouvernance sont mis en place.
• Niveau 4 – Géré : Approche correctement gérée. Métadonnées et référentiels font partie des
standards d’architecture. Les principes mettent en œuvre des bonnes pratiques qui permettent
un niveau de réutilisation élevé. Les applications du SI sont construites avec l’optique
d’être intégrées.
• Niveau 5 – Orienté services : Approche parfaite. En plus du niveau 4, l’architecture est
orientée services (SOA). Des outils de BPM, de BAM et de BSM(*) sont mis en œuvre et le SI est
piloté correctement. Un référentiel de services métiers est accessible. L’outil BPM utilise
correctement les services métiers définis.
Une des difficultés qui ne transparaît pas dans le niveau d’intégration est le fait d’avoir à traiter des
problématiques transverses pointues. Nous verrons d’ailleurs dans la partie de cet ouvrage qui traite de
l’intégration, que cette transversalité est ressentie également sur un point de vue purement technique
et non uniquement métier, fonctionnel ou organisationnel.
Niv ea u 5
Niv ea u 4
•• Architecture
Architectureorient
orient ée
ée
services
services(SOA)
(SOA)
•• Strat
Stratégieégiebas
bas ée
éesur
(Source Integration Consortium)
sur
Niv ea u 3 •• Utilisation
Utilisationdd ’outils
’outilsde
de
les
lesm métadonn
étadonn ées
ées
BPM
BPMet etde
deBAM/BSM
BAM/BSM
•• Gestion
Gestionde derr éférentiel
éférentiel
•• Bonnes
Bonnespratiques,
pratiques, •Référentiel
•Référentielde de
Niv ea u 2 •• Niveau
Niveaudede
processus
processus services
servicesm m étiers
étiers
réutilisation
réutilisation élev
élevéé
standardis
standardis és ésetet •• Infrastructure
Infrastructure
•• Centre
Centredede
document
document és és orient
orient ée éeservices
services(SOI)
(SOI)
comp étence
comp étence
•• Mod
Modélisation
élisationdes
des •• Int
Intégration
égrationparfaite
parfaite
intégration
intégration
Niv ea u 1 processus
processusm m étiers
étiers
•• Interfaces
Interfacespoint
point àà •• Excellence
Excellence
•• Mod
Modèles èlesadministr
administr és és
point
point op
opérationnelle
érationnelle
et
etsauvegard
sauvegard és ésauau
•• Couplage
Couplagelâche
lâche •• Les
Lesapplications
applicationssont
sont
sein
seindd ’un ’un rr éférentiel
éférentiel
•• Pas •• Automatique
Automatique construites
construitespour pourêtre
être
Pasde de •• Gouvernance
Gouvernance
documentation •• Middleware
Middleware orient éé
orient int
intégrées
égrées
documentation •• Adaptateurs
Adaptateurs
•• Impr évisible message
message •Les
•Lesrr ésultats
ésultatssont
sont
Impr évisible •• Int
Intégration
égrationde detype
type
•• Manuel •• Règles
Règlesint int égrées
égréesaux aux prévisibles
prévisibles
Manuel «« Hub
Huband and Spoke
Spoke »»
•• Dépendant applications
applications
Dépendant •• Formations
Formations
d’individus •• Processus
Processusm m étiers
étiers
d’individus •• Gestion
Gestiondes des
•• Des inconsistants
inconsistants
Desinterfaces
interfaces fournisseurs
fournisseurs
archa
archaïquesïqueset et
spécifiques
spécifiques
•• Architecture
Architecturenon non
standard
standard
•• Réutilisation
Réutilisationlimit limit ée
ée
Figure 50 : Niveaux de maturité de l’intégration
(*) voir glossaire Néanmoins, le niveau de maturité actuel, et ce quel qu’il soit, doit être identifié. Cela permettra d’éviter
page 192 de passer une étape qui pourrait s’avérer trop importante et trop coûteuse.4.

4. Modélisation,
Analyse & Optimisation
Tout processus de l’entreprise devrait être formalisé mais la réalité est toute autre. L’expérience démontre
que des processus peu ou mal formalisés pourraient amener à repartir d’une feuille blanche.
Et d’abord, que doit comprendre le formalisme d’un processus ? Le formalisme devrait comprendre
un modèle ou représentation graphique du processus permettant de se représenter le fonctionnement
de celui-ci. Ensuite, un document expliquant toutes les étapes, les cas exceptionnels où le processus
pourrait dévier de son chemin initial, les indicateurs qui permettent de qualifier la qualité du processus
lors de son déroulement mais également les indicateurs qui permettront de qualifier la qualité de ce qui
est produit en sortie du processus, doit être rédigé.
Il est donc nécessaire de décrire les étapes permettant de décrire le processus dans son ensemble,
de manière d’une part à en avoir une vision fonctionnelle, mais d’autre part pour permettre à une
équipe technique d’en faire découler une implémentation pour tout ou partie au sein du système
d’information.
Mais en premier, et après avoir déterminé la liste des processus candidats et triés par priorités, il est
nécessaire de déterminer le niveau de formalisme existant ou non. Pour ce faire, nous nous appuyons
sur les étapes permettant ainsi d’identifier les documents (livrables) qui, à minima, constitueront le jeu
de documentation pour chacun des processus.
Les étapes de la formalisation des processus

Les étapes du formalisme sont représentées sous forme d’un cycle itératif, ce qui ne signifie en aucun
cas qu’une fois sorti du cycle le processus n’existe plus ou n’évolue plus.
Si on se réfère au cycle allant de la modélisation à l’implémentation(*) des processus, nous avons des
étapes importantes que sont :
• La cartographie
• La modélisation
• La documentation
• L’analyse
• L’optimisation
• L’implémentation
Un autre sujet, qui lui est plus global, est la gestion de version des processus. Les processus sont censés
être en constante amélioration. La gestion de version permettra de garantir que tous les acteurs qui
œuvrent à leur amélioration travaillent bien sur les bons modèles et documents.
La formalisation permet de définir les modèles des processus, la documentation et les métriques associées.
Le mode de fonctionnement est itératif et permet la première fois de modéliser les processus qui ne le
seraient pas, de les analyser, de les optimiser puis de les implémenter. Si le processus a besoin d’être
modifié, on repart dans la boucle.
(*) voir glossaire

page 192
C artographie
Mod élis ation
Implé mentation
D oc umentation
O ptimis ation
A naly s e
Figure 51 : Les étapes de la formalisation et optimisation
L’étape de modélisation permet de se poser un grand nombre de questions plus ou moins structurantes
et facilitant la compréhension du fonctionnement détaillé du processus et surtout :
• de mieux prendre en compte les besoins des utilisateurs
• d’impliquer les acteurs du processus
• de clarifier les rôles et responsabilités des acteurs des processus
• de transformer un processus pour être en adéquation avec les objectifs stratégiques
de l’entreprise
• de diminuer les coûts et délais induits par le processus
• de proposer un pilotage temps réel de la performance du processus
• de limiter les variations et par conséquent les aléas
Cette formalisation des processus peut s’inscrire dans un processus de certification de l’entreprise à
une norme qualité (ISO par exemple). Formaliser les processus c’est également laisser la possibilité à
d’autres d’en comprendre leurs fonctionnements. De plus, la vie de l’entreprise fait qu’elle est confrontée
à des départs et des arrivées de collaborateurs. Ces départs causent des pertes de la connaissance des
processus de l’entreprise.
Formaliser ne veut pas dire formaliser à l’origine et s’arrêter là. Il faut également s’astreindre à mettre à
jour toutes les modifications apportées aux processus. Le cycle complet veut que les processus soient
améliorés et toutes les améliorations doivent être tracées pour en comprendre l’origine.
Pour terminer, capitaliser le savoir sur les processus de l’entreprise devient important et ce depuis l’origine
des processus. Pour permettre de mieux capitaliser il est probablement judicieux de mettre en place un
référentiel des processus. Ce référentiel impliquera un certain niveau de formalisme qui permettra de
construire une véritable base de capitalisation du savoir-faire et des connaissances.
Le référentiel des processus

Le référentiel des processus permet d’avoir toutes les informations sur les processus de l’entreprise,
mais également des éléments comme des cas pratiques, des indicateurs, etc.
Ce référentiel, bâtit au fil du temps, permet de capitaliser le savoir sur tous les thèmes environnants
du processus.
Pour bien faire, et de par les expériences connues, le référentiel peut comporter les éléments
suivants :
• des processus standardisés : Il existe des organismes qui définissent des standards de

fonctionnement d’un processus pour un domaine métier particulier. Dans certains cas le fait de
s’appuyer sur les standards permettra à l’entreprise d’obtenir un label qualité.
• des modèles : C’est la représentation graphique des processus. On utilise généralement un
langage commun basé ou non sur des standards du marché
• des indicateurs de performances : Chaque processus comporte quelques indicateurs
permettant de connaître leur performance. Ces indicateurs de performance répertoriés sont de
« haut niveau ».
• des bonnes pratiques : Les bonnes pratiques permettent de définir ce qui est bon de faire
et d’indiquer en quoi cela est bénéfique.
• Un Dictionnaire de termes : ce dictionnaire comprend tous les termes communs avec leurs
définitions partagées par l’ensemble des acteurs.
• des indicateurs de coûts : lors de la modélisation et pour permettre la simulation du
fonctionnement des processus, on intègre généralement des indicateurs de coûts par activité.
Ces indicateurs permettent d’évaluer le coût d’exécution d’un processus.
• des benchmarks : comparatifs et positionnement du fonctionnement d’un processus
particulier au sein de plusieurs entreprises concurrentes ou non.
• des supports de formation : Dans le cadre de la conduite du changement d’une part et de la
montée en compétence de nouveaux acteurs d’autre part, il est nécessaire de disposer de
supports de formations permettant à ces nouveaux acteurs de suivre un cursus leur permettant
de comprendre à quel niveau ils interviennent dans ces processus.
• des cas pratiques : Les cas pratiques proviennent d’expériences vécues dans d’autres sociétés.
Ces sociétés peuvent provenir de secteurs d’activités similaires ou différents
• des références documentaires : pour que les acteurs puissent approfondir certains sujets, le
référentiel doit comprendre des renvois vers des ouvrages mais également des articles, des sites
Internet spécialisés, des spécifications, projets, notes, etc.
Référentiel des processus
Indic
Indicaate
teurs
urs SS upports
upports
PProces
rocesssus
us BBonne
onness DDee de
de CCas
as pra
pratiques
tiques
ssta
tandardis
ndardis ééss pra
pratique
tiquess ccooûû ts
ts forma
formation
tion
Indic
Indicaate
teurs
urs RR ééfé
fére
rences
nces
de
de DDic
ictionna
tionnaire
ire Mod
Mod èèle
less BB eenc
nchmarks
hmarks doc
documeumentantaires
ires
pe
performa
rformance
nce
Figure 52 : Les composants d’un référentiel des processus
Il arrive que des entreprises utilisent un outil spécialisé de modélisation pour créer ce référentiel, et
l’expérience a souvent démontré que ces outils sont trop souvent restrictifs en termes de possibilités
de stockage et surtout de manière de répertorier les informations collectées. C’est pourquoi de plus
en plus d’entreprise mettent en place un serveur de partage de la connaissance couplé à un moteur
d’indexation et de recherche (serveur de knowledge). Ces outils permettent alors d’indexer le contenu
des documents partagés et d’apporter aux utilisateurs la possibilité d’effectuer des recherches complexes
par utilisation de mots clés permettant de mieux cibler l’information recherchée.
La cartographie des processus

Dans notre « Figure 15 : Les étapes de la formalisation et optimisation», nous avons une phase de
modélisation. Cette phase de modélisation démarre, en général, par une cartographie des processus,
c’est à dire, un inventaire de tous les processus de l’entreprise par famille de processus.
Cette cartographie permettra de dresser la liste exhaustive des processus métiers de l’entreprise pour
identifier les processus « cœur de métier » et processus de « support ».
Par exemple dans une entreprise on pourrait avoir les processus suivants :
Support
P roc es s us Cœur de métier
Pilotage de l'encadrement 
Pilotage de la qualité 
Logistique 
Marketing 
Avant-vente 
Réalisation du produit et/ou service 
Après-vente 
RH 
Comptabilité/Finance 
Figure 53 : Exemple de liste de processus
Dans notre tableau ci-dessus, la classification des processus en processus de support ou cœur de
métier peut être tout à fait contestable en fonction d’éléments contextuels. Par exemple, le pilotage
de l’encadrement est, dans notre exemple, indiqué comme processus cœur de métier. Dans notre cas
on entend le pilotage de l’encadrement dans l’accomplissement de la stratégie de l’entreprise, ce qui
place alors le processus comme processus cœur de métier. Si par contre le pilotage de l’encadrement
était effectué de manière à garantir que les collaborateurs sont correctement suivis dans l’exercice de
leurs fonctions, alors le processus serait catégorisé de processus de « support ». Ce qui ne sera pas sans
blesser quelques âmes sensibles.
Prenons un autre exemple. Une société de services catégoriserait très probablement son processus de
recrutement RH comme un processus cœur de métier, les collaborateurs étant le reflet de la qualité des
services rendus aux clients.
La cartographie va donc non seulement permettre de connaître tous les processus de l’entreprise,
mais également la relation entre ces processus. Elle permettra de définir les priorités des différents
processus.
La conception d’un processus

Dans la discipline du BPM, la phase de conception du processus est la première étape concrète qui consiste
à modéliser un processus métier sélectionné avec soin, d’identifier les besoins clés de ce processus et
de le documenter. La modélisation consiste en une représentation graphique du processus en utilisant
un outil spécialisé. Pour permettre de représenter graphiquement et documenter le processus, il est
nécessaire de se poser un certain nombre de questions initiales :
• Quel événement va déclencher le processus : manuel, applicatif ?
• Quelles sont les tâches au sein de ce processus et quels en sont les enchaînements ?
• Quel est le niveau de granularité des activités (ou tâches) ? Font-elles appel à des sous
processus ou certains enchaînements ne peuvent-ils pas faire l’objet d’un sous processus
réutilisable pour d’autres processus ?
• Quel type d’acteur va effectuer les tâches : profils types définis par liste, applicatifs accédés au
sein du processus.
• Quelles sont les informations (ou données) qui sont nécessaires au bon accomplissement de
l’activité ou de la tâche ?
• Y a-t-il des règles et des calculs à appliquer pour valider des données et si oui y a-t-il
plusieurs types différents d’enchaînements ?
• Quels sont les types d’activités exécutées ? (manuelles, automatiques, semi-automatiques)
• Quels résultats attendus pour les tâches ?

• Quelles sont les données en sortie de chaque tâche ?
• Comment chacune des tâches est elle exécutée ? par quelle condition ou par quelle règle ?
• Doit on gérer une corbeille de tâches et auquel cas certaines d’entre elles ne doivent-elles pas
être regroupées en une seule et unique tâche ?
• Pour chaque tâche, y a-t-il des conditions spéciales, des exceptions ? (fonctionnelles,
techniques) lesquelles ?
• Les tâches ont-elles un temps d’exécution normal ? Y a-t-il un délai à respecter pour chacune
des tâches ou pour tout ou partie du processus ?
• Si les délais d’exécution ne sont pas conformes, y a-t-il des actions à mener ? (alertes, escalade
vers des acteurs, …)
Toutes ces questions doivent obtenir des réponses très précises car faute d’informations, la formalisation
ne pourra avancer et l’implémentation du processus ne pourra débuter.
Il est également nécessaire que les rôles et responsabilités soient clairement identifiés, de manière à bien
identifier qui va pouvoir répondre aux questions. Par exemple, le type d’exception pourra être donné
par un expert fonctionnel du processus, même mieux, un utilisateur de ce processus et qui indiquera
le mode opératoire « macroscopique » à utiliser. Par contre, si l’exception est technique et que la
solution doit alerter un outil de supervision, alors il sera nécessaire de travailler avec les responsables
de l’exploitation pour permettre une bonne intégration avec l’outil de supervision utilisé. Pour ce
qui concerne les éléments clés au niveau des activités et des métriques associées, le « propriétaire du
processus » (process owner) doit être clairement identifié car lui seul est à même de donner toutes les
informations nécessaires permettant de garantir que le processus et ses métriques sont bien en cohérence
avec la stratégie de l’entreprise, que les ressources nécessaires pour exécuter les activités sont identifiées
et que les impératifs vis-à-vis des clients et des partenaires sont bien adressés. Mais ne pas oublier que
les propriétaires des processus ne sont, en général, pas des informaticiens et que par conséquent, il va
falloir parler le même langage qu’eux.
Un autre point important est le niveau de granularité de la conception des processus. On va bien entendu
partir d’un niveau macro pour ensuite descendre dans les détails en passant par le processus, le ou les
sous-processus, les activités et enfin les tâches (si nécessaire).
Processus
Sous -Processus
Activit
Activités
és
TTââcches
hes TTââcches
hes TTââcches
hes TTââcches
hes
Figure 54 : Le Processus et ses composants
De manière générale, il est préférable d’éviter d’avoir plus de 3 niveaux différents, auquel cas, le
processus deviendra trop complexe. Le processus macro est le premier niveau et ne doit pas excéder une
dizaine d’activités. Les activités de ce niveau correspondent à des processus, des sous-processus ou des
activités et on redescend ensuite d’un niveau pour traiter le contenu des tâches unitaires. Les activités
sont composées de tâches à effectuer permettant de les réaliser. Les tâches sont un sous-ensemble des
activités. Dans le cas de solutions de Workflow, nous verrons que nous piloterons des activités mais
également parfois des tâches lorsque celles-ci seront réalisées par des acteurs différents. Dans d’autres
cas, nous resterons au niveau de l’activité de manière à minimiser les impacts en termes de suivi qui
serait rendu trop complexe. Lors de la modélisation des processus, il faudra prendre en compte ce
critère pour identifier le niveau de détail.
La modélisation
La modélisation des processus est certainement l’une des étapes les plus importantes car si la modélisation
et la documentation des processus sont erronées, l’optimisation des processus s’en retrouvera beaucoup
plus complexe à réaliser.
Un autre point important de la modélisation est la représentation commune des processus. Si les équipes
sont internationales, la représentation graphique sera l’élément crucial que tout le monde sera en capacité
de comprendre car indépendant, en grande partie, de la langue aux commentaires près.
Il existe également des outils de modélisation qui comportent des fonctions de simulation. Dans ce cas,
il devient alors possible d’analyser le comportement du processus avant sa mise en œuvre et de valider
certaines hypothèses prises.
Et tout d’abord, pourquoi modéliser ?
Il y a en fait un grand nombre de raisons pour lesquelles il est nécessaire de modéliser les processus
métiers :
• Comprendre et analyser le fonctionnement du processus en l’état : on appelle ce modèle
le modèle « AS-IS »
• Modifier le processus pour en améliorer le fonctionnement : on appelle ce modèle le modèle
« TO-BE » ou le modèle cible
• Analyser le processus avec un outil de simulation de manière à tester la performance du
processus suite à des modifications apportées : On utilise cette technique pour vérifier ce qui
pourrait se passer si … On nomme cette partie le « WHAT IF »
• Avoir la capacité de fournir un modèle du processus au projet d’implémentation. En effet, des
outils pourraient permettre la reprise par importation du modèle métier et ainsi faciliter son
intégration au sein du système d’information
• Identifier les risques de dégradation des performances du processus et comment les éviter
• Appliquer une norme qualité qui peut imposer l’utilisation d’outils de modélisation et de
principes de modélisation pour documenter les processus
• Communiquer. Les modèles sont utilisés à des fins d’outil de communication et d’échanges
avec différents acteurs impliqués dans le processus métier ou avec les équipes chargées de
leur implémentation.
• Apporter les éléments nécessaires pour évaluer les coûts des activités d’un processus et donc du
coût d’un processus dans son ensemble. Il sera alors possible d’utiliser les techniques du
« WHAT IF » pour évaluer l’évolution des coûts d’un processus en fonction de simulations.
La toute première étape consiste à identifier le processus à modéliser et le sélectionner sur des critères
de visibilité, de pertinence par rapport aux clients, etc. Ce processus est en général un processus critique
ou stratégique. La démarche de modélisation va se scinder en deux parties : la partie processus et la
partie interfaces.
Processus
éé
Processus sélectionné
Identification
Identification Collecter
Collecter Diag rammes
des
des les informations et
et RRèg
èg les Exceptions
Exceptions
lectionn activit
activités
és ddétaill
étaill ées Donn
Donn ées
ées
Exceptions
éélectionn
Interfaces
Processus
Processus ss
Identification
Identification Définition
Définition Diag
Diagrammes
rammes Mapping
Mapping
des des
des Et Et
Et
interfaces interfaces
interfaces Donn
Donn ées
ées règ
règles
les
Figure 55 : Processus de modélisation
La modélisation des processus est en fait la phase de formalisation des processus par laquelle on modélise
(dessin) en utilisant une représentation graphique des processus. Il existe plusieurs représentations

possibles comme l’UML (Unified Modeling Language) et le BPMN (Business Process Modeling Notation)
qui sont tous deux les plus utilisés pour la représentation des processus métiers. Le premier n’était,
à la base, pas très adapté à la modélisation des processus alors que le BPMN a été conçu pour cela.
Au fur et à mesure, ces représentations ont évolué et permettent d’avoir des représentations simples
à comprendre. Il est vrai que l’arrivée de la représentation BPMN et de ses dernières évolutions rend
celle-ci la plus adaptée au Business Process Management.
Organisation
Organisation
Donn
Donn Processus
Processus
Fonctions
Fonctions
Données
Fonctions
Processus
éé
es
es
Outil
Outil BPM
BPM
Figure 56 : La fusée à 3 étages
Dans le cadre de la formalisation des processus, on part souvent de l’organisation et c’est celle-ci qui
permettra de les identifier ainsi que toutes les fonctions et données associées. Ces éléments permettront de
formaliser toutes les interfaces que celles-ci soient humaines ou informatiques. Une fois la documentation
effectuée, on pourra identifier plus facilement la mise en œuvre du suivi, ainsi que l’intégration des
processus à l’aide d’un outil de BPM.
L’organisation
L’organisation est primordiale dans le fonctionnement des processus et celle-ci doit être correctement
identifiée. Un organigramme complet est dressé de manière à prendre correctement en compte cette
organisation. Certains outils de BPM permettent d’intégrer l’organisation afin d’identifier tous les rôles
nécessaires à l’exécution du processus de bout en bout. Avoir la capacité à modéliser l’organisation est
très certainement un plus. De plus en plus d’outils permettent la modélisation de cette organisation
apportant parfois jusqu’à la création des rôles, fonctions, groupes. Cela permet ainsi de faciliter la
création ultérieure des utilisateurs et leur affectation à des rôles et groupes.
L’organigramme va également permettre de comprendre comment l’entreprise fonctionne et quels

utilisateurs sont impliqués au sein des processus. Toutes les relations seront mises en évidence.
Le processus et ses exceptions
Le processus à formaliser comprend des éléments qui lui permettent de fonctionner et de

traiter ses cas de dysfonctionnement. On peut identifier 6 étapes qui permettent de le définir.
1. L’identification des activités permet de découper le processus en activités élémentaires. Toutes ces
activités permettent une exécution du processus de bout en bout. Pour comprendre le fonctionnement
des activités et/ou tâches, on doit identifier les tâches manuelles des tâches systèmes.
2. La Collecte des informations détaillées nécessite souvent de passer par des interviews pour récupérer
toutes les informations nécessaires aux activités (données, critères de décision, qualification d’un client,
règles, cas spécifiques, procédures d’escalade, indicateurs de qualité, etc.). Ces informations permettront
ensuite de documenter le processus dans son ensemble.
3. Les Diagrammes et données : Pour apporter une première vision du processus, on prépare un
diagramme de fonctionnement de celui-ci. Ces diagrammes sont dessinés à partir d’un outil de modélisation.
Ensuite les données principales sont identifiées, en particulier, toutes les données permettant de qualifier
et quantifier les instances de processus. Ces indicateurs permettent à un concepteur de processus de
lister ensuite les données détaillées et nécessaires au bon fonctionnement du processus sélectionné.
4. Les Règles : elles doivent être clairement identifiées et sont listées de manière à valider les valeurs
possibles et les actions à appliquer par rapport à la valeur identifiée. Certains outils permettent de séparer
les règles des activités, laissant ainsi la possibilité future de modifier les règles sans avoir à modifier le
processus et par voie de conséquence, de limiter les efforts en termes d’évolution et de déploiement.
5. Les exceptions : Toutes les procédures d’exceptions doivent également être identifiées. Ces règles
permettent de contrôler le comportement du processus et ce, en fonction des valeurs de retour des
activités, de codes d’erreurs capturés par la solution de BPM ou encore, d’actions utilisateurs menées.
On peut alors envisager des procédures de compensation automatiques ou la redirection des tâches vers
une corbeille permettant à un administrateur ou superviseur de lancer des actions qui sont fonction
des données et codes présentés.
6. Les acteurs : Les acteurs des processus sont les utilisateurs ou systèmes qui sont responsables pour
une activité ou un processus tout entier. C’est à ce moment que l’on peut identifier les processus mono
acteur ou multi acteurs. Ces acteurs appartiennent à des rôles ou groupes d’utilisateurs permettant de
garantir que les activités seront traitées. Bien souvent on couple ces fonctions de transmission d’activités
à une gestion de calendrier qui pourrait indiquer la disponibilité des acteurs, y compris les périodes où
ceux-ci sont en congés, par exemple.
Les fonctions
Les fonctions permettent d’identifier des activités/tâches. Dans notre cas, nous parlons de fonctions
du système d’information. Ces fonctions permettent de rendre un service au métier et c’est d’un point
de vue purement fonctionnel que les fonctions seront identifiées et documentées. Les entrées/sorties
seront également à décrire.
Les données
Les données importantes au processus sont identifiées au niveau métier, mais également au niveau du
SI. Il est important de valider la disponibilité des informations nécessaires au métier. Dans certains
cas, les applications pourront mettre à disposition ces données. Dans d’autres cas, il faudra déduire
les données à partir d’autres données. Pour finir, certains cas nécessiteront des évolutions applicatives
permettant de disposer des données nécessaires.
La sémantique est un point important et on doit valider le contenu exact des données demandées et
pourquoi elles sont utilisées. La question du pourquoi permettra souvent de justifier ou non la mise à
disposition des données ainsi demandées.
Pour terminer, les types de données devront également être indiqués (chaîne de caractères, date, …).
L’outil de BPM
L’outil de BPM ne fait qu’apporter la possibilité d’intégrer et de piloter les processus. Il arrive que l’outil
impose la manière de travailler. Certains exemples de projets ont démontré des résultats mitigés ; les
méthodes de travail ayant été bouleversées et les acteurs des processus n’ayant pas été impliqués. L’outil
doit être choisi en fonction des méthodes de travail d’une part, mais également en fonction des besoins
réels qui seront tournés vers les processus humains, les processus d’intégration, les processus faisant
appel à des règles métiers très complexes ou tout autre type de processus.
La représentation UML
Le langage UML ; Unified Modeling Language ; est un langage de notation orienté objet qui a été créé par
Rational Software (maintenant IBM Software) et l’OMG(*). Il est principalement utilisé pour modéliser,
concevoir, implémenter et documenter un logiciel.
A la base, UML accompagne une approche objet. Cette notion d’objet défini à la fois des informations
comme les données ou les attributs ainsi que leurs comportements comme, par exemple des traitements,
méthodes ou opérations.
(*) voir glossaire

page 192

Nom Mac
Machine
hine àà la
laver
ver
Mod èle
Modèle
Attributs NN um éro de ss érie
um éro de érie
PPoids
oids de
de linge
linge la
lavable
vable
N
Nombre
ombre de
de programmes
programmes
LL aaver()
ver()
Fonctions RR inc
incer()
er()
EE ss ss orer()
orer()
Figure 57 : Représentation objet UML
Un objet en UML est composé d’un nom, d’attributs et de fonctions. L’exemple ci-dessus donne un
exemple pour une machine à laver qui comporte des attributs (ou des caractéristiques) pour finalement
apporter des fonctionnalités précises à l’utilisateur comme laver, rincer ou essorer.
Ce langage est aujourd’hui un standard. Nous n’allons pas entrer dans les détails, des ouvrages complets
existants déjà sur le sujet.
Ce standard de modélisation et de description regroupe différents types de diagrammes comme :

• Le diagramme de cas d’utilisation – « Use Case » : Ce diagramme décrit le comportement du
logiciel d’un point de vue utilisateur,
• Le diagramme de classes – « Class diagram» : Ce diagramme décrit les classes qui
interviennent dans le système,
• Le diagramme d’objets – « Object diagram » sert à décrire les instances de classes qui sont
utilisées dans le système,
• Le diagramme de composants – « Component diagram ». Ce diagramme permet de montrer
les composants physiques du système,
• Le diagramme de déploiement – « Deployment diagram » permet de représenter tous les
composants, leur répartition sur les composants physiques ainsi que leurs interactions,
• Le diagramme des paquetages – « Package diagram » permet de créer une vue logique
permettant de regrouper des éléments dans un modèle UML. Ce diagramme permet de
représenter les dépendances entre des paquetages différents,
• Le diagramme de structure composite – « Composite structure diagram » permet de décrire
les relations entre les composants d’une classe de manière à les présenter sous forme d’une
structure. On peut appeler cette structure une structure blanche(*),
• Le diagramme états-transitions – « State machine diagram ». Ce diagramme permet de
décrire sous forme de machine à états le comportement du système et/ou de ses composants,
• Le diagramme d’activité – « Activity diagram ». Avec ce diagramme, on décrit sous la forme de
flux ou d’enchaînements le comportement du système et/ou de ses composants,
• Le diagramme de séquence – « Sequence Diagram » permet de représenter séquentiellement le
déroulement des traitements et des interactions entre les composants du système. On utilise
assez souvent ce diagramme pour représenter le flux séquentiel entre des applications du
système par exemple,
• Le diagramme de communication – « Communication diagram ». Ce diagramme est une
version allégée du diagramme de séquence. On se limite aux messages échangés entre objects ou
composants du système,
• Le diagramme global d’interaction – « Interaction Overview Diagram » permet de décrire
les enchaînements possibles entre différents scénarii. Ces différents scénarii ont été
préalablement modélisés sous forme de diagrammes de séquence,
• Le Diagramme de temps – « Timing diagram » permet de décrire la variation d’une donnée
dans le temps (notion de cycle de vie).
Le diagramme le plus utilisé mais également le plus facilement transposable à un contexte processus, est
le diagramme d’activité. Ce qui est important, au niveau de la modélisation, c’est le fait d’apporter un
modèle qui soit facilement lisible. C’est le cas du diagramme d’activité. De plus, ce diagramme permet (*) voir glossaire
d’identifier les différents participants des activités. page 192
Par expérience, les diagrammes UML sont peu utilisés par les métiers. Ils préfèrent utiliser des outils
plus simples et avec lesquels, ils ont l’habitude de travailler.
La représentation BPMN
Le BPMN (Business Process Modeling Notation) est un modèle de notation permettant de décrire les
processus métier et qui se veut être compréhensible par tous (analystes métier et experts techniques).
Il permet d’implémenter plus facilement les processus au sein d’une solution logicielle.
Un diagramme contient des objets graphiques qui vont permettre de modéliser les activités, les flux, les
relations, les données des processus, leurs interactions, etc. Ce mode de formalisation des processus est
couramment utilisé. La spécification de cette notation est disponible gracieusement auprès de l’OMG.
Il est important de comprendre que ce n’est pas seulement un autre mode de représentation des processus
métiers, mais également un moyen de garantir un bon niveau d’accostage entre les différentes couches
de l’urbanisme (métier, fonctions, applications et infrastructure). De plus, le BPMN a été conçu pour
permettre une transcription vers des langages d’exécution des processus comme le BPML (Business
Process Modeling Language) ou le BPEL (Business Process Execution Language) ou pour finir son dérivé
SOA : BPEL4WS (Business Process Execution Language for Web Services). Pour finir, le BPMN a toutes
les fonctions qui peuvent être nécessaires de manière à garantir une bonne correspondance vers les
langages d’exécution alors que le langage UML est dépourvu de cette correspondance. On comprend
pourquoi ce langage a été conçu même ci celui-ci a mis du temps pour être à un niveau utilisable par
les solutions logicielles du marché. Le BPMN est aujourd’hui de plus en plus utilisé dans le domaine
de l’« Enterprise Architecture » et de la modélisation de processus. Un des autres objectifs du BPMN
est de vouloir unifier en une unique représentation des notations qui étaient utilisées auparavant
pour modéliser des processus, effectuer des simulations de processus, de définir des « Workflow »
d’activités ou de tâches manuelles, de modéliser des processus d’échanges internes (A2A : Application
To Application) et externes (B2B : Business To Business).
Enfin, le BPMN a introduit en particulier la notion de message et de flux qui étaient jusqu’à maintenant
absente des langages de notation des processus. Cette notation apporte la possibilité de mixer processus
humains et processus automatisés de manière à refléter la réalité des processus d’une entreprise.
Pour en revenir à l’objectif de cette notation, il était important de catégoriser les principaux objets en :
• Flux (ou des messages entre des objets)
• Liens
• « Swimlanes » ou couloirs (on peut faire une analogie aux couloirs de natation dans une
piscine olympique).
• « Artifacts » : des objets créés, modifiés ou utilisés par des personnes.
Tous les objets proposés au sein de la norme de notation ont été conçus pour ne permettre aucune
ambiguïté quant à l’interprétation du fonctionnement du processus et de ses activités et/ou tâches.
Ci-après, nous montrons une partie de la palette d’objets proposée dans le cadre de la notation
BPMN :
+ + ~+ ~ +
The height of the text box

and its associated line
increases or decreases as
you add text . To change the
width of the comment , drag
the side handle .
Figure 58 : Des objets disponibles de la notation BPMN

La notation est de plus en plus utilisée par les outils de pure modélisation mais également par les outils
de BPM.
Elle est prévue pour permettre de lier les travaux de différentes populations de l’entreprise : métier,
MOA, MOE.
Source BPMI.ORG
Figure 59 : Gestion de la chaîne des utilisateurs
Parmi cette population, nous pouvons citer :

• Les consultants en stratégie
• Les analystes métiers
• Les concepteurs de processus
• Les architectes de systèmes
• Les ingénieurs en génie logiciel.
Les outils doivent également proposer un pont permettant, à partir de la modélisation BPMN, d’obtenir
un fichier BPEL utilisable au sein de la solution de BPM. Ceci est de plus en plus le cas.
Les représentations spécifiques

Il existe d’autres représentations graphiques. La plupart d’entre-elles proviennent d’éditeurs d’outils
de modélisation spécialisés.
Il est vrai que bon nombre de ces outils sont très présents dans les entreprises du fait de leur facilité
d’utilisation par des utilisateurs métiers. Le problème a toujours résidé en la possibilité de passer d’un
modèle créé par un utilisateur métier à un modèle compréhensible et intégrable au sein d’un outil de
BPM du système informatique. C’est pourquoi, les outils de BPMS apportent, en théorie, toutes les
fonctionnalités permettant de modéliser puis d’intégrer les processus. On trouvera également des outils,
pauvres en modélisation, qui apporteront des ponts d’outils de modélisation très courants comme
Microsoft Visio vers leurs outils d’intégration des processus. Ce peut être un moyen simple mais efficace
de palier au problème d’accostage métier/technologie.
La documentation
La documentation est ce qui permettra à différents acteurs de comprendre le fonctionnement du
processus, des activités et des tâches. Elle doit comprendre un certain nombre d’éléments comme :
• Son modèle
• Sa fiche d’identité
• Son descriptif détaillé
Pour le modèle des processus, nous n’allons pas y revenir, mais il fait partie de son dossier de
documentation.
La fiche d’identité d’un processus
Une fiche d’identité d’un processus doit comprendre un certain nombre d’informations comme :
• Le nom du processus
• Sa date de création ou de modification de la fiche
• Le nom de la personne qui a créé la fiche
• Le descriptif de l’objectif du processus
• Le descriptif de la finalité du processus
• Les principales données en entrée et en sortie
• Les indicateurs principaux permettant de mesurer la qualité du processus ainsi que la fréquence
et le type d’indicateur mesuré (qualité ou performance)
• Les améliorations possibles du processus
• Le nom du « Process Owner » (propriétaire du processus).
• Le descriptif des principales activités voire des tâches importantes
• La liste des risques potentiels pour que le processus se dégrade et les dysfonctionnements
possibles associés.
Le descriptif détaillé
Lors de la description détaillée, il est nécessaire d’identifier toutes les caractéristiques du processus.
Les facteurs ayant une influence sur un processus peuvent être par exemple, une distance, un coût, un
délai, une taille, etc. Pour correctement décrire le processus, il faut décrire la nature exacte des activités
ou des tâches unitaires quand cela est nécessaire et :
• d’aborder les notions de temps et de délais des activités et du processus de bout en bout,
• d’identifier les documents qui y seront rattachés,
• de lister les données nécessaires aux activités mais également au pilotage du processus,
• etc.
Il est également nécessaire de décrire l’organisation permettant de traiter les activités et identifier la
volumétrie des instances des processus avec le niveau de performance attendu.
La nature des activités
L’identification de la nature des différentes activités à conduire pour que le processus puisse s’exécuter
dans son ensemble devra être faite. Il est vrai que le niveau de détail de la documentation et de l’analyse
du processus dépend l’objectif du projet. Une activité du type « saisie des informations client » peut
être suffisante. Dans d’autres cas, on aura besoin d’indiquer que la saisie est relative à la saisie d’une
commande d’une nappe ovale de 2m x 1m par exemple. On peut affiner l’activité en indiquant qu’il
s’agit de la saisie d’une nouvelle commande, d’une résiliation, d’un complément à une commande
existante, etc. résultant en des fonctions de type création, mise à jour ou suppression.
La notion de temps
Le processus doit s’exécuter dans un certain délai qui sera plus ou moins long. Il est possible d’avoir
besoin de spécifier qu’un processus, voire une activité, doive se dérouler en un certain temps (en
secondes par exemple) et que passé ce délai, une alerte soit remontée ou que l’activité ou la tâche
suivante puisse être lancée. On peut également avoir des interdépendances entre des activités et que
sous un certain délai certaines activités liées ne peuvent être exécutées avant d’autres. Prenons l’exemple
de la souscription d’un crédit à la consommation. Lorsqu’un client souscrit un crédit, celui-ci a un délai
de rétractation de 7 jours. On peut envisager de mettre un minuteur sur une activité et que pour que
cette activité soit dans un état « terminée », il est nécessaire que le client se rétracte et à ce moment
une action est effectuée ou que le délai de rétractation soit dépassé et que la procédure de déblocage
des fonds soit alors lancée.
La notion de temps et de délai peut être utilisée de plusieurs manières.

Les documents attachés
Une activité peut également avoir des documents attachés. Par exemple, on pourrait avoir une copie du
contrat de souscription, mais également tout support en relation directe avec l’activité. Les documents
peuvent être :
• des formulaires,
• des listes,
• des graphiques,
• des éléments multimédia,
• etc.
Ils peuvent faciliter les prises de décisions. Il est néanmoins nécessaire de prêter attention à la taille des
documents car ceux-ci peuvent entraîner des dégradations de performances.
Les données
Chaque processus a des données qui lui sont propres. Ces données sont des données d’entrée ou de
sortie. Ensuite chaque processus comporte des activités. Elles véhiculent également des données leur
permettant de produire le résultat attendu en sortie.
Maintenant, d’autres données doivent être également identifiées comme les données qualitatives du
processus ou des activités permettant de piloter sa qualité d’exécution.
Processus
A2
A1 A3 A5
A4
Figure 60 : Des données à tous les niveaux
Par exemple, une instance de notre processus ci-dessus aura des données attachées aux activités A1, A2
et A5 qui pourront quantifier la qualité de l’exécution de ces activités. Le délai d’exécution de A1 à A5
peut également faire partie des indicateurs calculés. Par ces données, on pourra connaître également le
nombre de fois que le processus aura choisi de passer par les activités A2, A3 et A4.
Toutes les données à identifier le sont sur un point de vue métier uniquement. Le point de vue système
se fera ultérieurement.
Il faut prêter attention au nombre de données utilisées. Plus elles sont nombreuses, plus les risques qui
pèsent sur les performances sont importants.
L’organisation
Le processus fait appel à des membres d’une ou plusieurs organisations (internes ou externes) permettant
de réaliser les activités des processus de bout en bout. Le descriptif de cette organisation va consister
en une identification des rôles et responsabilités d’acteurs de ces processus et en une documentation de
l’organisation du travail de chacun de ces acteurs. Les acteurs vers qui des exceptions seront escaladées
seront également à décrire (l’exploitant par exemple).
Il est probable que lors de la description des processus tel qu’ils devront être (le TO-BE), on identifie
que certains acteurs sont manquants. Dans ce cas, des fiches seront créées de manière à décrire le profil
type avec les rôles et responsabilités associés.
Certains outils de modélisation voire de BPM permettront de modéliser l’organisation et parfois même,
d’intégrer cet organigramme directement au sein d’une solution d’annuaire ou de gestion d’identité.
Processus courts ou processus longs ?
La nature des processus permettra d’identifier la durée de vie de ces instances. On parle alors de
processus courts ou de processus longs. Les processus courts ont un délai d’exécution de bout en bout
qui peut aller jusqu’à quelques dizaines de minutes. Les processus longs peuvent se placer en veille
d’un événement qui peut survenir quelques jours, semaines, mois après que l’instance ait été créée.
Ces éléments sont primordiaux dans le calcul de la durée de stockage des informations relatives aux
instances de processus et à la taille réservée aux bases de données associées.
La fréquence, volumétrie et disponibilité
Pour terminer, la fréquence des processus et leur volumétrie sont importants pour définir les besoins
en ressources des processus. Ces ressources nécessaires pourront être soit des acteurs de ces processus,
soit des ressources système. Par exemple, on pourra déterminer le nombre d’acteurs nécessaires pour
traiter 1000 demandes d’informations clients par heure. Cette information permettra également,
en fonction du volume des données véhiculées par le processus, de définir les ressources système
nécessaires permettant de garantir un traitement dans des délais acceptables. Le niveau de disponibilité
nécessaire du système est important pour les processus les plus critiques. On peut très bien avoir
besoin d’une disponibilité du système 24h sur 24 et 7 jours sur 7 et avoir un niveau de qualité de
service du SI très conséquent (95 % voire plus).
Tous ces éléments sont importants pour définir l’organisation qui sera fonction des volumes à traiter.
La capacité des outils aura également un impact sur la disponibilité du système. L’expérience a souvent
démontré que l’insatisfaction des utilisateurs est bien souvent due à une sous-estimation de tous ces éléments.
Ne pas oublier non plus que ces éléments sont complexes à collecter et vont nécessiter du temps pour en
avoir une vision assez exhaustive. La charge induite pour cette collecte est bien souvent mésestimée.
Le niveau de détail de la documentation
Du niveau des lecteurs des documents dépend le niveau de détail proposé dans la documentation. Il ne
sera pas rare d’avoir un premier niveau pour une population de lecteurs métiers et un second niveau
pour une population de lecteurs fonctionnels, voire techniques.
Un autre point important concerne l’utilisation de termes simples. Les lecteurs peuvent être novices.
Donc les noyer dans des détails ou termes complexes ne sert à rien. D’autre part, il est toujours important
de laisser une certaine latitude dans la façon d’implémenter le processus. Il faut laisser de la place à la
créativité tout en étant certain que les contraintes sont effectivement bien connues.
Dernier point : le formalisme utilisé. Il vaut mieux utiliser un bon schéma ou diagramme plutôt que
de la mauvaise prose. Les mots peuvent être interprétés de différentes manières. Il est donc important,
de rester clair dans la manière de décrire le processus, quitte à intégrer un glossaire pour être certain
de la bonne interprétation des termes employés. Ce glossaire est très efficace lorsqu’il est créé avec le
concours de tous les acteurs.
L’analyse et optimisation
(*) voir glossaire L’analyse (ou le BPA(*)) est l’étape permettant de comprendre le fonctionnement du processus, mais
page 192 également d’identifier ses défauts. Le fait de procéder à une analyse peut être assimilé à un audit ou

diagnostic du processus. On va étudier le processus, ses acteurs, ses activités et ce, en se basant sur
sa documentation. Une première analyse alors réalisée, on va affiner, discuter, chercher pourquoi le
processus fonctionne de cette manière. Ces discussions se feront avec les acteurs des processus et, si
possible, leurs responsables.
Des « ateliers » permettront de décrire les conclusions du fonctionnement du processus tel qu’il est
dans la réalité.
Lors de l’analyse du processus ont doit pouvoir identifier des critères permettant de qualifier et quantifier
le fonctionnement du processus, comme :
• L’efficacité de la gestion de l’information
• Le cycle de vie du processus et son délai global d’exécution
• Le lien entre certaines activités du processus, voire les interdépendances entre certains
processus ou activités
• La façon dont sont réalisées les activités et les tâches
• L’existence de tâches dupliquées
• Les moyens de contrôle de la qualité d’exécution des processus et des tâches
• Les opportunités de standardiser certaines tâches
• L’efficacité et l’implication des acteurs réalisant les activités
• Les moyens utilisés pour transférer certaines activités
L’analyse se réalise, bien souvent, par itération.
On procède alors comme suit :

• prendre le processus à analyser en étudiant son modèle et au besoin, en le faisant évoluer
• effectuer son analyse détaillée et identifier des scénarii possibles
• choisir le scénario en se servant de critères identifiés
• modifier le modèle et la documentation associée
• faire implémenter la nouvelle version du processus
L’analyse est d’autant plus facile que le processus a déjà été utilisé et que nous avons des données de
production accessibles et utilisables pour analyser en détail son comportement. On pourra simuler les
différents scénarii identifiés pour faciliter le choix de celui qui paraît le plus opportun.
Les axes d’amélioration portent sur des dysfonctionnements constatés du processus et dont les causes
peuvent être variées, comme :
• de la non qualité
• les types d’anomalies
• les insatisfactions des bénéficiaires des processus
• les évolutions d’indicateurs (comme les coûts et les délais)
• la fréquence des anomalies
• les délais d’exécution du processus
• la non-conformité à des attentes extérieures (clients ou partenaires)
Mod é lis ation
Analy s e
Am élioration
Mis e en oeuvre
Figure 61 : Cycle macroscopique de l’analyse et optimisation
Avant la mise en œuvre des actions portant sur l’optimisation du processus, on identifie les impacts de
ces actions. Nous verrons d’ailleurs, que la mise en place de certains patrons (ou patterns) de processus
pourront aider à palier aux dysfonctionnements du processus.
Un exemple simple serait de prendre un processus avec 3 activités : A1, A2 et A3. Ces 3 activités
s’exécutent en séquence. Une optimisation simple pourrait consister en un parallélisme des activités
A2 et A3 (sous réserve que cela puisse être possible, bien entendu).
A1 A2 A3
A2
A1
A3
Figure 62 : Exemple d’optimisation
Pour savoir alors si l’optimisation est envisageable, on effectue l’analyse d’impacts à plusieurs
niveaux :
• Au niveau de l’organisation
• Au niveau des développements, de la maintenance, de l’exploitation, etc.
• Au niveau du système d’information et des infrastructures associées
• Au niveau financier
L’expérience a souvent démontré que de se baser sur des patterns permettait d’identifier un plus grand
nombre de possibilités d’optimisation. Par contre, il faudra identifier tous les risques associés à chacun
des scénarii de manière à minimiser les impacts et faciliter la mise en œuvre de l’optimisation. On
dressera d’ailleurs un plan d’action permettant de palier aux risques identifiés.
Bien souvent, et c’est le cas de Six sigma, on utilisera une expérimentation pour fiabiliser les résultats
attendus de l’optimisation du processus. D’un point de vue système, on peut avoir des impacts au
niveau des interfaces voire même des applications métiers utilisées. Ces impacts peuvent être importants
notamment en termes de coût. Des alternatives peuvent être envisagées et les coûts comparés.
Pour terminer, les modifications apportées à un processus peuvent avoir des impacts sur la façon de
travailler des acteurs de ces processus. Il est donc important de prévoir la mise en place d’une conduite
du changement appropriée et en adéquation avec l’ampleur des modifications apportées au processus.
Les modifications apportées peuvent également nécessiter des mises à jours des compétences des acteurs.
De manière générale, on ne va mettre en œuvre que les optimisations qui comportent des modifications
acceptables. Tout dépendra du niveau de modification acceptable identifié.
Analyse
Analyse des
des processus
processus
BPO
BPO Optimisation
Figure 63 : Les 2 objectifs de l’analyse

L’analyse des processus permet d’optimiser le ou les processus, mais permet également l’externalisation
de tout ou partie de processus. On parle alors de Business Process Outsourcing : BPO.
On voit aujourd’hui, une augmentation significative de l’externalisation de processus administratifs

vers des sociétés spécialisées.
Le benchmarking de processus
Le benchmarking(*) de processus a pour principal objectif de comparer le niveau de performance
d’un processus par rapport à des processus internes ou externes pour en permettre une amélioration
significative à court terme et de valider que son processus est au minimum équivalent aux standards
du marché. On dit que le benchmarking de processus permet de comparer diverses entreprises entre
elles et ainsi identifier des bonnes pratiques performantes.
Cette comparaison se fait :
• Entre processus internes à l’entreprise
• De manière concurrentielle
• De manière générique
Pour cela, on doit procéder à l’analyse de son processus. Ensuite on effectue un comparatif du processus
entre des entreprises de son secteur, en dehors de son secteur, dans son pays ou à l’international.
Pour effectuer ce benchmarking de manière efficace, on doit :
• se reposer sur un réseau apportant des éléments de comparaisons d’autres entreprises et pour
celles qu’ils l’acceptent, un point de contact avec qui dialoguer sur les bonnes pratiques qui
ont permis des améliorations significatives
• se construire une base de données regroupant des bonnes pratiques et des experts capables
de commenter les raisons des implémentations sélectionnées
• disposer d’outils permettant d’évaluer les besoins internes ou externes
Les différents types de benchmarking utilisés dépendent des possibilités offertes à l’entreprise et de
ses besoins :
• Le benchmarking générique : On utilise ce type de comparaison quand une entreprise
concurrente n’existe pas ou quand il est impossible de la comparer. On l’utilise également
lorsqu’un changement radical est nécessaire.
• Le benchmarking interne : Ce type de comparatif est utilisé quand des services équivalents
existent au sein d’une même entreprise. Par exemple entre des centres d’appels ou entre des
centres de développements de logiciels.
• Le benchmarking externe : Ce type de comparaison permet de comparer l’entreprise à ses
pairs et permet, par l’utilisation de bonnes pratiques extérieures, d’apporter de l’innovation.
• Le benchmarking international : Ce type de benchmarking permet de comparer avec des
entreprises à l’international sur des secteurs identiques ou différents mais comportant des
similitudes. Cela permet également de comparer ses bonnes pratiques avec celles liées à la
culture ou à la réglementation d’un pays.
Bien entendu, le fait de faire du benchmarking a un coût et les bonnes pratiques doivent être remises
à jour régulièrement, mais les bénéfices sont de toutes sortes, comme :
• Augmenter les profits
• Améliorer l’efficacité
• Apporter une vision de ce qui se fait ailleurs
• Participer à la satisfaction client
Finalement, le benchmarking est peu pratiqué mais se répand de plus en plus. On commence à voir
des associations spécialisées qui prônent le benchmarking de processus et proposent des rencontres
entre des entreprises de même secteur ou de secteurs différents.
(*) voir glossaire

page 192
L’architecture des processus
Tout d’abord, pourquoi de l’architecture alors que nous sommes en phase de modélisation et/ou d’analyse
du processus ? Tout simplement parce que le modèle a un impact sur l’architecture dès le moment où
nous ne sommes plus au niveau macroscopique.
L’architecture des processus consiste en leur conception structurelle de manière à ce que les entrées
soient transformées en sorties en passant par toute une série d’activités.
D’expérience, le plus complexe sera le découpage des processus en sous-processus de manière à en

assurer un bon niveau de réutilisation et ensuite des sous-processus en activités. La multitude des
activités peut rendre complexe la mise en œuvre d’un processus. Si les processus doivent être intégrés
à l’aide d’une solution de BPMS, mieux vaut se garantir que les patterns de processus pourront être
supportés tout en proposant des niveaux de performances suffisants.
Autre point : les performances. La manière dont est conçu le processus pourra dépendre le niveau de
performance associé. Dans certains cas, il sera nécessaire de revoir le découpage, y compris de certaines
activités, de manière à assurer un bon niveau de performances.
Par ailleurs, les processus devront être pilotés. Pour ce faire, les indicateurs de pilotage doivent être
identifiés. Véhiculer trop d’indicateurs peut être une source de performances médiocres.
Il faut également identifier les sous-processus automatisés. Certains processus pourront effectivement
faire appel à des sous-processus automatisés et ceux-ci devront être performants de manière à ne pas
dégrader les performances globales du processus. Le système devra supporter la charge demandée. La
traçabilité du sous-processus automatisé pourrait également être source de mauvaises performances.
Trop de traces ralentit un processus. Donc prudence lors de l’utilisation de ces traces.
Pour ce qui concerne les tâches gérées dans des corbeilles, il faut veiller à ce que celles-ci ne soit pas
d’un niveau trop fin, ce qui impliquerait la création d’un trop grand nombre de tâches. On regroupe
pour cela les tâches au sein d’activités qui sont réalisées par une seule et même personne.
Processus automatis é
A6
A5 D2 A8
A7
A2
A1 D1 A4
A3
Corbeille de tâches
A9
Figure 64 : Processus comprenant des sous processus
Il existe des démarches ou méthodes permettant de définir l’architecture de processus. Parmi ces
méthodologies ou cadres méthodologiques, on peut citer une discipline nommée l’ « Enterprise
Architecture » et qui est semblable à de l’urbanisme. Il existe des cadres méthodologiques comme
TOGAF(*) par exemple.
(*) voir glossaire L’ « Enterprise Architecture » concerne l’analyse et la documentation d’une entreprise dans son état
page 192 actuel et futur. Cette discipline propose des méthodes et frameworks pour décrire l’état actuel et futur
des processus métiers, du système d’information et de l’organisation de manière à mieux les aligner avec
les objectifs stratégiques de l’entreprise. L’objectif principal de cette discipline est vraiment de mieux
optimiser le fonctionnement de l’entreprise de manière à la rendre plus efficiente.
4 catégories sont distinguées dans la pratique de l’Enterprise Architecture et permettent de

documenter :
• L’architecture métier : Stratégie métier, gouvernance de l’entreprise, organisation et principaux
processus métiers, les cycles (ventes, produits, …), les fournisseurs de matériels, logiciels
et services, …
• L’architecture des données : méta-données et modèles de données (conceptuel, logique
et physique).
• L’architecture applicative : Cartographie applicative, interfaces entre les applications avec tous
les flux et événements.
• L’architecture technologique : tout ce qui concerne les infrastructures, les réseaux internes et
externes, les systèmes d’exploitation ainsi que les infrastructures logicielles comme les
serveurs d’applications, les bases de données, etc.
M
é
tier
Métier
Technique Enterprise
Enterprise Architecture
Architecture Applications
Information
Information
Figure 65 : Les 4 catégories de l’Enterprise Architecture
La gestion des processus peut utiliser des principes d’Enterprise Architecture liés à des méthodes
d’amélioration de la qualité et de la performance des processus, ce à quoi l’Enterprise Architecture
n’apporte pas de réponse et n’est d’ailleurs pas son objectif principal.
Il existe d’ailleurs des frameworks d’architecture comme :

• Zachman : framework en 6 couches basées sur des questionnements comme :
Quoi, Comment, Où, Qui, Quand et Pourquoi
• DODAF : Framework du département de la Défense aux Etats-Unis
• MODAF : Framework du département de la Défense en Grande-Bretagne
• TOGAF : Framework de l’Open Group
• TEAF : Framework du Trésor aux Etats-Unis
• Et bien d’autres …
Certains frameworks sont bien reconnus comme l’Integrated Architecture Framework (IAF) de Capgemini
ou l’Agile Enterprise Architecture de Hewlett Packard. La plupart de ces frameworks sont même certifiés
par l’Open Group (TOGAF, IAF, AEA de Hewlett Packard).
L’implémentation
L’implémentation des processus doit permettre une approche via un socle. Ce socle devra permettre le
déploiement ultérieur des processus de manière industrialisée. Bien entendu, la productivité pour la
mise en œuvre des processus est dépendante de la productivité proposée par l’outil de BPMS.
Par contre et pour ne pas perdre de la nature des processus modélisés, il est fortement conseillé soit
d’utiliser l’outil de BPMS pour modéliser les processus, soit d’utiliser un outil spécifique à la modélisation
et de s’assurer que des ponts sont possibles entre l’outil de modélisation et l’outil de BPMS (notion
d’accostage).
Reengineering ou amélioration de processus ?

Le reengineering des processus métiers (BPR) est l’une des disciplines les plus anciennes. Elle a vu le
jour dans les années 1920 quand bon nombre d’entreprises ont modifié leur façon de travailler pour
être plus efficace plus rapidement. Bien plus tard les concepts du reengineering ont été repris avec
comme concept de base que les processus cibles étaient voués à être cassés et complètement reconstruits.
Malheureusement et faute de bonnes méthodes, la plupart des projets de reengineering des processus
ont été des échecs sanglants (près de 75 % d’entre eux n’ont pas abouti). Beaucoup d’exemples passés
ont démontré que les processus ont été refaits entièrement ainsi que le système d’information associé.
Une nouvelle organisation a été mise en place et le projet a été construit autour de ce nouveau système.
Ce qui a conduit à des projets pharaoniques. Pourtant des méthodes qualité telles que TQM avaient
déjà vu le jour et parlaient d’amélioration continue des processus métiers, si ce n’est que les outils
permettant d’accompagner la démarche n’étaient alors pas suffisamment matures. Ni le BPR ni TQM
n’ont pu s’affirmer. Sa cousine, Six Sigma, avait elle aussi déjà fait ses preuves notamment chez Motorola.
Il fallait laisser du temps pour avoir les premiers retours d’expérience et probablement adapter les
méthodes à un contexte particulier.
Par analyse à posteriori, on constate plusieurs choses à propos du BPR :

• pas de méthodologie associée,
• pas de limitation des risques en simulant les processus avant de les utiliser,
• peu de validation avec les utilisateurs pour vérifier l’adéquation avec les besoins,
• pas d’accompagnement du changement lors de la mise en place des processus en environnement réel,
• pas ou peu d’outillage pour accompagner la démarche.
Bien entendu, tous ces points ne font pas que tout du Business Process Reengineering soit à proscrire.
Aujourd’hui et avec la maturité de méthodologies (comme Six Sigma par exemple) et des outils permettant
de gérer les processus métiers de bout en bout, on peut conduire une telle démarche et gérer le cycle
de vie complet. L’utilisation de certaines bonnes pratiques se trouve être, dans le cadre de la discipline
du Business Process Management, d’un intérêt certain et permettent de sécuriser ces projets.
Il est vrai que les mentalités doivent évoluer à propos des processus métiers. Par exemple, un processus
métier ne doit pas être figé à 100%. Il doit être évolutif au gré des besoins métiers et les règles métiers
doivent être modifiables simplement et surtout par le métier. Un autre exemple serait de penser qu’un
processus interne à l’entreprise est plus simple qu’un processus étendu (avec des parties externes à
l’entreprise). La réalité peut en être tout autre. En effet, on peut avoir des processus internes dix fois
plus complexes que des processus étendus.
Le BPR est conçu pour prendre en compte des modifications importantes des processus avec des
améliorations conséquentes en termes de qualité, coûts, délais et niveau de service.
Au sein d’une entreprise on constate que les processus sont d’origines diverses et c’est pourquoi avant
tout choix d’une solution il est impératif de bien connaître les besoins du métier. Par ailleurs, les
processus sont différents en fonction du secteur d’activité de l’entreprise, de sa culture et de ses produits
et services. Pour finir, l’interprétation de ce qu’est le BPM est très différente d’une personne à une autre
et je suis certain que si vous prenez le temps de questionner différentes personnes, vous allez recueillir
des réponses différentes les unes des autres. Certaines parleront de la modélisation des processus,
d’autres de l’automatisation des processus et certaines de la gestion électronique de documents. Il est
alors préférable de s’appuyer sur une matrice permettant d’identifier les processus, leur cible et à quelle
activité métier ils s’adressent.
Identific
Identificaation
tion
EEva
valua
luation
tion
AAm
mélioration
élioration RR edes
edesign
ign
Mis
Misee en
en œ
œuvre
uvre
Figure 66 : Processus de reenginnering et optimisation
Par contre, en fonction de ce que l’on doit faire, formaliser le processus ou améliorer le processus,
on doit s’appuyer sur une démarche qui permettra d’effectuer les 2 cas. Si rien n’existe, on passera
probablement par une phase de « re-design » et à l’itération suivante, on se focalisera sur l’amélioration
du processus.
Niveau d ’effort
Am
Am
élioration
éli
or
at
io
Re
n
Re
-conception Périm ètre

-c
on
ce
pt
Reengineering
io
Re
n
eg
in
ee
rin
g
Figure 67 : Niveaux des efforts à fournir
Si on se trouve dans une démarche d’optimisation, les efforts seront potentiellement plus importants.
D’où l’importance de passer par une phase de reengineering ou de re-conception, la seconde étant
moins drastique que la première.
Le niveau d’effort à fournir est fonction de ce que l’on souhaite faire : amélioration, re-conception ou
reengineering total.
La classification des processus

Pour terminer ce chapitre, il est important de rappeler que l’on doit classifier les processus en processus/
sous-processus mais également dans une des 4 catégories que sont :
• les processus d’intégration,
• humains,
• décisionnels
• et documentaires.
On constate finalement, que certains projets de mise en place de Gestion Electronique de documents
nécessitent la mise en place d’outils pour gérer les processus de diffusion de l’information ou de validation.
Ces projets, dits de dématérialisation, utilisent de manière intensive les outils de BPM et permettent de
mixer des processus automatisés, mais également des corbeilles d’activités ou de tâches que les acteurs
doivent réaliser. Ces processus seront classés dans la catégorie des processus documentaires même si
ceux-ci sont en fait des processus métiers plutôt orientés « décisionnel ».
S ous - P roces s us P roces s us P roces s us P roces s us

P roces s us
proces s us d ’ inté gration Hum ain dé cis ionnel docum entaire
S ous cription

C alcul d ’ é ligibilit é
 
C ollecte de docum ents
 
E nvoi de courrier

Duplication des donn é es du
C R M vers le s ys t è m e de
ges tion
  
T raitem ent de cas lim ite
 
Figure 68 : Exemple de matrice de processus
Le tableau ci-dessus donne un exemple de classification de processus métiers au sein d’une banque qui
gère des crédits à la consommation.
5. Intégration, Workflow et BPM
Un bon nombre de concepts de la partie « intégration » des outils de BPM proviennent d’outils
d’intégration d’applications d’entreprise en particulier pour les processus automatisés. Ce qui n’est pas
sans apporter de confusion car la gestion des processus métiers ne s’arrête pas à leur automatisation. Il
est rare d’avoir un processus métier automatisable de bout en bout. Néanmoins l’intégration au système
d’information est nécessaire pour le fonctionnement et le pilotage des processus métiers.
Pour permettre l’intégration d’un outil de BPM au sein du système informatique, on utilise cette couche
d’intégration. Certaines solutions possèdent déjà un EAI intégré auquel cas on pourra réutiliser celui-ci.
Pour mieux comprendre les fonctionnalités de cette couche d’intégration, nous allons en détailler les
principales fonctions.
L’intégration et le concept de l’EAI

L’EAI (Enterprise Application Integration) est un concept permettant d’intégrer les applications
d’entreprise entre elles et de leur permettre d’échanger des données dans le but d’automatiser des tâches
ou flux d’informations à l’intérieur ou à l’extérieur de l’entreprise. Il est vrai que le fait d’introduire
des échanges inter applicatifs, en mode point à point (voir le schéma ci-après), créé avec le temps un
véritable plat de spaghettis qui devient si complexe, que la moindre modification de l’interface d’une
des applications peut avoir des impacts non négligeables sur un grand nombre d’échanges. L’un des
avantages de l’EAI est d’apporter la connectivité nécessaire, permettant de s’interfacer aux applications et
infrastructures du système d’information et une fois la connectivité configurée, en assurer sa réutilisation
pour de multiples flux ou échanges au sein du système ou inter systèmes.
L’EAI est particulièrement adapté aux échanges appelés A2A (Application to Application) et met à
disposition des fonctionnalités comme
• la traçabilité,
• la transformation,
• le re-jeu des flux en erreur,
• etc.
Application
Application
R éférentiels
Application
Application
Application
Application Application
Application
B ase de
donn ées
FFiliale(s)
iliale(s)
PPartenaires
artenaires
Figure 69 : Interfaces traditionnelles
A contrario, l’EAI permet d’avoir une gestion centralisée des interfaces, des producteurs et consommateurs
de messages, de l’administration des échanges et bien d’autres fonctionnalités encore. Par contre, n’est-ce
pas une vue idyllique ? Pour que l’EAI soit utilisé de la manière la plus efficace possible, il est impératif
qu’une démarche appropriée soit mise en place et garantisse que certaines bonnes pratiques (formats pivots,
rationalisation des interfaces vers les applications, fonctions de supervision et administration, …) soient
correctement appliquées faute de quoi vous aurez le plaisir de voir le retour d’un plat de spaghettis.
Applica
Application
tion
R éférentiels
Applica
Application
tion
Applica
E AI Applica
Application
tion
Application
tion
Ba se d e
d onn ées
Filia
Filiale(s)
le(s)
Pa
Partena
rtenaires
ires
Figure 70 : Interfaçage avec un EAI
Ensuite, un véritable outil d’EAI doit supporter des standards technologiques (XML, EDI, http, ftp, web
services,…) pour faciliter l’intégration des applications ou partenaires.
La connectivité annoncée par les éditeurs de solution se veut être standard. Standard par rapport à
quoi ? Standard par rapport à leur outil d’EAI mais pas par rapport à un standard bien défini (XML ou
SWIFT par exemple). Dans le passé, seules quelques solutions en ont utilisé et aujourd’hui avec les
architectures orientées services, de véritables standards ont vu le jour et ceux-ci sont utilisés par les
éditeurs, intégrateurs et clients.
Outre la connectivité, un outil d’EAI doit apporter diverses fonctionnalités comme :

• Le routage
• La transformation
• La transcodification
• La traçabilité de bout en bout
• Un interfaçage normalisé (connecteurs & adaptateurs)
• Le support d’un mode message (Message Broker)
• La publication/souscription d’événements
• L’automatisation de processus métiers
• L’administration et la supervision
• La sécurité
Le B2B et le B2C
Le e-Commerce est un terme qui se réfère au commerce électronique et qui signifie l’exécution de
tâches commerciales en relation entre des entreprises, des partenaires et des clients. Par contre, les
activités commerciales entre l’entreprise et ses clients sont différentes des activités entre l’entreprise et
ses partenaires. La relation B2B (Business to business : relation de l’entreprise avec ses partenaires) est
beaucoup plus complexe car elle met en œuvre des traitements et des flux d’informations provenant des
processus achats, des relations entre des entités de recherche et développement, d’une collaboration au
niveau de gestion planification inter entreprises, etc. La relation B2C (Business to consumer : relation
de l’entreprise avec ses clients) met en œuvre des échanges entre l’entreprise et ses clients.
Outre les types d’interlocuteurs, la différence entre le B2C et le B2B se situe à plusieurs niveaux et en
particulier :
• des moyens de communication : dans le B2C le client aura à faire à une application web lui
permettant d’effectuer un certain nombre d’opérations qui font le contenu des échanges alors que
dans le cas du B2B les échanges sont beaucoup plus souvent automatisés et leur contenu est bien plus
complexe
• du contenu des échanges : Dans le cadre du B2C, le client a la possibilité de parcourir des
catalogues, placer des ordres de bourse, effectuer des virements et voir l’état de commandes, etc. Dans
le cadre du B2B, les échanges se font pour des demandes d’achats en direct (e-procurement) avec une
relation entre les systèmes des différentes entreprises concernées, la gestion de catalogues avec des
réplications par exemple, les demandes de disponibilité de produits au travers de l’application du client,
l’expédition de commandes, le passage d’ordres de virements en quantité, etc.
• des niveaux de contrôles : Pour ce qui concerne le B2C les contrôles sont fait via l’application
que le client utilise (bien souvent une application web ou portail), alors que pour le B2B les contrôles
sont plus complexes le système doit prendre en compte les problèmes de sécurité et de droits d’accès
ainsi que les processus étendus(*). Dans ce cas les échanges B2B font partie intégrante du processus.
On dit que c’est une « entreprise étendue ».
Dans le cadre du B2B, il existe des plates-formes qui permettent d’une part de simplifier la mise en
place de ces échanges, mais également d’apporter un support d’échanges normalisés dans le domaine
du B2B comme des échanges SWIFT(*) dans la banque, de l’EDI (Electronic Data Interchange) avec
des standards comme X12 ou encore EDIFACT, etc. Il existe d’ailleurs des réseaux spécialisés (comme
SWIFT-NET) qui font partie de la famille des VAN (Value Added Networks : réseaux d’échanges à
valeur ajoutée). Les plates-formes utilisées sont des plates-formes dédiées au B2B et e-Commerce ou
bien alors, des plates-formes de type EAI qui embarquent des fonctionnalités de B2B et qui supportent
d’innombrables protocoles différents utilisés dans les échanges interentreprises.
Une autre partie importante du B2B est l’utilisation d’un protocole d’accès et surtout d’autorisation
d’accès pour identifier le ou les partenaire(s) lors des échanges et permettre un suivi de bout en bout avec
celui-ci. Certains outils ont même des fonctionnalités permettant de gérer les profils des partenaires avec
en plus une gestion de certificats permettant d’encrypter les données en utilisant le certificat de chacun
des partenaires. Tous les niveaux de sécurité des échanges de l’entreprise étendue peuvent être proposés
avec certaines solutions. Ces solutions de B2B proposent plusieurs possibilités d’interactions.
Internet
Figure 71 : Accès client web
L’accès « client web » est le mode d’interaction le plus utilisé aujourd’hui et permet à des partenaires
d’échanger, de commander, etc. de manière assez simple et sécurisée. Par contre, cet accès nécessite
qu’une personne effectue les manipulations à partir d’une station de travail.
(*) voir glossaire

page 192
E ntrepris e P artenaire
Internet
Figure 72 : Processus étendu
Dans le cadre de processus, certaines activités ou tâches sont au niveau de l’entreprise et pour vérifier,
par exemple, la disponibilité d’un produit et le réserver, 2 des tâches sont exécutées chez le partenaire.
Il met alors à disposition les fonctions nécessaires pour les appeler et les suivre. Dans ce cas on peut
parler réellement d’entreprise étendue.
Par ailleurs, les briques B2B permettent maintenant de gérer la notion de « Trading Partner » (partenaire
commercial) avec des outils qui permettent de gérer le profil de ces partenaires ainsi que les catégories
de produits dont ils disposent. Ensuite, ces partenaires mettent à disposition des fonctions que l’on
peut utiliser de l’extérieur et moyennant un minimum de sécurité.
On parle d’ailleurs souvent d’entreprise étendue qui se définit comme suit :

Une entreprise étendue est un ensemble formé par l’entreprise et ses partenaires directs (clients,
fournisseurs et prestataires) et qui fonctionne comme une entreprise unique en tenant compte de tous
les composants.
Entreprise étendue
Entreprise
Entreprise
Entreprise
Partenaires
Entreprise
Entreprise
Entreprise
Entreprise
Clients
Figure 73 : Entreprise étendue
Cet écosystème fonctionne selon des normes et règles qui sont définies entre les différentes parties et qui
fluidifient les échanges de manière à rendre le meilleur service possible aux clients de l’entreprise.
Les échanges avec les partenaires sont alors souvent au format électronique et utilisent des standards de
l’Internet mais également d’autres définis pour des fonctions particulières comme les transferts d’argent,
les envois de demandes vers des places de marché électroniques, etc.
Parmi ces protocoles standards, on va trouver les protocoles spécialisés soit par fonction, soit par
métier.
Dans les principaux protocoles on peut citer des protocoles comme :

• EDI (Electronic Data Interchange) est un ensemble de protocoles qui existent depuis les années
1980. On peut d’ailleurs considérer que l’EDI est l’ancêtre de l’e-Business.
Comme protocoles, on peut citer également :

• AS1 et AS2 EDI/XML
• EDIINT
• ANSI X12
• EDIFACT
• SWIFT
• HIPAA
• HL7
• HPRIM
• RosettaNet
• UCCNet
• ebXML
• …
Tous ces protocoles permettent d’échanger des données selon des formats et des modes préétablis. A
noter également que certains de ces protocoles sont sectoriels, comme HIPAA et HL7 utilisés dans le
monde de la santé à l’international et HPRIM qui est l’équivalent de HL7 en France. D’autres, comme
RosettaNet1 sont particulièrement adaptés au niveau des échanges de partenaires entre eux.
Outre les protocoles, les fonctionnalités B2B doivent également permettre un certain niveau de gestion
des partenaires et à minima de droits d’accès permettant aux partenaires de répondre à des demandes qui
émanent soit de l’entreprise, soit des clients en direct avec dans certains cas des mécaniques permettant
la non répudiation des requêtes reçues au niveau de la plate-forme.
On pourrait prendre comme exemple une place de marché qui regrouperait des entreprises proposant
des services de reprographie proposés par des partenaires. Cette place de marché mettrait en contact
les clients et les fournisseurs, le tout en se basant sur les critères qui caractérisent les demandes des
clients. Dans le cas de telles plates-formes, il sera alors facile de faire évoluer la liste des partenaires en
fonction des demandes et d’intégrer de nouveaux partenaires pour proposer de nouveaux services aux
clients de l’entreprise.
Processus
étendu
Entreprise étendue
Entreprise
Entreprise
P a rtena ires
Entreprise
E ntrepris e
Entreprise
C lients
Entreprise
Entreprise
Figure 74 : Processus étendu
On comprend alors aisément que l’on va pouvoir mettre en place des processus dit « étendus » qui
permettront de suivre et d’optimiser la procédure et permettre de répondre aux besoins des clients
depuis la demande jusqu’à la réalisation des prestations ou de la livraison des produits demandés.
Demain, des partenaires spécialisés proposeront des processus exposés sous forme de services sécurisés
et permettront à une entreprise extérieure d’instancier tout ou partie d’un processus. Ces processus
devront également permettre la récupération d’informations permettant d’assurer un suivi au niveau
de l’accomplissement des différentes activités. Dernier point, ces processus doivent également proposer
l’accès à des indicateurs permettant d’analyser la qualité d’exécution de ces processus.
L’automatisation des processus métiers

Au sein des processus métiers vont se trouver des activités qui peuvent être automatisées. Ces activités
automatisées permettent, en général, d’éliminer les doubles saisies par exemple, de proposer une aide
à la décision basée sur des données présentées à l’utilisateur, d’apporter la capacité d’exécuter des
procédures alternatives en fonction de délais de traitement constatés, etc. Ces activités feront l’objet
d’activités ou de tâches au sein du processus et celles-ci seront identifiées comme étant système. Les
applications faisant partie de ce processus devront proposer les données et méthodes d’accès permettant
aux processus d’une part d’être exécutés et d’autre part d’être correctement suivis et ainsi, ne pas rompre
la chaîne de traitement.
Bien entendu, les applications qui font partie d’un processus doivent proposer des moyens d’accès. Si
elles n’en disposent pas, ou alors que ces accès ne sont pas adaptés, alors il sera nécessaire de prévoir
des évolutions de l’application en question.
Commandes
Services des
Ac tivit é A Ac tivit é B
Service des
commandes
BPMCRM
CRM
BPM
S ervic e A S ervic e B
Gestion de
stock
S ervic e C S ervic e D
Gestion de stock
Figure 75 : Automatisation des processus
Complémentarité EAI/BPM
Les outils de BPM ont aujourd’hui une couche d’intégration qui s’apparente à de l’EAI et cette couche
est importante pour que les processus puissent accéder aux données du SI et permettre à la suite BPM
de correctement s’intégrer. Il est vrai qu’aujourd’hui avec les architectures basées sur des services web
l’accès aux applications s’en trouve facilité, mais ces services ne sont pas toujours disponibles et il
faudra, très certainement, allier connectivité spécifique et connectivité standardisée pour permettre
une intégration complète des processus.
B P M - Métier
Portail
Portail et
et notifications
notifications
Supervision
Supervision &
& administration
administration
Supervision & administration

B P M - Métier
E AI - Tec hnique Processus
Processus et
et coordination
coordination des
des échanges
échanges
Référentiel
E AI
B P M – R outage ac tivit é s
Transformations
Transformations et
et routage
routage
rentiel
rentiel
é
fé
éfé
R RE AI
Messages
Messages (( événements,
événements, donn
donn ées
ées et
et transactions)
transactions)
Adaptateurs
E AI Connecteurs EAI
A utres
http ERP CRM A pplic a tions
S GB D Fic hiers ftp s ervic es
…
Figure 76 : Modèle fonctionnel de l’EAI
Le BPM va apporter, en plus de la modélisation des processus, des interfaces permettant aux utilisateurs
de suivre l’activité et ce via un accès de type web.
En conclusion, l’EAI est un concept d’outil d’intégration qui apporte les fonctions facilitant l’intégration
des processus ainsi que leur pilotage. C’est ce que l’on appelle l’agilité d’intégration nécessaire pour
apporter un bon niveau de flexibilité et d’agilité aux processus.
Les outils de Workflow

Le Workflow définit un flux d’informations au sein d’une organisation. Ce flux d’information peut être
la transmission d’informations voire de documents au sein d’une entreprise.
Les outils de Workflow sont, à la base, des outils permettant la modélisation et la gestion d’un ensemble
d’activités ou de tâches, manuelles ou semi-automatiques, à accomplir par différents acteurs pour
traiter des flux de documents ou d’informations. On parle, en général, de procédure au sein d’une
entreprise.
On fait souvent référence de gestion électronique d’un processus métier permettant de piloter une
activité au sein de l’entreprise et où les documents ou tâches doivent passer d’un acteur à un autre; un
acteur pouvant être une personne ou une application du système d’information.
Avec les outils de Workflow, on décrit le circuit d’exécution de tâches à accomplir lors du déroulement
d’un processus métier (plus souvent une partie de processus) en tenant compte de données calendaires,
de rôles et responsabilités d’acteurs, de délais et de modes de validation. Les décisions, que les utilisateurs
de ces Workflow peuvent prendre, se basent sur les données présentées par l’outil (bien souvent
une interface accessible via un navigateur Internet). En fait un outil de Workflow permet de gérer la
coordination de tâches et d’acteurs afin de servir au mieux les intérêts de l’entreprise. Bien entendu
les outils apportent également des fonctions de communication (vers d’autres applications) ou de
collaboration (vers d’autres acteurs qu’ils soient internes ou externes).
Les outils de Workflow ont d’ailleurs pénétré le marché principalement dans le cadre de la gestion de
tâches (gestion électronique de documents : GED, circuits de décisions, re-routage de tâches vers des
acteurs présents au moment où les demandes arrivent dans le système, etc.).
Des organisations se consacrent à standardiser les outils de Workflow, comme le WfMC1 qui s’attache
à définir des normes et à valider la conformité d’outils du marché par rapport à ces normes.
Le modèle définit par le WfMC (voir Figure 14 : Modèle de référence défini par le WfMC), établit des
normes pour définir :
• un standard d’échange entre des outils de modélisation des processus et les moteurs
d’exécution de Workflow (interface 1),
• des APIs standardisées pour que les applications clientes puissent effectuer des requêtes auprès
des moteurs de Workflow pour connaître l’état exact des processus et activités (interface 2),
• des méthodes standardisées permettant d’invoquer (ou d’appeler) des applications externes qui
seront, en quelque sorte, des sous-traitants du Workflow pour réaliser l’exécution d’activités ou
de tâches. Aujourd’hui ces méthodes se font par des APIs définies au niveau de
l’interface 2. (interface 3),
• des modèles d’interopérabilité et les standards associés des Workflow de manière à permettre
des échanges entre des applications de Workflow (interface 4),
• les fonctions d’administration et de supervision d’un Workflow (interface 5).
Dé finition du
proc es s us
Interface 1 Echanges externes (WfXML)
Mod èles (XP DL )

Interface 4
A dminis tration Moteurs Moteurs

& outils de de de
s upervis ion W ork flow
W ork flow
Interface 5 Autres
S erv ic es de diffus ion du W ork flow
s erv ic es de
W ork flow A P I (W A P I) diffus ion du W ork flow
Interface 2 Interface 3
Applications Applications
clientes invoqu ées
Figure 77 : Modèle de référence défini par le WfMC (Source WfMC)
L’objectif du modèle de référence est d’apporter un cadre commun sur lequel les éditeurs de solutions
peuvent se baser et permettre un bon niveau d’interopérabilité. Bien entendu, bon nombre d’entre eux
ont intégré ces standards, mais ont également effectué des extensions pour augmenter la capacité du
produit à prendre en charge de nouvelles fonctionnalités.
L’utilisateur du Workflow est défini de par les outils d’administration et est affecté à un ou plusieurs
rôles. On peut avoir des rôles tels que l’utilisateur, le superviseur, le manager, l’administrateur, etc.
Ces rôles permettent de définir le niveau de droits pouvant effectuer certaines opérations comme la
visualisation de certaines tâches, le routage de tâches, l’affectation de tâches, etc.
Côté client, l’utilisateur a une interface qui lui permet d’effectuer des actions sur des tâches qui lui ont
été affectées et ce en fonction de leurs rôles qui sont paramétrés par l’administrateur du système. Dans
ce cadre, l’utilisateur dispose d’un certain nombre de fonctions dont la première est de lister les tâches
qui lui ont été affectées. L’utilisateur a donc la possibilité de visualiser ses tâches, de les trier et de les
filtrer par thème, niveau d’importance, client, etc. Par rapport à ces tâches et en fonction du ou des
rôles affectés, l’utilisateur pourra avoir l’état de tâches et la possibilité de modifier ces états, d’assigner
des tâches à des utilisateurs ou groupes d’utilisateurs, de conférer certains droits en fonction de critères
préétablis, de modifier le calendrier de disponibilité d’utilisateurs et bien d’autres fonctions relatives à
ces activités ou tâches.
Pour ce qui concerne le serveur, il contient le descriptif des processus (modèle) et les exécute tout en
apportant à des applications clientes les possibilités de suivre jusqu’aux tâches unitaires et d’en connaître
leurs états au fur et à mesure de leur avancement.
La définition des processus
Pour permettre l’échange de la définition d’un processus, en particulier entre un outil de modélisation
et un outil d’exécution, le WfMC a donc définit un standard nommé XPDL (XML Process Definition
Language) qui permet de définir un processus en utilisant le langage XML.
Cette définition des processus comporte tous les éléments composant un processus métier comme :
• Les balises de début et de fin
• Les activités et tâches
• Les transitions
• Les attributs qui caractérisent les activités et tâches
• Les participants comme les utilisateurs, rôles, groupes et leurs relations
• …
Ce langage permet de définir le processus au sein d’un outil de modélisation en utilisant une interface
graphique simple et ergonomique et de l’exporter dans un format standard et compréhensible par la
majorité des outils de Workflow du marché. L’écran suivant nous montre une vue graphique d’un
processus très simple et la vue XPDL(*) de ce même processus. Dans notre exemple, très simple, un
client effectue une demande de crédit à la consommation et l’agent de la banque collecte les informations
en vue de lui faire une proposition.
Client
Client Dema nde
BPM
BPM
Service client
R épo ns e
Service Client
Figure 78 : Diagramme d’un processus très simple (BPMN)
On comprend bien, en regardant la vue d’un XPDL ci-après, qu’il est primordial d’utiliser des outils
permettant de transcrire une vue graphique en un fichier standardisé. Le fichier XPDL serait caractérisé
de « barbare » par tout expert métier et donc impossible à exploiter. Ces vues graphiques seront donc
le lien (ou la vue partagée) entre le métier d’une part et l’informatique d’autre part.
(*) voir glossaire

page 192
Figure 79 : Vue XPDL du processus simple
On comprend alors que le moteur d’exécution interprètera le fichier XPDL pour exécuter et suivre le
processus de bout en bout.
La corbeille de tâches
La corbeille de tâches permet à un utilisateur de visualiser les tâches qu’il a à effectuer et l’état d’avancement
de chacune de ces tâches. L’utilisateur aura la possibilité de visualiser le détail de chaque tâche ainsi
que les données associées. Elles sont affectées selon des règles qui sont prédéfinies et qui permettent
de tenir compte de règles métiers, de rôles et responsabilités et d’états divers qui peuvent être fonction
du cycle de vie du processus et de ses activités.
Cette gestion des tâches peut se faire soit à partir d’une application cliente (du type client lourd) soit à
partir d’un navigateur Internet permettant d’accéder à leurs écrans de gestion.
Pour chacune de ces tâches il est nécessaire de permettre, en fonction du rôle de l’utilisateur, des
actions comme :
• les lister,
• les visualiser,
• visualiser les documents et données attachées,
• les attribuer,
• les transférer,
• visualiser leur état (clôturée, en attente, en retard,…).
La présentation de ces tâches doit pouvoir se faire en utilisant des formulaires configurables et utilisés
en fonction des activités et processus. Ces tâches sont affectées selon des mécanismes définis et
programmables en fonction de critères paramétrés, de disponibilités d’acteurs, etc.
Le transfert de tâches
Le routage des tâches est une des fonctionnalités importantes du Workflow. Plus l’entreprise est
importante plus les fonctions offertes de transfert des activités et tâches sont importantes.
Un routage est bien souvent oublié : le routage d’une tâche d’un même processus et pour un même
utilisateur. En d’autres termes, la gestion des tâches d’un processus mono acteur. Tous les produits du
marché ne le supportent pas mais contournent ce besoin par un enchaînement d’écrans. Or cette solution
ne permet pas d’avoir une traçabilité de l’avancement des tâches. Il peut s’avérer donc important de
bien veiller à supporter cette traçabilité de bout en bout des tâches d’un processus et ce, même pour
un acteur unique.
Les différents modes de routage peuvent être basés sur :
• Le nom d’un utilisateur,
• Le groupe d’appartenance d’un utilisateur,
• Un rôle,
• Une file d’attente,
• Des compétences,
• La présence d’un acteur.
Les fonctions d’intégration
Les outils de Workflow comportent des fonctions d’intégration de type EAI qui permettent d’intégrer
la solution au système informatique de manière à disposer :
• des données nécessaires aux processus, activités et tâches,
• de mécanismes de notification permettant de déclencher une ou plusieurs tâches automatiquement,
• de notifier un sous-ensemble du système de l’évolution des tâches ou de leur accomplissement.
Certains outils de Workflow préfèreront s’appuyer sur des fonctions plus évoluées proposées par des
outils spécialisés (ETL, EAI ou ESB par exemple).
La gestion des utilisateurs, des rôles et des groupes
La gestion des utilisateurs permet de paramétrer les accès aux processus et interfaces utilisateurs. Pour
cela les outils proposent des fonctionnalités soit internes, soit basées sur un annuaire externe.
Rôle
Rôle Direc tion

Utilisateurs
Ventes direc tes Autres c anaux DAF
Ma na ger Ma na ger Ma na ger
C ontrôleur de C ontrôleur de C ontrôleur de

ges tion ges tion ges tion
V endeurs
V endeurs C omptabilit é
partenaires
Tél é-V endeurs Fac turation
Groupes
Figure 80 : Utilisateurs, rôles et groupes dans l’organisation
L’avantage de s’appuyer sur un annuaire externe est de disposer d’une brique qui permet de gérer les
accès et droits d’accès à la solution de Workflow ou de BPM mais également à d’autres.
Dans notre contexte, il est préférable que la solution apporte la possibilité de calquer les utilisateurs, rôles
et groupes sur l’organisation de l’entreprise. On trouve d’ailleurs des outils qui permettent de modéliser
l’organisation de l’entreprise et d’en déduire les utilisateurs, rôles et groupes associés. Cette modélisation
permet de faciliter la création de cette organisation et de la paramétrer au sein de la solution.
Les briques logicielles externes sur lesquelles la solution pourrait s’appuyer sont souvent des annuaires du
type LDAP ou des solutions beaucoup plus complètes d’IAM(*) qui permettent de gérer non seulement
les accès, mais l’identité des utilisateurs dans leur ensemble et des processus sous-jacents. Les données
sont alors toutes référencées dans une base centralisée. (*) voir glossaire
page 192
Les outils de modélisation et de simulation des processus
La modélisation des processus est le formalisme effectué pour décrire le processus métier de manière
graphique. Mais la formalisation ne s’arrête pas là ! Il faut également documenter le processus, c’est-à-
dire décrire de manière détaillée, le contenu des tâches, des règles métiers, etc.
Les outils utilisés sont d’origines diverses comme :

• La modélisation des processus
• Les outils de Workflow et de BPM qui proposent un outil de modélisation
Les outils spécialisés de modélisation (en anglais on parle d’outils d’Enterprise Architecture) ont plus
vocation à permettre de formaliser les processus et à les simuler avec plus ou moins de profondeur(*).
Pour ce faire, il est nécessaire de se poser un certain nombre de questions lors de cette formalisation
comme :
• Comment fonctionnent mes processus métier ?
• Quelles sont les priorités de mes processus ?
• Mon processus va-t-il fonctionner correctement ?
• Quelles ressources sont nécessaires ?
• Quelles règles allons-nous utiliser ?
• Quels liens avec l’informatique ?
• Quels profils pour l’exécution des tâches ?
• Quels types de routage et d’escalade ?
• Quels volumes à traiter ?
• Quel pilotage est-il nécessaire de mettre en place ?
Ce qui est également important c’est le type de formalisme utilisé comme l’utilisation de standards de
représentation graphique des processus (UML, BPMN, …)
Pour finir, les formats d’import et d’export doivent permettre de laisser le choix de l’outil de modélisation.
Il n’est pas rare de voir une entreprise utiliser un outil de pure modélisation. Il faut permettre ensuite,
un accostage entre les modèles définis et l’outil de BPM.
Le référentiel de processus
La notion de référentiel de processus au sein d’une solution est importante car elle permet d’accéder à
l’ensemble des définitions et de la cartographie des processus dans leur ensemble. La centralisation ne
pourra que faciliter l’analyse et l’optimisation ultérieures des processus. Maintenant certains outils ne
vont stocker dans le référentiel que la définition des processus sans pour autant attacher les données
des processus.
La notion de référentiel global des processus et des données associées, peut apporter des fonctions
permettant de vérifier si un sous processus n’existerait pas déjà et dans ce cas de le réutiliser pour un
autre processus ou bien encore de faciliter les analyses d’impacts lorsque certains processus ou formats
de données doivent évoluer. Jusqu’à maintenant les outils de BPM n’ont que trop peu intégré ce type
de fonctionnalité ce qui rend plus difficile et surtout plus long l’analyse d’impact.
Les règles métiers
Les règles métiers permettent d’influencer une décision basée sur des critères bien définis. Par exemple,
une règle simple consisterait à envoyer une commande à un responsable si celle-ci est supérieure à
10000 euros. Le principal objectif de la règle métier est de séparer la logique métier de la logique de
l’enchaînement des activités du processus. Le principal avantage est de permettre, par le biais de ces
règles, d’apporter une meilleure évolutivité des processus, et surtout des règles métiers, d’autant que
si celles-ci sont bien séparées, elles pourront être aisément modifiées ultérieurement par des experts
métiers et fonctionnels sans pour autant avoir à redéployer le processus.
(*) voir glossaire Le dernier avantage dépend du support ou non de services web (au sens SOA). Si des règles sont souvent
page 192 utilisées au sein de plusieurs processus, il peut s’avérer très avantageux de publier ces règles sous forme
de services web pour en assurer une meilleure réutilisabilité ultérieure. Les règles doivent donc être
correctement identifiées lors de la modélisation des processus.
Exceptions
Autre partie des processus; les exceptions. Il est nécessaire d’analyser les cas d’exceptions possibles. Dans
ce cas, on peut avoir à procéder à l’identification d’exceptions techniques mais également fonctionnelles.
Ces exceptions peuvent se produire suite à une erreur du système, à un mauvais format de donnée ou
bien encore à un cas métier non traité.
On va alors alerter un superviseur d’une exception au niveau d’une instance particulière du processus de
manière à en assurer la traçabilité. Ces exceptions doivent toujours avoir une action associée permettant
de les résoudre.
Procédures de compensation
Autre cas: les procédures de compensation. Certaines exceptions pourraient conduire, par exemple,
à devoir revenir à un état précédent voire à annuler toutes les actions précédemment réalisées. Par
contre, il n’est pas toujours possible de réaliser ces retours en arrière. Par exemple, dans le secteur des
télécommunications, certains progiciels spécialisés comme les systèmes de facturation, ne permettent
pas de faire ce que l’on appelle des « rollback(*) ». La solution consiste alors à définir des procédures
de compensation. Dans notre précédent exemple, elle consisterait à modifier le client créé pour le passer
d’un état actif à un état inactif.
Ces procédures doivent être également modélisées de manière à comprendre toutes les actions nécessaires
pour revenir en arrière. Ces actions pourront, bien entendu, être automatiques ou manuelles.
Le rôle de la simulation de processus
Une fois le processus et ses règles modélisés (avec exceptions et procédures de compensation), il est très
utile de pouvoir le simuler. Les outils proposent aujourd’hui des fonctions permettant de réaliser cette
simulation qui va permettre de visualiser le comportement du processus en introduisant des données
de test, dans un premier temps.
Ces simulations permettent d’identifier les points de contention du processus et de modifier certaines
activités de manière à le rendre plus efficace dans son ensemble.
Dans un second temps, pas toujours existant dans les différents produits, on injecte des données en
provenance des systèmes de production de manière à simuler le processus avec des données réelles et
ainsi être plus proche de la réalité. A ce stade, les simulations sont basées principalement sur l’injection
de données ainsi qu’à l’intégration du coût de chacune des tâches. La simulation va alimenter des
tableaux de bords permettant de voir le coût en fonction des données injectées en entrée du processus.
Certaines solutions vont même jusqu’à afficher les tableaux de bord des indicateurs clés comme si le
système se trouvait en production.
Les moteurs de règles

Un moteur de règles est un médiateur de l’information au sein du système d’information. Il prend des
décisions basées sur le contenu des données qui lui sont accessibles. C’est la logique métier basée sur
des données qui est ainsi mise en place pour apporter l’intelligence dont doit disposer un processus
métier pour prendre des décisions et ainsi effectuer des opérations particulières ou encore, exécuter un
processus, sous-processus ou activité en particulier. Il existe des outils spécialisés dans la mise en place
de règles métiers. Il est d’ailleurs opportun d’externaliser les règles métiers à l’extérieur d’un progiciel afin
d’apporter toute l’agilité nécessaire au système et permettre ainsi de le faire évoluer plus rapidement.
Lors de la formalisation des processus métiers, il est important de bien identifier les éléments qui seront
du domaine du processus, ceux qui seront du domaine des règles métiers ainsi que ceux qui devront
faire partie d’un référentiel de données. (*) voir glossaire
page 192
Une répartition clairement établie, comme dans le tableau ci-dessous, permet d’éviter toute confusion
et facilitera aux experts métiers et aux experts techniques la séparation des fonctions, processus, règles,
etc. Autre avantage, cette répartition favorisera l’agilité de ce qui sera implémenté au sein de la solution
de BPM.
Régle
E lem ent du proc es s us Processus Référentiel
Décision 
Politique 
Invocation Service applicatif 
Etat 
Durée 
Localisation 
Appel à sous processus 
Certification de transaction 
Gestion des erreurs 
Données de référence   
Transformation de données  
Enregistrement des données  
Figure 81 : Répartition Processus et Règles métiers
Une répartition clairement établie va également fortement contribuer à l’alignement métier/IT et apporter
la flexibilité tant demandée par les experts métiers de l’entreprise. Combien de fois les experts métiers
ont dû trouver des solutions pour accompagner la stratégie de l’entreprise ou d’une activité faute de
flexibilité du système d’information ? Certaines de nos récentes études ont indiqué que plus de 50 % des
experts métiers se plaignent du manque de flexibilité et d’agilité du système d’information. Par ailleurs,
le fait de bien séparer règles et processus permettra de modifier les règles dans un délai court (et l’on
sait que ce sont plus souvent les règles que les processus qui évoluent) car, si elles sont correctement
conçues, il sera plus simple de les modifier, d’effectuer les tests de non régression et de déployer ces
évolutions et ce sera certainement, pour la plus grande satisfaction du métier.
Les outils de BPM

Les outils de BPM ou BPMS (Business Process Management Suites) sont des outils de gestion de processus
qui regroupent des fonctions :
• D’outil de modélisation
• D’EAI ou d’intégration
• De Workflow
• De moteur de règles
En fait, ces outils regroupent toutes les fonctionnalités que nous avons vu précédemment que ce soit
des fonctions d’intégration, de Workflow ou de modélisation.
Le BPM et le modèle OSI
Le modèle OSI définit différentes couches qui représentent les fonctions nécessaires pour
supporter les communications entre applications. Les 7 couches principales (1 à 7) ainsi
définies vont du physique (matériel) à la partie applicative (couche 7).
On peut y ajouter les couches suivantes :
• La connectivité : connectivité applicative ou interfaces
• La transformation : transformation des données qui se fait soit au niveau du bus d’échange soit
au niveau de la connectivité.
• La couche de routage : elle permet de transférer les tâches et données vers une cible.
• Les flux techniques : automatisation des flux entre les applications
• Les processus métiers : cette couche prend en charge les processus qui enchaînent les tâches
automatisées et les tâches manuelles et qui en assure un suivi de bout en bout de manière à
apporter fiabilité et traçabilité.
12. Pr ocessus m étier
11. F lux techniques
10. R outage
9. T r ansfor mation
8. C onnectivit é
7. A pplication
6. Pr ésentation
5. Session
Mod èle OS I
4. T r anspor t
3. R éseau
2. D ata L ink
1. Physique
Figure 82 : Le BPM et le modèle OSI
Les évolutions du marché

Depuis les années 1997/1998, le marché a beaucoup évolué. Différents types d’outils (Workflow, EAI,
…) ont vu le jour. Tous ces outils évoluent aujourd’hui vers des outils de BPMS. Aucun des outils
n’a le travail facile pour prendre en compte les fonctionnalités qui vont les conduire vers un véritable
outil de BPMS. Il est vrai que, en règle générale, les outils de BPM ont une possibilité d’évolution plus
simple. Ils englobent dores et déjà des fonctionnalités de type EAI et de type Workflow et proposent
des possibilités, plus ou moins évoluées, de modélisation des processus. Maintenant, la plus grande
différence se fait au niveau de la modélisation, là où la plupart des outils ne sont pas très évolués
actuellement. C’est pourquoi on distingue 2 marchés et donc 2 catégories d’outils différentes : les outils
de modélisation (catégorisés d’outils d’« Enterprise Architecture » par les anglo-saxons) et les outils de
Business Process Management.
cessaire BPMS
é
Niveau d’évolution nécessaire

volution n
’é
BPM
Niveau d Workflow
EAI
Figure 83 : Niveau d’évolution nécessaire aux outils actuels
Sur le plan des outils de Business Process Management, on voit bien que les éditeurs de solutions d’EAI,
de Workflow et de BPM vont tous vers des outils plus complets que sont les Suites BPM. On peut assez
vite identifier quels éditeurs viennent de quel marché (EAI, Workflow, BPM,…) et on distingue leur
force par leur domaine d’appartenance. Les Suites BPM provenant d’outils d’EAI seront très complètes
sur la partie intégration, les outils provenant des outils de Workflow seront très complets en ce qui
concerne les fonctions de gestion de corbeille d’activités et de tâches, d’interface utilisateur et pour finir
les outils de BPM seront orientés processus et permettront facilement la mise en œuvre de règles métiers,
de processus de bout en bout et prendront en charge correctement les notions de rôles.
Il est vrai que les différents éditeurs cherchent aujourd’hui à intégrer plus de fonctionnalités autour de
la modélisation car tous ne viennent pas de ce monde, et tous ne s’intègrent pas avec des outils externes.
Les éditeurs de solutions de modélisation ne permettent pas facilement de lire les modèles de processus
et surtout les formats des différentes solutions qu’elles soient du domaine de l’EAI, du Workflow ou
du Business Process Management.
BPM
•F onctionna lit é s de
BPI workflow
•ET L
•M od é lisa tion a va nc é e
E AI
•B AM
•Pla ces de m a rch é •P orta il
•Tra nsform a tion •M od é lisa tion •SOA
•Routa g e •Processus sectoris é s
•Ada pta teurs
•Processus a utom a tis és
•Gestion é vénem entielle
1997 2000 2005
Figure 84 : Evolution du marché du BPM
Dans les principes, l’EAI a commencé à parler d’intégration de processus. Devant la complexité de la
mise en place d’une telle démarche, les entreprises l’ont rarement utilisée et pourtant, elles auraient
probablement tiré avantage à le faire surtout sur le plan financier. Bien entendu la démarche implique
de modifier le fonctionnement de l’entreprise mais devant l’instinct de préservation, rares ont été
celles qui l’ont réellement mise en place. Le clivage entre métier et IT doit s’estomper voire disparaître
pour augmenter les chances de succès des projets. L’EAI a été principalement utilisé pour effectuer de
l’intégration par les données et pour bénéficier d’une connectivité applicative plus simple qu’en utilisant
des développements spécifiques, peu évolutifs et trop souvent coûteux.
Est arrivé ensuite le BPI (Business Process Integration) qui a été un peu plus utilisé dans le cadre de
places de marchés pour automatiser les processus achats notamment entre sociétés: mais là encore trop
peu utilisé. Les éditeurs se sont donc penchés sur une sectorisation des processus pour proposer à leurs
clients des processus préfabriqués. Là, encore une fois, l’adhésion n’est que très modérée voire quasi
inexistante. Les spécificités des différents pays utilisateurs ne sont souvent pas prises en compte.
Si l’on passe par une analyse plus approfondie, on s’aperçoit qu’à chaque fois les principes étaient bons,
mais qu’ils n’ont que peu été introduits avec une approche métier. L’approche technologique ayant,
généralement, été privilégiée.
N’oublions pas non plus les moteurs de règles. Certains de ces outils spécialisés introduisent désormais
des fonctions avancées afin de répondre aux exigences de tout outil de BPMS. Les règles étant plutôt
métiers, il est plus facile à ces outils d’évoluer vers le BPM.
Aujourd’hui le Business Process Management est porté de plus en plus par le métier et c’est ce qui en fait
un atout fort pour l’entreprise. Les méthodes ont évolué avec les outils et les démarches d’amélioration
continue des processus de l’entreprise ont très fortement contribué à son essor. C’est très certainement
« LA » discipline de ces 15 prochaines années et son succès est plus que probable. L’entreprise en
recherche de l’amélioration continue peut désormais s’appuyer sur des technologies lui permettant de
piloter son activité avec toute la réactivité que l’environnement concurrentiel actuel lui oblige d’avoir
pour répondre aux nouvelles demandes.
Les outils de BPM disposent de fonctionnalités provenant d’outils de Workflow, d’EAI, d’ETL, de BAM,
avec dores et déjà des fonctionnalités de type « portail d’entreprise » pour permettre l’affichage de l’état
des processus et des corbeilles, des indicateurs associés permettant d’assurer le pilotage opérationnel
attendu, et pour finir, le support des architectures SOA pour permettre de prendre en compte les
services de l’entreprise, mais également la possibilité d’exposer des règles métiers, des sous-processus
ou bien encore des processus sous forme de services web. Il ne serait d’ailleurs pas étonnant que demain
arrivent sur le marché des réseaux de processus réutilisables qui seraient, moyennant finance, mis à
disposition des entreprises. Ces réseaux de processus seraient alors une autre étape complémentaire
pour le Business Process Outsourcing (Externalisation de processus de l’entreprise auprès d’un tiers
de confiance).
Le BPM et le logiciel libre

Ne pas parler de logiciel libre serait une erreur. Il existe des outils de BPM en logiciel libre qui sont mûrs
et qui proposent des fonctionnalités à la hauteur de certaines solutions du marché. Bien entendu, les
fonctionnalités ne sont pas aussi poussées mais pour certaines utilisations satisferont grandement les
besoins. Mais attention ! Certains produits limités en fonctionnalités cachent des sociétés qui proposent
d’acheter une version plus complète.
Le point parfois manquant se trouve au niveau de la documentation de ces outils, qui se trouve être
faible voire inexistante.
Certaines sociétés se spécialisent dans la mise en œuvre, la documentation et la formation sur des outils
BPM libres.
Les standards de notation, référentiel et exécution

Les différents outils de BPM tirent parti des standards disponibles. Mais certains standards ont des
objectifs identiques et se retrouvent parfois en concurrence avec d’autres. Difficile de se faire une idée
quand les standards sont très nombreux.
Dans les principaux standards, on peut citer :

• BPMN - Business Process Modeling Notation : C’est une notation qui permet de dessiner
graphiquement un processus métier. La spécification de cette notation est réalisée par le consortium BPMI
(Business Process Management Initiative). Elle est facile d’utilisation notamment pour des utilisateurs
métiers.
• BPDM – Business Process Definition Metamodel : C’est la définition d’un metamodel qui
permet d’échanger des modèles de processus entre des outils qui n’ont pas, à l’origine, vocation à
dialoguer entre eux.
• XPDL – XML Process Definition Language : C’est un standard défini par le WFMC qui permet
de décrire un processus. Le fichier résultant sera alors utilisé pour exécuter le processus. Il existe des
éditeurs graphiques. Ceux-ci utilisent fréquemment la notation BPMN et exportent ensuite le processus
au format XPDL.
• BPEL – Business Process Execution Language : A la base c’est une spécification créée
conjointement par Microsoft, IBM et BEA Systems. Ce langage, basé sur XML, permet de décrire
l’interaction de processus métiers basés sur des services web (environnement SOA). BPEL est plus une
projection exécutable d’un modèle de processus métier. On parle alors d’orchestration de services.
• BPML – Business Process Modeling Language : Langage de description d’un processus définit
par le consortium BPMI
• BPEL4WS – Business Process Execution Language for Web Services : C’est un language qui
permet de définir des tâches par une combinaison de services web. En fait, ce langage est composé de
2 principaux standards que sont le WSFL (Web Services Flow Language) et le XLANG. Ce language
utilise WS-Coordination qui est un standard qui permet d’assurer la communication entre les services
web et WS-Transaction qui gère le déroulement des tâches.
• XLANG : C’est une extension de WSDL (langage de description des services web) créée par
Microsoft. Le WSDL a principalement 2 manques : les arrêts dus à l’atteinte d’une date limite ou d’une
durée écoulée et les exceptions.
• W3C Choreography : C’est une spécification qui permet de décrire comment les interactions entre
services web doivent se faire. En fait ce langage est utilisé pour décrire l’orchestration de services web
de bas niveau. C’est une orientation technique d’interaction avec les utilisateurs des services.
• UML – Unified Modeling Language : C’est un standard de notation graphique de conception
orientée objet défini par l’OMG. On peut utiliser l’UML pour modéliser des processus même si celui-
ci n’était pas prévu pour cela au départ. Par contre l’approche est moins intuitive que des approches
plus fonctionnelles et aujourd’hui de plus en plus d’entreprises préfèrent utiliser une modélisation plus
naturelle comme le BPMN voire certaines notation d’outils de modélisation propriétaires.
• WSFL – Web Services Flow Language : Langage de description d’une composition de services
web en tant qu’élément d’un processus métier. WSFL considère 2 types de compositions : un processus
métier nommé « flow model » et une collaboration métier nommée « global model ».
Nom du s tandard O rganis me C ommentaire

C'est un référentiel de modèles métiers construit à l'origine par
B PDM l'OMG (Object Management Group). Les modèles de
Business Process Definition Metamodel OMG processus sont formalisés avec la notation BPMN.
Ce langage représente un processus exécutable en incluant
B PE L les liens vers des services web représentant les activités des
Business Process Execution Language OASIS processus.
Initialement c'était l'organisation BPMI (Business Process
Management Initiative) qui a rejoint depuis l'OMG.C'est un
B PML
language XML de description de processus équivalent au
Business Process Modeling Language OMG BPEL
Mode de représentation graphique des processus dévelopé à
B PMN
Business Process Modeling Notation OMG l'initial par le BPMI
L'objectif de ce standard est de créer une interface commune

B PR I
aux éditeurs de solutions de moteur d'exécution de processus
Business Process Runtime Interface OMG de manière à garantir une meilleure interopérabilité
Framework définit pour garantir les collaborations business to
B PS S business. Ce standard supporte le mode transactionnel entre
Business Process Specification Schema OASIS des entreprises
API définie par le WfMC pour permettre l'appel de fonctions du
WA PI workflow ou de fonctions dédiées à l'administration du
Workflow API WfMC workflow.
C'est un langage XML définit par le WfMC et dans le but de
WfXML standardiser les communications basées sur des services web
Workflow XML WfMC entre des moteurs de workflow
Web Services Choreography Description Le langage de chrégraphie des services web créé par le W3C
WS C DL
Language W3C (World Wide Web Consortium)
Langage XML de chorégraphie de services web. Il permet de
WS C I
Web Services Choreography Interface W3C décrire les interactions entre les services web.
Un autre langage XML de chorégraphie de services web. Il
WS C L permet de décrire également les interactions entre les services
Web Services Conversation Language W3C web.
WS F L Web Services Flow Language IBM Language plus simple que le BPEL, mais qui l'a influencé
XL A NG
XMl Language Microsoft Langage XML utilisé par Microsoft pour décrire les processus.
XPDL XML Process Definition Language WfMC
Workflow Reference Model WfMC Modèle de référence d'architecture d'outils de workflow
Figure 85 : Principaux standards de modélisation et exécution
Le tableau ci-dessus récapitule les principaux standards. Il existe d’autres spécifications qui se veulent
être des standards mais qui ne le sont pas. Donc, attention aux acronymes et soit disants standards
affichés par les solutions.
Les processus : véritable patrimoine de l’entreprise
Les processus définissent comment l’entreprise effectue ses activités et sont fonction de son organisation.
L’exécution des processus permet de collecter des données associées. Tous ces éléments constituent
le patrimoine de l’entreprise et doivent être considérés comme tels. De par la place prépondérante de
l’informatique au sein de l’entreprise, les données revêtent un caractère de plus en plus important. Les
données, modifiées au jour le jour, doivent faire l’objet d’une démarche permettant de garantir leur
« première fraîcheur » ainsi que leur bonne utilisation dans le contexte de l’entreprise. Mais la sécurité
et la confidentialité des données doivent être également pris en compte.
Pour cela, les entreprises vont devoir mettre en place des modes de gestion à la fois plus complexes et
plus sécurisés qui vont prendre en compte la propriété de la donnée (système et acteur) ainsi que les
processus associés qui permettront de traiter les fonctions fondamentales sur ces données comme leur
mise à jour et toutes les opérations associés (création, suppression, etc.). Il sera également nécessaire
de définir des processus de gestion (en particulier la gestion des conflits) et de présenter les activités et
conflits associés en fonction des acteurs et applications du système d’information.
On voit donc aujourd’hui une discipline s’esquisser qui consiste à gérer l’information au sein de l’entreprise
que celle-ci soit structurée ou non structurée (on parle de documents scannés). Les processus de l’entreprise
font partie du patrimoine de celle-ci et il est également important de le faire vivre, de le documenter, de
partager la connaissance et de gérer le cycle de vie complet y compris les versions successives.
L’EIM (Enterprise Information Management) est une discipline qui a pour objectif d’apporter un cadre
permettant de gérer les données de l’entreprise aussi bien d’un point de vue métier que d’un point
de vue IT. C’est pourquoi cette discipline contribue à l’alignement Métier/IT car elle permet de se
préoccuper non seulement de la gestion des données, mais également de tout ce qui se trouve autour
de cette gestion, comme la gouvernance, les processus et la communication, le tout construit sur une
vision commune Métier/IT qui est définie en amont de la mise en place de cette démarche.
La qualité des données des processus

La qualité des données est un élément clé pour plusieurs raisons. La première raison est pour le
fonctionnement correct du processus métier. Si celui-ci utilise des données erronées ou mal qualifiées alors
le processus peut se comporter de manière très controversée. On peut même rencontrer un pourcentage
d’exceptions très important. La seconde raison est la qualité des indicateurs de pilotage remontés et
permettant de connaître la qualité d’exécution du processus. Indicateurs erronés, pilotage erroné !
C’est pour ces raisons qu’il est important de passer par une phase de validation de la qualité des données.
Des exemples ont montré des fonctionnements aléatoires de processus du simple fait de cette qualité
des données. Un exemple a même retardé la mise en production du système. Bien entendu, ce cas ne
peut être généralisé.
La qualité des indicateurs est également un point important. Nous verrons d’ailleurs que
l’identification même des données permettant le calcul des indicateurs de performance est
un élément clé de la fiabilité des indicateurs présentés dans les tableaux de bord de pilotage.
6. Le pilotage des processus
Les processus qui s’exécutent ont besoin d’être pilotés afin que, soit des dysfonctionnements, soit
des améliorations possibles soient perceptibles par les utilisateurs. Pour ce faire, les outils de BPM
intègrent une solution de pilotage des processus. Ils doivent également permettre pour chaque activité
de sélectionner les données permettant de construire et de calculer les indicateurs clés de performance
qui permettront de piloter globalement le processus.
Le pilotage des processus apporte la visibilité nécessaire à plusieurs niveaux :

• Les mesures : indicateurs divers quantitatifs ou qualitatifs
• Le suivi : état des activités, tâches, exceptions, erreurs
Il n’y a pas de pilotage de processus sans mesure. Pour mesurer, il est impératif de collecter
des informations. Le pilotage des processus identifiés et la pertinence des mesures effectuées
dépendent de la qualité des données et impactent l’efficacité de l’optimisation future des processus.
Le pilotage des processus

Le pilotage des processus doit permettre de suivre, de mesurer et d’interagir sur le fonctionnement des
processus. Le suivi donne l’état dans lequel se trouve une instance de processus. Par exemple, on sous-
entend par instance de processus la souscription d’un crédit à la consommation de Monsieur Dupond. La
mesure permet de collecter des informations pour évaluer des délais, des comportements, voire d’avoir, en
temps réel, des informations sur les montants cumulés des crédits acceptés par les clients, par exemple.
Le pilotage peut avoir des effets pervers comme l’utilisation des indicateurs à des fins de sanction vis-à-vis
de collaborateurs et c’est très certainement un des effets à éviter à tout prix. Le fait que des indicateurs
puissent être perçus comme des éléments pouvant sanctionner, rendra la démarche de BPM plus difficile à
faire adhérer, alors qu’elle doit, bien au contraire, aider les collaborateurs à transférer leurs efforts réalisés
sur des tâches sans valeur ajoutée vers des tâches plus en rapport avec les objectifs stratégiques. Le pilotage
peut également permettre de comprendre comment on peut améliorer la productivité de certaines tâches. Le
pilotage des processus est la raison la plus souvent retenue pour la première mise en place d’une telle démarche.
La mesure des processus
La mesure permet de collecter les informations nécessaires permettant de représenter la réalité du terrain. Les
informations sont ensuite analysées et exploitées de manière à tirer des conclusions pertinentes. Les actions
permettant de résoudre les dysfonctionnements constatés sont identifiées et réalisées. La mesure permettra,
en outre, une amélioration continue d’un processus et par voie de conséquence de l’activité d’un domaine
et donc de l’entreprise. Pour permettre d’effectuer les bonnes mesures, il est nécessaire de bien évaluer les
données qui permettront de calculer les indicateurs. Les indicateurs choisis seront supervisés pour identifier
de potentielles dérives avec des limites dites « inférieures » et d’autres dites « supérieures ».
B Lim ite sup érieure
Cible de fonctionnem ent
A Lim ite inf érieure
Figure 86 : Mesure des processus
Avec l’exemple de la Figure 23 les indicateurs vont se trouver à un point A très proche de la limite
inférieur, puis vers le point B très proche de la limite supérieure. On distingue dans nos 2 cas une dérive
par rapport à la cible de fonctionnement.
Les mesures doivent permettre de valider l’atteinte des objectifs, mais pour cela ils doivent être
SMART (voir Phase « Define » du chapitre « 3. Amélioration et qualité des processus » page 71).
La prédictibilité des indicateurs
Reprenons l’exemple de la Figure 86. Nous avons nos indicateurs qui se trouvent à un moment vers
le point A (limite inférieure) et à un autre moment vers le point B (limite supérieure). Dans le cas de
certains outils qui ont un fonctionnement prédictif, on a 2 possibilités :
• soit l’outil nous demande à partir de quelle valeur l’indicateur se dégrade et auquel cas, une
alerte vers un utilisateur ou groupe d’utilisateur sera émise,
• soit l’outil est doté de fonctions intelligentes permettant d’identifier des seuils à partir desquels
les indicateurs sont considérés comme dégradés.
Ceci démontre l’importance de la bonne connaissance des indicateurs et de leur construction, car ces
seuils seront à mettre en place et permettront de remonter des alertes pertinentes. Ces seuils sont soit
connus par le métier ou bien alors, la solution est mise en place et on la laisse fonctionner un certain temps
afin de produire des données historiques permettant ainsi de déduire ces seuils ultérieurement.
Une autre possibilité serait de disposer de données historiques stockées dans un entrepôt et de permettre
à la solution d’effectuer des requêtes et calculs sur cet entrepôt pour identifier les seuils franchis avec
plus de fiabilité et d’exactitude.
Ces seuils sont importants, mais sont également à double tranchant. Pour mieux illustrer nous allons
prendre un exemple. Nous sommes dans une entreprise qui vend des fournitures de bureau (gommes,
crayons, papier, …). Cette société a pour habitude d’avoir un montant de commande journalier de
75000 euros. La connaissance des seuils de l’entreprise permet de savoir qu’en moyenne 40 000 euros
de commandes sont confirmées tous les jours à 11h30. Un indicateur qui serait excellent serait d’avoir
40000 euros de commandes à 11h00, ce qui laisserait présager d’une bonne journée en termes de chiffre
d’affaire. Par contre un mauvais indicateur serait si à11h00 le chiffre d’affaire ne s’élevait qu’à 20000 euros,
ce qui pourrait indiquer un problème potentiel. Maintenant il peut y avoir plusieurs sources pour ce
problème. Les commandes sont prises par des télévendeurs qui sont trop peu nombreux suite à une
épidémie de grippe, par exemple. Ou alors, les commandes sont prises par les clients directement et le
portail de prise de commande a un problème de performance suite à une panne du système où à des
dégradations de performances. On comprend alors l’importance d’un système bien mesuré de manière
à garantir un pilotage efficace du processus. Ce cas de figure a eu réellement lieu, à ceci près que le
système avait un composant prédictif et une alerte a été envoyée 30 minutes avant que le problème ne se
pose. Si l’entreprise est correctement organisée, le fait que le personnel soit malade peut se résoudre avec
des solutions alternatives. Par contre dans notre cas, le système commençait à avoir des performances
dégradées et le fait d’avoir été prévenu en avance a permis de ne pas se retrouver dans une situation
extrême. La réactivité apportée permet alors de traiter les dysfonctionnements dans des délais rapides
et limite les pertes potentielles pour l’entreprise.
A titre d’exemple et si on reprend le graphique 86 et en particulier le point A, on peut configurer le

système pour que les alertes soient envoyées à 10 % de la valeur pour laisser du temps pour résoudre
le problème. Nous les appelons les seuils d’alertes inférieurs et supérieurs. Ils sont présentés dans la
figure ci-dessous. Ces seuils sont utilisés de manière à assurer des fonctions prédictives et sont calculés
par comparaisons. Cette fonction de comparaison se nomme le « Baselining ».
B Lim ite sup é rieure
10% Seuil d ’ a lerte sup é rieur
Cible de fonctionnem ent
Seuil d ’ a lerte inf é rieur

10%
A Lim ite inf érieure
Figure 87 : Seuils d’alerte des indicateurs : baselining
Certains systèmes prédictifs de pilotage sont basés sur des mécanismes qui effectuent un apprentissage
et qui sont capables, de manière intelligente, de proposer des seuils. Ces seuils sont alors calculés
par rapport à des données historiques. Des systèmes encore plus évolués peuvent effectuer une sorte
d’apprentissage permettant ainsi de proposer ces seuils en rapports avec des données historiques qui
peuvent être fonction de périodes de l’année. Maintenant, il reste un autre problème à prendre en
compte. Reprenons notre exemple de société de vente de fournitures de bureau pour mieux illustrer : les
ventes sont à 20 000 euros à 11h00. Seul bémol, sous sommes au mois d’Août ! Donc il faut également
avoir la capacité de prendre en compte des périodes pendant lesquelles les indicateurs sont différents
naturellement. Dans notre cas, la période estivale implique que les ventes sont systématiquement à un
niveau plus faible. Il est alors inutile de lever des alertes.
Quel que soit l’outil utilisé, et que la prédictibilité soit intelligente ou pas, il est nécessaire
de pouvoir prendre en compte des éléments extérieurs qui impactent les indicateurs
de manière cyclique et de façon à éviter à ce que des alertes erronées soient envoyées.
Le suivi des processus
Le suivi des processus est une autre partie importante et proposée comme fonctionnalité standard de
la plupart des outils de BPM pour partie.
Figure 88 : Parties suivies d’un processus
Pourquoi pour partie ? Tout simplement parce que les processus et règles sont spécifiques à un contexte
et qu’il est souhaitable de laisser la possibilité de piloter les processus en symbiose avec la stratégie
d’entreprise et des différentes entités de celle-ci. L’autre partie qui concerne l’intégration au système
informatique est le pilotage des interfaces et échanges. Bien souvent des « framework » sont utilisés
pour piloter techniquement la complétude de l’exécution des échanges et de la qualité des interfaces.
Dans ce cas, il faut utiliser, le plus possible, les fonctionnalités du produit afin de limiter l’usage d’un
framework propriétaire qui complexifie la maintenance de la solution.
Dans le cadre du suivi des processus, on va retrouver des éléments comme :
• la durée d’un processus de bout en bout
• l’état de chaque étape d’un processus
• la complétude du processus
• les règles utilisées et des statistiques associées
• etc.
Processus
Processus
Indicateurs
Indicateurs
Règles &
&
Tableaux de bord
Intégration
Dataware
Dataware
Figure 89 : Classes d’indicateurs du BPM
Si on se réfère aux différentes classes liées aux fonctionnalités du BPM, on peut indiquer que nous
pourrons avoir des indicateurs en relation avec :
• les processus : indicateurs en relation avec la qualité du processus, son exécution, en allant
jusqu’aux sous-processus et activités ainsi que les données associées.
• les règles métiers : indicateurs en relation avec les tendances, les règles les plus utilisées
qu’elles soient complexes ou non, etc.
• l’intégration au système informatique : indicateurs en relation avec les échanges entre les
applications, la qualité des services, etc. C’est la couche qui apporte les données utilisées au sein
des tableaux de bord. Cette couche peut être une couche de type EAI mais également d’autres
sources de données comme une base de données en accès direct (un dataware(*) par exemple).
Le dataware permettra de comparer certains indicateurs pour apporter tous les éléments historiques
qui pourraient être nécessaires au bon pilotage des processus.
Les indicateurs clés de performance (KPI)

Les indicateurs clés de performance permettent de mieux piloter l’entreprise à condition qu’il n’y en ait
pas plus de 20 et que ceux-ci soient pertinents. Dans la majorité des cas, les indicateurs sont soit trop
nombreux, soit pas tout à fait en adéquation avec les objectifs de l’entreprise. Des exemples existent
où le management exécutif de l’entreprise tente de gérer avec plus de 40 indicateurs clés et une bonne
partie de ces indicateurs ne sont pas des indicateurs clés de performance.
Pour mieux comprendre, nous allons nous atteler aux différents niveaux d’indicateurs et la différence entre
des indicateurs de résultats, des indicateurs de performance et des indicateurs clés de performance.
Il est également important que ces différents types d’indicateurs soient correctement compris car ils
seront clés dans le succès de la mise en œuvre de la démarche de Business Process Management.
(*) voir glossaire

page 192
Indic ateurs
c lé s
de
perform anc e
Indicateurs
de performance
Indicateurs
de r és ultat
Figure 90 : Indicateurs et hiérarchie
Déjà, la différence entre les indicateurs de performance et les indicateurs de résultat est que les
indicateurs de résultat sont issus d’actions bien identifiées comme la satisfaction client, la satisfaction
des collaborateurs, les bénéfices avant impôt, etc. Au contraire des indicateurs de performance qui sont
issus du niveau de performance de parties de l’entreprise, de lignes de produits, de la profitabilité des
15 clients les plus importants, de la durée de prise en compte de commandes, de la disponibilité de
produits, etc. Cette différence est essentielle et si elle n’est pas correctement appréhendée alors il y a de
fortes chances que les indicateurs identifiés ne permettent pas d’atteindre les objectifs fixés.
Ces indicateurs clés de performance (appelés Key Performance Indicator : KPI) sont utilisés par
différents profils et en fonction de ces profils les indicateurs seront plus ou moins fins et correspondront
principalement au mode de management de l’activité qui se trouve sous leur responsabilité.
Maintenant que la différence est faite dans ses grands principes, il est important que les indicateurs clés
de performance aient des caractéristiques bien précises comme :
• Ces KPI’s sont définis par le management exécutif de l’entreprise,
• Les équipes connaissent et comprennent ces indicateurs et les actions associées
(nous reviendront plus tard sur la notion des actions associées),
• La responsabilité des indicateurs peut être liée à une personne ou à une équipe,
• Les indicateurs sont mesurés 24h/24 et 7j/7 si nécessaire.
Les KPI’s sont souvent en relation avec d’autres indicateurs et si les KPI’s s’améliorent alors la plupart des
indicateurs utilisés dans le calcul des KPI’s s’amélioreront aussi. C’est pourquoi, et dans le but d’assurer
un pilotage fin, il est nécessaire que les indicateurs soient mesurés à des fréquences très rapprochées.
De nos jours et avec la compétitivité nécessaire aux entreprises, il est devenu primordial de mesurer
ces indicateurs clés en « temps réel » ou quasi réel pour un grand nombre des activités réalisées par
l’entreprise. La réactivité nécessaire est telle, qu’une entreprise qui fait partie du Top 5 de son domaine
peut disparaître en quelques années ! Nous verrons d’ailleurs que certaines entreprises utilisent dans leur
démarche, des outils qui tendent vers le prédictif: ce qui leur permet d’identifier des causes probables
et donc non effectives à l’instant de la mesure. La détection prédictive de détérioration d’indicateurs
permet de réagir avant même que l’indicateur clé ne soit dans un état catastrophique. Les actions associées
doivent être identifiées et exhaustives pour remettre en ordre de marche l’activité mesurée.
Indicateurs de performance 80%
20%
10% 10%
Indicateurs cl és de performance Indicateurs de r ésultat
Figure 91 : répartition des indicateurs

Pour comprendre également les KPI’s, il est important de savoir que les indicateurs dans leur ensemble
n’échappent pas à la répartition des 80/20 avec 80 % des indicateurs qui sont des indicateurs de
performance, et les autres 20 % sont répartis en 10 % d’indicateurs de résultat et 10 % d’indicateurs
clés de performance. Ce qui veut dire que si on ne doit pas excéder 10 indicateurs clés de performance,
les indicateurs de performance seront autour d’une centaine au maximum.
La mesure d’indicateurs effectuée pour les managers de l’entreprise est souvent vue par les collaborateurs
comme une source de conflits et pour seul et unique but de réprimandes. Pour éviter ces effets pervers,
une conduite du changement appropriée doit être mise en place. Ceci aussi bien pour les managers que
pour les collaborateurs. Par ailleurs, il faut toujours analyser un indicateur. L’interprétation est bien
souvent raccourcie alors qu’il est toujours nécessaire d’analyser un minimum la cause d’une dégradation
qui est, bien souvent, pas si évidente que cela. Les mesures effectuées ne doivent pas être source de
conflits entre les managers et les collaborateurs.
A chacun ses indicateurs
Pour le pilotage des processus, on se doit d’identifier les indicateurs mais également et surtout les classes
d’indicateurs, car ils doivent être pertinents, certes, mais pertinents pour la population pour lesquels
ils ont été construits. C’est pourquoi, nous pouvons les classer en 4 catégories que sont :
1. Les indicateurs à destination de la direction de l’entreprise (exécutif)
2. Les indicateurs à destination du management
3. Les indicateurs à destination des acteurs des processus (collaborateurs, partenaires, …)
et superviseurs
4. Des acteurs de l’IT
Les indicateurs à destination de la direction doivent leur permettre d’avoir une « vision » de la stratégie
de l’entreprise et de son accomplissement. Ces indicateurs sont plus généraux et ne donnent pas les
informations détaillées lors de dysfonctionnements d’un ou plusieurs processus, même si ceux-ci sont
perceptibles au regard des indicateurs qu’ils pilotent. Un zoom sur le détail des indicateurs aura alors
beaucoup de sens.
Pour les indicateurs à destination du management, ils doivent permettre de prendre des décisions sur
l’amélioration de l’activité comme par exemple, améliorer :
• la satisfaction client,
• les délais de livraison,
• la marge opérationnelle,
• etc.
Les indicateurs à destination des collaborateurs permettent de visualiser leur performance en temps
réel ou quasi réel et par rapport aux tâches qu’ils doivent accomplir. Les collaborateurs ont souvent la
possibilité d’agir à un premier niveau sur leurs indicateurs. Bien entendu, c’est là où l’on doit prêter
attention. Ces indicateurs doivent permettre de piloter et non de sanctionner comme nous l’avons déjà
souligné.
Direction
Vision Stratégique
Management
KPI’s métiers (marge , revenus ,
Productivité , satisfaction client ,
Délai de livraison ,…)
Acteurs des processus
Mesure de la performance des

Processus métiers , optimisation et anticipation , actions
et suivi
IT
Supervision des composants de l’infrastructure

Afin de garantir et mesurer le niveau de service
Attendu au niveau informatique
Figure 92 : Utilisateurs des indicateurs
La dernière catégorie d’indicateurs concerne l’IT. Jusqu’à maintenant, les tableaux de bord ont plus
souvent concerné le métier. L’IT doit tout autant être impliqué car des impacts au niveau de l’informatique
et de ses infrastructures peuvent avoir des conséquences plus ou moins importantes au niveau de l’activité
de l’entreprise et par conséquent, du métier. Prenons par exemple un nœud de téléphones mobiles. Si
celui-ci tombe en panne, alors quel est l’impact sur l’activité ! La conséquence est que les utilisateurs
consommeront moins de temps de communication et, par conséquent, des pertes potentielles de chiffre
d’affaire peuvent être calculées. D’où l’importance de superviser l’informatique et sa performance et
de la lier au métier.
Identification et pertinence des KPI’s
Dans l’identification des indicateurs il est important de choisir des indicateurs de qualité et non d’utiliser
de grandes quantités d’indicateurs.
Les indicateurs clés de performance (Key Performance Indicator) sont des indicateurs qui permettent
de mesurer les progressions/variations. Ces indicateurs, dans le cadre de la gestion des processus,
mesurent l’efficacité du processus, permettent de donner des indications quasi immédiates et apportent
la vision de ce qui est en train de se passer et en particulier une vue, par avance, d’alertes potentielles
(indicateurs prédictifs).
Pour répondre à l’objectif de qualité, il paraît intéressant de se poser les 3 questions suivantes :
• Quelle information ?
• Pour qui ?
• Comment la présenter ?
Une fois les questions posées et pour que les indicateurs soient pertinents, il est nécessaire :
• d’identifier les sources des données : la provenance sera soit l’outil de BPM, soit un dataware
ou toute autre source qu’elle soit interne ou externe.
• de définir la granularité des indicateurs : la granularité peut être différente en fonction de la
dimension. On peut identifier 3 dimensions que sont l’échelle de temps (heure, jour, semaine,
année, …), la géographie (pays, département, ville, …) et le produit (nombre total de ventes
de gommes, nombre de ventes de services, …).
• d’identifier les règles de calcul : comment sont calculés les indicateurs (revenu total, revenu
cumulatif sur une période glissante de 3 mois, pourcentage de vente d’un produit en particulier,
moyennes, etc.)
• de définir les variations : on définit dans ce cas des méthodes de comparaison d’un indicateur
(variation des ventes de gommes des 3 premiers mois comparées aux 3 premiers mois de l’année
précédente, par exemple).
Ensuite, on se doit d’identifier les seuils maximums et minimums des indicateurs. La difficulté dans ce
cas est de disposer de données historiques. Dans le cas de la non disponibilité des données historiques,
on peut mettre en place la solution permettant ainsi au système de collecter des informations un certain
temps afin de créer des données historiques. Il sera, de toute façon, nécessaire de revenir à plusieurs
reprises sur ces seuils. Si l’on dispose d’un dataware ce sera alors notre source de données historiques
dans laquelle nous identifions ces seuils.
En fonction des seuils, il peut s’avérer nécessaire de configurer des alertes : le délai d’attente téléphonique
des clients est trop long. Dans ce cas nous pourrions envoyer une alerte à un superviseur pour soit
mettre plus d’agents dans le centre d’appels, soit dériver les appels en débordement vers un autre centre
d’appels.
On pourra également mettre en place une hiérarchie des indicateurs (année, trimestre, mois, …). C’est
ce que l’on pourra utiliser en tant qu’échelle de temps.
Un autre point important est la mise en place de tableaux permettant de capitaliser les indicateurs et
d’éviter d’avoir des indicateurs redondants. Pour ce faire, on catégorisera les indicateurs par activité,
secteur, produit, etc. en indiquant également leurs sources.
Les tableaux de bord

Un tableau de bord est ce qui permet de visualiser les évolutions d’une activité. Pour cela, un tableau
de bord doit apporter 3 principales fonctionnalités que sont :
• La supervision
• L’analyse
• La gestion
Le tableau de bord est très certainement ce qui sera le plus visible pour les utilisateurs et managers de
l’entreprise. C’est pourquoi, il faut impérativement mettre un accent sur l’ergonomie d’une part et la
pertinence de l’information présentée d’autre part.
Manager
•Gérer les acteurs et processus pour
faciliter les d écisions
•Optimiser les performances
S upervis er
•Superviser les processus et activit és
•Permettre à l’organisation de se
critiques
diriger dans la bonne direction
•Lever des alertes quand des
F o n c tio n n a lit és problèmes potentiels sont identifi és
d ’u n
ta blea u d e bo rd
A nalys er
•Analyser les causalit és par
exploration des informations relev ées
à différents niveaux
Figure 93 : Fonctionnalités d’un tableau de bord
Aujourd’hui, une application se doit d’être ergonomique. C’est identique pour le tableau de bord. De
plus, cette ergonomie doit être en rapport avec la cible d’utilisateurs visée. Il est donc nécessaire de
bien identifier des éléments aussi simples que :
• les groupes d’utilisateurs qui vont utiliser ces tableaux de bord,
• les données qui permettent à ces groupes de piloter leurs activités respectives,
• les modes de calcul et les modes de vérifications associés,
• les actions associées permettant de remédier aux dysfonctionnements constatés.
Par contre, il serait déplacé de croire que le seul fait de mettre en œuvre des tableaux de bord permettra
à l’entreprise de s’améliorer. Si les tableaux de bord présentent des données erronées, ceux-ci n’auront
aucun effet sur la performance de l’entreprise si ce n’est potentiellement un effet contraire faute de
visibilité.
Les tableaux de bord ont pour objectif de permettre de piloter une activité et offrent un grand nombre
d’avantages comme :
• de communiquer la stratégie,
• d’affiner la stratégie,
• d’accroître l’accomplissement de la stratégie,
• d’améliorer la coordination,
• d’augmenter la motivation,
• d’apporter une vue consistante de l’activité,
• de diminuer les coûts et la redondance d’activités,
• de permettre aux utilisateurs de créer et modifier leurs rapports personnels,
• d’apporter toutes les données nécessaires aux utilisateurs leur permettant ainsi d’identifier
les actions à mener pour fixer les dysfonctionnements constatés.
Par contre il faut éviter l’effet pervers qui consiste en une utilisation des tableaux de bord à des fins de
réprimande. Il est préférable d’étudier pourquoi une condition particulière s’est réalisée. D’où l’importance
de la conduite du changement de manière à éviter toutes réticences à l’égard des tableaux de bord.
Les 3 types majeurs de tableaux de bord
Les tableaux de bord sont de plus en plus utilisés pour piloter l’activité d’une entreprise que ce soit au
niveau opérationnel, tactique ou stratégique. Ce sont eux qui permettent de présenter les indicateurs
de pilotage de tout ou partie de l’entreprise.
Il existe 3 types de tableaux de bord :
• Les Tableaux de Bord Opérationnels : Ils permettent aux utilisateurs et aux superviseurs de
piloter les processus et indicateurs opérationnels de leurs activités
• Les Tableaux de Bord Tactiques : Ils permettent aux managers et analystes métier de piloter
les activités au niveau d’un département, de processus et/ou de projets de ces départements
• Les Tableaux de Bord Stratégiques : Ils permettent au management exécutif et leurs équipes de
visualiser les progressions effectuées et contribuent à l’atteinte des objectifs stratégiques
de l’entreprise
Chaque type de tableau de bord répond à une utilisation, à un niveau d’information, à une cible
d’utilisateurs. Pour répondre aux différents besoins, chaque type a un objectif bien précis et pour chacun
d’entre eux, on peut y associer une fréquence. Le tableau ci-après détaille ces éléments.
O pératio n n el T ac tiqu e S tratégiqu e

U tilis atio n Suivi des opérations Suivi des progressions Suivi de a stratégie
Niveau d'in fo rm atio n Détaillée Détaillée et som m aire Détaillée et som m aire
Superviseurs m étiers, IT Responsables, analystes, Direction executive et
U tilis ateu rs
ou experts m anagers d'unités directions
F raic h eu r/F réqu en c e Tem ps réel Journalière/hebdom adaire Mensuelle/trim estrielle
Supervision
O bjec tif
opérationnelle Analyse Gestion et stratégie
Figure 94 : Objectifs des 3 types de tableau de bord
Tableaux de bord opérationnels
Dans le cadre du suivi opérationnel, le besoin consiste en une vue apportée aux utilisateurs et superviseurs
d’une activité leur permettant de visualiser l’efficacité d’un processus opérationnel.
Les indicateurs sont présentés en temps quasi réel (on peut appeler cela le « right time » : au bon
moment).
Au niveau architecture, le tableau de bord va utiliser une couche qui gère les indicateurs soit en offrant
des accès simples à des indicateurs prêts à l’emploi, soit en agrégeant et calculant des indicateurs afin de
les présenter. Ensuite, les données sont stockées soit en mémoire, soit dans un entrepôt. Cet entrepôt
peut être le référentiel d’un outil de BPM, un dataware ou toute autre source à l’exception de bases
de données partagées au sein du système d’information. Dans ce dernier cas, les données seront tout
d’abord accédées par une couche d’intégration (celle de la suite BPM, un EAI, …). Cette même couche
d’intégration apporte les accès aux applications de l’entreprise.
Tableaux
Tableaux de
de bord
bord
Supervision
(indicateurs)
Entrepôt
Entrepôt Mémoire
Couche
Couche int
int égration
égration du
du BPM
BPM
API,
API, EAI
EAI
Applications
Applications
(CRM,SCM, ERP, …) …)
Figure 95 : architecture d’une solution opérationnelle
Les données sont mises à jour de manière dynamique. Le principal objectif étant de superviser des
événements métiers qui surviennent à des fréquences comme la seconde, la minute ou l’heure, mais
plus rarement au delà. Les mises à jour sont souvent limitées à la journée.
De plus, l’entrepôt de données de l’outil BPM n’est pas conçu pour archiver de gros volumes de données.
Un trop gros volume aurait pour conséquence de dégrader, de manière significative, les performances
du système.
Les données utilisées sont bien souvent des données dites de « diagnostic ». Elles permettent de
comprendre le comportement du processus. On peut avoir par exemple le nombre de ventes d’un
produit durant la dernière heure ou le nombre d’accès à un site marchand ces 10 dernières minutes.
Ces tableaux de bord sont simples et la navigation doit être simplifiée au maximum et surtout intuitive.
Ces tableaux de bord ne sont pas créés pour effectuer des analyses complexes mais doivent permettre
aux utilisateurs et aux superviseurs de prendre des décisions immédiates voire d’anticiper certaines
décisions. Les tableaux de bord opérationnels ne doivent pas manipuler de très gros volumes de données.
Les entrepôts ne sont pas dimensionnés pour cela.
Enfin, ces tableaux seront soit proposés par l’outil de BPM soit proposés par des outils tiers. On trouvera
notamment des fonctions similaires dans des outils de BAM.
Tableaux de bord tactiques
Les tableaux de bord sont plus du domaine de la « business intelligence ». Ils permettent néanmoins,
d’apporter aux utilisateurs une notion de « self service » en leur proposant de modifier et faire
évoluer leurs tableaux de bords en fonction de leurs besoins et sans avoir besoin de faire intervenir
des experts informatique pour cela.
Les données sont stockées dans un Data Mart1 ou un dataware. L’utilisateur a alors le choix d’accéder à
des données et de les représenter sous forme de graphiques ou d’utiliser des rapports pré-établis.
Portail
Portail –– Tableaux
Tableaux de
de Bord
Bord
Analyse
Dataware
Dataware Data
Data Mart Rapports
Rapports
EAI,
EAI, ETL
ETL
Applications
Applications
(CRM,SCM,
(CRM,SCM, ERP,
ERP, …)
…)
Figure 96 : architecture d’une solution tactique
Pour l’alimentation du dataware ou du Data Mart, on utilise des outils de type EAI ou ETL. La fréquence
de rafraîchissement des données et rapports est de l’ordre de la journée. Les technologies utilisées pour
la partie analyse s’appuie sur la technologie OLAP(*) et permet d’avoir différentes vues d’un même
indicateur. Le portail permet d’apporter des vues multiples constituées de rapports et tableaux de bord.
Les vues multidimensionnelles permettent une analyse pointue des différents indicateurs présentés.
Ce type de solution ne fait, généralement, pas encore partie de solutions de BPM. Mais on comprend
aisément la complémentarité des 2 solutions. L’importance avant tout est d’apporter à l’utilisateur les
différents moyens d’analyser les performances enregistrées de son activité, de son département. Les
utilisateurs tirent parti des fonctions de zoom avant et arrière (drill down et drill up) pour analyser
pleinement les données présentées.
Tableaux de bord stratégiques
Les tableaux de bord stratégiques sont ceux qui sont proposés en premier lors de la mise en œuvre
d’outils de Business Intelligence. Ces tableaux de bord sont utilisés par l’exécutif de l’entreprise et leur
permet de vérifier l’atteinte des objectifs stratégiques. Ces tableaux de bord utilisent des indicateurs
dits de « haut niveau » et reflètent ce sur quoi les responsables et leurs équipent doivent se focaliser.
Les données de ces tableaux de bord sont rafraîchies mensuellement ou trimestriellement.
Bien entendu, l’utilisation reste identique à tout autre tableau de bord. On souhaite tout d’abord trouver
la cause de la déviation d’un indicateur que celui-ci soit bon ou mauvais. La direction de l’entreprise
souhaite être en capacité de comprendre la cause, sans trop de détails, de la déviation. Les détails sont
nécessaires aux responsables d’unités, de filiales, etc.
La « Balanced Scorecard »
La « Balanced Scorecard (*)», ou tableau de bord prospectif, met en application un mode de management

basé sur la mesure d’indicateurs.
Le principe est de dire que les chiffres que l’on a sont des chiffres du passé. L’entreprise doit donc créer
de la valeur à travers des investissements au niveau :
• Des clients,
• Des fournisseurs,
• Des collaborateurs,
• Des processus,
• Des technologies,
• Et de l’innovation de l’entreprise.
(*) voir glossaire

page 192 C’est pourquoi, cette méthode préconise de voir l’entreprise sous 4 perspectives et de créer des métriques
permettant de mieux la piloter.
Ces 4 perspectives sont :

• Les résultats financiers : Comment l’entreprise doit être perçue par ses actionnaires ?
Les indicateurs sont orientés performance financière.
• Les processus métiers : Pour satisfaire les clients et actionnaires : Quels sont les processus
sur lesquels l’entreprise doit exceller ?
• Les clients : Pour atteindre notre objectif, comment les clients doivent-ils nous percevoir ?
• L’apprentissage et le développement : Pour atteindre notre objectif, comment allons nous
soutenir notre capacité à changer et améliorer ? Comment supporter l’innovation nécessaire ?
Les r ésultats financiers
Objectifs
Mesures
CiblesInitiatives
Les clients Les processus m étier
Objectifs
Mesures
CiblesInitiatives
Vision & Strat é gie
Objectifs
Mesures
CiblesInitiatives
Apprentissage et
d éveloppement
Objectifs
Mesures
Cibles
Initiatives
Figure 97 : Balanced Scorecard

(Source : le tableau de bord prospectif, David P. Norton & Robert S. Kaplan, Editions d’Organisation, 1998)
Les résultats financiers : Cette perspective est et restera toujours la plus importante. Avoir des données
financières pour des périodes données et sur des activités particulières reste le moyen de pilotage préféré
des managers de l’entreprise. Avec les systèmes d’informations actuels, on espère de plus en plus avoir des
rapports et tableaux de bord centralisés et générés automatiquement. Par contre, les données présentées
ne sont pas ajustées par rapport aux données d’autres perspectives. On ajoute également des données
du type estimation du risque et des coûts/bénéfices pour fiabiliser le pilotage.
L’apprentissage et le développement : Cette perspective doit comprendre la formation des collaborateurs

ainsi que le développement de la culture d’entreprise, le tout dans le but du développement personnel
et de l’amélioration de l’entreprise. Aujourd’hui, il est particulièrement important de former le personnel
de l’entreprise sans quoi les connaissances deviennent vite obsolètes. L’obsolescence affecte les résultats
de l’entreprise. Dans le concept de la BSC, l’apprentissage et le développement vont bien au-delà de la
formation en prenant en compte les aspects de tutorat et de coaching. Autre point, la communication.
Il est nécessaire de mettre en place des mécanismes et outils permettant de partager la connaissance
mais également les expériences. Pour terminer sur cette perspective, des outils seront mis en place pour
faciliter la formation et les échanges, comme la mise en place de serveur de gestion de la connaissance,
des forums, des blogs(*), des wiki(*) et autres outils.
Les processus métier : Cette perspective prend en compte les processus métier internes de l’entreprise.
Les métriques des processus permettent aux divers responsables d’en connaître l’efficacité. Les personnes
les mieux à même d’identifier les bons indicateurs sont celles qui utilisent ces processus de manière
quotidienne. Les processus seront d’ailleurs, comme nous l’avons déjà vu, séparés en processus « cœur
de métier » d’une part, et processus de « support » d’autre part.
Les clients : De plus en plus, les entreprises constatent l’importance d’être orienté client et d’évaluer
le niveau de satisfaction du client. Il est simple de comprendre qu’un client mécontent risque fort de
regarder chez un autre fournisseur des produits ou services équivalents. Pour cela, il est important que (*) voir glossaire
les clients soient analysés par catégorie. Les types de processus utilisés pour les produits et services page 192
sont également analysés.
On constate d’ailleurs que le management basé sur les faits est de rigueur. Les métriques utilisées
permettent de piloter l’entreprise en fonction de ses produits, services, processus et opérations. Les
BSC sont de plus en plus utilisées dans un cadre où les tableaux de bord sont générés en temps réel
ou presque de manière à permettre une réactivité accrue et palier, plus rapidement, aux imperfections
constatées et ce qu’elles qu’en soient les causes.
Balanced Scorecard ou Tableau de bord ?
Maintenant que choisir ? La Balanced Scorecard est plutôt orientée sur le suivi de la progression réalisée
et la mesure de l’atteinte des objectifs stratégiques alors que les tableaux de bord sont plus orientés pour
piloter la performance qu’elle soit opérationnelle ou non.
Le tableau ci-après donne quelques éléments permettant de comprendre mieux la différence entre les
deux.
Balanced Scorecard Tableaux de bord
Objectif Suivi des progr ès Suivi de la performance

réalis és
Temps de Mensuel, parfois moins Quasi temps r éel
rafra îchissement
Contexte de mesure Cibles, seuils Exceptions, alertes,
strat égiques seuils op érationnels
Figure 98 : Principales différences entre Scorecard et Tableaux de bord
L’évolution des technologies qui permettent de renseigner les 2 modes de pilotage, fait que de plus en
plus, les Balanced Scorecard utilisent des données rafraîchies dans des délais de plus en plus courts.
Néanmoins les objectifs des 2 modes de suivi restent identiques.
Les technologies OLAP
Certains outils de pilotage utilisent, ce que l’on appelle, un cube OLAP. Les cubes OLAP ou hypercubes
OLAP permettent d’obtenir des informations déjà agrégées pour les besoins des utilisateurs. Ils apportent
une simplicité et rapidité d’accès à l’information. Ils donnent la capacité de manipuler ces données
selon différentes dimensions et utilisent des calculs et des agrégations standards (min, max, avg, …)
ou spécifiques.
Il existe différentes déclinaisons d’OLAP :

• R-OLAP - Relational OLAP : c’est une technique de modélisation et de stockage des données
qui s’appuie sur des données relationnelles.
• D-OLAP – Dynamic OLAP : les données sont mises à jour en quasi temps réel. Les requêtes et
mises à jours doivent avoir un coût le plus bas possible.
• M-OLAP – Multidimensional OLAP : les données sont représentées sous la forme de croisement
de plusieurs dimensions. Les dimensions peuvent avoir plus ou moins de densité.
• H-OLAP – Hybrid OLAP : les données agrégées se basent sur une structure multidimensionnelle
et lorsque l’on a besoin d’accéder aux données élémentaires les tables relationnelles sont utilisées.
• S-OLAP – Spatial OLAP : les données agrégées sont spécialement conçues pour
des analyses géographiques.
Toutes ces technologies ont pour principal objectif de faciliter l’accès aux données et d’en permettre
une présentation sous la forme souhaitée par l’utilisateur. Certaines ont des avantages en termes
d’investissements comme R-OLAP par exemple qui permet de les minimiser. L’idée est plus de donner
un accès facilité tout en offrant la possibilité de voir de mêmes données sous différents angles de vue
et ce, en fonction des différentes catégories d’utilisateurs.
Le CEP, le BEM et EDA
Il existe également 2 technologies qui sont complémentaires d’outils de Business Process Management
(voire parfois déjà intégrées) que sont :
• Le CEP – Complex Event Processing
• Le BEM – Business Event Management
Aujourd’hui les entreprises se devant d’être de plus en plus réactives voire proactives, ces outils permettent
de traiter des conditions complexes et soit d’en automatiser tout ou partie du traitement, soit de
déclencher des traitements parfois manuels en direction d’utilisateurs et de responsables.
Le CEP provient le plus souvent d’éditeurs spécialisés dans le domaine de l’intégration inter applicative
alors que le BEM provient d’éditeurs d’outils de Business Intelligence (BI).
Le CEP
Dans une architecture EDA(*) (voir la section « Le lien entre le BPM et la SOA » page 168) , il y a plusieurs
possibilités :
• Le « Simple Event Processing » : Un exemple d’utilisation serait la détection d’un seuil de
température atteint.
• Le « Stream Event Processing » : utilisé par exemple, pour traiter les flux de commandes.
Les flux ont la nécessité d’être notarisés.
• Le « Complex Event Processing : CEP » : Il y a d’abord évaluation des événements en rapport
avec un modèle (pattern) défini.
Le CEP est une des bases possible pour une architecture EDA. Le CEP fonctionne sur le principe
d’agrégation d’événements et permet de déclencher un événement tiers basé sur une combinaison plus
ou moins complexe d’événements en entrée. Son fonctionnement est en temps réel et permet de ce fait
de filtrer et analyser les données à la volée. Ces outils se doivent d’être très performants pour être capable
de traiter de très gros volumes de données sans pour autant se trouver être le goulet d’étranglement
du Système d’Information.
De part ce fonctionnement, les décisionnaires peuvent être alertés et traiter les cas rapidement. Ceci est
d’autant plus important quand l’entreprise propose des services avec un engagement de qualité.
Outils
Outils de
de ssupervis
upervision
ion
Tableaux
Tableaux dede bord
bord
CCEE PP
EE AI
AI –– EESSBB
Applications
Applications
RR és
éseau
eau
Figure 99 : Le CEP dans le SI
D’ailleurs, certains outils de supervision comportent déjà ce type de technologie de manière à analyser et
traiter les événements en transit dans le système. L’avantage est que l’on peut combiner diverses sources
comme des événements plutôt matériels provenant du réseau par exemple ou des événements provenant
des applications. Les événements peuvent alors être utilisés pour afficher les données et indicateurs (*) voir glossaire
vers des outils de supervision ou des tableaux de bord. L’autre possibilité est que la couche CEP ait à page 192
générer d’autres événements suite à la corrélation et agrégation d’événements en entrée.
E v é ne m e nt A
AApplication
pplication
AA
E v é ne m e nt B
AApplication
EEvvtt AA CC orr
orréélalation
tion
pplication
BB
Référentiel
Référentiel EEvvtt CC
RR èègles
gles
FFiltra
iltra ge &&
ge
aananalys
lys ee
E v é ne m e nt C
AApplication
pplication
CC
Figure 100 : Principe du CEP
Dans notre « Figure 14 : Principe du CEP », nous avons 3 applications. Ces 3 applications génèrent chacune
un événement : A, B et C. Ces événements sont stockés dans un référentiel prévu à cet effet et basé sur
un moteur de base de données du marché. Une structure se prépare dès la réception de l’événement A et
quand un événement B vient compléter cette structure, alors un événement est généré. A cet événement
on peut appliquer des corrélations avec encore d’autres événements, filtrés ou non, sur lesquels on peut
appliquer des règles pour déclencher ensuite un ou plusieurs événements voire actions.
Le BEM
Les outils de type BEM sont des cousins des outils de Workflow. Ils permettent principalement de
superviser des données et, en fonction de certains événements, de générer des tâches manuelles
affectées à un superviseur désigné. Par exemple, on peut configurer un événement qui se déclenche
lors d’une commande d’un montant supérieur à une certaine somme. Dans le contexte du BPM, on
pourrait très bien déclencher l’exécution d’un processus métier ou d’un sous-processus.
Le plus souvent, un outil de BEM, va superviser un événement unique basé sur la valeur d’une donnée.
Ces mécanismes sont plus sécurisés et permettent de mieux garantir qu’un événement ne sera pas oublié.
Toujours basé sur le contenu de la donnée, on peut mettre en place des règles permettant de filtrer le
niveau d’intervention nécessaire afin d’automatiser certaines actions et ne traiter, via un responsable,
que certaines.
Les outils de BEM comportent 4 grandes fonctionnalités comme :

• la détection des données et surtout de leur contenu,
• la corrélation des événements : classifier les événements, maîtriser leur état voire même générer
un nouvel événement
• le déclenchement de tâches manuelles de manière à attendre une décision ou action quelconque
en rapport avec l’événement
• la gestion du cycle de vie des événements, d’autant que certains d’entres eux peuvent avoir un
cycle de vie très long.
Le drill-down, drill-up et drill-through
Les notions de drill-down et drill-up sont des notions de zoom avant et zoom arrière. Pour obtenir toute
l’efficacité nécessaire au pilotage, il est conseillé de mettre à disposition des fonctionnalités permettant
de faire un zoom sur un indicateur en offrant la possibilité à l’utilisateur de visualiser toutes les mesures
qui ont permis de constituer l’indicateur (drill-down) ou d’identifier la mesure de l’indicateur final
agrégé (drill-up).
N’oublions pas que les indicateurs doivent être vérifiables. Ces zooms sont donc importants pour
reconstituer les conditions qui ont causé un dysfonctionnement ou une excellente performance. Les
zooms s’appuient sur des données qui sont déjà agrégées.
Le drill-through permet de naviguer entre des structures de données multidimensionnelles et des

données élémentaires contenues dans des tables relationnelles.
Ces 3 modes ont tous pour objectif de simplifier la recherche d’indicateurs liés entre eux et de permettre
de trouver les causes à des états constatés, en d’autres termes, de faciliter le travail d’analyse.
L’ergonomie des tableaux de bord
Pour qu’un tableau de bord soit ergonomique, il faut utiliser les technologies à disposition comme il
se doit et :
• S’appuyer sur des écrans graphiques : au contraire des rapports, les tableaux de bord doivent
présenter les données sous forme de graphiques. Les couleurs auront toute leur importance et seront
fonction de ce qui doit être rendu le plus évident possible aux regard des utilisateurs.
• Effectuer des choix de types de graphiques en fonction des objectifs : Les types de graphiques
seront fonction des indicateurs. Par exemple des parts de marché seront facilement représentables sous
forme de camembert alors que les variations des ventes ne le serait probablement plus sous forme de
graphique de type points, par exemple.
• Intégrer des animations : Une animation simple mais très utile serait de faire apparaître une
fenêtre avec le détail des données lorsque la souris passe au dessus de la zone d’un graphique. Il faut
par contre éviter les animations inutiles qui ne font que ralentir le chargement des écrans.
• étudier soigneusement le positionnement des informations contenues dans les écrans :
La navigation est importante et doit être la plus intuitive possible. De plus le découpage de l’écran sera
important et dépendant de la résolution des écrans utilisés. L’utilisateur ne doit pas avoir à trop défiler
les pages. Il faut également étudier la symétrie de l’information affichée sur la page. Un tableau de bord
doit être agréable à regarder. On pourra également regrouper des informations dans des zones de l’écran
ou de la page. Pour terminer, les fonctions pour effectuer les drill-down et autres, doivent être simples
d’accès (simples clics ou clic droit par exemple).
Ci-après, quelques exemples de graphiques utilisés au sein des tableaux de bord.
180 90
160 80
140 70
120 60
100 50
80 40
60 30
40 20
20 10
0 0
1 2 3 4 5
Figure 101 : Exemples de tableaux de bord
Chaque type de graphique permet de faire ressortir différemment l’information importante.
Le pilotage de la performance opérationnelle
Le pilotage de la performance opérationnelle est une des briques importantes permettant de piloter les
processus métiers par remontée d’indicateurs clés de performance. Cette brique, partie intégrante de
toute suite BPM, permet de contrôler le comportement des processus et d’alerter les utilisateurs lors de
dysfonctionnements. Il existe des outils nommés outils de BAM (Business Activity Monitoring : terme
inventé par le Gartner Group en 2001) qui permettent de suivre les indicateurs, de les afficher au sein
de tableaux de bord et d’alerter des utilisateurs identifiés lors de dysfonctionnements de ces processus
et plus exactement lors de la dégradation des indicateurs clés de performance. Cette brique de BAM se
trouve intégrée dans certaines suites BPM.
La mise en place d’outils de pilotage tient tout d’abord au besoin de l’entreprise de mieux maîtriser son
écosystème et de se doter des moyens permettant de mesurer et d’optimiser l’efficacité de ses processus
métiers. Le principal but est de faciliter l’atteinte des objectifs stratégiques de l’entreprise.
B AM
T ableaux de bor d,E -M ail, SM S, P D A
Outils de
reporting
P rŽsentation
Temps r
M oteur de
Temps réel
C or r élation, agr égation : s évér ité, actions associ ées, … corr Žla tion
é
el
P r ocessus : d éclencheur s, pr ocessus, activit és, r ègles P rocessus
A P I s, C onnecteur s, E A I , E SB , … I nt Žgra tion
BI
SG BD/R
W eb
P ortail
NSM C R M ,E R P A pplications
sp écifiques DW H Sources
SC M , …
Figure 16 : Architecture d’une solution de BAM
Une solution de BAM peut avoir jusqu’à 4 couches :

• L’intégration : Elle propose les sondes, connecteurs et adaptateurs qui permettent de s’intégrer au
système d’information pour collecter toutes les données qui pourraient être nécessaires lors du calcul
des indicateurs et critères permettant un pilotage efficace.
• Les processus : La possibilité, d’avoir recours à un outil de modélisation et d’utiliser ce modèle
pour indiquer les activités suivies. On peut ensuite configurer toutes les actions qui pourront déclencher
les calculs des indicateurs, l’exécution de règles, le suivi d’une activité ou d’une tâche, etc.
• Le moteur de corrélation : Cette partie propose la mise en œuvre de mécanismes complexes
de corrélation d’événements, d’agrégation d’informations, d’identification de niveaux de sévérité et
d’actions associées, etc.
• La présentation : Cette partie apporte tout ce qui est nécessaire à la présentation des tableaux de
bord. Les indicateurs peuvent être montrés sous forme de graphiques de différents types. C’est à partir
de cette couche que les fonctions de type « drill down » sont proposées et afin de permettre l’analyser
des dysfonctionnements avérés. Cette partie permet également le déclenchement d’alertes qui sont
envoyées sur divers types de terminaux (PC, Pocket PC, Téléphone mobile, etc.). Cette couche est
généralement accessible à partir d’un navigateur Internet.
L’expérience a déjà démontré des utilisations très diversifiées d’outils de BAM. La première utilisation se
fait pour piloter les indicateurs clés de performance, mais des abus de langage font que certains outils de
BAM (présentés en tant que tel) sont plus orientés supervision de flux. Néanmoins, l’utilisation principale
reste au niveau du pilotage des indicateurs métiers. Certaines solutions permettent d’ailleurs de mettre
en place des méthodes de manière à apporter des possibilités de prédictibilité des indicateurs. Pour ces
solutions, on en distingue certaines ayant leurs propres mécanismes assez rudimentaires mais néanmoins
efficaces, pour effectuer un apprentissage du contexte dans lequel l’application de BAM s’exécute et
ensuite remonter des alertes de manière prédictive. D’autres solutions utilisent des calculs statistiques
très complexes permettant de calculer la probabilité que l’indicateur puisse arriver au seuil défini.
Nous verrons également que bien des éditeurs se positionnent sur le marché du BAM alors qu’ils
oublient totalement le B de BAM qui signifie Business (Métier) alors que les services proposés sont bien
souvent des services avancés de supervision d’infrastructure technique ou pour d’autres des services
de supervision applicative.
Le pilotage opérationnel des services métiers

Le pilotage opérationnel des services métiers est devenu un axe également important. Le BSM : Business
Service Management a pour but de superviser la qualité des services métiers proposés par les différents
systèmes à l’intérieur ou à l’extérieur de l’entreprise.
Ces outils permettent de lier le métier aux infrastructures et applications du système d’information
de manière à identifier les impacts du SI sur le métier. Ils indiquent comment les services au métier
performent, et ce, en se basant sur la santé des infrastructures et applications.
Les technologies et applications que l’on peut lier peuvent être du type :
• Infrastructure : les infrastructures du système d’information ( internes ou externes)
• Application management : La gestion des applications (disponibilité, performances, …)
• Service Level management : La gestion de la qualité des services proposés
• Capacity management : Le capacity management (la gestion de la capacité) permet de valider que
les infrastructures sont à même d’accompagner les besoins métiers. On traite des problématiques
de performance, d’optimisation des performances, d’utilisation de services et de planification
de l’utilisation de ces services (Le capacity management est d’ailleurs traité dans le
framework ITIL(*)).
• Problem management : On a, encore une fois, certains liens avec le framework ITIL pour traiter
de la gestion des problèmes. On entend par là, la gestion permettant de limiter le nombre mais
également la sévérité des incidents.
• Identity management : Aujourd’hui, on parle d’ailleurs d’Identity and Access Management
(IAM). Plus simplement, c’est tout ce qui est en rapport avec la gestion des identités dans le but
de les fédérer et d’en faciliter leur gestion.
• Configuration management : La gestion de la configuration des composants du SI.
• Event management : La gestion des événements. Ce peut être du CEP ou BEM.

Application Service Level
Infrastructure Management Management
Event BSM Capacity

Management Management
Configuration Problem
Identity
Management Management
Management
Figure 103 : Les technologies liées au BSM
Tous ces axes peuvent impliquer l’utilisation d’outils de BSM pour assurer un suivi fin lié aux objectifs
métiers. De cette manière, il est possible de valider l’efficacité des services rendus et de leur impact
dans l’atteinte des objectifs stratégiques. (*) voir glossaire
SLA et SLM page 192
Les outils de pilotage apportent naturellement des possibilités permettant d’effectuer un suivi de la
qualité des services proposés aux clients, ainsi que d’apporter des moyens de gérer ces services.
Bon nombre d’entreprises trouveront avantage à proposer des engagements de service à leurs clients et
utiliseront ces outils pour piloter cette qualité de service.
Dans un premier temps, une société qui propose des services va signer un engagement avec son client.
C’est le SLA : Service Level Agreement, donc autrement dit le contrat de service.
Ensuite l’entreprise qui propose ses services, doit avoir des outils permettant de piloter cette qualité de
service. C’est le SLM : Service Level Management.
La concurrence du marché fait que ces notions deviennent de plus en plus importantes et que les
entreprises s’outillent de manière à piloter leurs niveaux de services.
Prenons un exemple plus concret. Une entreprise effectue des placements. Des titres sont achetés et
pour cela l’entreprise utilise les services d’une société spécialisée lui permettant de gérer ce portefeuille
d’actions. Ces actions doivent être valorisées tous les jours, permettant ainsi à l’entreprise de valoriser
ses actifs. La société de prestation pourrait envisager d’avoir des niveaux de services qui sont fonction
des délais proposés pour la valorisation des portefeuilles et facturer ses services en fonction du niveau
d’engagement de qualité. Pour cela, on utilisera des outils qui permettront de vérifier si le contrat est
respecté.
La qualité de service peut être à différents niveaux comme par exemple :

• La qualité de service proposé par un applicatif
• La qualité de service de flux de bout en bout
• Le délai de transit des flux de données et des échanges
• La bande passante d’un réseau
• La qualité d’un réseau et de sa disponibilité
• La qualité du transport d’information
• La garantie de non altération des données
• Etc.
C’est aujourd’hui la raison principale pour laquelle des outils sont mis en place pour piloter cette
qualité de service et les outils de BAM, de BSM ou de BI « temps réel » font référence à des mécanismes
similaires et ayant tous pour principal objectif de piloter la qualité des services proposés. Il en est de
même pour les processus. Demain des BPN(*) seront mis en place et proposés aux entreprises et tous
les clients auront besoin d’avoir des outils permettant de suivre la qualité assurée par les processus
métiers mis ainsi à disposition.
Dernier point: certains outils ont la possibilité de calculer les impacts lors de dysfonctionnements
d’applications et de services allant parfois même jusqu’au calcul des impacts d’un point de vue financier.
Nous avons déjà parlé d’un exemple où un nœud d’accès de téléphones mobiles était en panne. Que
dirait l’opérateur téléphonique qui a mis la maintenance de ces nœuds chez un prestataire s’il avait à
disposition un outil permettant de calculer le manque à gagner à chaque fois qu’un des éléments tombe
en panne ?
(*) voir glossaire

page 192 Nous allons maintenant voir de quoi se compose un moteur de BPM, les types d’outils que nous pouvons
7. Les solutions de BPM
trouver sur le marché, les fonctionnalités plus ou moins avancées de ces outils et les standards qu’ils
utilisent. Aujourd’hui on distingue 2 grandes catégories d’outils de BPM : les outils BPM et les suites
BPM. La distinction entre ces 2 catégories se fait sur le principe qu’une suite est capable de traiter le
cycle de vie complet de bout en bout d’un processus (de la modélisation à l’exécution). Une suite
BPM va également posséder un référentiel contenant le descriptif des processus et données associées
ainsi que les données provenant de leur exécution. Le moteur de BPM a pour fonction d’exécuter les
processus définis. La couche d’intégration permet d’assurer la connectivité avec les applications du
système informatique.
Moteur
Moteur de
de BPM
BPM
Intégration
Intégration
Serveur
Serveur
d’application
d’application
Figure 104 : Briques principales d’une solution de BPM
Le serveur d’application, intégré ou non au sein de la solution, permet de proposer l’accès à des
interfaces utilisateurs apportant les fonctions de gestion des processus ou bien encore, des fonctions
d’administration. On constate également des produits qui par défaut proposent l’utilisation de leur
propre serveur d’application, mais lors de la mise en production, ils peuvent s’appuyer sur des solutions
plus couramment utilisées au sein du système informatique.
Les principaux avantages d’une suite BPM

Les outils BPM de type « suite » offrent aujourd’hui des fonctionnalités qui permettent une gestion
de bout en bout du cycle de vie des processus ou presque. La plus grande rupture étant entre la
modélisation et l’intégration du processus car tous les outils ne sont pas encore basés sur des standards
qui permettent le passage de l’un à l’autre. C’est ce que l’on peut également appeler accostage entre les
modèles métiers et les technologies.
Parmi les avantages d’une suite BPM, on peut citer :

• La réutilisation des systèmes existants : c’est d’autant plus vrai qu’avec l’arrivée du SOA, la
publication des services des applications de l’entreprise permet à l’outil de BPM de les utiliser au sein
de ses processus de manière assez simple.
• La réutilisation de processus métiers : cette réutilisation est surtout fonction de la conception
des processus. Si les processus n’ont pas été conçus pour être utilisés par d’autres, leur réutilisation ne
peut alors pas être faite de manière simple et répandue. Ces processus, et toujours grâce au SOA, peuvent
être également publiés sous forme de services et peuvent ainsi être appelés par d’autres processus.
• Une intégration temps réel : Les outils de BPM permettent d’intégrer les différentes parties du
système et de ce fait apportent un accès temps réel (ou quasi temps réel) aux différentes applications
de l’entreprise.
• Un apport d’agilité au sein du système : Les outils apportent également une certaine agilité
qui elle dépend, comme les processus métiers, de la conception de ceux-ci. En règle générale, il sera
opportun d’externaliser les règles utilisées au sein des processus de manière non seulement à permettre
une réutilisation de celles-ci au sein d’autres processus, mais surtout de pouvoir les faire évoluer
sans impact sur les processus et d’en permettre un déploiement beaucoup plus simple et rapide. Les
utilisateurs métiers pourront d’ailleurs modifier certaines règles sans pour autant devoir demander à
redéployer les processus concernés.
• Une simplification des déploiements : Les procédures de déploiement sont plus simples et
permettent de ne déployer qu’une partie des processus comme les sous-processus ou les règles. Dans
certains cas, aucun déploiement ne sera nécessaire en termes de composants, mais une simple mise à
jour de données permettra de faire en sorte que le processus se comporte de manière différente.
Le Moteur de BPM
Le Moteur de BPM est découpé en 2 grandes parties : Le serveur et le client. Aujourd’hui, la partie cliente
est sous forme de client dit « léger » et donc accessible à partir d’un poste de travail disposant d’un
navigateur Internet à l’exception de la partie modélisation qui elle, est plutôt sous forme d’application
cliente lourde (lorsque l’outil de BPM propose la partie modélisation) que l’on doit installer sur le poste
de travail. Quelques cas utilisent des technologies de type « client riche » (web 2.0(*)) et évitent ainsi
le déploiement d’un outil de modélisation sur les postes de travail.
On va également constater que la plupart des éditeurs présentent leur moteur de BPM de manière
différente et qui dépend de leur contexte d’origine (outil de Workflow, EAI, orchestrateur de services,
…). La grande majorité des acteurs s’appuie sur un serveur d’application web que l’outil BPM provienne
d’un éditeur ou d’une communauté du logiciel libre. L’avantage majeur est que les serveurs d’applications
gèrent déjà toutes les problématiques de haute disponibilité ou de répartition de charge. Le serveur
d’application va également prendre en charge la génération des pages qui vont être présentées aux
utilisateurs internes ou externes à l’entreprise.
Le moteur de BPM est responsable de l’exécution des processus, des moyens de les contrôler et de leur
suivi.
Les Typologies d’outils

Comme nous l’avons déjà indiqué, les typologies d’outils sont différentes de par leur provenance
respective. Par exemple, un outil d’EAI qui a évolué vers le BPM sera très consistant sur la partie
intégration et probablement moins sur la partie modélisation et simulation. Par contre, un outil de
BPM d’un éditeur provenant de la modélisation, aura des fonctionnalités plus riches en modélisation et
simulation des processus qu’un outil provenant d’un éditeur EAI. Ajoutez à cela les outils de Workflow
ayant évolué vers un outil de BPM et vous comprendrez que les outils ne sont pas tous identiques et
comportent, bien souvent, des différences importantes.
Modélisation
Modélisation Simulation
Simulation Moteur
Moteur de
de rr ègles
ègles
Supervision
Supervision des
des Environnement
Environnement
Moteur
Moteur de
de processus
processus processus
processus de développement
développement
Intégration
Intégration Corbeille
Corbeille dd ’activités
’activit és Notation
Notation des
des
applicative et
et de
de tâches
tâches processus
processus
Figure 105 : Architecture fonctionnelle d’une Suite BPM
(*) voir glossaire

page 192 L’architecture fonctionnelle présentée ci-dessus montre les différents composants d’une suite BPM. Le
niveau de couverture des outils du marché dépendra :
• de la provenance de l’outil de BPM (d’un éditeur spécialisé dans le Workflow documentaire,
l’intégration inter applicative, etc.)
• de la sensibilité de l’éditeur sur les grandes fonctionnalités (techniques de modélisation des
processus, conception des modèles de données associés, etc.)
L’outil de BPM : Accompagnateur de la démarche

L’outil de BPM ne doit être considéré que comme l’outil permettant d’accompagner la démarche de
BPM et ne se substituera jamais à la démarche en elle-même. Il est donc important de préparer cette
démarche et ce en adéquation avec les besoins de l’entreprise et surtout de sa culture. L’outil est et
doit rester le moyen de parvenir à une intégration et à un pilotage des processus. Il ne doit en aucun
cas modifier le déroulement de la démarche. Des exemples ont déjà démontré des usages étendus de
fonctionnalités d’outils qui, à l’origine, n’étaient pas prévus pour cette utilisation. Conclusion, des
développements spécifiques ou des utilisations détournées ont été mis en œuvre et ont rendu les
migrations ultérieures bien trop complexes au point d’envisager des changements de produits tellement
les charges de migrations étaient importantes.
D’autres exemples bien plus nombreux, démontrent que les entreprises choisissent plusieurs produits
de BPM qui sont fonction de leurs besoins.
Le choix d’un outil de BPM

Le marché comprend aujourd’hui un grand nombre de solutions de BPM. Pour garantir que l’outil sera
le plus en adéquation avec le besoin de l’entreprise, il est nécessaire de suivre une démarche de cadrage.
Cette démarche de cadrage permet d’identifier les processus qui seront de bons candidats, de connaître
le niveau de priorité de chacun d’entre eux, d’identifier les coûts et le retour sur investissement associé.
La solution qui sera sélectionnée au final ne doit pas l’être du simple fait que la solution d’un éditeur
est déjà utilisée dans un autre cas au sein de l’entreprise ou parce que son prix est très bas, mais plutôt
pour son adéquation aux besoins actuels ainsi qu’aux besoins futurs.
Bon nombre d’entreprises ont effectué des choix qui se sont avérés ne pas correspondre du tout au
besoin. Au final, elles ont dû investir dans des développements spécifiques si coûteux que le ROI (retour
sur investissement) n’était pas au rendez-vous.
Il ne faut pas oublier que le marché du BPM, même si celui-ci est composé d’outils déjà existants depuis
un certain temps, n’en reste pas moins un marché émergeant et que par conséquent, certains acteurs
détournent leur cœur de métier au profit d’un marché en pleine explosion. Dans certains cas, il pourra
s’avérer qu’une seule solution ne répondra pas au besoin. Il sera nécessaire d’avoir un outil de modélisation
et un autre pour l’exécution et le pilotage de processus. Ou alors, on pourra choisir un outil proposant
la modélisation et l’exécution des processus et un autre pour le pilotage de processus.
On peut classer les besoins en 2 grandes catégories que sont :

• La capacité : la capacité de la solution en termes de scalabilité, performances, compatibilité
avec certaines infrastructures pour répondre aux besoins techniques de votre entreprise
• L’adéquation fonctionnelle : Comment la solution répond aux besoins métier actuels et futurs
et la complexité de mise en œuvre.
Une suite BPM est conmporte 3 composants principaux que sont :

• Un serveur d’application J2EE(*),
• Un moteur de BPM,
• Un EAI ou un ESB.
Le serveur d’application J2EE sert d’infrastructure de base. Il a l’avantage d’être connu par les
administrateurs et exploitants et d’être stable.
(*) voir glossaire

Les fonctionnalités d’un outil de BPM page 192
Un outil de BPM doit apporter un certain nombre de fonctionnalités. En fonction de celles-ci, il sera
possible de le catégoriser par rapport à notre matrice.
Dans les grandes fonctionnalités nous retrouvons :

• L’intégration,
• Le support de patterns de processus,
• L’automatisation des processus,
• Les fonctions de Workflow,
• Le moteur de règles,
• Le support d’une API et/ou d’un framework,
• Les outils de développement,
• Les interfaces pour les utilisateurs et les administrateurs,
• L’interface de supervision de l’activité (BAM : Business Activity Monitoring),
• Le référentiel des méta-données.
En fonction de l’outil, ces fonctionnalités seront plus ou moins bien couvertes.
Outils de développem ent Interface utilisateurs
G énérateur
Modélis ate O util de
de
ur Mapping
form ulaire
Supervision technique
E diteur de O utils de D oc um enta
Supervision métier
c ode tes t tion
U tilisateurs Administrateurs
e S
u u
q
i p
n e
h rv
c A P I /F ram ework is
e
t io
n n
o
i
is m
vr é
A utom atisation des processus W orkflow R ègles ti
e e
p r
u
S
R éférentiel des Méta -données
T ransform ation
C onnectivité
Figure 106 : Architecture fonctionnelle d’une suite BPM
Néanmoins, il sera important de bien veiller à ce que l’outil soit capable de satisfaire les besoins réels
et non pas l’affinité à un produit en particulier ou la surabondance de fonctionnalités.
On voit également des solutions très spécialisées sur des problématiques précises, comme les moyens de
paiements dans la finance ou encore les échanges, en utilisant des protocoles de commerce électronique,
etc. Certains autres produits du marché seront plutôt orientés vers la gestion de documents et le Workflow
documentaire. C’est pourquoi, il n’est pas rare de voir plusieurs produits au sein d’une même entreprise.
Pour terminer, certains produits sont liés à une plate-forme matérielle ou logicielle.
L’intégration
La partie intégration donne à l’outil de BPM la capacité de s’intégrer au système informatique en utilisant
des principes qui sont similaires aux outils d’EAI et d’ETL.
Les fonctionnalités apportées par ces outils sont parfois complexes à mettre en œuvre si l’on devait faire
la même chose à partir d’un langage comme le C ou autre.
Dans les fonctionnalités que la couche d’intégration doit supporter, on peut citer :
• Le routage,
• La transformation,
• Le transcodage,
• La traçabilité de bout en bout,
• Un interfaçage normalisé,
• La gestion des messages,
• La publication/souscription,
• La supervision,
• L’administration,
• La sécurité.
Il est important de comprendre les fonctionnalités que peut apporter la couche d’intégration. Mais
encore une fois attention à ne pas en vouloir trop.
Le routage
Le routage permet de faire suivre un message ou des données vers un ou plusieurs destinataires. Pour
cela, la couche d’intégration doit être capable de reconnaître le contenu ou le type de message qui arrive.
Basé sur le type ou le contenu, y compris un champ du message, la couche d’intégration doit envoyer
le message vers un ou plusieurs destinataires ou consommateurs. Ce routage peut avoir besoin de faire
appel à des règles plus ou moins complexes. Ces règles peuvent être métiers ou techniques. Certains
produits proposent des fonctions de filtrage des messages qui, basées sur des requêtes complexes,
permettent de faire suivre les messages dans des délais de traitement extrêmement courts.
Les formats des messages
Les formats des messages peuvent être de différents types : du format spécifique au format XML
normalisé. On voit d’ailleurs le XML se généraliser aujourd’hui et des standards basés sur XML arrivent
à maturité.
Parmi les formats on peut citer :

• cXML – Commerce XML : format XML provenant de la Société Ariba défini pour la gestion
de catalogues et de transactions commerciales sur Internet
• IOTP – Internet Open Trading Protocol : Ce format provient de l’IETF(*) et est consacré aux
échanges de commerce électronique pour le grand public
• OBI – Open Buying on the Internet : Ce format est une normalisation des échanges dans
le domaine des achats
• RosettaNet : Ce format provient de la société Rosetta et concerne des formats de données pour
les échanges sur Internet et les processus métiers
• ebXML – Electronic Business using XML : Ce format est un standard dédié au
commerce électronique
• FPML – Financial Products Markup Language : Ce XML format est dédié aux échanges dans
le domaine de la finance et est différent de standards comme SWIFT par exemple.
• …
Ces formats permettent de faciliter les échanges externes entre des systèmes très différents. L’intégration,
dans certains cas, peut s’avérer extrêmement accélérée.
Les formats pivots
L’expérience a su démontrer que la complexité des transformations d’un format à un autre a toujours
poussé à l’utilisation d’un format plus générique représentant des objets avec une connotation plutôt
orientée métier. C’est ce que l’on appelle les « formats pivots ».
Ces « formats pivots » permettent de décrire un client, une commande, une facture, de manière générique
et surtout de manière à garantir que toute nouvelle application devant utiliser un tel objet puisse trouver
toutes les données qui lui sont nécessaires. On a vu dans le passé des formats pivots créés de toute pièce
et d’autre basés sur le format de l’application principale du système informatique.
Les bonnes pratiques ont également su démontrer qu’il est absolument vital de ne pas vouloir être
totalement exhaustif dès le début. Cela peut conduire à des délais de projets extrêmement longs. (*) voir glossaire
Dernier problème potentiel : sa complexité. En effet, si le format pivot est très complexe, le système page 192
peut avoir à consommer beaucoup plus de ressources pour véhiculer les données au format pivot et
les transformer de l’application source vers le format pivot ou du format pivot vers l’application cible.
Il est donc important de rester pragmatique et raisonnable dans la définition du format.
Charge ensuite soit au bus soit au connecteur/adaptateur d’en effectuer les transformations.
La transformation
La transformation, ou encore appelée le « Mapping » des données, signifie la correspondance de données.

Dans notre cas, le Mapping permet de faire correspondre un champ d’une donnée source vers un champ
d’une donnée cible. Il se peut qu’au passage, nous ayons besoin d’effectuer une correspondance plus
complexe avec des opérations de transformation des données comme des additions, des soustractions,
des pourcentages voire des opérations bien plus complexes.
Nom Nom
Prénom Société
Soci été Adhérant
Adhérant Adresse
Adresse
Figure 107 : La transformation de données
Il est également possible d’effectuer des opérations sur des chaînes de caractères comme de la
concaténation, par exemple. Maintenant, la transformation peut également concerner, en plus des formats
de données, le fait de transformer des données provenant d’échanges utilisant des protocoles différents et
qui n’avaient pas vocation à échanger leurs données ou très difficilement.
Le transcodage
Le transcodage permet de transformer une donnée par une autre donnée en effectuant une recherche
de correspondance. Par exemple, on peut avoir une donnée de type identifiant dans une application
source (SRC001) représentant un client et que ce même client dans une application cible 1 ait un autre
identifiant (CIB001) différent et que ce même client ait, dans une autre application cible 2, encore
un autre identifiant (CIB002). Le transcodage permettra par l’appel d’une fonction de codifier notre
identifiant SRC001 en l’identifiant CIB001 pour l’application cible 1 et CIB002 pour l’application
cible 2. La couche d’intégration propose donc toutes les fonctions pour mettre en œuvre cette fonction
de transcodage. Les données codifiées sont, en général, stockées dans une base de données.
transcodification
Fonction de
transcodification
SRC001
Fonction de
CIB001
CIB002
Base de donn ées
Figure 108 : Le transcodage
La fonction de transcodage peut également retourner plusieurs valeurs en un seul appel soit pour des
raisons fonctionnelles, soit pour des questions de performances.
La traçabilité de bout en bout
La traçabilité de bout en bout permet de savoir, à tout moment, l’état d’un processus que ce soit un
processus d’échange ou un processus métier. Ce type de fonction, si on devait la réaliser avec des
développements spécifiques, serait très complexe à mettre en œuvre. La couche d’intégration permet
de suivre l’état, étape par étape, de tout processus. Bien entendu, le niveau de traçabilité se doit d’être
configurable, car même s’il est parfois complexe à développer, il est consommateur de temps. Un
développement spécifique peut pénaliser le délai de traitement des échanges. C’est pourquoi, il est
nécessaire de bien valider que l’outil permet de tracer de bout en bout tout processus, aussi complexe
puisse t-il être mais également de ne pas abuser de cette fonction.
Un interfaçage normalisé (connecteurs & adaptateurs)
L’EAI permet de normaliser les interfaces d’accès aux données par l’utilisation d’adaptateurs proposés
par la solution. Normaliser ne veut pas dire standardiser. L’EAI ne standardise pas les interfaces, bien au
contraire. Les interfaces sont, bien souvent, liées à l’outil d’EAI quel qu’il soit sauf si l’adaptateur utilise
comme format d’entrée un format standard comme le XML. L’outil peut le convertir en appels spécifiques
à l’application. Par exemple, un adaptateur qui normalise les accès, utilisera XML comme format de
données et les réceptionnera en utilisant des protocoles standards (TCP/IP, etc.) et transcrira en appels à
l’applicatif, en utilisant son langage d’appel natif (comme l’ABAP(*) pour un progiciel comme SAP(*)).
Le seul de standardisation le plus fréquent aujourd’hui passe par l’utilisation de services web.
Figure 109 : Anatomie d’un Adaptateur/Connecteur
Il existe 3 types différents de connectivité avec un outil d’EAI :

• les connecteurs,
• les adaptateurs,
• les APIs.
Un adaptateur/connecteur doit déjà être interfacé dans un premier temps avec les fonctions d’appels de
la gestion des messages (API Message Broker) de l’EAI. C’est en fait la première interface schématisée en
« Figure 2 : Anatomie d’un Adaptateur/Connecteur ». Cette interface est propriétaire à l’exception de
certaines solutions du marché qui se basent sur un standard appelé JCA (Java Connector Architecture).
Ce standard permet de normaliser les accès entre un Broker et une application, mais ne normalise pas
les accès à l’application.
Deux catégories de connectivités sont disponibles : les connecteurs et les adaptateurs. Ils ont des
fonctions différentes avec l’un qui est spécialisé dans les connectivités techniques et protocolaires
(le connecteur) et l’autre qui s’occupe des connectivités applicatives (l’adaptateur). Mais ils peuvent
également comporter des fonctions évoluées comme l’introspection1 qui permet via l’interface de
paramétrage et de programmation de l’EAI d’accéder directement aux objets métiers et de connaître
leurs structures y compris si ceux-ci évoluent. On peut prendre l’exemple d’un progiciel d’ERP2 où les
objets métiers sont publiés et deviennent visibles dans la partie intégration de la solution de BPM.
Les connecteurs assurent une connectivité technique comme :

• L’accès à des bases de données (Oracle, Microsoft SQL Server, IBM DB2, Ingres, …)
• L’accès à des fichiers
• L’accès à des messages au format SWIFT, EDI, XML
• Etc. (*) voir glossaire
Les adaptateurs assurent une connectivité applicative pour des progiciels comme : page 192
• SAP : progiciel de gestion intégré et propriété de la société SAP
• PeopleSoft CRM : progiciel de gestion de la relation client et propriété de la société
Oracle Corporation
• Siebel CRM : autre progiciel de gestion de la relation client et propriété de la société
Oracle Corporation
• Etc.
Dans bien des cas, l’accès à l’application devra se faire au travers d’une interface. Le progiciel est bien
souvent personnalisé et pour mettre à disposition les bonnes données, il est nécessaire qu’entre l’EAI
et l’application un contrat d’interface soit établi.
La gestion des messages (Message Broker)
L’EAI utilise des messages qui sont soit publiés, soit souscrits (en temps réel ou pas) et qui permettent
de bénéficier de fonctionnalités supplémentaires comme :
• La Notification : La notification est un mécanisme permettant de notifier à la couche
d’intégration que quelque chose s’est passé au niveau d’une application par exemple.
• La garantie de délivrance : La garantie de délivrance permet de garantir que le message envoyé
par une application source sera bien délivré à une application cible et ce même si l’EAI devait
tomber en panne d’une part, mais également si l’application cible devait elle-même tomber en
panne ou être inaccessible. Dans ce cas, dès que l’application sera rétablie ou que l’EAI sera
remis en route, le message sera alors traité par l’EAI, envoyé par l’application source ou traité
par l’application cible.
• La sécurité : La sécurité se situe au niveau de la plate-forme, des flux, des accès vers l’extérieur,
des accès aux applications, etc. La couche d’intégration doit prendre en charge une partie des
fonctions de sécurité de la plate-forme globale de BPM et supporter l’utilisation
d’annuaires externes.
Toutes ces fonctionnalités sont apportées par un composant de l’EAI nommé le « Message Broker ». Celui-
ci est, en général, propriétaire, sauf dans le cas de plates-formes basées sur des serveurs d’applications
qui utilisent un ESB(*).
La publication/souscription de messages
L’EAI a apporté une utilisation intensive des mécanismes de messages. Les clients de l’EAI sont ainsi soit
des producteurs de messages, soit des consommateurs de messages. Ces mécanismes existent également
au sein des ESB si ce n’est que les accès sont plus normalisés par l’utilisation de services web.
L’exemple ci-après nous montre le fonctionnement de la mécanique de publication et de souscription.
Mes s age B roker
A pplic ation
1
ou agent F ile d’ attente 5
A
Identific ation A pplic ation

des ou agent
s ous c ripteurs
B
3
N otific ation 4
des
s ous c ripteurs
(*) voir glossaire Figure 110 : Mécanisme de publication/souscription

page 192 Un message peut être souscrit, c’est-à-dire qu’un client peut s’abonner, comme une personne s’abonne
à un magazine, à un message d’un certain nom ou type particulier afin de le recevoir. Un message
peut être également publié et le client envoie un message à l’EAI sans connaître les destinataires de
ces messages. Ces mécanismes permettent un certain niveau de découplage avec les applications.
Dans notre exemple, l’application ou agent A détecte une modification au sein de l’application avec
laquelle il est interfacé et publie sur le bus (Message Broker) un message .
Le « message broker » doit ensuite

• placer le message dans une file d’attente,
• valider que le message est unique et donc n’a pas déjà été publié,
• identifier les souscripteurs de ce message ,
• notifier les souscripteurs de la mise à disposition des messages ,
• l’application ou agent B consomme ensuite le message ,
• dans certains cas, un message peut être publié soit automatiquement soit à la demande
par l’application ou agent B afin de notifier que le message a correctement été traité de manière
technique, fonctionnelle ou les 2 .
A pplic ation
ou agent
B
A pplic ation
ou agent
A pplic ation
ou agent C
Mes s age B roker
A
A pplic ation
ou agent
D
Figure 111 : Publication de 1 vers N
L’un des autres avantages de la mécanique de publication/souscription est de permettre à un Agent A

de publier un message sur le « Message Broker » et que ce message soit consommé par les agents B, C
et D. C’est ce que l’on appelle la publication de 1 vers N destinataires.
Pour finir, l’un des autres avantages est le mode de publication qui peut se faire soit en synchrone,
auquel cas l’émetteur attend une réponse du récepteur, soit en mode asynchrone et dans ce dernier cas,
l’émetteur publie le message sans attendre de réponse de la part d’un quelconque récepteur. Une réponse
pourrait être envoyée ultérieurement à l’émetteur initial qui alors traiterait ce message de réponse.
La supervision
La supervision avec un EAI peut se faire de différentes manières et à plusieurs niveaux.

Un flux de bout en bout peut à un moment donné, changer d’état, se terminer avec ou sans erreur,
attendre des réponses d’une application ou agent, etc. Toutes ces étapes, tous ces états doivent pouvoir
être supervisés. C’est ce qui s’appelle une supervision au niveau flux.
Un autre niveau de supervision concerne une supervision technique permettant de connaître, de

manière exhaustive, l’état :
• de connecteurs et adaptateurs
• du bus de messages
• de la mémoire consommée
• etc.
Tous ces indicateurs techniques doivent pouvoir être supervisés. Dans certains cas, l’outil permettra
de le faire en installant un agent qui sera capable de lire les journaux, d’attraper les erreurs et messages
d’alertes pour les envoyer sous la forme de messages SNMP(*), etc. Cet agent communiquera alors
avec une console de supervision utilisée par les exploitants et permettant d’identifier les causes des
alertes et erreurs.
Des standards existent sur le marché comme SNMP, OMI(*) ou JMX(*). Ces standards définissent soit
des formats de messages de supervision, soit des APIs permettant d’administrer et superviser à distance
la couche d’échange et d’intégration.
L’Administration
Les fonctions d’administration peuvent être de 2 types et sont fonction de la supervision :

• Technique : cette supervision doit comprendre la gestion des utilisateurs de la plate-forme, de
leur authentification et de leurs droits. Mais également l’accès à des statistiques sur les flux et messages
passés, ceux en cours et ceux en erreur de manière à apporter toutes les fonctions permettant d’analyser et
d’identifier les causes de ces erreurs. Pour terminer, la solution doit proposer des fonctions de sauvegarde
et de restauration des paramètres et données des échanges, flux et processus d’échanges.
• Fonctionnelle : Les superviseurs fonctionnels sont bien souvent des utilisateurs métier. C’est
pourquoi, ces utilisateurs doivent disposer de mécanismes leur permettant d’identifier les flux qui
sont en erreur ou non, car un superviseur métier doit pouvoir indiquer si oui ou non le processus
concernant un client bien identifié est terminé ou non (par exemple une commande et son état). Dans le
cas d’une erreur, un superviseur fonctionnel doit pouvoir regarder pourquoi son message est en erreur
et le corriger si besoin est. Dans le cas où le superviseur fonctionnel ou métier ne serait en capacité
d’identifier la cause de l’erreur, il devra avoir la possibilité de transmettre à un superviseur technique le
message en erreur pour en permettre une correction technique (Application non disponible, problème
de réseau, bogue, etc.).
La sécurité
La sécurité d’un EAI est à 3 niveaux :

• Sécurité des flux : Dans certains cas, une authentification des messages et flux est nécessaire. La
solution doit également proposer des fonctions permettant d’assurer un bon niveau de confidentialité
et d’intégrité des informations véhiculées. Pour finir, des mécanismes de garantie de livraison et de non
répudiation seront importants en particulier dans des échanges B2B ou B2C.
• Sécurité de l’invocation de services web : Certains messages ou flux peuvent être désormais
produits ou consommés par des ressources qui font appel à un service web. Les services sont alors
sécurisés de manière à en garantir les accès, l’intégrité ainsi que la sécurité que les appels à ces services
soient intérieurs ou extérieurs.
• Sécurité des fonctions d’administration et de supervision : Pour administrer ou superviser
des flux ou messages, il est nécessaire que l’outil propose les fonctions apportant une vision globale
des paramètres et des échanges. Ces informations sont accessibles en fonction de profils utilisateurs
permettant ainsi de proposer une vision adaptée à chacun d’entre eux : administrateur, superviseur
technique, superviseur fonctionnel, etc.
Les patterns de processus
Les outils de BPM doivent supporter la mise en œuvre de typologies de processus différents. C’est
ce que l’on appelle les patterns (ou patrons au sens de la couture) de processus. Ces patterns sont
essentiels à la mise en œuvre et au fonctionnement des processus métiers. Les patterns que nous allons
décrire, permettent de comprendre les enchaînements d’activités et les mécanismes associés qu’un
processus métier doit pouvoir supporter. Certains d’entre eux sont des cas particuliers mais peuvent
nécessiter, s’ils ne sont pas supportés par la solution, de devoir fournir des efforts importants en termes
de développement et d’impliquer des coûts élevés.
La séquence
La séquence est un enchaînement simple d’activités. Dans notre schéma, le processus démarre : une
activité A est exécutée, puis une activité B et, pour finir notre processus, une activité C.
(*) voir glossaire
page 192
Ac tivité A Ac tivité B Ac tivité C
Figure 112 : Pattern : La séquence

Le Split
Le « Split » (ou séparation) se déroule comme suit. Un événement déclenche le processus, puis l’activité
A est exécutée. Ensuite une passerelle (1) détermine qu’il est nécessaire de séparer le processus en 2
activités distinctes et autonomes : activités B et C. Lorsque ces activités sont terminées, le processus est
terminé. Les activités B et C peuvent se terminer dans des délais différents.
Ac tivité B
Ac tivité A P as s erelle 1 P as s erelle 2
Ac tivité C
Figure 113 : Pattern : Le Split

La jointure
La « jointure » (Merge en anglais), se déroule comme suit : Le processus est déclenché par deux
événements qui lancent les activités A et B. L’activité A est exécutée et une fois terminée va jusqu’à la
passerelle (1) et attend. L’activité B est également exécutée et une fois terminée va jusqu’à la passerelle
(1). L’activité C peut alors démarrer. Le processus prend fin lorsque l’activité C est terminée.
Ac tivité A
P as s erelle 1 Ac tivité C
Ac tivité B
Figure 114 : Pattern : La jointure
La jointure synchronisée
Dans le cadre de la jointure synchronisée, nous pouvons avoir 2 cas de figure :

• Cas 1 : Le processus passe par l’activité A puis s’arrête à la passerelle (2). Attend que l’activité B
soit exécutée. Une fois l’activité exécutée, le processus continue ou se termine.
• Cas 2 : Le processus passe par l’activité B puis s’arrête à la passerelle (2), attend que l’activité A
soit exécutée. Une fois l’activité exécutée, le processus continue ou se termine.
Ac tivité A
P as s erelle 1 P as s erelle 2
Ac tivité B
Figure 115 : Pattern : La Jointure Synchronisée
Un autre cas pourrait d’ailleurs consister en de multiples activités qui pourraient exécuter une dernière
activité que si et seulement si tous les activités ont été exécutées et pas avant. Cet effet de synchronisme
multiple peut s’avérer intéressant dans certains cas.
Les choix multiples
Dans le cadre des choix multiples, nous allons avoir 3 cas différents. Le processus démarre et l’activité
A est exécutée. Une fois cette activité terminée, le processus va à la passerelle (1).
Ac tivité B
Ac tivité C
Figure 116 : Pattern : Les choix multiples
3 cas de figure se présentent :

• Cas 1 : la passerelle décide de lancer l’activité B uniquement et une fois celle-ci terminée,
le processus prend fin.
• Cas 2 : la passerelle décide de lancer l’activité C uniquement et une fois celle-ci terminée,
• Cas 3 : la passerelle décide de lancer les activités B et C et une fois les 2 activités terminées,
Le XOR
Le XOR a un caractère exclusif et fonctionne comme suit : le processus est démarré par un événement
et lance l’activité A. Lorsque l’activité A est terminée, la passerelle (1) effectue la décision de transférer
la suite du processus vers l’activité B et exclusivement à l’activité B. Une fois l’activité B terminée, le
processus prend fin. Une autre instance de ce processus démarre, l’activité A est exécutée et se termine
pour arriver à la passerelle (1).
Basée sur les données contenues dans le processus, la passerelle fait cette fois le choix de transférer la
suite du processus vers l’activité C. Une fois l’activité C terminée, le processus prend fin.
Ac tivité B
Ac tivité C
Figure 117 : Pattern : Le XOR

La notion de Cycle
La notion de cycle peut être importante pour un processus qui a besoin de dérouler plusieurs itérations
de plusieurs activités. Le processus démarre et l’activité A est démarrée. Une fois terminée elle va
directement à l’activité B, puis C. Le processus passe à la passerelle (2) qui elle décide de re-transférer
le processus vers la première passerelle (1 : par exemple pour des traitements non effectués ou réalisés
à un premier niveau). Alors, le processus passe de nouveau à l’activité B puis C. La seconde passerelle
(2) décide de passer à l’activité D. Celle-ci terminée, le processus prend fin.
Ac tivité A Ac tivité B Ac tivité C Ac tivité D
P as s erelle 1 P as s erelle 2
Figure 118 : Pattern : La notion de cycle
Dans notre cas, on va avoir les activités B et C qui vont se comporter d’une certaine manière lors du
premier passage (voire d’attribution d’activité à un utilisateur en particulier), et une fois les activités
effectuées, la seconde passerelle va re-transférer le processus vers la première passerelle de manière à,
suite aux informations et actions effectuées lors de la première itération, à re-exécuter les activités B
et C mais avec d’autres utilisateurs ou systèmes et ce, afin que le processus de traitement soit correct
jusqu’à permettre l’arrivée à l’activité D.
Fin de processus explicite ou implicite
La fin du processus peut être soit explicite : on attend que les 2 activités soient terminées pour déclencher
un événement indiquant que le processus est terminé, soit implicite et c’est à la fin d’une des 2 activités
(C ou E) que le processus s’achève de fait et sans déclenchement d’événement spécifique.
Ac tivité B Ac tivité C
Ac tivité A
Ac tivité D Ac tivité E
Figure 119 : Pattern : Fin implicite
Annulation du processus
Pour l’annulation d’un processus, le principe est simple et réside dans le fait que l’on a la possibilité
d’annuler le processus dans son ensemble et sans se soucier de son état d’avancement.
Annuler
Figure 120 : Pattern : Cas d’annulation
Annulation d’une activité du processus
L’annulation d’une activité consiste en une fonction permettant de choisir l’activité à annuler et soit de
terminer le processus soit de relancer une activité du processus.
Annuler
Figure 121 : Pattern : Annulation d’une activité
Activités multiples sans synchronisation
Le processus est lancé et exécute l’activité A, puis l’activité B. L’activité B lance 3 activités C, D et E et
passe aussitôt à l’activité F. L’activité B ne reste pas en attente d’un quelconque retour des activités C,
D ou E.
Ac tivité A Ac tivité B Ac tivité F
Ac tivité C Ac tivité D Ac tivité E
Figure 122 : Pattern : Activités multiples sans synchronisation
événement remarquable
Ce cas est plus complexe. Prenons notre « Figure 16 : Pattern : Evénement remarquable ». Le processus
démarre. L’activité A est réalisée puis les activités B et F sont déclenchées. Les activités C et G sont
ensuite exécutées. Arrivé aux activités D et H, on peut rencontrer alors 3 cas de figure :
• Cas 1 : Les activités D et H n’ont pas besoin d’attendre un événement provenant de l’activité
opposée (D n’attend pas H et vice versa).
• Cas 2 : L’activité D se place en attente d’un événement remarquable de la part de l’activité H.
Une fois reçu, le processus continue jusqu’à achèvement en passant par l’activité E.
L’activité I n’étant jamais déclenchée.
• Cas 3 : L’activité H se place en attente d’un événement remarquable de la part de l’activité D.
Une fois reçu, le processus continue jusqu’à achèvement en passant par l’activité I.
L’activité E n’étant jamais déclenchée.
A c tiv ité B A c tiv ité C A c tiv ité D A c tiv ité E
A c tiv ité A A c tiv ité J
A c tiv ité F A c tiv ité G A c tiv ité H A c tiv ité I
Figure 123 : Pattern : Evénement remarquable
Multi instances d’activités
Autre cas, l’exécution d’instances multiples d’une activité. Notre processus démarre avec une activité A
puis réalise une activité B. Ensuite, et basé sur des données, des critères particuliers, la création manuelle
d’instances supplémentaires pour des raisons métiers, de multiples instances de l’activité C sont créées
et exécutées. Le processus prend alors fin, lorsque toutes les activités C et D sont terminées. Le nombre
d’instances de l’activité C n’est pas connu d’avance.
A c tiv ité A A c tiv ité B A c tiv ité C A c tiv ité C A c tiv ité C A c tiv ité D
Figure 124 : Pattern : Multi instances d’activités
Activités parallèles non ordonnancées
Pour ce processus, l’activité A est exécutée, puis indifféremment les activités B, C et D sont exécutées
dans n’importe quel ordre. L’activité E ne sera exécutée que quand les 3 activités B, C et D seront
terminées. Le processus est terminé dès la fin de l’activité E.
Ac tivité B
Ac tivité A Ac tivité C Ac tivité E
Ac tivité D
Figure 125 : Pattern : Activités parallèles non ordonnancées
Choix manuels
Dernier cas, apporter la possibilité d’un routage manuel. Le processus est démarré et l’activité A est lancée.
Cette activité A est manuelle et permet notamment à l’utilisateur de choisir quelle sera l’activité suivante :
B ou C. Le processus se terminera lorsque le choix est effectué et l’activité concernée finalisée.
Ac tivité B
Ac tivité A Ac tivité C
Figure 126 : Pattern : Choix Manuels
L’automatisation des processus
L’automatisation des processus, pour ce qui est bien entendu automatisable, doit permettre d’utiliser
les fonctions d’intégration et d’enchaînement d’activités.
commandes
Service des
Ac tivité A Ac tivité B
Service des
commandes
CRM
BPM
BPM
CRM S ervic e A S ervic e B
Gestion de
stock
S ervic e C S ervic e D
Gestion de stock
Figure 127 : Processus automatisés
Certaines solutions pourront être pauvres en possibilités d’intégration et dans ce cas nécessiter l’utilisation
d’un produit tiers comme un EAI ou un ESB par exemple.
L’intérêt de certaines solutions est de permettre un mix de processus automatisés et de processus

manuels.
Les sous processus
La solution doit permettre de concevoir des processus réutilisables par de multiples autres processus.
Prenons l’exemple de la souscription d’un crédit. Le processus d’évaluation de l’éligibilité d’un client
pour un crédit doit pouvoir être réutilisé dans des processus de souscription de crédit qui proposeraient
des offres différentes mais pour lesquelles la procédure d’éligibilité reste identique.
Ou bien encore, on doit pouvoir instancier et dériver un processus pour ne modifier qu’une partie qui
serait spécifique à un pays par exemple. On pourrait utiliser le terme de fonction dérivée dans ce cas.
La gestion de corbeille
La gestion de corbeille est un composant hérité des outils de Workflow permettant à un utilisateur ou
un groupe d’utilisateurs de visualiser les activités et/ou tâches qui lui sont affectées. Cette affectation doit
se faire selon des critères définis et permettant, dans le cas de règles particulières ou d’indisponibilité,
de les transférer automatiquement ou manuellement vers d’autres acteurs disponibles ou habilités à
les réaliser. Dans le cas d’allocation d’activités ou de tâches, on peut envisager qu’elles soient allouées
en fonction d’un produit, d’un service ou d’une typologie de client. Les tâches peuvent être transférées
suite à une action réalisée par un superviseur métier ou suivant des règles métiers prédéfinies.
Dans le cas de règles métiers, on peut envisager le transfert d’une activité de traitement d’une commande
vers un superviseur en fonction de son montant (dépassement maximum autorisé par exemple). D’autres
mécanismes plus complexes peuvent permettre de transférer des activités ou tâches en fonction du niveau
d’occupation des différents utilisateurs : seuil de traitement maximum de commande par heure.
Un autre cas peut également se présenter. Une activité est allouée à un utilisateur. L’utilisateur dépasse
un délai de traitement prédéfini de l’activité. Elle est alors réallouée à un autre utilisateur voire escaladée
à un superviseur pour être traitée.
Le superviseur d’une corbeille de groupe doit également pouvoir réallouer des activités et/ou tâches et
l’outil doit proposer de les visualiser de différentes manières.
Les Modes de routage
Le routage est un point très important en fonction de l’utilisation de l’outil de BPM qui est désirée
(gestion de documents, automatisation de processus, suivi de tâches,…).
Le routage peut être :

• automatique ou manuel : le routage automatique est utilisé dans la gestion de processus d’échanges
inter applicatifs. Il est basé, bien souvent, sur le contenu. Le routage manuel est utilisé dans le cadre
de gestion d’activités
• conditionnel : Le routage conditionnel correspond à des règles mises en place afin d’assurer un
routage automatique des différentes activités et tâches.
• fonction de délais et de priorités : Basé sur des critères contenus au niveau des données des
processus ou alors en fonction du type d’instance de processus, on doit être capable de router en
priorité des activités ou tâches. D’autre part des activités ou tâches restées dans une corbeille
au-delà d’un certain délai voire d’une certaine heure, doivent pouvoir être re-routées vers
d’autres utilisateurs.
• basé sur des exceptions : Certaines exceptions peuvent être utilisées pour effectuer le routage
d’activités ou tâches. On peut d’ailleurs utiliser ce moyen de routage pour mettre en place des
procédures de compensation.
• basé sur criticité : On peut placer des niveaux de criticité basés sur des données contenus au
sein du processus ou sur des critères de fonctionnement du processus pour permettre ainsi un
routage vers d’autres acteurs (humains ou systèmes).
• basé sur des rôles : Le routage basé sur des rôles permet de router des instances de processus
en fonction de la population à laquelle s’adresse ces processus, activités ou tâches. Par exemple,
on peut router les activités ou tâches en fonction de produits ou services traités par des groupes
d’utilisateurs particuliers.
Bien entendu, ces modes de routages peuvent s’adresser à des systèmes ou à des acteurs humains. Ce
qui est important, c’est d’être capable de traiter les différents modes. Malheureusement, tous les produits
ne le permettent pas.
Procédures de « rollback » ou de compensation
Le Rollback est l’action permettant de revenir en arrière dans le cas où cela s’avèrerait nécessaire.
Les procédures de «Rollback » sont couramment utilisées dans un contexte d’utilisation de bases de
données. On peut assimiler le Rollback à une fonction d’annulation de frappe permettant de revenir à
un état antérieur stable.
Il n’est pas toujours disponible. Même si une application utilise une base de données, ce n’est pour
autant que l’on a la possibilité de revenir en arrière.
Des exemples d’applications permettent de dire que certaines d’entre-elles ont des mécanismes pour
désactiver un client, par exemple. Des procédures de compensation sont alors mise en œuvre et
permettent, dans le cas d’une volonté de retour arrière, de procéder à la désactivation des données qui
ont été précédemment envoyées à l’application. De cette manière, les données ne seront plus visibles
aux utilisateurs de l’application, mais restent toujours présentes au sein de sa base de données.
Un autre exemple de Rollback serait de permettre à un processus de revenir à un état antérieur de

manière à permettre à l’utilisateur de revenir sur des choix, des décisions prises par un client qui
souhaite revenir sur celles-ci.
Le support d’API et de Framework
Le WfMC a défini une architecture type, comprenant notamment des APIs. Il peut être intéressant
d’avoir de telles APIs notamment pour l’interopérabilité de la solution. Il est vrai que si cela ne concerne
que l’interopérabilité, le SOA apporte des réponses à ces besoins. Néanmoins, on peut avoir recours
à de telles API notamment pour permettre un pilotage à distance de certains processus ou parties de
processus y compris des activités ou tâches et de permettre d’interagir à distance sur celles-ci.
Les outils de développement
Les outils de développement proposés par la solution de BPM doivent permettre de développer la totalité
des fonctions nécessaires et de manière productive. Du niveau de productivité des outils dépendra
le ROI global. N’oublions pas que ce qui va être important c’est la rapidité de développement, plus
exactement de paramétrage, de mise en œuvre ainsi que de déploiement des processus, en particulier
lorsque ceux-ci sont dans un cycle d’amélioration continue.
Nous allons regarder les principales fonctionnalités que doit comporter un outil de BPM et à quoi elles
servent. Même si les outils de BPM sont destinés à l’accompagnement de l’amélioration des processus, il
est nécessaire de pouvoir compter sur l’outil dans le cadre de la démarche et de veiller à ce que celui-ci
propose et s’appuie sur certains standards en adéquation avec les besoins métiers.
Les outils de développement de l’outil de BPM doivent comprendre :

• un outil de modélisation des processus et des activités
• une interface permettant de créer des pages et des formulaires à destination des utilisateurs
• des outils permettant de définir les correspondances entre les données (Mapping)
• une interface permettant l’édition de code source
• des outils permettant de tester les processus, activités et règles métiers
• à minima, une interface permettant de gérer les versions de processus voire d’apporter
un outil intégré de gestion des versions
• des outils de documentation des processus ou, à minima, de configurer des liens avec
des documents externes
Modélisation de processus
L’interface de modélisation des processus est l’outil permettant de dessiner les processus, sous processus,
activités et tâches. Cet outil s’adresse plutôt au métier qui va l’utiliser pour définir ses processus. Il doit
être intuitif et se reposer, si possible, sur des standards. Dans certains cas, les processus seront modélisés
dans un outil spécifique puis importés dans la solution de BPM. Dans ce cas, il va être important d’avoir
à identifier le pont possible entre les outils permettant ainsi de réduire les risques d’erreurs dues à des
doubles saisies.
Aujourd’hui de plus en plus d’outils supportent des méthodes d’import/export. On parle, par exemple,
de XMI (XML Metadata Interchange), standard XML proposé par l’OMG permettant d’importer et
d’exporter des définitions de processus compréhensibles par des outils variés.
Le BPMN est une bonne alternative. Cette notation a pour vocation de devenir le standard de fait pour
la modélisation des processus en ayant un lien direct avec le XPDL qui est son pendant pour l’exécution
des processus et qui est de plus en plus utilisé par les outils de BPM notamment les plus récents.
Les outils de modélisation utilisent des palettes d’objets qui peuvent être glissés/déplacés sur une feuille
de travail. On doit également pouvoir effectuer des « copier/coller » de tout ou partie de modèles.
Interface de création de pages et formulaires
L’interface de création de page doit permettre de créer toutes les pages nécessaires aux utilisateurs
techniques ou fonctionnels. Ces pages et formulaires doivent utiliser des standards permettant de les
accéder en utilisant un navigateur Internet. C’est pourquoi l’utilisation de standards technologiques de
type HTML, XHTML, .NET ou ASP doit être privilégiée.
Une des utilisations des outils peut également être pour la dématérialisation de certains documents
de type contrats, factures, etc. C’est également pour cette raison que les pages et formulaires doivent
permettre l’utilisation et la visualisation de documents dans divers formats dont des formats PDF,
Microsoft Word ou encore Open Office, …
Les formulaires doivent pouvoir être dynamiques et proposer des choix en fonction de données attachées
à la tâche du processus. Ils doivent également permettre de modifier, en fonction des droits de l’utilisateur,
les données pour que le processus puisse se poursuivre.
Les outils devront également proposer des solutions permettant dans certains cas d’enchaîner des pages
les une derrière les autres (page flow).
Les outils permettant de créer les pages et formulaires sont bien souvent des outils WYSIWYG1, facilitant
ainsi leur mise en œuvre.
Outil de Mapping
Le Mapping permet de faire correspondre des données de sortie d’un processus ou d’une activité vers
les données d’entrée d’un autre processus ou activité.
En ce qui concerne l’outil de « Mapping », le minimum est d’avoir la possibilité de programmer la

correspondance des données et donc des champs entre eux. Des outils plus évolués permettront de
faire ces « Mapping » par simple glissé/déplacé. Le dernier niveau consiste en la mise à disposition de
fonctions permettant de programmer des correspondances particulières et de permettre leur utilisation
au sein de plusieurs activités ou processus.
Certains outils permettent même l’utilisation de feuilles de styles (XSLT(*)) qui peuvent être préparées
avec des outils différents et ensuite utilisés au sein de la solution de BPM.
éditeur de Code
L’éditeur de code permet de modifier le code source de services associés aux activités, mais également
aux fonctions permettant d’intégrer la solution au système d’information. Il peut également permettre
la modification et la programmation de transformations de données qui sont très complexes.
Certains outils proposent aujourd’hui une intégration à des outils communément utilisés, comme
Eclipse(*) par exemple, et qui proposent un environnement de développement permettant de prendre en
charge de nouvelles fonctionnalités par le biais de composants additifs nommés plugins. Il est préférable
de limiter le développement de code spécifique et d’utiliser les fonctions standard proposées, mais il
est rare de disposer de toutes celles qui sont nécessaires. Dans ce cas, la conception sera guidée par le
développement de services réutilisables.
Outil de tests
Un autre point important : avoir un environnement de test permettant de vérifier que les services et les
processus mis en œuvre fonctionnent tous correctement. Certains outils se basent sur leurs capacités
de simulation des processus. Dans certains cas, on pourra même utiliser des données provenant du
système de production.
Les tests pourront alors être, soit des tests unitaires techniques, soit des tests fonctionnels. Dans tous
les cas, une automatisation de ceux-ci permettra de garantir le déroulement de tests de non régression
dans des délais acceptables notamment lors d’évolutions mineures ayant un impact sur un ou plusieurs
services voire processus.
Gestion de version
La gestion de version est bien souvent l’un des éléments oublié des éditeurs. Il est important d’avoir
des mécanismes permettant de gérer les versions car il n’est pas rare de devoir gérer plusieurs versions
d’un même processus. Dans d’autres cas, l’outil laisse la possibilité d’utiliser un outil externe de gestion
de version.
Les fonctions de gestion de version peuvent avoir jusqu’à 3 niveaux :

• Un premier niveau consiste en la gestion de la version d’un processus (ex : 1.1, 1.2, 2.0, …)
• Un second niveau consiste en la gestion de versions différentes tout en supportant la possibilité
d’exécuter des processus dans des versions différentes
• Un troisième niveau permet de réinjecter les données dans un processus ayant évolué et de
relancer les instances choisies.
Les 2 premiers niveaux sont en général supportés par la plupart des solutions. Pour le troisième, très
peu de solutions le permettent. Il est aujourd’hui très complexe de permettre la re-exécution d’une
instance de processus déjà en cours dans une nouvelle version.
Outil de documentation
Lors de la modélisation ou du développement/paramétrage des processus, il est nécessaire de documenter

les activités, processus et sous-processus ainsi que le code réalisé. Pour cela, il existe 2 possibilités :
• Utiliser des outils bureautiques et lier les objets aux documents pour en comprendre
leur fonctionnement
• Utiliser des fonctions internes pour décrire les différentes parties et bénéficier de fonctions qui
exporteront les descriptifs apportés sous forme soit directement de documents bureautiques
(mais cela est plutôt rare), soit sous forme d’un site web comprenant tous les liens permettant
d’accéder aux pages et diagrammes décrivant le processus et ses activités.
(*) voir glossaire
page 192
Figure 128 : Exemple d’écran de documentation d’un processus
L’avantage principal de la possibilité de documenter au sein de l’outil de BPM est d’avoir à jour la
documentation par simple export. Cela facilite la prise en compte des modifications et permet la mise
à disposition rapide des nouvelles informations aux différentes équipes concernées.
Moteur de règles
Les règles au sein d’un processus métier sont nombreuses et il est donc important d’avoir un bon moteur
de règles intégré à la solution de BPM. Les règles font partie des éléments qui nécessitent le plus souvent
des évolutions. On distingue d’ailleurs 2 type majeurs de règles : techniques et métiers.
Les règles techniques sont utilisées au niveau de processus d’échanges ou d’activités techniques réalisées
au sein du système informatique. On appliquera des règles en fonction de valeurs ou de compléments
techniques de la solution.
Il est donc important que la solution propose 2 modes pour implémenter les règles :
• Un mode graphique : permettant de définir par une modélisation les règles des processus et de
définir les conditions associées par simple paramétrage.
• Un mode développement : permettant, en utilisant un langage de programmation, de
programmer des règles plus complexes et faisant parfois appel à des formules ou équations
mathématiques. Ce langage peut être le langage Java par exemple, mais peut également être un
langage plus propriétaire et plus naturel pour un expert métier.
Il est également important que les règles puissent être modifiées sans pour autant à avoir à tester la
non régression de la chaîne complète du processus métier. Les règles changent plus souvent que le
processus. L’impact de l’évolution d’une règle qui serait réutilisée au sein de plusieurs processus pourrait
être important en termes de tests de non régression des processus déjà déployés. Minimiser ces impacts
est donc important.
Dans le cas d’un très grand nombre de règles utilisées, il est important de vérifier la robustesse du
moteur de règle et d’avoir des moyens efficaces pour multiplier les instances d’exécutions de ces règles.
Le moteur de règle est, probablement, l’un des éléments important de l’outil de BPM. De la façon dont
est conçu l’accès aux règles dépend la flexibilité des processus.
Il est d’ailleurs judicieux de permettre aux utilisateurs métiers de modifier, par eux-mêmes, les
règles.
Les éditeurs d’outils BPM se distinguent par rapport à la richesse des fonctionnalités proposées pour la
définition et la gestion des règles métiers et/ou techniques.
Le référentiel des processus
Le référentiel des processus est utilisé pour stocker :

• Les modèles des processus et leur descriptif,
• Les formats des données utilisées au sein des processus (méta-données),
• Les données provenant de l’exécution des processus.
Les modèles et leurs descriptifs sont stockés dans une base de la solution de BPM. Cette base permet de
sauvegarder les différents modèles. Ce qui peut faire une différence importante d’une solution à une autre,
c’est la capacité de la solution à permettre de garder différentes versions du ou des processus. Le plus
complexe est, maintenant, de permettre d’échanger des formats différents entres outils (modélisation,
intégration, etc.).
BPMN UML
UML Modèle
Mod èle propri
propri étaire
BPDM
Exécution
Exécution
Figure 129 : Le référentiel de processus et BPDM
L’OMG a donc lancé des travaux pour aboutir à un référentiel de modèles de processus, et plus exactement,
pour permettre à différentes solutions d’utiliser les mêmes modèles même s’ils sont stockés de manières
différentes. Ce référentiel va dans la continuité des travaux autour du MDA (Model Driven Architecture).
Il a justement pour vocation, de définir des standards permettant d’échanger des modèles entre des
notations différentes (BPMN, UML et d’autres) et surtout autour de solutions différentes et d’apporter
une solution permettant de transcrire ces modèles de notation en modèles d’exécution.
Ce référentiel a pour vocation le stockage des informations relatives à la description des processus et
non celui des données d’exécution. D’ailleurs, pour assurer un fonctionnement correct de la solution,
il est fortement conseillé que la base contenant le descriptif des processus et les formats de données
associés soient séparés des données d’exécution des processus : ce qui est le cas dans la plupart des
solutions. La base de données contenant les informations des processus exécutés ou en cours d’exécution
aura d’ailleurs besoin d’une optimisation différente. La solution doit également apporter la possibilité
de sauvegarder toutes les données à des fins d’archivage mais surtout pas dans le même espace; cela
pouvant entraîner des dégradations des performances. Des procédures permettant de gérer cet archivage
pourront également être associées dans le cas où il y aurait besoin de garder un historique important.
Dans certains cas, il sera également nécessaire d’ajouter des fonctions externes permettant de gérer la
non altération des informations avec des mécanismes de « notarisation(*) ».
La solution doit être capable de supporter un bon nombre de types de champs permettant ainsi de
gérer les types de données dont vous avez besoin pour vos processus. Certaines solutions permettent
même de créer ses propres types ou structures de données. On peut, par exemple, avoir besoin d’une
structure de données qui soit réutilisable.
Certaines questions vont alors se poser comme : cette base est-elle propriétaire ou utilise t-elle une base
de données du marché voire une base de données en « logiciel libre » ? Dans certains cas, les données
et méta-données sont tout simplement stockées dans des fichiers qui peuvent être au format XML.
(*) voir glossaire
page 192
Gestion des exceptions
La gestion des exceptions est très importante pour tous types de processus (documentaires, automatisés,
humains, …). Ces exceptions doivent être traitées et les mécanismes mis en place doivent permettre
d’identifier si ce sont des exceptions métiers, fonctionnelles ou techniques.
Des exemples d’exceptions métiers pourraient être :

• Une création de facture alors que le client n’a pas encore été créé,
• La création d’un mouvement comptable alors que le paiement n’a pas été effectué par le client,
• …
Parmi les exceptions fonctionnelles ont peut trouver :

• des données manquantes ou erronées,
• des règles ne traitant pas un cas de figure particulier,
• un format non conforme,
• …
Des exemples d’exceptions techniques seraient :

• l’indisponibilité d’une application
• un lien réseau non disponible
• une base de données devenue inaccessible
• du matériel informatique en panne
• …
Les exceptions doivent pouvoir être transférées dans des corbeilles de tâches, de manière à attirer
l’attention d’un superviseur des dysfonctionnements qui ont eu lieu. On peut également vouloir en
parallèle alerter un responsable métier ou autre du dysfonctionnement en utilisant des moyens comme
l’envoi d’un mail, d’un SMS ou d’alertes remontées au niveau d’un tableau de bord.
Les interfaces utilisateurs
Les interfaces utilisateurs doivent être accessibles via un navigateur Internet de manière à ne pas avoir
de déploiement d’applications clientes lourdes sur les postes de travail.
Ces interfaces doivent, en général, assurer le suivi:

• des activités et tâches ainsi que les actions associées
• technique des processus et mettre à disposition les écrans permettant d’administrer la
plate-forme BPM, les instances de processus et tous les éléments associés.
Les interfaces d’administration
Les interfaces d’administration doivent permettre d’assurer toutes les fonctions d’administration
comme :
• La création d’utilisateurs et des droits associés
• Le suivi des différentes instances de processus
• La relance d’instances dans le cas où certaines seraient en erreur ou auraient été suspendus
• La supervision des différents éléments qui composent la suite BPM y compris certains
composants de l’infrastructure
Il sera également important de connaître la possibilité de l’outil dans le cas où la solution serait utilisée
dans l’environnement distribué plutôt que centralisé. Un environnement distribué pourrait apporter
de la complexité si l’interface devait se connecter à chacune des plates-formes installées sans apporter
une vision consolidée. N’oublions pas que nous pourrions avoir des processus étendus et devoir les
administrer de bout en bout dans un environnement distribué.
Les interfaces utilisateurs
Les interfaces utilisateurs permettent aux utilisateurs métier soit de suivre leurs activités et tâches,
soit de les superviser.
Pour cela on distingue 2 grandes catégories d’utilisateurs :
• Les utilisateurs métiers
• Les superviseurs métiers
Pour la première catégorie d’utilisateurs, cette interface doit leur permettre de connaître les tâches qui
leurs sont affectées ou qui sont affectées au groupe d’utilisateurs auquel ils appartiennent. L’interface
doit également permettre l’escalade de certaines tâches vers d’autres utilisateurs ou groupes, quand
celles-ci peuvent être en dehors des compétences ou des prérogatives de l’utilisateur concerné.
Pour la seconde catégorie, les superviseurs doivent pouvoir :
• voir les activités de leur équipe,
• voir les activités escaladées ainsi que les raisons associées,
• rediriger certaines tâches vers d’autres groupes ou utilisateurs,
• gérer ou visualiser le calendrier des disponibilités des utilisateurs,
• accéder aux tableaux de bord permettant d’effectuer un suivi efficace de l’activité.
L’environnement de développement
L’environnement de développement d’un outil de BPM doit proposer un certain nombre de

fonctionnalités, comme :
• Gérer les accès concurrents
~ La gestion des accès concurrents permet une réalisation des développements par
plusieurs développeurs. Cela permet de préserver l’intégrité de l’ensemble
des développements
• Disposer d’un référentiel contenant toutes les données
~ Le référentiel d’informations doit en permettre le stockage (données intrinsèques
aux processus, informations concernant les Mapping, formats pivot, …)
~ Le code source peut également être stocké
• Se baser sur des standards
~ La solution doit permettre l’utilisation de formats standards (basés sur du XML
par exemple),
~ S’intégrer grâce à des protocoles standards (http, ftp, …),
~ Utiliser des standards de modélisation (UML, BPMN,…)
• Proposer une gestion de version
~ Idéalement, une gestion de version intégrée (ou une gestion de version
communément utilisée : CVS(*) par exemple).
Référentiel
Des meta-données Poste d’administration
et supervision
Base de données
Postes de développement
Figure 130 : Architecture de développement (*) voir glossaire
page 192
Une des fonctionnalités importante que tout outil devrait avoir est la possibilité de préparer des paquetages
contenant les composants constituant un processus métier. Les environnements sont également souvent
dupliqués : environnement de développement, d’intégration, de recette, de production. L’outil doit
permettre, si possible, de basculer un processus d’un environnement à un autre et d’en faciliter son
déploiement. Cette fonctionnalité peut permettre de choisir un outil plutôt qu’un autre. Ceci n’empêche
pas d’avoir également des scripts permettant de déployer le processus d’un environnement à un autre
et en particulier dans l’environnement de production. Les exploitants ne souhaitent pas utiliser des
interfaces graphiques et ont besoin d’automatiser au mieux les procédures. D’où l’importance d’impliquer
les exploitants dès le début du projet de manière à prendre en compte leurs besoins mais surtout leur
façon de travailler.
Une architecture web
La solution est souvent basée sur un serveur d’application propriétaire, du marché ou en logiciel libre.
Le fait d’avoir une architecture web doit permettre de proposer une interface utilisable à partir d’un
navigateur Internet qui, aujourd’hui, est disponible sur toute station de travail. Il sera également nécessaire
que la solution propose une interface web permettant de visualiser des statistiques et d’administrer
le système. Cela a également un effet particulièrement réducteur sur les coûts de déploiement. Les
technologies supportées doivent être du type HTML(*), JAVA(*), JSP(*), XML, … et permettre la
mise en place de la charte graphique web du client, de l’entreprise.
La supervision
La supervision est un élément essentiel d’une suite de BPM, mais souvent une confusion est faite entre
supervision de l’outil et celui de la performance des processus.
On peut distinguer 3 sortes de supervision. La supervision :
• Technique : les composants d’infrastructure, les outils de BPM, les connecteurs et adaptateurs,
les serveurs ainsi que les journaux d’événements,
• Des flux : certaines parties des processus automatiques peuvent être assimilés à des flux.
On peut alors vérifier l’état d’avancement, rejouer certains flux en échec, etc.
• Des processus : c’est en général la partie supervisée par défaut. Elle permet de visualiser
l’avancement des activités et tâches d’un processus. Cet avancement est d’ailleurs souvent
présenté sous forme d’un graphique.
L’expérience a souvent démontré que les exploitants ont besoin d’intégrer ces nouveaux outils avec
les outils qu’ils ont l’habitude d’utiliser tels que les outils de supervision comme BMC Patrol(*), HP
OpenView(*), IBM Tivoli(*), etc. Il sera probablement nécessaire de trouver les moyens permettant
à ces solutions de dialoguer entre elles et permettre ainsi une supervision approfondie de l’ensemble
des composants, flux et processus.
Le suivi et pilotage des processus
En ce qui concerne le pilotage des processus, on en distingue de 2 sortes :

• Le suivi du processus
• Le pilotage du processus
Le suivi des processus apporte toutes les fonctions permettant de savoir où en est une instance particulière
du processus. Dans le cas d’une erreur, on doit avoir la possibilité de stopper cette instance ou de la
relancer en fonction de la cause du problème, quitte à devoir modifier certaines données associées à
cette instance.
Pour le pilotage des processus (au sens remontée d’indicateurs, calculs, agrégations), c’est la possibilité
qu’apporte la solution pour présenter, au sein de tableaux de bord par exemple, les indicateurs et
alertes relatifs à une activité de l’entreprise (vente de produits par exemple). Cette partie doit également
apporter la possibilité de remonter des alertes vers des outils divers comme un serveur de messagerie,
un PDA(*) ou bien encore un téléphone mobile.
(*) voir glossaire
page 192
La gestion d’agenda
La gestion d’agenda doit permettre de prendre en compte le calendrier des utilisateurs avec la possibilité
que des activités soient transférées soit dans le cas d’absences, soit dans le cas de jours fériés par exemple.
Cette gestion doit apporter les interfaces permettant de paramétrer la solution de manière à prendre en
compte tous ces points et ainsi garantir une meilleure qualité de service.
Le lien entre le BPM et la SOA

Les architectures de systèmes ont beaucoup évolué depuis 40 ans. Et pourtant, l’informatique est toujours
en quête du graal. La SOA pourrait-il en faire partie ? Rien n’est sûr !
La SOA : Services Oriented Architecture, est un style de construction d’un système informatique qui
n’est pas nouveau en soi si ce n’est que l’on utilise des standards permettant d’assurer une meilleure
interopérabilité des systèmes ou applications entre eux.
Figure 131 : Evolution des architectures
L’évolution des systèmes a été forte depuis les années 70 où les Mainframe ont su s’imposer jusqu’aux
architectures SOA d’aujourd’hui. Ces architectures ont toutes influencé de près ou de loin la SOA et
toutes les bonnes pratiques tirées des expériences passées ont permis d’évoluer vers de nouveaux modes
de construction des applications et systèmes informatiques.
L’objectif de la SOA est de proposer une meilleure flexibilité et agilité assurant ainsi des moyens efficaces
pour faire évoluer le système d’information et intégrer plus facilement et plus rapidement de nouvelles
applications mais surtout de nouveaux besoins métiers. Il est nécessaire aujourd’hui de proposer une
prise en compte de nouveaux services métier plus rapidement que par le passé.
Pour sa part, le BPM permet d’intégrer des processus métiers au sein du système d’information et apporte
des fonctions permettant de lier des activités manuelles et des activités informatiques pour assurer un
suivi et un pilotage de bout en bout.
Les services SOA peuvent alors devenir une des activités d’un processus et c’est là tout l’avantage pour
le BPM d’utiliser ces services. Nous serons confrontés à 2 niveaux de services : les services techniques
et les services métiers.
Un de mes clients m’indiquait que son système informatique était déjà orienté services. C’est un fait ! Bien
des entreprises ont déjà pris en compte des bonnes pratiques permettant de construire des composants
ou services réutilisables, mais la SOA s’appuie sur bon nombre de standards qui vont de l’implémentation
à la sécurité des accès. Et c’est bien là que sont les innovations.
La cohabitation du BPM, de la SOA et de l’ancien
La SOA permet d’intégrer des technologies plus anciennes et de les rendre plus facilement accessibles
grâce aux services web.
BPM
SOA
Orchestration
des services métiers
EAI
Appli Appli Appli Appli Appli Appli Appli Appli Appli
E ntrepris e
Figure 132 : Architecture SOA et BPM
Par exemple, on peut envisager de publier les services d’un Mainframe sous forme de services web qui
seront ensuite utilisables au sein d’un processus. Si on se réfère au schéma ci-dessus, on peut très bien
faire cohabiter ces mondes totalement différents.
Autre point, la solution de BPM est capable de dialoguer avec des infrastructures totalement différentes.
On peut alors mixer l’utilisation d’un EAI ou ETL, avoir des interfaces spécifiques, s’appuyer sur une
architecture SOA pour partie, etc.
Bien entendu, une architecture SOA permettra de mieux garantir les bénéfices du BPM (flexibilité,
agilité, …). Seulement, les entreprises évoluent lentement vers ce nouveau style d’architecture et cela
prend du temps d’avoir une architecture totalement SOA.
On parle aujourd’hui de « Business Architecture » lorsque l’on associe SOA et BPM. La complémentarité
est facilement justifiable et soit le BPM est lancé suite à une initiative autour du SOA, soit le SOA est
lancé suite à une initiative BPM. Certaines entreprises disent même que les avantages compétitifs s’en
retrouvent décuplés.
Encore une fois, il serait bien restrictif de cantonner le BPM à une utilisation exclusivement système.
Le suivi des tâches, par exemple, a besoin des composants lui permettant de connaître l’état d’une
tâche manuelle et les systèmes ne peuvent strictement rien à cela. Le BPM a également une fonction
complémentaire d’outils qui ont pour vocation l’orchestration pure de services web; leur objectif étant
de proposer des services web orientés métiers par orchestration de services web techniques.
Pour finir, un processus implémenté au sein d’une solution de BPM doit pouvoir être publié et surtout
accessible via un service web. C’est ce qui pourra demain constituer les réseaux de processus.
Les services Web
Les services web sont très largement adoptés par les entreprises, les éditeurs et les intégrateurs de
systèmes. Ce standard permet notamment aux développeurs :
• De s’intégrer avec des applications internes ou externes au système d’information de l’entreprise :
le fait que les applications proposent des services web, facilite l’intégration d’applications au sein des
processus,
• D’utiliser des processus existants en tant que sous processus accessibles via des services web. On
pourra alors invoquer les processus, sous-processus, règles, etc.
• D’exposer des fonctions de supervision et d’administration pour permettre une meilleure
intégration avec les outils existants,
• De proposer des accès externes à des applications qui souhaiteraient utiliser des processus
définis au sein de la solution de BPM ou même de lancer un processus par une action externe
(notification par exemple),
• D’ouvrir les possibilités d’alerter lorsque la partie supervision d’activités et de tâches détecte
des dysfonctionnements au sein d’un processus,
• De permettre à une application de connaître l’état d’une instance de processus,
• De faciliter l’accès aux données partagées des processus.
Pour le système d’information, c’est un mode d’accès mis à disposition des applications métiers permettant
de faciliter l’utilisation de fonctions nécessaires aux processus transverses de l’entreprise.
Un service est composé :

• D’un contrat : il amène les informations relatives à l’objectif du service, à ses fonctionnalités, à
ses contraintes et à son usage
• D’une interface : c’est l’exposition du service et les paramètres que doivent passer tout
utilisateur du service
• De son implémentation : la manière dont le service a été programmé et paramétré
• D’une logique métier : La logique métier fait partie intégrante du service et surtout de
son implémentation
• De données : Un service peut intégrer des données nécessaires à son fonctionnement.
Le principe de fonctionnement est assez simple. On parle de producteur et de consommateur. Le

consommateur invoque un service qui lui répond. Ceci est un exemple de service synchrone.
Consommateur
Consommateur
Producteur
Producteur
requête
Consommateur
Producteur
réponse
Figure 133 : Notion de producteur/consommateur en mode synchrone
Le second exemple consiste toujours en un producteur et un consommateur. Par contre le consommateur

effectue une requête. La réponse à cette requête est envoyée en différé. C’est un appel de service
asynchrone. Le seul retour immédiat pouvant être un code retour.
Consommateur
Consommateur
Producteur
requête
Consommateur
Producteur
Réponse diff érée
Figure 134 : Notion de producteur/consommateur en mode asynchrone
Le fonctionnement des services permet donc d’avoir des modes de communication diversifiés et d’apporter
un couplage lâche. Ceci permet d’avoir une indépendance plus forte que dans le cas d’intégration avec
des interfaces propriétaires. Par contre, il serait illusoire de croire que la SOA, et surtout les services
web, apportent une évolutivité à 100 %. C’est leur conception qui peut amener cette évolutivité.
Les services web sont décrits par une structure XML qui se nomme WSDL (Web Services Description
Language) et qui contient des informations comme :
• Les types : les types de données qui sont utilisés dans les messages
• Les messages : Ils définissent la partie données de communication
• Les « bindings » : c’est en fait le protocole de communication utilisé
• Les types de port : ces ports définissent les opérations (ou fonctions) qui sont exposées.
En général, il y a un port d’entrée, un port de sortie et un port par défaut.
• Les ports : Ils permettent de spécifier l’adresse du port qui est utilisé au niveau du serveur
web pour l’appel au protocole de communication (ou binding)
• Les services : le nom des services
Bien entendu, si un service web est modifié, le descriptif (WSDL) pourra l’être également.
Avec l’arrivée des services web, de plus en plus d’éditeurs intègrent des fonctionnalités comme le BPEL
(Business Process Execution Language) qui normalise le descriptif d’exécution des processus, le BPMN
(Business Process Modeling Notation) qui normalise la façon de modéliser les processus métiers et ce
au fur et à mesure que les spécifications de ces normes deviennent stables. La norme BPEL ne prend pas
en compte les activités humaines et ne fait appel qu’à l’automatisation des processus inter applicatifs.
Par contre certaines solutions permettent aujourd’hui d’importer des fichiers BPEL et d’en tirer parti.
Les entreprises qui doivent choisir un outil de BPM vont regarder de très près la possibilité d’exposer
des services web et/ou d’invoquer des services web.
L’annuaire de services
L’architecture SOA a bien des avantages mais également des inconvénients. Parmi les inconvénients, on
peut mettre en évidence le danger de se retrouver dans un plat de spaghettis qui ferait que l’évolutivité
du système s’en retrouverait réduite. Le simple fait de penser qu’une architecture peut tout résoudre
est bien illusoire. Par ailleurs, la multiplicité des services fait qu’une application cliente pourrait ne pas
connaître l’existence de services sans utiliser un annuaire.
Recherche d ’un service Annuaire

Annuaire Publication
et identification du service
Consommateur
Consommateur
Producteur
Consommateur
Producteur
Figure 135 : Annuaire de services
Cet annuaire permet, en effet, de répertorier les services qui sont à disposition et de connaître les
moyens d’invoquer le service désiré et surtout sa localisation. Un producteur de service publie celui-
ci dans l’annuaire avec toutes les informations associées. Le consommateur, à la recherche d’un tel
service, peut alors demander à l’annuaire s’il en existe un et dans l’affirmative, utiliser alors celui avec
les paramètres connus de l’annuaire. Cette vision un peu simpliste mais tout à fait réaliste permet de
comprendre que tant que vous n’avez que quelques services, vous pourrez vous dispenser d’utiliser un
annuaire. Mais quand le nombre de services aura dépassé les quelques dizaines, il sera alors impossible
d’en avoir une vue exhaustive à moins d’utiliser un annuaire. On appelle d’ailleurs cet annuaire un
annuaire UDDI(*). Il existe d’ailleurs des outils évolués qui vont bien au-delà du simple annuaire et
qui simplifient la gouvernance du SOA.
(*) voir glossaire
page 192
La granularité des services web
Avec l’arrivée des services web, un outil de BPM doit offrir la possibilité de choisir le niveau de granularité
du découpage d’un processus.
On peut identifier 4 niveaux différents :

• Niveau 1 : Une tâche.
• Niveau 2 : Une règle métier
• Niveau 3 : Une partie de processus ou sous processus
• Niveau 4 : Un processus
La granularité choisie va dépendre des contraintes auxquelles on va devoir faire face. Avoir trop de
services de niveau 1 alors que l’on a besoin de bonnes performances du processus est incompatible.
Créer un service pour une règle qui ne changera jamais n’a également pas beaucoup de sens. C’est
pourquoi, il est important de bien cadrer les besoins et les contraintes associées.
Par contre, dans le cas de changements fréquents au niveau de règles métiers, il sera très judicieux
de créer un service (niveau 2). Le processus pourra rester identique et permettre aux règles métiers
d’évoluer, garantissant mieux leur prise en compte dans un délai très court.
Ac tivit é/fonc tion

Niveau 1 Niveau 4
R ègle
Niveau 3
Niveau 2
Figure 136 : La granularité des services

Dans le cas du Niveau 3, on pourra créer un service pour un sous-processus qui comprendra règles et
activités/tâches.
L’orchestration de Services Web et le BPM
Le BPM apporte le niveau manquant à la SOA pour la gestion des processus et la SOA apporte la flexibilité
nécessaire au BPM pour que les processus soient plus évolutifs qu’avec des interfaces propriétaires ou
basées sur des briques EAI. La SOA permet de disposer de services plus diversifiés incluant des services
métiers.
Ces services peuvent être à plusieurs niveaux :

• Les services applicatifs : Ils ont un orientation plus technique et proposent des fonctions qui
sont en rapport avec l’utilisation de l’application (CRM, facturation, comptabilité, …)
• Les services métiers : sont d’un niveau plus abstrait et sont composés de multiples services
applicatifs. Les fonctions proposées sont des fonctions métiers qui seules ne peuvent pas répondre
complètement au besoin. Les services métiers peuvent être composés de services proposés par des
applications différentes.
• L’orchestration de services : l’orchestration de services met en œuvre des enchaînements de
services afin de publier un véritable service métier complexe. Par exemple la création d’un client.
Cette orchestration n’enchaîne pas des activités entre elles.
• Les processus métiers : les processus métiers enchaînent des activités par invocation :
~ d’une fonction d’un applicatif,
~ de services applicatifs,
~ de services métiers,
~ ou d’orchestration de services.
Processus
Processus
Processus m
m étiers
étiers
M étiers
Orchestration
de services
Services
M étiers
Services
Applicatifs
Application
Application A
A Application
Application BB Application
Application C
C Application
Application D
D
Figure 137 : Les niveaux de services
Pour terminer, il sera important de permettre que les orchestrations et les processus soient également
invocables par appel de services web.
L’évaluation de la solution
Une étape très importante consiste en l’évaluation de la solution de Business Process Management en
prenant en compte le contexte dans lequel il sera utilisé. Les produits sont choisis, parfois, par rapport
à un contrat existant ou par rapport à une affinité en dehors de toute relation avec le besoin exprimé.
Bien sûr, il est judicieux de mettre dans le processus de sélection l’éditeur déjà présent ou avec lequel
un contrat existe dores et déjà, mais en aucun cas le choix doit en être dénaturé. C’est pourquoi le
processus de sélection doit passer par une évaluation complète de la solution y compris financière.
Pour cela, il suffira de collecter les informations nécessaires pour effectuer cette évaluation en passant
au crible certains critères.
Les critères d’évaluation
Regardons maintenant les principaux critères permettant d’évaluer la solution. Bien entendu, ces critères
peuvent avoir une importance toute relative par rapport au contexte dans lequel l’outil sera utilisé.
Les activités manuelles
Les critères sont les suivants :

• Possibilité de définir des activités humaines avec support pour définir des tâches unitaires ou
des sous ensembles si besoin
• Support pour utiliser la solution dans un contexte départemental y compris pour les fonctions
de reporting et les liens entre unités
• Possibilité d’escalader si des délais sont dépassés ou la charge de travail est devenue
importante pour une personne ou un groupe
• Personnalisation de la liste des activités
• Utilisation d’un client léger ou d’un client lourd en fonction des besoins (même si pour
ce dernier, l’arrivée du web 2.0 apporte des fonctions plus avancées)
• Validation de patterns afin d’éviter des incohérences au niveau d’un processus
• Modélisation graphique personnalisable avec intégration d’icônes spécifiques si nécessaire
• Sauvegarder les préférences d’un modélisateur ou analyste
• Support multilingue
• Possibilité de faire évoluer un processus en cours d’utilisation : terminer, mettre à jour
et suspendre
• Intégration d’un annuaire pour la gestion des utilisateurs, rôles et groupes
• Possibilité d’utiliser des processus de versions différentes en parallèle
• Reporting et administration
La modélisation et simulation de processus
Les critères peuvent être les suivants :

• Facilité de compréhension des modèles : utilisation de BPMN par exemple
• Mise en place de métriques
~ Coût,
~ Délai,
~ Valeur,
~ Risque.
• Fonctions de simulation : animation des modèles et calculs associés des métriques
• Analyse financière
• Analyse des risques
• Analyse de la chaîne de valeur
• Rapports prédéfinis
• Simulation en termes d’utilisation des ressources et optimisation
• Import/export de modèles (BPMN, BPDM)
• Palette d’outils pour modéliser le processus
• Utilisation d’images et d’icônes spécifiques
Patrons, modèles, flux, services et règles
Dans le cadre de patrons, modèles, flux, services et règles, il sera plus complexe de qualifier les critères.
Ceux-ci peuvent être enrichis par des apports de sociétés tierces qui proposeront leur savoir et leurs
bonnes pratiques.
Dans les différents critères, on peut noter :

• Richesse des patrons proposés (sectoriels, métiers, …)
• Interopérabilité avec d’autres solutions d’intégration, de Workflow ou de BPM
• Capacité à s’intégrer dans un écosystème complexe et très hétérogène
Interface utilisateur et gestion de contenu
Les critères peuvent être :

• Possibilité de gérer électroniquement des documents en incluant des fonctions de classement,
d’indexation et de liaison avec d’autres documents
• Intégration d’images, de systèmes de reconnaissance, support de fonctions d’annotations
• Support de fonctions de recherches pour les informations structurées, mais également
non structurées
• Possibilité de lier l’information à des ressources et à des compétences
Support de travail collaboratif

• La possibilité de supporter des fonctions permettant de prendre en compte des échanges
autour d’objectifs, d’une cible, de règles et de délais
• Accéder à des listes partagées d’activités, de calendrier et de cas. Les cas peuvent être
formalisés dans du contenu structuré mais également non structuré (mail, fichier PDF, …)
• Permettre de partager une vision commune des processus, de la progression de l’activité et
des tableaux de bord associés (*) voir glossaire
• Apporter la capacité de créer des espaces collaboratifs permettant d’échanger, de partager de page 192
la même manière qu’une communauté le ferait (espace de partage, chat, forums, …)
• Proposer des outils permettant de prendre des décisions de groupe basées sur une vision
partagée des processus et des données associées.
Intégration au système informatique
Les critères sont les suivants :

• Apporter des fonctions permettant de créer des services par assemblage
• Création d’applications composites basées sur de l’assemblage de services proposés par
des applications externes
• Orchestration de services (au sens SOA)
• Support de fonctions facilitant la gestion de projet (versions, documentation, …)
• Fonctions de tests et de visualisation des résultats
• Support de fonctions pour réaliser des tests de non régression
Supervision de la performance opérationnelle

• Apporter des fonctions ergonomiques et intuitives pour l’utilisation des tableaux de bord
• Proposer des fonctions permettant de personnaliser simplement les tableaux de bord
• Permettre de définir des métriques et surtout de mettre en place des règles permettant au
mieux de répondre ou d’agir en fonction d’indicateurs prédéfinis
• Gérer des actions en fonction d’alertes paramétrées
• Permettre le paramétrage simple de seuils d’alertes
• Supporter des fonctions de gestion d’événements complexes (Complex Event processing)
• Apporter des capacités analytiques (patterns, corrélations et causalités)
• Analyser des événements historiques
• Capturer et analyser des événements provenant de sources très diversifiées
• Filtrer des événements
Simulation en mode réel, optimisation et modélisation prédictive

• Apporter des fonctions permettant d’injecter des données provenant de systèmes réels pour
simuler au plus près de la réalité
• Modéliser des projections
• Apporter des fonctions permettant la gestion financière et la gestion des risques
• Intégrer la possibilité de scénarii métiers et de les simuler
Gestion des règles et polices métiers

• Réutiliser des règles et permettre l’héritage lors d’utilisation en cascades
• Apporter des possibilités de vérifier l’inconsistance de règles ou bien encore le conflit
potentiel entre plusieurs règles d’un même processus
• Proposer des fonctions de mise en œuvre simples, des modifications de règles et polices
avec possibilité de les tester et de les déployer
• Apporter des fonctions qui permettent d’analyser l’impact de la modification de règles
• Supporter des fonctions permettant de gérer la propriété des règles métiers
Matrice d’évaluation
Tous les critères vus précédemment doivent être notés et pondérés par rapport au contexte. Une matrice
de positionnement de la solution sera utilisée dans le but d’identifier la meilleure solution. L’étude
devant se baser, à minima, sur un questionnaire.
C C C C
s
é
B B B C
Fonctionnalités
Fonctionnalit
A A B C
A A B C
Niveau de couverture
Figure 138 : Matrice d’évaluation
Ce questionnaire doit permettre de valider la mise à disposition de certaines fonctions. Ensuite, et par
rapport à un système de notation, on doit positionner cette solution.
On peut identifier 3 catégories principales de solutions :

• Zone A : Outil de BPM
• Zone B : Suite BPM
• Zone C : Zone de différenciation
L’outil de BPM
L’outil de BPM prend en compte l’intégration du processus au sein du système d’information. Il ne

permet peu ou pas de gérer tout le cycle de vie du processus. L’outil de BPM a une orientation forte
vers l’un des 4 types de processus (humain, intégration, …). Mais l’outil est généralement fonctionnel
et sans fonctions superflues. L’outil propose rarement des fonctions avancées d’analyse et de simulation
des processus.
La suite BPM
La suite BPM est capable de gérer le cycle de vie de bout en bout du processus : modélisation, analyse
avancée, suivi des performances, exécution, intégration au système informatique existant, etc.
La zone de différenciation
La zone de différenciation dépend de l’excellence de la solution sur certaines de ses fonctionnalités.

Par exemple, avoir un véritable moteur de règles qui propose d’une part l’externalisation des règles
métiers mais également une interface pour que le métier puisse les modifier fait que l’outil aura une
véritable différenciation.
Lors de l’évaluation de la solution, on peut décider que le choix se portera sur la solution qui accentuera
certains points plutôt que d’autres. Très probablement expérimenterez-vous la provenance même de
l’outil (moteur de règles, intégration, Workflow, acteur de niche BPM, etc.).
Il ne faut pas hésiter à réaliser des preuves de concepts (POC : Proof Of Concept). Ces « preuves de
concepts » sont des prototypes réalisés dans un délai court permettant de valider la disponibilité de
fonctionnalités pour les projets à venir et avant de finaliser le choix de l’outil.
Méthodologie d’évaluation
Pour effectuer cette évaluation, il faut utiliser une méthodologie selon des axes comme :
• Les fonctionnalités de la solution : nous avons déjà regardé en détail ces critères, mais encore une
fois, bien prendre en compte les besoins réels.
Si nous devions retenir quelques critères :

• La solution est-elle complexe à utiliser ?
• La mise en œuvre est-elle plus du domaine du paramétrage ou nécessite t-elle beaucoup
de développements spécifiques ?
~ Peut-on automatiser les processus métiers et si oui, comment ?
~ L’outil propose t-il un suivi des processus voire une solution de supervision
d’indicateurs métiers ?
~ La solution permet-elle de gérer des corbeilles d’activités ou de tâches ?
~ Quelles sont les fonctionnalités permettant de faciliter l’analyse et la simulation
des processus ?
~ Quel écart existe-t-il entre les fonctionnalités et leur complexité d’exploitation ?
• Le coût de la solution : Le coût impactera le retour sur investissement, mais une approche
projet peut faciliter le choix final. Attention, certaines solutions plus coûteuses que d’autres
peuvent avoir une productivité bien plus importante.
• L’expérience et les références : L’expérience de l’éditeur et les cas similaires peuvent avoir leur
importance. Bien que les produits soient émergeants, on trouve bien souvent des références
similaires, même dans d’autres pays.
• La capacité de mise en œuvre des projets : Quel est le délai moyen de mise en œuvre
d’un projet ?
• La pérennité de l’éditeur : Parmi les principaux critères, on peut citer :
~ Stratégie de l’entreprise et des produits
~ La base installée
~ Les revenus générés avec la répartition services/licences ainsi que
la progression annuelle
~ Les partenaires intégrateurs
~ La capacité de formation
Tous ces axes sont importants et certains plus que d’autres : les fonctionnalités et la pérennité par
exemple. Quid d’une solution qui comporte toutes les fonctionnalités mais dont la pérennité n’est pas
garantie ? Et le contraire ? Certaines solutions sont parfois très complexes à évaluer.
S’il y a un conseil à appliquer : effectuer une preuve par l’exemple. En d’autres termes, faites un essai
de l’outil dans des conditions réelles ! Même si les délais du projet sont courts, prenez le temps. La
réflexion et les essais peuvent éviter les pires désagréments.
La pondération des catégories
La pondération des critères est importante pour refléter encore plus les besoins. C’est pourquoi, il est
préférable de regrouper les questions permettant d’évaluer la solution en plusieurs catégories que sont :
• Les fonctionnalités
• Le coût
• Les retours d’expériences et les références
• Le délai de mise en œuvre de projets
Ces catégories permettent ainsi de bien identifier les points les plus importants et de veiller à ce que la
solution et l’éditeur de la solution répondent au mieux aux besoins.
Le travers souvent retrouvé est le choix basé uniquement sur le prix. Attention ! Les expériences passées
ont souvent démontré que le prix ne fait pas tout. Parfois la mise en œuvre d’une fonctionnalité peut
coûter autrement plus cher que le prix de la licence.
8. La valeur de la gestion
des processus
Depuis de nombreuses années, le système d’information s’est enrichit de nouveaux applicatifs, plus
compliqués les uns que les autres, sans pour autant prendre en compte les bienfaits ou méfaits de
certaines technologies en termes d’évolutivité, de support ou de maintenance. Il est vrai, également, que
bien des projets ont eu des coûts importants et des impacts sur le business assez faibles. L’informatique
évolue et quitte cette fonction de support pour servir de véritable outil de travail. Ce changement de
positionnement implique d’utiliser l’informatique différemment et donc de sélectionner la nature
des besoins d’une autre manière. Retour sur investissement et analyse de la valeur: ces techniques
apportent des éléments permettant de mieux orienter les décisions. La culture et le confort, quels qu’ils
soient, peuvent également faire partie des critères qui influeront sur le lancement ou non de projets
informatiques. Il en est de même pour un outil de BPM. Ceci est moins vrai pour ce qui concerne la
formalisation, l’analyse et l’optimisation des procédures de l’entreprise qui sont nécessaires et permettent
de garder des traces de leur fonctionnement ou de leurs évolutions.
C’est pourquoi, pour les projets comportant une forte composante technologique, en l’occurrence l’achat
d’une suite BPM, il est demandé de justifier les projets et d’apporter aux décideurs tous les éléments
leur permettant d’étudier le réel apport de valeur ainsi que le retour sur investissement. Maintenant, la
justification ne veut pas dire obligatoirement des gains immédiats. Ces gains peuvent se faire à posteriori
et ils pourront être soit qualitatifs, soit quantitatifs. Il est donc important d’identifier les apports d’un
projet de BPM pour en permettre sa justification.
Des entreprises se sont perdues à vouloir baisser les prix de leurs achats. Ce qui peut impliquer de retenir
un partenaire ou prestataire qui risque d’être moins en adéquation avec le besoin réel et mettre ainsi en
grave danger l’atteinte des objectifs stratégiques. Certaines entreprises n’ont pas souhaité investir dans
de nouveaux projets innovants. C’est alors que ces entreprises ont vu leurs investissements décuplés
car l’écart à combler était devenu trop important face aux besoins internes et externes leur permettant
de rester compétitif. D’autres ont vu leur Direction Informatique vouloir justifier des projets d’un point
de vue presque essentiellement technologique alors que le ROI, dans ce cas, est amoindri. Le métier
souhaite obtenir aujourd’hui un meilleur support de l’informatique. D’ailleurs, une justification métier
est plus pertinente dans la plupart des cas. Il n’est pas toujours facile de savoir justifier un projet auprès
des métiers. C’est pourquoi, il faut s’entourer des profils nécessaires pour le faire. Un bon moyen
pour commencer un alignement entre métier et IT ! Maintenant, il est fort probable qu’une analyse
concurrentielle peut apporter des éléments permettant d’évaluer les gains que l’entreprise pourrait faire
par rapport à ses concurrents, mais également pour ses clients en démarrant un tel projet.
Aujourd’hui, la fidélisation de la clientèle est également devenue un axe très important avec certains
secteurs très porteurs comme les télécoms où les opérateurs doivent mettre en place des stratégies, parfois
complexes, afin de fidéliser leurs clients. Les banques sont également confrontées au problème.
Le ROI, ou retour sur investissement, est un exercice complexe permettant d’identifier si oui ou non
il est économiquement intéressant de mettre en place une démarche de gestion des processus. Cette
démarche peut être accompagnée d’outillage permettant d’améliorer la performance des processus
métiers de l’entreprise.
L’analyse de la valeur est un autre exercice qui permet de sélectionner les besoins ayant un réel impact.
Par contre, attention car l’analyse de la valeur est bien souvent galvaudée. Certaines entreprises utilisent
ce terme et passent par de simples questionnaires pour sélectionner les projets candidats. Que voilà
une vue bien restrictive. Cette analyse de la valeur est utile quelque soit l’avancée du projet. Elle
peut d’ailleurs faciliter la décision d’arrêter un projet en particulier car, malgré l’obstination, le projet
n’atteindra jamais les objectifs visés.
L’un des pièges dans lequel tombent certaines entreprises est d’arrêter l’initiative BPM après avoir obtenu
des premiers retours sur investissements. Le BPM doit s’inscrire dans une démarche d’amélioration continue
des processus lui permettant ainsi d’être toujours en adéquation avec les attentes du marché.
Pour terminer, les coûts d’un processus doivent être déterminés si l’on veut pourvoir les optimiser. Pour
cela, on peut utiliser des techniques de contrôle de gestion comme le calcul des coûts par activité. La
fonction de simulation des outils peut prendre en compte les coûts par activité pour connaître le coût
global du processus. En fonction des simulations, on pourra choisir l’alternative qui répond au mieux
aux objectifs fixés.
Le ROI et TCO
Le retour sur investissement peut être trouvé selon 3 axes principaux que sont :
• La productivité
• La profitabilité
• La valeur client
Pro
duProductivit
ctiv téé
ili
ité tab
é rofi
PProfitabilit
R OI
Valeur client
Valeur Client
Figure 139 : Les 3 axes principaux du ROI
Ces 3 axes sont les plus courants. Il peut y avoir d’autres pistes de ROI. Prenons le cas des normes
comptables. Que coûtent les amendes infligées aux entreprises qui ne sont pas conformes à certaines
normes comptables de publication des comptes ? Ceci ne touche pas directement la productivité, la
profitabilité ou la valeur client, mais affecte directement la marge de l’entreprise et donc potentiellement
sa valeur boursière si celle-ci est cotée en bourse.
Le « Total Cost of Ownership »: TCO
Avant de pouvoir aller plus loin dans la démarche de calcul du retour sur investissement, il est nécessaire
d’étudier le coût total d’acquisition (TCO : Total Cost of Ownership) de la solution. Lors du calcul du
TCO, on prendra en compte tous les postes budgétaires que sont :
• Le logiciel,
• Le matériel,
• Le personnel,
• Le conseil et l’accompagnement,
• La formation,
• Les autres postes budgétaires.
Certains de ces postes budgétaires sont également récurrents. Ils doivent être identifiés et étudiés.
Aujourd’hui, bien des éditeurs indiquent un niveau de TCO proche de zéro ! Est-ce bien raisonnable ?
Non, pas vraiment ! Même si les éditeurs proposent des frameworks, des bonnes pratiques, le coût des
licences et de la maintenance restent un élément essentiel. Bien entendu, le ROI apporté par ces outils
reste important mais l’outil seul ne suffit pas. L’expérience a démontré que les meilleurs outils du monde
sans une bonne démarche augmentaient le TCO de manière significative. Il n’est pas rare, même encore
aujourd’hui, que les délais annoncés pour la mise en place d’un outil de BPM soient sous estimés. Un
éditeur de solutions propose son outil mais n’est pas un professionnel des projets informatiques même
si ils les utilisent. Les méthodes, démarches, bonnes pratiques permettent de mieux garantir la fiabilité
des coûts estimés. Le calcul du TCO n’est pas une tâche aussi simple. Il faut récupérer des coûts que,
généralement, seule la Direction Financière ou la Direction Informatique peuvent connaître au sein de
l’entreprise.
Le « Return On Investment » : ROI
La partie complexe du calcul du ROI est l’accès à des données financières fiables. Elles sont assez souvent
difficiles à récupérer, soit par ce qu’elles sont noyées dans des postes budgétaires plus globaux, soit
parce qu’elles ne sont pas suivies en tant que telles. Par ailleurs, il faut éviter de tomber dans l’excès
où à force de vouloir justifier économiquement les projets l’entreprise finisse par ne plus innover. Elle
risque alors de se retrouver rapidement, en dehors des normes du marché.
L’innovation coûte de l’argent et la non innovation encore plus.
Les outils de BPM facilitent le ROI mais celui-ci pourra être plus ou moins long à obtenir. C’est le délai
d’amortissement. Ce délai pourrait se trouver réduit ou allongé en fonction de la méthodologie de mise
en place utilisée.
ts
û
Co
écifique
Sp
Délai d ’amortissement BPM
Délai
Figure 140 : Comparaison BPM vs Spécifique
Les éditeurs de solutions de BPM annoncent souvent des ROI démesurés. Il faut néanmoins accorder
au BPM ses apports bénéfiques à l’entreprise. Sans une démarche correctement construite, ou par une
approche exclusivement technique, le ROI tiré risque d’être proche du zéro voire négatif dans certains
cas.
Si l’on regarde certains retours d’expérience de projets de BPM, on constate qu’ils ont eu un retour sur
investissement minimum de 10%. 70% d’entre eux ont eu un ROI de plus de 15%. C’est pourquoi les
projets de BPM ont de plus en plus de succès, d’autant que le ROI constaté l’est dès la première partie
du projet et que dans une démarche d’amélioration continue, le ROI s’en trouve, de manière générale,
amélioré au fil du temps.
Le ROI est très lié d’une part à la facilité d’utilisation et à la pertinence de l’outil et d’autre part à la
méthodologie employée pour le mettre en œuvre. On distingue également 2 catégories de sources de
ROI :
• Les sources internes :
~ Productivité améliorée,
~ Diminution des erreurs des utilisateurs,
~ Diminution des coûts de formation,
~ Modification des spécifications faites avant un point de non retour,
~ Limitation du support utilisateur nécessaire.
• Les sources externes :
~ Ventes améliorées,
~ Coûts de support diminués,
~ Coûts des évolutions limités suite à la prise en compte au bon moment dans
le cycle de vie.
Le calcul du pourcentage du retour sur investissement se base sur la formule suivante :
Bénéfice - Coûts x 100

% de ROI =
Coûts
Figure 141 : Formule de calcul du pourcentage de ROI
Le calcul des bénéfices se fait en identifiant les gains réalisés. Ces gains sont calculés en comparant les
coûts actuels des coûts futurs à 3 voire 5 ans.
Les coûts sont ceux identifiés pour le calcul du TCO. L’autre exercice va consister à établir les coûts
qui sont récurrents de ceux qui ne le sont pas.
Mais un ROI médiocre voire inexistant ne signifie pas non plus que le projet ne soit pas à faire. C’est le
cas de la mise en conformité de l’entreprise face à une législation ou régulation comme Sarbanes-Oxley,
BALE II, SOLVENCY II, … D’autre part, le ROI peut arriver à une échéance plus lointaine et le projet
peut, tout de même, apporter des fonctions de confort utiles à l’entreprise. Mais qu’adviendrait-il si
le projet n’était pas réalisé ? La société serait-elle toujours compétitive dans 3 ou 5 ans ? La marche à
sauter pour revenir à des normales ne serait-elle pas trop importante et donc trop coûteuse ? On adjoint
souvent le ROI à des coûts pour faire, mais qu’en est-il si on ne fait pas ? L’inaction a bien souvent mis
en difficulté des entreprises tout comme la non décision !
Quid du ROI indirect ? Il peut être non négligeable. On peut prendre, pour exemple, un projet où la
mise en place d’une démarche et d’une solution a permis à une entreprise d’adresser un nouveau marché
à effectif constant. La croissance induite par ce nouveau marché était de 40%. Pourtant, le coût initial
du projet était important et le retour sur investissement incertain : rien ne garantissait la croissance sur
ce nouveau marché.
Les sources de ROI

Lors de la mise en place de BPM et de l’étude du potentiel ROI que l’on pourra en tirer, on va devoir
étudier, par rapport au contexte, les éléments déterminants qui composeront le ROI.
Dans le domaine de la gestion des processus métiers, il existe 5 principales sources de ROI que sont :
• L’automatisation,
• La qualité,
• La conformité,
• Le management,
• L’optimisation.
Ces catégories apportent des ROI qui sont à des niveaux plus ou moins importants et avec plus ou
moins d’impacts.
Automatisation
Automatisation
Automatisation
Optimisation
Optimisation
Management
Management
Optimisation
Management
Qualit
Qualit
Qualité
Conformit
Conformit éé
Conformité
éé
Figure 142 : Niveaux de ROI
Notre graphique ci-dessus donne quelques ordres de grandeur du ROI que l’on peut attendre. Dans
l’ordre d’importance, l’automatisation. Elle peut apporter l’économie d’activités à faible valeur ajoutée
ou conduire au transfert de personnel réalisant une activité vers une autre plus importante au processus.
L’optimisation est plus complexe mais apporte également un bon niveau de ROI. Le Management
peut, lui aussi, faciliter le ROI à condition que le pilotage des processus ne soit pas utilisé à des fins de
répression ! La répression est contre-productive et peut avoir des effets très néfastes sur les résultats de
l’entreprise voire même bloquer l’innovation. La qualité peut avoir son importance sur la perception
qu’a le client de l’entreprise ainsi que de ses produits et services. Pour la conformité, cela dépend des
impacts. Si des impacts financiers peuvent être évités, alors le ROI sera positif, sinon il peut être négatif
car le coût de mise en œuvre peut s’avérer très important.
L’automatisation
L’automatisation est l’une des sources qui permet de quantifier le ROI le plus facilement. La plupart des
éditeurs de de BPM se réfèrent à l’automatisation des processus, mais cela ne concerne qu’une partie
des processus. Ces projets d’automatisation sont également plus simples à conduire. En effet, il n’y
a pas d’analyse détaillée des tâches manuelles à optimiser. L’analyse va porter sur les tâches réalisées
manuellement que l’on peut automatiser grâce à la solution technique.
Le gain identifié dans ce cas consiste en la quantification de temps pour réaliser les tâches manuelles et
les coûts associés qui sont purement et simplement supprimées lors de l’automatisation. Dans le cadre
de l’étude de ROI, on va parler de suppression d’ETP(*).
De manière générale, l’entreprise sait où elle consomme le plus de main d’œuvre et comment elle peut
probablement réduire cette main d’œuvre. Ceci constitue la piste essentielle d’automatisation de tâches
et de processus. Il arrivera tout de même que certaines pistes n’aient pas été identifiées ou alors que
certaines pistes sont jugées trop coûteuses pour être automatisées. Dans bien des cas on va omettre les
coûts récurrents de maintenance et d’évolution, voire les coûts induits par l’obligation de faire évoluer
l’infrastructure d’automatisation vers une nouvelle version. Dans certains cas, il peut y avoir des impacts
importants sur l’existant.
Dans d’autres cas, on va détecter lors de la modélisation et l’analyse d’un processus qu’une partie peut
être automatisée. On identifiera alors les coûts et gains associés permettant ainsi aux décideurs d’effectuer
les meilleurs choix d’optimisation.
L’optimisation
L’optimisation permet également d’obtenir un ROI assez important. Dans cette démarche d’optimisation, (*) voir glossaire
on se servira de la démarche de gestion des processus comme outil d’analyse pour identifier les page 192
optimisations possibles que celles-ci soient d’ordre de la réduction de coûts ou de l’amélioration de la
performance globale d’un processus.
Pour la réduction des coûts, elle peut être de plusieurs sortes, comme :
• L’externalisation de tout ou parties de processus (BPO),
• La suppression d’activités sans valeur ajoutée,
• Le transfert de personnel vers des tâches plus valorisantes,
• La réduction des flux de production résultant en des stocks moins importants,
• Etc.
D’autres sources peuvent être plus indirectes. La satisfaction des clients peut résulter en un accroissement
des ventes mais compter dessus reste quelque peu hasardeux.
Le management
L’utilisation des outils de BPM dans le cadre du management de l’entreprise permet de valider
l’adéquation des résultats aux objectifs stratégiques de l’entreprise. Le ROI peut ne pas être important
voire inexistant. Piloter a toujours apporté une meilleure maîtrise de l’écosystème et de ses aléas.
Un processus qui ne serait temporairement que peu ou pas performant mais correctement piloté,
permettrait au management de prendre les décisions qui amélioreront la performance et garantirait
une meilleure adéquation vis-à-vis des objectifs de l’entreprise ou de l’activité. C’est d’ailleurs souvent
le management qui sera destinataire des alertes, quelles qu’en soient leurs formes. Le manager peut
prendre la décision de réorganiser les méthodes de travail. Dans le cadre de la gestion de la qualité de
service (BSM), on voit les managers avoir des tableaux de bord différents en fonction de leur domaine
de responsabilité. Cette flexibilité que le produit doit apporter est également importante. Les données
présentées sont des indicateurs macroscopiques au contraire des opérationnels qui, eux, ont besoin
d’indicateurs plus précis leur permettant ainsi de déterminer la cause de la variation constatée et, qui sera
demandée par le manager. Le manager doit par contre savoir comment il peut aider les opérationnels
pour résoudre le problème plutôt que de les sanctionner. Les sanctions peuvent devenir un des revers
de la démarche. C’est pourquoi le management doit également s’inscrire dans la démarche de conduite
du changement afin d’éviter ces effets qui ont démontré bien souvent des résultats négatifs à plus ou
moins long terme.
La qualité
Une démarche qualité utilise des processus. La mise en place d’outils de BPM peut permettre de piloter
la qualité des processus et donc l’adhésion de l’entreprise aux processus qualité.
L’outil permettra d’ailleurs d’identifier les exceptions et donc de renforcer le suivi des règles à appliquer
dans ces cas. Les alertes qui en découlent peuvent alors être levées et envoyées aux différents acteurs
concernés, pour peu que la matrice des rôles et responsabilités ait été correctement définie.
Les processus pilotés et placés sous contrôle d’un outil seront, en général, des processus qualité qui
auront un impact direct sur la perception que le client a des produits et services de l’entreprise.
Pour terminer, la mise en place d’un tel pilotage peut garantir une meilleure qualité des données et
donc apporter des indicateurs plus fiables aux managers de l’entreprise.
La conformité
La conformité est prise comme une contrainte forte. Celle-ci peut avoir plus ou moins d’impacts
financiers. Certaines autorités de régulation peuvent infliger à des entreprises des sanctions financières
pour non-conformité à une règle établie. C’est aujourd’hui souvent le cas des entreprises cotées en bourse
par exemple. Un autre exemple venant de Belgique est le cas des opérateurs de télécommunication.
Un opérateur de téléphonie mobile doit prendre en compte une demande de portage d’un numéro
de téléphone d’un opérateur vers un autre dans les 15 minutes, faute de quoi l’autorité de régulation
des télécoms belge peut infliger des sanctions financières (amende) étant proportionnelles au chiffre
d’affaire réalisé par l’opérateur mis en cause. Le ROI est alors facilement quantifiable ! Mais ce n’est pas
toujours le cas et l’entreprise ne peut déroger à la règle de mise en place de la conformité en question.
L’atout de l’outil de BPM, dans ce cas, est de proposer les outils permettant de démontrer que le ou les
processus de l’entreprise sont bien conformes aux contraintes imposées.
L’Activity Based Costing (ABC) et le BPM

La technique ABC, ou technique de calcul des coûts par activité, est utilisée dans le calcul de coût d’un
service ou produit et ce sans prendre en compte l’organisation de l’entreprise pour créer ce service ou
produit.
Elle permet en outre, et dans le cadre du Business Process Management, de calculer le coût de chacune
des activités d’un processus et donc de permettre l’évaluation de son coût d’exécution. Ces coûts peuvent
être utilisés dans l’outil de modélisation et de simulation de manière à tester des solutions alternatives
permettant d’améliorer le processus.
En fait, la méthode ABC couplée au BPM est un moyen d’apporter des éléments au management de
l’entreprise sur ses processus et de décider des améliorations à apporter en prenant en compte différents
critères. L’atteinte des objectifs stratégiques peut être mieux pilotée. On utilise cette technique de manière
à identifier les zones de coûts qui pourraient être améliorées ou pour veiller à ce qu’une zone de coût
en particulier ne soit pas plus importante qu’une autre.
Les activités identifiées sont exécutées par des systèmes, par des machines, par des ressources de
l’entreprise et donnent lieu à des services rendus ou à des produits fabriqués. Les ressources consomment,
en général, des matières premières et celles-ci ont des coûts. Dans l’utilisation de la méthode pour
améliorer l’efficacité des processus, il est nécessaire, et même primordial, de bien identifier toutes les
activités ainsi que tous les entrants associés.
La démarche ABC
La démarche ABC permet d’identifier les coûts associés aux activités unitaires pour mesurer ces activités
correctement.
Les activités ainsi identifiées sont alors catégorisées comme apportant ou non de la valeur ajoutée. Il
n’est pas rare que certaines activités soient remplacées par d’autres à plus forte valeur ajoutée. Dans le
cas où l’on ne pourrait pas supprimer certaines activités ne comportant pas ou peu de valeur ajoutée,
on cherchera à les minimiser au niveau des coûts. Des ressources sont également assignées à l’exécution
de tâches et les coûts associés doivent également être intégrés. Trop souvent les ressources sont oubliées
et pourtant, elles sont l’un des éléments essentiels d’une activité.
La démarche ABC permet :
• De collecter les coûts pour réaliser une activité
• De se focaliser sur les activités les plus coûteuses
• D’apporter des éléments d’identification des indicateurs pour la supervision des activités
• D’effectuer le lien entre les modèles de processus et les coûts
• D’aider aux prévisions des dépenses en fonction des ventes estimées de produits ou de services
On verra bien souvent, que certaines activités identifiées comme ayant peu de valeur seront supprimées
purement et simplement de la liste des activités. Le schéma ci-après donne une idée de la démarche
qui pourrait être utilisée.
AAnnaaly
lysseerr
le
less aacctiv
tivitit ééss
CCoolle
lleccte
terr
le
less ccoo ûûts
ts
LLie
ierr to
touuss leless
ccooûûtsts aauuxx
aacctiv
tivititééss
DDééfin
finirir le
less
m
meessuureress
AAnnaaly
lysseerr
le
less ccoo ûûts
ts
Figure 143 : La démarche ABC
Cette démarche peut être utilisée dans le cadre de la simulation et de l’optimisation de processus.
Analyser les activités
L’analyse des activités débute par celles qui ont été modélisées dans un outil et dont les acteurs ont été
identifiés. Ces derniers seront alors interviewés de manière à bien comprendre ce qui est important
dans l’accomplissement de leurs tâches.
L’analyse des activités doit permettre d’identifier si l’activité:

• apporte de la valeur ajoutée ou non,
• est primaire ou secondaire,
• est obligatoire ou non.
De manière générale, on considère une activité à valeur ajoutée toute activité qui consiste à apporter
de la valeur au client.
Collecter les coûts
Cette partie consiste en la collecte des coûts en relation avec :

• la création du produit ou du service,
• les salaires,
• la Recherche et développement,
• les fournitures
• les autres postes impactant la réalisation du produit ou du service.
Dans bien des cas, il n’existe aucune documentation de ces coûts et celle-ci devra être réalisée lors du
projet.
Lier tous les coûts aux activités
Une fois que tous les coûts ont été collectés, il est nécessaire de correctement identifier ceux associés
à une activité précise. Ils doivent comprendre non seulement les aspects budgétaires mais également
toutes les informations nécessaires à la qualification de dérives potentielles ainsi que le niveau des
profils utilisés pour réaliser les tâches. Combien d’entreprises ont supprimé des fonctions de support
pour effectuer des économies immédiates sans vérifier le fait que de confier certaines tâches à d’autres
profils peut engendrer un coût plus important que de garder certaines fonctions de support en nombre
suffisant.
Par ailleurs, les coûts peuvent être répartis sur plusieurs domaines de l’entreprise voire filiales. Il faudra
également les collecter.
Définir les mesures
Les mesures identifiées permettent, ici, de connaître le coût unitaire d’une activité. Parmi les différentes
mesures identifiées, l’une d’entre elle sera la mesure la plus représentative de l’activité et permettra
d’avoir un œil pour en mesurer son efficacité. Ensuite, il est important de pouvoir dissocier le coût total
de l’activité du coût unitaire et du nombre de livrables produits par l’activité.
Analyser les coûts
Cette dernière étape doit permettre d’identifier les activités qui coûtent cher à l’entreprise et parfois
de manière démesurées. Si l’on prend les techniques de l’analyse de la valeur, on comprendra ne pas
vouloir dépenser plus pour certaines activités. C’est d’ailleurs à ce moment que certaines activités seront
supprimées. Souvent, la suppression de l’une d’entre-elle finit par apporter un produit ou service de
meilleure qualité. Cela peut également améliorer la perception que le client a vis-à-vis des produits et
services.
L’analyse de la valeur et les processus

L’analyse de la valeur est une méthodologie qui s’applique à la conception fonctionnelle de produits et
qui consiste en une évaluation des fonctionnalités et des coûts associés en éliminant celles qui sont à
faible valeur ajoutée et coût important.
Elle permet d’évaluer notamment la valeur perçue par le client.
Niveau de satisfaction
Valeur per çue =
Prix d’acquisition consenti
Figure 144 : Calcul de la valeur perçue
La valeur perçue est le rapport entre le niveau de satisfaction de l’utilisateur du produit ou du service
par rapport au prix payé pour l’obtenir.
L’analyse de la valeur consiste principalement en une identification des fonctions et de leur coût associé.
Pour chacune de ces fonctions, des questions fondamentales sont posées du type : pourquoi ? L’important
est de ne prendre en compte que les vrais besoins. Un besoin pour un utilisateur en particulier peut
paraître important. Cette importance peut être toute relative et n’avoir qu’un poids assez faible. Alors
cette fonction est classée comme non prioritaire. Il en sera de même pour les processus/procédures de
l’entreprise. Certaines n’auront que peu de valeur ajoutée et ne seront donc pas prioritaires.
Ce qui est important de noter dans l’analyse de la valeur est qu’elle doit être réalisée le plus en amont
possible de la réalisation. Bien entendu, on pourra toujours l’utiliser ensuite, mais l’objectif sera alors
plutôt de savoir s’il est intéressant de continuer le projet en l’état ou non.
La démarche de l’analyse de la valeur se fait en groupes de travail pluridisciplinaires. On cible tous les
efforts sur les (vrais) besoins des utilisateurs.
La première étape consiste en une analyse fonctionnelle et en une mesure de la valeur du processus
existant. Les enquêtes permettront d’avoir une réelle perception de cette valeur, celle-ci étant ensuite
discutée lors des réunions de groupe. L’objectif est de comprendre le fonctionnement du processus
et d’identifier les dysfonctionnements de chacune de ses étapes. La valeur du processus dans son
état actuel est calculée (valeur actuelle). Lors du recueil des besoins, des faux besoins vont émerger
et des solutions vont être proposées, alors que l’objectif est de connaître le fonctionnement actuel et
de comprendre les insatisfactions actuelles. Donner des solutions n’est pas non plus à l’ordre du jour
durant cette étape. Pour évaluer la performance de chacune des activités du processus, on doit se baser
sur des critères comme :
• Les conditions de service,
• Le niveau de qualité acceptable,
• L’efficience acceptable,
• Les critères pour lesquels on se retrouvera dans un mode dégradé.
Ces critères permettent très bien d’identifier des activités inutiles ou avec peu de valeur ajoutée.
A
A nalys
nalys ee
fonc
fonc tio
tionne
nnelle
lle
S olutions C ible
Valeur
Valeur Valeur
ac tuelle ccible
ible
Figure 145 : Démarche de l’analyse de la valeur
La seconde étape consiste en l’identification des solutions possibles permettant d’améliorer le processus. Il
faut prêter attention à ne pas préjuger des solutions. La liste se doit d’être exhaustive et sans autocensure.
Les solutions peuvent provenir d’une modification nécessaire de l’organisation plutôt que du processus.
On peut également s’apercevoir que l’insatisfaction provient de cas exceptionnels qui interviennent plus
régulièrement que prévu !
La troisième étape consiste en la construction de la cible. On identifie les solutions les plus plausibles
ainsi que les coûts associés. On évalue la satisfaction potentielle pour chacune des solutions proposées
et surtout pour le résultat final du processus. On peut faire intervenir quelques bons clients pour
plus de pertinence. Le rapport coût/valeur modifié constitue alors un bon élément décisionnel. On ne
prendra en compte que les besoins les plus importants. Ce que l’on peut également appeler les besoins
« justes nécessaires ».
Bien entendu, nous pourrions encore parler bien longtemps de l’analyse de la valeur. C’est une véritable
discipline. La réelle analyse fonctionnelle n’étant pas faite dans bien des cas ! Néanmoins, même si le
coût de cette analyse paraît important, il a souvent été démontré les bienfaits de celle-ci. Des exemples
ont même démontré les bénéfices tirés de l’arrêt de certains projets qui n’avaient en fait, que très peu
d’intérêt pour l’utilisateur final, que celui-ci soit interne ou externe.
L’alignement du métier et du système d’information

Il n’existe que peu de lien mécanique entre le système d’information et la performance de l’entreprise.
Néanmoins, le système d’information peut contribuer à la bonne performance de l’entreprise par l’usage
qu’il en est fait et de l’adéquation des outils mis à disposition. Vous l’avez peut-être déjà compris, mais
l’enjeu majeur de l’alignement métier/informatique est principalement dans le fait que l’informatique
doit de plus en plus aider la bonne application de la stratégie de l’entreprise en devenant un atout
différenciant de cette stratégie.
Pour permettre cet alignement, il est important de bien prendre en compte les enjeux métier ainsi que
les enjeux IT.
Dans le cadre des enjeux métier il va être nécessaire :

• de bien comprendre les enjeux métier ainsi que l’écosystème,
• de bien tirer profit des innovations technologiques.
Dans le cadre des enjeux IT, il va être nécessaire
• d’industrialiser la production des produits et services fournis par l’IT,
• de renforcer la flexibilité et la réactivité du système d’information,
• de définir les principes d’architecture, de transformation et de gouvernance du SI.
Si on revient au Business Process Management, les enjeux métier sont identiques et les outils de BPM
permettent de conduire la démarche en apportant un cadre et des innovations technologiques qui, si
utilisées correctement, rendront les services attendus. Par contre il est important de prendre en compte
les contraintes mais également les opportunités qu’ouvre le système d’information dans l’application de
la stratégie d’entreprise. Il est à noter que la stratégie s’applique à n’importe quel domaine ou activité
de l’entreprise.
Aujourd’hui encore, l’informatique est vue comme un centre de coûts alors que dans le cadre de
l’alignement métier/IT, l’informatique doit faire partie de la chaîne de valeur. Les données collectées et
présentes au sein du système d’information doivent faire partie du patrimoine de l’entreprise et le système
d’information doit donc être considéré comme faisant partie de l’actif de l’entreprise. Il faut également
mettre en place les procédures qui permettront de mieux tirer parti de l’informatique. Le système
d’information est découpé en domaines fonctionnels, ce qui amène naturellement à un fonctionnement
en silos. L’un des points importants est que le fonctionnement et la communication au sein des équipes
doivent être traités dans un mode transversal et en l’occurrence, en intégrant métier et IT.
Maintenant, pour que l’alignement métier/IT puisse être effectué correctement, il sera nécessaire
de prendre en compte quelques bonnes pratiques comme :
• S’assurer que la direction de l’entreprise est bien consciente des risques encourus du fait
d’un mauvais alignement entre métier et Informatique
• L’Informatique doit participer aux réunions métiers et travailler de concert avec eux pour
valider les besoins IT répondant au mieux aux enjeux métiers
• Valider la disponibilité de ressources pour comprendre les besoins métiers, étudier correctement
le niveau de service nécessaire de l’IT pour comprendre le niveau d’engagement nécessaire
• Fusionner les plannings du métier et de l’Informatique pour en vérifier et valider les cohérences
• Faire participer l’Informatique aux comités de direction régulièrement pour comprendre tous
les enjeux stratégiques
• Afficher le programme Informatique de manière transparente et permettre ainsi au métier d’en
comprendre le fonctionnement. Cela permet également de faire comprendre les structures de
coûts et d’avoir un niveau de compréhension du métier plus élevé
• Communiquer la stratégie ! La direction de l’entreprise définie une stratégie. Elle doit être
communiquée à tous les niveaux. Une stratégie non comprise c’est potentiellement un manque
d’adhésion fort des opérationnels et donc un risque accru de non atteinte.
• L’informatique doit avoir une vision :
~ des innovations technologiques et comment les utiliser au mieux par rapport au
contexte de l’entreprise,
~ de la stratégie informatique à mettre en place pour mieux accompagner
les objectifs stratégiques de l’entreprise.
La gestion des processus sera un moteur important dans cet alignement métier/informatique et ne peut,
en aucun cas, être conduite autrement que conjointement : d’où l’importance de la gouvernance des
processus.
La gouvernance des processus

La gouvernance des processus est particulièrement importante dans l’alignement du métier et de l’IT. Le
tableau « Figure 8 : Performance de la gouvernance » montre qu’en fonction du mode de gouvernance
choisi dépendra son efficacité. On comprend alors toute l’importance de bien placer le pouvoir de
décision et de faire en sorte que métier et informatique se parlent et agissent ensemble.
La mise en place d’une méthodologie ne peut que favoriser la collaboration des différentes équipes. Choisir
des outils et techniques qui permettent de favoriser le dialogue entre métier et IT est un véritable levier,
en particulier pour la modélisation des processus. Sans travail collaboratif, pas de processus efficaces.
Un autre point important sera de définir un glossaire de termes commun. Ce glossaire est construit au
fur et à mesure de l’avancée des projets et permet de valider une définition unique et compréhensible
par tous des termes qui sont employés. Un modèle, par exemple, ne comprendra par les mêmes objets
en fonction de la population qui va le définir. Néanmoins, l’IT pourra valider la faisabilité des principes
demandés par le métier. C’est pourquoi, dans ces projets complexes à forts objectifs stratégiques, la
gouvernance se doit d’être commune. Bien entendu, cela n’indique pas que la gouvernance sera simple,
mais le sponsor du projet pourra et devra alors orienter les décisions quand cela s’impose.
P o u v o ir de déc is io n
Métier IT C o n jo in t
Métier
- Principes IT
- Besoins en applications métiers
- Investissements IT
IT
- Architecture IT
Types de-décisions
Infrastructure
Figure 146 : Performance de la gouvernance
Un exemple serait si le métier devait définir les principes IT. Et si les principes ainsi définis allaient à
l’encontre de ceux existants ? Le résultat aurait des chances d’être infaisable.
Autre exemple concret : définir un périmètre trop ambitieux dans un délai court peut mettre en échec
le projet ! Les membres n’en tireront alors que frustrations et déceptions. Quid de valider un premier
périmètre conjointement aussi simple soit-il ? Le succès et la communication autour du projet ne sont-
ils pas plus importants ?
Autre exemple, la carte des rôles et responsabilités ! Celle-ci doit être définie en commun. Bien entendu
une trame peut être proposée, mais la validation par les 2 parties est primordiale. Chacun doit savoir
ce qu’il a à faire et surtout quand ! Les charges induites peuvent être non négligeables des 2 côtés. Et
d’abord, pourquoi parler de 2 côtés ! Choisir un mode intégré est bien plus efficace. Si des personnes
sont à temps partiel, alors que des jours ou demi-journées soient bloquées à cet effet de manière à ce
que les réunions de travail puissent se dérouler correctement et le calendrier respecté.
Autre point, le centre de compétence processus ! Un centre de compétence peut faciliter la gouvernance
et permettre de mieux capitaliser les expériences vécues sur les différents projets (librairie de processus,
bonnes pratiques, méthodes d’évaluation de la performance des processus, définition de la priorité des
différents projets, etc.).
Pour faciliter la gouvernance des projets de gestion des processus, il est donc important de s’appuyer
sur les 9 principes suivants :
1. établir et utiliser des standards en termes de méthodologie et de démarche projet,
2. Définir la priorité des différents projets de manière à ne travailler, dans un premier temps, que
sur ceux à forte valeur ajoutée,
3. Définir la charte des rôles et responsabilités de tous les acteurs du projet en y incluant une
échelle de temps permettant à ces acteurs d’organiser leur travail,
4. Un sponsor permettant de palier aux manques de décisions ou aux difficultés de décisions que
pourrait rencontrer le projet doit être identifié et doit être à un bon niveau de hiérarchie,
5. Mettre en place un centre de compétence permettant de gérer :
a. Une librairie de processus, sous processus ou activités
b. Une base de gestion de la connaissance pour y trouver l’ensemble des bonnes pratiques
c. Les méthodes à utiliser lors des différentes phases de projets de BPM et permettent
de cadrer les activités et livrables
d. La priorité des projets de manière à ne se consacrer qu’aux projets ayant des apports
visibles, à minima au niveau des clients que ceux-ci soient internes ou externes.
6. Communiquer largement sur les succès. Nos confrères anglo-saxons parlent d’ailleurs
d’évangélisation,
7. Permettre au modèle de gouvernance d’évoluer en fonction de l’évolution des projets,
8. Idéalement, mettre en place un système de reconnaissance (prime, bonus, variables, …) et le
respecter. Les équipes n’en seront que plus motivées,
9. Conduire le changement de manière, en particulier, à limiter les résistances. Il y a toujours des
personnes réfractaires à la mise en place d’une gestion des processus. Ne pas conduire ce
changement, c’est potentiellement ne pas réussir le projet.
Bien entendu, en plus de ces principes, la prise en compte de la culture d’entreprise est un élément
vital et l’oublier ne serait que conduire les projets à une mort certaine. La communication des différents
intervenants doit prendre en compte l’historique de l’entreprise de manière à limiter les conflits possibles
et surtout les non compréhensions qui pourraient résulter de cet oubli.
Le positionnement concurrentiel
Pour terminer cet ouvrage, il est tout à fait naturel de revenir sur ce vers quoi le marché oblige les sociétés
à aller. La tension sur les prix les oblige à chercher à se renouveler, à innover. Faute de quoi, elles perdent
toute leur compétitivité, en particulier face aux marchés émergeants comme les marchés asiatiques.
L’approche processus peut être un véritable levier d’apport d’excellence pour l’entreprise. Elle peut lui
permettre de se différencier par rapport à ses concurrents. Une entreprise ne doit pas toujours baisser
ses prix, sauf contrainte particulière, mais doit apporter quelque chose de plus que le client pourrait
souhaiter. Parmi toutes les armes stratégiques, il est certain que de proposer des coûts les plus bas est
vraisemblablement l’arme la plus spontanée. C’est cette arme qui est la cause principale de recherche
de réduction des coûts des entreprises à des fins de préserver la marge opérationnelle. Néanmoins,
l’innovation peut réduire les coûts à plus ou moins long terme et donc annuler des différences entre
des concurrents d’un même segment de marché.
La concentration peut être une autre arme qui consiste à se focaliser sur une partie du marché pour
laquelle l’entreprise peut apporter le plus d’éléments différenciant. C’est pourquoi, toute entreprise a
besoin de comprendre son positionnement et d’étudier comment, pour certains produits ou services,
elle peut se différencier. La différenciation peut également permettre de ne pas affronter la totalité des
concurrents d’un marché. La concentration ainsi réalisée par l’entreprise en fera son positionnement
ou, tout du moins, le positionnement du produit ou service concerné.
Les entreprises peuvent se situer dans 4 catégories différentes que sont :

• Généraliste,
• Spécialisée dans des services de commodité,
• Spécialisée dans des services très recherchés,
• Créatrice de valeur.
connaissance
Niveau de
Niveau de
connaissance
T r ès recherch é
Créatrice
Spécialis ée
de valeur
V a le ur a jout é e
Généraliste Spécialis ée C om m odité
Figure 147 : Positionnement concurrentiel
Connaître son marché et ses concurrents est primordial et permet de réagir en fonction des besoins du
marché et de la volonté affichée ou non de se différentier sur un segment particulier. Dans le cadre du
BPM, le « benchmarking » de processus peut être un moyen d’identifier les zones de différenciation.
Les entreprises qui ont les tarifs les plus élevés sont celles qui se situent dans la partie supérieure et
qui sont très recherchées pour leur domaine d’expertise ou pour la qualité de leurs produits. Mais
pas seulement. Elles sont également recherchées pour leur niveau de connaissance qui peut être soit
au niveau d’un segment de marché ou d’un secteur tout entier, soit de par leur approche innovante
qui apporte beaucoup de valeur aux clients. Les produits et services proposés sont, généralement, de
meilleure qualité.
Les entreprises qui se situent dans la partie « commodité » sont celles qui proposent des services
spécialisés, ou plus généralistes à des tarifs plus intéressants.
Celles qui sont au niveau « très recherché » doivent néanmoins investir plus pour rester dans cette
partie du quadrant. Le plus complexe étant pour celles qui apportent de la valeur aux clients car les
investissements doivent rester constants pour permettre à l’entreprise de rester dans cette partie. Pour
certains secteurs d’activités, ces entreprises peuvent se positionner plus favorablement sur des marchés
dits « de masse ».
La gestion des processus métiers peut apporter ces éléments de différenciation. Le simple fait d’apporter
une démarche cadrée à des clients (approche par les processus) apporte de la valeur ajoutée. Plus
ces processus seront agiles et flexibles, plus l’entreprise pourra mieux se positionner et surtout plus
rapidement que ses concurrents : d’où l’importance de bien connaître ses processus internes, mais aussi
externes. La mise en place d’une démarche d’optimisation permet de garantir une meilleure efficience
de l’entreprise. Le pouvoir de réagir face aux aléas du marché, qui, parfois sont brutaux et complexes
à gérer, a un coût et demande un minimum de capacité de pilotage opérationnel.
Bref, utilisez ou non du BPM, mais de plus en plus d’entreprises ont démarré une telle démarche. Plus
votre entreprise tardera, plus le saut à réaliser pour revenir à un niveau équivalent à vos concurrents
sera complexe et surtout coûteux.
Glossaire
A2A Application to application.

On se réfère à l'échange entre 2 applications ou à l’intégration inter applicative du SI
ABAP Advanced Business Application Programming

C’est un langage de programmation de 4ème génération qui fait partie du progiciel
SAP de la société allemande SAP.
API Application Programming Interface

C'est une bibliothèque de fonctions utilisée par les développeurs d'applications
B2B Business to Business.

Services permettant la mise en relation d'entreprises. Ces services sont, en général,
des services électroniques
B2C Business to Consumer

C'est la relation directe entre une entreprise et son client
BAM Business Activity Monitoring

Outils qui, par le biais de sondes placées au sein du système informatique,
permettent de remonter des indicateurs pour l'évaluation de la performance
d’un processus
Benchmarking Le benchmarking de processus est une technique de gestion de la qualité qui

consiste en une étude et analyse d’un processus utilisé par des entreprises d’un
même secteur ou d’un secteur différent
Blog C’est un journal personnel disponible sur le web permettant d’échanger librement
avec les internautes.
BP Business Process
Processus métier
BPA Business Process Automation

Automatisation des processus. Les processus sont soit métiers soit d'échanges
BPA Business Process Analyse

étude et analyse de processus métiers. On y intègre souvent la modélisation
des processus.
BPDM Business Process Definition Metamodel

C'est un référentiel de modèles métiers définit par l'OMG (Object Management
Group). Les modèles de processus sont formalisés avec la notation BPMN. Le
principal objectif est de permettre les échanges de modèles entre outils de
modélisation et/ou d'intégration de processus
BPI Business Process Integration

Intégration des processus d'échanges et métiers
BPM Business Process Management

Gestion des processus métiers. Se réfère à la discipline de la gestion des processus,
mais également aux outils.
BPMN Business Process Modeling Notation
Notation standardisée des processus métiers. Cette notation définie par l'OMG
permet de représenter de manière graphique un processus métiers, ses sous-
processus et ses activités et/ou tâches.
BPMS Business Process Management Suites

Outils complets de gestion des processus permettant de gérer le cycle complet d'un
processus métier. De son formalisme à son pilotage.
BPN Business Process Network

Réseau d’accès à des processus ou parties de processus. Ces processus pourront
être proposés par des sociétés spécialisées.
BPO Business Process Outsourcing

Externalisation de processus de l’entreprise. En général, l’entreprise confie une
partie de son activité à un prestataire externe
BR Business Rules
Règle métier
BRE Business Rules Engine

Moteur de règle. C'est la partie qui gère l'exécution des règles métiers.
BRM Business Rules Management

Gestion des règles métiers. Il existe des outils dédiés qui permettent d'externaliser
les règles métiers des applications de manière à rendre plus flexible les application
en permettant de modifier les règles sans avoir à changer le code de l'application
BSC Balanced Score Card

C’est un tableau de bord prospectif qui intègre des éléments choisis et mesurés qui
sont fonction de la stratégie de l’entreprise
BSM Business Services Management

Interfaces de reporting (rapports) temps réel permettant de combiner des
métriques techniques et des métriques métiers afin de piloter la qualité des services
métiers du SI
Client Léger Un client léger est une application accessible par l’utilisation d’un navigateur
Internet et qui ne nécessite pas de déploiement logiciel sur le poste de travail.
CPO Chief Process Officer

C'est un directeur responsable du choix et du suivi de la qualité des processus
métiers de l'entreprise. Il définit la stratégie des processus métiers en rapport avec
la stratégie de l'entreprise.
CRM Customer Relationship Management

Cela signifie "Gestion de la Relation Client"
CVS Concurrent Versions System

C’est un système de gestion de configuration qui permet de tracer les versions
successives d’une application ou d’un logiciel. L’outil est bien adapté aux
développements réalisés en parallèle.
Data Mart Le Data Mart est une base de donnée décisionnelle décentralisée qui est orientée
sur un thème particulier (ressources humaines, marketing, ventes, …).
DOE Design Of Experiment
La conception par expérimentation a pour effet d’avancer en marchant et de voir,
en temps quasi réel, les effets de paramètres extérieurs par l'utilisation d'une
maquette ou d'un prototype.
DSI Directeur des Systèmes d'Information
EAI Enterprise Application Integration

EAI signifie l’intégration des applications d’entreprise ou en d’autres termes, la
manière de faire communiquer des applications entres-elles
Eclipse C’est un projet de logiciel libre proposant des outils de développements universels.
Un grand nombre d’éditeurs utilisent désormais cet environnement.
EDA Event Driven Architecture

C’est un modèle d’architecture qui promeut la production, la consommation, la
détection et la réaction à des événements. Un événement peut être assimilé à un
changement d’état.
EDI Electronic Data Interchange

échanges de données informatisées. On parle d'EDI quand des échanges
concernant des transactions sont réalisées en utilisant des réseaux avec des formats
et protocoles standardisés ou, à minima, normés.
EDIFACT Electronic Data Interchange for Administration, Commerce and Transport

Norme des Nations Unies concernant l'échange de données informatisé pour
l'administration, le commerce et le transport
ERP Enterprise Ressource Planning

en français PGI. Le Progiciel de Gestion Intégré intègre des fonctions comme la
comptabilité, la gestion financière, la gestion des ressources humaines, …
ETL Extract Transform & Load

Outils permettant d’extraire des données d’une application, de les transformer en
un autre format et de les recharger dans une autre application. Ces outils
permettent de traiter des volumes plus importants que les outils d’EAI
ETP équivalent Temps Plein

Nombre de personnes, employées à temps plein, nécessaires pour
l’accomplissement d'activités et de tâches.
ESB Enterprise Service Bus

Nouveau type d’outil d’intégration basé sur des standards et qui comporte certaines
fonctions similaires à un EAI
Framework Squelettes permettant de cadrer la démarche mais apportant parfois des outils qui
sont spécifiques pour assurer du suivi et quelques fonctionnalités supplémentaires
FTP File Transfer Protocol

C'est un protocole de communication dédié à l'échange de fichiers informatiques
GED Gestion électronique de document

Système informatique de gestion, classement, archivage, recherche et stockage de
documents électroniques structurés et non structurés
HTML HyperText Markup Language

C'est un langage informatique de description conçu pour écrire les pages web
HTTP HyperText Transfer Protocol
C'est le protocole développé pour le web utilisé lors de la communication entre un
ordinateur et un serveur web.
IAM Identity Access Management

Gestion des identités. Suite d’outils qui permet de gérer les utilisateurs et leurs
accès à partir d’un point central dans le cas d'applications multiples. Les
informations sont stockées dans un référentiel spécialisé qui peut stocker jusqu’à
des certificats spécifiques par application et toute autre information nécessaire.
IETF International engineering Task Force

C’est une organisation internationale qui regroupe des entreprises et des experts
pour la définition des standards de l’Internet.
Integration Consortium Organisme international focalisé sur les problématique

d’intégration et qui regroupe des clients, des éditeurs et des
intégrateurs de solutions technologiques comme l’EAI, les ETL, les plates-formes
B2B. Cet organisme définit des principes, règles et méthodes.
Introspection C’est la capacité d’un adaptateur ou connecteur (EAI) à prendre en compte les
mises à jour d’un paramétrage ou du modèle de données de l’application pour
laquelle il assure l’interface
ISO International Standardisation Organisation Organisation internationale de

normalisation. En France c’est l’AFNOR
IT Information Technology
Les technologies de l’information
ITIL IT Infrastructure Library

C’est un référentiel de processus appliqués à l’IT pour contribuer à l’amélioration
du système d’information et de son organisation
J2EE Java 2 platform Enterprise Edition

C’est un framework JAVA développé par SUN Mirosystems permettant de
construire des applications d’entreprise. Ce framework apporte un grand nombre
de standards comme pour la connectivité, le scripting de pages utilisateurs, la
connectivité à des bases de données, des modèles de communications, etc.
JCA Java Connector Architecture

C'est une solution permettant l'intégration d'ESB avec des serveurs d'applications
ainsi que l'intégration des applications de l'entreprise
JMX Java Management eXtensions

C’est une API permettant de gérer le fonctionnement d’une application. Les plates-
formes de supervisions utilisent ces APIs pour surveiller le fonctionnement
d’applications JAVA
KPI Key Performance Indicator

Les Indicateurs clés de performance sont des mesures quantifiables comme des
volumes traités, des délais, des durées, etc
LDAP Lightweight Directory Access Protocol

C'est un protocole standard permettant de gérer des annuaires contenant des
informations sur des utilisateurs par exemple(droits, …)
MOA Maîtrise d'ouvrage
MOE Maîtrise d'œuvre
Notarisation C’est la capacité permettant d’enregistrer des éléments d’un processus ou d’une
activité critique. Ces éléments pourraient être utilisés ultérieurement comme
preuves pour garantir l’exactitude d’informations (les date et heure d’exécution,
par exemple).
OLAP Online Analytical Processing

Désigne des bases de données multi dimensionnelles destinées à l’analyse des
données sous différents angles de vue
OMG Object Management Group

C’est une association américaine dont l'objectif est de standardiser et promouvoir
le modèle objet sous toutes ses formes.
OMI Open Management Interface

C’est une spécification qui a pour vocation de définir la manière de gérer les
composants d’une plate-forme d’intégration. Cette spécification a été établie par
Hewlett Packard et webMethods Inc..
Orchestration Dans une architecture SOA, on a besoin d’exécuter des services pour qu’une
fonction soit exécutée dans son ensemble. On dit que ces services doivent être
orchestrés.
PAQ Plan d’Assurance Qualité

C’est généralement un document contractuel qui définit l’ensemble des
dispositions prises pour assurer la qualité du produit fourni ou des prestations
réalisées. On décrit ce que l’on fait : Qui, quoi, où, comment et quand
PDF Portable Document Format

C’est un format de fichier créé par la société Adobe Systems. C’est un format ouvert
pour lequel la société Adobe met à disposition un lecteur. Ce format de fichier est
aujourd’hui très largement diffusé notamment dans le cadre de la dématérialisation
de documents.
Portail Un portail Web est un site Web qui offre une porte d'entrée unique sur une
gamme complète de ressources et de services (messagerie électronique, espaces de
publication, moteur de recherche, états de processus, etc.)
Prédictibilité Caractère d'un phénomène prédictible. Que l'on peut prévoir à l'avance. On parle
d'indicateur prédictif
Processus Suite continue d'opérations constituant la manière de fabriquer, de faire quelque

chose ; procédé technique. Processus de fabrication.
Processus étendu Un processus étendu est un processus qui va au-delà de l’entreprise pour
avoir certaines activités réalisées à l’extérieur de l’entreprise.
ROI Return Of Investment

Permet de quantifier les gains financiers apportés ainsi que le délai d’obtention de
ces gains
Rollback On entend par là, la possibilité de revenir à un état précédent pour des
données
ayant été insérées ou modifiées au sein de processus ou applications. Ce
mécanisme existe notamment dans les moteurs de bases de données.
RosettaNet C’est un organisme qui regroupe des acteurs du e-business et qui définit des
normes d’échanges entre les sociétés. Beaucoup d’entreprises utilise ce format
d’échanges.
SAP Systems Applications and Products for data processing

éditeur de logiciel allemande qui propose un progiciel de gestion. On sous-entend
le progiciel quand on indique SAP.
SCM Supply Chain Management

C’est la gestion globale de la chaîne logistique en partant du fournisseur jusqu’au
client final.
Short list La traduction littérale est « liste succincte ». Il faut entendre par là une liste de
candidats présélectionnés par rapport à une liste de critères.
SI Système d’information
C'est un ensemble de moyens (organisation, acteurs, systèmes informatiques,
procédures et méthodes) nécessaires au traitement des informations au sein de
l’entreprise
SLA Service Level Agreement

Contrat définissant le niveau de qualité de service qu’un fournisseur propose à ses
clients
SLM Service Level Management

Gestion de la qualité de service proposé par un fournisseur permettant de valider
que les promesses faites sont tenues
SNMP Simple Network Management Protocol

C’est un protocole de communication permettant aux administrateurs de gérer des
équipements réseaux et infrastructures pour en diagnostiquer les
dysfonctionnements.
SOA Services Oriented Architecture

Une Architecture orientée services met en œuvre des services qui utilisent des
standards pour leur accès et facilitant ainsi les interactions applicatives.
SOAP Simple Object Access Protocol

C'est un protocole de transmission de messages entre des objets qui sont distants.
Structure blanche Canevas logiciel réutilisable dans un autre contexte que celui
utilisé à l'origine.
SWIFT Social for Worldwide Interbank Financial Telecommunications

Société qui met à disposition un réseau international de transmission de messages
financiers entre les banques. Le réseau SWIFT compte environ 3000 banques
membres
Time to market Le « time to market » désigne le délai de mise à disposition sur le marché d’un
nouveau produit ou service
TOGAF The Open Group Architecture Framework

C'est un framework d'architecture
UDDI Universal Description, Discovery and Integration

C’est la spécification qui indique la manière de publier et de retrouver des
informations relatives à des services web.
VAN Value Added Network
VOC Voice Of the Customer (Six Sigma)

La voix du client. On parle d’expression des besoins des clients.
Web 2.0 Le web 2.0 est un ensemble de technologies permettant d’apporter aux utilisateurs
une interface enrichie d’informations dont les sources proviennent de multiples
applications. L’utilisateur a d’une part une vue enrichie (on parle d’application
Internet riche) et d’autre part bénéficie d’un chargement des pages plus rapide, car
les informations arrivent de manière asynchrone ce qui n’est pas le cas des pages
dynamiques web.
WfMC Workflow Management Coalition

Organisation qui a en charge la définition du modèle de référence ainsi que sons
architecture fonctionnelle et les standards associés.
WIKI C’est un site dynamique dont les pages peuvent être modifiées par tout utilisateur
Workflow Un workflow est un système permettant d'automatiser un flux d'informations au

sein d'une organisation, par exemple en transmettant automatiquement des
documents entre des personnes.
WSDL Web Services Description Language

Il décrit une interface publique d'accès à un service web.
WYSIWIG What You See Is What You Get

Vous voyez le résultat final à l’écran.
XML eXtended Markup Language

C'est un langage informatique de balisage extensible.
XPDL XML Process Definition Language

C’est un langage qui décrit un processus métier et qu’un moteur de BPM ou de
Workflow utilise pour l’exécuter. Certains outils de modélisation exportent leurs
modèles au format XPDL.
XSLT eXtended Stylesheet Language Transformations

C’est un langage de transformation plutôt fonctionnel. Il est utilisé pour
transformer un format XML en un autre ou vers un dialecte particulier.
Table des illustrations
Figure 1 : Profils des lecteurs par chapitre 15

Figure 2 : Composants d’une suite BPM 19
Figure 3 : Sentiment et réalité du BPM 20
Figure 4 : Démarche Quadrangulaire 21
Figure 5 : Les 4 perspectives du BPM 22
Figure 6 : Courbe d'adoption des technologies 25
Figure 7 : Lien entre agilité et évolutions du SI1 31
Figure 8 : Organisation et pyramide inversée 34
Figure 9 : Activités et responsabilités du métier 34
Figure 10 : Activités et responsabilités de l'IT 35
Figure 11 : Activités et responsabilités partagées entre le métier et l'IT 35
Figure 12 : Efficacité du pilotage opérationnel 37
Figure 13 : La communication et la notion de leader 38
Figure 14 : Les sentiments et la résistance au changement 39
Figure 15 : Les 4 axes de la conduite du changement 40
Figure 16 : Les phases de la conduite du changement 40
Figure 17 : Les familles de processus 44
Figure 18 : Vision client d'un processus 47
Figure 19 : Processus verticaux et horizontaux 47
Figure 20 : Approche Top-Down 48
Figure 21 : Approche Bottom-Up 49
Figure 22 : Approche mixte Top-Down/Bottom-Up 50
Figure 23 : Démarche Topup 50
Figure 24 : Cycle de vie du BPM 51
Figure 25 : Efforts à fournir 52
Figure 26 : Les 3 axes de la supervision 54
Figure 27 : Méthodes et BPM 57
Figure 28 : Human Performance Technology 59
Figure 29 : Décomposition des processus SCOR 61
Figure 30 : Les 4 axes de la pensée « Lean » 62
Figure 31 : Niveaux de maturité CMMI 64
Figure 32 : Variations et performance 66
Figure 33 : Vision Six Sigma d’un processus 67
Figure 34 : Organisation d’un projet Six Sigma 68
Figure 35 : Processus "Cœur de métier " et "support" 68
Figure 36 : Lien satisfaction client et profits 69
Figure 37 : La démarche Six Sigma DMAIC 69
Figure 38 : Les niveaux de sigma 70
Figure 39 : Principaux livrables de Six Sigma 70
Figure 40 : Formule de calcul du Sigma d'un processus 73
Figure 41 : Exemple de Diagramme 73
Figure 42 : Graphique pour représenter un échantillonnage 74
Figure 43 : Exemple de dysfonctionnement 74
Figure 44 : Représentation graphique du dysfonctionnement 75
Figure 45 : Complémentarité Six Sigma et BPM 78
Figure 46 : Comparaison entre Six Sigma et Lean 79
Figure 47 : Complémentarité des outils Six Sigma et Lean 79
Figure 48 : Exemple de radar pour le degré de maturité global 81
Figure 49 : Graphique de maturité des processus 82
Figure 50 : Niveaux de maturité de l'intégration 83
Figure 51 : Les étapes de la formalisation et optimisation 85
Figure 52 : Les composants d’un référentiel des processus 86
Figure 53 : Exemple de liste de processus 87
Figure 54 : Le Processus et ses composants 88
Figure 55 : Processus de modélisation 89
Figure 56 : La fusée à 3 étages 90
Figure 57 : Représentation objet UML 92
Figure 58 : Des objets disponibles de la notation BPMN 93
Figure 59 : Gestion de la chaîne des utilisateurs 94
Figure 60 : Des données à tous les niveaux 96
Figure 61 : Cycle macroscopique de l'analyse et optimisation 98
Figure 62 : Exemple d'optimisation 99
Figure 63 : Les 2 objectifs de l'analyse 99
Figure 64 : Processus comprenant des sous processus 101
Figure 65 : Les 4 catégories de l'Enterprise Architecture 102
Figure 66 : Processus de reenginnering et optimisation 104
Figure 67 : Niveaux des efforts à fournir 104
Figure 68 : Exemple de matrice de processus 105
Figure 69 : Interfaces traditionnelles 106
Figure 70 : Interfaçage avec un EAI 107
Figure 71 : Accès client web 108
Figure 72 : Processus étendu 109
Figure 73 : Entreprise étendue 109
Figure 74 : Processus étendu 110
Figure 75 : Automatisation des processus 111
Figure 76 : Modèle fonctionnel de l'EAI 112
Figure 77 : Modèle de référence défini par le WfMC (Source WfMC) 113
Figure 78 : Diagramme d'un processus très simple (BPMN) 114
Figure 79 : Vue XPDL du processus simple 115
Figure 80 : Utilisateurs, rôles et groupes dans l'organisation 116
Figure 81 : Répartition Processus et Règles métiers 119
Figure 82 : Le BPM et le modèle OSI 120
Figure 83 : Niveau d’évolution nécessaire aux outils actuels 121
Figure 84 : Evolution du marché du BPM 121
Figure 85 : Principaux standards de modélisation et exécution 123
Figure 86 : Mesure des processus 125
Figure 87 : Seuils d'alerte des indicateurs : baselining 127
Figure 88 : Parties suivies d'un processus 127
Figure 89 : Classes d'indicateurs du BPM 128
Figure 90 : Indicateurs et hiérarchie 129
Figure 91 : répartition des indicateurs 129
Figure 92 : Utilisateurs des indicateurs 131
Figure 93 : Fonctionnalités d'un tableau de bord 132
Figure 94 : Objectifs des 3 types de tableau de bord 133
Figure 95 : architecture d'une solution opérationnelle 134
Figure 96 : architecture d'une solution tactique 135
Figure 97 : Balanced Scorecard 136
Figure 98 : Principales différences entre Scorecard et Tableaux de bord 137
Figure 99 : Le CEP dans le SI 138
Figure 100 : Principe du CEP 139
Figure 101 : Exemples de tableaux de bord 140
Figure 102 : Architecture d'une solution de BAM 141
Figure 103 : Les technologies liées au BSM 142
Figure 104 : Briques principales d'une solution de BPM 144
Figure 105 : Architecture fonctionnelle d'une Suite BPM 145
Figure 106 : Architecture fonctionnelle d'une suite BPM 147
Figure 107 : La transformation de données 149
Figure 108 : Le transcodage 149
Figure 109 : Anatomie d’un Adaptateur/Connecteur 150
Figure 110 : Mécanisme de publication/souscription 151
Figure 111 : Publication de 1 vers N 152
Figure 112 : Pattern : La séquence 154
Figure 113 : Pattern : Le Split 154
Figure 114 : Pattern : La jointure 154
Figure 115 : Pattern : La Jointure Synchronisée 154
Figure 116 : Pattern : Les choix multiples 155
Figure 117 : Pattern : Le XOR 155
Figure 118 : Pattern : La notion de cycle 155
Figure 119 : Pattern : Fin implicite 156
Figure 120 : Pattern : Cas d'annulation 156
Figure 121 : Pattern : Annulation d'une activité 156
Figure 122 : Pattern : Activités multiples sans synchronisation 157
Figure 123 : Pattern : Evénement remarquable 157
Figure 124 : Pattern : Multi instances d'activités 157
Figure 125 : Pattern : Activités parallèles non ordonnancées 158
Figure 126 : Pattern : Choix Manuels 158
Figure 127 : Processus automatisés 158
Figure 128 : Exemple d'écran de documentation d'un processus 163
Figure 129 : Le référentiel de processus et BPDM 164
Figure 130 : Architecture de développement 166
Figure 131 : Evolution des architectures 168
Figure 132 : Architecture SOA et BPM 169
Figure 133 : Notion de producteur/consommateur en mode synchrone 170
Figure 134 : Notion de producteur/consommateur en mode asynchrone 170
Figure 135 : Annuaire de services 171
Figure 136 : La granularité des services 172
Figure 137 : Les niveaux de services 173
Figure 138 : Matrice d’évaluation 176
Figure 139 : Les 3 axes principaux du ROI 179
Figure 140 : Comparaison BPM vs Spécifique 180
Figure 141 : Formule de calcul du pourcentage de ROI 181
Figure 142 : Niveaux de ROI 182
Figure 143 : La démarche ABC 185
Figure 144 : Calcul de la valeur perçue 186
Figure 145 : Démarche de l'analyse de la valeur 187
Figure 146 : Performance de la gouvernance 189
Figure 147 : Positionnement concurrentiel 190
Bibliographie
Il existe un très grand nombre d’ouvrages qui traitent du sujet de la gestion des processus métiers.
Voici quelques un d’entre eux qui sont intéressants et probablement assez complémentaires.
Ouvrages
• Smith et Fingar, Business Process Management – The third wave, Meghan-Kiffer Press, 2003
• Rashid Kahn, Business Process Management – A practical guide, Meghan-Kiffer Press, 2004
• Sarv Devaraj et Rjiv Kohli, The IT Payoff, Financial Time – Prentice Hall, 2002
• P. Norton et S. Kaplan, Le tableau de bord prospectif, Editions d’Organisation, 1998
• H. James Harrington, Erik K.C. Esseling, et Harm van Nimwegen, Business Process Improvment
workbook, McGraw-Hill,1997
• Wayne W. Eckerson, Performance Dashboards, Wiley, 2006
• Olivier Boutou et Lauren Lévêque, Miniguide des indicateurs et tableaux de Bord, AFNOR, 2003
• Joël Ballieu et Claude Boulet, L’analyse de la valeur, AFNOR, 2002
Sites web
Internet regorge de ressources traitant de la gestion des processus métiers, des standards, du SOA,
du Workflow, etc. Nous donnons ici un certain nombre de sites intéressants sur lesquels vous
trouverez des compléments.
www.bijonline.com : Site officiel d’une revue nommée Business Integration Journal. Ce journal
vient de changer de nom pour se nommer désormais Align Journal (http://www.alignjournal.
com). Cette revue spécialisée dans le domaine de l’intégration que ce soit au niveau données ou au
niveau processus, met à disposition un très grand nombre d’articles, de livres blancs, de retours
d’expériences sur des cas concrets de projets. On y retrouve des articles et ressources des principaux
acteurs du marché.
www.bpmi.org : Site initial du Business Process Management Initiative qui est à l’origine des
spécifications du BPMN et BPEL. Le BPMI est désormais fusionné avec l’OMG (Object Management
Group). Tous les documents, stencils BPMN pour Microsoft Visio sont disponibles sur leur site.
www.businessrulesgroup.org Site d’une organisation créée en 1989 et qui travaille à définir ce que
sont les règles métiers et travaille avec l’OMG pour la définition de principes et la rédaction de
spécifications
www.ebizq.net : Site proposant de nombreux articles et livres blancs autour de la « Business
Integration ».
www.ietf.org : Site de l’Internet Engineering Task Force. On y trouve les spécifications de standards
de l’Internet
www.integrationconsortium.org : La mission du consortium d'intégration (IC) est de stimuler la

principale communauté des professionnels de l’intégration des technologies de l'information et et de
réaliser des travaux autour de l'intégration traditionnelle et du SOA pour l’obtention d'une meilleure
agilité et faciliter l'utilisation de ces technologies pour les entreprises.
www.omg.org : Les groupes de travail d'OMG développent des normes d'intégration d'entreprise
pour une large gamme de technologies, et un éventail encore plus large d'industries. Les normes de
modélisation de l’OMG permettent la conception, l'exécution et la maintenance de logiciels et de
processus. On y trouve les spécifications de standards comme UML, BPMN, …
www.opengroup.org : Groupement axé sur l’Enterprise Architecture. Ce consortium est l’auteur de
TOGAF.
www.cigref.fr : C’est le site de l’organisation pour la promotion de l’usage des systèmes
d’information comme facteur de création de valeur et de source d’innovation pour l’entreprise. Cette
organisation regroupe principalement des DSI.
www.supply-chain.org : La Supply Chain Council est un organisme qui a été créé en 1996 et qui a
défini un modèle de référence des processus dans le domaine de la demand/supply chain.
www.w3c.org : C’est le site du World Wide Web Consortium. Ce consortium a pour vocation de
développer des standards pour le Web.
www.processus-metier.fr : Ce site est le blog de l’auteur dédié à la gestion des processus métiers.
Vous pouvez y retrouver des articles et d’autres compléments autour du BPM. Des « points de vue
» sur les produits de BPM sont en cours de rédaction et y seront ajoutés. Les internautes peuvent
également s’y connecter et échanger sur les différents sujets.
A propos de l’auteur
Jean-Noël GILLOT est Directeur du conseil au sein d’un grand groupe de conseil et d’intégration. Ses
expériences dans différents cabinets comme Logica Management (anciennement Unilog Management)
, Capgemini et d’autres ou des éditeurs lui ont permis de se forger une vision et une expérience de la
gestion des processus métiers. Son expérience est basée sur des missions auprès de grands comptes
français. Outre son expérience mise à disposition des grands groupes français et internationaux, Jean-
Noël GILLOT enseigne à l’EFREI dans le cadre du Master « Management des Systèmes d’Informations
» et plus particulièrement pour la filière BPM international mais également à l’Université de Marne la
Vallée. Jean-Noël GILLOT est également le co-auteur de la méthode TopUp brièvement décrite dans cet
ouvrage qui facilite l’alignement des objectifs stratégiques de l’entreprise et le système d’information par
les processus. Membre de différents consortium et consulté dans le cadre de normes comme le BPMN,
Jean-Noël GILLOT effectue régulièrement des conférences sur le thème de la gestion des processus, du
pilotage de la performance et de l’excellence opérationnelle.
Cet ouvrage est également disponible en anglais et un autre ouvrage sur l’excellence opérationnelle sera
disponible très prochainement.
L’auteur peut être joignable directement par mail à l’adresse suivante : jean-noel@gillot.biz
Best Practices Research est marque déposée de Best Practices International - SARL au capital de 21 000 euros,
Pavillon Sisley, rue de la Croix-Rouge, 78430 Louveciennes - Tél. 06 07 04 79 61 - 503 117 988 RCS Versailles
Directeur des études : Philippe Rosé - philippe.rose@bestpractices-si.fr

Rédaction : Aurélie Chandèze - Philippe Rosé
Correction révision : Alain Condrieu
Conception graphique : Charles Ballesterros
Marketing/vente : Marc Guillaumot - marc.guillaumot@bestpractices-si.fr
w w w. be s t re s e a rc h .fr
Dépôt légal : à parution.
www.bestresearch.fr

La Gestion Des Processus Métiers

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

La Gestion Des Processus Métiers

Transféré par

Droits d'auteur :

Formats disponibles

La gestion

des processus métiers

par Jean-Noël GILLOT

La gestion des processus métiers - mars 2011 - N° 9 - Best Practices Reseach • 3

Imprimé en Italie : Pixart.it

© Navigacom, Best Practices International, 2010

Reproduction interdite – Tous droits réservés

4 • Best Practices Research - N° 9 - mars 2011 - La gestion des processus métiers

La gestion des processus métiers - mars 2011 - N° 9 - Best Practices Reseach • 5

6 • Best Practices Research - N° 9 - mars 2011 - La gestion des processus métiers

3. Amelioration et qualite des processus 56

4. Modelisation, analyse & optimisation 84

La gestion des processus métiers - mars 2011 - N° 9 - Best Practices Reseach • 7

5. Integration, workflow et BPM 106

6. Le pilotage des processus 125

8 • Best Practices Research - N° 9 - mars 2011 - La gestion des processus métiers

7. Les solutions de BPM 144

La gestion des processus métiers - mars 2011 - N° 9 - Best Practices Reseach • 9

8. La valeur de la gestion des processus 178

Table des illustrations 199

La gestion des processus métiers - mars 2011 - N° 9 - Best Practices Reseach • 11

Je tiens à remercier tout particulièrement :

La gestion des processus métiers - mars 2011 - N° 9 - Best Practices Reseach • 13

• Certaines briques technologiques au sein du système d’information existent-elles déjà ?

A qui s’adresse cet ouvrage

Figure 1 : Profils des lecteurs par chapitre

La gestion des processus métiers - mars 2011 - N° 9 - Best Practices Reseach • 15

Cequ’est le Business Process Management

L’agilité de l’entreprise, pourra se mesurer à sa capacité de faire face au changement, et à sa réactivité

Des exemples de processus métiers pourraient être :

La gestion des processus métiers - mars 2011 - N° 9 - Best Practices Reseach • 17

Figure 2 : Composants d’une suite BPM

Voyons maintenant les différents composants d’une suite BPM.

Le Workflow : ce composant comporte plusieurs fonctionnalités principales qui sont :

La gestion des processus métiers - mars 2011 - N° 9 - Best Practices Reseach • 19

L e s entiment, la perc eption

Mod é lis a tion

Adm inis tra tion Int é gra tion

S upe rvis ion

Figure 3 : Sentiment et réalité du BPM

Métier & Fonctionnel

Figure 4 : Démarche Quadrangulaire

La gestion des processus métiers - mars 2011 - N° 9 - Best Practices Reseach • 21

Les 4 perspectives du Business Process Management

Ces quatre perspectives sont :

orga nis a tion

Figure 5 : Les 4 perspectives du BPM

Le but de l’agilité de l’organisation sera de permettre d’atteindre une meilleure performance et de

Pour les améliorations possibles on peut indiquer

La gestion des processus métiers - mars 2011 - N° 9 - Best Practices Reseach • 23

ba tta ge m é dia tique

L e s innova te urs L e s pr é c urs e urs L a m a jorit é L e s re ta rda ta ires

Figure 6 : Courbe d’adoption des technologies

La maîtrise des enjeux

La gestion des processus métiers - mars 2011 - N° 9 - Best Practices Reseach • 25

De manière générale, l’adaptabilité dont l’entreprise doit faire preuve, provient :

La gestion des processus métiers - mars 2011 - N° 9 - Best Practices Reseach • 27

L’alignement de la stratégie et du Système d’Information

Les fondements du positionnement compétitif sont au nombre de 3 :

Le positionnement compétitif est fonction de :

De manière générale, s’il y a un marché il y a compétition. L’entreprise doit communiquer sur

L’amélioration ou l’adhésion à des critères de qualité

Les bénéfices du Business Process Management