← Volver al blog Gestión de procesos

Mejora de procesos: método en 7 pasos con ejemplo [2026]

Mejorar un proceso es cambiar cómo se ejecuta para que entregue el mismo resultado con menos tiempo, menos errores o menos costo, y demostrarlo con una medición de antes y otra de después. Todo lo que no termina en esa comparación no fue una mejora: fue un taller. La diferencia entre las dos cosas es una sola disciplina, y es la que casi ningún proyecto respeta: medir el proceso antes de tocarlo.

Esta guía trae el método completo en siete pasos con el entregable de cada uno, las cinco métricas que hay que levantar antes de cambiar nada y cómo se levanta cada una, el criterio para decidir si un proceso se mejora, se rediseña o se elimina, una tabla que dice qué metodología usar según el síntoma, un ejemplo resuelto con números y los ocho errores que hacen que la mejora se pierda a los seis meses.

Qué es mejorar un proceso, y qué no

La mejora de procesos es el trabajo de identificar dónde un proceso pierde tiempo, dinero o calidad, cambiar la causa de esa pérdida y comprobar con datos que la pérdida bajó. Tiene tres partes obligatorias y ninguna es negociable: un problema expresado en una cifra, una causa verificada y una medición posterior.

Lo que se confunde con mejorar y no lo es:

Mejorar, rediseñar o eliminar: cómo se decide

Antes de aplicar cualquier método hay una decisión que lo condiciona todo y que se salta casi siempre: ¿este proceso hay que mejorarlo, rediseñarlo por completo o dejar de hacerlo? Son tres proyectos distintos, con costos y riesgos distintos.

Qué hacer	Cuándo es la respuesta	Qué se mueve	Riesgo
Mejorar (mejora incremental)	El diseño del proceso es razonable y el problema está en la ejecución: variabilidad, esperas, reprocesos.	Pasos, tiempos, reglas puntuales, capacitación. La secuencia general se conserva.	Bajo. Se puede revertir.
Rediseñar	El proceso cumple su objetivo pero por un camino que ya no tiene sentido: se diseñó para otra escala, otra tecnología u otra estructura.	La secuencia completa, los roles, los sistemas. Se parte del resultado esperado, no del flujo actual.	Alto: toca puestos y sistemas. Ver reingeniería de procesos.
Eliminar	El proceso existe por un incidente que ya no ocurre, por un reporte que nadie abre o por un control duplicado con otra área.	Nada: se deja de hacer, y se avisa a quien dependía de él.	El de no haber preguntado a quién le servía. Se mitiga preguntando.

La prueba rápida para saber en cuál estás: pregunta por el resultado del proceso, no por el proceso. «¿Qué tiene que pasar al final para que esto haya salido bien?» Si la respuesta describe algo que el flujo actual consigue de forma torcida, es rediseño. Si la respuesta describe lo mismo que el flujo hace pero mal ejecutado, es mejora. Si nadie sabe responder, es candidato a eliminar.

Lo que hay que medir antes de tocar nada

Sin línea base no hay mejora demostrable, y sin mejora demostrable no hay presupuesto para la siguiente. Cinco métricas cubren casi cualquier proceso administrativo o de servicio. Se levantan sobre casos reales, no sobre percepciones.

1. Tiempo de ciclo

Desde que el caso entra hasta que sale, en tiempo de calendario. Se saca de fechas que ya existen en algún sistema: fecha de alta contra fecha de cierre, de los últimos 100 casos. Se reporta con mediana y percentil 90, nunca solo con promedio: el promedio esconde justo los casos que enojan al cliente.

2. Tiempo tocado

Minutos de persona que realmente consume el caso, sumando a todos los que lo tocan. Se cronometra. La diferencia entre tiempo de ciclo y tiempo tocado es espera, y en la mayoría de los procesos administrativos la espera es la porción dominante. Ese dato solo cambia por dónde se busca la mejora: no hay que hacer a la gente más rápida, hay que quitar las colas.

3. Porcentaje de trabajo correcto a la primera

De cada 100 casos, cuántos pasaron sin que nadie los devolviera, corrigiera o pidiera información faltante. Se cuenta revisando casos, no preguntando. Es el indicador que más rápido revela dónde está el problema, porque se puede calcular por paso: el paso que devuelve más casos es el paso a atacar.

4. Trabajo en curso

Cuántos casos están abiertos a la vez. Un número alto de casos abiertos alarga el tiempo de ciclo de todos: es aritmética de colas, no una opinión de gestión. Limitar cuántos casos se pueden tener abiertos a la vez suele bajar el tiempo de ciclo sin cambiar nada más del proceso.

5. Puntos de transferencia

Cuántas veces el caso cambia de manos o de sistema. Cada transferencia es una cola potencial y un punto de pérdida de información. Contarlos sobre el diagrama del proceso toma diez minutos y suele ser la cifra más reveladora del levantamiento.

El método en 7 pasos

Paso 1 — Acotar el proceso y su problema en una frase con número

