Cómo medir el tiempo de un proceso y detectar dónde se generan las demoras

Imaginemos que una empresa tarda cinco días en atender una solicitud de un cliente.

A primera vista podríamos concluir que el proceso necesita cinco días de trabajo.

Sin embargo, al analizarlo podemos descubrir que las actividades necesarias requieren solamente tres horas de trabajo efectivo. El resto corresponde a esperas entre áreas, aprobaciones, correcciones, búsqueda de información o acumulación de solicitudes.

Esta diferencia es fundamental.

Tiempo total del proceso: tiempo transcurrido desde que se inicia hasta que finaliza.

Tiempo efectivo de trabajo: tiempo durante el cual realmente se está ejecutando una actividad.

Tiempo de espera: períodos en los que el proceso permanece detenido esperando una acción, decisión, información o recurso.

Cuando una organización diferencia estos tiempos, comienza a entender dónde se encuentra realmente el problema.

El tiempo de ciclo es el tiempo que transcurre desde un punto definido de inicio hasta la finalización del proceso. Por ejemplo, en un proceso de compras podría medirse desde que un área genera una solicitud hasta que recibe el producto. En atención al cliente, desde que ingresa un requerimiento hasta que se entrega una respuesta o solución. En facturación, desde que se recibe la información necesaria hasta que la factura es emitida. 

Lo importante es establecer claramente dónde comienza y dónde termina la medición.

Sin estos límites, diferentes personas podrían medir el mismo proceso de maneras distintas y obtener resultados que no son comparables.

Antes de utilizar un cronómetro o analizar registros, debemos establecer qué queremos medir.

Por ejemplo:

Inicio: recepción de la solicitud del cliente.
Fin: envío de la respuesta definitiva al cliente.

Esta definición debe mantenerse constante durante las mediciones.

El siguiente paso es comprender cómo funciona actualmente el proceso.

Se deben identificar actividades, responsables, decisiones, transferencias entre áreas, sistemas utilizados, documentos y puntos de aprobación.

Representar el proceso mediante un diagrama de flujo o BPMN facilita visualizar dónde se producen cambios de responsable y posibles tiempos de espera.

El objetivo es analizar el proceso AS-IS, es decir, cómo funciona realmente y no cómo debería funcionar según un procedimiento.

Una vez identificadas las actividades, podemos registrar cuánto tarda cada una.

Por ejemplo:

Recepción y revisión de solicitud: 15 minutos.
Registro en sistema: 10 minutos.
Análisis técnico: 45 minutos.
Aprobación: 20 minutos.
Preparación de respuesta: 30 minutos.

Pero medir únicamente estos tiempos puede generar una conclusión equivocada.

También necesitamos medir qué ocurre entre las actividades.

Supongamos que el análisis técnico termina el lunes a las 11:00 y la aprobación comienza el martes a las 15:00.

La aprobación puede tomar solamente 20 minutos, pero el proceso permaneció detenido durante más de un día.

Ese tiempo debe ser visible.

Los tiempos de espera suelen aparecer cuando:

• una actividad pasa de un área a otra;
• se requiere autorización;
• falta información;
• existen bandejas de trabajo acumuladas;
• una persona concentra demasiadas decisiones;
• se espera respuesta de un proveedor o cliente;
• la información debe corregirse;
• existen tareas que solamente se realizan determinados días.

En muchos procesos, la mayor oportunidad de mejora no está en reducir minutos de ejecución, sino horas o días de espera.

Una forma sencilla de analizar un proceso es separar:

Tiempo de procesamiento + Tiempo de espera = Tiempo total del proceso

Por ejemplo:

Tiempo efectivo de trabajo: 3 horas.
Tiempo de espera acumulado: 21 horas.
Tiempo total: 24 horas.

En este caso, intentar reducir una actividad de 20 a 15 minutos tendrá un impacto limitado.

La pregunta debería ser:

¿Por qué existen 21 horas de espera?

Este cambio de enfoque ayuda a priorizar correctamente las iniciativas de mejora.

Una vez obtenidos los tiempos, conviene analizarlos por actividad y por transición.

Algunas señales importantes son:

Acumulación de solicitudes: existe más trabajo pendiente del que una actividad puede procesar.

Aprobaciones prolongadas: una solicitud permanece demasiado tiempo esperando autorización.

Transferencias entre áreas: cada cambio de responsable genera esperas adicionales.

Reprocesos: una actividad regresa a una etapa anterior porque la información está incompleta o contiene errores.

Dependencia de una persona: el proceso se detiene cuando un responsable no está disponible.

Procesamiento por lotes: las solicitudes no se atienden cuando llegan, sino que se acumulan para ser procesadas posteriormente.

Sistemas desconectados: la información debe copiarse manualmente entre aplicaciones, hojas de cálculo o documentos.

Estas situaciones permiten identificar posibles cuellos de botella.

Un cuello de botella es una actividad, recurso o punto del proceso cuya capacidad limita el flujo general.

