De l'autre côté du miroir
Le syndrome shadokPourquoi faire simple quand on peut faire compliqué ? A trop vouloir fixer des règles strictes et rigoureuses, on en arrive à éloigner les utilisateurs de l’application : bref l’objectif contraire de ce qui est recherché Contexte: ce constat provient de l’Observatoire PAD qui est composé de 50 clients en France, dont 60% de « pure players » ou élaborant un projet SaaS. La plupart sont des éditeurs de solutions fonctionnelles à forte valeur ajoutée utilisant des réseaux de type SS2I, VARS ou Consultants métier. . Chacun a vécu au moins une fois, ces réunions qui participent à la constitution d’un cahier des charges d’un projet de gestion documentaire ou d’automatisation de processus. Trop souvent, les bonnes intentions pleuvent et les contraintes sont édictées au nom des utilisateurs pour corriger leurs nonchalances supposées.
J’ai en tête deux exemples marquants où après le choix rapide d’une solution VDoc, le projet peinait à démarrer. L’alerte ayant été remontée par le marketing, une visite s’est imposée pour comprendre pourquoi dans un cas le projet de traitement des notes de frais ne répondait pas aux attentes et dans l’autre la gestion documentaire implantée semblait n’être que peu utilisée. Des validations encore et encoreDans le premier cas, la première réaction du client fut assez naturellement de mettre en cause la capacité de l’outil à répondre aux attentes. A y regarder de près, l’affaire était tout autre. Au sein de l’entreprise, les différents responsables n’arrivaient pas à se mettre d’accord sur la définition du processus lui-même. Chacun voulait en effet affirmer ses prérogatives et sa position dans l’entreprise en intervenant à un moment ou un autre dans le processus. Pour satisfaire tout le monde, un processus extraordinairement complexe avait été mis en place avec une succession de validations. Au final, le processus s’avérait à peine plus efficace que le papier. Ce constat ayant été fait, l’entreprise s’est finalement repenchée sur son fonctionnement interne, a redéfini le processus et a supprimé des étapes pour un gain de temps de 30% !
Des champs obligatoiresLe second exemple est assez symptomatique des projets informatiques en général et de gestion documentaire en particulier. Ne dit-on pas que l’enfer est pavé de bonnes intentions ! Pour garantir un classement ad-hoc et éviter que tout le monde au sein de l’équipe projet publie ses documents n’ importe où, n’importe comment, le groupe de travail avait choisi de mettre en place une fiche documentaire particulièrement riche en attributs. Bien entendu, tous plus ou moins obligatoires. Cette organisation correspondait à une volonté de rigueur absolue de l’entreprise ; la même que longtemps, les tenants de l’ISO 9000 ont imposé. Cette époque semble aujourd’hui bien lointaine et très éloignée des attentes des utilisateurs. Dans l’exemple, le résultat obtenu a été diamétralement opposé à celui souhaité : face à une telle complexité, les utilisateurs se sont détournés de l’espace projet amenant au final les responsables à revoir et à simplifier le processus de publication. Ces deux exemples illustrent bien les dérives de certaines équipes projets qui oublient un peu les utilisateurs et restent bien loin de l’agilité nécessaire et attendue. |
