Matriz Atributo-Actividad
Resumen
El calculador de la Matriz Atributo-Actividad proporciona una tabla cruzada completa que muestra la relación entre atributos y actividades en tu registro de eventos. Para cada combinación de atributo y actividad, muestra el número de casos que tienen valores, ayudando a los administradores a entender los patrones de completitud de datos e identificar problemas de calidad de datos.
IMPORTANTE: Este es un calculador exclusivo para administradores diseñado para el análisis técnico y la evaluación de la calidad de datos. Genera una matriz que muestra cómo se rellenan los atributos a lo largo de diferentes actividades, lo cual es esencial para entender los patrones de extracción de datos, identificar datos faltantes y validar la estructura del registro de eventos.
Este calculador se utiliza principalmente por administradores del sistema y especialistas en calidad de datos que necesitan comprender los patrones de población de atributos a lo largo de las actividades del proceso para resolver problemas, validar o optimizar conjuntos de datos.
Usos Comunes
- Identificar qué actividades completan atributos específicos para entender el flujo de datos en el proceso
- Detectar valores faltantes de atributos en actividades específicas que deberían tener datos
- Validar que atributos críticos estén poblados en las etapas del proceso esperadas
- Diagnosticar problemas de extracción de datos identificando lagunas sistemáticas en la población de atributos
- Entender dependencias de atributos en actividades específicas para el diseño de ETL
- Documentar qué actividades contribuyen con datos a qué atributos para especificaciones técnicas
Configuración
Este calculador no requiere configuraciones específicas. Al ejecutarse, genera automáticamente una matriz que muestra todos los atributos (tanto a nivel de caso como a nivel de evento) contra todas las actividades, con valores en las celdas que indican el número de casos donde ese atributo tiene un valor para esa actividad.
Nota: Para conjuntos de datos con muchos atributos y actividades, esta matriz puede ser muy grande. El calculador muestra la matriz completa, pudiendo requerirse desplazamiento para revisar todas las combinaciones.
Ejemplos
Ejemplo 1: Validando la Completitud de Datos de Aprobación
Escenario: Has implementado un nuevo sistema de seguimiento de aprobaciones y necesitas verificar que los atributos relacionados con aprobaciones se estén rellenando correctamente en cada etapa de aprobación de tu proceso de órdenes de compra.
Configuración:
- Título: "Análisis de Población de Atributos de Aprobación"
- Descripción: "Validar captura de datos de aprobación en el proceso P2P"
Salida:
El calculador muestra una matriz con las actividades como columnas y los atributos como filas. Para los atributos relacionados con aprobación, ves:
| Atributo | Crear OC | Enviar para Aprobación | Aprobación L1 | Aprobación L2 | Aprobación Finanzas | Enviar a Proveedor |
|---|---|---|---|---|---|---|
| ApproverName | 0 | 0 | 1,847 | 456 | 234 | 0 |
| ApprovalLevel | 0 | 0 | 1,847 | 456 | 234 | 0 |
| ApprovalTimestamp | 0 | 0 | 1,847 | 456 | 234 | 0 |
| ApprovalComments | 0 | 0 | 1,523 | 398 | 189 | 0 |
| DelegatedBy | 0 | 0 | 234 | 67 | 23 | 0 |
Análisis: La matriz confirma que los atributos de aprobación se rellenan correctamente solo durante las actividades de aprobación (L1, L2 y Aprobación de Finanzas), con población cero durante otras actividades como se esperaba. Todos los 1,847 casos que llegan a la Aprobación L1 tienen los campos ApproverName, ApprovalLevel y ApprovalTimestamp poblados, indicando captura completa de datos. Sin embargo, ApprovalComments muestra una menor población (1,523 casos en vez de 1,847 en L1), revelando que 324 casos carecen de comentarios de aprobación; esto podría ser aceptable si los comentarios son opcionales, pero requiere investigación. El atributo DelegatedBy aparece solo para un subconjunto de aprobaciones, capturando correctamente escenarios de delegación.
Ejemplo 2: Identificando Vacíos en la Extracción de Datos
Escenario: Tras fusionar datos de múltiples sistemas fuente en tu proceso de pedido a cobro, sospechas que algunos atributos no se están llenando consistentemente en todas las actividades esperadas.
Configuración:
- Título: "Verificación de Completitud de Datos Multifuente"
- Descripción: "Validar población de atributos desde CRM, ERP y sistemas de envío"
Salida:
| Atributo | Crear Pedido | Verificación Crédito | Selección Ítems | Empaque Ítems | Envío | Generar Factura | Recibir Pago |
|---|---|---|---|---|---|---|---|
| CustomerName | 2,456 | 2,456 | 2,456 | 2,456 | 2,456 | 2,456 | 2,456 |
| CreditScore | 2,456 | 2,456 | 2,456 | 2,456 | 2,456 | 2,456 | 2,456 |
| WarehouseLocation | 0 | 0 | 2,456 | 2,456 | 2,456 | 0 | 0 |
| CarrierName | 0 | 0 | 0 | 0 | 2,456 | 0 | 0 |
| TrackingNumber | 0 | 0 | 0 | 0 | 2,234 | 0 | 0 |
| InvoiceAmount | 0 | 0 | 0 | 0 | 0 | 2,456 | 2,456 |
| PaymentMethod | 0 | 0 | 0 | 0 | 0 | 0 | 1,987 |
Análisis: La matriz revela varios problemas de calidad de datos. CustomerName y CreditScore son atributos a nivel de caso (poblados en todas las actividades para todos los casos), lo cual es esperado. WarehouseLocation aparece correctamente solo en actividades de almacén (Selección, Empaque, Envío). Sin embargo, TrackingNumber muestra solo 2,234 casos en Envío en vez de los 2,456 esperados, revelando que 222 envíos carecen de número de seguimiento, una brecha crítica que requiere investigación. PaymentMethod muestra solo 1,987 casos en Recibir Pago en lugar de 2,456, indicando que 469 pagos carecen de dato de método de pago, sugiriendo un problema de integración con el sistema de pagos.
Ejemplo 3: Entendiendo el Ciclo de Vida del Atributo
Escenario: Necesitas documentar cuándo se vuelven disponibles atributos específicos durante el ciclo del proceso para guiar el diseño de análisis e informes posteriores.
Configuración:
- Título: "Documentación del Ciclo de Vida de Atributos"
- Descripción: "Mapear cuándo cada atributo se llena en el procesamiento de facturas"
Salida:
| Atributo | Recibir Factura | Validar Factura | Emparejar a OC | Aprobar Pago | Programar Pago | Realizar Pago | Cerrar Caso |
|---|---|---|---|---|---|---|---|
| InvoiceNumber | 3,456 | 3,456 | 3,456 | 3,456 | 3,456 | 3,456 | 3,456 |
| VendorID | 3,456 | 3,456 | 3,456 | 3,456 | 3,456 | 3,456 | 3,456 |
| PONumber | 0 | 0 | 3,456 | 3,456 | 3,456 | 3,456 | 3,456 |
| MatchStatus | 0 | 0 | 3,456 | 3,456 | 3,456 | 3,456 | 3,456 |
| ApprovedAmount | 0 | 0 | 0 | 3,456 | 3,456 | 3,456 | 3,456 |
| PaymentDate | 0 | 0 | 0 | 0 | 3,456 | 3,456 | 3,456 |
| ActualPaymentDate | 0 | 0 | 0 | 0 | 0 | 3,456 | 3,456 |
| ClosureReason | 0 | 0 | 0 | 0 | 0 | 0 | 3,456 |
Análisis: Esta matriz muestra claramente el ciclo de vida del atributo. InvoiceNumber y VendorID se llenan desde el inicio (atributos a nivel de caso establecidos al recibir la factura). PONumber y MatchStatus están disponibles solo después de Emparejar a OC, siendo inaccesibles en etapas anteriores. ApprovedAmount aparece en Aprobar Pago y se mantiene en actividades siguientes. PaymentDate (fecha programada) aparece en Programar Pago, mientras que ActualPaymentDate solo en Realizar Pago, diferenciando fechas planificadas de fechas reales. ClosureReason solo se llena en la actividad final. Este entendimiento del ciclo de vida es crucial para diseñar análisis que dependan de atributos específicos.
Ejemplo 4: Detectando Problemas Sistémicos de Calidad de Datos
Escenario: Los usuarios reportan disponibilidad inconsistente de datos en análisis. Necesitas identificar si ciertas actividades fallan sistemáticamente en rellenar atributos esperados.
Configuración:
- Título: "Análisis de Brechas Sistémicas de Datos"
- Descripción: "Identificar actividades con población faltante de atributos"
Salida:
| Atributo | Verificar Solicitud | Asignar Recurso | Iniciar Trabajo | Control Calidad | Completar Trabajo | Documentar Resultados |
|---|---|---|---|---|---|---|
| RequestID | 5,678 | 5,678 | 5,678 | 5,678 | 5,678 | 5,678 |
| AssignedTo | 0 | 5,678 | 5,678 | 5,678 | 5,678 | 5,678 |
| WorkCategory | 0 | 5,678 | 5,678 | 5,678 | 5,678 | 5,678 |
| StartTime | 0 | 0 | 5,678 | 5,678 | 5,678 | 5,678 |
| QualityScore | 0 | 0 | 0 | 4,234 | 4,234 | 4,234 |
| CompletionNotes | 0 | 0 | 0 | 0 | 5,678 | 5,678 |
| DocumentationLink | 0 | 0 | 0 | 0 | 0 | 3,456 |
Análisis: La matriz revela un problema crítico de calidad de datos. QualityScore debería estar poblado en Control Calidad para todos los casos (5,678), pero solo 4,234 casos tienen este atributo, lo que significa que faltan 1,444 casos (25%). Esto es una brecha sistémica que podría indicar un problema con el sistema de inspección o la extracción de datos. Además, DocumentationLink está faltante en 2,222 casos (39%) en Documentar Resultados, sugiriendo que la documentación se omite en una parte significativa del trabajo. Estas brechas sistemáticas requieren atención inmediata para asegurar la integridad de datos.
Ejemplo 5: Validando Integración Multi-Sistema
Escenario: Tu proceso integra datos de tres sistemas diferentes (CRM, ERP y logística), y necesitas verificar que los atributos de cada sistema estén correctamente asociados con las actividades apropiadas.
Configuración:
- Título: "Validación de Integración Multi-Sistema"
- Descripción: "Verificar población de atributos desde CRM, ERP y sistemas logísticos"
Salida:
| Atributo | Ingresar Pedido (CRM) | Reservar Inventario (ERP) | Asignar Stock (ERP) | Despacho (Logística) | Entrega (Logística) | Confirmar Recepción (CRM) |
|---|---|---|---|---|---|---|
| CustomerID (CRM) | 8,945 | 8,945 | 8,945 | 8,945 | 8,945 | 8,945 |
| SalesRepID (CRM) | 8,945 | 8,945 | 8,945 | 8,945 | 8,945 | 8,945 |
| SKU (ERP) | 8,945 | 8,945 | 8,945 | 8,945 | 8,945 | 8,945 |
| InventoryLocation (ERP) | 0 | 8,945 | 8,945 | 8,945 | 8,945 | 8,945 |
| StockLevel (ERP) | 0 | 8,945 | 8,945 | 8,945 | 8,945 | 8,945 |
| CarrierID (Logística) | 0 | 0 | 0 | 8,945 | 8,945 | 8,945 |
| DeliveryStatus (Logística) | 0 | 0 | 0 | 8,945 | 8,945 | 8,945 |
| ReceivedBy (CRM) | 0 | 0 | 0 | 0 | 0 | 7,234 |
Análisis: La matriz valida que la mayoría de las integraciones de sistemas funcionan correctamente. Los atributos de CRM (CustomerID, SalesRepID) están disponibles a lo largo del proceso como se espera para atributos a nivel de caso. Los atributos de ERP (InventoryLocation, StockLevel) aparecen correctamente desde la actividad Reservar Inventario. Los atributos logísticos (CarrierID, DeliveryStatus) aparecen apropiadamente desde Despacho en adelante. Sin embargo, hay un problema significativo con el atributo ReceivedBy: solo 7,234 casos de 8,945 tienen este atributo en Confirmar Recepción, lo que significa que 1,711 entregas (19%) carecen de confirmación de quién recibió el pedido. Esto requiere investigación en el flujo de trabajo de confirmación del CRM.
Ejemplo 6: Planificando Estrategia de Enriquecimiento de Atributos
Escenario: Deseas identificar qué atributos tienen población escasa y podrían beneficiarse de un enriquecimiento con datos de referencia o procesos de captura de datos mejorados.
Configuración:
- Título: "Análisis de Oportunidades para Enriquecimiento de Atributos"
- Descripción: "Identificar atributos escasos que requieren enriquecimiento"
Salida:
| Atributo | Enviar Reclamo | Revisar Documentos | Evaluar Daño | Aprobar Monto | Emitir Pago | Cerrar Reclamo |
|---|---|---|---|---|---|---|
| ClaimNumber | 12,456 | 12,456 | 12,456 | 12,456 | 12,456 | 12,456 |
| PolicyNumber | 12,456 | 12,456 | 12,456 | 12,456 | 12,456 | 12,456 |
| AdjusterID | 0 | 12,456 | 12,456 | 12,456 | 12,456 | 12,456 |
| AdjusterName | 0 | 0 | 0 | 0 | 0 | 0 |
| DamageCategory | 0 | 0 | 12,456 | 12,456 | 12,456 | 12,456 |
| EstimatedCost | 0 | 0 | 12,456 | 12,456 | 12,456 | 12,456 |
| ApprovalReason | 0 | 0 | 0 | 12,456 | 12,456 | 12,456 |
| PaymentMethodCode | 0 | 0 | 0 | 0 | 12,456 | 12,456 |
| PaymentMethodName | 0 | 0 | 0 | 0 | 0 | 0 |
Análisis: La matriz revela excelentes oportunidades de enriquecimiento. AdjusterID está poblado para todos los casos desde Revisar Documentos en adelante (12,456), pero AdjusterName nunca se llena. Enriquecer AdjusterID con nombres de tasadores obtenidos de una tabla de empleados haría los análisis más amigables. De manera similar, PaymentMethodCode está poblado para todos los pagos (12,456 casos), pero PaymentMethodName falta. Enriquecer los códigos de métodos de pago con nombres descriptivos mejoraría significativamente la legibilidad de los informes. Estos enriquecimientos agregarían un valor sustancial con poco esfuerzo, dado que las claves de referencia ya están presentes.
Salida
El calculador de la Matriz Atributo-Actividad muestra una tabla matriz completa con la siguiente estructura:
Filas: Cada fila representa un atributo de tu registro de eventos, incluyendo tanto atributos a nivel de caso (que aplican a todo el caso) como atributos a nivel de evento (que pueden variar por actividad).
Columnas: Cada columna representa una actividad única de tu proceso.
Valores de Celda: Cada celda contiene un número que representa cuántos casos tienen un valor para ese atributo en esa actividad. Un valor de 0 significa que el atributo no está poblado para ningún caso en esa actividad.
Entendiendo los Valores de Celda
Atributos a Nivel de Caso: Para atributos a nivel de caso (como CustomerID, OrderNumber, etc.), el valor de la celda será el mismo en todas las actividades para esa fila, mostrando el total de casos donde el atributo tiene un valor.
Atributos a Nivel de Evento: Para atributos a nivel de evento (como ApproverName, WarehouseLocation, etc.), los valores de celda varían según la actividad, mostrando dónde en el proceso se llena ese atributo.
Valores Cero: Un valor de celda 0 indica que el atributo nunca se llena en esa actividad, lo que puede ser un comportamiento esperado o indicar un problema de calidad de datos dependiendo del proceso.
Funcionalidades Interactivas
Ordenar y Filtrar: Haz clic en los encabezados de columna para ordenar la matriz por actividad. Usa la búsqueda del navegador para localizar atributos específicos rápidamente.
Exportar Resultados: Exporta la matriz completa a Excel o CSV para análisis detallados offline, documentación o para compartir con equipos técnicos.
Matrices Grandes: Para procesos con muchas actividades y atributos, la matriz puede ser muy grande. Considera usar desplazamiento horizontal y vertical para navegar toda la matriz.
Interpretando los Patrones de Población
Población Consistente: Si un atributo muestra el mismo valor no cero en todas las actividades, es un atributo a nivel de caso poblado temprano en el proceso.
Población Progresiva: Si un atributo muestra valores cero en actividades tempranas y valores no cero en actividades posteriores, indica que el atributo se llena en una etapa específica del proceso.
Población Parcial: Si un atributo muestra un valor menor que el conteo total de casos, algunos casos no tienen el atributo, indicando posibles problemas de calidad de datos o campos opcionales.
Población Específica por Actividad: Si un atributo muestra valores no cero solo para ciertas actividades, es un atributo a nivel de evento relevante solo para esas actividades.
Consideraciones de Rendimiento
- Conjuntos de Datos Grandes: Para conjuntos con cientos de atributos y actividades, este calculador puede requerir tiempo significativo de procesamiento.
- Uso de Recursos: El calculador escanea todas las combinaciones atributo-actividad, lo cual es intensivo en recursos computacionales.
- Buenas Prácticas: Ejecuta este calculador fuera de horas pico para conjuntos de datos muy grandes.
Acceso Administrativo
Este calculador está restringido a usuarios con rol de Administrador. Los usuarios comunes que necesiten entender las características del conjunto de datos deberían usar el calculador Información del Dataset, que proporciona métricas resumidas sin el desglose detallado atributo-actividad.
Esta documentación es parte de la plataforma de minería de procesos mindzieStudio.