Pas une erreur. Une organisation entière.

Épisode 3 : Pas une erreur. Une organisation entière.

Il y a un moment, dans beaucoup de projets, où on croit encore que le problème est de taille humaine.

Un délai qu'on peut rattraper. Un bug qu'on peut corriger. Un processus mal optimisé qu'on peut ajuster un peu mieux qu'avant. On bricole. On adapte. On fait avec ce qu'on a. Et pendant un temps, ça suffit.

Puis il y a le jour où ça ne suffit plus.

Pas parce que quelque chose a cassé. Mais parce qu'on réalise que ce qui cassait, c'était déjà là depuis le début.

Rappel de où on en était

Cinq ans après le choix de leur ERP, cette entreprise de ventes aux détails se retrouvait dans une situation qui durait depuis longtemps sans que personne ne pose vraiment la question. L'ERP ne répondait plus. Pas violemment. Pas d'un coup. Il répondait juste… moins bien. Chaque jour un peu moins.

L’ERP n’a pas changé, ni évolué dans un autre sens. C’est l’entreprise et ses processus qui ont évolué sans que leur SI (système d’informations) suivent.

Et moi, j'ai développé un SaaS pour boucher le trou le plus visible. Le plus urgent. Le plus coûteux en temps. Une solution pensée pour gagner des minutes sur la partie critique du processus. Une solution qui avait du sens. Qui fonctionnait.

Mais une solution qui ne changeait pas le fond du problème.

Puis il y a eu l’audit et les échanges

Entre le moment où la direction m’a expliqué leurs problématiques à l’instant, et le moment où j’ai constaté la profondeur du problème, il y a eu pas mal d’échanges. J’ai pu avoir la chronologie de leur système d’informations depuis le choix de leur ERP, et depuis les grands changements dans leurs processus.

Aux premiers échanges, il fallait juste un SaaS qui devait optimiser/automatiser certains processus que l’ERP ne pouvait pas faire, et sur ce qui demandaient le plus de temps.

Ils me parlaient également d’autres problèmes comme des incohérences entre les données terrains et les données dans l’ERP, utilisées par la directions pour prendre des décisions.

Mais finalement, après tout ces échanges je me rend compte de quelque chose de plus gros.

Ce qui a rajouté une couche, c'est le moment où la direction a vu que les chiffres mentaient

Pas les chiffres qu'ils avaient. Les chiffres qu'ils croyaient avoir.

Dans cette entreprise, les données qui guidaient les décisions ne venaient pas d'un tableau de bord en temps réel. Elles venait d’un tableau de bord construit manuellement sur plusieurs jours. Après plusieurs extractions de données via l’ERP, et des croisements de données.

Et en parallèles, il y avait les données qui provenaient du terrain également. De ce que les équipes remontaient à la main, à leur rythme, dans des fichiers, dans des conversations. Et puis ces informations prenaient du temps, avant de devenir exploitables par la direction.

Le problème, c’est que les différentes façons de remontées d’informations et leurs délais étaient pointés du doigt et remis en question. Mais sans savoir quoi faire, et comment faire.

Et tant que tout le monde utilisait la même source, même imparfaite, ça donnait l'illusion de cohérence.

De mon côté, je le vois avec plus de recul

C'est pas dans une réunion que ça m'a frappé. C'est dans un moment plus calme, plus isolé. Pendant le développement d’une des premières versions du SaaS.

Est-ce que ce que je fais, ça résout le problème ? Ou ça gère les symptômes ?

Le SaaS que j'ai construit, il gère les symptômes. Bien. Efficacement. Il économise du temps sur des processus qui en consommaient trop. Et c'est réel, ça compte, personne ne peut nier ça.

Mais le problème, il n'est pas juste là. Il est structurel. Il est dans la façon dont cette entreprise a organisé ses données, ses flux, ses décisions depuis cinq ans. Et mon outil, aussi bon soit-il, ne peut pas corriger ça tout seul.

Ce n'est pas un échec. C'est une prise de conscience.

Et c'est là que ça devient intéressant. Et compliqué.

Parce que quand on réalise que le problème est structurel, on réalise aussi que les solutions sont structurelles. Et elles prennent du temps. Elles prennent de l'énergie. Elles demandent des décisions que personne ne veut prendre en premier.

En plus du temps perdus, la direction sait maintenant que les chiffres sur lesquels elle appuie ses décisions ne sont pas fiables dans le temps. Mais changer ça, c'est changer une partie de leur organisation.

Et moi, je sais que mon SaaS va devoir évoluer — pas juste techniquement. Fondamentalement. Parce qu'un outil qui gère un processus isolé, dans un système qui ne tient pas, ça a ses limites. Et on approche de ces limites.

Deux prises de conscience en même temps. Deux directions possibles. Et aucune réponse simple.

Ce qui n'est pas encore décidé, c'est comment on bouge à partir de là.

Avec la direction, on a rapidement identifié deux axes. Je leur ai proposé un stratégie en deux temps : un court terme et un long terme. Court terme : on continue avec le SaaS. On optimise ce qui peut être optimisé maintenant. On limite la casse sur les processus les plus critiques. On gagne du temps — pas pour résoudre, mais pour souffler. Long terme : on change d'ERP. C'est la seule vraie solution structurelle. Celle qui adresse le fond, pas la surface.

Deux axes clairs. Mais aucune indication sur comment on les exécute. Et surtout, comment on fait les deux en même temps, dans une entreprise qui ne peut pas s'arrêter de tourner.

La pression ne s'arrête pas pendant qu'on réfléchit. Les magasins continuent. Les processus continuent de consommer du temps. Et l'ERP, lui, continue de répondre moins bien.

On sait où on doit aller. On ne sait pas encore comment y arriver. Et ce qui allait rendre ce choix encore plus compliqué : on ne l'avait même pas encore regardé en face.

À suivre.