Votre grille de sélection de logiciel ne sert à rien !

Chez tous les éditeurs de logiciel applicatif, le directeur commercial le sait bien, le coût d’acquisition d’un nouveau client est bien supérieur à celui lié à la vente de produits complémentaires chez un client existant. La raison principale, au-delà du temps passé par le chargé d’affaire à créer le lien de confiance nécessaire à la vente, est que votre organisation a des règles d’équité à respecter pour faire son marché. Il faut « objectiver » l’achat, éviter le « copinage » et ne surtout pas être pris en flagrant délit de conflit d’intérêt.

Durant de nombreuses années, à la lointaine époque où vous achetiez un produit, la pratique courante d’objectivisation consistait à écrire un cahier des charges des fonctionnalités nécessaire à la mise en œuvre des processus d’entreprise. Tout un écosystème s’est mis en place entre maîtrise d’ouvrage, maîtrise d’œuvre et leurs cohortes de consultants en « assistance » pour fédérer l’écriture de ce document maître. A mon avis, c’est bien cher payé le risque de coercition… mais c’est un autre débat. Au cœur de cette démarche, la grille des fonctionnalités attendues est génératrice de discussions internes infinies et ressemble la plupart du temps à un florilège de banalités, d’incongruités, de rêves fous et d’ambitions cachées. La grille sert d’élément d’évaluation mais elle sert également ensuite à cadrer le projet de mise en œuvre et à décider des « customisations » importantes à faire avant le démarrage du progiciel.

Qu’en est-il à l’heure du Cloud et des applications vendues sous forme d’abonnement à un service ? Eh bien disons-le clairement, cela ne sert à rien ! Vous ne voulez plus « customiser » l'application et vous ne pouvez pas décider à vous seul la mise en œuvre d’une fonctionnalité manquante qui ne ferait que répondre à un besoin propre à votre organisation du moment. C’est d’ailleurs ce que votre management achète : plus de temps passé à exécuter le processus qu’à en imaginer un meilleur.

Mais alors, comment procéder au choix ? Soit en assumant le fait que votre choix est subjectif, croyez-le ou non c’est de plus en plus souvent le cas, soit en vous focalisant sur la finalité de votre choix. Le critère de sélection devient alors le taux de couverture de mon processus et non plus ce qui se cache derrière chaque bouton de l’application.

Pourquoi alors dépenser autant de temps et d’argent à bâtir cette grille que plus personne ne lit ? Je vous le demande ! A mon avis, vous comprendrez beaucoup mieux la direction dans laquelle tel ou tel éditeur vous aura emmené dans les 3 ou 5 ans du terme de votre contrat d’abonnement en testant l’application par vous-même. C’est là une toute autre organisation d’avant-projet à mettre en place mais le bénéfice est bien plus grand pour vous. D'une part, le coût d'émission de l'appel d'offre est bien plus bas et d'autre part les experts métiers sont focalisés sur l'atteinte de leurs objectifs avec ce projet. Une simple description des parties-prenantes du processus et du moment où ils sont impliqués vous suffira pour tester la proximité des progiciels avec votre approche métier et vos contraintes organisationnelles. L’utilisation d’exemples « extrêmes » vous permettra de pousser les progiciels dans leurs limites pour évaluer leur potentiel. L’implication des utilisateurs dans des opérations de test vous permettra de construire la dynamique de changement même si vous créerez aussi une certaine frustration chez les utilisateurs préférant une autre solution que celle retenue. Mais cela, après tout, était déjà le cas avec la précédente génération de progiciels.