Business Process Management

De la modlisation lexcution
Positionnement par rapport aux Architectures Orientes
Services
PARTIE 1

Extrait du BPM Whitepaper de Tanguy Crusson socit Intalio

Plan
INTRODUCTION AU BPM
LIMPORTANCE DE LA STANDARDISATION
PROCESSUS MTIER : DE LA MODLISATION
LEXCUTION
ARCHITECTURES ORIENTES SERVICES
CONCLUSION

2
BUSINESS PROCESS MANAGEMENT

INTRODUCTION AU BPM
LIMPORTANCE DE LA STANDARDISATION
PROCESSUS MTIER : DE LA MODLISATION
LEXCUTION
ARCHITECTURES ORIENTES SERVICES
CONCLUSION

3
 Constat sur la gestion actuelle des
processus 1/4

Collaboration difficile entre les acteurs dfinissant

les processus
profils diffrents, et peu habitus collaborer,
utilisant des concepts et outils compltement
diffrents
Equipe mthode: dfinissent les recommandations
pour la modlisation des processus mtier
Equipe mtier : dfinissent les processus mtiers
de haut niveau, les cas dutilisation et les scnarios
dtaills, en sappuyant sur les recommandations des
quipes mthode
Equipe technique : transposent ces processus en
terme dapplications, services et intgration de
lexistant, en capitalisant sur le systme
dinformation (SI) de lentreprise

4
 Constat sur la gestion actuelle des
processus 2/4
Time to Market trop important pour passer de la
modlisation lexcution des processus, puis pour
modifier les processus existants et rendre ces
modifications effectives
Modlisation du Dploiement
Modlisation
processus mtier,
fonctionnelle et
technique

Dploiement

Excution se basant sur Interaction des utilisateurs

les applications avec ce processus
existantes de lentreprise Excution Interaction (contrle dexcution,
optimisation)

Cycle de vie dun processus

5
 Constat sur la gestion actuelle des
processus 3/4
Il nexistait pas jusquici doutil unique
permettant aux acteurs ralisant les
processus de collaborer
Pour raliser un processus excutable, il y a
actuellement cinq tapes :
1. Modlisation par les utilisateurs mtiers dans un outil.
2. Nouvelle modlisation par lquipe technique sans
pouvoir capitaliser sur les processus modliss dans
ltape prcdente.
3. Phase dimplmentation (o la majorit du code est
ralis la main).
4. Dploiement du code ralis
5. Recette technique et fonctionnelle.

6
Constat sur la gestion actuelle des
processus 4/4
Elments sensibles
La rupture existant entre la modlisation mtier et la modlisation
technique entrane des dcalages entre les besoins exprims au dpart
et les applications effectivement ralises
Une fois le processus dploy, la phase dinteraction permet de
loptimiser. Cette phase permet, au niveau technique et mtier,
didentifier les modifications effectuer. Pour les raliser, on entre alors
dans une autre phase de modlisation, et ce cycle se rpte. Comme il
existe une rupture entre la modlisation fonctionnelle et la modlisation
technique, il est complexe de maintenir les deux spcifications
cohrentes et de les rendre volutives. Gnralement, aprs trois
itrations, il est plus simple de redvelopper lapplication hbergeant le
processus que den modifier limplmentation.
Points damliorations
il devrait tre possible dimporter les dfinitions des processus mtiers
dans les outils techniques pour ajouter le lien avec les applications du
SI
les capacits de modlisation mtier et technique des outils devraient
permettre de dployer directement les processus modliss sans passer
par une phase dimplmentation

7
Constat sur la gestion actuelle des
processus 5/5
Pour rsumer, il est ncessaire de fournir un
modle et des outils permettant aux
quipes mtier, mthode, et technique de
collaborer pour la dfinition, le
dploiement, lexcution et le contrle de
processus permettant de capitaliser sur les
applications du systme dinformation
(intgration) et de mettre en jeu des
actions utilisateurs (workflow).

