La théorie des contraintes

La première règle de la théorie des contraintes d’Eli Goldratt pourrait paraître contre-intuitive : optimiser chaque étape d’un processus ne permet pas d’obtenir le meilleur ROI à la création de valeur globale.

Pourquoi ? Parce que certaines étapes limitent la création de valeur du processus global, et c’est pourquoi il les appelle des bottlenecks, ou goulots.
Prenons un exemple simple : je suis capable de produire 100 pièces à l’heure, mais je ne suis capable d’en assembler que 80 à l’heure. Si j’optimise tout de 10%, à quoi donc me servirait de produire 110 pièces à l’heure si je ne peux toujours en assembler que 88 ?

Dans le digital comme dans l’industrie, la théorie des contraintes nous encourage à analyser notre processus dans son entièreté, à détecter les bottlenecks, et à décider de porter des efforts ciblés plutôt que d’uniformiser les demandes d’optimisation. A mon sens, elle nous encourage aussi à quitter l’abstraction des pourcentages pour considérer la réalité des volumes. Si j’augmente mes commandes Internet et ma logistique Internet de 10%, est ce que je suis certain de ne pas avoir renforcé un bottleneck tuant ma performance potentielle ?

Goldratt propose une approche pragmatique pour augmenter la performance :
1. Identifier la contrainte
2. Diminuer la contrainte jusqu’à un seuil souhaité évitant la déperdition du processus (ce qui n’est pas la faire disparaître, il y a souvent une notion de ROI diminuant)
3. S’organiser autour de la contrainte (elle est toujours priorisée sur les étapes surproductives)
4. Faire disparaître la contrainte si élever la performance globale du process est la finalité
5. Retour à l’étape 1 : Identifier la nouvelle contrainte du processus

Les approches agiles et kanban permettent de détecter des bottlenecks simplement en regardant où les tâches s’accumulent, ou alors en regardant où se génère en premier non la non-qualité.
Trop de besoins et pas assez de gens pour spécifier ?
Trop de devs front, pas assez de back ?
Trop de devs et pas assez de testeurs ?
Trop d’applis et pas assez d’exploitants ?
Trop de projets et pas assez de chefs de projets ?

Posted in Non classé.

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *