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.
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:
Es por ello que los juicios que he tenido en concepto de ODOO han tenido varias cuestiones en común:
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:
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.
