La présentation est en train de télécharger. S'il vous plaît, attendez

La présentation est en train de télécharger. S'il vous plaît, attendez

Business Process Management De la modélisation à lexécution Positionnement par rapport aux Architectures Orientées Services PARTIE 1 Extrait du BPM Whitepaper.

Présentations similaires


Présentation au sujet: "Business Process Management De la modélisation à lexécution Positionnement par rapport aux Architectures Orientées Services PARTIE 1 Extrait du BPM Whitepaper."— Transcription de la présentation:

1 Business Process Management De la modélisation à lexécution Positionnement par rapport aux Architectures Orientées Services PARTIE 1 Extrait du BPM Whitepaper de Tanguy Crusson société Intalio

2 2 Plan INTRODUCTION AU BPM LIMPORTANCE DE LA STANDARDISATION PROCESSUS MÉTIER : DE LA MODÉLISATION À LEXÉCUTION ARCHITECTURES ORIENTÉES SERVICES CONCLUSION

3 3 INTRODUCTION AU BPM INTRODUCTION AU BPM LIMPORTANCE DE LA STANDARDISATION PROCESSUS MÉTIER : DE LA MODÉLISATION À LEXÉCUTION ARCHITECTURES ORIENTÉES SERVICES CONCLUSION BUSINESS PROCESS MANAGEMENT

4 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 dutilisation et les scénarios détaillés, en sappuyant sur les recommandations des équipes méthode : Equipe technique : transposent ces processus en terme dapplications, services et intégration de lexistant, en capitalisant sur le système dinformation (SI) de lentreprise

5 5 Constat sur la gestion actuelle des processus 2/4 «Time to Market» trop important pour passer de la modélisation à lexé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 dun processus Modélisation Déploiement ExécutionInteraction Déploiement Exécution se basant sur les applications existantes de lentreprise Interaction des utilisateurs avec ce processus (contrôle dexécution, optimisation)

6 6 Constat sur la gestion actuelle des processus 3/4 Il nexistait pas jusquici doutil 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 dimplémentation (où la majorité du code est réalisé à la main). 4.Déploiement du code réalisé 5.Recette technique et fonctionnelle.

7 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 dinteraction permet de loptimiser. Cette phase permet, au niveau technique et métier, didentifier 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 lapplication hébergeant le processus que den modifier limplémentation. Points daméliorations il devrait être possible dimporter 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 dimplémentation

8 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, lexécution et le contrôle de processus permettant de capitaliser sur les applications du système dinformation (intégration) et de mettre en jeu des actions utilisateurs (workflow).

9 9 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 intégrés et les moteurs de règles métiers

10 10 Les limitations des solutions actuelles: Le Workflow Le Workflow peut être défini comme « lautomatisation 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 dun 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 dinformation. Linté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 lautomatisation des processus métiers. Il est nécessaire davoir un niveau dabstraction supplémentaire, où lon parle plus généralement de services, et dinformations.

11 11 Les limitations des solutions actuelles : LEAI – Enterprise Application Integration 1/2 EAI signifie « intégration des applications dentreprise ». A lorigine, les progiciels EAI avait pour vocation la collaboration des applications dune entreprise pour accomplir des objectifs métiers, mais dans les faits leur utilisation est beaucoup plus technique. Les fonctions de lEAI sont : Connectivité : fournir les interfaces daccès aux applications, généralement par lutilisation de connecteurs propriétaires difficilement maintenables ; Transformation : fournir les services de transformation de données permettant de créer un niveau dabstraction 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 dun message en fonction de son contexte.

12 12 Les limitations des solutions actuelles : LEAI – Enterprise Application Integration 2/2 Avantages Réutilisabilité: il permet de capitaliser sur les applications existantes : lapplication de facturation récupère les bons de commande pour générer automatiquement les factures, etc. Cest une réponse au souci technique dintégration mais malheureusement cela ne suffit pas Inconvénients Les fonctionnalités de gestion des processus métiers des outils dEAI sont généralement complexes à utiliser et dissociées de loffre technique dintégration Les processus sont définis à un niveau technique, et les décideurs nont 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 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 dEAI, nont pas les mêmes contraintes que les processus externalisés. Le résultat est que ces outils fournissent surtout un moyen technique de surveillance dune 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 dEAI – 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 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 deProcurement, de comptabilité, de facturation, etc. Le problème qui se pose ici est celui de ladaptabilité : La mise en place dun tel progiciel demande un long projet de paramétrage et dadaptation. Lentreprise sadapte aux processus définis par le progiciel et non linverse Pour modifier un processus, il est nécessaire de customiser la plateforme. Cela peut savérer coûteux et problématique dans le cas de migration de version par exemple. De manière plus générale, il nest pas aisé dadapter 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 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 lentreprise, 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 lentreprise. 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 à dautres outils, permettant de gérer les processus.

16 16 Le BPM: enjeu et objectif Lenjeu du BPM est dunifier sous un seul outil toutes ces visions, pour fournir à lentreprise la possibilité de définir ses processus au niveau métier, et de faire intervenir les utilisateurs et les applications de lentreprise en tant que partie prenante à ces processus. Lobjectif 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 17 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 limpact sur lorganisation de lentreprise. Ce niveau est défini par les décideurs, et les équipes méthodes de lentreprise. 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 lentreprise.

