Vaste sujet que celui du workflow, sans même parler de BPM encore. D’autant plus lorsqu’on commence à faire la différenciation entre workflow documentaire, workflow de formulaire et workflow métier (pour ne parler que de ceux là).

Je m’y étais essayé dans une précédente note (lire la note en question) et je vais donc reprendre en partie ce que je disais alors pour définir ma conception du workflow documentaire (chaque éditeur ayant bien sûr la sienne lorsqu’on rentre dans les détails fonctionnels) afin d’alimenter cette série « concepts ».

On entend donc par workflow documentaire tout processus consistant à faire circuler 1/ des documents et 2/ d’un utilisateur à un autre. Je mets volontairement l’accent sur ces deux points car il n’est pas question ici de traitement métier impliquant une quelconque intégration aux applications de l’entreprise (cf. ma définition des besoins rencontrés par les entreprises). C’est bien un « simple » circuit de routage des documents permettant à ces derniers de suivre un trajet prédéfini, pouvant être modifié par un des participants selon les cas (au run-time, si l’applicatif le permet ce que proposent la plupart des outils).

Ce circuit peut être purement séquentiel (le document passe d’une corbeille à l’autre sans possibilité d’aiguillage conditionnel) ou bien au contraire complexe et conditionné par les métadonnées portées par le document (par exemple envoi à un collaborateur A si une condition est satisfaite et à un collaborateur B dans le cas contraire). Il sera également possible d’envisager des retours à l’envoyeur, des étapes de rendez-vous (plusieurs collaborateurs doivent valider le même document avant que le circuit n’avance), des sauts d’étapes (un responsable ne valide que certains documents pour lesquels une métadonnée présente une valeur particulière), etc.

Un workflow documentaire ne fait pas appel à des instructions systèmes élaborées (appel de sous-procédures, composants applicatifs, Web Services, transactions SQL, etc.) ou si peu, selon les produits.

On retrouve par contre chez certains éditeurs la capacité de ce type de workflow à faire appel à des composants de manipulation des documents, par exemple de conversion au format PDF (« PDF Rendition »), de modification/enrichissement par une application bureautique (par exemple application d’un modèle MS Word), ce type de fonctionnalité vient enrichir la capacité du workflow à prendre en charge une partie des traitements (purement documentaires donc) afin de minimiser les tâches à faible valeur ajoutée précédemment attribuées aux utilisateurs.

L’exemple (volontairement simpliste) ci-dessous montre ce que peut être un workflow documentaire consistant à :

• créer un document à partir d’une demande (par exemple nouvelle procédure Qualité)
• le rédiger à partir d’un modèle MS Word, stockage local pendant la rédaction (l’idéal étant d’utiliser la gestion des versions offerte par la GED sous-jacente)
• le faire relire
• le faire corriger si les critères de relecture ne sont pas satisfaits
• le faire valider
• le corriger si les critères de publication ne sont pas satisfaits
• le faire publier, classer en GED

Ce circuit incluant quelques retours et branchements conditionnels peut être complexifié afin de prendre en compte de multiples acteurs, un enchaînement plus complexe d’actions, des validations plus nombreuses, une publication multi-canaux, etc.

Comme on vient de le voir, un workflow documentaire vient compléter un système de Gestion des Documents afin d’en faciliter la circulation, l’enrichissement, la classification, la publication. Il est en ce sens orienté « utilisateurs » (‘human centric’ selon la terminologie usuelle) et s’intègre assez naturellement aux applications bureautiques.