14 May Peritaje de ERP Navision – Desestimación de demanda
En este post quiero explicar uno de los juicios que he asistido recientemente en calidad de perito informático. En este caso contratado por el Partner de Navision al haber recibido una demanda del cliente por diferentes cuestiones que se alegaban. El resultado del juicio ha sido desestimación de la demanda. Seguidamente contaré las claves de este juicio.
Peritaje de ERP Navision
En primer lugar quisiera explicar el alcance que literalmente fue “Analizar el alcance o evaluación del estado de implantación del programa ERP Microsoft Dynamics NAV en EL CLIENTE realizado por el partner YYYYYYYYY, contrastándolo con lo realmente contratado, fijando el estado de la implantación del programa en la fecha en la que el PARTNER recibió el burofax de EL CLIENTE instando la resolución del contrato (que fue el 11 de abril de 2017), y si el mismo presenta los defectos que se aducen por EL CLIENTE en su informe pericial, si son graves y la causa de los mismos, así como valorar el porcentaje de trabajos ejecutados en vista el contrato firmado entre las partes y el importe que debe percibir EL PARTNER por los mismos“. Lo primero que podemos extraer es que hubo reconvención por parte del partner, a partir de una demanda inicial del cliente final.
Estamos ante un ERP donde sus módulos más utilizados están al 99,9% libre de errores. Esta premisa es fundamental para entender esta pericial ya que el lector debe asumir que todas aquellas funcionalidades que se han encontrado instaladas y configuradas,así como no modificadas su código fuente, podemos y es aceptable asumir que NO tienen errores sustancial, es decir, que afectaban al core del negocio o que impidan su uso.
Más allá de todas las funcionalidades que hemos podido analizar que existen instaladas y configuradas por EL PARTNER y utilizadas por EL CLIENTE exhaustivamente durante meses,existe lo que se denomina personalizaciones.
Las personalizaciones son funcionalidades que por si NAVISION no aporta pero que el partner, desarrolla para su cliente. Estas personalizaciones son realizadas para adaptar al máximo el ERP a las necesidades del cliente. Estas funcionalidades, como pude revisaren el código fuente estaban libres de errores.
Por lo tanto pude afirmar que la funcionalidad estándar de NAVISION está libre de errores sustanciales, así como las personalizaciones realizadas, lo que nos llevó a concluir que la implantación no tenía errores sustanciales que no pudieran ser resueltos en pocas horas.
Recordemos que en un ERP como Navision, y en general en cualquier desarrollo software, un error sustancial es aquel que:
El concepto de error sustancial es importante en esta pericial. Como Ingeniero de Software considero que un error es sustancial si:
- No se puede resolver en un periodo corto de tiempo.
- No tiene solución.
- Afecta al normal funcionamiento del ERP y el cliente no puede utilizarlo de forma global o en procesos clave en su empresa.
Una de las conclusiones que creo ayudaron fue “Quiero concluir en este punto que los fallos y errores son parte normal del ciclo de vida de implantación de un ERP, especialmente si estos no afectan al core del sistema, no existiendo ningún proyecto ejecutado que lo tenga. El objetivo de estabilización de la implantación es una tarea compartida entre cliente y partner, que de forma colaborativa deben trabajar hasta que el número de incidencias sea bajo,facilitando la comunicación de todo problema. “
Conclusiones
El utilizar el concepto de error sustancial y de curva de errores en un desarrollo software, asi como mi explicación en sala judicial fueron clave para que el juez entendiera las razones lógicas por las cuales un CLIENTE puede cancelar un proyecto o demandar al partner. Si se encuentra en esta situación en un proyecto software, tanto si es cliente como partner, puede contactar conmigo para defender su problema adecuadamente.
Luis Vilanova Blanco. Perito informático colaborador con la justicia.
606954593