Multi-sites, multi-sociétés : ce que les logiciels standards ratent

Le même logiciel, acheté une fois pour tout le groupe, finit par ressembler à autant de logiciels que de sites. Chacun a ajouté ses champs, ignoré ceux qui ne lui servaient pas, contourné ce qui ne collait pas à sa façon de travailler. À la fin du mois, le reporting de direction se termine dans un tableau que quelqu'un reconstruit à la main, parce que les deux sites ne comptent pas tout à fait pareil.

Ce qui tient sur un site ne tient pas sur dix#

Un logiciel standard est pensé pour un périmètre : une entité, un référentiel, une façon de valider une commande. Sur un site, ça tient. Sur dix sites et trois sociétés, chaque hypothèse de départ devient une exception locale.

Le premier site qui a des règles différentes (un seuil de validation plus bas, une unité de mesure différente, une relation fournisseur spécifique) se retrouve devant deux choix : forcer sa réalité dans des champs qui ne sont pas faits pour, ou construire à côté, dans un tableur. Les deux coûtent cher, mais seul le second se voit tout de suite.

Ce n'est pas un problème d'éditeur. C'est que personne, en configurant l'outil, n'a tranché à l'avance ce qui devait rester identique partout et ce qui pouvait varier. Sans cette décision, chaque site la prend seul, et chacun la prend différemment.

Ce qui doit rester commun, ce qui peut rester local#

La question qui règle la moitié du problème se pose en une phrase : si deux sites comptent la même chose de deux façons différentes, peut-on encore les additionner ? Si la réponse est non, l'élément doit être commun. Sinon, il peut rester local.

Cette grille ne se devine pas en configurant un logiciel acheté sur étagère : elle se construit avec les sites, avant de choisir l'outil. C'est un travail de méthode, pas un paramétrage.

Le coût de la fragmentation#

Quand la grille n'existe pas, chaque site finit par ajouter son propre outil autour du logiciel central : un tableur pour ce que le logiciel ne sait pas faire, un second pour ce qu'il fait mal, un troisième pour relier les deux premiers au reporting de groupe. Chez un distributeur de plusieurs centaines de personnes, on a vu plus de quinze outils ainsi empilés autour du logiciel maison, et parmi eux, quatre logiciels du commerce coûtaient 190 000 € par an, sans compter les tableurs que personne ne facture mais que quelqu'un entretient chaque mois.

Le signe le plus simple à repérer : deux sites qui ne donnent pas le même chiffre pour la même question, le même jour. Quand c'est le cas, le reporting de direction n'est plus un chiffre, c'est une négociation entre deux versions.

Ce qui change avec une application construite pour le groupe#

Une application construite pour le groupe part de l'inverse : la grille commun/local est posée avant d'écrire le premier écran. La définition d'un chiffre (une marge, un délai de livraison, un taux de service) est unique, écrite une fois, et partagée par tous les sites. Un directeur ouvre son tableau de pilotage un lundi matin et voit un chiffre de groupe qui s'additionne vraiment, pas un cube que trois personnes seules savent reconstituer.

Ce qui reste local le reste explicitement : un site garde l'organisation d'entrepôt qui lui convient, un autre garde son circuit d'approbation à deux niveaux parce que son organigramme est différent. Rien n'est imposé en copiant l'écran d'un site sur tous les autres. Et parce qu'il n'y a pas de licence par utilisateur à multiplier par site, ouvrir un nouveau site ou absorber une société rachetée n'augmente pas la facture logicielle au même rythme que les effectifs.

Ce qu'il ne faut pas faire#

Imposer un écran strictement identique à tous les sites, sous prétexte d'uniformité, produit l'effet inverse de celui qu'on cherche. Le site dont l'organisation réelle ne colle pas à l'écran imposé construit son tableur à côté, exactement comme avec le logiciel du commerce. L'uniformité qui compte est celle des définitions et des chiffres de groupe, pas celle des écrans.

Multi-sites, multi-sociétés : ce qu'il faut retenir#

Un logiciel standard ne casse pas parce qu'il est mauvais : il casse parce qu'il suppose un seul périmètre, et qu'un groupe en a plusieurs. La grille entre ce qui doit rester commun et ce qui peut rester local se construit avant de choisir l'outil, pas pendant son paramétrage.

Faite une fois, cette grille tient dans le temps : elle dit ce qu'un nouveau site doit respecter dès le premier jour, et ce qu'il garde pour lui. C'est elle, plus que le logiciel, qui décide si le reporting de groupe reste un chiffre ou redevient une négociation chaque mois.

Voir aussi ce que change une application construite pour une entreprise, ce qu'une application sur mesure change pour un groupe, et la rubrique supply chain et transport pour les sujets propres à la distribution multi-sites.