Simulation à événements discrets pour processus métier

Inhaltsverzeichnis+

Pourquoi « discret » et pourquoi « orienté événement »

Il existe deux manières de traiter le temps dans une simulation.

Orienté pas de temps : L’horloge avance par pas fixes (chaque minute, chaque seconde), et à chaque pas on vérifie ce qui s’est passé. Facile à programmer, énergivore à l’exécution : entre deux événements dans un processus de validation il y a des heures où rien ne se passe et où l’on calcule quand même.

Orienté événement : L’horloge saute jusqu’au moment du prochain événement planifié. Entre les événements rien ne change, donc rien n’a besoin d’être calculé.

Liste d’événements (triée par temps) :
  09:14  Arrivée du dossier #418
  09:22  Fin de traitement du #402 à l’étape "Vérification"
  09:40  Changement d’équipe de la Validation
  ...
L’horloge saute à 09:14, traite, planifie les événements suivants, saute à nouveau.

« Discret » signifie : l’état change de façon brusque à des instants distincts, pas de façon continue. Cela correspond exactement aux processus métier. Une demande est traitée ou non, il n’existe pas de « à moitié traitée ».

Les quatre composants

La propriété la plus importante : les files d’attente ne sont pas modélisées, elles apparaissent. Qui saisit une durée de séjour de trois jours comme pas fixe a présupposé le résultat au lieu de le calculer. Il ne peut ensuite pas montrer comment cette durée change si la capacité ou la dispersion changent.

Les trois décisions qui font échouer des modèles

1. Quelle distribution ?

Pour les intervalles d’arrivée : exponentielle. C’est l’hypothèse standard quand les dossiers arrivent indépendamment les uns des autres, par exemple des factures de différents fournisseurs ou des tickets de différents utilisateurs. Elle produit exactement le comportement observé dans la boîte de réception : de longues périodes calmes, puis trois qui arrivent en même temps.

Si l’arrivée n’est pas exponentielle, elle est cadencée : un lot en fin de mois, une transmission quotidienne à 8h. Alors il vous faut un calendrier, pas une distribution.

Pour les durées de traitement : asymétrique à droite. Lognormale ou Gamma. Si vous n’avez que des estimations, triangulaire à partir du minimum, de la valeur la plus probable et du maximum. La raison : les temps de traitement ont une borne inférieure stricte et une longue traîne à droite. Une distribution normale génère des durées négatives et sous‑estime les valeurs extrêmes qui créent la file d’attente.

Règle pratique : Si vous ne savez que « 5 à 15 minutes », prenez une distribution triangulaire avec le mode à 8. Le choix entre lognormale et Gamma influe moins sur le résultat que la question de savoir si vous autorisez une dispersion.

2. Phase d’échauffement

Une simulation démarre avec des files vides. C’est un état que votre processus n’a jamais. Les premiers jours du modèle sont donc systématiquement trop bons.

Traitement : soit exclure les premiers jours de l’analyse (warm‑up), soit démarrer avec un stock initial réaliste. Pour des processus avec une utilisation nettement inférieure à 85 % quelques jours suffisent ; proches de la limite la période d’ajustement peut durer des semaines.

Comment le repérer : si la moyenne de la première semaine est nettement inférieure à celle de la deuxième, la phase d’échauffement a été trop courte.

3. Combien de runs ?

Un seul run est un échantillon de taille un. Il dit autant sur le processus qu’une seule journée de travail. On répète avec de nouvelles valeurs aléatoires jusqu’à ce que la bande de résultats soit stable.

Critère pratique : doublez le nombre de runs. Si P50 et P90 bougent de moins de quelques pourcents, le nombre suffit. Pour des processus métier il se situe typiquement à quelques centaines.

Plus important que le nombre exact : répéter du tout et produire une bande de sortie. Une simulation qui ne donne qu’un seul nombre a raté l’objectif de la méthode.

Comparaison des points de vue

Pour les processus métier la vue orientée processus est la plus naturelle : vous écrivez ce qui arrive à un dossier, et cela correspond exactement à la manière dont une unité métier décrit son déroulement.

Validation : trois contrôles

1. Little's Law. Stock ÷ débit doit donner à peu près le temps de traversée, dans le modèle comme dans la réalité. Ce test ne repose pas sur des hypothèses de distribution et c’est donc le plus solide qui existe.

2. Charge comparée au calcul manuel. ρ = demande ÷ capacité se calcule étape par étape avec une calculatrice. Si le modèle diverge fortement, une branche ou un calendrier est faux.

3. Test de valeur extrême. Doublez la capacité d’une étape. Si rien ne change, cette étape n’était jamais le goulot d’étranglement. Si vous ne vous y attendiez pas, votre modèle n’est pas conforme à votre idée du processus. C’est précisément là que commence la discussion intéressante.

Quand le DES n’est pas la bonne méthode

• Les participants prennent des décisions qui modifient le déroulement (les clients abandonnent, les agents choisissent leurs cas) → simulation multi‑agents.
• Il s’agit de stocks et de rétroactions sur des années (recrutement, dynamique de marché) → dynamique des systèmes.
• Il n’y a pas de files parce que la capacité est abondante → une simple addition suffit.
• La question est de savoir ce qui s’est réellement passé → Process Mining. Le DES calcule une hypothèse, pas un journal.