Praxeme Institute – Meaning in actionwiki.praxeme.org/uploads/Corpus/BAM-MSIR_TBthese.doc · Web viewChiffres clés en 2005 (en France) : Pôles transport et logistique : 2 milliards

Mise en place du Business Activity Monitoring (BAM)pour piloter les processus logistiques

grâce aux Echanges de Données Informatisés (EDI)

Nom BIARD

Prénom Thierry

Programme MSIR

Promotion 2006-2008

Adresse postale 150 Bis chaussée Jules César

95250 BEAUCHAMP

Téléphone portable professionnel 06 81 43 03 23

Téléphone fixe personnel 01 39 95 64 45

Téléphone fixe professionnel 01 64 62 36 67

E-mail personnel [email protected]

E-mail professionnel [email protected]

Numéro de version 1.2

Nombre de pages 83

Numéros des chapitres dans la version précédente

Numéros des nouveaux chapitres dans cette version

Thèse professionnelle V1.2 - Thierry BIARD - MSIR 2006-2008 - 21/11/2008 - Page 1/83

mailto:[email protected]

mailto:[email protected]

Mise en place du Business Activity Monitoring (BAM) pour piloterles processus logistiques grâce aux Echanges de Données Informatisés (EDI)

Remerciement« J'ai tremblé à l'idée de paraître devant vous. Tremblé d'émotion, certes, de gratitude aussi,

comme fit assurément, devant la première Académie, le premier récipiendaire, qui par un té-

moignage spontané établit un long usage, celui de commencer un discours académique par un

remerciement. »

COLETTE, Discours de réception à l’Académie Royale de Belgique.

Thèse professionnelle V1.2 - Thierry BIARD - MSIR 2006-2008 – 21/11/2008 - Page 2/83


Table des matièresRemerciement............................................................................................................................2

Table des matières.....................................................................................................................3

Table des figures.......................................................................................................................8

Résumé.......................................................................................................................................9

Chapitre 1. Introduction........................................................................................................10

1.1 La motivation pour le BAM............................................................................................10

1.2 Un challenge pour l’Entreprise.......................................................................................11

1.3 Les bénéfices attendus....................................................................................................11

Chapitre 2. L’entreprise et son organisation........................................................................12

2.1 L’entreprise.....................................................................................................................12

2.1.1 Présentation..............................................................................................................12

2.1.2 Chiffres clés en 2005 (en France) :..........................................................................13

2.1.3 Chiffres clés en 2005 (dans le monde) :..................................................................13

2.2 Son organisation (Systèmes d’Information)...................................................................15

Chapitre 3. Le problème dans son contexte..........................................................................16

3.1 Son contexte....................................................................................................................16

3.2 La nature du problème (constat).....................................................................................17

3.2.1 Pas de pilotage proactif des Echanges de Données Informatisés............................17

3.2.2 Historique limité dans la base de données EDI.......................................................18

3.2.3 Modélisation statique des processus logistiques......................................................18

3.3 Les objectifs de la solution.............................................................................................19

3.3.1 Pilotage proactif des processus logistiques..............................................................19

3.3.2 Base de données dédiée au BPM et au BAM..........................................................24

3.3.3 Modélisation dynamique des processus logistiques................................................24



3.4 Les enjeux de la solution.................................................................................................26

3.5 Evaluation des bénéfices attendus..................................................................................27

Chapitre 4. Les méthodes retenues, exposées, justifiées......................................................30

4.1 Les étapes de la démarche de résolution.........................................................................30

4.2 La gestion des processus métiers....................................................................................30

4.2.1 Une étape intermédiaire conseillée..........................................................................30

4.2.2 Définition du BPM...................................................................................................31

4.3 Définition du BAM.........................................................................................................31

4.3.1 Ce n’est pas du BAM...............................................................................................31

4.3.2 C’est enfin du BAM.................................................................................................33

4.4 Processus métiers et macro-processus............................................................................34

4.5 Choix des processus métiers candidats...........................................................................36

4.6 Choix des indicateurs de performance métier.................................................................37

4.6.1 Principe du choix de ces indicateurs........................................................................37

4.6.2 Indicateurs de performance logistique.....................................................................38

4.7 Les indicateurs d’activité................................................................................................43

4.8 Mesure des indicateurs....................................................................................................44

4.8.1 Principe de mesure...................................................................................................44

4.8.2 A partir des applications existantes.........................................................................44

4.8.3 A partir des fichiers échangés..................................................................................45

4.8.4 A partir de processus modélisés puis exécutés........................................................48

4.9 De l’intérêt de la modélisation des processus.................................................................48

4.10 Une théorie pertinente pour la modélisation.................................................................49

4.11 De l’intérêt de la standardisation..................................................................................50

4.11.1 Périmètre de la standardisation..............................................................................50

4.11.2 La notation BPMN.................................................................................................50

4.11.3 Le langage BPEL...................................................................................................51



4.11.4 Le langage BPQL...................................................................................................51

4.12 Positionnement du BAM par rapport à la BI................................................................51

4.13 Méthodes applicables :..................................................................................................53

4.13.1 Méthodes applicables au BPM..............................................................................53

4.13.2 CPI (Continuous Process Improvement)...............................................................54

4.13.3 Méthode applicable au BAM.................................................................................54

Chapitre 5. Les outils utilisés et décrits................................................................................55

5.1 La BAM Matrix™..........................................................................................................55

5.1.1 Objectif de la méthode BAM Matrix™...................................................................55

5.1.2 La méthode BAM Matrix™.....................................................................................55

5.1.3 La BAM Matrix™ : une grille d’analyse.................................................................57

5.1.4 La BAM Matrix™ : Exemple d’application............................................................57

5.2 L’Architecture Orientée Service (SOA).........................................................................59

5.2.1 Le concept de l’Architecture Orientés Services.......................................................59

5.2.2 Les Web Services.....................................................................................................59

Chapitre 6. Les résultats obtenus, présentés et discutés......................................................61

6.1 La désynchronisation des flux........................................................................................61

6.2 La prédiction...................................................................................................................61

6.2.1 Le calcul des tendances............................................................................................61

6.2.2 La prédiction des incidents......................................................................................61

6.2.3 La prévention des risques........................................................................................62

6.3 Les bénéfices...................................................................................................................62

6.3.1 Diminution de la non-qualité...................................................................................62

6.3.2 Réduction des temps de traitement..........................................................................63

6.3.3 Augmentation de la productivité..............................................................................63

6.3.4 Réduction des coûts.................................................................................................63

6.3.5 Une comparaison Avant/Après................................................................................64



6.3.6 La valeur ajoutée dans la chaine de traitement........................................................64

6.4 Les impacts.....................................................................................................................65

6.4.1 Une innovation pour le Business ?..........................................................................65

6.4.2 L’impact sur les Clients...........................................................................................65

6.4.3 L’impact sur l’organisation et le personnel.............................................................65

6.4.4 L’appropriation du BAM par les Opérations...........................................................66

6.4.5 Les obstacles rencontrés..........................................................................................67

Chapitre 7. La critique de la démarche et des résultats......................................................68

7.1 L’alignement sur le Métier..............................................................................................68

7.1.1 Pilotage opérationnel (à chaud)...............................................................................68

7.1.2 Pilotage tactique (à froid)........................................................................................68

7.1.3 Alignement stratégique............................................................................................68

7.2 Tableaux de bord.............................................................................................................70

7.3 Importance des processus clés........................................................................................71

7.3.1 Identification des processus clés..............................................................................71

7.3.2 Mise sous contrôle des processus clés.....................................................................71

7.4 Entreprise temps réel.......................................................................................................71

7.4.1 Vers l'Excellence opérationnelle..............................................................................71

7.4.2 Un avantage compétitif............................................................................................71

Chapitre 8. Conclusion...........................................................................................................72

8.1 Rappel des objectifs de départ........................................................................................72

8.2 Travail réalisé..................................................................................................................72

8.3 Synthèse..........................................................................................................................73



Chapitre 9. Bibliographie.......................................................................................................75

9.1 Aucun ouvrage sur le BAM............................................................................................75

9.2 Ouvrages en langue française.........................................................................................75

9.3 Ouvrages en langue anglaise...........................................................................................76

Chapitre 10. Webographie.....................................................................................................77

10.1 Ressources en langue française.....................................................................................77

10.2 Ressources en langue anglaise......................................................................................77

Chapitre 11. Glossaire............................................................................................................78

11.1 Acronymes et autres sigles............................................................................................78

11.2 Mots entiers...................................................................................................................78



Table des figuresFigure 1 : BAM versus TAM (Thierry BIARD).......................................................................17

Figure 2 : Courbe de maturité des technologies en janvier 2003 (Gartner)..............................19

Figure 3 : Exemple de processus logistique à piloter (DHL)....................................................21

Figure 4 : Principe d'une solution de BAM dont le suivi des échanges (Vistali).....................22

Figure 5 : Les 3 U : Utile, Utilisable, Utilisée..........................................................................24

Figure 6 : Principe de modélisation, d'exécution et de pilotage (Thierry BIARD)..................25

Figure 7 : Compréhension, mesure puis amélioration des processus métiers (IDS Scheer).....26

Figure 8 : Modèle de maturité du BPM dans les entreprises (Gartner)....................................28

Figure 9 : CMMI Maturity Levels (SEI)...................................................................................29

Figure 10 : Courbe de maturité du BSM en 2005, 2008 & 2010 (Forrester)............................32

Figure 11 : Positionnement du BAM par rapport au BSM (Vistali).........................................33

Figure 12 : Début et fin de processus (Henri CHELLI)............................................................34

Figure 13 : Exemple de non-conformité avec déclenchement d'alertes (webMethods)...........40

Figure 14 : Bus logiciel avec mécanisme Publish-Subscribe (Thierry BIARD)......................46

Figure 15 : Echanges de données entre applications sans et avec EAI (Thierry BIARD)........47

Figure 16 : Architecture EAI & EDI chez DHL France (Thierry BIARD)..............................47

Figure 17 : Consolidation des données stockées et temps réel (Thierry BIARD)....................52

Figure 18 : La BAM Matrix™ (Systar)....................................................................................58

Figure 19 : Pilotages opérationnel, tactique et stratégique (IDS Scheer).................................69



RésuméLes processus métiers sont complexes et le Système d’Information de l’Entreprise est devenu

indispensable à leur réalisation. Le point de départ de cette thèse est un constat : la supervi-

sion du Système d’Information est trop technique et ne permet que rarement de rattacher un

indicent à un processus métier précis.

Le dialogue est donc difficile entre les Opérationnels et les Informaticiens, qui leur proposent

souvent des solutions à faible valeur ajoutée. Le but de cette thèse professionnelle est d’étu-

dier si la mise en place du BAM (Business Activity Monitoring) permet de piloter efficace-

ment les processus métiers, notamment les processus logistiques.

Le BAM fournit en quasi temps réel des informations fiables concernant le déroulement des

processus métiers aux opérationnels. Cela leur permet de prendre des décisions rapidement et

d’effectuer les actions correctives si nécessaire : on dit alors que les processus sont pilotés. Le

BAM permet ainsi d’améliorer le niveau de service fourni par les processus métiers aux

Clients, qu’ils soient internes ou externes à l’Entreprise.

Cette thèse s’intéresse plus particulièrement au secteur d’activité de la Logistique. Ce sont

donc des processus logistiques qu’il s’agira ici de piloter. L’idée novatrice est d’utiliser la

plate-forme d’Echanges de Données Informatisés (EDI), afin de centraliser mais surtout d’au-

tomatiser, autant que faire se peut, le pilotage.

Après une introduction dans le chapitre 1, le chapitre 2 présentera l’Entreprise DHL et son or-

ganisation. Le chapitre 3 placera le problème dans son contexte, avant de définir les objectifs

de la solution.

Les différentes méthodes retenues seront exposées dans le chapitre 4. Puis ce seront les outils

utilisés qui seront décrits dans le chapitre 5.

Ensuite, les résultats obtenus, essentiellement des bénéfices, seront présentés dans le chapitre

6. La démarche sera critiquée dans le chapitre 7, en rappelant les différents types de pilotages

et les objectifs stratégiques à atteindre.

Enfin, une synthèse sera faite en guise de conclusion dans le chapitre 8. Une bibliographie,

une webographie et un glossaire figurent dans les chapitres 9,10 &11.



Chapitre 1.Introduction

1.1 La motivation pour le BAMLes processus métiers sont de plus en plus complexes. Depuis quelques décennies déjà, le

Système d’Information de l’Entreprise permet de réaliser de nombreuses tâches dont l’enchai-

nement rigoureux compose un processus métier. L’exécution correcte de ces tâches est géné-

ralement surveillée (mais rarement pilotée). En outre, ces différentes tâches sont de plus en

plus exécutées sur des systèmes informatiques hétérogènes et répartis sur plusieurs sites de

l’Entreprise, rendant difficile une surveillance globale. Cette surveillance est souvent cloison-

née par service technique (le réseau, les serveurs, les PC, etc.). Le moindre dysfonctionne-

ment est détecté, mais il est alors difficile de le rattacher à un processus métier précis et de

mesurer son impact sur la bonne marche de l’Entreprise, avant de le résoudre.

Ces contraintes essentiellement techniques font que le dialogue est bien difficile entre le Busi-

ness (souvent appelé « les Opérations ») et l’Informatique, car leurs métiers mais surtout leurs

langages sont différents. Cela induit inévitablement un délai pour que le Business prenne en

compte un dysfonctionnement signalé par l’Informatique, puis prenne enfin la décision adé-

quate pour le supprimer.

Le BAM (Business Activity Monitoring) serait-il le chainon manquant entre le Business et

l’Informatique ? Loin d’être un effet de mode, le BAM semble promis à un bel avenir ces pro-

chaines années.



1.2 Un challenge pour l’EntrepriseLe BAM est un véritable challenge pour l’Entreprise. Va-t-on aller, grâce au BAM, vers l’En-

treprise « temps réel » ? Le pilotage des processus logistiques signalerait, voire anticiperait, le

moindre dysfonctionnement. Des indicateurs de performance permettraient de mesurer en per-

manence l’activité de ses équipes et de respecter ses engagements vis-à-vis de ses Clients

(qu’ils soient internes ou externes à l’Entreprise).

Mais surtout, les processus métiers, qui constituent l’activité et le savoir-faire de l’Entreprise,

deviendraient le cœur et l’objet de toutes les attentions. L’Entreprise bénéficierait ainsi d’un

véritable avantage concurrentiel, sans doute provisoire (car ses concurrents s’équiperont sans

doute un jour), mais bien réel.

1.3 Les bénéfices attendusIl s’agit d’offrir aux différents intervenants dans l’Entreprise une solution de pilotage centrali-

sée des processus logistiques s’appuyant sur un Système d’Information généralement distri-

bué (c'est-à-dire que les ordinateurs, serveurs et PC, sont répartis sur plusieurs sites de l’En-

treprise ; c’est bien le cas au sein de l’entreprise DHL décrite dans le chapitre suivant).



Chapitre 2.L’entreprise et son organisation

2.1 L’entreprise2.1.1 Présentation

DHL est le numéro 1 mondial du Transport Express et de la Logistique. DHL sont les initiales

des noms des trois fondateurs de l’entreprise : Dalsey, Hillblom et Lynn, qui sont en quelque

sorte les inventeurs du transport express international. En 1969, ces trois étudiants américains

ont eu l’idée de transporter des documents par avion de San Francisco à Honolulu pour com-

mencer le dédouanement des marchandises transportées par navire avant l’arrivée de celui-ci

à son port de destination (Les documents papiers se séparent alors des marchandises : il s’agit

du premier exemple de désynchronisation entre le flux physique et le flux d’information qui

sera détaillée plus loin).

En France, l'activité Transport Express de DHL est issue de la fusion de trois sociétés dites les

"3 D" : Danzas fondée en 1815, Ducros fondée en 1948 et DHL fondée en 1969. C’est la so-

ciété la plus récente qui a donné son nom au groupe ainsi constitué, car sa notoriété internatio-

nale était plus développée.

NB : Cette fusion est à l’origine de l’hétérogénéité du Système d’Information de DHL. L'ac-

tionnaire unique du groupe DHL est la Deutsche Post depuis décembre 2002.

DHL Express propose essentiellement du transport international par avion et national par ca-

mion (messagerie). Un pôle de fret routier est également constitué par DHL Freight.

Quant à l'activité Logistique, elle se décompose en 2 pôles distincts : DGF (DHL Global For-

warding) pour l'import-export de marchandises par avion et par bateau, et DESC (DHL Exel

Supply Chain) pour l'entreposage et la distribution.



2.1.2 Chiffres clés en 2005 (en France) :2.1.2.1 Pôles transport et logistique :

2 milliards d'euros de Chiffre d'Affaires

12.700 collaborateurs

53.200 clients

4.500 véhicules

300 sites dans 125 villes

1 million de m² d'entrepôts

2.1.3 Chiffres clés en 2005 (dans le monde) :2.1.3.1 Pôle transport :

Un chiffre d’affaires de plus de 18,2 milliards d’euros

Près de 132 000 collaborateurs

Présent dans plus de 220 pays et territoires dans le monde

Environ 72 000 véhicules

420 avions (opérant en propre ou pour le compte de DHL)

4 700 agences

36 hubs (plates-formes de tri)



2.1.3.2 Pôle logistique : Un chiffre d’affaires de plus de 7,9 milliards d’euros en 2005 (hors Exel)

Plus de 148 000 collaborateurs

DGF (DHL Global Forwarding) :

Présent dans 170 pays et territoires dans le monde

640 agences

2.380.000 tonnes de fret aérien

1.240.000 TEU de fret maritime

