Qué automatizar primero cuando todo parece automatizable
Frecuencia por tiempo por costo del error, más el factor que nadie pone en la lista: quién se entera cuando falla. Lo que suele ganar, lo que conviene dejar para después y qué arreglar antes.
Cuando una empresa decide automatizar, la lista de candidatos aparece rápido y es larga. Todo parece automatizable, todo parece urgente, y el proyecto se atasca antes de empezar porque no hay forma obvia de ordenar la lista.
Este es el criterio que usamos para ordenarla. No es una metodología con nombre: son cuatro preguntas que se contestan en una reunión.
La pregunta que no lleva a ningun lado
«¿Qué se puede automatizar?» no sirve, porque la respuesta honesta es «casi todo», y con eso no se prioriza nada. La pregunta que sí ordena es otra: ¿qué me está costando más hacer a mano de lo que costaría arreglarlo?
El cambio importa porque saca de la conversación las tareas que son molestas pero baratas, y mete las que son invisibles y caras. Casi siempre la que más duele no es la que más cuesta.
Frecuencia x tiempo x costo del error
| Factor | La pregunta | Donde se subestima |
|---|---|---|
| Frecuencia | Cuantas veces por semana pasa | Lo diario gana a lo mensual, aunque lo mensual duela mas |
| Tiempo por vez | Cuanto toma hacerlo a mano | Contar la interrupcion, no solo la tarea |
| Costo del error | Que pasa si sale mal una vez | Un error que llega al cliente vale mucho mas que uno interno |
| Deteccion | Quien se entera si deja de funcionar | Si la respuesta es nadie, el riesgo se multiplica |
Frecuencia. Es el factor que más se subestima, porque lo mensual se siente más pesado. Una tarea de tres minutos que ocurre quince veces por día consume mucho más que un cierre mensual de cuatro horas — y además parte el día de alguien quince veces.
Tiempo por vez. Contá la interrupción completa, no la tarea. Copiar un dato de un sistema a otro toma dos minutos; retomar lo que estabas haciendo toma bastante más.
Costo del error. Acá se separan dos mundos. Un error interno se corrige. Un error que llega al cliente —un presupuesto mal, una reserva duplicada, un correo al destinatario equivocado— cuesta en confianza, y eso no se recupera con una disculpa.
El cuarto factor: quien se entera cuando falla
Es el que nadie pone en la lista y el que más problemas genera después. Toda automatización se cae alguna vez: cambia una API, vence un token, alguien renombra una columna.
La pregunta no es si va a fallar, es cuánto tarda alguien en enterarse. Y hay un modo de falla particularmente cruel: el silencioso. Una automatización que deja de correr no produce un error visible — produce nada. Y «nada» se ve exactamente igual que «esta semana no pasó».
Lo que suele ganar, y lo que suele no deber
Candidatos que casi siempre puntúan alto:
- Mover un lead desde el formulario hasta donde alguien lo va a ver. Frecuente, rápido de hacer mal, y el costo del error es un cliente perdido sin que nadie se entere.
- Avisar cuando algo lleva demasiado tiempo sin respuesta. Barato de construir y ataca el problema que más plata cuesta en negocios de servicios.
- Consolidar datos que hoy se copian a mano a una planilla. Frecuencia alta y error silencioso garantizado.
- Recordatorios y confirmaciones. Volumen alto, criterio nulo, impacto directo en ausencias.
Y los que conviene dejar para después, aunque den ganas:
- Procesos con muchas excepciones. Si cada caso tiene un «salvo que», vas a programar el «salvo que» para siempre.
- Lo que cambia todos los meses. Automatizar algo inestable es construir sobre arena.
- Decisiones de criterio disfrazadas de reglas. Si la regla real es «depende de cómo venga el cliente», eso no es una regla.
- Lo que ocurre tres veces al año. Aunque cada vez sea un dolor de cabeza.
Un apunte sobre IA: casi nada de la primera lista la necesita. Mover, avisar, validar y agendar son problemas resueltos con automatización clásica, más barata y más predecible. La IA gana cuando la entrada es lenguaje sin estructura — y ahí trae sus propias reglas, que están en qué sale mal con un agente que atiende clientes.
Que arreglar antes de automatizar nada
Automatizar un proceso malo lo hace más rápido, no mejor. Antes de construir conviene descartar tres cosas:
- Que el proceso esté escrito. Si nadie puede describirlo en cinco pasos, no está listo para automatizarse: está listo para definirse.
- Que los datos que necesita existan y sean confiables. Una automatización que lee un campo que la mitad de las veces está vacío hereda ese problema y lo esparce.
- Que haya un dueño. Alguien que reciba la alerta y decida qué hacer. Sin eso, la automatización tiene fecha de vencimiento.
El primero descarta más proyectos de los que parece, y siempre para bien: escribir el proceso suele revelar que el problema no era la falta de automatización.
Preguntas frecuentes
- Conviene automatizar primero el proceso mas grande? Normalmente no. Los procesos grandes son los que tienen mas excepciones, y las excepciones son lo que rompe una automatizacion. Empezar por algo chico y frecuente te deja un sistema funcionando y un equipo que confia, que es lo que hace posible el siguiente.
- Conviene comprar una herramienta o construirla? Comprar cuando el proceso es estandar y la herramienta ya lo hace. Construir cuando el proceso es lo que te diferencia. El error caro es comprar una herramienta y despues doblar tu negocio para que entre.
- Necesito IA para esto? La mayor parte de lo que conviene automatizar primero no necesita IA: mover datos entre sistemas, avisar, validar, agendar. La IA gana su lugar donde la entrada es lenguaje sin estructura. Ponerla primero le agrega costo e incertidumbre a un problema resuelto.
- Como se si esta funcionando? Defini la senal de falla antes de construir. Si nadie se daria cuenta de que la automatizacion se detuvo, no construiste un sistema: construiste algo que va a fallar en silencio.