Peritaje informático ERP. Del lado del cliente o partner.

Peritaje informático ERP

Peritaje informático ERP. Del lado del cliente o partner.

Estos días estoy trabajando varios peritajes informáticos de ERP, bastante variado tanto desde el lado que defiendo, al ser de parte y variado también en el tipo de ERP, Navision, AXAPTA, SAP y otro que no puedo nombrar. El Peritaje informático ERP te enseña las complejidades de un proyecto transversal en las organizaciones, donde las situaciones pueden complicarse al extremo.

Peritaje informático ERP

En menos de 48 horas he podido estar con 3 empresas en juicio por la implantación de un ERP. Dos de ellas partner y un cliente final. Las ideas, los comentarios, etc del porque ha fracasado sus proyectos suelen ser muy variados pero tienen características comunes, sea cual sea el sector, fabricante del ERP, etc Como CIO part time y consultor de procesos/gestión he estado personalmente involucrado, como cliente, implantador, consultor y CIO en bastantes implantaciones de ERP, en concreto en varios de Navision, SAP, JDEdwards y otros, además de haber implantado la gestión de ópticas El Corte Ingles entre otros. Digo esto porque tengo la gran suerte de tener una visión global. Como Interim Manger TIC, desde el lado del cliente defiendo la empresa final, pero como consultor o auditor también se lo que es estar al otro lado.

Conociendo las problemáticas que se repiten en la mayoría de ERP me gustaría hacer un resumen de diferentes evidencias que voy a reflejar en estas periciales invitando al lector a que deduzca en qué casos estoy en un peritaje de parte del lado del cliente o del lado del partner:

  • El ERP debe informar del inventario continuo de stocks, dice la pericial contraria. Sí, es correcto, pero como siempre relativo. ¿Está el cliente llevando un control exhaustivo de todas las operaciones que afectan al stock como albaranes de compra, venta, regularización, roturas, robos, etc?
  • El proyecto se ha desviado del alcance inicial. Este punto es increíble. Me apasiona por cómo se repite en muchísimas periciales. La firma del proyecto basado en un documento DRP (nomenclatura Microsoft), Blueprint (nomenclatura SAP), etc incompleto, realizado rápido o incorrectamente, que no incluye con detalle cómo funcionan los procesos del cliente, resulta como una bomba de tiempo, que solo es cuestión de tiempo para que lleve al proyecto al fracaso. Entendamos que definir el alcance lo más detalladamente posible es como, y así se lo explico al juez, terminar los planos de un edificio de manera incorrecta, todo el resto del proyecto puede verse afectado e incluso, como ocurre, acabar con un proyecto en situación de fracaso.
  • En relación con el anterior punto defiendo, en dos de los peritajes, el responsable de este documento. En uno de ellos es el consultor o partner el que claramente comete la negligencia, presentando un documento de alcance que se limita a copiar las imágenes del software anterior, sin explicar cómo se realizan los cálculos de costes, márgenes, lista de materiales, etc. En otro, desde mi punto de vista, es el cliente el que no puso al frente del proyecto a un responsable interno con aptitudes, capacidad y tiempo para dedicar al proyecto.
  • Del punto anterior se deriva una cuestión importante y es los costes ocultos que pueden aparecer si el alcance de proyecto no se ha definido con claridad. Es típico que el partner reclame más euros conforme avance el proyecto si el alcance inicial no ha sido bien estimado.
  • ¿Es necesario la figura de un responsable interno? FUNDAMENTAL. No cabe duda que la implantación de un ERP será un éxito siempre que el cliente final ponga un equipo interno liderado por un responsable de proyecto cercano al negocio, con capacidad, experiencia previa en procesos o software de gestión y si es posible con un apoyo de TI. La ausencia de esta figura es, desde mi punto de vista, la razón de la dificultad o fracaso de muchos proyectos.
  • En otro de los peritajes, uno de los más amplios en su alcance, me encuentro con una pericial contraria, es decir estoy realizando un contra peritaje de parte, donde el perito no conoce cómo funciona el ERP y ha cometido el grave error de peritar algo que no sabe cómo funciona. Asi me encuentro con afirmaciones erróneas respecto del funcionamiento más básico, por ejemplo cambiar el nombre de cliente de una factura.
  • En Navision suele ser fundamental la selección de la licencia para un Peritaje informático ERP. La incorrecta selección de la misma puede encarecer el proyecto e incluso ser una de las razones de su fracaso. Entendamos aquí que una licencia superior puede tener un coste más elevado pero más aún es el desarrollo a medida en un ERP. Es decir, seleccionar la licencia con la funcionalidad más adecuada es clave y razón de algunas implantaciones fallidas.

Conclusión

Mi mensaje en este punto para los abogados es selecciona bien al perito que haga un Peritaje informático ERP pues no es lo mismo peritar un Whatsapp o un email que un sistema de gestión tan complejo como un ERP que requiere peritos que seamos experimentados, con experiencia como consultores, como directores de proyecto y como cliente final. Solo así el peritaje puede ser de calidad y ser adecuadamente defendido en la vista oral ante el juez.

Luis Vilanova Blanco. Perito informático judicial.

luis.vilanova@leyesytecnologia.com

606954593

www.ciberseguridad.com