- 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
- 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
- Introducción a los paneles
- Crear paneles
- Paneles
- Gestor de automatización
- Input data
- Definición de nuevas tablas de entrada
- Añadir campos
- Añadir tablas
- Requisitos del modelo de datos
- Ver y editar el modelo de datos
- Exportar e importar transformaciones
- Ver los registros de transformaciones
- Editar y probar transformaciones de datos
- Structure of transformations
- Combinar registros de eventos
- Tips for writing SQL
- Gestor de procesos
- Publicar aplicaciones de proceso
- Plantillas de la aplicación
- Recursos adicionales

Process Mining
Structure of transformations
models\
en la sección Transformaciones de Transformaciones de datos 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 Objeto, las tablas de entrada se transforman en tablas de objetos. Cada objeto necesario para los eventos esperados debe tener su propia tabla. Consulta Diseñar un registro de eventos. Además, el objeto de apoyo también se puede definir aquí.
Invoices_input
, Invoice_types_input
y Customers_input
para crear la tabla de objetos Facturas.
Sigue estas directrices al crear una tabla de objetos.
- Hay un campo de ID de objeto, que es único para cada registro de datos.
- Todos los campos de objeto necesarios para el análisis de datos están presentes.
- Todos los campos de objeto tienen nombres que son fáciles de entender.
Invoice_ID
.
No todas las tablas de entrada se transforman en tablas de objetos. Además, otras tablas de entrada pueden contener información relevante, como la tabla Clientes del ejemplo. Puede ser conveniente definirlos en el paso Objetos como tablas independientes para 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 objeto. 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:
- Campos de marca de tiempo: campos en una tabla de objetos 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, deben identificarse los eventos relevantes por objeto. Crea una tabla por objeto y almacena el ID de objeto correspondiente, el nombre del evento (Actividad) y la marca de tiempo en que tuvo lugar el evento (Fin del evento).
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 |
---|---|
IdDeObjeto |
ID del objeto para el que ocurre el evento. Por ejemplo, el ID de la factura. |
Actividades |
La actividad describe qué acción tuvo lugar en el objeto. |
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. |
[Activity] + _events
para crear un archivo de eventos por actividad, o [Object] + _events
para crear un archivo de eventos por objeto. Por ejemplo, Purchase_order_created_events
, Purchase_order_approved_events
o un archivo con todas las actividades de orden de compra combinadas Purchase_order_events
.
Cuando el proceso contiene un objeto, no se necesitan transformaciones adicionales en este paso. La tabla de un solo objeto y las tablas de eventos ya están en el formato correcto.
Cuando hay varios objetos involucrados en un proceso, los eventos de todos los objetos deben vincularse al objeto principal que se considera el "Caso" en el proceso. Consulta Definir el registro de eventos para obtener más detalles. Los siguientes pasos describen cómo relacionar todos los eventos con el objeto principal y cómo combinarlos en un único registro de eventos.
Crea una tabla de "relaciones de objetos" para centralizar las relaciones entre todos los objetos. Esta tabla de relaciones de objetos contendrá los campos de ID de los objetos relacionados.
Para crear la tabla de relaciones de objetos, une todas las tablas de objetos en función de sus campos de ID:
- Comenzar con el objeto principal
- Unir objetos relacionados al objeto principal con una combinación izquierda.
- Si los objetos no se relacionan directamente con el objeto principal, únelos a los objetos relacionados que ya están unidos al objeto principal.
En el siguiente ejemplo, hay tres objetos: orden de compra,línea de factura y factura. La orden de compra se considera el objeto principal del proceso. La línea Factura está directamente vinculada a la Orden de compra y la Factura está vinculada indirectamente a través de la línea Factura.
Object_relations as (
select
Purchase_orders."Purchase_order_ID"
Invoice_lines.Invoice_line_ID
"Invoices.Invoice_ID"
from Purchase_orders
left join Invoice_lines
on Purchase_orders."Purchase_order_ID" = "Invoice_lines."Purchase_order_ID"
left join Invoices
on Invoice_lines."Invoice_ID" = Invoices."Invoice_ID
)
Object_relations as (
select
Purchase_orders."Purchase_order_ID"
Invoice_lines.Invoice_line_ID
"Invoices.Invoice_ID"
from Purchase_orders
left join Invoice_lines
on Purchase_orders."Purchase_order_ID" = "Invoice_lines."Purchase_order_ID"
left join Invoices
on Invoice_lines."Invoice_ID" = Invoices."Invoice_ID
)
La siguiente ilustración muestra la tabla de relaciones de objetos resultante.
Las relaciones individuales entre el objeto principal y cada uno de los objetos se almacenan en tablas separadas, utilizando la información combinada de la tabla de relaciones de objetos.
Relation_invoice_lines as (
select
Object_relations."Purchase_order_ID"
Object_relations."Invoice_line_ID"
from Object_relations
group by "Purchase_order_ID", "Invoice_line_ID"
)
Relation_invoice_lines as (
select
Object_relations."Purchase_order_ID"
Object_relations."Invoice_line_ID"
from Object_relations
group by "Purchase_order_ID", "Invoice_line_ID"
)
Relation_invoices as (
select
Object_relations."Purchase_order_ID"
Object_relations."Invoice_ID"
from Object_relations
group by "Purchase_order_ID", "Invoice_ID"
)
Relation_invoices as (
select
Object_relations."Purchase_order_ID"
Object_relations."Invoice_ID"
from Object_relations
group by "Purchase_order_ID", "Invoice_ID"
)
El siguiente paso es utilizar estas relaciones para añadir el "ID de caso" correspondiente a cada tabla de eventos. El "ID de caso" se obtiene a través de la tabla de relaciones, donde la información del evento se obtiene de la tabla de eventos. Para crear el registro de eventos completo, se unen las tablas de eventos de cada objeto.
Purchase_order_event_log as (
select
Purchase_order_events."Purchase_order_ID"
Purchase_order_events."Activity"
Purchase_order_events."Event_end"
from Purchase_order_events
union all
select
Relation_invoice_lines."Purchase_order_ID"
Invoice_line_events."Activity"
Invoice_line_events."Event_end"
from Invoice_line_events
inner join Relation_invoice_lines
on Invoice_line_events."Invoice_line_ID" = "Relation_invoice_lines."Invoice_line_ID"
union all
select
Relation_invoices."Purchase_order_ID"
Invoice_events. "Activity"
Invoice_events. "Event_end"
from Invoice_events
inner join Relation_invoices
on Invoice_events."Invoice_line_ID" = Relation_invoices."Invoice_line_ID"
)
Purchase_order_event_log as (
select
Purchase_order_events."Purchase_order_ID"
Purchase_order_events."Activity"
Purchase_order_events."Event_end"
from Purchase_order_events
union all
select
Relation_invoice_lines."Purchase_order_ID"
Invoice_line_events."Activity"
Invoice_line_events."Event_end"
from Invoice_line_events
inner join Relation_invoice_lines
on Invoice_line_events."Invoice_line_ID" = "Relation_invoice_lines."Invoice_line_ID"
union all
select
Relation_invoices."Purchase_order_ID"
Invoice_events. "Activity"
Invoice_events. "Event_end"
from Invoice_events
inner join Relation_invoices
on Invoice_events."Invoice_line_ID" = Relation_invoices."Invoice_line_ID"
)
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 objetos, que significan ciertas reglas empresariales. Las etiquetas se suelen añadir 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.
Object ID
y Tag
. No todos los objetos tendrán una etiqueta y algunos objetos pueden tener varias etiquetas. La siguiente ilustración muestra un ejemplo de tabla de etiquetas.
Solo se permite una tabla de etiquetas en el modelo de datos.
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 de vencimiento representa una fecha de vencimiento para un objeto determinado. Ejemplos de fechas de vencimiento son:
- una fecha límite de pago para un pago.
- una fecha límite de aprobación para una orden de compra.
Object ID
, Due date
, Actual date
y Expected date
.
Solo se permite una tabla de Fechas de vencimiento en el modelo de datos.
- Información general
- 1. Entrada
- Convencion de nombres
- Campos opcionales
- 2. Objetos
- Directrices
- Additional transformations
- Convencion de nombres
- 3. Eventos
- Timestamp fields
- Registro de transacción
- Convencion de nombres
- 4. Registros de eventos
- Proceso de objeto único
- Proceso de varios objetos
- Relaciones de objetos
- Relation tables
- Registro de evento
- Convencion de nombres
- 5. Lógica de negocios
- Etiquetas
- Fechas límite