(TEU : Twenty-foot Equivalent Unit ; container de 20 pieds de long)

DESC (DHL Exel Supply Chain) :

Présent dans 41 pays et territoires dans le monde

700 centres de distribution

3,5 millions de m² d’entrepôts



2.2 Son organisation (Systèmes d’Information)Depuis toujours, la Direction des Systèmes d’Information (DSI) était organisée en un seul

groupe plus ou moins homogène. Depuis le 1er octobre 2006, la DSI a été scindée en deux par-

ties au niveau mondial (ce qui justifie la terminologie anglo-saxonne employée ci-dessous) :

- Demand (qui correspond à la maitrise d’ouvrage MOA)

La partie Demand est elle-même découpée verticalement par métiers (Business

Units) : Express, Freight, Logistics.

- Supply (qui correspond à la maitrise d’œuvre MOE)

La partie Supply travaille pour tous les métiers de la partie Demand. Elle assure donc

une fonction de service horizontale et transverse.

Le personnel de la partie Demand est en contact étroit avec les équipes BP&O (Business Pro-

cess & Organisation, coté métier également) pour formaliser les demandes de développements

informatiques, conformes aux processus déjà en place et répondant au niveau de qualité de

service exigé.

La partie Supply fournit deux grands types de services :

- le Build (développement et infrastructure en mode Projet),

- le Run (Production, Télécom, Helpdesk, Support et Service Management).

Ces deux parties Demand et Supply sont, depuis le 1er janvier 2008, dans des entités juri-

diques différentes, une pour chaque métier coté Demand, une seule coté Supply, DHL Global

Business Services, qui regroupe les différentes fonctions transverses (pas seulement informa-

tiques), à disposition des autres entités.

La DSI en France regroupe 80 personnes environ, réparties essentiellement sur 3 sites : Marne

la Vallée, Marseille et Roissy. Ces employés DHL sont épaulés par de nombreux prestataires,

quasi permanents (pour le Run) ou temporaires seulement pour la durée d’un projet (pour le

Build).



Chapitre 3.Le problème dans son contexte

3.1 Son contexteDHL est déjà équipé d'un outil de BPM (Business Process Management). A ce jour, il est uti -

lisé à des fins purement techniques pour modéliser uniquement les transferts de fichiers. Les

processus n'étant pas modélisés, le BAM se révèle quasiment impossible à mettre en place (un

projet pilote de BAM sans modélisation préalable a échoué en 2005). En outre, cet outil de

BPM, comme encore beaucoup d’outils similaires, utilise une notation graphique propriétaire

de son éditeur. Cela ne permet pas la portabilité des modèles de cet outil vers un autre.

Une attention particulière sera portée dans cette thèse à n'utiliser que des notations graphiques

ou des langages standards (bien que souvent émergents ; exemples : BPMN & BPEL ; lire

plus loin). Les indicateurs obtenus devront être affichés en quasi temps réel (retard de

quelques minutes autorisé).

Il faudra prendre en compte les horaires de travail des différents opérateurs (ce qui n’est pas le

cas actuellement ; le SLA – Service Level Agreement – est le même 7 jours sur 7, 24 heures

sur 24). Sur la figure suivante, nous distinguons clairement le TAM (Technical Activity Mo-

nitoring ; acronyme très peu usité, vu uniquement dans [CRUSSON 2004, page 20]) qui

concerne les machines, disponibles en permanence y compris le week-end, et le BAM qui

concerne les personnes, disponibles 8 heures par jour du lundi au vendredi (il s’agit là d’un

minimum ; le travail en équipe reste bien entendu possible). Le SLA ne prend souvent en

compte que des délais techniques, liés à l’infrastructure, tandis que le BAM prend en compte,

en plus du SLA, les interventions humaines, qui sont souvent bien plus longues.



Figure 1 : BAM versus TAM (Thierry BIARD)

La plate-forme EDI (Echanges de Données Informatisés) quant à elle, qui est en place depuis

une dizaine d’années, est bâtie selon une architecture classique de type Client-Serveur. La dif-

ficulté technique de cette thèse sera de l’interfacer avec un système BPM bâti selon une archi-

tecture moderne de type SOA (Service Oriented Architecture). Ce travail d’intégration repré-

sente une charge importante et nécessite des compétences particulières.

3.2 La nature du problème (constat)3.2.1 Pas de pilotage proactif

des Echanges de Données InformatisésLes EDI (Echanges de Données Informatisés) sont très utilisés dans le transport de marchan-

dises. Cela permet au Transporteur de connaître, avant l'enlèvement de la marchandise, le

nombre de colis, le poids et le volume, mais aussi le numéro identifiant unique de chaque co-

lis (également indiqué sur un code à barres imprimé sur son étiquette), qui permettra au Client

de connaître, après l'enlèvement, l'état d'avancement de la livraison (Traçabilité).

Dans cette activité du transport, les processus sont relativement simples car les différentes

tâches qui les composent sont séquentielles. Dans l'activité de la Logistique, les processus

sont plus complexes car les différentes tâches qui les composent sont souvent parallèles. Par

exemple : dans l'import-export de marchandises, on peut préparer le dédouanement parallèle-

ment au transport.



Pour le moment, les EDI sont considérés comme de simples échanges de fichiers entre DHL

et ses clients. Au niveau de la plate-forme EDI, il n'y a aucun rapprochement fonctionnel

entre un fichier entrant et un fichier sortant concernant la même instance d’un processus. Au-

cune mesure de délai entre les deux évènements qui ont généré ces deux fichiers n’est donc

effectuée.

Le pilotage est uniquement technique et seule une erreur de télécommunication ou de traduc-

tion déclenche une procédure d'exception. Un fichier censé avoir été envoyé par un client

mais non reçu chez DHL (avant une certaine heure pour garantir l’enlèvement de la marchan-

dise par DHL le lendemain par exemple) ne produit aucune erreur chez DHL. Ce non-évène-

ment n’est donc pas détecté et sera signalé par le client mécontent le lendemain !

3.2.2 Historique limité dans la base de données EDIL’historique des Echanges de Données Informatisés est limité à une dizaine de jours, pour des

raisons de capacité de stockage essentiellement. En effet, DHL échange environ 4 millions de

messages par mois et il n’est pas question de stocker cet historique plus longtemps. Dans le

cadre d’un monitoring technique, tel qu’il est fait actuellement, cette dizaine de jours est suffi-

sante.

3.2.3 Modélisation statique des processus logistiquesCertains processus logistiques sont modélisés avec un outil de dessin (Exemple : Microsoft

Visio). Cette modélisation est statique, souvent théorique quand elle est faite avant l’exécu-

tion des processus, et les écarts avec la réalité sont souvent nombreux. Cette modélisation

constitue toutefois la documentation nécessaire pour obtenir la certification ISO-9001.



3.3 Les objectifs de la solution3.3.1 Pilotage proactif des processus logistiques

Comment passer d’un pilotage réactif à un pilotage proactif des processus logistiques ? La

mise place du BAM répond à cette question et nous allons expliquer comment.

L'objectif principal est le suivant :

- Mettre en place le Business Activity Monitoring (BAM) pour piloter

les processus logistiques

Créé par le cabinet d’analyse Gartner en 2002, le BAM (Business Activity Monitoring) est un

acronyme qui définit le concept de fournir l’accès, en temps réel, à des indicateurs de perfor-

mance pour améliorer la rapidité et l’efficacité des opérations. La courbe de la figure ci-des-

sous (Janvier 2003) laissait à penser que le BAM serait une technologie mature vers 2008.

Figure 2 : Courbe de maturité des technologies en janvier 2003 (Gartner)



En 2002 également, Patricia SEYBOLD, une consultante réputée spécialisée en économie nu-

mérique, déclarait dans « What’s New in the Customer Revolution ? » : « Vous aurez besoin

d’intégrer des indicateurs opérationnels qui vous permettront de suivre, en temps réel, la pro-

gression de votre relation client […]. Pour la première fois dans l’histoire des entreprises, il

est désormais possible de suivre de nombreux processus métiers majeurs de bout en bout pra-

tiquement en temps réel. En vous concentrant sur les scénarios qui sont importants pour vos

clients, vous distribuez les informations cruciales qui permettront à vos employés et parte-

naires de prendre les mesures immédiates afin d’améliorer la qualité de l’expérience client. »

(Citation et traduction par [RANADIVÉ 2006, page 69]).

Certains [MALONE 2005, web] proposent quelquefois la définition de Business Activity Ma-

nagement à l’acronyme BAM. En fait, il s’agit sans doute du résultat d’une fusion avec le Bu-

siness Service Management (BSM), qui sera abordé plus loin.

Quant à la traduction du BAM en langue française, il faut traduire Business Activity par l’Ac-

tivité Métier (dans le cas présent, la Logistique). La traduction littérale du terme Monitoring

est le Contrôle, voire la Supervision (traduction littérale proposée par le cabinet d’études

Yphise [YPHISE 2006, page 5] et d’autres auteurs [GARIMELLA 2008, page 9]). L’auteur

préfère toutefois le terme Pilotage, car les mesures fournies par le Contrôle et la Supervision,

si elles dépassent certains seuils prédéfinis, doivent donner lieu à des actions bien souvent cu-

ratives et si possible préventives. Le but de ces actions est de retrouver ou maintenir le cap

préalablement défini (alignement stratégique) : en ce sens, le terme Pilotage semble mieux

adapté, car il représente l’aspect interactif du BAM. Il couvre aussi la dimension managériale

évoquée précédemment. [RANADIVÉ 2006, page 70] traduit le Business Activity Monitoring

par le Pilotage opérationnel des activités métiers.

Enfin, le glossaire du site web Loosely Coupled indique, non sans humour, que le BAM est

l’équivalent électronique de « Tenir la boutique » [LOOSELY COUPLED, web].

Afin d’illustrer notre propos, voici ci-dessous un exemple de processus logistique avec son

flux physique, de la commande du client jusqu’à sa livraison, qu’il serait intéressant de pilo-

ter. DHL assure dans cet exemple l’entreposage, la préparation puis la livraison de la mar-

chandise commandée.



Figure 3 : Exemple de processus logistique à piloter (DHL)

L'idée novatrice de cette thèse est de se servir des Echanges de Données Informatisés (EDI)

pour atteindre cet objectif. En effet, les flux physiques de marchandises sont suivis (voire pré-

cédés) de flux logiques de fichiers (EDI) plus ou moins synchronisés. Le passage d'un fichier

indiquera généralement le début ou la fin d'une tâche (ou d’un ensemble de tâches dans une

même application par exemple), permettant ainsi de suivre automatiquement le déroulement

d'un processus, sans extraction de données supplémentaires.

Les deux flèches en vert clair, nommée « Suivi des échanges et processus inter-applicatifs »

dans la figure ci-dessous, illustrent ce propos. Une plate-forme EDI déjà en place centralise

tous ces flux en un seul lieu de passage. Elle centralise aussi bien les flux externes entre DHL

et ses clients (il s’agit généralement de messages utilisant un format standard comme EDI-

FACT ou XML ; on parle alors d’EDI) que des flux internes entre deux applications de DHL

(il s’agit alors de fichiers utilisant généralement un format propriétaire à DHL ; on parle alors

d’EAI : Enterprise Application Integration).

Mais comme cette plate-forme assure également un service de traduction de formats, le type

de flux le plus fréquent sera un échange de données entre un client utilisant un message au

format standard et une application DHL utilisant un fichier au format propriétaire. Autant que

faire se peut, la mise en place du BAM se fera de préférence avec des messages standards,

pour des raisons évidentes d’indépendance vis-à-vis des applications et de portabilité.

En outre, le mot Business du BAM sous-entend qu’il faut que le pilotage des processus soit

clairement orienté Clients et l’on privilégiera donc la supervision des flux externes. Toutefois,

afin de piloter certaines tâches internes dont la bonne exécution est primordiale à l’ensemble

d’un processus, l’utilisation de fichiers aux formats propriétaires, échangés entre deux appli-

cations DHL, sera souvent nécessaire (on parle alors de flux inter-applicatifs).



Il n'y a donc pas de changement de l'organisation existante dans un premier temps (phase de

mise en place). Un rapprochement fonctionnel entre un fichier entrant et un fichier sortant

concernant la même instance d’un processus sera opéré, sous réserve de disposer dans ces

deux fichiers d’un même identifiant unique.

Figure 4 : Principe d'une solution de BAM dont le suivi des échanges (Vistali)

L'approche classique aurait consisté en un suivi manuel du déroulement d'un processus,

chaque opérateur indiquant par une saisie que chaque tâche est terminée dans une application

de type workflow. Cette approche collaborative, mais en quelque sorte manuelle, n’est pas re-

tenue ici. Les six flèches en vert foncé, nommées « Suivi de processus et traitements applica-

tifs » dans la figure ci-dessus, illustrent cette approche classique.



Les sous-objectifs du BAM, à atteindre dans l'ordre chronologique, sont :

- Modéliser quelques processus logistiques, selon le principe du BPM (Business Process Ma-

nagement),

- Mettre en place un système d’exécution de ces processus avec un BPMS (BPM System),

- Mesurer les délais d'exécutions globaux de ces processus avec ce BPMS, voire mesurer les

délais d’exécutions intermédiaires de certaines tâches,

- Sélectionner les indicateurs pertinents (délais essentiellement) pour évaluer la performance

d’exécutions des processus, voire de certaines tâches,

- Contrôler ces délais d’exécutions avec le BAM (Business Activity Monitoring),

NB : Il serait souhaitable de pouvoir prendre en compte un calendrier de disponibilité des in-

tervenants dont la granularité serait le jour, afin de ne pas compter les week-ends et les jours

fériés, voire l’heure, afin de ne pas compter les pauses déjeuners et les nuits,

- Déclencher des alertes lorsque les délais d’exécutions maxima ont été dépassés,

NB : Les délais d’exécution maximum seront fixés pour garantir le niveau de service requis

(selon le SLA - Service Level Agreement - formalisant l’engagement de service auprès des

clients),

- Vérifier l’exécution des tâches planifiées à des heures précises,

- Déclencher des alertes lorsque ces tâches planifiées ne se sont pas exécutées (gestion des

non-événements),

- Prédire les délais d’exécutions futurs en fonction de la tendance actuelle, pour prévenir les

débordements,

- Présenter les graphiques adéquats pour le pilotage de ces processus sur un tableau de bord,

- Permettre de relancer les instances de processus qui ont échoué (après avoir résolu les pro-

blèmes à l’origine des dysfonctionnements) ou d’arrêter provisoirement celles de processus en

cours (afin d’éviter qu’un dysfonctionnement ne survienne à coup sûr).



3.3.2 Base de données dédiée au BPM et au BAMDans le cadre d’un monitoring métier et plus particulièrement dans la logistique, les cycles de

vie des processus peuvent durer plusieurs semaines. Il sera donc nécessaire de disposer d’une

base de données dédiée, dont le contenu ne sera purgé qu’au bout d’un certain nombre de

jours, mais seulement pour les processus dont l’exécution sera terminée. Le cycle de vie com-

plet d’un processus, du début jusqu’à la fin, pourra être reconstitué à partir du contenu de

cette base de données, permettant ainsi la traçabilité de bout en bout (End-to-end monitoring).

Cela permettra de mesurer la performance de chacune des tâches, tout en conservant une vue

d’ensemble des processus. Nous parlons bien ici de la traçabilité des processus, la traçabilité

des unités logistiques (colis, palette) étant depuis longtemps assurée dans le transport.

Les logiciels de BAM proposent souvent une fonction d’auto-apprentissage qui déterminera, à

partir de l’historique stocké dans cette base de données dédiée, les mesures « habituelles »

qu’il convient de ne pas dépasser (baseline).

3.3.3 Modélisation dynamique des processus logis-tiques

Il s’agit désormais d’obtenir une modélisation dynamique des processus logistiques. La modé-

lisation sera à la base de l’exécution réelle des processus : la pratique sera donc alignée sur la

théorie, sans écart possible. L’exécution éventuelle d’une tâche non modélisée d’un processus

sera déclarée non-conforme et provoquera aussitôt une erreur (ou plus souvent, si les tâches

ne sont pas exécutées dans l’ordre préalablement défini par la modélisation). Tandis que la

modélisation statique des processus est seulement « Utile », la modélisation dynamique de-

vient « Utilisable » pour le BPM et le BAM permet de s’assurer qu’elle est « Utilisée ».

Figure 5 : Les 3 U : Utile, Utilisable, Utilisée

Tandis que la modélisation d’un processus n’est à faire qu’une seule fois, ainsi que la généra-

tion de sa logique d’exécution, son exécution peut se faire plusieurs fois et de façon concomi-



tante. Ainsi, à un instant donné, plusieurs instances d’un même processus peuvent être en

cours d’exécution. Le BAM récoltera alors les informations concernant chaque instance,

comme le montre la figure ci-dessous. Mais le BAM fournira également le nombre d’ins-

tances terminées (depuis un certain temps) et en cours d’exécution, afin de mesurer précisé-

ment la charge de travail et adapter le nombre de ressources nécessaires (les ressources hu-

maines notamment).

Figure 6 : Principe de modélisation, d'exécution et de pilotage (Thierry BIARD)

La modélisation permet également de formaliser la compréhension des processus métiers par

des personnes tierces (les informaticiens notamment). Puis la compréhension facilite le dia-

logue entre les intervenants.

Il faut mentionner qu’en fin d’année 2005, un projet pilote de BAM, sans modélisation préa-

lable des processus, se solda par un échec, les informaticiens n’ayant pas compris les proces-

sus qu’il s’agissait de piloter. Mais de plus en plus les éditeurs de logiciels préconisent cette

