Erika Souza de Melo |

Le premier paradoxe de Toyota fait référence au processus de production, le Toyota Production System (TPS), où la réduction du gaspillage et la recherche de la valeur ajoutée sont des priorités. Le second paradoxe de Toyota concerne le processus de développement de produits qui selon Ward et al. (1995), a permis à Toyota de finaliser ses projets de développement de voitures plus rapidement que d’autres entreprises. L’objectif de cet article est de présenter ce second paradoxe.

Imaginons qu’il soit nécessaire de planifier une réunion avec trois collègues. Nous appelons le premier et constatons qu’il serait disponible mercredi après-midi. Nous appelons le deuxième et lui demandons s’il serait disponible pour la réunion mercredi après-midi, malheureusement, il indique que non et propose une nouvelle date. Cela nécessite de rappeler le premier collègue pour vérifier s’il peut participer à la nouvelle date, et ainsi de suite jusqu’à ce que les trois collègues confirment qu’ils pourront être présents à une même date et heure qui leur convient.

Le second paradoxe de Toyota serait comme si, au lieu de téléphoner à chaque collègue, nous envoyions un “Doodle” et chaque collègue pourrait indiquer sa disponibilité. Ainsi, les dates auxquelles les participants à la réunion ne sont pas disponibles sont exclues du processus décisionnel, et seules les dates auxquelles les participants à la réunion sont disponibles sont prises en compte. Cela permet de déterminer la date de la réunion plus rapidement, et il y a plus de chances que les participants soient présents à la réunion.

On constate qu’au lieu de réaliser des activités de manière séquentielle et itérative – appeler un collègue à la fois, ce que Ward et al. (1995) définissent comme point-based design (PBD), les activités sont réalisées simultanément – remplissage d’un tableau de disponibilités, défini par Ward et al. (1995) comme set-based concurrent engineering (SBD), c’est-à-dire le second paradoxe de Toyota.

Ce paradoxe est intéressant pour deux raisons majeures.

La première raison tient au fait qu’il est contraire aux pratiques conventionnelles de projets de développement de produits (PDP) comme illustré dans le Tableau 1 (Kennedy et al., 2014).

Tableau 1

Pratiques PDPConventionnellesToyota
Gel des définitions techniquesLe plus tôt possibleLe plus tard possible
Proposition de solutions et prototypagePeuNombreux
ProcessusSéquentiel et itératifSimultané
Logique du processusCycles de conception, de production et de testStratégie de test, d'apprentissage, de définition
Communication avec les fournisseursBeaucoupPeu

La seconde raison tient au fait que les résultats du PDP de Toyota ont été meilleurs que ceux d’autres entreprises japonaises et américaines selon Ward et al. (1995). De plus, les pratiques de Toyota semblent contribuer à minimiser les problèmes systémiques des pratiques conventionnelles de PDPs (comme discuté dans l’article précédent) et illustrés dans le Tableau 2.

Tableau 2

Problèmes systémiques des pratiques conventionnelles de PDPsContributions du PDP de Toyota à la mitigation des problèmes systémiques des pratiques conventionnelles de PDPs
Les décisions importantes sont prises dans la phase initiale même si peu d'informations sont disponibles.Report de la prise de décision au maximum. Le prototypage est réalisé pour réduire les lacunes de connaissance et permettre une prise de décision plus assertive, fiable et moins risquée.
La liberté dans la définition du produit diminue tout au long du cycle de vie du projet en raison des décisions précédentes.Au lieu de travailler avec des définitions ponctuelles, Toyota travaille avec un « espace » de définitions où les solutions faisables et infaisables sont identifiées.
De nouvelles informations tout au long du cycle de vie du projet invalident les hypothèses et décisions antérieures, résultant en retravail et coûts supplémentaires, et un potentiel retard du projet.L’« espace » de définitions réduit l'effet boule de neige du changement si une décision antérieure est invalidée.

Il y a beaucoup derrière la culture Toyota qui lui permet de confronter les pratiques conventionnelles de PDPs, par exemple, une bonne relation à long terme avec les fournisseurs qui permet aux fournisseurs de travailler de manière autonome dans l’« espace » de définitions déterminé par Toyota et de réduire la fréquence des communications. Il y a aussi la pratique des livres de leçons apprises qui sont utilisés pour refléter l’expérience des ingénieurs par rapport aux contraintes de la fabrication et ainsi proposer des définitions techniques plus assertives (Ward et al., 1995). En fin de compte, Toyota nous enseigne que l’agilité et la discipline procédurale peuvent se produire conjointement et donner d’excellents résultats. Un exemple plus récent d’application du second paradoxe de Toyota est disponible dans Edward (2022) dans une étude de cas sur le développement d’un navire de guerre américain.

Bibliographie

Edward, J. (2022). A Model for Set-Based Design at the System-of-Systems Scale with Approaches for Emergent Properties [Massachusetts Institute of Technology].

Kennedy, B. M., Sobek, D. K. et Kennedy, M. N. (2014). Reducing Rework by Applying Set-Based Practices Early in the Systems Engineering Process. Systems Engineering, 17(3), 278-296.

Ward, A., Liker, J., Cristiano, J. et Sobek, D. (1995, 19950401). The second toyota paradox: How delaying decisions can make better cars faster. Sloan Management Review, 36(3), 43.

À propos de l’auteur

Erika Souza de Melo

Elle est diplômée en génie électrique (baccalauréat et maîtrise). Elle détient également un MBA et un DBA dans le domaine de la gestion de projet. Erika a consacré sa thèse de doctorat sur le retravail de conception technique en projet de développement de produit aéronautique. Elle a travaillé au sein de grandes entreprises du secteur automobile et aéronautique, dont Delphi Automotive Systems, Airbus Hélicoptères, Embraer et Bombardier aviation. Elle est professeure en gestion de projet à l’Université du Québec à Rimouski (UQAR). Ses intérêts de recherche portent sur les erreurs et le retravail, le changement d’ingénierie, la prise de décision dans la gestion de projets de développement de produits complexes.