GESTION DE PROCESSUS AVEC SOA ET BPM DANS UNE PME

Université de Fribourg, Suisse

Département d'informatique

Bachelor en informatique de gestion

GESTION DE PROCESSUS AVEC SOA ET BPM

DANS UNE PME

Travail de bachelor

Matthieu Borloz

Mettlenweg 3

2504 Biel/Bienne

(Dr. Stefan Hüsemann)

Mars 2013

Introduction 1

ABSTRACT

Ce travail de bachelor en informatique de gestion va s’intéresser à la problématique de

l’intégration d’un processus automatisé entre le système d’information d’une entreprise de

type PME et la douane Suisse.

Pour être concurrentielles, les entreprises ont à gérer des interactions qui nécessitent des

échanges d’information de plus en plus riches avec des parties prenantes. Ces relations, qui

existent sous forme de processus, poussent les systèmes d’information des entreprises à

être à même de supporter une collaboration avec d’autres SI. Ce travail va s’intéresser aux

concepts SOA et BPM qui établissent des standards pour rendre possible cette

collaboration.

MOTS CLÉS

SOA, BPM, BPM Lifecycle, BPMN 2.0, BPMS, e-dec exportation, Architecture des SI, SOAP,

WSDL, processus, web services.

.

Introduction 2

TABLE DES MATIERES

1. Introduction ..................................................................................................................... 7 1.1 Problématique ......................................................................................................... 7

1.2 Questions de recherche et démarche ...................................................................... 8

1.3 Méthodologie ..........................................................................................................10

1.4 Public cible .............................................................................................................10

2 L’entreprise et le SI ........................................................................................................11 2.1 Définitions ..............................................................................................................11

2.1.1 Système d’information .....................................................................................11

2.2 Classification des SI ...............................................................................................13

2.2.1 Typologie selon le niveau de décision et vision OLAP OLTP ...........................13

2.2.2 Découpage fonctionnel d’un SI : métiers et besoins ........................................14

2.3 Architecture des SI .................................................................................................17

2.3.1 Définition .........................................................................................................17

2.3.2 Un modèle d’architecture des SI : Le modèle de référence de l’urbanisation ...17

3 SOA : Emergence d’un modèle d’architecture SI ...........................................................20 3.1 La réponse SOA .....................................................................................................20

3.1.1 Motivation et Définition de SOA .......................................................................20

3.2 Les principes conceptuels de SOA .........................................................................22

3.2.1 Orientation service ..........................................................................................22

3.2.2 Modularité et composition des services ...........................................................22

3.2.3 Réutilisabilité ...................................................................................................23

3.2.4 Couplage faible ...............................................................................................23

3.2.5 Promotion de l’Agilité .......................................................................................23

3.2.6 Valorisation des systèmes déjà existants ........................................................23

3.3 Les composants et standards de SOA ...................................................................24

3.3.1 Niveaux de service de l’architecture SOA ........................................................24

3.3.2 Utilisation des web services ............................................................................26

3.3.3 Un format pilier : XML ......................................................................................26

3.3.4 Echange de messages avec SOAP .................................................................27

3.3.5 WSDL .............................................................................................................28

Introduction 3

3.3.6 UDDI ...............................................................................................................29

3.3.7 BPEL ...............................................................................................................30

4 BPM : gérer l’organisation par les processus .................................................................31 4.1 Bases conceptuelles ..............................................................................................31

4.1.1 Définition .........................................................................................................31

4.1.2 Historique ........................................................................................................31

4.1.3 Le but du BPM : l’agilité ...................................................................................32

4.2 BPM Lifecycle ........................................................................................................33

4.2.1 Concept général ..............................................................................................33

4.2.2 La phase Goal Specification / Strategy Definition ............................................34

4.2.3 La phase Design .............................................................................................34

4.2.4 La phase Implementation ................................................................................35

4.2.5 La phase de Process Runtime ........................................................................35

4.2.6 La phase de Process Improvement .................................................................36

4.3 BPMM ....................................................................................................................37

4.3.1 Concept ...........................................................................................................37

4.3.2 Représentation des niveaux ............................................................................37

4.3.3 Niveau 1 : initial ...............................................................................................38

4.3.4 Niveau 2 : Managed ........................................................................................38

4.3.5 Niveau 3 : Standardized ..................................................................................39

4.3.6 Niveau 4 : Predictable .....................................................................................39

4.3.7 Niveau 5 : Inovating Level ...............................................................................40

4.3.8 Liens entre BPMM et le BPM Lifecycle ............................................................40

4.4 BPMN 2.0 ...............................................................................................................41

4.4.1 Avènement de BPMN 2.0 ................................................................................41

4.4.2 Principaux constituants d’un diagramme de BPMN 2.0 ...................................42

4.4.3 Exécution de BPMN 2.0 ..................................................................................45

4.5 BPMS .....................................................................................................................47

4.5.1 Principe ...........................................................................................................47

4.5.2 Comparatif des outils existants ........................................................................47

Introduction 4

5 Partie pratique : Application du BPM Lifecycle dans une PME .......................................50 5.1 BPM Lifecycle Phase 1 : Goal specification / Strategy definition.............................50

5.1.1 Business Case ................................................................................................50

5.1.2 Specification du but .........................................................................................53

5.1.3 Alignement stratégique ....................................................................................54

5.2 BPM Phase 2 : Process Design..............................................................................55

5.2.1 Description du processus d’export du point de vue de l’entreprise ..................55

5.2.2 Description du processus d’export du point de vue de la douane suisse .........56

5.2.3 Web service e-dec ..........................................................................................57

5.2.4 e-dec web .......................................................................................................58

5.2.5 Processus d’export entre l’ERP, le BPMS et e-dec .........................................58

5.3 BPM Phase 3 : Implementation ..............................................................................62

5.3.1 Création des interfaces de vérification des données issues de l’ERP ..............62

5.3.2 Mise en fonction du mock service e-dec avec SOAP UI ..................................62

5.3.3 Configuration du webservice dans Bonita ........................................................64

5.3.4 Réponse du web service .................................................................................67

5.3.5 Intégration des résultats dans le BPMS ...........................................................67

5.4 BPM Phase 4 : Process Runtime ...........................................................................69

5.4.1 Utilisation de la User XP ..................................................................................69

5.4.2 Contrôle et saisie des données par l’utilisateur ................................................69

5.5 Phase 5 : Process Improvement.............................................................................71

5.5.1 Envoi des données par l’ERP ..........................................................................71

5.5.2 Utilisation de fichiers XML dans le BPMS ........................................................71

5.5.3 Gestion des réponses de déclaration par le BPMS .........................................72

5.5.4 Définition des rôles autour du processus dans la perspective d’une

implémentation ..............................................................................................................73

5.5.5 Gestion des ressources ...................................................................................73

6 Conclusion .....................................................................................................................74 7 Bibliographie ..................................................................................................................76 8 Annexes .........................................................................................................................79

8.1 Annexe 1 : Prototype d’implémentation dans BonitaSoft ........................................79

8.2 Annexe 2 : Documents issus du service e-dec .......................................................79

Introduction 5

LISTE DES FIGURES

Figure 1 : Fonctionnement générique d’un système ............................................................................. 11

Figure 2 : Décomposition en sous-systèmes ........................................................................................ 12

Figure 3: Niveau décisionnels ............................................................................................................... 13

Figure 4 : OLTP vs OLAP (Zaiaine, 2013) ............................................................................................ 14

Figure 5: Découpage fonctionnel (CSB, 2013)...................................................................................... 15

Figure 6: Modele de l'urbanisation (Jozwiak, 2013) .............................................................................. 18

Figure 7: Avant et après SOA (www.tridens.si, 2011) ........................................................................... 21

Figure 8: Couches SOA (Erl, 2005) ....................................................................................................... 24

Figure 9: XML Schema avec fichier XML (Wikipedia, 2012) ................................................................. 27

Figure 10: Requête et reponse SOAP simple (Quaine, 2012) .............................................................. 28

Figure 11: Fonction de WSDL (Haas, 2012) ......................................................................................... 28

Figure 12: Forme d'un document WSDL (IBM, 2012) ........................................................................... 29

Figure 13: Implémentation de UDDI (Krawler, 2009) ............................................................................ 29

Figure 14: BPM Lifecycle ....................................................................................................................... 33

Figure 15: Niveaux du BPMM ................................................................................................................ 38

Figure 16: Avant et après BPMN 2.0 ..................................................................................................... 42

Figure 17: Types d'évènement BPMN 2.0............................................................................................. 43

Figure 18: Tâches BPMN 2.0 ................................................................................................................ 43

Figure 19: Branchements BPMN 2.0 ..................................................................................................... 44

Figure 20: Pools et Lanes BPMN 2.0 .................................................................................................... 45

Figure 21: Tableau comparatif des outils BPMS en accès libre ............................................................ 48

Figure 22: Canaux de distribution et imputation de la marge sur prix de vente final ............................ 51

Figure 23: Incoterms .............................................................................................................................. 52

Figure 24: Processus de commande dans l'ERP .................................................................................. 55

Figure 25: Procédure d'export actuelle chez Hans Werk ...................................................................... 56

Figure 26: Fonctionnement de e-dec export du point de vue de la douane .......................................... 57

Figure 27: Portail e-dec web (e-dec, 2013) ........................................................................................... 58

Figure 28 : Processus d’export avec ERP, BPMS et e-dec .................................................................. 59

Figure 29 : Facture ERP ........................................................................................................................ 60

Figure 30: Configuration de SOAP ui avec fichier WSDL ..................................................................... 63

Figure 31: interface SOAP UI ................................................................................................................ 64

Figure 32: Interface connecteur service web de bonita ........................................................................ 65

Figure 33: Definitions du fichier e-dec WSDL ....................................................................................... 66

Figure 34: Déclaration en format XML .................................................................................................. 67

Figure 35: Configuration du retour des données dans Bonita ............................................................... 68

Figure 36: User Experience Bonita........................................................................................................ 69

Figure 37: Formulaire de saisie et de contrôle des données ................................................................ 70

Figure 38: Interface de connexion web service payante de bonita (BonitaSoft, 2011) ......................... 72

Introduction 6

Introduction 7

1. INTRODUCTION

1.1 Problématique

L’implémentation d’un processus avec le concept de BPM (Business Process Management)

entre l’administration des douanes et une PME (Petites et Moyennes Entreprises) va être le

sujet de ce travail. Le processus dont il sera question consiste en la déclaration pour l’export

de marchandise qui est exigé par toute exportation de marchandise depuis la Suisse. Ce

processus verra l’ERP (Entreprise Ressource Planning) de l’entreprise collaborer avec e-

dec, la plateforme de déclaration de douane de la Confédération suisse.

Exporter des marchandises depuis la Suisse n’est de loin pas une sinécure. Les processus

administratifs nécessaires aux opérations de douane représentent une charge de travail

importante. L’entreprise exportatrice devra disposer d’un important savoir-faire dans son

organisation qui sera à même d’exécuter des tâches administratives spécialisées pour

lesquelles les erreurs sont proscrites. Cette compétence occasionnera des coûts qui se

répercuteront inévitablement sur le prix du produit ainsi qu’un temps de traitement qui aura

une influence sur le délai de livraison du produit. Le prix et la disponibilité du produit étant

des éléments clés de la compétitivité d’une entreprise, ces démarches ont, du point de vue

de l’entreprise, tout intérêt à être optimisées.

Consciente de l’impact de ces tâches administratives pour ses déclarants et soucieuse d’un

mode de gestion efficace, la douane suisse a mis sur pied un système de type SOA (Service

Oriented Architecture) nommé e-dec qui permet de réaliser les déclarations de douane

(export et import) en ligne et gratuitement.

Mais l’utilisation de ce service semble pour le moment surtout privilégiée par de grandes

entités à même de développer des solutions informatiques à l’interne et par des entreprises

spécialisées dans la logistique, offrant un service d’export facturé à leurs clients. Or si le

modèle d’affaire de l’entreprise exige de nombreux envois et par conséquent de nombreuses

déclarations, les frais engendrés par ceux-ci deviendront importants et il pourrait être

pertinent que l’entreprise réalise elle-même ces déclarations avec le concours de son SI.

Afin de s’assurer d’un traitement optimal et d’éviter une saisie manuelle des données qui

serait à la fois source d’erreurs et de coûts, l’entreprise aura tout intérêt à interfacer son

propre système et ainsi à faire transiter les données entre les deux systèmes de manière

automatique. Or la plupart des entreprises exportatrices sont des PME. Celles-ci comptent

généralement sur un système de type ERP dont les possibilités de configuration sont

limitées.

Introduction 8

La problématique de ce travail sera d’évaluer comment il est possible par le biais de BPM de

faire collaborer un système de type SOA et un ERP pour réaliser le processus de déclaration

de marchandises exigé par la loi. Afin de répondre à cette problématique, il sera

premièrement question d’explorer et d’expliciter les concepts théoriques inhérents à SOA et

BPM pour disposer des bases conceptuelles nécessaires à la mise sur pied d’une approche

processus avec des SI pour cible. Ensuite, l’intégration même du processus sera abordée en

utilisant les concepts définis dans la partie théorique.

1.2 Questions de recherche et démarche

Ce travail s’intéressera dans un premier temps au concept général d’architecture des SI et la

place que SOA occupe dans celle-ci. Pour cela, les questions de recherche suivantes seront

traitées :

Pourquoi un SI est-il un élément essentiel d’une entreprise et, particulièrement, de sa

stratégie ?

Pourquoi le concept d’architecture des SI a-t-il émergé comme une nécessité ?

En quoi SOA est-elle une architecture de référence à ce jour et quels sont ses

principes de fonctionnement ?

La démarche pour traiter ces trois premières questions sera de d’abord comprendre le lien

fondateur entre les systèmes d’information et l’entreprise. Cette première question permettra

alors de comprendre la nécessité d’un recours au niveau d’abstraction qu’est l’architecture

des SI. Suite à cela, un type particulier d’architecture, SOA, sera exposé en détail. L’objectif

sera de partir de la notion de SI au sens le plus générique et d’offrir au lecteur des clés de

compréhension pour appréhender les problèmes d’architecture des SI et les solutions

offertes par l’industrie informatique.

Après s’être intéressé au fonctionnement technique des SI, ce travail va opérer un

changement de perspective en mettant le focus sur l’organisation et ses processus par le

biais des concepts et outils du BPM. Ces derniers seront abordés avec les questions de

recherche suivantes :

Qu’est-ce que BPM, pourquoi l’utiliser ?

Comment le BPM Lifecycle permet-il à l’entreprise de gérer ses processus et de les

améliorer ?

Comment le niveau de sensibilité d’une organisation aux processus peut-il être

évalué et amélioré ?

Quelles bases conceptuelles et technologiques rendent possible l’exécution de

Business Process sur une SOA ?

Introduction 9

Quel outil BPMS open source ou en accès libre est-il le plus à même de permettre

une modélisation et une exécution de processus ?

La démarche consistera ici à présenter quelles approches managériales ont permis la

naissance de BPM et sa reconnaissance comme une pratique utile pour les organisations.

La méthodologie du BPM Lifecycle servira à présenter les différentes phases relatives à la

gestion des processus. Des normes utilisées dans le cadre de cette démarche seront

également traitées. La présentation de celles-ci permettra notamment d’expliciter le lien

entre SOA et BPM et ainsi de pouvoir évaluer des solutions logicielles BPMS.

