Cómo medir el rendimiento de una automatización

Introducción

Una automatización puede estar activa, ejecutar tareas todos los días y no mostrar errores evidentes, pero eso no significa necesariamente que esté rindiendo bien. Puede tardar cada vez más, necesitar más reintentos, dejar demasiados casos en revisión manual, acumular retrasos en horas punta o procesar correctamente el 95 % de los casos mientras el 5 % restante consume casi todo el esfuerzo de supervisión.

Medir el rendimiento de una automatización consiste en observar de forma sistemática cómo se comporta durante el trabajo real. El objetivo no es únicamente saber si “funciona” o “falla”, sino comprender con qué velocidad procesa, cuántos casos completa correctamente, qué carga soporta, qué errores se repiten, cuántas excepciones necesita, cuánto trabajo manual residual genera y si su comportamiento empeora con el tiempo.

Este análisis es diferente de calcular el retorno económico. Una automatización puede tener un rendimiento técnico excelente y no ser rentable si apenas se utiliza. También puede ser económicamente interesante y, sin embargo, presentar una tasa de errores o una dependencia de intervención manual que aconseje mejorar su diseño. El rendimiento operativo describe cómo funciona el sistema; el retorno analiza qué valor económico produce frente a su coste.

En una pequeña empresa no es necesario implantar una plataforma compleja de observabilidad para empezar a medir. En muchos casos bastan registros de ejecución, tiempos de inicio y finalización, estados, errores, reintentos y una revisión periódica de algunas métricas bien elegidas.

Este artículo desarrolla un método práctico para medir el rendimiento de una automatización, establecer una línea base, seleccionar indicadores útiles, interpretar tendencias, definir umbrales y detectar cuándo una degradación puntual se está convirtiendo en un problema estructural.

Índice

• Qué significa medir el rendimiento de una automatización
• Diferencia entre rendimiento, eficiencia y ROI
• Definir correctamente la unidad de medida
• Crear una línea base antes de comparar
• Tasa de ejecuciones correctas
• Tasa de errores y fallos
• Tiempo de ejecución
• Tiempo de ciclo completo
• Volumen procesado y capacidad
• Cola, retraso y trabajo pendiente
• Tasa de excepciones
• Reintentos y recuperaciones
• Intervención humana residual
• Calidad del resultado
• Calidad de datos de entrada y salida
• Disponibilidad y continuidad
• Rendimiento de dependencias externas
• Por qué no basta con mirar la media
• Segmentar métricas para encontrar problemas ocultos
• Definir objetivos y umbrales
• Crear alertas útiles sin generar ruido
• Analizar tendencias y detectar degradación
• Comparar rendimiento entre versiones
• Construir un cuadro de mando mínimo
• Método práctico de medición
• Ejemplo completo
• Errores frecuentes al medir
• Checklist de rendimiento
• Conclusión
• Preguntas frecuentes

Qué significa medir el rendimiento de una automatización

El rendimiento describe la capacidad de una automatización para producir el resultado esperado de forma correcta, suficientemente rápida, estable y sostenible bajo la carga real de trabajo.

Por tanto, no existe una única cifra que resuma todo el rendimiento. Conviene observar varias dimensiones:

• correctitud: cuántas ejecuciones terminan bien;
• velocidad: cuánto tarda cada caso;
• capacidad: cuánto volumen puede procesar;
• estabilidad: si el comportamiento se mantiene en el tiempo;
• resiliencia: cómo responde ante fallos temporales;
• calidad: si la salida cumple los criterios esperados;
• autonomía: cuánta intervención humana sigue necesitando.

El rendimiento debe relacionarse con el propósito

Una automatización que genera un informe nocturno puede tardar quince minutos sin causar ningún problema. La misma latencia sería inaceptable en un flujo que debe confirmar una solicitud en pocos segundos.

Las métricas solo tienen sentido cuando se interpretan en función del proceso.

Medir permite pasar de impresiones a evidencia

Sin datos, las frases habituales son “parece que va más lento”, “últimamente falla bastante” o “creo que tenemos demasiados casos manuales”. Con medición pueden convertirse en afirmaciones verificables.

Por ejemplo: “el tiempo mediano sigue estable, pero el 10 % de ejecuciones más lentas ha pasado de 40 segundos a 3 minutos durante las últimas cuatro semanas”. Esa información permite investigar con mucha más precisión.

Diferencia entre rendimiento, eficiencia y ROI

Estos conceptos están relacionados, pero conviene separarlos para evitar canibalizar análisis distintos.

Rendimiento operativo

Pregunta si la automatización ejecuta correctamente y con suficiente velocidad, capacidad y estabilidad.

Eficiencia

Relaciona resultados con recursos utilizados. Puede observar operaciones consumidas, tiempo de proceso, llamadas a APIs o intervención humana necesaria.

ROI

Relaciona el valor económico producido con los costes de construir y mantener la automatización.

Una automatización puede procesar 1.000 casos al día con una tasa de éxito del 99,8 % y aun así no justificar económicamente su coste. Esa sería una automatización con buen rendimiento técnico pero posible retorno insuficiente.

Para el análisis económico completo conviene utilizar cómo calcular el retorno de una automatización. En este artículo las horas, errores y mantenimiento se utilizan como señales operativas, no para convertirlos en euros.

Definir correctamente la unidad de medida

Antes de calcular indicadores hay que definir qué representa una ejecución.

Puede ser:

• procesar una solicitud;
• clasificar un correo;
• crear un documento;
• sincronizar un registro;
• generar un informe;
• actualizar un estado;
• realizar una copia de seguridad.

Evitar mezclar unidades diferentes

Si unas ejecuciones procesan un registro y otras procesan lotes de mil registros, comparar tiempos medios sin distinguirlas puede ser engañoso.

Definir inicio y fin

El tiempo solo puede medirse bien si está claro cuándo empieza y cuándo termina el trabajo.

Por ejemplo:

• inicio: formulario recibido;
• fin: registro creado, correo enviado y tarea generada.

Distinguir ejecución técnica y caso de negocio

Un único caso puede generar varias ejecuciones técnicas. Conviene decidir si se mide cada llamada interna o el resultado final de principio a fin. En muchos procesos resulta útil disponer de ambas perspectivas.

Crear una línea base antes de comparar

Una métrica aislada dice poco. Para saber si algo mejora o empeora hace falta una referencia.

Medir un periodo representativo

Puede utilizarse una semana, un mes o un número suficiente de ejecuciones según la frecuencia del proceso.

Registrar condiciones

La línea base debe indicar:

• versión activa;
• volumen;
• horarios;
• dependencias principales;
• configuración relevante.

No elegir únicamente días tranquilos

La referencia debe incluir picos, errores y variabilidad reales.

Crear una línea base después de cambios grandes

Si una automatización se rediseña o cambia de plataforma, conviene establecer una nueva referencia y conservar la anterior para comparación histórica.

Tasa de ejecuciones correctas

La tasa de éxito es uno de los indicadores más básicos.

Puede expresarse como:

ejecuciones correctas / ejecuciones totales × 100

Si se procesan 2.000 casos y 1.970 terminan correctamente:

1.970 / 2.000 × 100 = 98,5 %

Definir qué significa “correcta”

Una ejecución técnicamente completada no siempre equivale a un resultado válido. Si el flujo crea un documento vacío y termina sin error técnico, el sistema puede marcar éxito aunque el proceso haya fallado desde el punto de vista operativo.

Distinguir éxito completo y parcial

Puede existir:

• éxito completo;
• éxito con advertencia;
• resultado parcial;
• fallo recuperable;
• fallo definitivo.

Esta clasificación aporta más información que un simple binario éxito/error.

Tasa de errores y fallos

La tasa de error complementa la tasa de éxito, pero conviene clasificar los errores por causa.

Errores de datos

Campos vacíos, formatos incorrectos, duplicados o valores inesperados.

Errores de integración

API no disponible, timeout, límite de peticiones o respuesta inválida.

Errores de permisos

Credenciales caducadas o acceso insuficiente.

Errores de lógica

Condiciones mal definidas o rutas incorrectas.

Errores de infraestructura

Falta de espacio, proceso detenido, caída de servidor o problemas de red.

La tasa global puede permanecer estable mientras cambia la distribución de causas. Por eso conviene conservar un código o categoría de error.

Una automatización que falla un 1 % puede ser aceptable o desastrosa dependiendo de qué casos fallen y de su impacto.

Tiempo de ejecución

El tiempo de ejecución mide cuánto tarda la automatización en completar su trabajo técnico.

Registrar inicio y fin

La diferencia permite obtener duración por ejecución.

Observar distribución

No conviene limitarse al promedio. Puede existir una mayoría de casos rápidos y unos pocos extremadamente lentos.

