Business Process Management

De la modélisation à l’exécution
Positionnement par rapport aux Architectures Orientées
Services
PARTIE 1

Extrait du BPM Whitepaper de Tanguy Crusson société Intalio

Plan
 INTRODUCTION AU BPM
 L’IMPORTANCE DE LA STANDARDISATION
 PROCESSUS MÉTIER : DE LA MODÉLISATION À
L’EXÉCUTION
 ARCHITECTURES ORIENTÉES SERVICES
 CONCLUSION

2
BUSINESS PROCESS MANAGEMENT

 INTRODUCTION AU BPM
 L’IMPORTANCE DE LA STANDARDISATION
 PROCESSUS MÉTIER : DE LA MODÉLISATION À
L’EXÉCUTION
 ARCHITECTURES ORIENTÉES SERVICES
 CONCLUSION

3
 Constat sur la gestion actuelle des
processus 1/4

 Collaboration difficile entre les acteurs définissant

les processus
 profils différents, et peu habitués à collaborer,
utilisant des concepts et outils complètement
différents
 Equipe méthode: définissent les recommandations
pour la modélisation des processus métier
 Equipe métier : définissent les processus métiers
de haut niveau, les cas d’utilisation et les scénarios
détaillés, en s’appuyant sur les recommandations des
équipes méthode
 Equipe technique : transposent ces processus en
terme d’applications, services et intégration de
l’existant, en capitalisant sur le système
d’information (SI) de l’entreprise

4
 Constat sur la gestion actuelle des
processus 2/4
 «Time to Market» trop important pour passer de la
modélisation à l’exécution des processus, puis pour
modifier les processus existants et rendre ces
modifications effectives
Modélisation du Déploiement
Modélisation
processus métier,
fonctionnelle et
technique

Déploiement

Exécution se basant sur Interaction des utilisateurs

les applications avec ce processus
existantes de l’entreprise Exécution Interaction (contrôle d’exécution,
optimisation)

Cycle de vie d’un processus

5
 Constat sur la gestion actuelle des
processus 3/4
Il n’existait pas jusqu’ici d’outil unique
permettant aux acteurs réalisant les
processus de collaborer
Pour réaliser un processus exécutable, il y a
actuellement cinq étapes :
1. Modélisation par les utilisateurs métiers dans un outil.
2. Nouvelle modélisation par l’équipe technique – sans
pouvoir capitaliser sur les processus modélisés dans
l’étape précédente.
3. Phase d’implémentation (où la majorité du code est
réalisé à la main).
4. Déploiement du code réalisé
5. Recette technique et fonctionnelle.

6
Constat sur la gestion actuelle des
processus 4/4
 Eléments sensibles
 La rupture existant entre la modélisation métier et la modélisation
technique entraîne des décalages entre les besoins exprimés au départ
et les applications effectivement réalisées
 Une fois le processus déployé, la phase d’interaction permet de
l’optimiser. Cette phase permet, au niveau technique et métier,
d’identifier les modifications à effectuer. Pour les réaliser, on entre alors
dans une autre phase de modélisation, et ce cycle se répète. Comme il
existe une rupture entre la modélisation fonctionnelle et la modélisation
technique, il est complexe de maintenir les deux spécifications
cohérentes et de les rendre évolutives. Généralement, après trois
itérations, il est plus simple de redévelopper l’application hébergeant le
processus que d’en modifier l’implémentation.
 Points d’améliorations
 il devrait être possible d’importer les définitions des processus métiers
dans les outils techniques pour ajouter le lien avec les applications du
SI
 les capacités de modélisation métier et technique des outils devraient
permettre de déployer directement les processus modélisés sans passer
par une phase d’implémentation

7
Constat sur la gestion actuelle des
processus 5/5
Pour résumer, il est nécessaire de fournir un
modèle et des outils permettant aux
équipes métier, méthode, et technique de
collaborer pour la définition, le
déploiement, l’exécution et le contrôle de
processus permettant de capitaliser sur les
applications du système d’information
(intégration) et de mettre en jeu des
actions utilisateurs (workflow).

8
Les limitations des solutions actuelles

Les solutions actuelles n’adressent que partiellement

ces besoins. Nous verrons en particulier les
limitations des outils
 de Workflow,
 d’EAI,
 de B2Bi,
 les progiciels intégrés
 et les moteurs de règles métiers

9
Les limitations des solutions actuelles:
Le Workflow
Le Workflow peut être défini comme « l’automatisation de processus métiers
par échange de documents, informations et tâches entre acteurs pour
action ». Le workflow a pour objectif la coordination automatisée de
tâches réalisées par des intervenants humains.
Le moteur de workflow transfère des documents entre les participants d’un
processus en leur assignant des tâches (valider le document, effectuer
une modification, etc.).

