Modélisation des processus métiers et standardisation

Transcription

1 Modélisation des processus métiers et standardisation

2 Table des matières Introduction... 3 Processus métier : un même mot, plusieurs domaines d application... 4 Les défis contemporains de la gestion des processus... 6 Les critères pour un standard de modélisation des processus métiers... 7 Etat de l art des standards du BPM... 9 XPDL, BPEL...10 ISO 9000/ IDEF EPC...12 UML BPMN Business Process Modeling Notation...14 BPDM Business Process Definition Metamodel...15 BPMN En résumé...18 L action de MEGA dans les groupes de standardisation...19 Page 2 sur 19Page 2 sur 19 Page 2 / 19

3 Introduction Comme toute tendance en vogue, l approche par les processus suscite de nombreuses attentes et de nombreuses prises de position. Que l on parle de Business Process Reengineering (BPR), Business Process Management (BPM), Activity Based Costing (ABC), de Business Activity Monitoring (BAM), ou de gestion des risques opérationnels, la notion de processus est au cœur de chacune de ces approches. L émergence de standards de modélisation permet d entrevoir une rationalisation des méthodes d analyse des processus et la création d une communauté de savoir partageable par l ensemble des acteurs de ce marché. Sans nier l importance des progrès accomplis, ce livre blanc se propose de faire un état des lieux sur les travaux de standardisation de la modélisation des processus métiers afin d en dresser un portrait le plus fidèle possible à la réalité. Les perspectives données dans ce point de vue s appuieront sur le retour d expérience et la participation active de la société MEGA aux groupes de normalisation depuis de nombreuses années ainsi que des tendances émergentes du marché de l analyse des processus. Page 3 sur 19Page 3 sur 19 Page 3 / 19

4 Processus métier : un même mot, plusieurs domaines d application Avant même d établir une liste des standards de modélisation en cours de maturation, nous nous heurtons en premier lieu à la question : de quel processus métier parlons nous? Le terme «Processus métiers» est souvent employé dans des projets de nature très différente. Nous en distinguerons trois : 1) L établissement d un mode de gestion de l entreprise orientée client à partir l analyse des services rendus. On parlera alors de pilotage par les processus. 2) L établissement des modes de travail et des responsabilités des acteurs de l organisation. On parlera alors de processus organisationnels. 3) L intégration des composants informatiques dans une logique de processus en alignement avec les chaînes de valeur de l entreprise. On parlera alors de processus applicatifs. Dans les projets de pilotage, on s intéresse à la relation entre la stratégie et les processus. Par exemple, une banque peut décider de se concentrer sur le marché des produits financiers aux dépens de la banque de détail. Le processus «Fournir des produits financiers» devient alors l axe majeur de création de valeur pour l entreprise. Il faut reconfigurer les services rendus aux clients et réorganiser en conséquence le mode de pilotage de la banque en fonction des nouveaux services à rendre. Chaque division doit désormais concourir à satisfaire les clients acheteurs de produits financiers. Dans le deuxième cas, une entreprise cherchera à améliorer son fonctionnement opérationnel. Par exemple, notre banque voudra s assurer, au travers de processus organisationnels, appelés aussi procédures de gestion, du contrôle du niveau d endettement de ses clients. L objectif est de déterminer les règles à appliquer et les acteurs qui en ont la charge. Ici, ce sont la distribution des tâches et la maîtrise des responsabilités de chacun qui sont en jeu. Page 4 sur 19Page 4 sur 19 Page 4 / 19

5 Le troisième cas concerne le système d information. Ce qui est en jeu est la coordination des composants informatiques et des tâches des utilisateurs. Dans le cas de notre banque, on pourra, par exemple, mettre en œuvre un processus applicatif automatisant l interrogation de l historique des clients pour le contrôle de leur endettement. Il apparaît que les domaines concernés recoupent des sujets aussi variés que l analyse de la stratégie, l analyse des responsabilités ou l architecture de service du système d information. Cette revue des différents cas d emploi des approches processus souligne qu il y aura nécessairement besoin d adapter la modélisation aux enjeux et objectifs de chaque projet. A chaque cas d emploi devra finalement correspondre un usage circonstancié et adapté de la modélisation des processus. Page 5 sur 19Page 5 sur 19 Page 5 / 19

