Votre Excel calcule correctement et a quand même tort
Pour une chaîne pure, la somme des moyennes est exacte ; c’est la linéarité de l’espérance, et personne ne remet en cause le tableau. Mais dès que le processus contient une jonction (deux étapes doivent être terminées), une boucle de retouche ou une opératrice partagée, la durée totale est une fonction convexe des durées individuelles. D’après l’inégalité de Jensen, la vraie moyenne se situe au‑dessus : dans une simulation de six étapes de 3 jours chacune, elle dépasse de 10 %, le P90 de 52 %. L’erreur la plus lourde est la seconde : une moyenne ne dit rien sur la fréquence à laquelle elle est respectée. Une échéance promise appartient au P90, pas à la moyenne.
Inhaltsverzeichnis
Tout le monde connaît ce fichier Excel. À gauche les étapes du processus, à droite la durée moyenne, en bas la somme. Six étapes, trois jours en moyenne chacune, font dix-huit jours de durée de traitement. Ce chiffre sert ensuite dans une offre, dans une planification des capacités ou dans un engagement envers un client.
Et puis cela prend plus de temps. Pas toujours, mais bien trop souvent. L'explication habituelle est : « Les estimations étaient trop optimistes. » C'est commode, mais le plus souvent faux. Les estimations peuvent être parfaitement correctes et le calcul être pourtant à côté.
Commençons par le côté qui dérange : Excel ne se trompe pas dans ses calculs.
D'abord la défense d'Excel
Si un processus est vraiment une chaîne (étape un, puis deux, puis trois, pas d'attente, pas de ressources partagées), alors la somme des moyennes est exactement la moyenne de la somme. Ce n'est ni une approximation ni une règle empirique, mais la linéarité de l'espérance. Elle vaut toujours, quelle que soit l'asymétrie des distributions individuelles.
Nous avons recalculé : six étapes, chacune avec une durée à droite asymétrique et une moyenne de trois jours, 400 000 processus simulés.
[
{ "label": "Excel: Summe der Mittelwerte", "value": "18,0", "unit": "Tage" },
{ "label": "Simulation: echter Mittelwert", "value": "18,0", "unit": "Tage", "tone": "positive", "note": "Abweichung: 0 %" },
{ "label": "P90 der Simulation", "value": "24,3", "unit": "Tage", "tone": "critical", "note": "+35 % gegenüber dem Excel" },
{ "label": "Vorgänge über 18 Tagen", "value": "44", "unit": "%", "tone": "critical" }
]
Excel trouve la moyenne exactement. C'est justement pour cela que personne ne le met en doute. Il a raison. Sur une seule question. Sauf que ce n'est pas la question qu'on pose vraiment.
Car la deuxième ligne est déjà là : dans 44 % des cas, cela prend plus de dix-huit jours. Une moyenne ne dit rien sur la fréquence à laquelle on l'atteint. C'est une affirmation sur la moyenne de nombreux processus, pas sur le processus que l'on s'engage à réaliser maintenant.
Le chiffre à côté est le P90. Ce qu'il signifie exactement et quel percentile on utilise pour planifier la capacité se trouve chez FlowVisual : P10, P50, P90 richtig lesen. Là se trouvent les statistiques, ici la conséquence : pourquoi la somme des moyennes est le mauvais chiffre pour un engagement, même si elle est correcte.
Sauf que : votre processus n'est pas une chaîne
Une chaîne pure existe presque jamais en pratique. Trois éléments apparaissent dans pratiquement tous les processus. Chacun casse le calcul.
La porte. Deux choses doivent être terminées avant d'avancer : la clarification technique et la vérification de solvabilité, avant d'envoyer l'offre. Les deux prennent en moyenne trois jours. Excel inscrit trois jours. La réalité attend le plus lent des deux, et sa moyenne n'est pas trois jours.
La boucle. Une étape doit parfois être répétée. Quinze pour cent de retouches ressemble à une erreur d'arrondi. Ce n'en est pas une.
La file d'attente. Une personne effectue deux des six étapes. Dans Excel figure son seul temps de traitement. Ce qui n'y figure pas : le temps pendant lequel le dossier reste sur son bureau en attendant qu'elle ait fini autre chose.
Les mêmes durées par étape, les mêmes trois jours en moyenne. Seule la structure change :
{
"caption": "Abweichung der echten Dauer vom Excel-Wert, je Prozessbaustein (Simulation, je 300.000 Vorgänge)",
"unit": "%",
"data": [
{ "label": "Kette: A, dann B, dann C", "value": 0, "tone": "positive" },
{ "label": "Schleife: 15 % Nacharbeit", "value": 18 },
{ "label": "Tor: A und B müssen fertig sein", "value": 33 },
{ "label": "Schleife: 30 % Nacharbeit", "value": 43 },
{ "label": "Tor: A, B und C müssen fertig sein", "value": 54 },
{ "label": "Warteschlange bei 67 % Auslastung", "value": 124, "tone": "critical" },
{ "label": "Warteschlange bei 80 % Auslastung", "value": 231, "tone": "critical" },
{ "label": "Warteschlange bei 90 % Auslastung", "value": 531, "tone": "critical" }
]
}
La file d'attente est le clou de cette liste. Beaucoup considèrent une charge de travail de 67 % comme détendue. Là, le temps de séjour réel est déjà plus du double du seul temps de traitement. À 90 % il est six fois plus long. Ce n'est pas une mauvaise organisation, c'est des mathématiques : plus la charge se rapproche de cent pour cent, plus le temps d'attente augmente brutalement. Et il n'augmente pas linéairement, il explose.
Celui qui fait travailler ses employés à 90 % d'occupation n'est pas efficace. Il a simplement déplacé le temps d'attente hors de son bilan vers la durée de traitement de ses clients.
Pourquoi l'erreur a toujours le même signe
Le motif dans le graphique n'est pas un hasard. Il a un nom.
Excel calcule f(moyenne) : il remplace chaque étape par la moyenne et calcule le processus. La réalité fournit moyenne de f(X) : elle laisse chaque processus avec ses durées fluctuantes traverser le processus, puis ne calcule la moyenne qu'après.
Ce n'est pas identique. D'après la inégalité de Jensen, si la fonction est convexe, alors la moyenne des résultats est supérieure au résultat des moyennes.
Et maintenant l'observation décisive : porte, boucle et file d'attente sont toutes trois convexes. Un maximum est convexe. Une répétition géométrique est convexe. Une file d'attente l'est de façon particulièrement prononcée. C'est pourquoi la déviation dans le graphique n'est jamais négative.
Cela veut dire : l'erreur d'Excel n'est pas un bruit aléatoire, mais un biais. On ne se trompe pas de temps en temps dans un sens puis dans l'autre. On est systématiquement trop optimiste. Plus la structure du processus est riche, plus l'écart est fort.
Le même processus, deux calculs
Prenons un processus à six étapes, tel qu'il est réellement : les étapes deux et trois s'exécutent en parallèle et doivent toutes deux être terminées. L'étape cinq comporte quinze pour cent de retouches. Sinon rien de particulier : pas de file d'attente, pas de salarié partagé. Chaque étape dure en moyenne trois jours.
Excel remplace par les moyennes et obtient 15 jours. Ce calcul est bien fait, la porte est même correctement modélisée comme parallélisme.
[
{ "label": "Excel: Mittelwert je Schritt", "value": "15,0", "unit": "Tage" },
{ "label": "Simulation: Mittelwert", "value": "16,5", "unit": "Tage", "tone": "critical", "note": "+10 %" },
{ "label": "Simulation: P90", "value": "22,8", "unit": "Tage", "tone": "critical", "note": "+52 %" },
{ "label": "Termin von 15 Tagen gehalten", "value": "43", "unit": "%", "tone": "critical" }
]
On promet 15 jours. Ils sont tenus dans 43 % des cas.
C'est là tout le point. Ce n'est pas qu'Excel se trompe de dix pour cent (on pourrait vivre avec). C'est qu'il donne un chiffre qui ressemble à un engagement et qui est en réalité un tirage à pile ou face. Qui planifie à partir de ce chiffre planifie un processus qui n'existe pas.
Vous pouvez lancer la simulation vous-même ci‑dessous. La simulation montre non seulement combien de temps ça prend, mais aussi quelle étape devient goulot dans quelle situation. La réponse change dès que la situation change.
Le seul élément qui penche dans l'autre sens
Si chaque structure convexe rend Excel trop optimiste, existe-t-il une structure concave ? Une pour laquelle le calcul avec des moyennes est pessimiste ?
Oui. Et c'est la raison pour laquelle la meilleure amélioration n'est souvent pas un logiciel.
Imaginez deux gestionnaires de dossiers. Chacun a sa spécialité, chacun sa propre file. L'un est spécialiste des nouveaux clients, l'autre des clients existants. Tous deux aussi rapides, tous deux aussi chargés.
Changez maintenant une seule chose : une file d'attente commune. Qui se libère prend le dossier suivant, quel qu'il soit. Les mêmes deux personnes, mêmes temps de traitement, même charge de travail.
{
"caption": "Verweilzeit bei gleicher Kapazität und gleicher Last: getrennte gegen gemeinsame Warteschlange (Simulation)",
"unit": "Tage",
"data": [
{ "label": "Zwei Spezialisten, je eigene Schlange (Mittel)", "value": 20.7, "tone": "critical" },
{ "label": "Zwei Spezialisten, je eigene Schlange (P90)", "value": 43.5, "tone": "critical" },
{ "label": "Zwei Generalisten, eine Schlange (Mittel)", "value": 12.5, "tone": "positive" },
{ "label": "Zwei Generalisten, eine Schlange (P90)", "value": 23.9, "tone": "positive" }
]
}
Le temps de séjour diminue de 40 %, le P90 de 45 %. Sans personne supplémentaire. Sans une ligne de code. Sans un outil payant mensuel.
La raison est encore une fois mathématique, mais cette fois dans l'autre sens : deux files séparées ne peuvent pas s'entraider. L'un reste inactif pendant que le travail s'accumule chez l'autre. Ces temps morts sont perdus. Une file commune supprime précisément cette perte. Le minimum entre plusieurs opérateurs libres est une fonction concave, et c'est pourquoi le signe s'inverse ici.
Pour nous, c'est le constat le plus honnête de tout cet article. Si une analyse montre que votre goulot est une file d'attente, la bonne recommandation n'est souvent pas : « Achetez un logiciel. » Mais : « Faites d'un deux domaines un seul. » Ça ne vous coûtera rien et nous enlèvera un projet.
Ce que cela implique pour la pratique
Premièrement : les valeurs ponctuelles n'ont pas leur place dans une analyse de processus. Une durée est un intervalle, pas un nombre. Enregistrez pour chaque étape une valeur optimiste, une valeur typique et une valeur pessimiste. Cela prend pas plus d'une minute que deviner une moyenne. C'est la seule donnée avec laquelle on peut calculer.
Deuxièmement : ne promettez jamais la moyenne. La moyenne est une affirmation sur votre moyenne annuelle, pas une promesse pour le prochain dossier. Un délai doit être fixé au P90. Qui promet la moyenne promet de casser une de ses deux promesses.
Troisièmement : la structure compte plus que l'estimation. Qui estime les durées d'étape à dix pour cent près, mais oublie une porte et une file d'attente, se trompe d'un facteur multiple. À l'inverse, on s'approche étonnamment bien avec des estimations grossières si la structure est correctement modélisée.
Quatrièmement : l'occupation n'est pas un objectif. Quatre-vingt-dix pour cent d'occupation donne l'impression d'une bonne gestion. C'est la raison pour laquelle vos durées de traitement explosent.
Et c'est pourquoi FLOW a un O
Notre méthode s'appelle Flowrefy, et les quatre premières lettres sont la mesure : Find — quels processus sont éligibles. Lay bare — combien coûte l'état actuel en euros. Observe — simuler. Weigh — peser.
Pour F, L et W nous proposons des calculateurs gratuits. Pour O il n'y en a pas. Non pas parce que nous l'aurions placé derrière un mur payant, mais parce que l'on ne peut pas mettre la simulation dans un champ de saisie. Elle a besoin de la structure du processus : qui attend qui, qui partage avec qui, où il y a des retouches. Exactement ce qui n'apparaît pas dans la formule de somme d'Excel, et exactement ce qui fait la différence entre 15 et 22,8 jours.
C'est pourquoi nous avons construit FlowVisual : dessinez le processus, saisissez les intervalles, jouez les situations. Il ne vous montre pas seulement combien de temps cela prend, mais où ça coince quand la demande augmente, et si le goulot que vous voulez résoudre est encore le même sous charge.
Si vous voulez juste savoir combien coûte par an votre goulot le plus cher, commencez ici. C'est gratuit et cela prend dix minutes.
Sur la méthodologie
Tous les chiffres de cet article proviennent d'une simulation Monte Carlo, pas de projets clients. Les durées par étape suivent une loi lognormale avec une moyenne de 3,0 jours et un écart qui conduit à un coefficient de variation d'environ 0,65. La distribution est asymétrique à droite, comme le sont les temps de traitement en réalité : ils ne peuvent pas aller sous zéro, mais peuvent s'étendre vers le haut. Par étape, 300 000 à 400 000 processus ont été simulés, les files avec 80 000 arrivées et une phase transitoire tronquée.
Les pourcentages concrets dépendent de ces hypothèses. La direction n'en dépend pas : elle découle de l'inégalité de Jensen et vaut pour toute dispersion supérieure à zéro. Qui calcule avec des distributions plus resserrées obtient des écarts plus petits, mais jamais un signe différent.