Un court historique du BPM – Cinquième partie
sur une idée originale de Sandy Kemsley

Un court historique du BPM – Cinquième partie

Suite aux évolutions citées dans les notes précédentes, les deux marchés du workflow et de l’EAI commencèrent à converger. Les outils de workflow comme ceux d’EAI se virent complétés de fonctionnalités communes, comme les moteurs de gestion des règles métiers et des outils de modélisation des processus plus évolués. Les moteurs de gestion des règles métiers étaient intégrés en mode OEM, tandis que les outils de modélisation étaient généralement conçus en tant que partie intégrante des moteurs de workflow ou d’EAI. Les moteurs de workflow ont également vu leurs capacités d’EAI monter en puissance tandis que les moteurs d’EAI voyaient leurs capacités workflow s’améliorer.

A ce sujet, il est assez curieux de constater que malgré que les deux typologies de produits dont il est question ici paraissent concurrentes sur certains points, il y avait peu de projets dans lesquels une mise en concurrence forte était évoquée. En effet, les projets EAI étaient généralement menés par les Directions Informatiques à la recherche de solutions d’intégration bas niveau, tandis que les projets workflow/BPM étaient eux gérés plutôt par les utilisateurs Métiers (LOB) et les Directions Organisation. En ce qui concerne le marché européen, et la France en particulier, il faut également noter que le taux de pénétration des solutions d’EAI en production était et reste toujours d’ailleurs assez faible, de l’ordre de 5% dans les groupes à mêmes d’en supporter la mise en oeuvre. les projets BPM étaient eux plus répandus avec néanmoins des degrés d’importance très différents selon la nature des projets.

Les clients commencèrent à se sentir un peu perdus : où est-ce que le workflow s’arrétait et où est-ce que l’EAI démarrait ? Quand fallait-il choisir un produit plutôt qu’un autre ?

Une des conséquences de ce dernier point est que ces deux types d’outils étaient bien souvent vus comme des infrastructures assez lourdes à mettre en oeuvre et qu’il y avait d’autres priorités en matière d’architecture et d’urbanisation à traiter avant. Les projets workflow pouvant néanmoins se révéler « simples » à initier tant que le périmètre restait restreint, un certain d’entre eux virent le jour tandis que l’EAI était toujours considéré comme un poids lourd dont le retour sur investissement restait difficile à estimer. Sa diffusion fût donc moindre ces dernières années.

A suivre: « La tour de Babel »

Retrouvez l’article original sur le blog de Sandy Kemsley