6 Les défis contemporains de la gestion des processus De simples producteurs, les entreprises sont devenues des fournisseurs de services. Ainsi dans le secteur des télécommunications, le téléphone en tant que produit tend à céder la place aux services rendus via le téléphone : accès aux s, achat en ligne, etc. Les entreprises exploitent cette approche d intégration de service pour trois raisons majeures : 1. Etendre leur marché et leurs revenus : à partir d un même produit, fournir plusieurs prestations. 2. Se différencier de la compétition : fournir le service à valeur ajoutée pour se démarquer de la concurrence. 3. Se concentrer sur leur savoir-faire : externalisation, infogérance par consommation de services d autres prestataires pour les activités périphériques. La combinaison de services va de pair avec la combinaison des processus. Chaque processus est effet l usine de production d un service élémentaire. Ces besoins de combinaison de processus, de services, se cumulent à tous les défis que fait naitre la globalisation de l activité des entreprises. Il faut, en effet, ajouter de nouvelles combinaisons de services et de processus pour prendre en compte les différents sites géographiques de l entreprise, les différentes législations auxquelles elle est soumise, les délégations d activités ou les délocalisations auxquelles elle a souscrit, etc. Un nouveau besoin se fait alors sentir pour les standards de modélisation : celui de pouvoir parler des éléments modélisés (processus, organisation, objet métier,..) non pas dans l absolu, mais en fonction d un contexte donné. Ainsi, dans l exemple banque précédent, le choix sera fait de ne mettre en place le processus «Fournir des produits financiers» que pour certains segments de clientèle en fonction de leur niveau de revenus et de leur localisation (eg Paris/ Province). On parlera donc de «mise en situation» de ce processus dans chacun des contextes. Le pilotage du processus devra être propre à chaque mise en situation. Page 6 sur 19Page 6 sur 19 Page 6 / 19

7 Les critères pour un standard de modélisation des processus métiers Afin d apporter un support à valeur ajoutée pour l analyse et la gestion des processus, un standard de modélisation des processus métier doit offrir des caractéristiques le distinguant d un simple schéma graphique. Il doit ainsi disposer des éléments suivants : Une notation intuitive à l usage des acteurs de l organisation et de la gestion d entreprise pour que l on puisse enfin dire : un bon dessin vaut mieux qu un long discours. Un méta-modèle et un vocabulaire - ensemble de concepts et de relations - rigoureusement définis pour fournir un socle robuste à la démarche et à l outillage des approches processus. On distinguera ici deux types de méta-modèle : o Les méta-modèles à plat : ces types de formalisation permettent de représenter l ensemble d un processus, mais dans une seule dimension. Ils sont souvent basés sur des décompositions hiérarchiques rigides (de type processus-sous-processus) ne permettant pas de mettre un même processus dans plusieurs contextes. Lorsque plusieurs «mises en situations» sont nécessaires, il faut procéder à des sortes de copier-coller de bout de processus, ce qui rend rapidement le graphe de dépendance entre processus inextricable. La plupart des anciens standards de processus sont des méta-modèles à plat (EPC, IDEF, ). o Les méta-modèles à relief : ces types de formalisation visent à intégrer de manière cohérente les deux notions de définition des processus et de mise en jeu des processus. Au premier abord, ces méta-modèles apparaissent plus complexes tant est forte l habitude de la simple décomposition hiérarchique. Mais dès les premiers cas d application, les méta-modèles en relief révèlent toute leur puissance et leur capacité à adresser les questions du BPM d aujourd hui. Page 7 sur 19Page 7 sur 19 Page 7 / 19

