Dossiers > WMS / TMS > Comment réussir son projet ? > Entretien A-SIS



WMS / TMS : comment réussir son projet ?

INTERVIEW

‘‘L’intégrateur d’un WMS doit avant tout être un logisticien’’ C.TRAMOY, A-SIS


Christophe TRAMOY, Directeur de l'Intégration d’A-SISInterview de Christophe TRAMOY, Directeur de l'Intégration d’SAVOYE ADVANCED SOFTWARE
Réalisée le 08/01/2019 par Frédéric LEGRAS, Directeur du Portail FAQ Logistique dans le cadre du dossier thématique « WMS/TMS : comment réussir son projet ? »



Webinaire TMS Chargeur : les points clés pour un ROI rapideMardi 25 juin 2019 à 10h30

Ce webinar s’adresse à toutes les sociétés qui souhaitent initier un projet TMS et en maximiser le ROI. Au travers de quelques astuces, Olivier SCHULMAN, Responsable Développement TMS, vous donnera des conseils concrets pour vous aider à déployer les fonctions vous permettant la génération de gains immédiats.


Quels conseils pourriez-vous donner à une entreprise en cours de rédaction du cahier des charges de son futur WMS ?

Je pense qu’il faut veiller à respecter deux points principaux.

  Autres contributions

JP. GAUTIER | ACSEP
‘‘ Tant qu’un colis de test n’a pas été livré sur le bureau du Directeur, l’entreprise n’est pas prête à basculer ses opérations sur la nouvelle solution ’’

F. PETITJEAN | DESCARTES
‘‘ Commencer par bien définir les enjeux business auxquels l’entreprise est confrontée ’’

G. GARCIA et T. TSCHINSCHANG | KLS
‘‘ Il est primordial pour les entreprises de toujours garder une vision globale de leur Supply Chain  ’’

J. BOUR | DDS LOGISTICS
‘‘ Aller au-delà de la simple démo !  ’’

H. KERJEAN | AKANEA
‘‘ Se comprendre et créer un climat de confiance  ’’

D’abord il convient que le cahier des charges ne soit pas trop généraliste. Nous recevons souvent des documents très denses, généralement rédigés par des consultants qui ne s’attaquent pas réellement aux besoins métier. Il s’agit au contraire de s’assurer que les attentes de l’entreprise sont bien définies par rapport à son activité et à ses particularités.

Ensuite, il faut que le client prenne suffisamment de recul au moment de la rédaction des spécifications. Il est en effet naturel de souhaiter reproduire la solution déjà en place. Néanmoins, l’objectif d’un projet WMS est d’obtenir des gains de productivité et/ou de qualité par l’adoption d’une nouvelle organisation. Attention donc à ne pas reproduire l’existant en tant que cible.


Quels sont les principaux critères à considérer au moment de la sélection de son futur WMS ?

Préalablement, il existe des critères généraux qui concernent la pérennité financière de l'éditeur, le nombre de références dans le même secteur que le client, la capacité de l'éditeur à l'accompagner à l'international pour les grands comptes, avoir une gamme complète pour la SCE (WMS, OMS, TMS, WCS...) en particulier pour les organisations multi-canal ou avec des sites très mécanisés. Depuis quelques années, une consultation WMS s'accompagne de demandes sur le TMS.

Les clients souhaitent de plus en plus s'équiper de solutions SaaS afin de confier à l'éditeur l'administration complète de son application et la gestion de ses montées de version. Au sein des PME par exemple, le taux de demandes en solution SaaS constaté chez A-SIS est de 50% environ. Les grands comptes sont encore un peu réticents.

Les clients regardent également les capacités d'innovation de l'éditeur et la compatibilité de sa solution avec les technologies des outils de la logistique : Android, solution vocale, capacité à piloter des équipements type afficheurs ou Led.

Concernant la couverture fonctionnelle souhaitée, il existe un certain nombre de critères classiques.

Au-delà des critères, je pense que c’est le poids accordé à chacun d’entre eux qu’il convient de précisément définir. Ceux-ci diffèreront grandement d’une entreprise à une autre en fonction des besoins et contextes dans lesquels évolue chaque organisation.

Prenons l’exemple d’un module de gestion des ressources humaines dans l'entrepôt. Si 500 personnes y travaillent, le critère correspondant sera primordial. Si au contraire, l’entrepôt ne compte que 5 opérateurs, la première question à se poser est : « en ai-je vraiment besoin ? »

Attention également à bien prendre conscience que chez les éditeurs, les commerciaux qui répondent aux cahiers des charges ont suffisamment d’expérience pour savoir identifier les « questions éliminatoires », celles auxquelles il convient d'apporter une réponse positive pour passer à l’étape suivante, quitte à trouver plus tard un moyen de contournement.

