Peritajes & Peritos

Recientemente he podido estar en sala judicial defendiendo mi pericial informática sobre un proyecto de implantación de un sistema informático vertical en el sector del transporte. En este caso las preguntas tanto de la parte actora, parte demandada y juez fueron claramente respondidas por mi parte con suficiente claridad, desde mi punto de vista, para que se haya visto la verdad de la implantación y del error del perito contrario.

Peritaje informático de software ERP

Par entender la situación debemos explicar el timeline del proyecto informático fallido:

    1.Una empresa de transporte contrata a un partner la implantación de un software del sector transporte. Este software, ya desarrollado e implantado en decenas de empresas de transporte, funciona perfectamente.

    2.Es el cliente el que, tras buscar varias opciones de proveedores de software, decide solicitar al partner la implantación de su software. Este software, a modo de ERP, tiene ya unas funcionalidades claras, que debería haber conocido el cliente, así como una capacidad de adaptación posible, pero siempre bajo ciertos procesos clave que el sistema informático posee.

    3.Se desarrolla un alcance donde el cliente, por ahorro de coste y diferentes motivos, decide prescindir de la compra de ciertos módulos del software.

    4.Meses después demanda al partner por diferentes motivos, entre otros insuficiente funcionalidad para sus requerimientos.

En este caso el cliente final es la parte actora, la que demanda al partner, mi cliente. Parto de una pericial de parte ya realizada por la parte contraria de manera que mi trabajo se ciñe a dos cuestiones:

    1.Analizar la consistencia de la pericial contraria.

    2.Añadir aquellas cuestiones clave que creo son de vital importancia para que decir la verdad de lo ocurrido.

Inconsistencias de la pericial informática contraria.

Tras revisar la pericial contraria que por anonimato no nombrare su autor veo diferentes inconsistencias que dejo reflejadas en mi pericial y que son objetivo claro de las preguntas en sala judicial tanto de los abogados de ambas partes como del juez. Quisiera destacar algunas:

    1.Según dice el perito contrario el cliente encarga al partner un desarrollo a medida. Este grave error puede haber costado el juicio al cliente final puesto que el producto software que contrata es un paquete tipo ERP ya desarrollado donde solo se puede personalizar pero no es un desarrollo a medida. El desarrollo a medida, generalmente, es mucho más caro que si compramos un paquete ya realizado y solo solicita adaptaciones. Este concepto es el principal error del cliente.

    2.El adquirir un paquete ya realizado y funcionando en decenas de empresas tiene ventajas e inconvenientes. Como explique al juez las ventajas es poder tener en poco tiempo el software implantado y adquiere los principales procesos del sector 100% operativos y libres de error. Por el contrario la empresa tiene que adaptarse al nuevo software, lo contrario podría llevar al fracaso completo del proyecto. Desde mi punto de vista la “resistencia al cambio” del cliente en este caso fue un punto claro causa por la cual el proyecto fracaso.

    3.El perito contrario tuvo dos cuestiones erróneas. Realizo lo que se llama una “pericial conducida” donde el cliente le dijo exclusivamente donde tenía que revisar, obviando el 95% del programa que funcionaba perfectamente y por otro lado y más grave no se apoyó en el fabricante para revisar el software donde, desde su desconocimiento, indico ciertas evidencias erróneas de “mal funcionamiento” cuando realmente no conocía el software y este SI funcionaba adecuadamente.

    4.Por ultimo añadir que el perito contrario no tenía experiencia en la implantación de ERP ni certificaciones. En mi caso certificado en los principales ERP como Navision, Odoo, SAP,… pude demostrar perfectamente las causas reales del fracaso del proyecto.

Conclusiones

Cuando vamos a realizar una pericial informática de parte de la implantación de un software debemos contratar a un perito informático experimentado en el tipo de proyecto que peritamos. Así mismo demostrar que un proyecto informático ha fracasado requiere analizar el global del mismo, desde la propuesta inicial, contrato, documentos intercambiados, emails, etc lo que yo denomino el “timeline del proyecto” para determinar con la mayor precisión posible evidencias solidas que ayude a tener claro las responsabilidades del mismo.

Luis Vilanova Blanco

Perito informático certificado.

Fuente: Luis Vilanova

Source