8 Ecosystème I Processus X Processus X dans I Processus Y Processus Z Processus Y dans I Processus étudié dans E-I Processus A Processus C Processus étudié Nouveaux besoins Processus étudié Processus Z dans I Ecosystème II Processus α Processus B dans II Un seul Eco-System global Processus α Processus étudié dans E-II Processus β dans II Processus β Processus γ Processus γ dans II Méta-modèle plat Les processus sont reliés directement entre eux de manière absolue Méta-modèle en relief Les processus sont reliés relativement entre eux, en fonction de chaque contexte Tout méta-modèle à relief peut être replié en un méta-modèle à plat. La réciproque est bien sûr impossible. La plupart des nouveaux standards de processus sont basés sur des métamodèles en relief (BPEL2, UML2, BPDM, BPMN2, ). Ces standards nécessitent une nouvelle génération d outils de manière à allier facilité d emploi et puissance d analyse. Un modèle d interaction unifié, inscrit dans le méta-modèle. Le modèle d interaction doit permettre de décrire aussi bien les échanges intra-processus que les échanges inter-processus. Une déclinaison du méta-modèle et de la notation pour chacun des niveaux d analyse des processus métier : l analyse des services rendus et des chaînes de valeur, l analyse de l organisation et des responsabilités, l analyse des processus applicatifs. Cette déclinaison doit s accompagner d un mécanisme de navigation entre les différents niveaux d analyse. Un format d échange à la fois pour les modèles de processus et pour leurs diagrammes. Page 8 sur 19Page 8 sur 19 Page 8 / 19

9 Etat de l art des standards du BPM Les paragraphes précédents nous ont permis de dégager une double grille d analyse des standards de modélisation du BPM. Nous en fournissons ci-dessous une synthèse sous forme de tableau pour l appliquer ensuite aux principaux standards actuels, existants ou en cours d élaboration Champs d application du BPM Caractéristiques d un standard de modélisation Analyse des services rendus et des chaînes de valeur Analyse des modes de travail des acteurs de l organisation Analyse des processus applicatifs Exécution des processus applicatifs Dispose d un méta-modèle à plat Dispose d un méta-modèle en relief Dispose d un modèle d interaction intégré Dispose d une notation Dispose d un format d échange Figure Grille d analyse d'un standard de modélisation de processus Le tableau suivant nous donne ensuite un aperçu des principaux standards : Nom Organisme de standardisation Statut Champs d application Méta modèle à plat Meta Modèle en relief Modèle d interaction intégré Notation Format d échange XPDL 2.0 WFMC Finalisé Langage d exécution Oui Oui Non BPEL 2.0 OASIS Finalisé Utilise BPMN Langage d exécution Oui Oui Oui Non Oui Oui ISO 9000x ISO Finalisé Analyse de l organisation Analyse des chaînes de valeur Non Non Non Non Non EPC SAP/R3 Finalisé Analyse des processus organisés Oui Non Non Oui Oui UML 2.0 OMG Finalisé Analyse des processus applicatifs Oui Oui Non Oui Oui BPMN 1.1 OMG Finalisé BPDM 1.0 for BPMN 1.1 OMG finalisé BPMN 2.0 OMG En projet Notation pour les diagrammes pour de processus Analyse des services rendus Analyse des chaînes de valeur Analyse des processus organisés Analyse des processus applicatifs Fusion de BPDM et BPMN Analyse des services rendus Analyse des chaînes de valeur Analyse des processus organisés Analyse des processus applicatifs Non Non Non Oui Non Oui Oui Oui Oui Oui Oui Oui Oui Oui Oui Figure - Principaux standards de modélisation de processus Page 9 sur 19Page 9 sur 19 Page 9 / 19