Suite à cette approche théorique de BPM et SOA, il sera question de mettre en pratique

cette implémentation avec le cas d’un processus concret d’exportation de marchandises. Les

questions de recherche suivantes seront alors traitées :

Quels sont les besoins qui vont nécessiter une approche processus au sein de la

PME et comment le web service e-dec pourra-t-il y participer ?

Quelle forme prendra la modélisation de ce processus avec le standard BPMN 2.0 ?

Quelles tâches de configuration seront nécessaires depuis la modélisation pour

réaliser l’exécution et les phases suivantes du BPM Lifecycle ?

La partie pratique s’intéressera dans un premier temps au contexte particulier d’une

entreprise active dans l’industrie horlogère et aux besoins qui motivent une approche

processus. Une fois cela défini, il sera possible de modéliser le processus d’export avec

BPMN 2.0. Cette modélisation amènera à l’implémentation d’un prototype de processus dont

les résultats et la description des limitations serviront à une prochaine itération du BPM

Lifecycle qui aura pour objectif une implémentation fonctionnelle. Ces tâches seront

réalisées avec le concours de la solution BPMS préalablement retenue.

Introduction 10

1.3 Méthodologie

Les questions de recherche de la partie théorique seront traitées de manière scientifique en

faisant référence à de la littérature spécialisée, à des sources académiques et des sites

internet de référence. Les concepts seront illustrés à l’aide de figures qui seront soit issues

des sources, soit réalisées dans le cadre du travail. La partie pratique sera l’occasion de

vérifier les hypothèses retenues et formulées dans la partie théorique. La partie pratique sera

illustrée par des diagrammes de modélisations et des copies d’écran des interfaces de

configuration. Ces illustrations permettront au lecteur de se figurer de manière visuelle les

enjeux liés au passage de la théorie au concret.

1.4 Public cible

Ce travail a été écrit avec la volonté de s’adresser aux personnes pour qui les thèmes de

SOA et de BPM représentent une thématique générale de questionnement et qui aimeraient

disposer de la base théorique nécessaire pour implémenter dans une organisation de type

PME une approche processus par le biais du BPM Lifecycle.

Ce travail part d’une approche fondamentale des SI. De la sorte, il permettra au décideur de

PME qui n’est pas spécialiste des problèmes d’architecture des SI de pouvoir les

appréhender sans grands prérequis. Il lui servira ensuite à formuler son opinion sur

l’éventuel recours aux concepts de SOA et de BPM dans son organisation.

L’entreprise et le SI 11

2 L’ENTREPRISE ET LE SI

Sous ce point, la question de recherche suivante sera abordée : « pourquoi un SI est-il un

élément essentiel d’une entreprise et particulièrement, de sa stratégie ? ». Afin de répondre

à cette question une définition des concepts fondamentaux y sera proposée. Celle-ci servira

de base pour s’intéresser aux types que peuvent prendre les SI dans une entreprise. Ces

typologies vont amener à traiter la seconde question de recherche, s’interrogeant sur

« pourquoi le concept d’architecture des SI a-t-il émergé comme une nécessité ? ».

2.1 Définitions

2.1.1 SYSTÈME D’INFORMATION

Pour définir un système d’information, il convient d’abord de s’intéresser à la notion de

système. On peut définir un système comme étant un « ensemble d'éléments considérés

dans leurs relations à l'intérieur d'un tout fonctionnant de manière unitaire » (Larousse,

2012). Le fonctionnement d’un système implique des flux qui sont des inputs et des outputs.

Les premiers rentrent dans le système et sont traités par celui-ci. Les seconds ressortent du

système et sont la conséquence du traitement de celui-ci. Ce fonctionnement est illustré à la

Figure 1.

FIGURE 1 : FONCTIONNEMENT GÉNÉRIQUE D’UN SYSTÈME

Cette approche est dite celle de la boîte noire, soit une approche où l’on s’intéresse

uniquement aux liens entre les systèmes. Or il est aussi possible de considérer qu’un

système se décompose en sous-systèmes qui vont s’occuper du traitement de l’information.

Cette vision est appelée boite blanche. Elle est illustrée par la Figure 2 ci-dessous.


¨

FIGURE 2 : DÉCOMPOSITION EN SOUS-SYSTÈMES

Il est à noter que les liens entre les systèmes, soit les flèches à deux pointes qui relient

chaque sous-système sont ici notées comme de possibles interactions. Il serait aussi

envisageable que les différents sous-systèmes disposent d’un type d’organisation qui soit

basé sur un nouveau découpage en sous-systèmes, voire en séquence, comme ce sera le

cas pour un processus.

Le type de système auquel va s’intéresser ce travail sera les systèmes dont les inputs et les

outputs seront de l’information. La notion d’information telle qu’elle est présente dans ce

contexte est tout aussi générique que celle de système. On peut définir l’information comme

étant « un élément de connaissance susceptible d'être représenté à l'aide de conventions

pour être conservé, traité ou communiqué » (Larousse, 2012).

Pour définir un système d’information (SI) la définition suivante sera retenue pour ce travail :

«Un Système d’Information (SI) est un ensemble de composantes interreliées qui recueillent

ou récupèrent de l’information, la traitent, la stockent et la diffusent afin d’aider à la prise de

décision, à la coordination et au contrôle au sein d’une organisation » (Laudon, 2010)

Il faut encore opérer une distinction entre un système d’information et un système

informatique. Le premier regroupe tout ce qui a trait à de l’information dans l’entreprise

tandis que le second concerne l’infrastructure technique qui va permettre de traiter cette

information.


2.2 Classification des SI

Après avoir vu des définitions concernant les SI de nature relativement abstraite, il faut

maintenant s’intéresser à la forme que peuvent prendre les SI dans la réalité. Pour cela, une

approche présentant des typologies vues dans le cours Systèmes d’Informations

(Hüsemann, 2012) a été retenue dans ce travail.

2.2.1 TYPOLOGIE SELON LE NIVEAU DE DÉCISION ET VISION OLAP OLTP

On reconnaît dans le management trois niveaux décisionnels qui sont illustrés à la Figure 3.

Le but du niveau de décision stratégique est de faire en sorte que l’entreprise soit à même

de réussir ses objectifs sur une perspective de long terme. Le niveau tactique s’intéresse à la

mise en œuvre de ressources sur une échelle temporelle moins étendue que celle du niveau

stratégique, alors que le niveau opérationnel concerne toutes les décisions qui permettent le

fonctionnement à court terme de l’organisation.

FIGURE 3: NIVEAU DÉCISIONNELS

Chaque niveau décisionnel possède des exigences et des besoins en information différents.

Ces besoins influencent directement la structuration des SI. Alors que les besoins en

informations du niveau stratégique vont tendre vers la consultation de données agrégées,

ceux du niveau opérationnel vont privilégier la disponibilité et la vitesse de traitement. Ces

deux besoins vont nécessiter la mise sur pied de systèmes de constitutions différentes.

Les deux grandes orientations données ici, amènent à la classification qui distingue OLAP

(OnLine Analytical Process) et OLTP (OnLine Transactional Process). Cette typologie est

illustrée à la Figure 4 ci-dessous.

Niveau stratégique

Niveau tactique

Niveau opérationnel


FIGURE 4 : OLTP VS OLAP (ZAIAINE, 2013)

On remarque dans ce tableau que les exigences ne sont pas les mêmes pour ces deux

systèmes. Dans le cas de l’OLTP, le défi est de proposer une disponibilité à une multitude

d’utilisateurs et un temps de réponse qui soit le plus bref possible afin de permettre à

l’activité de l’entreprise d’être soutenue le mieux possible par les SI. Dans le cas de l’OLAP,

c’est la quantité de données, sa consultation et sa qualité à soutenir le processus d’aide à la

décision qui est primordiale.

Cette typologie permet de comprendre qu’une même organisation peut avoir besoin de

systèmes qui sont d’une conception différente, car les besoins en information divergent selon

le niveau décisionnel. Cette hétérogénéité représente un important défi technique qui devra

être traité par la discipline de l’architecture des SI présentée au point 2.3.

2.2.2 DÉCOUPAGE FONCTIONNEL D’UN SI : MÉTIERS ET BESOINS

Le SI d’une entreprise est en général composé d’applications qui permettent un traitement

spécifique de l’information, selon les besoins inhérents à un secteur d’activité de l’entreprise.

Ce secteur d’activité et de compétence est nommé métier. Une application en charge de la

comptabilité va ainsi être conçue pour respecter les règles comptables, tandis qu’une

application visant à la production aura des règles et une implémentation propre à son

domaine. Cette approche permet de réaliser un découpage fonctionnel du SI de l’entreprise,

c’est-à-dire de classifier le SI de l’entreprise selon la nature fonctionnelle des applications.

Cette démarche est illustrée à la Figure 5. Celle-ci reprend le concept de niveau décisionnel

présent à la Figure 3 et procède à une division du spectre décisionnel selon les grandes

fonctions de l’entreprise.


FIGURE 5: DÉCOUPAGE FONCTIONNEL (CSB, 2013)

Si cette typologie permet de comprendre les besoins hétérogènes en SI en fonction des

activités d’une entreprise, elle laisse des questions ouvertes. Premièrement, le découpage ici

présenté ne tient pas compte qu’une même information peut être utilisée par plusieurs

fonctions de l’entreprise. En effet, si l’on prend l’exemple d’une personne qui est recrutée

dans une entreprise, le processus qui va amener à lui verser un certain salaire va concerner

autant les ressources humaines, que la finance et la comptabilité. C’est ce type de

problèmes qui a fait naître les solutions de types intégrées nommées ERP (Enterprise

Ressource Planning). Ces solutions ont pour avantage de faire partager la même base de

données à toutes les fonctions de l’entreprise intégrées dans l’ERP. Elles permettent ainsi un

partage d’une source unique d’information qui permet des transactions à travers les métiers.

Mais le découpage fonctionnel, même lorsqu’il est soutenu par un ERP, pose encore un

autre problème. Dans la pratique, les business process d’une entreprise sont généralement

amenés à changer sans cesse. Or les solutions informatiques et notamment les ERP ont été

conçues pour les besoins d’une organisation à un moment donné. L’éditeur de la solution

logicielle va certes proposer de nouvelles versions, mais celles-ci ne seront pas à même de

couvrir adéquatement les besoins des organisations. Il faudra alors recourir à des

développements spécifiques. Dans ce cas de figure le découpage par fonction des activités

de l’entreprise et de sa prise en charge peut servir de problème fondateur auquel ce travail

va apporter des solutions conceptuelles par les biais de SOA au point 3 et de BPM au point

4.

Les deux typologies ici présentées sont des concepts qui peuvent se comprendre de

manière complémentaire : la première permet d’expliciter un axe vertical qui est lié à la


hiérarchie des organisations, tandis que la seconde pratique un découpage horizontal du

spectre des fonctions de l’entreprise. Ensemble, elles permettent de comprendre que les SI

et l’organisation possèdent un rapport de dépendance réciproque. C’est-à-dire que les SI

doivent le plus possible être à même de soutenir l’organisation et ses processus,

l’organisation doit quant à elle intégrer les SI dans sa stratégie si elle entend avoir du

succès. Afin que cela soit possible, il faudra gérer la structuration des SI par une discipline

particulière : l’architecture des SI qui est présentée au point 2.3.


2.3 Architecture des SI

2.3.1 DÉFINITION

L’architecture des SI peut être définie comme une démarche visant à « décrire la

structuration d’un système informatique en terme de composants, d’organisation et de

fonctions » (Hüsemann, 2012). Il s’agit d’une discipline qui a pour objectif de permettre que

l’interdépendance entre SI et organisation vue au point 2.2.2, amène à un alignement des SI

sur la stratégie de l’entreprise. Cela tant en considérant les besoins qui émanent de la

stratégie, qu’en permettant à l’organisation de pouvoir intégrer de nouvelles technologiques

qui lui soient profitables.

L’architecture des SI représente une discipline à part entière de l’informatique qui est à

même de par ses décisions d’influencer en totalité l’organisation d’une entreprise. Cette

thèse peut être illustrée par l’idée que « ce qu’une entreprise fera d’ici 2 ou 3 ans, c’est ce

que son système d’information sera capable de faire » (Laudon, 2010).

L’architecture des SI a recours à des modèles pour décrire la structuration des SI. Le point

suivant décrira un des modèles fondateurs de la discipline appelé Le modèle de référence de

l’urbanisation (Longépé, 2004). Ce modèle a été retenu dans ce travail car il a pour qualité

de représenter les SI et la problématique de l’architecture SI de manière exhaustive en

utilisant l’allégorie de la ville.

2.3.2 UN MODÈLE D’ARCHITECTURE DES SI : LE MODÈLE DE RÉFÉRENCE DE

L’URBANISATION

Le modèle de référence de l’urbanisation est issu de la théorie de l’urbanisation qui compare

la problématique de l’organisation d’un SI à celle de l’organisation d’une ville, soit le

problème traité par l’urbanisation au sens littéral du terme. Le SI - tout comme la ville - est

susceptible d’héberger des services. La ville propose par exemple un service de construction

d’infrastructures, un service de transport et service un de sécurité. Ceux-ci sont rendus

disponibles par celui qui gère la ville à l’utilisateur et organisés en couches qui se cumulent.

En reprenant cette forme, le modèle de l’urbanisation propose une vision de l’architecture

informatique en 4 couches distinctes. Il est représenté sur la Figure 6. Né dans les années

1990 suite à une prise de conscience du développement chaotique de celui-ci, ce modèle

développe une vision en couches de l’architecture informatique qui offre une vision holistique

du problème architectural, notamment en y intégrant une couche technique, absente de

SOA.


FIGURE 6: MODELE DE L'URBANISATION (JOZWIAK, 2013)

La vue métier

La vue métier est la partie qui concerne les utilisateurs du système. Elle « recense les

événements métiers que l’entreprise doit traiter, les processus métiers répondants à ces

événements, les documents utilisés dans les processus, en consultant/élaborant les

documents » (Fournier-Morel, 2011).

Cette première couche du modèle de référence de l’urbanisme permet de traiter les besoins

en SI de l’organisation en analysant les inputs et les outputs ainsi que les acteurs et les

règles de décision présentes en son sein.


La vue fonctionnelle

La vue fonctionnelle « décrit les fonctions du système d’Information, telles qu’on les décrit

dans un cahier des charges en vue de la mise en œuvre d’une nouvelle application »

(Fournier-Morel, 2011).

Il s’agit donc d’une couche qui interface le fonctionnement de l’entreprise et l’informatique à

proprement parler en traduisant la logique de l’entreprise en logique informatique. Cette

couche représente SOA dans le modèle de l’urbanisation. Les fonctions étant les services.

La vue applicative

La vue applicative s’intéresse à décrire les fonctions logicielles qui sont présentes dans

l’entreprise et qui servent aux deux couches supérieures. La problématique de cette couche

sera donc le développement logiciel et la programmation d’éléments informatiques à même

de s’agréger en fonctions dans la couche supérieure.

La vue physique

La vue physique décrit les composants (ordinateurs, routeurs, imprimantes, etc.) qui

constituent l’infrastructure sur laquelle les trois niveaux précédents s’exécutent. Ces

éléments sont garants de la performance générale d’un SI en termes de disponibilité et de

capacité. Leur considération est donc des plus importantes, notamment selon le type du SI

développé (voir 2.2.1).

Limites du modèle

