Automatizar procesos en tu empresa: del papel al piloto en 30 días
La mayoría de proyectos de automatización mueren en la fase de reuniones. Este es el plan de cuatro semanas que usamos para llevar un proceso real desde la idea hasta funcionando, sin apostarse la operación.
Hay una razón por la que tantas iniciativas de IA en empresas no llegan a ningún lado, y no es la tecnología. Es que empiezan con un plan de doce meses para transformar toda la compañía, y a los tres meses nadie recuerda cuál era el objetivo.
Lo que sí funciona es lo contrario: un proceso, cuatro semanas, un resultado medible. Y cuando el equipo ve funcionar el primero, el segundo lo piden ellos.
Semana 1 — Elegir el proceso correcto
Esta es la semana más importante y la que más gente se salta. Elegir mal el primer proceso es la forma más común de quemar el proyecto.
Haz la lista
Reúne al equipo y pregunta algo muy concreto: «¿qué haces cada semana que te aburre y sientes que un robot podría hacer?». No preguntes por «oportunidades de innovación» — pregunta qué les molesta. Salen mejores respuestas.
Filtra con cuatro criterios
- Volumen: ¿pasa al menos 20 veces por semana? Menos que eso y el esfuerzo no se paga.
- Repetición: ¿se hace casi igual todas las veces? Si cada caso es un mundo, no es el primero.
- Reversibilidad: ¿un error se detecta y se corrige fácil? Empieza por donde equivocarse sea barato.
- Dueño claro: ¿hay una persona que conoce el proceso y puede decidir? Sin eso, el proyecto se estanca en consultas.
Si nadie sabe explicar el proceso completo en una hoja, no lo automatices todavía — ordénalo primero. Automatizar un proceso confuso solo produce confusión más rápida.
Semana 2 — Mapearlo como es, no como debería ser
Siéntate con quien lo hace hoy y escribe cada paso real. No la versión oficial del manual: la versión verdadera, con los atajos y las excepciones que la gente aplica sin decírselo a nadie.
Para cada paso anota tres cosas: qué entra, qué decisión se toma y qué sale. Ese documento es el 80% del trabajo de automatizar; el código es el otro 20%.
Presta atención especial a las excepciones: «cuando el cliente es del norte, se hace distinto», «si viene sin factura, se llama a Andrea». Las excepciones son donde los proyectos se atascan si aparecen tarde. Sácalas ahora.
Define qué es «bien hecho»
Antes de escribir una línea de código, escribe cómo vas a saber si funciona. Por ejemplo: «el 90% de las respuestas se pueden enviar sin editarlas», o «ningún correo queda sin procesar en más de 15 minutos». Un criterio que se pueda verificar, no una sensación.
Semana 3 — Montar el piloto, siempre supervisado
Acá se construye. Y hay una regla que no negociamos: el piloto arranca en modo supervisado. El sistema hace todo el trabajo, pero no ejecuta la acción final — deja el borrador, la clasificación o la respuesta lista para que una persona apruebe.
Suena a media automatización, pero hace tres cosas clave:
- Elimina el riesgo mientras todavía no sabes qué tan bien funciona.
- Genera confianza en el equipo, que ve la calidad antes de soltarle el control.
- Te da datos reales de cuántas veces acierta, que es justo lo que necesitas para decidir.
Y limita el alcance: un canal, un tipo de caso, un volumen manejable. La tentación de meter todo de una es la que hace que nada quede bien.
El modo supervisado no es un paso previo a la automatización real. Es la automatización real, con un interruptor de seguridad que puedes apagar cuando ya confíes.
Semana 4 — Medir, ajustar y decidir
Deja correr el piloto con casos reales y mide contra lo que definiste en la semana 2. Tres números:
- Tasa de acierto: ¿cuántas veces el resultado se aprobó sin cambios?
- Tiempo de trabajo: ¿cuánto tarda ahora la persona, comparado con antes?
- Tiempo hasta la respuesta: desde que entra el caso hasta que sale la respuesta.
Con esos números tienes tres caminos honestos:
- Acierta por encima del 90%: pasa a modo autónomo para los casos claros y deja supervisión solo en los raros.
- Entre 70% y 90%: quédate en supervisado y ajusta. Casi siempre el problema son las instrucciones, no la tecnología.
- Por debajo del 70%: mira el mapa de la semana 2 otra vez. Normalmente falta información que el proceso usa sin que nadie lo hubiera escrito.
Los errores que más vemos
| Error | Qué pasa | Qué hacer |
|---|---|---|
| Empezar por el proceso más crítico | Un fallo cuesta caro y mata el proyecto | Empieza por uno molesto pero seguro |
| Saltarse el modo supervisado | Errores llegan al cliente y se pierde la confianza | Supervisado siempre las primeras semanas |
| No involucrar a quien hace el trabajo | El sistema ignora las excepciones reales | Que sea copiloto del proyecto, no espectador |
| No medir el «antes» | No puedes demostrar la mejora | Mide una semana antes de tocar nada |
| Automatizar todo de una vez | Nada queda bien terminado | Un proceso, un canal, una victoria |
Y después del primero
El segundo proceso siempre es más rápido: ya tienes las conexiones montadas, el equipo entiende la dinámica y hay un resultado que mostrar cuando alguien pregunte «¿y esto para qué sirve?».
Nuestro agente de reclutamiento siguió exactamente este plan: elegimos el buzón de hojas de vida porque era molesto y de bajo riesgo, lo mapeamos, lo montamos supervisado y lo medimos. Sigue en supervisado — y lo pasaremos a autónomo cuando los números lo pidan, no cuando nos emocionemos.
¿Arrancamos con tu primer proceso?
La primera conversación es gratis: nos cuentas el proceso, y te decimos si es buen candidato, cuánto toma y qué esperar — sin humo.