Genchi genbutsu : aller voir par soi-même avant de décider, et avant de déployer un ERP.
Vous connaissez la chanson : réunions, présentations, tableaux, reporting. On croit tout savoir depuis nos écrans. Erreur. La réalité opérationnelle ne se capture pas dans un rapport. Elle se vit, se ressent, et s’observe là où les choses se passent.
Montrer pourquoi le terrain est l’outil de diagnostic le plus fiable. Expliquer la méthode genchi genbutsu, illustrer son impact avec un cas emblématique, et traduire cette logique en pratiques concrètes pour sécuriser un projet ERP, notamment en cadrage et en POC.
0. Le problème : l’écran ment par omission.
Un reporting dit rarement comment le travail se fait réellement. Il décrit un processus “propre”, souvent idéal, parfois politique. Il oublie les contournements, les adaptations, les contraintes physiques, et les micro-décisions quotidiennes.
Or, un projet d’amélioration ou un déploiement ERP échoue rarement sur un grand principe. Il échoue sur une accumulation de détails invisibles. Ce sont ces détails que le terrain révèle.
Un bon diagnostic n’est pas une opinion. C’est une observation. Et une observation exige d’être au bon endroit, au bon moment, avec les bonnes questions.
1. Définition et origine : au cœur du toyota production system.
Genchi genbutsu est une méthode japonaise qui signifie “aller voir par soi-même”. Elle fait partie des piliers du TPS et a profondément influencé l’excellence opérationnelle au-delà de l’industrie.
Pour comprendre une situation, résoudre un problème, ou améliorer un processus, il faut se rendre sur le gemba. Il faut voir, écouter, mesurer, et comprendre les contraintes réelles. Pas dans une salle de réunion.
“Va sur le terrain pour voir de tes propres yeux”. Cette règle est simple. Son impact est radical.
Genchi genbutsu n’est pas une observation passive. C’est une investigation. Vous cherchez la réalité brute, non filtrée par les habitudes, les biais, ou les intérêts. Vous remplacez l’interprétation par la preuve.
2. Les 4 étapes fondamentales.
La méthode se résume en un cycle court. Elle vise à passer de l’observation à une solution alignée sur la réalité.
1. Aller sur le terrain
- Ce que vous faites
- Vous observez les activités réelles dans l’environnement de travail.
- Ce que vous cherchez
- Les gestes, les flux, les temps d’attente, les interruptions, les échanges informels.
Point de vigilance. Vous observez d’abord, vous expliquez ensuite.
2. Interroger les contraintes
- Ce que vous faites
- Vous questionnez les obstacles, détours, et adaptations non documentés.
- Ce que vous cherchez
- Les raisons : sécurité, qualité, charge, outillage, temps, responsabilités.
Point de vigilance. Une “mauvaise pratique” est souvent une réponse intelligente à une contrainte invisible.
3. Identifier les écarts
- Ce que vous faites
- Vous comparez le processus théorique et le processus réel.
- Ce que vous cherchez
- Les écarts qui créent du retard, des erreurs, du rework, ou de la frustration.
Point de vigilance. Vous cherchez la cause racine, pas le symptôme.
4. Adapter la solution
- Ce que vous faites
- Vous concevez une solution alignée sur les pratiques réelles, pas sur les fantasmes procéduraux.
- Ce que vous livrez
- Des règles simples, des workflows clairs, et des arbitrages explicités.
Point de vigilance. Un ERP ne “corrige” pas le terrain, il amplifie ce que vous standardisez.
3. Approche traditionnelle vs approche genchi genbutsu.
Les deux approches peuvent coexister. La différence est simple : l’une part du déclaratif, l’autre part du réel.
| Angle | Approche traditionnelle | Approche genchi genbutsu |
|---|---|---|
| Point de départ | Cahier des charges théorique | Observation concrète du terrain |
| Source principale | Ce que les gens disent faire | Ce que les gens font réellement |
| Représentation | Documentation procédurale | Adaptations et contournements réels |
| Risque dominant | Automatiser l’illusion | Corriger le vrai problème |
| Résultat typique | Surcoûts post-déploiement | Solution plus adoptable et plus stable |
- Dépasser les idées préconçues et les récits de management.
- Comprendre les contraintes invisibles sur le papier.
- Concevoir une solution ancrée dans la réalité opérationnelle.
- Réduire les adaptations post-déploiement en traitant les causes tôt.
4. Le processus en 5 étapes : une approche méthodique.
Vous pouvez appliquer cette séquence sur un flux entier, ou sur un point de douleur précis. L’important est de rester factuel et orienté décision.
1. Préparation
- But
- Définir le périmètre, les hypothèses, et les questions à valider.
- Sortie
- Une liste de processus critiques et de métriques de terrain à observer.
À produire. 10 questions, 5 risques, 3 décisions attendues.
2. Immersion terrain
- But
- Observer les utilisateurs sans interférer.
- Sortie
- Une cartographie des gestes, écrans, documents, interruptions, et exceptions.
Règle. D’abord voir, ensuite expliquer.
3. Questionnement contextuel
- But
- Comprendre l’intention derrière l’action observée.
- Sortie
- Une liste de contraintes réelles et de règles implicites.
Astuce. Demander “qu’est-ce qui vous empêche de faire autrement”.
4. Documentation factuelle
- But
- Capturer le processus réel avec notes structurées, exemples, et cas d’exception.
- Sortie
- Une base de preuves utilisable en atelier de décision.
Règle. Une preuve vaut mieux qu’un avis.
5. Analyse et solution
- But
- Transformer les observations en décisions et recommandations ERP.
- Sortie
- Process cibles, règles de gestion, user stories, et priorités d’implémentation.
Règle. 1 observation = 1 décision, sinon cela reste du storytelling.
Résultats attendus
- Vous obtenez
- Une solution adaptée aux contraintes réelles.
- Vous facilitez
- L’adhésion des utilisateurs et la stabilité des processus.
- Vous réduisez
- Les risques projet et les surcoûts liés aux “surprises” terrain.
À retenir. La vérité se trouve sur le terrain, pas dans les rapports.
5. Exemple : toyota sienna et yuji yokoya.
L’ingénieur toyota yuji yokoya avait accès à des données clients complètes. Cela n’a pas suffi. Il a parcouru 55 000 miles à travers l’amérique du nord pour observer l’usage réel.
- Au nouveau-mexique, le rayon de braquage était insuffisant pour des rues étroites.
- Dans le midwest, les vents forts créaient des problèmes de stabilité.
- En alaska, sur routes de gravier, la direction ne répondait pas comme prévu.
- Dans la vie quotidienne, des irritants invisibles apparaissaient : accès aux enfants, rangement, bruit.
Les meilleures améliorations ne viennent pas d’une “analyse” supplémentaire. Elles viennent d’une observation qui change votre modèle mental. Le terrain transforme le produit parce qu’il transforme la compréhension.
6. Enjeux pour les projets ERP : quand la théorie rencontre la réalité.
Un ERP touche toute l’entreprise. Ces projets sont complexes, coûteux, et sensibles à l’adoption. L’une des causes majeures d’échec est la mauvaise compréhension des besoins réels et des contraintes du terrain.
6.1. Le cadrage : le point de bascule.
Le cadrage définit le périmètre, les processus cibles, les règles de gestion, et les arbitrages. Si cette phase est construite sur du déclaratif, les conséquences sont mécaniques : surcoûts, retards, fonctionnalités inutiles, et résistance des équipes.
Ce que le terrain révèle en cadrage
- Vous découvrez
- Les processus informels et les règles implicites.
- Vous clarifiez
- Les responsabilités réelles, pas seulement l’organigramme.
- Vous évitez
- De modéliser des inefficacités et de les industrialiser.
Décision à déclencher. Si un flux repose sur des “astuces”, alors il faut traiter la contrainte, pas supprimer l’astuce.
Le livrable utile
- Contenu
- Process cibles, décisions, règles de gestion, user stories, priorités.
- But
- Mettre la direction et le terrain d’accord sur “comment on veut travailler demain”.
- Risque évité
- Confondre “ce qu’on fait” et “ce qu’on devrait faire”.
À retenir. Un bon cadrage réduit le coût du changement, parce qu’il réduit les surprises.
6.2. Le POC : tester dans les conditions réelles.
Un POC en salle, avec des données fictives et des scénarios idéalisés, donne une fausse impression de réussite. Le vrai risque apparaît quand l’outil rencontre les contraintes : délais réels, interruptions, exceptions, ergonomie, et culture.
- Vrais utilisateurs sur leurs postes habituels.
- Données réelles et cas d’exception volontairement inclus.
- Mesures simples : temps de traitement, taux d’erreur, points de friction, acceptation.
- Décisions immédiates : corriger, simplifier, ou changer de design.
Vous ne validez pas seulement une faisabilité. Vous validez une utilisabilité. Et l’utilisabilité se prouve dans le contexte réel. Un POC ancré terrain est un anti-risque.
Immersion terrain, blueprint, user stories, et POC réaliste avec vos équipes.
Conclusion : pour comprendre, il faut voir par soi-même.
Genchi genbutsu est un appel à l’humilité intellectuelle. Il reconnaît que la connaissance la plus utile est celle acquise par l’observation directe. Cette posture évite les décisions “hors-sol” et accélère les bonnes.
Dans un projet ERP, cette méthode devient un levier de réussite : elle révèle les contraintes réelles, clarifie les arbitrages, et favorise l’adoption. Vous ne décidez plus depuis votre bureau. Vous allez voir.
- La vérité opérationnelle se trouve sur le terrain.
- Le cadrage doit être factuel, pas seulement déclaratif.
- Le POC doit être réalisé en conditions réelles, sinon il rassure à tort.
- Un ERP amplifie vos règles et vos pratiques, donc choisissez-les consciemment.
Genchi genbutsu : aller voir par soi-même avant de décider, et avant de déployer un ERP.
Vous connaissez la chanson : réunions, présentations, tableaux, reporting. On croit tout savoir depuis nos écrans. Erreur. La réalité opérationnelle ne se capture pas dans un rapport. Elle se vit, se ressent, et s’observe là où les choses se passent.
Montrer pourquoi le terrain est l’outil de diagnostic le plus fiable. Expliquer la méthode genchi genbutsu, illustrer son impact avec un cas emblématique, et traduire cette logique en pratiques concrètes pour sécuriser un projet ERP, notamment en cadrage et en POC.
0. Le problème : l’écran ment par omission.
Un reporting dit rarement comment le travail se fait réellement. Il décrit un processus “propre”, souvent idéal, parfois politique. Il oublie les contournements, les adaptations, les contraintes physiques, et les micro-décisions quotidiennes.
Or, un projet d’amélioration ou un déploiement ERP échoue rarement sur un grand principe. Il échoue sur une accumulation de détails invisibles. Ce sont ces détails que le terrain révèle.
Un bon diagnostic n’est pas une opinion. C’est une observation. Et une observation exige d’être au bon endroit, au bon moment, avec les bonnes questions.
1. Définition et origine : au cœur du toyota production system.
Genchi genbutsu est une méthode japonaise qui signifie “aller voir par soi-même”. Elle fait partie des piliers du TPS et a profondément influencé l’excellence opérationnelle au-delà de l’industrie.
Pour comprendre une situation, résoudre un problème, ou améliorer un processus, il faut se rendre sur le gemba. Il faut voir, écouter, mesurer, et comprendre les contraintes réelles. Pas dans une salle de réunion.
“Va sur le terrain pour voir de tes propres yeux”. Cette règle est simple. Son impact est radical.
Genchi genbutsu n’est pas une observation passive. C’est une investigation. Vous cherchez la réalité brute, non filtrée par les habitudes, les biais, ou les intérêts. Vous remplacez l’interprétation par la preuve.
2. Les 4 étapes fondamentales.
La méthode se résume en un cycle court. Elle vise à passer de l’observation à une solution alignée sur la réalité.
1. Aller sur le terrain
- Ce que vous faites
- Vous observez les activités réelles dans l’environnement de travail.
- Ce que vous cherchez
- Les gestes, les flux, les temps d’attente, les interruptions, les échanges informels.
Point de vigilance. Vous observez d’abord, vous expliquez ensuite.
2. Interroger les contraintes
- Ce que vous faites
- Vous questionnez les obstacles, détours, et adaptations non documentés.
- Ce que vous cherchez
- Les raisons : sécurité, qualité, charge, outillage, temps, responsabilités.
Point de vigilance. Une “mauvaise pratique” est souvent une réponse intelligente à une contrainte invisible.
3. Identifier les écarts
- Ce que vous faites
- Vous comparez le processus théorique et le processus réel.
- Ce que vous cherchez
- Les écarts qui créent du retard, des erreurs, du rework, ou de la frustration.
Point de vigilance. Vous cherchez la cause racine, pas le symptôme.
4. Adapter la solution
- Ce que vous faites
- Vous concevez une solution alignée sur les pratiques réelles, pas sur les fantasmes procéduraux.
- Ce que vous livrez
- Des règles simples, des workflows clairs, et des arbitrages explicités.
Point de vigilance. Un ERP ne “corrige” pas le terrain, il amplifie ce que vous standardisez.
3. Approche traditionnelle vs approche genchi genbutsu.
Les deux approches peuvent coexister. La différence est simple : l’une part du déclaratif, l’autre part du réel.
| Angle | Approche traditionnelle | Approche genchi genbutsu |
|---|---|---|
| Point de départ | Cahier des charges théorique | Observation concrète du terrain |
| Source principale | Ce que les gens disent faire | Ce que les gens font réellement |
| Représentation | Documentation procédurale | Adaptations et contournements réels |
| Risque dominant | Automatiser l’illusion | Corriger le vrai problème |
| Résultat typique | Surcoûts post-déploiement | Solution plus adoptable et plus stable |
- Dépasser les idées préconçues et les récits de management.
- Comprendre les contraintes invisibles sur le papier.
- Concevoir une solution ancrée dans la réalité opérationnelle.
- Réduire les adaptations post-déploiement en traitant les causes tôt.
4. Le processus en 5 étapes : une approche méthodique.
Vous pouvez appliquer cette séquence sur un flux entier, ou sur un point de douleur précis. L’important est de rester factuel et orienté décision.
1. Préparation
- But
- Définir le périmètre, les hypothèses, et les questions à valider.
- Sortie
- Une liste de processus critiques et de métriques de terrain à observer.
À produire. 10 questions, 5 risques, 3 décisions attendues.
2. Immersion terrain
- But
- Observer les utilisateurs sans interférer.
- Sortie
- Une cartographie des gestes, écrans, documents, interruptions, et exceptions.
Règle. D’abord voir, ensuite expliquer.
3. Questionnement contextuel
- But
- Comprendre l’intention derrière l’action observée.
- Sortie
- Une liste de contraintes réelles et de règles implicites.
Astuce. Demander “qu’est-ce qui vous empêche de faire autrement”.
4. Documentation factuelle
- But
- Capturer le processus réel avec notes structurées, exemples, et cas d’exception.
- Sortie
- Une base de preuves utilisable en atelier de décision.
Règle. Une preuve vaut mieux qu’un avis.
5. Analyse et solution
- But
- Transformer les observations en décisions et recommandations ERP.
- Sortie
- Process cibles, règles de gestion, user stories, et priorités d’implémentation.
Règle. 1 observation = 1 décision, sinon cela reste du storytelling.
Résultats attendus
- Vous obtenez
- Une solution adaptée aux contraintes réelles.
- Vous facilitez
- L’adhésion des utilisateurs et la stabilité des processus.
- Vous réduisez
- Les risques projet et les surcoûts liés aux “surprises” terrain.
À retenir. La vérité se trouve sur le terrain, pas dans les rapports.
5. Exemple : toyota sienna et yuji yokoya.
L’ingénieur toyota yuji yokoya avait accès à des données clients complètes. Cela n’a pas suffi. Il a parcouru 55 000 miles à travers l’amérique du nord pour observer l’usage réel.
- Au nouveau-mexique, le rayon de braquage était insuffisant pour des rues étroites.
- Dans le midwest, les vents forts créaient des problèmes de stabilité.
- En alaska, sur routes de gravier, la direction ne répondait pas comme prévu.
- Dans la vie quotidienne, des irritants invisibles apparaissaient : accès aux enfants, rangement, bruit.
Les meilleures améliorations ne viennent pas d’une “analyse” supplémentaire. Elles viennent d’une observation qui change votre modèle mental. Le terrain transforme le produit parce qu’il transforme la compréhension.
6. Enjeux pour les projets ERP : quand la théorie rencontre la réalité.
Un ERP touche toute l’entreprise. Ces projets sont complexes, coûteux, et sensibles à l’adoption. L’une des causes majeures d’échec est la mauvaise compréhension des besoins réels et des contraintes du terrain.
6.1. Le cadrage : le point de bascule.
Le cadrage définit le périmètre, les processus cibles, les règles de gestion, et les arbitrages. Si cette phase est construite sur du déclaratif, les conséquences sont mécaniques : surcoûts, retards, fonctionnalités inutiles, et résistance des équipes.
Ce que le terrain révèle en cadrage
- Vous découvrez
- Les processus informels et les règles implicites.
- Vous clarifiez
- Les responsabilités réelles, pas seulement l’organigramme.
- Vous évitez
- De modéliser des inefficacités et de les industrialiser.
Décision à déclencher. Si un flux repose sur des “astuces”, alors il faut traiter la contrainte, pas supprimer l’astuce.
Le livrable utile
- Contenu
- Process cibles, décisions, règles de gestion, user stories, priorités.
- But
- Mettre la direction et le terrain d’accord sur “comment on veut travailler demain”.
- Risque évité
- Confondre “ce qu’on fait” et “ce qu’on devrait faire”.
À retenir. Un bon cadrage réduit le coût du changement, parce qu’il réduit les surprises.
6.2. Le POC : tester dans les conditions réelles.
Un POC en salle, avec des données fictives et des scénarios idéalisés, donne une fausse impression de réussite. Le vrai risque apparaît quand l’outil rencontre les contraintes : délais réels, interruptions, exceptions, ergonomie, et culture.
- Vrais utilisateurs sur leurs postes habituels.
- Données réelles et cas d’exception volontairement inclus.
- Mesures simples : temps de traitement, taux d’erreur, points de friction, acceptation.
- Décisions immédiates : corriger, simplifier, ou changer de design.
Vous ne validez pas seulement une faisabilité. Vous validez une utilisabilité. Et l’utilisabilité se prouve dans le contexte réel. Un POC ancré terrain est un anti-risque.
Immersion terrain, blueprint, user stories, et POC réaliste avec vos équipes.
Conclusion : pour comprendre, il faut voir par soi-même.
Genchi genbutsu est un appel à l’humilité intellectuelle. Il reconnaît que la connaissance la plus utile est celle acquise par l’observation directe. Cette posture évite les décisions “hors-sol” et accélère les bonnes.
Dans un projet ERP, cette méthode devient un levier de réussite : elle révèle les contraintes réelles, clarifie les arbitrages, et favorise l’adoption. Vous ne décidez plus depuis votre bureau. Vous allez voir.
- La vérité opérationnelle se trouve sur le terrain.
- Le cadrage doit être factuel, pas seulement déclaratif.
- Le POC doit être réalisé en conditions réelles, sinon il rassure à tort.
- Un ERP amplifie vos règles et vos pratiques, donc choisissez-les consciemment.
Genchi Genbutsu :
aller voir par soi-même
Pilier du Toyota Production System, cette méthode transforme la façon dont nous comprenons les processus métier avant tout déploiement d'ERP
Genchi (lieu réel) + Genbutsu (objet réel)
« Va sur le terrain pour voir de tes propres yeux »
Les 4 étapes fondamentales :
ALLER SUR LE TERRAIN
Observer les activités réelles des utilisateurs dans leur environnement de travail
INTERROGER LES CONTRAINTES
Questionner les obstacles, détours et adaptations non documentés
IDENTIFIER LES ÉCARTS
Mesurer la différence entre processus théoriques et pratiques réelles
ADAPTER LA SOLUTION
Concevoir des solutions ERP alignées sur les pratiques réelles plutôt que théoriques
APPROCHE TRADITIONNELLE
APPROCHE GENCHI GENBUTSU
Cahier des charges théorique
Observation concrète du terrain
Ce que les gens disent faire
Ce que les gens font réellement
Documentation procédurale
Adaptations et contournements réels
Application sectorielle
Les clés du changement de paradigme :
- Dépasser les idées préconçues des managers
- Comprendre les contraintes réelles invisibles sur le papier
- Créer des solutions ancrées dans la réalité opérationnelle
- Réduire de 30% à 60% les coûts d'adaptation post-déploiement
« Pour comprendre, il faut voir par soi-même »
Taiichi Ohno, père du Toyota Production System
Genchi Genbutsu :
aller voir par soi-même
Pilier du Toyota Production System, cette méthode transforme la façon dont nous comprenons les processus métier avant tout déploiement d'ERP
Genchi (lieu réel) + Genbutsu (objet réel)
« Va sur le terrain pour voir de tes propres yeux »
Les 4 étapes fondamentales :
ALLER SUR LE TERRAIN
Observer les activités réelles des utilisateurs dans leur environnement de travail
INTERROGER LES CONTRAINTES
Questionner les obstacles, détours et adaptations non documentés
IDENTIFIER LES ÉCARTS
Mesurer la différence entre processus théoriques et pratiques réelles
ADAPTER LA SOLUTION
Concevoir des solutions ERP alignées sur les pratiques réelles plutôt que théoriques
APPROCHE TRADITIONNELLE
APPROCHE GENCHI GENBUTSU
Cahier des charges théorique
Observation concrète du terrain
Ce que les gens disent faire
Ce que les gens font réellement
Documentation procédurale
Adaptations et contournements réels
Application sectorielle
Les clés du changement de paradigme :
- Dépasser les idées préconçues des managers
- Comprendre les contraintes réelles invisibles sur le papier
- Créer des solutions ancrées dans la réalité opérationnelle
- Réduire de 30% à 60% les coûts d'adaptation post-déploiement
« Pour comprendre, il faut voir par soi-même »
Taiichi Ohno, père du Toyota Production System
Genchi Genbutsu : la méthode de cadrage des processus de l’entreprise