Avantages:
 les concepts sont clairs,
 les outils relativement aisés à mettre en place.

Inconvénients:
 les participants humains, on ne tient pas compte des applications du
système d’information. L’intégration du workflow aux systèmes est une
tâche difficile qui nécessite beaucoup de code propriétaire
 Les documents et les tâches ne sont pas suffisants pour
l’automatisation des processus métiers. Il est nécessaire d’avoir un
niveau d’abstraction supplémentaire, où l’on parle plus généralement de
services, et d’informations.
10
Les limitations des solutions actuelles:
L’EAI – Enterprise Application Integration 1/2
EAI signifie « intégration des applications d’entreprise ». A l’origine, les
progiciels EAI avait pour vocation la collaboration des applications
d’une entreprise pour accomplir des objectifs métiers, mais dans
les faits leur utilisation est beaucoup plus technique.

Les fonctions de l’EAI sont :

 Connectivité : fournir les interfaces d’accès aux applications,
généralement par l’utilisation de connecteurs propriétaires
difficilement maintenables ;
 Transformation : fournir les services de transformation de
données permettant de créer un niveau d’abstraction au dessus
des applications du SI – un format pivot pour représenter les
données du SI (factures, bons de commande, etc.), et des
transformations pour les mapper vers les formats propriétaires
attendus par les applications ;
 Routage : fournir les services permettant de localiser
dynamiquement le destinataire d’un message en fonction de son
contexte.

11
Les limitations des solutions actuelles:
L’EAI – Enterprise Application Integration 2/2
Avantages
 Réutilisabilité: il permet de capitaliser sur les applications
existantes : l’application de facturation récupère les bons de
commande pour générer automatiquement les factures, etc.
C’est une réponse au souci technique d’intégration mais
malheureusement cela ne suffit pas

Inconvénients
 Les fonctionnalités de gestion des processus métiers des
outils d’EAI sont généralement complexes à utiliser et
dissociées de l’offre technique d’intégration
 Les processus sont définis à un niveau technique, et les
décideurs n’ont aucune visibilité sur leur SI
 Il est impossible de réconcilier 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 à définir les processus de collaboration
entre entreprises partenaires, partant du principe que les
processus intra-entreprise, donc d’EAI, n’ont pas les mêmes
contraintes que les processus externalisés.
Le résultat est que ces outils fournissent surtout un moyen
technique de surveillance d’une collaboration avec un
partenaire : gestion de la sécurité des échanges, fiabilité du
transport (le bon de commande a bien été envoyé, et reçu
par le partenaire), support des protocoles EDI, etc. Cela
pose un certain nombre de problèmes :
 Ces outils doivent pouvoir collaborer avec les outils d’EAI –
les processus B2B se déclinant en un processus interne par
participant de la collaboration ;
 Pourquoi avoir deux outils différents pour les processus
internes et externalisés ? Ces deux types de processus
participent en réalité au même processus métier !

13
Les limitations des solutions actuelles:
Les progiciels intégrés
Les progiciels intégrés sont une solution « clé en main » : des progiciels
tels que ceux de SAP ou CommerceOne fournissent une solution
complète d’eProcurement, de comptabilité, de facturation, etc.
Le problème qui se pose ici est celui de l’adaptabilité :
 La mise en place d’un tel progiciel demande un long projet de
paramétrage et d’adaptation. L’entreprise s’adapte aux processus
définis par le progiciel et non l’inverse
 Pour modifier un processus, il est nécessaire de customiser la
plateforme. Cela peut s’avérer coûteux et problématique dans le
cas de migration de version par exemple. De manière plus
générale, il n’est pas aisé d’adapter un processus pour répondre à
un besoin métier urgent et critique
 Les progiciels changent régulièrement de versions, en stoppant le
support des versions précédentes, ce qui force la mise à jour. Le
principal problème est que les outils de migration ne prennent pas
en compte les customisations du progiciel, qui sont inévitables ! Il
est donc nécessaire de refaire les customisations sur la nouvelle
version après migration.

14
Les limitations des solutions actuelles:
Les moteurs de règles métiers
Les moteurs de règles métiers (Business Rules Engine)
permettent de modéliser les règles métiers de
l’entreprise, par exemple « un bon de commande reçu
de la part de tel client doit être traitée par telle
division du service commercial »

Ces outils sont indispensables pour automatiser les

processus métiers de l’entreprise. Ils permettent en
particulier de formaliser et automatiser les prises de
décisions sur la branche du processus à choisir, en
fonction du contexte du processus.

