Debo adaptar Odoo a mi cliente, o mi cliente a Odoo?

Gustavo Orrillo
- 23/05/2022 - 4 min. de lectura

Es una pregunta que surge cuando empiezan los proyectos. Si el cliente o la empresa se debe adaptar a los procesos de Odoo, o hacer que Odoo se adapte a los procesos de la empresa. Odoo soporta los procesos empresariales en una forma básica. Permite ingresar pedidos de venta, facturarlos y remitirlos. Permite registrar ordenes de compra, registrar los ingresos. Tiene un punto de venta que es una pesadilla de mantener. También permite mover stock de un lado para otro y tiene un módulo de manufactura que soporta MRP.  Para muchas empresas pequeñas y medianas argentinas es suficiente.

En ese caso, el grado de customización es bajo. Muchas veces es necesario prestarle más atención al manejo de impuestos que otra cosa. Pero el trabajo de desarrollo es realmente escaso. Ahora, hay muchas empresas cuyo modelo de negocios no es precisamente el standard. Por ejemplo una firma financiera, donde necesitamos personalizar los productos financieros a la contabilidad de Odoo. Ahí vuelve la pregunta, debemos adaptar los procesos del cliente a Odoo? o adaptar Odoo a los procesos del cliente?

Odoo no es una fuente de best-practices en el mundo de los negocios

Años atras (décadas para ser maś exactos) vi muchas empresas implementar SAP porque en sus procesos ya tenía incorporada muchas best-practices de la industria en la que se trabajaba. No se puede decir lo mismo de Odoo. Principalmente porque SAP siempre fue una empresa de consultoría que hacía software. No se puede decir lo mismo de Odoo, que vende principalmente licencias y los servicios... corren por cuenta de sus partners.

Lo cierto es que Odoo no implementa ninguna best-practice. Es un buen software, de eso no hay ninguna duda. Y es un software que brinda los building-blocks para armar el flujo de trabajo de un negocio; pero no arma el negocio en si mismo. Esos building blocks se implementan principalmente en los módulos de ventas, contabilidad, compras y stock (fundamentales para entender como funciona Odoo). Con ellos, uno puede implementar el flujo de trabajo que necesita para su negocio. Odoo brinda workflows ya implementados, pero la verdad son muy elementales (pero, la verdad es que sea adapta a la mayoría de las empresas pequeñas y medianas argentinas).

Es por eso que, primero conozca los procesos de su empresa y busque implementarlos en Odoo. No busque hacer que su empresa se adapte a Odoo ya que pocas veces va a funcionar eso (es más, puede llegar a tener resultados calamitosos). Si los procesos de su empresa se ven reflejados en Odoo, buenísimo. Ahora, si no lo están... va a tener que afrontar un trabajo de personalización que puede llegar a ser o no importante.

Soy un consultor, debo adaptar Odoo a mi cliente o adaptar mi cliente a Odoo?

Es la pregunta que uno se realiza cuando empieza su trabajo como consultor, y creo que podemos resumirla en el siguiente cuadro:


Como ven hay dos ejes; el grado de customización requerida y el conocimiento del consultor. Veamos cada una de las opciones disponibles:

  • Proyectos simples de corta duración: son los primeros proyectos que uno debe buscar cuando empieza. Y gracias a la localización argentina, estan disponibles para los principiantes. Son proyectos de dos o tres meses que involucran la instalación de la localización argentina, un muy bajo grado de customización y la puesta en marcha del cliente. Mucho del trabajo se va en la configuración de Odoo y asegurarse que la contabilidad funciona con la factura electrónica. Años atras esta opción no estaba disponible, pero gracias a la localización argentina (y por sobre todo gracias a AdHoc) ahora si lo está. Hay mucha gente que puede encarar estos proyectos.

  • Paquetes verticales de corta duración: sería una etapa ideal en la maduración de un equipo de desarrollo. Porque creo que es por medio de los productos es donde uno tiene las mayores posibilidades de escalar su negocio en Odoo (no voy a dar el nombre, pero es la experiencia de un partner de Odoo ubicado en el litoral argentino). En estos proyectos uno ya cuenta con un conjunto de módulos que resuelven la problemática de un segmento de clientes. Y lo que busca es implementarlos la mayor cantidad de veces posible, reduciendo el tiempo de customización. Un atractivo de esta opción es que brinda la oportunidad de brindar mucho valor agregado debido al grado de conocimiento específico que se logra sobre la industria, logrando así salir del esquema de software-factory.

  • Proyectos de múltiples etapas de corta duración; es para aquellos clientes que tienen proyectos complejos y el equipo de implementación tiene poco conocimiento de Odoo. Es por ello que para reducir el riesgo del proyecto uno se ve forzado a utilizar metodologías ágiles (scrum concretamente) e ir liberando soluciones al cliente en múltiples etapas. Lo que uno busca es a lo largo del proyecto ir aprendiendo, al mismo tiempo que ir brindando soluciones al cliente.

  • Proyectos complejos de larga duración; es la situación que uno debe evitar. Pero, muchas veces no se puede. Son proyectos riesgosos que requieren un esfuerzo de project management importante. Muchas veces implementados con la metodología scrum. Se requiere para llevarlos a cabo mucha experiencia de parte del equipo de implementación, y tambien tener los procesos ordenados por parte del cliente. No son recomendados para los consultores con poca experiencia.

Concluyendo, si uno está arrancando en Odoo debe buscar empezar con clientes que tienen poca complejidad en los procesos y que los mismos ya se encuentren reflejados en Odoo. También aquellos proyectos en los cuales el grado de customización es bajo (es por eso que recomiendo que no empiecen por el punto de venta, ya que como saben su customización esta fuera del alcance del consultor semi-senior). Por suerte, muchas empresas en Argentina estan al alcance de los consultores que están empezando con Odoo. 


Acerca de:

Gustavo Orrillo

Passionate about programming, he has implemented Odoo for different types of businesses since 2010. In Moldeo Interactive he is a founding Partner and Programmer; In addition to writing on the Blog about different topics related to the developments he makes.