1 – Préambule

Flowable est un outil de BPM, acronyme de Business Process Management, c’est à dire la Gestion des Processus Métiers, ce qui parle tout de suite plus 😉
De manière schématique, c’est une palette d’outils destinés à des utilisateurs métier (spécialistes fonctionnels) pour qu’ils décrivent leurs processus métier, qui peuvent être aussi simples et usuels qu’une demande de congés que complexes et uniques comme un diagnostic de panne pour un avion. A partir de la modélisation réalisée, selon les outils, on obtient automatiquement une application de gestion des tâches permettant de saisir des données dans des formulaires pour démarrer un processus, visualiser le processus et son état d’avancement, réaliser une tâche… Des outils complémentaires permettent généralement d’analyser les processus et de produire des statistiques fonctionnelles, techniques, d’exploitation afin de les suivre, les auditer, de mieux comprendre leur fonctionnement et de les optimiser dans une approche itérative d’amélioration progressive continue.

Flowable est un fork d’Activiti et présente le même périmètre fonctionnel que Bonita, Intalio, W4 qui sont ses principaux concurrentes… Les grands éditeurs comme IBM, Microsoft… ont également leur outil.
La quasi-totalité des logiciels qui appartiennent au domaine du BPM travaillent sur le standard de formalisation BPMNv2 (BPM Notation). Ces logiciels permettent de créer, éditer, importer, exporter des processus au format BPMNv2, c’est à dire respectant une notation standardisée permettant d’échanger les éléments entre les outils. Comme nous le verrons, un processus est également constitué de formulaires, tables de décision… qui ne font pas obligatoirement partie de la notation BPMNv2 et qui feront que, dans la pratique, on ne récupère qu’une partie des éléments constituant un projet.

2 – Introduction

Notre objectif est de créer un premier processus de gestion de demande de congés dans le cadre de l’informatisation du périmètre fonctionnel RH. Nous créerons par la suite d’autres processus RH qui viendront s’ajouter à notre bibliothèque.

Les outils de BPM permettent généralement de définir les éléments suivants :

• Le(s) processus proprement dit permettant d’exprimer la circulation des informations, données et documents ;
• Le(s) formulaire(s), permettant de saisir et afficher des données, joindre des documents ;
• La(es) table(s) de décision permettant à partir de critères basées sur des valeurs issues du processus, de formulaires, de référentiels externes de calculer une conclusion….
• L’application, donnant accès, en fonction de vos droits, aux processus accessibles dans le cadre d’un module ainsi qu’aux tâches à réaliser pour l’utilisateur connecté.

A l’issue de ce tutoriel, vous serez capable de créer un processus et l’utiliser avec d’autres acteurs, indépendamment de tout autre élément logiciel. Un BPM peut généralement fonctionner de manière totalement autonome. Il n’a pas besoin d’une GED par exemple.

Il est cependant clair qu’associé à une GED, un outil de BPM permet de construire une solution très puissante puisqu’on bénéficie alors des fonctionnalités d’indexation, de recherche, de transformation documentaire, de partage particulièrement bien développées dans les GED.

On a bien ainsi :

1 (GED) + 1 (BPM) = 3

Bien sûr, je pars du principe que Flowable est installé et initialisé. L’installation et l’initialisation ont fait l’objet d’un autre tutoriel.

3 – Demande de gestion de congés

3.1 -Analyse

L’analyse consiste à réaliser les étapes suivantes :

• étude de l’existant
• rédaction des spécifications

3.1.1 -Existant

J’ai la demande de congés suivante :

Elle est basée sur un fichier Excel et permet simplement de saisir les dates de début/fin et le type de congés souhaité.

Le processus de validation consiste à l’envoyer par mail à l’adresse rh@xxx.com qui s’occupe alors de la traiter et de renvoyer la réponse au demandeur initial.

3.1.2 -Spécifications

La demande de congés est initialisée par le demandeur. L’objectif est de réaliser la gestion de cette demande de manière complètement dématérialisée en la passant d’acteurs en acteurs, chacun réalisant les tâches qui lui incombent à travers une application spécialisée.

Cette approche pilotée par les processus pourrait dans un second temps être rematérialisée afin de faciliter la consultation, le partage, l’archivage…