Par contre, ces solutions doivent obligatoirement être

couplées à d’autres outils, permettant de gérer les
processus.

15
Le BPM: enjeu et objectif
L’enjeu du BPM est d’unifier sous un seul outil
toutes ces visions, pour fournir à l’entreprise la
possibilité de définir ses processus au niveau
métier, et de faire intervenir les utilisateurs et
les applications de l’entreprise en tant que
partie prenante à ces processus.

L’objectif est de permettre aux décideurs,

analystes métiers, équipes fonctionnelles et
équipes techniques de collaborer pour la
définition et l’évolutivité des processus métiers
via un seul outil agrégeant les différentes
visions
16
 Le BPM: les niveaux
Un processus métier est modélisé en plusieurs niveaux, et plus
généralement en trois niveaux :

 métier: vue métier haut niveau du processus, définissant ses

principales étapes et l’impact sur l’organisation de l’entreprise. Ce
niveau est défini par les décideurs, et les équipes méthodes de
l’entreprise.

 fonctionnel: formalisation des interactions entre les participants

fonctionnels du processus, où sont formalisées les règles métiers
conditionnant son déroulement. Ce niveau est modélisé par les
équipes fonctionnelles.

 technique: lien entre les activités / participants modélisés dans le

niveau fonctionnels, et les applications / services du SI, ainsi que
les tâches utilisateurs (Workflow). Ce niveau est réalisé par les
architectes et les équipes techniques de l’entreprise.
17
Processus métier : définitions
Le terme de « processus métier » est
souvent utilisé à tort et à travers pour
désigner des notions différentes :
processus exécutable, processus
abstrait, processus collaboratif, etc.
 Processus métier
 Processus collaboratif
 Processus exécutable

18
Processus métier : définitions
 Processus métier
Un processus métier est une chorégraphie
d’activités incluant une interaction entre
participants sous la forme d’échange
d’informations. Les participants peuvent être :
 Des applications / services du SI
 Des acteurs humains
 D’autres processus métiers

19
Processus métier : exemple
 Exemple: processus
métier de gestion des
bons de commande
Cet exemple fait intervenir
deux participants :
 Le département marketing
de l’entreprise,
 et un processus
automatisé de gestion des
bons de commande

20
Processus métier
Processus collaboratif: définition
Un processus collaboratif est un processus métier mettant en jeu des
entreprises partenaires. Un processus collaboratif incluant n
partenaires est composé de deux parties :
 une interfaces
 et n implémentations

L’interface définit la partie visible du processus, c'est-à-dire le contrat

entre les partenaires :
 définition des documents métiers échangés,
 du séquencement des activités,
 des rôles et responsabilités de chaque partenaire
L’exécution spécifique de chaque partenaire est abstraite grâce à cette
interface

Les implémentations – une pour chaque partenaire – définissent le

comportement interne de chaque partenaire pour réaliser le processus,
et respecter les contraintes définies dans l’interface publique

21
 Processus métier
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 métier
Processus collaboratif: exemple 2/2
Voici un exemple d’implémentation, pour le partenaire « sous
traitant » du processus ci-dessus (les activités en bleu
correspondent aux activités présentes dans l’interface)

23
Processus métier
Processus collaboratif (suite)
Un processus collaboratif est plus communément appelé «
processus métier B2B ». Il met en jeu une interface
publique et des implémentations privées, qui sont souvent
appelées « processus métiers EAI »

Un certain nombre d’organisations définissent des interfaces

publiques standards, de manière verticale ou horizontale,
permettant aux entreprises de formaliser leurs
collaborations commerciales. Ainsi :
 Un consortium d’entreprises dans le domaine de l’électronique
ont défini RosettaNet, qui décrit les processus et les
documents échangés dans le domaine de l’électronique :
traitement d’une demande de devis, d’un bon de commande,
etc.

 OAGIS définit les processus et les documents échangés de

manière transverse à tout corps de métier

24
Processus métier
Processus exécutables
Un processus peut être rendu exécutable de trois
façons
 Il peut orchestrer les applications
 services du SI
 ainsi que des actions utilisateurs pour rendre une
tâche automatisée.

Par exemple, un processus de gestion de bons de

commande va recevoir les bons de commande
via des messages XML, les transmettre aux
personnes adéquates, se renseigner sur la
disponibilité des éléments commandés dans les
bases de données de l’entreprise, etc.
25
Processus métier
Processus exécutables (suite)
Ceci dit, rendre un processus exécutable ne signifie pas
nécessairement l’automatiser
Par exemple un processus peut uniquement être l’automatisation
de la transmission d’informations entre acteurs (approche
Workflow), les actions étant effectuées manuellement par les
utilisateurs.

