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

Tandis que le workflow faisait ses débuts dans les années 80, l’Intégration d’Applications d’Entreprise, ou EAI, émergeait indépendamment afin de répondre aux besoins d’intégration de systèmes à systèmes.

Il est intéressant de noter à quel point d’ailleurs ces outils furent bien différenciés dans leurs débuts et vus par les différents responsables fonctionnels comme informatiques comme des solutions couvrant des besoins bien différents. Il n’y a pas si longtemps que l’on commence à se dire qu’ils adressent peu ou prou des problématiques semblables. Pour avoir vu plusieurs projets de mise en oeuvre d’EAI ne jamais aboutir, je pense que l’EAI a souffert d’un déficit d’image et de l’absence de compréhension par les utilisateurs métiers qui ne voyaient pas dans l’EAI une réponse à leurs problématiques quotidiennes.

Un des acteurs phares dès les premiers jours (et encore aujourd’hui d’ailleurs) fût IBM avec MQ Series qui est devenu un standard de facto dans les grandes entreprises pour traiter les problèmes d’intégration de systèmes à systèmes. Plusieurs autres acteurs intégrèrent le marché, et une vraie diversité d’architectures techniques vit le jour en matière de messageries inter-applications (« message brokers »), mais toutes avaient le même objectif : automatiser les échanges de données en temps quasi-réel entre les systèmes, typiquement un système de traitement des transactions sur base mainframe ou encore un serveur de base de données relationnelle.

Je rajouterais que jusqu’à l’apparition d’outils ERP et CRM ‘modernes’ et à la montée en puissance des front-office de service (montée en puissance justifiée par le besoin de différentiation forte des entreprises face à leurs concurrents), seules les problématiques d’intégration d’applications étaient évoquées par les Directions Informatiques des grands groupes (à quelques exceptions près). La gestion des processus au sens métier du terme impliquait trop de changements organisationnels pour trouver une véritable justification et elle venait perturber les stratégies des services informatiques qui ne voyaient pas en ces systèmes une solution aux problématiques d’intégration. Ce n’est plus vrai désormais, particulièrement depuis que les entreprises ont compris que les systèmes EAI étaient très couteux à mettre en oeuvre et à faire évoluer et que les outils BPM se sont dotés de véritables capacités d’intégration.

Même les fonctionnalités les plus simples offertes par ces tous premiers systèmes EAI apportaient des bénéfices importants pour deux raisons :

– il n’était plus nécessaire de resaisir les données pour les transférer d’un système à l’autre, d’où une forte réduction des erreurs de saisie et du taux d’erreurs,
– les informations pouvaient être échangées d’un système à l’autre en temps quasi-réel, plutôt que par traitement batch nocturne.

Ces systèmes EAI initiaux ne disposaient pas d’interfaces et de fonctionnalités « utilisateurs » car ils partaient du principe que les applications ainsi intégrées disposaient elles des interfaces requises. En d’autres termes, si une erreur survenait lors d’un transfert d’une donnée d’un système A vers un système B, alors la donnée ou le problème devait être corrigé dans un des deux systèmes, pas dans l’EAI.

A mes yeux, c’est là que le BPM a su faire la différence en apportant nativement cette capacité d’interaction avec les acteurs humains (c’est sa raison d’être) et en étant capable de gérer les exceptions lors du déroulement des processus. C’est d’ailleurs ce qui fait la force des meilleurs outils BPM du marché aujourd’hui que d’être capable de gérer des processus dont tous les cas de figure ne sont pas nécessairement connus à l’avance.

Le workflow et l’EAI vécurent deux vies bien distinctes à cette époque, même si aujourd’hui ils sont vus comme les deux extrémités de la chaîne d’intégration. Non seulement ils n’étaient pas diffusés par le même type d’éditeurs (à quelques exceptions près), et basés sur des standards et des technologies différents, mais ils étaient également vendus à deux types d’entités différentes au sein des entreprises : le workflow était généralement vendu aux entités métiers en tant que solution départementale, tandis que l’EAI était vendue à l’informatique en tant que composant d’infrastructure.

En ce qui concerne la France, le taux d’implantation des solutions EAI a toujours été relativement faible, de l’ordre de 5%, et seuls quelques grands groupes disposant des moyens nécessaires se sont lancés dans l’aventure. L’arrivée sur le marché ces dernières années de solutions plus légères et non moins efficaces devrait certainement changer la donne.

A suivre: le workflow à la rencontre de l’EAI.

Retrouvez l’article original sur le blog de Sandy Kemsley