Como resolver una contra pericial informática judicial de parte

Como resolver una contra pericial informática judicial de parte

Contra peritajes judiciales de parte

Uno de los últimos trabajos que he tenido que defender delante de una jueza ha sido un peritaje que en realidad era un contra peritaje de parte de una implantación ERP, típico conflicto entre proveedor y cliente.

Cuando te encargan y asumes una tarea de este tipo generalmente dispones de los siguientes elementos:

  1. Pericial del anterior perito informático defendiendo unos hechos que irán, generalmente, en contra de los intereses de mi cliente.
  2. Información desde el punto de vista opuesto, mi cliente y terceras partes (fabricante del producto, etc.).
  3. Nuevas informaciones que mi cliente me aporta y son susceptibles de ser incorporadas.

Por tanto la realización de mi pericial consiste en tener la capacidad de reunir toda la información de los puntos anteriores y elaborar un dictamen pericial informático de calidad, donde uno de los objetivos es que sea mejor considerado por el juez que el peritaje inicial de la parte contraria. Pero veamos punto por punto como lo enfoco y como lo trabajo…

Respecto de la pericial de la parte contraria…

El perito informático anterior en muchas ocasiones parte en desventaja, es obvio, pues es el primero que abre ‘la caja de pandora’. Cuando redactó su pericial informática no conocía si quiera, pues no siempre ocurre, que habría un contra peritaje informático y, por supuesto, desconoce el nivel de profesionalidad o capacidad de este nuevo perito informático. Por tanto sus argumentos están ahora delante de mí para que los estudie con minuciosidad, los diseccione hasta detectar el más mínimo error, sesgo o incoherencia, o simplemente que este mal defendido, para acertar con mis criterios y anular, contrarrestar o sembrar la duda (muy utilizado generalmente) respecto de los argumentos contrarios.

Generalmente trabajo varios aspectos a la hora de contrarrestar una pericial contraria:

  1. Objetivo de la pericial equivocada o no relevante respecto del tema juzgado. Aunque parezca increíble me encontrado ya varias veces ante periciales informáticas que se preocupan de demostrar que un ERP o hardware funciona, cuando en la mayoría de ocasiones esto no es la pieza clave, sino que se juzga realmente si el partner ha cumplido con un proyecto (habitualmente es necesario enfocar la pericial hacia el proyecto contratado no hacia las características funcionales del producto pues en realidad es una herramienta que forma parte del problema, no es el problema en sí) o bien el cliente a colaborado o ha aceptado ciertos hitos (depende del lado en el que te encuentres como perito informático).
  2. Falta de experiencia del anterior perito informático en el producto, ERP, etc. juzgado. Este punto es fundamental. Subrayar que el otro perito juzga algo respecto del cual no tiene experiencia, formación acreditada o similar es suficiente para sembrar la duda del global de su pericial informática ante el juez. En uno de los últimos peritajes me encontré con una pericial contraria, previa a la mía, donde se afirmaba tajantemente que el ERP no funcionaba porque dos informes daban cifras de facturación anuales distintas, cuando, según su opinión, era inadmisible no tener un dato único y que ambos informes coincidieran. En este caso mi contra pericial informática estaba clara en este aspecto. Si el perito hubiera entendido que un informe muestra la facturación de los pedidos a una fecha y el otro la facturación de los albaranes enviados, claramente no hubiera reflejado su incorrecta evidencia, ya que ambos datos eran correctos, simplemente mostraban información distinta.
  3. 3.       Juicios de valor o defensa de aspectos simples que no demuestran el problema. En ocasiones el perito anterior realiza juicios de valor desmedidos tipo “este ERP debe ser reprogramado por completo” o “El ERP no funciona pues claramente se ve el error ‘la unidad Z no se encuentra’…” siendo puntos claramente contra restables.
  4. 4.       Parcialidad. Uno de los puntos donde se suele caer es en la parcialidad. Si el anterior perito informático lo demuestra, lo enfatizo pues es un punto que el juez claramente lo tendrá en cuenta. Frases del estilo “Esta claro que el cliente colaboro siempre y el problema es solo del proveedor…”, “el proyecto nunca arranco…” (cuando existe la aceptación por mail del cliente del arranque en cuestión) son puntos a utilizar de cara a una parcialidad. Buscar en la pericial contraria palabras como nunca, siempre, nada, todo,… suelen ser puntos a estudiar.
  5. 5.       Probar y puntualizar cada evidencia que el primer perito informático reflejo. Me encuentro muchas veces que el anterior perito marca como fallo grave cuestiones que son menores. Por ejemplo, un informe, que presenta la información en un orden incorrecto. Es en este tipo de puntos donde puedo minimizar su evidencia o incluso anularla, detectando exactamente la causa del fallo o error que el otro perito justifica como gravísimo, cuando en el ejemplo se debe simplemente a una ordenación en pantalla.
  6. Evaluación del cumplimiento del documento de requisitos base del proyecto. Este punto es clave. La no existencia o la existencia del mismo es base para realmente comprobar que las afirmaciones del anterior perito tienen fundamento o bien se requieren funcionalidades que jamás se incluyeron en el mismo.
  7. Pruebas modificadas. Realmente parece increíble que un perito informático haya entrado en el código fuente de un proyecto y lo haya modificado para probar que si funciona. Esto me lo he encontrado varias veces. Cabe destacar que el perito es, en el fondo, un “observador” teniendo absolutamente prohibido basar sus afirmaciones en modificaciones de las pruebas. Si un ERP no muestra un dato adecuadamente de nada sirve, de cara a un juez, entrar en el código y cambiar aunque sea una única línea de código, pues está alterando la prueba base de la pericial.