L’avantage du BPM est de pouvoir mélanger les concepts :

workflow et intégration

Rendre un processus exécutable peut aussi signifier introduire des

points de contrôle pour permettre le contrôle de son
déroulement. On parle alors de processus de BAM – Business
Activity Monitoring. Ainsi, les outils de BPM peuvent être
utilisés pour construire des dashboards à destination des
décideurs leur permettant de suivre les processus et d’anticiper
les erreurs

26
BUSINESS PROCESS MANAGEMENT

 INTRODUCTION AU BPM
 L’IMPORTANCE DE LA STANDARDISATION
 PROCESSUS MÉTIER : DE LA MODÉLISATION À
L’EXÉCUTION
 ARCHITECTURES ORIENTÉES SERVICES
 CONCLUSION

27
Objectif : des outils collaboratifs
La standardisation du BPM se fait à différents niveaux :
 Modélisation du processus: il est nécessaire d’avoir une notation
graphique commune à tous les outils de modélisation, et un format
d’import / export, pour que les outils de modélisation et les outils
d’implémentation puissent communiquer. La notation graphique doit
permettre la modélisation métier, et le renseignement des informations
techniques pour rendre les processus exécutables.

 Exécution du processus: les éléments déployés et exécutés sur les

serveurs BPMS doivent être standards pour garantir une portabilité des
processus réalisés sur différentes plateformes (exemple de java). Cela
permet aux entreprises de s’affranchir d’un éditeur particulier pour
choisir les outils pour leur valeur ajoutée – coût, robustesse, facilité de
prise en main, réactivité du support, etc.

 Connectivité: les applications participant au processus doivent si

possible fournir des connecteurs standards et indépendants de toute
architecture : systèmes d’exploitation, bases de données, plateforme
(Java, .Net), etc.

28
Les acteurs de la standardisation
Comme sur tout sujet novateur, il existe
deux types d’acteurs pour la
standardisation :
 les innovateurs,
 et les organismes d’industrialisation

29
Les acteurs de la standardisation:
les innovateurs
BPMI.org – Business Process Management
Initiative – définit le socle de BPM

Il rassemble les leaders du marché :

 De la modélisation de processus : Aris, MEGA,
Rational, Popkin
 De l’EAI : WebMethods, SeeBeyond, Vitria
 De l’applicatif : 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 spécifications
 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 d’industrialisation
Une fois les spécifications stabilisées, leur viabilité
dépend de leur adoption par les éditeurs, et par un
organisme de standardisation indépendant. Pour cela,
les spécifications réalisées 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 l’adoption de BPEL comme standard pour
l’exécution des processus métiers
 OMG – Object Management Group – qui maintient la
spécification UML, étudie BPMN comme standard de
représentation graphique des processus métiers, pour
l’introduire en tant que nouveau diagramme UML 2.x.
 Le W3C, qui standardise les spécifications XML

32
La modélisation des processus:
Utilisation de UML
UML – Unified Modeling Language – propose des
diagrammes spécialisés (dont les diagrammes
d’activité, de séquence, de classe, etc.) ayant chacun
une fonction précise.
Il n’existe pour le moment pas de diagramme UML
spécialisé pour la modélisation des processus métiers.
UML propose cependant un mécanisme d’extensibilité
permettant de spécialiser chaque diagramme pour
une utilisation particulière.
Il est par exemple possible de spécialiser les diagrammes
d’activité pour la modélisation des processus métiers -
un tel « profil UML » est proposé par IBM sur son site
developerworks

33
La modélisation des processus:
La réponse par les standards : BPMN
En réponse à la RFP soumise par l’OMG, et aux contraintes d’exécution des
processus modélisés, le BPMI.org a proposé la spécification BPMN –
Business Process Modeling Notation

L’objectif de BPMN est double :

 Fournir une notation graphique complète permettant de représenter un
processus métier en découplant les informations métiers des informations
techniques – qui fournit un cadre de travail commun aux utilisateurs métiers
et techniques ;
 Fournir un mapping complet vers les langages d’exécutions. Ainsi, une fois
les processus modélisés par les utilisateurs métiers, et les informations
techniques renseignées pour rendre le processus exécutable –
applications/services du SI à appeler pour réaliser les activités, règles de
transformation, etc. – il est possible de générer automatiquement, et de
manière standard, le processus BPEL à exécuter par le moteur de
processus.

La spécification BPMN est actuellement en version 1.0, et 2.O en RFP. Cette

spécification est le gage d’interopérabilité des outils de modélisation de
processus métiers.

