Rendimiento de Process Mining: comparativas y consejos

Qué determina el rendimiento de Process Mining

El rendimiento de Process Mining depende de tres factores: cuántos datos carga, cómo los estructura y cómo los procesa el sistema. Esta guía aborda los tres aspectos con comparativas reales y formas prácticas de mejorar los resultados.

Publicamos todas nuestras cifras. Compárelas con cualquier herramienta de Process Mining del mercado.

La canalización de datos: dónde se emplea el tiempo

Cuando carga datos en ProcessMind, ocurren tres cosas. Aquí se explica exactamente dónde se emplea el tiempo:

1. Carga (domina el tiempo total). Su archivo viaja por internet hasta nuestra infraestructura en la nube. Este es el cuello de botella para los archivos grandes. La física se impone: un CSV de 50 millones de eventos (11 GB) tarda 2 minutos con una conexión de 1 Gbps, 18 minutos con 100 Mbps o más de 3 horas con 10 Mbps. Los mismos datos en Parquet ocupan solo 1,7 GB, lo que reduce esos tiempos a 19 segundos, 3 minutos y 28 minutos. Esta es la razón principal para utilizar formatos columnares como Parquet u ORC, o conjuntos de datos más pequeños.

2. Preprocesamiento (coste único, de ~30 s a 2,5 min). Una vez cargados, transformamos sus datos en un almacenamiento columnar optimizado: indexamos los eventos, precalculamos las transiciones de actividades, identificamos las variantes del proceso y calculamos las estadísticas resumidas. Esto tarda 30 segundos en conjuntos de datos pequeños y hasta 2,5 minutos con 100 millones de eventos. Este coste se aplica una sola vez por carga y después puede aprovechar sus resultados.

3. Cambios en el modelo (recálculo parcial, de 6 a 52 s). Cuando modifica el modelo del proceso al añadir o eliminar actividades, o cambiar las asignaciones, solo se actualizan los cálculos que dependen del modelo. Esto tarda 6 segundos en conjuntos de datos pequeños y hasta 52 segundos con 100 millones de eventos, mucho menos que un preprocesamiento completo. Los cambios en los filtros son instantáneos.

Comprender el rendimiento de las consultas

Una vez cargados sus datos, varias características determinan la velocidad de las consultas. Comprenderlas le ayuda a diseñar mejores exportaciones y establecer expectativas realistas.

El número de actividades es importante. Los modelos de proceso con entre 10 y 20 actividades distintas son óptimos. Por encima de 50 actividades, el flujo del proceso tarda más en calcularse y resulta más difícil de comprender. Demasiados nodos y conexiones generan ruido visual. Si su exportación contiene muchas actividades, considere agrupar los pasos relacionados.

La diversidad de variantes afecta al cálculo. Un proceso en el que el 80 % de los casos sigue 5 variantes se analiza más rápido que otro en el que cada caso toma una ruta única. Una variación elevada no es necesariamente negativa y a menudo señala problemas reales, pero debe prever tiempos de consulta algo más largos.

Más columnas implican más datos que analizar. Cada atributo que incluye se indexa y se consulta. Las columnas principales, CaseId, Activity y Timestamp, siempre son necesarias. Las columnas adicionales ayudan a filtrar y categorizar, pero cada una añade carga.

Los casos largos tardan más. Un caso con 50 eventos requiere más cálculo que uno con 5. Si su proceso tiene casos que abarcan cientos de eventos, las consultas serán proporcionalmente más lentas. Esto es inherente al Process Mining y no depende de una herramienta concreta.

Datos de referencia del mundo real (marzo de 2026)

Comprender qué puede esperar le ayuda a planificar. Estas pruebas de referencia se ejecutan en infraestructura de producción de AWS, con latencia de red real, y representan el promedio de varias ejecuciones. Probamos más de 50 tipos de consulta por tamaño de conjunto de datos.

Tiempos de carga y preprocesamiento

La tabla siguiente muestra expectativas realistas para cada tamaño de conjunto de datos. El tiempo de carga domina en los archivos grandes, especialmente con conexiones lentas. Es el factor individual que más influye en su tiempo total de espera.

Los tamaños corresponden a un CSV sin comprimir con un esquema de Registro de eventos habitual (CaseId, Activity, Timestamp y entre 5 y 8 atributos empresariales). Sus archivos pueden ser más grandes o más pequeños según el número y el contenido de las columnas.