10 XPDL, BPEL Ces langages de modélisation de processus sont des langages dédiés à l exécution de processus. Ils ne sont généralement pas utilisés directement dans les phases de conception. Exprimés dans une syntaxe XML ils disposent ainsi d un format d échange natif BPEL et XPDL, qui sont exprimés tous deux sous forme de schéma XML dont le méta-modèle sous-jacent est de type «méta-modèle à relief». Chacun des deux standards permet, en effet, d exprimer la «mise en jeu» de processus dans une approche similaire de celle de la programmation structurée qui fait l appel entre fonction et appel de fonction. Le premier standard d exécution est apparu sous l égide de la WFMC Workflow Management Coalition. Une nouvelle version XML du langage de la WMFC a été publiée en 2002 sous le nom de XPDL. L avènement du langage concurrent BPEL pousse la WMFC à étendre le positionnement de XDPL, de celui d un langage d exécution de processus à un véritable langage d analyse des processus. En 2004, dans sa version 2.0, XPDL propose ainsi une correspondance avec la notation BPMN 1.0 ce qui lui fournit un support visuel qui aide indéniablement à la communication avec les analystes métier. XPDL est cependant loin de fournir un véritable méta-modèle pour BPMN. Sa conception première reste celle d un langage d échange entre outil d exécution. Par ailleurs, la correspondance entre les éléments du schéma XPDL et la notation BPMN n est pas toujours sans ambigüités et approximations sémantiques. Le langage BPEL Business Process Execution Language a été lancé à l initiative de Microsoft et IBM en réponse à l initiative de BPMI qui avait lancé le langage BPML. Depuis, BPML a disparu du paysage ; BPEL a reçu le support de la plupart des acteurs du marché et est devenu le langage d exécution de processus de facto. Il vient en complément de la spécification sur les services web ce qui lui donne de nombreux atouts pour se positionner comme un standard clé pour l intégration de systèmes. Depuis 2003, c est l organisme de standardisation OASIS qui a en charge l évolution du langage BPEL. Une version 2.0, publiée en avril 2007, ajoute une nouvelle dimension à BPEL ; les «human tasks». Cet ajout répond à une critique faite à la version 1.0 de BPEL qui ne Page 10 sur 19Page 10 sur 19 Page 10 / 19

11 prenait en compte que les processus entre systèmes, laissant de coté le «facteur humain». La prise en compte des interfaces utilisateurs est effectivement un élément essentiel pour l automatisation des processus ; qui donc pourrait ne pas s en soucier? Il y a cependant une méprise sur l expression «facteur humain». C est celle qui consiste à opposer la notion de tâche manuelle à celle de tâche automatisée comme si l on pouvait passer de l une à l autre par simple substitution. La matière des langages d exécution de processus est l orchestration des ressources informatiques au moyen d enchainements de traitements et d appels de composant. A moins de considérer l homme comme un personnage bio-ionique, un programme ne peut pas faire «d appel de personne». Il peut, en revanche, proposer une interface utilisateur. Ceci nous permet de conclure sur les limites des langages d exécution de processus en tant qu outils d analyse des processus : ce n est tout simplement pas leur objectif premier. Il manquera bien des éléments à XPDL et BPEL pour faire le cahier des charges fonctionnel d un nouveau système et préciser les différentes exigences qui y sont associées, les différents «cas d emplois» qui doivent en résulter, ainsi que des processus applicatifs «logiques» qui décrivent ces cas d emploi. La réciproque est tout aussi vraie : on aura bien du mal à prendre un processus applicatif définissant un cas d emploi du système comme le processus automatisé s exécutant dans ce système. C est tout bêtement confondre la spécification et le programme qui la réalise. ISO 9000/2000 L ISO a été une des premières organisations à s intéresser aux processus métiers avec les normes de la famille ISO L ISO fournit de nombreuses définitions très pertinentes pour les niveaux d analyse concernant l organisation ou les chaînes de valeur. Malheureusement, l ISO n a jamais fourni ni une expression formelle des processus qualité ni une notation graphique associée. Conséquemment, les normes ISO 9000 n ont pas conduit à un standard de modélisation des processus. Elles restent une référence pour l analyse des processus qualité. Page 11 sur 19Page 11 sur 19 Page 11 / 19

