- Notas relacionadas
- Antes de empezar
- Primeros pasos
- Integraciones
- Gestionar el acceso
- Trabajar con apps de proceso
- Creación de aplicaciones
- Cargar datos
- Cargar datos
- Retrieving the SQL Server database parameters
- Configurar una cuenta de SQL Server para la carga de datos utilizando un Extractor
- Loading data using Theobald Xtract Universal
- Personalizar apps de proceso
- Transformaciones de datos
- TemplateOne
- Plantilla de la app Purchase to Pay
- Plantilla de la aplicación Order to Cash
- Basic troubleshooting guide
Process Mining
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.
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 se pueden definir aquí.
Invoices_input, Invoice_types_inputy 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 apps de proceso TemplateOne-SingleFile y TemplateOne-MultiFiles .
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_createden 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_invoicey 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 para obtener más información. 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 datey 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
- 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
