Centre d’aide/Opérations Core/Cycle counts : l’exactitude de l’inventory comme cadence
11Opérations Core3 min de lecture

Cycle counts : l’exactitude de l’inventory comme cadence

Définir le périmètre, parcourir le rack, résoudre les écarts, approuver le résultat — au lieu d’une panique annuelle.

L’inventaire annuel n’a pas la bonne forme pour un warehouse ITAD. Le stock bouge tous les jours — chaque receiving ajoute des assets, chaque outbound en retire, chaque échec en testing peut changer un statut sans déplacer une étiquette. Une fois par an, c’est trop tard pour rattraper la dérive. Les cycle counts répondent à ce problème par des comptages petits, fréquents et ciblés qui gardent la base de données alignée sur le rack.

Le cycle de vie

Un comptage démarre en draft : un périmètre (warehouse, zone ou rack), une affectation et un ensemble de positions. Le dialog de nouveau comptage prévisualise les codes de position du périmètre et les parcourt tous, donc une zone de 400 positions n’est pas représentée par ses douze premières lignes. Démarrer le comptage le fait passer en in progress ; l’opérateur scanne ou compte, incrémente les quantités, marque les positions comme comptées et signale tout ce qui ne correspond pas. Terminer le fait passer en completed, et une étape distincte approved accepte le résultat après revue. Un comptage qui n’aurait pas dû avoir lieu part en cancelled. Completed ne veut pas dire que les écarts étaient anodins — cela veut dire que la marche est finie. L’approbation, c’est le moment où quelqu’un se prononce.

Les écarts et leur résolution

Un écart est l’une de quatre choses : un asset missing là où le système l’attend, un asset found là où rien n’était attendu, un location mismatch, ou un quantity mismatch. Chacun se résout par l’une de cinq actions : mettre à jour l’emplacement, marquer l’asset comme manquant, enregistrer l’asset, corriger le comptage, ou l’ignorer avec une raison. L’observation d’origine et la résolution sont toutes deux conservées, pour qu’un auditeur voie ce que l’opérateur a vu et ce que l’équipe a décidé. Personne n’est prié d’écrire une dissertation sur un câble manquant. On lui demande une raison.

Le chiffre d’exactitude

Chaque comptage affiche son inventory accuracy : les positions du périmètre moins les écarts encore ouverts ou résolus autrement que par « ignorer », divisées par les positions du périmètre. C’est un chiffre par comptage, calculé à partir des positions de ce comptage — c’est-à-dire exactement le chiffre qui prédit si votre prochain outbound order vous réservera une surprise au dock.

La policy vit dans les Paramètres

Sous /settings/core/cycle-counts, votre équipe fixe le périmètre par défaut (warehouse, zone ou rack), le SLA par défaut en heures, le seuil d’auto-approbation en pourcentage d’exactitude, la fréquence des rappels en jours, l’obligation ou non d’une photo sur un écart, et la possibilité ou non d’ignorer un écart sans raison. Une bonne policy est assez stricte pour attraper les erreurs et assez humaine pour que les opérateurs puissent finir le travail.

Retrouver le comptage qu’il vous faut

La liste des cycle counts cherche et filtre sur tous les comptages du tenant avant d’afficher une page, et les tuiles du haut séparent les sessions, les comptages en cours, ceux en attente d’approbation et les écarts non résolus. Un comptage réconcilié par zone et par trimestre tient mieux dans la durée qu’un comptage parfait une fois par an, et la liste est faite pour que les comptages du trimestre se retrouvent quand l’auditeur les demande.