Efficience sur VSM

[Yannick Quenec'hdu]

Bonjour,

 J'ai récemment étudié l'efficience de 2 projets en Kanban via une cartographie en VSM. J'obtiens des chiffres assez faibles, surtout parce que le temps de mise en production est très long. Pour les deux projets, j'obtiens 14% et 17%. 

 J'ai fait un point avec mon client à ce sujet, ce dernier se dit choqué par mes chiffres, ils refusent d'ailleurs d'admettre le résultat. Même après une explication pragmatique et factuelle de la démarche. 

 J'avais lu dans l'ouvrage de Laurent cette phrase "Sophie n'a pas à être surprise. Ce résultat est classique pour une équipe Scrum. L'efficience d'un système en cycle en V peut être encore plus faible entre 5% et 10". J'ai repris la fin de cette phrase devant mon client. Ce dernier me demande d'où provient cette source de données. 

Voilà donc ma question, j'ai réalisé de multiples recherches sur ce sujet sur le net. Mais je n'ai rien trouvé sur le sujet. Quelques un a des informations complémentaires pour étayer ces informations, que ce soit sur l'efficience Scrum et/ou en cycle en V. 

Merci de votre retour

Yannick  

[Arnaud Bailly]

Bonjour,

Pardonnez mon ignorance, mais comment sont calculés ces chiffres ? Et que signifient-ils ?

Merci et bonne année à tous,

--

Arnaud Bailly

FoldLabs Associate: http://foldlabs.com

2014/1/7 Yannick Quenec'hdu <yquen...@xebia.fr>

--
Vous recevez ce message, car vous êtes abonné au groupe Google Groupes KanbanDevFr.
Pour vous désabonner de ce groupe et ne plus recevoir d'e-mails le concernant, envoyez un e-mail à l'adresse kanbandevfr...@googlegroups.com.
Pour plus d'options, visitez le site https://groups.google.com/groups/opt_out .

[laurent morisseau]

Salut Yannick,

De mon côté, ce chiffre vient d'abord de ma propre expérience: entre 5 et 10%. Ensuite, j'ai pu constaté que d'autres avançaient les mêmes ordre de grandeur. Anderson annonce une fourchette de 5 à 15% : "Flow efficiencies of 2% have been reported*. 5% -> 15% is normal, > 40% is good!" dans sa keynote Kanban, an alternative path to agility, Ohio, 2013.

C'est une valeur que j'ai trouvé dans différents ouvrages Lean IT, sans pour autant être spécifique au cycle en V.

Des exemples sont donnés par Poppendieck dans leading LSD sont de 14%; dans implementing LSD, elle donne l'exemple d'une feature haut priorité avec une efficience de 33% dans une organisation et de 1% pour une autre, d'une efficience de 23 à 33 % pour les fast- track project d'une organisation,19% pour des projets moyens d'une organisation normale... Ce ne sont que des exemples. L'efficience est calculée par rapport aux tâches à valeurs ajoutées. Les efficiences précédentes sont des efficiences gentilles ou la correction, les tests, .. sont considérées comme des tâches à valeurs ajoutées. L'efficience réelle serait surement encore plus basse.

Ce ne sont que des exemples. L'ordre de grandeur est plus important: 5 à 15/20 % est normal pour les projets. Au-delà on est déjà dans des flux qui commencent à être optimisés du point de vue du délai.

Laurent

[Yannick Quenec'hdu]

Salut Laurent

Merci pour ta réactivité et la qualité de la réponse. Il est difficile pour un manager d'accepter que l'efficience de leur projet est de 10 à 15%.

A bientôt

Yannick 

[Yannick Quenec'hdu]

Le mardi 7 janvier 2014 23:09:09 UTC+1, Yannick Quenec'hdu a écrit :

[Yannick Quenec'hdu]

Bonjour Arnaud,

 La signification des chiffres est de montrer l'efficience du système en terme de valeur.  Pour ce faire, on fait la différence entre les temps d'attente et les temps à valeur ajoutée (temps travaillé sur un élément)

Quand tu travailles dans un projet, une fonctionnalité passe de l'idée jusqu'a mise en production. Durant ce passage, il y a des temps d'attente et des temps à valeur ajoutée.

Pour le calculer, nous utilisons une VSM (une chaine de valeur, le flux de création de produit) et nous positionnons des indicateurs pour mesurer le temps de cycle et le temps de traversée.

Voici un bon exemple, voici un lien de l'ouvrage de Laurent Morisseau qui vous permettra de comprendre le principe. 

http://www.morisseauconsulting.com/2012/06/06/myprojectstuff-episode-11/

Pour ma part, mes calculs sont réalisés sur des moyennes de plus de 100 User Stories sur un flux en une dizaine d'étapes pour arrivée en production.

A votre disposition pour plus d'informations

Bonne journée

Yannick

Le mardi 7 janvier 2014 23:09:09 UTC+1, Yannick Quenec'hdu a écrit :

[Dimitri BAELI]

Ma compréhension basique de l'efficience est :

    L'efficience c'est le rapport entre le temps passé à travailler sur la tache et le temps qui s'est écoulé (une sorte de rendement). Si une tache de 2j de développement met 10j à aller de la demande à la production, alors l'efficience est de 20%.

   

   Ce qui me semble difficile c'est de savoir quand commencer le chronomètre, et comment calculer le temps passé effectivement. Et savoir si on compte double si 2 personnes travaillent sur la tache le même jour (ce qui serait logique, mais pourrait générer des efficiences supérieures à 100%).

   Est-ce que ce chiffre n'est pas un risque de retourner à l'optimisation de l'occupation des postes de travail ? Ce qui justement peut devenir un frein à la fluidité du traffic. J'ai l'impression que l'efficience revient au calcul de la distance entre les voitures sur un autoroute, et qu'on essaie de la réduire pour mieux occuper l'espace ! Alors que justement c'est plus dangereux, ça ralenti/bloque au moindre soucis et nuit à la vitesse des voiture (donc au débit). Peut-être que trouver le bon calcul de l'efficience pour cette analogie serait un premier pas.

   Je suis aussi preneur de vos définitions, car je suis plutôt inconfortable avec cette définition. 

Dimitri

Dimitri

[laurent morisseau]

L'efficience est prise du point de vue de l'utilisateur : il émet une demande, le chrono démarre, la demande parcours le process et part en production, l'utilisateur peut utiliser la solution qui répond à sa demande, le chrono s'arrête. Le point de vue est celui du délai. Ensuite, il est prêt à payer pour des actions à valeurs ajoutées qui vont transformer sa demande en une solution opérationnelle. L'efficience est le rapport entre le temps de ces actions à valeurs ajoutées et le chrono total. 

L'idéal est que l'on s'occupe tout de suite de la demande, à une ou plusieurs personnes, et qu'on ne s’arrête plus tant que la solution n'est pas utilisable et dans la main de l'utilisateur : one piece flow. Si on atteint cet idéal on est à 100% (même si deux personnes ont travaillé dessus, c'est le délai qui compte de ce point de vue, pas la charge).

De ce point de vue délai, on voit bien qu'il faut de la disponibilité pour répondre, de la souplesse pour ne pas être bloqué, ... Donc pour augmenter cette efficience on ne va pas vers l'optimisation des postes individuels.

Maintenant, cet idéal n'est pas réaliste. On ne se rend pas à ce point disponible, on travaille par batch, on spécialise les gens, ... Résultat, il y a de l'attente. L'efficience se dégrade.

Généralement on calcule cet efficience sur les 10-20 dernières demandes réalisées, ça donne une bonne idée.

Ca répond à ta question Dimitri?

--Laurent Morisseau

Mobile: 06 08 34 63 55

Skype: laurentmorisseau

Twitter Viadeo LinkedIn DoYouBuzz SlideShare   YouTube

2014/1/9 Dimitri BAELI <dba...@gmail.com>

[Arnaud Bailly]

Wikipedia distingue l'efficience qui est le rapport entre le résultat obtenu et les ressources utilisées de l'efficacité qui est le rapport entre le résultat obtenu et le résultat attendu. Selon cette définition, on peut obtenir une efficience de 100% assez facilement, il suffit de rejeter toute demande qui ne soit pas satisfiable immédiatement. 

Car toute les demandes ne sont pas égales entre elles et l'utilisateur n'est pas omniscient : si je développe un logiciel d'optimisation du trajet pour un transporteur routier et que l'utilisateur me demande de fournir une réponse optimale quel que soit le nombre de camions et d'arrêts, ce en moins d'une seconde, je ne pourrais pas la satisfaire quels que soient mes efforts et mon efficience sera faible. Inversement, si un utilisateur me demande une fonctionnalité qui existe déjà mais sous une forme différente ou travestie et que je la lui fournie quasi instantanément, alors mon efficience (et mon efficacité) sera très grande.

Je suis un peu soupçonneux de ce genre de mesure appliquées sur une partie du système - le développement - et pas sur son intégralité - l'ensemble de l'organisation incluant les sales, les RH, la compta... N'est on pas en train de faire de l'optimisation locale ?

--

Arnaud Bailly

FoldLabs Associate: http://foldlabs.com

2014/1/9 Dimitri BAELI <dba...@gmail.com>

[laurent morisseau]

Tu as raison Arnaud, la cible est bien l'ensemble (non pas de l'organisation) mais de la chaine, ce qui inclue les commerciaux, les secrétaires (envois des devis, ...), ...