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

Index de l'article

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.

Simco Italia  Simco Italia