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.

Introduction

Nous sommes passés, en une décennie, d’une multitude d’outils proposant des fonctionnalités d’édition documentaire et utilisant des GED spécifiques à une phase de consolidation dont a émergé une architecture basée sur une GED transverse unique dans laquelle les applications métiers déversent leurs documents.

Autour de cette GED gravite un ensemble de solutions produisant des documents :

• les applications métiers ;
• les applications bureautiques ;
• les processus.

Ces documents stockés dans la GED sont déplacés dans un système d’archivage intermédiaire (un autre tenant de la GED) et sont finalement :

• soit stockés dans un SAE (Système d’Archivage Électronique ;
• soit détruits.

Bluexml a développé très tôt chez ses clients une architecture de référence, dite transverse :

Face à tous ces outils, l’utilisateur, un peu perdu et soumis à une forte pression marketing (licence offerte), s’est parfois fourvoyé dans de mauvaises directions. Cependant, après plusieurs projets de GED réalisés ces dernières années, les utilisateurs voient la difficulté de mener à terme ces projets. Ils constatent également que les coûts de migration d’une version à l’autre sont très importants du fait des très nombreuses adaptations demandées par rapport au logiciel “de base”.

Gagnant en maturité grâce à ces expériences, les utilisateurs cherchent maintenant à construire des architectures composées de logiciels spécialisés, sans tordre ceux-ci, ne nécessitant pas de coûts supplémentaires excessifs pour un changement de version. Ils cherchent également à rationaliser leurs coûts d’exploitation via l’utilisation d’application SAAS et à simplifier l’interconnexion de toutes ces applications à leur SI.

A partir de ces besoins et de ces problèmes identifiés, Bluexml construit sa démarche d’innovation et la remet régulièrement à jour au fur et à mesure de l’évolution des technologies et des logiciels. Cette démarche veut proposer une approche simple, compréhensible par tous les acteurs, clients comme prestataires. Il ne faut pas que la connaissance ne se retrouve que chez le prestataire, ce qui arrive encore : cela n’a pas de sens !

Besoins utilisateurs

Les grandes fonctions auxquelles les utilisateurs cherchent une réponse, au-delà de la RH, la paie, la comptabilité ainsi que les fonctions liées à chaque métier, sont :

• le travail collaboratif, pour faciliter la création et le partage de contenu ;
• les processus (BPM), pour limiter le nombre de mails échangés et faciliter les échanges des informations et la pérennité du SI ;
• le stockage (GED) des documents de référence soumis à des contraintes légales ;
• l’archivage des documents soumis à des contraintes légales ou ayant une valeur historique.

GED

La GED propose de nombreuses fonctionnalités dont :

• La gestion de métadonnées ;
• La recherche par facettes ;
• La sécurité ;
• L’interopérabilité via le support de multiples protocoles (HTTP, FTP, ReST et surtout CMIS) ;
• Les transformations documentaires ;
• Le stockage d’un nombre TRÈS important de documents (Milliard(s)) ;
• La disponibilité d’API pour faciliter l’intégration de la GED dans le SI.

En comparant rapidement différentes solutions (Alfresco, Nuxéo, Sharepoint) sur ces critères, on obtient la matrice suivante :

La comparaison est assez caricaturale de façon à donner des éléments clairs de décision.

SharePoint Online (SPO) n’est pas vraiment une GED car :

• SPO ne supporte pas CMIS ;
• SPO présente des limites en termes de perf (limite de 300 K documents par site) qui empêche de l’utiliser dans de nombreux cas d’utilisation même avec des petites organisations (200 personnes) ;
• SPO présente des fonctionnalités de recherche limitée.

BPM

Le BPM propose de nombreuses fonctionnalités dont :

• La modélisation de processus métier
• L’utilisabilité
• La génération d’application
• L’interopérabilité

En comparant rapidement différentes solutions (Alfresco Process Services, Bonita, Flowable, SPO avec Flow ou PowerApps) sur ces critères, on obtient la matrice suivante :

SharePoint Online (SPO) n’est pas un outil de gestion de processus car :

• SPO ne supporte pas BPMNv2 ;
• SPO + Flow est un outil permettant de créer seulement des tâches automatiques (à l’instar des règles de gestion de contenu d’Alfresco) simples, en aucun cas des processus ;
• SPO + PowerApps est un outil de gestion de formulaires, orienté développeurs, utilisant des expressions plutôt complexes (sorte de super formules Excel), inutilisable par des fonctionnels.

Concernant SharePoint, des modules tiers supplémentaires peuvent fournir des fonctionnalités de BPM mais sortent, du coup, du champ de la comparaison.

Les autres choix (APS, Bonita et Flowable) présentent chacun des avantages et inconvénients. La solution Flowable (communautaire) est particulièrement efficace et appréciée par les fonctionnels qui parviennent après une courte formation (1j) à prototyper eux-mêmes leur processus.

Travail collaboratif

Les outils de travail collaboratif proposent de nombreuses fonctionnalités dont :

• La gestion de contenus web (CMS) ;
• L’édition en ligne simultanée et collaborative ;
• Le partage ;
• La mobilité.

En comparant rapidement différentes solutions (Alfresco Content Services, Nuxeo, SharePoint Online) sur ces critères, on obtient la matrice suivante :

Indiscutablement, SharePoint Online est un outil de travail collaboratif avec des fonctionnalités de CMS efficaces ainsi que des fonctionnalités d’édition en ligne et de rédaction collaborative utilisant MS Office en mode web (Office365 ou Word Online). On peut cependant clairement s’interroger sur sa facilité d’utilisation.

Alfresco et Nuxeo n’offrent pas, de base, de réelles fonctionnalités d’édition en ligne quoiqu’en disent les documents marketing. Des modules supplémentaires peuvent fournir des fonctionnalités d’édition en ligne (basées sur LibreOffice OnLine ou LOOL) mais sortent, du coup, du champ de la comparaison.

Solutions

Selon leur positionnement originel et la pertinence de leurs outils, les acteurs se sont spécialisés :

• au niveau fonctionnel
• au niveau du mode d’exploitation (sur site ou hébergé)

Spécialisation fonctionnelle

• Focus sur la GED et les processus documentaires : Alfresco ;
• Focus sur les processus documentaires : Flowable, Bonitasoft, Alfresco Process Services ;
• Focus sur le DAM : Nuxéo ;
• Focus sur le travail collaboratif : Sharepoint Online, LibreOffice OnLine.

Mode d’exploitation

Les solutions sont généralement disponibles sous 2 formes, quel que soit le métier visé :

• solution sur site (on premise) ;
• solution en mode SAAS, hébergé par l’éditeur ou par un prestataire.

Solutions on premise

Les solutions étaient auparavant toutes disponibles sur site et parfois en mode hébergé. Un transfert est en train de s’opérer au profit des solutions hébergées, certaines solutions sur site étant amenées à disparaître.

On peut ainsi voir les prémisses de cette fin avec, par exemple, la solution SharePoint. Disponibles en 2013 et 2016 en version “on premise”, ce n’est qu’en 2019 que la solution sur site est apparue, basée sur les fonctionnalités disponibles dans la version hébergée disponible depuis 2013, 2016… (SPO 2019) et agrémentée de fonctionnalités spécifiques au mode sur site comme le CMIS (non disponible en mode hébergé)… La version SPO est maintenant la version de référence à partir de laquelle seront déclinées les versions “on premise”. Il est parfois difficile de s’y retrouver.

L’avantage des solutions “on premise” est bien sûr la confidentialité des informations (données et documents), celles-ci n’étant pas hébergées sur le site de l’éditeur et leur maîtrise. Cependant, cette confidentialité oblige à une exploitation assidue des serveurs pour limiter les failles de sécurité et assurer une disponibilité correcte.

Solutions en mode SAAS

Certains éditeurs distribuent également leurs solutions en mode SAAS.

Avantages

L’avantage des solutions en mode SAAS est de proposer aux clients un coût par utilisateur incluant l’hébergement, mais aussi les coûts d’exploitation, pour une qualité optimale et une disponibilité proche des 99,99999%. Les utilisateurs ont du mal à résister à ce type d’offre qui leur permet de contourner les limites de leur organisation, notamment en termes de management RH, qui les empêche de proposer des hébergements avec une disponibilité correcte (comment redémarrer un serveur sans astreinte le we ?).

Inconvénients

Pourtant, par cet acte, les utilisateurs prennent plusieurs risques :

• “RGPD” ?
  • quelle assurance que la confidentialité sera assurée ?
  • que le vol de données est impossible ?
  • que les données ne sont pas utilisées par le fournisseur de services pour une quelconque manipulation (cf l’affaire Cambridge Analytica) ?
  • que les données ne sont pas “espionnées” ?

L’histoire nous a montré que les grands fournisseurs de service sont des organisations à but lucratif, soumises à des lois (Patriot Act par exemple) et à des pressions de tous genres. L’histoire nous montre chaque jour que des vols de données ont lieu chez les plus grands opérateurs (Amazon, Facebook, les banques…). Comment croire que vos données seront plus en sécurité chez eux ? D’un autre côté, si elles ne sont pas en sécurité chez eux, le sont-elles chez vous ?

En outre, le fait d’utiliser des services en mode SAAS vous expose aux risques suivants :

• quelle maîtrise des données ?
• quel suivi des utilisateurs ?
• comment interconnecter des applications hébergées sur différents serveurs sur différents réseaux sur lesquels vous n’avez pas de maîtrise ?

Plus globalement, des risques économiques et stratégiques apparaissent :

• quid si le fournisseur disparaît ?
• quid si le fournisseur de services décide de couper celui-ci sans préavis ?
• quid si le fournisseur de service subit une pression extérieure (gouvernementale ou para-gouvernementale par exemple) pour couper, espionner, modifier celui-ci ?

Le réseau souverain

Si le SAAS, qui répond à de vraies problématiques, a de beaux jours devant lui, la mise en place d’un réseau souverain, par exemple à l’échelle européenne, basé sur des architectures open source ou en tout cas auditables et maîtrisées, permettrait de pallier à certains des risques identifiés.

Architecture cible

Pour répondre à ces différents besoins fonctionnels, sans prendre en compte les risques identifiés préalablement, plusieurs architectures sont possibles :

• (BAD) SharePoint Online est l’application de référence ;
• (GOOD) VOTRE application de référence.

Bluexml vous conseille clairement de développer VOTRE application de référence afin d’investir vos ressources dans un objectif durable.

(BAD) SharePoint Online est l’application de référence

Cette solution où SharePoint est le frontal de référence pour vos utilisateurs est l’erreur dans laquelle il faut éviter de tomber. La conduite du changement s’avèrera plus compliqué si vous souhaitez en changer, vos utilisateurs ayant pris l’habitude de son interface dès la connexion.

(GOOD) VOTRE application de référence

Faire ce choix consiste à se concentrer sur vos besoins et vos utilisateurs et non sur un produit. Vos investissements sont pérennes. L’utilisateur finira par aller peut-être sur SharePoint Online ou sur LibreOffice Online, mais après être passé par VOTRE application. Du coup, les changements, s’il y en a, interviendront à un second niveau et auront un impact moins important.

Bluexml vous conseille clairement de développer VOTRE application de référence afin d’investir vos ressources dans un objectif durable.

Conclusions

Les outils d’ECM ont longtemps proposé des fonctionnalités de BPM et de travail collaboratif. Les difficultés de migration des processus intégrés ainsi que leur limitation ont fait que les utilisateurs se sont dirigés vers des solutions de BPM pures. En parallèle, des solutions puissantes d’édition collaborative, en ligne, utilisables à travers le navigateur, sont devenues très présentes comme Word Online (Office365), LibreOffice OnLine (LOOL) ou Google Docs présent sur ce marché depuis déjà une dizaine d’années.

Du coup, les fonctions sont aujourd’hui clairement identifiées et structurées dans des architectures techniques spécifiquement conçues pour faciliter leur évolution, voire leur changement. Le temps où une application essayait de couvrir tout le champ fonctionnel semble révolu.

Choisir une telle architecture ayant un impact sur votre SI et votre budget pour de nombreuses années, nous vous conseillons de proposer à vos utilisateurs une interface qui soit la vôtre, et non celle d’un éditeur. La conduite du changement en sera d’autant facilitée.

Bluexml vous conseille clairement de développer VOTRE application de référence afin d’investir vos ressources dans un objectif durable.