La vision en couches offerte par l’urbanisation aura permis de réaliser une abstraction des

systèmes d’informations qui aide à maîtriser leur niveau de complexité élevé. Mais de l’avis

de Fournier-Morel cette démarche aura surtout amené à « une documentation ″littéraire″ de

la cible du SI urbanisé qui ne débouchait sur aucune mise en œuvre concrète» (Fournier-

Morel, 2011). Pour reformuler, on peut dire que le modèle de l’urbanisation aura permis une

prise de conscience face aux problèmes rencontrés par l’architecture des SI. Son apport se

sera limité à la description des problèmes architecturaux et à leur explication. Mais l’industrie

informatique se devait de répondre avec autre chose que l’identification du problème et la

description de comment les choses devraient être. Son rôle était de formuler une solution.

C’est ce qu’elle a fait avec SOA. Cette émergence d’une solution à la fois conceptuelle et

technique est le sujet du chapitre 3.

SOA : Emergence d’un modèle d’architecture SI 20

3 SOA : EMERGENCE D’UN MODÈLE D’ARCHITECTURE SI

Dans cette partie, la troisième question de recherche est traitée: « En quoi SOA est-elle une

architecture de référence à ce jour et quels sont ses principes de fonctionnement ? ».

3.1 La réponse SOA

3.1.1 MOTIVATION ET DÉFINITION DE SOA

Le concept de SOA – qui désigne en français une architecture orientée service – est né du

besoin de pouvoir gérer l’architecture des SI avec plus de souplesse et ainsi permettre un

meilleur alignement stratégique des SI. La structuration fondamentale de SOA est d’ordre

systémique. La définition générale suivante est retenue pour ce travail :

« SOA est une forme d’architecture technologique qui adhère au principe d’orientation

service. Lorsqu’elle est réalisée par le biais d’une plateforme de web services, SOA parvient

à soutenir et promouvoir l’orientation service au sein des business process et domaines

d’automation d’une entreprise. » (Erl, 2005)

Cette définition permet de comprendre que SOA est avant tout un concept de structuration

des SI. Son adoption va donner aux SI une forme particulière qui sera la conséquence d’une

réorganisation des fonctions informatiques qui est illustrée à la Figure 7. Sur celle-ci on peut

constater que si le modèle de l’urbanisation – et notamment sa représentation visible à la

Figure 6 – s’était intéressé à la structuration verticale du SI en couches, SOA va intégrer des

concepts de structuration horizontale en utilisant l’approche d’orientation service et d’autres

principes qui seront décrits sous le point 3.2.

Il faut aussi remarquer à ce stade que cette description représente un état idéal qui a vu la

totalité des fonctions de l’entreprise obéir à SOA. Dans la réalité, SOA doit notamment son

succès au fait qu’il est un projet qui se réalise progressivement. La Figure 7 à droite

représente schématiquement le degré idéal de structuration SOA. Dans la réalité la plupart

des entreprises qui intègrent SOA se trouvent à quelque part entre la situation décrite à

gauche et la situation idéale. Afin de situer le niveau d’intégration de SOA dans une

entreprise, il est possible de recourir à un outil intitulé le SOA Maturity Model (BPtrends,

2007). Le sujet n’étant pas l’intégration SOA, mais celle d’un processus, ce modèle ne sera

pas décrit ici.


FIGURE 7: AVANT ET APRÈS SOA (TRIDENS, 2011)

Si SOA est un concept de structuration des SI, son intégration va nécessiter le recours et

l’acquisition d’infrastructures techniques. Le présent travail ne traitera que de manière

sommaire ces infrastructures car elles sont intégrées dans des solutions distribuées par des

éditeurs informatiques. En revanche, les composants structurels de SOA et les standards

des web services qui permettent un échange d’information entre les constituants de SOA et

l’extérieur du système seront traités sous le point 3.3.


3.2 Les principes conceptuels de SOA

Les principes conceptuels ici exposés sont ceux présentés dans l’ouvrage de Thomas Erl

(Erl, 2005). Ils ne sont pas présentés à titre exhaustifs, mais avec l’intention de décrire le

comportement et les propriétés d’un système qui se revendique être une SOA.

3.2.1 ORIENTATION SERVICE

Un service peut se définir en informatique comme « […] une fonctionnalité ou partie de

fonctionnalité ″offerte″ (ie mise à disposition) par un composant logiciel pour assurer une

tâche particulière. » (Wikipedia/Service, 2012).

Un service fait appel à une logique de type client-serveur où le client consomme le service et

le serveur le met à disposition. Entre le client et le serveur se trouve une interface, soit un

moyen standardisé d’accéder au service qui est toujours le même pour le client et qui

respecte le principe d’encapsulation. C’est-à-dire que le client ne doit pas savoir comment le

service est implémenté pour l’utiliser. Il doit savoir où il se trouve et quels paramètres il doit

lui donner pour l’utiliser. Entre le client et le serveur, les interactions se font par le biais d’un

contrat, c’est-à-dire d’une description de ce que chaque partie (client et serveur) doit faire.

L’orientation service consiste à décrire la disposition de tous les éléments du système à

tendre vers cet état de fait. Toute fonctionnalité logicielle de SOA repose sur ce principe. Un

service permet aussi une abstraction de l’implémentation. C’est-à-dire que l’utilisateur n’a

pas besoin de connaître la nature de l’implémentation pour accéder au service.

Le principe de base d’orientation service est fondateur, dans le sens où il permet l’existence

des principes de modularité, de réutilisation et de couplage faible.

3.2.2 MODULARITÉ ET COMPOSITION DES SERVICES

Une architecture SOA dans son ensemble est une composition de modules. Ces modules

sont en fait tous des services qui ont la capacité de s’agréger en des fonctionnalités plus

étendues. Chaque module possède les deux propriétés fondamentales suivantes :

Il est un service qui est accessible par son interface.

Il peut être composé d’une ou de plusieurs unités.

La modularité et la composition des services sont des principes essentiels à la mise sur pied

d’une architecture. Leur recours amène à des problèmes de structuration qui peuvent faire

intervenir des patterns de structuration qui vont permettre la création de services dans les

différentes couches d’une SOA (voir 3.3.1).


3.2.3 RÉUTILISABILITÉ

Les applications rendues possibles par SOA reposant sur la composition de services

peuvent servir de base pour réaliser de nouvelles fonctions. L’utilisation d’éléments déjà

existants permet de tirer profit au maximum d’une réalisation générique des modules : c’est

le principe de la réutilisabilité.

3.2.4 COUPLAGE FAIBLE

Derrière le principe de couplage se trouve l’idée suivante : un module ne doit pas être trop

interdépendant des autres. De la sorte, il peut facilement être remplacé par un autre en cas

d’indisponibilité de service. Le couplage faible permet aussi de respecter le principe

d’orientation service. Il permet de rendre l’accès à un service, sans que l’utilisateur doive se

préoccuper de son implémentation.

3.2.5 PROMOTION DE L’AGILITÉ

L’agilité qualifie une entreprise qui « s’adapte rapidement aux changements et aux

opportunités d’affaires et qui améliore de manière continue l’optimisation des coûts, de la

qualité et la vitesse de livraison. » (Cummins, 2009). SOA n’est pas uniquement compatible

avec l’agilité. Elle propose d’être un moteur d’implémentation de ce concept dans toute

l’organisation.

3.2.6 VALORISATION DES SYSTÈMES DÉJÀ EXISTANTS

La démarche SOA n’est pas une démarche ex nihilo. Le recours à SOA peut se faire en

utilisant les fonctions déjà présentes dans l’entreprise dont le fonctionnement est jugé

adéquat. SOA permet de valoriser ces systèmes en les intégrant, en les faisant

communiquer avec d’autres fonctionnalités et en leur permettant de devenir évolutifs grâce à

une interface qui standardise leur accès par le biais de l’orientation service.


3.3 Les composants et standards de SOA

3.3.1 NIVEAUX DE SERVICE DE L’ARCHITECTURE SOA

Le concept d’orientation service décrit au point 3.2.1 concerne tous les éléments de

l’architecture SOA. Mais ce concept est soumis à un principe d’organisation interne de SOA :

les niveaux de service (Erl, 2011). Cette logique d’implémentation peut être expliquée avec

un modèle qui empreinte la forme de couches du modèle de l’urbanisation (voir 2.3.2) et qui

est illustré à la Figure 8.

FIGURE 8: COUCHES SOA (ERL, 2005)

Le business process layer

Il s’agit du niveau qui concerne l’exécution des processus au niveau des fonctions de

l’entreprise. Son rôle est de mettre à disposition de l’organisation des processus composés

par les fonctions de l’entreprise. Il peut s’agir à la fois de processus internes, mais ceux-ci

sont souvent instanciés par des end-to-end process, c’est-à-dire des processus qui


traversent l’entreprise en entier et qui atteignent le client à la fin. La forme constituant ces

processus est sujette à un changement continu car elle est directement reliée à la manière

dont l’organisation crée de la valeur. C’est ici dans SOA que la problématique de

l’architecture des SI rencontre celle des business process et qui avait été identifiée au point

2.2.2 de ce travail. L’abstraction du business process layer permet donc aux personnes du

business de penser et d’organiser les processus qui concernent le modèle d’affaire de

l’entreprise, avec des outils conceptuels et particulièrement ceux offerts par le BPM. Ces

outils seront décrits dans le chapitre 4.

Le service interface layer

Le service interface layer est un niveau d’abstraction de SOA dans lequel a lieu la

composition des services. Cette composition de service commence par l’établissement de

services de bas niveau qui soient les plus génériques et réutilisables possibles. Ensuite,

ceux-ci sont agrégés en fonctions opérationnelles au niveau du business service layer. On

distinguera les trois sous niveaux suivants :

o Le niveau application service layer qui interface les applications issues de la

couche applications. Cet interfaçage permet d’utiliser les applications

indépendamment de leur nature et leur implémentation. Elles permettent ainsi

d’utiliser les fonctionnalités de l’application de SOA.

o Le niveau de composition qui va être garant que des services génériques

soient développés dans la SOA, afin de s’assurer un niveau de modularité qui

permette une réutilisabilité la plus large possible.

o Le niveau d’orchestration va quant à lui s’assurer que les services soient

appelés de manière cohérente pour s’offrir à la couche processus. Il est à

noter qu’il existe plusieurs niveaux d’orchestration. Un niveau technique qui a

lieu dans la couche de service et un niveau métier qui a lieu au niveau du

business process layer.

Il est à noter que les niveaux qui sont ici décrits représentent des niveaux conceptuels et

qu’une implémentation de la couche service pourra, selon les besoins et les choix faits par

l’architecte, utiliser plus ou moins un niveau de service, voire ne pas distinguer les trois sous-

catégories ici. On remarquera aussi que pour réaliser la couche service, il peut être

nécessaire de créer une plateforme technique qui soit dédiée à l’exécution de services.

Celle-ci prend le nom d’ESB (Enterprise Bus Service). Elle est une importante constituante

technique d’une architecture SOA. La description de son fonctionnement ne fera toutefois

pas partie de ce travail.


Le niveau application

Le niveau application est constitué de fonctions informatiques exploitables par les couches

supérieures. Il s’agit de l’input du service layer. La nature selon laquelle sont constituées les

applications va fortement influencer le besoin de traitement de celles-ci par le service

interface layer.

3.3.2 UTILISATION DES WEB SERVICES

Si « SOA est une approche d’architecture et ne fait pas d’hypothèse sur la technologie mise

en œuvre » (Fournier-Morel, 2011), il existe une technologie qui dispose de spécification

particulièrement adaptée à SOA. Il s’agit des web services. Le principe des services web est

de proposer un service à distance par le biais d’une relation client serveur. Cette relation est

rendue possible par l’utilisation d’un format d’échange de documents qui soit clair tant pour

le client que le serveur. Il s’agit généralement de la technologie XML qui est utilisée.

La première génération de web services XML-RPC (eXtensible Markup Langage - Remote

Process Call) a vu le jour en 1995. Comme sa dénomination l’indique, il s’agit d’une

technique d’appel de procédure à distance utilisant le format XML. Si cette norme considérée

comme désuète est ici mentionnée, c’est que le système ERP (Open ERP) de l’entreprise

qui sera l’objet de la partie pratique est basé sur ce format d’échange au niveau de son

organisation interne. Dans ce travail, c’est une nouvelle génération de web intitulée WS*- qui

va être utilisée. Celle-ci désigne des services web qui respectent les spécifications WS-*, soit

un standard défini par le W3C (World Wide Web Consortium). Les principales normes qui

permettent l’échange d’information et l’exécution de processus seront traitées ici.

3.3.3 UN FORMAT PILIER : XML

Le XML (eXchange Markup Langage) est le format des messages et des normes dans le

monde des web services. Il s’agit d’un format générique qui est extensible dans des

syntaxes propres à n’importe quelle utilisation. Il est composé des balises qui sont contenues

entre <…> et qui sont paramétrables. Le paramétrage de celles-ci se fait par le biais d’un

XML-Schema. Celui-ci est toujours décrit dans l’en-tête sous forme d’une URL qui l’héberge.

Lui-même contient un XML Schema.

La Figure 9 permet de voir un fichier XML associé à son XML Schema. On voit dans celle-ci

que les champs sont créés dans le XML Schema, avec la balise <xs : element…/> et que

ceux-ci sont repris dans le fichier XML avec la syntaxe de balise suivante : <nom></nom>.


Le fichier XML fait quant à lui référence au fichier XML Schema dans son entête par le biais

de la balise <personne xmlns :xsi=url… xsi :.../>.

FIGURE 9: XML SCHEMA AVEC FICHIER XML (WIKIPEDIA, 2012)

3.3.4 ECHANGE DE MESSAGES AVEC SOAP

Le web service SOAP (Simple Object Access Protocol) est un protocole qui gère l’échange

de messages entre les composants d’une SOA. Il permet la standardisation des échanges

dans des infrastructures informatiques qui disposent d’interfaces de sécurité. Les messages

SOAP peuvent utiliser divers protocoles de transports tels que HTTP, mais aussi SMTP, FTP

et d’autres protocoles d’échanges présents dans la couche application du modèle OSI

(Tannenbaum, 2008). Les messages représentent une enveloppe composée de deux

parties :

Le HEADER qui est composé des informations nécessaires au traitement de

données ;

le BODY qui, lui contient les données elles-mêmes sous une forme propre au service

invoqué et à l’exécution de ce dernier.

Il est possible d’apercevoir deux fichiers SOAP constitués d’une requête simple et de sa

réponse par le service invoqué à la Figure 10. On notera dans les balises XML les balises :

< ?xml version…> qui définit le recours au format XML et ses paramètres.

<SOAP-ENV : Envelope> </SOAP-ENV : Envelope> qui contient une suite de

métadonnées nécessaires au traitement du message, ainsi que le Body.

<SOAP-ENV : Body> </SOAP-ENV : Body> qui contient les informations à

proprement parler du message.


On notera que la requête et la réponse respectent strictement les mêmes balises.

FIGURE 10: REQUÊTE ET REPONSE SOAP SIMPLE (QUAINE, 2012)

3.3.5 WSDL

Si SOAP gère la standardisation des communications entre deux entités dans une relation

client serveur, il ne prend pas en charge le traitement des informations au niveau du service

à proprement parler. C’est la norme WSDL (Web Service Description Langage) qui va s’en

charger. Celle-ci propose de définir « un contrat qui définisse le fonctionnement technique du