Por ejemplo, cinco personas pueden preparar solicitudes, pero si solamente una persona puede aprobarlas, es posible que las solicitudes comiencen a acumularse antes de esa aprobación.

El problema no necesariamente está en que la aprobación sea lenta.

Puede estar en que la capacidad disponible es menor que la demanda que recibe.

Por eso, además del tiempo, conviene observar:

• cantidad de solicitudes recibidas;
• solicitudes pendientes;
• capacidad de procesamiento;
• frecuencia de errores;
• porcentaje de reprocesos;
• carga de trabajo por responsable.

No es necesario comenzar con herramientas complejas. Una hoja de cálculo puede registrar:

Proceso | Actividad | Responsable | Fecha/hora inicio | Fecha/hora fin | Tiempo efectivo | Tiempo de espera | Observación

Con varias mediciones será posible calcular promedios e identificar las actividades o transiciones que concentran mayores demoras.

Es importante no basar las decisiones en un único caso. Un proceso puede experimentar una demora excepcional que no represente su comportamiento habitual.

Por ello, conviene analizar una muestra suficiente de operaciones.

Además del tiempo total, pueden utilizarse indicadores como:

Tiempo promedio de ciclo: tiempo promedio necesario para completar el proceso.

Tiempo promedio de espera: tiempo que las solicitudes permanecen detenidas.

Porcentaje de tiempo de espera: proporción del tiempo total que corresponde a esperas.

Porcentaje de cumplimiento del tiempo objetivo: cantidad de casos terminados dentro del plazo establecido.

Tasa de reproceso: porcentaje de casos que deben regresar a una actividad anterior.

Solicitudes pendientes: volumen de operaciones que todavía no han sido procesadas.

Estos indicadores permiten pasar de una percepción subjetiva —"el proceso es lento"— a una gestión basada en datos.

Encontrar el punto donde se produce una demora es solamente el comienzo. El siguiente paso es determinar por qué ocurre.

Una aprobación puede tardar dos días porque el responsable tiene demasiadas solicitudes, porque la información llega incompleta, porque no recibe una notificación automática o porque la organización estableció un nivel de autorización innecesario.

Dependiendo de la causa, la solución será diferente. Las alternativas pueden incluir:

simplificar actividades, eliminar duplicidades, redefinir responsabilidades, establecer tiempos objetivo, modificar niveles de aprobación, estandarizar información, redistribuir cargas de trabajo, integrar sistemas o automatizar tareas.

Primero se identifica la causa. Después se selecciona la solución.

No necesariamente.

Si un proceso tiene actividades innecesarias, controles duplicados o demasiadas aprobaciones, automatizarlas puede hacer más rápido un proceso que sigue estando mal diseñado.

Antes de automatizar conviene analizar:

¿La actividad agrega valor?
¿Es necesaria?
¿Puede simplificarse?
¿Puede eliminarse?
¿Debe cambiar de responsable?
¿Puede automatizarse?

Una vez optimizado el proceso, herramientas de automatización e inteligencia artificial pueden ayudar a reducir tareas manuales, generar alertas, transferir información entre sistemas y facilitar el seguimiento de tiempos.

Si una empresa rediseña un proceso pero nunca midió su situación inicial, tendrá dificultades para demostrar cuánto mejoró.

Por eso es recomendable establecer una línea base AS-IS.

Por ejemplo:

Antes: tiempo promedio de ciclo = 72 horas.
Después: tiempo promedio de ciclo = 30 horas.

La reducción sería:

(72 − 30) / 72 × 100 = 58,3 %

Este tipo de medición permite demostrar con datos el impacto del rediseño y establecer nuevos objetivos de mejora.

Medir el tiempo de un proceso no consiste únicamente en cronometrar actividades.

El verdadero objetivo es entender cómo fluye el trabajo, cuánto tiempo agrega valor y cuánto tiempo se pierde esperando, corrigiendo, trasladando información o buscando aprobaciones.

Una metodología práctica puede seguir esta secuencia:

LEVANTAR AS-IS → MEDIR → IDENTIFICAR DEMORAS → ANALIZAR CAUSAS → DISEÑAR TO-BE → IMPLEMENTAR → VOLVER A MEDIR

De esta manera, las decisiones de mejora dejan de depender únicamente de percepciones y comienzan a sustentarse en evidencia.

En ​KONEGGUI ​ayudamos a las organizaciones a levantar y analizar sus procesos AS-IS, identificar tiempos de espera, reprocesos y cuellos de botella, diseñar procesos TO-BE y evaluar oportunidades de automatización e inteligencia artificial.

El objetivo no es simplemente hacer un diagrama, sino encontrar dónde se está perdiendo tiempo y qué cambios pueden mejorar la eficiencia operativa.

¿Sabes cuánto tiempo de tus procesos corresponde realmente a trabajo y cuánto a espera?

Analicemos tus procesos e identifiquemos dónde se generan las demoras.