Chaque analyste, éditeur et client définit le BPM à sa façon, parce que la définition actuelle du BPM est très vague, et qu’il y a beaucoup d’éditeurs qui revendiquent une place sur ce marché. Les éditeurs d’EAI/ESB appellent leurs produits BPM, mais ces produits ne contiennent la plupart du temps que quelques rares fonctionnalités à destination d’acteurs “humains”. Les éditeurs de workflow qui s’auto-proclament éditeurs BPM ne disposent pas de l’infrastructure nécessaire à l’intégration, et traitent bien mal la plupart du temps les étapes automatisées. Quelques produits de pure intégration se prétendent aussi être des workflows, de façon à accroître encore la confusion. Il y a également pas mal d’offres complémentaires, comme les outils de reporting analytique et de simulation, et les moteurs de règles : les éditeurs de BPM vous diront que telle fonctionnalité bien particulière doit faire partie de l’offre de base en matière de BPM (si leur produit l’inclut) ou ne doit jamais en faire partie (si leur produit ne l’inclut pas). Et en plus maintenant la dimension SOA vient rendre la confusion encore plus grande.

De mon côté, je pense comme Sandy que le terme BPM est pas mal galvaudé aujourd’hui comme l’a été celui de workflow ces dernières années. Je suis surpris de découvrir régulièrement de nouveaux éditeurs “BPM” et de nouvelles offres “BPM” chez ces éditeurs, la seule vraie raison étant à mes yeux - et c’est plutôt rassurant en ce qui me concerne - le fait que le BPM ait enfin trouvé sa place au sein des organisations désormais et devienne un marché à part entière.

Le BPM est l’exemple même d’un domaine pour lequel la superficie couverte est plus grande que la somme des surfaces qui la composent. Ce n’est pas simplement du workflow plus de l’EAI plus du B2Bi plus des règles métiers plus plus plus … : c’est une quasi-intégration de tous ces outils en une seule et même suite qui fournit à une organisation la capacité de faire des choses qu’elle n’aurait jamais pu faire avant. Ceci ne signifie pas que tous les outils doivent être fournis par le même éditeur, mais il est essentiel de pouvoir mettre à disposition toutes les fonctionnalités du BPM au sein d’un seul et même environnement d’amélioration en boucle fermée des processus.

Là-aussi je rejoins Sandy et je recommande à tous ceux qui sont à la recherche de solutions BPM de commencer par demander à leurs interlocuteurs, éditeurs, consultant ou intégrateurs, leur définition du BPM. Ainsi le choix d’une solution n’en sera que plus simple une fois le premier tour d’horizon fait.

Le livre de Smith et Fingar intitulé “Business Process Management, The Third Wave” décrit bien cette “troisième vague” comme la capacité de créer une définition unique d’un processus à partir de laquelle plusieurs vues différentes de ce processus peuvent être tirées et sur les bases de laquelle de nouveaux systèmes d’information peuvent être construits. Ceci permet à différentes personnes aux profils différents - Responsable métier, analyste métier, utilisateur quotidien, développeur - de voir et de manipuler le même processus selon une représentation qui leur est propre et qui est dérivée de la même source. Smith et Fingar font l’analogie avec le langage HTML, pour lequel un utilisateur métier peut utiliser un environnement de développement intégré comme Frontpage pour voir et éditer du code HTML, ou un développeur peut éditer ce même code directement tout en travaillant tous les deux sur la même source. Les aller-retours entre l’outil de modélisation de l’analyste métier et l’environnement runtime du développeur sont une des façons de mettre ce principe en oeuvre, même si cette méthode “viole” l’idée de “source identique” au plus pur sens du terme, mais nous devons nous affranchir complètement de la notion de trajet en sens unique de l’analyse à la mise en oeuvre telle qu’elle est vue par bon nombre d’organisations.

De plus, Smith et Fingar mettent en avant le fait que dans le monde du BPM, la capacité à changer est bien mieux mise en valeur que la capacité à créer initiale, et que le BPM possède le potentiel nécessaire pour libérer le développement d’applications du cycle classique — le Saint Graal du “zero code” qui fait la une de la presse ces temps-ci. Ils font une analogie là-aussi avec VisiCalc, qui retire l’analyse personnalisée des données des mains du département informatique pour la mettre dans celles des utilisateurs métiers, retirant le développement logiciel du chemin critique pour l’atteinte des résultats.

Zero-code en matière de BPM ? Un voeu pieux en effet, mais nous en sommes encore loin aujourd’hui, quelque soit l’éditeur. Certains offrent en effet des facilités plus importantes que d’autres pour mettre en oeuvre des applications avec un minimum de développements mais dans la mesure où le BPM sous-entend l’intégration au Système d’Information en partie, je ne pense pas que nous puissions assister à une mise en oeuvre sans aucun développement de sitôt.

Pour en revenir au sujet initial de cette note, quel est le statut actuel du BPM ?

Premièrement nous trouvons plusieurs sociétés dans le marché des purs acteurs BPM et fournisseurs de suites BPM : elles fournissent des BPM de type “à interaction humaine” excellents et des fonctionnalités d’intégration adéquates, certaines d’entre elles fournissant des capacités d’intégration exceptionnelles. Lors du séminaire BPM du Gartner au début de cette année, ont été listés les trois acteurs majeurs de ce secteur aux revenus supérieurs à 100 Millions d’US$ — FileNet, Pegasystems et Global 360 ainsi que cinq nouveaux arrivants au revenu supérieur à 30 Millions d’US$ — Appian, Lombardi, Savvion, Metastorm et Ultimus — tout en ignorant toutes les sociétés de plus faible envergure que toutes celles-ci. Ces huit sociétés se retrouvent dans les bons quadrants du Gartner et de Forrester, ce qui signifie qu’elles possèdent toutes les fonctionnalités requises ou sont à mêmes de les fournir en partenariat avec un autre acteur.

C’est la vision de Sandy sur le marché nord-américain. Pour l’Europe et la France en particulier je pense que l’on peut ajouter à la liste W4 qui est assez présent sur le secteur public et para-public à ma connaissance sans avoir la dimension internationale que l’on connaît aux acteurs cités ci-dessus.

En second, nous retrouvons quelques éditeurs spécialisés dans l’intégration qui ont fait l’acquisition d’éditeurs spécialisés dans le BPM pour disposer d’une gamme complète de fonctionnalités. Les deux exemples les plus pertinents sont l’acquisition par TIBCO de Staffware en 2004, et l’acquisition par BEA de Fuego au début de cette année. Dans les deux cas, il y a une complémentarité intéressante mais ma préoccupation est de savoir si les capacités de BPM “à visage humain” ne vont pas avoir tendance à être dévalorisées sachant que ces sociétés sont très focalisées sur l’intégration.

En troisième lieu, nous trouvons les grands éditeurs qui ont développé (ou acquis) un produit de BPM : IBM, Microsoft et Fujitsu, diables surgissant de leur boîte. Dans la plupart des cas, comme pour IBM et Microsoft, leurs produits de BPM sont initialement orientés intégration sans énormément de support des transactions à caractère humain, ces sociétés adressant le marché avec des offres du type “vous prendrez bien quelques frites avec ça …” s’adressant à leurs clients déjà attachés à leur architecture. MQ Series Messaging d’IBM est très certainement le middleware le plus utilisé en matière d’intégration dans les services financiers, bien que je crois qu’IBM l’appelle (comme tout le reste de l’offre) “Websphere” désormais, et IBM maintient à juste titre cette offre comme partie intégrante de sa stratégie BPM. Fujitsu est le plus curieux du lot ici, avec ce qui paraît être un BPMS parfaitement fonctionnel; malheureusement ils ont promu très furtivement cette offre et la plupart des gens ne la connaissent pas : comme je le dis dans une de mes notes à propos du séminaire BPM du Gartner, “qui savait que Fujitsu faisait du BPM?”

En Europe n’ayont pas peur d’ajouter à la liste SAP et Oracle, le premier poussant ses capacités d’intégration sans trop disposer à ce jour de fonctionnalités pures et dures de BPM mais avec la puissance de feu qu’on lui connaît auprès de sa base installée en particulier, le second arrivant sur un marché juteux avec une offre encore bien maigre mais avec beaucoup d’ambition et de moyens. En ce qui concerne Microsoft, les quelques projets dont j’ai entendu parler sont tous portés par des éditeurs partenaires et non par Microsoft directement, avec des offres comme K2Net et Ultimus sans succés à ma connaissance (corrigez-moi si je me trompe).

