BPM : enfin des offres crédibles !

Dans un marché stable présentant des offres mâtures, la DSI a désormais les moyens de donner aux directions métiers la maîtrise tant attendue des processus d'entreprise.

Les différents voyants des tableaux du bord du BPM passent au vert . Ça y est, le marché du logiciel de gestion des processus métier est mature ! La conjonction de l'offre et de la demande, a poussé les éditeurs leaders du  software à se lancer dans une lutte acharnée de rachat. Les directions métiers ont en effet compris l'intérêt du BPM pour offrir à l'entreprise l'agilité et la maîtrise dont elle a besoin. Le marché du logiciel n'est plus divisé en deux typologies de produits (Processus d'intégration et Workflow humain), il n'y a plus de limites entre ces deux mondes. Les grands éditeurs généralistes (IBM, Oracle, BEA, Software AG...) ont terminé leurs emplettes, et sont en phase de restructuration dans ce domaine. Le rachat des "pure player BPM" (Staffware, Fuego...) les a incités à repositionner leurs offres autour de ces acquisitions.

Un projet BPM d'envergure s'accompagne souvent d'une réflexion sur le poste de travail. Les derniers "pure player" (Lombardi, Savvion...) remportent sur ce point la bataille de l'ergonomie en proposant des outils collaboratifs (pour la modélisation des processus) et de la génération automatique d'IHMs Web 2.0 conviviales. Cette dernière fonctionnalité est à nuancer chez les grands comptes en fonction de la maturité des équipes études des DSI. Ces éditeurs, proposent une solution complète et intégrée d'outils, de la simulation au monitoring en passant par la connectivité Web Service, leur garantissant l'interaction avec un bus de service externe. Ils ont ainsi les moyens de séduire les directions métiers et les porteurs de projets MOA .
 
La maturité des offres passe aussi par celle des standards associés à la SOA. Elle est désormais éprouvée par leur capacité à supporter les charges d'exécution pour les processus critiques et coeur de métiers (processus de recouvrements, de gestion de crédits, de gestion des réclamations...). Ces technologies sont totalement encapsulées dans des connecteurs adéquats masquant la cuisine technologique (c'est un outil métier avant tout) assurant une facile intégration des modules BPM dans une infrastructure existante.

Reste l'éternel débat sur l'évolution de la notation de modélisation, où BPMN 2.0 et BPDM entrent clairement en conflit sur la sérialisation XML des processus modélisés. Pour simplifier, ce dernier point concerne le portage entre la modélisation du processus et sa traduction en termes de processus d'exécution. Par expérience, l'idéal est de bénéficier d'un outil permettant à la fois une modélisation métier et technique.

Aujourd'hui la DSI a les moyens de répondre aux attentes et aux exigences de ses métiers sur le thème de "l'automatisation des processus".  On constate deux approches à la problématique BPM

- Le BPM comme couche d'orchestration des flux métiers. Souvent associé à une démarche plus globale SOA, le projet BPM est alors considéré comme l'ultime étape ; il fait suite à la mise en place d'un bus de services interconnectant des progiciels dorénavant ouverts. L'intervention humaine est considérée comme une étape de rupture parmi des étapes  d'orchestration de services techniques (vision très orwellienne, j'en conviens). Cette typologie de projet a pour objectif de fluidifier la mise en oeuvre de nouveaux processus par l'identification d'une combinaison de services existants.

Cette démarche n'a de sens que lorsqu'elle est conjointement menée avec une réflexion plus générale d'urbanisation du système d'information. En effet, quel intérêt y a-t-il à combiner des services qui seraient redondants, peu cohérents et d'une granularité approximative ? Dans cette approche, la modélisation recouvre toute son importance pour prendre en compte les changements et autres évolutions au gré des transformations exigées par les métiers. D'où, parfois, la légitimité de prendre toute une suite logicielle intégrée chez un même éditeur. 

- Le BPM comme pilote et garant de l'optimisation des flux métiers. La démarche, souvent portée par les directions métiers, vise à améliorer de manière continue la performance des processus métiers et permettre une meilleure allocation des ressources requises. Découvrir les points de contention, simuler les modifications d'un processus liant à la fois des taches humaines et des services techniques et ainsi en prévoir les prochains coûts, améliorer les temps de traitements entre plusieurs acteurs, tels en sont les enjeux. Il incombe aux DSI de saisir cette opportunité de lancer conjointement une démarche de rationalisation des services applicatifs et d'infrastructure du SI pour répondre à ces besoins.

La gestion des processus métiers s'inscrit alors dans une démarche plus générale de gouvernance du système d'information.

Quelle que soit l'approche la bonne recette tient en deux principes : un cycle projet court et une méthodologie adaptée. Afin de garantir le succès d'un projet BPM, il est judicieux de mettre en place une méthodologie itérative de type agile permettant des échanges rapides de validation entre le  propriétaire du processus et son implémenteur IT - un délai moyen de 14 semaines est constaté entre la phase de lancement du projet et la mise en production du processus, avec des cycles en 4 étapes classiques  ("Requirements - Design - Build - Test").

Cette organisation projet permet de s'affranchir de la problématique de désynchronisation entre des environnements de modélisation souvent disjoints, et de s'assurer d'une mise en oeuvre conforme aux attentes des métiers. C'est sur cet effort d'adaptation que repose la réussite d'un projet BPM. D'aucuns s'affranchissant de cette contrainte auraient de grande chance de voir leurs initiatives échouer et repousser un ROI pourtant clairement identifiable par les métiers.