vendredi 17 juin 2011
Cyril VAZQUEZGérant et consultant, OpiomVincennes, France
Second volet de notre billet consacré aux erreurs qui pénalisent les projets de dématérialisation des factures fournisseurs. Après les chausse-trappe des phases amont, les dangers qui guettent les projets durant les phases de mise en œuvre. 4) Avoir trop de responsables et pas de coupablesNe pas désigner de chef de projet interne ou ne pas l'impliquer fortement revient à prendre un risque énorme sur un projet qui va toucher de nombreux services (la comptabilité évidemment, mais aussi le contrôle de gestion, les achats, les stocks...). Dans l'idéal, il faut désigner une ou plusieurs personnes référentes dans chaque service concerné, un correspondant.Surtout, il faut clairement identifier les personnes responsables pour les parties techniques et fonctionnelles dès l'établissement des spécifications de l'application. Faute de quoi l'application a de fortes chances de se révéler, in fine, partiellement inopérante ou mal adaptée aux besoins de l'organisation. 5) Négliger l'adhésion des utilisateursLes utilisateurs doivent être impliqués très tôt, afin de leur présenter les objectifs du projet, de recueillir leurs besoins, de détailler ce qui va changer avec la nouvelle solution. Le risque est de voir le projet rejeté par ses utilisateurs ou que ces derniers mettent en place des stratégies de contournement de la nouvelle solution. Attendre les formations ne constitue pas une bonne solution : les utilisateurs y reçoivent beaucoup d'informations en un temps réduit, la solution est perçue comme trop complexe et les changements dans leurs tâches quotidiennes trop importants. La phase de recette, premier contact concret avec la nouvelle solution, est encore plus critique: non seulement ils se retrouvent face à un nouvel outil qu'ils ne maîtrisent pas mais qu'ils devront utiliser, mais en plus leur rôle les amène à en détecter les défauts et non conformités qui sont éventuellement passés au travers des mailles des tests. Attention également à ce que j'appelle le syndrome de l'application magique : les décideurs ne doivent pas "survendre" la solution, la décrire comme une solution miracle à tous les problèmes. Ceci vaut notamment pour la lecture automatique de documents (LAD) ou pour les rapprochements entre factures et bons de commandes. Ces opérations ne seront pas automatisées à 100 % ; l'intervention des utilisateurs restera nécessaire pour gérer les exceptions. Dès le départ, ce que la solution saura ou ne saura pas faire doit être présenté clairement, conjointement avec les nouvelles missions des utilisateurs. 6) Oublier de piloter la production Une fois l'application mise en place, le projet ne s'arrête pas ! Un nouvel outil implique de nouvelles missions pour les responsables : surveiller l'utilisation de la solution, générer et analyser des statistiques (notamment pour la LAD et les rapprochements automatiques), maintenir à jour les paramétrages, détecter les évolutions dans les factures reçues qui nuisent aux performances... Faute de quoi, on risque de retomber dans les travers qui ont donné naissance au projet : documents laissés de côté, traités en retard, erreurs dans le traitement, dégradation des performances, etc. Or, dans de nombreux cas, cet aspect portant sur la performance de la solution dans le temps passe tout simplement à l'as et tous les bénéfices attendus sont perdus petit à petit ! Conclusions : pour aborder sereinement un tel projet, il faut donc une maîtrise d'ouvrage forte qui saura définir clairement le périmètre et les responsabilités en interne et en externe, identifier et gérer les risques, accompagner le changement, définir les nouvelles pratiques et missions inhérentes à la nouvelle solution.Lien vers la première partie: http://www.viadeo.com/hub/forums/detaildiscussi...
http://www.viadeo.com/hub/forums/detaildiscussion/?containerId=002xryjfx13ezym&action=messageDetail&messageId=002qps9goo4lub5&forumId=0021iay6rgvy3z2x
Aucun commentaire:
Enregistrer un commentaire