Système de gestion des stocks de restaurant vs ERP : où le calcul du coût des recettes s'effondre

Ce que fait réellement un système de gestion des stocks de restaurant et ce que fait un ERP

Un système de gestion des stocks de restaurant suit les stocks, les recettes et le coût matière au niveau de l'assiette ; un ERP d'entreprise généraliste gère les finances et la chaîne d'approvisionnement de l'ensemble de l'entreprise. Ils se recoupent sur les achats et les stocks, mais seul l'un d'eux a été conçu pour chiffrer le coût d'une recette, et c'est dans cet écart que les groupes multi-sites se retrouvent bloqués.

Les deux systèmes gèrent des articles, des fournisseurs et des prix, si bien que sur le papier, un ERP semble devoir couvrir également la gestion des stocks. Les équipes qui évaluent cette question utilisent généralement déjà SAP, Microsoft Dynamics 365 ou un back-office similaire, et la question est rarement « lequel acheter ? » mais « avons-nous vraiment besoin d'une couche distincte alors que l'ERP dispose déjà d'un module de gestion des stocks ? ». La réponse honnête dépend d'une seule chose : quelle part de votre activité repose sur le coût des recettes, et combien de sites cela concerne.

Le tableau ci-dessous indique où chaque système excelle. Lisez-le comme une répartition des rôles, et non comme un combat à mort, car dans la plupart des groupes multi-sites, les deux finissent par travailler ensemble plutôt que l'un ne remplace l'autre.

Pourquoi un ERP financier ne peut pas chiffrer le coût d'une recette de restaurant

Les ERP d'entreprise comme SAP et Microsoft Dynamics ont été conçus pour la fabrication et la finance, où une nomenclature assemble des composants fixes pour obtenir un produit fini. Une recette de restaurant est une tout autre chose : les portions varient, les ingrédients sont substitués, la préparation entraîne des pertes de rendement, et le même plat est préparé légèrement différemment dans dix cuisines. La nomenclature de l'ERP n'a jamais été conçue pour gérer cela, si bien que l'équipe de chiffrage finit par exporter les données de réception et de prix dans Excel pour reconstruire manuellement les coûts des recettes.

C'est là que le calcul du coût des recettes s'effondre. Ce n'est pas que l'ERP soit un mauvais système ; c'est que le chiffrage d'une assiette est en dehors de ce pour quoi il a été conçu. Nous entendons la même histoire d'un groupe multi-marques contraint de travailler avec des tableurs parce que leur ERP ne permettait pas le coût des recettes, et d'un groupe de dix sites qui extrait manuellement chaque semaine les données de réception et de prix du même ERP. Le travail est réel, répétitif et silencieusement sujet aux erreurs, ce qui est exactement le type de tâche qu'un tableur gère bien jusqu'au jour où il ne le fait plus. Le même piège touche les équipes qui tentent de gérer le chiffrage via un module de gestion des stocks ERP dans une cuisine centrale.

Une plateforme dédiée comble cet écart en modélisant la recette telle que la cuisine fonctionne réellement. Les recettes et les recettes de préparation prennent en charge les articles préparés et semi-finis, sont liées au menu de la caisse pour qu'une vente déduise les bons ingrédients, y compris les modificateurs, et intègrent les pertes de préparation pour que le coût reflète ce que la cuisine consomme réellement. Comme le coût est appliqué automatiquement aux inventaires, aux pertes, à la production et aux transferts, le coût théorique est toujours basé sur le coût de recette en cours, sans que personne n'ait à déclencher un recalcul.

Là où la solution de contournement Excel corrompt silencieusement vos coûts

Le pont tableur ne s'effondre pas bruyamment. Il échoue une ligne substituée à la fois. Un fournisseur livre une marque, une qualité ou une origine différente pour le même ingrédient, la réception l'enregistre sous un nouveau code ou un code incorrect, et la recette dans Excel continue de pointer vers l'article retiré et son ancien prix. L'assiette est maintenant chiffrée sur un prix que la cuisine ne paie plus, et parce que chaque site lit la même recette, l'erreur se propage partout à la fois.