«Mejorar facturación» no es un alcance. «Bajar de 9 a 3 días el tiempo de ciclo del percentil 90 de la facturación de proyectos, antes del cierre del trimestre» sí lo es: tiene proceso, métrica, línea base, meta y fecha. Entregable: una hoja de encuadre de una página, firmada por el dueño del proceso.

Paso 2 — Levantar el proceso real

Se recorre con quien lo ejecuta, paso a paso, en su puesto de trabajo. No en una sala. El objetivo es el flujo tal como ocurre, con sus atajos y sus excepciones, no el que aparece en el manual. Entregable: el diagrama del proceso actual con tiempos, volúmenes y puntos de transferencia anotados sobre cada paso.

Paso 3 — Medir la línea base

Las cinco métricas de la sección anterior, sobre datos reales. Si el proceso no deja rastro en ningún sistema, se instrumenta durante dos o tres semanas antes de seguir. Entregable: tabla de línea base con la fecha de corte y la fuente de cada cifra.

Paso 4 — Encontrar la causa, no el culpable

Se ordenan los modos de falla por frecuencia, se toma el primero y se busca su causa hasta llegar a algo que se pueda cambiar: una regla, un formato, un plazo, un permiso, un dato que falta en el origen. Entregable: causa raíz escrita con la evidencia que la sostiene.

Paso 5 — Diseñar el proceso mejorado y priorizar

Se proponen cambios contra la causa —no contra el síntoma— y se ordenan por impacto contra esfuerzo. Lo que entra en la primera ola es lo de impacto alto y esfuerzo bajo, sin excepción: hay que producir un resultado visible antes de que el proyecto pierda patrocinio. Entregable: flujo mejorado y lista priorizada de cambios con dueño y fecha.

Paso 6 — Probar en pequeño antes de desplegar

Se aplica el cambio a un subconjunto acotado —un tipo de caso, un equipo, una semana— y se compara contra la línea base. Un cambio que se despliega a toda la operación sin piloto no se puede revertir sin costo político, y eso hace que se sostenga aunque no funcione. Entregable: resultado del piloto con la misma tabla de métricas.

Paso 7 — Estandarizar y entregar el proceso a su dueño

El proceso nuevo se documenta, se capacita, se le fija un indicador con frecuencia de revisión y se entrega formalmente al dueño del proceso. Sin este paso, la mejora dura lo que dure la atención del equipo de proyecto. Entregable: procedimiento actualizado —ver manual de procedimientos— e indicador en el tablero del área.

Qué metodología elegir según el síntoma

Las metodologías de mejora no compiten entre sí: resuelven problemas distintos. Elegir por moda —o porque alguien del equipo tiene una certificación— es la causa habitual de un proyecto que aplica un método pesado a un problema que se resolvía en dos semanas.

Síntoma	Método adecuado	Por qué	Cuándo NO usarlo
El caso tarda mucho aunque el trabajo sea poco: hay colas y esperas.	Lean	Ataca el desperdicio y el flujo: esperas, transportes, inventario de casos, reprocesos, sobreproducción.	Cuando el problema es variabilidad del resultado, no tiempo.
El resultado varía sin motivo aparente entre casos iguales.	Six Sigma (ciclo DMAIC)	Es un método estadístico para reducir la variación. Necesita datos suficientes para ser útil.	Con pocos datos o con un proceso que se ejecuta cinco veces al mes: el aparato estadístico no aporta.
Hay un defecto concreto, recurrente y con un reclamo detrás.	8D (ocho disciplinas)	Es un método de respuesta a problema: contención inmediata, causa raíz, acción permanente y verificación. Muy usado en cadena automotriz.	Para mejora general sin un defecto identificado: se convierte en papeleo.
Todo el flujo se detiene siempre en el mismo punto.	Teoría de restricciones	Identifica la restricción, la explota, subordina lo demás a ella y la eleva. Mejorar fuera de la restricción no cambia la salida del sistema.	Cuando no hay un cuello de botella estable, sino variabilidad repartida.
Muchos problemas pequeños, conocidos por quien opera, sin resolver.	Kaizen / mejora continua	Ciclos cortos, participación de quien ejecuta, cambios de bajo riesgo. Es lo que sostiene el resto.	Para un problema grande y estructural: no alcanza.
El proceso completo ya no tiene sentido tal como está.	Rediseño	Se parte del resultado esperado y se vuelve a trazar el camino, no se optimiza el existente.	Si el diseño es sano: se está pagando un proyecto grande por un problema chico.

Lo que ninguna metodología resuelve: un proceso cuyo problema es que dos áreas no se han puesto de acuerdo sobre quién decide. Eso no es un problema de método, es un problema de autoridad, y se arregla con una decisión, no con un taller.

Análisis de causa: las tres herramientas y cómo se usan mal

Los cinco porqués

Preguntar «por qué» encadenadamente hasta llegar a una causa accionable. El error típico: pararse en el segundo porqué, que casi siempre apunta a una persona. «Se equivocó al capturar» no es una causa raíz; «el formulario permite capturar una fecha inválida y no hay validación» sí lo es, porque se puede cambiar. La prueba: una causa raíz auténtica se enuncia como algo que se puede modificar sin cambiar de persona.

