Podríamos decir que el factor principal para asegurar el éxito de nuestra implantación de un sistema ERP como Odoo y posteriormente, su funcionamiento, viene determinado por el partner de Odoo que hayamos escogido. En muchos proyectos que revisamos, el problema no es Odoo, sino la falta de visibilidad que tiene el cliente sobre qué se está haciendo, cómo se desarrolla y qué calidad tiene el trabajo entregado. Por ese motivo, nos gusta explicar que es lo que debemos esperar en nuestra instancia y sobretodo que pueda ser entendido para perfiles que no sean técnicos.
El Odoo es del cliente
Lo primero que debemos de realizar es pedir acceso a nuestro código, aunque no lo entendamos, si no es que lo tenemos ya. Esto es sinónimo de transparencia y da mucha seguridad, pues podemos pedir auditorias externas si lo consideramos necesario, por ejemplo. Si nuestro partner se opone a ello, es la primera señal que debe hacer saltar las alarmas. No existe ningún argumento de peso para no poder tener acceso al código de tu propio sistema.
Esto aplica tanto si Odoo está alojado en servidores del partner, en Odoo.sh o en cualquier otro proveedor cloud. El alojamiento no elimina el derecho del cliente a acceder al código desarrollado para él.
Entendiendo mínimamente como funciona un proyecto Odoo
Sin necesidad de entrar en detalles técnicos, es conveniente conocer de forma superficial cómo se organiza un proyecto de Odoo. Esto nos permitirá evaluar de primera mano cómo trabaja nuestro partner y qué señales debemos observar.
Vamos a explicar qué aspectos conviene revisar.
¿Cómo se realiza la gestión del código?
Primeramente, debemos saber que el código se sube a repositorios donde se almacenan y se gestionan. Existen muchas plataformas que permiten la gestión de repositorios en la nube y acceder a ellos. Los más usados son Gitlab y Github, seguramente os sonará. Por debajo, la gestión es común y se realiza con un sistema de control de versiones llamado git, que mediante comandos nos permite realizar acciones sobre las subidas y gestión del código. Volviendo a lo que nos interesa, nosotros, como clientes, debemos de tener acceso a nuestro código accediendo a una de estas plataformas.
Accediendo a nuestros proyectos
Una vez dentro del repositorio, podremos ver la estructura de carpetas del proyecto. Normalmente encontraremos:
- Configuración del entorno de Odoo
- Código de módulos utilizados
- Lista de módulos estándar utilizados
- Scripts de despliegue
En este punto ya no habría que profundizar más, pero si es razonable pedirle a nuestro partner que nos explique cómo está estructurado y porqué.
Veamos algunas de las señales positivas que nos podemos encontrar al revisar el proyecto:
- Estructura clara de módulos
- Historial de cambios continuo (podemos pedir que nos enseñen como ver los commits, en general, deberían ser relativamente pequeños, no cambios de 2.000 líneas de golpe)
- Los cambios deben tener mensajes entendibles
- Documentación mínima del proyecto
Por el otro lado, debemos estar alertas a cosas como:
- Todo el código se sube de golpe
- Sin historial de cambios
- Se accede a repositorios a los que no tenemos acceso
- No existe ningún tipo de documentación
Gestión del proyecto
Otro aspecto que debemos conocer y nuestro partner nos debe explicar con total claridad es, cómo se va a gestionar nuestro Odoo, aunque sea a alto nivel:
- Donde están alojados los servidores
- Que sistemas de seguridad se utilizan
- Como se realizan las copias de seguridad
- Como se monitoriza el sistema
No es necesario entender todos los detalles, pero sí percibir que existe una gestión ordenada y profesional.
Origen y calidad del código
En Odoo, el código puede provenir de distintas fuentes:
- Módulos core de Odoo
- Módulos de Odoo Enterprise (bajo licencia)
- Módulos de la OCA
- Módulos de terceros
- Desarrollos a medida
Nuestro consejo es priorizar siempre módulos core de Odoo o módulos de la OCA, ya que provienen de entornos abiertos, auditados y mantenidos por comunidades técnicas amplias. En el caso de disponer de licencia Enterprise de Odoo, los módulos acostumbran a ser buenos también, aunque en general existen alternativas Community si nos interesa. En ese caso, también es importante que nuestros partners sean capaces de explicarnoslo.
Respecto a módulos de terceros, solo deberían utilizarse cuando el proveedor sea conocido, el código esté accesible y exista un mantenimiento claro. En caso contrario, suelen generar problemas graves de mantenibilidad.
El desarrollo de módulos propios es totalmente válido cuando no existe una alternativa abierta, siempre que esté bien documentado, explicado al cliente y correctamente testeado.
Vigilar la implantación de CI/CD
Adicionalmente, podemos preguntar a nuestro partner si tiene implantados sistemas de calidad para el desarrollo y despliegue de código, que se conocen como CI/CD.
Estos sistemas permiten:
- Ejecutar tests automáticamente
- Detectar errores antes de llegar a producción
- Garantizar despliegues reproducibles
Esto se traduce en menos errores en producción, menos caídas tras actualizaciones y menos dependencia en una persona concreta.
La OCA como sello de calidad
Es muy común que muchos partners sean colaboradores de la OCA. Esto se debe a que en la gran mayoría de ocasiones para completar nuestro Odoo y hacerlo funcional debemos hacer uso de los módulos desarrollados por la misma. La OCA es una comunidad abierta y colaborativa, donde el código es valorado por toda la comunidad y por ende, se asegura una gran calidad. No es una garantía absoluta, pero sí una muy buena señal. Un partner activo en la OCA suele trabajar alineado con buenas prácticas y estándares técnicos reconocidos. Si queremos indagar en ello, podemos revisar una conversación entre Harald de Sygel y Enric, nuestro CEO, en los que hablan de como verlo. También podemos ver las estadísticas que comparte la comunidad sobre partners más colaborativos.
Conclusión
Estos consejos no buscan desconfiar del partner, sino aportar visibilidad y control al cliente. Un buen partner no teme la transparencia y entiende que el código y el proyecto son del cliente.
Aunque aplicar estas recomendaciones requiere un pequeño esfuerzo inicial, se compensa ampliamente al evitar dependencias excesivas, proyectos opacos o sistemas difíciles de mantener. Al final, el Odoo es vuestro y debéis poder tener acceso a vuestro código de forma sencilla.