étape de modélisation qui nous semble désormais indispensable. Les spécialistes s’accordent à

dire qu’il est plus facile de récupérer les données concernant l’exécution de processus modéli-

sés préalablement.



3.4 Les enjeux de la solutionSans modélisation et sans moyen de mesure, les processus métiers ne sont pas pilotés de façon

formelle et efficace. L'hypothèse de départ est que tout processus mesuré pourra ensuite être

amélioré. Car la mesure est le fondement de l’amélioration. Pour être mesurable, un processus

devra être modélisable. Pour être modélisable, un processus devra avoir un déroulement

connu et toujours identique des différentes tâches qui le composent.

Figure 7 : Compréhension, mesure puis amélioration des processus métiers (IDS Scheer)

Il faut également passer d'un mode réactif, où c'est bien souvent les clients de DHL qui si-

gnalent les dysfonctionnements, à un véritable pilotage proactif, où ces dysfonctionnements

sont prévus, voire évités avant qu'ils ne surviennent. Si un dysfonctionnement semble irrémé-

diable, son anticipation doit permettre de limiter ses impacts en mobilisant à l’avance les res-

sources disponibles.

Il s’agit de résoudre un problème à la fois fonctionnel et technique. La solution fonctionnelle

devra s’intégrer dans la stratégie logistique de l’entreprise. Quant à la solution technique, elle



devra compléter l’architecture technique existante. La solution globale (fonctionnelle & tech-

nique) permettra plus tard d’établir une cartographie complète des processus métiers (la carto-

graphie ne sera pas traitée dans cette thèse).

NB : La couche applicative intermédiaire entre les couches fonctionnelle et technique est sans

importance ici. En effet, l’utilisation de la plate-forme EDI centralisée évite la mise en place

de sondes applicatives réparties (appelées aussi agents ou extracteurs ou connecteurs, elles

sont souvent intrusives, ce qui limite leur déploiement). Car, pour piloter un Système d’Infor-

mation hétérogène et réparti, bâti au fil des ans et de fusions, ces sondes devraient être instal-

lées sur tous les systèmes d’exploitation (OS : Operating Systems), y compris les plus an-

ciens. Ici, seule la plate-forme EDI doit être équipée. Les fichiers qui y transitent doivent tou-

tefois permettre de contrôler l’exécution des processus, et c’est bien là l’enjeu de cette solu-

tion. L’existence ou non d’un fichier sur la plate-forme EDI pour « matérialiser » le début ou

la fin d’une tâche, faisant partie d’un processus, permet de fixer implicitement la granularité

du système de pilotage : il ne pourra pas être plus détaillé, si aucun fichier ne transite sur la

plate-forme EDI ; par contre, il pourra être éventuellement moins détaillé, si l’on décide vo-

lontairement de ne pas prendre en considération un fichier qui transite sur la plate-forme EDI

(matérialisant par exemple une étape intermédiaire insignifiante ou une tâche subalterne).

L'architecture technique nécessaire au BPMS et au BAM s'appuie sur une technologie mo-

derne : SOA dont Web Services avec messages XML.

3.5 Evaluation des bénéfices attendusLa démarche de modélisation dynamique des processus, puis leur pilotage, permettra sans au-

cun doute d’augmenter le degré de maturité de l’entreprise sur ce sujet. Ainsi, selon le modèle

de maturité BPM du Gartner ci-dessous, DHL se situerait entre les niveaux 0 et 1 : les proces-

sus sont modélisés, de manière statique toutefois, mais les indicateurs de performance ne sont

pas clairement définis (et encore moins les seuils à ne pas dépasser). Cette situation n’a rien

de catastrophique : c’était le lot de 88% des entreprises en 2006. L’objectif est d’atteindre le

niveau 2 de maturité BPM, en reliant directement la modélisation des processus, qui devient

alors dynamique, à leur exécution. Le BAM permet alors de mesurer le temps passé à chaque

activité composant un processus. Soyons modeste et réaliste dans un premier temps : il s’agit

de considérer chaque processus de façon autonome. En effet, le niveau 3 de maturité BPM si-

gnifie que l’on est capable d’analyser les interactions entre les différents processus. Cela se-



rait fort intéressant sur le plan pratique, car on pourrait gérer si nécessaire les priorités entre

les différents processus. Quant au niveau 4, il pourrait permettre de mesurer la performance

globale de l’Entreprise…

Figure 8 : Modèle de maturité du BPM dans les entreprises (Gartner)

L’approche de CMMI (Capability Maturity Model Integration) est intéressante également, car

elle est très orientée vers le contrôle puis l’optimisation des processus. Elle représente en

outre un référentiel standard de plus en plus connu. 5 niveaux de maturité sont définis selon le

degré de contrôle des processus :

1 – Initial : Processus qui réalise le travail attendu

2 – Discipliné : Processus connu, exécuté, mesuré, répété, optimisé

3 – Ajusté : Processus connu de l’organisation qui participe à l’optimisation

4 – Géré quantitativement : Processus piloté, mesuré et amélioré selon des KPI

5 – En optimisation : Processus piloté, mesuré et en constante optimisation

KPI : Key Performance Indicator, sigle défini plus loin (Chap. Indicateurs de performance)

NB : Le modèle de maturité CMMI est publié par le SEI (Software Engineering Institute –

Université américaine de Carnegie Mellon).



Figure 9 : CMMI Maturity Levels (SEI)



Chapitre 4.Les méthodes retenues, exposées, justifiées

4.1 Les étapes de la démarche de résolutionIl serait presque facile de mettre en place un BPMS avec un BAM en partant de rien pour les

nouveaux processus. Cette démarche aurait pour inconvénient de ne pas permettre de piloter

les centaines de processus actuellement en production (bien qu’ils ne soient pas modélisés).

D’où, une toute autre démarche en plusieurs étapes, centrée sur l’existant.

La première étape pratique consistera donc à interfacer la plateforme EDI existante avec un

BPMS. Cette plate-forme EDI semble avoir les outils nécessaires pour réaliser cette interface :

client HTTP (HyperText Transfer Protocol) et traducteur XML (eXtensible Mark-up Lan-

guage) pour émuler le protocole SOAP (Simple Object Access Protocol).

La modélisation des processus sera la deuxième étape importante de cette thèse. Il faut une

méthode pour identifier les processus logistiques candidats à la modélisation puis au pilotage,

selon des critères techniques (EDI, XML) et des critères économiques (sources de valeur). Le

BPM étant désormais courant et ayant déjà fait l'objet de plusieurs thèses, ne sera toutefois

pas le sujet principal de celle-ci.

La troisième et ultime étape sera la mise en place du BAM et la promotion d’un pilote auprès

des Opérations pour l’amélioration du pilotage des processus logistiques et du support tech-

nique proposé.

4.2 La gestion des processus métiers4.2.1 Une étape intermédiaire conseillée

La modélisation préalable des processus métiers est une étape intermédiaire fortement

conseillée, mais pas obligatoire. Bien entendu, c’est plus rapide et donc moins cher de mettre

en place le BAM sans cette étape intermédiaire facultative, mais il nous semble qu’à moyen et

surtout long termes, il serait dommage de se priver du grand intérêt de la modélisation. Car

elle apporte une contribution importante à l’urbanisation du Système d’Information de l’En-

treprise et à sa gouvernance.



4.2.2 Définition du BPMLe BPM (Business Process Management) est un concept qui permet la gestion des processus

métiers. Il s’agit que les opérations accomplissent des processus précis afin d’atteindre les ob-

jectifs de l’Entreprise. Au-delà du concept, le BPM est souvent matérialisé dans l’Entreprise

par la mise en place de plusieurs outils logiciels (BPM Suite ou BPMS) permettant de modéli-

ser puis d’orchestrer l’exécution de ces processus métiers, conformément aux modèles. Cette

orchestration concerne aussi bien les ressources matérielles, facilement automatisables, que

les ressources humaines, qui concourent ensemble à l’exécution des processus. La difficulté

du BPM est bien là : synchroniser des ressources de natures aussi différentes. Le BAM va

permettre ensuite de mesurer puis d’optimiser ces processus métiers.

4.3 Définition du BAM4.3.1 Ce n’est pas du BAM

4.3.1.1 PréambuleVoyons d’abord des activités qui se rapprochent du BAM, mais qui n’en sont pas vraiment :

la supervision technique puis la disponibilité applicative. Les principales différences entre le

BAM et la BI (Business Intelligence) feront l’objet d’un chapitre distinct plus loin dans cette

thèse, et nous démontrerons que ces deux activités sont en fait complémentaires.

4.3.1.2 Supervision techniqueLa supervision technique de l’infrastructure qui supporte le système d’information (serveurs,

composants réseau, etc. ; NSM : Network and Systems Management) est souvent déjà en

place dans l’Entreprise et fonctionne en temps réel, grâce au protocole SNMP (Simple Net-

work Management Protocol) notamment. Elle sert aux informaticiens, mais pas aux interve-

nants métiers.

Toutefois, certains problèmes techniques peuvent être remontés vers le BAM pour connaitre

l’impact métier sur les processus en cours d’exécution. Cette approche Bottom-Up, du bas (in-

frastructure) vers le haut (processus métiers), orientée vers le service rendu aux utilisateurs, se

nomme Business Service Management (BSM). Le BSM inclut la mesure de la QoS (Qualité

de Service) et le SLM (Service Level Management, qui fait partie d’ITIL : Information Tech-

nology Infrastructure Library) pour la gestion des SLA. Le BSM doit permettre de connaître

les impacts d’un incident technique sur l’exécution des processus métiers. On notera, à l’exa-



men de la figure ci-dessous, que les objectifs du BSM sont similaires à ceux du BAM, à sa-

voir : passer d’un service réactif à un service proactif, voire prédictif.

Figure 10 : Courbe de maturité du BSM en 2005, 2008 & 2010 (Forrester)

4.3.1.3 Disponibilité applicativeVoici une autre activité intéressante, mais qui n’est toujours pas du BAM. La mesure de la

disponibilité applicative, est cette fois-ci orientée vers les intervenants métiers (les utilisateurs

des applications). Des sondes applicatives, grâce à des scripts, simulent la connexion à une

application, puis son utilisation (transactions). Mais cette mesure n’est utile que pour évaluer

la Qualité de Service (QoS). Les quelques secondes maximum qu’elle devrait mesurer sont

négligeables par rapport à un temps global d’exécution d’un processus logistique, compris

entre quelques heures (déclaration douane) et plusieurs semaines (transport maritime). Ce

n’est donc pas du BAM non plus.



4.3.2 C’est enfin du BAMMaintenant, découvrons enfin le BAM. Le BAM résulte plutôt d’une approche Top-Down, du

haut (processus métiers) vers le bas (infrastructure ; dans notre cas, les Echanges de Données

Informatisés). Comme évoqué plus haut, les processus métiers auront été au préalable avanta-

geusement modélisés avec un système BPM. La figure ci-dessous positionne notamment le

BAM par rapport au BSM : le recouvrement entre les deux concepts est certain, même si l’ap-

proche est différente (Top-Down versus Bottom-Up).

Figure 11 : Positionnement du BAM par rapport au BSM (Vistali)

Tandis que le monitoring traditionnel se focalise sur une source unique de données, le BAM

consolide des informations provenant de plusieurs sources de données, internes voire ex-

ternes. Le BAM peut donc être interfacé aux plates-formes d’administration et de supervision

(NSM), aux middlewares d’intégration (EAI voire EDI dans notre cas) et aux systèmes BPM.



4.4 Processus métiers et macro-processusIl s’agit de piloter des processus métiers. Rappelons ici la définition d’un processus métier,

puis d’un macro-processus. Un processus métier est un ensemble d’activités cohérentes, qui

s’effectuent dans un ordre prédéterminé et qui traitent une suite d’objets métiers cohérents

(Exemple : un bon de commande, puis un bon de préparation, puis un bon de livraison puis

enfin une facture). Ces activités sont généralement effectuées les unes après les autres (elles

sont alors sérialisées), mais elles peuvent également être effectuées en parallèle, rendant alors

plus complexe le pilotage du processus qu’elles composent (Exemple : préparer le dédouane-

ment parallèlement au transport de la marchandise). Un processus métier étant également dé-

fini par un début (évènement déclencheur) et une fin, les « résultats » des activités parallèles

doivent être regroupés avant la fin. C’est dans ce second cas d’activités parallèles que la mo-

délisation préalable des processus puis leur pilotage par le BAM se justifient beaucoup plus

que dans le premier cas d’activités sérialisées.

Généralement, l’évènement déclencheur est bien connu et matérialise sans ambiguïté le début

d’un processus (Exemple : réception d’une commande). Il faut qu’il en soit de même pour

l’évènement interrupteur qui marquera la fin du processus. Ainsi, selon [CHELLI 2003, page

60], les évènements interrupteurs sont les miroirs de la performance de l’Entreprise. Mesurer

la performance de l’Entreprise afin de pouvoir la piloter, c’est bien l’un des principaux objec-

tifs du BAM.

Figure 12 : Début et fin de processus (Henri CHELLI)

En fait, il peut y avoir plusieurs évènements interrupteurs, ce qui rend la fin du processus plus

difficile à identifier. Il y a généralement la fin normale (Exemple : commande livrée) mais

aussi une ou plusieurs fins « anormales » (Exemple : commande annulée). Le BAM s’attache-

ra donc à mesurer le délai d’exécution des processus qui se terminent normalement, mais se

contentera de compter les processus qui se terminent anormalement, en essayant de distinguer



les anomalies fonctionnelles (Exemple : commande annulée suite à une rupture de stock) des

anomalies techniques (Exemple : message EDI non-conforme).

Chaque activité est attribuée à une seule personne, ou mieux à un seul service, voire à une ap-

plication automatisée, qui remplit une fonction bien précise. Si l’application n’est pas automa-

tisée et nécessite l’action d’un intervenant, celle-ci est alors considérée comme un simple outil

à disposition de cet intervenant. Un processus métier complet, composé donc de plusieurs ac-

tivités, peut mobiliser plusieurs personnes et plusieurs services, à l’intérieur mais aussi à l’ex-

térieur de l’Entreprise, et son pilotage devient vite difficile.

Toutefois, pour un véritable pilotage par le BAM, il sera préférable dans un premier temps de

se concentrer sur un processus circonscrit à l’intérieur de l’Entreprise (bien que l’évènement

déclencheur soit bien souvent d’origine extérieure), afin de pouvoir agir plus facilement sur

son déroulement. Cela étant dit, le BAM peut également servir à contrôler les délais d’exécu-

tion des prestataires (externes) de l’Entreprise, surtout si ceux-ci sont censés respecter, eux

aussi, un niveau de service minimum (SLA).

En fait, la tendance actuelle est d’étendre le périmètre logistique en dehors de l’Entreprise, en

englobant ses Clients et surtout ses Fournisseurs : on parle alors de Supply Chain Manage-

ment. Il faudra donc impliquer ces tiers si l’on veut vraiment mesurer les processus logis-

tiques de bout en bout. Mais la marge de manœuvre auprès des Clients pour améliorer éven-

tuellement les processus semble bien étroite, car il est difficile de leur contraindre. Par contre,

le rapport de force inversé avec les Fournisseurs laisse à penser que cela sera plus facile.

Un processus global qui regroupe les principales activités de l’Entreprise est appelé macro-

processus, donnant ainsi une vision conceptuelle mais surtout stratégique de haut niveau. Ce

dernier est ensuite décomposé en plusieurs processus opérationnels, appelés aussi sous-pro-

cessus. Le déroulement détaillé d’un processus opérationnel est décrit dans une procédure. La

représentation des activités de l’Entreprise sous la forme de macro-processus et de processus

s’apparente à de la cartographie à grande échelle.

Les outils de modélisation s’attachent généralement à bien séparer les intervenants (per-

sonnes, services ou applications automatisées) dans des couloirs (swim lanes), permettant ain-

si de mettre en évidence les flux d’objets échangés entre ces intervenants. Dans le cadre de

l’EDI, ces objets seront matérialisés sous la forme de fichiers. Ces outils de modélisation per-



mettent également l’imbrication de plusieurs niveaux de processus, bien plus facilement que

sur le papier.

4.5 Choix des processus métiers candidatsParmi les différents processus métiers, certains seront de bons candidats pour le BAM : il

convient de les identifier puis d’en choisir quelques-uns pour le pilotage.

La phase d’implémentation sera limitée à la mise en place d’un pilote de BAM sur quelques

processus représentatifs de l’activité Logistique de DHL. Ces processus devront être partielle-

ment automatisés, c’est-à-dire que les activités manuelles des intervenants humains devront

déclencher des évènements dans le Système d’Information de l’Entreprise. Les processus mé-

tiers avec des Echanges de Données Informatisés, si possible au format XML, auront notre

préférence.

Il convient de choisir des processus, dont le pilotage en quasi temps réel permet de réagir très

rapidement au moindre écart afin de remettre aussitôt les processus défaillants dans les

« rails ». La mise en production du BAM sera envisagée selon les résultats obtenus. Les amé-

liorations, voire la valeur ajoutée au pilotage des processus logistiques, devront être démon-

trées aux Responsables Opérationnels pour obtenir leur adhésion au projet.

Sur le plan technique, les processus dont les tâches sont réparties sur différentes applications

et présentant un volume élevé (nombre d’instances de chaque processus) auront notre préfé-

rence. Il en sera de même pour les processus dont les délais d’exécution sont encadrés par un

engagement fort de niveau de service (SLA).

Les processus présentant des incidents récurrents (qui deviennent un problème selon ITIL) de-

vront faire l’objet d’une attention particulière, notamment s’ils contribuent à servir des Clients

