RFI, RFP et RFQ : la folie dans la supply chain
Au fil des années, Lokad a acquis une certaine notoriété, et nous avons eu le privilège de faire partie d’un nombre toujours croissant de RFI (demande d’information), RFP (demande de proposition) et RFQ (demande de devis) liés à l’optimisation de la supply chain. Bien que je sois reconnaissant que Lokad soit considéré comme assez notable pour être présélectionné dans ces initiatives – et régulièrement choisi également – je ne peux m’empêcher de contempler la pure folie qui sous-tend ces processus.

Depuis longtemps, j’ai été interloqué par les pratiques étranges qui prévalent dans le domaine des logiciels d’entreprise 1. Plus récemment, j’ai également proposé une approche que je crois fermement supérieure, à tous égards, aux méthodes classiques 2. Cependant, aujourd’hui, j’aimerais décortiquer certains des éléments franchement bizarres (voire carrément insensés) des RFP que j’ai observés. En résumé, les RFP 3 sont du scientisme en action. Une perspective, une attitude et un processus qui imitent, aux yeux du grand public, ce à quoi une entreprise « scientifique » est censée ressembler. Cependant, en pratique, les RFP sont aussi scientifiques ou rationnels qu’une séance.
Pour commencer, les listes de questions rassemblées dans les RFP sont, sans exception, à la fois longues et dénuées de sens. Ces documents résultent invariablement d’un comité qui tente de satisfaire tout le monde en listant toutes les questions auxquelles on pourrait penser. Pire encore, chaque fois que des experts – typiquement des consultants – sont amenés à examiner ou améliorer la liste, le catalogue de questions est gonflé d’un ordre de grandeur.
Si le dicton il n’y a pas de question bête peut constituer un principe directeur valable pour une école primaire, il devient carrément nuisible lorsqu’il s’agit d’une grande entreprise et de sa supply chain. Franchement, dans le monde réel, de mauvaises questions peuvent engendrer des coûts en temps perdu, en attention mal investie et en compromis coûteux faits pour ménager les susceptibilités. Il existe plusieurs catégories de telles questions 4, et ci-après, j’identifierai sept des plus courantes tout en en soulignant les défauts.
- Questions paresseuses. Exemple : La solution respecte-t-elle les meilleures pratiques de sécurité ? Ces questions font tout simplement perdre du temps à tout le monde. Aucun fournisseur de logiciels d’entreprise, avec toute sa raison, ne va jamais répondre négativement à une telle question.
- Questions stupides. Exemple : La solution gère-t-elle les MOQ (quantités minimales de commande) ? Ces questions ajoutent de la confusion. Gérer les MOQ est trivial ; c’est réaliser toute forme d’optimisation en présence de MOQ qui est difficile.
- Questions « intelligentes ». Exemple : Comment la solution rationalise-t-elle les divergences entre les prévisions et le plan initial en cas de ruptures de stock ? Je présume que ces questions (apparemment précises, mais en réalité vagues) sont destinées à impressionner les collègues, mais elles ne font qu’ajouter une couche supplémentaire de confusion, laquelle se voit rapidement aggravée par la réponse tout aussi fleurie du fournisseur de logiciels.
- Questions biaisées. Exemple : La solution offre-t-elle la possibilité de gérer et d’ajuster les profils de saisonnalité? Ces questions portent atteinte à la neutralité du processus et suscitent des interrogations implicites supplémentaires. La question d’exemple implique que la saisonnalité doit être abordée via des « profils » (pourquoi ?) et que les utilisateurs finaux doivent être impliqués (pourquoi ?).
- Questions ambiguës. Exemple : La solution permet-elle l’introduction d’indicateurs de performance (KPIs) ? Cette catégorie de questions exacerbe les incompréhensions. Ce qui constitue un KPI dépend du regard que l’on porte dessus ; il est peu probable que le fournisseur et le client partagent les mêmes sentiments à ce sujet.
- Questions tangentielles. Exemple : La solution peut-elle recalculer en temps réel ses suggestions de reapprovisionnement? Ces questions servent à détourner l’attention des problématiques centrales. La notion de « temps réel », dans le domaine des logiciels d’entreprise distribués, entraîne de longues discussions excessivement techniques qui deviennent finalement sans importance si les chiffres de reapprovisionnement sont pourris dès le départ.
- Questions effrayantes. Exemple : La solution est-elle certifiée ISO/IEC 27001 ? Ces questions donnent du pouvoir aux mauvaises parties. Les certifications, dans les logiciels d’entreprise, renforcent les organismes de certification et leur écosystème, tout en n’apportant absolument aucune valeur à l’entreprise cliente.
S’attendre à ce que le bon fournisseur soit choisi en posant les mauvaises questions revient à espérer qu’un calcul soit correct en utilisant des données initiales erronées. Pourtant, cela semble être l’approche privilégiée par la plupart des grandes entreprises en matière de logiciels d’entreprise.
Pour aggraver les choses, de nombreux RFP comportent une colonne « Conformité » – ou quelque chose dans ce goût-là – à côté de la colonne « Réponse », demandant au fournisseur de s’auto-diagnostiquer son degré de conformité par rapport à la question. L’idée qu’un produit logiciel puisse être conforme à une question est déconcertante. Toutefois, en pratique, les questions des RFP étant tellement biaisées, la colonne « Conformité » prend un certain sens, quoique de manière étrange et tordue.
Je tiens également à souligner que (presque ?) tous les documents de RFP reflètent, dans leur présentation, un manque de soin tout à fait brutal. Chaque paragraphe est truffé de fautes d’orthographe épouvantables. On y trouve des questions en double et des numéros de questions dupliqués. La taille de la police varie inélégamment de 6 à 20, et des retours à la ligne hasardeux jalonnent le document. Côté questions, c’est encore pire puisque les RFP sont généralement formatés sous forme de tableurs Microsoft Excel – répartis sur plusieurs onglets, chacun ayant sa propre colonne « Question » et « Réponse », auxquels s’ajoutent quelques autres pour faire bonne mesure (comme l’exemple de « Conformité » mentionné ci-dessus). Le format de tableur n’a aucun sens dans le contexte d’un RFP. L’expérience utilisateur – qu’il s’agisse d’écrire ou de lire un contenu multi-paragraphe dans une cellule de tableur – est misérable ; d’autant plus quand il y a des centaines de questions, comme c’est généralement le cas.
Comme si cela ne suffisait pas, considérez que les outils d’e-procurement, fréquemment utilisés pour mener ces mascarades, ont été forgés dans le neuvième cercle de l’enfer. Ces outils représentent les pires incarnations des logiciels d’entreprise, chacun pionnier dans l’art d’abaisser les attentes : design non réactif, bâclé, expérience utilisateur inepte, et encombré de listes de bugs non corrigés d’une longueur tolkienienne. Grâce à l’utilisation de tels outils d’e-procurement, la folie bureaucratique est portée à onze 5.
Il est naïf de penser que la forme est sans importance tant que le fond est présent. La forme d’un RFP, aussi atroce soit-elle, fait en sorte que se plonger dans les questions, sans parler des réponses, représente un véritable gouffre temporel. En conséquence, les personnes qui devraient mener le processus de sélection – des dirigeants tels que le directeur de la supply chain – se retirent et délèguent la tâche à des « experts », comme les responsables des achats ou des tiers. Ces responsables disposent généralement de peu d’intuition sur ce qui constitue une solution raisonnable pour leur propre entreprise. Pendant ce temps, les tiers, introduits en tant que facilitateurs du RFP, sont incités à rendre l’opération aussi labyrinthique que possible.
Certains pourraient soutenir qu’un RFP est un mal moindre comparé au pur favoritisme qui surviendrait en son absence. Autrement dit, les RFP, aussi défectueux soient-ils, restent l’option la plus sûre pour préserver l’intégrité de l’entreprise et de son processus de sélection. Cependant, il s’agit d’une affirmation tout à fait extraordinaire qui requiert, de ce fait, des preuves extraordinaires. En effet, cela soulève des questions quant au type de fraude que les RFP sont censés prévenir et, par conséquent, sur leur efficacité dans cette mission. Franchement, l’idée de canaliser un vaste processus de sélection à travers un tableur tout aussi vaste et chaotique pour rendre le processus « plus honnête » semble, de prime abord, bien tirée par les cheveux. (Veuillez excuser mon scepticisme.)
Mes observations anecdotales du monde des logiciels d’entreprise indiquent que de nombreux grands fournisseurs récompensent généreusement les personnes qui, autrefois, occupaient des postes d’influence en matière de RFP en les embauchant une décennie plus tard. L’antidote à cette (mauvaise) pratique est simple : identifier les fournisseurs qui jouent ce jeu et les bannir purement et simplement 6. Réalistement, les RFP ne font rien contre le type de corruption avant-gardiste qui sévit dans le monde des logiciels d’entreprise.
Ainsi, mon analyse est la suivante : tout ce qui rend le processus de sélection des fournisseurs plus bureaucratique qu’il ne le devrait le rend, en retour, plus vulnérable aux acteurs malveillants. Cette proposition peut être reformulée d’un point de vue de la sécurité informatique : la bureaucratie augmente la surface d’attaque du processus de sélection des fournisseurs en répartissant la confiance (et donc la vulnérabilité) sur des couches de personnes qui n’ont aucune raison d’être dignes de confiance dans ce cadre.
Malgré tous ces problèmes, les RFP sont omniprésents dans les logiciels d’entreprise. Pourtant, en privé, la plupart des gens – du moins ceux qui ne vivent pas des RFP – admettent que le processus a peu de sens, ce qui rend encore plus énigmatique leur prévalence. L’explication la plus simple que je puisse proposer est que les RFP constituent une forme élaborée de virtue signaling d’entreprise 7. À l’ère des technologies de l’information, admettre qu’une décision majeure puisse être prise sur la base d’une simple estimation éclairée n’est pas acceptable et est perçue comme simpliste, peu sophistiquée et carrément non scientifique. Le processus de RFP n’apporte peut-être rien de valeur pour l’entreprise mais il répond pleinement à l’angle du virtue signaling.
-
Un guide d’achat pour les logiciels d’entreprise, Joannes Vermorel, août 2013. ↩︎
-
Recherche de marché antagoniste pour les logiciels d’entreprise - Conférence 2.4, mars 2021, Joannes Vermorel ↩︎
-
Pour faire court, dans cet article le terme « RFP » se réfère collectivement aux RFI, RFP et RFQ. ↩︎
-
Tous les exemples listés dans cette section sont de véritables questions de RFP que nous avons reçues au cours des 12 derniers mois. ↩︎
-
En règle générale, lorsqu’un outil d’e-procurement est en place, Lokad et son client potentiel gaspillent l’équivalent de plusieurs journées de travail à faire ce qui revient à envoyer un e-mail avec une pièce jointe PDF à 5 destinataires en copie. ↩︎
-
LinkedIn permet d’identifier relativement facilement les fournisseurs de logiciels qui embauchent des personnes qui, commodément, occupaient autrefois des postes au bon endroit et au bon moment. Cependant, le fait de disposer de toutes les informations pertinentes en accès public rend ce type de corruption encore plus insidieux, car il ne nécessite même pas de communication explicite entre les parties, seulement une entente tacite. ↩︎
-
Un autre avantage secondaire des RFP pourrait être la dilution des responsabilités, car les RFP, par leur conception, impliquent un nombre assez important de personnes du côté client. ↩︎