All posts by Jean-Christophe Kermagoret

28Oct/19

Dématérialisation du contrôle de la commande publique avec Flowable et Alfresco

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. 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.

01Août/19

Pérennisez vos investissements dans l’ECM

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.

14Mai/19

Bluexml et la supervision  : BlueReport

Description

/Users/bxml/Desktop/Tmp/Screenshots/Capture d’écran 2019-05-06 à 16.49.17.png

BlueReport fournit des indicateurs fonctionnels aux responsables de sites et aux administrateurs de la plateforme, pour faciliter le suivi et l’animation des sites collaboratifs, et des indicateurs techniques pour contrôler le fonctionnement des services Alfresco. Selon leur rôle dans l’organisation, les agents ont différents besoins :

  • Les cadres ont besoin d’informations sur l’utilisation du système, son évolution dans le temps, par typologie et sur tous différents axes possibles (volume de stockage, nombre de documents) pour justifier d’éventuels investissements qui contribueront à améliorer l’efficacité du système pour répondre aux besoins de l’organisation ;
  • Les agents en charge de l’administration fonctionnelle et du support aux utilisateurs de l’application de dématérialisation ont besoin d’informations leur permettant de mieux comprendre les problèmes, leur typologie, leur origine afin de justifier d’éventuels développements pour faciliter leur tâche et améliorer l’expérience utilisateur ;
  • Les agents en charge de l’exploitation du système ont besoin d’informations leur permettant de diagnostiquer certains problèmes techniques et de faciliter la communication avec les équipes de TMA.

BlueReport vous fournit ainsi différents tableaux de bord en fonction de vos droits :

  • Indicateurs fonctionnels : nombre et volume de stockage des documents métiers (cf figure 1), nombre des documents en cours de dématérialisation – qualifiés et non classés (cf figure 2) ;
  • Indicateurs d’administration fonctionnelle : nombre d’erreurs (cf figure 3), d’anomalies ;
  • Indicateurs techniques d’exploitation : quantité de ressources utilisées – mémoire, CPU (cf figure 4), logs.

Ces indicateurs peuvent être déclinés par service, dans le temps… afin d’affiner l’analyse et identifier les problèmes, leur origine. En outre, en centralisant les logs issus des différents éléments de l’architecture, le diagnostic des problèmes est facilité, contribuant à fournir un service plus efficace.

Indicateurs fonctionnels

Une image contenant capture d’écran, moniteur, intérieur, mur Description générée automatiquement

Figure 1  : Activité des documents “finance”

Une image contenant capture d’écran, moniteur, intérieur, mur Description générée automatiquement

Figure 2  : Nombre de documents en cours de dématérialisation (qualifiés et non classés)

Indicateurs fonctionnels d’administration

Une image contenant moniteur, capture d’écran, intérieur, ordinateur Description générée automatiquement

Figure 3  : Documents en erreur

Indicateurs techniques

Une image contenant moniteur, intérieur, mur, horloge Description générée automatiquement

Figure 4  : Ressources du serveur d’application

Fonctionnalités

STATISTIQUES FONCTIONNELLES

FONC_1 – NOMBRE DE DOCUMENTS EXISTANTS

STATISTIQUES D’ADMINISTRATION

ANOMALIES

ANO_1 – NOMBRE DE DOCUMENTS EN ATTENTE DE CLASSEMENT

ANO_2 – NOMBRE DE DOCUMENTS EN ERREUR

PROCESSUS

PROCESS_1 – DEMAT – DOCS ENTRANTS

PROCESS_2 – DEMAT – DOCS QUALIFIES

PROCESS_3 – DEMAT – DOCS CLASSES

PROCESS_4 – DEMAT – DOCS NON CLASSES

PROCESS_5 – FINANCE – SUIVI DES FACT.

PROCESS_6 – RH – NOMBRE DE DOCS.

RECHERCHE

RECHERCHE_1 – RECHERCHES

STATISTIQUES D’EXPLOITATION

PLATEFORMES ALFRESCO

EXP_SRV_1 – CHARGE PROCESSEUR.

EXP_SRV_2 – CHARGE MEMOIRE.

EXP_SRV_3 – CHARGE DISQUE.

EXP_SRV_4 – ESPACE DISQUE DISPONIBLES.

SERVEUR D’APPLICATION

EXP_APP_1 – CHARGE PROCESSEUR.

