La diferencia entre un Go Live controlado y una crisis operacional en la puesta en marcha está en la planificación de la transición. Cada implementación de ERP, CRM, SIS o sistema crítico dentro de un ecosistema académico tiene un momento decisivo: el Go Live. Sin embargo, existe la creencia común de que el éxito depende sólo de que el software funcione bien. La realidad demuestra otra cosa.
En proyectos complejos, el software ya fue probado semanas antes. Lo que define el éxito de la puesta en marcha es la capacidad de organizar y coordinar todas las actividades para pasar de la operación actual a un nuevo modelo en un periodo muy reducido de tiempo, asegurando la continuidad de los servicios académicos y administrativos.
Ese proceso se llama Cutover, y mi objetivo al abordarlo siempre es que la institución siga funcionando normalmente, minimizando riesgos para alumnos, docentes, académicos, personal y autoridades. En mi recorrido liderando transformaciones digitales, entiendo el Cutover como una estrategia de preparación que mueve a todo el ecosistema educativo, mucho más allá de un simple cronograma técnico.
El error más frecuente
Es habitual encontrar proyectos donde el Cutover se comienza a armar pocas semanas antes del Go Live, o se levantan únicamente actividades técnicas. Cuando esto ocurre, aparecen responsables poco claros, dependencias no identificadas y una coordinación basada solo en el riesgo técnico.
Según mi experiencia, el Cutover debe comenzar a prepararse varios meses antes de la salida a producción, en paralelo de las actividades de proyectos y evolucionar juntos.
Nos ocurrió en un proyecto al que fuimos convocados para fortalecer la puesta en marcha. El equipo nos comentó con total confianza: «El Cutover ya está listo, solo necesitamos que nos ayuden a hacer seguimiento.» Al abrir el plan, entendimos el problema: era un excelente cronograma técnico, pero la operación y las personas prácticamente no existían.
Comenzamos a hacer preguntas que nadie había hecho y, en pocas sesiones, incorporamos los frentes funcionales y organizacionales que faltaban. El resultado fue un Cutover realmente integral, preparado no solo para “encender” un sistema, sino para que la organización pudiera operar con éxito desde el primer día.
Una metodología de Cutover construida sobre seis dimensiones
A lo largo de mi experiencia en transformaciones digitales, he aplicado una metodología basada en seis dimensiones fundamentales:
Un buen Go Live comienza mucho antes: Errores a evitar
1. Reducir el soporte a solo disponibilizar una “ticketera”
En mi experiencia, el soporte debe diseñarse como una estrategia integral, con equipos en terreno, un centro de coordinación y salas de resolución (war rooms). La ticketera es solo una herramienta más; el éxito depende de una coordinación efectiva durante los primeros días de operación.
2. Delegar el control absoluto de incidencias al implementador
Atribuir todas las incidencias al implementador, cuando muchas dependen de distintas áreas y proveedores del ecosistema tecnológico, es otro error. La institución debe gobernar el modelo de soporte, manteniendo visibilidad. El éxito del Go Live depende de una coordinación integral que asegure la continuidad operacional.
En un proyecto preguntamos algo muy simple: «¿Quién tiene la foto completa de las incidencias?» La respuesta fue: el implementador. El problema era que nadie más veía lo que estaba ocurriendo. Los proveedores trabajaban por separado, las incidencias llegaban al equipo equivocado y la dirección no tenía información para decidir.
Nos llamaron para ordenar la operación. Lo primero fue devolver la gobernanza a la institución, centralizando la gestión de incidencias e integrando a todos los equipos. En pocos días, dejaron de existir múltiples versiones de la realidad y todos comenzaron a trabajar con la misma información.
3. Capacitar solo en el uso del sistema y no capacitar en el modelo de soporte
Si los usuarios no conocen los canales oficiales de soporte, los tiempos de respuesta y los mecanismos de escalamiento, el proceso recurrirá a la informalidad (correos y llamadas), aumentando el riesgo para la continuidad operacional.
Porque al final del día, los usuarios no evalúan si el software se instaló correctamente. Evalúan si pudieron seguir trabajando al día siguiente. Y esa diferencia la hace un buen Cutover.
En un proyecto participamos en una mesa donde otra consultora presentó un completo plan de capacitación para la nueva tecnología. Parecía impecable… hasta que hicimos una pregunta: ¿Qué harán las personas el primer día del Go Live?
El silencio dijo mucho. Nadie había preparado a los usuarios para saber a quién acudir, cómo registrar una incidencia, qué hacer si el sistema no respondía, qué procesos podrían iniciar o dónde encontrar ayuda rápida. La capacitación enseñaba el sistema, pero no cómo operar el cambio. Ahí incorporamos ese frente y preparamos a la organización para el día en que realmente comenzaba la transformación.