34
L’exécution des processus
En ce qui concerne l’exécution des
processus métiers, le premier langage
qui fût proposé est BPML – Business
Process Modeling Language.
Pour des raisons marketing, ce langage
a été adapté et renommé BPEL –
Business Process Execution Language

35
L’exécution des processus:
Concepts
BPEL est la représentation XML d’un processus exécutable, qui peut
être déployée sur n’importe quel moteur de processus métier.
L’élément atomique d’un processus BPEL est une « activité »,
qui peut être l’envoi d’un message, la réception d’un message,
l’appel d’une opération (envoi d’un message, attente d’une
réponse), ou une transformation de données. BPEL offre les
fonctionnalités suivantes :

 Organisation des activités : activités séquentielles, parallèles,

switch conditionnel, etc.
 Gestion des erreurs : il est possible de définir des gestionnaires
d’erreurs pour des erreurs spécifiques – métier ou techniques.
Des erreurs peuvent être déclenchées, traitées ou ignorées ;
 Gestion des transactions : il existe deux modes de transactions
– les transactions courtes – XA ou 2-phase commit – et les
transactions longues – ou transactions compensées.
 Organisation du processus en sous processus.

36
L’exécution des processus:
Concepts (suite)
Un processus BPEL définit, en XML, les activités réalisées dans
le cadre de l’exécution du processus métier. Toutes les
informations techniques nécessaires sont décrites.

<process>
<partners/> // Définition des partenaires (WebServices)
<containers/> // Définition des conteneurs de données
<sequence>
<receive/> // Réception d’une requête
<assign/> // Transformation de données
<invoke/> // Appel de Web Service
<assign/> // Transformation de données
<reply/> // Envoi de la réponse
</sequence>
</process>
37
L’exécution des processus:
Concepts (suite)
Le nom exact de la spécification BPEL est BPEL4WS – Business Process Execution
Language for Web Services. Ce nom est trompeur car un processus BPEL ne se limite
pas à l’orchestration de Web Services : il est aussi possible d’inclure des connecteurs
transactionnels comme des EJB ou des procédures stockées SQL. Pour cela BPEL
repose sur les capacités d’extension de WSDL, le langage de définition des interfaces
Web Services.
Un processus peut donc être utilisé pour orchestrer tout type de ressources
techniques: on capitalise sur les applications du SI.

Procédure Processus Web Service

stocké JDBC SOAP
BPEL

RMI

EJB
38
L’exécution des processus:
L’intérêt d’un langage interprété
Il y a deux alternatives pour rendre un processus modélisé
exécutable:
 La première est la technique classique de génération de code
 la seconde est la génération d’un document interprété par un
serveur de processus (le couple BPMN/BPEL)

La technique de génération de code est très controversée:

 Le code généré est rarement complet
 il est souvent nécessaire d’effectuer des modifications dans
le code même, ce qui rend l’évolutivité des éléments
modélisés assez difficile
 manque de flexibilité et d’évolutivité de cette approche. Le
modèle généré n’est pas réutilisable.
 Un processus BPEL peut être agrégé à d’autres processus
BPEL pour créer des processus de plus haut niveau, cela est
rendu difficile voir impossible par la génération de code.

39
La connectivité vers les applications
Les outils d’EAI trouvent la justification de
leurs coûts dans la batterie de connecteurs
propriétaires qu’ils proposent, permettant
d’accéder aux applications / progiciels du
SI.
Ces technologies sont cependant en cours de
banalisation : les Web Services s’imposent
graduellement comme les connecteurs
standards applicatifs

40
La connectivité vers les applications:
Web Services : définition
Un Web Service est un composant métier ou technique
accessible par des protocoles standards

Cette technologie est la première technologie d’intégration

faisant abstraction des détails d’implémentation :
 Un service est décrit dans une interface standard.
 Il est accessible par échange de messages XML. Un
Web Service est donc accessible depuis n’importe
quelle plateforme, ou langage de programmation.
 Son interface peut être publiée et découverte dans
un annuaire.

41
La connectivité vers les applications:
Web Services : définition (suite)
Le schéma suivant positionne les spécifications
formant le socle des Web Services :
 SOAP – Simple Object Access Protocol : format
des messages échangés pour invoquer un Web
Service
 WSDL – Web Service Definition Language :
langage de définition des interfaces des services
offerts
 UDDI – Universal Description, Discovery and
Integration : annuaire des Web Services.

42
 La connectivité vers les applications:
Web Services : définition (suite)
Web service
Client du
web service Implémentation
Interface

SOAP

Applications du
SI

UDDI

Public standard Privé propriétaire

43