8
Les limitations des solutions actuelles

Les solutions actuelles nadressent que partiellement

ces besoins. Nous verrons en particulier les
limitations des outils
de Workflow,
dEAI,
de B2Bi,
les progiciels intgrs
et les moteurs de rgles mtiers

9
Les limitations des solutions actuelles:
Le Workflow
Le Workflow peut tre dfini comme lautomatisation de processus mtiers
par change de documents, informations et tches entre acteurs pour
action . Le workflow a pour objectif la coordination automatise de
tches ralises par des intervenants humains.
Le moteur de workflow transfre des documents entre les participants dun
processus en leur assignant des tches (valider le document, effectuer
une modification, etc.).

Avantages:
les concepts sont clairs,
les outils relativement aiss mettre en place.

Inconvnients:
les participants humains, on ne tient pas compte des applications du
systme dinformation. Lintgration du workflow aux systmes est une
tche difficile qui ncessite beaucoup de code propritaire
Les documents et les tches ne sont pas suffisants pour
lautomatisation des processus mtiers. Il est ncessaire davoir un
niveau dabstraction supplmentaire, o lon parle plus gnralement de
services, et dinformations.
10
Les limitations des solutions actuelles:
LEAI Enterprise Application Integration 1/2
EAI signifie intgration des applications dentreprise . A lorigine, les
progiciels EAI avait pour vocation la collaboration des applications
dune entreprise pour accomplir des objectifs mtiers, mais dans
les faits leur utilisation est beaucoup plus technique.

Les fonctions de lEAI sont :

Connectivit : fournir les interfaces daccs aux applications,
gnralement par lutilisation de connecteurs propritaires
difficilement maintenables ;
Transformation : fournir les services de transformation de
donnes permettant de crer un niveau dabstraction au dessus
des applications du SI un format pivot pour reprsenter les
donnes du SI (factures, bons de commande, etc.), et des
transformations pour les mapper vers les formats propritaires
attendus par les applications ;
Routage : fournir les services permettant de localiser
dynamiquement le destinataire dun message en fonction de son
contexte.

11
Les limitations des solutions actuelles:
LEAI Enterprise Application Integration 2/2
Avantages
Rutilisabilit: il permet de capitaliser sur les applications
existantes : lapplication de facturation rcupre les bons de
commande pour gnrer automatiquement les factures, etc.
Cest une rponse au souci technique dintgration mais
malheureusement cela ne suffit pas

Inconvnients
Les fonctionnalits de gestion des processus mtiers des
outils dEAI sont gnralement complexes utiliser et
dissocies de loffre technique dintgration
Les processus sont dfinis un niveau technique, et les
dcideurs nont aucune visibilit sur leur SI
Il est impossible de rconcilier cette vision avec la vision
workflow : comment faire intervenir les utilisateurs dans les
processus ?

12
Les limitations des solutions actuelles:
Le B2Bi Business to Business integration
Les outils de B2Bi visent dfinir les processus de collaboration
entre entreprises partenaires, partant du principe que les
processus intra-entreprise, donc dEAI, nont pas les mmes
contraintes que les processus externaliss.
Le rsultat est que ces outils fournissent surtout un moyen
technique de surveillance dune collaboration avec un
partenaire : gestion de la scurit des changes, fiabilit du
transport (le bon de commande a bien t envoy, et reu
par le partenaire), support des protocoles EDI, etc. Cela
pose un certain nombre de problmes :
Ces outils doivent pouvoir collaborer avec les outils dEAI
les processus B2B se dclinant en un processus interne par
participant de la collaboration ;
Pourquoi avoir deux outils diffrents pour les processus
internes et externaliss ? Ces deux types de processus
participent en ralit au mme processus mtier !

