80 likes | 180 Views
Pratiques Lean dans le développement. Michael Ballé Projet Lean Entreprise. Gestion des ressources. Planning produit rigoureux pour mieux utiliser la ressource de développement Séparer l’innovation technologique des projets de développement destinés aux clients
E N D
Pratiques Lean dans le développement Michael Ballé Projet Lean Entreprise
Gestion des ressources • Planning produit rigoureux pour mieux utiliser la ressource de développement • Séparer l’innovation technologique des projets de développement destinés aux clients • Donner la responsabilité de la signature et de l’architecture du produit à un « Chief Engineer », de la vision client, à la livraison en production • Créer des « Simultaneous Engineers » venant du manufacturing engineering pour suivre le développement de chaque sous-ensemble
Processus projet • Une première phase exploratoire du CE pour bien comprendre les critères client, et la position du produit dans la gamme, les capacités des usines, qui se traduit par un « concept paper » • Charger l’amont du développement par une phase de concurrent engineering sur la définition du produit et la planification du projet • Une phase de design détaillé extrêmement standardisée au niveau des solutions techniques, process et pièces • Travailler les prototypes, outils et tests selon des méthodes de lean manufacturing
Contrôle du développement • Une fonction très forte de Value Engineering en amont du projet pour définir: • Target cost • Qualité fonctionnelle • Planning détaillé • Utilisation systématique des « tear downs » pour fixer les target costs • Pas de « gate reviews » mais des « design reviews » étagées selon les principaux milestones du projet • Exploration parallèle de plusieurs solutions dans les phases amont
Intégration du produit • Pas de collocation, mais une « war room » utilisée fréquemment par les chefs fonctionnels concernés par les projets en cours pour faire un « build » deux fois par semaine • Le CE et les SE vont constamment voir les ingénieurs pour voir où ils en sont, ce qu’ils font, rapports réguliers d’avancement • Assister au « slow build » des prototypes et décisions prises sur le champ • Un « white paper » après le SOP pour faire le point sur les difficultés et modifs à faire
Technologies de support • Les innovations techniques en matière d’informatique sont utilisée de manière ciblée • Intégration des systèmes pour passer d’un système à l’autre facilement • Simulations pour réduire le nombre de prototypes • La technologie au service des hommes et du process, et non le contraire
Management des ingénieurs • Développer la compétence technique par des carrières fonctionnelles • Chaque ingénieur est coaché par un mentor, qui lui apprend la technique ET la résolution de problèmes • Intégration des ingénieurs des fournisseurs dans les équipes de développement • Des standards écrits pour tout, sous formes de checklists, A3, etc. • Une remise en cause des standards permanentes, par un mécanisme de « hansei » réguliers et de post-mortems, analyse des modifs
Conclusions • Compétence technique pointue compensée par nombreux mécanismes d’intégration • Obsession de la satisfaction du client et du fonctionnement systémique du produit • Adhésion aux standards et remise en cause systématique des standards lors de séances de « hansei » • La révolution permanente par des challenge techniques audacieux