Cómo empezar un proyecto de automatización (guía para gerentes)

Los gerentes que nos escriben rara vez piden un robot. El mensaje suele parecerse a este: "Tengo dos personas que pasan la mañana copiando datos de un sistema a otro, y siento que eso debería hacerlo una máquina."

La intuición es correcta. Lo que suele faltar es saber qué hacer, en concreto, entre esa idea y un robot funcionando.

Si sospechas que hay algo para automatizar y no sabes por dónde empezar, los primeros pasos no son técnicos y puedes darlos sin ayuda. Si ya cotizaste y comparas proveedores, probablemente pasaste esta etapa.

Elegir el primer proceso

Antes de hablar con un proveedor, define qué proceso vas a poner sobre la mesa. Esa decisión te corresponde, porque nadie conoce el día a día del área mejor que quien la dirige.

Busca un proceso que se repita seguido, todos los días o todas las semanas, y que se haga casi siempre de la misma forma. El candidato ideal, además, toca sistemas que hoy no se comunican entre sí.

Un error frecuente en esta etapa es empezar por el proceso que más duele. El que más ruido hace en las reuniones suele ser también el más caótico, con cincuenta excepciones y cambios de forma cada cierto tiempo.

Para el primer proyecto conviene algo estable, incluso aburrido: una tarea que se hace igual desde hace un año y que nadie planea cambiar. Un robot así entra rápido en producción y muestra el retorno pronto. Eso te da la confianza interna que vas a necesitar cuando toque abordar los procesos difíciles. Empezar por el proceso equivocado figura entre los errores comunes al implementar RPA.

Medir cómo se hace hoy

Si empiezas el proyecto sin registrar cuánto tarda el proceso a mano y cada cuánto se ejecuta, cuando el robot esté funcionando no podrás demostrar que la inversión se justificó. Un "ahora es más rápido" no convence a quien tiene que aprobar el presupuesto del próximo año.

Necesitas pocos datos: cuántas horas a la semana se le dedican y cuántas veces al mes se ejecuta. Si hay errores humanos que obligan a reprocesar, anota también con qué frecuencia ocurren. Con eso el retorno se calcula casi solo, y el próximo proyecto se puede justificar en una reunión de diez minutos en vez de tener que defender su presupuesto desde cero. Cómo se traducen esas horas en dinero lo explicamos en cuánto cuesta automatizar un proceso.

Confirmar que el proceso esté estable

A veces lo mejor es esperar, aunque el problema sea real. Pasa cuando el proceso todavía cambia de forma cada dos o tres semanas porque el negocio está ajustando cómo lo hace. Si construyes un robot sobre algo que no se ha estabilizado, vas a tener que reconfigurarlo una y otra vez, y ese mantenimiento termina comiéndose el ahorro.

Hay una prueba sencilla para saber si un proceso está listo: intenta escribir sus pasos exactos, con sus excepciones, en una sola página. Si en cada línea aparece un "depende", todavía no lo está. En ese caso, documéntalo, déjalo funcionar así un par de meses y automatízalo cuando deje de cambiar.

Decidir si RPA es la herramienta correcta antes de cotizar

No todo proceso repetitivo necesita un robot RPA. Si el sistema ya tiene una API, una integración directa suele resolver el problema. Muchos traspasos de datos también se pueden automatizar sin código con n8n. Para leer información y decidir con criterio, rinde mejor un agente de IA. Esas alternativas casi siempre cuestan menos y piden menos mantenimiento que un robot tradicional.

RPA sigue siendo lo más confiable si el sistema no tiene API, la interfaz es estable y el proceso se repite miles de veces de forma idéntica. Revisamos cada caso con más detalle en el artículo sobre cuándo no conviene automatizar un proceso.

Esta conversación hay que tenerla de entrada, antes de firmar. Si un proveedor te cotiza un robot sin preguntar si el sistema tiene API, probablemente te está ofreciendo la herramienta que domina sin haber evaluado si es la que tu proceso necesita. Ampliamos la comparación en RPA vs desarrollo a medida.

Elegir proveedor y revisar la propuesta

Con el proceso elegido y medido, ahora sí tiene sentido buscar quién lo construya. Más allá del precio y el portafolio, hay dos señales que anticipan cómo va a envejecer el robot. Un buen proveedor insiste en documentar las excepciones antes de escribir una línea de código, aunque eso encarezca la primera cotización. También te muestra cómo maneja las fallas del robot, porque en algún momento va a fallar.

En los robots que construimos con Rocketbot, cada paso crítico tiene control de errores. Si algo se rompe, el robot registra en un log qué estaba haciendo, guarda una captura de pantalla del momento exacto y avisa a un responsable en lugar de quedarse detenido en silencio. Quien recibe el aviso sabe en dos minutos qué pasó.

En una demo no se distingue un robot con control de errores de uno sin él. El segundo puede llevar detenido desde el jueves sin que nadie lo note, hasta que contabilidad pregunta por qué no se ingresaron las facturas. Los demás criterios para elegir proveedor los detallamos en el artículo sobre cómo elegir un partner de RPA en LatAm.

Asignar un responsable antes de la entrega

Un robot en producción necesita que alguien confirme periódicamente que se ejecutó, lea el reporte de ejecución y avise si algo se ve raro. Para ese rol no hace falta un perfil técnico ni contratar a nadie. Basta con una persona de operaciones que sepa leer un reporte y a quién escribir si hay un problema.

Como gerente, te toca nombrar a esa persona antes de la entrega. Si nadie tiene asignado ese rol, alguien lo va a tener que improvisar el día del primer error.

Resumen de los pasos

1. Elige el proceso.
2. Mide cómo se hace hoy.
3. Confirma que esté estable.
4. Decide si RPA es la herramienta correcta.
5. Elige quién lo va a construir.
6. Deja asignado quién lo va a cuidar.

Los tres primeros pasos los haces tú, sin proveedor, y son los que más influyen en el resultado del proyecto.

Preguntas frecuentes

Lecturas relacionadas

• Cuánto cuesta automatizar un proceso
• Errores comunes al implementar RPA
• Cómo elegir un partner de RPA en LatAm