24 Ene Contra pericial de parte de ERP
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.
Contra pericial de parte de ERP
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:
- Si el proyecto no ha sido arrancado es complicado decidir si realmente todas las funcionalidades se han completado como el cliente deseaba o explicaba al partner.
- Por otro lado la base de datos de pruebas/test estará llena de pruebas y tests (como su nombre indica) pudiendo haber datos desvirtuados de la realidad. Por ejemplo, si hago pruebas de movimiento de un producto quizás puedo haber cambiado su configuración o añadido clientes y productos de prueba, etc En cualquier caso NUNCA será la base de datos que hubiese entrado en producción
- En realidad, ¿tiene sentido hablar de fallos de funcionamiento en un programa que no ha entrado en funcionamiento real y no tiene las conexiones, datos y configuraciones necesarias para operar como programa real? La respuesta parece obvia.
No quiero entrar en detalle en diferentes funcionalidades que el perito contrario marco como fallos y que en sala judicial se ha demostrado que:
- Si el partner no tiene contratado la migración de daos históricos y estoy intentando utilizar una funcionalidad que necesita del histórico obviamente no funcionara y no será responsabilidad del partner.
- La migración del histórico suele ser un proyecto a parte, en concreto en este juicio al no estar contratada no se puede exigir.
- La migración de datos de un programa anterior en un ERP es un tema complejo que en ocasiones se desestima, haciendo punto y aparte con diferentes técnicas de DWH o bien se plantea como un proyecto complejo y con sus tiempos y presupuestos bien establecidos y contratados.
- El funcionamiento de Navision es tal que la generación de cliente so ventas desde portales webs o app que se integran se basan en la lógica que Navision tiene en el “servidor central”. Por tanto si esta funcionalidad funciona adecuadamente en el servidor central es muy probable que lo hiciera si se desarrolla una app o web que integra con los servicios web nativos de Navision.
- Si bien los datos maestros de un programa anterior suelen traspasarse al nuevo (clientes, productos, etc) y es responsabilidad del partner, no lo puede ser el detalle de grano fino como los precios o ubicaciones exactas en el almacén si el cliente no se lo entrega adecuadamente. Por ejemplo, si un producto debe estar en el almacén 1 pero en Navision está en el almacén 2 puede ser porque o bien el cliente ha cambiado su ubicación o porque los datos que importo el partner que el cliente le dio (como es el caso) tenía ese almacén. Existen otras razones que ahora no entrare.
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.
606954593
Luis.vilanova@leyesytecnologia.com