Automatizar un proceso roto solo hace que el problema ocurra más rápido
Casi cada semana nos piden automatización. Casi nadie nos pide primero revisar el proceso. Esa es la parte que la mayoría de los equipos se salta, y es la que realmente importa.
Lo vemos pasar casi siempre de la misma forma: un equipo está ahogado en un proceso manual, alguien propone una herramienta, y en una semana ya hay una demo agendada. Nadie se detuvo a dibujar qué pasa realmente entre el paso uno y el paso diez. La demo se ve increíble. Siempre se ve así, porque las demos corren con datos limpios e hipotéticos, no con la versión del proceso que vive repartida en tres hojas de cálculo distintas y la bandeja de entrada de una persona.
La velocidad no es el objetivo
Un proceso que confunde a tu equipo, pierde información o depende de que una sola persona se acuerde de algo no mejora por correr más rápido. Empeora. Los errores que antes tardaban una semana en aparecer ahora aparecen en un día. El cuello de botella que antes se escondía detrás del trabajo manual ahora queda a la vista, solo que ya nadie puede bajar el ritmo para arreglarlo.
Lo hemos visto con el seguimiento de leads, el onboarding, los reportes: el patrón se repite. Una empresa construye un bot o un flujo sobre un proceso que nadie ha mapeado de verdad, y tres meses después están automatizando el mismo desorden, nada más que más rápido.
Para cuando alguien lo nota, la automatización ya no es el problema. Solo está repitiendo el problema original, más rápido y con más confianza. Nadie regresa a revisar, porque el dashboard dice que todo está corriendo, y correr se parece mucho a funcionar.
Lo que hacemos en su lugar
Antes de automatizar cualquier cosa, preguntamos para qué sirve realmente el proceso, quién lo toca y dónde se pierde la información. A veces la respuesta es que un paso no debería existir. Automatizar ese paso habría sido trabajo desperdiciado, sin importar qué tan bien estuviera construido.
A veces esa conversación termina en "automaticemos esto." Igual de seguido termina en "dejemos de hacer esto por completo," que es un mejor resultado del que nadie esperaba escuchar. Ninguna de las dos respuestas es un fracaso. Gastar una tarde en averiguarlo es más barato que gastar un trimestre construyendo lo que no era.
¿Qué decide si está listo?
Es una lista corta de preguntas, no una corazonada. Hacemos las mismas cuatro preguntas antes de automatizar cualquier cosa:
- ¿Todo el equipo ya está de acuerdo en cómo debería funcionar esto?
- ¿Este proceso se ha mantenido igual en los últimos meses, o todavía está cambiando?
- ¿Un error aquí sería fácil de detectar, o se escondería hasta que un cliente se queje?
- ¿Alguien ya está haciendo esto lo suficientemente bien como para enseñárselo a una máquina?
Si la respuesta a más de una de esas es no, automatizar solo deja fijo el desacuerdo en lugar de resolverlo.
Un equipo con el que trabajamos se saltó esto y automatizó la aprobación de facturas antes de que alguien acordara qué significaba realmente "aprobado." La herramienta funcionó perfecto. Solo hizo oficiales tres definiciones distintas de la misma palabra, dependiendo de quién presentara la solicitud.
Eso no es un problema de tecnología. Es un problema de definición disfrazado de tecnología, y aparece justo en el momento en que la automatización vuelve oficial el desacuerdo en lugar de resolverlo.
¿Qué realmente cambia cuando el orden es el correcto?
No es la velocidad. Es si el mismo error deja de pasar, automatizado o no.
Un proceso lento que por fin está claro tiende a arreglarse solo antes de que alguien construya nada. Esa suele ser la primera señal de que el equipo ya estaba listo para automatizar.
Un cliente seguía posponiendo la automatización porque el proceso manual "todavía no estaba listo." Para cuando lo estuvo, el error que les preocupaba no había vuelto a pasar en meses, no porque nadie se volviera más rápido, sino porque la confusión que lo causaba ya no estaba.
La lección no era esperar más tiempo. Era que la preparación que les faltaba no tenía nada que ver con el calendario.
Un proceso está realmente claro, no solo más rápido, cuando:
- La misma pregunta deja de hacerse dos veces
- Alguien nuevo puede seguirlo sin que otra persona se lo traduzca
- Las excepciones tienen una regla en vez de una persona que las recuerde
- Ya nadie necesita revisar a mano el trabajo de la automatización
Ninguna de esas cosas depende de la automatización en sí. Ya eran ciertas, o no lo eran, antes de que entrara una sola herramienta. La herramienta solo decide qué tan rápido se nota la verdad.
Preguntas frecuentes
¿Cómo sabemos si un proceso realmente está listo para automatizarse?
Córranlo manualmente una vez más y escriban cada decisión que alguien toma en el camino, no solo los pasos. Si dos personas tomarían decisiones distintas en el mismo punto, el proceso todavía no está listo, el desacuerdo sí. Esa es la parte que vale la pena arreglar antes de construir nada, y normalmente toma menos tiempo del que la gente espera.
Ya automatizamos algo y no está funcionando. ¿Ahora qué?
Regresen al proceso sobre el que se construyó, no a la automatización en sí. La mayoría de las veces la herramienta está haciendo exactamente lo que le indicaron, las instrucciones fueron las que estuvieron mal desde el principio. Reconstruir la automatización sin arreglar eso solo produce una versión más rápida y más segura del mismo error.
¿Mapear el proceso no nos va a hacer más lentos?
Hace más lenta la primera semana, no los próximos dos años. Mapear normalmente toma unos días. Desenredar una mala automatización después toma mucho más tiempo, y ese es el costo real que vale la pena comparar.
¿Cuál es la diferencia entre automatizar un proceso y arreglarlo?
Arreglar un proceso cambia cómo se hace el trabajo de verdad. Automatizar un proceso cambia quién, o qué, hace el mismo trabajo más rápido. Se puede automatizar sin arreglar nada, que es exactamente cómo un proceso roto empieza a moverse más rápido. La mayoría de las empresas necesitan lo primero mucho más seguido que lo segundo, aunque lo segundo sea lo que se presupuesta.
La automatización es un multiplicador. Multiplica lo que le des de comer: claridad o caos. Nuestro trabajo es asegurarnos de que sea claridad.
En Linaria empezamos por ahí: mapeamos el proceso antes de tocar una sola automatización, para asegurarnos de que lo que se multiplique sea orden y no desorden. Si no estás seguro de qué le estarías dando de comer a tu próxima automatización, hablemos.