Le portail d'achat
Brancher un portail de commande sur l'ERP du réseau, sans double saisie
Un portail de commande qui oblige quelqu'un au siège à ressaisir les commandes dans l'ERP ne fait pas gagner de temps : il en déplace. Voici les trois branchements possibles, leurs limites réelles, et la règle qui évite le pire des scénarios.
La promesse d'un portail d'achat est simple : le franchisé commande au catalogue et aux prix du réseau, et le siège voit les volumes. En pratique, tout se joue sur un point que personne ne tranche assez tôt : où vit la vérité du catalogue et des prix ?
Tant que cette question n'est pas réglée, vous obtenez deux catalogues qui divergent, des prix différents selon l'endroit où on les regarde, et un salarié qui passe ses matinées à recopier des commandes d'un écran à l'autre.
Trois branchements possibles, trois niveaux d'exigence
1 · Le fichier déposé
L'ERP exporte son catalogue dans un fichier, le portail le lit à intervalle régulier. Dans l'autre sens, le portail dépose les commandes de la journée dans un fichier que l'ERP importe.
Ce que ça coûte : presque rien, et ça marche avec n'importe quel logiciel, même ancien. Ce que ça limite : le catalogue est à jour au dernier export, pas à la seconde. Pour des prix qui bougent une fois par mois, c'est sans conséquence. Pour des tarifs qui bougent chaque semaine, il faut assumer le décalage et l'afficher.
2 · L'interface applicative
Le portail interroge l'ERP en direct : catalogue, disponibilités, prix, et il y renvoie les commandes. C'est le branchement propre, celui qui permet de dire au franchisé « ce prix est le bon, maintenant ».
Ce que ça coûte : ça suppose que l'ERP expose une interface, que quelqu'un chez l'éditeur réponde, et souvent une ligne dans le contrat de maintenance. Ce que ça apporte : plus aucune ressaisie, et une vérité unique.
3 · La saisie côté siège, assumée comme transitoire
On démarre sans branchement : le catalogue est tenu dans le portail, les commandes sont exportées une fois par jour. Ce n'est pas élégant, mais c'est honnête et ça permet de démarrer en deux semaines au lieu de six mois.
« On branchera l'ERP plus tard » devient un état permanent dès que le réseau s'est habitué à la ressaisie. Si vous choisissez ce démarrage, écrivez la date de bascule dans le projet, sinon elle n'arrivera jamais.
La règle qui évite tous les conflits : une seule source pour le prix
Un prix ne doit pouvoir être modifié qu'à un seul endroit. Si le siège peut changer un tarif dans l'ERP et dans le portail, les deux divergeront, et le jour où un franchisé sera facturé au mauvais prix, c'est votre crédibilité qui trinquera, pas celle du logiciel.
Concrètement, cela veut dire choisir, pour chaque donnée, qui commande :
| Donnée | Qui fait foi |
|---|---|
| Références et libellés | L'ERP. Le portail les affiche, ne les crée pas. |
| Prix réseau | L'ERP, sans exception. |
| Droit de commander une référence | Le portail, parce que ça dépend du format du restaurant et pas de la comptabilité. |
| Historique des commandes | Les deux, et c'est normal : le portail pour le franchisé, l'ERP pour la facturation. |
Ce que ça change sur les écarts d'achats
C'est le vrai gain, et il n'a rien à voir avec le confort de commande. Quand toutes les commandes passent par un même catalogue, elles deviennent comparables. Vous voyez alors trois choses que personne ne voyait :
- Qui commande hors catalogue. Un restaurant dont les volumes ne correspondent pas à son chiffre d'affaires s'approvisionne ailleurs. Ce n'est pas forcément une faute, mais c'est une conversation à avoir.
- Ce que le réseau pèse vraiment chez un fournisseur. Vous arrivez en négociation avec un volume constaté, pas avec une estimation. C'est la différence entre demander une remise et la justifier.
- Les écarts de consommation à chiffre d'affaires égal. Deux restaurants qui font le même chiffre et commandent des quantités très différentes : il y a une perte quelque part, ou une recette appliquée différemment.
Ouvrir le portail avec le catalogue et le fichier déposé, laisser le réseau prendre l'habitude, puis brancher l'interface applicative quand les volumes justifient l'investissement. L'inverse (six mois d'intégration avant la première commande) échoue une fois sur deux, parce que le projet perd son sponsor avant d'avoir produit quoi que ce soit.
Les quatre questions à poser avant de commencer
- Qui met à jour les prix aujourd'hui, et à quelle fréquence ? La réponse dicte le branchement, pas l'inverse.
- Votre ERP expose-t-il une interface, et à quel coût ? À demander à l'éditeur par écrit, avant de promettre quoi que ce soit au réseau.
- Tous les restaurants ont-ils droit aux mêmes références ? Si non, la gestion des droits doit être prévue dès le départ, elle se rajoute très mal après.
- Qui traite un litige de livraison ? Un portail qui prend les commandes sans dire qui règle les problèmes crée un aller-retour de plus, pas un de moins.
Ce qu'il faut retenir
Un portail d'achat n'est pas un problème d'interface, c'est un problème de source de vérité. Réglez d'abord qui commande le prix, choisissez le branchement le plus simple qui permette de démarrer, et gardez la marche suivante écrite dans le projet. Le jour où toutes les commandes du réseau passent par le même catalogue, vous ne gagnez pas seulement du temps : vous gagnez un levier de négociation que vous n'aviez pas.
Votre réseau commande déjà. La question, c'est où vit la vérité.
En vingt minutes, on regarde votre chaîne d'achat telle qu'elle est aujourd'hui : où sont les prix, qui les met à jour, et ce qu'il faudrait brancher pour arrêter la double saisie.
Vingt minutes, les chiffres réels →Vous préférez la voix ? 07 56 80 87 26 · un message WhatsApp