Nombre de cas actifs par jour

Vue d'ensemble

Le calculateur Nombre de cas actifs par jour mesure combien de cas étaient activement en cours à chaque jour calendaire. Un cas est considéré comme "actif" à une date donnée s'il a commencé mais n'est pas encore terminé - ce qui signifie que le cas a au moins un événement à ou avant cette date et au moins un événement à ou après cette date.

Ce calculateur est particulièrement précieux pour comprendre la charge de travail, identifier les contraintes de capacité et détecter les goulets d'étranglement. Contrairement aux calculateurs basés sur les événements qui comptent les activités, ce calculateur compte les cas uniques qui étaient dans un état en cours, fournissant une vision des niveaux de travail en cours (WIP) au fil du temps.

Remarque : Il s'agit d'un calculateur caché dans mindzie Studio, ce qui signifie qu'il n'est pas directement visible dans le menu standard des calculateurs mais peut être accessible de manière programmatique ou via des configurations avancées.

Usages courants

  • Surveiller les niveaux de travail en cours (WIP) pour identifier les goulets d'étranglement de capacité et les contraintes de ressources
  • Détecter les périodes d'accumulation excessive de cas qui peuvent indiquer des problèmes systémiques
  • Analyser les tendances saisonnières de la charge de travail afin d'optimiser la dotation en personnel et l'allocation des ressources
  • Identifier l'impact des changements de processus sur le débit des cas et les temps de cycle
  • Valider que les taux de complétion des cas suivent ceux de création de cas
  • Supporter la planification de la capacité en comprenant les volumes historiques de cas actifs
  • Détecter des anomalies telles que des pics soudains de WIP pouvant indiquer des pannes de processus

Paramètres

Ce calculateur ne dispose d'aucun paramètre configurable au-delà du contexte de filtrage standard. Il analyse automatiquement tous les cas de votre ensemble de données filtré en déterminant quels cas étaient actifs (en cours) à chaque jour calendaire.

Comment les cas actifs sont calculés :

