Un projet de mise en oeuvre d’un progiciel de Gestion des Processus Métier (BPM – Workflow) fait appel à beaucoup de rigueur et de méthode comme tout projet informatique, il se doit aussi d’éviter quelques erreurs qui peuvent le faire basculer du mode « succès » au mode « échec cuisant ». Parmi ces erreurs, et au fil du temps et des projets que j’ai pu suivre, j’ai relevé quelques points récurrents que je vous soumets ci-dessous.

1. Choisir un processus trop complexe

Tout naturellement lorsqu’on cherche à automatiser un processus métier, on s’oriente vers un processus couteux pour l’Entreprise en terme de ressources :

• nombreuses tâches
• nombreux acteurs
• fort degré d’intégration

en se disant que ce sera le « plus rentable » et que donc il faut le traiter en priorité.

C’est là où l’expérience prouve que contrairement à ce que l’on peut croire, il est souhaitable, lors de la mise en oeuvre d’une infrastructure BPM devant servir de multiples processus, de commencer par celui qui paraît le plus simple, qui demandera le temps de mise en oeuvre le plus réduit, avec le minimum de risque. En effet, mieux vaut mettre en production un premier processus simple et faire en sorte que cela fonctionne, que les utilisateurs se l’approprient, qu’il y ait un retour positif, afin de valoriser l’image de cette mise en oeuvre et de faciliter les mises en oeuvre ultérieures.

De même, cela permettra d’apprendre, de s’approprier l’outil, la méthode, de résoudre les problèmes inhérents à ce type de mise en oeuvre sans avoir à se consacrer à la complexité intrinsèque du processus.

2. Vouloir modéliser tous les cas possibles

Une fois le processus à implémenter identifié, il va falloir en modéliser les différentes étapes, les intervenants et les conditions de routage d’une tâche à une autre. Une des erreurs que j’ai pu constater consiste à vouloir recenser la totalité des routes et conditions possibles, et ainsi à complexifier au possible la mise en oeuvre – ce qui n’est pas encore le pire – et à rallonger de façon inconsidérée le temps nécessaire à la rédaction des spécifications. Résultat ? Lorsque la modélisation est (enfin) terminée (s’il elle l’est), le processus est (déjà) obsolète ou le projet est tombé à l’eau !

N’essayez donc pas de chercher à qualifier toutes les alternatives possibles et préférez un niveau de modélisation de type 80/20 (80% des cas couverts pour 20% d’exceptions à traiter en manuel) permettant une première mise en oeuvre rapide. Il sera toujours temps par la suite d’optimiser ce processus en lui rajoutant le traitement automatique des exceptions les plus fréquentes. Viser l’excellence à ce niveau ne sert donc à rien, il vaudra mieux privilégier la souplesse de l’outil et sa capacité à gérer les exceptions.

3. Ne pas impliquer les utilisateurs

Automatiser un processus, c’est entre autre chose faciliter la vie des utilisateurs qui vont pouvoir se consacrer à la réalisation des tâches à valeur ajoutée. C’est aussi introduire un changement non négligeable dans leurs méthodes de travail, et pour cela il est impératif de les impliquer dès le début de l’aventure dans les phases de spécifications, de réflexion et de définition tant des processus que des interfaces (IHM) qu’ils devront utiliser.

Un des buts du projet doit être de provoquer l’adhésion de ces utilisateurs, et quoi de plus frustrant que de leur imposer des interfaces qu’ils n’ont pas définies par eux-mêmes, avec une ergonomie à laquelle ils n’adhèrent pas (le bouton en bas à droite qui devrait être en haut à gauche), une cosmétique inadéquate (pourquoi du rouge alors qu’il serait si simple de lister les tâches en bleu), etc.

Il me paraît donc primordial de donner à nos utilisateurs la possibilité d’intervenir dans les choix de conception, et de leur donner ainsi tant l’envie d’utiliser l’application que le niveau d’appropriation dont ils ont besoin pour l’utiliser.

4. Trop enrichir l’application BPM

Tant qu’à faire d’optimiser … optimisons ! Et de cette remarque fracassante découlent bien souvent des applications d’une complexité (au sens implémentation) incroyable. Ce n’est pas parce que l’outil « peut le faire » qu’il faut le lui faire faire. A vouloir tout gérer dans le progiciel, on se retrouve la plupart du temps avec des contraintes d’implémentations fortes, des modèles de bases de données bien trop riches et une lourdeur d’administration et de supervision technique excessive. Mieux vaut dans ce cas externaliser certaines informations et alléger par là-même l’application. N’hésitez pas à gérer dans une base de données applicative connexe les informations redondantes au niveau du processus (par exemple informations de facturation client répétées tous les mois alors qu’elles ne changent pas, et occupant donc 12 fois plus de place que nécessaire).

5. Négliger les aspects documentaires

Je ne conçois pas une application BPM sans contenu documentaire associé. Bien évidemment j’exclus de ce champ applicatif les applications de pure intégration system-to-system, ou workflow d’infrastructure, mais je n’ai encore pas vu le moindre projet de BPM pour lequel la notion de document (électronique, dématérialisé, entrant, sortant, etc.) n’est pas abordée.

Conséquence directe, il va falloir intégrer l’accès à un référentiel documentaire (homegrown, file system, système GED) et de fait complexifier le niveau d’intégration du progiciel BPM et le projet en lui-même. Je ne prétends pas pour autant que seuls les outils de BPM intégrant un référentiel documentaire sont dignes d’être utilisés, mais simplement qu’il faut s’assurer au préalable (en amont du choix bien souvent) du niveau d’intégration natif entre BPM et référentiel documentaire. Le niveau d’agilité offert par la solution logicielle sera ainsi grandement amélioré.

6. Négliger les aspects matériels

Une remarque toute simple, mais essayez de penser à vos utilisateurs là-aussi : vous leur imposez une application BPM, vous les privez du contact avec la feuille de papier ou le dossier dont ils avaient l’habitude, et vous remplacez tout cela par la visualisation à l’écran des documents, des informations, du contexte … sur un minuscule écran de 15 pouces. Refus de l’application assuré ! Voire (j’ai déjà vu) demande d’impression systématique des documents pour pouvoir les lire.

Il est impératif d’étudier les nouvelles contraintes d’usage apportées par l’application, d’y répondre avec une configuration matérielle adaptée et – en marge pour cet article mais crucial au demeurant – d’accompagner le changement par une méthodologie adaptée.

En conclusion …

Il y a bien d’autres « recettes » à mettre en oeuvre, mais j’ai souhaité ici mettre en avant les erreurs les plus communément rencontrées sur le terrain, celles qui sont à-même de provoquer le rejet de l’application, la non-adoption du système et l’échec du projet ; ça vaut le coup d’y penser non ?