Bref, une sélection par critère revêt selon moi plusieurs limites. Elle peut en particulier amener à écarter des solutions qui auraient finalement tout à fait répondu aux besoins. Il n’est d’ailleurs pas rare de se rendre compte, a posteriori, que des demandes décrites dans le cahier des charges initial ne sont plus d’actualité une fois la phase de mise en place activée.




Quelle alternative préconisez-vous ?

Tester le WMS à travers la réalisation d’un POC me paraît être une solution tout à fait pertinente.

Il s’agit d’identifier quelques sujets clés et de demander au fournisseur de préparer un "bac à sable" dans lequel il va démontrer que sÀ proposition fonctionne. Le client disposera alors d’éléments concrets lui permettant de se forger son opinion.

La réalisation de ce POC peut demander plusieurs jours ou semaines de travail à des sociétés dont certaines, c’est l’objectif de l’exercice, ne seront finalement pas retenues. Les coûts générés peuvent donc être significatifs pour les éditeurs.


Dans le cas où l’entrepôt à équiper est mécanisé, à quels éléments faut-il particulièrement prendre garde au moment du choix de sa solution WMS ?

Dans ce cas, le WMS devra pouvoir s'interfacer avec des sous-systèmes mécanisés plus ou moins complexes (machines de tri, goods-to-person, préparation à gare, etc.). Il convient de s’assurer que la future solution de gestion d’entrepôt est à même à la fois de maitriser les concepts liés à ces solutions mécanisées et de s'interfacer avec le WCS. Étant une marque de l’intégrateur et ingénierie de solutions intra-logistiques SAVOYE, les logiciels édités par A-SIS ont été pensés pour intégrer ces différents aspects dès l’origine. Ce n'est pas forcément le cas de tous les WMS.

Quels sont les pièges concernant les projets de mise en place d’un WMS à destination d’un entrepôt mécanisé ?

Il existe une représentation pyramidale assez classique qui illustre bien le fait que les ordres partent de l’ERP pour descendre au WMS, puis au WCS et enfin aux automatismes. Le système de remontée d’informations prend le chemin inverse.

Il est important de respecter le périmètre d’action de chaque système. Parfois, il peut arriver que le client demande à mettre une fonctionnalité d'ERP dans le WMS ou une fonctionnalité WMS dans le WCS. Par expérience, ce n'est jamais une bonne idée. Les systèmes ont été pensés pour un périmètre fonctionnel. En sortant de ce périmètre, la logique du produit est cassée et c’est toute l’organisation qui est mise en danger.

Prenons un exemple. Un des rôles de l'ERP est de gérer commercialement les cas de pénurie. Quand 100 produits A sont disponibles à la vente et que les commandes comportent 120 produits A, il doit y avoir une stratégie dans l'ERP permettant de définir les règles d’affectation des produits aux clients. Il m’est plusieurs fois arrivé de constater que l’ERP en place ne le faisait pas et de voir l'entreprise nous demander que le WMS puisse prendre en charge ce rôle. Cela revient en fait à affecter à la logistique la prise d’une décision qui n'est pas de son domaine, mais de celui de la gestion du client. Pour pouvoir orienter cette décision, il devient nécessaire de mettre de l'information client dans le WMS.

Le problème est que cela impose de gérer une base clients à la fois dans l’ERP et dans le WMS. De fil en aiguille, les systèmes perdent en cohérence.


Passons à la mise en place d’un WMS, quelles sont les bonnes pratiques ?

Un projet réussi implique la collaboration entre les deux sociétés concernées : le fournisseur de la solution et son client. Ni l'un ni l'autre ne doivent penser pouvoir mener le projet seul dans leur coin.

Pour favoriser cette collaboration, il est nécessaire de s'organiser.

La première chose est de bien définir et formaliser le rôle et les tâches de chacun. C'est une étape fondamentale. C'est généralement ce que nous faisons au cours d'une réunion de lancement. Une fois les rôles des protagonistes définis, il convient également de préciser les liens qu'il y aura entre eux.

Chacun doit avoir clairement à l’esprit ce qui relève de sa responsabilité. Cela permettra d’éviter qu'il y ait ensuite des ambiguïtés au détriment du résultat du projet.


Attardons-nous sur cette réunion de lancement. Quels en sont les grands objectifs ?

La réunion de lancement permet de définir deux instances :

  • Le comité de projet géré par les chefs de projet
  • Le comité de pilotage. À des moments clés du projet, il permettra de s’attaquer aux sujets que les chefs de projet n'ont pas pu traiter en autonomie. C'est donc une instance de Direction qui implique des sponsors client et intégrateur visant à vérifier que le projet est bien en ligne et à arbitrer le cas échéant.

