Un logiciel qui ne dessine pas votre processus mais le calcule

1. Quelle étape limite le débit ? Pas celle dont on se plaint le plus fort, et pas celle qui dure le plus longtemps. Le goulot d'étranglement est l'étape avec la plus haute utilisation ρ = demande ÷ capacité. À 85 % d'utilisation, une opération attend déjà 5,7 fois son temps de traitement, à 95 % 19 fois. Le détail du calcul est ici.

2. Combien de temps cela prend-il dans le pire des cas ? Une moyenne ne répond pas à une promesse. Celui qui promet « trois jours » parce que la médiane est de trois jours rompt la promesse dans la moitié des cas. Ce qui importe est le P90, la valeur que neuf opérations sur dix n’atteignent pas.

3. Où se déplace le goulot si je le résous ? C'est la question qui fait échouer les business cases issus de tableaux. Tant que la validation est à 114 % d'utilisation, la libération derrière semble détendue. Elle ne reçoit presque rien. Si vous résolvez la validation, la libération reçoit la totalité. L'économie indiquée dans le tableau ne se réalise jamais.

4. Combien vaut une modification en euros ? Pas « plus rapide », mais un nombre avec origine : coûts de personnel par opération, coûts de l'attente, coûts des retouches, avant contre après, avec intervalle.

Quand vous êtes au mauvais endroit : Si vous concevez une ligne de production, un entrepôt, un service des urgences ou un terminal, prenez un laboratoire de simulation. La logique de transport, les matrices de réglage et les plans d'expérience manquent volontairement ici. Si vous gérez 300 processus avec obligation de validation, prenez une suite BPM.

La comparaison détaillée avec les limites de chaque catégorie est dans l'article Prozesssimulation: Software im Vergleich.

Les opérations arrivent individuellement. Pas 120 par jour comme un chiffre rond, mais tirés d’une distribution avec fluctuation, probabilité de pic et facteur de pic. Le dommage survient pendant les cinq pires jours du trimestre, pas en moyenne.

Chaque étape a une capacité et une plage de traitement. Capacité soit en personnes × heures par jour soit en cadence fixe si une installation fixe la limite. Traitement de–à, pas une valeur ponctuelle. La dispersion est l’information essentielle, car elle crée la file d’attente.

La simulation est répétée des centaines de fois. Chaque répétition tire de nouvelles valeurs aléatoires. De la distribution des résultats naît la bande : P10, P50, P90. Pourquoi un seul nombre ne suffit pas ici est expliqué dans P10, P50, P90 richtig lesen.

L’enchaînement est pris en compte. Une étape ne voit jamais plus d’opérations que la plus lente avant elle n’en laisse passer. C’est exactement pourquoi le goulot d’étranglement se déplace dès que vous le résolvez. Cela, aucun tableau ne le peut.

Taux d’utilisation  ρ  =  Besoin ÷ Capacité
Temps d’attente  Wq  ≈  ρ/(1−ρ)  ×  (ca² + cs²)/2  ×  te

La deuxième ligne est l’approximation à laquelle tout résultat de simulation peut être confronté. Si la simulation s’en écarte fortement, la différence tient à l’enchaînement ou au calendrier. Les deux doivent alors être expliqués, pas écartés.

• Pas de Process Mining. FlowVisual ne mesure pas le passé à partir des journaux système. Il calcule une hypothèse. Il n’a pas besoin d’un event-log, mais ne fournit donc aucune indication sur ce qui s’est réellement passé. Si vous avez un event-log et voulez savoir ce qui s’est passé hier : outil de mining. Si vous voulez savoir ce qui se passera une fois l’étape 3 automatisée : simulation.
• Pas un outil BPMN. Six blocs au lieu d’une notation. Si vous avez besoin d’une documentation de processus conforme à la norme, vous ne l’obtiendrez pas ici. Voir BPMN-Simulation pour la distinction.
• Pas de référentiel d’architecture. Un processus par modèle, pas toute l’organisation en une fois.
• Pas de dimensionnement d’usine. Pas de logique de transport, pas de matrices de réglage, pas de plans d’expérience, pas de modèles d’équipes avec règles de passage.
• Pas une plus belle image. Il ne dessine pas plus joliment que Visio. Il calcule.

1. « Ouvrir un modèle au lieu de partir de zéro. » Traitement des commandes, processus d’offre, validation des factures, réclamation, intégration des nouveaux arrivants ou ticket IT sont prêts à l’emploi. Trente secondes pour voir à quoi ressemble un modèle terminé. Cela vous évite de surdétailler le vôtre.
2. « Dessinez le flux. » Début, étapes dans l’ordre réel, décisions là où le processus bifurque vraiment, abandon pour tout ce qui sort du processus.
3. « Saisissez volumes, durées et coûts. » Volume par jour avec variation, capacité et durée de traitement par étape de–à, plus rôle, système et taux horaire. Calculez le coût complet : salaire brut × 1,5 à 1,8, divisé par environ 1 500 heures productives.
4. « Regardez avant de calculer. » Est‑ce que cela se passe vraiment ainsi ? Ces deux minutes avec le métier vous évitent la discussion sur le résultat.
5. « Lancez le test de charge. » La barre la plus haute est votre goulot d’étranglement ; un clic ouvre l’étape dans l’inspecteur.
6. « Sauvegardez l’état actuel, changez exactement un levier, comparez. » Sans ligne de base il n’y a rien à comparer, et avec trois modifications simultanées personne ne sait laquelle a agi.
7. « Exportez. » Offre (PDF) pour le décideur, documentation (PDF) pour la traçabilité.

Les étapes 1 à 6 sont gratuites. La version détaillée avec listes de contrôle et les cinq erreurs coûteuses se trouve dans la Anleitung.