Comment les consultants intègrent un POC OEE 48 heures dans une mission LEAN
Une mission LEAN chez un client industriel dure typiquement huit à douze semaines. Les deux premières sont le diagnostic — tours d’usine, entretiens stakeholders, revue des données historiques. Les semaines trois à dix sont les sprints d’amélioration. La dernière semaine, c’est la transition et le handover. Dans cette structure, le move à plus forte leverage qu’une équipe consulting peut faire sur les deux premières semaines, c’est d’obtenir pour le client de la donnée OEE temps réel sur au moins deux lignes — pas de l’OEE estimé depuis l’ERP, pas de l’OEE reconstitué à la main depuis les rapports d’équipe, mais du vrai OEE temps réel avec décomposition des pertes et hypothèses root cause.
C’est exactement ce que livre un POC OEE léger en 48 heures. Cet article explique comment les consultants BCG, McKinsey, Bain, Kearney, Roland Berger, Sia Partners et voisins intègrent un POC TeepTrak 48h dans la phase diagnostic d’une mission LEAN, quoi communiquer au client avant/pendant/après, et comment utiliser l’output dans le deck du COPIL de fin de semaine 2.
Cet article reflète des perspectives construites lors de 4 années au BCG sur des programmes LEAN, performance opérationnelle et réduction des coûts à travers l’Europe, l’Asie et les Amériques.
À quel moment proposer le POC dans le cycle de mission
Le moment idéal, c’est le kickoff au début de semaine 1, avant que l’équipe n’ait fait de travail de terrain. Au kickoff, le client s’attend à ce que le premier livrable concret arrive en semaine 2 ou 3 — généralement une présentation diagnostic avec OEE estimé, hypothèse de pertes, et proposition de programme d’amélioration. Si l’équipe consulting peut ajouter « et nous aurons de la donnée OEE temps réel sur deux lignes en fin de semaine 1 » à cette attente, la perception client du tempo de la mission change immédiatement.
Le POC est un engagement que l’équipe ne devrait prendre que si le vendor peut livrer de façon fiable. TeepTrak a mené 200+ POCs consulting et le délai 48 heures tient si l’équipe vendor est sur site avec le matériel en main. Ajouter un jour de déplacement ou un retard d’envoi de matériel repousse la livraison réelle à jour 3 ou 4, ce qui reste rapide par rapport à un projet traditionnel d’infrastructure de mesure, mais détruit le framing « 48 heures » avec le client. Prévoir la présence physique à jour zéro.
Le moment secondaire pour proposer le POC est en milieu de mission, vers la semaine 4, si le diagnostic initial a fait émerger un gap de mesure OEE dont le client n’avait pas conscience. C’est fréquent — le client croyait son reporting ERP fiable, le diagnostic a montré qu’il ne l’était pas. Le POC devient alors l’outil qui remplace l’OEE ERP peu fiable par de l’OEE temps réel fiable dès maintenant. C’est un move de crédibilité : l’équipe consulting a identifié le gap et fourni le fix dans la même conversation.
Scoping du POC : quelles lignes, combien de capteurs, quelle donnée
Le POC devrait couvrir deux lignes, pas une. Une seule ligne donne un point ; deux lignes donnent une comparaison. La comparaison, c’est ce qui génère l’insight pour le diagnostic : la ligne A tourne à 71% d’OEE, la ligne B à 58%, et les 13 points d’écart sont concentrés dans une catégorie de perte spécifique que l’équipe peut alors creuser.
Critères de sélection des lignes, par ordre d’importance : les lignes doivent être opérationnellement importantes pour le client (pas des lignes pilotes ou faibles volumes), les lignes devraient représenter des types de process différents si possible (une ligne conditionnement et une ligne assemblage, pas deux postes identiques), et les lignes devraient avoir un potentiel OEE obvious (le client croit qu’elles sous-performent, même sans donnée).
Couverture capteurs par ligne : typiquement quatre à huit capteurs selon le nombre de postes — capteurs de courant sur les moteurs principaux, photoélectriques en sortie, vibration sur équipement critique, et une tablette Andon partagée pour la saisie opérateur. Le kit POC est pré-configuré ; il n’y a pas de décision sur le choix des capteurs à faire sur site.
Données collectées pendant la fenêtre 48 heures : stream complet des événements d’arrêt avec timestamps, débit vs vitesse théorique, comptage qualité vs production totale, fréquence et distribution des micro-arrêts, raisons taggées par opérateur pour chaque événement, et signaux environnementaux le cas échéant (température, patterns vibration).
Téléchargement gratuit
Téléchargement immédiat. Aucune confirmation par e-mail requise.
La timeline 48 heures, heure par heure
Heures 0-8 jour 1 : arrivée site, briefing sécurité, installation capteurs, configuration réseau (WiFi local ou 4G), et setup tablette opérateur. L’installation est non-invasive : capteurs courant à pince, capteurs vibration à fixation magnétique, capteurs photoélectriques sur châssis existants. Aucun équipement n’est arrêté, aucun PLC n’est touché. L’équipe consulting utilise cette période pour les entretiens stakeholders sur les lignes concernées — opérateurs, chefs d’équipe, personnel maintenance — ce qui contribue au diagnostic indépendamment du POC.
Heures 8-24 : première équipe de production avec donnée qui flow. À ce stade le dashboard est live mais la donnée n’est pas encore statistiquement significative. L’équipe consulting devrait regarder le flux temps réel pour valider que les capteurs capturent les événements qu’ils devraient — si la ligne s’arrête et que le dashboard le montre en moins d’une seconde, la config est bonne. S’il y a un lag ou des événements manquants, l’ingénieur vendor ajuste sur place.
Heures 24-40 : seconde équipe de production. À ce point on a assez de donnée pour reconnaissance de pattern initiale. La couche JEMBA AI commence à sortir des outputs d’hypothèse : « pertes de disponibilité sur ligne A concentrées sur les changements de série entre SKU-102 et SKU-104, durée moyenne 38 minutes, 3x la cible » ; « fréquence micro-arrêts sur ligne B : 47 par équipe, au-dessus du benchmark 12-par-équipe, concentrée sur le poste 4 ». C’est le matériau brut pour le deck diagnostic.
Heures 40-48 : revue donnée, conversation root cause avec les leaders opérations client, et export des findings dans le deck de l’équipe consulting. L’ingénieur vendor quitte typiquement le site à l’heure 48 ; le système continue de tourner et produit de la donnée que l’équipe consulting peut référencer pour le reste de la mission.
Ce qu’il faut mettre dans le deck diagnostic semaine 2
L’output POC change le deck diagnostic de trois façons spécifiques. Premièrement, les slides baseline OEE passent de chiffres estimés à chiffres mesurés avec une note de méthodologie claire — c’est la plus grosse upgrade de crédibilité qu’un diagnostic puisse avoir. Deuxièmement, les slides de décomposition des pertes ont de vrais timestamps et fréquences plutôt que des hypothèses, ce qui permet à l’équipe de zapper le débat classique avec le client sur « est-ce que ces chiffres sont justes ? » et d’aller directement à « qu’est-ce qu’on en fait ? »
Troisièmement, la proposition de programme d’amélioration gagne en spécificité. Au lieu d’une proposition générique de programme LEAN, l’équipe peut proposer des interventions ciblées : « réduire le temps de changement de série de 38 à 20 minutes sur la ligne A via un atelier SMED en semaines 4-5 ; cela à soi seul devrait yielder 4-5 points d’OEE » ; « investiguer le goulot au poste 4 sur la ligne B via un Kaizen micro-arrêts dédié en semaines 6-7 ». La spécificité de la proposition d’amélioration est ce qui sépare les missions qui closent avec de l’impact mesurable des missions qui closent avec un deck de stratégie.
Beaucoup d’équipes incluent directement des screenshots du dashboard TeepTrak dans le deck — avec accord client — parce que la preuve visuelle du monitoring OEE temps réel renforce la crédibilité de la recommandation. Le format typique est une annexe deux slides : le dashboard as-is et un résumé baseline qualité de donnée (taux de capture événements, uptime capteurs, taux de saisie opérateur).
Communiquer le POC au sponsor client
Les sponsors clients — typiquement des responsables d’usine, directeurs opérations, ou CIOs — ont entendu beaucoup de pitches « 48 heures » et « quick-win » avant, dont la plupart n’ont pas livré. La barre de crédibilité pour cette communication est plus haute qu’une proposition vendor générique.
Trois messages à mettre en tête : le POC ne demande aucun travail PLC à l’équipe IT client, le POC est structuré pour produire de la donnée de qualité décisionnelle dans les 48 heures, et le POC peut être arrêté à tout moment sans empreinte résiduelle sur les systèmes usine. Ces trois messages adressent les trois inquiétudes qui tuent typiquement les propositions quick-win : charge IT, incertitude de time-to-insight, et risque de lock-in.
Le sponsor demandera souvent ce qui se passe à la fin du POC. La réponse honnête : l’équipe consulting possède la donnée générée pendant le POC, le client décide s’il veut continuer vers un déploiement à l’échelle (étape classique suivante : 4 à 8 semaines de lignes supplémentaires) ou s’arrêter et emmener les findings POC avec d’autres outils. La décision n’est pas pré-chargée. Ce framing construit la confiance ; le framing inverse (« vous allez tellement aimer que vous serez obligés d’acheter le système complet ») ne la construit pas.
Modes d’échec fréquents et comment les éviter
Le POC échoue quand l’équipe consulting skippe le travail de sélection de lignes. Une ligne mal choisie — où l’OEE est déjà haut, où le volume de production est faible pendant la fenêtre POC, ou qui est en maintenance — produit une donnée qui ne génère pas d’insight diagnostic. La conversation sélection de lignes avec le client devrait prendre au moins une heure en semaine de kickoff.
Le POC échoue quand l’équipe consulting ne prépare pas les opérateurs. Les opérateurs qui voient les tablettes apparaître sans contexte vont résister. Un briefing de dix minutes en réunion pré-équipe — « c’est un outil pour nous aider à comprendre ce qui ralentit la ligne, ce n’est pas un outil de surveillance, personne n’est évalué là-dessus » — fait la différence entre 90%+ de taux de saisie et 30%.
Le POC échoue quand l’équipe consulting ne réserve pas du temps pour revoir la donnée. Une donnée générée mais non revue par l’équipe est une donnée gaspillée. Bloquer deux heures à l’heure 24 et deux heures à l’heure 40 pour que l’équipe s’assoie avec le dashboard et l’ingénieur vendor, c’est le minimum. Sauter ça termine avec un deck semaine 2 qui référence la donnée POC mais qui ne l’a pas vraiment intégrée.
Comment le POC change l’économie de la mission
Les missions consulting avec un POC 48 heures au début produisent de façon constante plus de scope follow-on que les missions sans. Le mécanisme est straightforward : le client voit de la valeur mesurable dans les deux premières semaines, ce qui construit la confiance dans le jugement technique de l’équipe, ce qui rend le client plus réceptif aux programmes d’amélioration à l’échelle, rollouts d’usines adjacentes, et mandats de transformation pluriannuels.
Pour le cabinet, l’économie est visible au closeout. Les missions avec POC intégré montrent routinièrement 1,5 à 2x la conversion follow-on des missions sans. Pour le consultant individuel, l’effet est réputationnel : les clients qui ont vu l’équipe livrer de l’amélioration OEE mesurée pendant la mission sont matériellement plus susceptibles d’être référençables auprès du prochain prospect du cabinet, et matériellement plus susceptibles de rappeler l’équipe pour la phase suivante.
Références externes : Lean Manufacturing — Wikipédia · TRS / OEE — Wikipédia · SMED — Wikipédia
À lire également : Pourquoi les consultants stratégie recommandent l’OEE léger vs MES · Ce que 4 ans au BCG m’ont appris sur la conception OEE · Comment les consultants évaluent les vendors MES/OEE
Vous intervenez chez un client industriel ?
Notre équipe a accompagné des missions BCG, McKinsey, Bain, Kearney, Roland Berger et Sia Partners dans 30+ pays. POC 48h gratuit sur site client — sans engagement de votre client.
Discuter d’un POC client
0 commentaires