Skip to main content
Agenda una reunión
Robotipy
Tutoriales

Cómo automatizar los reportes que hoy haces en Excel

Guía práctica para automatizar con RPA los reportes de Excel: qué parte del proceso atacar primero, cómo funciona en la práctica y cuándo no vale la pena.

En casi todos los proyectos que arrancamos, hay un momento en la reunión de relevamiento donde el cliente comparte su pantalla y aparece lo mismo: un Excel con pestañas que se llaman "Final", "Final_v2", "Final_USE THIS ONE". El reporte más importante del área, producido a mano, cada semana, desde hace tres años.

No lo menciono como crítica. Lo menciono porque ese Excel específico es, en muchos casos, el proceso más fácil de automatizar y el que más rápido muestra retorno. Y sin embargo la mayoría de las empresas lo deja para después, porque "funciona".

Funciona hasta que la persona que lo hace se va de vacaciones.

Qué parte del proceso se puede automatizar

Un reporte de Excel típico tiene tres momentos diferenciados:

  • Extracción de datos desde los sistemas fuente (SAP, una base de datos, un portal web, otro Excel).
  • Consolidación: copiar, pegar, calcular, ajustar formato, filtrar según la lógica de cada área.
  • Distribución: adjuntar, escribir el correo, enviar a la lista de siempre, guardar en la carpeta compartida.

Un robot RPA puede hacer los tres. Trabaja sobre la interfaz de los sistemas igual que un operador humano: abre sesiones, navega pantallas, extrae los datos. No necesita API. Si el sistema tiene pantalla, el robot lo puede operar.

La parte que más varía entre proyectos es la consolidación. Cuando la lógica de transformación es simple (filtros, sumas, formatos), el robot la maneja directamente. Cuando es compleja (cruce de múltiples fuentes con reglas de negocio no triviales), usamos un script Python embebido en el flujo, que hace el trabajo pesado antes de escribir el Excel final.

El resultado siempre llega al mismo lugar: el archivo armado, enviado, a la hora que definas, sin que nadie tenga que acordarse de hacerlo.

Cómo funciona en la práctica

El caso que más me gusta contar últimamente es el de un cliente con tres hoteles. Cada día, alguien en cada propiedad tenía que generar el reporte de censo: cruzar el estado de las habitaciones con lo que registraba el sistema de housekeeping y producir un consolidado para la dirección. Una hora por hotel, todos los días. Tres horas en total, distribuidas entre personas que también tenían que estar atendiendo huéspedes.

El problema real no era solo el tiempo. Era que el reporte a veces no se hacía. Cuando la recepción estaba ocupada, el censo pasaba a segundo plano. Y sin ese reporte, la dirección tomaba decisiones sobre disponibilidad con datos del día anterior.

El robot hace ahora el mismo cruce en un minuto. Los tres hoteles, el mismo proceso, todos los días a la misma hora, sin depender de si la recepción está libre o no.

Una aclaración sobre el número: un minuto es el tiempo de ejecución en ese proyecto específico, con esas fuentes y ese volumen de habitaciones. No lo uso como benchmark general porque cada reporte es distinto. Lo que sí se mantiene en todos los casos es que el robot no tiene días ocupados.

Cuándo no vale la pena automatizarlo

Acá me suelen preguntar si recomiendo siempre automatizar. No.

Si el reporte cambia de estructura cada mes porque el área todavía no definió qué quiere medir, el robot va a romperse con el mismo ritmo con que cambia el reporte. Antes de automatizar hay que estabilizar. Eso a veces toma meses.

Si la fuente de datos es caótica (distintos formatos según quién carga, campos que a veces están y a veces no), el primer problema es de calidad del dato, no de automatización. El robot va a amplificar el caos, no resolverlo.

Y si el reporte se genera una vez por trimestre y demanda dos horas, el retorno de un proyecto de automatización puede tardar tanto que no se justifica. Hay cosas que se hacen a mano por razones completamente válidas.

El candidato ideal para el primer bot es el que combina tres condiciones: frecuencia alta (diario o semanal), estructura estable desde hace al menos seis meses, y fuentes de datos predecibles. Si las tres se dan, el retorno aparece en semanas.

Qué herramienta usamos y por qué

Construimos la mayoría de nuestras soluciones de reportes sobre Rocketbot. La razón es simple: es la herramienta que, a nuestro criterio, mejor combina las 3B. Es buena, es barata y es fácil de operar sin ser desarrollador. Para el tipo de cliente con el que trabajamos, esa última parte importa tanto como las otras dos.

La capa de monitoreo que ponemos encima es nuestra, desarrollada por Robotipy. Cuando el robot falla a las 6 AM un martes, esa capa registra cada ejecución, el estado, los errores con el screenshot del momento exacto del fallo, y permite al cliente reiniciar o escalar sin depender de que yo esté disponible. Puedes ver cómo funciona en Robotipy Monitor.

Para los clientes que operan sus propios robots, eso significa que a las 7 AM del martes ya saben qué falló y pueden resolverlo solos.

Antes de hablar con nosotros

El indicio más simple: si hay alguien en tu equipo que es el único que sabe hacer ese reporte, ese proceso es candidato. Cuando esa persona se va de vacaciones y nadie más puede cubrirla, ya tienes el business case.

Preguntas frecuentes

¿El robot puede trabajar con cualquier versión de Excel?+
Sí. Rocketbot manipula archivos .xlsx y .xls directamente mediante bibliotecas de Python, sin necesidad de tener Excel instalado en el servidor de ejecución. Eso evita problemas de licencias y hace el robot más estable ante actualizaciones de Office.
¿Qué pasa si el sistema fuente cambia la pantalla o el formato del exportable?+
Eso genera una excepción que queda registrada y notifica por correo o por Monitor antes de que alguien note que el reporte no llegó. No es un fallo silencioso. El mantenimiento correctivo en esos casos es parte del servicio cuando trabajamos en modalidad de soporte continuo; si el cliente opera el robot propio, documentamos cada punto frágil antes de la entrega para que sepan qué ajustar.
¿Cuánto tarda implementar este tipo de bot?+
Para un proceso con una o dos fuentes y lógica de consolidación directa, entre dos y cuatro semanas con pruebas sobre datos reales incluidas. Si hay múltiples fuentes o validaciones complejas, puede extenderse a seis u ocho. El tiempo más variable no es el desarrollo: es el acceso a los sistemas y la definición de las reglas de negocio por parte del cliente.
¿El robot puede correr en la nube o solo on-premise?+
Ambas opciones funcionan. La elección depende de dónde viven los sistemas fuente y de las políticas de seguridad. Para sistemas SAP on-premise, lo más común es ejecutar el robot en un servidor dentro de la red del cliente. Para fuentes web o en la nube, la ejecución en instancia cloud es más limpia.

El próximo paso

Si quieres saber si tu proceso de reportes tiene potencial, podemos hacer un diagnóstico en una llamada de 45 minutos. Sin compromiso y sin necesidad de preparar nada: alcanza con que me muestres el Excel y me cuentes de dónde vienen los datos. Si prefieres empezar por los números, revisa cómo calculamos el ROI antes de arrancar un proyecto.

Danilo Toro
Danilo Toro
Fundador de Robotipy
Danilo es un desarrollador y un emprendedor. Cuenta con más de 7 años de experiencia en automatización de procesos y desarrollo de software.

¿Tu reporte de Excel es candidato a automatizar?

Muéstranos el archivo y de dónde vienen los datos. En una llamada de 45 minutos te decimos si conviene y estimamos el retorno.