07 Abr Próximo Webinar 19/04/2020 Peritaje ERP ODOO. Asociacion española de ODOO.
Cuando comencé en el mundo del ERP, quizás por el año 1998, como programador, después como consultor, después como director de proyectos de implantación, como CIO coordinando a proveedores, como auditor y finalmente como perito no podría imaginarme las implicaciones y complejidad que podía llevar implantar un sistema de gestión empresarial. Estamos ante uno de los proyectos más complejos que una organización, respecto de sus procedimientos de trabajo y sistemas de información puede abordar, generando todo tipo de conflictos internos y externos que nos podamos imaginar. Peritaje ERP ODOO.
Próximo Webinar 19/04/2020 Peritaje ERP ODOO. Asociacion española de ODOO.
Certificado en ERP como Microsoft Dynamics NAV y ODOO he estado en multitud de proyectos de este tipo para todo tipo de sectores farmacéutico, distribución minorista, abogacía, laboratorios, fabricación, logística,… así como he asistido a juicios de muchos otros ERP como SAP, AQUA y otros, donde mi opinión como perito ha sido reconocida por los letrados e incluso por el juez como clave para la resolución del procedimiento judicial. En una ocasión el juez nombro mi pericial como “elemento clave para haber podido llegar a una resolución justa”
En el caso del ODOO estamos ante un ERP con algunas características que lo hacen especialmente sensible para juicios:
- Estamos en un ERP que generalmente se implanta en Cloud o en el hosting del cliente. El acceso es fácil e intuitivo, combinado con el coste de licencia cero (depende de la licencia), módulos al estilo de un Apple Store, multitud de casos de éxito y consultoras, hacen de él un elemento de relativamente fácil introducción en pymes.
- El elemento de licencias a coste cero es un arma de doble filo ya que puede atraer a un tipo de empresas que no considera el ERP como un elemento estratégico sino como un gasto.
Es por ello que los juicios que he tenido en concepto de ODOO han tenido varias cuestiones en común:
- Falta de documento de requisitos firmado o aceptado por las partes.
- Metodología de desarrollo no basada en resultados a corto plazo (Scrum, Agile) donde el cliente acepta hitos o entregables.
- Falta de un pilotaje desde dentro de la organización con capacidad de decisión y dedicación suficiente al proyecto.
- Falta de colaboración del cliente o dedicación de recursos del partner.
- Elemento de no “inversión” en ningún tipo de licencias. Esto no siempre es así. Entendamos la integración con EDI, con terceras plataformas, módulos de pago, personalizaciones, etc
- Importación de datos. La compleja estructura de un ERP anterior puede no ser adaptable a ODOO, incluso por inconsistencias de los datos de origen.
- Traducciones del inglés no finalizadas en ODOO, que en ocasiones se han usado como un problema graves para ciertos usuarios.
- Problemática de impresión ya que en ocasiones se necesitan fuentes o componentes adecuados en el lado del servidor.
- Obsolescencia de ciertas versiones instaladas que no solucionan problemas que si lo están en siguientes versiones disponibles en el momento del arranque.
- Fallos o errores. Lo comentare con más detalle a continuación.
- “Rotura” del estándar de ODOO.
- Valoración económica del proyecto implantado si este no ha concluido o ha concluido sin la aceptación del cliente. Hablamos de esfuerzo horas y de otros conceptos.
- Otros…
Imaginemos la complejidad de explicar todo estas cuestiones a abogados, de ambas partes, a jueces e incluso en careos donde me he encontrado peritos que no dicen la verdad y que es en ocasiones complicado en sala judicial explicar que lo que se está diciendo es falso.
Dentro de los aspectos clave desde mi punto de vista está el concepto de error y fallo. Sin entrar a valorar lo difícil que puede resultar en sala judicial explicar que un fallo no tiene o si tiene importancia debo explicar el concepto de fallo bloqueante o sustancial.
Todo proyecto de Ingeniería de Software, incluido implantaciones de ODOO, tiene una curva de fallos que esta estudiada por la Teoría de Ingeniería de Software. El siguiente diagrama explica esta curva:
En un proyecto adecuadamente ejecutado la tasa de errores es alta al principio y cae con la estabilización del mismo y el paso del tiempo, como puede verse en la curva inferior, nunca siendo cero.
En ocasiones, con la aparición de nuevas versiones o nuevos desarrollos los errores pueden aparecer. Estos errores son lógicamente aceptables siempre y cuando no afecten al núcleo o core del sistema, interrumpiendo su servicio en un tiempo prolongado; impidiendo su funcionamiento en aspectos clave, etc.
En este sentido podemos decir que un proyecto software se estabiliza cuando un gran porcentaje de las necesidades globales y errores se subsanan (siempre con la colaboración de ambas partes, cliente y partner), siendo normal que las incidencias o mejoras acompañen al proyecto conforme dicho proyecto evoluciona, la estrategia de la empresa cambia, se aprovechan nuevas funcionalidades que derivan en otras o en informes nuevos que inicialmente no se habían planteado, etc.
El concepto de error bloqueante es importante en la mayoría de periciales de ODOO. En el campo de la Ingeniería de Software se considera que un error es bloqueante si cumple los siguientes requisitos:
- No tiene solución o, al menos, no se puede resolver en un periodo corto de tiempo.
- Afecta al normal funcionamiento del software en tal magnitud que el cliente no puede utilizarlo de forma global o en procesos que son clave para el normal funcionamiento de su empresa.
En general estos y otros temas podremos tratarlos en mi próximo webinar el día 19/04/2020 a las 10:30 https://www.aeodoo.org/event/webinar-peritaje-informatico-2020-04-21-58/register donde podremos tratar estos conceptos, experiencias reales en sala judicial, conceptos, clave y recomendaciones.
Luis Vilanova Blanco. Perito informático ERP ODOO.
911277300