Cette réunion de lancement est également l’occasion d’établir le planning et en particulier les jalons du projet. L’objectif est de ne pas avancer dans le brouillard. Les grandes étapes et les délivrables associés sont définis. Certains sont du domaine de l'intégrateur, mais d’autres sont de celui du client. Il est donc important que l’entreprise ait conscience des potentiels impacts planning. Nous attirons en particulier l’attention du client sur le fait que l'entrepôt a besoin de « ses deux jambes » pour avancer. À savoir :

  • Les données de base autour du produit (Masterdata). Il peut s'agir d'informations physiques de type dimension ou poids du produit, mais également tout ce qui est lié à des stratégies de réception, de rangement ou de préparation. Une palette complète n’est en effet pas traitée logistiquement comme un sachet. Ils ne seront probablement pas rangés au même endroit ni ne nécessiteront les mêmes ressources. Une palette complète et un colis de détail ne suivront pas non plus les mêmes circuits de préparation. Tout cela sera piloté par le logiciel d'entrepôt, mais encore faut-il que celui-ci puisse baser ses traitements sur des informations justes. Il est donc fondamental que ce référentiel article soit bien renseigné.
    Le problème est que cela peut avoir un fort impact sur le planning et nécessiter d’importantes ressources en fonction du référentiel article de l’entreprise. Prenons le domaine de la pièce automobile. Dans ce secteur, il n'est pas rare que les référentiels atteignent 200.000 références, chacune étant potentiellement déclinée en plusieurs unités logistiques. Le même article peut se préparer au détail, au colis complet ou à la palette. On arrive donc très vite à 500.000 unités à renseigner.
  • La correspondance entre stock physique et informatique. La qualité du stock physique doit être irréprochable afin de ne pas fournir des ordres non pertinents faute de données de base correctes. Cela peut paraître une banalité, mais bien souvent les deux ne correspondent pas.

Pouvez-vous illustrer l’importance de ces points ?

Prenons le cas du précolisage qui est l’un des grands intérêts d’une solution comme la nôtre. Le système détermine quels sont les produits devant être mis dans chaque colis afin de minimiser le vide transporté. L’optimisation est basée sur les dimensions des articles. Si celles-ci ne sont pas correctes, le résultat sera catastrophique : les colis seront à moitié vides ou au contraire déborderont.


Passons à l’analyse fonctionnelle, quelle est l’objectif de cette phase ?

Au moment où nous intervenons en tant qu’intégrateur, le contrat a déjà été signé. Ce contrat définit le périmètre du projet et reprend l’offre de notre société. Cette offre répond donc point par point aux éléments présents dans le cahier des charges en distinguant ce qui relève des fonctions standard, du paramétrage et des éventuels développements spécifiques.

En avant-vente, l’analyse menée minimise généralement les risques. A été identifié ce qui relève du standard et ce qui n’en relève pas. La démarche d'essayer de ramener en partie les processus du client vers le standard doit également avoir été initiée.

C'est pour moi un élément fondamental. Nous intégrons des produits qui ont un large périmètre fonctionnel. L'intérêt de tous est de rester le plus possible dans le fonctionnement standard du produit. Celui-ci est en effet éprouvé et le nombre de dysfonctionnements diminue au fur et à mesure qu'il est utilisé chez les différentes références de l'éditeur.

Néanmoins, les résultats de l’avant-vente ne sont pas gravés dans le marbre. C’est véritablement lors de la phase d’analyse fonctionnelle que tout est affiné. Il y a alors deux possibilités :

  • Faire converger au maximum le produit à la demande du client à travers des développements spécifiques
  • Lui présenter ce que fait le WMS et voir ensuite comment le logiciel peut couvrir son besoin

Les éditeurs qui ont un produit plus simple ou moins évolué, dont le périmètre fonctionnel est limité préfèreront que le client exprime son besoin et essaierons d’y « coller » en procédant à du développement spécifique.

Les éditeurs qui, au contraire, s’appuient sur un logiciel performant et bénéficiant d’une large couverture fonctionnelle privilégieront le fait de convaincre le client de couvrir ses besoins avec le périmètre standard. A-SIS est clairement dans ce dernier cas.

À ce titre, il est intéressant de commencer par former les équipes sur le produit standard avant d’entrer dans le détail des besoins du client. Il sera ainsi plus simple de raisonner en différentiel.


Quels sont les principaux axes de votre méthodologie d’intégration ?

Nous favorisons une logique de séquentialité. Il s’agit en fait du concept de l'agilité informatique appliquée au monde de la gestion de projets. Un sujet fonctionnel est choisi et toutes les étapes du process sont ensuite déroulées.