Respecto de la información de mi cliente y de terceras partes

Teniendo delante la pericial informática contraria es fácil conversar con mi cliente de cada punto en él detallado, confirmar hechos o bien destacar errores de concepto, documentos que hablan de puntos contrarios y aceptaciones tácitas, por mail, etc. me permiten aumentar la visión global del problema, de cómo enfocar la pericial de parte de manera más efectiva.

En ocasiones, como ocurre con algunos ERP, puedes hablar no solo con el partner instalador, sino con el fabricante o bien ilustrarte con información de Internet. Por ejemplo cuando un perito subraya “este ERP no funciona” el mero hecho de informarte que está instalado en cientos o miles de clientes con éxito puede “desmontar” su afirmación. Además puedes hablar con el fabricante de la causa de ciertos problemas que el perito anterior ha subrayado, de clientes del mismo sector que tienen el producto instalado con éxito (o con fracaso) etc.

Nuevas informaciones que tu cliente te aporta y son susceptibles de ser incorporadas.

Estaría centrándome en evidencias informáticas no incluidas en la anterior pericial, de información, quizás pasada por alto (podría enlazarlo con la posible parcialidad del anterior perito) o bien simplemente no incluida por no conocimiento del anterior perito informático.

Son puntos que refuerzan mi pericial de cara a que el juez entienda más aun las razones clave de lo ocurrido. Estos pueden ser desde puntos que van completamente en dirección contraria a la anterior pericial, buenas prácticas llevadas a cabo/o ausencia por la parte contraria y/o mi parte,…

Estos puntos son muy utilizados por el juez y por tanto se que con mucha probabilidad me preguntará sobre ellos, tanto a mí como al perito de la otra parte para conocer su opinión y saber, en alguna ocasión, porque el anterior perito no lo incluyó. Pueden llegar a ser puntos diferenciales que aportan ese plus que el juez valorará.

Conclusión

La redacción y defensa de una contra pericial informática judicial y de parte es compleja, es la clave en muchas ocasiones para poder extraer información que el primer perito no incluyó o incluyó de forma parcial, sesgada o limitada.

Una contra pericial informática puede desembocar, incluso, en una tercera pericial pues el juez puede solicitarla con el objetivo que delimite las dos primeras periciales y razone cada evidencia de ambas periciales.

 

 

Luis Vilanova Blanco. Perito judicial miembro de la asociación de peritos colaboradores con la justicia con oficina en Valencia y Madrid.

e-mail: info@legalauditors.es

telf: 606954593