El Go-Live suele sentirse como el momento en que termina una implementación de Odoo. Para los equipos que empiezan a trabajar con el sistema en condiciones reales, sin embargo, muchas veces es justamente cuando aparecen nuevas dudas, incidencias y situaciones que no habían surgido durante las pruebas.
Esto puede generar una preocupación legítima: ¿qué pasa con los pendientes de la implementación cuando la atención pasa a una Mesa de Soporte? ¿El consultor deja de acompañar al cliente? ¿Todo lo que aparezca después del Go-Live se considera soporte?
La respuesta requiere distinguir algo fundamental: no todas las solicitudes que aparecen después del Go-Live son del mismo tipo ni deben ser atendidas por el mismo equipo. Durante un periodo de estabilización pueden coexistir el cierre de pendientes de implementación y la atención de incidencias propias de la operación.
El error habitual: entender el traspaso a soporte como el cierre definitivo
Una de las razones por las que este momento puede generar incertidumbre es la experiencia previa de algunas empresas con otros sistemas.
En ciertos casos, el traspaso a una Mesa de Soporte ocurre cuando la implementación ya está completamente estable y no quedan pendientes. Por eso, cuando se plantea este cambio después de una salida en vivo, puede interpretarse como el cierre definitivo del proyecto.
Pero una salida en vivo cambia las condiciones de uso.
Durante las pruebas, los escenarios suelen estar más controlados. Después del Go-Live, el sistema comienza a utilizarse bajo las condiciones reales de la operación: más usuarios trabajando simultáneamente, mayores volúmenes de información, procesos que ocurren en paralelo y situaciones que simplemente no aparecieron durante las pruebas.
Por eso, es esperable que exista un periodo de estabilización.
El traspaso a la Mesa de Soporte no significa necesariamente que desaparezca el acompañamiento del consultor. Los pendientes que corresponden al alcance original de la implementación pueden continuar bajo su gestión, mientras la Mesa de Soporte comienza a atender las incidencias operativas relacionadas con funcionalidades que ya fueron configuradas, validadas y entregadas.
Ambas líneas de trabajo pueden coexistir.
Antes de derivar un requerimiento, hay que saber qué tipo de caso es
La forma más simple de evitar confusiones es no tratar todas las solicitudes como si fueran iguales.
Una solicitud posterior al Go-Live debería analizarse, al menos, desde estas categorías:
1. Pendiente de implementación
Es un punto que forma parte del alcance acordado originalmente y que todavía debe ser gestionado como parte de la implementación.
2. Incidencia operativa
Es un problema relacionado con una funcionalidad que ya fue configurada, validada y entregada, pero que presenta una situación que requiere atención durante la operación.
3. Nuevo requerimiento
Es una necesidad que no corresponde a los compromisos originales de la implementación y que plantea un cambio, una nueva necesidad o una mejora adicional.
Esta distinción importa porque evita enviar solicitudes al equipo equivocado y permite mantener trazabilidad sobre lo que realmente está pendiente.
También ayuda a diferenciar tres situaciones que pueden parecer similares para un usuario: una necesidad real del proceso, una mejora que sería deseable incorporar y un supuesto sobre cómo debería funcionar el sistema que todavía necesita ser validado.
Un usuario clave puede ordenar gran parte de esta transición
Una de las decisiones prácticas más importantes es definir un SPOC (Single Point of Contact) o usuario clave que centralice las solicitudes.
Esto no significa que una sola persona tenga que resolver todos los problemas. Su función es ayudar a ordenar la entrada de requerimientos y entregar la información necesaria para analizar cada caso.
Centralizar las solicitudes permite:
Evitar reportes duplicados.
Mantener la trazabilidad de cada caso.
Entregar contexto antes de derivar una solicitud.
Ayudar a clasificar correctamente el requerimiento.
Facilitar la priorización según impacto y urgencia.
Evitar la saturación innecesaria de la Mesa de Soporte.
Para que este esquema funcione, la empresa debería tener claridad sobre cuatro elementos antes o durante la salida en vivo:
Procesos críticos: qué partes de la operación no pueden detenerse y requieren atención prioritaria.
Usuarios y áreas involucradas: quiénes necesitarán mayor acompañamiento durante la estabilización.
Responsable interno y usuarios clave: quién centralizará las solicitudes y ayudará a entregar contexto.
Criterios de éxito: cómo se determinará que la operación está funcionando de acuerdo con lo esperado.
Estas preguntas también ayudan a detectar expectativas difíciles de cumplir antes de que se conviertan en un problema.
La transición funciona mejor cuando las responsabilidades quedan explícitas
Un buen traspaso no consiste simplemente en cambiar de canal de atención. Requiere revisar qué queda pendiente y quién es responsable de cada punto.
Una forma práctica de hacerlo es realizar una reunión específica de entrega con el cliente y revisar:
Qué se implementó.
Qué compromisos del alcance original siguen pendientes.
Quién queda responsable de cada pendiente.
Qué situaciones corresponden a incidencias operativas.
Qué solicitudes deberían considerarse nuevos requerimientos.
Qué canal corresponde utilizar en cada caso.
Quién será el usuario clave que centralizará las solicitudes.
En un caso gestionado por KONOS, se optó precisamente por un esquema de acompañamiento paralelo durante esta transición. Los compromisos pendientes de la implementación fueron identificados y quedaron bajo la responsabilidad del consultor correspondiente, mientras la Mesa de Soporte comenzó a atender las incidencias propias de la operación.
Como apoyo adicional para familiarizar al cliente con el servicio, se habilitaron dos horas gratuitas de Mesa de Soporte durante un mes.
Lo relevante de este ejemplo no es la cantidad de horas, sino el criterio detrás de la transición: ordenar las responsabilidades sin interpretar el paso a soporte como abandono de la implementación.
Además, no fue necesario realizar una integración ni un desarrollo nuevo. El problema se abordó mediante ajustes de proceso y configuración de responsabilidades.
¿Cuándo hay que revisar el caso con mayor profundidad?
No todas las situaciones posteriores al Go-Live pueden resolverse de la misma manera.
Hay que revisar con mayor profundidad un caso cuando no está claro si se trata de un pendiente de implementación, una incidencia sobre una funcionalidad previamente validada o un nuevo requerimiento.
También es importante revisar la prioridad. Una solicitud puede ser relevante para un usuario, pero no necesariamente tener el mismo impacto para la operación que otra que afecta un proceso crítico.
Por eso, no corresponde asumir que todas las solicitudes tendrán una solución inmediata ni que todo lo que aparezca después del Go-Live estará incluido automáticamente en el soporte.
Tampoco corresponde entender la Mesa de Soporte como un espacio para incorporar nuevas funcionalidades, cambios de alcance o desarrollos adicionales sin una evaluación previa.
Los tiempos y las alternativas de solución dependerán del impacto, la prioridad, la complejidad y de los antecedentes disponibles para analizar cada caso.
El Go-Live no debería ser un cambio brusco de acompañamiento
La salida en vivo marca un cambio importante: el sistema comienza a formar parte de la operación cotidiana. Eso hace natural que aparezcan dudas, ajustes e incidencias que no pudieron identificarse durante las pruebas.
El desafío está en evitar que esa realidad se convierta en confusión.
La clave es separar claramente la continuidad de la implementación de la atención de la operación, definir quién se hace cargo de cada tipo de solicitud y establecer un responsable interno que ayude a centralizar la información.
Cuando estas responsabilidades están claras, el equipo puede distinguir qué debe continuar con el consultor, qué corresponde a la Mesa de Soporte y qué constituye una nueva necesidad que debe evaluarse.
Para una empresa que está por pasar por esta etapa, una buena práctica es compartir esta definición con el equipo antes del Go-Live. No solo con quienes administran Odoo, sino también con los usuarios que estarán enfrentando la operación real.
La estabilización no consiste en asumir que no habrá problemas. Consiste en saber qué hacer cuando aparezcan y quién debe hacerse cargo de cada uno.
Si estás atravesando una salida en vivo, comparte este artículo con tu equipo y utilícenlo como punto de partida para conversar sobre responsabilidades, pendientes y canales de atención.
Preguntas frecuentes
¿El paso a la Mesa de Soporte significa que termina la implementación?
No necesariamente. Los pendientes que forman parte del alcance original pueden continuar bajo la gestión del consultor de implementación mientras la Mesa de Soporte atiende incidencias de la operación.
¿Todo requerimiento que aparece después del Go-Live corresponde a soporte?
No. Primero hay que determinar si se trata de un pendiente de implementación, una incidencia sobre una funcionalidad previamente configurada y validada, o un nuevo requerimiento.
¿Por qué es importante tener un único usuario clave o SPOC?
Porque permite centralizar solicitudes, evitar duplicidades, entregar contexto para analizar cada caso y mantener la trazabilidad y priorización de los requerimientos.
Nota de precisión
Este artículo describe un criterio de organización del acompañamiento posterior al Go-Live a partir de un caso interno de KONOS. No implica que todas las implementaciones tengan exactamente las mismas condiciones. Los tiempos, prioridades, alternativas de solución y alcance de atención dependerán de cada caso y de los antecedentes disponibles.