Build to Run : pourquoi l'équipe qui construit doit aussi exploiter

Le moment où tout se joue

Le Go-Live d'un WMS, d'un TMS ou d'un ERP n'est pas la fin d'un projet : c'est le début de sa vie en production. C'est pourtant souvent à ce moment que l'équipe qui connaît le mieux la solution quitte le terrain. L'intégrateur termine l'hypercare, transmet une documentation, et une équipe de TMA reprend un système qu'elle n'a pas conçu.

Ce qui se perd dans la passation

Une documentation décrit ce qui a été construit. Elle dit rarement pourquoi. Les arbitrages de paramétrage, les contournements décidés pendant la recette, les interfaces fragiles connues de quelques personnes : tout cela se transmet mal. Les premiers incidents révèlent ces zones d'ombre, au moment où les opérations ont le moins de marge.

S'ajoute une question de responsabilité. Quand un flux s'arrête entre l'ERP, le WMS et la mécanisation, chaque prestataire regarde son propre périmètre. Personne n'est propriétaire de l'interface.

Le principe du Build to Run

Chez Lean Technology, la même équipe conçoit, intègre, déploie puis exploite. Ce principe change la façon de construire : une équipe qui sait qu'elle assurera le support paramètre pour la lisibilité, documente pour elle-même et teste les modes dégradés avant qu'ils ne se produisent.

Le modèle suit cinq étapes : Advise, Build, Deploy, Run, Optimize. Le Run nourrit ensuite les évolutions : ceux qui traitent les incidents savent mieux que quiconque ce qu'il faut améliorer.

Préparer le Run avant le Go-Live

Le Run se prépare pendant le Build. Notre offre Run Readiness Assessment valide le modèle d'exploitation et un plan de transition daté avant la mise en production : niveaux de support, astreinte, engagements de service, indicateurs, autonomie des key users. Le jour du Go-Live, l'organisation du Run est déjà en place.

Une gouvernance unique

Le Build to Run s'accompagne d'une gouvernance à trois niveaux : opérationnel chaque semaine, tactique chaque mois avec un Customer Pulse, stratégique chaque trimestre. Un Engagement Manager unique porte la relation, du premier atelier aux évolutions.

Quand ce modèle est-il pertinent ?

• Quand le système est critique pour l'exploitation, avec peu ou pas de fenêtre d'arrêt.
• Quand plusieurs couches du SI sont concernées : ERP, WMS, WCS, TMS, APS.
• Quand un programme se déploie sur plusieurs sites, par vagues successives.
• Quand l'équipe interne ne peut pas absorber seule le support après le Go-Live.

Pour un périmètre simple et stable, un support éditeur peut suffire. Le bon modèle se décide pendant le cadrage, pas après la mise en production. Pour en parler sur votre contexte : réservez un atelier exécutif.