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

Index de l'article

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 !
Simco Consulting 26-28 Rue de Londres 75009 Paris France - Tél. +33 01 78 42 35 32 - simco@simcoconsulting.fr

Simco Italia  Simco Italia