Nous allons continuer à voir la plupart du spectre fonctionnel métier poussé par les éditeurs de la première catégorie car ils recherchent toujours de meilleurs moyens d’intégrer les règles métiers, l’analytique, la gestion de la performance et autres capacités dans le BPM; en fait la plupart de l’innovation semble venir des plus petits éditeurs de cette catégorie en raison de l’absence de contraintes tel que je l’ai présenté dans la septième partie de cet historique.

En raison de la focalisation actuelle des organisations sur l’amélioration des processus, je ne pense pas qu’il y ait beaucoup de risque que les éditeurs que j’ai cité ici disparaissent du marché du BPM prochaînement. Cependant, les éditeurs de produits d’intégration vont acquérir certains des éditeurs de suites BPM pour élargir leur portefeuille, et les grandes sociétés de logiciel vont acquérir un “bout de quelque chose”, dans la logique du cycle darwinien inhérent à ce type d’organisation.

Avant que vous, éditeurs, ne commenciez à ajouter des commentaires d’auto-promotion à cette note, n’oubliez pas qu’elle n’a pas prétention à être une liste exhaustive ou encore une revue des différents éditeurs d’outils BPM, et je sais bien que vous êtes tous très particuliers chacun à votre façon.

Je rajouterais pour terminer cette série sur l’historique du BPM que je suis preneur de toutes vos remarques et que ces notes ne demandent qu’à s’enrichir de vos expériences et avis respectifs. N’hésitez donc pas à réagir et/ou à me contacter, n’en profitez pas non plus pour faire trop d’auto-promotion de vos produits au détriment des autres, je rappelle comme Sandy l’a fait dans sa note originale que je suis aussi persuadé qu’elle que tous les outils présents sur le marché aujourd’hui ont leur propre valeur, et qu’aucun ne mérite d’être mis de côté systématiquement par une organisation lorsqu’elle est à la recherche de solutions. Je laisserai de côté par contre volontairement les effets de bord liés à la taille de la société éditrice et à son recul et son expérience, aspects certes importants mais hors sujet dans le cadre de cette série de notes.

Retrouvez l’article original sur le blog de Sandy Kemsley

Dans les années qui suivirent la rapide agonie des dotcoms en 2000, un certain nombre d’éditeurs d’outils BPM firent leur apparition dans le milieu très convoité des acteurs spécialisés. D’ailleurs, ce qui est drôle c’est qu’aujourd’hui être “pur acteur BPM” n’est pas un statut très désirable puisque ce terme est démodé et remplacé par “éditeur de suites BPM”, ce qui d’après quelques analystes ayant pignon sur rue semble être sensiblement la même chose. Dans la plupart des cas, ces nouveaux acteurs renaissaient sur les cendres de ceux qui avaient été évincés de leurs positions précédentes pendant l’explosion de la bulle, et il y avait ainsi énormément d’expérience accumulée mise au service de ces nouveaux éditeurs BPM.
Le principal avantage qu’a un nouvel acteur dans toute industrie est l’absence de bagages contraignants, et ceci était on ne peut plus vrai dans le monde du BPM : ces acteurs pouvaient lancer la conception de leurs nouveaux outils sans avoir à gérer les contraintes d’une technologie existante ou le support ascendant d’une base installée, parce qu’ils n’en avaient pas. Le marché du BPM devait être réinventé, et ces sociétés jeunes et en pleine ascension étaient les seules à pouvoir ainsi faire bouger les choses. Je ne vais pas créditer nécessairement ces nouveaux arrivants de toutes les innovations du BPM à ce moment-là, mais ils ont certainement mis un peu un peu le feu au regard de ce que faisait alors l’arrière-garde.

Pour compléter les propos de Sandy, j’ajouterais que ceci se retrouvait dans les phases d’avant-projet et venait “semer le trouble” auprès des éditeurs “bien établis” car la focalisation qui était la leur était mise en défaut par ces nouveaux arrivants et leurs fonctionnalités nouvelles, une mise en défaut que bon nombre de clients ne se privaient pas d’utiliser. Je suis assez d’accord sur la déstabilisation ainsi créée chez l’arrière-garde.

