Numéro 3)

Recevez chaque fin d'après-midi, un récapitulatif des infos supply chain du jour.

Article extrait des Logiguides de GROUPE GCL, cabinet de conseil en logistique.

Aujourd’hui, de plus en plus d’entreprises, dans toutes les industries, installent un nouveau WMS (Warehouse Management System) ou le mettent à jour afin de bénéficier d’un système efficace et convivial.

Chacune de ces entreprises a des buts communs : optimiser les déplacements et l’espace, obtenir des opérations de distribution performantes, disposer d’informations en temps réel, réduire ses coûts d’opération pour finalement offrir le meilleur service à la clientèle sur leur marché. Pour assurer une transition en douceur, la plateforme et l’application doivent être testées à plusieurs niveaux.

Pourtant, cette mise à l’épreuve n’est pas toujours bien réalisée et les conséquences sont souvent dramatiques (augmentation significative du coût du projet, perte de confiance et rejet du projet par les utilisateurs, baisse significative du taux de service et mécontentement de la clientèle, etc.).

Pour les éviter, il suffit d’adopter une démarche pragmatique et de s’y tenir. Nous vous proposons une approche en étapes qui vous aidera à maintenir votre cap.

1. Préparation des tests

La préparation des tests d’un projet d’implantation initiale est différente de celle d’une montée de version (mise à jour). L’implantation initiale implique systématiquement toute l’entreprise puisque qu’elle touche : les processus d’approvisionnement et de distribution, les flux transactionnels avec l’ERP en place et, parfois, l’introduction d’une nouvelle plateforme technologique. Dans ce cas, les tests se préparent dès la phase d’analyse fonctionnelle par l’identification des flux transactionnels et de marchandises, l’élaboration des processus et leur découpage en tâches élémentaires, l’identification des règles de gestion inhérente à chaque tâche, la conception de la plateforme technique (serveurs, logiciels, communication, outils de collecte de données, imprimantes, etc.); autant d’éléments dont il faudra vérifier les fonctionnements individuels et conjugués avant de démarrer.

Une montée de version peut parfois ressembler à une implantation initiale dans le cas d’un retard de version (plusieurs versions à rattraper) ou dans le cas d’une migration de plateforme technologique avec le même WMS. Cependant, si votre application est à jour et que le projet consiste à implanter la nouvelle version sans modifier la couverture fonctionnelle en place, vous devrez réaliser un test de non-régression. Ce test se base sur les cahiers de tests rédigés lors du projet initial et maintenus à jour au fil des évolutions de l’application. Si ces cahiers de tests n’existent pas ou sont incomplets, vous devrez les élaborer, car ils sont les seuls garants de la réussite de votre projet. Les cahiers de tests sont des documents qui listent de façon exhaustive les cas qui composent les tâches, les processus et les flux. Ils se composent des scénarios de tests et de la description des jeux de données requis pour valider chaque cas. Globalement, vous devez avoir des cahiers de recettes pour la plateforme technique et pour l’application (WMS + interfaces ERP et TMS).

Un environnement de test est impératif. Il se composera d’une plateforme technique dont les spécifications techniques et fonctionnelles sont identiques à la plateforme de l’environnement de production (mêmes technologies, mêmes versions des logiciels, mêmes équipements périphériques, même paramétrage, mêmes données de base). Les sessions de tests doivent être cycliques et basées sur la restauration des jeux de données définis dans les cahiers de tests à chaque installation de correctifs.

2. Tests unitaires

Les tests unitaires ont pour objectif de vérifier chaque élément individuellement sans considérer l’ensemble. Par exemple, le test d’une interface en particulier déclenchée manuellement ou le test de validation des rangements en RF ou le test d’une imprimante, etc. Ces tests sont fragmentés et pas nécessairement synchronisés. Lorsque tous les éléments sont individuellement conformes aux cahiers de tests, il est temps de passer à la phase « d’assemblage » de ces éléments pour effectuer les tests d’intégration.

3. Tests d’intégration

Les tests d’intégration ont pour objectif de vérifier le fonctionnement d’ensembles logiques (flux transactionnels et de marchandises). Par exemple, le flux d’approvisionnement de la commande achat à la localisation du stock dans l’entrepôt. Le test commencera donc dans l’ERP, passera par les interfaces vers le WMS, puis dans les processus de planification, de réception, de rangement dans le WMS, puis de retour des transactions vers l’ERP par l’interface, etc. Pour compléter ces tests, les résultats obtenus devront être conformes aux cahiers de tests sur la totalité du flux. Au delà de la qualité obtenue, ces tests d’intégration peuvent avoir un aspect légal dans le cas où une partie du flux est traitée par un prestataire. Dans ce cas, il est essentiel de contraindre les équipes à des validations de tests à l’aide d’un procès verbal de tests.

4. Tests de non-régression

Les tests de non-régression sont identiques aux tests d’intégration. La différence réside dans la formulation. Il s’agit de vérifier que le système est toujours en conformité avec les cahiers de tests de la version précédente à périmètre fonctionnel équivalent. Par conséquent, vous devez dérouler l’ensemble des cahiers de recette pour vous en assurer.

5. Tests de stress ou de masse

Une fois que le système est conforme au niveau des tests d’intégration, les tests de stress permettent de valider le niveau et la stabilité des performances dans diverses situations (sous-utilisation, utilisation normale ou extrême). Par exemple, votre système est conçu pour le traitement de 5 000 commandes par jour avec une équipe de 20 opérateurs (utilisation dite « normale »). Cependant, votre activité est saisonnière et vous pouvez monter à 10 000 commandes par jour avec 50 opérateurs en pleine saison. Vous devrez tester que votre système accepte cette surcharge sans dégradation de sa performance (aux niveaux technique et fonctionnel).

6. Tests fonctionnels

Les tests fonctionnels ont pour objectif de vérifier l’autonomie des opérateurs (formation, accès au système, etc.) et que les postes de travail sont opérationnels. C’est un peu une répétition générale. Ce test peut sembler superflu, mais il est essentiel. Il permet aux opérateurs d’être impliqués dans le projet, de créer une relation de confiance avec les super-utilisateurs de l’équipe de projet, de régler les derniers petits problèmes avant le démarrage et, par conséquent, d’avoir des acteurs souriant le jour du démarrage et surtout, des clients satisfaits dans les jours qui suivent.

Martin Lalumière
Conseiller, Groupe GCL
www.gclgroup.com

‹ LOGIGUIDE précédent

LOGIGUIDE suivant ›

Groupe GCL Europe, Conseil logistique

13 avenue René Boylesve
75016 Paris
Internet : www.gclgroup.com

Rubriques connexes :
- les éditeurs de WMS référencés dans l’annuaire du site
- l’article sur les Warehouse Management System (WMS)