Un proyecto Odoo que no se desarrolla como estaba previsto es una situación más frecuente de lo que parece, y no tiene nada de excepcional en el despliegue de un software de gestión. Ha invertido tiempo y recursos, y el resultado no corresponde a lo esperado. Antes de proponer nada, hay que reconocer esta situación por lo que es: un proyecto rara vez fracasa por culpa de una sola parte, y no conocemos el contexto completo — plazos, presupuesto, comunicación, restricciones de ambos lados — en el que se tomaron las decisiones. Este documento describe cómo retomar un proyecto Odoo en dificultad de forma serena, sin oportunismo.
No procede buscar un responsable antes de actuar. Un despliegue de Odoo implica a varias partes — el proveedor, la empresa cliente, a veces terceros como un proveedor de alojamiento u otro editor de software conectado — y cada una influye en el resultado final. Lo que importa en esta etapa no es reconstruir el historial de decisiones, sino comprender el estado real del sistema hoy y decidir con conocimiento de causa el seguimiento a darle.
Las situaciones típicas
Varios escenarios se repiten regularmente en las empresas que buscan retomar un proyecto Odoo existente.
- El proveedor anterior es ilocalizable o ha cesado su actividad. Ya no responde a las solicitudes, ya no hace seguimiento, a veces ya no existe la empresa.
- El proyecto se detuvo a medio camino. Parte de la configuración existe, pero el despliegue nunca se finalizó.
- Se ha rebasado el presupuesto sin puesta en producción. Se han invertido recursos, pero la herramienta todavía no es utilizable a diario.
- La instancia está en producción, pero es inutilizable. Los equipos eluden la herramienta, vuelven a Excel o a sistemas antiguos, por falta de una configuración adaptada a sus procesos reales.
- La contabilidad producida es errónea. Desviaciones, cierres de IVA incoherentes, conciliaciones bancarias que nunca se hacen.
- Desarrollos no documentados. Código específico funciona en producción sin que nadie sepa exactamente qué hace ni por qué se escribió así.
- Nadie, internamente, sabe cómo funciona la instancia. La dependencia de una sola persona — a menudo el propio proveedor — se ha instalado sin que la empresa se dé cuenta.
La primera etapa: recuperar el control de sus accesos, su código y sus datos
Antes de cualquier diagnóstico o decisión sobre el seguimiento, hay que asegurarse de que la empresa controla realmente sus propios activos. Es una etapa a tratar con prioridad, a menudo incluso antes de buscar un nuevo proveedor, porque un acceso perdido puede volverse muy difícil de recuperar una vez roto definitivamente el vínculo con el proveedor anterior.
- El acceso administrador a la instancia Odoo, no solo una cuenta de usuario.
- El acceso al alojamiento sobre el que funciona la instancia, o al menos el conocimiento de quién la aloja y bajo qué contrato.
- La propiedad del nombre de dominio asociado, si lo hay, y de su gestión DNS.
- El código de los desarrollos específicos, en un repositorio que la empresa controla, no solo en la máquina del proveedor.
- Las copias de seguridad existentes y una exportación de los datos actualizados, independientemente de lo que ocurra después.
Mientras estos elementos no estén asegurados del lado de la empresa, cualquier conversación sobre el seguimiento del proyecto sigue siendo frágil: no se decide con serenidad el futuro de un sistema sobre el que no se tiene el control. En los casos más tensos, donde el contacto con el proveedor anterior está roto, esta etapa puede requerir solicitar directamente al proveedor de alojamiento, verificar las condiciones contractuales de propiedad de los datos, o hacer valer un derecho de recuperación previsto en el contrato inicial. Es una gestión a veces incómoda, pero condiciona todo lo demás.
El estado de situación técnico y contable
Una vez asegurados los accesos, la siguiente etapa es un diagnóstico completo, próximo en su método a una auditoría de instancia Odoo clásica, pero orientado hacia una decisión de retoma más que hacia una simple fotografía. Trata sobre la configuración contable y de IVA, la configuración de nómina si existe, los módulos activos, los desarrollos específicos y su nivel de documentación, la calidad de los datos, los derechos de acceso, y el estado de las copias de seguridad. La dimensión contable se examina con el mismo rigor que la dimensión técnica: una instancia que funciona sin error visible puede, a pesar de todo, producir cifras erróneas, y a menudo es precisamente ese punto el que ha motivado la búsqueda de un nuevo acompañamiento.
Este diagnóstico responde a preguntas muy concretas. ¿Los asientos contables generados hasta ahora son aprovechables, o hay que volver sobre un período para corregirlos? ¿El cierre de IVA transmitido a las autoridades corresponde realmente a la actividad de la empresa? ¿Los desarrollos específicos en producción plantean un riesgo inmediato, o pueden esperar a una etapa posterior? Las respuestas a estas preguntas determinan la urgencia de cada acción, y evitan tratar como prioritario un punto secundario mientras un problema más grave sigue ignorado.
Decidir: reparar, reconstruir, o volver al estándar
El estado de situación desemboca en una elección entre tres opciones, y esa elección debe basarse en criterios concretos más que en una impresión general de la situación.
- Reparar lo existente tiene sentido cuando la base es globalmente sana: la configuración corresponde a las necesidades reales, los desarrollos específicos son de calidad correcta, y los problemas constatados son localizados e identificables.
- Partir de una base limpia se justifica cuando la configuración se aleja demasiado de los procesos reales de la empresa, cuando los desarrollos son demasiado frágiles o demasiado numerosos para sanearlos uno por uno, o cuando la calidad de los datos está demasiado degradada para corregirse de forma fiable.
- Volver la instancia al estándar de Odoo consiste en retirar las personalizaciones más arriesgadas y volver en la medida de lo posible a las funcionalidades nativas, en particular cuando los desarrollos específicos no están documentados y complican cada actualización de versión. A menudo es la vía más sostenible a medio plazo.
El criterio determinante no es la envergadura aparente de los daños, sino la sostenibilidad de cada opción en el tiempo: una reparación rápida que deja las mismas causas en su sitio no habrá hecho más que posponer el problema. Una instancia técnicamente inestable pero cuya configuración de negocio es pertinente no necesita reconstruirse; a la inversa, una instancia estable pero construida sobre procesos que ya no corresponden a la actividad real de la empresa seguirá siendo un lastre por muchas correcciones técnicas que se apliquen.
La puesta al día
Una vez elegida la opción, la puesta al día sigue las prioridades identificadas en el estado de situación: corrección de la configuración contable y de IVA en primer lugar, puesto que tiene un impacto directo e inmediato en las obligaciones legales de la empresa, luego saneamiento de los datos, luego retoma o reemplazo de los desarrollos más frágiles. Según las necesidades, esto puede movilizar nuestras páginas dedicadas a Odoo Contabilidad, a la nómina, o al desarrollo específico. Cuando la situación se asemeja más a un nuevo despliegue que a una corrección, se une a nuestra página implementación Odoo.
Documentación y transferencia de conocimiento
Una retoma de proyecto que se limita a corregir los síntomas reproduce la dependencia que llevó a la situación inicial. La documentación no es, por tanto, una etapa accesoria: cada decisión de configuración, cada desarrollo específico, cada regla de negocio configurada en Odoo debe quedar escrita en algún sitio de forma comprensible para una persona que no participó en el proyecto. Esta documentación no necesita ser exhaustiva en el sentido de un manual técnico completo: debe sobre todo responder a las preguntas que se haría una persona externa al descubrir la instancia — por qué existe este campo, para qué sirve esta automatización, qué regla de negocio justifica esta configuración y no otra.
Este trabajo se acompaña de una transferencia de conocimiento hacia sus equipos, para que el uso diario de la herramienta ya no dependa de una sola persona, interna o externa. Vea nuestra página formación Odoo para este acompañamiento, y soporte Odoo para el seguimiento posterior una vez la instancia puesta al día.
Evitar encontrarse en esta situación con el siguiente proveedor
Ciertas precauciones, planteadas desde el inicio de una nueva colaboración, reducen notablemente el riesgo de volver a vivir una situación similar:
- La reversibilidad: la posibilidad concreta de cambiar de proveedor sin partir de cero, prevista desde el inicio en lugar de negociada con urgencia.
- Los accesos: la empresa conserva en todo momento los accesos administrador a su instancia, a su alojamiento y a su nombre de dominio.
- La documentación: exigida como un entregable del proyecto, no como una opción dejada a la discreción del proveedor.
- La propiedad del código: los desarrollos específicos realizados para la empresa le pertenecen, en un repositorio que ella controla.
Estos cuatro puntos no garantizan que un proyecto se desarrolle sin contratiempos, pero garantizan que un contratiempo siga siendo reparable. Para situar esta gestión en el conjunto de nuestras prestaciones, vea Odoo ERP en Ginebra y Odoo en Ginebra. Si la duda recae más sobre el estado general de una instancia que sobre un proyecto claramente detenido, nuestra página auditoría de instancia Odoo puede ser el punto de partida más adecuado.