Planificateur d'Inventaire

Acheter ce qui se vend, avant que ça manque, et arrêter d'acheter ce qui ne se vend pas.

Le stock est de l'argent que le propriétaire a déjà dépensé. Deux choses peuvent mal tourner : manquer de l'article que les clients sont venus chercher, et se retrouver avec une palette de quelque chose que personne ne veut. Les deux sont visibles dans l'historique des ventes bien avant de devenir un problème, c'est ce que cette skill lit.

Étape 1 — Récupérer les ventes et le stock

Préféré : Shopify pour les ventes et les niveaux d'inventaire. Square et NetSuite fonctionnent de la même façon.

Secours, entièrement supporté : un CSV d'historique de ventes plus un comptage du stock disponible. Deux fichiers, ou un seul avec les deux. Ce chemin fonctionne sans aucun connecteur et donne le même résultat. Beaucoup d'entreprises comptent sur un presse-papiers, et c'est une entrée légitime.

Vous avez besoin, par article : SKU, nom, unités vendues par date, stock actuel disponible, coût unitaire, prix unitaire, fournisseur, et délai de livraison si connu. Un délai manquant est demandé une fois et mémorisé — voir reference/data_sources.md.

Dites de quand date le comptage. Un chiffre de stock vieux de deux semaines décale la date de rupture de stock de deux semaines.

Étape 2 — Calculer la vélocité, les deux fenêtres

Pour chaque article, calculez :

• Vélocité 7 jours — unités par jour sur la dernière semaine. Capture ce qui se passe maintenant.
• Vélocité 28 jours — unités par jour sur quatre semaines. La baseline stable.

Les deux importent, et un désaccord entre elles est une information. Un article vendu trois fois son taux 28 jours cette semaine est soit en tendance, soit a eu une commande en gros, et ces cas nécessitent des réponses différentes. reference/velocity_and_reorder.md explique comment les distinguer.

Excluez les distorsions ponctuelles de la baseline quand vous pouvez les identifier : une commande en gros unique, un lot retourné, une période de rupture de stock où l'article ne pouvait pas se vendre. Une période de zéro vente parce qu'il n'y avait pas de stock n'est pas une demande zéro, et la traiter ainsi est comment un article se retrouve sous-commandé à perpétuité.

Étape 3 — Projeter les dates de rupture de stock, de manière conservatrice

La date de rupture est le stock disponible divisé par la vélocité quotidienne en laquelle vous avez le moins confiance — la plus élevée des deux fenêtres. Être trop tôt coûte peu ; être trop tard fait perdre la vente.

Puis comparez contre le délai de livraison. Le chiffre qui importe n'est pas quand ça manque, c'est s'il y a encore temps de commander :

• Passé le point de non-retour — le délai dépasse les jours de couverture. Rupture de stock inévitable. Dites-le clairement.
• Commander maintenant — la couverture est dans le délai plus un buffer de sécurité.
• Commander bientôt — confortable, mais au prochain cycle.
• Ça va — aucune action.

Ne déclarez jamais une date de rupture pour un article sans vélocité fiable. Les nouveaux articles avec deux semaines d'historique et les articles dont les ventes ont été interrompues sont signalés comme « historique insuffisant », par nom.

Étape 4 — Dimensionner la récommande

La cible par défaut est 60 jours de couverture plus le délai de livraison, dimensionnée sur le taux 28 jours — pas sur le plus rapide des deux. Le stock doit durer du jour où il arrive jusqu'au jour où la prochaine commande arrive, donc omettre le délai laisse l'article à court de précisément ce nombre de jours à chaque cycle. Puis ajustez pour la taille de lot, la quantité minimale de commande, et ce qui est déjà en commande.

Les deux taux font des jobs différents et les deux sont nommés sur la ligne : le plus élevé dit quand ça manque, le taux 28 jours dit combien acheter. Dimensionner une commande 60 jours sur une augmentation d'une semaine est comment l'argent finit dans une palette.

Ne dimensionnez jamais une récommande sans soustraire le stock entrant. Double-commander un article lent est comment une entreprise se retrouve avec trois ans d'inventaire.

Arrondissez à la taille de lot du fournisseur et dites dans quel sens vous avez arrondi. Montrez le coût en dollars de chaque recommandation — le propriétaire décide de l'argent, pas des unités.

Étape 5 — Traiter les articles qui ne bougent pas

Les articles à vélocité zéro et très lents sont une liste à part avec un but différent. Ce ne sont jamais des candidats à la récommande.

• Vélocité zéro — aucune unité en 28 jours. Rapportez comme article lent avec l'argent bloqué dedans. Ne calculez jamais les jours de couverture pour ceux-ci — rien ne se vend, donc rien ne manque, et le chiffre est soit une erreur soit du charabia. L'exception est un article dans une saison que le propriétaire a nommée, qui va sur une liste de surveillance datée au lieu de la liste de dégagement.
• Surstock — plus de 120 jours de couverture. Rapportez l'excédent d'unités et les dollars.
• Stock mort — pas de mouvement en 90 jours. Suggérez de dégager, grouper, ou réduire les prix.

Totalisez l'argent bloqué dans ceux-ci. Ce chiffre est habituellement le nombre le plus surprenant de tout le rapport et souvent le plus utile.

