Tendances : ACM vs. BPM

L’amélioration des processus métier d’entreprise est un domaine auquel l’IT s’est attelée dès le début des années 1990 avec l’avènement des Systèmes d’Information distribués et le besoin naissant de rationaliser des activités réparties en de multiples applications de l’entreprise. Depuis 20 ans, l’axe d’amélioration privilégié a principalement été de rechercher une automatisation maximale des processus, en repensant le SI comme pourvoyeur de « services intelligents » et en reconsidérant l’humain comme fournisseur de « données manquantes ». Au centre de cette automatisation s’est inséré un chef d’orchestre technique – le moteur d’exécution de processus – qui est venu combiner dans une logique dirigiste les services nobles du SI et les tâches subalternes de l’humain.  Cette tendance a été largement débattue  dans les nombreux ouvrages publiés sur le Business Process Management (BPM) et ses variantes BPx (x = Modeling, Reengineering, Optimization…). Elle a été directement supportée par les nombreuses plateformes BPM aujourd’hui disponibles (IBM Lombardi, RedHat jBPM, Tibco ActiveMatrix, SAG webMethods etc.).

Cette approche tayloriste s’est finalement émoussée au contact de contraintes de terrain qui ont globalement restreint son applicabilité à des processus d’entreprise de périmètres simples, étroits et spécialisés à l’opposé de ses prétentions initiales de portée complexe et transverse. Ces contraintes sont tout à la fois culturelles (savoir oral vs. écrit…), organisationnelles (concentration du savoir en quelques experts vs. démultiplication en une armée de « sachants »…), techniques (existant applicatif inflexible vs. SOA…), stratégiques (revalorisation de l’existant applicatif vs. investissement en refonte …) et forcent les programmes d’amélioration des processus métier à plus de modestie et de pragmatisme. De cet échec d’un BPM trop normatif a même émergé (ou ressuscité) un nouveau paradigme – l’Adaptive Case Management (ACM = gestion adaptive d’activité) – dans lequel l’humain reprend un rôle prépondérant en terme de « comment et quand » faire ses activités et où le SI se limite à proposer des activités à faire et d’en suivre et piloter la réalisation. La frontière n’en est pas devenue pour autant limpide entre ce que sait faire le SI et ce que sait faire l’humain mais ce paradigme de BPM « passif » reconnait au moins l’inadéquation du BPM « actif » à supporter des processus métier complexes et transverses.

Retour d’expérience : ACM né du contexte

Nous avons vécu ce changement d’approche au cours d’une mission pour laquelle nous avons participé à l’amélioration d’un sous ensemble des processus cœur de métier de l’entreprise. Notre première réponse a été classique : un BPM « actif » qui identifie, modélise et exécute les processus dans un moteur d’exécution de processus doit aboutir à l’objectif fixé : plus de clients servis en moins de jours. Cette approche a été immédiatement remise en cause pour des raisons d’au moins trois ordres :

• Culturelles : l’expertise est plus humaine plus qu’informatique. La connaissance s’enracine dans des experts qui savent appréhender les détails des cas les plus complexes,
• Techniques : le SI présente des applications cœur de métier dont les écrans et les traitements contiennent déjà des fragments de processus qu’il est inutile d’externaliser pour les porter dans une technologie BPM. Le SI est par ailleurs très peu orienté service,
• Stratégiques : les sponsors sont intéressés avant tout par la gestion d’activité  (Business Activity Monitoring (BAM) = quelles activités, faites par qui, à quels moments, en quels nombres, avec quels reste à faire sur le processus global…)) plutôt que par les activités elles-mêmes (comment se fait telle ou telle activité à l’intérieur des applications cœur de métier existantes).