12 IDEF3 IDEF3 est une des familles de spécifications créées par l ICAM («Integrated Computer- Aided Manufacturing»), une initiative de l armée de l air américaine. Finalisé et rendu public dans les années 1980, le standard IDEF3 a été largement utilisé aux Etat-Unis et a été intégré à la méthode de conception de système anglo-saxonne SADT (Structured Analysis & Design Techniques). IDEF3 dispose d une notation et d un méta-modèle à plat mais pas de véritable format d échange. Les notions de processus et de mise en contexte de processus y sont représentées par un concept commun de UOB («Unit of Behavior»). IDEF3 comprend les éléments essentiels nécessaires à l expression de déroulement des processus mais ne dispose pas d un véritable modèle d interaction. L usage d IDEF est aujourd hui en déclin et tend à être remplacé par les nouveaux standards que sont BPMN et UML2. EPC Le modèle EPC (Event Process Chain) est originellement associé à la modélisation associée à SAP R/3. Le modèle EPC a été développé par le professeur Wilhelm-August Scheer à l université de Saarlandes au début des années Il est utilisé par plusieurs éditeurs, comme IDS-Scheer, pour modéliser et analyser les processus métiers. Le modèle EPC est basé sur deux concepts majeurs Evénement et Fonction complémenté par des éléments permettant de décrire le séquencement comme OU, ET, OU Exclusif. Présenté comme un modèle et une notation facile à appréhender, le modèle EPC relève, en fait, de la catégorie des méta-modèles à plat de telle sorte que la signification d une portion d un modèle peut dépendre arbitrairement d une autre portion située à une autre extrémité. La raison de cette limite est bien sûr l absence de la notion de mise en situation de processus qui, seule, permet de mettre en relation différents processus dans différents contextes. Page 12 sur 19Page 12 sur 19 Page 12 / 19

13 Les pluparts des acteurs majeurs du modèle EPC ont reconnu le besoin d une nouvelle génération de modèle de processus; certains d entre eux ont d ailleurs rejoint l initiative BPMN2 à l OMG. UML 2.0 La fin de l année 2004 a vu l aboutissement de la spécification UML 2.0 de l OMG, fruit d un long processus de maturation. UML 2.0 est une spécification très vaste et nous ne dirons ici que quelques mots sur le nouveau «modèle d activité». Les modèles d activités d UML 2.0 ont été totalement revus par rapport aux versions 1.X. Les erreurs notables des spécifications 1.X ont été corrigées et le nouveau modèle offre une base robuste pour l analyse des processus. Le modèle d activité d UML 2.0 dispose de la plupart des caractéristiques d un méta-modèle en relief et fait en particulier la distinction entre le concept d Activité (équivalent de processus) et le concept d action (équivalent d étape de processus) supportant ainsi la notion de mise en jeu de processus dans d autres processus. Cependant, le modèle d activité d UML 2.0 par son caractère technique s adresse encore essentiellement à des concepteurs de processus applicatifs. La notion d échange d information y est représentée à l aide des concepts de paramètres et de «pins» propres à l univers de la programmation. Cette préoccupation est totalement légitime et justifiée pour la conception des programmes informatiques. Elle est inadaptée pour la conception des processus métiers. Une autre critique que l on peut adresser au modèle d activité d UML 2.0 est la terminologie utilisée. Le terme d activité est utilisé pour désigner ce que l ensemble de la communauté BPM appelle Processus. Cette même communauté utilise le terme d activité pour étape de processus. Cette inversion des termes provoque une terrible confusion chez les utilisateurs. La compréhension d UML 2.0 est souvent entachée d erreur à ce propos. Le modèle d activité d UML 2.0 ne peut donc que difficilement être un support d analyse et de communication pour les processus «métier». L OMG ayant conscience de ces limitations a lancé il y a quelques années une initiative complémentaire BPDM pour traiter spécifiquement des processus métier et a aussi intégré la notation BPMN suite à la fusion avec BPMI. Ces deux initiatives BPMN et la notation BPMN ayant été lancées Page 13 sur 19Page 13 sur 19 Page 13 / 19

