Salir en vivo con Odoo 18 sin soporte es estrenar ERP y apagar la luz
La tesis es incómoda, pero necesaria: el go-live no demuestra que una implementación terminó. Demuestra que la empresa está lista para descubrir sus fricciones en tiempo real.
Hay implementaciones que llegan al viernes de salida en vivo con alivio y cansancio. Se prendió el sistema, los usuarios entraron y alguien declara victoria. El problema es que Odoo 18 no se implementa para una ceremonia de arranque. Se implementa para que compras, ventas, inventario, contabilidad, servicio y gerencia operen mejor.
Por eso el go-live es una línea de salida, no una meta. En ese momento aparecen preguntas que ningún ambiente de pruebas reproduce perfecto: quién aprueba, cómo se corrige una factura rechazada o qué se hace con el usuario que sigue llevando “su Excel por si acaso”. Sin soporte cercano, esas preguntas se convierten en ruido y reprocesos.
La primera semana no es soporte técnico: es gobierno operativo
Un soporte maduro de salida en vivo no consiste en “estar disponible por si falla algo”. La primera semana necesita una mesa con responsables, prioridades, escalamiento y lectura diaria. Odoo tiene aplicaciones como Proyecto, donde las tareas se organizan por etapas y estados, y Helpdesk, pensado para solicitudes y trazabilidad. La herramienta existe; lo que suele faltar es la disciplina para usarla como control del go-live.
Si cada área reporta problemas por WhatsApp, correos sueltos o pasillo, el proyecto pierde memoria. Nadie sabe si el incidente ya fue resuelto, si era configuración, duda de usuario o una regla no definida. No todo ticket es una falla: a veces es capacitación, decisión pendiente o resistencia del proceso viejo.
El peor enemigo del go-live es el usuario que vuelve al Excel
La señal temprana más peligrosa no siempre es técnica: el usuario que usa Odoo, pero mantiene su archivo paralelo. Esa doble operación mata la adopción. La empresa cree que cambió de sistema, pero abrió una sucursal clandestina del proceso anterior.
La solución no es regañar al usuario. Es entender por qué no confía en el flujo. Puede ser que el permiso no esté bien configurado, que el reporte no responda o que la capacitación se haya quedado en “dónde hacer clic”. La documentación de Odoo sobre usuarios y permisos recuerda que los accesos se asignan por aplicaciones y roles; en salida en vivo eso es estabilidad.
- Si el usuario no ve su trabajo completo en Odoo, buscará otro lugar para completarlo.
- Si los permisos son demasiado amplios, se pierde control; si son demasiado estrechos, se bloquea la operación.
- Si los reportes no responden preguntas reales, la gerencia seguirá pidiendo archivos externos.
- Si las dudas no quedan registradas, la misma pregunta se resuelve cinco veces.
La adopción no se decreta. Se observa. Y se corrige con evidencia.
En Colombia el soporte post go-live también es fiscal
Implementar Odoo 18 en Colombia tiene un componente poco poético: localización, impuestos, diarios, secuencias y facturación electrónica. La documentación oficial de Odoo lista la localización colombiana y el módulo de facturación electrónica con DIAN. El soporte post go-live no puede limitarse a “la pantalla no carga”. Tiene que incluir criterio contable y operativo.
Una mesa de estabilización seria debe revisar los primeros documentos reales: cotizaciones, facturas, pagos, movimientos de inventario, diarios y cierres iniciales. No para buscar culpables, sino para encontrar desviaciones antes de que se vuelvan costumbre.
En Colombia, una configuración mal entendida puede terminar en rechazo documental, reproceso contable o reportes que la gerencia ya no cree. Si solo hay soporte técnico, se arreglan síntomas. Si hay gobierno operativo, se estabiliza el negocio.
Un buen go-live tiene tablero, no solo reuniones
Las reuniones ayudan, pero no reemplazan un tablero claro. Odoo permite trabajar tareas por etapas y estados; ese concepto debería inspirar la estabilización completa. Cada caso necesita prioridad, dueño, impacto y cierre verificable. El criterio no debe ser “quién grita más duro”, sino qué bloquea operación, qué afecta cumplimiento y qué crea riesgo de dato.
Un tablero sano distingue cuatro tipos de trabajo. Primero, incidentes reales: algo que debía funcionar y no funciona. Segundo, ajustes: decisiones de configuración que se refinan al ver operación real. Tercero, formación: usuarios que necesitan reaprender el proceso. Cuarto, mejoras futuras: deseos válidos, pero no urgentes para estabilizar.
Sin esa clasificación, el go-live se vuelve una bolsa infinita de pendientes. Y cuando todo parece urgente, nada se gobierna.
Cómo se ve una salida en vivo adulta
Una salida en vivo madura no promete ausencia de problemas. Promete capacidad de respuesta. En un proyecto de Odoo 18, pediría mínimo esto:
- Mesa de estabilización: canal único, responsables claros y horario de atención definido.
- Clasificación de casos: incidente, ajuste, capacitación o mejora futura.
- Revisión diaria de operación: documentos reales, errores frecuentes y usuarios bloqueados.
- Control fiscal: facturación, secuencias, diarios y primeros cierres revisados con criterio.
- Cierre con evidencia: cada caso se cierra solo cuando el usuario o el proceso lo confirma.
Esto suena menos épico que decir “salimos en vivo”. Pero es lo que separa una implementación profesional de una mudanza apresurada al caos digital.
Conclusión: el go-live no es una foto, es una vigilancia
Salir en vivo con Odoo 18 es importante. Pero celebrarlo sin soporte cercano es como inaugurar una planta y dejar a todos solos frente al tablero eléctrico. Si algo falla, nadie sabe si debe operar, escalar o detenerse.
El éxito no es prender Odoo. Es lograr que la empresa confíe cuando el trabajo real presiona.
En Colombia, con operación, facturación, impuestos y decisiones gerenciales encima, esa confianza se construye después del go-live: caso por caso, cierre por cierre, usuario por usuario.
Fuentes consultadas: Odoo Documentation - Colombia, Odoo Documentation - Task stages and statuses, Odoo Documentation - Helpdesk, Odoo Documentation - Users.