Implementación de Soluciones Tecnológicas en Producción

En 16 años de implementaciones en entornos empresariales de alta criticidad, las causas más frecuentes son: integraciones con sistemas externos que no fueron probadas end-to-end en un entorno similar a producción, migración de datos con registros inconsistentes que solo aparecen al ejecutar con el volumen real, dependencias de terceros (proveedores, bancos, sistemas de gobierno) que no estaban disponibles para las pruebas, y equipos que declararon el sistema 'listo' sin haber probado los escenarios de falla y recuperación. La forma de evitarlos es un proceso de homologación riguroso antes del go-live — no una lista de chequeo, sino pruebas reales con datos representativos en un entorno que replique producción.

Hay escenarios donde aplazar el go-live es la decisión correcta aunque sea costosa: cuando quedan defectos críticos sin resolver que afectan flujos de negocio principales, cuando el plan de rollback no ha sido probado y no existe la certeza de que funciona, cuando los equipos de soporte del cliente no están listos para operar el sistema, o cuando la ventana de tiempo disponible para el despliegue no es suficiente para ejecutar el plan con los pasos de validación necesarios. Un go-live fallido en el sector bancario o de transporte puede costar más en horas de crisis, reputación y reprocesos que cualquier penalidad contractual por aplazar. Nuestra posición siempre prioriza la estabilidad del negocio del cliente.

Un plan de rollback efectivo especifica: el punto exacto de no retorno después del cual la reversión ya no es viable, los pasos técnicos secuenciales para revertir cada componente, los responsables y permisos necesarios para ejecutar cada paso, el tiempo estimado de ejecución de la reversión (debe probarse antes del go-live), los criterios objetivos que activan el rollback, y el estado esperado de los datos después de la reversión. Un plan de rollback que dice 'revertir a la versión anterior' sin estos detalles no es un plan de rollback: es una intención.

El equipo interno necesita estar preparado en tres dimensiones: operativa (conocen cómo operar el nuevo sistema, cómo responder a los escenarios de error más probables y a quién escalar), de soporte (saben dónde están los logs, cómo reiniciar componentes si es necesario, y qué monitorear en los primeros días), y de negocio (los usuarios finales han sido capacitados y hay un proceso para reportar problemas). Si alguna de estas tres dimensiones no está cubierta el día del go-live, el riesgo operativo se traslada al equipo de implementación indefinidamente. Por eso incluimos la preparación del equipo cliente como un hito explícito del plan de implementación.

En el sector bancario y de transporte, las ventanas de mantenimiento pueden ser de pocas horas en horarios de madrugada. Para trabajar dentro de estas restricciones, el proceso de implementación se divide en dos categorías: preparación (todo lo que puede hacerse antes de la ventana sin afectar la operación) y activación (solo los pasos que deben ejecutarse durante la ventana). Un ensayo completo en el entorno de preproducción, cronometrado, determina si la implementación cabe en la ventana disponible. Si no cabe, rediseñamos el plan de despliegue — no pedimos más tiempo del que el cliente puede dar.