Pregúntale a alguien de tu equipo cuánto tarda en hacer una tarea que hace todos los días. Te dará un número rápido y seguro. Y casi siempre será más bajo que el real.
No miente. Se acuerda mal. Y si decides automatizar un proceso a partir de ese número, vas a calcular mal lo que ganas, lo que cuesta y si ha funcionado.
Este artículo es la continuación práctica de por qué en IA lo pequeño es lo único que funciona. Allí decíamos que el primer paso es medir. Aquí te contamos exactamente qué medir, cómo hacerlo en una semana sin software y qué decisión tomar con cada resultado.
Resumen rápido
- Antes de automatizar un proceso hay que medir cinco números: frecuencia, tiempo de trabajo por vez, tiempo de espera, retrabajo y excepciones.
- La duración de las tareas no se pregunta, se cronometra: la investigación en psicología muestra que recordamos las tareas como más cortas de lo que fueron, y que la experiencia con una tarea aumenta ese sesgo en lugar de corregirlo (Roy, Christenfeld y McKenzie, Psychological Bulletin, 2005).
- En procesos administrativos, el tiempo en que alguien trabaja de verdad suele ser en torno al 10% del tiempo total; el resto es espera (George, Lean Six Sigma, 2002). Si lo que duele es la espera, lo que hay que automatizar es el aviso, no la tarea.
- Con dos semanas normales de registro tienes base suficiente. Al final tienes la fórmula de horas al año, una tabla de decisión y una plantilla de registro.
¿Por qué hay que medir antes de automatizar un proceso?
Por tres motivos, y ninguno es burocrático.
Primero, para elegir bien. La consultora EY, que ha desplegado proyectos de automatización robótica (RPA) en una veintena de países, cuenta en su guía Get ready for robots que ha visto fracasar entre el 30% y el 50% de los primeros proyectos. Entre las causas que señala están elegir mal los procesos y no tener un caso de negocio antes del piloto. Las dos se resuelven con lo mismo: números de partida.
Segundo, para no acelerar un proceso que sobra. En 1990 Michael Hammer publicó en Harvard Business Review un artículo con un título que sigue vigente: Reengineering Work: Don’t Automate, Obliterate. Su tesis: mucho trabajo no aporta valor y lo que hay que hacer con él es quitarlo, no hacerlo más rápido. Medir es la forma de verlo antes de pagar por automatizarlo.
Tercero, para saber si ha funcionado. Sin la cifra de antes, dentro de tres meses solo tendrás impresiones. Y las impresiones no aguantan una discusión de presupuesto.
¿Qué números hay que medir?
Cinco. Los tres primeros los mencionábamos en el artículo anterior; los dos últimos son los que casi nadie mide y los que más proyectos tumban.
1. Frecuencia: cuántas veces ocurre de verdad
Veces por semana, contadas, no estimadas. Es el multiplicador de todo lo demás: ahorrar diez minutos en algo que pasa dos veces al mes no se nota; ahorrar dos minutos en algo que pasa cien veces por semana, sí.
2. Tiempo de trabajo por vez: cronometrado, no recordado
Los minutos en que una persona está realmente con la tarea, desde que la abre hasta que la da por cerrada. Aquí está la trampa principal, y está documentada.
Michael Roy, Nicholas Christenfeld y Craig McKenzie revisaron la evidencia sobre por qué subestimamos lo que van a durar las tareas y llegaron a una explicación incómoda: no es solo optimismo, es memoria. Recordamos las tareas pasadas como más cortas de lo que fueron, y predecimos a partir de ese recuerdo sesgado. En experimentos posteriores, Roy y Christenfeld observaron que el sesgo desaparece cuando la tarea es nueva, y la literatura que recogen asocia más experiencia con una tarea a una mayor tendencia a subestimarla.
Traducido: la persona que mejor conoce el proceso es la que peor va a calcular cuánto dura. Y lo que corrigió el error en sus estudios no fue pedir que se esforzaran más, sino darles la duración real medida.
Un matiz útil: en tareas muy cortas, de menos de un par de minutos, el error suele ir al revés y se tiende a sobreestimar. Otra razón para cronometrar en lugar de preguntar.
3. Tiempo de espera: lo que tarda en salir, no lo que se tarda en hacer
Desde que la tarea entra (llega el correo, se pide el documento, se abre la incidencia) hasta que sale terminada. Casi siempre es muchísimo más que el tiempo de trabajo.
Lean Six Sigma tiene un nombre para la proporción entre los dos: eficiencia del ciclo del proceso. Michael George recoge en Lean Six Sigma (McGraw-Hill, 2002) que en procesos administrativos o transaccionales lo habitual ronda el 10%, y que los mejores llegan al 50%. Es decir: de cada diez horas que un expediente pasa «en proceso», en una alguien está trabajando en él. Las otras nueve está esperando en una bandeja, en un correo o en la cabeza de alguien.
Esto cambia la solución. Si la tarea son 8 minutos pero tarda 4 días en salir, automatizar los 8 minutos no arregla nada. Lo que hay que automatizar es el traspaso: el aviso, la asignación, el recordatorio.
4. Retrabajo: cuántas veces se hace dos veces
Porcentaje de veces que algo vuelve: falta un dato, hay que corregirlo, el cliente lo devuelve, alguien lo revisa y lo rehace. Armand Feigenbaum, uno de los padres de la gestión de la calidad total, llamó a esto la fábrica oculta: la parte de la organización que existe para rehacer trabajo mal hecho. En una entrevista de 1994 estimó que podía ocupar entre el 20% y el 40% de la capacidad de muchas empresas. Es una estimación de experto, no un estudio con datos, pero cualquiera que haya trabajado en calidad reconoce el fenómeno.
Por qué importa antes de automatizar: si un proceso se rehace una de cada tres veces y lo automatizas tal cual, ahora se equivocará más rápido. Primero se arregla la entrada (una plantilla, una lista de comprobación, un campo obligatorio). Después se automatiza.
5. Excepciones: cuántos casos se salen del camino normal
El porcentaje de veces en que alguien dice «este es distinto». Es el número que decide si un proceso se puede automatizar ya o hay que ordenarlo antes.
La propia EY propone como primer objetivo razonable automatizar en torno al 70% de un proceso, el de menos valor, y dejar el resto a personas. Nuestra regla es parecida: si la versión automatizada resuelve bien los casos normales y deriva los raros a una persona, adelante. Si los raros son casi la mitad, el proceso todavía no existe como proceso: son muchos procesos con el mismo nombre.
¿Cómo se calcula si merece la pena automatizarlo?
Con una cuenta de servilleta:
Horas al año = veces por semana × minutos por vez × 48 semanas ÷ 60 × (1 + % de retrabajo)
Sin retrabajo, así se ven algunos casos típicos:
| Frecuencia | Minutos por vez | Horas al año |
|---|---|---|
| 2 veces al mes | 120 | 48 h |
| 5 por semana | 10 | 40 h |
| 20 por semana | 5 | 80 h |
| 50 por semana | 3 | 120 h |
| 100 por semana | 2 | 160 h |
| 20 por semana | 20 | 320 h |
Fíjate en la segunda mitad de la tabla. La tarea de dos minutos que nadie tiene en el radar se come más horas que el informe de dos horas que todo el mundo odia. Por eso la frecuencia se cuenta y no se intuye.
Con las horas al año ya puedes comparar con el coste de montarlo y mantenerlo. Y si el retrabajo es alto, súmalo: en un proceso con un 30% de retrabajo, esas 320 horas son en realidad 416.
¿Cómo se mide en una semana sin software?
No hace falta minería de procesos ni una herramienta nueva. Hace falta una hoja con cinco columnas, rellenada por quien hace la tarea, cada vez que la hace:
| Entra (día y hora) | Empiezo (hora) | Termino (hora) | ¿Ha vuelto o se ha rehecho? | ¿Caso raro? ¿Por qué? |
|---|---|---|---|---|
| Lun 9:12 | Lun 11:40 | Lun 11:52 | No | — |
| Lun 10:05 | Mar 9:15 | Mar 9:31 | Sí, faltaba el NIF | — |
| Lun 12:30 | Lun 16:00 | Lun 16:45 | No | Sí, cliente con dos sedes |
Con eso salen los cinco números: frecuencia (filas), tiempo de trabajo (termino − empiezo), espera (empiezo − entra, más lo que tarda en salir), retrabajo (columna 4) y excepciones (columna 5).
Cuatro reglas para que los datos sirvan:
- Dos semanas normales. Ni cierre de mes, ni vacaciones, ni la semana de la auditoría. Si el proceso tiene picos, mide uno aparte y sepáralo.
- Mide quien lo hace, no quien lo supervisa. Quien supervisa conoce el procedimiento escrito; quien lo hace conoce el real. Y no suelen coincidir.
- Explica para qué es. No se mide a la persona, se mide el proceso. Si el equipo cree que es control, los tiempos saldrán bonitos y no te servirán.
- Anota en el momento. Rellenarlo el viernes de memoria es volver al problema del principio.
¿Qué hago con los resultados?
Esta es la parte que convierte la medición en una decisión. Cada patrón apunta a una solución distinta, y no siempre es automatizar:
| Lo que sale al medir | Qué significa | Qué hacer |
|---|---|---|
| Muchas horas al año, poco retrabajo, pocas excepciones | Candidato claro | Automatizar. Empezar por los casos normales y derivar los raros a una persona. |
| Poco tiempo de trabajo, mucha espera | El cuello de botella es el traspaso | Automatizar el aviso, la asignación o el recordatorio, no la tarea. |
| Retrabajo alto | El problema está en la entrada | Arreglar primero la plantilla, la lista de comprobación o los datos obligatorios. Volver a medir. |
| Excepciones altas | No es un proceso, son varios | Estandarizar primero. Separar los tipos de caso y medir cada uno. |
| Pocas horas al año | No compensa | No automatizar. Una plantilla o una lista de comprobación y a otra cosa. |
Fíjate en que tres de las cinco filas terminan en «todavía no». Eso no es un fracaso de la medición. Es exactamente para lo que sirve: para no pagar por automatizar algo que había que arreglar, y para que, cuando lo automatices, la mejora se pueda demostrar.
Medir antes de automatizar no retrasa el proyecto. Te ahorra el proyecto equivocado.
Los errores más comunes al medir un proceso
- Preguntar en vez de medir. Por lo que hemos visto: la memoria acorta las tareas que hacemos a menudo.
- Medir solo el tiempo de trabajo. Te pierdes la espera, que suele ser donde está el dolor del cliente.
- Medir el procedimiento, no el proceso. El documento dice una cosa; la persona hace otra que funciona mejor o peor. Automatiza lo que se hace, no lo que está escrito.
- Olvidar el retrabajo. Una tarea que se hace dos veces cuesta el doble, aunque en la hoja aparezca una sola fila.
- Medir y no volver a medir. Los mismos cinco números, 30 días después de poner en marcha la automatización. Si no han mejorado, se apaga y se prueba otra cosa.
Preguntas frecuentes
¿Cuánto tiempo hay que medir un proceso antes de automatizarlo?
Dos semanas normales suelen bastar para procesos que ocurren varias veces por semana. Si el proceso es mensual o tiene picos estacionales, mide al menos un ciclo completo y trata el pico por separado.
¿Necesito una herramienta de minería de procesos?
Para una pyme y un primer proceso, no. Una hoja de registro con cinco columnas da los números que necesitas para decidir. La minería de procesos tiene sentido cuando hay muchos procesos que ya dejan rastro en un sistema (un ERP, un gestor de incidencias) y quieres compararlos a escala.
¿Y si mi equipo siente que lo estoy vigilando?
Es el riesgo más real, y se gestiona explicando antes para qué es: se mide el proceso para quitar la parte mecánica, no para evaluar a nadie. Ayuda mucho que sea el propio equipo quien rellene el registro y quien vea los resultados primero.
¿A partir de cuántas horas al año compensa automatizar?
No hay un umbral universal: depende de lo que cueste montarlo y mantenerlo. Como orientación, un proceso que supera las 100 o 150 horas al año, con pocas excepciones, suele justificar una automatización sencilla. Por debajo, normalmente rinde más una plantilla o una lista de comprobación.
¿Puedo usar IA para medir el proceso?
Sí, sobre todo para lo pesado: extraer fechas de entrada y salida de correos o de un gestor de tareas, o clasificar los motivos de retrabajo y de excepción a partir de lo que el equipo anota. Lo que no conviene delegar es la decisión de qué hacer con los números.
En resumen
Antes de automatizar un proceso, cinco números: cuántas veces pasa, cuánto se tarda de verdad, cuánto espera, cuántas veces se rehace y cuántos casos se salen del camino. Cronometrados, no recordados. Dos semanas normales. Y una decisión por patrón, que a veces es automatizar y a veces es arreglar primero.
Lo que no se mide antes no se puede demostrar después.
¿Tienes ya los números y no sabes qué fila de la tabla te toca? Mándanoslos y te decimos qué haríamos con ellos. Y si al mirarlos sale que no compensa automatizar, ya tienes la respuesta, gratis.
Fuentes
- Roy, M. M., Christenfeld, N. J. S. y McKenzie, C. R. M. (2005). Underestimating the duration of future events: Memory incorrectly used or memory bias? Psychological Bulletin, 131(5), 738–756.
- Roy, M. M. y Christenfeld, N. J. S. (2007). Bias in memory predicts bias in estimation of future task duration. Memory & Cognition, 35(2), 557–564.
- Roy, M. M., Mitten, S. T. y Christenfeld, N. J. S. (2008). Correcting memory improves accuracy of predicted task duration. American Psychological Association.
- George, M. L. (2002). Lean Six Sigma: Combining Six Sigma Quality with Lean Speed. McGraw-Hill.
- Hammer, M. (1990). Reengineering Work: Don’t Automate, Obliterate. Harvard Business Review, julio-agosto.
- EY (2016). Get ready for robots: Why planning makes the difference between success and disappointment.
- Feigenbaum, A. V. Entrevista en IndustryWeek, julio de 1994 (estimación de la «fábrica oculta»).
¿Listo para que la IA trabaje para ti?
Cuéntanos qué necesitas y te respondemos en menos de 24h — sin compromiso.
Al enviar aceptas nuestra política de privacidad.