Comparar por tipo de caso

Una solicitud con archivo adjunto puede tardar mucho más que otra sin archivo. Mezclar ambas puede ocultar el comportamiento normal.

Identificar pasos lentos

Si el sistema permite medir cada etapa, puede localizarse dónde se consume tiempo:

• lectura de datos;
• consulta externa;
• transformación;
• generación documental;
• escritura;
• notificación.

Tiempo de ciclo completo

El tiempo de ejecución técnica no siempre representa el tiempo que percibe el usuario.

Un flujo puede tardar veinte segundos en ejecutarse, pero permanecer tres horas esperando en una cola antes de comenzar.

El tiempo de ciclo mide desde que aparece la necesidad hasta que el resultado final está disponible.

Incluye esperas

• cola;
• programación por lotes;
• espera de revisión;
• espera de sistema externo;
• reintentos.

Es una métrica muy útil para procesos operativos

Si el objetivo es responder más rápido, reducir únicamente el tiempo interno de ejecución puede no mejorar la experiencia real.

Volumen procesado y capacidad

El rendimiento debe observarse también frente al volumen.

Volumen por periodo

Casos por hora, día o mes.

Capacidad máxima observada

Cuántos casos ha procesado el sistema sin degradación relevante.

Relación entre carga y tiempo

Si duplicar el volumen multiplica por cuatro los tiempos, existe una señal de cuello de botella.

Capacidad disponible

Una automatización que normalmente funciona al 95 % de su límite tiene poco margen para picos.

En procesos que deben crecer, este indicador ayuda a saber si el sistema puede absorber nuevas cargas antes de que aparezcan retrasos.

Cola, retraso y trabajo pendiente

Una automatización puede mantener una tasa de éxito alta y, sin embargo, acumular trabajo pendiente.

Tamaño de cola

Número de casos esperando procesamiento.

Edad del caso más antiguo

Cuánto tiempo lleva esperando el elemento más retrasado.

Velocidad de entrada y salida

Si entran 120 casos por hora y el sistema solo procesa 100, la cola crecerá aunque individualmente no falle ninguna ejecución.

Tiempo hasta recuperar normalidad

Después de un pico conviene observar cuánto tarda la automatización en ponerse al día.

La cola es especialmente importante en automatizaciones por lotes o con dependencias externas limitadas.

Tasa de excepciones

Una excepción es un caso que no puede seguir el camino normal y necesita una ruta especial.

Puede calcularse:

casos excepcionales / casos totales × 100

Las excepciones no siempre son errores

Un proceso puede funcionar correctamente al identificar un caso especial y enviarlo a revisión humana.

Una tasa creciente puede indicar cambio del proceso

Si las excepciones pasan del 3 % al 25 %, quizá el flujo ya no representa adecuadamente la realidad.

Cuando este fenómeno se vuelve estructural puede ser necesario revisar cómo detectar cuándo una automatización debe rediseñarse.

Medir también el coste operativo de la excepción

No necesariamente en euros, sino en minutos humanos, pasos adicionales y retraso producido.

Reintentos y recuperaciones

Los reintentos permiten superar fallos temporales. Sin embargo, una automatización que necesita demasiados reintentos puede estar ocultando problemas.

Reintentos por ejecución

Cuántas veces debe repetirse una operación para completarse.

Porcentaje de ejecuciones recuperadas

Casos que fallaron inicialmente pero terminaron correctamente.

Fallo definitivo después de reintentos

Casos que agotaron los intentos.

Tiempo añadido por recuperación

Un flujo puede tener alta tasa final de éxito, pero conseguirla después de largos retrasos.

Una subida de reintentos puede anticipar una degradación de una API o una dependencia antes de que aumenten los fallos definitivos.

Intervención humana residual

Muchas automatizaciones están diseñadas deliberadamente para conservar revisión humana. Eso no representa mal rendimiento.

Conviene separar:

• revisión planificada;
• decisión que requiere criterio;
• corrección de errores;
• completado manual de datos;
• reactivación de ejecuciones;
• comprobación de resultados.

Medir casos que requieren intervención no prevista

Si una persona debe reparar continuamente registros o reiniciar flujos, existe una pérdida de autonomía.

Medir tiempo humano residual

Aunque no se convierta en dinero, permite observar si la automatización realmente reduce trabajo mecánico.

Calidad del resultado

Un sistema puede ser rápido y estable pero producir salidas deficientes.

