Cómo saber si un proceso mejoró: indicadores y método

Un proceso mejoró si el mismo indicador, medido igual antes y después, se movió en la dirección que buscabas y se sostiene varias semanas sin que nadie esté empujando. Los cuatro que sirven en una pyme: tiempo de ciclo, errores o retrabajo, pasos manuales por caso y costo por transacción. Sin línea base no hay mejora: hay sensación.

Lo escribo desde el lado de quien instala el cambio. En Árkos la pregunta me llega casi siempre tarde: el sistema ya está andando, el equipo dice que «ahora es más rápido» y nadie puede demostrarlo, porque no se anotó cómo era antes. Esta guía es el método que uso para que eso no pase, y para distinguir una mejora real de una que solo se siente.

¿Qué significa que un proceso mejoró?

Significa tres cosas a la vez, y las tres tienen que cumplirse:

Un indicador declarado antes del cambio se movió. No «el que mejor quedó» al final: el que dijiste que ibas a mirar.
El resto no empeoró. Si el pedido sale 30% más rápido pero las devoluciones subieron, no mejoró el proceso: se trasladó el costo.
Se sostiene sin empujón. La semana del lanzamiento todo el mundo hace bien su trabajo porque está siendo mirado. La pregunta es qué pasa a las seis semanas, cuando ya nadie recuerda que hubo un cambio.

Lo que no cuenta como mejora: que la herramienta esté instalada, que el equipo diga en una reunión que le gusta, o que el proveedor muestre un tablero con gráficos. Eso es actividad, no resultado.

¿Qué indicadores miden la mejora de un proceso?

Cuatro, y casi siempre basta con dos. Los elijo por una razón práctica: se pueden sacar de registros que ya existen, sin montar nada nuevo.

Tiempo de ciclo

Cuánto pasa desde que el trabajo entra hasta que sale terminado. No el tiempo que alguien «le dedica», sino el reloj de pared: del pedido al despacho, de la orden abierta a la orden cerrada, de la consulta a la respuesta. Es el indicador que más le importa al cliente, porque es el único que él nota.

Mídelo con la mediana, no con el promedio. Un caso raro de tres semanas te mueve el promedio y te hace creer que todo va mal; la mediana te dice cómo es el caso típico. Y mira además el percentil 90: ahí viven los clientes que se quejan.

Errores y retrabajo

Cuántas veces hay que volver a hacer algo: una factura reemitida, un pedido corregido, una cita reagendada, un dato que alguien vuelve a escribir porque llegó mal. Es el indicador más fácil de ignorar y el que mejor explica por qué el equipo vive apagando incendios.

Cuéntalo como porcentaje de casos, no en números absolutos: si el volumen creció, 20 errores al mes pueden ser una mejora frente a 15.

Pasos manuales por caso

Cuántas intervenciones humanas necesita un caso para completarse. Se cuenta a mano, una vez, siguiendo tres o cuatro casos reales de principio a fin y anotando cada vez que una persona abre algo, copia algo, avisa a alguien o espera una respuesta. Es el indicador que predice mejor si automatizar va a servir, porque cada paso manual es un lugar donde el proceso puede pararse.

Costo por transacción

Las horas que consume un caso, multiplicadas por el costo hora de quien lo hace, más lo que cuestan los errores. Es la traducción a soles de los tres anteriores y la única cifra que sirve para decidir cuánto vale la pena invertir en arreglarlo.

Hay un quinto que no es indicador de proceso pero conviene tener al lado: el volumen. Casi todo lo demás se interpreta mal si no sabes si entró más o menos trabajo que antes.

¿Cómo tomo la línea base si nunca medí nada?

Es la situación normal, no la excepción. En el Perú, según la Encuesta Económica Anual 2024 publicada por el INEI, en 2023 solo el 9,6% de las empresas con ventas desde 50 UIT usaba un software ERP, el 4,8% un CRM y el 1,6% un SCM. Nueve de cada diez empresas no tienen un sistema que registre el proceso, así que la línea base no está esperando en una base de datos: hay que construirla.

Tres formas, de la mejor a la peor, y todas valen más que ninguna:

Reconstruirla de lo que ya existe. Los cuadernos, el Excel de caja, los correos, el historial de WhatsApp. Si la conversación con el cliente vive en WhatsApp, la hora del primer mensaje y la del «ya está listo» te dan un tiempo de ciclo real, caso por caso. Veinte casos del mes pasado alcanzan para una mediana defendible.
Medir dos semanas antes de tocar nada. Una hoja con cuatro columnas: caso, cuándo entró, cuándo salió, si hubo que repetir algo. Dos semanas es poco, pero es medición. Si el proceso tiene estacionalidad fuerte —fin de mes, campaña— mide el tramo equivalente al que vas a comparar después.
Preguntarle al equipo y anotarlo como estimación. La gente que hace el trabajo acierta el orden de magnitud y falla el número. Sirve para decidir dónde mirar, no para declarar una mejora. Si usas esto, escribe en el informe que es una estimación, no un dato.