Tout à coup, nous disposions d’un BPM invoquant des Web Services, ou étant invoqué par ces mêmes Web Services, de façon à accélerer l’intégration (et faisant éventuellement partie de l’éco-système SOA). Nous avions le BAM (Business Analytics Monitoring), ou tout au moins des fonctionnalités assez décentes de monitoring des processus et de reporting analytique. Nous avions la simulation et l’optimisation. Nous avions l’intégration avec des outils de modélisation tiers. Nous avions l’intégration avec des moteurs de règles.

L’environnement des start-up dans ces années-là n’était pas le meilleur — il y avait peu d’investisseurs finançant cette technologie, la perception étant qu’il s’agissait d’un simple remaniement du marché bien établi du workflow — mais quelques-uns de ces éditeurs ont eu du succés même si pas mal d’autres étaient en mauvaise posture dans leur sillage.
Cependant, les éditeurs de BPM bien établis faisaient face à un vrai challenge : même si peu de nouveaux arrivants les inquiétaient directement en matière de ventes de licences, ces mêmes nouveaux arrivants étaient en train de changer la perception de ce que devait être le marché du BPM, forçant les anciens à suivre de près ce que les analystes comme le Gartner ou les principaux autres considéraient comme les fonctions à avoir et qui incluaient toutes ces nouvelles fonctionnalités. Pas mal de ces acteurs majeurs mirent du temps à implémenter ces nouvelles fonctionnalités, et apparurent un peu “fatigués” à cette époque en comparaison avec ces brillants nouveaux arrivants. Dans quelques secteurs très conservatifs de l’industrie, comme les services financiers et l’assurance, dans lesquels se trouvent la plupart de mes clients, ceci ne fût pas véritablement un problème car les gens préféraient choisir un éditeur présentant toutes les garanties d’expérience et de fiabilité pour gérer des centaines de milliers de transactions journalières. Ceci dit, c’est là que beaucoup de DSI “dinosaures” continuent à se battre contre les technologies innovantes, tout en sachant que certains nouveaux arrivants seront capables de démontrer suffisamment d’évolutivité et de stabilité même auprès des secteurs les plus conservateurs.

En effet, on peut dire que par chance pour “l’arrière-garde” les nouveaux arrivants et leurs fonctionnalités nouvelles ne représentaient pas un danger commercial fort. Néanmoins il fallait prendre tout cela comme des signes avants-coureurs car il ne s’agissait pas de simples coups de bluf mais bien d’une évolution réelle du marché correspondant de plus à la demande.

Même si aucun des nouveaux acteurs des années post-2000 ne survécut à la vague d’acquisitions, il faut reconnaître qu’ils n’ont pas simplement donné une nouvelle vie au BPM, mais qu’ils ont aidé à le réinventer.

A suivre avec : la situation actuelle

Un court historique du BPM - Sixième partie

Pour continuer cet historique du BPM, nous allons dans cette note parler de la confusion qui a régné lorsque la convergence entre outils workflow et outils EAI a été relabellisée, par les principaux analystes tout d’abord, Business Process Management ou BPM. A partir de là, au lieu d’être perdus entre ce qu’était un outil de workflow et ce qu’était un outil d’EAI, les clients étaient en pleine confusion ne sachant plus quel produit servait quel besoin technique ou fonctionnel dans ce marché encore bien fragmenté.

Pour aggraver encore la confusion, ces mêmes analystes qui avaient regroupé tous les produits sous cette appellation BPM, commencèrent à créer des divisions fonctionnelles au sein même de ce nouvel espace. Par exemple voici le schéma publié dans ma note précédente sur lequel j’ai ajouté les éléments de taxonomie BPM tels que définis par le Gartner en 2003 :

Ils appelèrent tous ces outils des “Suites BPM“, mais les classèrent en cinq catégories tout en laissant la majeure partie du marché tomber dans les catégories “pure-player” et “orientés applications”:

• Les outils de BPM “orientés applications” gèraient les flux de système à système dans le cadre de l’intégration des processus impliquant plusieurs applications distinctes. A cette époque, les produits classés dans cette catégorie investissaient lentement le champ des applications de traitement des flux d’acteurs humains à acteurs humains mais manquaient cruellement de fonctionnalités orientées utilisateurs et conviviales.
• Les produits classés comme “pure-player” disposaient d’un design et de capacités de connexion sans équivalent tant pour les aspects applicatifs purs que pour les aspects workflows orientés intégration. par exemple, en déclenchant un sous-workflow dans un autre système et en remontant le résultat du traitement dans le système maître. Il s’agissait des “super” outils de BPM, modélisant les processus transverses de l’Entreprise et de ses partenaires métiers, pas simplement les sous-processus internes à l’Entreprise, et incluant des outils de modélisation et d’analyse, des moteurs de gestion des règles métiers et des outils de simulation et d’optimisation des processus.

