Christian HOHMANN

Depuis 1998

  • Augmenter la taille
  • Taille par défaut
  • Diminuer la taille

Les gaspillages en Développement

Envoyer

Christian HOHMANN

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

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 :

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






View Christian HOHMANN's profile on LinkedIn

Mise à jour le Samedi, 27 Août 2016 05:45  

Sujets similaires