importants. La justification économique du BAM devrait alors en être facilitée.

Les processus métiers se terminant par une facturation sont particulièrement intéressants à pi-

loter, notamment ceux avec des dates voire des heures précises (cut-off) à respecter, afin

d’éviter tout retard. En effet, l’impact financier sur la trésorerie sera sans doute intéressant

pour l’Entreprise.

Mais le principal problème est ailleurs : si un processus métier ne peut pas être terminé à

cause d’un dysfonctionnement au cours de son déroulement, la facturation finale ne peut pas



être faite, d’où un impact direct sur le chiffre d’affaires. La valeur ajoutée du BAM sera plus

conséquente que celle du pilotage d’un processus sans impact financier, et le retour sur inves-

tissement (ROI) sera plus rapide.

NB : Le recouvrement des factures fait généralement l’objet d’un processus séparé, indépen-

dant de la logistique, commun à plusieurs activités de l’Entreprise. C’est en fait généralement

une fonction support « horizontale ».

Selon [PROCESSUS METIER, web], une solution de BAM doit permettre, en plus de piloter

en temps réel la performance des activités métiers en regard de leur criticité, de quantifier les

gains de productivité afin d’appréhender in fine le retour sur investissement.

4.6 Choix des indicateurs de performance métier4.6.1 Principe du choix de ces indicateurs

Une fois qu’un choix judicieux s’est porté sur certains processus métiers, il faut ensuite, pour

chacun d’entre eux, choisir des indicateurs de performance.

Les indicateurs de performance traditionnels des entreprises sont des indicateurs financiers

(Exemple : Chiffres d’affaires). Ces indicateurs sont bien souvent calculés a posteriori. Pour

piloter les processus logistiques, il nous faut des indicateurs de performance métier, calculés

en temps réel. Bien entendu, ces deux types d’indicateurs sont liés : ainsi, la diminution du

temps d’exécution d’un processus logistique permet potentiellement d’accroitre le chiffre

d’affaires d’une entreprise avec le même effectif.

L’amélioration des indicateurs de performance métier, par le pilotage des processus logis-

tiques, permettra donc l’amélioration à moyen terme des indicateurs de performance finan-

ciers. Les évolutions dans le temps des valeurs des différents indicateurs seront analysées

dans le cadre de la démarche d’amélioration continue des processus (CPI), abordée plus loin.

Il existe une pléthore d’indicateurs de performance. Il n’y a pas de méthode particulière pour

choisir des indicateurs de performance. Toutefois, certains secteurs d’activité ont des indica-

teurs bien connus par tous les acteurs ayant le même métier, ce qui peut faciliter les comparai-

sons. Il s’agit alors d’appliquer les meilleures pratiques de la profession (best practices). Ain-

si, le site spécialisé http://kpilibrary.com en propose près de 1.300, dont 147 dans la catégorie

Supply Chain, Procurement & Logistics.


http://kpilibrary.com/


4.6.2 Indicateurs de performance logistique4.6.2.1 Validité des indicateurs de performance choisis

Voici une sélection de quelques indicateurs de performance choisis parmi ceux qui sont les

plus utilisés en logistique selon [SAMII 2004, pages 210, 257 et 263] pour améliorer les pro-

cessus métiers de DHL. Les deux questions pertinentes pour les valider sont les suivantes :

- Cet indicateur est-il mesurable grâce aux Echanges de Données Informatisés ?

- Cet indicateur est-il pertinent pour DHL, en tant que prestataire logistique ?

Ce second critère retire en effet de nombreux indicateurs qui ne concernent que le propriétaire

de la marchandise (Niveau de stock, Niveau de prix, Analyse des écarts de stock et de prix).

4.6.2.2 Niveau de service offert aux clientsou proposé par les fournisseurs

- Durée du cycle de commande par fournisseur,

- Durée du cycle de facturation par client,

- Taux de performance des commandes (order fill rate) : Pourcentage des commandes

complètement livrées par rapport à l’ensemble des commandes de chaque client et de

chaque fournisseur.

4.6.2.3 Contrôle de qualité- Pourcentage des messages EDI rejetés par fournisseur et par client,

suite à anomalies techniques ou fonctionnelles (qualité des données par exemple),

- Ponctualité, fiabilité dans le respect des dates et heures de livraison

(OTD : On Time Delivery par exemple).

4.6.2.4 ProductivitéCes indicateurs de productivité sont des ratios : rapport entre le nombre d’entrées et de sorties

des processus logistiques, ou bien rapport entre un nombre à l’instant t et un nombre moyen :

Productivité = Nombre de sorties / Nombre d’entrées

Exemples d’indicateurs de productivité :



Nombre de commandes expédiées / Nombre de commande reçues (durant la même période)

Nombre de commandes expédiées (durant une période) / Nombre moyen de commandes ex-

pédiées (par période)

Ces indicateurs doivent toutefois être pondérés par le niveau de l’activité commerciale car ils

ne dépendent pas complètement des intervenants impliqués dans l’exécution des processus.

Des comparaisons pourront être effectuées en interne (entre fournisseurs, entre clients, entre

services, entre divisions, etc.) ou plus difficilement en externe (avec des entreprises dans le

même secteur d’activité ou directement avec les chiffres moyens du secteur).

4.6.2.5 Notions de statistiquesLes processus métiers étant souvent différents d’une entreprise à une autre, il faut choisir les

indicateurs de performance adaptés à chaque cas.

L’indicateur de performance principal sera le temps total d’exécution d’un processus, avec

son lot d’informations statistiques pouvant être facilement calculées dès qu’il existe un histo-

rique : minimum, maximum, moyenne, écart type, médiane, etc. Toute déviation en dehors de

la plage de ses valeurs habituelles de référence temporelle (baseline) devra être détectée puis

signalée comme le montre la figure ci-après.



Figure 13 : Exemple de non-conformité avec déclenchement d'alertes (webMethods)

Il convient, selon les cas, de bien distinguer entre la moyenne et la médiane. En effet,

quelques rares instances de processus qui se déroulent mal puis se terminent enfin après des

délais anormalement longs pourraient donner une moyenne anormalement élevée qui ne re-

flète pas la réalité, car plombée par ces valeurs extrêmes. Dans ce cas, il est préférable d’indi-

quer la médiane, qui prend en compte le nombre d’instances, mais ne pondère pas le résultat

en fonction de leurs valeurs.

Enfin, l’optimisation des processus logistiques passera par l’analyse des écarts types. L’écart

type est l’écart habituellement constaté entre la valeur moyenne et la valeur courante. Plus cet

écart est faible, plus le processus est sous contrôle. La lettre grecque sigma est le symbole de

l’écart type. Cette lettre a donné son nom à la méthodologie Six Sigma (6 ; marque déposée

par Motorola) que l’on peut appliquer dans la phase préalable de modélisation des processus

(BPM). Pour mémoire uniquement, la variance est l’écart type au carré.

Il faut signaler que ces informations statistiques sont basées sur une répartition normale (ap-

pelée aussi gaussienne) des valeurs mesurées. Dans le cas de la logistique et plus particulière-

ment du transport, les délais normaux de livraison sont définis précisément par un plan de

transport, selon les zones géographiques où sont situés les destinataires (par rapport à la zone



géographique où est situé l’expéditeur). Dans ces conditions, les marchandises expédiées n’ar-

rivent jamais avant la date de livraison théorique, mais peuvent arrivées après à cause d’inci-

dents divers (problèmes d’étiquette, d’adresse, de routage, etc.). L’optimisation des processus

logistiques sera donc focalisée sur l’écart type « de droite », c.à.d. sur la diminution des va-

leurs supérieures à la moyenne (l’axe du temps est par convention représenté horizontalement

de gauche à droite).

4.6.2.6 Règles de gestionDes règles de gestion précises, quelquefois élaborées (les anglo-saxons parlent alors de CEP :

Complex Event Processing), pourront être appliquées sur un indicateur, afin de déclencher ou

non une alerte à destination d’un opérateur : c’est un traitement par exception. Voici une

bonne description donnée par [GARIMELLA 2008, page 34] : « Lorsqu'un processus se

confronte à des conditions inattendues, l'outil de Business Activity Monitoring (BAM) détecte

l'évènement et entreprend des actions prédéfinies. Les actions, spécifiées lors de la modélisa-

tion du processus, peuvent aller de la notification personnalisée (par email, pager, etc.) à des

interactions complexes avec des systèmes. »

Un moteur de règles pourra parfois s’avérer nécessaire (Exemple : OpenLexicon livré avec In-

talio|BPMS), si l’on souhaite remplacer un opérateur et prendre automatiquement une déci-

sion à sa place. [TAYLOR 2007, page 111] indique que certains produits de BAM sont ca-

pables de court-circuiter les opérateurs concernés (v.o. bypassing people in the loop) pour

alerter directement des applications, mais cette caractéristique semble assez rare. [TAYLOR

2007, page 353] trouve toutefois dommage que ces règles métiers, qui sont souvent propres à

l’Entreprise et qui font partie de son capital, soient réservées aux outils de CEP et de BAM et

ne puissent pas être utilisées et partagées par d’autres applications (les « vieilles » applica-

tions héritées du passé notamment - legacy applications).

4.6.2.7 Indicateurs de performance clésIl convient de se focaliser sur les indicateurs de performance clés (Key Performance Indica-

tors – KPI – en anglais) afin d’éviter une avalanche de chiffres plus ou moins utiles. On dis-

tinguera les indicateurs obtenus directement à partir de mesures (données élémentaires) de

ceux qui sont issus de l’agrégation de plusieurs mesures (informations de haut niveau). Selon

[GARIMELLA 2008, page 45] : « Les outils de BAM proposent aussi des fonctionnalités

d'analyse supplémentaires, comme la possibilité de corréler différents KPI et d'explorer les in-

teractions », mais ce n’est pas encore, à notre humble avis, le lot de tous les outils.



Pour valider le choix des indicateurs de performance, deux questions pragmatiques au moins

doivent être posées aux utilisateurs auxquels ils sont destinés :

- A quoi va leur servir ces indicateurs de performance ?

La reconnaissance de leurs pertinences [DORNIER 2007] doit être acquise.

- A quelle fréquence ont-ils besoin de cet indicateur de performance ?

Toutes les minutes - quasi temps réel -, toutes les heures, ou tous les jours ?

Un groupe de quelques utilisateurs devra être réuni pour en débattre, constitué de spécialistes

des activités concernées (les best users des applications par exemple), afin de recueillir leur

point de vue opérationnel, mais aussi quelques managers directs ou indirects.

On privilégiera notamment les indicateurs de performance qui permettent de vérifier le res-

pect ou non des engagements de niveaux de service (SLA), surtout ceux qui sont assujettis à

des pénalités financières en cas de non respect.

4.6.2.8 Colorisation des indicateurs de performanceC’est l’observation continue des indicateurs de performance associée à un processus métier

qui permettra de définir précisément l’état de chaque instance de ce processus. Une colorisa-

tion des différents états possibles facilitera la visualisation sur le tableau de bord. La méta-

phore des feux tricolores servant à réguler la circulation automobile est la plus usitée :

- Vert : Tous les indicateurs de performance de l’instance du processus ne dépassent pas

les limites qui ont été fixées préalablement,

- Rouge : Au moins un des indicateurs de performance de l’instance du processus dé-

passe la limite qui a été fixée préalablement,

- Orange (amber en anglais) : Au moins un des indicateurs de performance de l’instance

du processus s’approche de la limite qui a été fixée préalablement (l’instance du pro-

cessus est alors border line).

Bien entendu, le BAM alertera les intervenants afin qu’ils s’occupent au plus vite des ins-

tances des processus qui sont passées au rouge (mode réactif). Mais la véritable valeur ajoutée

du BAM sera dans la détection en temps réel de l’état intermédiaire « orange », afin d’éviter

dès que possible, par des actions adéquates, qu’il ne passe au rouge (mode proactif).



4.7 Les indicateurs d’activitéUn besoin d’indicateurs, non pas de performance mais plus simplement d’activité, s’est fait

ressentir chez DHL, dans le cadre du pilotage de processus logistiques « asynchrones ». On

entend ici par asynchrone, un évènement (l’évènement déclencheur qui génère l’instance d’un

processus) qui peut survenir n’importe quel jour (week-end compris) et à n’importe quelle

heure (jour et nuit). Cela est dû à des processus logistiques se déroulant dans un contexte in-

ternational (worldwide) et dont certaines tâches sont effectuées dans d’autres pays situés dans

des fuseaux horaires différents (Exemple : importation en France de matériel expédié de

l’étranger).

Les opérateurs savent rarement si l’absence d’évènement est liée à une absence d’activité

« normale » ou à un problème informatique non signalé. Dans le cas de processus logistiques

où les flux physiques sont doublés par des flux EDI, il s’agira par exemple d’un ordinateur

qui n’envoie pas les fichiers attendus.

Aussi, l’indicateur d’activité pourra simplement rappeler le jour et la date du dernier évène-

ment déclencheur, la réception de la dernière commande par exemple. Une alerte pourra être

déclenchée s’il n’y a pas d’activité, c’est-à-dire pas d’évènement déclencheur donc pas de

nouvelle instance de processus, depuis plusieurs jours (time-out).

Une fois l’élément déclencheur enfin survenu, l’instance du processus étant alors créée, la sur-

veillance des délais internes entre les différences tâches du processus pourra s’effectuer nor-

malement grâce aux indicateurs de performance habituels (BAM classique).

A noter que, contrairement aux indicateurs de performance, les indicateurs d’activité ne dé-

pendent pas de l’Entreprise mais de l’environnement extérieur dans lequel elle évolue, notam-

ment de ses Clients.

Quelques indicateurs représentant l’activité courante, utilisés à des fins informatives, peuvent

également être affichés. Ainsi, pour représenter la partie Transport des processus logistiques,

on pourra afficher par exemple, afin de mesurer les sorties physiques d’un entrepôt :

- le nombre d’expéditions quotidiennes,

- le poids moyen d’une expédition,

- le nombre moyen de colis par expédition,



- le poids moyen d’un colis.

4.8 Mesure des indicateurs4.8.1 Principe de mesure

Pour mesurer les indicateurs de performance et d’activité, il faudra éviter la modification des

applications existantes, si l’on veut éviter un frein supplémentaire au déploiement du BAM

dans l’Entreprise, avec un lourd impact sur le délai et sur le coût. Par contre, pour les nou-

velles applications, l’intégration du BAM dans le cycle de développement permettra de sim-

plifier l’intégration ultérieure. La standardisation du format des messages échangés au sein de

l’Entreprise, puis la génération de messages standard pour chaque nouveau développement est

un bon exemple du but qu’il faut atteindre. Il n’y a pas encore, à notre connaissance, de nor-

malisation de format de messages pour le BAM, par un organisme indépendant.

Les informations nécessaires à la mesure des indicateurs de performance doivent être collec-

tées « au fil de l’eau » (on the fly). Il est hors de question de les collecter la nuit (ou en dehors

des heures de travail) par un traitement de type batch (comme cela peut être fait pour alimen-

ter un entrepôt de données utilisé par la Business Intelligence). En effet, le BAM doit fournir

des indicateurs de performance en temps réel et ne saurait attendre la fin d’un tel traitement

nycthémère. Il existe plusieurs possibilités pour collecter ces informations, selon [CRUSSON

2004, page 12] qui sont détaillées ci-dessous.

4.8.2 A partir des applications existantesIl est possible de collecter les informations nécessaires directement à partir d’une application

existante, qui aura été préalablement configurée pour générer l’information adéquate à la suite

d’une action ou d’un évènement précis (déclenchement par trigger) ; il est alors souhaitable

que cette fonctionnalité soit offerte en standard dans l’application, plutôt que de nécessiter un

développement spécifique (couteux, difficile à maintenir et indubitablement intrusif).

Puis certaines applications proposent en standard des API (Application Programming Inter-

face) qui permettent de les interroger périodiquement.

Enfin, si l’application s’appuie sur un Système de Gestion de Bases de Données Relation-

nelles (SGBDR) standard, il est possible de l’interroger directement en utilisant les méca-

nismes habituels (requêtes SQL via pilotes ODBC ou JDBC - Open or Java DataBase

Connectivity), sous réserve de disposer du Modèle de Données. Il s’agit alors d’un accès en



lecture uniquement au SGBDR, qui ne peut donc pas porter atteinte à l’intégrité des données,

qui n’est pas intrusif, mais qui peut être gourmand en ressources systèmes.

Collecter les informations à partir des applications existantes présente l’avantage de pouvoir

extraire uniquement les informations nécessaires à la mesure des indicateurs de performance.

Cette approche peut être envisagée si une seule application, dite verticale, permet l’exécution

complète d’un ou plusieurs processus métiers.

Par contre, modifier toutes les applications de l’Entreprise qui sont utilisées lors de l’exécu-

tion des processus métiers afin de récupérer toutes les informations nécessaires au BAM pour-

rait conduire à un gigantesque chantier. A notre avis, seul un ensemble d’applications homo-

gènes partageant un référentiel commun (logiciel de type ERP - Enterprise Resource Planning

- avec différents modules métiers) permettrait d’envisager cette approche, nécessitant toute-

fois la contribution de l’éditeur.

Profitons de ce chapitre pour indiquer que les fichiers rejetés automatiquement par les appli-

cations lors de leurs tentatives d’intégration pourraient faire l’objet d’une surveillance par le

BAM. En effet, ils échouent généralement dans un répertoire, sans notification des utilisateurs

de l’application (ou alors la raison du rejet n’est pas indiquée) et sont retrouvés en cas de ré-

clamation uniquement…

