En este post quiero comentar algunas cuestiones interesantes que ocurren en la implantación de un ERP, entre partner y cliente, que pueden llevar a serios conflictos y si no se solucionan, acabar en un juicio complicado para todas las partes, incluido el juez ya que en un Peritaje informático ERP las reflexiones de las razones objetivas que cada parte esgrime pueden ser muy variadas y en ocasiones difusas para el juez, aunque los peritos ayudemos a centrar el problema.
Peritaje informático ERP
Entendamos que la complejidad de implantación de un ERP en una empresa por parte de un partner es una tarea nada sencilla, llena de complejidades y frenos, que debe ser trabajada con metodología, como Microsoft, SAP, A3 etc tiene la suya, pero no es suficiente.
Existen factores que influyen positiva o negativamente en la implantación de un ERP y cuyo enfoque, desde las fases previas a la firma del contrato, pueden hacer el éxito o el fracaso de una implantación de este tipo.
Actualmente me encuentro trabajando 4 periciales de ERP, de 3 proveedores distintos, una implantación de SAP Business One, un proyecto de Microsoft Dynamics AX, una implantación de Microsoft Dynamics NAV y una implantación multisede de A3, 3 de ellas desde el punto de vista del partner y una desde el punto de vista del cliente final. Por privacidad y confidencialidad no diré los sectores ni por supuesto el nombre de cada uno.
Si tuviera que recapitular las razones principales que estos cuatro proyectos han fracasado los resumiría en los siguientes:
·Falta de un responsable interno de calidad en el cliente. Es decir, alguien con experiencia, tiempo, dedicación, liderazgo, etc que haya podido coger en el cliente el proyecto con garantías para que sea un éxito.
·Falta de un líder claro en la parte del proveedor. De igual manera, la falta de un profesional adecuado al proyecto, a la filosofía del cliente, capaz de analizar los puntos más complejos del proyecto y aplicar las medidas para mediar en situaciones complejas.
·Descripción muy simple inicial, pre contrato, para estimar el tiempo y el coste, así como las fases y recursos necesarios para finalizar el proyecto con éxito. Me he encontrado con documentos de requisitos muy básicos, muy sencillos, pero que no explican las características específicas de las necesidades de procesos del cliente. Por ejemplo, quien es el responsable de una buena definición del proyecto cliente o partner? Esto lo guardo como parte de mi Know-how y si, efectivamente, depende de varios factores…
·¿Se ha seleccionado el mejor ERP? Quizás el ERP que se seleccionó no era el más adecuado. Requisitos como funcionamiento offline, no todos los ERP lo permiten, incluso permitiéndolo el concepto puede no ser claro para el cliente, ¿Qué quiere decir offline, sin internet, sin acceso al servidor,…?
Ahora entendamos la postura del juez, un experto en leyes, con pocos o ningún conocimiento de los procesos transversales que afectan a un ERP. Como somos capaces los peritos de explicarle al juez que ha ocurrido, que ha pasado en ese proyecto, a posteriori de unos hechos cuya veracidad solo está en documentos y emails guardados por cada parte involucrada.
Buenas prácticas que ayudan
Existen multitud de variables que hacen que un proyecto ERP triunfe o fracase. Aquí solo nombraré 4:
1.El interlocutor interno o equipo interno de la empresa donde se va a implantar tiene tiempo y experiencia en este tipo de proyectos y se ha preocupado de especificar con detalle sus necesidades al partner, previa firma del contrato.
2.Si el cliente no tiene esa figura debe contratar a un experto externo que haga de puente o intermediario entre partner o cliente, por ejemplo un Interim Manager.
3.El proveedor tiene que tener experiencia en el sector a ser posible y haber forzado o colaborado en que el cliente le transmita con el mayor detalle posible los requisitos.
4.El proveedor debe definir las funcionalidades que se contratan con el nivel máximo posible o bien reflejar contractualmente que parte de ellas se definirán conjuntamente con el cliente a posteriori de la firma del contrato.
Conclusión
El lector habrá podido entender que cuando hablamos de un peritaje informático ERP, estamos ante una situación realmente compleja. Yo llevo 20 años con ERP, desde el punto de vista de consultor, cliente, auditor y perito informático y cada peritaje nuevo que realizo veo que complejidad tan elevada tiene un proyecto de este tipo, sin el que la colaboración de cliente y partner es imposible llegar a éxito.
Luis Vilanova Blanco. Perito judicial informático.
606954593
Luis.vilanova@leyesytecnologia.com