service web en termes d’opérations, de paramètre et de typage » (Fournier-Morel, 2011).

Comme cela est illustré à la Figure 11, WSDL prend la forme d’un fichier XML qui régit les

échanges entre le client et le service provider.

FIGURE 11: FONCTION DE WSDL (HAAS, 2012)


Le fichier WSDL, décrit à la Figure 12, définit un service qui implémente un contrat de

service. Celui-ci est constitué de deux types d’informations. Les informations de type

abstraites qui sont relatives à l’interface et indépendantes de la technologie et les relations

de type concrètes qui sont quant à elles, relatives à l’implémentation concrète du service. Le

contrat de service sera très important dans la partie pratique de ce travail lorsqu’il s’agira

d’implémenter un web service par le biais du BPMS. Cette norme joue aussi un rôle

primordial dans l’avènement du BPMN 2.0 comme un langage d’exécution (voir 4.4.3).

FIGURE 12: FORME D'UN DOCUMENT WSDL (IBM, 2012)

3.3.6 UDDI

SOA promeut la découverte des services de son architecture. UDDI (Universal Description,

Discovery and Integration) est une norme qui permet la mise sur pied d’un annuaire de

services. Son implémentation, décrite à la Figure 13 est basée sur l’utilisation de SOAP et de

WSDL. Le premier va permettre la communication avec l’annuaire et le second servira à la

description des services disponibles.

FIGURE 13: IMPLÉMENTATION DE UDDI (KRAWLER, 2009)


3.3.7 BPEL

Si SOAP, WSDL et UDDI sont des normes fondamentales qui offrent des standards de

communication fondamentaux à SOA, il reste un service de la norme WS-* qui doit être

mentionné ici car il est spécialisé dans ce qui est l’objet d’implémentation de ce travail. Il

s’agit de BPEL (Business Process Execution Langage). BPEL est un service spécialisé dans

l’exécution des business process. Basé sur la norme XML, il permet d’exécuter des fonctions

successives en régissant leur appel, les éventuelles conditions et les séquencements. Il ne

sera néanmoins pas utilisé dans ce travail car l’avènement d’une norme telle que BPMN 2.0

qui sera décrite au point 4.4 et qui permet à la fois la modélisation et l’exécution n’a pas

rendu son recours pertinent. Toutefois, de nombreuses solutions SOA et BPM l’utilisent

encore pour instancier des processus. Les solutions se chargeant de transformer par un

fonctionnement complexe des graphiques de modélisation en fichiers BPEL exécutables.

BPM : gérer l’organisation par les processus 31

4 BPM : GÉRER L’ORGANISATION PAR LES PROCESSUS

4.1 Bases conceptuelles

Au point 4.1, la question de recherche se demandant « Qu’est-ce que BPM, pourquoi

l’utiliser ? » sera traitée.

4.1.1 DÉFINITION

Pour Gartner, le Business Process Management (BPM) est « une discipline du management

qui traite des business process à titre d’actifs qui contribuent directement à la performance

de l’entreprise par le biais d’excellence opérationnelle et d’agilité » (Gartner, 2013).

En prêtant attention à cette définition, on constate qu’il s’agit donc d’une approche qui

considère l’entreprise dans son entier sous le prisme des processus. Qu’ils soient définis

comme des actifs leur donne la qualité d’être les moyens mis à disposition du management

pour réaliser une performance économique. En devenant ces moyens, ils deviennent donc

aussi les variables de décision par lesquelles une entreprise va être capable de maximiser la

valeur qu’elle pourra générer. En parlant d’excellence opérationnelle et d’agilité, cette

définition donne aussi une direction aux objectifs managériaux pour faire du BPM une

approche à même de faire performer l’entreprise d’un point de vue économique.

On notera que le concept de BPM a une qualité holistique : en effet, c’est l’organisation dans

son entier qui est vue par le biais des processus et non pas une partie de cette dernière. En

considérant les processus, le management considère toute sa structure et peut réfléchir à

l’organisation de celle-ci en termes de totalité, même si son action pourra par la suite ne

concerner qu’une sous-partie de l’organisation.

4.1.2 HISTORIQUE

Pour expliquer dans quel contexte l’approche BPM a éclos, il est nécessaire de faire un

détour par l’histoire de la théorie des organisations. Susan Morley considère que l’approche

BPM doit son existence à 4 sources principales (Morley, 2011) qui sont reprises et dont elle

a de chacun hérité d’un concept. La première de ces sources est le Just in Time (JIT)

développé dans l’industrie japonaise dans la première moitié du XXème siècle. Cette théorie

qui veut que la production d’un produit succède à la commande et ne génère pas de stock a

été la première à considérer le liage des besoins entre consommateurs et producteurs. Un

élément essentiel de BPM, puisque dans cette théorie, c’est la satisfaction finale du client qui

influence l’exécution de la totalité du processus.


On doit la seconde influence conceptuelle au Total Quality Management (TQM). Celui-ci va

généraliser le concept du next step is a customer qui signifie que chaque tâche est cliente de

la précédente. De la sorte, il va permettre un liage entre les tâches avec un mécanisme

rétroactif en cas de plainte de la part du client sur un défaut et un concept qui va permettre

au processus d’être trans-organisationnel. Etant donné que le lien de clientèle est entre

chaque tâche, le passage d’une organisation à l’autre pour un processus n’est pas de nature

différente.

La troisième influence est celle de la comptabilité analytique qui, dans les années 60, a mis

en exergue la limite d’une vision hiérarchique de l’organisation découpée en sous unités ou

en métiers (voir Figure 5) dans leur contribution à créer de la valeur et qui, elle aussi fera

naître le concept de chaîne de valeur, soit un ordonnancement de processus créant un

produit qui parcoure l’organisation de manière transversale.

Enfin, le process re-engineering proposé par Hammer et Champy, notamment au travers de

leur ouvrage Reengineering the Corporation: Manifesto for Business Revolution

(Hammer&Champy, 2003) va faire de la notion de processus l’élément clé pour repenser une

organisation. C’est de cette dernière démarche que naîtra ensuite un certain nombre d’outils

et de méthodes que l’on identifie désormais comme faisant partie du BPM.

4.1.3 LE BUT DU BPM : L’AGILITÉ

La pratique du BPM n’est en soi pas une finalité. Il s’agit d’un ensemble de moyens mis en

place pour permettre à une entreprise de devenir agile. Par agilité, on entend « une qualité

qu’une entreprise possède lorsqu’elle est capable de s’adapter rapidement à un

environnement d’affaires changeant tant au niveau des défis que des opportunités. Il s’agit

d’une démarche d’amélioration continue qui optimise les coûts, la qualité et les délais de

livraison. Elle implique le top management de l’entreprise afin d’implémenter très rapidement

les nouvelles stratégies et de contrôler les variables clés du modèle d’affaire, ceci dans le

but d’obtenir un avantage concurrentiel » (Cummins, 2009).

Cette définition permet de comprendre que l’agilité est un défi. Un défi qui demande à la fois

une compréhension de la part du management et son implication jusque dans les plus

hautes sphères de la direction. Mais pour pouvoir modifier les processus au besoin, il faut

aussi compter sur des outils qui permettent le changement et le déploiement de l’agilité, ainsi

que sur une infrastructure du SI qui rende possible ces changements organisationnels.

Comme cela été vu dans le point 3, SOA possède les caractéristiques pour supporter un

changement grâce à ses propriétés fondamentales. Quant à l’intégration de l’agilité dans

l’organisation, celle-ci se fera grâce aux outils BPM présentés à la suite de ce travail.


4.2 BPM Lifecycle

Le point 4.2 répondra à la question de recherche se demandant « En quoi le BPM Lifecycle

est-il un concept qui permet à l’entreprise de gérer ses processus et de les améliorer ? ».

4.2.1 CONCEPT GÉNÉRAL

Le BPM Lifecycle est une méthodologie dérivée de l’approche PDCA (Plan-Do-Check-

Adjust). Elle recourt au concept d’itération qui implique que l’exécution de la dernière phase

donne lieu au retour à la première phase du cycle. Les auteurs qui écrivent sur le BPM ont

plusieurs interprétations du BPM Lifecycle. Celle qui sera utilisée dans ce travail est celle

exposée par Michael Hammer dans l’ouvrage Handbook on Business Process Management

I (Brocke & Rosenmann, 2009). Elle est constituée de 5 phases distinctes dont la Figure 14

décrit le séquencement. Chaque phase va faire interagir des acteurs différents et va amener

au traitement de tâches spécifiques. L’étude distincte de chaque phase sera l’objet des

points 4.2.2 et suivants.

Sa qualité de standard est perceptible au fait qu’il est devenu un outil commun pour les

personnes en charge de la gestion des processus. Le recours au BPM Lifecycle est donc

garant d’une gestion des processus qui soit à la fois intelligible pour tous les acteurs et

standardisée au niveau de la méthode de projet.

FIGURE 14: BPM LIFECYCLE

Goal Specification /

Strategy Definition

Process Design

Process Implementation

Process Runtime

Process Improvement


4.2.2 LA PHASE GOAL SPECIFICATION / STRATEGY DEFINITION

La phase Goal Specification / Strategy Definition est la première phase du BPM Lifecycle.

Elle implique deux impératifs pour le management. En premier lieu, l’instance dirigeante doit

être capable de définir un but que l’organisation entend atteindre. Pour cela, elle se doit de

procéder à une réflexion sur la valeur attendue par le client quant aux prestations ou produits

qu’elle est à même de lui livrer. En parallèle, elle devra définir comment atteindre ce but :

c’est l’objet du Strategy Definition. Ces deux inputs devront ensuite être mis en forme pour

être transformés en réalité. Il faudra donc penser aux moyens à allouer au projet, à la

planification aux rôles à donner aux différents acteurs et définir en termes très clair le but

poursuivi par le projet et la forme qu’il doit prendre. La bonne exécution de cette phase est

capitale pour que la suite de projet puisse se dérouler dans les meilleures conditions. En

vertu du concept d’agilité défini au point 4.1.3, c’est en impliquant le plus tôt possible le top

management dans des décisions qu’il sera possible d’atteindre les meilleurs résultats.

Il est à noter que la première phase du BPM Lifecycle est dans les faits rarement la première

à être utilisée dans un projet concernant un processus. Elle ne l’est que lors de la première

itération sur un projet de processus. Elle sera, dans les itérations suivantes, consécutive à la

phase de Process Improvement.

4.2.3 LA PHASE DESIGN

La phase de design peut être considérée comme une phase intermédiaire entre le Plan-Do

du modèle PDCA. Elle va transformer les besoins du management en une représentation

abstraite des tâches et des séquencements nécessaires à l’exécution du processus. Cette

phase, mise sous la responsabilité de spécialistes appelés business process analysts est

absolument nécessaire pour définir un modèle qui soit à la fois compréhensible de la part du

management, des acteurs et des utilisateurs du processus ainsi que des informaticiens et

spécialistes métiers.

Le but de la phase design est donc de proposer une modélisation du processus qui soit « un

même langage » pour tous les acteurs du projet et qui garantisse à chacun d’entre eux que

les aspects importants relatifs à leurs fonctions y soient mentionnés. Pour parvenir à ces

fins, le recours à un langage de modélisation est une nécessité. Le langage BPMN 2.0 (voir

4.4) est un standard reconnu et partagé et sera utilisé dans ce travail. Il permet de définir et

de représenter :

Les acteurs du processus ;

Les opérations selon leur type ;

Les types d’interactions entre les acteurs ;


Les séquences et les éventuelles conditions.

Par ce biais, il sera question de déterminer un processus qui soit optimal, tenant compte des

limitations en termes de ressources et des conditions d’optimalité exprimées dans la phase 1

du BPM Lifecycle.

4.2.4 LA PHASE IMPLEMENTATION

La phase d’implémentation est consécutive à celle de design. Elle a pour objectif de faire des

spécifications et du concept de processus développé lors du design une réalité qui met en

œuvre les ressources de l’organisation délivrant de la valeur. Ces ressources peuvent être

de différentes natures. On notera deux grands types : les ressources humaines et celles qui

sont intégrées dans le SI de l’entreprise. L’implémentation d’un processus consiste à la fois

en l’exécution de tâches selon la séquence donnée du processus, mais aussi en la mise sur

pied des interfaces qui vont permettre aux utilisateurs de lancer le processus et d’interagir

avec le SI.

Une implémentation de processus va se faire par le biais d’un logiciel spécialisé dans la

gestion de processus qui soit à même d’appeler des tâches et les exécuter selon la

description donnée par la modélisation. Afin de rendre possible l’exécution successive des

tâches, le paradigme de l’orientation service sera alors requis. Chaque tâche devenant un

service qu’il est possible d’appeler par son interface. Ainsi, les fonctions informatiques et les

acteurs du processus seront appelés à agir selon les principes de SOA. La propriété

d’orientation service des services utilisés sera promue par le Service Layer (voir 3.3.1) et si

cela est nécessaire techniquement par la présence d’un ESB. Il existe plusieurs bases

technologiques pour l’exécution de processus. Comme cela a été vu au point 3.3.7, BPMN

2.0 sera la norme utilisée pour ce travail.

4.2.5 LA PHASE DE PROCESS RUNTIME

Une fois le processus implémenté et rendu exécutable, vient le temps pour le processus de

devenir une réalité dans l’organisation dans laquelle il existe. Cette réalité prend forme avec

des ressources informatiques mobilisées sous la forme d’interfaces visuelles qui permettent

l’interaction avec le processus, la formation d’utilisateurs et le monitoring du processus pour

s’assurer de son bon fonctionnement. Ce monitoring est aussi réalisé dans le BPM. En plus

du monitoring des ressources, il est nécessaire d’appliquer une métrique de performance au

processus pour s’assurer qu’il est optimal et qu’il corresponde aux attentes formulées dans

la première phase du BPM Lifecycle. Pour se faire, le recours à des KPI (Key Performance


Indicators) est nécessaire. Ces KPI sont à mettre en lien avec le BPMM et particulièrement

le niveau 4 de BPMM qui est défini au point 4.3.6.

Il est aussi à noter que si l’entreprise veut s’inscrire dans une démarche processus de long

terme, il sera extrêmement important durant cette phase de s’assurer que les utilisateurs font

une expérience optimale du processus tel qu’il est développé et que leurs remarques

puissent-être saisies et intégrées par le biais de la dernière phase du BPM Lifecycle qui sera

le sujet du point suivant.

4.2.6 LA PHASE DE PROCESS IMPROVEMENT

Une fois le processus exécuté au sein de l’entreprise, il faut encore s’assurer de son suivi, et

notamment de s’assurer qu’il desserve toujours le modèle d’affaire. Si le processus devait

devenir désuet et ne plus correspondre aux besoins et s’il devait s’avérer ne plus être

optimal d’un point de vue économique, ce serait alors à la phase du process improvement de

gérer les améliorations possibles.

Si l’exécution des 4 phases précédentes est à même de garantir que le projet se déroule le

mieux possible et selon des responsabilités et des rôles établis, elle ne peut en aucun cas

garantir que le résultat soit parfait, ni même suffisant par rapport à ce qui a été défini par

l’organisation. La dernière phase est garante qu’il soit possible de reprendre un projet peut-

être imparfait, mais elle permet aussi de réaliser des itérations plus courtes qui peuvent

permettre de montrer plus rapidement des résultats sur lesquels un retour de la part du

maître d’ouvrage – soit celui qui est à l’origine du projet et des besoins – est possible.


4.3 BPMM

Le point 4.3 répondra à la question de recherche suivante : « Comment le niveau de

sensibilité d’une organisation aux processus peut-il être évalué et amélioré ? »

4.3.1 CONCEPT

Le BPMM (Business Process Maturity Model) «est une norme définie par l'Object

Management Group (OMG) qui propose de fournir une grille d'analyse de la maturité des

processus métier d'une entreprise. » (BPMS Maîtriser la complexité, 2012). Cette norme est

définie par l’OMG, soit la même organisation qui définit BPMN 2.0. Les deux concepts sont

ainsi compatibles et complémentaires.

Le recours à cette norme permet de disposer d’un standard pour juger du niveau de

conscience et d’importance donnée aux processus dans une organisation. Les différents

niveaux de la norme seront exposés ci-dessous. Sa spécification utilisée ici pour décrire les

5 phases constitue le document BPMM Specification disponible sur la page du site OMG

(OMG, 2013). Il existe des Maturity Models dans de nombreux domaines de la gestion

d’entreprise et le point 3.1.1 a été l’occasion de mentionner celui dévolu à SOA. Dans ce

travail, la présentation d’un tel modèle pour les processus a été retenue car les processus et

leur gestion représentent la cible de ce travail, contrairement à SOA qui a un rôle de

participant.

4.3.2 REPRÉSENTATION DES NIVEAUX

Le BPMM est un modèle à 5 niveaux que la Figure 15 présente. Le premier niveau

représente le plus faible niveau de prise en compte des processus dans l’organisation alors

que le niveau 5 représente quant à lui la situation optimale. Chaque niveau porte un nom qui

décrit la situation générale des processus. Le passage d’un niveau à un autre est possible

par le recours à une itération du BPM Lifecycle.


FIGURE 15: NIVEAUX DU BPMM

4.3.3 NIVEAU 1 : INITIAL

Le niveau initial consiste en une situation qui fait des processus une réalité qui n’est pas

gérée ni contrôlée. Le déroulement des actions dans une entreprise qui a un niveau 1 de

BPMM n’obéit pas à une définition préalable des processus qui fait l’objet d’une réflexion,

mais à l’impératif d’exécuter les tâches pour obtenir un résultat qui ne fait pas l’objet d’une

définition préalable. D’une manière générale, « la capacité d’exécuter un processus est celle

des individus et pas de l’organisation » (OMG, 2013). Cela implique que si une personne

avec une compétence donnée devait quitter l’organisation, la compétence au sein même de

celle-ci serait perdue et nécessiterait d’être à nouveau développée.

Comme l’exécution du processus est directement liée aux personnes, c’est aux qualités

intrinsèques de celles-ci que l’organisation reconnaît son fonctionnement. On verra alors

souvent des situations de crise devoir être gérées par le biais d’actions « exercice pompier ».

A ce niveau, les processus ne sont rarement documentés puisqu’un processus repose la

plupart du temps sur une seule personne. Et s’ils sont documentés, leur exécution ne suit

pas ou rarement la description formelle qui en est faite.

4.3.4 NIVEAU 2 : MANAGED

Au niveau 2, il y a une prise en charge des processus, mais celle-ci est locale. Cela signifie

que ce sont des cadres intermédiaires, situés entre le top management et le déroulement

des opérations qui permettent à leurs subalternes de s’organiser et de faire en sorte que les

processus suivent une certaine logique.

Level 1 •Initial

Level 2 •Managed

Level 3 •Standardized

Level 4 •Predictable

Level 5 •Optimized


Comme la gestion des processus est locale, il n’y a pas de guidelines pour toute

l’organisation. Dans ces circonstances, une prise en charge d’une problématique de

processus dans un département et une prise en charge dans un autre département de la

même problématique pourra donner lieu à deux processus différents pour traiter le même

cas.

Les considérations pour optimiser les processus portent sur ce qui importe directement au

département : des délais, des coûts et des aspects de performance qui sont reliés à l’unité

organisationnelle qui gère les processus, mais pas pour la totalité de l’organisation. Le client

final n’est pas pris en considération dans l’amélioration des processus, en ce sens que les

processus choisis ne sont pas end-to-end.

4.3.5 NIVEAU 3 : STANDARDIZED

Il s’agit du premier niveau du modèle BPMM où la gestion des processus est pensée pour

l’organisation en entier. La documentation des processus est réalisée de manière générique

afin qu’elle puisse-t-être utilisée dans tous les départements de l’organisation pour des

problèmes donnés et que la solution proposée soit partout de la même forme. A ce niveau, il

existe une responsabilité définie dans l’organisation qui se charge des processus, de leur

application et de leur gestion.

Les processus sont organisés selon une typologie qui distingue les processus opérationnels,

les processus de soutien et les processus décisionnels. Elle tente de standardiser ceux-ci et

de généraliser les processus qu’elle identifie comme étant les meilleures pratiques. La

gestion des processus fait partie de l’organisation et une attention lui est donnée dans

l’organisation de la vie de l’entreprise.

4.3.6 NIVEAU 4 : PREDICTABLE

Au niveau 4, les processus font l’objet de métriques. Ces métriques sont garantes du

concept de qualité. Il est en effet possible grâce à elles de déterminer un niveau de

performance donné d’un processus en relation avec un besoin. L’existence d’une valeur qui

soit quantifiable permet d’effectuer un controlling des processus et de déterminer les actions

correctives qui seront à même d’améliorer le processus. (NB : on comprend ici le lien entre la

phase Process Monitoring et Process Improvement du BPM Lifecycle). Si ce niveau est

appelé « Predictable », c’est parce que les processus sont « contrôlés, quantifiés et

prévisibles (anglais : predicable) car leur performance est mesurée et opère dans des limites

quantitatives » (OMG, 2013).


4.3.7 NIVEAU 5 : INOVATING LEVEL

Le niveau 5 concerne les organisations qui évaluent sur une base constante leur modèle

d’affaires et les limites inhérentes à celui-ci. De la sorte, elles sont en mesure de proposer

des actions sur les processus qui aillent plus loin que la correction des erreurs, mais qui

permettent de faire de la maintenance préventive ou qui optimisent la valeur délivrée par le

biais de l’approche qualité développée dans le niveau précédent.

Cet effort a lieu avec le concours de tous les membres de l’organisation. Il est un état atteint

lorsque l’amélioration continue succède à l’atteinte des buts de tous les niveaux précédents.

4.3.8 LIENS ENTRE BPMM ET LE BPM LIFECYCLE

Le BPMM décrit des niveaux de prise en charge des processus dans une organisation. Le

comportement attendu d’une organisation étant ici, si elle veut livrer un maximum de valeur,

d’évoluer vers le niveau 5. Dans l’approche BPM, le BPM Lifecycle est la méthodologie qui

va permettre de planifier cette évolution et de maximiser les chances de succès.

Mais le BPM Lifecycle concerne habituellement un processus qui peut être à la rigueur

composé de sous-processus. Il faudra donc plusieurs itérations de BPM Lifecycle sur un

ensemble de processus qui couvrent l’entier de l’activité de l’entreprise pour que

l’organisation passe d’un niveau à un autre. Ce passage ne pourra être assuré par le simple

recours au BPM Lifecycle pour chacun des processus. Un intérêt pour la cohésion entre eux

et de leur gestion devra être développé. De par ses propriétés, c’est ce que propose de faire

le BPMM.

Il faut toutefois remarquer que le BPMM est un modèle, donc une simplification de la réalité.

Cela implique qu’il n’est pas possible de réduire toutes les situations et toutes les évolutions

possibles dans cette grille. On peut voir comme limite le cas où une entreprise produirait un

bien qui nécessite une compétence spécialisée dans un processus industriel et que cette

compétence soit celle d’un corps de métier qui la garde sous la forme de secret. Enfin, le

contexte dans une organisation peut ne pas être uniforme. Il sera ainsi possible qu’un

département intègre très rapidement l’approche processus s’il se trouve dans une situation

critique, alors qu’un autre département montre plus de résistance au changement.


4.4 BPMN 2.0

Sous ce point, la question de recherche suivante sera traitée : « quelles bases conceptuelles

et technologiques rendent possible l’exécution de Business Process sur une SOA ? »

4.4.1 AVÈNEMENT DE BPMN 2.0

Un certain nombre de langages ont été développés dans le but de gérer les processus.

Historiquement, deux tendances parmi ces langages sont à observer. Il existe premièrement

les langages qui servent à la modélisation des processus et ceux qui servent à leur

exécution.

Le standard WS-BPEL, promu par l’OASIS (Organization for the Advancement of Structured

Information Standards) a été abordé dans ce travail sous le point des web services (voir

3.3.7) car il respecte les spécifications WS* et il possède notamment un contrat WSDL. Il est

utilisé chez les principaux éditeurs de solutions membres de l’OASIS. Si ce langage propose

des propriétés d’exécution qui lui ont valu et lui valent toujours d’être massivement utilisé

dans l’industrie informatique, il n’offre en revanche pas de représentation graphique, sa

dénomination ayant la forme d’un fichier XML.

Le langage BPMN (Business Process Model and Notation) est quant à lui une notation qui

est née à l’initiative de l’OMG et qui a pour but d’être «une notation qui soit facilement

compréhensible pour les business users, les business analysts ainsi que pour les technical

developers qui en réaliseront l’implémentation technique et, enfin, pour les gens du business

qui vont gérer et monitorer les processus » (Krogstie, 2010). Cette notation voulait donc

rendre possible la communication entre les différents acteurs de processus,

indépendamment de leur rôle, de leur domaine de compétence et de toute notion technique.

Cette norme posait toutefois deux problèmes majeurs dans la gestion des processus.

Premièrement, une exécution des processus n’était pas possible et, ensuite, n’étant qu’une

convention graphique, les formes implémentées dans les différents BPMS pouvaient varier

et être incompatibles. Si ce dernier problème a été en partie résolu avec l’utilisation d’un

format standard d’échange en XML intitulé XPDL (eXtensible- Markup Process Definition

Langage) qui ne sera pas abordé dans ce travail, une solution de plus large envergure allait

être proposée pour éviter de complexes procédures de mapping entre une définition des

processus au travers d’une modélisation par les acteurs du business et une exécution au

sein des systèmes qui allait recourir à WS-BPEL.

Ainsi, la version BPMN 2.0 a été rendue exécutable, rendant ainsi possible le passage du

process design au process implementation sans qu’il faille changer de modèle. La Figure 16

illustre cette propriété fondamentale en montrant l’utilisation des normes entre le business et


le IT avant BPMN 2.0 et tels qu’ils sont rendus possibles avec l’adoption de la norme. BPMN

2.0 est donc plus qu’un langage de modélisation, c’est un standard pour représenter les

processus et leur exécution. Ces deux fonctions clés seront présentées dans les deux

prochains points.

FIGURE 16: AVANT ET APRÈS BPMN 2.0

4.4.2 PRINCIPAUX CONSTITUANTS D’UN DIAGRAMME DE BPMN 2.0

Les diagrammes de BPMN 2.0 sont une composition d’objets simples qui peuvent être

répliqués. Les principaux sont abordés à la suite, il existe un certain nombre de variation des

objets. Le layout des éléments présentés est celui proposé par la solution Open Source

Bonita qui servira à la partie pratique de ce travail.


Evènements

FIGURE 17: TYPES D'ÉVÈNEMENT BPMN 2.0

Les évènements sont modélisés sous la forme d’un point. Ils peuvent prendre plusieurs

formes suivant qu’ils soient un évènement de départ à la Figure 17 en vert, un évènement

intermédiaire en bleu ou un évènement de fin en rouge.

BPMN permet aussi de spécifier la nature de l’évènement. C’est ici les lignes de la Figure 17

qui en recensent les différents types. Un évènement peut être abstrait, il sera alors un point

vide, être un message, une minuterie, un signal, une correction d’erreur ou un arrêt.

Tâches

FIGURE 18: TÂCHES BPMN 2.0

Dans BPMN 2.0, les tâches sont les éléments qui nécessitent la mobilisation des fonctions

de l’organisation. Les actions peuvent être de différents types. Il peut soit s’agir de tâches qui

sont effectuées par des personnes. On parlera alors de tâches humaines. Si les tâches

requièrent l’appel d’une fonction informatique, on parlera alors de tâche de service. Il se

peut aussi qu’une tâche soit d’un type indéfini. On parlera alors de tâche abstraite. Enfin, il

est possible qu’un tâche soit elle-même composée de tâches. On parlera alors de sous-

processus.


Branchements

FIGURE 19: BRANCHEMENTS BPMN 2.0

Le chemin que va prendre l’exécution d’un processus n’a pas besoin d’être déterminé à son

début. Il peut être soumis à des conditions. Pour gérer cela, BPMN 2.0 intègre la notion de

branchements. Ceux-ci sont de trois types : les branchements parallèles, les branchements

exclusifs et les branchements inclusifs. Les branchements organisent les flux. Ces derniers

sont représentés sous la forme d’une flèche. Si les flèches sont placées avant un

branchement, on parlera du rôle de celui-ci comme d’une fusion. Si les flèches sont placées

après lui, on parlera de scission. Chaque type de branchement traite différemment ces deux

cas de figure.

Les branchements parallèles représentés à la Figure 19 sont reconnaissables à la croix

perpendiculaire qui se trouve au milieu du losange. Dans une situation de scission, ils

permettent à plusieurs flux de se dérouler en parallèle. Dans une situation de fusion, ils

attendent que tous les flux rentrant soient terminés pour passer à l’étape suivante.

Les branchements exclusifs que l’on reconnait au X situé au milieu du losange agissent

comme un « if » dans un langage de programmation. Ils vérifient une condition et permettent

uniquement le choix d’un flux en scission. Dans une situation de fusion, ils attendront aussi

qu’un seul des flux soit terminé pour passer à l’étape suivante.

Les branchements inclusifs qui sont le dernier type représenté sur la Figure 19 se distinguent

par le comportement suivant : à la scission ils permettent soit à un flux soit à plusieurs de se

poursuivre, alors qu’à la fusion, ils attendent que tous les flux soient terminés pour passer à

l’étape suivante.


Pools and lane

FIGURE 20: POOLS ET LANES BPMN 2.0

Les lanes représentent un niveau d’unité organisationnel dans lequel ont lieu certaines

tâches d’un processus alors que les pools sont, elles, composées de lanes (voir Figure 20).

Alors qu’entre deux lanes, la communication se fera par le biais d’un flux de séquence, celle

entre deux pools se fera par le biais d’un flux de message. Ces représentations permettent

de faire figurer les impacts organisationnels que peuvent avoir la modélisation de processus.

4.4.3 EXÉCUTION DE BPMN 2.0

L’exécution de BPMN 2.0 répond au défi de proposer une norme qui respecte le concept de

model preserving strategy (Swenson, 2009) entre la phase de modélisation et d’exécution du

BPM Lifecycle. Ce respect a pour conséquence que le modèle défini dans la modélisation

n’a pas besoin d’être retravaillé pour être utilisé dans la phase d’implémentation. Deux types

d’acteurs, soit ceux du business et ceux de la IT, comme illustré à la Figure 16, s’évitent non

seulement la transition d’un langage à un autre qui peut s’avérer très lourde en temps et en

ressources, mais parlent un langage qui est similaire et de ce fait, peuvent mieux collaborer.

Ce n’est donc pas que le passage de la phase de design à la phase d’implémentation qui est

