27 Août Peritaje informático en conflictos SAP: lo que años de litigios ERP me han enseñado
Después de años interviniendo como perito informático judicial en conflictos relacionados con implantaciones ERP, hay una conclusión que se repite una y otra vez: cuando un proyecto tecnológico termina en los tribunales, la cuestión fundamental no es únicamente quién tiene razón, sino quién puede demostrar técnicamente lo ocurrido.
Precisamente sobre esta experiencia tuve la oportunidad de hablar en la jornada «Conflictos en proyectos SAP: visión jurídica y pericial de los litigios ERP», organizada por AUSAPE (Asociación Española de Usuarios de SAP) y celebrada el pasado 8 de julio de 2026 en Madrid.
La jornada completa está ahora disponible en mi canal de YouTube, donde puede verse gratuitamente.
▶ VER LA JORNADA COMPLETA EN YOUTUBE
¿Qué hace realmente un perito informático en un litigio SAP?
Cuando recibo un asunto relacionado con una implantación SAP problemática, mi trabajo no consiste simplemente en comprobar si determinadas funcionalidades funcionan o presentan errores.
Un proyecto ERP puede haber durado meses o años, involucrado a decenas de profesionales y generado miles de documentos y comunicaciones.
El verdadero trabajo pericial consiste en reconstruir técnicamente la historia del proyecto.
¿Qué se contrató?
¿Qué requisitos se definieron?
¿Qué debía entregar el integrador?
¿Qué entregó realmente?
¿Qué aceptó el cliente?
¿Qué cambios se solicitaron durante el proyecto?
¿Quién era responsable de cada actividad?
¿Qué pruebas se realizaron?
¿Qué incidencias quedaron abiertas?
¿Quién provocó realmente los retrasos?
¿Existen evidencias que permitan demostrar todo lo anterior?
Estas preguntas son, en muchas ocasiones, mucho más importantes que comprobar simplemente si el ERP funciona.
El perito debe transformar miles de evidencias en una explicación comprensible
Una de las mayores dificultades de las periciales sobre grandes proyectos tecnológicos es el volumen de información.
Correos electrónicos, actas de comités, documentos funcionales, contratos, anexos, cronogramas, tickets, pruebas, entregables, solicitudes de cambio, incidencias o registros procedentes de herramientas de gestión pueden contener piezas fundamentales para comprender lo sucedido.
El trabajo del perito consiste en analizar y relacionar esas evidencias hasta construir una secuencia cronológica y técnicamente coherente de los hechos.
Pero existe además un segundo reto.
Todo ese conocimiento técnico debe explicarse posteriormente de forma que pueda ser entendido por abogados, jueces y tribunales que no necesariamente tienen conocimientos especializados en SAP.
Una buena pericial no debería complicar el problema.
Debería hacerlo comprensible.
La experiencia me ha enseñado que el problema rara vez es SAP
Este es un aspecto que considero especialmente importante aclarar.
Cuando hablamos de litigios SAP, puede parecer que estamos hablando de problemas relacionados con el propio producto.
Mi experiencia pericial indica algo diferente.
SAP es una plataforma ERP extraordinariamente consolidada y potente.
Los conflictos suelen aparecer alrededor de la implantación: definición del alcance, requisitos, desarrollos, planificación, cambios, responsabilidades, pruebas, migraciones, aceptación o gobernanza del proyecto.
Por eso, una de las primeras tareas del perito consiste precisamente en separar dos cuestiones completamente diferentes:
el funcionamiento de la tecnología y la ejecución del proyecto de implantación.
La documentación contemporánea tiene un valor extraordinario
Cuando analizo un proyecto que terminó hace varios años, los testimonios de las personas que participaron pueden ser importantes, pero presentan una limitación evidente: cada parte recuerda los acontecimientos desde su propia perspectiva.
Por ello, siempre concedo especial importancia a las evidencias generadas mientras estaban ocurriendo los hechos.
Un correo enviado en aquel momento.
Un acta de un comité de seguimiento.
Una incidencia registrada en el sistema.
Una prueba de aceptación.
Una solicitud de cambio.
Un documento funcional validado.
Un cronograma actualizado.
Estas evidencias permiten reconstruir lo sucedido con mucha mayor objetividad.
En el ámbito pericial existe una realidad difícil de evitar:
Lo que no se documentó durante el proyecto puede resultar extraordinariamente difícil de demostrar años después.
SAP Activate puede convertirse en una referencia pericial
Durante mi intervención en la jornada de AUSAPE expliqué también el valor que puede adquirir SAP Activate en determinados conflictos.
Cuando esta metodología forma parte de la referencia utilizada para ejecutar el proyecto, sus fases —Discover, Prepare, Explore, Realize, Deploy y Run— proporcionan una estructura especialmente útil para el análisis pericial.
El perito puede estudiar qué actividades debían realizarse, qué entregables se generaron, qué validaciones existieron y qué decisiones se adoptaron en cada momento.
Esto permite pasar de una discusión basada en opiniones a un análisis mucho más objetivo:
qué debía hacerse, qué se hizo realmente y qué evidencias permiten demostrarlo.
También analizo las actuaciones del cliente
Existe otro aspecto que considero esencial en cualquier pericial independiente.
Cuando una empresa me encarga analizar un proyecto, mi función no debería consistir simplemente en buscar argumentos contra la otra parte.
También debemos analizar críticamente las actuaciones y evidencias de quien encarga la pericial.
¿Participó correctamente el cliente en el proyecto?
¿Entregó la información necesaria?
¿Validó determinados documentos?
¿Solicitó cambios?
¿Retrasó decisiones?
¿Aceptó determinados hitos?
¿Existen correos o actas que contradigan posteriormente alguna de sus afirmaciones?
Exactamente el mismo análisis debe realizarse cuando se trabaja desde la perspectiva del integrador.
La credibilidad de una pericial depende, en gran medida, de su capacidad para diferenciar los hechos demostrables de las interpretaciones interesadas de cada parte.
El análisis pericial debería comenzar antes del juicio
Una de las recomendaciones que más repito es no esperar necesariamente a presentar una demanda para solicitar la intervención de un perito.
Cuando un proyecto comienza a deteriorarse seriamente, un análisis pericial preventivo puede ayudar a determinar qué está ocurriendo y, especialmente, qué puede demostrarse.
En esta fase todavía es posible localizar documentación, preservar evidencias, identificar desviaciones, reconstruir decisiones y advertir sobre posibles debilidades probatorias.
Además, el análisis puede proporcionar información muy valiosa para una negociación entre las partes y, en determinados casos, contribuir precisamente a evitar el procedimiento judicial.
Mi Test de suficiencia probatoria
Durante la jornada presenté también un concepto que utilizo para valorar la solidez técnica de un posible litigio: el Test de suficiencia probatoria.
Antes de acudir a los tribunales considero especialmente importante responder a cuestiones como estas:
- ¿Existen evidencias generadas durante el propio proyecto?
- ¿Puede vincularse cada supuesto incumplimiento con un requisito o compromiso concreto?
- ¿Puede demostrarse técnicamente la desviación?
- ¿Existe una relación causal entre esa desviación y el daño reclamado?
- ¿Las evidencias electrónicas presentan garantías suficientes de integridad y trazabilidad?
- ¿Puede cuantificarse objetivamente el perjuicio o el trabajo realizado?
- ¿La documentación de nuestra propia parte resulta coherente con aquello que pretendemos defender?
Si varias de estas respuestas son negativas, posiblemente exista un problema probatorio que conviene conocer antes de iniciar el litigio y no durante el procedimiento judicial.
Una jornada donde unimos la visión jurídica y la pericial
La jornada organizada por AUSAPE permitió precisamente confrontar estas cuestiones desde diferentes perspectivas profesionales.
Participamos:
- Marc Pujolàs, abogado de Deloitte Legal.
- Luis María Latasa, abogado de EJASO ETL.
- Luis Vilanova, auditor CISA, perito informático judicial y director de Legal Auditors.
La combinación de abogados especializados y experiencia pericial permitió analizar los conflictos SAP desde el punto donde realmente terminan confluyendo en un procedimiento judicial: el contrato debe interpretarse jurídicamente, pero los hechos tecnológicos deben poder demostrarse técnicamente.
La jornada completa ya está disponible
Para quienes trabajan en el ámbito de SAP, dirección de proyectos ERP, departamentos jurídicos, consultoría tecnológica, auditoría o peritaje informático, hemos publicado ahora la grabación completa de la jornada.
▶ VER LA JORNADA COMPLETA EN MI CANAL DE YOUTUBE
Después de años trabajando como perito en conflictos tecnológicos, sigo considerando que una de las mejores recomendaciones que pueden darse tanto a clientes como a integradores es muy sencilla:
Gestione cada gran proyecto tecnológico pensando que quizá algún día tendrá que explicar y demostrar ante un tercero por qué tomó cada decisión.
Probablemente nunca tenga que acudir a un tribunal.
Pero si llega ese momento, la calidad de las evidencias generadas durante el proyecto puede ser tan importante como la calidad del propio trabajo realizado.