La mise en place d’un progiciel lié à un processus métier n’est pas une mince affaire. Un projet de mise en place d’un workflow nécessite une rigueur de tous les instants et une méthodologie particulièrement cadrée.

En l’absence de ces 2 facteurs, les erreurs peuvent être nombreuses et mettre en péril le succès dudit projet. Ces postulats sont aussi à respecter avec le plus grand soin. Découvrez nos mises en garde concernant les erreurs les plus courantes.

Complexité du processus et modélisation à outrance

Le souhait de délimiter une méthodologie est un réel plus pour un projet de workflow. Toutefois, à trop vouloir automatiser un processus métier, certains managers peuvent avoir tendance à choisir un processus trop complexe. En effet, les tâches et les acteurs peuvent rapidement devenir trop nombreux.

En ce sens, il est vivement recommandé, dans le cadre d’un BPM composé de multiples processus, de prioriser les plus simples (temps de mise en place court et risque minimum). Il est préférable d’opter, dans un premier temps, pour des mises en production simples que les utilisateurs pourront s’approprier facilement (et donc prendre confiance dans la phase opérationnelle).

Dans le même temps, la modélisation à outrance peut entrainer les mêmes problèmes. A ce titre, il n’est pas toujours pertinent de vouloir, en début de projet, recenser toutes les « routes » possibles. Cela ne peut que complexifier le projet et rendre les acteurs vulnérables. La meilleure option, dans le cadre d’un projet de workflow, est d’opter pour une modélisation 80/20 (80% de « routes » couvertes et 20% de « routes » à définir au fil des cas).

Impliquer pour mieux régner

Une autre erreur courante consiste à ne pas impliquer les utilisateurs. Ne perdons pas de vue que l’automatisation d’un processus a pour objectif de leur faciliter la vie. L’introduction d’un changement au sein d’une méthode de travail déstabilise par essence les habitudes des utilisateurs.

Ainsi, plutôt que de ne pas les solliciter, il est vivement recommandé de les intégrer dès le début du projet. La réflexion doit s’établir entre les experts de l’automatisation ET les utilisateurs, et non, entre les experts et leurs idées reçues basées sur des concepts. De plus, cette implication va entrainer l’adhésion des utilisateurs.

Les aspects matériels et documentaires

Egalement, à trop prioriser, il ne faut certainement pas éluder les aspects documentaires et matériels. En effet, une application BPM doit disposer d’un contenu documentaire complet. Que la documentation soit électronique, entrant/sortant ou dématérialisée, elle doit être présent pour maximiser la potentielle agilité du projet de workflow.

Il en est de même pour les aspects matériels. Plutôt que d’imposer une application BPM aux utilisateurs en les privant de leurs habitudes (papier, dossier, stylo), il est vivement recommandé d’étudier les nouvelles contraintes liées. Sans cette analyse, le refus de l’application sera immédiat et l’optimisation désirée ne sera jamais au rendez-vous (impression en masse par exemple).