Business Process Management

De la modélisation à l’exécutionPositionnement par rapport aux Architectures Orientées ServicesPARTIE 1

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

2

Plan INTRODUCTION AU BPM L’IMPORTANCE DE LA STANDARDISATION PROCESSUS MÉTIER : DE LA MODÉLISATION À

L’EXÉCUTION ARCHITECTURES ORIENTÉES SERVICES CONCLUSION

3

INTRODUCTION AU BPMINTRODUCTION AU BPM L’IMPORTANCE DE LA STANDARDISATION PROCESSUS MÉTIER : DE LA MODÉLISATION À

L’EXÉCUTION ARCHITECTURES ORIENTÉES SERVICES CONCLUSION

BUSINESS PROCESS MANAGEMENT

4

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

5

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 processus métier, fonctionnelle et technique

Cycle de vie d’un processus

Modélisation

Déploiement

Exécution Interaction

Déploiement

Exécution se basant sur les applications existantes de l’entreprise

Interaction des utilisateurs avec ce processus (contrôle d’exécution, optimisation)

6

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.

7

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

8

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).

9

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

10

Les limitations des solutions actuelles: Le WorkflowLe 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.

11

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.

12

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 ?

13

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 !

14

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.

15

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.

16

Le BPM: enjeu et objectifL’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

17

Le BPM: les niveauxUn 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.

18

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

19

Processus métier : définitions

Processus métierUn 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

20

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

21

Processus métierProcessus 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 partenaireL’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

22

Processus métierProcessus collaboratif: exemple 1/2

Processus collaboratif de gestion de commande mettant en jeu trois partenaires – un client, un fournisseur et un sous traitant

23

Processus métierProcessus collaboratif: exemple 2/2Voici 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)

24

Processus métierProcessus 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

25

Processus métierProcessus 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.

26

Processus métierProcessus exécutables (suite)Ceci dit, rendre un processus exécutable ne signifie pas

nécessairement l’automatiserPar 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

27

INTRODUCTION AU BPM L’IMPORTANCE DE LA STANDARDISATIONL’IMPORTANCE DE LA STANDARDISATION PROCESSUS MÉTIER : DE LA MODÉLISATION À

L’EXÉCUTION ARCHITECTURES ORIENTÉES SERVICES CONCLUSION

BUSINESS PROCESS MANAGEMENT

28

Objectif : des outils collaboratifsLa 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.

29

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

30

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

31

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.

32

Les acteurs de la standardisation:les organismes d’industrialisationUne 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

33

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

34

La modélisation des processus:La réponse par les standards : BPMNEn 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.

35

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

36

L’exécution des processus: ConceptsBPEL 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.

37

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>

38

L’exécution des processus: Concepts (suite)

ProcessusBPEL

Procédure stocké

EJB

Web ServiceJDBC SOAP

RMI

Le nom exact de la spécification BPEL est BPEL4WS – Business Process ExecutionLanguage 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.

39

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.

40

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

41

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.

42

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.

43

La connectivité vers les applications:Web Services : définition (suite)

UDDI

SOAP

Client du web service

Interface Implémentation

Web service

Applications duSI

Public standard Privé propriétaire