Pour faire simple, le Gartner (ainsi que les autres analystes suivis rapidement et de près par les éditeurs) rendirent les termes “workflow” et “EAI” obsolètes, et se mirent à classer tout ce qui se rapportait de près comme de loin à la gestion des processus dans la catégorie BPM. Ils scindèrent ensuite cet espace BPM en “BPM pure-player” et “BPM d’intégration”, ce qui correspondait plus ou moins à la distinction faite précédemment entre workflow et EAI. Moyennant quoi, je suis sûre qu’ils placèrent allègrement de nombreuses nouvelles études et prestations de conseil à ce sujet.

Si j’en crois ce qui est écrit ci-dessus par Sandy, nous nous retrouvons donc bien toujours avec deux catégories de produits, ce qui finalement n’est pas une surprise puisque pour moi, la classification n’est pas tant liée à la définition qu’en donnent les analystes mais plutôt au rendu fonctionnel et technique que les clients attendent de ces outils. En quelque sorte, je dirais que la boucle est bouclée puisque les analystes donnent l’impulsion et jettent les bases, les clients se font leur idée au vu de ce qu’ils lisent et entendent et font le choix qui est le leur. Les analystes analysent … ce choix et précisent leurs définitions, tout va donc pour le mieux.

Keith Swenson a écrit une note ces jours-ci sur la désaffection liée au terme ‘workflow’ pendant cette période en raison des prouesses marketing des uns et des autres, un avis que je soutiens entièrement — à partir de l’année 2001, vous ne pouviez plus utiliser le mot ‘workflow’ dans une conversation avec des équipes IT sans que l’un d’eux vous considère comme faisant partie de “la vieille école”. Pour Keith, le fait est que BPM est maintenant devenu synonyme d’EAI ; je ne suis pas certaine d’adhérer à cette vision, mais je pense que le terme BPM est un des acronymes le plus souvent employé à mauvais escient et assurément un des plus mal compris aujourd’hui.

Je rejoins Sandy sur ce point. Pour moi aussi BPM et EAI restent deux domaines différents même si en effet on constate un recouvrement fonctionnel sur certains points. Pour autant les besoins adressés restent clairement distincts et les interlocuteurs aussi. Qu’on le veuille ou non, l’EAI s’adresse encore la plupart du temps aux équipes IT alors que le BPM concerne les LOB (Line of Business), utilisateurs métiers. Et je confirme également l’avis de Sandy sur la connotation presque péjorative liée au terme ‘workflow’, nous en sommes pratiquement à surveiller notre langage lors des interventions officielles afin de ne pas laisser penser que nous ne parlons QUE workflow alors que les autres parlent eux BPM !

A suivre avec “Les nouveaux arrivants” …

Retrouvez l’article original sur le blog 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

Un court historique du BPM - Quatrième partie

Les organisations qui avaient déployé des systèmes workflows se rendirent rapidement à l’évidence qu’une fois le processus devenu électronique et non plus manuel, il n’était plus possible de le suivre par les moyens habituels - ou tout simplement en faisant le tour des bureaux et des corbeilles. Le monitoring et le reporting en matière de workflow devenaient alors nécessaires car il n’y a pas de processus sans besoin de suivi et de traçabilité et de besoin de savoir où en est chacune des instances - voire “où elle n’en est pas” ! - et les premières implémentations faisaient appel la plupart du temps à des modules mis en oeuvre de façon complètement spécifique. Après plusieurs années passées à voir leurs clients construire leurs propres outils de reporting et de monitoring, les éditeurs de produits workflow commencèrent à inclure de telles fonctionalités dans leurs offres. Les premiers modules de monitoring temps réel apparurent, pour devenir ce qui est aujourd’hui connu sous le nom de Business Activity Monitoring - ou BAM. Le suivi des processus et leur gouvernance, grâce au monitoring temps réel, à la journalisation des évènements et au reporting analytique, devenait une composante essentielle de la gestion des processus métier, particulièrement pour les entreprises qui implémentaient des programmes d’Assurance Qualité comme Six Sigma. Le besoin d’optimiser les processus poussa également très rapidement les outils analytiques à prendre en compte tant la simulation des processus que la mise à disposition d’outils d’optimisation.