14 séparément, l intégration des deux projets s est faite en deux étapes (voir paragraphe cidessous sur BPDM et BPMN2). BPMN Business Process Modeling Notation Initiée dans le cadre de BPMI la notation graphique des processus BPMN présente une avancée indéniable dans la formulation graphique des processus. Elle introduit, en particulier, la notion de message et de flux d information qui manquait à la plupart des représentations traditionnelles de processus (IDEF, SAP EPC, UML 2.0). Un des objectifs initiaux de BPMN, dans sa version 1.0, a été la possibilité de représenter les processus exécutables. Pour cette raison, de nombreux dispositifs ont été intégrés comme la gestion d exception ou les activités de compensation en cas d erreur. Dans un premier temps, ces dispositifs ont fait apparaître la notation comme complexe et inadaptée pour la modélisation des processus métier. Mais dans les faits, la norme s est imposée à toutes les strates de l analyse des processus (Analyse des services rendus et des chaînes de valeur, analyse des modes de travail des acteurs de l organisation, analyse des processus applicatifs). BPMN apparaît aujourd hui comme le principal horizon des notations pour la modélisation des processus. Une faiblesse de taille subsiste cependant : BPMN n est qu une notation et ne comprend pas de méta-modèle formel. La norme ne dispose pas non plus de format d échange et il est donc difficile de parler d interopérabilité entre les différents outils revendiquant le support de BPMN. Une collaboration avait été entamée à ce sujet avec l OMG ce qui a conduit à la fusion de BPMI dans l OMG et à fait de BPMN un standard de l OMG. La version 1.1 de BPMN a été publiée au début de 2008 et comporte quelques clarifications et aménagements par rapport à la version 1.0. Suite à son intégration à l OMG, BPMN a rencontré sur sa route l autre standard de processus métier en cours d élaboration à l OMG : BPDM (Business Process Definition meta-model). C est de la fusion de ces deux normes que sortira le futur de la modélisation des processus. Page 14 sur 19Page 14 sur 19 Page 14 / 19

15 BPDM Business Process Definition Metamodel L OMG comprend un groupe de travail responsable des spécifications portant sur la modélisation des métiers de l entreprise : «the Business Modeling Integration Task Force» ou BMI DTF. Ce groupe a mis en place un plan de développement des spécifications métiers dont certaines ont déjà été publiées comme le BMM («Business Motivation Model») pour l analyse de la stratégie ou SBVR («Semantic for Business Vocabulary and Rules») pour les règles métiers. Le tableau ci-après brosse un résumé des spécifications et projets du groupe BMI. BMM SBVR SBVR Vocabulary Strategic Plan Value Chain BPMM Rules Business Cycles BPDM/ BPMN Processes Enterprise Models Financial Plan BPMN 2.0 Organization Motivation OSM Potential Development Resources Competencies Locations Current Work Adopted: Le développement conjoint de BPDM et BPMN se fait dans le contexte du BMI. BPDM et BPMN sont l axe principal de développement pour ce qui concerne la modélisation des processus.. Cet axe s inscrit dans l architecture générale de modélisation promue par l OMG sous le nom de MDA : «Model Driven Architecture». MDA est un cadre pour définir des méta-modèles, les transformer, définir les notations associées et échanger les modèles et leurs diagrammes dans un format d échange normalisé (XMI). Le cadre MDA fournit ainsi automatiquement les éléments essentiels à tout standard de modélisation. Page 15 sur 19Page 15 sur 19 Page 15 / 19

16 BPDM est la première spécification à couvrir l ensemble des dimensions de l analyse des processus et à proposer : un méta-modèle formel pour la notation BPMN 1.1. Ce méta-modèle est un méta-modèle à relief qui permet la mise en contexte des processus, de leurs acteurs et de leurs ressources. BPDM clarifie en bien des points les éléments ambigus de la notation BPMN et lui offre un socle robuste pour supporter la définition des processus, depuis l analyse métier, jusqu à l exécution. Un modèle d interaction unifié permettant de prendre en compte aussi bien les interactions entre processus que les interactions inter-processus ; c est ce que les anglo-saxons appellent respectivement la chorégraphie des processus (communications inter-processus) et l orchestration des processus (communication intra-processus). Un modèle d événement permettant de : o o o Décrire les situations résultant du déroulement des processus Assurer la synchronisation entre processus à partir de la détection des événements résultant de leur déroulement. Décrire les situations dont les processus doivent assurer la maîtrise. C est ce que les anglo-saxons appellent le «case handling». Un modèle de délégation de processus permettant une stratification de l approche par processus en montrant, par exemple, comment les processus de l organisation délèguent une partie de leur traitement aux processus applicatifs. Un format d échange basé sur le standard XMI de l OMG. La spécification BPDM est accessible à l url suivante : Page 16 sur 19Page 16 sur 19 Page 16 / 19

