Processus de gestion mêlant BPM (Flowable) et ECM (Alfresco)

Introduction

Ce processus consiste à faciliter le contrôle des commandes publiques en suivant un processus via un outil de BPM (Flowable), qui interagit avec des documents stockés dans un ECM (Alfresco).

Cette implémentation aurait pu être faite avec d’autres outils BPM comme Activiti, Bonita, ou ECM comme Nuxéo, Sharepoint (mais Sharepoint est-il vraiment un ECM ?)

Cahier des charges

Très succinctement, un atelier avec le service métier nous permet de décrire globalement le processus :

1. 1. Création des pièces techniques : Les pièces techniques sont rédigées par le service opérationnel (SO). Ces pièces sont transmises par répertoire ou e-mail à la direction des affaires financières (DAF) du service opérationnel.
   2. Stockage des documents : les pièces marchés sont stockées par dossier en fonction de l’état du dossier. Le plan de classement stocke les dossiers marco en fonction de leur état d’avancement : Le dossier marco est déplacé de répertoire en répertoire et reflète l’état du processus.
   3. Dépôt des pièces initiales dans MARCO : Après réception des pièces techniques, la DAF ou le service opérationnel autonome de la DGA-AT réalise les actions suivantes dans MARCO :
      1. Création des pièces administratives,
      2. Dépôt dans MARCO de l’ensemble des pièces techniques,
      3. Enregistrement du dossier complet dans Alfresco depuis MARCO, le statut du dossier indique « Enregistré ».
   4. Consolidation du dossier dans Alfresco : Après la création du dossier dans Alfresco, la DAF et le SO doivent le consolider en ajoutant les fiches qualités ( fiche de revue et fiche de planification) et l’estimation du marché. Ces fiches ne doivent pas être disponibles dans MARCO vu qu’elles ne sont pas destinées à être publiées. Lorsque le dossier est complété, la DAF initie le workflow de validation du marché initial.
   5. Contrôle du service de la commande publique : Lors de cette étape, le dossier ne doit être accessible qu’au service de la commande publique. Aucun accès en lecture ne doit être attribué au service opérationnel et à la direction des affaires financières. L’instructeur du service de la commande publique dépose la fiche d’observation et indique les modifications nécessaires au dossier.
   6. Mise à jour des pièces marché : Le dossier MARCO retrouve ses droits initiaux, il n’est plus limité au service de la commande publique. La DAF et le SO doivent mettre à jour les pièces marché dans MARCO et suivant les observations réalisées par le service de la commande publique.
   7. Validation par le service de la commande publique : Cette étape est la seule étape du workflow qui propose un choix d’action. Le service de la commande publique a le choix entre valider le dossier ou le refuser :
      1. En cas de refus, le workflow retourne à l’étape 5) de mise à jour des pièces marché pour que le service de la commande publique mette à jour les documents selon les remarques contenues dans la fiche d’observation.
      2. En cas de validation, le statut du dossier est enregistré à « validé » et le SO et la DAF sont notifiés de sa validation.
   8. Transfert du marché vers AWS : Après validation de l’ensemble des pièces marché, le SO et la DAF doivent transférer l’ensemble des pièces présentes dans MARCO vers AWS. Cette étape est faite manuellement par les agents depuis MARCO.
   9. Publication du marché : Après transfert des pièces vers AWS, le SO et la DAF doivent publier le marché dans AWS.

Réalisation

Côté BPM

Processus v1

A partir de ces demandes, le processus suivant a été dessiné :

Remarques :

• Des notifications ont systématiquement été ajoutées afin de faciliter la conduite du changement, même si elles sont inutiles avec l’utilisation d’un outil de gestion de tâches. Elles seront supprimées dans un deuxième temps.
• Des appels sont faits à des systèmes externes :
  • pour la récupération de listes de valeurs qui vont venir alimenter les listes déroulantes dans Flowable ;
  • pour exécuter des actions sur la GED afin de déplacer les dossiers et mettre à jour leur état.

Processus v2

