SMED, surmontons nos limites

Comment Toyota a révolutionné la technologie des presses mécaniques pour pousser une stratégie business jusqu’au bout, et 2 morales de cette histoire pour la DSI.

Une brève histoire du SMED chez Toyota

Toyota a toujours cherché à diminuer la taille des lots traités, dans la poursuite d’objectifs business multiples :

• Livrer plus vite ses clients en réduisant le temps de cycle
• Diminuer les coûts de gestion des stocks (notamment à cause du coût exorbitant du terrain au Japon)
• Adapter rapidement les produits en cours de production à la demande

Problème, si les coûts unitaires de gestion du stock diminuent avec la taille des lots, les coûts unitaires de reconfiguration des postes augmentent inversement : plus de petits lots => plus d’opérations de reconfiguration des postes à l’entrée d’un nouveau lot => augmentation du coût unitaire.

Disons qu’avant que Toyota ne se penche sur ce problème, l’optimum du coût unitaire s’appuyait « par défaut » sur des lots de grande taille, en considérant le temps de configuration comme LA contrainte irrémédiable.

Shigeo Shingo (un des pères fondateurs du Lean) a refusé cette contrainte comme inhérente à leur métier. La reconfiguration la plus chronophage était celle des presses qui emboutissent les tôles et qui nécessitent un placement précis au millimètre. En s’attaquant efficacement à la phase de reconfiguration des presses, Toyota l’a diminué de 97% entre 1975 et 1985, en atteignant des temps de reconfiguration de l’ordre de la minute. C’est le Single Minute Exchange of Die (SMED, die = presse en anglais).

En sommes, rien ne devait empêcher Toyota de réduire la taille des lots traités, y compris le temps de l’opération de reconfiguration des presses, considéré comme un postulat fondamental gravé dans le marbre.

2 morales en IT

La première morale dans nos activités IT est très proche de notre histoire Lean : réduire la taille des lots est une bonne chose pour le business et tous les coups sont permis pour y arriver.

Dans nos métiers il s’agit de livrer fréquemment des incréments utilisables. Pour beaucoup de projets la contrainte des recettes fonctionnelles manuelles est un frein : plutôt que de livrer 2 incréments de 3 mois on préfère livrer 1 gros incrément de 6 mois en mutualisant la recette manuelle longue et coûteuse.

Dans d’autres projets se présentant comme « agile », on observe des itérations de 2 mois, souvent allongées à cause des phases de recette manuelle très longues (disons de l’ordre de la semaine). Au pied de la lettre du manifeste agile (écrit en 2001), ces itérations sont bien "agiles". Toutefois les retours d’expérience de la dernière décennie ont montré tous les bénéfices des itérations courtes (d’une semaine à deux) en termes de réactivité et d’efficacité des feed-back courts.

Quelques exemples parmi d’autres. Par rapport aux équipes d’itération de 2 mois, les équipes d’itération de 2 semaines :

• soumettent leur livrables et receuillent du feed-back utilisateur 4 fois plus souvent
• se confrontent aux difficultés du déploiement/intégration 4 fois plus souvent
• améliorent 4 fois plus vite leur processus de développement sur la base des retrospéctives d’itération

Faisons le parallèle avec le SMED du Lean. La recette de non régression exhaustive n’est pas notre « setup » mais c’est bien notre « Exchange of Die » : répétitif, couteux, fastidieux et nous empêchant de réduire la taille de nos lots. Dans les pas de Shigeo Shingo nous devons nous demander comment diminuer le coût de cette recette fonctionnelle. Ca passera par exemple par l’automatisation des tests de non régression fonctionnelle, autour de démarches de spécification par les tests et d’outil de type Fitnesse ou GreenPepper. Après la mise en place de ce type de tests, on observe des coûts marginaux de non régression de 1 heure.homme sur les règles métier, contre 80 j.h en recette manuelle !

Cette première morale peut s’appliquer à toutes les activités qui nous paraissent un frein à la livraison fréquente de petits lots : les phases de prise en compte du feed-back utilisateur, les déploiements, etc.

La seconde morale consiste à prendre un peu de recul : si les principes sous-jacents d’un changement sont sains pour le business, nous acteurs de la DSI, devons nous efforcer de remettre en cause les façons de faire actuelles qui nous empêchent de suivre ces principes.