facilité, mais aussi les prochaines itérations du BPM Lifecycle qui pourront compter sur une

implémentation de processus qui soit plus facile à comprendre.

Afin de rendre BPMN 2.0 compatible avec ce concept, il a été nécessaire d’y intégrer des

spécifications particulières. Celles-ci qui sont ici reprises du chapitre Make a BPMN 2.0

executable de l’ouvrage BPMN Handbook (Shapiro, 2012) sont soit de types conceptuelles,

soit inhérentes à l’implémentation. Parmi le premier type, l’auteur observera qu’un respect

strict de la syntaxe du langage est nécessaire. Si ce point va amener à une complexification

de la modélisation avec BPMN 2.0 puisqu’il sera nécessaire de respecter une stricte

grammaire, elle permettra à la phase d’exécution de disposer des informations nécessaires à

l’exécution même du processus.


D’un point de vue technique, la norme demande le recours systématique à XML. Par le biais

de XML schémas en XSD (voir 3.3.3) qui définissent la forme des modèles, ainsi que par le

biais de WSDL (voir 3.3.5), pour l’appel de services. Cette dernière norme fait partie des web

services. Il est donc intéressant de constater que l’exécution de BPMN 2.0 est rendue

possible par une approche de standard fort au niveau de sa syntaxe et de sa sémantique,

ainsi que par le recours à des normes techniques qui sont constituantes de SOA. BPMN 2.0

n’est donc pas un constituant de l’approche SOA, mais une norme qui permet une interaction

standardisée avec celle-ci.


4.5 BPMS

Le point 4.5 répondra à la question de recherche qui demandait « Quel outil BPMS open

source ou en accès libre est-il le plus à même de permettre une modélisation et une

exécution de processus ? ».

4.5.1 PRINCIPE

Les méthodologies et concepts vus jusqu’à présent dans le cadre du BPM offrent une vision

qui permet d’intellectualiser et de gérer les processus. Mais ce qui rend l’approche

processus intéressante pour une organisation, c’est qu’elle est à même de se transformer en

réalisation concrète qui s’implémente dans une entreprise et qui permette d’automatiser

certains processus. L’industrie informatique a mis sur pied des outils qui permettent de

réaliser et d’implémenter les différentes tâches que l’on retrouve dans le BPM Lifecycle. Ces

solutions sont connues sous le nom de Business Process Management System (BPMS).

Ces solutions suivent les différentes étapes du BPM Lifecycle et les soutiennent avec des

outils relatifs aux différentes phases.

Historiquement, ces solutions ont été intégrées dans des plateformes SOA et permettaient

ainsi de gérer le business process layer par le biais d’une suite logicielle qui respecte les

standards SOA. Il s’avère qu’une entreprise peut aussi avoir besoin de gérer ses processus

sans pour autant disposer des ressources et des compétences nécessaires à la création

d’une SOA au sein de son organisation. Dans la pratique, c’est le cas de la plupart des PME.

Le BPMS peut alors servir d’interface pour connecter plusieurs systèmes ensemble et gérer

leurs interactions nécessaires et orchestrer le processus.

L’intérêt d’un tel recours est de rendre la gestion des processus indépendante d’une solution

de type ERP qui n’est pas nécessairement spécialisée dans la gestion des processus, même

s’il est possible qu’en théorie elle offre cette fonctionnalité. Pour se faire, il sera nécessaire

d’identifier les différentes caractéristiques des outils présents à cette heure sur le marché et

de voir lesquels offrent le plus grand potentiel pour la partie pratique de ce travail.

Certaines de ces solutions font aussi la promesse du zero code, c’est-à-dire de programmer

des fonctions informatiques sans avoir recours à une moindre ligne de programmation. Cette

notion est intégrée à titre de proposition du vendeur dans le tableau de la Figure 21.

4.5.2 COMPARATIF DES OUTILS EXISTANTS

Il existe une pléthore de solutions logicielles qui affirment être des solutions BPMS. Si toutes

garantissent par le biais de leurs vendeurs une prise en main facile et des résultats


fulgurants, il peut en être bien autrement dans la réalité. Ce travail a évalué 4 solutions en

consultant la documentation disponible sur la solution et en les installant, et pour chacune

d’entre elles en tentant de modéliser le processus de la Figure 24. Ces solutions ont été

choisies en fonction d’un critère simple : l’absence de coûts de licences pour l’utilisation dans

ce travail. Si le choix est non exhaustif, il se veut illustratif des différentes tendances

présentes sur le marché

Nom de la solution Type de licence Qualité de la

documentation

Orientation

technique

BPMN 2.0 Qualité de la

modélisation

Facilité de

prise en main

Bonita Soft Open Source * Zero code Oui *** ***

Xpert.Ivy Propriétaire *** Hybrid Oui ** ***

Agiliti 1.4 Open Source *** Orienté

développeur

Non ** *

Processmaker Open Source *** Zero code Non * **

FIGURE 21: TABLEAU COMPARATIF DES OUTILS BPMS EN ACCÈS LIBRE

Comme on peut le voir dans le tableau ci-dessus, il n’existe pas une solution qui soit

supérieure à toutes les autres. En revanche, il existe des critères qui sont quasi éliminatoires

chez certaines. Ainsi Agiliti peut s’avérer très utile dans le cadre d’un développement logiciel

basé sur Java, mais il nécessite d’importantes bases de connaissances de ce langage pour

espérer utiliser des fonctions ne serait-ce triviales. Pour processmaker, c’est la qualité

médiocre de la modélisation et l’impossibilité de pouvoir utiliser certains éléments de BPMN

2.0 comme des lanes qui s’est avéré éliminatoire.

Parmi les deux solutions restantes, la solution Open Source de Bonita Soft dispose du

meilleur outil de modélisation des 4 solutions, elle est en revanche très incomplète en termes

de documentation au sujet de l’implémentation des processus. Xpert.Ivy possède quant à lui

le meilleur rapport entre la qualité de la documentation et la facilité de prise en main, mais

offre un outil de modélisation qui est déjà orienté très technique et peut s’avérer difficile à

utiliser pour modéliser des processus abstraits qui serviraient dans la partie pratique au

niveau de la modélisation.

Il a été très difficile de procéder à un choix d’une de ces solutions compte tenu que chacune

comportait un important risque pour la partie pratique. La qualité de modélisation proposée

par Bonita a toutefois surpassé les qualités documentaires de Xpert.Ivy, notamment parce

qu’il était possible de mieux documenter l’exécution des processus avec son recours. Mais il

s’est avéré depuis la sélection des outils en libre accès qu’aucun n’allait permettre de

pouvoir approcher un résultat de prototype qui soit évolué en raison de leur demande d’une

maîtrise étendue d’un langage de programmation ou de leurs lacunes fonctionnelles.


Partie pratique : Application du BPM Lifecycle dans une PME 50

5 PARTIE PRATIQUE : APPLICATION DU BPM LIFECYCLE DANS

UNE PME

5.1 BPM Lifecycle Phase 1 : Goal specification / Strategy

definition

Dans ce chapitre, il sera question de répondre à la question de recherché suivante: « Quels

sont les besoins qui vont nécessiter une approche processus au sein de la PME et comment

le web service e-dec pourra-t-il participer à celle-ci ? » en utilisant la première phase du BPM

Lifecycle.

5.1.1 BUSINESS CASE

stefan.huesemann

Sticky Note

Confidentiel


Manufacture (50%)

stefan.huesemann

Sticky Note

Confidentiel


FIGURE 23: INCOTERMS

stefan.huesemann

Sticky Note

Confidentiel


stefan.huesemann

Sticky Note

Confidentiel


stefan.huesemann

Sticky Note

Confidentiel


5.2 BPM Phase 2 : Process Design

La partie 5.2 va répondre à la question de recherche suivante « Quelle forme prendra la

modélisation de ce processus avec le standard BPMN 2.0 ? ».

5.2.1 DESCRIPTION DU PROCESSUS D’EXPORT DU POINT DE VUE DE L’ENTREPRISE

Le processus d’export du point de vue de Hans Werk AG est un sous processus du

processus de commande de montre. Celui-ci est décrit à la Figure 24. Il consiste en la

collaboration de 4 départements :

La vente qui établit les commandes

La facturation qui s’occupe de traiter les données financières

La logistique qui prépare les produits et se charge de l’expédition des marchandises

et des procédures relatives

La production qui crée les produits qui vont ensuite être envoyés et facturés aux

clients.

FIGURE 24: PROCESSUS DE COMMANDE DANS L'ERP


La procédure d’exportation contrairement aux procédures d’établissement de CITES (import

+ export) et de tâches liées à l’import dans le pays de destination possède un grand potentiel

de standardisation. Le service d’export de Hans Werk AG a toujours affaire au même

interlocuteur : la douane Suisse. Actuellement, le processus suit le déroulement décrit à la

Figure 25.

FIGURE 25: PROCÉDURE D'EXPORT ACTUELLE CHEZ HANS WERK

La procédure d’export actuelle compte sur le concours de transporteurs pour gérer les

interactions avec la douane Suisse. Hans Werk AG n’a qu’à envoyer les marchandises et il

reçoit en retour la DTE (Déclaration Taxation à l’Export). Cette pratique est contraire à la

volonté de la direction de posséder le savoir-faire lié aux exportations. De plus, elle n’assure

pas une bonne qualité de traçabilité des cas d’export et s’avère problématique lors du retour

de marchandises qui ont été laissées en vente en consignation, c’est-à-dire une vente où le

paiement de la marchandise est effectué lors de l’achat par le client final. Il est actuellement

difficile d’assurer la traçabilité de ces envois et d’associer l’import des montres à leur

exportation initiale. Ces situations nécessitent actuellement des heures de travail

administratif qui sont assumées au détriment d’autres tâches.

Le niveau de BPMM de l’organisation peut être estimé à 2. Des initiatives locales ont permis

la description des processus et leur gestion, mais l’entreprise ne dispose pas encore d’une

stratégie globale des processus ni d’une documentation exhaustive.

5.2.2 DESCRIPTION DU PROCESSUS D’EXPORT DU POINT DE VUE DE LA DOUANE SUISSE

La solution e-dec est née d’un constat. La procédure d’export qui prévalait alors, basée sur

la RSE (Réglementation Simplifiée sur les Exportations) et soutenue par le système


informatique MD90 n’était plus à même d’offrir un fonctionnement efficace au niveau

administratif de l’AFD (Administration Fédérale des Douanes), ni de s’adapter aux évolutions

du contexte douanier international qui promeut de plus en plus l’échange d’information sous

format électronique.

Afin de pallier à cette situation, la douane suisse a donc décidé de se lancer dans un projet

qui permette à la fois d’alléger la tâche de l’administration en termes de traitement de

données en abolissant la saisie manuelle et d’échanger facilement des informations avec

d’autres systèmes informatiques, tout en tenant compte des évolutions futures possibles.

Cette solution porte le nom de e-dec. Basée sur une architecture de type SOA, elle met à

disposition des déclarants plusieurs canaux pour réaliser les déclarations. L’email, un web

service et un une plateforme web. Alors que le premier médium ne sera pas traité dans ce

travail, les deux suivants font l’objet d’une description ci-dessous.

5.2.3 WEB SERVICE E-DEC

Le web service de e-dec utilisé dans le cas d’une déclaration d’export fonctionne comme

décrit à la Figure 26. Cette modélisation étant une adaptation en BPMN 2.0 de celle du

document Manuel e-dec exportation pour la clientèle externe et les entreprises ((AFD), 2012)

qui utilisait le langage UML.

FIGURE 26: FONCTIONNEMENT DE E-DEC EXPORT DU POINT DE VUE DE LA DOUANE


Il est à noter qu’une prise en charge du web service e-dec par le système du déclarant est

un prérequis s’il veut éviter une rupture de média. Son SI doit donc être à même de faire

appel au service e-dec et aux technologies qui y sont inhérentes et qui ont notamment été

décrites dans ce travail au chapitre 3.

5.2.4 E-DEC WEB

La solution e-dec web consiste en une mise à disposition d’un masque sur le portail internet

de la douane qui rend possible la saisie des données de déclaration et leur saisie après

correction. La mise sur pied de cette solution ne demande aucun prérequis technique de la

part du déclarant, si ce n’est de disposer d’un accès à internet et un navigateur web.

FIGURE 27: PORTAIL E-DEC WEB (E-DEC, 2013)

Si elle offre une bonne solution d’appoint, elle ne peut en aucun cas être considérée comme

une solution viable pour une entreprise qui exporte quotidiennement des marchandises. En

effet, elle provoque une rupture de média entre le système du déclarant et e-dec. Cette

procédure risque donc d’être la source d’erreurs et de générer de coûts administratifs élevés

relatifs à la saisie manuelle des donnés.

5.2.5 PROCESSUS D’EXPORT ENTRE L’ERP, LE BPMS ET E-DEC

Compte tenu d’une croissance importante du volume de cas d’exportation attendue dans

l’entreprise Hans Werk AG, il a été décidé d’implémenter le service web. Cela va impliquer

de recourir au BPMS pour réaliser l’interface entre l’ERP et e-dec. Cette implémentation va

nécessiter les tâches illustrées à la Figure 28 et décrites ci-dessous. Il est à noter que les


tâches de couleur rouge sont celles qui feront l’objet d’une implémentation dans le point

suivant de ce travail.

FIGURE 28 : PROCESSUS D’EXPORT AVEC ERP, BPMS ET E-DEC

La première tâche de ce processus est intitulée dans la Figure 28 Décision d’envoi de

montres. A ce stade, il faut comprendre qu’une commande réalisée auprès de Hans Werk

AG ne va pas donner lieu à un seul envoi correspondant à toutes les montres commandées.

En effet, il se peut que pour des raisons de disponibilité de stock il ne soit possible d’envoyer

qu’une partie de la commande ou alors qu’il soit décidé pour des raisons commerciales d’en

envoyer qu’une partie. La décision est prise par l’entreprise Hans Werk AG durant la séance

de vente hebdomadaire. Elle nécessite la concertation de la direction, du responsable de la

logistique et du responsable de la production.

La décision d’envoi de montres amène à la génération des factures relatives à l’envoi. La

facturation a en effet lieu sur les quantités livrées. Les informations présentes sur une facture


de l’ERP servent à a fois au paiement de cette dernière par le client, mais elle est aussi la

base informationnelle pour toute exportation.

FIGURE 29 : FACTURE ERP

En plus des montants pour chaque ligne, on notera la présence du champ HS Code. Un HS

Code étant un identifiant tarifaire défini par l’Organisation Mondiale des Douanes (OMD) qui

est une information demandée par les douanes du monde entier pour les processus d’export

et d’import. Dans l’exemple de la Figure 29, les deux articles de la facture diffèrent de par

leur code car la première position est une montre en acier (9102.) automatique (.2100), alors

que la seconde est une montre en or (9101.) manuelle (.2900). Il faut aussi noter que

l’imputation de la TVA dans l’ERP se déroule comme suit : chaque produit possède une taxe

par défaut qui est celle prévue par la loi ; chaque client doit être soumis à un régime fiscal. Il

en existe 2. Le premier est intitulé « conventionnel » et le second « Import/Export ». Lorsque

la marchandise est vendue en Suisse, c’est le régime conventionnel qui s’applique. Si la

marchandise est exportée, c’est alors le régime « Import/Export » qui va être retenu. Ces

deux options sont visibles sur la Figure 28.

