Choisir un logiciel de gestion des stocks auto-hébergé : tester les flux essentiels
Évaluez un logiciel de gestion des stocks à l’aide de scénarios réalistes, puis décidez si vous souhaitez gérer vous-même son déploiement ou recourir à un service géré. Ce plan de test pratique couvre les flux de travail, la traçabilité, les limites comptables, les rapports, les autorisations et les responsabilités liées au déploiement.
Commencez par les décisions de stock, pas par les noms de fonctionnalités
Une liste de fonctionnalités peut vous indiquer comment un fournisseur nomme une capacité, mais elle ne vous montre pas si le personnel peut s’en servir pour prendre les décisions auxquelles votre entreprise est confrontée. Commencez par dresser la liste des décisions que le système doit permettre de prendre : par exemple, déterminer si une commande peut être honorée immédiatement, où un produit est entreposé ou si un écart doit faire l’objet d’une enquête.
Avant de comparer les produits, notez vos exigences indispensables, les options utiles et les critères rédhibitoires. Associez chaque exigence à une tâche réelle et à la personne qui l’effectue. Ainsi, un ERP généraliste, un outil de gestion des stocks autonome et une application d’inventaire domestique ne seront pas considérés comme interchangeables au seul motif qu’ils emploient tous le mot « inventaire ».
HomeBox se décrit comme un « logiciel simple de gestion de l’inventaire domestique » et indique être open source (https://homebox.software/). Cette description ne permet pas à elle seule de savoir si le logiciel prend en charge des processus d’entrepôt tels que la préparation de commandes, les réservations ou les transferts de stock. Vérifiez si le produit documente les flux de travail professionnels dont vous avez besoin.
- Quelles décisions concernant les stocks le personnel doit-il prendre chaque jour ?
- Combien de sites, de zones de stockage, de types de produits et d’utilisateurs faut-il représenter ?
- Quelles étapes doivent être contrôlées dans le système, et lesquelles peuvent rester dans un autre outil ?
- Qu’est-ce qui vous ferait rejeter un produit : un processus impraticable, une documentation manquante ou une intégration requise non prise en charge ?
Cartographiez le véritable flux de travail, de la réception au retour
Dessinez le parcours d’un article en stock dans votre entreprise : réception, mise en stock, préparation, expédition, retours et transferts entre sites. Indiquez les passages de relais entre les membres du personnel et les moments où une quantité ou un emplacement doit changer. Partez de votre propre processus au lieu de supposer que toutes les entreprises suivent la même séquence.
Pour chaque étape, consignez les informations de départ, l’action, le résultat attendu et ce que l’opérateur doit pouvoir voir. Demandez au fournisseur de présenter cette séquence dans une instance de test ou de vous indiquer la documentation relative au comportement précis concerné.
Si le flux de travail nécessite plusieurs sites, testez le transfert dans son intégralité : où le stock se trouve au départ, ce qui se passe pendant son acheminement si cela s’applique à votre activité, et comment le site destinataire confirme son arrivée.
- Réception : votre test peut-il représenter la livraison et préciser ce qui a été accepté ?
- Mise en stock : le personnel peut-il trouver ou attribuer la destination requise par votre processus ?
- Préparation et expédition : un opérateur peut-il traiter une commande et confirmer ce qui est parti ?
- Retours : pouvez-vous représenter les marchandises retournées sans considérer automatiquement chaque article comme vendable ?
- Transferts : vos sites peuvent-ils rapprocher les quantités expédiées et reçues ?
Utilisez des quantités qui révèlent les cas limites
Un test avec un seul produit et une livraison parfaite est trop indulgent. Préparez un petit ensemble d’exemples tirés de votre activité réelle, avec les unités utilisées par le personnel et les quantités auxquelles il est confronté. Vérifiez si l’application représente ces quantités avec précision et si son comportement correspond aux règles documentées.
Utilisez un exemple de réception partielle : commandez une quantité, réceptionnez-en moins, puis vérifiez ce qui reste ouvert ou nécessite un suivi. Ne testez un produit acheté dans une unité et manipulé dans une autre que si cette conversion fait partie de votre activité. Si les commandes peuvent dépasser le stock disponible, testez séparément les réservations et les reliquats de commande ; ne supposez pas que l’un implique l’autre.
Consignez les résultats attendus avant la démonstration. Si le système affiche une quantité différente, demandez quel événement l’a modifiée et si le personnel peut retracer ce changement.
- Créez un exemple de livraison partielle et comparez les quantités restantes attendues à celles affichées.
- Ne testez les conversions d’unités que si votre activité en a besoin ; vérifiez les règles d’arrondi et de saisie.
- Vérifiez comment l’application représente le stock affecté à des commandes par rapport au stock disponible à la promesse de livraison, si cette distinction est importante pour vous.
- Testez une rupture de stock suivie d’un réapprovisionnement et confirmez le traitement de la demande en attente.
- Conservez une trace de test comprenant les données saisies, le résultat attendu et le résultat observé.
Testez les inventaires, les ajustements et les marchandises endommagées
Un inventaire n’est utile que si le personnel peut comparer ce qu’il constate aux enregistrements et résoudre les écarts de manière contrôlée. Effectuez un exemple de comptage tournant avec une quantité connue, puis introduisez un écart et observez ce que le système demande à l’opérateur.
Testez les marchandises endommagées, manquantes ou autrement inutilisables comme des cas distincts si votre processus les traite différemment du stock vendable. Demandez si le système peut représenter la distinction dont vous avez besoin, qui peut effectuer la modification et quel historique est conservé.
Les erreurs font partie du test. Effectuez un ajustement autorisé, puis demandez comment un utilisateur habilité peut le repérer, le corriger si nécessaire et conserver un historique compréhensible de ce qui s’est passé.
- Comptez une quantité connue et comparez-la à la quantité enregistrée.
- Saisissez un écart et examinez la quantité qui en résulte ainsi que l’historique des transactions.
- Testez le processus appliqué aux marchandises endommagées et vérifiez s’il correspond à vos propres règles de traitement.
- Demandez quelle procédure de correction ou d’annulation est documentée en cas de saisie erronée.
- Si cela fait partie de vos exigences métier, vérifiez si un utilisateur peut savoir qui a effectué une modification et quand.
N’exigez une traçabilité que là où l’entreprise en a besoin
Le suivi des lots, des numéros de série et des dates de péremption peut être important si vous devez identifier certains lots, des articles individuels ou des dates. Il ajoute aussi du travail à la réception, au stockage et à l’exécution des commandes. Avant d’en faire des exigences universelles, déterminez quelles formes de traçabilité vos produits ou procédures nécessitent réellement.
Pour un produit concerné, créez une réception de test avec l’identifiant ou la date utilisés dans votre processus. Suivez-le au cours du stockage, d’une expédition et d’un scénario de retour ou d’enquête. Vérifiez que le personnel peut retrouver l’historique requis au moment où il en a besoin.
Si la traçabilité n’est pas nécessaire pour vos marchandises, consacrez le temps d’évaluation aux flux de travail qui comptent vraiment. Une fonctionnalité inutile pour votre activité ne devrait pas peser davantage qu’un processus de base que l’équipe ne peut pas réaliser de manière fiable.
- Déterminez quels produits nécessitent un numéro de lot, un numéro de série ou une date de péremption, et pourquoi.
- Testez le suivi de l’identifiant, de la réception jusqu’au processus de sortie ou de traitement d’exception concerné.
- Vérifiez si le personnel qui en a besoin peut retrouver l’information.
- Consignez toute solution manuelle de contournement et le risque qu’elle entraîne.
Distinguez les mouvements de stock des exigences comptables
Les enregistrements opérationnels du stock et la valorisation des stocks répondent à des questions liées, mais différentes. Les opérations peuvent avoir besoin de savoir ce qui est physiquement présent, engagé ou situé à un emplacement particulier. La finance peut également avoir besoin de valeurs, de règles de calcul des coûts, d’écritures et de contrôles de clôture. Ne partez pas du principe qu’un système qui répond à l’un de ces ensembles de besoins répond aussi à l’autre.
Demandez à votre responsable financier ou à votre comptable de définir les exigences comptables importantes, notamment les enregistrements qui doivent être transmis au système comptable et la personne qui en est responsable. Testez ensuite le transfert avec un exemple représentatif. Vérifiez si l’application envisagée documente le comportement précis en matière de valorisation ou de comptabilité dont vous avez besoin.
Un outil de gestion des stocks autonome peut mieux convenir lorsque le besoin porte principalement sur le contrôle des stocks et que la comptabilité peut rester dans un autre système déjà en place. Un ERP peut mériter une évaluation lorsque l’entreprise a besoin de relier les stocks à d’autres processus opérationnels ou financiers. Le bon choix dépend de la couverture vérifiée des flux de travail, pas seulement de la catégorie du produit.
- Dressez la liste des données de stock nécessaires aux opérations et des données de valorisation ou d’écriture nécessaires à la finance.
- Définissez le système de référence pour chaque enregistrement.
- Testez un transfert de données réaliste et déterminez comment les erreurs sont rapprochées.
- Demandez la documentation relative à toute méthode de calcul des coûts, de valorisation ou à tout comportement comptable requis.
Évaluez les rapports, les exportations et les intégrations en fonction des décisions
Un rapport est utile lorsqu’il répond à une véritable question opérationnelle. Commencez par nommer les décisions à prendre — par exemple, déterminer ce qui doit être réapprovisionné ou où subsiste un écart — puis demandez au fournisseur de présenter le rapport précis ou une méthode documentée pour obtenir l’information.
Vérifiez le résultat à l’aide de données de test que vous comprenez. Confirmez la signification des quantités, des emplacements et des statuts, ainsi que l’adéquation des filtres aux méthodes de travail du personnel. Si votre équipe dépend de feuilles de calcul ou d’un autre système, exportez un exemple puis vérifiez que les champs et les identifiants sont utiles au processus destinataire.
Pour les intégrations, décrivez le sens de circulation des données, les événements qui déclenchent les mises à jour et la manière dont sont gérés les transferts en double, retardés ou échoués. Notez comme questions en suspens tout comportement qui reste flou.
- Choisissez trois questions opérationnelles et indiquez le rapport ou l’exportation qui devrait répondre à chacune.
- Comparez les totaux des rapports aux transactions de test sous-jacentes.
- Vérifiez si les champs exportés peuvent être associés aux articles, aux commandes et aux emplacements.
- Consignez qui est responsable des intégrations, de la gestion des échecs et des rapprochements.
Distinguez l’auto-hébergement de l’hébergement géré
Dans un déploiement auto-hébergé et autogéré, votre entreprise exploite l’application et l’infrastructure qui l’entoure. Dans un modèle d’hébergement géré, un fournisseur exploite le service sur son infrastructure cloud. Ce sont deux modèles distincts : comparez-les en déterminant qui s’occupe de l’installation et de l’exploitation du service, quelle assistance est disponible et quelles responsabilités restent à la charge de votre entreprise.
Avec un déploiement auto-hébergé et autogéré, prévoyez qui assurera la maintenance de l’environnement et prendra en charge les tâches opérationnelles telles que les mises à jour, les accès, les sauvegardes et la restauration. Avec un hébergement géré, demandez précisément quelles tâches le fournisseur effectue et comment vous pourrez gérer vos données, vos utilisateurs et vos besoins de restauration. L’hébergement géré peut réduire le travail lié à l’infrastructure, mais votre entreprise reste responsable des décisions concernant les données et les accès.
Airbip propose un déploiement géré pour les applications de son catalogue public : les instances applicatives fonctionnent sous forme de charges Docker sur les serveurs cloud d’Airbip, qui automatise le routage et les certificats TLS par l’intermédiaire de Traefik et Let’s Encrypt. Le service comprend également des vérifications DNS, la gestion du cycle de vie des services et des sauvegardes quotidiennes, hebdomadaires et mensuelles configurables. Ces informations décrivent le déploiement géré, pas les capacités de gestion des stocks d’une application particulière. Vérifiez séparément si une application répondant à vos besoins figure au catalogue et confirmez les responsabilités applicables au service choisi.
- Déterminez qui sera responsable de la maintenance courante, des accès utilisateurs, des sauvegardes et de la restauration pour chaque option de déploiement.
- Demandez quelles données peuvent être exportées et comment vous pourriez en récupérer l’accès si vous changiez de fournisseur.
- Confirmez quelles tâches liées à l’infrastructure sont prises en charge par un service géré et lesquelles restent à la charge de votre équipe.
- Comparez la charge opérationnelle au niveau de contrôle dont votre entreprise a besoin.
Questions fréquentes
L’auto-hébergement et l’hébergement géré sont-ils la même chose ?
Non. Dans un déploiement auto-hébergé et autogéré, votre entreprise exploite l’application et l’infrastructure. Dans un hébergement géré, le fournisseur exploite le service sur son infrastructure ; il faut alors vérifier les tâches qu’il prend en charge et celles qui restent à votre charge.
Que signifie la description de HomeBox pour une entreprise qui évalue un outil d’entrepôt ?
HomeBox se présente comme un logiciel simple de gestion de l’inventaire domestique et open source. Cette description ne confirme pas la prise en charge de flux de travail d’entrepôt : il faut donc vérifier séparément chaque processus requis.
Comment traiter une exigence dont le comportement n’est pas documenté ?
Consignez-la comme non résolue, demandez une réponse écrite précise et, dans la mesure du possible, reproduisez le comportement dans une instance de test. Ne considérez pas le nom d’une fonctionnalité comme une preuve qu’elle répond à votre besoin.
Sources et lectures complémentaires
- HomeBox — HomeBox
- Docker documentation — Docker
- Traefik documentation — Traefik Labs
- Let’s Encrypt documentation — Internet Security Research Group