Cela permet d’éviter l'effet tunnel. Ce qui peut être livré l’est au plus tôt. Le client n’a plus besoin d’attendre que l’ensemble de la solution lui soit mis à disposition pour commencer à « jouer » avec elle, à la tester, etc.
Auparavant, un certain nombre de semaines étaient nécessaires à l’éditeur pour développer et paramétrer la solution dans son ensemble. Pendant ce laps de temps le client n’était plus en contact avec le WMS. Une fois le produit livré, les marges de manœuvre pour réaliser les éventuels ajustements étaient limitées, car la date cible de démarrage était généralement très proche.

Ensuite, nous avons beaucoup investi ces dernières années sur la phase de test et sur l’aspect formation.

Désormais les sociétés veulent absolument minimiser les risques inhérents à l’installation d’un WMS dans leurs entrepôts. Les enjeux opérationnels sont en effet importants. Un logiciel qui ne fonctionne pas bien, ce sont des colis qui ne sont pas livrés. Une société peut alors voir son activité totalement arrêtée.

Le temps investi en tests est donc beaucoup plus important qu'il ne l'était par le passé. La méthodologie est plus structurée également, avec une plus grande formalisation de la phase de tests. Chaque fonctionnalité est ainsi méticuleusement vérifiée et validée.

Ensuite, l'efficacité de nos formations a beaucoup été travaillée également. Les WMS sont des logiciels qui ont une certaine complexité qui peut décontenancer certains utilisateurs en particulier s’ils sont peu habitués à la technologie. Des réticences peuvent donc apparaître. Celles-ci doivent pouvoir en grande partie être levées en phase de formation. C’est pourquoi nous avons travaillé ces dernières années sur l'ingénierie de nos formations dans l’objectif de les rendre toujours plus efficaces.

En support de l’indispensable accompagnement sur site, nous proposons une plateforme digitale de services de formations, « ASCENTLINE », diffusant de la vidéo, des exercices, des QCM, etc. Tout cela permet d’accorder une certaine autonomie aux équipes pour voir ou revoir les formations.

Nous avons également développé des sujets périphériques. Installer un logiciel avec des nouveaux processus a forcément des répercussions : sur l'organisation du travail, sur les habitudes, sur l'utilisation des outils, etc. Nos formations ne pouvaient donc se limiter à la seule utilisation de notre solution. C’est pourquoi nous proposons désormais des prestations visant à "Préparer le changement", améliorant la communication, la formation et l’expertise.

Nous nous sommes rendu compte que nos clients n'étaient souvent peu ou pas structurés pour organiser ce changement. De notre côté, à travers la quarantaine d'installations annuelles sur lesquelles nous opérons, nous avons enrichi l’expérience qui va au-delà de la logistique.

Une gestion du changement efficace conditionne en grande partie le succès du projet. La communication et la préparation sont primordiales. Une partie des clients sont en mesure de prendre le sujet en charge. Néanmoins, si ce n’est pas le cas, nous sommes aujourd'hui capables de les accompagner également sur ces aspects-là.


Quels types de profils retrouve-t-on dans vos équipes d’intégration ?

Au niveau intégration, le principal interlocuteur du client est le consultant fonctionnel. Véritable chef de projet, il s’agit avant tout d’un logisticien plutôt que d’un informaticien. C’est primordial pour s’assurer qu’il puisse parler le même langage que le client.

D’ailleurs pour moi, même si la maîtrise de l’outil et de son paramétrage sont nécessaires, l'intégrateur doit avant tout être un logisticien.

Le consultant fonctionnel va ainsi parler de logistique avec le client et de produit avec le chef de projet informatique de l’éditeur.

Nous nous adaptons également à la taille des entreprises que nous adressons et à la complexité des solutions à mettre en place.

L'expérience nous a montré qu’un petit projet ne pouvait se gérer comme un projet de grande ampleur. La complexité et les organisations ne sont pas les mêmes, en particulier les profils de nos interlocuteurs.

On n’échange pas de la même façon avec le Directeur d’une PME qu’avec une équipe de consultants pour laquelle la prise de décision sera très hiérarchisée et codifiée.


Pour aller plus loin


Bio Express

Christophe TRAMOY a intégré A-SIS au lancement de la société dans les années 1990. D'abord consultant métier, il a ensuite pris en charge le département Expertise de l’entreprise. Aujourd’hui Directeur de l'Intégration des produits développés par l’éditeur (WMS, TMS, WCS, OMS, etc.) et Directeur des projets d’automatisation de SAVOYE, il est à la tête d’une équipe de plus de 80 collaborateurs en France et à l'étranger. Il est également en charge des services de formation.

Site Internet d'A-SIS : www.a-sis.com


Contactez notre équipe