Perito informático ERP

Perito informático ERP

Perito informático ERP

La semana pasada estuve reunido en un importante despacho de abogados de Madrid analizando las posibilidades de realizar una pericial de parte que demuestre las malas prácticas que ha realizado un importante partner de un importante ERP que no quiero nombrar en una empresa del sector fabricación de plásticos para regadío. En esta reunión, como Perito informático ERP, quise aportar todo mi Know-How en la dirección de proyectos informáticos, ERP y web, así como integraciones con terceras aplicaciones en una empresa de fabricación para marcar las pautas, las bases, que limitan el alcance de mi pericial siempre con el objetivo que esta sea perfecta para mostrar las evidencias que ayuden a entender al juez lo ocurrido.

Perito informático ERP

Día lluvioso, me desplazo al centro de Madrid, donde en me esperan abogad y cliente. Entramos en una sala y comenzamos a trabajar.

La primera duda que surge es cómo enfocar la pericial. El cliente, obviamente molesto por todo lo sucedido con su partner, plantea que todo está mal que todo es un engaño. Al respecto mi labor es frenar esa situación. Mi pericial no puede basarse en sentimientos ni en opiniones. Por mucho que nos pese aquellas cosas que no pueda demostrar (por ejemplo conversaciones no documentadas donde se decidió en su momento con el partner trabajar de una cierta manera yo no lo puedo incluir en mi pericial)

Tras varias discusiones llegamos a un acuerdo objetivo del alcance de la pericial:

  1. Malas prácticas que el partner ha incurrido. En este sentido la importancia de disponer de un profesional que dirija el proyecto TI adecuadamente fue uno de los problemas fundamentales del partner.
  2. Errores que podemos objetivamente demostrar mediante emails, partes de trabajo, documentos o que en nuestras pruebas con el software aparezcan. Por ejemplo cálculo de márgenes erróneo.
  3. Ya que el cliente ha estado trabajando unos meses como ha podido con el software demostrar que realmente ha “sobrevivido” con el mismo, buscando atajos y doble trabajo con el programa. Entendamos el concepto de “punto de no retorno” cuando un cliente decide arrancar, aunque por presión del partner, con un programa informático caótico o inacabado.
  4. El partner, ha roto el estándar del ERP dejando el producto en un estado inestable que afecta a diferentes cuestiones negativas.
  5. Valorar todos los desarrollos pendientes son erróneos desde un punto de vista económico.

Con este enfoque traté de aportar el máximo valor a mi cliente y a mi pericial pero sobre todo objetivizar al máximo todas las evidencias que incluiré en mi pericial.

Conclusión

Cuando comencé la reunión el abogado y el cliente depositaron en mí toda la responsabilidad para que les ayudará a centrar una pericial compleja, de un proyecto largo y difícil, donde el cliente ha sufrido mucho la dejadez del partner. Con mi experiencia aporte todo lo que debemos y sobre todo y muy importante lo que NO debemos incluir en la pericial. Ahora el siguiente paso será la realización de la pericial en las instalaciones del cliente, entrega del informe y defensa en sala judicial.

Luis Vilanova Blanco. Perito informático colaborador con ámbito nacional.

606954593

Luis.vilanova@leyesytecnologia.com

www.leyesytecnologia.com