- Notes de publication
- Avant de commencer
- Démarrage
- Intégrations
- Travailler avec des applications de processus
- Travailler avec des tableaux de bord et des graphiques
- Travailler avec des graphiques de processus
- Travailler avec des modèles de processus Découvrir et importer des modèles BPMN
- Showing or hiding the menu
- Informations contextuelles
- Exporter (Export)
- Filtres
- Envoi d’idées d’automatisation au Automation Hub d’UiPath®
- Balises
- Dates d’échéance
- Comparer
- Vérification de la conformité
- Analyse des causes profondes
- Simulation du potentiel d’automatisation
- Démarrage d'un projet Task Mining à partir de Process Mining
- Triggering an automation from a process app
- Afficher les données de processus
- Création d'applications
- Chargement des données
- Personnaliser les applications de processus
- Introduction aux tableaux de bord
- Créer des tableaux de bord
- Tableaux de bord
- Gestionnaire de l’automatisation
- Input data
- Définition de nouvelles tables d'entrée
- Ajout de champs
- Ajouter des tables
- Configuration requise pour le modèle de données
- Affichage et modification du modèle de données
- Exportation et importation de transformations
- Modification et test des transformations de données
- Structure of transformations
- Fusion des journaux d'événements
- Tips for writing SQL
- Gestionnaire de processus
- Publier les applications de processus
- Modèles d'applications
- Ressources supplémentaires
Designing an event log
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.
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 |
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.
purchase_order_type
et une entité de facture peut avoir un payment_due_date
.
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 ».