- Notas relacionadas
- Antes de empezar
- Primeros pasos
- Integraciones
- Trabajar con apps de proceso
- Trabajar con paneles y diagramas
- Trabajar con diagramas de proceso
- Trabajar con modelos de proceso Descubrir e Importar modelos BPMN
- Showing or hiding the menu
- Información del contexto
- Exportar
- Filtros
- Envío de ideas de automatización a UiPath® Automation Hub
- Etiquetas
- Fechas límite
- Comparar
- Comprobación de conformidad
- Análisis de causa raíz
- Simular el potencial de automatización
- Iniciar un proyecto de Task Mining desde Process Mining
- Triggering an automation from a process app
- Ver datos del proceso
- Creación de aplicaciones
- Cargar datos
- Personalizar apps de proceso
- Publicar aplicaciones de proceso
- Plantillas de la aplicación
- Recursos adicionales
Structure of transformations
A continuación se muestra un resumen de los pasos de transformación de las plantillas de la aplicación Process Mining .
models\
está organizada según la estructura de los pasos de transformación.
El paso de entrada se utiliza para cargar los datos sin procesar. Las siguientes operaciones se suelen realizar para preparar los datos para los siguientes pasos de transformación:
- Selecciona campos con la macro opcional y obligatoria. No es necesario que un campo esté presente en los datos sin procesar cuando se utiliza la macro opcional.
- Escriba los campos de conversión a los tipos de datos adecuados.
-
Filtrar tablas para reducir el tamaño de los datos al principio de las transformaciones.
_input
a las tablas de entrada.
optional
del paquete pm-utils
. Esto garantiza que un campo obtenga el valor null
si no está disponible en los datos de origen. De esa forma, todas las transformaciones se ejecutarán correctamente.
-
Use la macro opcional_tabla () si toda la tabla es opcional.
En el paso de entidades, las tablas de entrada se transforman en tablas de entidades. Cada entidad requerida para los eventos esperados debe tener su propia tabla. Consulta Diseñar un registro de eventos. Además, las entidades de apoyo también pueden definirse aquí.
Invoices_input
, Invoice_types_input
y Customers_input
se unen para crear la tabla de entidades Facturas.
Siga estas pautas al crear una tabla de entidades.
- Hay un campo de ID de entidad, que es único para cada registro de datos.
- Están presentes todos los campos de entidad necesarios para el análisis de datos.
- Todos los campos de entidad tienen nombres fáciles de entender.
Invoice_ID
.
No todas las tablas de entrada se transforman en tablas de entidades. Además, otras tablas de entrada pueden contener información relevante, como la tabla Clientes en el ejemplo. Puede ser conveniente definirlos en el paso de entidades como tablas separadas que puedan reutilizarse en las transformaciones de datos.
3. events
no está presente en las transformaciones para las aplicaciones de Registro de eventos y de Proceso personalizado.
En este paso de transformación, se crean tablas de eventos para cada entidad. Consulta Diseñar un registro de eventos. Cada registro de una tabla de eventos representa un evento que tuvo lugar. Hay dos escenarios sobre cómo se estructuran los datos:
- Camposde marca de tiempo: campos en una tabla de entidad con una marca de tiempo para un evento. Por ejemplo, el campo
Invoice_created
en una tablaInvoices
. - Registro de transacciones: una lista de eventos.
Según cómo estén estructurados los datos, las transformaciones para crear las tablas de eventos son diferentes.
En este escenario, los valores de un campo de marca de tiempo deben transformarse en registros independientes en una tabla de eventos. El siguiente ejemplo es una tabla de facturas que contiene tres campos de marca de tiempo.
Cada campo de marca de tiempo se usa para crear una tabla de eventos independiente. Por cada registro en el que el campo de marca de tiempo contenga un valor, crea una tabla con el ID de factura, el nombre del evento (Actividad) y la marca de tiempo en la que tuvo lugar el evento (Final del evento).
Invoices_input table
se divide en Invoice_events_Create_invoice
, Invoice_events_Delete_invoice
y Invoices_events_Change_invoice_price
.
Invoices_events
.
Si los eventos se almacenan en un registro de transacciones, se deben identificar los eventos relevantes por entidad. Crea una tabla por entidad y almacena el ID de entidad correspondiente, el nombre del evento (Actividad) y la marca de tiempo en la que tuvo lugar (Evento final).
En el siguiente ejemplo, el registro de transacciones contiene eventos para las entidades Orden de compra y Factura .
Los siguientes campos son obligatorios en una tabla de eventos. Todos los registros de las tablas de eventos deben contener un valor para estos campos.
Campo |
Descripción |
---|---|
ID de entidad |
ID de la entidad para la que ocurre el evento. Por ejemplo, el ID de la factura. |
Actividades |
La actividad describe qué acción se ha llevado a cabo en la entidad. |
Event end |
El campo de finalización del evento indica cuándo finalizó el evento específico. Idealmente, este debería ser un campo de fecha y hora, en lugar de una fecha. |
Cuando el proceso contiene una entidad, no se necesitan transformaciones adicionales en este paso. La tabla de entidad única y las tablas de eventos ya están en el formato correcto.
Cuando hay varias entidades involucradas en un proceso, los eventos de todas las entidades deben vincularse a la entidad principal que se considera el "Caso" en el proceso. Consulta Definir el registro de eventos. Los siguientes pasos describen cómo relacionar todos los eventos con la entidad principal y cómo combinarlos en un único registro de eventos.
Cree una tabla de "relaciones de entidad" para centralizar las relaciones entre todas las entidades. Esta tabla de relaciones de entidades contendrá los campos de ID de las entidades relacionadas.
Para crear la tabla de relaciones de entidades, una todas las tablas de entidades según sus campos de ID:
- Comenzar con la entidad principal
- Unir entidades relacionadas a la entidad principal con una unión a la izquierda.
- Si las entidades no están relacionadas directamente con la entidad principal, a la izquierda únelas a las entidades relacionadas que ya están unidas a la entidad principal.
En el siguiente ejemplo, hay tres entidades: pedido de compra,líneade factura y factura. La orden de compra se considera la entidad principal en el proceso. La línea Factura está directamente vinculada al pedido y la Factura está vinculada indirectamente a través de la línea Factura.
A continuación se muestra la tabla resultante de relaciones entre entidades.
En el último paso de transformación, se agrega lógica empresarial según sea necesario para el análisis de datos. Aquí se pueden añadir campos derivados adicionales a las tablas existentes. Por ejemplo, tiempos de procesamiento específicos o campos booleanos que se usan en KPI en paneles.
Tags
y Due dates
.
Las etiquetas son propiedades de los casos, que indican ciertas reglas empresariales. Normalmente se añaden etiquetas para facilitar el análisis de estas reglas empresariales. Por ejemplo:
- Factura pagada y aprobada por la misma persona.
- La aprobación de la factura tardó más de 10 días.
- Compruebe que se ha omitido la actividad de la factura.
Cada registro de la tabla de etiquetas representa una etiqueta que se produjo en los datos para un caso específico. Los campos obligatorios para esta tabla son el "ID de caso" y la "Etiqueta". No todos los casos tendrán una etiqueta y algunos casos pueden tener varias etiquetas. A continuación se muestra una tabla de Etiquetas de ejemplo.
Las fechas límite representan plazos en el proceso. Estos se agregan a los datos para analizar si las actividades se realizan a tiempo para estas fechas límite.
Cada registro de la tabla de fechas límite representa una fecha límite para un evento determinado. Las fechas límite de ejemplo son:
- un plazo de pago para un evento de pago.
- una fecha límite de aprobación para un evento de aprobación.
Event ID
, Due date
, Actual date
y Expected date
.
No todos los eventos tendrán una fecha límite y algunos eventos pueden tener varias fechas límite.
- Información general
- 1. Entrada
- Convencion de nombres
- Campos opcionales
- 2. Entidades
- Directrices
- Additional transformations
- Convencion de nombres
- 3. Eventos
- Timestamp fields
- Registro de transacción
- Convencion de nombres
- 4. Registros de eventos
- Proceso de entidad única
- Proceso de entidades múltiples
- Entity relations
- Relation tables
- Registro de evento
- Convencion de nombres
- 5. Lógica de negocios
- Etiquetas
- Fechas límite