Algunos factores que pueden hacer que vayan bien (o mal) los proyectos de Odoo

El día de ayer, hablando con un potencial cliente, estuvimos hablando sobre Odoo y los proyectos de software. Y en la conversación surgió el tema del riesgo en los proyectos de software y la comparación de estos con los proyectos en los que se construyen casas. Con una pequeña salvedad, la gran mayoría de las casas que se construyen se finalizan (a pesar de los desvíos en los tiempos y presupuestos planificados). Mas tarde o más temprano, hay gente viviendo en dichas casas. En cambio muchos proyectos de software no llegan a ponerse en producción (ni siquiera se retrasan, solo se cancelan). Entonces empecé a enumerar (en nuestra experiencia) porque muchos proyectos fracasan (o salen en producción) en Argentina. Y esta es la lista de lo que aprendimos

Mejor que su empresa sea ordenada

No espere que Odoo ordene su empresa. Es mejor ordenar sus procesos, y luego implementar Odoo. No al reves. Si implementa Odoo (lo cual seguro va a ser despues de un proyecto traumático), va a terminar automatizando el desorden. Y a la larga va a ser más caro. Implementar Odoo no es para ansiosos. Odoo es uno de los tres componentes de un proyecto de digitalización exitoso: los otros dos son la gente y los procesos. Por eso, ordene su gente y procesos, luego dele para adelante con el proyecto de Odoo.

Si tiene dudas sobre como empezar en ordenar sus procesos, solo googlee "gestión de procesos" o "mejora de procesos" y se va a encontrar con cientos de consultoras dispuestos a ayudarlos. Y dele para adelante, le aseguro que se va a ahorrar mucho tiempo y dinero.

Hacer un gap-analysis antes de empezar el proyecto

Un gap analysis es un estudio en el cual uno conoce en estado actual de la empresa, las funcionalidades que provee Odoo, y que se necesita para acercar ambos mundos. Más allá del documento que es el entregable del documento, lo ideal es tener un plan de trabajo o proyecto para poder implementar Odoo. Dicho proyecto deberá tener en cuenta las customizaciones a desarrollar para cubrir las deficiencias identificadas por el gap analysis.

Empiece un proyecto cuando tenga bien claro cuando el mismo se va a terminar. No espere terminar el proyecto bien si no sabe de antemano cuando se va a finalizar el mismo. Si el alcance del proyecto es difuso, aclárelo antes de comenzar.  

La importancia del product owner

Muchos proyectos en este momento son en remoto. Entonces la figura del product-owner (que es quien impulsa el proyecto de la parte del cliente) es fundamental. El product owner es quien marca el ritmo en el cliente (si el cliente no tiene ritmo, no importa que uno trabaje veinte horas por día, el proyecto no avanza). El product owner es quien se encarga de coordinar la capacitación de los usuarios y los testeos por parte de los usuarios. Tambien de recolectar y mantener los requerimientos. Pero por sobre todo priorizarlos, asegurandose que en cada iteración del proyecto, los requerimientos más importantes sean los que se implementan.

Por otra el product owner es el primero en vencer la resistencia al cambio (natural en toda implementación de un ERP). Todo ERP implica cambios en la operatoria de una empresa. Lo cual conlleva a una natural resistencia al cambio por parte de los usuarios. El primero sponsor de dichos cambios es el product-owner, y es una pieza fundamental en vencer la resistencia a la implementación del ERP. Si el product-owner no está alineado, el proyecto de implementación del ERP va a tener corta vida. 

Por último, un punto a tener en cuenta, es la disponibilidad del product-owner. Implementar Odoo no es una tarea que se pueda realizar a tiempo parcial (o como muchos entusiastas piensan, un proiyecto de fin de semana). El compromiso a nivel horario del product owner con la implementación de Odoo es muy importante. Puede no ser dedicación total al proyecto, pero si una dedicación importante. Y tambien el product-owner necesita ser una persona con seniority y credibilidad dentro de la empresa. 

Duración del proyecto y use metodologías ágiles

Todos los proyectos que terminaron bien, fueron aquellos que duraron menos de tres meses (y en los cuales se trabajó con tecnologías ya conocidas). Los que se aproximaron al año de duración, siempre tuvieron finales traumáticos (salieron en producción, pero tuvieron desvíos con respecto a sus estimaciones iniciales; principalmente debido a los requerimientos). Y creo que esto se da por varios motivos.

El primer motivo es que en un proyecto de tres meses, un desvío de dos o tres semanas es aceptable, desde el punto de vista financiero no es calamitoso. En cambio un desvío de dos o tres meses en un proyecto de diez o doce meses, ya tiene otro color (ni hablar desde el punto de vista financiero). Esto va de la mano de como crece la impaciencia de la gerencia, que es la que firma los cheques todos los meses.

El segundo motivo es el equipo de trabajo. Es más difícil mantenerlo y en un proyecto de muchos meses, hacia el fin de los meses ya presenta un agotamiento importante. Y en un entorno en el que la rotación del personal es alrededor del 30%, es algo para tener en cuenta. Hacia el final del proyecto van a haber caras que van a cambiar. Y eso va a tener un impacto sobre el schedule. No se olviden que agregar personal hacia el final de un proyecto, en lugar de acortar los tiempos de implementación los alarga. Y no piensen que los programadores son piezas intercambiables. Si así fuese, el salario de los programadores sería la mitad de lo que es el día de hoy. Y no serían las estrellas del mercado laboral.

