Algunas enseñanzas en proyectos de Odoo que fracasaron

Los proyectos de Odoo son proyectos de implementación de software. Y como tales tienen altas chances de fracasar. Es decir, no cumplen con sus presupuestos originales (en tiempo y dinero) ni con las necesidades del cliente. Sucede en la industria de la tecnologia, Odoo no es la excepción. Es por eso que voy a listar (sin dar los nombres de los clientes) algunas de las razones por las cuales fracasaron algunos proyectos en los cuales el que escribe participó.

Tecnología poco madura o nóveles

Los primeros proyectos  involucraban tecnología inmadura. Eran las versiones iniciales de Odoo (5.0, 6.0 o 6.1). O usábamos una localización que estaba inmadura (no solo la factura electrónica, sino también cheques y otras funcionalidades) o usábamos versiones de la impresora fiscal que nunca tomaron tracción en la comunidad, por ende nunca tuvieron la experiencia necesaria. Lo mismo puede decirse de los proyectos iniciales de MercadoLibre. 

Creo que esto va de la mano del dicho de "la primera o segunda versión nunca es la correcta". Lo mismo se puede decir aquí. Recién cuando se estabilizaron los proyectos de localización y de MercadoLibre pasamos a tener una mayor cantidad de proyectos exitosos. 

Algo parecido se puede decir de los proyectos que involucran al punto de venta en Odoo. Customizar el POS de Odoo es siempre problemático debido a su complejidad y al hecho que utiliza un lenguaje (Javascript o Typescript) con el cual los desarrolladores de Odoo (que son principalmente desarrolladores de backend) no se sienten precisamente cómodos (ni que decir productivos).

Los proyectos de Odoo son proyectos de implementación de un ERP, por ende uno debe implementar tecnologías que son conocidas. No son proyectos en los que uno puede probar nuevas tecnologías (lo que aumenta considerablemente el riesgo). En este aspecto se parecen a los equipos de los mundiales. Uno juega el mundial con el equipo que tiene en ese momento, no con el equipo soñado. De la misma manera un ERP debe implementarse con la tecnología que uno conoce y domina, no con la que a uno le gustaría aprender.

Demasiados features

Muchos proyectos buscan implementar demasiados features en una primera etapa, lo que lleva a frustraciones por parte de los usuarios y muchos retrasos. También se busca implementar funcionalidades que no son del todo necesarias en una primera etapa (por ejemplo, integración con MercadoLibre, e-commerce o mensajería).  Mensajería puede traer problemas, por la integración de Odoo con otros sistemas de e-mail. Pero e-commerce o MercadoLibre son dos proyectos con vida propia, por eso deben tratarse como proyecto por separado. Lo mismo con la calidad de los datos. Muchos esperan limpiar los datos durante la migración, y eso lo único que logra es retrasar el proyecto (por motivos que no vamos a detallar ahora).

En una primera etapa se debe buscar implementar un MVP (o mínimum viable product) de Odoo. Se busca reemplazar al sistema que se está usando actualmente e implementar solo lo necesario y crítico. Eso en una primera etapa, luego en etapas posteriores se pueden agregar funcionalidades adicionales. Esto trae el beneficio de particionar el proyecto en múltiples etapas de implementación, lo cual trae el beneficio de mayor visibilidad sobre el proyecto. Muchos pueden señalar el costo adicional de las interfaces para llegar a este esquema. Ese costo de las interfaces existe, pero es menor al costo que uno incurre por el retraso del proyecto.

Integración con otros partners en un proyecto

En los proyectos por razones coyunturales muchas veces uno se encuentra en proyecto en los que trabajan dos partners. Uno se encarga de la parte funcional y el otro de la parte técnica, lo cual lleva a problemas y costos de comunicación que no deben ser subestimados. Pueden llegar a ser costos superiores al 30% del proyecto. Esta situación se debe muchas veces a problemas de escala, en la cual un partner no puede tener los conocimientos técnicos o funcionales para llevar a cabo el proyecto, es por eso que debe buscar integrarse con un tercero. 

El tema es que cuando hay dos partners, uno tiene costos de comunicación y pueden ser considerables. Como se soluciona este problema? Hay dos soluciones; la primera es que los funcionales desarrollen los conocimientos técnicos (algo complejo, debido a que aprender a programar lleva años). La segunda es la que creo más factible, que los desarrolladores de Odoo tengan mayores conocimientos funcionales, algo que veo más factible. Creo que las consultoras que implementan Odoo que son sustentables son aquellas que son competentes a la hora de desarrollar en Odoo. Y que estas consultoras van a integrar verticalmente los trabajos funcionales.  

