Dos proyectos, dos ritmos muy distintos
En el mismo trimestre, Aleph Server implementó dos proyectos de automatización con Apache Airflow para clientes de segmento similar. Uno llegó a producción estable en dos semanas. El otro tardó tres meses. La diferencia no fue la complejidad técnica del DAG, ni el tamaño del equipo, ni el presupuesto del proyecto.
Fue el estado en que llegó el proceso al momento de empezar a construir.
El proyecto que tardó dos semanas
El primer proyecto era la automatización de un reporte operacional semanal que se generaba manualmente cada lunes. El proceso llegó documentado: las fuentes de datos estaban identificadas con sus credenciales y formatos de salida, las transformaciones necesarias estaban descritas con los casos borde incluidos, el formato del reporte final estaba definido y ejemplificado, y los destinatarios y el canal de distribución estaban acordados antes de la primera reunión técnica.
Con esa documentación, el trabajo de implementación fue traducir un proceso ya entendido a un DAG de Apache Airflow con manejo de errores y monitoreo. No hubo decisiones de diseño abiertas que resolver durante el desarrollo. No hubo descubrimientos de casos borde que obligaran a replantear etapas del pipeline. El primer DAG en producción funcionó con ajustes menores. A los diez días estaba estable.
El proyecto que tardó tres meses
El segundo proyecto era la integración de datos entre dos sistemas de gestión que debían sincronizarse diariamente. El proceso existía: alguien hacía esa sincronización de forma manual cada día con una exportación CSV de un sistema y una carga manual en el otro. Pero no estaba documentado.
Las reglas de transformación de datos estaban en la cabeza del único administrador que había hecho esa tarea durante dos años. Los casos borde —registros con valores nulos en campos que el sistema destino requería como obligatorios, registros duplicados que se gestionaban con criterios no escritos, fechas en formatos distintos según el origen del registro— no estaban mapeados en ningún documento.
Cada semana de desarrollo aparecía una excepción nueva que el proceso manual había manejado con criterio humano implícito y que el DAG no contemplaba. Cada excepción requería una reunión para entender la regla de negocio detrás, ajustar el código, volver a probar. El DAG en sí no era complejo. El trabajo era descubrir y documentar el proceso real, que resultó ser considerablemente más complicado que el proceso aparente.
A los tres meses el DAG estaba estable. Pero también había un documento que describía el proceso completo con todos sus casos borde, que no existía antes del proyecto y que tiene valor independiente de la automatización.
El aprendizaje que cambió el proceso de Aleph Server
La conclusión de esos dos proyectos no fue que uno fue mejor que el otro. Fue que el tiempo invertido en el segundo proyecto antes del desarrollo habría reducido el tiempo total de forma significativa.
A partir de ese aprendizaje, Aleph Server incorporó una etapa de diagnóstico de proceso como parte obligatoria del alcance de cualquier proyecto de automatización. Esa etapa no es una reunión de kickoff: es un trabajo estructurado de documentación del proceso actual, que incluye entrevistas con las personas que ejecutan las tareas, mapeo de casos borde, identificación de reglas de negocio implícitas, y validación con el equipo del cliente antes de empezar a construir.
El tiempo que toma esa etapa varía según la complejidad del proceso. En casos simples, puede ser medio día. En procesos con años de historia y múltiples personas involucradas, puede ser una semana. En todos los casos, ese tiempo se recupera durante el desarrollo.
La pregunta que ahora hacemos antes de empezar
Antes de comprometer cualquier estimación de tiempo para un proyecto de automatización, Aleph Server hace una pregunta al cliente: ¿puede describir el proceso paso a paso, incluyendo qué pasa cuando algo sale mal, sin consultar a nadie más?
Si la respuesta es sí y el cliente puede hacerlo, el proyecto arranca con una base sólida. Si la respuesta es no o requiere convocar a otras personas para completarla, hay trabajo de documentación previo que hacer. Eso no es un problema del proyecto: es una condición del proceso que conviene resolver antes de automatizar.
Un proceso mal documentado no mejora al automatizarlo. Se vuelve más rápido y más frecuente en cometer el mismo error. La automatización amplifica lo que hay, en ambas direcciones.