De manière très succincte :

• l’initiateur remplit un formulaire de demande ;
• il saisit son service, les dates de début et de fin, le type de congés… ;
• lorsqu’il valide sa demande, le responsable destinataire est automatiquement déduit en fonction de son service d’appartenance ;
• ce responsable approuve ou rejette la demande ;
  • si elle est rejetée, un commentaire doit être ajouté et la demande est renvoyée à l’initiateur qui la corrige ;
  • si elle est approuvée, elle doit passer alors par le responsable RH ;
• la demande suit alors le même circuit que précédemment :
  • si elle est rejetée, un commentaire doit être ajouté et la demande est renvoyée à l’initiateur qui la corrige ;
  • si elle est approuvée, un mail est envoyé à l’initiateur tandis que le service RH enregistre la demande.

3.1.3 -Roadmap

L’objectif est d’avoir une première version le plus rapidement possible en utilisant les fonctionnalités par défaut de Flowable. Ainsi, la roadmap est la suivante :

• v1, le processus est piloté par Flowable ;
• v2, les informations précédemment saisies sont déterminées automatiquement à partir de l’utilisateur et d’un référentiel externe ;
• v3, le processus est rematérialisé sous la forme d’un document PDF stocké et classé automatiquement dans Alfresco afin de permettre la constitution d’un dossier agent ;
• v4, le processus peut être piloté par la GED.

3.2 – Réalisation

La réalisation suit les étapes suivantes :

• Modélisation du processus
• Définition des formulaires
• Définition des tables de décisions
• Finalisation du processus
• Configuration de l’application

3.2.1 -Modélisation du processus

Nous allons créer plusieurs versions de ce processus dans le cadre d’une suite de tutoriels afin de montrer la démarche de modélisation.

Connectez-vous sur http://localhost:8080/flowable-modeler/ avec un compte utilisateur qui a les privilèges de « modeleurs ».

Cliquez sur Créer un processus et reproduisez le processus suivant :

Rien ne vaut une bonne séance d’essais/erreurs, vous verrez que ça vient vite 😉

Ce travail correspond à une démarche de modélisation et s’appuie sur les étapes suivantes :

• Circulation de l’information ;
• Formulaire de saisie des informations ;
• Tables explicitant les critères de décision et les déductions à faire.

3.2.1.1 -Circulation de l’information

Cette étape de modélisation consiste à dessiner le circuit que l’information doit suivre pour passer d’une étape à l’autre.

Le risque n°1 est de sur-modéliser : tout excité par la possession d’un nouvel outil qui semble vous permettre de tout faire, vous risquez de modéliser des cas qui n’arriveront que rarement. Jouez plutôt la carte de la simplicité en vous concentrant sur les 80 % de fonctions que vous pouvez atteindre avec 20 % de l’effort.

Pensez en outre que si vous êtes dans une démarche de dématérialisation, vous n’avez vraisemblablement rien pour le moment, donc toute réalisation est déjà un plus . Soyez donc raisonnable et ne visez pas trop haut au risque de vous retrouver dans un tunnel très rapidement…

Ceci étant dit, je vous invite à suivre les étapes suivantes :

• Cliquez sur l’événement de démarrage (start event) et donnez-lui un nom correspondant à sa fonction : Demande initiale de congés
• Cliquez et déplacez l’événement de fin (end event)
• Cliquez, déplacez puis déposez les activités correspondantes à des actions faites par les utilisateurs :
  • Validation N+1
  • Correction demande de congés
  • Validation N+2
• Cliquez, déplacez puis déposez les « exclusive gateways » (pour les conditions) permettant d’avoir une ou plusieurs transitions en sortie d’une activité :
  • Une gateway après Validation N+1
  • Une gateway après Validation N+2

3.2.2 -Formulaires

Cette étape de modélisation consiste à dessiner les formulaires de saisie que les utilisateurs vont devoir remplir en fonction de l’avancement du processus.

On retrouve un formulaire pour l’étape de démarrage ainsi qu’un formulaire pour chaque activité humaine ci-dessus :