Diagrama de causa-efecto

Organiza las causas posibles por categorías —método, máquina, material, medición, mano de obra, medio ambiente— para no quedarse con la primera que se ocurre. El error típico: confundirlo con un resultado. El diagrama es un inventario de hipótesis; hay que ir a verificar cuál de esas ramas es la que explica los datos.

Pareto

Ordena los modos de falla por frecuencia o por costo para atacar los pocos que explican la mayoría. El error típico: hacerlo por frecuencia cuando el impacto no es uniforme. Cien errores de un peso importan menos que dos de cien mil; el Pareto se hace por la dimensión que duele, y a veces hay que hacer los dos y comparar.

Ejemplo resuelto: proceso de facturación

Los números siguientes son un ejercicio de cálculo para mostrar cómo se encadenan medición, causa y resultado. No son un resultado medido en un cliente: sustituye las cifras por las tuyas y la mecánica es la misma.

Paso 5 · Cambios priorizados. Tres, todos de esfuerzo bajo: (1) el número de orden de compra pasa a ser un campo obligatorio en el cierre de proyecto, no en la facturación; (2) el concepto facturable se copia del contrato al abrir el proyecto, de modo que ya está resuelto antes de facturar; (3) la firma de revisión deja de ser semanal en bloque y se hace por umbral de monto, con autorización previa por debajo del umbral. Fuera de la primera ola queda el cambio de los datos fiscales, que exige tocar el alta de clientes.

El detalle que hace útil el ejemplo es el tercero: el tiempo tocado casi no se movió. Un proyecto que hubiera empezado por «hay que ser más eficientes» habría presionado justo donde no estaba el problema. Lo que cambió el resultado fue mover un dato al punto donde se conoce y quitar una cola.

8 errores que hacen fracasar una mejora

1. Empezar sin línea base. Sin la medición previa no se puede demostrar nada, y un resultado que no se puede demostrar se atribuye a la suerte o al esfuerzo de alguien. Es el error que invalida el proyecto entero, y es el más común.
2. Atacar el síntoma. Poner un control de revisión adicional sobre un paso que falla no arregla el paso: le agrega trabajo. Cada control que se añade es trabajo permanente que alguien va a tener que hacer para siempre.
3. Confundir promedio con realidad. Reportar solo el promedio del tiempo de ciclo esconde la cola larga, que es exactamente donde están los clientes molestos. Mediana y percentil 90, siempre.
4. Mejorar fuera de la restricción. Optimizar un paso que no es el cuello de botella no cambia la salida del sistema: solo acumula más trabajo en curso delante del cuello. Es esfuerzo que se siente productivo y no mueve el resultado.
5. Diseñar la mejora sin quien ejecuta el proceso. Quien lo opera conoce las excepciones que ningún levantamiento captura. Además, un cambio diseñado sin ellos se recibe como una imposición y se sortea.
6. Desplegar sin piloto. Un cambio aplicado a toda la operación de golpe no se puede revertir sin costo político, así que se sostiene aunque los datos digan lo contrario.
7. No estandarizar. La mejora que no queda escrita, capacitada y con indicador vuelve al estado anterior en cuanto cambia una persona. Es la causa de que el mismo proceso se «mejore» tres veces en cinco años.
8. Cerrar el proyecto sin entregar el proceso a un dueño. Sin dueño no hay quien mire el indicador, y un indicador que nadie mira deja de significar algo en dos trimestres.

Cómo se sostiene la mejora

Una mejora se sostiene con tres cosas, y ninguna cuesta dinero:

• Un estándar escrito y accesible. El proceso nuevo documentado donde la gente lo usa, no en una carpeta compartida que nadie abre. Si el procedimiento no se puede encontrar en treinta segundos, no existe.
• Un indicador con dueño y frecuencia. Uno, no ocho. Con nombre de responsable, fuente de datos definida y una fecha fija de revisión. Ver indicadores de productividad para elegirlo bien.
• Una revisión donde alguien pregunte por él. El mecanismo que mantiene vivo cualquier indicador es que en una reunión recurrente alguien con autoridad pregunte por el número y por qué se movió.

En una organización con sistema de gestión de calidad, esas tres piezas ya existen: información documentada, seguimiento y medición, y revisión por la dirección. La mejora de procesos no es un proyecto aparte del sistema; es lo que el sistema hace cuando está vivo.

Preguntas frecuentes

Conclusión

Mejorar un proceso no es hacer que la gente trabaje más rápido: en la mayoría de los procesos administrativos la velocidad de las personas no es el problema. El problema son las colas, los datos que faltan en el punto donde se conocen y los controles que se añadieron por un incidente que ya nadie recuerda. Se llega a eso midiendo, no opinando.

Si vas a arrancar, tres decisiones ordenan el resto: mide la línea base antes de proponer un solo cambio, decide si es mejora, rediseño o eliminación antes de elegir metodología, y entrega el proceso a un dueño con un indicador el día que cierres el proyecto. Las tres se toman en la primera semana y son las que determinan si la mejora sigue viva el año que viene.