La calidad debe definirse según el proceso.

Ejemplos:

• documento generado con todos los campos;
• clasificación correcta;
• registro sin duplicados;
• archivo ubicado en la carpeta adecuada;
• mensaje enviado al destinatario correcto;
• datos sincronizados sin pérdidas.

Crear una tasa de resultado válido

Puede revisarse una muestra o utilizar validaciones automáticas.

Distinguir fallo técnico y fallo de calidad

Esta separación es esencial para no sobreestimar la tasa de éxito.

Calidad de datos de entrada y salida

Muchas automatizaciones fallan por datos deficientes, no por la lógica del flujo.

Entradas incompletas

Porcentaje de casos con campos obligatorios ausentes.

Formatos inválidos

Fechas, teléfonos, identificadores o archivos incorrectos.

Duplicados

Registros repetidos antes o después del procesamiento.

Inconsistencias

Datos que no coinciden entre sistemas.

Conviene medir estas señales para no atribuir automáticamente a la automatización problemas que se originan antes de que empiece.

Disponibilidad y continuidad

Algunas automatizaciones necesitan estar disponibles prácticamente siempre; otras pueden ejecutarse una vez al día.

Disponibilidad

Porcentaje del periodo en el que el sistema puede ejecutar.

Incidencias

Número de interrupciones por periodo.

Duración de interrupciones

No es igual diez fallos de un minuto que una caída de diez horas.

Tiempo de recuperación

Cuánto tarda el sistema en volver a procesar después de una incidencia.

Pérdida de trabajo

Comprobar si los casos recibidos durante una caída quedan en cola o desaparecen.

Rendimiento de dependencias externas

Una automatización suele depender de correo, almacenamiento, APIs, bases de datos o aplicaciones externas.

Conviene distinguir:

• tiempo interno del flujo;
• tiempo esperando una dependencia;
• errores propios;
• errores externos.

Latencia externa

Si una API pasa de responder en 300 milisegundos a tardar 4 segundos, el flujo completo puede degradarse sin haber cambiado.

Límites de uso

Algunas plataformas reducen velocidad o rechazan operaciones cuando se superan determinados límites.

Disponibilidad del proveedor

Separar estas incidencias evita buscar errores en una lógica interna que funciona correctamente.

Por qué no basta con mirar la media

La media puede ocultar comportamientos extremos.

Supongamos diez ejecuciones:

• nueve tardan 10 segundos;
• una tarda 200 segundos.

La media es 29 segundos, una cifra que no representa bien ni la experiencia normal ni el caso problemático.

Mediana

Representa el valor central y describe mejor un caso típico cuando existen extremos.

Percentil 90

Indica el tiempo por debajo del cual termina aproximadamente el 90 % de ejecuciones.

Percentil 95 o 99

Permite observar la cola lenta.

En automatizaciones con suficiente volumen, estos indicadores ayudan a detectar degradaciones que la media disimula.

Segmentar métricas para encontrar problemas ocultos

Una métrica global puede parecer buena mientras un grupo concreto funciona mal.

Puede segmentarse por:

• tipo de solicitud;
• origen;
• cliente o categoría;
• tamaño de archivo;
• hora del día;
• día de la semana;
• versión;
• dependencia utilizada;
• resultado.

Ejemplo

La tasa global de éxito es 99 %, pero las solicitudes con adjuntos superiores a 10 MB solo alcanzan 82 %. Sin segmentación, el problema puede permanecer oculto.

La segmentación debe aplicarse con criterio. Crear cientos de combinaciones produce ruido y dificulta identificar lo importante.

Definir objetivos y umbrales

Medir sin saber qué nivel se considera aceptable limita la utilidad de los datos.

Puede definirse para cada automatización:

• tasa mínima de éxito;
• tiempo máximo de ciclo;
• porcentaje máximo de excepciones;
• cola máxima razonable;
• número máximo de reintentos;
• tiempo máximo de recuperación;
• porcentaje máximo de intervención manual correctiva.

Los umbrales deben derivar del proceso

No existe una tasa universal de éxito válida para todas las automatizaciones.

Utilizar varios niveles

Puede existir:

• normal;
• advertencia;
• crítico.

Así se evita tratar cualquier desviación pequeña como una emergencia.

Crear alertas útiles sin generar ruido

Una alerta debe señalar una situación que merece atención.

Alertas por fallo crítico

