On distingue généralement deux types de workflow (ou processus en français):

– le workflow procédural, faisant l’objet de procédures pré-établies: le cheminement est plus ou moins figé, les décisions de routage sont peu dépendantes des utilisateurs ;
– le workflow ad hoc, basé sur un modèle collaboratif : le cheminement est dynamique, les utilisateurs interviennent presque systématiquement dans les décisions de routage.

Le workflow ad hoc est trop souvent plébiscité. Par refus de transparence du côté des utilisateurs … et par paresse dans l’analyse du côté des informaticiens?

Il présente pourtant de solides défauts.

Dans un processus ad-hoc, le manque de documentation et de structuration signifie qu’il peut être difficile de savoir qui est responsable de quoi. Les responsabilités ne peuvent être clairement définies, et le succès ou l’échec du traitement d’un dossier dépend plus de la bonne volonté des employés, que d’un mode opératoire clairement défini.
Des tâches importantes peuvent être oubliées, dû au fait qu’un manque de documentation et de structuration peut engendrer des problèmes de communication, en particulier quand un processus fait intervenir plusieurs départements de l’entreprise.

Les processus ad hoc peuvent être lourds, lents et confus. Les employés peuvent être noyés sous une avalanche de sollicitations, mal ou non coordonnées.
La transparence est absente: il est pratiquement impossible de surveiller l’avancement des dossiers et d’assurer le respect des procédures (la difficulté [ou le refus déguisé] de les établir étant donné comme justification de la nécessité de processus ad hoc).

Lorsque les processus sont mal définis, ils sont presque impossibles à optimiser. Ainsi par exemple, la redondance est hors contrôle, de même que la construction par les utilisateurs de solutions périphériques (fichiers Excel de suivi individuel sur les pcs utilisateurs pour ne citer qu’un exemple).
Par absence d’indicateurs de suivi fiables et de tableaux de bord, toute démarche d’optimisation est difficile et hasardeuse.

Les processus ad-hoc ne sont en fait pas flexibles.
Ceci paraît contre-intuitif, puisque par définition un processus ad hoc satisfait à peu de règles et de structure.
La vérité est qu’un processus ad hoc étant mal maîtrisé, les acteurs seront peu tentés de se livrer à des tentatives d’amélioration (les volontaires sont toujours peu nombreux pour “défaire un sac de noeuds”).
Hors, flexibilité rime avec changements, en vue d’amélioration ou pour coller aux évolutions métiers.

Bref, avec les processus ad hoc, les améliorations restent du domaine de la conjecture. Y recourir de manière exagérée est contre productif … du moins si l’on veut s’inscrire dans une démarche de progrès permanents.

Ceci étant dit, et à contrario, l’élaboration d’un workflow procédural peut s’avérer très difficile : règles de routage complexes ou trop nombreuses, absence ou imprécision des informations nécessaire au bon déroulement des règles, coût de maintenance des règles prohibitif…
La solution pourrait être alors de s’appuyer sur un outil permettant les deux, procédural et ad hoc.
Dans les cas difficiles, la première implémentation porte sur un workfow ad hoc. Et l’outil est utilisé pour détecter les routages les plus fréquemment utilisés, et conduisant à une longueur de cycle total le plus court possible (si tel est l’objectif). Une façon peut-être de dégager progressivement les bases d’un futur workflow procédural.

L’outil retenu par Smals pour le case management va dans ce sens.

Le case management mérite un commentaire particulier au sujet des processus. Le case management touche autant à la notion de travail collaboratif qu’à la notion de processus. Il nécessite en effet des échanges non déterministes entre les acteurs. Ceci signifie que les transferts peuvent être, du moins en certains points (il faut recourir au procédural là ou c’est possible – voir la première partie de cet article), l’objet de décisions humaines au cas par cas, c’est-à-dire en fonction du dossier.
Pour cette raison, le case management ne sera pas idéalement résolu sur le plan des processus avec un outil de type BPMS (Business Process Management System).

J’espère avoir ainsi fait apparaître:
– la différence entre travail collaboratif et processus;
– le fait qu’un “processus” de gestion de dossier est très éloigné d’un processus de fabrication (au sens industriel du terme) – le premier se caractérise par la dominance de l’aspect décisionnel, suite à un raisonnement mené par un acteur humain, le second par la dominance de l’aspect automatisation avec l’emploi souvent exclusif de machines.
La confusion des genres est trop fréquente dans la compréhension du concept de processus appliqué aux tâches administratives.

Une dernière considération pour en terminer.
L’informatisation des processus est une forme de taylorisation des tâches administratives. Par conséquent, lorsque poussé à l’extrême, les impacts psycho-sociaux peuvent être nombreux, avec quelquefois des effets pervers sur le long terme (perte de sens du travail et démotivation résultante, par exemple). Les appréhender doit être partie intégrante de la démarche de change management.