Este artículo describe la implementación de un proceso de automatización de reportes operacionales en una empresa mediana con operaciones en dos regiones. Es un caso representativo de la categoría de proyectos con mayor retorno en el menor tiempo: procesos repetitivos, con estructura estable, y con dependencia de personas específicas que lo convierte en un riesgo operacional sistemático.
El contexto del proyecto
La empresa genera cada lunes un reporte de actividad operacional consolidado que dirección utiliza para revisar el estado de las operaciones de la semana anterior. El proceso involucraba la extracción manual de datos desde tres sistemas internos, la normalización en una planilla, y la generación del reporte en el formato que dirección requería.
El tiempo total del proceso era de tres a cuatro horas semanales. Dependía completamente de la disponibilidad de una persona específica del equipo. En dos ocasiones durante el año previo al proyecto, esa persona no estuvo disponible el lunes y el reporte no salió. En ambos casos, la situación generó fricción operacional e incertidumbre en la revisión de dirección.
El diagnóstico: por qué este proceso era el candidato correcto
El proceso cumplía con todos los criterios que justifican automatización como primera iniciativa.
Alto impacto medible: tres a cuatro horas de trabajo manual por semana, dependencia de una persona, y consecuencias directas cuando fallaba.
Bajo esfuerzo relativo: estructura fija y repetitiva, fuentes de datos con APIs disponibles, formato de salida estable. Sin lógica condicional compleja ni excepciones difíciles de manejar.
Sin dependencias bloqueantes: los tres sistemas tenían interfaces de programación disponibles y documentadas. No había trabajo de ingeniería inversa ni integraciones frágiles.
La implementación técnica
Se implementó un DAG de Apache Airflow con cuatro tareas secuenciales.
Tarea 1 — Extracción: consulta a las APIs de los tres sistemas, con manejo de errores y reintento automático si una consulta falla. Si después de los reintentos la consulta sigue fallando, la tarea marca el DAG como fallido y notifica al equipo técnico.
Tarea 2 — Normalización y validación: transformación de los datos extraídos al formato unificado, verificación de integridad (que los valores estén dentro de rangos esperados), y marcado de registros con anomalías para revisión posterior.
Tarea 3 — Generación del reporte: construcción del reporte en el formato requerido por dirección. El template es configurable sin modificar el código del DAG.
Tarea 4 — Distribución: envío del reporte por correo a la lista de destinatarios configurada. La lista es modificable sin intervención técnica.
El DAG se ejecuta automáticamente cada lunes a las 6:00 AM. El reporte llega a dirección antes del inicio del horario laboral.
El sistema de alertas
Cualquier falla en cualquiera de las cuatro tareas genera una notificación automática al equipo técnico con el log del error y la tarea específica que falló. Esto permite que el equipo identifique y resuelva el problema en la fuente antes de que alguien note la ausencia del reporte.
En la práctica, en las semanas posteriores a la implementación hubo una falla en una de las fuentes de datos por un cambio de API. El sistema notificó al equipo técnico a las 6:03 AM. El problema estaba resuelto a las 7:15 AM. El reporte llegó a dirección a las 7:18 AM, antes del inicio del horario laboral.
Los resultados medibles
Tiempo de generación: de tres a cuatro horas manuales a dieciocho minutos de ejecución automatizada.
Disponibilidad: el proceso dejó de depender de la disponibilidad de una persona específica. Funciona aunque esa persona esté de vacaciones, en enfermedad, o haya dejado la empresa.
Visibilidad: el equipo técnico tiene registro completo de cada ejecución: cuándo empezó, cuánto tardó cada tarea, qué datos se extrajeron, y el log completo en caso de error.
Capacidad liberada: la persona que antes generaba el reporte a mano recuperó tres a cuatro horas semanales que se reasignaron a trabajo de análisis que antes no se hacía por falta de tiempo.
Lo que este caso ilustra para otros proyectos
La automatización más valiosa no siempre es la más compleja. Un proceso bien mapeado, con una herramienta adecuada y monitoreo activo desde el primer día, puede tener impacto operacional inmediato y medible en pocas semanas.
El criterio de selección importa más que la herramienta. Apache Airflow fue la elección correcta en este caso por la necesidad de monitoreo estructurado, reintentos automáticos y registro de ejecuciones. Para un proceso más simple, un script Python con cron habría sido suficiente.
El siguiente paso para ese cliente fue mapear qué otros procesos similares existían en la organización. La respuesta fue que había varios. Esa conversación tiene sentido ahora, con un ejemplo propio funcionando en producción como referencia.