Pour compléter ce qu’en dit Sandy, j’ajouterai que bien souvent lors d’une première approche workflow/BPM, les interlocuteurs concernés n’ont pas conscience de l’importance de ces fonctionnalités de reporting et d’optimisation. Leur problématique est simple, choisir le meilleur outil et le mettre en oeuvre, ils laissent assez facilement de côté ces facettes secondaires (dans un premier temps) pour se focaliser sur les processus en eux-mêmes. par contre, une fois la mise en oeuvre d’un premier processus réalisée, le besoin précité de suivi et d’optimisation refait surface bien vite. On entre alors dans ce que l’on appelle parfois un peu communément le Business Process Reengineering, clef de voute de la mise en oeuvre d’un chantier BPM.

Les produits d’EAI évoluèrent eux globalement dans une direction différente. La plupart des produits fournissaient quelques capacités de reporting et d’analyse, et ne se préoccupaient pas de gérer la gouvernance des processus propres aux workflows à intervention humaine. A la place, les éditeurs d’EAI commencèrent à s’intéresser au monde externe à l’organisation, et amenèrent l’EAI à prendre en compte l’intégration “Business to Business”, ou B2Bi. Cette intégration collaborative des processus permettait ainsi aux clients d’implémenter des processus - toujours de systèmes à systèmes - en leur offrant la capacité à coupler - de façon encore approximative - leurs processus métier avec ceux de leurs clients ou partenaires commerciaux, il ne s’agissait plus de simples échanges de flux uniquement au sein de l’organisation et de son système d’information propre.

Le besoin en matière d’EAI diffère en effet de ce que l’on peut rencontrer dans le monde du BPM. Les processus se situant au niveau des applicatifs, de systèmes à systèmes, il est plus question d’administration et de gouvernance technique que de reporting analytique métier. Les fonctionnalités requises se rapprochent donc plus du monitoring applicatif, avec des besoins évoqués de remontée d’alertes par exemple.
Ceci allait devenir une des avancées les plus significatives pour le BPM tel que nous en disposons aujourd’hui, permettant aux organisations d’intégrer des participants à la fois ‘humains’ et ’systèmes’ dans les processus et à diffuser largement ces derniers. Le ROI - Retour sur Investissement - en matière de B2Bi pouvait être important, et permettre la création d’une sorte de plateforme de processus métier, interface standard entre une organisation et ses partenaires métiers de telle façon que chacun puisse faire évoluer ses processus internes et ses données sans déranger les autres.

J’ajouterai un dernier point au sujet du reporting et de l’optimisation afin de bien préciser la différence entre statistiques et reporting analytique. La confusion règne encore à ce sujet, parfois habilement alimentée par les différents éditeurs en fonction du contenu de leurs offres. Par ’statistiques’, on entend le besoin de fournir à des utilisateurs métiers un ensemble de données résultant des différents traitements générés par l’exécution des processus, données présentées généralement sous forme de tableaux de bord à partir d’un ensemble de besoins évoqués par ces mêmes utilisateurs et livrés sous une forme statique. Ces tableaux de bord ont une raison d’être purement consultative et ne peuvent être modifiés pour répondre à des questions spécifiques. C’est là l’intérêt du reporting analytique, qui à la différence des outils statistiques, est capable de fournir des tableaux de bord modifiables très facilement par les utilisateurs finaux. S’appuyant sur un silo de données (de type OLAP par exemple), il est ainsi possible d’accéder à l’ensemble des informations issues des traitements workflow, et de manipuler ces données en fonction des besoins analytiques propres à chaque utilisateur. On parlera alors de rapports ‘dynamiques’ en lieu et place des rapports ’statiques’ évoqués précédemment.

A suivre: Convergence et fusion

Retrouvez l’article original sur le blog de Sandy Kemsley

A la fin des années 90, quand les éditeurs d’outils workflow réalisèrent les bénéfices apportés par l’EAI et comprirent comment cette technologie pouvait remplacer les intégrations lourdes et coûteuses habituellement mises en oeuvre dans le cadre des projets workflow, ils commencèrent à ajouter des fonctionnalités EAI à leurs moteurs de workflow. A quelques exceptions près, il s’agissait généralement d’avoir un accord avec un éditeur d’EAI et d’intégrer en OEM son moteur. Afin de faciliter la mise en oeuvre, l’outil workflow proposait en plus une intégration fine dans ses propres outils.

La réalité est bien celle-ci est en fait très peu de projets faisant appel aux deux composantes Workflow et EAI ainsi intégrées virent le jour. La complexité du montage, de l’architecture et le besoin persistant d’un minimum d’intégration venaient en effet alourdir les charges au niveau du projet et l’enveloppe financière au niveau des logiciels. D’autre part, les entreprises disposant déjà d’EAI souhaitaient pouvoir utiliser leur propre moteur qui n’était qu’à peu d’exceptions près pas celui intégré par l’outil workflow, et inversement. C’était là un facteur aggravant en avant-vente workflow car la réalisation d’un connecteur spécifique entre le workflow et l’EAI pour les besoins d’un projet venait contrecarrer le bénéfice tiré de l’utilisation de l’EAI. Il devenait alors plus simple et moins coûteux de réaliser des intégrations point à point.

Sans surprise, les éditeurs d’EAI virent également l’avantage de disposer d’étapes proposant des interactions ‘utilisateurs’ à intégrer dans leurs procesus de systèmes à systèmes et ils commencèrent à inclure des fonctionnalités ‘utilisateurs’ rudimentaires dans leurs produits.
Ces fonctionnalités, généralement proposées par l’éditeur lui-même plutôt que par l’intégration d’un outil workflow du marché, étaient très rudimentaires car elles n’avaient pour seul but que d’adresser les besoins de gestion des exceptions ne pouvant être adressées automatiquement lors du déroulement des processus. On pourrait d’ailleurs dire que ces processus étaient “interrompus par l’utilisateur” plutôt que “interagissant avec l’utilisateur”.

Même si on disposait alors (en théorie) de systèmes adressant toute la gamme de besoins en terme d’intégration, il s’agissait en fait plus de systèmes workflow avec un peu d’EAI ou de systèmes EAI avec un peu de workflow, et les éditeurs continuaient à se focalisaient sur leurs suites initiales.

L’allongement des cycles de décision en phase d’avant-projet fût également un des effets de bord qui firent que ces architectures bicéphales furent peu mises en oeuvre. En effet, le fait d’avoir à choisir deux outils au lieu d’un lors de l’acquisition d’un moteur workflow (l’EAI embarqué en OEM n’étant pas nécessairement celui choisi par l’entreprise) complexifiait la démarche et venait fragiliser le montage rendant les Directions peu enclines à donner leur accord.

A suivre: diversification collatérale

Retrouvez l’article original sur le blog 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

J’ai beaucoup discuté ces dernières semaines avec Sandy Kemsley, une de mes anciennes collègues chez FileNet, qui fait depuis pas mal d’années du BPM son quotidien. J’avoue que Sandy n’est pas pour rien dans l’histoire de ce blog car ses encouragements à continuer l’aventure me permettent de trouver de nouvelles sources d’inspiration pour écrire mes notes personnelles.
Si vous lisez régulièrement la chronique de Sandy vous n’êtes pas sans avoir remarqué qu’elle a entamé depuis quelques semaines une série de notes sur l’histoire du BPM et elle m’a gentiment invité récemment à réutiliser une partie de ce contenu et à l’adapter en français en y joignant mes propres commentaires. Comme je trouve l’idée plutôt sympa, j’ai décidé de m’y mettre et voici donc une nouvelle rubrique sur ce blog qui va regrouper les différentes notes pompeusement intitulées “Un court historique du BPM“. Je précise ‘pompeusement’ car je n’ai aucune prétention en la matière, c’est tout simplement l’envie de réfléchir sur ce qu’a été le BPM à ses débuts, ce qu’il est aujourd’hui et ce qu’il pourrait être dans un proche avenir qui me pousse dans ma démarche.

Bien évidemment tous vos commentaires sont les bienvenus et seront publiés, et je ne manquerai pas de corriger mes notes si vous avez un apport intéressant à faire. En ce qui concerne les textes, et afin de rendre à César ce qui appartient à Sandy, j’ai pris la liberté de citer en italiques le texte original de Sandy et d’y ajouter mes commentaires en caractères normaux.

