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

Les magasins automatiques même les plus essentiels, sont sans aucun doute des systèmes complexes.

Leur complexité réside dans la grande quantité de composants présents dans ce qui est fourni, comme par exemple les machines pour le stockage et la mise en place des unités de charge (transstockeurs, shuttles, miniloads, etc.), les dispositifs de convoyage en tête de ligne (convoyeurs à rouleaux/à chaînes, bandes transporteuses, navettes, convoyeurs monorails, etc.), les trieurs performants, les baies de prélèvement avec la logique du “produit vers l’homme”, des zones de prélèvement équipées avec “points de décision” et outils d’aide au prélèvement, des machines spéciales (dépalettiseurs/palettiseurs, banderoleuses, étiqueteuses, formation de colis d’expédition, lignes de fermeture des colis), robots, fins de ligne de contrôle/confection des colis et l’on pourrait continuer longtemps, sans oublier bien entendu les éléments fondamentaux tels que les divers logiciels qui pilotent les stratégies et procédés pour planifier et exécuter les missions (selon quelques-uns des termes les plus courants : Warehouse Execution System (WES), Warehouse Management System (WMS), Automation Control System (ACS), System Control and Data Acquisition (SCADA), etc.).

Vous aurez noté que les rayonnages n’ont pas été cités dans la liste - éléments cruciaux pour la bonne réussite du projet - mais, dans ce contexte, nous aimerions les laisser de côté car notre objectif est de considérer les aspects “dynamiques” des systèmes d’entreposage.

Chaque élément mentionné a ses propres subtilités de fonctionnement, de performance et d’utilisation.

Cependant, les magasins automatiques sont aussi - et peut-être surtout - des “systèmes complexes” quant à la manière dont les divers composants interagissent entre eux dans le temps, en fonction de la charge de travail à laquelle ils sont soumis, extrêmement “tendue” et variable d’un instant à l’autre : tout cela débouche sur la difficulté objective de prévoir les performances globales de tels systèmes, des performances qui risquent souvent de se révéler insatisfaisantes, inférieures à ce qui est prévisible si l’on tient compte des performances de chaque machine.

En admettant que l’on ait relevé puis réglé le défi de la production d’un “bon projet”, bien sûr à vérifier et affiner au moyen d’une simulation dynamique, il reste face à nous l’astreignante nécessité d’être à même de démontrer avec des tests et des vérifications spécifiques que le magasin réalisé est vraiment conforme au projet préalablement élaboré ainsi qu’aux critères de fonctionnement et de performance qui doivent avoir été précédemment spécifiés pour pouvoir accepter sereinement le passage du magasin ("handover") du fournisseur au client qui devra l’utiliser pendant des années.

La première chose fondamentale (apparemment évidente, mais en fait trop souvent négligée) est d’avoir précisément et complètement défini les critères ci-dessus : en effet, cela fait partie du déjà cité “bon projet” auquel les entreprises doivent faire face avec l’appui de sociétés de conseil qualifiées et riches d’une expérience “transversale”, c’est-à-dire relative à toutes les phases du projet, jusqu’à la mise en service d’installations complexes.

Si l’on admet avoir abordé avec succès la phase des essais de réception en usine (les dénommés Factory Acceptance Test - FAT) de chaque élément (lorsque c’est faisable) et surtout du logiciel avant de les transférer sur site, il reste encore quelques défis assez ardus avant de pouvoir dire qu’on est certain d’accepter sans hésitation la livraison du système qui passe ainsi des mains du fournisseur à celles de l’utilisateur final, étant à même de fournir les performances requises.

Le thème de l’acceptation finale est précisément celui que nous voulons approfondir dans cet 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.

Le “morcellement” peut être réalisé de mille façons différentes : une des plus faciles et des plus rentables, quoique non dépourvue de difficultés et de risques, consiste à acheter séparément les rayonnages (surtout s’ils sont économiquement importants comme dans le cas des solutions autoportantes) et ce que nous pouvons qualifier d’“automatisation”, à savoir les équipements plus le logiciel.

Dans ce cas, aux fins de notre propos, nous sommes de fait dans une situation totalement analogue à celle de l’intégrateur de systèmes. Ou presque, car il est quand même possible qu’un dysfonctionnement des machines au service des rayonnages soit provoqué par un mauvais montage de ces rayonnages, avec toutes les difficultés pour identifier le vrai “coupable”.

Parfois cependant, le “morcellement" peut se faire de manière plus poussée jusqu’au cas le plus complexe - que nous traiterons à part du point de vue de l’acceptation finale - où le client décide d’acheter séparément les “objets en fer” (convoyeurs, transstockeurs, etc.) et le logiciel (WMS).

Ce choix n’est pas toujours dicté par des vecteurs d’économies d’argent : il peut être la conséquence de lignes directrices de l’entreprise qui imposent le logiciel WMS (par exemple, SAP EWM) et peut-être aussi son implémentation pour avoir partout des instruments et des processus homogènes.

Comme c’est facile à deviner, le fait d’avoir le “cerveau” (le logiciel) et les “muscles” (l’automatisation) fournis par deux intervenants différents implique une difficulté pratique significative dans l’attribution des responsabilités d’éventuelles défaillances de la performance du système ; la seule façon de contourner l’obstacle est de réussir à mettre tout le monde autour d’une même table dès le stade du projet et de coordonner le développement synergique des différents composants. Étant entendu qu’ensuite au final, il y aura toujours un terrain très "glissant”, celui de l’attribution des responsabilités sans parler de la situation désagréable et non souhaitée de la part du fournisseur de l’automatisation qui verra son installation utilisée pendant des semaines ou des mois - idéalement déjà parfaitement opérationnelle en mode semi-automatique - uniquement pour tester le logiciel WMS de quelqu’un d’autre, avec tout ce que cela comporte en termes d’usure dans une période où la garantie n’a pas encore commencé.

