Un client attend au comptoir, le produit n’existe pas dans le logiciel, il faut le créer tout de suite. Nom tapé vite, dosage approximatif, pas de code. La vente passe, le client repart satisfait, et l’officine vient d’ajouter une ligne de plus à une base de données que personne ne tient vraiment. Répété quelques centaines de fois sur plusieurs années, ce geste explique une bonne partie des problèmes de stock qu’on met ensuite sur le compte du logiciel ou de l’équipe.
Un doublon coûte deux fois
Le même produit saisi deux fois sous deux libellés différents, ce sont deux fiches, deux stocks et deux historiques. Aucun des deux n’est juste. L’une annonce trois boîtes quand il y en a douze en rayon, l’autre en annonce neuf. Le seuil d’alerte ne se déclenche jamais au bon moment, puisqu’il ne surveille qu’une fraction du stock réel. Les ventes se répartissent entre les deux fiches, donc le produit paraît deux fois moins demandé qu’il ne l’est, et la commande suivante en tient compte. Un doublon ne fausse pas une ligne, il fausse une décision d’achat.
Sans code, rien ne se raccorde
Un produit sans code reste du texte libre, et le texte libre ne se raccorde à rien. Ni au catalogue du grossiste, ce qui oblige à tout ressaisir à la réception. Ni à un rappel de lot, quand il faut retrouver vite ce qui est concerné. Ni à un état par famille thérapeutique, parce que le logiciel n’a aucun moyen de savoir qu’un produit appartient à une classe. Le code n’est pas une formalité administrative, c’est ce qui permet à deux systèmes de parler du même objet.
Le libellé que personne ne cherche de la même façon
Quand chaque personne saisit à sa manière, la recherche au comptoir devient un jeu de devinettes. L’un tape la marque, l’autre la molécule, un troisième une abréviation maison. Le produit ne remonte pas, et le vendeur conclut à une rupture alors que la boîte est à deux mètres de lui. C’est le pire des scénarios : une vente perdue sur un produit présent. Nous décrivions ce mécanisme sous un autre angle dans notre article sur la rupture comme problème de gouvernance.
Pourquoi chaque officine a fini par tenir sa propre base
Il faut le dire clairement : ce n’est pas de la négligence. Beaucoup d’officines ont constitué leur catalogue elles-mêmes parce que c’était le moyen disponible, et parce que garder la main sur ses propres données est un réflexe sain. Chaque logiciel arrivait avec sa base, chaque changement d’outil imposait de tout reprendre, et la prudence consistait à ne dépendre de personne. Ce qui a changé, c’est l’échelle. Une base tenue à la main reste gérable avec quelques centaines de références et une seule personne aux commandes. Elle devient ingérable avec plusieurs milliers de références, une équipe qui tourne et un second point de vente.
Ce qu’une base commune change
- Un produit, une identité : dénomination, dosage, forme, présentation, code ;
- Une réception qui se raccorde au catalogue du fournisseur, sans ressaisie ;
- Des mises à jour reçues une fois, au lieu d’être répercutées référence par référence ;
- Des états par famille thérapeutique, enfin possibles ;
- Un rappel de lot exploitable en quelques minutes ;
- Un historique comparable dans le temps, et transportable vers un second site.
Ce qu’elle ne doit pas vous enlever
Une base commune ne doit pas faire de vous le simple utilisateur du catalogue de quelqu’un d’autre. Vous devez garder la main sur ce qui vous est propre : parapharmacie, produits libres, conditionnements que vous seul travaillez, libellés que votre équipe reconnaît. Le bon partage n’est pas « tout est commun », c’est « l’identité des produits est commune, le reste vous appartient ». Une base qui n’accepte aucune ligne locale finit contournée, et l’officine recommence à créer ses doublons dans un coin.
Les questions à poser à votre éditeur
- Qui maintient la base, et à quelle fréquence est-elle enrichie ?
- Combien de temps entre l’arrivée d’un produit sur le marché et son apparition dans la base ?
- Que se passe-t-il quand la base et la réalité de mon rayon divergent, et qui tranche ?
- Puis-je créer mes propres lignes sans casser l’ensemble ?
- Mes doublons existants peuvent-ils être fusionnés sans perdre l’historique de ventes ?
- Si je change d’outil un jour, qu’est-ce qui part avec moi ?
La dernière question est celle qui décide de tout le reste, et c’est celle qu’on pose le moins.
Un référentiel propre est la condition de tout le reste
Un comptage ne veut pas dire grand-chose sur une base qui comporte des doublons : vous trouvez douze boîtes et vous ne savez pas sur laquelle des deux fiches les porter. C’est pour cette raison qu’un inventaire mal préparé produit des écarts qui n’existent pas, comme nous l’expliquons dans notre article sur l’inventaire d’officine. Et une correction de stock ne sert à rien si elle porte sur une fiche fantôme, ce qui vide de son sens la discipline décrite dans notre article sur les régularisations. Le référentiel n’est pas un sujet technique de plus : c’est la couche sur laquelle tiennent le stock, les commandes et le pilotage.
Phénix, le logiciel de gestion d’officine d’AS PHARM, s’appuie sur une base produits entretenue par l’éditeur, tout en laissant à chaque officine ses propres lignes et ses propres libellés. Le module Stock et approvisionnement en tire les codes, les familles et les raccordements aux catalogues fournisseurs. Réservez une démonstration de 30 minutes pour voir ce que donnerait votre catalogue actuel une fois nettoyé.