El tercer motivo es la visibilidad del proyecto; los proyectos cortos son más transparentes que los de larga duración, y esto es fundamental para el éxito del proyecto (y un alivio para la gerencia). Algo a tener en cuenta, cuando uno implementa un ERP en una empresa, lleva adelante muchos cambios (facturación, pagos, stock, ventas). Lo cual genera resistencia natural por parte de los usuarios. Por ende el proceso de implementarlo lleva muchos meses. Quizás una buena alternativa es implementar el sistema en etapas en paralelo con el sistema actual. Puede ser más lento y caro, pero tiene más chances de éxito.

Es por ello que es una buena idea utilizar metodologías ágiles. Por varios motivos. Pero creo que el principal es que permite un mejor seguimiento de los resultados y le brinda transparencia al proyecto. También porque al verse forzado uno a realizar entregas en cortos períodos de tiempo, brinda más visibilidad al proyecto. Y trae a la luz en forma temprana muchos problemas que solo se visibilizan hacia el final del proyecto. 

No experimentar con la tecnología

Es como en los mundiales. Uno los juega con el equipo que tiene en ese momento, no con el sueña. Algo parecido pasa en los proyectos en los que uno implementa un ERP. Debe hacerlo con las herramientas que uno ya conoce. No puede aprender nuevas tecnologías o desarrollar nuevas soluciones a problemas. Si uno en un proyecto se pone a experimentar, lo único que hace es demorarlo. Lo mismo sucede con el equipo de trabajo, no espere que un equipo con poca experiencia aprenda a implementar Odoo en pocos meses. En ese caso el proyecto solo servirá de escuela al equipo de trabajo y el proyecto terminará cancelándose.

Es por ello que si inicialmente en un proyecto se identifican tecnologías desconocidas (por ejemplo lectura de código de barras en los almacenes o impresión de etiquetas en impresoras de etiquetas), se debe decidir como mitigar su impacto en el proyecto. Quizá sean tecnologías no críticas para el proyecto, por ello las mismas o no pueden implementarse o se puede demorar su uso. O si son tecnologías críticas debe antes de iniciarse el proyecto, hacer un proyecto de prototipo para aprender sobre su uso. Y luego decidir que hacer con el proyecto principal.

El punto es; las nuevas tecnologías implican un riesgo para el proyecto. Es por ello que dichos riesgos deben ser identificados de forma temprana y mitigados. 

Tiene que existir un business-case para implementar el sistema

Todos los proyectos exitosos son aquellos que terminan poniendo en producción (más allá de los desvíos en tiempo y presupuesto). Nadie discute que poner un hombre en la luna fue un proyecto exitoso para la NASA; ahora les aseguro que los desvíos que tuvieron, la fecha en que el Apollo 11 llegó a la luna y los gastos que tuvieron durante el desarrollo; no fueron los que pensaron en el año 1960 cuando se lanzó el programa Apollo. Lo mismo puede decirse de las vacunas para el Covid. Nadie duda que fueron exitosas, pero la tecnología que las hizo posible llevó mucho tiempo y esfuerzo.

Lo mismo sucede con los proyectos en las cuales se implementa Odoo. Detrás de ellos debe existir una razón de negocios para implementarlos. Se debe o reducir los costos, o aumentar las ventas. El caso es que debe existir una motivación financiera. Si no puede relacionar una iniciativa tecnológica con un resultado monetario en su negocio, está en un problema. Por que? Tarde o temprano, es muy probable que el proyecto se retrase o se desvíe con respecto a su presupuesto original. Y en esos momentos, se debe decidir que hacer con el proyecto. Y los proyectos solo continuan cuando ponerlos en marcha es más barato que el impacto financiero que van a tener. Si esa cuenta no cierra, es mejor cancelar el proyecto (esto es, palabras más o palabras menos, el famoso "apoyo de la gerencia")

Priorizar los requerimientos

Un proyecto de implementación de un ERP se lo puede ver como un triángulo en el que se equilibran tres puntos: presupuesto, requerimientos, tiempo de implementación. Cuando uno modifica uno de estos puntos termina impactando los otros dos. Y por lo general, el que se termina modificando es el los requerimientos. Con la siguiente idea en mente; es mejor tener un buen sistema implementado el día de hoy, que un excelente sistema implementado el día de mañana (el pragmatismo debe primar en los proyectos).

Entonces, que se hace? Se prioriza los requerimientos. Por lo general, se dividen los requerimientos en las siguientes categorías: crítico, necesario, no tan necesario, nice-to-have. Y lo que se busca en cada una de las iteraciones del proyecto, es ir resolviendo los requerimientos críticos y necesarios. Dejando para una segunda etapa los no tan necesarios y nice-to-have. Esta tarea de priorización de requerimientos debe hacerse en conjunto con el product-owner del cliente y el project manager del equipo de implementación. 

Tamaño y seniority del equipo
Last but not least... el equipo de trabajo. Los equipos para implementar Odoo no deben ser multitudinarios. Por varios motivos. Si el equipo tiene el seniority necesario, no se necesita tantos consultores (por otra parte, si la consultora pone muchos consultores junior en el equipo de implementación, uno no esta contratando una consultora sino un jardín de infantes). Por otra parte, al tener mucha gente un porcentaje significativo de los costos del proyecto (en muchos lugares alrededor del 30%) se van en la coordinación y comunicación del equipo de trabajo. Al igual que en la separación de las tareas.

Por otra parte no esperen que el equipo de trabajo aprenda durante el proyecto. Implementar Odoo requiere un seniority de mínimo un año.