Procesos poco claros en el cliente

Esto va de la mano con los requerimientos poco claros. Si la empresa en la que se implementa Odoo no tiene procesos claros, el proyecto va a ser caótico con mucho retrabajo. Uno no puede esperar que por arte de magia Odoo ordene una empresa, esta debe organizarse previamente al inicio del proyecto. Si por ordenar sus procesos debe postergar la puesta en marcha del proyecto de Odoo, es buena idea. No se olvide que si uno automatica con procesos poco claros, uno automatiza los problemas.

Clientes donde implementar Odoo era una mala idea

Habían clientes que no necesitaban Odoo. Que manejaban su negocio con una planilla de Excel y "querían hacer las cosas bien" o "necesitaban sacarse de encima el infierno de mantener las planillas de Excel". Otros de alguna manera habían visto o analizado un poco las funcionalidades básicas de Odoo y habían concluido que con poco esfuerzo de un tercero podían poner en marcha Odoo en su empresa. Ninguno de ellos tenía un buen motivo para implementar Odoo, nunca iban a reducir sus costos o aumentar sus ventas.

O peor todavía, siempre entendieron que Odoo era gratis o muy barato y por eso querían implementarlo. Cuando en realidad era mejor idea comprar un paquete enlatado (por ejemplo, para que lidiar con las complejidades del POS de Odoo en un kiosco en el medio de Cuyo cuando podemos comprar un software que ya tiene el problema solucionado? O lidiar con la realidad impositiva argentina cuando ya hay muchos sistemas administrativos que ya tienen el problema resuelto?)

Para implementar Odoo uno necesita un buen motivo de negocios. O reduce costos o aumenta sus ventas. Muchos proyectos exitosos lo son porque existe un "compelling reason" entonces cuando se presentan los desvíos y retrasos naturales de un proyecto (supongamos por cambios en los requerimientos) se cuenta con el apoyo necesario para continuar con el mismo. Si no existe esa necesidad de negocio, es mejor cancelar el proyecto (debido a que el cliente ve el proyecto como un costo).

Desconocimiento del funcionamiento de Odoo

A nivel backend hay por lo menos dos áreas que nos afectaron mucho en los proyectos. La primera es el manejo de la contabilidad, lo cual se mitiga de dos maneras. La primera es entendiendo los fundamentos de la contabilidad misma. La segunda es comprendiendo como se realizan los asientos contables. Una vez que uno logra un buen conocimiento de estas áreas, ya se pueden lograr cosas interesantes.

El otra área que nos afecto en los proyectos fueron los módulos de stock y de fabricación. Son dos módulos que no se encuentran bien documentados, por lo que es necesario que uno desarrolle el conocimiento para consultar el inventario, actualizarlo, mover paquetes de una ubicación a la otra, encadenar operaciones, etc etc. Pero por otra parte necesitan ser automatizados, Odoo espera que en forma manual uno realice todas las operaciones. Y la necesidad del usuario es que muchas de esas operaciones sean automáticas (para evitar el trabajo extra que se le impone en los usuarios). Esta necesidad de automatización también está presente en el módulo contable.

Algo parecido se puede mencionar con respecto al punto de venta. Con el agravante que estamos hablando o de Javascript o de Typescript, lo cual incomoda mas a los desarrolladores de Odoo debido a que los mismos son de backend.

Estimaciones optimistas

El programador suele ser optimista, todos lo experimentamos a lo largo de nuestra carrera y pagamos las consecuencias de ello. En Odoo se suma muchas veces el desconocimiento de la plataforma mas los tiempos relacionados con la puesta en marcha. Tengamos en cuenta la siguiente relacion. Por cada hora dedicada al desarrollo, minimo hay una hora para capacitacion de usuarios, testeo, deployment de la solucion.

Conclusión

Los proyectos de Odoo son proyectos de implementacion de un ERP, que involucran trabajos de desarrollo de software. Por ende son proyectos de desarrollo de software. Estos tienen las mismas chances de fracasar como cualquier proyecto de software. Por mas que sean lindos los videos, los proyectos de Odoo estan bajo las generales de la ley de la industria.

Las unicas herramientas para reducir las chances de que falle  el proyecto es utilizar metodologias agiles, conocer mejor la plataforma con la que uno trabaja, reducir los costos de comunicacion en el proyecto, y aplicar las buenas practicas de proyectos que permiten reducir los riesgos de los mismos.