Inclure les utilisateurs pendant la phase de conception d’un projet workflow

Le SIVOA modélise son processus de validation du courrier sortant
Ou comment passer outre l’obligation d’inclure les utilisateurs à la mise en oeuvre d’un système de gestion des processus.

Je crois que s’il y a une constante dans la mis en oeuvre d’un projet workflow/BPM, c’est bien celle-ci. Il FAUT inclure les utilisateurs finaux dès la phase de conception des applications, ce que l’on n’a pas toujours le reflexe de faire. Pourquoi ? Tout simplement parce que ce sont eux qui vont utiliser les applications et que la meilleure méthode pour les faire adhérer c’est qu’ils concoivent eux-mêmes la face visible de ces applications.

Le Processus
Par face visible, j’entends les interfaces bien évidemment, mais aussi le processus en lui-même. EN effet, il suffit de réunir un gorupe de 30 utilisateurs d’un même service dans toute organisation pour se rendre compte bien vite qu’il existe … 31 processus, celui qui est censé être le bon et les 30 autres adoptés chacun par un utilisateur. Je n’ai plus de doutes là-dessus pour l’avoir vérifié par moi-même plusieurs fois.
Il est donc fondamental d’arriver, avant tout développement ou même proto, à un consensus général visant à décrire le processus concerné et à le publier. Ainsi plus personne ne pourra dire ultérieurement « ce n’est pas comme cela que l’on travaille ! ».

Les interfaces
C’est tout bête mais essayez donc d’utiliser une application que vous ne trouvez pas conviviale. Résultat ? Vous la rejetez très rapidement sans aucune arrière-pensée. Il en est de même pour une application workflow. Si les interfaces fournies aux utilisateurs métiers n’ont pas été concues et validées par eux, vous avez peu de chances qu’elles soient adoptées une fois en production. Il ne tient pourtant pas à grand-chose de les faire valider : un bouton placé au bon endroit, un label pertinent, des couleurs qui plaisent, etc. J’ai vu encore récemment une application workflow développée uniquement par des développeurs, sans aucune interaction avec les utilisateurs. Très franchement, elle n’était pas … belle. Des écrans stricts et fades, une présentation en tableau à la limite du mauvais goût, des fonctions simples inexistantes, tout semblait être fait pour que l’on ait pas envie de s’en servir. D’ailleurs c’était le cas. Il suffisait de modifier quelque peu les écrans, de faire du design simple sans remise en cause du processus sous-jacent, pour avoir en face de soi une application moderne, séduisante et surtout utilisable.

Il ne tient qu’à peu de choses qu’un projet workflow réussisse. Je pense sincèrement que parmi tous les projets informatiques confondus, les projets workflows sont parmi ceux qui ont le plus fort taux d’échec et de rejet. Alors ne passez pas à côté de ces deux aspects.

Lire la suite :

• Un court historique du BPM – Troisième partie
• Projets BPM/Workflow : quelques erreurs à éviter
• Exemple de mise en oeuvre du BPM : comment faire simple et efficace …
• Tendances Web 2.0 et BPM, un avenir certain mais lequel ??
• Un processus simple est un processus efficace
• Différence entre workflow et moteur de règles
• 5 facteurs clés de succès pour mettre en oeuvre une application ECM-BPM
• Un court historique du BPM – Deuxième partie
• BPM et SOA – Deuxième partie
• Applications métiers composites, quand BPM et SOA sont associés …