Los tiempos de carga a 1 Gbps se han medido con un rendimiento efectivo de 88 MB/s hacia AWS eu-central-1. Las demás velocidades se extrapolan a partir de rendimientos prácticos: 50 Mbps → ~5 MB/s, 100 Mbps → ~10 MB/s y 10 Mbps → ~1 MB/s. El rendimiento real depende de su red, la distancia al centro de datos y la carga actual.

La idea clave: el tiempo de preprocesamiento se mantiene entre 1 y 2,5 minutos, independientemente de la escala. El tiempo de carga aumenta de forma lineal con el tamaño del archivo. Reducir el tamaño del archivo es la optimización con mayor impacto que puede aplicar.

Elija el formato de archivo adecuado

El formato del archivo que carga influye mucho en la velocidad de carga y el tiempo de preprocesamiento. ProcessMind admite CSV, Parquet, ORC, Excel y XES. En conjuntos de datos grandes, Parquet y ORC superan ampliamente a CSV tanto en tamaño de archivo como en velocidad de procesamiento.

Comparación del tamaño de los archivos

Los archivos Parquet son un 85 % más pequeños que los CSV. Los archivos ORC son un 82 % más pequeños. Ambos son formatos columnares con compresión integrada, por lo que no se necesita ningún paso adicional. Es probable que su herramienta de ETL o plataforma de datos, como Spark, Databricks, dbt o BigQuery, ya admita la exportación a Parquet u ORC.

Preprocesamiento según el formato

El tamaño del archivo es solo la mitad de la historia. Después de la carga, sus datos pasan por una ingesta y un cálculo analítico que dependen del formato, incluidos el indexado de eventos y los cálculos de transiciones y variantes. El paso analítico domina y es igual para todos los formatos. CSV.GZ es el único formato que añade un tiempo considerable, porque los archivos gzip no se pueden dividir para descomprimirlos en paralelo.

El tiempo de preprocesamiento es prácticamente idéntico para Parquet, ORC y CSV porque el cálculo analítico domina independientemente del formato de entrada. Sin embargo, el preprocesamiento de CSV.GZ se degrada considerablemente a escala, al pasar de aproximadamente un minuto con 1 millón de eventos a más de 4 minutos con 100 millones. Los archivos comprimidos con gzip no se pueden dividir ni procesar en paralelo, por lo que la descompresión añade un paso cada vez más largo antes de que pueda comenzar el análisis.

La visión completa

Si considera tanto el tiempo de carga como el preprocesamiento, la elección del formato resulta clara:

A escala, Parquet y ORC son los claros ganadores porque sus archivos son mucho más pequeños. El tiempo de carga es el principal cuello de botella. El preprocesamiento tarda aproximadamente lo mismo en todos los formatos, excepto en CSV.GZ, que acumula una penalización de descompresión cada vez mayor.

Carga incremental: añada datos sin volver a cargarlo todo

Una vez cargado un conjunto de datos de referencia, no necesita volver a cargarlo todo cuando llegan datos nuevos. ProcessMind admite la carga incremental, o cargas progresivas, para que pueda añadir nuevos eventos a un conjunto de datos existente.

Cómo funciona:

1. Cargue su conjunto de datos inicial, por ejemplo, las órdenes de compra del primer trimestre de 2026 con 2,3 millones de eventos
2. Cuando lleguen los datos del segundo trimestre, cargue solo los eventos nuevos en un archivo incremental, por ejemplo, 800.000 eventos nuevos
3. ProcessMind combina los archivos automáticamente y vuelve a procesarlos

El impacto en el rendimiento es considerable. En lugar de volver a cargar cada vez el conjunto de datos en crecimiento, cargue solo lo nuevo:

Después de una carga incremental, el preprocesamiento vuelve a ejecutarse sobre el conjunto de datos combinado, con el mismo coste de 1–2,5 minutos. Pero ahorra todo el tiempo de carga de los datos que ya había cargado.

La carga incremental es ideal para:

• Actualizaciones de datos semanales o mensuales: añada nuevas transacciones a medida que estén disponibles
• Supervisión continua del proceso: mantenga los Dashboards actualizados sin cargas grandes
• Registros de eventos en crecimiento: añada nuevos eventos desde ERP, CRM u otros sistemas de origen

Los archivos incrementales deben utilizar el mismo formato y la misma estructura de columnas que la carga original. Consulte la guía de carga incremental de datos para obtener más información.

Uso de la API para cargas grandes o automatizadas