Afin d’assurer la collaboration entre l’ERP et le BPMS, il sera à la fois nécessaire que l’ERP

soit capable de transmettre des données à chaque fois que la décision de livrer des produits

qui sont sujets au régime de taxes « Import/Export » est prise par l’entreprise Hans Werk

AG. Cette problématique pose des questions de responsabilité du traitement de ces tâches.


En effet, même si l’évènement déclencheur a lieu dans l’ERP, on peut se demander quel

système entre le BPMS et l’ERP sera le plus à même de traiter les données pour les rendre

conformes à e-dec. De plus, on peut aussi se demander si une infrastructure de type ESB ne

serait pas nécessaire pour réaliser les tâches de traitement de données. Ces questions

excèdent la problématique de la collaboration d’un BPMS avec un web service qui est le

sujet de la partie pratique de ce travail. Elles pourraient en revanche être au centre d’une

prochaine itération de BPM Lifecycle pour le processus d’export.

La mise en conformité des données qui succèdera à la réception des données consiste à

confronter les données reçues de l’ERP dans un format indéfini et à les transformer en un

fichier XML qui respecte le contrat d’interface de e-dec. Une fois cette tâche exécutée, il sera

possible d’envoyer des données grâce à l’appel du web service à e-dec. Cet envoi sera

vérifié par un test de plausibilité. Si celui s’avère négatif, les données seront renvoyées à

l’exportateur par le biais du web service et une demande de correction aura lieu. Si le test

est passé avec succès, il donnera lieu à l’envoi de la DDE au client. S’ensuivra la procédure

d’exportation décrite en détail à la figure Figure 26 et la clôture du cas d’exportation par la

réception de la DTE.


5.3 BPM Phase 3 : Implementation

La partie de ce travail répond à la question de recherche suivante : « Quelles tâches de

configuration seront nécessaires depuis la modélisation pour que le processus puisse

s’exécuter ? ». Elle va le faire par le biais d’un prototype d’implémentation qui va permettre

de comprendre les enjeux d’implémentation. Ce prototype est en annexe du travail.

5.3.1 CRÉATION DES INTERFACES DE VÉRIFICATION DES DONNÉES ISSUES DE L’ERP

Dans cette implémentation, on doit considérer que les données issues de l’ERP sont

générées par un évènement qui a eu lieu dans l’ERP. En effet, comme on peut le voir à la

Figure 28, c’est suite à une décision d’envoyer des montres et la facturation qui va suivre

que les données nécessaires à l’exportation seront générées. Comme cela a été énoncé au

point 5.2.5, la décision de traiter les données soit par l’ERP ou par le BPMS ne va pas être

traitée dans l’implémentation de ce travail. C’est pourquoi les données à vérifier ont dû être

générées, indépendamment de la source qui serait la leur dans le cas d’une implémentation

complète du processus.

Idéalement, il aurait été possible d’utiliser le XML Schema goodsDeclaration.xsd fourni par

l’AFD par le biais du document Service Contract für Zollanmeldung (AFD, 2012) pour

générer un fichier XML qui soit conforme à l’interface du service e-dec. Il s’est

malheureusement avéré lors des tentatives de générer un fichier XML depuis le fichier

goodsDeclaration.xsd que celui-ci était reconnu comme corrompu par le BPMS Bonita, alors

qu’un contrôle de celui-ci avec le logiciel XML copy editor affirmait au contraire qu’il était

conforme. Afin de pallier à ce problème, une solution d’appoint consistant à rentrer les

données de déclaration sous forme de variable a été retenue (voir 8.1). Etant donné que le

fichier goodsDeclaration.xsd gère aussi les dépendances entre les champs et ceux qui sont

nécessairement à remplir pour valider la déclaration, il a été décidé de procéder de la

manière suivante : d’abord réaliser une déclaration sur l’interface test de e-dec web (voir

5.2.4), puis utiliser les données demandées lors de la déclaration comme les champs à

entrer pour le cas. Les valeurs saisies dans ce cas de déclaration préalable ont été

configurées comme valeur par défaut. Cette manière de procéder donne donc à l’utilisateur

du BPMS la possibilité de valider au travers d’un formulaire tous les champs qui ont été

reconnus comme nécessaires à l’établissement de la déclaration test.

5.3.2 MISE EN FONCTION DU MOCK SERVICE E-DEC AVEC SOAP UI

SOAP UI est un logiciel qui permet de simuler un service depuis un fichier WSDL. Comme

cela a été expliqué au point 3.3.5, WSDL est un format qui gère le contrat de service d’un

web service. Il suffit donc d’indiquer à SOAP UI l’adresse à laquelle se trouve le fichier


WSDL et depuis ce fichier, il sera en mesure de réaliser plusieurs tâches que l’on peut

apercevoir dans la capture d’écran à la Figure 30. Sur la base de ces informations, SOAP UI

sera en mesure de réaliser un mock service, c’est-à-dire un service qui ne respecte pas

nécessairement l’implémentation du service cible et qui soit à même de contourner certaines

restrictions émanant de celui-ci. Cela a permis dans ce travail de contourner l’authentification

nécessaire et le recours à HTTPS sur l’interface test tout en pouvant analyser l’exécution

d’un service depuis le côté serveur pour ce qui est de l’échange d’informations, sans pour

autant avoir accès aux fonctions de l’ESB de e-dec.

FIGURE 30: CONFIGURATION DE SOAP UI AVEC FICHIER WSDL

Suite à la validation de cette fenêtre, il est possible par le biais de l’interface de SOAP UI de

visualiser un certain nombre d’informations concernant le service, comme on peut le voir à la

Figure 31.


FIGURE 31: INTERFACE SOAP UI

La visualisation des services au travers de cette interface permet d’analyser au travers du

contrat de service WSDL les bindings, soit les services pris en charge. On notera qu’ils sont

au nombre de deux. Le premier s’intitule goodsDeclaration, alors que le second – qui ne sera

pas traité dans ce travail car il est réservé à des exportateurs qui répondent à des conditions

particulières et qui se nomment exportateurs agréées se nomme selectionAndTransit.

Chacun de ces services est constitué d’une enveloppe SOAP (voir 3.3.4) qui va permettre au

client d’utiliser le service en envoyant celle-ci avec le recours d’un protocole de transport. Le

mock service utilisera l’adresse de la machine comme hôte.

5.3.3 CONFIGURATION DU WEBSERVICE DANS BONITA

Suite à la validation des données dans le BPMS, il va être nécessaire d’appeler le service

web e-dec. Dans Bonita, cette opération est possible par le biais d’un connecteur. C’est-à-

dire une interface qui gère l’appel de service par le biais d’un paramétrage. Dans sa version

payante Bonita Teamwork permet la configuration des web services par le biais d’une

interface dédiée et prenant en charge les fichiers de type WDSL. Ce travail académique

n’étant pas basé sur des solutions informatiques payantes, il aura été nécessaire de réaliser

le paramétrage sur l’interface basique pour les web services. Celle-ci est visible à la Figure

32.


FIGURE 32: INTERFACE CONNECTEUR SERVICE WEB DE BONITA

Cette tentative de configuration se sera avérée vaine pour qu’un appel du web service soit

possible. En revanche, les champs demandés à compléter pour connecter le service sont ci-

dessous documentés. Les champs suivants seront à renseigner depuis le fichier WSDL. :

1. Cible NS

La cible NS désigne le targetNamespace, soit l’endroit où est stocké le fichier WSDL. Cette

information est elle-même stockée dans le fichier WSDL sous l’attribut targetNamespace

visible à la Figure 33.

2. Nom de service

Le Nom de service désigne le nom associé au contrat de service. Il est disponible dans le

fichier WSDL sous l’attribut name visible à la Figure 33.


FIGURE 33: DEFINITIONS DU FICHIER E-DEC WSDL

Les deux premières informations demandées font partie de ce qui a été défini au point 3.3.5

comme étant l’interface abstraite du service.

3. Nom du port

Le Nom du port désigne une information qui lie un URL et un binding. Ce dernier étant une

association entre plusieurs paramètres présents dans le fichier WSDL et qui ont étés décrits

lors de la description de la Figure 31.

4. Requête

La requête est constituée de l’enveloppe SOAP qui est à transmettre au web service. Ici, les

variables sont celles qui ont été confirmées par l’utilisateur grâce au formulaire. La forme de

l’enveloppe SOAP est celle que l’on trouve dans SOAP UI sous la forme de l’enveloppe

associée à Request1 qui est visible à la Figure 31.

5. Adresse endpoint

L’adresse endpoint est la destination à laquelle l’enveloppe SOAP va être utilisée pour le

traitement. Ici, c’est l’adresse qui est fournie par SOAP UI et qui héberge le mock service.

C’est-à-dire que le contenu de l’enveloppe sera envoyé au mock service lancé par SOAP UI

et qu’une réponse correspondant lui sera envoyée.

6. Binding

Le binding a été configuré ici selon les informations présentes dans le mode d’emploi pour

les connecteurs disponible sur la page web. Il s’agit de la meilleure source à disposition pour

l’utilisation de connecteurs trouvée.

7. SOAP Action

SOAP Action désigne quelle action décrite dans le fichier WSDL va-t-être utilisée pour

traiter la requête.


5.3.4 RÉPONSE DU WEB SERVICE

La réponse du web service va être assumée par le mock service mis en place dans SOAP

UI. Ce programme va permettre pour la requête envoyée au endpoint de définir une requête

définissable à l’avance. Celle-ci sera basée sur le fichier WSDL et utilisera l’enveloppe

SOAP utilisée par le web service e-dec. Il est toutefois nécessaire de configurer ce fichier.

Dans ce travail, le fichier a été configuré de façon à donner une réponse qui soit identique à

celle obtenue sur l’interface test de e-dec web. C’est-à-dire un fichier XML contenant la

déclaration et un PDF. Ces informations sont disponibles dans leur format original à l’annexe

8.2. La Figure 34 illustre leur contenu.

FIGURE 34: DÉCLARATION EN FORMAT XML

5.3.5 INTÉGRATION DES RÉSULTATS DANS LE BPMS

Il est possible d’intégrer les résultats issus de la déclaration au niveau du connecteur. Pour

cela, il est nécessaire d’attribuer aux valeurs de retour du web service une variable présente

dans le processus, comme cela est illustré à la Figure 35. On notera encore ici que le BPMS

dans sa version testée n’a pas reconnu le fichier GoodsDeclaration.xsd comme valide. La

configuration ici est donc donnée par défaut avec comme valeur par défaut à cette opération

le fichier xml généré par l’interface test de e-dec web.


FIGURE 35: CONFIGURATION DU RETOUR DES DONNÉES DANS BONITA

Suite à l’intégration de ces données par le biais du connecteur, il faut encore rendre celles-ci

consultables dans le processus. Pour cela, un formulaire de consultation a été généré dans

la tâche de Réception de la DDE présente à la Figure 28 qui permette à l’utilisateur d’avoir

accès à ces variables une fois qu’elles ont été saisies correctement.


5.4 BPM Phase 4 : Process Runtime

Etant donné que le processus est non fonctionnel, il est difficile lors de cette première phase

du BPM Lifecycle de s’intéresser à son déploiement et à son monitoring. Il n’y a en effet pas

de charge de travail, ni de possibilité de le simuler dans son entier. Toutefois, il est possible

de consulter les éléments que le système BPMS a générés avec les données de

configuration qui lui ont été transmises.

5.4.1 UTILISATION DE LA USER XP

La User XP dans Bonita représente l’interface par laquelle les utilisateurs voient les

processus et les exécutent. Il s’agit en fait d’un Inbox dans lequel les utilisateurs reçoivent

des tâches qui sont de leur responsabilité lorsqu’elles s’exécutent. Cette User XP est

accessible aux utilisateurs depuis une interface web que l’on peut voir à la Figure 36

FIGURE 36: USER EXPERIENCE BONITA

Cette interface permet à l’utilisateur de gérer les tâches qu’il doit accomplir sous la forme

d’une boîte de réception. Lorsqu’il est considéré comme responsable d’un processus, il peut

aussi « Démarrer un cas » du processus. Ci-dessus, c’est le cas avec le processus Export

avec e-dec visible dans le menu horizontal.

5.4.2 CONTRÔLE ET SAISIE DES DONNÉES PAR L’UTILISATEUR

Lors du lancement du processus depuis la User XP, l’utilisateur doit remplir un formulaire qui

contient les données du cas d’exportation qui ont été sorties de l’ERP. Il peut modifier celles-

ci si elles s’avèrent fausses ou les saisir si elles sont incomplètes. Le formulaire réalisé à

cette occasion dans la tâche de saisie des données contient plusieurs pages. Chacune

d’entre elle représentant une rubrique de la déclaration d’export. On peut voir un aperçu du

formulaire à la Figure 37.


FIGURE 37: FORMULAIRE DE SAISIE ET DE CONTRÔLE DES DONNÉES


5.5 Phase 5 : Process Improvement

Comme on a pu le voir lors de cette tentative d’implémenter un processus, le recours au

BPM Lifecycle n’est en rien garant qu’un processus soit facile à implémenter et que toutes

les options choisies durant cette tentative soient les bonnes. En revanche, de BPM Lifecycle,

de par sa nature itérative, permet d’intégrer l’expérience de chaque itération pour améliorer

le processus par la suite. Dans ce travail, son recours permettra d’évaluer les enjeux d’une

telle implémentation et de définir ce qui peut être amélioré et comment. A cette fin, les

principaux éléments qui se sont avérés critiques sont ici mentionnés et pourront servir à une

prochaine itération du processus.

5.5.1 ENVOI DES DONNÉES PAR L’ERP

Afin de rendre le processus pleinement fonctionnel et optimal en termes de fonctionnement,

il est essentiel que la transition entre l’ERP et le BPMS se fasse de manière automatique.

Pour cela, il faudra configurer l’ERP et le BPMS pour que la décision d’envoyer des montres,

lorsqu’elle concerne des montres à exporter aboutisse à l’envoi des données pour les lignes

de commandes désignées.

Les données concernant cet export sont en grande majorité présentes dans l’ERP, comme la

Figure 29 en atteste avec notamment la présence des HS Code sur la facture. Il faut ici

remarquer que l’intégration des informations douanières sur la facture ne servent pas qu’au

processus d’export, mais rendent aussi possible l’importation dans les marchés cible. Cela

implique que ces informations devront figurer dans l’ERP afin de soutenir la totalité du

processus d’export. Il conviendra donc dans un premier temps de renseigner les objets

« articles » et « client » de l’ERP de manière optimale. Le BPMS pourrait ensuite jouer un

rôle important dans le contrôle de la validité de ces informations avant leur envoi à la

douane. C’est notamment ce qui sera expliqué au point 5.5.2.

5.5.2 UTILISATION DE FICHIERS XML DANS LE BPMS

Dans sa version actuelle, le prototype se base sur des variables indépendantes les unes des

autres à titre d’input de données du processus d’import. Si ce format brut et non structuré

pourrait être ce qu’un ERP serait à même de fournir comme données d’input à un cas

d’export, il est à noter que la communication entre le web service et le BPMS s’effectue à

l’aide de fichiers XML qui sont définis à l’aide de XML Schemas. Cette forme devrait être

utilisée afin de réaliser les interfaces de contrôle avant l’envoi des données. Les XML

Schemas stipulant la forme des variables, leur optionalité et d’éventuels liens avec d’autres