13
Les limitations des solutions actuelles:
Les progiciels intgrs
Les progiciels intgrs sont une solution cl en main : des progiciels
tels que ceux de SAP ou CommerceOne fournissent une solution
complte deProcurement, de comptabilit, de facturation, etc.
Le problme qui se pose ici est celui de ladaptabilit :
La mise en place dun tel progiciel demande un long projet de
paramtrage et dadaptation. Lentreprise sadapte aux processus
dfinis par le progiciel et non linverse
Pour modifier un processus, il est ncessaire de customiser la
plateforme. Cela peut savrer coteux et problmatique dans le
cas de migration de version par exemple. De manire plus
gnrale, il nest pas ais dadapter un processus pour rpondre
un besoin mtier urgent et critique
Les progiciels changent rgulirement de versions, en stoppant le
support des versions prcdentes, ce qui force la mise jour. Le
principal problme est que les outils de migration ne prennent pas
en compte les customisations du progiciel, qui sont invitables ! Il
est donc ncessaire de refaire les customisations sur la nouvelle
version aprs migration.

14
Les limitations des solutions actuelles:
Les moteurs de rgles mtiers
Les moteurs de rgles mtiers (Business Rules Engine)
permettent de modliser les rgles mtiers de
lentreprise, par exemple un bon de commande reu
de la part de tel client doit tre traite par telle
division du service commercial

Ces outils sont indispensables pour automatiser les

processus mtiers de lentreprise. Ils permettent en
particulier de formaliser et automatiser les prises de
dcisions sur la branche du processus choisir, en
fonction du contexte du processus.

Par contre, ces solutions doivent obligatoirement tre

couples dautres outils, permettant de grer les
processus.

15
Le BPM: enjeu et objectif
Lenjeu du BPM est dunifier sous un seul outil
toutes ces visions, pour fournir lentreprise la
possibilit de dfinir ses processus au niveau
mtier, et de faire intervenir les utilisateurs et
les applications de lentreprise en tant que
partie prenante ces processus.

Lobjectif est de permettre aux dcideurs,

analystes mtiers, quipes fonctionnelles et
quipes techniques de collaborer pour la
dfinition et lvolutivit des processus mtiers
via un seul outil agrgeant les diffrentes
visions
16
 Le BPM: les niveaux
Un processus mtier est modlis en plusieurs niveaux, et plus
gnralement en trois niveaux :

mtier: vue mtier haut niveau du processus, dfinissant ses

principales tapes et limpact sur lorganisation de lentreprise. Ce
niveau est dfini par les dcideurs, et les quipes mthodes de
lentreprise.

fonctionnel: formalisation des interactions entre les participants

fonctionnels du processus, o sont formalises les rgles mtiers
conditionnant son droulement. Ce niveau est modlis par les
quipes fonctionnelles.

technique: lien entre les activits / participants modliss dans le

niveau fonctionnels, et les applications / services du SI, ainsi que
les tches utilisateurs (Workflow). Ce niveau est ralis par les
architectes et les quipes techniques de lentreprise.
17
Processus mtier : dfinitions
Le terme de processus mtier est
souvent utilis tort et travers pour
dsigner des notions diffrentes :
processus excutable, processus
abstrait, processus collaboratif, etc.
Processus mtier
Processus collaboratif
Processus excutable

18
Processus mtier : dfinitions
Processus mtier
Un processus mtier est une chorgraphie
dactivits incluant une interaction entre
participants sous la forme dchange
dinformations. Les participants peuvent tre :
Des applications / services du SI
Des acteurs humains
Dautres processus mtiers

19
Processus mtier : exemple
Exemple: processus
mtier de gestion des
bons de commande
Cet exemple fait intervenir
deux participants :
Le dpartement marketing
de lentreprise,
et un processus
automatis de gestion des
bons de commande

20
Processus mtier
Processus collaboratif: dfinition
Un processus collaboratif est un processus mtier mettant en jeu des
entreprises partenaires. Un processus collaboratif incluant n
partenaires est compos de deux parties :
une interfaces
et n implmentations

Linterface dfinit la partie visible du processus, c'est--dire le contrat