4.8.3 A partir des fichiers échangésIl est également possible de collecter les informations nécessaires à partir des fichiers échan-

gés entre deux applications de l’Entreprise (flux inter-applicatifs c’est à dire EAI) ou entre

une application de l’Entreprise et ses partenaires extérieurs (EDI avec ses fournisseurs et ses

clients). L’inconvénient est que ce déluge d’informations n’est pas filtré, et c’est l’outil de

BAM qui doit alors faire le tri pour ne conserver que celles nécessaires à la mesure des indica-

teurs de performance.

Cette solution est plus facile à mettre en œuvre si les applications de l’Entreprise sont déjà

connectées via un bus logiciel (ESB Enterprise Service Bus faisant partie du MOM : Message

Oriented Middleware), qui constitue alors la colonne vertébrale (backbone) des échanges in-

ter-applicatifs. On parle alors de messages, si possible standardisés au format XML, au lieu de

parler de fichiers. Le produit le plus ancien (15 ans déjà) et le plus répandu (80% du marché)

est MQSeries (MQ : Message Queue d’IBM ; le nouveau nom de ce produit est désormais



WebSphere MQ), mais de plus en plus les nouvelles solutions basée sur une Architecture

Orientée Services (SOA) utilisent le produit Open Source JMS (Java Message Service). Ces

deux produits peuvent désormais travailler ensemble.

Les différentes applications sont alors interconnectées entre elles. Quand l’une d’entre elles

publie (publish) une information sous la forme d’un message, il suffit aux autres applications

qui sont intéressées par cette information de s’abonner (subscribe) pour la recevoir. L’applica-

tion de BAM pourrait être une de ces applications et recevoir automatiquement des « copies »

des messages échangés sur le bus logiciel. Dans ce cas, il y a généralement plusieurs sources

qui publient des informations, au même format standard de préférence, et l’application de

BPM qui s’abonne à toutes. Cette solution n’est pas intrusive et n’a aucun impact sur les per-

formances du système informatique existant (notamment parce que les échanges se font de

manière asynchrone).

Figure 14 : Bus logiciel avec mécanisme Publish-Subscribe (Thierry BIARD)

Mais le bus logiciel n’est pas encore très répandu dans beaucoup entreprises. Le cas le plus

fréquent reste la liaison point à point entre une application et une autre (le protocole de com-

munication utilisé est alors le plus souvent FTP - File Transfer Protocol). Mais les entreprises

de taille importante ont de plus en plus recours à une plate-forme EAI qui centralise les

échanges entre les applications et une plate-forme EDI qui centralise les échanges avec les

partenaires externes (clients, fournisseurs).


Producteur A

(Publish)

Consommateur

(Subscribe)

BAM

Consommateur

(Subscribe)

Appli. X

BUS LOGICIEL

Producteur B

(Publish)

Producteur C

(Publish)


Figure 15 : Echanges de données entre applications sans et avec EAI (Thierry BIARD)

Chez DHL France, il s’agit d’une plate-forme unique qui s’occupe de l’EAI et de l’EDI (les

communications avec le monde extérieur sont toutefois déportées sur une passerelle dédiée -

gateway - installée en zone démilitarisée DMZ pour des raisons de sécurité).

Figure 16 : Architecture EAI & EDI chez DHL France (Thierry BIARD)

Que ce soit un bus logiciel ou une plate-forme EAI-EDI, on peut donc récupérer les informa-

tions nécessaires à la mesure des indicateurs de performance, mais celles-ci seront noyées par-

mi toutes les autres informations. Il semble alors bien difficile, dans ces conditions, de rappro-



cher un fichier retour avec un fichier aller, sous cette avalanche d’informations. Toutefois, il

est possible de mettre en œuvre un mécanisme de corrélation, dont le but est de rapprocher ces

différents fichiers, s’ils contiennent tous une référence unique (numéro de commande par

exemple).

4.8.4 A partir de processus modélisés puis exécutésC’est sans doute la meilleure méthode pour collecter les informations nécessaires au BAM,

mais aussi la plus simple. La solution idéale est de disposer d’un BPMS configurable pour gé-

nérer directement ces informations qui n’auront plus qu’à être analysées puis présentées par

l’outil de BAM. Le journal qui stocke dans l’ordre chronologique la séquence des informa-

tions collectées est appelé audit trail.

Si le BPMS ne propose pas cette fonctionnalité, il est possible d’ajouter dans les processus

des tâches spécifiques consistant à envoyer les informations nécessaires vers l’outil de BAM.

C’est donc l’utilisateur métier (ou le Business Analyst) qui précise, au moment de la modéli-

sation du processus, quels indicateurs il souhaite piloter.

Il est également possible de modéliser des processus techniques de BAM dont l’objectif est de

collecter puis d’analyser les informations, mais il est préférable de se concentrer sur la modé-

lisation des processus métiers. Cette solution est en outre gourmande en ressources système.

Les inconvénients de la collecte d’informations à partir de processus modélisés puis exécutés

sont directement ou indirectement d’ordre financier : il faut modéliser préalablement les pro-

cessus d’où un investissement important en temps (formation, courbe d’apprentissage) et en

coût (licence logiciel, formation encore). Mais à moyen terme, cela s’avère rentable. Il faut

noter que la modélisation permet souvent la réutilisation de certaines fonctions banalisées

dans plusieurs processus, ce qui constitue un avantage.

Selon [NEWCOMER 2005, page 228], la modélisation permet au BAM de connaître le

contexte d’exécution des processus métiers et de pouvoir corréler des informations et des évè-

nements avec les processus modélisés concernés.

4.9 De l’intérêt de la modélisation des processusLa modélisation d’un processus va permettre de représenter de façon graphique l’ensemble

des activités dont l’exécution dans un ordre bien précis va constituer ce processus, avec no-



tamment un début et une fin clairement identifiés. Cet exercice est long et difficile mais au

combien utile. On sera toujours surpris par les représentations différentes qu’ont les différents

intervenants qui exécutent pourtant les mêmes activités depuis plusieurs années. Quant à leurs

managers, leur perception est souvent bien différente également. Les réunir tous ensemble au-

tour d’une table afin de modéliser noir sur blanc un processus métier ne peut être que béné-

fique pour l’Entreprise. Cette documentation peut accessoirement répondre à des contraintes

de certification, comme le respect de la norme ISO-9000.

La modélisation est, à notre avis, une étape indispensable pour pouvoir mesurer les étapes in-

termédiaires afin de pouvoir ensuite les optimiser (voire modifier le déroulement d’un proces-

sus et donc son modèle).

Les solutions de certains éditeurs (Exemple : BusinessBridge & BusinessVision de Systar)

proposent des modèles de processus prédéfinis, mais qui ne peuvent s’appliquer qu’à des acti-

vités très standard, comme la vente d’un produit par une société de distribution (solution ver-

ticale banalisée). Pour les processus logistiques complexes, qui permettent de distinguer le sa-

voir-faire de chaque entreprise, il est nécessaire de les modéliser soi-même.

Enfin, le modèle d’un processus sera la base du dialogue entre les intervenants métiers et les

intervenants tiers, les informaticiens notamment, qu’ils soient internes ou externes (sociétés

de services, éditeurs de solutions BPM et BAM).

4.10 Une théorie pertinente pour la modélisationTandis que certains outils de modélisation autorisent une représentation graphique quasiment

libre (il en est ainsi d’UML - Unified Modeling Language - et notamment de son diagramme

d’activités pour modéliser les processus qui nous intéressent), un peu plus de formalisme est

nécessaire pour obtenir un modèle qui va pouvoir « tourner » dans la vraie vie. C'est-à-dire

que chaque début d’un processus métier créera une instance unique dans le système BPM qui

permettra de suivre jusqu’à la fin le déroulement de ce processus.

Le monde de l’automatisme industriel dans les années 1960 puis celui des télécommunica-

tions dans les années 1990 ont bâti le socle d’un formalisme mathématique encore utilisé de

nos jours.

Le formalisme mathématique Pi-Calculus sur lequel s’appuie la notation BPMN décrite plus

bas répond à ce besoin. Ce formalisme a été élaboré pour les premiers téléphones cellulaires



et mobiles. Il s’agissait, dans un même processus, d’exécuter des activités en parallèle, tout en

les resynchronisant une fois ces activités terminées. En l’occurrence, l’activité principale était

d’assurer la connexion avec l’émetteur de plus proche, tandis que l’activité secondaire consis-

tait à chercher l’émetteur suivant, afin d’éviter toute rupture de la communication télépho-

nique (technique dite du roaming, sorte de vagabondage entre les émetteurs).

Le résultat de ce formalisme mathématique est d’obtenir un modèle valide. Cette validation

est obtenue par les outils de modélisation qui se conforment scrupuleusement à la notation uti-

lisée. Il arrive toutefois qu’un modèle valide ne soit pas l’expression de la réalité : une phase

de mise au point sera souvent nécessaire.

4.11 De l’intérêt de la standardisation4.11.1 Périmètre de la standardisation

La standardisation s’applique aussi bien à des notations (de modélisation, sous forme gra-

phique) qu’à des langages (d’exécution, beaucoup plus verbeux). Tandis que les notations

graphiques standardisées permettent à des intervenants, équipés parfois d’outils de modélisa-

tions différents, de se comprendre puis de discuter, les langages sont, quant à eux, beaucoup

moins visibles, voire cachés pour la plupart des intervenants. En fait, les langages standardisés

assurent essentiellement l’interopérabilité entre les outils de différents éditeurs. Notations et

langages standardisés sont quelquefois liés : par exemple, la notation BPMN succinctement

décrite ci-dessous est généralement transformée en langage BPEL par l’un des outils de la

suite BPM. Des règles de correspondance précises (mapping) entre cette notation et ce lan-

gage sont d’ailleurs établies.

4.11.2 La notation BPMNLa notation qui s’impose actuellement sans contestation possible pour la modélisation des

processus est la notation BPMN (Business Process Modeling Notation). Publiée initialement

par des éditeurs de logiciels regroupés par l’Initiative BPM (BPMI), cette notation est désor-

mais dans le giron du consortium OMG (Object Management Group), tout comme UML cité

précédemment. Il est intéressant de signaler que BPMN et UML sont donc plus complémen-

taires que concurrents. La notation BPMN est la représentation graphique de la modélisation

des processus : c’est la partie visible pour tous les intervenants, même les non-informaticiens.

La portabilité de cette notation est assurée par le langage XPDL (XML Process Definition

Language) qui permet d’exporter un modèle d’un outil puis de l’importer dans un autre.



4.11.3 Le langage BPELL’exécution des processus est rendu possible grâce au langage BPEL (Business Process Exe-

cution Language) publié par le consortium OASIS (Organization for the Advancement of

Structured Information Standards). Le BPEL est la traduction en langage “machine” du pro-

cessus métier : c’est la partie cachée pour la plupart des intervenants. Seuls quelques informa-

ticiens (uniquement les développeurs en fait) y ont accès. Ce langage « machine » est plus ou

moins spécifique à chaque système BPM (BPMS) : sa portabilité n’est donc pas complète-

ment assurée ; mieux vaut échanger le modèle défini préalablement en notation BPMN lors du

changement d’un système BPM par un autre.

4.11.4 Le langage BPQLUne tentative de standardisation d’un langage d’interrogation pour le BAM a été faite en 2004

par l’Initiative BPM (BPMI) avant son regroupement avec le consortium OMG (Object Ma-

nagement Group) : il s’agit du BPQL (Business Process Query Language) [HAVEY 2005,

page 144]. Ce langage, défini par des WSDL (Web Service Definition Language), qui voulait

constituer une des fondations du BAM, n’est resté qu’au stade du projet d’intention, car sa

version publique n’a jamais été publiée à ce jour.

4.12 Positionnement du BAM par rapport à la BIIl est important de noter que certains analystes (Exemple : Forrester Research) considèrent le

BAM comme une application de la Business Intelligence (BI). Leurs positionnements sont

toutefois différents, ainsi que leurs outils. Le BAM et la BI s’appuient tous les deux sur des

bases de données relationnelles, consultables à l’aide de requêtes SQL.

Mais le BAM doit fournir des indicateurs en temps réel sur le déroulement des processus en

cours d’exécution, permettant ainsi un pilotage opérationnel, par les intervenants métiers et

leurs managers directs (N+1). C’est un outil au service de l’équipe opérationnelle.

Tandis que la Business Intelligence permet une analyse à postériori sur une période donnée, à

partir de l’historique stocké dans un entrepôt de données des processus dont l’exécution est

terminée, permettant ainsi un pilotage tactique voire stratégique, par les managers directs

(N+1) ou indirects (N+2, N+3...) d’une autre équipe (contrôle de gestion, ventes & marketing,

qualité), voire par la direction générale de l’entreprise.



Selon [RANADIVÉ 2006, page 227], qui fait une comparaison implicite avec la Business In-

telligence : « L’objectif du BAM est de faciliter une prise de décision adéquate et plus rapide

grâce à des informations actualisées à la seconde près, au lieu de compter sur des informations

périmées recueillies grâce à des requêtes ponctuelles ».

Chez DHL, les entrepôts de données (data warehouse) sont alimentés rarement quotidienne-

ment (toujours la nuit), plus couramment une fois par semaine ou une fois par mois par un ou-

til d’ETL (Extract Transform Load) : l’exploitation qui est faite de ces données est bien de la

Business Intelligence ; par contre, ce n’est clairement pas du BAM, car cela n’aide en rien les

opérations quotidiennes des exploitants.

Le calcul de tendance est à mi-chemin entre le BAM et la BI : il faut corréler une mesure

temps réel avec l’historique des mesures précédentes. Les tableaux de bord afficheront donc

une consolidation de ces deux types de mesures.

Figure 17 : Consolidation des données stockées et temps réel (Thierry BIARD)



Certaines fonctionnalités sont identiques. Par exemple, le drill-down permet d’investiguer du

niveau le plus haut (le processus métier) jusqu’au niveau le plus bas (l’activité, l’étape, voire

la règle associée à un indicateur) afin de trouver l’origine d’un problème (root cause). [HA-

VEY 2005, page 39] propose même le terme de process mining (exploration des processus)

comme synonyme du BAM, en référence au terme plus courant de data mining, utilisé dans le

Business Intelligence.

En fait, certains se posent la question d’adapter - s’ils sont déjà en place - leurs outils de Busi-

ness Intelligence, d’Analyse et de Reporting, plutôt que d’investir dans un nouvel outil spéci-

fique pour le BAM. Ainsi, il est possible de connecter un outil de Business Intelligence

(Exemple : Business Object) sur un BPMS en utilisant de préférence une interface de type

Web Services.

La solution technique dépendra également du cœur de métier de l’éditeur de l’outil BAM. Il y

a aujourd’hui très peu d’éditeurs proposant des solutions complètement dédiées au BAM (ap-

pelés aussi pure players. Exemple : Systar, société française et leader mondial). Certains ont

été rachetés par des éditeurs plus généralistes, afin de compléter leur catalogue de produits

(Exemple : Celequest racheté par Cognos, lui-même racheté par IBM). Puis il y a ceux qui

étendent leurs suites BPM (le module BAM, pour le moment optionnel et souvent limité, sera

bientôt incontournable et de plus en plus riche). Enfin, il a ceux qui sont spécialisés dans la

Business Intelligence, et qui voient dans le BAM un moyen de toucher un nouveau type de

clientèle. Dans ces derniers cas, ces extensions d’activités se font souvent par l’acquisition de

sociétés spécialisées.

4.13 Méthodes applicables :4.13.1 Méthodes applicables au BPM

Voici une liste des principales méthodes (ou approches) applicables pour la phase prélimi-

naire de modélisation des processus (BPM) :

- ABC (Activity Based Costing),

- PDCA (Plan Do Check Act – roue de Deming),

- DSDM (Dynamic Systems Development Method),

- Top-Down (approche BPR – Business Process Re-engineering),

- Bottom-Up (approche EAI – Enterprise Application Integration),

- Middle-Out (approche CPI – Continuous Process Improvement).



4.13.2 CPI (Continuous Process Improvement)La dernière approche CPI dans la liste ci-dessus est intéressante pour le BAM, car elle est

orientée vers l’optimisation permanente. A défaut d’améliorer constamment son niveau de

service, une entreprise prend le risque de perdre des clients. Face à la concurrence mondiale,

il ne faut pas attendre que les clients formalisent leur demande, il faut anticiper.

L’amélioration continue des processus, par la modélisation, puis la mesure, ensuite la correc-

tion et enfin l’optimisation est l’objectif du CPI. Il s’agit de mettre en place un cercle ver-

tueux, comme la roue de Deming qui illustre la méthode qualité PDCA (Plan Do Check Act).

Trois méthodes au moins sont applicables pour le BPM : Six Sigma, Lean et TQM (Total

Quality Management).

4.13.3 Méthode applicable au BAMQuant au BAM, il n’y a, à notre connaissance, qu’une seule méthode formelle, qui permet de

qualifier un processus métier pour le BAM. Ainsi, la société française Systar, pionner et lea-

der du BAM dans le monde, propose la méthode BAM Matrix™ [SYSTAR, web], présentée

dans le chapitre suivant. Certaines méthodes applicables à l’élaboration des tableaux de bord

seront sans doute applicables au BAM. Ainsi, pour [ECKERSON 2005, page 117], le BAM

n’est qu’un tableau de bord opérationnel, orienté toutefois vers le pilotage de la performance.

Que ce soit pour la partie BPM ou pour la partie BAM, les méthodes de gestion de projets ha-

bituelles en informatique seront utilisées, afin de suivre notamment le déploiement de l’infra-

structure nécessaire (matériel & logiciel).



Chapitre 5.Les outils utilisés et décrits

