No todos los clientes llegan con un listado técnico de requerimientos. Algunos llegan con agotamiento. La solicitud real detrás de la reunión no es ‘necesito un servidor nuevo’ ni ‘quiero implementar automatización’. Es: ‘necesito que alguien se haga responsable de TI y que yo pueda dejar de pensar en esto’. Esa es una solicitud legítima. También es la más difícil de responder bien, porque la respuesta correcta casi nunca es la más rápida ni la más vistosa.
El diagnóstico que nadie quiere escuchar
Al revisar la situación de ese cliente, encontramos lo que encontramos con frecuencia en empresas medianas que llevan años operando en modo contingencia. Tres sistemas distintos que no se integran entre sí. Procesos manuales que dependen de que una persona específica esté disponible —en este caso, el proceso de consolidación semanal de datos operacionales dependía de que esa persona corriera manualmente tres exports desde sistemas distintos y los cruzara en Excel. Backups que ‘probablemente funcionan’ pero que nadie ha verificado en meses. Un servidor físico cuya última revisión formal nadie recuerda. Individualmente, ninguno de esos problemas era una emergencia en ese momento. En conjunto, representaban un riesgo acumulado que eventualmente iba a cobrarse tiempo, datos o continuidad operacional en el peor momento posible: un cierre de mes, un proceso de auditoría, o simplemente un lunes cualquiera.
Qué propusimos y qué descartamos
La respuesta más fácil habría sido proponer un proyecto de transformación amplio: migración a la nube, nuevos sistemas, automatización avanzada. Eso tiene más superficie de conversación y parece más ambicioso. No lo hicimos. Propusimos empezar por lo que tenía mayor impacto con el menor riesgo de disruption para el negocio. Primero: estabilizar y verificar los backups, porque sin eso cualquier otra intervención es frágil. Segundo: documentar los procesos críticos que dependían de una sola persona, porque esa dependencia es el riesgo más común y menos visible en empresas de ese tamaño. Tercero: establecer monitoreo básico de los sistemas críticos, para que el equipo supiera cuando algo fallaba antes de que los usuarios lo notaran. Tres semanas de trabajo enfocado. Sin slide decks. Sin promesas de transformación en doce meses.
La regla que aplicamos: no construir sobre lo inestable
En Aleph Server tenemos un principio que aplicamos antes de recomendar cualquier herramienta avanzada: el piso tiene que estar firme antes de construir encima. Un cliente que implementa Apache Airflow para orquestar pipelines de datos sobre procesos sin documentar y backups sin verificar no tiene una solución más robusta. Tiene una solución más compleja con las mismas fragilidades de base. Cuando algo falla —y algo siempre falla— el tiempo de resolución es mayor, la trazabilidad es peor, y la confianza en el sistema completo se deteriora más rápido. El orden de las intervenciones no es conservadurismo técnico. Es ingeniería básica. Y es también la diferencia entre un proyecto que entrega valor sostenido y uno que entrega entusiasmo inicial seguido de frustración.
Lo que se logró y cuándo tuvo sentido ir más lejos
Tres meses después del inicio del proyecto, ese cliente tenía visibilidad real de lo que ocurría en su infraestructura. Sus procesos críticos dejaron de depender de la disponibilidad de una persona específica. El equipo de operaciones dejó de recibir llamadas de emergencia fuera del horario laboral. Eso es lo que se comprometió y eso es lo que se entregó. Seis meses después de ese trabajo inicial, la conversación sobre automatización de procesos de negocio empezó a tener sentido real. No porque el cliente no lo hubiera querido antes, sino porque las condiciones para que esa automatización funcionara de forma confiable estaban creadas. Hoy ese cliente está en proceso de implementar orquestación con Apache Airflow para sus pipelines de datos operacionales. La implementación avanza sin fricciones porque la base está en orden.
Lo que esto implica para cómo trabajamos
Ese cliente lleva hoy más de un año trabajando con Aleph Server. La primera conversación fue sobre backups. La última fue sobre orquestación de pipelines operacionales con Apache Airflow. El orden de esas conversaciones no fue casualidad: fue la condición para que la segunda tuviera sentido.
