LE MAGASIN AUTOMATIQUE, UN SYSTÈME COMPLEXE : COMMENT CONCEVOIR, PLANIFIER ET RÉALISER LES TESTS QUI CONDUISENT À SON ACCEPTATION FINALE

Index de l'article

Pour l’essentiel, les vérifications à effectuer pour l’acceptation concernent :

  1. la quantité/conformité de ce qui est fourni : autrement dit, tous les composants prévus par le projet doivent avoir été installés selon l’agencement convenu, avec tous les raccordements faits dans les règles de l’art, avec le bon niveau de lubrifiants, avec une concordance totale des matériaux et finitions avec les spécifications techniques, etc., et dotés des accessoires/pièces détachées et des périphériques (HMI - Human Machine Interface ou Interface Homme-Machine) ;
  2. toutes les fonctionnalités opérationnelles des équipements et du logiciel de pilotage ;
  3. les performances de chaque équipement et de certains sous-systèmes importants ;
  4. la performance globale du système vu d’une façon holistique, en référence à la capacité de ce système d’absorber un ensemble de flux concomitants dans des délais compatibles avec le niveau de service cible que l’on souhaite obtenir : ces performances sont les plus difficiles à spécifier et surtout à vérifier sur site et elles sont fréquemment inférieures à la somme des performances des différents éléments ;
  5. la fiabilité globale du système qui est aussi un concept plus compliqué qu’on pourrait le croire au premier abord.

Comme prévu, pour effectuer correctement et de manière incontestable les vérifications indiquées ci-dessus, les paramètres concernant les matériels, les fonctions et les performances attendues doivent avoir été en temps utile (c’est-à-dire lors du contrat) définis et précisés avec soin.

Par exemple, dans le cas des performances, les KPI de référence (Key Performance Indicator ou Indicateur Clé de Performance) devront avoir été identifiés avec leurs métriques et les valeurs minimales d’acceptabilité, par ailleurs en ayant fixé les conditions dans lesquelles les tests seront effectués.

Il va alors de soi que sans un projet bien détaillé et bien documenté, il deviendra ensuite très difficile d’avoir précisément à l’esprit toutes les performances et fonctionnalités que l’on veut obtenir du “système d’entreposage” et, par conséquent, la phase de test et de réception peut faire l’objet de discussions interminables avec le fournisseur.

Pour en revenir aux considérations sur les opérations d’acceptation de ce qui est installé, je dirai à propos du point 1 que ça ne vaut pas trop la peine de s’y étendre ici : c’est évidemment une opération importante qui consiste à relever sur le site le nombre et le type de composants installés, vérifiant leur disposition dans les bâtiments, contrôlant les certificats relatifs aux matériels, etc.

En ce qui concerne le point 2, la condition nécessaire pour pouvoir vérifier toutes les fonctionnalités est d’avoir bien défini au préalable dans un document spécial (en général intitulé “Spécifications Fonctionnelles” ou “Users Requirements Specifications - URS”) ce que chaque élément du système et le système dans son ensemble doivent être capables de faire, en référence non seulement aux tâches opérationnelles mais aussi aux fonctions de contrôle et de diagnostic.

La vérification des fonctionnalités - surtout celle du logiciel - sera d’autant plus rapide et d’autant plus efficace que davantage de travail aura été fait dans les phases qui précèdent le chantier, c’est-à-dire en laboratoire, en faisant particulièrement référence aux essais de réception en usine (FAT) déjà cités.

De plus, au cours des dernière années se profile comme une véritable et nouvelle méthode de référence (“golden standard”) la pratique de ladite mise en service virtuelle (“virtual commissioning”) qui permet d’avoir un “jumeau numérique” de l’installation dans un environnement virtuel où peut être directement inclus le logiciel que l’on entend tester (logiciel de gestion d’entrepôt WMS et programme PLC), émulant ainsi de manière détaillée les dispositifs du site. La promesse de cette technique est de pouvoir réduire de manière significative les temps d’exécution sur place de la mise en service de l’installation et des tests d’acceptation.