Para conjuntos de datos de varios gigabytes o cargas recurrentes, los scripts o las herramientas de línea de comandos son más fiables que las cargas desde el navegador. Los navegadores pueden agotar el tiempo de espera, consumir demasiada memoria o perder el progreso si se interrumpe la red.

Por qué la API funciona mejor con archivos grandes:

• Transferencias fiables. Si se interrumpe la conexión, puede volver a intentarlo sin empezar de cero.
• Sin límites de memoria del navegador. Los navegadores tienen dificultades con archivos de varios gigabytes. Las herramientas de línea de comandos los gestionan fácilmente.
• Automatización. Programe cargas nocturnas, integre sus procesos de ETL o active cargas desde CI/CD.
• Supervisión del progreso. Herramientas como curl muestran el progreso de la transferencia en tiempo real.
• Cargas incrementales. Añada nuevos datos mediante programación según un calendario.

Ejemplo con curl:

# Upload a Parquet file directly using a presigned URL
curl -X PUT "$PRESIGNED_URL" --upload-file data.parquet

ProcessMind proporciona URL prefirmadas que autorizan cargas directas al almacenamiento en la nube. No se necesitan credenciales adicionales aparte de su clave de API. También puede copiar la URL de carga prefirmada directamente desde el menú de configuración del conjunto de datos en la interfaz de ProcessMind.

Consulte la documentación de la API para ver ejemplos completos en Bash, JavaScript y Python, incluido cómo obtener URL prefirmadas, cargar archivos incrementales y gestionar conjuntos de datos grandes mediante programación.

Velocidad de iteración del modelo

Cuando perfecciona su modelo de proceso al cambiar el nombre de las actividades, modificar las asignaciones o añadir agrupaciones, solo es necesario actualizar los cálculos que dependen del modelo. Los datos base permanecen en su lugar:

Los cambios del modelo son rápidos porque el paso inicial de carga de datos, que aumenta con el tamaño del conjunto, ya se ha completado. Solo vuelve a ejecutarse la agregación que depende del modelo, incluidas las asignaciones de actividades, las transiciones y las variantes. En conjuntos de datos de hasta 20 millones de eventos, los cambios del modelo se completan en menos de 25 segundos. Incluso con 100 millones de eventos, tardan menos de un minuto, mucho menos que un preprocesamiento completo.

Tiempos de respuesta del panel

Una vez cargados sus datos, estos son los tiempos de respuesta que experimenta durante el análisis. Los tiempos siguientes son medianas calculadas a partir de varias ejecuciones de referencia. Cada componente del panel realiza sus consultas de forma independiente y se carga en paralelo:

Patrones que conviene observar:

• Las estadísticas, incluidos los recuentos y las duraciones resumidos, se mantienen en ~0,6 s independientemente del tamaño. Estas consultas están muy optimizadas.
• El flujo del proceso, el diagrama del proceso, aumenta con el tamaño del conjunto de datos porque calcula las transiciones entre todas las actividades.
• Las variantes y las categorías aumentan moderadamente. Los datos preagregados mantienen su rapidez.
• El navegador de datos se mantiene rápido gracias a la paginación. Con filtros aplicados, baja de 1 s.
• La animación varía según el número de casos activos que se visualizan.

La conclusión: con los tamaños de conjunto de datos recomendados, de 1 a 10 millones de eventos, todos los componentes del panel responden en menos de 3,5 segundos. Incluso con 50 millones, la mayoría de las consultas se completan en 2–4 segundos con filtros aplicados. Solo los flujos de proceso y las vistas de categorías sin filtrar en conjuntos de datos de más de 50 millones alcanzan los 5–6 segundos.

Empiece con poco y crezca después

Este es el consejo más importante de esta guía: no empiece con su conjunto de datos más grande.

Los números hablan por sí solos:

La mayoría de las organizaciones descubren que entre 1 y 5 millones de eventos son más que suficientes para obtener información útil. El comportamiento del proceso se estabiliza mucho antes de llegar a 10 millones de eventos. A partir de ahí, en su mayoría solo añade duplicados de patrones que ya ha visto.

Si su archivo Parquet de 1 millón de eventos, de 34 MB, se carga en 3 segundos y le proporciona el mismo mapa de proceso que 50 millones de eventos, ¿por qué esperar 18 minutos?

Estrategia de datos: encuentre el tamaño adecuado

