AMOA & pilotage de projets de transformation IT Supply Chain

Réponse directe

Dans un projet de transformation Supply Chain, trois acteurs ont des intérêts différents : l’éditeur veut livrer son standard, l’intégrateur veut tenir son forfait, vous voulez que ça marche en exploitation. Sans tiers qui représente ce troisième intérêt, l’arbitrage se fait mécaniquement en faveur des deux premiers. L’AMOA n’est pas une couche administrative : c’est la fonction qui transforme une promesse commerciale en performance opérationnelle.

Le déroulé complet d’une transformation

1. Audit de l’existant

Analyse des flux réels, des données, de l’organisation et du SI. Observation terrain, entretiens à tous les niveaux, extraction et analyse quantitative. Livrable : un diagnostic chiffré et une hiérarchie des dysfonctionnements par impact financier.

2. Schéma directeur

Cible à 3-5 ans, trajectoire par étapes, arbitrage entre les chantiers, budget global et séquencement. C’est le document qui permet à une direction générale d’arbitrer et de tenir un cap sur plusieurs exercices.

3. Choix de la solution

Cahier des charges fonctionnel, présélection, soutenances sur vos jeux de données, grille de notation pondérée, analyse du coût complet sur cinq ans, négociation contractuelle et clauses de réversibilité.

4. Pilotage de l’intégrateur

Animation des ateliers de conception, tenue du registre des décisions et des écarts, suivi du reste-à-faire, gestion des avenants, comités de pilotage. Le rôle est simple à décrire, exigeant à tenir : ne rien laisser passer.

5. Conduite du changement

Cartographie des impacts par population, plan de communication, formation des key users puis des utilisateurs, documentation des nouveaux modes opératoires. C’est le poste le plus souvent sacrifié quand le planning se tend — et la première cause d’échec des go live.

6. Go live et hypercare

Répétition générale à blanc, critères go / no-go objectifs et écrits, bascule, puis présence renforcée pendant 4 à 8 semaines. L’hypercare n’est pas du support : c’est la période où l’on corrige ce que la recette n’a pas vu.

L’audit : par où je commence

Un audit logistique utile ne se fait pas en salle de réunion. Il se fait sur trois plans simultanés.

Le plan des faits. Extraction de 12 à 24 mois de données : lignes de préparation, commandes, références, mouvements de stock, écarts d’inventaire, litiges transport, heures travaillées. C’est la seule base non discutable de la discussion.

Le plan du réel observé. Plusieurs journées sur site, y compris en horaires décalés. Ce qui se voit : les contournements, les doubles saisies, les post-it sur les écrans, les stocks tampons non déclarés, le temps réellement passé à chercher.

Le plan des perceptions. Entretiens individuels du préparateur au directeur général. La question la plus productive que je connaisse : « si vous aviez une chose à changer demain matin, ce serait quoi ? » Les réponses convergent beaucoup plus qu’on ne l’imagine, et rarement vers ce que la direction attend.

Pourquoi les go live échouent

J’ai vu suffisamment de bascules réussies et ratées pour identifier des constantes. Les échecs ne viennent presque jamais du logiciel.

La reprise de données. C’est la première cause, de loin. Stocks, emplacements, référentiel article, en-cours de commande, historiques. La reprise se prépare six mois à l’avance, se teste au moins deux fois à blanc, et doit être réconciliée ligne à ligne. Un go live avec 3 % d’écart de stock démarre avec plusieurs semaines de désordre.

Les critères de go / no-go non écrits. Si les critères de bascule ne sont pas définis et signés avant, la décision se prend sous pression politique le vendredi soir. Elle est alors presque toujours favorable au go live, y compris quand tous les signaux sont au rouge.

Les key users non déchargés. Un key user qui garde 100 % de sa charge opérationnelle ne fera ni la recette, ni la formation de ses collègues. La décharge doit être actée par écrit et remplacée dans l’équipe, sinon elle n’existe pas.

L’hypercare non budgété. Les quatre à huit semaines qui suivent la bascule concentrent l’essentiel des irritants. Si l’équipe projet est déjà dissoute et l’intégrateur reparti, ces irritants deviennent des contournements durables — et le nouveau système hérite de la réputation d’être moins bon que l’ancien.

Reprendre un projet qui dérive

Une partie de mes missions consiste à reprendre des projets déjà engagés et mal partis. La démarche est différente : il faut d’abord établir un état des lieux contradictoire, sans chercher de coupable.

Établir le reste-à-faire réel, fonction par fonction, avec l’intégrateur, et le confronter au planning officiel. L’écart est généralement considérable et connu de personne en totalité.
Requalifier le périmètre. Presque toujours, le projet a grossi sans arbitrage. Distinguer ce qui est indispensable au go live de ce qui peut attendre une version 2 débloque souvent la situation à lui seul.
Reconstituer une gouvernance. Un arbitre unique, un comité hebdomadaire, un registre des décisions écrit. Beaucoup de projets dérivent simplement parce que personne n’a le mandat de trancher.
Rétablir la relation contractuelle. Ce qui relève de l’avenant, ce qui relève du forfait, ce qui relève de la non-conformité. Le dire clairement, une fois, par écrit.

Pour aller plus loin

Comment réussir un projet WMS ?

Questions fréquentes

Qu’est-ce que l’AMOA exactement ?

L’assistance à maîtrise d’ouvrage consiste à représenter les intérêts du client face aux prestataires techniques. Concrètement : formaliser le besoin, écrire le cahier des charges, piloter la consultation, animer les ateliers de conception, arbitrer les écarts, organiser la recette, préparer les équipes et sécuriser le go live. La maîtrise d’œuvre construit ; la maîtrise d’ouvrage définit ce qui doit être construit et vérifie que ça l’a été.

Pourquoi ne pas confier l’AMOA à l’intégrateur ?

Parce qu’il y a conflit d’intérêts. L’intégrateur a un forfait à tenir : chaque écart au périmètre initial est pour lui un avenant, donc une marge. Il ne peut pas simultanément défendre son forfait et arbitrer en votre faveur. Ce n’est pas une question d’honnêteté, c’est une question de position.

Quand faut-il faire appel à une AMOA ?

Le plus tôt possible, idéalement avant même la rédaction du cahier des charges — car c’est là que se jouent les décisions les plus structurantes. Une AMOA appelée en cours de projet reste utile mais hérite de choix déjà faits. Le pire moment, c’est trois semaines avant un go live compromis : à ce stade, il ne s’agit plus d’AMOA mais de gestion de crise.

Combien de jours faut-il prévoir ?

Pour un projet WMS de PME sur un site, comptez 25 à 50 jours répartis sur 12 mois. Pour un déploiement multi-sites avec interfaces complexes, 80 à 150 jours sur 18 mois. En règle générale, l’AMOA représente 8 à 15 % du budget projet — un ratio qui se rembourse largement sur les avenants évités et les délais tenus.

Transformation IT : quelqu’un doit représenter vos intérêts