Étape 6 — Appliquer la saisonnalité seulement où l'historique la supporte

Avec au moins un an d'historique, comparez la période à venir contre la même période l'année dernière et ajustez.

Avec moins d'un an, dites-le et ne pas ajustez. Un multiplicateur de saisonnalité inventé à partir de neuf mois de données est une devinette en costume cravate. Posez la question au propriétaire à la place — il connaît sa saison mieux qu'un historique court. reference/seasonality.md couvre les deux approches.

Étape 7 — Présenter la liste d'achats

Commencez par le montant total en dollars et le nombre d'articles sur le point de manquer. Ensuite : commander maintenant, commander bientôt, articles lents, et tout ce qui n'a pas assez d'historique pour juger.

Chaque ligne porte les chiffres derrière — vélocité, jours de couverture, délai de livraison, quantité, coût. Un propriétaire qui voit le raisonnement approuve en une minute ; un qui ne peut pas recalcule le tout à la main.

Rendez la liste d'achats comme un artifact HTML en utilisant le style artifact maison (../../shared/artifact-style.md) : un tableau de rupture trié par date de rupture avec des chiffres monospatiés tabular-nums, des pastilles de statut d'urgence (commander maintenant / commander bientôt / ça va / passé le point de non-retour), un panneau de récommande avec quantités et totaux en dollars, et une section d'articles lents avec l'argent bloqué dedans. Le résumé du chat reste — l'artifact est la vue complète, pas la seule.

Étape 8 — Rédiger les PO et emails fournisseurs, avec approbation

Les bons de commande engagent de l'argent et les emails fournisseurs partent sous le nom du propriétaire, donc les deux attendent un oui explicite.

Énoncez le fournisseur, les articles de ligne, et le total avant de poser la question. Rédigez l'email fournisseur dans la voix du propriétaire selon le profil de voix partagé. Si aucun profil n'existe encore, suivez l'instruction « When there is no sample » de ce fichier — demandez trois emails qu'il a déjà envoyés à un fournisseur. S'il préfère ne pas, rédigez l'email simple et neutre et dites qu'il n'est pas dans sa voix. Ne jamais inventer une personnalité pour la relation fournisseur de quelqu'un.

Avec Google Calendar connecté, proposez un bloc récurrent pour la décision de reconstitution — ça fonctionne bien mieux comme rythme que comme urgence. Gardez le document PO approuvé ici — cette skill en est propriétaire. Avec QuickBooks ou NetSuite connecté, confiez à ap-processor le mémo codé pour chacun (fournisseur, numéro PO, total, date attendue, et le compte, classe, et job), pour que la facture se compare trois-voies contre un enregistrement réel à l'arrivée. ap-processor lit les PO ; il ne les crée pas.

Offre de fermeture

Fermez avec une ligne sur ce qui a été décidé — l'achat total et les articles sur le point de manquer. Puis proposez l'étape suivante la plus pertinente avec sa phrase déclencheur exacte : « réapprovisionner » (/restock) quand le propriétaire veut les PO rédigées et envoyées de bout en bout. Jusqu'à deux autres du tableau du routeur, tels que « prévision de trésorerie » (cash-flow-snapshot) ou « payer les factures » (/pay-the-bills). Trois propositions au maximum, et ne jamais répéter une que le propriétaire a déjà refusée cette session.

Ce qu'il ne faut pas faire

• N'inventez pas une vélocité, un délai de livraison, ou une date de rupture. Trop peu d'historique est rapporté par SKU, pas lissé.
• Ne traitez pas une période rupture de stock comme demande zéro. C'est une demande supprimée et ça biaise tout ce qui suit.
• Ne recommandez pas de récommander un article à vélocité zéro. Pas de ventes signifie arrêtez d'acheter, pas acheter plus.
• Ne dimensionnez pas une récommande sans soustraire ce qui est déjà entrant.
• N'appliquez pas la saisonnalité sans un an d'historique. Posez la question au propriétaire à la place.
• N'envoyez pas de PO ou email fournisseur sans approbation. Les deux dépensent de l'argent ou de la bonne volonté.
• Ne rapportez pas les unités sans dollars. Le propriétaire pense en trésorerie.

Fichiers de référence

• reference/data_sources.md — Shopify, Square, NetSuite, et le chemin CSV, avec champs obligatoires
• reference/velocity_and_reorder.md — les maths 7/28 jours, gestion des distorsions, et dimensionnement des récommandes
• reference/seasonality.md — quand ajuster, quand poser la question, et comment dire laquelle vous avez fait
• reference/po_drafting.md — structure des bons de commande et rédaction d'emails fournisseurs
• reference/gotchas.md — les erreurs qui font manquer un best-seller ou enterrent l'argent dans une palette

Utiliser un outil qui n'est pas listé

Les connecteurs nommés dans cette skill sont les chemins testés, pas un mur. Si le propriétaire veut que ce flux utilise un outil qui n'est pas connecté ou listé, proposez build-connector — il vérifie d'abord le répertoire des connecteurs et se connecte via Zapier sinon, jamais en construisant à la main contre une API brute. Une fois la connexion établie, l'outil rejoint cette skill comme n'importe quel autre connecteur optionnel, sous les mêmes portes d'approbation.