Un diagrama de process mining solo puede reconstruir los hechos presentes en el registro. Si una aprobación se realiza por teléfono y nadie la registra, el análisis no descubrirá cuándo ocurrió. Antes de interpretar cuellos de botella, comprueba qué parte del proceso representan tus datos.
Esta lista de revisión ayuda a decidir si una extracción está preparada para un primer análisis. El entregable es un registro de eventos explicable, junto con las actividades que todavía no puedes observar.
1. Define qué representa un caso
Un caso es la instancia del proceso que quieres seguir. Puede ser una solicitud o un pedido. No tiene por qué coincidir con un cliente: una misma persona puede tener varios pedidos abiertos y mezclar sus eventos produciría un recorrido ficticio.
En un ejemplo de compras, decide si vas a estudiar la solicitud completa o cada línea. Una solicitud puede tener varios proveedores y recepciones parciales; usar su identificador sin aclarar ese alcance puede hacer que actividades legítimamente paralelas parezcan repeticiones.
Comprueba que todas las filas tienen identificador y que este no se reutiliza para operaciones distintas entre sistemas.
2. Normaliza actividades sin borrar diferencias útiles
“Validar”, “Validación” y “Solicitud validada” pueden representar el mismo hecho o tres estados distintos. La equivalencia debe confirmarla quien conoce el proceso.
Conserva el evento original y una actividad normalizada. Esto permite corregir el mapeo sin perder evidencia. No agrupes aprobación automática y aprobación manual si después necesitas estudiar cómo influyen en el recorrido.
Microsoft identifica el caso, la actividad y las marcas temporales como elementos necesarios para preparar datos de process mining. La elección de su significado requiere conocer el sistema de origen.
3. Separa el momento del hecho y el de su registro
Una integración nocturna puede guardar todos los cambios con la hora de importación. Si la interpretas como hora del evento, el análisis mostrará una actividad concentrada que quizá nunca existió en la operación.
Documenta zona horaria, precisión y origen de cada marca. Si varios eventos tienen la misma hora, utiliza una secuencia fiable cuando exista. No inventes segundos para imponer un orden que el registro no permite conocer.
4. No llames duración a cualquier diferencia de fechas
Supongamos esta secuencia ilustrativa:
| Caso | Actividad | Hora registrada |
|---|---|---|
| S-18 | Solicitud recibida | 09:00 |
| S-18 | Revisión iniciada | 11:00 |
| S-18 | Revisión completada | 11:20 |
Entre la recepción y el final transcurren dos horas y veinte minutos. La revisión registrada dura veinte minutos; el intervalo previo incluye espera y puede contener trabajo que el sistema no observa.
Si solo tienes eventos de finalización, no puedes deducir directamente cuánto tiempo estuvo trabajando una persona. Presenta el intervalo observado con su significado real.
5. Busca casos incompletos y duplicados
Una ventana de extracción puede cortar procesos que comenzaron antes o terminaron después. Marca esos casos para evitar comparar recorridos completos con parciales sin advertirlo.
Revisa eventos duplicados por reenvíos y cambios que sustituyen el estado anterior sin conservar su historia. Una tabla con el estado actual de cada solicitud no equivale a un registro histórico de eventos.
6. Valida recorridos antes de interpretar resultados
Selecciona casos normales, rechazados, reabiertos y con recepciones parciales. Reconstrúyelos con el responsable del proceso y compara el relato con el registro.
Deja por escrito los pasos no observables, las reglas de normalización y las limitaciones temporales. Solo entonces utiliza el análisis para formular hipótesis de mejora; una variante infrecuente no es automáticamente un error. Si la mejora requiere integrar sistemas, la decisión entre RPA e integración por API se toma después de entender ese recorrido.
Si preparas un proyecto de automatización de procesos, comparte con Nexeus Big Data una muestra de eventos y el recorrido que quieres estudiar. Verificar esa evidencia ayuda a elegir qué automatizar y qué información falta antes de decidir.