Choisir la plate-forme prenant en charge les flux documentaires

Choisir la plate-forme prenant en charge les flux documentaires
 

Le logiciel de gestion de contenu, le PGI et le moteur BPM dédié sont trois candidats à cette prise en charge du workflow documentaire, avec leurs atouts et leurs inconvénients.

 Avant de déployer un moteur d’orchestration de processus (BPM) au-dessus de sa plate-forme de gestion de contenu, il convient d’abord de définir quelle plate-forme prend les rênes du workflow. Autrement dit, quel outil, de la plate-forme de gestion de contenu, du PGI ou du moteur BPM externe, valide au final une facture et déclenche la consolidation correspondante dans le PGI.

Plusieurs cas de figures sont donc possibles. Le workflow appelé procédural, que proposent à la fois les PGI et les moteurs BPM spécifiques, a vocation à piloter les applications métier. Dans le cas d’un organisme de financement, il peut être déclenché par l’arrivée, dans l’ECM, d’une demande de prêt. Il réalise alors une série de processus métier comme la création d’une commande, la génération d’un dossier client, la demande de pièces supplémentaires…

Une mise en oeuvre longue, jonchée d'étapes

Laurent Le Calvé, consultant chez Steria, met toutefois en garde : « Vouloir directement mettre en oeuvre ce workflow procédural, en s’appuyant sur ses capacités de connexion vers le référentiel documentaire, reste trop ambitieux. » Il insiste sur le besoin de « réussir l’étape de dématérialisation avant de passer au niveau procédural ». Autrement dit, chercher à automatiser un maximum de processus peut déclencher, à juste titre, une résistance des utilisateurs qui se voient contournés par l’outil.

Le workflow documentaire, issu des plates-formes de gestion de contenu, est, quant à lui, la transposition d’un circuit papier. Il n’a pas pour vocation de piloter des applications métier, mais de proposer des étapes de validation aux utilisateurs. D’après Sylvain Hubert, de l’intégrateur spécialisé Aerow, ce workflow présente plusieurs avantages. A commencer par sa facilité de mise en place et d’utilisation : « Il autorise notamment un opérationnel n’ayant pas de compte dans un PGI, à valider et à suivre facilement l’avancement d’un processus. Un autre atout, cette démarche accepte de définir des flux de validation transversaux, communs à plusieurs PGI. »

Une phase d'intégration et des développements complexes

Dernier cas de figure : le processus est entièrement porté par l’application, généralement spécifique comme «une application de gestion de sinistres », évoque par exemple Ziad Wakim de la société Ever. Mais, quel que soit le type de worflow choisi pour un projet, sa mise en oeuvre passe toujours par les mêmes étapes : modélisation et développement (connexion aux couches techniques et aux applicatifs, développement d’écran utilisateurs, contrôle et consolidation de données).

Si la première étape se compte d’ordinaire en jours, la dernière est souvent beaucoup plus longue. Selon Franck-Yves Berenguer, d’Euriware, « cette phase d’intégration technique suppose des développements parfois complexes. Des développements qui se mesurent en dizaines, voire en centaines de jours ». Les développements font appel à des APIs pour « créer les écrans et développer la logique métier », détaille Manuel Sanchez, consultant et architecte ECM chez Filenet. Comme pour modifier les attributs des fichiers, les classer une fois sortis de l’application métier.