EXP_APP_2 – CHARGE MEMOIRE.

EXP_APP_3 – AJP – DISPONIBILITES.

EXP_APP_4 – AJP – TEMPS DE TRAITEMENTS.

EXP_APP_5 – TEMPS DE DISPONIBILITE.

EXP_APP_6 – SUIVI DES JOURNAUX.

EXP_APP_7 – NB DE SESSIONS OUVERTES.

EXP_APP_8 – DUREE MOY. DES SESSIONS.

SERVEUR BASE DE DONNEES

EXP_BDD_1 – CHARGE PROCESSEUR.

EXP_BDD_2 – CHARGE MEMOIRE.

EXP_BDD_3 – ESPACE DISQUE DISPONIBLE.

30Avr/19

(3/3) Analyse d’une politique documentaire : cas client

Etude fonctionnelle : Politique documentaire

A partir des éléments injectés dans ELK, on peut également obtenir un export csv répondant à la requête. On peut ainsi reconstruire pour chaque source un fichier csv avec la liste des 3 premiers niveaux d’arborescence et extraire automatiquement une carte cognitive. Cette dernière facilite la communication et permet une analyse “a priori” puis un travail de reconstruction avec un spécialiste métier.

On a ainsi les images Avant/Après facilitant la conduite du changement et la mise en oeuvre d’un plan d’actions.

L’étude porte ainsi sur les éléments suivants :

  • M: Lecteur réseau organisationnel : contient des répertoires pour chaque service de l’organisation ;
  • N: Lecteur réseau commun : contient des répertoires pour chaque projet ou élément commun à l’organisation ;
  • O: Serveur Alfresco : contient les répertoires pour chaque nouveau projet ou chaque nouvel élément commun qui est basculé sur le serveur Alfresco. Les éléments organisationnels sont aussi peu à peu basculés sur Alfresco.

M: Lecteur Organisationnel

Les premiers niveaux d’arborescence sur un serveur réseau “organisationnel” correspondent généralement aux niveaux suivants :

  • Direction
  • Département
  • Service…

Arborescence

On peut extraire ce genre de carte :

/Users/bxml/Desktop/Tmp/Screenshots/Capture d’écran 2019-04-09 à 11.33.21.png

Eléments communs

On trouve normalement des éléments liés à l’organisation de la direction/service/cellule, à la gestion opérationnelle des personnels associés (RH, formation, règlement intérieur…) :

  • Plannings
  • Congés
  • Compte-rendus
  • Modèles
  • Outils
  • Processus

Conclusion

A la lecture des plans de classement, on constate souvent des anomalies de ce type :

  • Trop d’éléments, rendant la compréhension difficile ;
  • Des références à des personnes (via leur nom, leur prénom) empêchant un stockage mutualisé des informations ;
  • Des références à des événements précis (via la date d’une journée), empêchant le stockage d’éléments ultérieurs ;
  • Des noms mêlant une information et une année, empêchant une déclinaison naturelle sur plusieurs années
  • Des noms correspondants à des types de fichiers, obligeant à parcourir le répertoire pour connaître son contenu

N: Lecteur commun

Désolé, cette section est n’est pas reproduite car les éléments issus d’une réelle étude client sont trop nombreux pour être anonymisés correctement.

O : Serveur Alfresco

Arborescence

/Users/bxml/Desktop/Tmp/Screenshots/Capture d’écran 2019-04-09 à 11.35.07.png

L’arborescence ci-dessus a été construite en regroupant manuellement les éléments. En effet, le concept de site ne supporte pas les hiérarchies qu’on reproduit généralement à l’aide de conventions de nommage.

Bonnes pratiques : les préconisations

On reprend les anomalies précédentes et on liste les solutions possibles :

Trop d’éléments gêne la visibilité

Afin de permettre une navigation fluide et pertinente, il faut respecter les règles suivantes la compréhension, la mémorisation :

  • Eviter plus de 20 éléments par répertoire
  • Créer des sous-répertoires pour regrouper les éléments par thèmes/sous-thèmes
Eviter les références aux éléments susceptibles de changer

Ce sont les personnes qui changent le plus dans les organisations. Ainsi, il faut éviter les noms et/ou prénoms dans les noms de répertoires (Michel, Stéphanie…) car lorsque la personne s’en va, il est difficile de savoir si les données sont privées, quels sont les thèmes concernés, ce qu’il faut garder, jeter… C’est le genre de répertoire qu’on retrouve plusieurs années après le départ de la personne…

