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

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

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 La collaboration entre ces différents acteurs est actuellement difficile. Tout d’abord, ces acteurs manipulent des concepts différents : un diagramme UML a par exemple peu de signification pour un analyste métier. De plus, leurs outils ne fournissent pas les moyens de cette collaboration : pour implémenter un processus métier modélisé avec Aris, il est nécessaire de le modéliser à nouveau sous Rational, pour pouvoir générer du code de manière plus ou moins efficace lors de la phase d’implémentation (la génération de code est d’ailleurs généralement manuelle en raison du manque de maturité de ces outils). Actuellement, que ce soit dans les phases de modélisation métier et technique, ou d’implémentation, des outils de conception sont rarement utilisés de bout en bout, de la modélisation à l’exécution. On retrouve un fossé entre les phases de spécification et d’implémentation, même dans la partie technique. De ce fait, il est difficile pour les décideurs d’avoir une vue claire sur les besoins auxquels répondent les applications du système d’information, et donc de justifier les nouveaux investissements IT. La maîtrise des processus est actuellement dans les mains des techniques, pas des personnes qui les définissent

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 Interaction des utilisateurs avec ce processus (contrôle d’exécution, optimisation) Exécution se basant sur les applications existantes de l’entreprise

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 : Modélisation par les utilisateurs métiers dans un outil. Nouvelle modélisation par l’équipe technique – sans pouvoir capitaliser sur les processus modélisés dans l’étape précédente. Phase d’implémentation (où la majorité du code est réalisé à la main). Déploiement du code réalisé Recette technique et fonctionnelle.

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

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

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

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.

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.

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 ?

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 !

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. L'eProcurement désigne un module de la gestion électronique des approvisionnements dans les entreprises ou les organisations. Il fait partie du eAchat qui comprend, en amont, les actions de sélection de fournisseurs (eSourcing), en aval, le passage et suivi des commandes, le eProcurement. Dans le cadre du eProcurement, les commandes sont passées electroniquement sur des catalogues ou des catalogues privés préalablement négociés lors du eSourcing. Les achats sont en général centralisés ou regroupés. C'est une catégorie de commerce électronique en mode B2B, c'est-à-dire Business to business, ou encore d'entreprise à entreprise.

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.

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

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.

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

Processus métier : définitions 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

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

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

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

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)

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

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.

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

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

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.

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

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

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.

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

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

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.

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

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.

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 <reply/> // Envoi de la réponse </sequence> </process>

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. Processus BPEL Procédure stocké EJB Web Service JDBC SOAP RMI

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.

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

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. Un service est composé de deux parties : une interface et une implémentation. L’interface est standard ; l’implémentation quant à elle est propriétaire, et dépend de la plateforme utilisée : cela a peu d’importance à partir du moment où l’interface est respectée, et que cette implémentation dialogue avec ses clients par échange de messages XML. L’implémentation du Web Service accède aux applications du système d’information, et permet donc d’encapsuler leurs fonctionnalités sous formes de services accessibles depuis toute plateforme. Les Web Services sont en particulier la clé de l’interopérabilité entre les plateformes Java et .Net.

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.

La connectivité vers les applications: Web Services : définition (suite) Client du web service Interface Implémentation SOAP Applications du SI UDDI Public standard Privé propriétaire