- 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
- 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
- Trabajar con el editor del panel
- Crear paneles
- Paneles
- Gestor de automatización
- 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 el registro de transformaciones
- Editar y probar transformaciones de datos
- Structure of transformations
- Tips for writing SQL
- Combinar registros de eventos
- Gestor de procesos
- Plantillas de la aplicación
- Recursos adicionales
- Etiquetas y fechas de vencimiento listas para usar
- Editar transformaciones de datos en un entorno local
- Setting up a local test environment
- Designing an event log
- Ampliar la herramienta de extracción de SAP Ariba
- Características de rendimiento

Process Mining
Designing an event log
Al configurar las transformaciones para Process Mining, es importante tener una buena comprensión del proceso. El primer paso es definir los eventos que se producen y los objetos en los que tienen lugar estos eventos.
Comience definiendo las actividades de alto valor. Priorice la adición de actividades en función de la frecuencia con la que ocurren y su importancia para el usuario final. La definición de las actividades debe ser un proceso iterativo.
La siguiente ilustración muestra un ejemplo de un registro de eventos para el proceso Facturas.
El número ideal de actividades para describir un proceso es entre 10 y 20. Aunque más actividades darán lugar a más posibilidades de análisis, también darán lugar a más variaciones de procesos y a una mayor complejidad.
Número de actividades |
Resultado |
---|---|
<10 |
Baja complejidad de análisis, bajo número de posibles mejoras. |
10-20 |
Equilibrio óptimo entre la complejidad del análisis y las posibles mejoras |
20 |
Alta complejidad de análisis, alto número de pequeñas mejoras. |
Convenciones de nombres
Para los nombres de actividad, la mejor práctica es utilizar el formato Verbo Sustantivo, como Crear documento. La siguiente tabla contiene algunos consejos sobre la denominación de actividades.
Nombre de actividad |
Asesoramiento |
Mejores prácticas |
---|---|---|
Orden Orden |
Evita los nombres ambiguos de las actividades. |
Solicitar material |
Ticket |
Evita los nombres singulares de las actividades, indica qué pasó con qué. |
Crear ticket |
Documento cancelado |
Evita la voz pasiva. |
Cancelar documento |
Aprobar la comprobación del control de crédito en el pedido |
Evita los nombres de actividades demasiado largos |
Aprobar la verificación de crédito SO |
Los eventos tienen lugar en uno o más objetos del proceso. Utilice el conjunto de eventos deseados para determinar qué objetos son necesarios para un proceso empresarial. La siguiente tabla muestra un ejemplo de un conjunto de eventos y sus objetos correspondientes.
Evento |
Objeto |
Crear orden de compra |
Orden de compra |
Aprobar orden de compra |
Orden de compra |
Crear factura |
Factura |
Cambiar las condiciones de pago |
Factura |
purchase_order_type
y un objeto de factura puede tener un payment_due_date
.
El número de objetos que son de interés en un proceso varía en función de la complejidad del proceso. En algunos procesos, solo se puede requerir un objeto, como el ticket en un proceso de gestión de incidentes.
En procesos más complejos, varios objetos pueden ser de interés. Por ejemplo, un proceso Purchase-to-Pay que comienza con la compra de un producto hasta el pago de una factura cubre un conjunto de eventos relacionados con múltiples objetos. Para crear un registro de eventos para tales procesos, deben definirse las relaciones entre los objetos. La siguiente ilustración muestra un ejemplo de diagrama de relaciones de objetos Purchase-to-Pay.
El registro de eventos describe el proceso de extremo a extremo que cubre los eventos de todos los objetos combinados. Solo un objeto del proceso puede funcionar como objeto principal, del que se realizará un seguimiento durante todo el proceso. Este objeto principal se denomina "Caso" en el proceso, identificado por su "ID de caso".