• Un formulaire pour la demande de congés initiale : FORM_CREATION ;
• Un formulaire pour la validation N+1, permettant de valider la demande par le N+1 en fonction du service d’origine du demandeur. Le formulaire permet de consulter les données saisies précédemment mais pas de les modifier. En revanche, un champ de commentaires est disponible afin de pouvoir indiquer le problème éventuel : FORM_VALIDATION ;
• Un formulaire pour la correction, permettant à l’initiateur du processus de modifier sa demande. Les champs sont donc à nouveau en écriture mais le champ commentaire saisi par l’approbateur est en lecture seule : FORM_CORRECTION ;
• Un formulaire pour la validation, permettant de valider la demande par le N+2 en fonction du type de la demande. C’est exactement le même formulaire que pour l’étape de validation N+1.

Comme vous pouvez le constater, les formulaires suivent des conventions de nommage pour faciliter la communication, la maintenance… Il est prépondérant d’être cohérent !

3.2.2.1 -FORM_CREATION

Le champ Direction contient les valeurs suivantes :

• Commercial
• Communication
• Informatique

Le champ Motif contient les valeurs suivantes :

• Congés payés
• RTT

Pour les listes déroulantes, le premier élément sera considéré comme neutre (c’est celui qui fera office de titre pour les choix possibles). Veillez donc à ne pas mettre une des valeur de la liste comme un choix possible sous peine de ne pas pourvoir le sélectionner lors du déroulement du processus.

A l’issue de sa demande, l’initiateur peut simplement envoyer sa demande. Seul le bouton « OK » est disponible :

• Cliquez sur l’onglet Résultats ;
• Cliquez sur « Utiliser des résultats personnalisés pour ce formulaire » ;
• Saisissez « OK » ;
• Ne cliquez pas sur « Ajouter un résultat » mais sur Enregistrer (icône de disquette en haut à gauche… qui ne doit pas beaucoup parler aux jeunes générations 😀 )

3.2.2.2 -FORM_VALIDATION

Pour le formulaire « form_validation », inutile de ré-inventer la roue. Faites simplement une copie de « form_creation ».

Ce formulaire permet de valider la demande. La philosophie est de pouvoir consulter toutes les informations préalablement saisies afin de vérifier la demande tout en empêchant leur modification. Ces informations sont donc en lecture seule.

Un champ Commentaires a été ajouté pour permettre à l’approbateur d’indiquer la raison du refus pour faciliter la correction de la demande par l’initiateur.

En outre, le valideur peut :

• soit accepter et appuyer sur OK
• soit refuser la demande et appuyer sur Corriger

Il faut donc créer ces 2 boutons :

• Cliquez sur l’onglet Résultats ;
• Cliquez sur « Utiliser des résultats personnalisés pour ce formulaire » ;
• Saisissez « OK » puis cliquez sur « Ajouter un résultat » ;
• Saisissez « Corriger » ;
• Ne cliquez pas sur « Ajouter un résultat » cette fois mais sur Enregistrer.

3.2.2.3 -FORM_CORRECTION

De même pour « form_corection », une copie de « form_validation » vos donnera toutes les bases pour votre nouveau formulaire.
Le champ Commentaires a été saisi par le valideur N+1 pour indiquer la raison de la correction afin que le demandeur puisse modifier sa demande. Le champ Commentaires est en lecture seule.

A l’issue de la correction, seul le bouton « OK » est disponible pour l’initiateur de la demande, n’oubliez pas de l’ajouter !

3.2.3 -Tables de décision

Une table de décision est un outil permettant de formaliser, à partir d’un ou plusieurs critères d’entrée, le ou les résultats souhaités.

Dans notre application de gestion de demande de congés, les tables de décision permettent de :

• sélectionner le groupe d’approbation N + 1 (par exemple les chefs de service) en fonction du service auquel l’utilisateur appartient pour vérifier que cela ne nuit pas au bon fonctionnement de celui-ci ;
• sélectionner le groupe d’approbation N + 2 pour valider la demande au niveau RH.

Une bonne pratique consiste généralement à assigner une tâche à un groupe plutôt qu’à un utilisateur afin de faciliter la gestion de l’organisation et pallier aux absences, aux réorganisations, aux départs…

3.2.3.1 -Sélection N+1 en fonction du service du demandeur