Ce besoin de flexibilité dans le déroulement des processus métier nous a conduits à créer une architecture sur mesure dans laquelle des événements de rupture d’activité (réclamation client enregistrée…), des règles d’enchainement d’activité (après l’ouverture, missionner un expert si…), des fragments de processus techniques (relance de document par email au bot de 5 jours…) et fonctionnels (indemniser le client par virement et l’informer par courrier…) viennent compléter les applications existantes pour assurer l’instruction d’un dossier de prise en compte de réclamation.

Architecture applicative : un moteur BPM asservi

L’architecture proposée comporte 6 blocs applicatifs majeurs, chacun de périmètre fonctionnel complémentaire :

• Les applications (cœur de métier, messagerie, GED…) sont pleinement réutilisées et gardent les règles de présentation et métier de chacun des actes de gestion (ouverture de réclamation, missionnement d’expert, règlement de client…) et de contact (demande / réception de document au / du client…). Elles sont modifiées pour publier un événement technique dûment caractérisé lorsqu’un acte est terminé, qu’il ait été exécuté sous le contrôle de l’utilisateur ou de l’exécuteur de processus,
• Un coordinateur d’événements est placé en abonné des événements publiés par les applications. Un événement non associé à un dossier donne lieu à la création d’un nouveau dossier. Chaque événement est ajouté à son dossier pour audit, puis transmis à l’exécuteur de processus pour éventuellement réveiller un fragment de processus (demande / réception de document…). Il alimente enfin un exécuteur de règles pour éventuellement proposer à l’utilisateur un ou plusieurs fragments de processus à créer,
• Un exécuteur de règles (EdR) d’enchainement de fragments de processus. A partir d’un événement et du dossier associé, il suggère à l’utilisateur des fragments de processus pour continuer l’instruction du dossier (processus de missionnement d’un expert à la suite d’un événement de création d’une réclamation…). Le paramétrage de ces règles est à la main du métier pour assurer une souplesse dans la démarche,
• Un exécuteur de processus (EdP) qui instancie et exécute des fragments de processus suggérés par l’EdR et choisis par l’utilisateur. Les fragments de processus matérialisent soit des actes isolés (régler), soit des actes techniquement liés (missionnement expert suivi de demande, relance et réception de documents), soit des actes fonctionnellement liés (missionnement expert suivi de règlement client pour un dossier avec un montant faible). Dans ce dernier cas, des transitions complexes peuvent être déterminées par l’EdR pour passer d’une étape du processus à une autre.
• Un exécuteur de tâche (EdT) qui crée une tâche dans le contexte d’un fragment de processus ou hors processus (flexibilité de l’approche qui permet dynamiquement d’ajouter des tâches pour un dossier). Cette tâche représente un acte à effectuer manuellement dans une application. Elle est attribuée à une corbeille. Le statut de cette tâche suit un cycle de vie que l’utilisateur ou le moteur de règle font évoluer de « à traiter », à « en exécution », puis à « traitée ».
• Un portail qui permet aux utilisateurs habilités de consulter les dossiers avec les objets métier, les tâches et les événements qui les composent. Depuis ce portail, les utilisateurs ont accès à la liste des tâches des corbeilles auxquelles ils sont affectés. L’exécution d’une tâche correspond à une prise en traitement (réservation), à un débranchement sur l’écran pré-rempli des informations du dossier dans l’application associée et à une clôture automatique ou manuelle.

Flexibilité de la solution

Dans cette architecture, les processus métier tirent leur flexibilité d’une plus grande implication de l’utilisateur qui peut à tout moment aménager le déroulement d’un processus existant en ajoutant des tâches non prévues dans la gestion du dossier ou activer les règles d’enchainement d’activité pour choisir une activité suivante. La flexibilité est aussi apportée par la non nécessité de prévoir d’entrée l’exhaustivité des situations et les processus de bout en bout. Le métier peut ainsi progressivement améliorer en plusieurs itérations les fragments de processus tout en sachant que l’utilisateur peut toujours intervenir pour débloquer ou poursuivre dans des cas non anticipés.

Filed under: Articles