Face aux défis que doivent relever les acteurs de la Conception, du Développement et de l'Industrialisation des produits et des processus, l'approche Lean Thinking semble porteuse de réponses intéressantes, les solutions ayant été largement éprouvées en production.

Lorsque l’on évoque l’approche Lean en développement, on pense spontanément aux gaspillages et à vérifier l’existence et l’ampleur des 7 types de gaspillages (muda) dans ce domaine. Ceux-ci existent bien et s’enrichissent même de quelques autres selon le modèle du MIT.

Il ne faut cependant pas oublier les autres familles de gaspillages que sont les variabilités (mura) et les excès (muri).

Au sommaire de cet article :

Les muda en Développement
Sources de variabilités, Mura
Sources d’excès ou de surcharges, Muri
Autres dysfonctionnements ou gaspillages courants
Pratiques, outils et méthodes de gestion de projets

Les muda en Développement

Tout comme en production, les muda en Développement sont probablement les plus faciles à appréhender. Le Développement peut être assimilé à une usine à produire et/ou traiter des données. Celles-ci et les ressources utilisées sont victimes des mêmes muda qu’en Production.

Le site Lean Advancement Initiative du célèbre MIT propose 10 types de gaspillages (waste drivers) en « Product Development », assortis d’une quarantaine de causes (subdrivers), identifiés au travers de l’analyse de 300 "problèmes typiques". Ils sont retranscrits partiellement par mes soins dans le tableau ci-dessous.

Attentes	Libération des ressources (humaines ou technologiques) Données ou informations attendent leur destinataire ou plus généralement une action humaine Attente de données, de réponses, spécifications, résultats de tests, approbations, décisions, validations, révisions, signatures
Transports / transferts	Communication inefficace Interruptions et travail multitâche Transmission de données / fichiers / informations Échanges de données excessifs
Déplacements	Chasse aux informations, aux données Déplacements physiques vers des lieux distants Absence / manque d’accès direct à des sources de données ou des ressources
Surtravail	Utilisation de compétences inadéquates Fonctionnalités ou processus inutiles Détails et/ou précision excessifs Méthodes et/ou outils inappropriés Validations en nombre excessif Nombre excessif de transactions Données d’entrée incomplètes Changements de spécifications
Stocks / encours	File d’attente sur le chemin critique (capacité saturée, grande variabilité, taille des lots importants) Tests inutiles et nombre excessifs de prototypes Stockage de données excessif
Surproduction et manque de synchronisation	Mauvaise synchronisation temporelle et capacités différentes entre ressources Mauvaise synchronisation des contenus Dissémination excessive des informations Tâches redondantes Planification à capacité infinie
Défauts	Qualité d’information déficiente Erreurs dans les données et informations Porosité des tests et vérifications Priorité à la tenue des délais
Manque de discipline	Objectifs flous Rôles, responsabilités et droits mal définis, interprétables, flous Règles floues Volonté de coopération insuffisante Ordonnancement non respecté Incompétence ou manque de formation
Ressources informatiques limitées	Manque de compatibilité Manque de capabilité Manque de capacité Droits d’accès trop restrictifs
Réinvention	Faible taux de réemploi Trop peu de retours d’expériences Manque de capitalisation Satisfaction de l’égo ; volonté d’inventer, de briller

Sources de variabilités, Mura

Les sources de variabilité fréquemment rencontrées en développement, sont multiples :

Changements fréquents imposés par les clients ou le chef de projet,
Hypothèses en lieu et place de données fiables, qui obligent à reprendre l'étude une fois les données certifiées,
Inconstance des données, par exemple les cotes ou tolérances qui changent fréquemment,
Une option nouvelle qui doit être proposée rapidement, en alternative,
Le multitâche !

Ces changements et interruptions représentent des ruptures de charge, des perturbations du flux, des risques potentiels d'erreurs et de dépassement de délais.

Lorsque de telles causes sont identifiées, ou tout du moins lorsque des indices laissent à penser qu'elles existent, la méthode d'analyse des 5 pourquoi? permet de remonter à leurs causes racines et chercher à les éliminer ou au moins en réduire leur "toxicité".

Sources d’excès ou de surcharges, les Muri

L'inadéquation des moyens et ressources aux besoins est également considéré comme un genre de gaspillage. Cette familles, nommée "Muri", est certainement la plus délicate à débusquer. Dans un environnement de Développement, nous pouvons trouver :

Les moyens de calcul ou de traitement inadéquats ; stations trop peu puissantes, trop sollicitées
Nombre limité d'accès ou de licences, qui oblige à gérer des files d'attente, des priorités
Dessins ou simulations demandés en nombre inutilement excessifs
Essais, tests, contrôles ou analyses surnuméraires, inutiles qui engorgent les labos, surchargent les techniciens ou saturent les moyens,
Bande passante du réseau inadéquate, espace de stockage de données inadapté,
Etc.

Les Muri sont sources d'irritations et de sous-performance. Les stations de travail inadaptées peuvent se révéler ressources goulot et conditionner de manière significative la tenue des délais. L'exagération des demandes de calculs ou de dessins peuvent saturer les capacités des personnels et/ou des stations de travail. Dans ce cas ce n'est pas la capacité installée qui est en cause, mais sa mauvaise utilisation par des sollicitations inutiles.

Autres dysfonctionnements courants

D’autres sources d’erreurs et de sous-performance et nombre de facteurs de perturbation existent également et pèsent sur les coûts, la qualité et la rapidité des développements.

Citons les contraintes (réelles ou auto-imposées) souvent nombreuses, qui peuvent être normatives, réglementaires, contractuelles, organisationnelles, etc.

Les dépendances à des acteurs externes multiplient les échanges, attentes et transaction et de fait les ruptures de charge dans le processus. Cela peut être attendre une réponse d’un client, d’un prestataire, d’un fournisseur ou d’une autorité par exemple. Ceci sans même évoquer la gestion ordinaire des interfaces (fournisseurs, clients internes et externes…).

La complétude et la fiabilité des données initiales à chaque étape du processus est une condition sine qua non pour assurer l’exécution sans délai ni erreur en aval. Pour autant, combien de fois cette condition est-elle réellement remplie ?

De ce fait ainsi que pour d’autres raisons, existe-t-il des retours en arrières et des boucles (révisions, refaisage, corrections…)

Cette liste de dysfonctionnements, de gaspillages et d’irritants est déjà longue sans être exhaustive.

Pratiques, outils et méthodes de gestion de projets

Nous supposerons que les basiques d’une organisation mature, avec des pratiques, outils et méthodes de gestion de projets, sont en place et fonctionnent, faute de quoi leur manque risque de peser également sur la performance :

Les tableaux de bord et indicateurs, de préférence visuels
Les rôles et responsabilités clairement définis, au travers d’une matrice RASCI (Responsable, Accountable, Support, Consulted, Informed), par exemple
L’intégration des fournisseurs et des clients internes et externes dans le processus de développement, dès les étapes très en amont,
Les efforts d’anticipations et de prévention des dérives et non qualité
La robustesse du processus, délivre-t-il "bon du premier coup" ?
La mutualisation des bonnes pratiques
Le taux de réemploi des solutions, fonctions, pièces ou éléments déjà développés
Les goulots identifiés et gérés de manière adéquate (approche CCPM, "kanban", agile…)
Une approche DFSS (Design For Six Sigma) DFMA (Design For Manufacturing and Assembly), qui pense la performance future en production
La connaissance des processus aval et les conséquences des décisions en phase de développement
La connaissance et/ou sensibilité au tryptique coût, qualité, délais, à la notion de valeur