Isoler les années

Il faut éviter de nommer un répertoire en ajoutant une année, caractéristique des événements, car cela bloque les regroupements automatiques. Si l’événement est amené à se reproduire, alors faire un répertoire du nom de l’événement puis un répertoire avec les années. Le fait d’isoler l’année permettra de consolider les données au niveau tranverse.

Ne pas utiliser de répertoires explicitant le type des fichiers

Cette information peut être obtenue automatiquement par la GED en se basant (en partie) sur le suffixe du fichier, il n’est donc pas nécessaire de l’expliciter et lui préférer un répertoire porteur de sens.

Donner du sens

Il est plus facile de mémoriser une arborescence porteuse d’une logique métier, que l’utilisateur manipule tous les jours de manière implicite, plutôt qu’une succession de tâches qui peuvent être très variées. L’arborescence devient du coup dure à comprendre et à suivre avec le risque que des répertoires redondants soient créés.

Conclusions

Revoir les PDC en fonction des règles ci-dessus et faire des préconisations pour chaque service département, service, mission, projet… Attention, le traitement de répertoires correspondant à des unités organisationnelles complexes (avec plusieurs centaines de milliers de fichiers) sera plus long que les répertoires d’une simple unité organisationnelle (avec quelques centaines voire milliers de fichiers au maximum).

Conclusion

L’utilisation d’un système d’indexation est fondamentale pour vous aider à connaître votre système documentaire, pour l’améliorer et vous aider à la conduite du changement en identifiant les sources de gaspillage et les pistes d’amélioration.

Afin d’avoir un véritable système outil de supervision et de pilotage de votre SI documentaire, il est nécessaire de mettre en place une collecte continue des informations seul moyen qui permettra d’obtenir un outil de supervision en temps réel de votre SI documentaire.

 

Suivez bluexml sur les réseaux sociaux

24Avr/19

(2/3) Analyse d’une politique documentaire : cas client

Etude technique : indicateurs

Généralement, les indicateurs attendus sont les suivants :

  • Répartition et évolution des documents en nombre et volume
  • Comprendre les pics de création de documents
  • Répartition des documents en fonction de l’organisation (DGA/Pôle/Département ou Service…)
  • Répartition des documents par type de fichiers (extension)

L’indicateur supplémentaire suivant, plus complexe à calculer, est souvent attendu :

  • Recherche de doublons

Phase1 : répartition et évolution

Evolution du nombre total de documents et de leur volume par serveur

Le stockage est actuellement réalisé sur 3 composants :

  • Lecteur réseau M : (Organisationnel)
  • Lecteur réseau N : (Commun)
  • Lecteur 0 : (Serveur Alfresco)

Le nombre de documents augmente constamment sur chaque composant alors qu’on pourrait s’attendre à voir diminuer ce nombre sur les serveurs réseaux au profit du serveur Alfresco. Au contraire, on constate même que le nombre de documents augmente plus vite sur le lecteur réseau « Organisationnel ».

Alfresco est vraisemblablement utilisé pour répondre à d’autres besoins, notamment des besoins collaboratifs.

Répartition des documents en nombre et en volume entre les différents serveurs

Evolution mensuelle du nombre de création de documents et de leur taille moyenne quelle que soit l’origine des documents

En cliquant sur un point précis, on peut avoir l’explication de sa valeur avec le détail des éléments ayant permis son calcul, comme la liste des documents comptabilités. On s’aperçoit ainsi que les pics de création de documents correspondent à des imports en grand nombre d’éléments de taille importante venant par exemple de la direction technique ou de la communication.

Répartition du nombre de documents par Niv1 (DGA) x Niv2 (Pôle) x Niv3 (Direction…)

Répartition des documents en fonction du nombre et du volume selon leur extension

 

Phase 2 : Recherche des doublons

Plusieurs solutions sont possibles :

  • lister les fichiers avec le même nom et regarder par la suite si les documents sont identiques (même taille et même md5). Le hash md5 peut être long à calculer sur des millions de fichiers, cette approche n’est pas toujours envisagée ;
  • lister les fichiers avec le même nom et la même taille en une seule passe et vérifier par la suite s’ils ont la même taille.