entre les partenaires :
dfinition des documents mtiers changs,
du squencement des activits,
des rles et responsabilits de chaque partenaire
Lexcution spcifique de chaque partenaire est abstraite grce cette
interface

Les implmentations une pour chaque partenaire dfinissent le

comportement interne de chaque partenaire pour raliser le processus,
et respecter les contraintes dfinies dans linterface publique

21
 Processus mtier
Processus collaboratif: exemple 1/2
Processus collaboratif de gestion de commande mettant en jeu
trois partenaires un client, un fournisseur et un sous traitant

22
Processus mtier
Processus collaboratif: exemple 2/2
Voici un exemple dimplmentation, pour le partenaire sous
traitant du processus ci-dessus (les activits en bleu
correspondent aux activits prsentes dans linterface)

23
Processus mtier
Processus collaboratif (suite)
Un processus collaboratif est plus communment appel
processus mtier B2B . Il met en jeu une interface
publique et des implmentations prives, qui sont souvent
appeles processus mtiers EAI

Un certain nombre dorganisations dfinissent des interfaces

publiques standards, de manire verticale ou horizontale,
permettant aux entreprises de formaliser leurs
collaborations commerciales. Ainsi :
Un consortium dentreprises dans le domaine de llectronique
ont dfini RosettaNet, qui dcrit les processus et les
documents changs dans le domaine de llectronique :
traitement dune demande de devis, dun bon de commande,
etc.

OAGIS dfinit les processus et les documents changs de

manire transverse tout corps de mtier

24
Processus mtier
Processus excutables
Un processus peut tre rendu excutable de trois
faons
Il peut orchestrer les applications
services du SI
ainsi que des actions utilisateurs pour rendre une
tche automatise.

Par exemple, un processus de gestion de bons de

commande va recevoir les bons de commande
via des messages XML, les transmettre aux
personnes adquates, se renseigner sur la
disponibilit des lments commands dans les
bases de donnes de lentreprise, etc.
25
Processus mtier
Processus excutables (suite)
Ceci dit, rendre un processus excutable ne signifie pas
ncessairement lautomatiser
Par exemple un processus peut uniquement tre lautomatisation
de la transmission dinformations entre acteurs (approche
Workflow), les actions tant effectues manuellement par les
utilisateurs.

Lavantage du BPM est de pouvoir mlanger les concepts :

workflow et intgration

Rendre un processus excutable peut aussi signifier introduire des

points de contrle pour permettre le contrle de son
droulement. On parle alors de processus de BAM Business
Activity Monitoring. Ainsi, les outils de BPM peuvent tre
utiliss pour construire des dashboards destination des
dcideurs leur permettant de suivre les processus et danticiper
les erreurs

26
BUSINESS PROCESS MANAGEMENT

INTRODUCTION AU BPM
LIMPORTANCE DE LA STANDARDISATION
PROCESSUS MTIER : DE LA MODLISATION
LEXCUTION
ARCHITECTURES ORIENTES SERVICES
CONCLUSION

27
Objectif : des outils collaboratifs
La standardisation du BPM se fait diffrents niveaux :
Modlisation du processus: il est ncessaire davoir une notation
graphique commune tous les outils de modlisation, et un format
dimport / export, pour que les outils de modlisation et les outils
dimplmentation puissent communiquer. La notation graphique doit
permettre la modlisation mtier, et le renseignement des informations
techniques pour rendre les processus excutables.

Excution du processus: les lments dploys et excuts sur les

serveurs BPMS doivent tre standards pour garantir une portabilit des
processus raliss sur diffrentes plateformes (exemple de java). Cela
permet aux entreprises de saffranchir dun diteur particulier pour
choisir les outils pour leur valeur ajoute cot, robustesse, facilit de
prise en main, ractivit du support, etc.

Connectivit: les applications participant au processus doivent si

possible fournir des connecteurs standards et indpendants de toute
architecture : systmes dexploitation, bases de donnes, plateforme
(Java, .Net), etc.