Un cas est compté comme actif à une date spécifique si :

  • Le premier événement du cas a eu lieu à ou avant cette date (le cas a commencé)
  • Le dernier événement du cas a eu lieu à ou après cette date (le cas n'était pas encore terminé)
  • Cela signifie qu'un cas est actif de sa date de début jusqu'à sa date de clôture (inclus)

Champs standard :

  • Title : Titre personnalisé optionnel pour la sortie du calculateur
  • Description : Description optionnelle à des fins de documentation

Exemples

Exemple 1 : Identifier les goulets d'étranglement de capacité

Scénario : Votre processus de traitement des commandes subit des retards, et la direction souhaite comprendre si l'augmentation du nombre de cas dépasse la capacité de traitement de votre équipe. Vous devez identifier les périodes où les cas actifs s'accumulent plus rapidement qu'ils ne sont terminés.

Paramètres :

  • Title : "Analyse du travail en cours dans le traitement des commandes"
  • Description : "Suivre les niveaux de cas actifs pour identifier les contraintes de capacité"

Sortie :

Le calculateur affiche un tableau avec deux colonnes :

  • Date : Chaque jour calendaire dans la plage temporelle du journal d'événements
  • Nombre de cas actifs : Le nombre de cas en cours à cette date

Exemple de sortie :

Date         Active Case Count
2024-01-15   487
2024-01-16   492
2024-01-17   501
2024-01-18   523
2024-01-19   558
2024-01-20   562
2024-01-21   559
2024-01-22   612
2024-01-23   648
2024-01-24   687
2024-01-25   724

Conclusions : L'augmentation régulière du nombre de cas actifs de 487 à 724 en 10 jours indique que de nouveaux cas arrivent plus vite que les cas existants ne sont terminés. Cette hausse de 49 % du WIP suggère un goulet d'étranglement de capacité. L'accélération du taux d'augmentation (de +5 cas/jour en début de période à +37 cas/jour en fin de période) montre que le goulet d'étranglement s'aggrave. La direction devrait vérifier si les effectifs sont suffisants ou si un problème de processus ralentit la complétion des cas.

Exemple 2 : Évaluer l'impact d'une amélioration de processus

Scénario : Votre équipe a mis en place une automatisation de processus le 15 mars pour réduire les étapes d'approbation manuelles et accélérer le débit des cas. Vous souhaitez mesurer si l'automatisation a effectivement réduit les niveaux de travail en cours.

Paramètres :

  • Title : "Évaluation de l'impact de l'automatisation du processus"
  • Description : "Comparer les niveaux de WIP avant et après le déploiement de l'automatisation"

Sortie :

La sortie montre le nombre de cas actifs deux semaines avant et après le déploiement de l'automatisation :

Avant automatisation (1er-14 mars) :

Date         Active Case Count
2024-03-01   856
2024-03-05   871
2024-03-10   883
2024-03-14   892

Après automatisation (16-30 mars) :

Date         Active Case Count
2024-03-16   879
2024-03-20   823
2024-03-25   761
2024-03-30   698

Conclusions : L'automatisation a eu un impact positif significatif. Avant le déploiement, les cas actifs augmentaient de 856 à 892 (+4 %). Après le déploiement, ils ont diminué de 879 à 698 (-21 %). La réduction du WIP indique que les cas se terminent désormais plus vite qu'ils n'arrivent, suggérant que l'automatisation a amélioré le débit. La baisse régulière sur deux semaines montre une amélioration soutenue et non temporaire.

Exemple 3 : Détecter les schémas liés aux weekends et jours fériés

Scénario : Vous analysez un processus de tickets du service clientèle et souhaitez comprendre comment les weekends et jours fériés affectent les niveaux de travail en cours. Cela vous aidera à décider si une couverture le weekend est nécessaire ou s'il faut laisser les fluctuations naturelles.

Paramètres :

  • Title : "Analyse du schéma hebdomadaire du WIP du service clientèle"
  • Description : "Identifier les schémas d'accumulation durant le weekend"

Sortie :

Le calculateur montre les cas actifs sur un mois typique. Visualisé sous forme de graphique en courbes, on observe :

  • Les cas actifs augmentent progressivement du lundi au vendredi (d'environ 450 à 520)
  • Les cas restent stables ou augmentent légèrement samedi et dimanche (pas d’activité complétée, mais de nouveaux cas peuvent arriver)
  • Le lundi affiche un pic net (jusqu’à environ 580) dû à l’accumulation du weekend
  • Le schéma se répète chaque semaine

Données d’un exemple sur une semaine :

Date         Active Case Count  Day of Week
2024-02-12   452               Lundi
2024-02-13   463               Mardi
2024-02-14   478               Mercredi
2024-02-15   495               Jeudi
2024-02-16   518               Vendredi
2024-02-17   527               Samedi
2024-02-18   531               Dimanche
2024-02-19   587               Lundi

Conclusions : Le schéma hebdomadaire constant montre que les cas s'accumulent le weekend (de 518 vendredi à 531 dimanche, puis un pic à 587 lundi) parce qu’aucun cas n’est complété mais de nouveaux tickets continuent d’arriver. Ce pic du lundi, avec 56 cas actifs supplémentaires (+10 %), crée un défi récurrent de capacité. Ce schéma suggère soit d’implémenter un support limité le weekend pour éviter l’accumulation, soit d’assurer une dotation suffisante le lundi pour gérer ce pic prévisible. La répétition sur plusieurs semaines confirme qu’il s’agit d’un problème structurel et non d’une variation aléatoire.

Exemple 4 : Analyser les besoins de capacité saisonniers

Scénario : Votre processus de comptes fournisseurs gère un volume de factures nettement plus élevé en fin de trimestre. Vous devez quantifier les variations saisonnières du WIP pour justifier des renforcements temporaires d’effectifs pendant les pics.

Paramètres :

  • Title : "Analyse de la capacité trimestrielle en comptes fournisseurs"
  • Description : "Comparer les niveaux de WIP en période normale et en fin de trimestre"

Sortie :

La sortie montre les cas actifs sur un trimestre complet, révélant des schémas distincts :

Période normale (milieu de trimestre) :

Date         Active Case Count
2024-02-15   245
2024-02-20   238
2024-02-25   251

Période de fin de trimestre (dernière semaine du trimestre) :

Date         Active Case Count
2024-03-25   312
2024-03-26   367
2024-03-27   423
2024-03-28   489
2024-03-29   537
2024-03-30   582
2024-03-31   641

Conclusions : Le WIP moyen en milieu de trimestre est d’environ 245 cas actifs. Durant la dernière semaine du trimestre, le WIP plus que double, culminant à 641 cas le dernier jour (+162 %). L'accélération dramatique en fin de période (de 312 à 641 cas, soit 329 cas supplémentaires en 6 jours) montre une pression extrême sur la capacité. Ces données justifient le recours à du personnel temporaire lors de la dernière semaine de chaque trimestre, ou la mise en place d’une politique de "fermeture douce" pour étaler le traitement des factures plus uniformément dans le mois.

Exemple 5 : Identifier des problèmes de qualité de données

Scénario : Votre équipe de data engineering a récemment migré les données du journal d'événements depuis un système ancien. Vous voulez vérifier que la migration a correctement conservé les informations du cycle de vie des cas sans créer de ruptures artificielles dans la continuité des cas.

Paramètres :

  • Title : "Validation de migration de données - Vérification de la continuité des cas"
  • Description : "Vérifier que les comptages de cas actifs sont cohérents et continus"

Sortie :

Le calculateur révèle une anomalie dans les données :

Date         Active Case Count
2024-01-10   1,247
2024-01-11   1,289
2024-01-12   1,312
2024-01-13   47
2024-01-14   52
2024-01-15   1,278
2024-01-16   1,301

Conclusions : La chute brutale de 1 312 cas actifs à 47 le 13 janvier, suivie d’un rebond immédiat à 1 278 le 15 janvier, est impossible en conditions réelles d’exploitation. Une baisse nocturne de 96 % du WIP suivie d’une hausse de 2 359 % le lendemain indique un problème de migration des données. Très probablement, les événements des 13 et 14 janvier n’ont pas été correctement migrés, faisant apparaître les cas comme terminés artificiellement le 12 janvier. L’équipe data engineering doit vérifier les scripts de migration pour ces dates spécifiques et réimporter les événements manquants.

Sortie

Le calculateur produit un tableau de données avec les colonnes suivantes :

Date (DateTime) : La date calendaire pour chaque jour dans la plage temporelle du journal d'événements. La composante horaire est toujours fixée à 00:00:00 (minuit) car le calculateur regroupe par date uniquement. Les dates vont du premier timestamp d'événement au dernier dans votre jeu de données filtré.

Nombre de cas actifs (Nombre) : Le nombre de cas uniques qui étaient en cours à cette date. Cela inclut tous les cas où la date de début est à ou avant la date, et la date de fin est à ou après la date. Les cas sont comptés une fois par jour, indépendamment du nombre d'événements qu'ils ont eus ce jour-là.

La sortie peut être visualisée comme :

  • Graphiques en courbes : Idéal pour identifier tendances, schémas et anomalies dans les niveaux de WIP au fil du temps
  • Graphiques en aires : Efficace pour montrer le volume du travail en cours sous forme de région remplie
  • Graphiques en barres : Utile pour comparer les niveaux de WIP sur des plages de dates ou périodes spécifiques
  • Analyse de tendance : Appliquer des moyennes mobiles pour lisser les variations quotidiennes et identifier les schémas sous-jacents
  • Résumé statistique : Calculer la moyenne, la médiane et l’écart-type pour comprendre les niveaux typiques et la variabilité du WIP

Conseils d'interprétation :

  • Tendance à la hausse : Les cas arrivent plus vite qu'ils ne sont terminés (problème de capacité ou goulet d’étranglement)
  • Tendance à la baisse : Les cas se terminent plus vite qu'ils n'arrivent (excès de capacité ou baisse de la demande)
  • Schéma stable : Processus en équilibre avec des taux d’arrivée et de complétion équilibrés
  • Pics soudains : Peuvent indiquer des problèmes de qualité des données, des pannes de processus ou des événements inhabituels
  • Schémas hebdomadaires : Révèlent souvent les effets du weekend ou des variations de dotation
  • Schémas saisonniers : Montrent les demandes cycliques du métier nécessitant une planification de la capacité

Remarque : Les cas avec des timestamps de début ou de fin manquants peuvent être exclus de l’analyse ou comptés de manière incorrecte. Assurez-vous que votre journal d'événements contient des timestamps valides pour tous les événements afin d'obtenir des comptages de cas actifs précis.

Cette documentation fait partie de la plateforme de process mining mindzie Studio.