Las cifras anteriores cuentan una historia clara: con entre 1 y 5 millones de eventos, las cargas tardan segundos, el preprocesamiento tarda menos de 2 minutos y los Dashboards responden en 1–2,5 segundos. Con 50 millones, debe esperar 20 minutos para cargar los datos a través de una conexión de 100 Mbps, y los Dashboards tardan entre 3 y 6 segundos. La experiencia cambia radicalmente.

Por tanto, la pregunta real no es «¿qué tan rápida es la herramienta?», sino «¿cuántos datos necesito realmente?». La respuesta casi siempre es menos de lo que cree.

Segmente primero y agregue después

Analice primero un país, un departamento o una línea de productos.

No se trata de limitarse, sino de ganar claridad. El análisis segmentado produce información más precisa que los promedios globales.

Por qué funciona la segmentación:

• Los procesos varían según la región. Las operaciones alemanas siguen cadenas de aprobación distintas de las operaciones estadounidenses. Las leyes laborales francesas generan Workflow de RR. HH. diferentes. Analizarlos juntos genera ruido.
• Distintos grupos de interés, distintas prioridades. La persona responsable de EMEA se interesa por EMEA. Muéstrele los datos de EMEA. La vista global puede esperar.
• Iteración más rápida. Los datos de un solo país pueden contener 500.000 eventos en lugar de 10 millones. Puede iterar en minutos, no en horas.
• Comparación integrada. Una vez analizada Alemania, haga lo mismo con Francia. Ahora puede comparar.

Ejemplo: una empresa europea de logística con 42 millones de eventos de envíos en 8 países:

• Analizarlo todo: 42 millones de eventos, 9,3 GB, 16 min de carga (100 Mbps), 2 min de preprocesamiento
• Analizar solo Alemania: 8,5 millones de eventos, 1,9 GB, 3 min de carga, 1,5 min de preprocesamiento
• Analizar solo los Países Bajos: 3,1 millones de eventos, 690 MB, 1 min de carga, 1 min de preprocesamiento
• Usar la carga incremental: cargar primero Alemania y añadir después los Países Bajos cuando estén listos

Filtre la ruta habitual

Excluya la ruta habitual antes de cargar los datos. Esta técnica puede reducir los conjuntos de datos entre un 90 y un 95 %.

La mayoría de los procesos empresariales siguen la regla 80/20. La gran mayoría de los casos sigue la ruta estándar y satisfactoria. Si busca excepciones, incumplimientos de Cumplimiento o desviaciones del proceso, no necesita esos datos.

Ejemplo: un proceso de compra a pago con 1,2 millones de órdenes de compra (8,4 millones de eventos):

• 1,1 millones de pedidos (92 %) siguen la ruta habitual: Crear PO → Aprobar → Goods Receipt → Invoice → Payment
• 96.000 pedidos (8 %) presentan excepciones: rechazos, devoluciones, facturas duplicadas y aprobaciones pendientes

Si analiza problemas de Cumplimiento, exporte solo los casos con excepciones. Esto supone una reducción del 92 %, de 8,4 millones de eventos (1,9 GB) a 670.000 eventos (150 MB). El tiempo de carga baja de 3 minutos a 15 segundos con 100 Mbps. Exporte en Parquet (15 MB) y podrá cargarlo en menos de 2 segundos.

Selección de columnas: menos es más

Cada columna que exporta consume ancho de banda, almacenamiento y tiempo de procesamiento. Elegir las columnas con cuidado es una de las optimizaciones con mayor impacto que puede aplicar.

Qué debe excluir:

• Campos de texto largos. Descripciones de órdenes, comentarios, notas y campos de texto libre. Un campo de descripción de 500 caracteres en 5 millones de eventos añade 2,5 GB al archivo.
• PII (información de identificación personal). Nombres, direcciones de correo electrónico y números de teléfono. Eliminar la PII reduce el tamaño del archivo, elimina riesgos de privacidad y simplifica el Cumplimiento.
• Identificadores redundantes. Si tiene OrderId, no necesita OrderGUID, OrderReference ni LegacyOrderNumber.
• Columnas de auditoría. CreatedBy, ModifiedBy, CreatedDate y ModifiedDate. A menos que las analice específicamente, déjelas fuera.
• Columnas del sistema. Indicadores internos, claves de partición y metadatos técnicos.

Ejemplo: una exportación de SAP con 1,8 millones de eventos de órdenes de compra y 45 columnas se redujo a 12 columnas esenciales:

