Récemment, un groupe de mes collègues de Planview AgilePlace et moi-même parlions de Kanban. Le sempiternel débat sur les définitions du délai d'exécution et du temps de cycle a été soulevé, et nous avons tous un peu roulé des yeux. La communauté Lean a déjà rabâché ce sujet un million de fois, mais il semble que nous n'arrivions toujours pas à trouver un consensus. Le sujet peut être déroutant pour les personnes qui découvrent Kanban, et frustre immanquablement les praticiens expérimentés. Dans ce billet, j'expliquerai pourquoi ces définitions sont couramment débattues. Je vous expliquerai également comment une simple définition peut vous aider à tirer le meilleur parti de ces mesures Lean.
Quand l'horloge commence-t-elle ?
Le débat autour du délai d'exécution et du temps de cycle est essentiellement le suivant : Quand l'horloge commence-t-elle ?
Les personnes novices en matière de Kanban pensent souvent que le délai d'exécution correspond au temps qui s'écoule entre le moment où un travail est demandé et celui où il commence effectivement.
L'idée la plus communément admise est que le délai commence avec la demande d'un client et se termine lorsque la valeur est livrée à ce client.
Mais qu'est-ce qu'une demande ? Dans la production allégée traditionnelle, une demande représente une commande du client pour un produit physique.
Dans le travail de la connaissance, une demande peut être beaucoup plus intangible : Pour utiliser un exemple tiré du développement de logiciels, il peut s'agir d'une idée non vérifiée pour une fonctionnalité. Cette idée pourrait devoir passer par un processus de priorisation avant même d'être placée dans le backlog d'une équipe. La question devient alors : L'horloge a-t-elle commencé à tourner - lorsque nous avons eu l'idée, ou lorsqu'elle a été ajoutée au backlog ?
C'est à ce moment que la définition du délai d'exécution et du temps de cycle peut devenir délicate. Les termes sont souvent utilisés de manière interchangeable. Lorsque cela se produit, les métriques qui les sous-tendent perdent leur sens.
C'est pourquoi certains ont remplacé le terme de délai d'exécution par des termes plus spécifiques : délai d'exécution client, par exemple, ou délai d'exécution système. Cela permet de clarifier exactement ce qui est mesuré, et pour qui.
Au lieu de vous débattre avec ces différences, commencez par les bases. Posez-vous la question : Quel problème est-ce que j'essaie de résoudre avec ces mesures ?
Avec toutes les mesures, demandez d'abord "pourquoi" ?
J'ai posé cette question à mes collègues de travail au cours de notre conversation. L'un d'eux a dit : "Nous devons connaître le temps de cycle pour savoir à quelle vitesse nous pouvons produire quelque chose."
"Ok," j'ai dit, "Pourquoi ?"
Cela a suscité plusieurs regards confus, mais j'ai continué : "Peu importe comment vous les définissez, le délai d'exécution et le temps de cycle sont des mesures. Nous perdons du temps à débattre de ce qu'ils mesurent exactement.
Prenons un peu de recul et demandons-nous pourquoi nous voulons connaître ces informations en premier lieu."
La discussion qui a suivi a été beaucoup plus productive. Nous avons tous convenu que nous voulions connaître ces informations afin de pouvoir faire de meilleures prévisions concernant notre travail.
Un exemple
Disons qu'une demande de fonctionnalité d'un nouveau produit nous parvient des ventes. Logiquement, la première question que posent les vendeurs est : "Quand puis-je espérer que cette fonctionnalité soit réalisée ?"
Vous pouvez estimer que la fonctionnalité pourrait prendre environ 10 jours. Mais les ventes doivent-elles s'attendre à voir la fonctionnalité dans 10 jours ? Non.
Pourquoi ? Parce que leur demande est traitée en priorité avec toutes les autres demandes en cours.
Pourquoi ? Leur demande est classée en priorité avec toutes les autres demandes en cours. Ainsi, si le délai moyen entre la demande et la livraison (lead time) est de 10 jours, et qu'il y a 4 articles dans la file d'attente avant cette nouvelle demande des ventes, nous prévoyons que la demande sera très probablement livrée en 50 jours. (10 jours par caractéristique, fois cinq.)
Remarque : Nous devons être prudents avec ces types de prévisions car l'utilisation d'une moyenne ne reflète pas toujours le degré de variation qui est courant dans le travail de connaissance.
Comment nous définissons les délais et les temps de cycle
Délai d'exécution
Chez Planview AgilePlace, nous définissons le délai d'exécution comme le temps qui s'écoule entre le moment où une demande est faite et celui où elle est livrée au client. Nous qualifions souvent le terme de "délai d'exécution pour le client" pour nous rappeler que cette mesure se situe du point de vue du client.
Bien sûr, nous ne pouvons pas commencer chaque travail dès que la demande est faite. Ce serait insoutenable, pour ne pas dire imprudent. Lorsqu'une demande est faite, elle passe généralement un certain temps dans le backlog avant que l'on y travaille. Pour optimiser notre façon de travailler, nous devons examiner une mesure plus granulaire. C'est pourquoi il est précieux de mesurer à la fois le délai d'exécution, tel que décrit ci-dessus, et le temps de cycle.
Temps de cycle
La durée du cycle est le temps qui s'écoule entre le moment où le travail commence réellement sur une demande et le moment où elle est livrée au client final. Le temps de cycle mesure tous les temps de travail actifs (à valeur ajoutée) ainsi que les états d'attente entre les temps de travail actifs. Il est utile de mesurer le temps de cycle pour avoir une idée de l'efficacité de votre système. Daniel Vacanti vient de publier un excellent billet sur pour expliquer comment calculer le temps de cycle.
Temps de cycle des processus
Pour encore plus de détails, il peut être utile d'analyser également le temps de cycle des processus individuels. Si vous voulez savoir avec quelle efficacité votre équipe fait passer le travail par l'étape "conception", par exemple, vous mesurerez votre temps de cycle de conception. Pour le temps de cycle de conception, l'horloge démarre lorsque le travail entre dans le couloir de conception et s'arrête lorsqu'il passe au couloir suivant. Mesurer la durée du cycle de conception pour plusieurs éléments de travail vous permettrait de comprendre combien de temps il faut pour que le travail passe par l'étape de conception.
Si vous optimisez chaque étape autant que possible, et que votre temps de cycle total est toujours lent, il peut y avoir une explication simple : Les transferts. Pour la plupart des systèmes, la majorité du gaspillage se situe dans les états d'attente entre les étapes - et non dans les étapes elles-mêmes. Mesurer les temps de cycle individuels peut vous aider à identifier les transferts lents et autres obstacles au flux.
Utiliser les métriques à bon escient
Le délai d'exécution et le temps de cycle peuvent nous aider à prévoir quand les éléments de nos arriérés pourraient être achevés. Cela nous aide à communiquer plus efficacement avec nos parties prenantes.
L'étude des temps de cycle des processus peut nous aider à identifier les possibilités d'améliorer le flux. La réduction de nos temps de cycle signifie un meilleur flux, ce qui signifie que nous pouvons livrer nos clients plus rapidement.
Nous devons veiller à ce que nos efforts pour réduire le délai d'exécution et la durée du cycle n'aient pas un impact négatif en aval sur d'autres parties de l'entreprise (qualité du produit, satisfaction du client, etc.). La vitesse à laquelle les articles passent par notre processus n'est qu'un indicateur de la qualité de nos prestations et doit être équilibrée par d'autres mesures clés. Pour en savoir plus sur les dangers des vanity metrics, consultez ce post .
Lorsque nous passons du débat sur les termes aux raisons pour lesquelles ces mesures sont importantes, nous pouvons commencer à les utiliser efficacement dans nos équipes. Si nous parvenons à faire passer la conversation du "quoi" au "pourquoi", nous pourrons commencer à nous concentrer sur ce qui compte vraiment : améliorer la fourniture de valeur à nos clients.