Première partie: Au tout début

Au tout début il n’y avait pas de workflow. Pour être plus précis, on pratiquait le routage de documents dématérialisés de personnes à personnes en suivant un processus prédéterminé.

Pour autant que je sache, FileNet a été le premier éditeur à utiliser le terme “Workflow” dans ce contexte, dans les années 80 quand la société à débuté, même si elle a été rejointe rapidement sur ce créneau par IBM et quelques autres acteurs.
La plupart de ces systèmes workflow étaient alors centrés “documents”, leur seule raison d’être étant de faire circuler un document dématérialisé - scanné, une image électronique donc - d’une personne à une autre afin que ces dernières puissent en traiter le contenu à l’aide de différentes applications, saisir des données liées à une transaction par exemple.

Je rajouterais même ici “au sein d’une seule et unique organisation”, la notion d’échanges entre partenaires métiers au-delà des frontières du Système d’Information ne faisant pas partie des capacités des systèmes workflow à cette époque.

Cette étape découlait d’une certaine logique après que les organisations aient commencé à scanner leurs documents afin de les préserver et de les partager : en effet, pourquoi ne pas les scanner avant de les utiliser, et ensuite les faire circuler de façon électronique afin d’améliorer l’efficacité de l’organisation ? Malheureusement toute tentative d’intégration directe entre les différentes applications du Système d’Information et les systèmes workflow était forcément spécifique, couteuse et très peu flexible.

En fait nous avons là la raison initiale qui fait qu’aujourd’hui encore les outils de workflow soient divisés en deux grandes familles, les workflow de routage (ou Ad Hoc) et les workflow métier (ou d’Entreprise). Il n’en reste pas moins vrai que cela avait du sens à une époque où les applications critiques d’Entreprise reposaient majoritairement sur des systèmes centraux (mainframes) et où il n’était pas trop question de les porter sur des systèmes Unix comme on peut le voir aujourd’hui avec les ERP, les CRM et autres progiciels de gestion.

A la suite, les systèmes workflow ont évolué lentement durant les années 90 pour devenir des produits plus fonctionnels et plus souples, particulièrement en matière d’intégration, supportant des plateformes serveurs et clients plus nombreuses, incluant des outils de conception des processus simples et des outils de supervision basiques. Dans la plupart des cas néanmoins, les produits de workflow restaient très orientés “documents” : le marché de la dématérialisation et de la gestion électronique des documents était alors une telle “vache à lait” pour la plupart des éditeurs qu’ils ne furent pas énormément visionnaires lorsqu’il s’agit de trouver des utilisations au workflow allant au-delà du simple routage documentaire d’un bureau à l’autre. Ceci a favorisé deux choses :

- des modules complémentaires aux outils du marché ont proliféré, afin de couvrir tous les besoins que les éditeurs ne jugeaient pas importants de couvrir
- des start-up plus souples et spécialisées dans le workflow (en fait les premiers éditeurs de BPM) allaient laisser de côté l’orientation “contenu” initiale et développer des produits de workflow qui n’étaient certes pas nécessairement capables d’assumer la charge quotidienne des entreprises mais qui avaient au moins le mérite de permettre l’élargissement du spectre fonctionnel.

Ce que dit Sandy est vrai, mais il faut aussi penser aux sociétés de services qui ont elles-aussi développé des modules tiers venant compléter les offres éditeurs. Bien souvent intégratrices de ces outils, ces sociétés ont permis aux éditeurs de prendre conscience du fait que les add-ons proposés avaient une vraie raison d’exister pour certains, particulièrement quand ces mêmes éditeurs voyaient leurs clients investir dans des outils compagnons et laissaient ainsi échapper une part non négligeable des revenus associés.

On peut également signaler la montée en puissance des acteurs issus du monde du groupware qui ont petit à petit commencé à intégrer dans leurs offres des fonctionnalités de routage très orientées “documents” bien évidemment. On ne saurait les classer aujourd’hui dans les éditeurs de BPM.

Avant d’en arriver à aborder ces deux sujets, il nous faut parler un peu de l’EAI.

A suivre …

Retrouvez l’article original sur le blog de Sandy Kemsley