Una ejecución importante termina definitivamente con error.

Alertas por tendencia

La tasa de error supera un umbral durante un periodo.

Alertas por cola

El trabajo pendiente supera un límite.

Alertas por silencio

Una automatización que debería recibir casos deja de ejecutar por completo.

Evitar alertar por cada reintento recuperado

Si el sistema puede resolver automáticamente una incidencia menor, enviar una notificación por cada intento puede generar fatiga.

Las alertas deberían conducir a una acción clara.

Analizar tendencias y detectar degradación

Una automatización rara vez pasa de excelente a inutilizable de un día para otro. Muchas veces se degrada lentamente.

Señales:

• tiempos que suben semana a semana;
• más excepciones;
• más reintentos;
• cola creciente;
• más intervención manual;
• más errores de una dependencia concreta;
• reducción de capacidad en horas punta.

Comparar periodos equivalentes

No tiene sentido comparar un día de máxima carga con un domingo tranquilo sin contexto.

Buscar cambios coincidentes

Una degradación puede comenzar después de:

• una nueva versión;
• un cambio de API;
• un aumento de volumen;
• una nueva categoría de casos;
• una modificación del esquema de datos.

Si las métricas muestran que la propia estructura se ha vuelto inadecuada, puede llegar el momento de rediseñar.

Comparar rendimiento entre versiones

El control de versiones permite relacionar cambios y comportamiento.

Antes de desplegar una versión nueva conviene registrar métricas de la versión actual.

Después pueden compararse:

• tasa de éxito;
• tiempo mediano;
• percentiles altos;
• excepciones;
• reintentos;
• intervención manual;
• volumen procesado.

No asumir que una versión nueva es mejor

Puede añadir funciones y al mismo tiempo empeorar latencia o estabilidad.

Para gestionar la identidad, historial y rollback entre versiones puede consultarse cómo controlar versiones de procesos automatizados.

Construir un cuadro de mando mínimo

Una pequeña empresa puede comenzar con muy pocos indicadores.

Indicadores básicos recomendados

• ejecuciones totales;
• tasa de éxito;
• errores por causa;
• tiempo mediano de ejecución;
• percentil 95 si hay suficiente volumen;
• excepciones;
• reintentos;
• casos pendientes;
• intervenciones manuales correctivas.

Periodicidad

Puede revisarse diariamente en procesos críticos, semanalmente en flujos activos o mensualmente en automatizaciones estables de bajo riesgo.

Mostrar tendencia

Una serie temporal suele aportar más que una tabla con la cifra actual.

No llenar el cuadro de métricas decorativas

Cada indicador debería responder una pregunta operativa concreta.

Método práctico de medición

Paso 1: definir la unidad

Determinar qué representa un caso completo.

Paso 2: definir éxito y fallo

Establecer criterios operativos, no solo técnicos.

Paso 3: instrumentar registros

Guardar inicio, fin, estado, error y versión.

Paso 4: registrar excepciones y reintentos

No limitarse al resultado final.

Paso 5: medir intervención humana

Distinguir revisión prevista de reparación.

Paso 6: crear línea base

Utilizar un periodo representativo.

Paso 7: elegir pocas métricas

Priorizar las que describen correctitud, velocidad, capacidad y estabilidad.

Paso 8: definir umbrales

Establecer qué se considera normal, advertencia y crítico.

Paso 9: revisar tendencias

No reaccionar únicamente a una ejecución aislada.

Paso 10: segmentar cuando aparece una anomalía

Buscar qué tipo de caso concentra el problema.

Paso 11: relacionar cambios con versiones

Comprobar si la degradación coincide con una modificación.

Paso 12: decidir acción

Ajustar, corregir dependencia, ampliar capacidad, simplificar o rediseñar.

Ejemplo completo

Supongamos una automatización que recibe solicitudes, valida datos, crea un registro, genera una carpeta y envía confirmación.

Volumen

Durante un mes procesa 3.000 solicitudes.

Resultados

• 2.940 éxitos completos;
• 30 éxitos con advertencia;
• 20 fallos recuperados mediante reintento;
• 10 fallos definitivos.

La tasa de éxito final es:

2.990 / 3.000 × 100 = 99,67 %

Tiempo

• mediana: 18 segundos;
• percentil 90: 35 segundos;
• percentil 95: 58 segundos;
• percentil 99: 190 segundos.

La media podría parecer razonable, pero el percentil 99 muestra una cola lenta significativa.