Après plusieurs échanges avec le client et quelques itérations de modélisation entre le métier et un spécialiste fonctionnel, le processus final ressemble à ceci :

Ce processus final n’utilise pas de swimlanes du fait d’un bug dans Flowable Modeler qui empêche dans ce cas l’utilisation de sous-processus. Du coup, celles-ci sont simulées par le positionnement des étapes sur des lignes virtuelles. Un commentaire à gauche permet de préciser le groupe assigné.

Les sous-processus suivants ont été créés :

• Assignation instructeurs
• Pré-contrôle
• A corriger
• Post-validation

Ils permettent de regrouper les actions jouées lors du passage des transitions et facilitent ainsi la lecture et la compréhension du processus, comme on pourrait le faire avec des fonctions dans un programme écrit traditionnellement.

Côté ECM

Le plan de classement “de base” est initialisé. Les dossiers sont créés automatiquement par la suite à partir des métadonnées fournies par Marco lors du dépôt du dossier.

L’accès aux dossiers est géré par des droits d’accès, positionnés sur le plan de classement physique fourni par le service métier, qui protègent les dossiers et documents. Des droits « ad hoc » sont rajoutés selon les transitions suivies dans le processus pour s’adapter aux besoins précis du métier.

Remarque :

• Création dans Alfresco d’une action permettant de lancer le processus de contrôle sur un dossier en fonction de l’état du dossier et de l’appartenance de l’utilisateur courant à un groupe spécifique (en l’occurrence, le goupe DAF des instructeurs financiers)
• Création d’un webscript permettant de « bouger » le dossier fourni en paramètre pour refléter l’état du processus
• Création d’un script pour mettre à jour les permissions

Groupes et utilisateurs

Les groupes et utilisateurs assignés sont basés sur les groupes Alfresco afin d’éviter de reproduire dans Flowable une configuration de groupes identique à celle existant déjà.

Par défaut, Flowable propose d’utiliser une base LDAP pour s’authentifier et gérer les groupes. Cependant, ce connecteur oblige à recréer les groupes créés localement au niveau d’Alfresco, la structure des annuaires LDAP ne correspondant jamais à la structure logique attendue. L’utilisation d’Alfresco comme un fournisseur d’identité (utilisateurs, groupes, privilèges) pour Flowable nécessite :

1. soit de développer un connecteur IDM pour Alfresco pour que Flowable s’appuie sur les utilisateurs et groupes définis dans Alfresco (locaux ou issus d’une synchronisation LDAP) ;
2. soit de jouer de la possibilité d’utiliser une variable contenant une listes d’utilisateurs potentiels pour la réalisation d’une tâche, cette variable pouvant être calculée par un appel de webscript sur Alfresco qui renverra donc la liste d’utilisateurs adéquats correspondants à un groupe Alfresco (local ou non).

La solution 2 est immédiate et facile à mettre en oeuvre. Cependant, la solution 1 est plus « propre » et correspond mieux à la logique de Flowable. Elle est en revanche nettement moins triviale.

Résultat

L’implémentation donne les résultats suivants. Plutôt qu’une longue succession de captures d’écrans et d’explications textuelles, je vous propose la vidéo suivante qui commente étape par étape le fonctionnement de l’application du point de vue des utilisateurs :

Conclusions

Le BPM et tous les outils répondant à cette logique permettent de répondre rapidement et facilement aux besoins principaux des utilisteurs. Cependant, il faut prévoir une étape où un développeur interviendra pour gérer les aspects techniques.

Un socle technique adéquat, tel que celui proposé par Bluexml, évite, ou à tout le moins, retarde, l’appel à un développeur permettant ainsi aux métiers de répondre rapidement à ses besoins sans dépendre de contraintes budgétaires ou de moyens humains que trop souvent on leur oppose.

Afin de vous aider à prendre en main le BPM, et éventuellement le lier à un ECM comme Alfresco, Bluexml se tient à votre disposition et propose une formation, éventuellement sous forme d’un transfert de compétences, pour réaliser en totalité ou en partie la présentation qui vous a été faite à travers ce billet de blog.