La phase 3, c’est-à-dire la vérification des performances de chaque élément du système (par exemple, un chariot élévateur, une filmeuse, un déviateur à rouleaux/chaînes, etc.) peut sembler apparemment simple, mais requiert aussi une préparation minutieuse.

Tout d’abord, il serait idéal d’effectuer cette phase et les suivantes avec de vraies unités de charge, avec un produit valable ou placebo et d’avoir ces unités de charge à disposition en temps utile dans une quantité suffisante. Dans la réalité, surtout quand il s’agit de produits coûteux ou frais ou avec beaucoup de variantes au point de mettre à rude épreuve le composant à tester, cela peut être un problème auquel il faut penser à temps parallèlement à la production ou à la chaîne d’approvisionnement.

Outre le produit à manutentionner, la réalisation de ces tests demande aussi de se doter du personnel nécessaire et des utilités permettant de déplacer les unités de charge depuis et vers le système automatique. En général, sauf négociations contraires lors de la phase contractuelle, ces ressources doivent être fournies par le client.

Si pour certains équipements, il peut être suffisamment simple de définir le cycle d’essai, pour d’autres appareils - et nous faisons notamment allusion aux transstockeurs et aux miniloads - la chose peut nettement être plus compliquée, surtout en présence de rayonnages à profondeurs multiples et/ou avec des outils de préhension multi-charges. Beaucoup de ces cas ont été fort heureusement normalisés par la F.E.M. (Fédération Européenne de la Manutention - https://www.fem-eur.com/about/), comme par exemple la norme FEM 9.851 “Vérification du rendement des transstockeurs”.

Bien que la F.E.M. soit l’association des principaux fabricants et intégrateurs de systèmes logistiques et donc qu’elle fournisse en quelque sorte une vision partisane, dans la pratique, ces normes sont acceptées comme référence par tout le monde, soit pour simplifier les références des performances, soit pour définir des plages de tolérance acceptables de construction/réalisation, ce qui permet ensuite une intégration plus simple des machines et des rayonnages provenant de divers fournisseurs.
Bien entendu, rien n’empêche aussi de pouvoir définir dans le contrat la performance de référence d’une manière plus adaptée au client (au cas par cas).

Il est très important d’avoir convenu avec le fournisseur la présentation du formulaire à utiliser test après test afin de garder une trace contresignée du déroulement de l’essai et de son résultat, avec une référence particulière aux champs à remplir en cas de mauvais résultat, enregistrant les causes possibles de l’échec et ce qui est convenu entre le fournisseur et le client pour la mise au point successive de l’appareil et la nouvelle exécution de tests.

Les phases 1 à 3 donneront certainement lieu à une liste de réserves (dite “punch list”) au vu des différentes vérifications effectuées, cette liste doit constamment être tenue à jour : ces réserves ne seront pas nécessairement un obstacle pour l’avancement des tests, ni même pour l’utilisation du bien, mais elles devront être totalement levées avant l’acceptation finale.

La phase 4 relative au test des performances du système complet - à faire pour des raisons évidentes après avoir vérifié l’adéquation de chaque équipement et de chaque sous-système - est malheureusement à la fois la plus importante et la plus difficile (je dirai même parfois extrêmement difficile) à mettre en pratique.

En premier lieu, il faut avoir soigneusement défini ce qu’on entend par “performances du système complet”, ce qui renvoie inévitablement à un projet minutieux. En fait, dans un système complexe de manutention de marchandises, il peut y avoir de nombreux, voire de très nombreux flux concomitants (entrées, sorties pour expédition, sorties vers les zones de prélèvement et/ou de préparation, transfert de marchandises, abaissement des palettes, contrôles des marchandises en stock) avec des profils de flux qui varient dans le temps.

Dans ce contexte, le fait d’avoir réalisé un modèle détaillé de simulation dynamique (outre bien entendu la production d’un bon projet incluant même les aspects logistiques et de gestion) aide aussi à se fixer des objectifs clairs et concrets sur de nombreux KPI dynamiques, spécialement ceux liés aux délais minimums nécessaires pour garantir le niveau de service souhaité : les résultats de la simulation peuvent donc devenir de véritables références à vérifier sur site.

Même lorsque le cadre de référence du test est clair, il peut y avoir des difficultés parfois insurmontables dans la gestion pratique de la “coordination” des événements qui conduit à la reconstruction sur site de ce cadre. En effet, il faut prévoir avec soin les marchandises en magasin, le niveau des entrées, celui des sorties et toutes les ressources qui servent à réaliser sans encombre ces niveaux, le tout lors de la phase initiale de l’installation où souvent les machines et les personnes ne sont pas encore “mûres” et “rodées” pour tout faire fonctionner au mieux.

Tout problème même minime et non nécessairement occasionné par l’installation en elle-même (par exemple, des palettes qui se mettent de travers, une absence de lecture des étiquettes code-barres, etc.) peut entraîner la nécessité de repartir de zéro pour ne pas affecter les résultats du test et donc entraîner la tâche pénible de tout ramener dans les conditions initiales.

Outre la complexité intrinsèque de la chose (déjà mise en évidence), il convient de dûment prendre en compte un laps de temps suffisant pour effectuer ces tests.

C’est pourquoi on choisit parfois (ou l’on est contraint) de ne pas faire de “répétition générale” englobant vraiment tout et l’on se contente de tester plus ou moins de larges groupes d’équipements (sous-systèmes) qui, si possible, interfèrent peu les uns avec les autres afin de garantir la pertinence de ces tests partiels.

Une autre approche possible consiste à tester les performances de chaque élément du système, puis d’insérer ces performances (et les logiques de gestion du logiciel WMS/ACS et peut-être même des taux raisonnables de fiabilité - MTBF/MTTR (Mean Time Between Failures / Mean Time To Repair ou temps moyen entre défaillances / temps moyen jusqu’à réparation) dans un modèle de simulation dynamique à l’échelle 1:1 et de vérifier avec ce modèle - autrement dit “in vitro” - les performances qui en résultent.

La question des performances globales du système peut être encore plus compliquée, ou plutôt la détermination des responsabilités en cas de non-atteinte des performances cibles en vertu de la stratégie d’achat que le client a décidé d’adopter et qui - comme on peut facilement le deviner - conditionne aussi les essais à réaliser.

En simplifiant un peu, la stratégie d’achat peut prévoir de se tourner vers un interlocuteur unique - qui intègre les différents composants du système et se rend responsable de tout le résultat final - ou alors aller sur le marché pour acheter les composants distincts, puis veiller à les intégrer de manière plus ou moins directe.

La première option, à première vue plus coûteuse (et l’on pourrait en parler longuement) montre dès le départ un responsable précis et bien défini (le dénommé intégrateur de systèmes - "system integrator" - qui, parfois, ne produit rien pour son propre compte si ce n’est le logiciel) non seulement pour les performances de chaque dispositif, mais aussi et surtout pour les performances du système.

Il va sans dire que, d’un point de vue théorique, cette option est une grande simplification sur la voie de l’acceptation du système ainsi que des responsabilités quant aux performances de ce système, en mesure aussi de rendre moins épineux certains aspects “politiques” qui mènent vers cet objectif (nous y reviendrons plus loin).

Vice-versa, la seconde stratégie - celle qu’on pourrait gentiment qualifier de stratégie du “morcellement” - conduit à quelques économies sur les coûts d’achat initiaux en évitant l’intermédiation de l’intégrateur de systèmes, mais conduit aussi à d’importantes complications dans la phase du projet et de l’acceptation finale, ces mêmes complications (choix des sous-traitants, parfaite intégration physique et fonctionnelle des fournitures, gestion du chantier, etc.) pour lesquelles l’intégrateur de systèmes exige à juste titre une rémunération afin de les traiter.

Soit dit en passant, avec le “morcellement”, ces coûts ne sont pas réellement évités par le client final, ils risquent seulement d’être moins évidents, surtout s’ils sont directement soutenus par du personnel interne ou s’ils sont la compensation de sociétés de conseil et d’ingénierie.

Simco Italia  Simco Italia