17 BPMN 2.0 Les projets BPMN et BPDM ayant été initiés dans des contextes différents (BPMI pour BPMN et l OMG pour BPDM), il était nécessaire de parfaire la fusion entamée par le projet BPDM dans une version unifiée. A cette occasion, la signification de l acronyme «BPMN» a été modifié. De «Business Modeling Notation» il a été transformé en «Business Model and Notation», signifiant par là que le standard intègre aussi bien un méta-modèle de processus que sa notation. Le projet BPMN 2.0 a les objectifs suivants : 1. Clarifier certains éléments de la terminologie de BPDM encore non alignés avec la notation BPMN Clarifier certains éléments de la notation BPMN 1.1 dont la signification en termes de logique de processus a été fournie par le projet BPDM 3. Fournir une notation pour la chorégraphie de processus (communication interprocessus) 4. Fournir un format d échange pour les diagrammes de processus. BPDM, en effet, ne propose pour l instant qu un format d échange pour les modèles de processus et non pas pour leur dessin. L horizon de la spécification BPMN 2.0 est l année Page 17 sur 19Page 17 sur 19 Page 17 / 19

18 En résumé L activité de standardisation des processus métiers est en pleine effervescence et de nombreux progrès ont été accomplis. La partie exécution, sous l égide d OASIS, continue sa fusion avec les services web ; la partie conception remonte des préoccupations d exécution vers des problématiques plus résolument métiers. La spécification BPDM a fait franchir un premier pas essentiel qui verra son achèvement dans le projet BPMN 2.0. Il faudra encore quelque temps pour cette nouvelle génération de modèle de processus soit adoptée par l ensemble des acteurs du marché. On perçoit dès aujourd hui les limites des approches classiques pour résoudre les défis contemporains d analyse des processus énoncés au début de ce document : combinaison des notions de services et processus, prise en compte des contextes de mises en jeu des processus, mise sous contrôle des situation à risques, délégation de processus, etc. Nous vivons une période de changement des cas d emploi de la modélisation de processus ainsi que des soubassements formels et théoriques sur lesquelles elle s appuie comme les nouveaux méta-modèle en relief. Les pièces du puzzle sont en train de s assembler sous nos yeux ainsi que le positionnement des acteurs sur ce marché en renouvellement. Page 18 sur 19Page 18 sur 19 Page 18 / 19

19 L action de MEGA dans les groupes de standardisation Les standards sont un élément majeur pour aider à l adoption d un vocabulaire commun et de représentations communes des processus dans l entreprise. MEGA est une des premières sociétés à avoir rejoint l organisation BPMI où elle a participé activement aux travaux sur BPMN et a contribué à la fusion de BMI avec l OMG. L OMG dispose d une architecture de modélisation robuste et ouverte pour le support des approches processus couvrant aussi bien la partie informatique que la partie métier. MEGA a participé aux derniers développements en cours à l OMG ont conforté cette analyse. MEGA participe ainsi aux initiatives BMM (analyse de la stratégie) BSBR (vocabulaire et règles métiers), BPDM et BPMN2 (processus métier). Celles-ci font désormais intervenir à l OMG des acteurs du monde de l entreprise et non plus seulement des informaticiens. L OpenGroup avec le succès croissant de TOGAF a retrouvé une dynamique dans la capture des méthodes de conception et de gestion de l architecture d entreprise. De grands groupes comme CapGemini ou SAP sont désormais partie prenantes et MEGA suit attentivement les travaux en cours. La collaboration de l OpenGroup et de l OMG permettra d allier théorie et pratique pour le plus grand bénéfice des utilisateurs. La standardisation des processus entre progressivement dans une phase de maturité. Page 19 sur 19Page 19 sur 19 Page 19 / 19