Techniquement, cette table de décision sera traduite en une succession de si/alors/sinon successifs :

SI direction est vide

ALORS le groupe d’approbation est la direction RH

SINON SI direction = Commercial

ALORS le groupe d’approbation est la direction Commerciale

SINON SI direction = Communication

ALORS le groupe d’approbation est la direction Communication

SINON SI …

Vous pouvez ajouter de nouveaux critères en fonction des informations saisies au niveau du formulaire ou disponibles à partir de sources externes. Dans ce dernier cas, cela nécessite de pouvoir accéder à un référentiel externe, ce qui dépasse le cadre de ce tutorial et fera l’objet d’un tutorial dans le futur.

Vous pouvez également ajouter un nouveau résultat qui vous permettra de répondre à des situations plus complexes.

3.2.3.1.1 -Ajout d’un nouveau critère

En cliquant sur l’icône représentant un crayon ou sur le bouton Editeur de table de décision, vous accédez à l’écran suivant :

Les colonnes à gauche où apparaissent les conditions sont appelées les colonnes d’entrée. Dans la capture d’écran ci-dessus, la première colonne est une colonne d’entrée.
Les colonnes à droite où apparaissent les résultats (ou les conclusions) sont appelées les colonnes de sortie. Dans la capture d’écran ci-dessus, la colonne de droite est une colonne de sortie.
L’icône située à droite en haut d’une colonne d’entrée permet d’ajouter un critère de condition :

Les informations à saisir sont les suivantes :

• Libellé de colonne : Nom d’affichage du critère ;
• Nom de variable : Nom de la variable, généralement issu du formulaire ;
• Type de variable : Indique si la variable est une chaine de caractères, un nombre, une date, un booléen (oui/non) ;
• Valeurs autorisée : Liste les valeurs possibles.

L’icône située à droite en haut de la deuxième colonne permet d’ajouter un nouveau résultat (on dit aussi une nouvelle conclusion) :

Les informations à saisir sont les suivantes :

• Libellé de colonne : Nom d’affichage du critère ;
• Nom de variable : Nom de la variable, généralement issu du formulaire ;
• Type de variable : Indique si la variable est une chaîne de caractères, un nombre, une date, un booléen (oui/non) ;
• Valeurs autorisée : Liste les valeurs possibles.

3.2.3.2 -Sélection N+2, N+3…

On peut facilement imaginer d’autres tables de décision pour exprimer des situations de plus en plus complexes. Attention à ne pas construire d’usine à gaz. En outre, la modélisation peut devenir difficile à maintenir, voir à comprendre.
Restez simple !
Il serait également possible d’imaginer une table de décision unique rassemblant des critères de condition et des résultats multiples. Ces résultats pourraient par la suite être testés sur chaque transition.

3.2.4 -Finalisation de la configuration du processus

Revenez au processus. Il faut finaliser la configuration :

• associer les formulaires aux activités
• configurer les conditions sur les transitions
• configurer les assignations pour indiquer qui doit réaliser chaque tâche. Généralement, l’acteur sera défini via une table de décision.

3.2.4.1 -Association des formulaires

Pour associer un formulaire déjà existant à une activité, effectuez les étapes suivantes :

• Sélectionner par exemple l’étape de lancement du processus correspondant à l’étape de départ
• La valeur du champ Form Reference est normalement vide

• Cliquer sur cette valeur : une fenêtre contenant les formulaires disponibles s’ouvre

• Sélectionner celui qui vous intéresse puis cliquer sur Sauver
• Le nom du formulaire correspondant à cette étape apparaît

3.2.4.2 -Configuration des conditions

Dans notre exemple, les conditions servent à contrôler le nom des boutons cliqués sur les formulaires et à suivre les chemins (transitions) correspondants. Ainsi, sans surprise :

SI le bouton cliqué sur formulaire de Création est « Corriger »
ALORS on suit la transition Corriger
SINON on suit la transition par défaut

En fait, la configuration se fait sur chaque transition en exprimant une condition (aussi appelée garde) pour qu’elle se réalise. Pour mettre en place cette approche avec notre outil de BPM, il faut ainsi configurer une condition pour chaque transition. Effectuez les opérations suivantes :

