¿Qué pasa realmente en las primeras 48 horas tras arrancar tu nuevo ERP?

El momento donde se decide si el proyecto fue un éxito

A las 7 de la mañana del primer día de operación con el nuevo sistema, el área de compras descubre que las órdenes generadas durante el fin de semana de migración no coinciden con los saldos de los proveedores. El almacén reporta que tres referencias críticas aparecen con existencia cero, aunque hay producto físico en el anaquel. El equipo de facturación no puede cerrar los documentos pendientes porque los folios fiscales no se sincronizaron correctamente con el nuevo módulo. Para una empresa que factura en promedio entre 800 mil y 1.5 millones de pesos diarios, cada hora de bloqueo en facturación representa ingresos retenidos que no se pueden reconocer hasta resolver la discrepancia.

Esto no es un escenario hipotético. Es lo que documentan de forma consistente los reportes de hipercuidado de implementaciones ERP en distintas industrias: las primeras 48 horas después del arranque concentran la mayor densidad de incidentes críticos de todo el proyecto, precisamente cuando la dirección espera ver resultados y no fricciones.

La pregunta que de verdad importa no es si habrá incidentes. Los habrá. La pregunta es si la empresa cuenta con un protocolo de hipercuidado que convierta esos incidentes en correcciones controladas, o si los va a enfrentar de manera improvisada mientras el negocio sigue operando.

Los tres frentes que colapsan primero

Migración de datos: el ambiente de pruebas nunca replica con exactitud la complejidad de la base de datos real. Catálogos de clientes con direcciones incompletas, listas de precios con vigencias cruzadas, saldos de inventario capturados en momentos distintos del corte. Todo esto convive sin problema en el sistema anterior porque los usuarios han aprendido a rodear sus inconsistencias durante años. El nuevo ERP no tiene ese conocimiento implícito y expone cada discrepancia el primer día que alguien intenta facturar, surtir o reportar contra esos datos.

Esta exposición no ocurre de forma pareja. Los catálogos con mayor rotación son justamente los que primero generan fricción, porque son los que se tocan en las primeras horas de operación. Un error de migración en una referencia de baja rotación puede pasar inadvertido semanas. El mismo error en una referencia de alta rotación se convierte en un ticket urgente antes del mediodía del primer día.

Carga cognitiva de los usuarios: un usuario puede completar perfectamente un flujo de captura durante una sesión de capacitación tranquila, con tiempo y sin clientes esperando. Esa misma persona, el primer lunes de operación real, enfrenta llamadas, pedidos urgentes y la presión de no atrasar a su equipo mientras intenta recordar en qué pantalla se valida un descuento o se libera una orden retenida. La literatura de gestión de cambio en proyectos ERP documenta de forma reiterada que la mayoría de los tickets reportados en las primeras horas no son fallas del software, sino fricción de usuario frente a un flujo que cambió.

Brecha de confianza en reportes: durante las primeras 48 horas es común que los dashboards y reportes del nuevo ERP muestren cifras que no coinciden con lo que los gerentes de área saben de memoria sobre su negocio. Esto ocurre porque los datos abarcan ventanas de tiempo mixtas y porque algunos cálculos automáticos, costos promedio, existencias disponibles, márgenes, aún no se han recalculado sobre la base completa de transacciones. El riesgo no es solo el error puntual: es que los gerentes pierden confianza en el sistema desde el primer día y empiezan a llevar registros paralelos en hojas de cálculo, reintroduciendo exactamente el problema que el ERP debía resolver.

Por qué el hipercuidado no es soporte técnico genérico

Las implementaciones que logran estabilizarse rápido no dependen de la suerte. Dependen de tener, desde el día cero, un punto único de coordinación donde cada incidente se clasifica por área de negocio (finanzas, almacén, ventas, producción), se asigna a un responsable concreto y se revisa en una reunión diaria breve y disciplinada.

En Oasys hemos observado que esta estructura, organizada por área de negocio y no como una bandeja genérica de tickets, es la que permite distinguir entre un problema de capacitación que se resuelve con una sesión de refuerzo y un defecto real de configuración que requiere intervención técnica. Sin esta clasificación, los equipos terminan tratando ambos tipos de problema igual, y eso multiplica el tiempo de resolución.

Tan importante como abrir el centro de comando es saber cuándo cerrarlo. Definir desde el inicio qué indicadores deben estabilizarse para declarar el cierre, volumen de tickets, transacciones bloqueadas, exactitud de reportes, evita tanto el cierre prematuro como el hipercuidado indefinido que normaliza la inestabilidad.

El error más costoso: tratar el go-live como el final del proyecto

Una de las causas más documentadas detrás de las implementaciones que no cumplen sus objetivos es precisamente esta: la organización celebra el arranque como si fuera la meta y reduce la atención justo cuando la operación real empieza a poner a prueba cada decisión de diseño tomada durante el proyecto. Entre el 55% y el 75% de los proyectos de ERP no cumple sus objetivos originales, y buena parte de ese riesgo se decide en estas primeras 48 horas.

La transición ordenada de responsabilidad, del equipo de proyecto al equipo operativo, debe ser gradual y explícita, no un corte abrupto el día después del go-live. En las primeras semanas, el equipo de implementación debe seguir liderando la resolución de incidentes mientras el equipo operativo observa y aprende. Solo después de varias semanas de estabilidad demostrada conviene que los roles se inviertan.

Las primeras 48 horas no son el final del proyecto de implementación. Son el inicio de la fase donde el ERP se pone a prueba contra la realidad de la operación diaria, con clientes, proveedores y empleados que no van a esperar a que el sistema termine de estabilizarse. Por eso en Oasys diseñamos cada implementación con un protocolo de hipercuidado documentado antes del arranque: catálogo de incidentes por área, usuarios clave disponibles en piso, revisión diaria estructurada y criterios claros de salida hacia la operación normal.

Preguntas frecuentes

¿Cuánto debe durar el periodo de hipercuidado después de un go-live de ERP?

La duración varía según la complejidad del proyecto, pero la práctica documentada en la industria ubica el hipercuidado típico entre dos y ocho semanas, con las primeras 48 a 72 horas como la ventana de mayor concentración de incidentes críticos.

¿Cómo distinguimos un error de capacitación de un defecto real del sistema en las primeras horas?

Clasificando cada ticket por tipo y por flujo de trabajo afectado desde el primer reporte. Si el mismo paso genera tickets repetidos en distintos usuarios, suele ser un problema de diseño o configuración. Si los tickets varían entre usuarios sobre el mismo paso, suele ser fricción de adopción.

¿El proveedor del ERP debe estar presente físicamente durante las primeras 48 horas?

Es la práctica recomendada para implementaciones de alto impacto operativo. La presencia en sitio o la disponibilidad inmediata por canal directo reduce significativamente el tiempo entre la detección de un incidente y su resolución.

¿Cuándo conviene declarar terminada la fase de hipercuidado?

Cuando los incidentes críticos disminuyen a niveles de soporte normal, las transacciones se procesan sin errores de reconciliación recurrentes y los usuarios dejan de depender de apoyo en piso para completar sus flujos diarios. Cerrar antes de cumplir estos criterios deja a la operación expuesta sin el respaldo que aún necesita.