Dans ces cas, la figure de celui que l’on pourrait qualifier d’architecte du système devient primordiale, ce dernier - dans certaines limites - doit se porter garant du schéma stratégique de ce système où les caractéristiques et les limites du logiciel WMS et de l’automatisation sont prises en compte. Une fois encore, l’outil fondamental pour vérifier des situations aussi complexes dès le stade du projet reste la simulation dynamique.

Le rôle d’“architecte du système” peut être dûment tenu par un consultant logistique expérimenté, surtout dans la mesure où il sera capable de gérer personnellement la simulation dynamique.

Cependant, la performance globale du système ne peut pas faire abstraction d’une vérification fructueuse même si la fiabilité de ce système est suffisamment élevée : en effet, il ne sert à rien d’avoir un système absolument remarquable quand il fonctionne, mais qui ensuite est souvent hors service.

On considère toutefois que la fiabilité du système ne peut pas être élevée dans les phases initiales du fonctionnement de systèmes aussi complexes : empiriquement et même intuitivement, on sait que celle-ci augmente au fil du temps durant lequel il faut affiner les points en suspens et durant lequel les utilisateurs et les manutentionnaires améliorent leurs aptitudes à gérer le système.

Par contre, il est concevable que le client veuille commencer à utiliser le plus vite possible à des fins commerciales le coûteux investissement fait et il pourrait donc ne pas être disposé à attendre trop le moment où sera mesurée la fiabilité. De surcroît, la fiabilité ne peut s’affiner qu’avec une véritable utilisation du système, avec des flux et des situations qui pourront “solliciter” tous les cas possibles que pas même le plan d’essai le plus complet ne peut considérer.

Voilà pourquoi les normes F.E.M. (plus précisément la norme 9.222) invitent à ne vérifier en phase 4 - au terme de laquelle se situe généralement ledit “handover” du système, c’est-à-dire la remise du système du fournisseur au client et le commencement de la période de garantie - que la présence d’une disponibilité élevée, mais pas très élevée (par exemple, 80 %) afin que le client commence à utiliser l’installation avec suffisamment de confiance, car il est aussi à espérer qu’au début l’installation ne devra pas être à 100 % de rendement en permanence, sachant que l’objectif final de fiabilité (par exemple, 98%) ne pourra être atteint qu’en l’espace de quelques mois d’utilisation intense de l’installation en y effectuant l’entretien approprié.

Ainsi la phase 5 - la vérification de l’atteinte de la disponibilité objective prévue par le contrat - ne se produira qu’à une date ultérieure, relativement éloignée de la remise de l’installation (par exemple, 6 mois). Au cours de cette période, le fournisseur sera tenu de résoudre tous les éventuels points en suspens.

En passant sur le plan technique et organisationnel, la vérification du taux de fiabilité n’est pas non plus une opération exempte de difficultés et de complications. C’est peut-être l’une des plus compliquées.

Les difficultés concernent :

• la détermination d’un modèle de fiabilité cohérent et partagé, divisant le système en sous-systèmes entre eux en série et en parallèle, identifiant les éventuelles redondances et tampons qui rendent inefficaces d’éventuelles indisponibilités localisées, évaluant le taux de disponibilité de chaque sous-système en fonction de critères rationnels (par exemple, le pourcentage de flux géré) ;
• la conduite pratique du test et surtout la collecte de données, avec une référence particulière à la spécification de qui sera le responsable d’une panne déterminée (automatisation, unités de charge, logiciel WMS, autre chose) et quelle sera la durée de remise en état de cette panne : dans les systèmes logistiques étendus géographiquement et/ou composés de nombreux éléments, il peut être vraiment difficile de suivre les événements.

Dans la pratique, même si tout semble facile à considérer de manière “scientifique”, surtout si l’on est soutenu par des logiciels avancés SCADA qui fournissent de bonnes indications de diagnostic sur la cause de la panne, on finit souvent par en pâtir suffisamment.

Les causes typiques de discussion sont les suivantes : quelle part de la durée d’une panne est imputable au fournisseur du système et quelle part est imputable au client qui n’a peut-être pas mis à disposition un nombre adéquat de manutentionnaires formés ou qui n’a pas de parc adéquat de pièces détachées chez lui ? Quand un blocage est-il imputable au fournisseur et quand est-il imputable au client, peut-être, pour avoir adopté des unités de charge non adaptées à la manutention automatique (par exemple, des palettes cassées) ?

De telles discussions interrompent la continuité du test en l’allongeant et parfois en le rendant peu significatif, créant quelquefois une atmosphère conflictuelle et peu constructive, car il y a aussi habituellement des aspects financiers liés à la constatation de la disponibilité finale.

Conclusions

La conduite correcte de la réalisation et du démarrage de systèmes complexes comme ceux du stockage et de la manutention automatisée ne peut pas faire abstraction d’une bonne “ingénierie” et planification et exécution de toutes les opérations de test et vérification qu’il convient d’accomplir.

Pour ce faire, on a besoin de capacités professionnelles avérées et d’expérience ainsi que de l’implication profonde du fournisseur qui peut être dûment amené à soumettre au client et à son consultant logistique, pour commentaires et acceptation, ses propres listes de tests.

En tout cas, Il n’est pas souhaitable d’ignorer le problème, ni même de trop le repousser jusqu’à parvenir aux abords des tests eux-mêmes.

La prévention fournie par un bon projet structuré est le seul remède vraiment efficace pour traiter et résoudre cette phase fondamentale avec le maximum de sérénité et d’efficacité.

Et pour en savoir plus ? contactez-nous !