Cette seconde approche est souvent plus simple et plus rapide à mettre en oeuvre.

Script

La requête suivante sur ELK permet de récupérer tous les fichiers de plus de 10K dont le nom et la taille sont identiques. Pour garantir qu’il s’agit de doublons, il faudrait utiliser un hash md5 mais à défaut de celui-ci cela permet d’avoir une forte présomption de doublon.

 

Sur cette base, on peut obtenir un fichier json, qui peut être converti en csv, avec finalement les résultats suivants :

  • Nombre de fichiers > 10 Ko étudiés avec le même nom et la même taille : 10 000 fichiers
  • Nombre de résultats : 309 173
  • Nombre de répétitions : 16 à 2432 (situation.xls)
  • Place occupée : 1 835 Mo
  • Place optimale : 115 Mo

La taille est multipliée par 15, le nombre de fichiers par 35, ce qui entraîne un gaspillage de ressources, de temps et de maintenance et risque de se traduire par la conservation ‘ad vitam’ de centaines de milliers (pour ne pas dire plusieurs millions) de fichiers redondants…

Les 25 plus grandes répétitions quelle que soit la source

Dans notre cas d’utilisation, on ne connaît que les noms de fichiers, mais pas la source. Pour cela, il faudrait faire une requête supplémentaire sur chaque nom afin de savoir comment il se répartit sur chaque racine.

Le nom des fichiers répétés permet de se faire une idée des fichiers redondants.

Les 25 plus grands gaspillages

Conclusion

L’analyse des doublons est un peu “laborieuse” (données à nettoyer). Un indicateur intéressant serait de calculer la répartition des doublons d’un même fichier sur différentes sources afin de mieux comprendre le mécanisme de propagation et mettre en place des actions pour modifier les comportements.

 

Suivez bluexml sur les réseaux sociaux

 

16Avr/19

(1/3) Analyse d’une politique documentaire : cas client

Préambule

Ce billet de blog vous présente le travail réalisé pour un client institutionnel dans le cadre d’une mission d’analyse de leur politique documentaire.

Ce billet se décompose en 3 parties :

  • Présentation de l’objectif, du contexte et de la démarche
  • Présentation de l’étude technique avec une partie des indicateurs obtenus
  • Présentation de l’étude fonctionnelle avec une partie des arborescences

/Users/bxml/Desktop/Tmp/Screenshots/Capture d’écran 2019-04-09 à 11.49.26.png

 

Introduction

L’objectif de l’audit est de réaliser une analyse des contenus stockés dans leur fonds documentaire dans leur totalité (environ 20 To) :

  • un serveur de fichiers Windows, organisationnel (avec les contenus de chaque direction) ;
  • un serveur de fichiers Windows, communs (avec les contenus transverses) ;
  • un serveur de GED Alfresco (avec les contenus collaboratifs).

Cette analyse s’effectue généralement en collaboration avec la DSI et se décompose en 2 parties :

  • une étude technique des contenus stockés sur les différents composants ;
  • une étude fonctionnelle de ces contenus.

Démarche

L’objectif est de lister tous les fichiers contenus dans les systèmes ci-dessus, en récupérant les métadonnées disponibles dans un fichier au format csv. Le nombre de fichiers étant considérable, cette collecte est découpée en plusieurs sous-ensembles afin de ne pas surcharger le système lors de la récupération de ce listing. En outre, afin de pouvoir analyser les contenus extrêmement nombreux (plusieurs millions de ligne), un tableur n’est pas suffisant, il est ainsi prévu d’indexer et rechercher les contenus à l’aide de l’outil spécialisé Elasticsearch (ELK) de la société éponyme.

 

Listing au format csv

Liste des fichiers

Deux scripts ont été écrits en powershell 2 afin de permettre la récupération de ces éléments sur Windows :

  1. Un premier script liste les éléments principaux de premier niveau (c’est à dire les sous-répertoires) du répertoire passé en paramètre et appelle un deuxième script pour chacun des sous-répertoires principaux identifiés ;
  2. Le deuxième script liste tous les fichiers contenus dans le répertoire principal ou un de ses sous-répertoires.

Le premier script pilote le deuxième script. Le premier script a été lancé à la main à des moments propices (soirée, veille de we) pour éviter de trop surcharger le système pendant l’exploitation quotidienne.

Le fichier csv ressemble à ceci :

