- 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
Structure of transformations
Vous trouverez ci-dessous un aperçu des étapes de transformation des modèles d'application Process Mining .
models\
est organisé selon la structure des étapes de transformation.
L’étape d’entrée est utilisée pour charger les données brutes. Les opérations suivantes sont généralement effectuées pour préparer les données en vue des étapes de transformation suivantes :
- Sélectionnez les champs avec les macros facultatives et obligatoires. Il n'est pas nécessaire qu'un champ soit présent dans les données brutes lorsque la macro facultative est utilisée.
- Saisissez les champs de conversion vers les types de données appropriés.
-
Filtrez les tables pour réduire la taille des données au début des transformations.
_input
aux tables d'entrée.
optional
du paquet pm-utils
doit être utilisée. Cela garantit qu'un champ obtient la valeur null
si elle n'est pas disponible dans les données source. De cette façon, toutes les transformations s'exécuteront correctement.
-
Utilisez la macro table_optionnel() si la table entière est facultative.
Lors de l'étape des entités, les tables d'entrée sont transformées en tables d'entités. Chaque entité requise pour les événements attendus doit obtenir sa propre table. Voir Conception d'un journal des événements. De plus, les entités d'assistance peuvent également être définies ici.
Invoices_input
, Invoice_types_input
et Customers_input
sont jointes pour créer la table d'entité Factures.
Suivez ces directives lors de la création d'une table d'entité.
- Il existe un champ ID d'entité, qui est unique pour chaque enregistrement de données.
- Tous les champs d'entité nécessaires à l'analyse des données sont présents.
- Tous les champs d'entité ont des noms faciles à comprendre.
Invoice_ID
.
Toutes les tables d'entrée ne sont pas transformées en tables d'entités. En outre, d'autres tables d'entrée peuvent contenir des informations pertinentes, telles que la table Customers dans l'exemple. Il peut être pratique de les définir à l'étape des entités en tant que tables distinctes afin qu'elles puissent être réutilisées dans les transformations de données.
3. events
n'est pas présent dans les transformations du journal des événements et des applications de processus personnalisé .
Lors de cette étape de transformation, des tables d'événements sont créées pour chaque entité. Voir Conception d'un journal des événements. Chaque enregistrement d'une table d'événements représente un événement qui s'est produit. Il existe deux scénarios sur la façon dont les données sont structurées :
- Champs d'horodatage: champs d'une table d'entité avec un horodatage pour un événement. Par exemple, le champ
Invoice_created
dans une tableInvoices
. - Journal des transactions: une liste d'événements.
En fonction de la structure des données, les transformations permettant de créer les tables d'événements sont différentes.
Dans ce scénario, les valeurs d'un champ d'horodatage doivent être transformées en enregistrements distincts dans une table d'événements. L'exemple ci-dessous est une table de factures qui contient trois champs d'horodatage.
Chaque champ d'horodatage est utilisé pour créer une table d'événements distincte. Pour chaque enregistrement pour lequel le champ timestamp contient une valeur, créez une table avec l'ID de facture, le nom de l'événement (activité) et l'horodatage auquel l'événement a eu lieu (fin de l'événement).
Invoices_input table
est divisé en Invoice_events_Create_invoice
, Invoice_events_Delete_invoice
et Invoices_events_Change_invoice_price
.
Invoices_events
.
Si les événements sont stockés dans un journal des transactions, les événements pertinents par entité doivent être identifiés. Créez une table par entité et stockez l'ID d'entité correspondant, le nom de l'événement (activité) et l'horodatage de l'événement (fin de l'événement).
Dans l'exemple ci-dessous, le journal des transactions contient des événements pour les entités Purchase Order et Invoice .
Les champs suivants sont obligatoires dans une table d'événements. Tous les enregistrements des tables d'événements doivent contenir une valeur pour ces champs.
Champ |
Description |
---|---|
Identifiant de l’entité |
ID de l'entité pour laquelle l'événement se produit. Par exemple, l ' ID de facture. |
Activité |
L'activité décrit l'action qui a eu lieu sur l'entité. |
Event end |
Le champ de fin d'événement indique quand l'événement spécifique a été terminé. Idéalement, il doit s'agir d'un champ datetime plutôt que d'une date. |
Lorsque le processus contient une entité, aucune transformation supplémentaire n'est nécessaire dans cette étape. La table d'entité unique et les tables d'événements sont déjà au format correct.
Lorsque plusieurs entités sont impliquées dans un processus, les événements de toutes les entités doivent être liés à l'entité principale qui est considérée comme l'« incident » du processus. Voir Définir le journal des événements. Les étapes ci-dessous expliquent comment associer tous les événements à l'entité principale et comment les combiner en un seul journal d'événements.
Créez une table « Entity-Relations » pour centraliser les relations entre toutes les entités. Cette table de relations d'entités contiendra les champs d'ID des entités associées.
Pour créer la table des relations d'entités (Entity-Relations), joignez toutes les tables d'entités en fonction de leurs champs d'ID :
- Commencer par l'entité principale
- Joindre les entités associées à l'entité principale avec une jointure à gauche.
- Si les entités ne sont pas directement liées à l'entité principale, joignez-les aux entités liées qui sont déjà liées à l'entité principale.
Dans l'exemple ci-dessous, il existe trois entités : Purchase order,Invoice lineet Invoice. Le bon de commande est considéré comme l'entité principale du processus. La ligne Facture est directement liée au Bon de commande et la Facture est liée indirectement via la ligne Facture.
Vous trouverez ci-dessous la table des relations d’entités résultante.
Dans la dernière étape de la transformation, la logique métier est ajoutée selon les besoins pour l'analyse des données. Des champs dérivés supplémentaires peuvent être ajoutés aux tables existantes ici. Par exemple, des délais de traitement spécifiques ou des champs booléens utilisés dans les ICP des tableaux de bord.
Tags
et Due dates
.
Les balises sont des propriétés des cas, qui signifient certaines règles métier. Les balises sont généralement ajoutées pour faciliter l'analyse de ces règles métier. Par exemple :
- Facture payée et approuvée par la même personne.
- L’approbation de la facture a pris plus de 10 jours.
- Vérifier l’activité de facturation ignorée.
Chaque enregistrement de la table des balises représente une balise qui s'est produite dans les données pour un cas spécifique. Les champs obligatoires de cette table sont « Case ID » et « Tag ». Tous les cas n’auront pas de balise et certains cas peuvent avoir plusieurs balises. Vous trouverez ci-dessous un exemple de table Balises.
Les dates d’échéance représentent les échéances du processus. Celles-ci sont ajoutées aux données pour analyser si les activités sont effectuées à temps ou non pour ces dates d’échéance.
Chaque enregistrement de la table du journal des échéances représente une échéance pour un certain évènement. Exemples de dates d'échéance :
- une échéance de paiement pour un événement de paiement.
- un délai de validation pour un événement de validation.
Event ID
, Due date
, Actual date
et Expected date
.
Tous les événements n'auront pas tous une date d'échéance, et certains événements pourront avoir plusieurs dates d'échéance.
- Vue d'ensemble (Overview)
- 1. Entrée
- Conventions d'affectation de noms
- Champs facultatifs
- 2. Entités
- Directives
- Additional transformations
- Conventions d'affectation de noms
- 3. Événements
- Timestamp fields
- Journal de transactions
- Conventions d'affectation de noms
- 4. Journaux des événements
- Processus d'entité unique
- Processus à entités multiples
- Entity relations
- Relation tables
- Journal des événements
- Conventions d'affectation de noms
- 5. Logique métier
- Balises
- Dates d’échéance