Designing an event log

Introduction

Lors de la configuration des transformations pour Process Mining, il est important de bien comprendre le processus. La première étape consiste à définir les événements qui se produisent et les entités sur lesquelles 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.

Vous trouverez ci-dessous un exemple de journal des événements pour le processus Factures.

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 Verb Noun, tel que Créer un document. Consultez le tableau ci-dessous pour obtenir 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

Define entities

Les événements ont lieu sur une ou plusieurs entités dans le processus. Utilisez l'ensemble d'événements souhaités pour déterminer les entités nécessaires à un processus métier. Vous trouverez ci-dessous un exemple d'un ensemble d'événements et de leurs entités correspondantes.

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

Define the event log

Le nombre d'entités qui présentent un intérêt dans un processus varie en fonction de la complexité du processus. Dans certains processus, une seule entité peut être requise, comme le ticket dans un processus de gestion des incidents.

Dans les processus plus complexes, plusieurs entités peuvent être intéressantes. 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 entités. Pour créer un journal des événements pour de tels processus, les relations entre les entités doivent être définies. Consultez l'illustration ci-dessous pour obtenir un exemple de diagramme de relation Entités Purchase-to-Pay.

Le journal des événements décrit le processus de bout en bout couvrant les événements de toutes les entités combinées. Une seule entité du processus peut fonctionner comme entité principale qui sera suivie tout au long du processus. Cette entité principale est nommée « Cas » dans le processus, identifiée par son « ID de cas ».