En parallèle du lancement des scripts de comptage, il faut également lancer la fonction de Windows permettant de compter le nombre et le volume des fichiers et répertoires pour un répertoire donné.

Erreurs

Certaines erreurs apparaissent :

  • répertoires inaccessibles, pour des raisons de droits ;
  • répertoires ou fichiers avec un nom trop long ;
  • répertoires ou fichiers avec des caractères interdits.

Dans l’absolu, il faudrait traiter ces erreurs. Cependant, un comptage a été fait en parallèle par le système Windows et comparé au nombre de répertoires et fichiers trouvés via les scripts ci-dessus. La différence n’est pas significative et on peut simplement ignorer ces erreur.

 

Injection dans le système d’indexation ELK

Le système d’indexation ELK facilite le comptage et le regroupement des données en fonction des indicateurs souhaités afin de faciliter le calcul des éléments techniques mais aussi l’étude du fonds documentaire.

ELK est un système d’indexation de contenus basé sur 3 composants :

  • Logstash pour la récupération et l’analyse des données en amont, en l’occurrence les fichiers csv générés par les scripts précédents ;
  • Elasticsearch, pour l’indexation des données ;
  • Kibana, pour la navigation dans les données.

Traitement et import des données

Logstash permet le traitement et l’import des données afin d’extraire toutes les informations souhaitées. Par exemple, l’extraction de la source de données (Lecteur M: dans notre cas) ou la conversion de la taille des documents en Ko afin de faciliter la lecture. Attention à bien conserver toutes les données afin de pouvoir les réutiliser si nécessaire.

Requête et comptage

Elasticsearch permet la création de requêtes pour extraire et compter le nombre de fichiers comme par exemple compter le nombre de documents par source ou leur taille.

La requête suivante permet par exemple de ne compter que les documents respectant certaines contraintes :

 

Tableaux de bord

Kibana permet la création de tableaux de bords, notamment avec la fonctionnalité TimeLion permettant de calculer et afficher des indicateurs sur le même graphique afin, par exemple, de comparer l’évolution du nombre de documents dans le temps en fonction de leur source.

/Users/bxml/Desktop/Tmp/Screenshots/Capture d’écran 2019-04-08 à 16.48.56.png

 

Comptages des répertoires et fichiers par source

Lorsque tous les éléments ont été injectés dans le moteur d’indexation, on compare alors les éléments obtenus entre le comptage Windows et le comptage ELK afin de vérifier que les erreurs ne sont pas significatives.

 

M:\Organisationnel

Les comptages sont les suivants :

Répertoire principal Nb de répertoires Nb de fichiers Volume
Total comptage listing via le calcul de Windows 1 309 910 10 798 669 16,1 To
Total comptage index 1 305 950 10 171 949 17,1 To

 

N:\Commun

Les comptages sont les suivants :

Répertoire principal Nb de répertoires Nb de fichiers Volume
Total comptage listing via le calcul de Windows 581 770 3 402 133 3,45 To
Total comptage index 564 576 3 089 141 3,64 To

O:\Alfresco

Un lecteur réseau a été monté sur le serveur Alfresco afin de pouvoir lister les fichiers stockés à la racine et dans les sites. Dans notre étude de cas, du fait du faible stockage et du faible nombre des éléments stockés en dehors des sites, qui représentent à peine 10 Go et quelques milliers de fichiers, ils n’ont pas été importés et ont été ignorés dans l’analyse.

Répertoire principal Nb de répertoires Nb de fichiers Volume Remarques
Total comptage index 50 113 295 702 781 Go 115 sites

 

 

Suivez bluexml sur les réseaux sociaux

19Oct/18

Pourquoi Alfresco abandonne Alfresco Share au profit d’ADF ?

ADF ou Alfresco/Application Development Framework est le nouvel outil d’interface mis à disposition par Alfresco. Il vise, à terme, à remplacer la solution d’interface “Alfresco Share”, actuellement distribuée avec Alfresco, qui est en cours d’abandon. Les cycles de vie des produits Alfresco et Alfresco Share ayant été dissociés, Alfresco Share sera quand même disponible sur les prochaines versions d’Alfresco mais n’évoluera plus.

Alfresco Share est un outil générique de gestion documentaire, avec de nombreuses fonctionnalités pas toujours utiles aux utilisateurs. Il peut être jugé, à raison, complexe et ne facilite pas la conduite du changement. En outre, basé sur des technologies “maison” telles que Surf ou abandonnées telles que Y!UI (Yahoo) et Dojo (un vieux projet IBM), il est difficile de trouver des compétences pour l’adapter.

