Je viens de passer deux jours à Berlin dans le cadre du club utilisateurs FileNet EMEA et j’ai noté quelques points d’intérêt en matière de BPM qui méritaient bien une note que je vous retranscrit ci-dessous.
Tout d’abord, ce qui ressort des discussions et présentations auxquelles j’ai assisté, c’est la montée en puissance de BPMN (Business Process Modeling Notation) dans les outils de BPM. Ce n’est pas surprenant dans la mesure où tout projet de workflow/BPM aujourd’hui s’intéresse à tout ce qui concerne la modélisation des processus par les utilisateurs métiers et l’import de ces définitions dans les outils de workflow. BPMN fournit une norme de communication entre les outils de modélisation (de Visio à Mega par exemple) permettant aux utilisateurs métiers d’utiliser un outil simple et convivial (enfin, assez simple …) pour modéliser leurs processus et de pouvoir les transmettre à l’outil de BPM sans resaisie particulière. Un gros pas en avant donc dans la rapidité de mise en oeuvre.
J’en viens à me poser la question de l’avenir du BPM en matière de modélisation. En effet, les outils spécialisés sont devenus tellement performants et pertinents qu’il va être difficile pour les éditeurs d’outils BPM d’arriver à suivre le rythme. D’où l’idée que l’on est certainement pas très loin d’un rapprochement entre les éditeurs et que BPMN pourrait bien être la prochaine ‘révolution’ que va subir le BPM ?? Rendre la main aux fonctionnels métiers en matière de définition des processus et surtout de mise à jour et d’optimisation, voilà qui va en réjouir plus d’un !
De plus, BPMN déplace la problématique de modélisation/conception des processus en dehors du cadre strict de l’outil BPM, celui devient en effet un ‘simple’ exécutant des processus définis par un outil ‘externe’. Je ne serais donc pas très surpris de voir poindre d’ici quelques mois des alliances entre éditeurs, des partenariats nouveaux, voire des rachats des uns par les autres.
Ceci dit, reste quelques points à clarifier : comment prendre en compte les spécifités de chacun des outils afin que l’ensemble puisse en tirer la quintessence ? Dans quelle mesure pourra-t-on ajouter des informations aux processus ainsi définis sans remettre en cause l’intégrité de ce même processus et sa lisibilité dans les différents outils de modélisation ? Les moteurs BPM se doivent d’ajouter des informations techniques aux définitions de processus, comment ces informations seront-elles interprétées par les outils de modélisation ? la communication entre outils de modélisation et outils de BPM sera-t-elle mono ou bidirectionnelle ?
Autre sujet d’actualité, BPMN et BPEL, quel avenir ? Je manque de recul sur le sujet pour tenter de donner une réponse mais là-aussi beaucoup de choses dans l’air. Faut-il pouvoir générer des éléments d’information BPEL depuis les définitions BPMN des processus ? Quelle interaction entre les outils ? Un vaste sujet à développer et d’ailleurs je suis preneur de vos retours pour compléter cette note 😉
Je vous poste quelques autres infos à la suite toujours en léger différé de Berlin …
Bonne analyse en effet. Il est clair qu’? l’origine modélisation des processus et gestion des processus sont deux métiers différents. Aujourd’hui l’intégration (la cohabitation ?) est de mise et je pense également que les partenariats (rachats ?) vont se multiplier entre acteurs. Maintenant, il va quand même falloir disposer de moyens de communications entre ces outils et je pense qu’effectivement BPMN est un élément de réponse. les passerelles existantes ou ayant existé sont quasiment toutes propriétaires, une standardisation devient donc nécessaire et nous sommes en passe d’avoir un langage commun. Reste ? savoir si les enjeux économiques vont l’emporter (acquisitions) avant la mise en oeuvre de ces nouvelles normes auquel cas la donne pourrait être différente ??
Je me permets, avec un mois de retard de rebondir sur cet article.
La montée du BPM au sein des entreprises (et essentiellement des grands comptes) a été l’occasion pour nombres d’entreprises d’analyser en profondeurs leurs processus internes (pour commencer). L’inventaire des processus a été réaliser par les personnes les mieux plaçaient pour réaliser ce recueil : les utilisateurs eux-mêmes. Ces analyses sont souvent très « métiers », les outils de descriptions de processus fournis par les acteurs du BPM étant trop technique, les éditeurs tels que MEGA ont proposé des outils adaptés afin de réaliser ces entrepôts de processus.
De plus, le fait de réaliser les entrepôts de processus par les utilisateurs et ensuite les intégrer dans un moteur de Workflow a souvent été un outil de marketing auprès des décideurs alors que les plateformes n’étaient pas réellement prête pour cela. En effet, la description d’un même processus est différent selon le côté où l’on se place : utilisateur (métier) ou architecte (technique).
En conséquence depuis deux ans, se montent des partenariats entre Editeurs de « carto » tel que MEGA et des pure players BPM tel que W4. Le but étant de monter des passerelles entre des processus avec une vue très métier et des processus plus techniques et adapté aux moteurs de Workflow.
BPMn et BEPL peuvent être une solution pour faciliter cette passerelle. BPMn et BEPL permettent ils de faire la liaison entre les deux ?
Les rapprochements entre les éditeurs de carto et les pure player BPM vont se multiplier. Mais pas seulement. En effet, et pour rebondir sur d’autres points traités sur ce blog, les pure players BPM doivent intégrer des outils de BI, de BAM… Et comme cela n’est pas leur cœur de métiers, les partenariats croisés ne peuvent donc que se multiplier.
JC, the issue about bi-directionality is critical, since engine-specific information must be added to a model in all cases once it is within the BPMS. XPDL allows for additional information to be added to a process definition by the engine, then preserved when exported back to a modelling tool for further modifications: see my post about the XPDL session at the recent OMG BPM Think Tank:
http://www.ebizq.net/blogs/column2/