Durées entre un attribut de cas et les temps d'activité
Vue d'ensemble
L’enrichissement Durations Between a Case Attribute and Activity Times calcule la différence de temps entre un attribut horodaté au niveau du cas et le temps d’activité de chaque événement individuel au sein de ce cas. Cet enrichissement puissant crée un nouvel attribut d'événement qui montre combien de temps s’est écoulé entre un point de référence fixe (comme la date de commande, la date de début d’un contrat ou la date d’échéance) et chaque activité du processus. Cela permet une analyse détaillée de la relation entre les activités et les échéances commerciales importantes, les jalons ou les dates de référence.
Contrairement aux enrichissements qui mesurent le temps entre activités, cet opérateur utilise un horodatage au niveau du cas comme point d’ancrage pour tous les calculs de durée. Ceci est particulièrement précieux lorsque vous devez comprendre comment chaque étape de votre processus se rapporte à une date commerciale critique, par exemple pour mesurer toutes les activités par rapport à une échéance de niveau de service, suivre la progression depuis une date de début de projet ou analyser comment les activités se regroupent autour d’une date de paiement due. L’enrichissement supporte à la fois les calculs vers l’avant (temps écoulé depuis la date de référence) et vers l’arrière (temps restant jusqu’à la date de référence), avec des options flexibles d’unités de temps allant de la seconde à l’année.
Utilisations courantes
- Suivre le temps écoulé depuis la date de commande jusqu’à chaque activité de réalisation dans le processus commande-à-encaissement
- Mesurer combien de jours avant ou après la date d’échéance de paiement chaque activité de recouvrement se produit
- Contrôler le temps depuis la date d’admission du patient jusqu’à chaque procédure médicale dans les processus de santé
- Calculer les jours entre la signature du contrat et chaque livraison d’étape dans la gestion de projet
- Analyser combien de temps après la création du dossier se produit chaque interaction du service client
- Mesurer le temps depuis la date de début de production jusqu’à chaque contrôle qualité ou étape de fabrication
- Suivre les jours entre la date de demande de prêt et chaque activité d’approbation ou de vérification
Paramètres
New Attribute Name : Le nom du nouvel attribut d’événement qui stockera les durées calculées. Cet attribut sera créé au niveau de l'événement, ce qui signifie que chaque événement au sein d’un cas aura sa propre valeur de durée calculée à partir de l’attribut du cas. Choisissez un nom descriptif qui indique clairement ce qui est mesuré, par exemple "Days_Since_Order_Date", "Hours_Until_Due_Date" ou "Time_From_Contract_Start". Le nom doit être unique et ne pas exister déjà dans votre jeu de données.
Attribute Name : L’attribut horodaté au niveau du cas à utiliser comme point de référence pour tous les calculs de durée. Ce menu déroulant liste tous les attributs DateTime disponibles dans votre table de cas. Sélectionnez l’attribut représentant votre date de référence métier, comme "Order_Date", "Due_Date", "Contract_Start_Date" ou "SLA_Deadline". Seuls les attributs de type DateTime sont disponibles, assurant des comparaisons de timestamps valides.
Duration Type : Spécifie l’unité de temps pour le calcul de la durée. Les options incluent :
- TimeSpan : Préserve la durée complète avec jours, heures, minutes et secondes (affichée comme "2d 14:30:45")
- Seconds : Nombre total de secondes entre les timestamps
- Minutes : Nombre total de minutes (utile pour les processus courts)
- Hours : Nombre total d’heures (idéal pour les processus sur une ou plusieurs journées)
- Days : Nombre total de jours (le plus courant pour les processus métier)
- Weeks : Nombre total de semaines (utile pour les processus longs)
- Months : Nombre approximatif de mois (calculé comme jours/30.44)
- Years : Nombre d’années (pour les processus très longs)
Attribute Should Come First : Contrôle la direction du calcul de durée. Lorsque coché (par défaut), le calcul est "temps de l’événement moins temps de l’attribut du cas", produisant des valeurs positives lorsque les événements surviennent après la date de référence. Lorsque décoché, le calcul est inversé en "temps de l’attribut du cas moins temps de l’événement", produisant des valeurs positives lorsque les événements surviennent avant la date de référence. Utilisez la valeur par défaut pour mesurer le temps écoulé depuis une date de départ, ou décochez pour mesurer le temps restant jusqu’à une échéance.
Allow Fractional Periods : Détermine si les valeurs de durée peuvent inclure des décimales. Lorsque décoché (par défaut), les durées sont arrondies à l’entier inférieur (ex. : 3 jours au lieu de 3,7 jours). Lorsque coché, les durées conservent la précision décimale (ex. : 3,7 jours, 2,5 heures). Activez cette option pour des calculs plus précis lors de l’analyse de métriques temporelles détaillées ou lorsque de petites différences de temps sont importantes. Laissez-la désactivée pour un reporting plus clair lorsque les unités entières suffisent.
Exemples
Exemple 1 : Suivi du temps de réalisation des commandes
Scénario : Une entreprise de commerce électronique veut suivre la durée de chaque étape de réalisation depuis la date de placement de la commande pour identifier les goulets d’étranglement dans leur processus commande-à-encaissement.
Paramètres :
- New Attribute Name : Days_Since_Order
- Attribute Name : Order_Date
- Duration Type : Days
- Attribute Should Come First : Coché (true)
- Allow Fractional Periods : Décroché (false)
Résultat : L’enrichissement crée un nouvel attribut d’événement "Days_Since_Order" montrant le nombre entier de jours écoulés depuis la commande : | Activité | Heure de l’activité | Order_Date | Days_Since_Order | |----------|---------------------|------------|------------------| | Commande passée | 2024-01-15 09:00 | 2024-01-15 | 0 | | Paiement vérifié | 2024-01-15 14:00 | 2024-01-15 | 0 | | Prélevé | 2024-01-16 10:00 | 2024-01-15 | 1 | | Emballé | 2024-01-16 15:00 | 2024-01-15 | 1 | | Expédié | 2024-01-17 08:00 | 2024-01-15 | 2 | | Livré | 2024-01-19 16:00 | 2024-01-15 | 4 |
Informations : L’entreprise peut désormais facilement filtrer les commandes où "Days_Since_Order" dépasse leur SLA de réalisation de 3 jours au stade de l’expédition, identifiant les activités qui causent des retards.
Exemple 2 : Recouvrement avant la date d’échéance
Scénario : Une société de services financiers doit analyser ses activités de recouvrement par rapport aux dates d’échéance de paiement, pour comprendre quelles actions sont proactives ou réactives.
Paramètres :
- New Attribute Name : Days_Until_Due_Date
- Attribute Name : Payment_Due_Date
- Duration Type : Days
- Attribute Should Come First : Décroché (false)
- Allow Fractional Periods : Coché (true)
Résultat : L’enrichissement crée "Days_Until_Due_Date" affichant des jours décimaux avant la date d’échéance (positif) ou des jours de retard (négatif) : | Activité | Heure de l’activité | Payment_Due_Date | Days_Until_Due_Date | |----------|---------------------|------------------|---------------------| | Facture envoyée | 2024-02-01 | 2024-02-15 | 14.0 | | Email de rappel | 2024-02-10 | 2024-02-15 | 5.0 | | Appel téléphonique | 2024-02-14 | 2024-02-15 | 1.0 | | Paiement reçu | 2024-02-16 | 2024-02-15 | -1.0 | | Pénalité appliquée | 2024-02-20 | 2024-02-15 | -5.0 |
Informations : Les valeurs positives indiquent des efforts de recouvrement proactifs, tandis que les valeurs négatives montrent des mesures réactives après la date d’échéance, aidant à optimiser les stratégies de recouvrement.
Exemple 3 : Chronologie des traitements des patients en santé
Scénario : Un hôpital souhaite suivre toutes les activités de traitement par rapport au moment d’admission du patient pour garantir la rapidité des soins et identifier les retards dans les traitements critiques.
Paramètres :
- New Attribute Name : Hours_Since_Admission
- Attribute Name : Admission_DateTime
- Duration Type : Hours
- Attribute Should Come First : Coché (true)
- Allow Fractional Periods : Coché (true)
Résultat : L’enrichissement produit "Hours_Since_Admission" avec des valeurs d’heures décimales précises : | Activité | Heure de l’activité | Admission_DateTime | Hours_Since_Admission | |----------|---------------------|-------------------|----------------------| | Admission urgence | 2024-03-10 14:30 | 2024-03-10 14:30 | 0.0 | | Évaluation triage | 2024-03-10 14:45 | 2024-03-10 14:30 | 0.25 | | Analyse sanguine demandée | 2024-03-10 15:15 | 2024-03-10 14:30 | 0.75 | | Consultation médecin | 2024-03-10 16:00 | 2024-03-10 14:30 | 1.5 | | Début traitement | 2024-03-10 17:30 | 2024-03-10 14:30 | 3.0 | | Sortie du patient | 2024-03-11 09:00 | 2024-03-10 14:30 | 18.5 |
Informations : L’hôpital peut définir des seuils pour les activités critiques (par ex., triage en moins de 0,5 heure, traitement en moins de 4 heures) et suivre la conformité sur tous les cas d’urgence.
Exemple 4 : Analyse du délai de fabrication
Scénario : Un fabricant doit mesurer chaque étape de production par rapport à la date de début planifiée pour optimiser son planning et identifier les inefficacités du processus.
Paramètres :
- New Attribute Name : Production_Days
- Attribute Name : Planned_Start_Date
- Duration Type : Days
- Attribute Should Come First : Coché (true)
- Allow Fractional Periods : Décroché (false)
Résultat : L’enrichissement crée "Production_Days" affichant les jours entiers depuis le début planifié : | Activité | Heure de l’activité | Planned_Start_Date | Production_Days | |----------|---------------------|-------------------|-----------------| | Matière reçue | 2024-04-01 | 2024-04-03 | -2 | | Début production | 2024-04-03 | 2024-04-03 | 0 | | Assemblage terminé | 2024-04-05 | 2024-04-03 | 2 | | Contrôle qualité 1 | 2024-04-06 | 2024-04-03 | 3 | | Retouche | 2024-04-07 | 2024-04-03 | 4 | | Contrôle qualité 2 | 2024-04-08 | 2024-04-03 | 5 | | Emballage | 2024-04-09 | 2024-04-03 | 6 |
Informations : Les valeurs négatives indiquent une arrivée anticipée des matériaux, tandis que la progression montre un cycle de production de 6 jours avec 2 jours supplémentaires pour le retravail, soulignant des problèmes de qualité.
Exemple 5 : Suivi des jalons de projet
Scénario : Une société de conseils suit toutes les activités de projet par rapport à la date de signature du contrat pour garantir que les livrables respectent les délais contractuels et identifier les risques de planning.
Paramètres :
- New Attribute Name : Weeks_From_Contract
- Attribute Name : Contract_Signed_Date
- Duration Type : Weeks
- Attribute Should Come First : Coché (true)
- Allow Fractional Periods : Coché (true)
Résultat : L’enrichissement génère "Weeks_From_Contract" avec des valeurs décimales en semaines : | Activité | Heure de l’activité | Contract_Signed_Date | Weeks_From_Contract | |----------|---------------------|---------------------|---------------------| | Contrat signé | 2024-01-01 | 2024-01-01 | 0.0 | | Réunion de lancement | 2024-01-03 | 2024-01-01 | 0.29 | | Recueil des besoins | 2024-01-15 | 2024-01-01 | 2.0 | | Conception validée | 2024-01-29 | 2024-01-01 | 4.0 | | Début développement | 2024-02-05 | 2024-01-01 | 5.0 | | Tests terminés | 2024-03-04 | 2024-01-01 | 9.0 | | Livraison | 2024-03-11 | 2024-01-01 | 10.0 |
Informations : La société peut comparer les temps réels des jalons par rapport au planning contractuel, la durée totale de 10 semaines aidant à valider les estimations et la planification des ressources futures.
Résultat
L’enrichissement crée un nouvel attribut au niveau des événements contenant la durée calculée entre l’attribut de cas spécifié et le temps d’activité de chaque événement. Le type d’attribut dépend de votre choix de Duration Type : type TimeSpan pour l’option TimeSpan (préservant la précision complète du temps), type Integer pour les durées entières quand les périodes fractionnelles sont désactivées, ou type Float pour les durées décimales quand les périodes fractionnelles sont activées.
Chaque événement du jeu de données reçoit sa propre valeur de durée, calculée individuellement à partir de son horodatage d'activité. Le calcul respecte le paramètre "Attribute Should Come First" pour déterminer si les durées sont positives (événements après la date de référence) ou négatives (événements avant la date de référence). Lorsque les dates n’ont pas de composante temporelle (horodatages à minuit), l’enrichissement utilise automatiquement une arithmétique sur date seule pour des calculs plus clairs en jours.
Le nouvel attribut s’intègre parfaitement avec les autres fonctionnalités de mindzieStudio. Utilisez-le dans des filtres pour identifier les événements se produisant dans des fenêtres temporelles spécifiques (par exemple, "Afficher toutes les activités survenant plus de 5 jours après la date de commande"). Combinez-le avec des calculateurs pour calculer des durées moyennes, identifier des valeurs aberrantes ou créer des indicateurs de performance basés sur la durée. L’attribut peut aussi servir d’entrée pour d’autres enrichissements, comme catégoriser des événements en tranches de temps ou identifier des cas avec des modèles temporels inhabituels.
Cette documentation fait partie de la plateforme d’analyse des processus mindzie Studio.