Primeros 90 Días Después del Go-Live: Guía para Operaciones

El nuevo sistema salió en vivo el lunes. Para el miércoles, tres personas ya habían preguntado si podían “volver a como era antes.” Para el viernes, alguien había armado una hoja de cálculo que replica lo que el sistema debería hacer. Bienvenido a los primeros 90 días después del go-live.

Este período es donde la mayoría de los proyectos de transformación digital se ganan o se pierden. No porque el software esté mal, sino porque la transición entre “sistema en producción” y “sistema que realmente nos funciona” toma más tiempo y duele más de lo que cualquiera anticipó. Según Deloitte, el 75% de los ejecutivos dice que medir el impacto de la transformación digital sigue siendo su principal desafío. Para los gerentes de operaciones, ese desafío se vive en tiempo real en el piso operativo.

Esto es lo que puede esperar, qué vigilar y cómo llevar a su equipo hasta el otro lado.

Por Qué Todo Go-Live Tiene una Caída de Productividad

Todo cambio de sistema trae una baja temporal de productividad. Esto no es señal de fracaso. Es una fase predecible que ocurre porque su equipo está haciendo el mismo trabajo de antes, pero a través de flujos de trabajo desconocidos.

Piense en lo que cambia el día uno. Personas que procesaban una tarea en tres clics ahora necesitan siete. La memoria muscular construida durante años se vuelve inútil. Los atajos y el conocimiento informal (“pregúntale a María, ella sabe dónde va ese archivo”) dejan de funcionar.

La caída ocurre porque la competencia se reinicia. Su equipo no empeoró. Perdió la eficiencia que venía de años de práctica en el sistema anterior. Investigaciones de Prosci sobre adopción de ERP muestran consistentemente que las organizaciones subestiman esta brecha entre el estado actual y el estado futuro de los procesos, y que el soporte necesario para cerrarla suele quedarse corto.

Esta caída es temporal si se gestiona. Si no se gestiona, los parches temporales se vuelven permanentes.

Cómo Se Ve Realmente el Primer Mes

El primer mes es modo de supervivencia. Su equipo está aprendiendo una interfaz nueva mientras sigue siendo responsable de la misma producción. Esto es lo que probablemente verá:

• Los tiempos de procesamiento se duplican o triplican. Tareas que tomaban 5 minutos ahora toman 15. Esto es normal.
• La tasa de errores se dispara. Las personas ingresan datos en campos equivocados, saltan pasos o malinterpretan los nuevos flujos.
• Las preguntas inundan su bandeja. “¿Cómo hago…?” y “¿dónde quedó…?” se vuelven constantes.
• La frustración llega al máximo en la segunda semana. La paciencia inicial se agota y la realidad de la fricción diaria se instala.

El mayor error que cometen los gerentes de operaciones en esta fase es intentar arreglar todo al mismo tiempo. No se puede. Enfóquese en tres cosas:

1. Lleve un registro estructurado de problemas. No un tablero de quejas. Un registro que separe lo que está roto, lo que es solo desconocido y lo que es una brecha real del sistema. Esta distinción importa después.
2. Proteja a sus usuarios clave. Identifique a las 2 o 3 personas de cada equipo que se están adaptando más rápido. Evite que se conviertan en la mesa de ayuda de todos. Necesitan tiempo para construir su propia competencia antes de ayudar a otros.
3. Alinee expectativas con la dirección. Si no lo hizo antes del go-live, hágalo ahora. Comparta números concretos: “El volumen de procesamiento bajó 30% esta semana. Esperamos recuperar el 80% para la cuarta semana.” Las garantías vagas invitan al micromanagement.

Días 31 a 60: Cuando los Parches Echan Raíces

El segundo mes es el más peligroso. El dolor agudo del primer mes pasa, pero algo más sutil ocurre. Su equipo empieza a encontrar “soluciones creativas” para las partes del sistema que se sienten lentas o incómodas.

Alguien arma una hoja de cálculo de seguimiento. Otra persona empieza a enviar aprobaciones por correo en lugar de usar el flujo del sistema. Un supervisor lleva un cuaderno de papel con excepciones porque “el sistema no maneja eso bien.” Según datos recopilados por ElectroIQ, el 80% de los empleados usa aplicaciones no aprobadas sin permiso de TI. En el contexto post-go-live, esto no es mala fe. Es su equipo resolviendo problemas de la forma más rápida que conoce.

Estos parches son oro diagnóstico. Cada uno revela algo específico:

• Una hoja de cálculo rastreando embarques significa que las funciones de visibilidad del sistema no cubren las necesidades del equipo, o que el equipo no fue capacitado en ellas.
• Aprobaciones manuales por correo significan que el motor de workflow está mal configurado o es demasiado rígido para las excepciones del mundo real.
• Cuadernos de papel significan que el sistema no maneja casos atípicos que ocurren a diario.

No prohíba los parches. Mapéelos. Cada uno apunta a una brecha de capacitación, un problema de configuración o una limitación real. La solución es diferente para cada caso, y tratarlos igual desperdicia tiempo y confianza.

