J'ai un aveu à vous faire. Quand un tableau d'exigences atterrit dans ma boîte mail, je connais ma réponse avant même de l'ouvrir. Ce sera oui. Oui partout, ou presque. Et ce n'est pas de l'arrogance : c'est que la question est mal posée.
Un cahier des charges ERP, dans sa forme habituelle, c'est une colonne de fonctionnalités, une mention « souhaitée », « attendue » ou « indispensable » en regard, et une case à remplir par chaque candidat. L'exercice ressemble à un entretien d'embauche où l'on demanderait à tous les postulants s'ils savent « travailler en équipe » et « gérer la pression ». Évidemment, tout le monde répond oui. Et à la fin de l'entretien, on n'a strictement rien appris.
Je vois ces tableaux défiler depuis plus de vingt ans. Ils descendent des grands cabinets, se transmettent de projet en projet comme un usage qu'on ne discute plus, et continuent d'être pris pour un outil de compréhension métier alors qu'ils n'en sont pas un. Voici pourquoi, et ce que je propose à la place.
Pourquoi tout le monde coche « oui »
Le premier problème, c'est que la grille ne trie personne.
Les fonctions de base d'un ERP du marché sont aujourd'hui banalisées. Gérer des devis, des commandes, de la facturation, des congés, un suivi analytique : n'importe quelle solution sérieuse sait le faire. Quand vous demandez à dix éditeurs s'ils cochent la case, ils la cochent tous, et ils ont raison de la cocher. La réponse ne vous renseigne en rien sur ce qui va réellement se passer ensuite.
On croit pourtant se rassurer en allongeant la liste. Plus elle compte de lignes, plus on a le sentiment d'avoir balayé tous les angles. J'ai vu des grilles de deux cent cinquante lignes, j'en ai vu de sept cents. Aucune des deux ne raconte comment l'entreprise gagne sa vie. Une liste exhaustive n'est pas une connaissance. C'est une liste, simplement plus longue.
La vérité est dans la mécanique, pas dans la case
Prenons une exigence que l'on retrouve dans presque tous les dossiers : la gestion des congés et des absences.
Tout le monde sait faire. Mais derrière ces trois mots se cache une mécanique entière que la case ignore. Qui pose la demande, et qui l'approuve : le manager direct, les ressources humaines, les deux successivement ? Que se passe-t-il quand l'approbateur est lui-même absent ? Comment l'absence se répercute-t-elle sur la planification des équipes, sur la facturation d'une prestation au forfait, sur la remontée vers la paie ? Que fait-on des compteurs, des reliquats, des récupérations, des cas particuliers qui représentent la moitié du quotidien d'un service RH ?
Rien de tout cela ne tient dans un oui ou un non. Et c'est précisément à cet endroit, dans la façon dont les choses s'enchaînent vraiment, que se joue l'écart entre un projet qui soulage les équipes et un projet qui les alourdit. Le « quoi » est commun à tous les ERP. La différence vit dans le « comment », et le tableau l'efface méthodiquement, ligne après ligne.
On grave dans le marbre un fonctionnement qu'on n'a jamais choisi
C'est ici que le mal devient sérieux.
Rédiger une grille d'exigences, c'est prendre une photo du fonctionnement actuel et la transformer en contrat. On observe la façon de travailler d'aujourd'hui, on la découpe en cases, on la fait signer. Le souci, c'est que cette façon de travailler n'a presque jamais été décidée. Elle s'est déposée, couche après couche, au fil des années. Un contrôle URSSAF qui a imposé une procédure supplémentaire. Un litige client qui a fait naître une étape de validation. Un impayé douloureux qui a engendré un circuit d'approbation interminable.
Et surtout, il y a tous ces contournements que les équipes ont fini par inventer parce que l'ancien logiciel ne suivait pas. Le tableur tenu en parallèle que plus personne n'ose toucher. La ressaisie « provisoire » qui dure depuis quatre ans. Le fichier partagé qui sert de mémoire officieuse. Ces astuces ont permis de tenir le quotidien, mais elles n'existent que pour compenser la rigidité d'un outil qu'on s'apprête à jeter.
Que demande la grille d'exigences ? De recopier tout cela à l'identique dans le nouvel outil. C'est déménager dans une maison neuve en emportant soigneusement les fissures.
À aucun moment on ne pose la question qui ferait toute la différence : pourquoi procédez-vous ainsi, et faut-il vraiment que cela continue ?
Le vrai gisement : l'ERP comme levier, pas comme copie
Voilà ce qui me chagrine le plus dans cette histoire.
Un changement d'ERP est l'une des rares occasions, dans la vie d'une entreprise, de tout remettre à plat. C'est le moment rêvé pour faire le ménage : supprimer les ressaisies, abandonner les rustines, interroger chaque étape héritée d'une contrainte qui n'existe peut-être plus. Pas pour reproduire l'ancien monde en plus net, mais pour le repenser.
Sur le plan opérationnel, cela veut dire fluidifier la circulation de l'information, automatiser ce qui se faisait à la main faute de mieux, rendre les équipes plus autonomes. Sur le plan financier, cela veut dire ouvrir le capot et regarder enfin où la marge se construit et où elle s'évapore, où la trésorerie se coince, où les heures se perdent. Un projet ERP bien mené, c'est un levier de performance avant d'être un changement de logiciel.
La grille d'exigences fait l'inverse exact. Elle sanctifie le fonctionnement d'hier, contournements compris, avant même qu'on ait cherché à comprendre comment l'entreprise vit. Elle verrouille le besoin trop tôt, quand rien n'a encore été questionné.
À quoi sert vraiment le tableau
Soyons justes : la grille a une utilité réelle. Elle permet de comparer des fournisseurs sur une base commune, et elle protège juridiquement le donneur d'ordre. C'est un instrument d'achat, et c'est même un excellent dossier le jour où un projet tourne mal et finit devant un tribunal, puisqu'elle établit noir sur blanc qui s'était engagé sur quoi.
Mais en tant qu'outil de compréhension métier, elle ne vaut rien. On a pris un document d'acheteur et on l'a déguisé en démarche d'analyse. Le déguisement tient parce qu'il vient des grands cabinets et qu'il rassure tout le monde autour de la table.
L'absurdité que personne ne relève
Pousse-t-on le raisonnement ? On exige que les candidats remplissent ces tableaux avant même de leur avoir montré la solution.
Faisons le calcul. Une consultation un peu sérieuse réunit volontiers une quinzaine de répondants. Chacun y consacre d'un à plusieurs jours. À l'échelle d'un appel d'offres, on brûle ainsi quinze à quarante-cinq journées d'expertise, pour aboutir à quinze classeurs qui répondront tous « oui » aux mêmes lignes. Quelques semaines de cerveaux compétents, dépensées à cocher des cases que presque personne ne lira en détail. Difficile de croire qu'il n'existe pas un meilleur emploi de ce temps, comme par exemple comprendre l'entreprise.
Et puisque rien n'a été éclairci, on convoque les finalistes en soutenance. On demande alors au commercial de l'intégrateur d'exécuter son numéro : la démonstration sans accroc, les écrans qui s'enchaînent, le récit bien huilé. Tout ce théâtre vise une seule chose, masquer le fait que personne, jusque-là, n'a vraiment saisi le fonctionnement de la maison. On a remplacé l'analyse par un spectacle, et on choisit l'outil de la décennie sur la qualité de la représentation.
Le consultant qu'on emploie à l'envers
Dans toute cette mécanique, une compétence est gaspillée : celle du consultant.
On le sollicite, et on lui confie quoi ? La rédaction du cahier des charges. On paie un spécialiste de la compréhension des organisations pour produire une liste à cocher. C'est un contresens sur son métier. Ce qu'il faudrait lui demander, c'est l'opposé : aidez-nous à revoir notre manière de fonctionner et à identifier la solution qui correspond vraiment à ce que nous sommes. Un bon consultant ne coche pas des cases, il pose les questions dérangeantes et il remonte les flux jusqu'à leur origine.
La bonne nouvelle, c'est que cela se rencontre de plus en plus. Il nous arrive de prendre la suite de projets où le consultant amont a réellement travaillé le métier : flux décortiqués, processus remis en cause, fonctionnement de l'entreprise compris avant qu'on parle d'outil. Cela se voit tout de suite, parce qu'on hérite alors de vrais schémas de flux et non d'un inventaire de fonctions. Ces projets démarrent avec une longueur d'avance considérable : le plus difficile, comprendre, a déjà été accompli sérieusement.
La méthode Auguria : suivre une affaire, pas remplir une grille
Notre conviction guide notre manière de travailler. Elle est moins spectaculaire qu'un classeur de plusieurs centaines de lignes, je l'assume.
Nous passons une journée dans vos bureaux, et nous suivons une affaire réelle du début à la fin. Une commande, depuis l'instant où elle naît jusqu'au moment où elle devient une facture réglée. Nous observons par où elle transite, qui la manipule, à quel endroit elle se grippe, quelles exceptions dévorent l'essentiel du temps des équipes. Une affaire suivie en conditions réelles enseigne davantage qu'un tableur de plusieurs centaines de lignes. Chez un distributeur, par exemple, c'est une marge qui se fait ou se défait à chaque étape, et aucune case ne vous le dira.
Ni classeur signé, ni colonne « indispensable ». À l'arrivée, vous repartez avec deux livrables concrets. D'abord la cartographie complète de vos processus, le portrait fidèle de la vie de votre entreprise, celui qu'aucune grille ne contient. Ensuite les optimisations que nous recommandons, opérationnelles et financières, posées étape par étape, avant la moindre décision d'outillage.
Et si un consultant a déjà mené ce travail en amont ? Tant mieux, nous bâtissons dessus et nous allons plus loin. Sinon, nous le menons nous-mêmes. Dans les deux cas, nous refusons d'engager une entreprise pour dix ans sur la foi d'une liste que personne n'a vraiment lue.
C'est moins rassurant qu'un document épais. C'est nettement plus utile.
Un projet ERP se prépare longtemps avant la première démonstration. Si vous sentez que la phase amont mérite mieux qu'une grille à cocher, parlons-en : chez Auguria, nous commençons toujours par comprendre votre métier.