variables. Pour cela, le BPMS devra être à même de reconnaître le XML Schema Goods

Declaration, ce qui n’est pas le cas actuellement.


Dans sa forme actuelle, le connecteur du BPMS qui accède à e-dec nécessite qu’il faille

placer chaque variable dans l’enveloppe SOAP. Or il existe une extension payante qui va

rendre possible la gestion des fichiers XML et qui permette une configuration nettement plus

simple des variables, comme il est possible de le voir à la Figure 38.

FIGURE 38: INTERFACE DE CONNEXION WEB SERVICE PAYANTE DE BONITA (BONITASOFT, 2011)

De plus, ce module permet aussi de gérer le retour d’information sous la forme de fichier

XML, ce qui aurait permis un meilleur retour des informations.

5.5.3 GESTION DES RÉPONSES DE DÉCLARATION PAR LE BPMS

Un des intérêts d’un service comme e-dec est, comme cela a été illustré à la Figure 28, sa

capacité à pouvoir automatiquement déceler des erreurs dans la déclaration de douane et à

communiquer avec le déclarant. Or, le système du déclarant doit être à même de gérer cela

par le biais d’interfaces qui prennent en charge les différentes réponses, c’est-à-dire soit un

fichier à corriger, soit la consultation de la déclaration acceptée. Ces interfaces doivent elles

aussi se baser sur des XML Schema pour être générées. Elles pourront se baser sur

l’interface de contrôle des données à la sortie de l’ERP au niveau de leur layout et de leur


implémentation tout en intégrant les spécificités dues à la communication avec le web

service e-dec.

5.5.4 DÉFINITION DES RÔLES AUTOUR DU PROCESSUS DANS LA PERSPECTIVE D’UNE

IMPLÉMENTATION

Lors de cette première itération, il n’a pas été considéré que plusieurs personnes allaient

participer à l’exécution du processus. Or si on veut que celui-ci se passe selon un optimum, il

va falloir définir des responsabilités plus claires que ce n’est le cas actuellement. Par

exemple, les données transmises à e-dec depuis l’ERP devront toujours être à jour. Cette

responsabilité devra-t-être clairement assignée à quelqu’un dans l’entreprise afin d’éviter que

des informations incomplètes sortent de l’ERP. De plus, le recours au BPMS va demander

aux personnes de l’organisation de s’habituer à de nouvelles interfaces et à une nouvelle

manière de travailler. Il faudra à la fois offrir la formation nécessaire aux utilisateurs et gérer

le changement et toutes les réticences qu’il peut occasionner. De plus, cette implémentation

devra se faire avec la conviction et le soutien inconditionnel de la hiérarchie.

5.5.5 GESTION DES RESSOURCES

Tout projet informatique est soumis à un impératif budgétaire. Afin de rendre possible

l’intégration de e-dec dans le SI de l’entreprise, il va être nécessaire de procéder à des

investissements qui n’ont pas eu lieu dans cette première itération du BPM Lifecycle. Il

faudra en effet soit investir dans la solution Bonita pour la rendre utilisable selon les

exigences fournies par le web service e-dec en investissant dans des modules et du conseil,

soit utiliser une solution propriétaire qui soit à même de garantir que l’implémentation

fonctionne sans bug technique. Ce n’est donc qu’en fonction d’un budget donné qu’une

prochaine itération pourrait avoir lieu. Ce budget permettrait alors d’évaluer si les solutions

libres retenues pour ce travail sont à même de concurrencer les solutions propriétaires en

termes de rapport qualité/prix.

Conclusion 74

6 CONCLUSION

Comme cela a été démontré dans ce travail par le biais des questions de recherche qui ont

été traitées tout le long du travail, les approches SOA et BPM permettent aux dirigeants de

gérer des problématiques qui sont centrales dans toute organisation : la pérennité du

système d’information et le lien entre processus et création de valeur. Maîtriser les outils

conceptuels de SOA et BPM contribue indéniablement à une prise de décision stratégique

qui offre des avantages concurrentiels. L’approche SOA va en effet permettre au système

d’information de pouvoir développer des nouvelles fonctionnalités qui puissent être les plus

proches possibles des besoins de l’organisation. Quant à la gestion des processus offerte

par BPM, elle va être à même de toujours relier les activités réalisées dans l’entreprise au

but final de création de valeur et de mettre sur pied une philosophie d’amélioration continue.

En ayant pour objectif l’implémentation d’un processus d’export utilisant un web service issu

d’une SOA, ce travail a pu évaluer en pratique la collaboration des deux paradigmes. Il a

ainsi été possible d’étudier et d’interagir avec les interfaces du web service e-dec, lui-même

basé sur une SOA. Cette interaction s’est faite dans le cadre d’une méthodologie dédiée aux

processus : le BPM Lifecycle.

Cette démarche a nécessité une intégration des services passant par des outils BMPS et

avec l’utilisation du langage de modélisation et d’exécution BPMN 2.0. Ces outils se sont

avérés d’une très grande efficacité lorsqu’il a fallu identifier les fonctions cibles des acteurs

faisant l’objet de l’intégration, modéliser les processus, les documenter. Au travers du

modèle BPMM, le degré de maîtrise des processus a pu être situé et des objectifs ont pu

être placés. Il a aussi été possible, en vertu de la qualité du BPMN 2.0 de garder le même

modèle entre la phase de modélisation et d’exécution.

Les principaux problèmes qui sont apparus lors de ce travail sont liés au recours à un BPMS.

Les solutions en libre accès dans le domaine des BPMS se sont avérées inadéquates pour

implémenter un web service utilisant SOAP et WSDL. Ces lacunes auraient dû être relevées

plus tôt dans ce travail, notamment en évaluant la prise en charge des web services à la

partie 4.5.2. Les tentatives sur différents outils réalisées dans ce travail se sont soldées par

la mise sur pied d’un prototype non fonctionnel. Cela démontre que la gestion des processus

et leur intégration nécessite à la fois un investissement en ressources et une réflexion

organisationnelle et infrastructurelle. Un excellent degré de réflexion sur les processus ne

suffira pas à implémenter ceux-ci. Il faut disposer d’outils qui soient fonctionnels et qui

permettent d’interagir avec les web services sur des interfaces standardisées qui supportent

les standards WS*. Ces propriétés sont essentielles pour tirer profit des web services et afin

de rendre possible l’agilité promise par la rencontre entre SOA et BPM.

Conclusion 75

Pour s’assurer que la PME puisse disposer d’une solution d’export qui soit viable à l’avenir et

ceci grâce aux prochaines itérations du BPM Lifecycle, il faudra prendre une décision au

niveau de l’orchestration des processus. Soit celle-ci devra être laissée à l’ERP actuel et les

processus soutenus seront ceux qui feront l’objet de développement par l’éditeur et la

communauté open source qui le soutient, ou alors la PME pourra faire le choix d’investir

dans une solution BPM qui soit conforme aux spécificités techniques du service e-dec. Dans

les deux cas de figure, ce travail pourra servir de base pour réaliser soit un module qui

permette la collaboration directe entre l’ERP et le web service e-dec, soit pour intégrer dans

la PME une politique de gestion des processus qui soit basée sur un BPMS. Cette dernière

option sera sans doute la plus intéressante pour l’entreprise si elle entend profiter de toute la

puissance des outils de BPM. Il lui serait alors possible de pouvoir adapter son SI aux

processus de manière optimale. Pas uniquement pour des cas concernant l’export, mais

pour tous les processus de l’entreprise.

Pour réaliser cette vision, il faudrait traiter des points laissés ouverts par ce travail. Il faudrait

tout d’abord commencer par une étude approfondie de l’offre faite aux PME pour intégrer de

tels systèmes, tant au niveau de la solution logicielle - et de l’architecture qu’elle implique -

qu’au niveau de la formation des utilisateurs. Car comme ce travail l’a montré, l’explication

des concepts théoriques n’est en rien garante qu’une solution BPMS fonctionne sans

difficultés techniques. Si les concepts sont nécessaires ne serait-ce qu’à la formulation des

besoins qui motivent le choix d’un BPMS, un lien contractuel avec un fournisseur de solution

sera une garantie importante pour que les processus puissent s’exécuter.

Un autre point laissé ouvert par ce travail concerne la collaboration entre le management de

l’entreprise et les personnes responsables des processus. Il sera nécessaire que le

management puisse, en ayant consulté ce travail, se faire une idée précise sur les

approches BPM et SOA et qu’il leur attribue des ressources et des buts qui cadrent avec la

stratégie de l’organisation. Pour cela les objectifs des itérations suivantes de BPM Lifecycle

devront impérativement être définis à l’aide de métriques quantifiables. Car même si le

langage de modélisation de BPMN 2.0 facilite la communication entre les différents acteurs

impliqués dans la gestion des processus, c’est bien l’adéquation avec les objectifs fixés qui

va être garante que le BPM et SOA soient des approches pertinentes et qui permettent à

l’organisation de créer de la valeur.

Bibliographie 76

7 BIBLIOGRAPHIE

AFD, 2012. Manuel e-dec exportation pour la clientèle externe et les entreprises, Berne: Confédération helvétique.

AFD, 2012. Service Contract für Zollanmeldung, Berne: Confédération helvétique.

BonitaSoft, 2011. Bonita Connector Reference Guide, Grenoble: BonitaSoft SA.

BPMS Maîtriser la complexité, 2012. bpms.info. [En ligne] Available at: http://www.bpms.info/index.php/component/option,com_glossary/Itemid,75/catid,95/func,view/term,BPMM/ [Accès le 01 03 2013].

BPtrends, 2007. SOA Maturity Model. [En ligne] Available at: http://bpmg.orgwww.bptrends.com/publicationfiles/04-07-ART-The%20SOA%20MaturityModel-Inagantifinal.pdf [Accès le 17 03 2013].

Brocke, J. V. & Rosenmann, M., 2009. Handbook on Business Process Management 1. Heidelberg: Springer.

Caseau, Y., 2011. Urbanisation, SOA et BPM. Paris: Dunod.

Collectif, 2009. Encyclopedia of Information Science and Technology. New York: Information SCI.

CSB, 2013. Site web CSB. [En ligne] Available at: http://csbapp.csb.uncw.edu/janickit/mis213/learning/module8/8-2.htm [Accès le 01 04 2013].

Cummins, F. A., 2009. Building the Agile Enterprise. Burlington: Elsevier.

Cummins, F. A., 2009. Building the agile enterprise with SOA BPM and MBM. Burlington: Morgan Kaufmann Publishers.

e-dec, 2013. e-dec web. [En ligne] Available at: https://e-dec-web-a.ezv.admin.ch/webdec/index_webdec.xhtml?cid=43714 [Accès le 17 03 2013].

Erl, T., 2005. Service-Oriented Architecture: Concepts, Technology, and Design. Boston: Pearson Education.

Erl, T., 2011. SOA Governance. Boston: Pearson Education.

Fournier-Morel, 2011. SOA Le guide de l'architecte d'un SI agile. Paris: Dunod.

Gartner, 2013. [En ligne] Available at: http://www.gartner.com/it-glossary/business-process-management-bpm/ [Accès le 01 04 2013].

Haas, H., 2012. WSDL 2.0 : Décrire Les Services Web. [En ligne] Available at: http://www.w3.org/2004/Talks/1125-hh-fi/slide14-0.html [Accès le 13 02 2013].

Hammer&Champy, 2003. Reengineering the Corporation: Manifesto for Business Revolution. 2e éd. New York: HarperCollins.

Bibliographie 77

Hüsemann, S., 2012. Cours Systèmes d'information. Fribourg: Université de Fribourg.

IBM, 2012. SOA Best Practice. [En ligne] Available at: http://www.ibm.com/developerworks/webservices/tutorials/ws-soacert1/section2.html [Accès le 19 01 2013].

Josuttis, 2009. SOA in der Praxis. Heidelberg: dpunkt.verlag.

Jozwiak, N., 2013. Xebia. [En ligne] Available at: http://blog.xebia.fr/2008/04/10/urbanisation-pour-les-nuls/ [Accès le 15 03 2013].

Krawler, 2009. Krawler. [En ligne] Available at: http://blog.krawler.com/tag/uddi/ [Accès le 12 12 2012].

Krogstie, G. A. a. J., 2010. Analysis and Design of Business Processes in Handbook on BPM. Berlin Heidelberg: Springer.

Küng, P., 2011. Prozessmanagement. Fribourg, Universität Fribourg.

Larousse, 2012. Définition cybernétique. [En ligne] Available at: http://www.larousse.fr/dictionnaires/francais/cybern%C3%A9tique/21262 [Accès le 16 10 2012].

Larousse, 2012. Définition information. [En ligne] Available at: http://www.larousse.fr/dictionnaires/francais/information/42993 [Accès le 16 10 2012].

Larousse, 2012. Défintion de système. [En ligne] Available at: http://www.larousse.fr/dictionnaires/francais/syst%C3%A8me/76262 [Accès le 16 10 2012].

Laudon, 2010. Management des systèmes d'information. Paris: Pearson Education.

Longépé, C., 2004. Le projet d'urbanisation du SI. 2e éd. Paris: Dunod.

Morley, 2011. Processus Métiers et Systèmes d'Information. Paris: Dunod.

OCTO Technology, 2002. Architecture de systèmes d'information livre blanc. [En ligne] Available at: http://www.dsi.cnrs.fr/methodes/gestion-projet/methodologie/OCTO-architecture-des-SI.pdf [Accès le 01 04 2013].

OMG, 2013. BPMM Specification. [En ligne] Available at: http://www.omg.org/spec/BPMM/1.0/ [Accès le 01 04 2013].

Quaine, N., 2012. [En ligne] Available at: http://www.soapuser.com/basics3.html [Accès le 01 03 2013].

Rudolf Grünig, R. K., 2009. Planifier la stratégie. Lausanne: PPUR.

Shapiro, R., 2012. BPMN 2.0 Handbook. Lighthouse Point: Future Strategies.

Shapiro, R. M., 2008. XPDL 2.1 Integrating. Hingam: Workflow Management Coalition.

Swenson, K., 2009. Model Strategy:, Cohasset: WfMC.

Bibliographie 78

Tannenbaum, A., 2008. Réseaux. Paris: Pearson Education.

Tridens, 2011. Tridens. [En ligne] Available at: http://www.tridens.si/wp-content/uploads/2010/04/diagram-soa.jpg [Accès le 22 01 2013].

Wikipedia/Service, 2012. Wikipedia/Service. [En ligne] Available at: http://fr.wikipedia.org/wiki/Service [Accès le 19 01 2013].

Wikipedia, 2012. Système d'information. [En ligne] Available at: http://fr.wikipedia.org/wiki/Syst%C3%A8me_d'information [Accès le 01 04 2013].

Wikipedia, 2012. XML Schema. [En ligne] Available at: http://fr.wikipedia.org/wiki/XML_Schema [Accès le 12 12 2012].

Workflow Management Coalition, 2012. [En ligne] Available at: http://www.wfmc.org/ [Accès le 04 01 2013].

Zaiaine, O. R., 2013. ualberta.ca. [En ligne] Available at: http://webdocs.cs.ualberta.ca/~zaiane/courses/cmput690/slides/Chapter2/sld021.htm [Accès le 01 04 2013].

Annexes 79

8 ANNEXES

8.1 Annexe 1 : Prototype d’implémentation dans BonitaSoft

Sur support informatique

8.2 Annexe 2 : Documents issus du service e-dec

Sur support informatique