¿Cómo Saber Si Son Dolores de Crecimiento o un Problema Real?

Esta es la pregunta que todo gerente de operaciones enfrenta alrededor del segundo mes. El equipo sigue más lento. Los parches existen. La dirección quiere saber cuándo se van a “normalizar” las cosas. ¿Cómo distinguir un sistema que necesita más tiempo de uno que genuinamente no funciona?

Señales de dolores de crecimiento (temporales):

• La velocidad de procesamiento mejora semana a semana, aunque sea despacio
• Las mismas preguntas dejan de aparecer, reemplazadas por nuevas y más avanzadas
• Los parches se reducen en alcance (de hojas que reemplazan el sistema completo a pequeños complementos)
• Sus usuarios clave ya prefieren el nuevo sistema para ciertas tareas

Señales de problema real (estructural):

• Un flujo de trabajo central requiere más pasos que el sistema anterior, sin ningún beneficio compensatorio
• El mismo error se repite porque la interfaz induce a la acción equivocada
• Los datos del sistema no coinciden con la realidad, y nadie confía en los números
• Los parches crecen en lugar de reducirse, y aparecen nuevos constantemente
• Sus mejores personas (no solo las resistentes) están frustradas

Si está viendo señales estructurales, escale con datos concretos. “El flujo de estado de embarque requiere 11 clics donde el sistema anterior necesitaba 4, y no hemos encontrado forma de reducirlo” es accionable. “Al equipo no le gusta el nuevo sistema” no lo es.

Qué Medir en los Primeros 90 Días

La mayoría de las organizaciones mide las cosas equivocadas después del go-live. Miden uptime del sistema, cantidad de logins y tasas de finalización de capacitación. Eso dice si las personas pueden acceder al sistema. No dice si el sistema está funcionando para sus operaciones.

Mida esto:

• Tiempo de completar tareas. Elija 5 procesos clave y cronométrelos semanalmente. Quiere ver una tendencia descendente, aunque los números absolutos sigan por encima de la línea base anterior.
• Tasa de error y retrabajo. Registre cuántas transacciones necesitan corrección. Esta tasa debería alcanzar el pico en las semanas 2 y 3 y descender de forma sostenida después.
• Conteo de parches. Cuente literalmente los sistemas paralelos, hojas de cálculo laterales y procesos manuales que su equipo mantiene. Este número debería reducirse para el tercer mes.
• Preguntas por semana por tema. Si las mismas preguntas siguen apareciendo, sus materiales de capacitación necesitan actualización. Si surgen preguntas nuevas, su equipo está avanzando hacia un uso más avanzado.
• Tiempo de resolución de excepciones. Cuando algo sale mal (y va a pasar), ¿cuánto toma corregirlo? Esto muestra si sus canales de soporte funcionan.

Grafique semanalmente. Comparta con su equipo y con la dirección. La tendencia importa más que cualquier punto aislado. Un equipo 40% más lento en la semana uno pero mejorando 5% por semana va por buen camino. Un equipo 20% más lento en la semana uno sin mejora, no.

Cinco Cosas Que el Gerente de Operaciones Puede Controlar Después del Go-Live

Usted no controla el software. No controla la velocidad de respuesta del proveedor. No controla si la dirección le dará más tiempo. Pero sí controla estas cinco cosas, y tienen un impacto desproporcionado en que su equipo salga adelante.

1. La reunión diaria rápida (solo los primeros 30 días). Diez minutos por la mañana donde el equipo levanta bloqueos. No es una reunión de estatus. No es una sesión de quejas. “¿Qué te está impidiendo hacer tu trabajo hoy?” Breve y al punto. Suspéndala después del primer mes, a menos que el equipo pida mantenerla.

2. La regla de “una cosa nueva.” Cada semana, enseñe al equipo una capacidad del sistema que les facilite la vida. Sin volcado de capacitación. Una cosa. “Así se crea un filtro guardado para no tener que buscar cada vez.” Las pequeñas victorias generan impulso.

3. La revisión de parches. Cada dos semanas, revise los parches activos con su equipo. Para cada uno, decida: ¿es brecha de capacitación (se resuelve con coaching), problema de configuración (se abre un ticket) o limitación real (se acepta o se escala)? Luego actúe.

4. El canal de feedback hacia TI. Su equipo necesita una vía clara y rápida para reportar problemas que no sea “mandar correo al director de TI.” Un canal compartido, un formulario simple, cualquier cosa que registre el problema y dé acuse de recibo en 24 horas. El silencio genera frustración más rápido que los bugs.

5. La retrospectiva de los 90 días. Al final de los 90 días, haga una revisión estructurada. ¿Qué es mejor que el sistema anterior? ¿Qué es peor? ¿Qué parches siguen existiendo y por qué? Esto le da la munición para una conversación basada en datos con la dirección sobre qué viene después.

Los Errores Que Convierten Dolores de Crecimiento en Problemas Permanentes

Algunos gerentes de operaciones prolongan involuntariamente el período de dolor. Esté atento a estos patrones:

• Mantener el sistema anterior “por si acaso.” Los sistemas paralelos se sienten seguros, pero le dan a su equipo una razón para no comprometerse con el nuevo. Si todos saben que pueden volver atrás, nadie cambia de verdad. Defina una fecha de corte y cúmplala.
• Esperar que el proveedor resuelva todo. Sus solicitudes de configuración tomarán semanas. Sus solicitudes de funcionalidad pueden tomar meses. Ajuste sus procesos para funcionar dentro del sistema tal como está hoy, y mejore de forma incremental después.
• Ignorar a los resistentes silenciosos. Las quejas en voz alta reciben atención. Pero las personas que silenciosamente dejaron de usar el sistema y volvieron a sus métodos anteriores son el mayor riesgo. Revise datos de uso, no solo encuestas de satisfacción.
• Comunicar de más la visión, de menos lo práctico. Su equipo no necesita otro correo sobre “los beneficios a largo plazo de la transformación digital.” Necesita saber cómo procesar una devolución en el nuevo sistema sin perder 20 minutos.

Preguntas Frecuentes

¿Cuánto tarda en recuperarse la productividad total después del go-live de un sistema?

La mayoría de los equipos de operaciones alcanza el 80% de la productividad pre-go-live en 4 a 6 semanas y la productividad total en 3 a 4 meses. Implementaciones complejas con múltiples módulos integrados pueden tomar 6 meses o más. El plazo depende en gran medida de la calidad de la capacitación, la complejidad de los flujos de trabajo y qué tan activamente la gerencia apoya la transición.

¿Cuál es la caída normal de productividad al implementar un nuevo software?

Una caída del 20% al 40% en las dos primeras semanas es típica. Los equipos que procesan transacciones, gestionan flujos de trabajo o manejan documentos sienten el impacto con mayor intensidad. La caída debería reducirse cada semana. Si la productividad no ha mejorado de forma medible para la cuarta semana, investigue si el problema es capacitación, configuración o un fallo fundamental en el flujo de trabajo.

¿Conviene mantener el sistema anterior en paralelo después del go-live?

La operación en paralelo debe limitarse a un período definido, generalmente 2 a 4 semanas, y solo para procesos críticos donde la precisión de los datos necesita verificarse. Mantener el paralelo indefinidamente es una de las razones más comunes por las que los equipos no adoptan el nuevo sistema. Cuando el sistema anterior sigue disponible, los usuarios resistentes vuelven a él por defecto y la adopción se estanca.

¿Cuándo escalar problemas post-go-live a la dirección?

Escale cuando tenga datos específicos que muestren un problema estructural, no solo una curva de aprendizaje. “La tarea X toma tres veces más tiempo y no encontramos solución de configuración tras dos semanas trabajando con TI” vale la escalación. La frustración genérica no. Lleve el registro de problemas, los datos de tendencia y un pedido específico.

¿Cuáles son los mayores riesgos en los primeros 90 días después del go-live?

Los tres mayores riesgos son el crecimiento descontrolado de parches (equipos construyendo procesos paralelos permanentes), el desenganche silencioso (usuarios que dejan de usar el sistema sin decir nada) y la pérdida de paciencia de la dirección (ejecutivos que esperan ROI inmediato y retiran el soporte demasiado pronto). Los tres se pueden gestionar con comunicación estructurada y medición consistente.

Cómo Tier2 Keel y Tier2 Cargo Apoyan el Período Post-Go-Live

Los desafíos descritos arriba son los que hemos visto a lo largo de cientos de implementaciones en más de 11 años construyendo y desplegando sistemas empresariales. Los productos Tier2 están diseñados pensando en el período post-go-live.

Tanto Tier2 Keel como Tier2 Cargo incluyen flujos de trabajo guiados que reducen el problema del “conteo de clics.” En lugar de exigir que los usuarios naveguen menús complejos, el sistema los guía paso a paso por cada proceso. Esto acorta la curva de aprendizaje para usuarios nuevos y reduce la tasa de errores que alimenta la frustración en el primer mes.

Los dashboards integrados ofrecen a los gerentes de operaciones las métricas de visibilidad discutidas anteriormente, como tiempo de completar tareas y tasas de excepción, sin necesidad de construir reportes personalizados. Cuando su equipo puede ver su propio progreso mejorando semana a semana, la motivación para atravesar la caída aumenta.

Para equipos que migran desde flujos basados en hojas de cálculo, Pluto permite hacer preguntas en lenguaje natural, tendiendo un puente entre lo que las personas sabían encontrar en sus hojas y lo que el sistema rastrea por ellos.

Agende una demostración para ver cómo funciona en la práctica.

Qué Pasa Después del Día 90

La marca de los 90 días no es una línea de llegada. Es el punto donde debería tener suficientes datos para tomar decisiones claras sobre qué funciona y qué necesita cambiar. Los gerentes de operaciones que mejor navegan este período son los que lo tratan como un proyecto con sus propios hitos, no como algo que debería “calmarse solo.”

Su equipo pasó la parte más difícil. El siguiente paso es convertir lo que aprendió en esos 90 días en las mejoras que hacen que la inversión se pague.