18 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 19 Processus métier : définitions Processus métier Un processus métier est une chorégraphie dactivités incluant une interaction entre participants sous la forme déchange dinformations. Les participants peuvent être : Des applications / services du SI Des acteurs humains Dautres processus métiers

20 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 lentreprise, et un processus automatisé de gestion des bons de commande

21 21 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 Linterface 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 Lexé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 linterface publique

22 22 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

23 23 Processus métier Processus collaboratif: exemple 2/2 Voici un exemple dimplémentation, pour le partenaire « sous traitant » du processus ci-dessus (les activités en bleu correspondent aux activités présentes dans linterface)

24 24 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 dorganisations définissent des interfaces publiques standards, de manière verticale ou horizontale, permettant aux entreprises de formaliser leurs collaborations commerciales. Ainsi : Un consortium dentreprises 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 dune demande de devis, dun bon de commande, etc. OAGIS définit les processus et les documents échangés de manière transverse à tout corps de métier

25 25 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 lentreprise, etc.

26 26 Processus métier Processus exécutables (suite) Ceci dit, rendre un processus exécutable ne signifie pas nécessairement lautomatiser Par exemple un processus peut uniquement être lautomatisation de la transmission dinformations entre acteurs (approche Workflow), les actions étant effectuées manuellement par les utilisateurs. Lavantage 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 danticiper les erreurs

27 27 INTRODUCTION AU BPM LIMPORTANCE DE LA STANDARDISATION LIMPORTANCE DE LA STANDARDISATION PROCESSUS MÉTIER : DE LA MODÉLISATION À LEXÉCUTION ARCHITECTURES ORIENTÉES SERVICES CONCLUSION BUSINESS PROCESS MANAGEMENT

28 28 Objectif : des outils collaboratifs La standardisation du BPM se fait à différents niveaux : Modélisation du processus: il est nécessaire davoir une notation graphique commune à tous les outils de modélisation, et un format dimport / export, pour que les outils de modélisation et les outils dimplé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 saffranchir dun é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 dexploitation, bases de données, plateforme (Java,.Net), etc.

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

30 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 lEAI : WebMethods, SeeBeyond, Vitria De lapplicatif : IBM, BEA Du Workflow : Fujitsu, FileNet, Staffware Des ERP : SAP, PeopleSoft, Siebel

31 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 32 Les acteurs de la standardisation: les organismes dindustrialisation 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 ladoption de BPEL comme standard pour lexé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 lintroduire en tant que nouveau diagramme UML 2.x. Le W3C, qui standardise les spécifications XML

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

34 34 La modélisation des processus: La réponse par les standards : BPMN En réponse à la RFP soumise par lOMG, et aux contraintes dexécution des processus modélisés, le BPMI.org a proposé la spécification BPMN – Business Process Modeling Notation Lobjectif 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 dexé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 dinteropérabilité des outils de modélisation de processus métiers.

35 35 Lexécution des processus En ce qui concerne lexé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 36 Lexécution des processus: Concepts BPEL est la représentation XML dun processus exécutable, qui peut être déployée sur nimporte quel moteur de processus métier. Lélément atomique dun processus BPEL est une « activité », qui peut être lenvoi dun message, la réception dun message, lappel dune opération (envoi dun message, attente dune 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 derreurs 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 37 Lexécution des processus: Concepts (suite) Un processus BPEL définit, en XML, les activités réalisées dans le cadre de lexécution du processus métier. Toutes les informations techniques nécessaires sont décrites. // Définition des partenaires (WebServices) // Définition des conteneurs de données // Réception dune requête // Transformation de données // Appel de Web Service // Transformation de données // Envoi de la réponse

38 38 Lexécution des processus: Concepts (suite) Processus BPEL Procédure stocké EJB Web Service JDBCSOAP RMI 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 à lorchestration de Web Services : il est aussi possible dinclure des connecteurs transactionnels comme des EJB ou des procédures stockées SQL. Pour cela BPEL repose sur les capacités dextension 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 39 Lexécution des processus: Lintérêt dun 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 dun 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 deffectuer 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é nest pas réutilisable. Un processus BPEL peut être agrégé à dautres 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 40 La connectivité vers les applications Les outils dEAI trouvent la justification de leurs coûts dans la batterie de connecteurs propriétaires quils proposent, permettant daccéder aux applications / progiciels du SI. Ces technologies sont cependant en cours de banalisation : les Web Services simposent graduellement comme les connecteurs standards applicatifs

41 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 dintégration faisant abstraction des détails dimplé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 nimporte quelle plateforme, ou langage de programmation. Son interface peut être publiée et découverte dans un annuaire.

42 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 43 La connectivité vers les applications: Web Services : définition (suite) UDDI SOAP Client du web service Interface Implémentation Web service Applications du SI Public standardPrivé propriétaire


Télécharger ppt "Business Process Management De la modélisation à lexécution Positionnement par rapport aux Architectures Orientées Services PARTIE 1 Extrait du BPM Whitepaper."

Présentations similaires


Annonces Google