• Sélectionner par exemple la transition OK à l’issue de l’étape de validation N+1 qui amène sur « Sélection Valideur N+2 »

• Cocher la boite Default flow : cette transition est la transition par défaut, il n’y a donc pas de condition à configurer dessus ;
• Sélectionner la transition à l’issue de l’étape de « Validation N+1 » qui amène sur « Notification d’un problème »

• Cliquer sur Flow condition et saisir la condition « ${form_FORM_VALIDATION_outcome == “Corriger”} »

• Cliquer sur Sauvegarder

3.2.4.3 -Assignations

Les activités humaines (ou tâches utilisateurs – User task) sont généralement assignées à des groupes, afin de faciliter la réalisation de celles-ci lors de l’absence d’un ou plusieurs acteurs. Ce peut être vu comme une sorte de délégation de fait (dans la réalité, une délégation est plus complexe, basée sur une date de début et de fin…).

Dans notre exemple, les tables de décision permettent de calculer les groupes auxquels seront assignés les tâches de validation N+1 et N+2. Ainsi, comme décrit plus haut, la table de décision Sélection valideur N+1 calcule le groupe auquel sera assigné la tâche de validation N+1 en fonction du service d’appartenance du demandeur. Ce groupe une fois calculé est stocké dans la variable « validator ».

Pour configurer cette assignation, effectuez les assignations suivantes :

• Sélectionner la tâche

• Cliquer sur Assignments, en bas de la fenêtre de propriétés
• Cliquer sur Valeur fixées
• Cliquer dans Groupes candidats
• Saisir ${validator}

• A l’exécution, cette variable sera remplacée par sa valeur correspondant dans notre exemple à la conclusion de la table de décision précédente ;
• Cliquer sur Sauvegarder.

Cette opération est à répéter également pour le formulaire N+2.

Pour le formulaire Correction demande de congés, il doit être assigné à l’initiateur de la demande :

• Cliquer sur la tâche Correction demande de congés
• Cliquer sur Assignments
• Cliquer sur Identity Store
• Sélectionner Assigné à l’initiateur de processus

3.2.4.4 -Déploiement de l’application

A chaque fois que vous effectuez quelques étapes de configuration, je vous suggère de les tester en effectuant un déploiement de test de votre processus. En cas d’erreur, vous saurez ainsi que vos dernières étapes de configuration posent problème.

3.2.4.4.1 -Création de l’application

3.2.4.4.2 -Configuration de l’application

• Cliquer sur l’icône représentant un crayon

• Saisir le nom, le titre et la description de votre application/module ;
• Cliquer sur Sauvegarder.

Cliquer ensuite sur

• Indiquer éventuellement les utilisateurs et les groupes ayant accès à cette application. Attention, il faut indiquer « id » des utilisateurs et des groupes. Si vous n’indiquez rien alors elle sera accessible à tout le monde ;
• Cliquer sur Editeur les modèles ;
• Sélectionner les modèles de processus auxquels vos utilisateurs devront pouvoir accéder.

3.2.5 -Applications

Les outils de BPM permettent de générer automatiquement les applications de gestion des processus. Ceux-ci sont généralement rassemblés en modules. Dans le cadre de notre exemple, nous aurons ainsi un module de gestion RH, dans lequel on trouvera la gestion de demande de congés. On peut bien sûr avoir d’autres processus pour ce même module et on peut avoir d’autres modules.

4 – Conclusions

Travailler avec des listes déroulantes dont on rentre les éléments à la main devient vite fastidieux. Dans la vraie vie, on a intérêt à s’interconnecter avec des référentiels externes où ces éléments existent déjà. L’intérêt de pouvoir les insérer à la main est de mettre le doigt là où la valeur ajoutée de votre service informatique ou de votre prestataire sera maximale. En lui demandant de s’interfacer simplement avec votre référentiel, vous décuplerez l’intérêt de votre BPM tout en limitant strictement les manipulations du service informatique à une couche technique : vous gardez totalement le contrôle sur les aspects fonctionnels.

5 – Ressources

https://en.wikipedia.org/wiki/Comparison_of_Business_Process_Modeling_Notation_tools