28
Les acteurs de la standardisation
Comme sur tout sujet novateur, il existe
deux types dacteurs pour la
standardisation :
les innovateurs,
et les organismes dindustrialisation

29
Les acteurs de la standardisation:
les innovateurs
BPMI.org Business Process Management
Initiative dfinit le socle de BPM

Il rassemble les leaders du march :

De la modlisation de processus : Aris, MEGA,
Rational, Popkin
De lEAI : WebMethods, SeeBeyond, Vitria
De lapplicatif : IBM, BEA
Du Workflow : Fujitsu, FileNet, Staffware
Des ERP : SAP, PeopleSoft, Siebel

30
Les acteurs de la standardisation:
les innovateurs (suite)
BPMI.org propose ce jour trois spcifications
BPMN Business Process Modeling Notation.
BPML Business Process Modeling Language, qui a
servi de base au standard BPEL Business Process
Execution Language soumis OASIS par Intalio,
IBM et Microsoft.
BPQL Business Process Query Language.

31
Les acteurs de la standardisation:
les organismes dindustrialisation
Une fois les spcifications stabilises, leur viabilit
dpend de leur adoption par les diteurs, et par un
organisme de standardisation indpendant. Pour cela,
les spcifications ralises dans le cadre du BPMI.org
sont soumises deux organismes :
OASIS Organisation for the Advancement of
Structured Information a form un groupe de
travail, regroupant entre autres Intalio, IBM, Microsoft
et BEA, pour ladoption de BPEL comme standard pour
lexcution des processus mtiers
OMG Object Management Group qui maintient la
spcification UML, tudie BPMN comme standard de
reprsentation graphique des processus mtiers, pour
lintroduire en tant que nouveau diagramme UML 2.x.
Le W3C, qui standardise les spcifications XML

32
La modlisation des processus:
Utilisation de UML
UML Unified Modeling Language propose des
diagrammes spcialiss (dont les diagrammes
dactivit, de squence, de classe, etc.) ayant chacun
une fonction prcise.
Il nexiste pour le moment pas de diagramme UML
spcialis pour la modlisation des processus mtiers.
UML propose cependant un mcanisme dextensibilit
permettant de spcialiser chaque diagramme pour
une utilisation particulire.
Il est par exemple possible de spcialiser les diagrammes
dactivit pour la modlisation des processus mtiers -
un tel profil UML est propos par IBM sur son site
developerworks

33
La modlisation des processus:
La rponse par les standards : BPMN
En rponse la RFP soumise par lOMG, et aux contraintes dexcution des
processus modliss, le BPMI.org a propos la spcification BPMN
Business Process Modeling Notation

Lobjectif de BPMN est double :

Fournir une notation graphique complte permettant de reprsenter un
processus mtier en dcouplant les informations mtiers des informations
techniques qui fournit un cadre de travail commun aux utilisateurs mtiers
et techniques ;
Fournir un mapping complet vers les langages dexcutions. Ainsi, une fois
les processus modliss par les utilisateurs mtiers, et les informations
techniques renseignes pour rendre le processus excutable
applications/services du SI appeler pour raliser les activits, rgles de
transformation, etc. il est possible de gnrer automatiquement, et de
manire standard, le processus BPEL excuter par le moteur de
processus.

La spcification BPMN est actuellement en version 1.0, et 2.O en RFP. Cette

spcification est le gage dinteroprabilit des outils de modlisation de
processus mtiers.

34
Lexcution des processus
En ce qui concerne lexcution des
processus mtiers, le premier langage
qui ft propos est BPML Business
Process Modeling Language.
Pour des raisons marketing, ce langage
a t adapt et renomm BPEL
Business Process Execution Language

35
Lexcution des processus:
Concepts
BPEL est la reprsentation XML dun processus excutable, qui peut
tre dploye sur nimporte quel moteur de processus mtier.
Llment atomique dun processus BPEL est une activit ,
qui peut tre lenvoi dun message, la rception dun message,
lappel dune opration (envoi dun message, attente dune
rponse), ou une transformation de donnes. BPEL offre les
fonctionnalits suivantes :

