Peritaje informático judicial en un proyecto SAP con informes contradictorios

Actuar como perito informático designado judicialmente en un proyecto SAP de gran envergadura implica una responsabilidad técnica y jurídica muy superior a la de un peritaje de parte. En este caso concreto, el juzgado me designó para analizar dos informes periciales completamente contradictorios, uno aportado por el cliente final y otro por el partner implantador. Ambos defendían tesis opuestas sobre el origen del fracaso del proyecto, en una implantación SAP que había superado ampliamente los dos millones de euros y que afectaba a una multinacional del sector de la distribución de moda con una operativa logística compleja y altamente dependiente del sistema.

Prioridad en un peritaje judicial de un ERP

Desde el primer momento, el enfoque no puede ser ni conciliador ni interpretativo. Un peritaje judicial exige desmontar los informes existentes, analizar su coherencia interna, contrastar sus afirmaciones con evidencias técnicas objetivas y, sobre todo, verificar si las conclusiones se sostienen desde el punto de vista metodológico, contractual y tecnológico. Mi trabajo no consistía en decidir quién tenía “razón”, sino en determinar qué hechos estaban acreditados, cuáles no lo estaban y qué afirmaciones carecían de sustento técnico o documental.

Uno de los puntos clave del análisis fue la revisión exhaustiva de las pruebas de validación funcional y técnica. Ambos informes afirmaban que el sistema había sido validado correctamente antes del arranque, pero ninguno aportaba una malla de pruebas sólida, estructurada y trazable. No existían evidencias claras de pruebas integrales de negocio, ni matrices de validación firmadas que cubrieran escenarios críticos reales. En particular, se detectó una ausencia grave de pruebas de estrés y de validaciones específicas sobre procesos sensibles para el cliente, como la logística inversa, devoluciones masivas y reubicación de stock, fundamentales en el sector moda. Esta carencia no es un detalle menor, sino uno de los factores que, desde un punto de vista pericial, invalida cualquier afirmación de “sistema apto para producción”.

Otro elemento determinante fue el análisis de la gestión del soporte tras el arranque. El partner sostenía que el sistema funcionaba correctamente y que los problemas eran consecuencia de un mal uso por parte del cliente. Sin embargo, al revisar los tiempos de respuesta, la organización del soporte y la ausencia de un plan de estabilización real, quedó patente que no se había gestionado adecuadamente la fase más crítica de cualquier proyecto SAP. Los tiempos de resolución eran incompatibles con una operación en producción, no existía una priorización clara de incidencias bloqueantes y se confundían errores funcionales graves con simples incidencias operativas. Desde un punto de vista pericial, esta mala gestión del soporte post go-live es un indicador claro de una implantación técnicamente inmadura.

Rendimiento del sistema como elemento clave

El rendimiento del sistema fue otro de los aspectos centrales del peritaje. Los informes de parte trataban este punto de forma superficial, pero el análisis técnico reveló problemas estructurales de rendimiento en escenarios de logística inversa, con bloqueos, tiempos de espera excesivos y degradación del sistema en momentos de carga real. Estos problemas no podían atribuirse al hardware ni al uso indebido por los usuarios, sino a un diseño deficiente de procesos, parametrización incorrecta y falta de pruebas de concurrencia. En un entorno SAP multiusuario, especialmente en una multinacional de distribución, los bloqueos y colisiones entre usuarios son un riesgo conocido que debe anticiparse y mitigarse desde el diseño, algo que claramente no se hizo.

Los bloqueos multiusuario merecieron un apartado específico en el informe judicial. No se trataba de incidencias aisladas, sino de un patrón recurrente que afectaba a procesos críticos y que evidenciaba una falta de análisis de concurrencia y de volumen. La inexistencia de pruebas de carga reales antes del arranque y la ausencia de ajustes posteriores refuerzan la conclusión de que el sistema no estaba preparado para la operativa real del cliente en el momento de su puesta en producción.

La defensa del peritaje en sede judicial es, probablemente, la fase más exigente del trabajo. No basta con tener razón técnica; es imprescindible explicar de forma clara, pedagógica y jurídicamente comprensible por qué determinados hechos son relevantes y cómo se conectan con las obligaciones contractuales y con las buenas prácticas de implantación SAP. En este caso, la contradicción entre informes obligó a desmontar afirmaciones, explicar por qué determinadas conclusiones eran técnicamente incorrectas y poner en valor la evidencia objetiva frente a opiniones o interpretaciones interesadas.

Conclusiones

Mi experiencia de más de veinticinco años en proyectos ERP y peritajes informáticos fue clave para mantener una posición sólida, independiente y técnicamente incuestionable. Un peritaje judicial no admite improvisaciones ni posicionamientos ambiguos. Cada afirmación debe poder sostenerse frente a preguntas del juez, de los abogados y de los peritos de parte, y debe apoyarse en hechos verificables, no en percepciones. En un procedimiento con una reclamación superior a los dos millones de euros, cualquier error técnico o conceptual puede tener consecuencias económicas y jurídicas muy relevantes.

Este tipo de peritajes demuestra que los proyectos SAP fallidos no se explican por un único factor, sino por una combinación de deficiencias en la validación, en la gestión del arranque, en el diseño técnico y en el soporte posterior. El valor del perito judicial reside precisamente en saber identificar esas causas, separarlas de los discursos interesados y trasladarlas al tribunal de forma clara, rigurosa y defendible. Ese es, en última instancia, el verdadero papel del peritaje informático judicial en grandes proyectos tecnológicos.