Hoy día 23 de Enero de 2018 he podido asistir en calidad de perito de parte en un juicio donde la implantación de Microsoft Dynamics Nav (Navision) ha sido demandada por el cliente final al partner. En esta pericial mi labor se ha centrado en recoger la pericial presentada por el cliente final, el demandante o parte actora, para analizar su veracidad y exactitud, realizando una Contra pericial de parte de ERP que he podido defender.
Para realizar esta pericial se debe contar con experiencia en Navision, en mi caso no solo como Consultor y director de proyectos si no certificado en Microsoft Dynamics Nav en diferentes áreas (financiero, logística, cadena de suministro, CRM, etc). Sin esta formación sería muy complicado poder realizar este tipo de pericial ya que el ERP Navision es amplio y complejo, disponiendo de multitud de funcionalidades orientadas a la gestión de la empresa.
Uno de los problemas que pueden surgir en una pericial es lo que se llamaría la “conducción por el cliente” y esto es que el perito contrario haya realizado su pericial conducido e inducido por las instrucciones de su cliente. Un claro ejemplo de esta situación puede ser que el perito solo se centre en una serie de funcionalidades que no son representativas del tamaño del proyecto, lo que como Auditor CISA denominamos “materialización”. Es decir, si un ERP dispone de 1000 funcionalidades y solo se presentan 4 que no funcionan podríamos concluir que el total del proyecto está realizado (es un tema relativo y no exento de discusión)
Otro de los puntos que debemos tener en cuenta es la cadena de custodia de la prueba, En este caso recibí una máquina virtual con una instalación de Navision junto con el análisis del otro perito. Lo primero que pude detectar es que no se había cuidado la cadena de custodia y, desde el tiempo que el partner abandono el proyecto no sabemos si los datos almacenados y entregados en juzgados han podido ser alterados. No así el código fuente pues Navision dispone de un control de la última fecha de modificación del código fuente, que nos puede servir como apoyo para demostrar que el código no ha sido alterado a partir de una fecha dada.
Por otro lado tenemos que entender que hacer una pericial de validación de la implantación de un ERP cuando este no ha entrado en producción es complejo o puede llegar a ser inútil por diferentes motivos:
No quiero entrar en detalle en diferentes funcionalidades que el perito contrario marco como fallos y que en sala judicial se ha demostrado que:
En un proyecto informático basado en Navision o en cualquiera generalmente basado en un ERP estándar la empresa se debe adaptar en gran medida a los procesos testeados en el mismo porque de lo contrario las ventajas de un ERP estándar se pueden perder con demasiadas personalizaciones que, incluso, pueden suponer un verdadero problema en el futuro para actualizaciones del software.
Mi exposición al juez ha stenido varios objetivos. Por un lado explicar las evidencias extraidas de mi análisis pericial y por otro mantener la atención del juez con una explicación amena y educativa ya que el juez tras 4 horas de juicio necesita una explicación que le mantenga con atención. Tras explicar mi pericial, a la salida de juzgados, mi abogado me felicita por la intervención y piensa que ha sido decisiva.
Conclusión
Un proyecto ERP no puede terminar con éxito si el cliente final no detalla con precisión los procesos a implantar. Cuando estamos ante un proyecto donde el 98% del mismo ha sido desarrollado la razón para no arrancar puede no ser técnica si no de intereses diversos, miedo al cambio u otras razones. Si tiene una implantación de un ERP que ha fracasado bien sea cliente o partner escoja a un perito peragrado y con amplia experiencia en este sector.
Luis Vilanova Blanco. Perito y auditor CISA. Master en Ciberseguridad por Deloitte.