Lo que no sirve: inventar el antes después del cambio. Si el número del «antes» se calculó cuando ya conocías el «después», no estás midiendo, estás justificando.

¿Cuánto tiempo hay que esperar para decir que mejoró?

Cuatro a seis semanas de operación normal, y la palabra importante es normal: sin el proveedor encima, sin la gerencia preguntando todos los días, con el volumen habitual y con las personas que de verdad van a hacer el trabajo.

Las dos primeras semanas después de un cambio no se parecen a nada. Hay curva de aprendizaje —el proceso puede verse peor que antes, y es esperable— y hay efecto de estar observado. Si tomas la decisión con esos datos, vas a cancelar cosas que funcionaban o a celebrar cosas que no.

Una regla que uso: la mejora se declara cuando el indicador se mantiene mejor que la línea base durante tres periodos consecutivos de los que uses para gestionar. Si cierras caja cada semana, tres semanas. Si miras el mes, tres meses.

¿Cómo sé que mejoró el proceso y no otra cosa?

Esta es la parte que casi nadie hace, y es la que separa un número de una prueba. Antes de atribuir la mejora al cambio, descarta tres explicaciones alternativas:

El volumen. Si entró 30% menos trabajo, todo se ve más rápido. Mira los indicadores por caso, no los totales.
La estacionalidad. Compara con el mismo periodo del año anterior, no con el mes pasado. Un restaurante en enero no se compara con diciembre.
La gente. Si además contrataste a dos personas o se fue la que cometía la mitad de los errores, el cambio de proceso no es la única variable. No lo ignores: escríbelo.

La forma más honesta de hacerlo es dejar algo sin cambiar y comparar contra eso: una sucursal, un turno, una línea de producto. Si el local que recibió el sistema mejoró 40% y el que no recibió nada mejoró 35%, lo que mejoró fue el negocio, no el sistema.

Lo aplico también a mi propio trabajo técnico. En Precio Vivo, un producto que publicamos abierto, probé modelos de pronóstico esperando que ganara el gradient boosting; midiéndolos contra una línea base, el mejor resultó ser un AR(1) lineal, con 26% menos error que el baseline. Sin esa comparación habría publicado el modelo que me gustaba y lo habría llamado mejora.

¿Qué errores invalidan la comparación?

Cuatro, en orden de frecuencia:

Cambiar la definición del indicador a mitad del camino. Es el más común y el más silencioso. Si el «tiempo de atención» antes se contaba desde que el cliente escribía y después se cuenta desde que el ticket se asigna, el antes y el después ya no comparan lo mismo. No es un error de aficionados: el propio INEI advierte en su ficha técnica que en 2023 desvinculó el ERP del indicador general de «empresas que contaron con sistema de gestión» para medirlo aparte, y deja escrito que ese ajuste metodológico «podría afectar la comparabilidad histórica del indicador general». Si una oficina nacional de estadística lo declara, tu empresa también puede.

Medir solo a los que llegaron al final. Si cuentas el tiempo de ciclo únicamente de los pedidos que se completaron, los que se cayeron a mitad —los peores— desaparecen de la cuenta y el número mejora solo. Cuenta los abandonos como casos, con su propio indicador.

Cambiar el denominador sin decirlo. «Errores por mes» con el doble de volumen no es comparable. «Costo por orden» cuando además subió el precio del servicio, tampoco.

Confundir el indicador con el objetivo. Si al equipo se le mide por «órdenes cerradas», va a cerrar órdenes: también las que debían seguir abiertas. Cada vez que declares un indicador, pregúntate cómo lo haría subir alguien que quisiera hacer trampa, y mide también eso.

¿Cómo se ve una mejora medida de verdad?

Así quedan escritas las nuestras, con el antes, el después y la unidad:

En el piloto de RestHUB, nuestro ERP para restaurantes, el tiempo de toma de pedidos bajó casi 60% y el cierre de caja pasó de 45 a 5 minutos. El cierre de caja es el ejemplo perfecto de un indicador bien hecho: lo cronometra cualquiera, no admite interpretación y le importa a quien lo sufre todas las noches.
En el servicio técnico que opera una clienta a diario —el sistema que empezó con la web de Solutec DHA—, con 650 órdenes al mes y 15 usuarios, el cierre de orden es 45% más rápido.
En la plataforma de gestión de citas de una clínica que atiende emergencias 24 horas, el 78% de las citas se gestiona digitalmente. Ese es un indicador de adopción, no de velocidad: mide cuánta operación pasó de verdad al sistema, que es lo primero que hay que comprobar antes de mirar cualquier otra cosa.

Fíjate en lo que tienen en común: unidad explícita, periodo acotado y un número que alguien puede ir a verificar. «Mucho más eficiente» no es una mejora medida; es una opinión.

¿Qué señales dicen que la mejora solo movió el problema de sitio?

Cinco, y las busco siempre antes de firmar un resultado:

Alguien mantiene el Excel en paralelo. Si el equipo sigue llevando su hoja «por si acaso», el proceso no se reemplazó: se duplicó.
El trabajo apareció en otro equipo. Ventas cierra más rápido porque ahora administración corrige los datos.
Creció una cola invisible. Los casos no se demoran: se acumulan en un estado intermedio que nadie mira.
Las excepciones se volvieron la norma. El proceso nuevo funciona para el caso estándar y el 40% del volumen entra «por fuera» con un permiso especial.
El indicador mejoró y el cliente no lo nota. Si nada de lo que mides se parece a lo que el cliente experimenta, estás midiendo tu comodidad.

¿Qué hago con el resultado?

Si el proceso mejoró, escríbelo en una línea con su unidad y su periodo, y guárdalo: ese es el «antes» de tu próximo cambio. Si no mejoró, también escríbelo. Una mejora que no ocurrió y se documenta cuesta una vez; una que se celebra sin datos se repite durante años.

En Árkos esto es la mitad del trabajo. Hacemos mejora de procesos y adopción de IA para empresas en Perú, y en cada proyecto la línea base se toma antes de escribir código, porque es lo único que después permite decir si el sistema sirvió. El diagnóstico de procesos es exactamente ese trabajo —dos semanas, S/ 950, con garantía de devolución si no encuentra pérdidas de al menos tres veces su precio al año— y los rangos de lo que cuesta construir después están publicados en precios.

Si quieres empezar sin contratar nada, elige un solo proceso, mide dos semanas y no cambies nada mientras mides. Esas dos semanas son el activo más barato que vas a tener en todo el proyecto.

Preguntas frecuentes

¿Qué indicadores miden la mejora de un proceso?

Cuatro cubren casi cualquier proceso de una pyme: tiempo de ciclo (del inicio al final, medido con la mediana y el percentil 90), porcentaje de casos con error o retrabajo, pasos manuales por caso y costo por transacción en soles. Al lado de ellos hay que llevar el volumen, porque sin saber si entró más o menos trabajo los otros cuatro se interpretan mal.

¿Cómo mido un proceso si nunca medí nada antes?

Reconstruyendo la línea base de lo que ya existe —WhatsApp, correos, el Excel de caja, los cuadernos—, que suele alcanzar para veinte casos del mes pasado, o midiendo dos semanas con una hoja de cuatro columnas antes de tocar el proceso. Preguntarle al equipo sirve para orientarse, pero se anota como estimación, no como dato.

¿Cuánto tiempo tarda en verse la mejora de un proceso?

De cuatro a seis semanas de operación normal. Las dos primeras no sirven: hay curva de aprendizaje, el proceso puede verse peor que antes y el equipo está siendo observado. La mejora se declara cuando el indicador se mantiene mejor que la línea base durante tres periodos consecutivos de los que uses para gestionar.

¿Cómo sé que la mejora vino del cambio y no de otra cosa?

Descartando tres explicaciones alternativas antes de atribuirla: que entró menos volumen, que el periodo es estacionalmente mejor y que cambió la gente. Lo más honesto es dejar algo sin cambiar —una sucursal, un turno, una línea— y comparar contra eso; si lo que no se tocó mejoró casi igual, lo que mejoró fue el negocio, no el cambio.

¿Es mejor usar el promedio o la mediana para medir un proceso?

La mediana para describir el caso típico, porque un caso extremo mueve el promedio y distorsiona la lectura, y el percentil 90 para ver lo que viven los clientes que se quejan. El promedio solo conviene cuando necesitas sumar o multiplicar por costos, como en el costo por transacción.

¿Qué hago si el proceso no mejoró?

Escribirlo con el mismo detalle que si hubiera mejorado y revisar primero la medición: indicador redefinido a mitad de camino, casos abandonados que quedaron fuera de la cuenta o denominador cambiado. Si la medición está sana y el número no se movió, el cambio no sirvió para eso, y saberlo a las seis semanas es mucho más barato que sospecharlo a los dos años.

Fuentes

Instituto Nacional de Estadística e Informática, Perú: Tecnologías de Información y Comunicación en las Empresas, 2023 (Encuesta Económica Anual 2024). Gráfico 2.44, tipos de software de gestión que utilizaron las empresas: ERP 9,6%, CRM 4,8% y SCM 1,6% de las empresas con ventas netas iguales o superiores a 50 UIT; y la ficha técnica del indicador de ERP, que advierte que el ajuste metodológico de 2023 «podría afectar la comparabilidad histórica del indicador general» del que formaba parte. Consultado el 28 de octubre de 2026.
Árkos, caso Precio Vivo: evaluación de modelos de pronóstico contra línea base, con el AR(1) lineal 26% por debajo del error del baseline. Datos y evaluación públicos en el repositorio del proyecto.
Árkos, caso RestHUB: piloto en un restaurante de Trujillo, tiempo de toma de pedidos y cierre de caja antes y después.