Segmentación

Al separar por tipo de solicitud se descubre que casi todas las ejecuciones superiores a dos minutos incluyen archivos grandes.

Errores

• 12 errores de formato de archivo;
• 8 timeouts de almacenamiento;
• 10 fallos definitivos por credencial caducada durante una incidencia.

Reintentos

Un 2,5 % de las ejecuciones necesita al menos un reintento. El mes anterior era 0,8 %.

La tasa final de éxito sigue siendo alta, pero el incremento de reintentos indica degradación.

Intervención manual

45 casos necesitan corrección humana. De ellos:

• 30 corresponden a datos incompletos;
• 10 a archivos incompatibles;
• 5 a errores internos.

Conclusión operativa

La automatización funciona bien en términos generales, pero existen tres acciones claras:

1. mejorar validación de archivos antes de iniciar el flujo;
2. investigar el aumento de latencia del almacenamiento;
3. mejorar gestión de credenciales para evitar un fallo masivo equivalente.

El análisis no necesita convertir ninguna de estas señales en euros para resultar útil. Ya permite priorizar mejoras técnicas y operativas.

Errores frecuentes al medir

Medir solo si terminó o falló

Oculta latencia, reintentos, excepciones y degradación.

Utilizar únicamente la media

Puede esconder casos extremos.

No definir éxito operativo

Un flujo técnicamente completado puede producir un resultado inválido.

Mezclar tipos de caso

Las diferencias de complejidad pueden distorsionar métricas.

No separar errores internos y externos

Dificulta localizar la causa.

Ignorar intervención humana

Una automatización puede parecer autónoma porque el sistema no registra todas las correcciones manuales.

Medir demasiadas métricas

Genera paneles difíciles de interpretar.

No conservar contexto de versión

Impide relacionar cambios y degradación.

Confundir rendimiento con rentabilidad

Un sistema rápido y estable no necesariamente compensa económicamente.

Reaccionar a cada anomalía aislada

Conviene distinguir incidentes puntuales de tendencias persistentes.

Checklist de rendimiento

• ¿Está definida la unidad de trabajo?
• ¿Se sabe cuándo empieza y termina cada caso?
• ¿Está definido qué significa éxito?
• ¿Se distinguen éxito completo y parcial?
• ¿Se registra la causa de los errores?
• ¿Se mide tiempo de ejecución?
• ¿Se mide tiempo de ciclo cuando existen esperas?
• ¿Se conoce el volumen procesado?
• ¿Se controla el tamaño de la cola?
• ¿Se registran excepciones?
• ¿Se registran reintentos?
• ¿Se diferencia revisión humana prevista de corrección?
• ¿Se controla calidad del resultado?
• ¿Se separan problemas de datos y problemas del flujo?
• ¿Se observan dependencias externas?
• ¿Se utilizan mediana o percentiles cuando hay suficiente volumen?
• ¿Se segmentan los problemas por tipo de caso?
• ¿Existe una línea base?
• ¿Hay objetivos y umbrales?
• ¿Las alertas conducen a acciones concretas?
• ¿Se revisan tendencias?
• ¿Cada ejecución importante registra la versión?

Conclusión

Medir el rendimiento de una automatización permite saber si el sistema sigue cumpliendo su función bajo condiciones reales. La tasa de éxito es importante, pero por sí sola no basta. También hay que observar velocidad, cola, volumen, excepciones, reintentos, intervención humana, calidad de datos y comportamiento de dependencias externas.

Una automatización madura puede mostrar una tasa final de éxito elevada y, al mismo tiempo, estar degradándose porque necesita cada vez más reintentos o acumula una cola creciente. Detectar estas señales pronto permite intervenir antes de que el problema se convierta en una interrupción visible.

La medición tampoco debe transformarse en otro sistema pesado. Para una empresa pequeña suele ser suficiente elegir unas pocas métricas relacionadas con el propósito del proceso, conservar una línea base, establecer umbrales razonables y revisar tendencias.

Cuando aparecen problemas, la segmentación ayuda a descubrir si afectan a un tipo concreto de caso, a una dependencia, a una versión o a una franja de carga. Así la mejora deja de basarse en intuiciones y puede dirigirse a la causa real.

Una automatización bien medida no es la que produce más gráficos, sino la que permite detectar con claridad cuándo funciona bien, cuándo empieza a degradarse y qué aspecto merece atención.

Preguntas frecuentes