5.1 La BAM Matrix™5.1.1 Objectif de la méthode BAM Matrix™

BAM Matrix™ est une marque déposée par Systar. L’objectif principal de la méthode BAM

Matrix™ est de valider la pertinence du choix des processus candidats au BAM puis de défi-

nir les priorités d’implémentation du BAM pour ces processus. La méthode BAM Matrix™

ne couvre pas ensuite l’implémentation effective du BAM sur les processus métiers retenus.

Notamment, cette méthode ne porte pas sur le choix des indicateurs de performance (KPI).

Le postulat de départ est qu’il n’est pas recommandé d’implémenter le BAM pour tous les

processus métiers d’une entreprise d’un seul coup : cette approche radicale de type big-bang

aurait toutes les chances de péricliter (sauf peut-être lors de la création d’une entreprise nou-

velle du genre start-up, où le BAM serait mis en place en même temps que la formalisation

voire la modélisation des processus métiers).

Il s’agit donc de donner un score BAM aux différents processus candidats, afin de les pondé-

rer, de les catégoriser puis finalement de les comparer entre eux. Seuls les meilleurs candidats,

ceux qui devraient permettre potentiellement d’obtenir les meilleurs résultats, seront retenus

pour l’implémentation du BAM.

5.1.2 La méthode BAM Matrix™Pour estimer les 3 indicateurs détaillés ci-dessous, il suffit de répondre à 3 listes de questions

relativement simples. Il est toutefois fortement conseillé de s’entourer du personnel opération-

nel afin de répondre justement à ces questions. Ces listes de questions ne sont pas reproduites

dans cette thèse, car la méthode BAM Matrix™ est protégée par des droits d’auteur.

5.1.2.1 Le BAM Matrix™ ScoreEstimer le BAM Matrix™ Score d’un processus candidat permet essentiellement de le pondé-

rer afin de pouvoir le comparer aux autres. Ce score est basé sur certaines caractéristiques du

processus métier : la distance avec le client (externe ou interne), la réactivité au changement

de l’environnement et les sources de dysfonctionnement. Plus une activité est proche du



client, plus le besoin de réactivité est fort, plus les sources de dysfonctionnement sont nom-

breuses, plus la valeur potentielle du BAM est grande et le score obtenu est élevé.

Parmi les nombreuses sources potentielles de dysfonctionnement dans un processus, seule est

abordée, dans cette thèse, celle qui concerne les échanges d’informations, qu’ils soient in-

ternes (EAI) ou externes (EDI avec des partenaires). Il faudra essentiellement identifier les

échanges d’informations qui sont indispensables au bon déroulement d’un processus métier.

Lire plus loin le chapitre sur la synchronisation du flux EDI et du flux physique, qui concerne

le BAM de façon générale.

5.1.2.2 La BAM Matrix™ UrgencyEstimer la BAM Matrix™ Urgency d’un processus candidat, en déterminant l’urgence de ré-

solution d’un incident, permet de le catégoriser. Cet index d’urgence est fondé sur les com-

portements vis-à-vis du processus métier. Plus cet index est élevé, plus la visibilité potentielle

du BAM sera élevée également.

Sous réserve qu’il s’agisse d’une activité existante, il convient d’analyser les incidents qui af-

fectent son bon déroulement : délai d’identification, coût de résolution et notification. Le délai

pour s’apercevoir d’un incident et l’éventuel besoin d’anticipation, afin d’éviter qu’il ne sur-

vienne, sont également pris en compte. Les incidents récurrents (qui deviennent alors un pro-

blème, selon la définition d’ITIL) feront l’objet d’une plus grande attention. L’impact des in-

cidents sur les clients sera pris en compte également. Cette analyse sera pondérée selon la

croissance de l’activité, qui est souvent un facteur d’amplification du nombre d’incidents.

5.1.2.3 Le BAM Matrix™ ImpactEstimer le BAM Matrix™ Impact d’un processus candidat, en déterminant l’impact financier

d’un incident sur un processus, permet de le catégoriser également. Cet index d’impact est

fondé sur les conséquences pour un processus métier. Plus cet index est élevé, plus le retour

sur investissement (ROI) potentiel du BAM sera rapide.

En premier lieu, il convient de mesurer l’impact d’un incident sur le business (les opérations)

puis ses conséquences (généralement financières, mais en terme d’image également). Le

risque le plus important est de perdre un client. En second lieu, on notera si un incident dé-

grade la qualité de service formalisée dans un SLA, avec ou sans pénalités. Enfin, on pondére-

ra le résultat obtenu en fonction de la fréquence des incidents et de leurs conséquences réelles.



5.1.3 La BAM Matrix™ : une grille d’analyseLa BAM Matrix™ présente les résultats sous la forme d’une grille d’analyse, l’index Urgency

en abscisse, l’index Impact en ordonnée. Chaque processus métier candidat est alors représen-

té par un point et positionné sur cette grille. Le Score obtenu par chaque processus peut être

indiqué sous ou dans chaque point, afin de marquer les différences entre des points proches

les uns des autres. On pourrait sans doute aussi faire varier le diamètre du point selon son

score, comme cela se fait dans certaines méthodes de gestion de portefeuille de projets infor-

matiques [SAHILLIOGLU 2007, page 119].

Cette grille d’analyse comporte 4 zones qui permettent de catégoriser les processus métiers

candidats au BAM. Cette approche n’est pas sans rappeler la fameuse matrice du BCG (Bos-

ton Consulting Group). La priorité d’implémentation du BAM devra être donnée aux proces-

sus métiers ayant un index d’urgence et un index d’impact élevés, positionnés sur un seul

quart de la grille d’analyse. Ce positionnement idéal des processus métiers dans le cadran

« magique » (Magic Quadrant, concept cher au cabinet d’analyse Gartner) pourra être pondé-

ré par leurs scores, s’il est nécessaire de les départager.

5.1.4 La BAM Matrix™ : Exemple d’applicationVoici un exemple d’application de la BAM Matrix™ chez DHL. Nous avons calculé pour un

projet précis (constitué d’un ensemble d’activités formalisées par plusieurs processus métiers)

son index d’urgence, son index d’impact et son score (indiqué entre parenthèses : 8), afin de

le positionner sur la BAM Matrix™ pour estimer le bénéfice potentiel si on lui appliquait le

BAM. Ce projet de portail fournisseurs (Supplier Portal) est basé sur des échanges EDI entre

un client et ses fournisseurs. DHL est responsable du transport et du dédouanement des mar-

chandises des fournisseurs jusqu’au client et doit fournir une excellente qualité de service.



Figure 18 : La BAM Matrix™ (Systar)

Forte valeur (High Value) : Ces activités ont le potentiel de fournir un retour sur investisse-

ment rapide, mais ne sont pas forcément parmi les préférées du management.

Forte visibilité (High Visibility) : Ces activités recevront beaucoup d’attention, bien qu’elles

n’aient pas une forte valeur. Le retour sur investissement (ROI) ne sera pas rapide.

Forte priorité (High Priority) : Ces activités seront les plus faciles à justifier, car elles pré-

sentent à la fois une forte valeur et une forte visibilité. Ce sont ces activités qu’il convient de

choisir pour commencer à mettre en place le BAM.

Tactique (Tactical) : Ces activités n’ont ni une forte valeur, ni une forte visibilité. Appliquer

le BAM à ces activités ne se justifie que si c’est une demande spécifique du management pour

des raisons tactiques.

Dans l’exemple ci-dessus, l’index d’urgence est élevé, donnant à ce processus métier une

forte visibilité. Par contre, l’index d’impact est moyen, privant ce processus métier d’une forte

valeur. Cela est essentiellement dû au fait que les incidents n’ont pas d’impact financier di-

rect. En effet, le client n’a pas souhaité signer avec DHL un contrat d’interchange (document

généralement utilisé pour formaliser les Echanges de Données Informatisés, similaire au

SLA), qui aurait formalisé les engagements réciproques des deux parties, voire les pénalités

financières en cas de leur non-respect.



Aussi la décision, sans doute provisoire, a été prise de ne pas commencer par ce processus

métier pour l’implémentation du BAM. Un projet de migration de plate-forme EDI à moyen

terme n’accélère pas la mise en place du BAM non plus…

5.2 L’Architecture Orientée Service (SOA)5.2.1 Le concept de l’Architecture Orientés Services

Le BPM n’est pas une technologie, mais une discipline de management qui influe sur l’orga-

nisation de l’entreprise. Le BPM et le BAM sont théoriquement agnostiques à la technologie,

mais sont plus faciles à mettre en place grâce à une Architecture Orientée Service (SOA : Ser-

vice-Oriented Architecture). C’est aujourd’hui un fait avéré, qui n’a pas besoin d’être déve-

loppé dans cette thèse.

L’Architecture Orientée Service va présenter un système informatique sous la forme de ser-

vices évolués. Il s’agira si possible de services métiers : ainsi, il sera plus facile d’aligner l’in-

formatique avec le business. Ses avantages sont nombreux ; citons entre autres : réutilisation

des services existants donc diminution des coûts de développement, simplification et standar-

disation de l’intégration de nouveaux services.

Ce concept d’architecture logicielle ne concerne pas uniquement les nouvelles applications : il

est en effet possible d’exposer les fonctionnalités d’anciennes applications (legacy) sous

forme de services, afin d’uniformiser les accès à toutes les applications. C’est bien notre in-

tention d’utiliser cette possibilité afin d’interfacer la plate-forme EDI vieillissante avec une

suite BPM et BAM moderne.

5.2.2 Les Web ServicesCe n’est pas obligatoire, mais la majorité des Architectures Orientées Services s’appuient sur

des services de type web (Web Services). Ces services sont automatisés (ils ne requièrent pas

d’intervention humaine) et sont rendus en temps réel (sans attendre un traitement de nuit par

exemple). En outre, les fournisseurs de services et les consommateurs de ces services sont

souvent distribués/répartis sur des systèmes différents donc hétérogènes. Les Web Services,

qui garantissent l’interopérabilité entre ces différents systèmes, sont donc particulièrement

adaptés au suivi des processus métiers pour le BPM puis le BAM, dans l’environnement tel

qu’il a été décrit au début de cette thèse.



Les Web Services sont basés sur l’échange de messages XML selon le protocole http (l’en-

semble est regroupé dans le standard SOAP). La description du service proposé par un Web

Service interne (Intranet) ou externe (Internet) est fournie dans un fichier WSDL.



Chapitre 6.Les résultats obtenus, présentés et discutés

6.1 La désynchronisation des fluxLe flux d’information, matérialisé ici par des échanges de données, doit être plus ou moins

synchrone avec le flux physique de marchandises. Plus ou moins car, selon les cas les plus

courants, les informations précèdent ou suivent les marchandises. Ainsi, un ordre d’enlève-

ment précède l’enlèvement de la marchandise. Une preuve de livraison (POD : Proof Of Deli-

very) suit la livraison de la marchandise, car en effet on accorderait peu de crédit à une preuve

de livraison qui arriverait… avant la livraison effective. Il est bien rare que les informations et

les marchandises arrivent exactement en même temps : c’est sans doute le cas pour les mar-

chandises (ou leurs emballages) qui sont équipées de puces électroniques RFID (Radio Fre-

quency IDentification), mais cela reste encore assez rare.

6.2 La prédiction6.2.1 Le calcul des tendances

Le calcul des tendances des indicateurs de performance est la fonction de base pour prédire

les comportements futurs [GARIMELLA 2008, page 9]. Il convient d’indiquer au minimum si

la tendance d’un indicateur est stable, à la hausse ou à la baisse, généralement par une simple

flèche orientée vers le haut ou vers le bas. Une visualisation graphique de l’historique des me-

sures d’un indicateur de performance dans un tableau de bord permet de manière intuitive

d’appréhender sa tendance. Si des limites haute et basse ont été fixées et sont également vi-

sualisées, cela permet d’anticiper afin d’éviter tout débordement.

6.2.2 La prédiction des incidentsGrâce au calcul des tendances, la prédiction des incidents potentiels devient possible. Cela va

permettre d’anticiper les actions correctives afin d’éviter qu’ils ne surviennent.

A noter que l’utilisation du BAM est bien souvent « défensive », c'est-à-dire qu’elle s’attache

à mettre en évidence les dysfonctionnements réels (incidents) ou potentiels (risques).



On peut également imaginer une utilisation « offensive » du BAM pour identifier des oppor-

tunités commerciales.

Enfin, on peut noter que le BAM peut permettre d’améliorer des processus métiers qui se dé-

roulent normalement, c’est-à-dire sans forcément présenter d’incidents.

6.2.3 La prévention des risquesRappelons que les risques sont des incidents qui ne sont pas encore produits. Prédire les inci-

dents peut donc prévenir des risques et éviter ainsi les coûts de la non-qualité qui en dé-

coulent. Un des risques majeurs est la perte d’un client externe. Les clients internes sont sou-

vent plus captifs, mais ils disposent de plus en plus de la liberté de recourir à des prestataires

externes. Le coût d’acquisition d’un nouveau client est bien supérieur au coût de pilotage du

processus métier qui sert à satisfaire un client existant et à le fidéliser.

6.3 Les bénéfices6.3.1 Diminution de la non-qualité

Le BAM permet d’obtenir le taux des processus logistiques exécutés hors délai (selon une li-

mite préalablement définie). Une tactique pour diminuer ce taux de non-qualité peut alors être

établie, avec son lot d’actions correctives concrètes à appliquer par les opérationnels. Ces ac-

tions peuvent être documentées sous la forme d’instructions contextuelles en ligne. L’objectif

ultime de cette démarche de diminution de la non-qualité est bien entendu d’obtenir la satis-

faction des clients, qui sont plus sensibles aux dysfonctionnements qu’à la bonne marche de

leurs affaires (il est bien naturel de trouver cela normal quand tout va bien). Il nous plait aussi

de croire que l’amélioration de la satisfaction des clients permet d’augmenter le volume d’af-

faires confiées par un client à son prestataire logistique. Tandis que l’activité Entreposage est

le plus souvent confiée à un unique prestataire logistique, pour une durée de 3 ans maximum,

il est très fréquent que les activités Transport & Import-Export soient soumises à la dure loi de

la concurrence : le client a souvent plusieurs prestataires.

Le BAM, par sa surveillance détaillée de l’exécution des processus, permet de diagnostiquer

précisément et surtout rapidement la cause d’un dysfonctionnement, sans perdre de temps en

investigation au niveau du système d’information. Par contre, l’investigation sera sans doute

nécessaire au niveau du métier.



La non-qualité entraine généralement le non-respect des engagements (SLA) pris avec les

clients : les coûts induits peuvent alors se révéler importants (pénalités de retard imposées par

les clients ; transports gratuits en compensation ; amendes infligées par l’Administration, la

Douane notamment). En fait, lors du calcul du retour sur investissement d’une solution de

BAM, il est souvent plus facile de chiffrer les pertes évitées que les bénéfices attendus.

A noter que la mise en place du BAM pour le suivi des colis chez un transporteur américain

(Logistics Group) a permis de réduire le nombre de colis perdu de 75% et de réaliser plusieurs

millions de dollars d’économies [MALONE 2005, web].

6.3.2 Réduction des temps de traitementLa réduction des temps de traitement est souvent un bénéfice attendu, afin de pouvoir aug-

menter le volume d’affaires traitées par les activités métiers avec les mêmes ressources (à ef-

fectif constant). Cette augmentation du volume doit se traduire par une augmentation du

chiffre d’affaires et, encore mieux, de la marge commerciale dégagée, car on devrait enregis-

trer moins de dysfonctionnements lors de l’exécution des processus métiers pilotés par le

BAM, d’où des coûts moindres pour les résoudre.

6.3.3 Augmentation de la productivitéAfin d’augmenter la productivité, la réaffectation des ressources existantes peut être envisa-

gée, afin qu’elles soient disponibles sur le chemin critique des processus. Car tout retard sur

une des taches situées sur le chemin critique allonge le délai d’exécution de tout le processus.

Les informations fournies par le BAM sont fiables et doivent servir de base à toute discussion

visant à augmenter la productivité et à améliorer un processus métier.

6.3.4 Réduction des coûtsLa réduction des coûts directs est bien entendu le pendant de l’augmentation de la productivi-

té. Les coûts indirects sont quant à eux réduits par la diminution de la non-qualité. Le retour

sur investissement (ROI) d’une solution de BAM doit être obtenu rapidement. Les sources

d’économies obtenues, voire les gains, doivent permettre de rembourser l’investissement en 2

ou 3 ans maximum.

Nous avons abordé plus haut la notion de retour sur investissement par processus métier piloté

par le BAM. En fait, la solution de BAM sera bien souvent mutualisée pour le pilotage de plu-

sieurs processus métiers et le ROI devra en tenir compte. Mais le calcul du retour sur investis-



sement sera, si possible, justifié par une étude de cas détaillée (business case) s’appuyant de

préférence sur un processus métier candidat parmi ceux ayant le plus de potentiel d’écono-

mies grâce au BAM et offrant de la visibilité à la Direction de l’Entreprise (en améliorant la

qualité de service pour un client stratégique et historique par exemple).

Le calcul du retour sur investissement ne peut être basé que sur des estimations « grosses

mailles ». Il convient toutefois de fixer un cadre pertinent pour faire ces estimations. On pour-

ra généralement se baser sur les données historiques, pondérées éventuellement par la crois-

sance de l’activité concernée (peu de chance de mettre en place le BAM pour une activité en

déclin, sauf si l’on a pour ambition d’inverser la tendance).

6.3.5 Une comparaison Avant/AprèsLes engagements de service (SLA) vis-à-vis des clients sont rarement pris dès le début d’un