Organisation des activits : activits squentielles, parallles,

switch conditionnel, etc.
Gestion des erreurs : il est possible de dfinir des gestionnaires
derreurs pour des erreurs spcifiques mtier ou techniques.
Des erreurs peuvent tre dclenches, traites ou ignores ;
Gestion des transactions : il existe deux modes de transactions
les transactions courtes XA ou 2-phase commit et les
transactions longues ou transactions compenses.
Organisation du processus en sous processus.

36
Lexcution des processus:
Concepts (suite)
Un processus BPEL dfinit, en XML, les activits ralises dans
le cadre de lexcution du processus mtier. Toutes les
informations techniques ncessaires sont dcrites.

<process>
<partners/> // Dfinition des partenaires (WebServices)
<containers/> // Dfinition des conteneurs de donnes
<sequence>
<receive/> // Rception dune requte
<assign/> // Transformation de donnes
<invoke/> // Appel de Web Service
<assign/> // Transformation de donnes
<reply/> // Envoi de la rponse
</sequence>
</process>
37
Lexcution des processus:
Concepts (suite)
Le nom exact de la spcification BPEL est BPEL4WS Business Process Execution
Language for Web Services. Ce nom est trompeur car un processus BPEL ne se limite
pas lorchestration de Web Services : il est aussi possible dinclure des connecteurs
transactionnels comme des EJB ou des procdures stockes SQL. Pour cela BPEL
repose sur les capacits dextension de WSDL, le langage de dfinition des interfaces
Web Services.
Un processus peut donc tre utilis pour orchestrer tout type de ressources
techniques: on capitalise sur les applications du SI.

Procdure Processus Web Service

stock JDBC SOAP
BPEL

RMI

EJB
38
Lexcution des processus:
Lintrt dun langage interprt
Il y a deux alternatives pour rendre un processus modlis
excutable:
La premire est la technique classique de gnration de code
la seconde est la gnration dun document interprt par un
serveur de processus (le couple BPMN/BPEL)

La technique de gnration de code est trs controverse:

Le code gnr est rarement complet
il est souvent ncessaire deffectuer des modifications dans
le code mme, ce qui rend lvolutivit des lments
modliss assez difficile
manque de flexibilit et dvolutivit de cette approche. Le
modle gnr nest pas rutilisable.
Un processus BPEL peut tre agrg dautres processus
BPEL pour crer des processus de plus haut niveau, cela est
rendu difficile voir impossible par la gnration de code.

39
La connectivit vers les applications
Les outils dEAI trouvent la justification de
leurs cots dans la batterie de connecteurs
propritaires quils proposent, permettant
daccder aux applications / progiciels du
SI.
Ces technologies sont cependant en cours de
banalisation : les Web Services simposent
graduellement comme les connecteurs
standards applicatifs

40
La connectivit vers les applications:
Web Services : dfinition
Un Web Service est un composant mtier ou technique
accessible par des protocoles standards

Cette technologie est la premire technologie dintgration

faisant abstraction des dtails dimplmentation :
Un service est dcrit dans une interface standard.
Il est accessible par change de messages XML. Un
Web Service est donc accessible depuis nimporte
quelle plateforme, ou langage de programmation.
Son interface peut tre publie et dcouverte dans
un annuaire.

41
La connectivit vers les applications:
Web Services : dfinition (suite)
Le schma suivant positionne les spcifications
formant le socle des Web Services :
SOAP Simple Object Access Protocol : format
des messages changs pour invoquer un Web
Service
WSDL Web Service Definition Language :
langage de dfinition des interfaces des services
offerts
UDDI Universal Description, Discovery and
Integration : annuaire des Web Services.

42
 La connectivit vers les applications:
Web Services : dfinition (suite)
Web service
Client du
web service Implmentation
Interface

SOAP

Applications du
SI

UDDI

Public standard Priv propritaire

43