Designing an event log

Introduction

Lors de la configuration des transformations pour Process Mining, il est important d'avoir une bonne compréhension du processus. La première étape consiste à définir les événements qui se produisent et les objets sur lesquels ces événements ont lieu.

Define the events

Commencez par définir les activités à haute valeur ajoutée. Ajoutez en priorité des activités en fonction de la fréquence probable à laquelle elles se produiront ainsi que de leur importance pour l'utilisateur final. La définition des activités doit être un processus itératif.

L'illustration suivante montre un exemple de journal des événements pour le processus Factures (Invoices).

Le nombre idéal d'activités pour décrire un processus se situe entre 10 et 20. Bien que plus d'activités conduiront à plus de possibilités d'analyse, cela conduit également à plus de variations de processus et à une complexité plus élevée.

Nombre d'activités	Résultat
<10	Faible complexité d'analyse, peu d'améliorations potentielles.
10-20	Équilibre optimal entre complexité d'analyse et améliorations potentielles.
20	Grande complexité d'analyse, nombre élevé d'améliorations mineures.

Conventions d'affectation de noms

Pour les noms d'activité, la meilleure pratique consiste à utiliser le format Nom du verbe (Verb Noun), par exemple Créer un document (Create document). Le tableau suivant contient des conseils sur le nommage des activités.

Nom de l'activité	Conseils	Bonnes pratiques
Commander Commander	Évitez les noms d'activité ambigus.	Commander du matériel
Ticket	Évitez de donner uniquement les noms des activités : indiquez ce qui est arrivé, pour quel élément.	Créer un ticket
Document annulé	Évitez la voix passive.	Annuler le document
Valider le contrôle de la solvabilité pour la commande client	Évitez les noms d'activité trop longs	Approuver la vérification de solvabilité SO

Définir des objets

Les événements ont lieu sur un ou plusieurs objets du processus. Utilisez l'ensemble d'événements souhaités pour déterminer les objets nécessaires pour un processus métier. Le tableau suivant montre un exemple d'ensemble d'événements et leurs objets correspondants.

Événement (Event)	Objet
Créer un bon de commande	Bon de commande
Approuver le bon de commande	Bon de commande
Créer une facture	Facture
Modifier les conditions de paiement	Facture

Chaque objet peut avoir des propriétés qui sont spécifiques à cet objet. Par exemple, un objet de bon de commande peut avoir un purchase_order_type, et un objet de facture peut avoir un payment_due_date.

Define the event log

Le nombre d'objets intéressants dans un processus variera en fonction de la complexité de ce processus. Dans certains processus, un seul objet peut être requis, comme le ticket dans un processus de gestion des incidents.

Dans les processus plus complexes, plusieurs objets peuvent être intéressants. Par exemple, un processus Purchase-to-Pay qui commence par l'achat d'un produit jusqu'au paiement d'une facture couvre un ensemble d'événements liés à plusieurs objets. Pour créer un journal d'événements pour de tels processus, les relations entre les objets doivent être définies. L'illustration suivante montre un exemple de diagramme de relation d'objets Purchase-to-Pay.

Le journal des événements décrit le processus de bout en bout couvrant les événements de tous les objets combinés. Seul un objet du processus peut fonctionner comme objet principal qui sera suivi tout au long du processus. Cet objet principal est nommé « incident » dans le processus, identifié par son « ID de cas ».