projet, mais souvent lors d’une deuxième phase de formalisation. Il s’agit de mettre noir sur

blanc les engagements de l’Entreprise pour répondre aux attentes des clients. La connaissance

précise de la performance opérationnelle, grâce au BAM, permet alors de négocier des ni-

veaux de services tangibles donc atteignables. Le niveau de la Qualité de Service peut alors

être communiqué aux clients, mais également aux prospects pour améliorer la visibilité de

l’Entreprise, voire augmenter sa part de marché au détriment de la concurrence.

En effet, il y a souvent un décalage entre le niveau de qualité perçu par les clients et le niveau

de qualité réelle prouvé par des chiffres. Le fait de communiquer les chiffres dans un souci de

transparence contribue de toute façon à donner aux clients une bonne perception de son four-

nisseur : cela démontre que les processus métiers sont sous contrôle, c'est-à-dire au moins me-

surés, à défaut d’être pilotés.

En fait, quand les prestations proposées par l’Entreprise sont relativement banalisées (les pro-

cessus logistiques sont essentiellement composés de transport et d’entreposage) et la concur-

rence féroce, une meilleure qualité de service peut constituer un critère déterminant pour fidé-

liser les clients existants et en attirer de nouveaux.

6.3.6 La valeur ajoutée dans la chaine de traitementLes indicateurs doivent permettre de localiser les maillons faibles dans la chaîne de traitement

d’un processus logistique. Ainsi, dans le cas d’un processus composé de plusieurs tâches

s’exécutant en parallèle, le chemin critique (selon la terminologie de la gestion de projet) sera



rapidement identifié : ce chemin est constitué des tâches dont le moindre retard d’exécution se

répercutera sur la durée d’exécution globale du processus. Il s’agira de renforcer les res-

sources disponibles pour ces tâches ou, pour le moins, prévoir leur remplacement en cas d’in-

disponibilité (analyse des risques).

6.4 Les impacts6.4.1 Une innovation pour le Business ?

Le BAM, grâce à l’automatisation des contrôles, permet de surveiller le respect de la régle-

mentation. Généralement, selon [GARIMELLA 2008, page 45], les outils de BAM exposent

l'information d'une manière graphique très intuitive et permettent aux utilisateurs métiers de

procéder à leur propre analyse afin de déterminer l’origine des problèmes rencontrés par les

processus.

6.4.2 L’impact sur les ClientsSans le BAM, la notification des intervenants est manuelle (et encore si leurs noms et leurs

coordonnées figurent dans une quelconque documentation…) mais surtout il est souvent diffi-

cile d’identifier l’intervenant concerné. Pire, on sollicite parfois inutilement un intervenant

qui n’est en rien à l’origine d’un dysfonctionnement. S’il s’agit d’un « vrai » client (externe),

l’impact est désastreux pour l’image de l’Entreprise.

Le BAM permet de prévenir les clients d’un dysfonctionnement, en plus des équipes internes

(opérationnels métiers voire informaticiens), par une notification automatique mais sélective,

généralement par email ou SMS (Short Message Service), aux intervenants concernés. La

bonne information envoyée à la bonne personne au bon moment permet d’agir le plus effica-

cement possible.

Enfin, une interface entre l’outil de BAM et l’outil de gestion des incidents, généralement

pourvu d’un mécanisme d’escalade (HP OpenView Service Desk chez DHL), pourra être en-

visagée, uniquement pour des incidents techniques dont la résolution dépend des informati-

ciens.

6.4.3 L’impact sur l’organisation et le personnelGrâce au BPM, chacun connait précisément son rôle dans un processus et grâce au BAM, cha-

cun connaît sa contribution directe à la performance du processus et pourquoi pas de l’entre-



prise. Leur efficacité sur des tâches particulières peut également être mesurée. L’autonomie

des intervenants est ainsi renforcée. Il est assez rare que cette implication ait un impact direct

sur la rémunération mensuelle des intervenants (le travail n’est généralement plus rémunéré

« à la pièce »). Par contre, cela pourra se traduire par des objectifs annuels, récompensés

comme il se doit par des primes s’ils ont été atteints (management par objectifs).

Il ne s’agit toutefois pas ici (et surtout dans le cadre de cette thèse) de comparer les individus,

mais plutôt de leur faire prendre conscience de leurs rôles dans les processus, de les responsa-

biliser, voire de les mobiliser, pour atteindre collectivement des objectifs communs. Les indi-

cateurs de performance seront si possible partagés entre plusieurs personnes (ce qui est de

plus en plus difficile à faire, car les équipes sont généralement de moins en moins grandes).

Pour continuer sur cette voie de la responsabilisation des intervenants, il sera intéressant que

ceux-ci puissent superviser, voire piloter, eux-mêmes leurs activités, selon leurs capacités,

s’ils disposent de suffisamment de temps pour le faire. Cela n’empêche pas bien entendu que

le management ait un droit de regard sur cette forme d’autocontrôle. Mais c’est là un autre dé-

bat, et dans la plupart des entreprises, la supervision et le pilotage seront effectués par des per-

sonnes tierces afin d’établir une séparation claire des rôles et des fonctions.

6.4.4 L’appropriation du BAM par les OpérationsLes Opérations s’approprieront le BAM s’il les aide concrètement à résoudre leurs problèmes

quotidiens. Il faut que les indicateurs de performance soient compréhensibles, sélectionnés et

regroupés dans un tableau de bord opérationnel, spécifiquement établi pour les Opérations. Ils

doivent leur permettre de prendre rapidement et facilement les bonnes décisions. Un tableau

de bord permet aux responsables de visualiser les tendances et de prendre les mesures néces-

saires pour anticiper d’éventuels problèmes [RANADIVÉ 2006, page 218].

L’outil de BAM doit permettre un « management by fact » (management par les faits) :

- Analyse causale des écarts par rapport aux objectifs,

- Puis actions correctives [DORNIER 2007].

Le tableau de bord sera consultable comme n’importe quel serveur web connecté sur le réseau

intranet de l’Entreprise. L’usage d’un navigateur internet standard évitera l’installation et le

paramétrage d’une application particulière. Il sera toutefois préférable que les utilisateurs



s’identifient avant de pouvoir accéder au tableau de bord. Des profils différents pour être as-

sociés aux noms des utilisateurs, afin de présenter à chacun le tableau de bord adéquat.

Des statistiques de consultation de ce tableau de bord de BAM devront être collectées auto-

matiquement, comme pour tout serveur web, afin de s’assurer qu’il est vraiment utilisé (avec

la liste des utilisateurs qui se sont connectés, dans la mesure du possible).

Enfin, selon [GARIMELLA 2008, page 34] : « Le BAM offre aux responsables de processus

une visibilité inégalée sur les évènements et les conditions d'exécution en temps réel. »

6.4.5 Les obstacles rencontrésLe paradigme du Zéro Code (codeless) semble être un mythe, notamment dès qu’il s’agit

d’interfacer un système BPM avec des applications existantes. En effet, le développement de

Web Services (décrits par leurs fichiers WSDL) est nécessaire. Bien qu’un Web Service soit

normalement indépendant d’un langage de programmation, l’usage est actuellement de déve-

lopper avec un langage Microsoft (.NET) ou un langage plus standard comme Java.



Chapitre 7.La critique de la démarche et des résultats

7.1 L’alignement sur le Métier7.1.1 Pilotage opérationnel (à chaud)

Le pilotage opérationnel, à partir des indicateurs fournis par le BAM en temps réel, permet de

réagir aussitôt « à chaud » en cas de dysfonctionnement (real-time feedback), afin de prendre

les actions correctives qui s’imposent pour revenir dans la normalité au plus vite. Il est désor-

mais possible de prendre rapidement des décisions quelques minutes après la survenance des

problèmes, sans attendre que ceux-ci soient signalés, par les clients le plus souvent…

7.1.2 Pilotage tactique (à froid)Le pilotage tactique « à froid » et le pilotage opérationnel « à chaud » ne sont pas opposables,

mais au contraire tout à fait complémentaires. Le pilotage tactique, avec du recul sur le pilo-

tage opérationnel, permet sereinement d’analyser puis d’optimiser les processus logistiques.

Cela peut se faire généralement sur deux axes : soit on modifie les processus, soit on répartit

mieux les ressources, afin de diminuer les temps d’exécution des tâches, surtout celles situées

sur le chemin critique (« Le temps, c’est de l’argent. » selon le vieil adage populaire).

7.1.3 Alignement stratégiqueLe BAM, par le pilotage des opérations, permet surtout d’agir sur les opérations et la tactique.

Néanmoins, c’est bien la tactique qui permet d’aligner l’entreprise avec le positionnement tel

qu’il est défini, ou au moins souhaité, par la stratégie du Comité de Direction. On peut égale-

ment parler de Gouvernance. Voici un tableau récapitulatif des trois différents types de pilo-

tage (page suivante ) :



Figure 19 : Pilotages opérationnel, tactique et stratégique (IDS Scheer)



7.2 Tableaux de bordAfin d’assurer les pilotages opérationnel, tactique et l’alignement stratégique, le tableau de

bord devra si possible être présenté selon 3 perspectives différentes (en fait 3 tableaux de bord

différents, qui s’appuient toutefois sur les mêmes données). Le BAM couvre essentiellement

les pilotages opérationnel et tactique. Comme indiqué précédemment, il « suffit » de fournir

les bonnes informations aux bonnes personnes aux bons moments !

Quelquefois, les tableaux de bord du BAM sont appelés EPM dashboards (Enterprise Perfor-

mance Management) : cela confirme bien que ces tableaux de bord doivent présenter des indi-

cateurs qui reflètent la performance de l’Entreprise.

Certains tableaux de bord présentent quelquefois une vision technique ; dans le cadre du

BAM, ils devront présenter clairement une vision métier. Ils devront présenter un aspect sym-

pathique à leurs utilisateurs (user-friendly) [ECKERSON 2005, page 117).

Les bonnes personnes doivent être habilitées à recevoir les bonnes informations. Le problème

d’authentification des utilisateurs accédant au tableau de bord, qui est commun aux autres ap-

plications informatiques, n’est pas développé dans cette thèse. Notons simplement qu’un pro-

fil peut être rattaché à un utilisateur, afin de lui présenter automatiquement la perspective du

tableau de bord qui lui convient.

On préfèrera des tableaux de bord simples et concis, tenant sur un seul (grand) écran, et ne

contenant que des informations pertinentes. Ces tableaux de bord présenteront des indicateurs

de performance en provenance de différentes sources (concaténation de plusieurs éléments

souvent hétérogènes). Dans un élan philosophique, on pourrait dire que le tableau de bord

idéal devrait représenter une vision unique de la Vérité, avec un V majuscule (sic).

En plus des trois tableaux de bord permettant les pilotages opérationnel, tactique et l’aligne-

ment stratégique, on peut également envisager un quatrième tableau de bord pour les clients

externes (les clients internes utilisant le tableau de bord opérationnel). Toutefois, cela pose un

problème de sécurité d’accès au système d’information de l’entreprise, nécessitant générale-

ment la mise en place d’un serveur de type Extranet en zone démilitarisée (DMZ). Malgré

cette contrainte technique (qui est loin d’être insurmontable), l’externalisation du tableau de

bord du BAM peut contribuer à l’amélioration de la satisfaction Client.



7.3 Importance des processus clés7.3.1 Identification des processus clés

Le Client est Roi. Nul ne déroge à cette règle. Ainsi, les processus impliquant les clients, no-

tamment ceux qui sont encadrés par un engagement de niveau de service (SLA), seront présé-

lectionnés en priorité.

Il faut collecter les besoins des intervenants, puis analyser les enjeux, les risques et les im-

pacts notamment financiers des processus, afin de choisir intelligemment ceux qui seront mis

sous contrôle. Les processus qui présentent des enjeux importants et/ou des risques élevés et/

ou des impacts significatifs seront identifiés comme processus clés.

7.3.2 Mise sous contrôle des processus clésPour assurer le succès d’un projet de BAM, il faut absolument éviter de vouloir dès le départ

mettre sous contrôle tous les processus. Seuls les processus clés tels que définis précédem-

ment seront mis sous contrôle. Il faut choisir pour chaque processus clé, si son pilotage doit

être opérationnel, tactique ou les deux.

7.4 Entreprise temps réel7.4.1 Vers l'Excellence opérationnelle

On pourrait définir l’Excellence par l’aboutissement de la tactique visant à atteindre l’efficaci-

té opérationnelle (l’organisation la plus performante possible ; le moins de dysfonctionne-

ments possible) et l’augmentation de l’efficience (le plus de rentabilité possible, grâce à l’op-

timisation, suite à l’analyse de l’exécution réelle des processus). Ainsi [GARIMELLA 2008,

page 45] confirme : « Les outils de BAM permettent à l'utilisateur de visualiser à haut niveau

un processus en cours d'exécution, avec des indications claires des chemins critiques et des

goulots d'étranglement. » Tout cela est possible grâce aux indicateurs en temps réel.

7.4.2 Un avantage compétitifUn module de BAM est bien entendu un avantage compétitif pour les éditeurs de solutions

BPMS (bien que de plus en plus courant et donc de moins en moins discriminant). Il en va de

même pour les entreprises utilisatrices de ces modules de BAM, qui conservent ainsi un

temps d’avance sur leurs concurrents.



Chapitre 8.Conclusion

8.1 Rappel des objectifs de départL'objectif principal de départ était le suivant :

- Mettre en place le Business Activity Monitoring (BAM) pour piloter

les processus logistiques.

Cet objectif principal a ensuite été décliné en plusieurs sous-objectifs, qui sont en fait les prin-

cipales fonctionnalités que devrait offrir la solution de BAM idéale. Cette contribution néces-

saire et importante pourra servir ultérieurement à rédiger un cahier des charges.

8.2 Travail réaliséLa mise en place de BAM n’a pas encore été faite chez DHL France, ni d’ailleurs aucune

autre nouvelle application visant à moderniser et améliorer le Système d’Information, qui n’a

bénéficié d’aucun investissement logiciel depuis plusieurs années. Cette thèse, bien que basée

sur l’expression des besoins d’un secteur d’activité professionnelle précis (la logistique), reste

donc conceptuelle et les bénéfices attendus sont théoriques.

La dimension technique, bien que présentée dans ses grandes lignes, a été volontairement peu

développée. Le paradigme du Zéro Code n’est valable qu’à partir du moment où les données

nécessaires au BPM puis au BAM sont exposées par des Web Services, ce qui n’est pas en-

core le cas ici.

L’accent a par conséquent été mis sur la dimension managériale du BAM, qui n’est pas celle

développée dans les rares livres blancs sur le BAM (voir chapitre Bibliographie plus bas).

Cette dimension managériale est avantageusement plus « transverse » que la dimension tech-

nique, c'est-à-dire qu’elle peut être transposée facilement à d’autres secteurs d’activités et à

d’autres entreprises, dotées d’infrastructures techniques différentes.

La méthode BAM Matrix™ de Systar a également été appliquée pour valider ou non le choix

d’un processus métier candidat. Le travail réalisé n’est pas restitué complètement dans cette

thèse, car cette méthode est protégée. Seuls l’objectif, les principes et résultat ont été restitués.



8.3 SynthèseNous avons vu que les processus métiers en général, les processus logistiques chez DHL en

particulier, constituent le savoir-faire et donc la richesse des entreprises. La façon dont elles

gèrent ces processus métiers est souvent représentative de leur maturité. Pourtant, les outils

informatiques actuellement à leur disposition ne permettent qu’une supervision technique

orientée vers le traitement des incidents.

Cette supervision technique notifie ces incidents, sans qu’il soit malheureusement possible de

les rattacher à un processus métier précis. Elle s’occupe, en outre, essentiellement des sys-

tèmes (machines et programmes). Mais surtout, elle ne fournit aucune mesure concernant

l’exécution des processus sans incidents, ce qui freine toute tentative d’optimisation et em-

pêche d’obtenir une vision globale de la performance d’une entreprise.

Le BAM (Business Activity Monitoring), acronyme crée par Gartner en 2003, définit le

concept d’accès, en temps réel, à des indicateurs de performance permettant d’augmenter la

rapidité et l’efficacité des opérations. Cela reste aujourd’hui un concept relativement nova-

teur, encore peu appliqué dans les entreprises françaises, mais qui est promis à un bel avenir.

De nombreux éditeurs de logiciel proposent déjà des solutions.

Un positionnement précis du BAM par rapport à d’autres concepts similaires s’est avéré né-

cessaire. Ainsi, le BAM est proche du concept de BSM (Business Service Management) no-

tamment, lorsqu’il s’agit d’améliorer la supervision technique en la rattachant aux processus

métiers (approche pragmatique Bottom-Up).

Avec une approche analytique et conceptuelle Top-Down, le BPM (Business Process Mana-

gement) permet de faire « vivre » les processus métiers préalablement modélisés (bien que le

terme officiel soit « exécuter les processus » !). Cette approche permet également de prendre

en compte, dès le début, le besoin de mesurer ces processus métiers pour calculer les indica-

teurs de performance. La modélisation des processus simplifie en outre leur optimisation ulté-

rieure. Cette approche est, à notre avis, la plus adaptée pour le BAM.

Le BAM est également proche de la BI (Business Intelligence). Nous avons vu que ces deux

concepts sont plus complémentaires que concurrents. En effet, la corrélation des données en

temps réel, récoltées par le BAM, avec les données historiques, entreposées par la BI, permet

de calculer des tendances et ainsi de prédire, voire d’éviter des incidents.



Parmi tous les processus métiers, certains profiteront plus du BAM que d’autres. Nous avons