Multipliez cela par une semaine chargée, où une part significative des lignes est substituée, et le coût matière déclaré s'éloigne de la réalité sans que personne ne touche à la formule. Un groupe peut observer un coût matière qui semble sain alors que le chiffre réel est plusieurs points plus élevé, et personne ne le voit jusqu'à ce que la clôture mensuelle impose une réconciliation.

Une plateforme qui tire les prix de la réception et garde la recette liée à l'article en temps réel supprime la ressaisie manuelle qui permet à cela de se produire. Ce n'est pas que les personnes soient négligentes ; c'est que le tableur n'a aucun moyen de savoir qu'un article a été substitué, donc la correction n'est jamais faite.

Ajouter une couche par-dessus, ou tout remplacer ?

La question qui compte n'est pas « ERP ou plateforme dédiée ». Pour la plupart des groupes qui utilisent déjà un ERP financier, c'est « remplaçons-nous l'ERP, ou ajoutons-nous une couche qui fait la partie que l'ERP ne peut pas faire ? ». Remplacer un système financier qui fonctionne pour obtenir le calcul du coût des recettes n'en vaut presque jamais la peine, et gérer les opérations d'un restaurant entièrement dans un ERP généraliste signifie vivre indéfiniment avec la solution de contournement par tableur.

La voie médiane est celle que la plupart des groupes multi-sites choisissent : conserver l'ERP comme système de référence pour les finances et les dettes fournisseurs, et ajouter une plateforme dédiée de gestion des stocks et des recettes par-dessus pour les inventaires, le coût des recettes et le coût matière. Les deux se connectent via une intégration, de sorte que les valeurs de réception et le statut des documents circulent entre eux plutôt que d'être ressaisis. Supy affiche l'état de synchronisation en temps réel des systèmes comptables connectés, notamment Xero, QuickBooks, NetSuite, MS Dynamics et d'autres, directement sur les enregistrements de réception et de fournisseurs, et fait partie d'une bibliothèque de 75+ intégrations couvrant la caisse, la comptabilité et les ERP. L'ERP continue de faire ce qu'il fait bien ; la couche chiffre les assiettes qu'il n'a jamais pu calculer.

Choisir entre les deux : quand chaque approche l'emporte

Ramenez cela à votre propre situation. Choisissez le module de gestion des stocks ERP seul lorsque votre menu est simple, vos sites peu nombreux, et que le coût des recettes représente une partie mineure de l'activité. Choisissez une plateforme dédiée de gestion des stocks et des recettes en plus de votre ERP lorsque vous gérez un vrai menu sur plusieurs sites, que votre équipe de chiffrage exporte vers Excel, et que le coût matière est un chiffre que l'entreprise cherche à améliorer. Si vous n'avez pas encore d'ERP et que vos recettes sont complexes, commencez par la plateforme dédiée et évitez le détour par l'ERP de fabrication que vous ne feriez qu'ajouter en surface plus tard.

Un rapide bilan personnel : ouvrez la dernière recette que votre équipe a chiffrée et trouvez la date à laquelle les prix des ingrédients ont été mis à jour pour la dernière fois. Si cette date est antérieure à votre dernier changement de prix fournisseur, votre coût matière dérive déjà, et aucune configuration ERP ne corrige une méthode de chiffrage qui vit dans un tableur. Si vous souhaitez évaluer rapidement la situation de vos assiettes avant de changer de système, notre calculateur de coût matière gratuit vous donne le chiffre en quelques minutes.

Supy est la couche dédiée exactement pour cela : un calcul du coût des recettes natif pour la restauration qui se met à jour lorsque vos prix changent, qui s'appuie sur l'ERP que vous utilisez déjà, et qui garantit que chaque site chiffre la même assiette de la même façon. Si c'est l'écart que votre groupe a comblé avec un tableur, il vaut la peine de voir comment cela fonctionne avec vos propres recettes.