• Tamaño del archivo: 2,1 GB → 380 MB (reducción del 82 %)
• Como Parquet: 380 MB → 58 MB (otra reducción del 85 %)
• Tiempo de carga (100 Mbps): 3,5 min → 6 segundos
• El mismo valor analítico

Las columnas importantes: CaseId, Activity, Timestamp y algunos atributos empresariales, como estado, importe, categoría y región. Todo lo demás probablemente sea ruido.

Cuándo importa la escala

Algunas preguntas analíticas requieren realmente conjuntos de datos grandes. Comprender cuándo ocurre esto le ayuda a tomar la decisión adecuada:

• Detección de eventos poco frecuentes. Para encontrar casos extremos que ocurren 1 de cada 100.000 veces se necesita una población lo bastante grande como para contener muestras significativas. Si necesita analizar 50 casos de una excepción poco frecuente y esta ocurre el 0,01 % de las veces, necesita 500.000 casos.
• Medición de rutas de baja frecuencia. Las variantes del proceso que ocurren el 0,1 % de las veces pueden ser invisibles en una muestra de 1 millón de eventos, pero significativas en una población de 50 millones.
• Cumplimiento y auditoría. Algunas normativas exigen cubrir toda la población. No se acepta el muestreo.
• Análisis de tendencias de varios años. Comparar el primer trimestre de 2024 con el primer trimestre de 2025 y el primer trimestre de 2026 requiere datos de los tres periodos. Utilice la carga incremental para construir este histórico progresivamente.

Si necesita más de 50 millones de eventos, planifíquelo: utilice el formato Parquet, que reduce un CSV de 11 GB a 1,7 GB y acelera el preprocesamiento; utilice la API para realizar transferencias fiables; y use una conexión de red rápida si está disponible. Después de esa primera carga, los Dashboards siguen siendo rápidos.

Cómo mantener rápido el modelo y la interfaz

Las secciones anteriores tratan sobre el volumen de datos. La otra mitad de la capacidad de respuesta depende de cómo se construyen el modelo y los Dashboards:

• Simplifique el modelo. Divida los procesos grandes en subprocesos modulares; un lienzo con mil elementos visibles tarda en renderizarse y resulta imposible de leer. Ejecute auto-layout después de realizar cambios estructurales.
• Sea selectivo con los Dashboards. Cada gráfico y cada tarjeta deben calcularse. Conserve los gráficos que sirven para actuar y traslade el resto a su propio Dashboard, en lugar de acumularlo todo en una sola vista.
• Adapte el gráfico al conjunto de datos. En conjuntos de datos grandes, evite las visualizaciones que requieren más recursos, como los gráficos circulares detallados o los desgloses con muchas categorías, y prefiera gráficos que resuman la información.
• Aplique los filtros con moderación. Los filtros son económicos por separado y costosos en combinación. Conserve el conjunto que responde a su pregunta y elimínelo después.
• Vigile la animación. El coste de la animación aumenta con el número de casos activos. Reduzca la velocidad o desactive las colas y los efectos cuando solo necesite ver el flujo. Consulte Animación del proceso.
• Archive y vuelva a consultar. Traslade los conjuntos de datos y procesos antiguos fuera del espacio de trabajo activo y utilice la simulación con las métricas de tiempo para encontrar los cuellos de botella que merece la pena corregir, en lugar de optimizarlo todo a la vez.

Próximos pasos

La mejor forma de comprender el rendimiento del Process Mining es experimentarlo con sus propios datos.

1. Empiece con una muestra. Exporte 1 millón de eventos de un periodo reciente en formato Parquet. Cárguelos. Cree su primer modelo. Compruebe con qué rapidez puede iterar.

2. Aplique las técnicas de esta guía. Utilice formatos columnares. Filtre las excepciones. Segmente por región. Elimine las columnas innecesarias. Cada optimización se apoya en la anterior.

3. Escale de forma deliberada. Cuando comprenda su proceso con 1 millón de eventos, decida si necesita más. Normalmente, no. Cuando los necesite, utilice delta loading para añadir datos en lugar de volver a cargarlos.

Inicie la prueba gratuita y compruebe estos datos de referencia en acción. Si necesita ayuda para determinar el tamaño de su conjunto de datos u optimizar sus exportaciones, póngase en contacto con nosotros. Hemos ayudado a cientos de organizaciones a encontrar el equilibrio adecuado entre volumen de datos y velocidad de análisis.