démontré que la BAM Matrix™ de Systar propose un cadre méthodologique qui permet de

choisir les processus candidats, en les positionnant les uns par rapport aux autres.

Puis nous avons donné les principaux critères qui permettent de choisir et de valider les indi-

cateurs de performance. Le besoin a également été exprimé d’indicateurs d’activité, plus

simples mais néanmoins utiles : il s’agit d’indiquer l’activité d’une entreprise ou d’un service,

sans notion d’efficacité ou de performance.

Les différentes possibilités pour mesurer ces indicateurs ont été étudiées. Plutôt que d’effec-

tuer des mesures réparties à plusieurs endroits du Système d’Information, ce qui nécessiterait

des sondes intrusives ou des modifications des applications existantes, l’avantage d’utiliser,

comme source d’informations unique, les fichiers échangés au niveau d’une plate-forme cen-

tralisée a été démontré. En effet, cette plate-forme voit déjà transiter les flux externes échan-

gés avec les partenaires (EDI : Echanges de Données Informatisés) et les flux internes entre

les différentes applications (EAI : Enterprise Application Integration).

L’intérêt de la modélisation des processus métiers, s’appuyant sur une théorie pertinente (Pi-

Calculus) et utilisant une notation standard (BPMN : Business Process Modeling Notation) a

été abordé. Les principales méthodes applicables au BPM (Business Process Management)

ont été exposées, ainsi que les deux techniques essentielles pour le mettre en œuvre : l’Archi-

tecture Orientée Services (SOA) et les Web Services.

Les bénéfices potentiellement obtenus grâce au BAM ont été présentés : prédiction des inci-

dents, prévention des risques, diminution de la non-qualité, augmentation de la productivité et

réduction des coûts. Les impacts sur les Clients, sur l’organisation et le personnel ont été pré-

sentés, l’appropriation du BAM par les utilisateurs et les obstacles rencontrés également.

Le BAM permet deux types de pilotages : un pilotage opérationnel (à chaud) pour les interve-

nants et un pilotage tactique (à froid) pour leurs managers. L’identification puis la mise sous

contrôle des processus clés permet leur alignement stratégique sur le cap fixé pour l’Entre-

prise par le Comité de Direction.

Enfin, le BAM procure un avantage concurrentiel certain, car il permet d’atteindre l’Excel-

lence opérationnelle dans l’Entreprise, pilotée désormais en temps réel grâce à lui. Le grand

intérêt du BAM a donc été démontré : il sera un outil incontournable dans le futur.



Chapitre 9.Bibliographie

9.1 Aucun ouvrage sur le BAMQue ce soit en français ou en anglais, il n’existe à notre connaissance aucun livre en papier

dédié au BAM (un marché à prendre ?). Toutefois, le BAM est cité dans plusieurs livres trai-

tant du BPM et autres activités connexes (SOA, urbanisation, etc.). On trouve aussi sur le web

quelques livres blancs (white books) sur le BAM au format numérique Acrobat PDF.

9.2 Ouvrages en langue françaiseCASEAU Yves, 2005, « Urbanisation et BPM : Le point de vue d’un DSI », Dunod

CHELLI Henri, 2003, « Urbaniser l’entreprise et son système d’information : Guide des en-

treprises agiles », Vuibert

CLUB URBA-EA, 2006, « Urbanisme des SI et Gouvernance : Retours d'expériences et

bonnes pratiques », Dunod

DORNIER Philippe-Pierre, FENDER Michel, 2007 (2e édition), « La logistique globale et le

Supply Chain Management », Editions d’Organisation

GARIMELLA Kiran, LEES Michael, WILLIAMS Bruce, 2008, « Les Bases du BPM pour

les Nuls », Edition Spéciale Software AG, Wiley Publishing

PORTER Michael, 2003, « L'avantage concurrentiel : Comment devancer ses concurrents et

maintenir son avance », Dunod

SAHILLIOGLU Gunes, 2007, « Gestion de portefeuille de projets informatiques », Hermès-

Lavoisier

SAMII, Alexandre K., 2004 (3e édition), « Stratégie Logistique ; Supply Chain Manage-

ment », Dunod



RANADIVÉ Vivek, 2006, « Le Pouvoir de Prévoir : Comment l’Entreprise temps réel anti-

cipe les besoins de clients, crée des opportunités et distance la concurrence », Maxima

YPHISE, 2006, « Supervision des activités métier (BAM) », Yphise (Volume DECIDER)

9.3 Ouvrages en langue anglaiseBURLTON Roger, 2001, « Business Process Management : Profiting from process », SAMS

ECKERSON Wayne W., 2005, « Performance Dashboards : Measuring, Monitoring, and

Managing Your Business », John Wiley & Sons

HAMMER Michael, CHAMPY James, 1993, « Reengineering the Corporation : A Manifesto

for Business Revolution », Harper Business

HAVEY Michael, 2005, « Essential Business Process Modeling », O’Reilly

LINTHICUM David S., 2003, « Next Generation Application Integration : From simple in-

formation to web services », Addison-Wesley

NEWCOMER Eric, LOMOW Greg, 2005, « Understanding SOA with Web Services », Pear-

son Education

SMITH Howard, FINGAR Peter, 2006, « Business Process Management : The Third Wave »,

Meghan Kiffer Pr

TAYLOR James, RADEN Neil, 2007, « Smart (Enough) Systems: How to Deliver Competit-

ive Advantage by Automating the Decisions Hidden in Your Business », Prentice Hall



Chapitre 10.Webographie

10.1 Ressources en langue françaiseCRUSSON Tanguy, 2004, « Business Activity Monitoring (BAM) : Maîtrise des processus

métiers End-to-end », Intalio (Livre blanc), lien valide le 02/09/2008 :

http://www.urba-ea.org/fichiers/ref/ref04061111630235.pdf

PROCESSUS METIER, Site communautaire de la Gestion des Processus, lien valide le

07/09/2008 : http://www.processus-metier.fr

MANDEL René, 2007, « Le Business Process Management (BPM) : S’orienter processus »,

Oresys (Livre blanc ; sur demande), lien valide le 02/09/2008 :

http://www.oresys.fr/publications-35.html

10.2 Ressources en langue anglaiseBAM, 2002-2005, « Business Activity Monitoring Resources », lien valide le 15/09/2008 :

http://www.businessActivitymonitoring.com/resources.htm

LOOSELY COUPLED, Glossary, « BAM », lien valide le 15/09/2008 :

http://looselycoupled.com/glossary/BAM

MALONE Robert, 2005, « BAM to the Rescue », Forbes.com, lien valide le 01/09/2008 :

http://www.forbes.com/logistics/2005/10/25/bam-logistics-tracking-cx_rm_1025bam.html

SYSTAR, « The BAM Matrix™ », Systar, lien valide le 01/09/2008 :

www.bam Matrix .com


http://www.bammatrix.com/

http://www.forbes.com/logistics/2005/10/25/bam-logistics-tracking-cx_rm_1025bam.html

http://looselycoupled.com/glossary/BAM

http://www.businessactivitymonitoring.com/resources.htm

http://www.oresys.fr/publications-35.html

http://www.processus-metier.fr/

http://www.urba-ea.org/fichiers/ref/ref04061111630235.pdf


Chapitre 11.Glossaire

11.1 Acronymes et autres siglesAPI : Application Programming InterfaceInterface pour les développeurs permettant d’accéder aux services d’une application.

BAM : Business Activity MonitoringPilotage en temps réel de la performance des processus au travers du contrôle continu des in-dicateurs clés.

BI : Business IntelligenceDésigne des applications décisionnelles capables de transformer des données en informations pertinentes pour aider à la prise de décision.

BPEL : Business Process Execution LanguageLangage de programmation XML pour la spécification des processus métiers exécutables, ap-pliqué essentiellement à l'orchestration de services Web.

BPM : Business Process Management (Gestion des processus métiers)Les méthodes, les techniques et les outils utilisés pour concevoir, déployer, exécuter, contrô-ler et analyser les processus métiers opérationnels impliquant des personnes, des systèmes, des applications, des données et des entreprises.

BPMN : Business Process Modeling Notation (Notation pour la modélisation des processus métiers)Une notation graphique standardisée pour dessiner des processus métiers dans un workflow, faciliter la communication et la portabilité des modèles de processus.

BPA : Business Process Analysis

BPMS : BPM Suite or SystemEnsemble logiciel destiné à modéliser, documenter, intégrer, exécuter et piloter les processus métiers de l’entreprise.

BPQL : Business Process Query Language

BPR : Business Process ReengineeringStratégie développée par des consultants qui se concentre sur la modification des processus métiers afin d’en augmenter l’efficacité.

BSM : Business Services ManagementSolution logicielle permettant de piloter la performance des services métiers d’une architec-ture SOA.



CEP : Complex Event Processing (Traitement des évènements complexes)Permet la corrélation des évènements, leur comparaison avec des modèles et de mettre en évi-dence leur impacts sur les objectifs de l’entreprise et sur les processus métiers afin de réagir en temps réel.

CMMI : Capability Maturity Model Integration

CPI : Continuous Process Improvement (Amélioration continue des processus)Effort incessant pour découvrir et éliminer les causes des problèmes de performance dans les processus métiers et accroître ainsi la création de valeur et la productivité.

DIFOT : Delivered In-Full and On-Time (Livré complètement et à l'heure)Mesure clé de la performance de la chaîne logistique qui mesure combien de fois les clients ont obtenu ce qu'ils voulaient au bon moment.

DMAIC (Define, Measure, Analyze, Improve, Control)Acronyme pour les cinq phases essentielles de la méthodologie Six Sigma : définir, mesurer, analyser, améliorer et contrôler. Utilisé pour résoudre des problèmes de processus et opéra-tionnels par des données et des méthodes analytiques.

DMZ : DeMilitarized Zone

DSDM : Dynamic Systems Development Method

DSI : Direction des Systèmes d’Information

EA : Enterprise Architecture

EAI : Enterprise Application Integration (Intégration d'applications d'entreprise)Solution logicielle permettant à des applications hétérogènes internes ou externes à l’entre-prise de synchroniser leurs données.

EDI : Electronic Data Interchange (Echanges de Données Informatisés)Echanges informatisés de documents standardisés par le biais de réseaux publics.

EDIFACT : Electronic Data InterchangeFor Administration, Commerce and Transportation.

EIS : Executive Information SystemUn outil de visualisation qui rend l’information relative à l’entreprise visible pour ceux qui en ont besoin.

EPM : Enterprise Performance Management

ERP : Enterprise Resource Planning

ESB : Enterprise Service BusPartie intégrante d'une infrastructure de middleware, un ESB est une architecture logicielle qui fournit aux systèmes d'informations des services fondamentaux pour l'échange de données via un bus d'échange.



ETL : Extract, Transform & LoadIl s'agit d'une technologie permettant d'effectuer des synchronisations massives d'information d'une banque de données vers une autre.

FTP : File Transfert ProtocolNorme permettant d’échanger des fichiers entre différents systèmes.

IGOE : Input Guide Output & EnablerReprésentation qui généralise le formalisme SIPOC.

ITIL : Information Technology Infrastructure Library

JDBC : Java DataBase Connectivity

JMS : Java Message Service

HTTP : HyperText Transfer ProtocolMéthode de type requête-réponse pour publier et accéder des pages sur Internet. C’est le pro-tocole le plus utilisé sur Internet (World Wide Web).

KPI : Key Performance Indicator (Indicateur de performance clé)N'importe quel ensemble de métriques financières ou non financières qui peuvent être mesu-rées pour quantifier les performances d'une activité.Par exemple, le temps de cycle d'un processus.

MDM : Master Data ManagementMéthode de traitement des données destinée à qualifier et uniformiser le mode de description des données métiers pour en garantir une bonne prise en compte.

MOA : Maitrise d’OuvrAge

MOE : Maitrise d’Œuvre

NSM : Network and Systems ManagementSystème de gestion s’assurant que le réseau est disponible pour les utilisateurs et les applica-tions, prenant en charge la notification des dysfonctionnements matériels et logiciels.

ODBC : Open DataBase Connectivity

PDCA : Plan Do Check ActRoue de Deming.

QoS : Quality of Service (Qualité de service)

ROI : Return On Investment (Retour sur investissement)

SIPOC : Suppliers Input Process Output Customers

SLA : Service Level Agreement (Engagement de niveau de service)



SLM : Service Level Management

SMS : Short Message Service

SOA : Service-Oriented Architecture (Architecture orientée service)Architecture logicielle où des fonctionnalités nouvelles et anciennes sont packagées et expo-sées sous la forme de services. L’architecture orientée services est un modèle d’interaction ap-plicative qui met en œuvre des services avec une notion de couplage lâche permettant une meilleure flexibilité du système d’information.

SOAP : Simple Object Access ProtocolProtocole léger destine à l’échange d’informations dans un environnement distribué.

SQL : Structured Query Language

SGBDR : Système de Gestion de Bases de Données RelationnellesSérie de programmes qui gèrent l’organisation et l’archivage des données, ainsi que les re-quêtes des utilisateurs.

TAM : Technical Activity Monitoring

TQM : Total Quality Management (Gestion par la qualité totale)Stratégie de gestion qui vise la prise de conscience de l'importance de la qualité par toutes les structures organisationnelles et les processus.

UML : Unified Modeling Language

VOC : Voice of the Customer (La voix du client)Représentation des besoins, des désirs, des volontés définis ou non par le destinataire du ré-sultat généré par un processus, d'un produit ou d'un service. Ces attentes sont généralement exprimées sous la forme de spécifications

WSDL : Web Service Definition LanguageLangage de développement XML pour décrire les services web sous la forme d'opérations re-présentant des documents ou des appels de procédures.

WYMIWYR : What You Model Is What You Run(Ce que vous modélisez est ce qui s'exécute)Acronyme pour désigner la manière dont un BMPS totalement intégré assemble la modélisa-tion à un environnement d'exécution.

XPDL : XML Process Definition LanguageLangage de définition basé sur XML pour permettre aux modèles de processus d'être repré-sentés de manière consistante et modifiés par des outils de modélisation de processus.

XML : eXtensible Markup LanguageReprésentation des données et des métadonnées afin qu’elles puissent être facilement parta-gées par de multiples applications et organisations.



11.2 Mots entiersBalanced ScorecardStructure pour élaborer des métriques métiers autres que les métriques financières de base gé-néralement utilisées. Concerne le client, les processus, les personnes et les informations finan-cières. Fait le lien entre les objectifs stratégiques et les métriques opérationnelles.

GouvernanceStructure ou cadre conceptuel pour la prise de décision et la responsabilité financière qui pro-duit des résultats souhaitables pour l'entreprise. La gouvernance détermine le quoi, le qui et le comment de la prise de décision dans l'entreprise.

LeanMéthodologie d'amélioration basée sur une définition de la valeur centrée sur le client, l'opti-misant le plus efficacement possible en combinant diminution des non-conformités et engage-ment des personnes.

Métriques prédictivesAlgorithmes appliqués à des ensembles d'informations portant sur les activités et les compor-tements qui servent de bases statistiquement valides pour prédire des résultats à venir.

Modèle de processusPrescription représentative de la manière dont un ensemble d'activités devraient opérer en sé-quence afin de parvenir régulièrement au résultat attendu.

Optimisation des performancesPratique consistant à procéder à des ajustements et à des changements dans des activités et des processus métier pour améliorer la performance.

Optimisation du processusPratique consistant à apporter des modifications et des ajustements à un processus pour amé-liorer son efficacité et son rendement.

OrchestrationArrangement, coordination, exécution et gestion automatisés d'applications informatiques complexes, de systèmes, d'intégration et de services.

PortailCadre logiciel qui permet aux personnes, via une interface unitaire fournie via un navigateur Web, de gérer l'information et les processus à travers les systèmes et les organisations.

ProcessusEnsemble d'activités, de matériels et/ou de flux d'informations qui transforment un ensemble de données d'entrées en données de sorties défi nies.

Propriétaire de processusIndividu qui a la responsabilité de la performance et des ressources d'un processus, et qui fournit l'assistance, les ressources et l'expertise fonctionnelle aux projets. Le propriétaire d'un processus est responsable de l'amélioration continue du processus.



Règles métiersCodification formelle des politiques et des actions métiers dans des pratiques opérationnelles prescriptives, extraites et maintenues indépendamment du code des applications.

Six SigmaEnsemble éprouvé et reconnu d'outils d'analyse, de techniques de contrôle de projet, de mé-thodes de remontée d'informations et de techniques de gestion que l'on combine pour amélio-rer les performance et la résolution de problèmes.

Supply Chain (Chaîne logistique)Ensemble de personnes, d'activités, d'informations et de ressources impliquées dans le dépla-cement de produits ou de services du fournisseur vers le client.

Tableau de bordReprésentation graphique qui indique le statut ou la santé d'une entreprise ou de processus via des indicateurs clés de performances (KPI).

Temps de cycleTemps total passé à partir de l'instant où une tâche, un produit ou un service a démarré jusqu'à ce qu'il se termine.

Transformation métierInitiative métier qui réaligne les personnes, les processus et la technologie pour générer des changements significatifs et améliorer les performances.

Visibilité métierOutils et techniques qui fournissent une visibilité en temps réel des processus et des activités métier.

Workflow (Enchaînement logique de tâches)Modélisation d'une activité métier reposant sur l'organisation systématique de ressources au sein de processus qui transforment des matériaux, fournissent des services ou traitent des in-formations.


Documents

Praxeme Institute – Meaning in actionwiki.praxeme.org/uploads/Corpus/BAM-MSIR_TBthese.doc · Web viewChiffres clés en 2005 (en France) : Pôles transport et logistique : 2 milliards