A la lumière de tous ces éléments, Alfresco a choisi d’adapter sa stratégie et propose ainsi un nouveau framework basé sur Angular, technologie récente, supportée par un géant de l’internet, assurant une disponibilité importante de compétences. En outre, ce framework est constitué d’un ensemble de composants fonctionnels, qu’il est possible d’assembler en fonction des besoins des utilisateurs.

ADF permet de développer des outils qui s’adaptent aux besoins des utilisateurs et non l’inverse. La conduite du changement sera ainsi facilitée.

ADF se base sur le framework Angular 5, qui lui apporte beaucoup de flexibilité au niveau des fonctionnalités ainsi qu’une bonne adaptabilité par rapport au support de visualisation (PC, tablette ou téléphone).

ADF est un projet open-source et profite d’une communauté très active sur internet.

 

18Oct/18

Lancement du nouveau site web

Ça y est, il est arrivé !!!

Ce nouveau site présente l’offre de BlueXML ainsi que notre stratégie en terme d’innovation.

Notre offre s’étoffe avec l’arrivée en force du BPM pour répondre à la demande croissante de nos clients. En outre, nous développons l’offre autour des séminaires en 1j afin de vous donner un maximum d’informations en un minimum de temps.

Nous mettons également l’accent sur l’innovation en lançant des chantiers autour d’ADF, Angular et la blockchain, notamment avec la mise en place d’un calcul d’empreinte avec stockage dans la blockchain supportant bitcoin.

N’hésitez pas à revenir vers nous si un sujet vous intéresse.

A bientôt,

Jean-Christophe Kermagoret

PS : malgré tout le soin que nous y apportons, nous avons pu parfois oublier quelques règles de grammaire et d’orthographe, bref, des fautes… N’hésitez pas à nous en faire part afin que nous les corrigions.

06Juil/18

Créons une application métier avec Flowable

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

03Juil/18

Intégrer CMIS avec Ruby

Installation

Pour jouer cette même requête avec ruby, et l’intégrer par exemple dans un développement basé sur RoR, il faut installer une  librairie cmis, par exemple :

  • https://github.com/UP-nxt/cmis-ruby.git

Configuration

Après installation, il faut saisir les informations correspondantes à votre GED, en l’occurrence Alfresco, dans spec/config.yml :

server:
  service_url: http://localhost:8080/alfresco/api/-default-/public/cmis/versions/1.1/browser
  username: admin
  password: admin
repository: -default-

Lancez alors les tests avec la commande suivante :

rake

Récupération d’une liste de documents

Pour vous aider à faire vos premiers pas avec cette librairie, vous pouvez tester le script suivant adapté depuis le readme du projet :

[code language=”ruby”] $LOAD_PATH.unshift ‘lib’
require ‘cmis’

# get the repository object
server = CMIS::Server.new(service_url: ‘http://localhost:8080/alfresco/api/-default-/public/cmis/versions/1.1/browser’,
username: ‘admin’, password: ‘admin’)
repository = server.repository(‘-default-‘)

# query for first 50 documents where the property ‘cmis:name’ is ‘%DAT%’
# and stored in sites/test directory
cmisq = <<eos
select * from cmis:document
where cmis:name like ‘%DAT%’
and contains (‘PATH:\”//app:company_home/st:sites/cm:test//*\”‘)
eos

#query = repository.query(“select * from cmis:document where cmis:name like ‘GED%'”)
query = repository.query(cmisq)

query.each_result(limit: 50) { |document|
puts “-New item ——————————”
puts “Name: ” + document.name
puts “CMIS ObjectId: ” + document.cmis_object_id
puts “Mime-Type: ” + document.content_stream_mime_type
puts “Last Modification Date: ” + document.last_modification_date.to_s
}
[/code]

En exécutant ce code, on obtient la sortie suivante :

Conclusion

Pour étudier les autres possibilités de la librairie, je vous invite à consulter les fichiers de tests dans le répertoire spec/cmis-ruby, et plus particulièrement :

  • document_spec.rb : pour la création/lecture/mise à jour/suppression de document
  • folder_spec.rb : pour la création/lecture/mise à jour/suppression de dossier