Un court historique du BPM – Quatrième partie
sur une idée originale 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