¿Qué ocurre cuando una implantación SAP no termina como esperaba el cliente? ¿Cómo puede demostrar un integrador que ejecutó correctamente el proyecto? ¿Qué valor tienen los correos, actas, pruebas, tickets y cambios de alcance ante un tribunal?
Estas fueron algunas de las cuestiones que analizamos 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 buena noticia es que la jornada completa ya está disponible en YouTube.
Cuando un proyecto tecnológico se convierte en un problema jurídico
Una implantación SAP puede prolongarse durante meses o incluso años y movilizar a numerosos equipos, departamentos, consultores y proveedores.
Durante ese tiempo se toman cientos de decisiones: requisitos que cambian, desarrollos que se modifican, pruebas que se aceptan, funcionalidades que se aplazan, incidencias que aparecen y solicitudes adicionales que pueden alterar el alcance inicialmente contratado.
Mientras el proyecto funciona correctamente, muchas de estas decisiones parecen simplemente cuestiones propias de su gestión.
El problema aparece cuando el proyecto entra en conflicto.
En ese momento surge una pregunta fundamental:
¿Podemos demostrar objetivamente qué ocurrió?
Y es precisamente aquí donde comienza el verdadero trabajo pericial.
El contrato es importante, pero no cuenta toda la historia
En un litigio ERP, el contrato constituye una pieza esencial, pero normalmente no resulta suficiente para comprender todo lo sucedido.
Es necesario reconstruir la historia completa del proyecto.
¿Qué se contrató inicialmente?
¿Qué requisitos fueron definidos?
¿Qué funcionalidades se modificaron posteriormente?
¿Qué entregables fueron aceptados?
¿Qué incidencias se comunicaron?
¿Qué decisiones adoptaron los comités de seguimiento?
¿Existieron retrasos imputables al integrador o también al cliente?
¿Se produjeron ampliaciones de alcance?
¿Se realizaron correctamente las pruebas?
Responder a estas preguntas exige analizar evidencias técnicas y documentales generadas durante meses o años de proyecto.
SAP no suele ser el problema
Este fue también uno de los mensajes que consideramos importante transmitir durante la jornada.
SAP es una de las principales plataformas ERP del mercado y una tecnología extraordinariamente consolidada.
Los conflictos que posteriormente analizamos como peritos suelen estar mucho más relacionados con la propia ejecución del proyecto: alcance mal definido, expectativas diferentes entre las partes, deficiencias de gobernanza, cambios insuficientemente documentados, validaciones ambiguas o falta de trazabilidad.
Por eso, cuando hablamos de litigios SAP, normalmente estamos hablando realmente de litigios relacionados con proyectos de implantación SAP.
La diferencia es importante.
La documentación puede decidir un litigio
Un proyecto ERP genera una enorme cantidad de información.
Actas de reuniones, correos electrónicos, diseños funcionales, especificaciones, tickets, pruebas, incidencias, entregables, validaciones y solicitudes de cambio forman parte de la memoria técnica del proyecto.
Durante la jornada insistimos especialmente en la importancia de conservar estas evidencias.
Porque meses o años después resulta muy difícil reconstruir una implantación únicamente a partir de los recuerdos de quienes participaron en ella.
La documentación permite transformar afirmaciones en hechos verificables.
No basta con afirmar:
«El proyecto se retrasó por culpa del integrador».
Será necesario determinar qué hitos estaban previstos, cuándo debían producirse, qué dependencias existían, qué ocurrió realmente y qué evidencias permiten atribuir técnicamente el retraso.
Y exactamente el mismo principio se aplica al partner que pretenda demostrar que determinadas desviaciones fueron consecuencia de cambios solicitados por el cliente.
SAP Activate como mapa para reconstruir el proyecto
Otro de los aspectos tratados fue la utilidad de SAP Activate desde una perspectiva pericial.
Las fases Discover, Prepare, Explore, Realize, Deploy y Run permiten estructurar el desarrollo de una implantación y, cuando la metodología ha sido correctamente utilizada y documentada, proporcionan una referencia extraordinariamente útil para reconstruir posteriormente el proyecto.
Desde una perspectiva probatoria, esto tiene un enorme valor.
Podemos analizar qué debía ocurrir en cada fase, qué documentación debería haberse generado, qué validaciones existieron y cómo se produjo la transición entre las diferentes etapas.
Una metodología de proyecto correctamente documentada puede convertirse así en una auténtica cadena de evidencias.
Cliente y partner deben protegerse documentalmente
La jornada permitió abordar el conflicto desde las dos perspectivas.
El cliente debe ser capaz de acreditar los requisitos comprometidos, las desviaciones detectadas, las comunicaciones realizadas y las consecuencias que esas desviaciones han producido.
El partner, por su parte, debe poder demostrar el trabajo realizado, las aceptaciones obtenidas, las decisiones adoptadas conjuntamente, los cambios solicitados y las obligaciones que correspondían al propio cliente.
Existe, por tanto, una conclusión común para ambas partes:
Una buena gobernanza del proyecto es también una excelente estrategia de prevención jurídica.
Documentar adecuadamente un proyecto no debería considerarse burocracia.
Es gestión del riesgo.
¿Esperar al litigio para llamar al perito?
Probablemente sea uno de los errores más frecuentes.
Cuando una implantación comienza a presentar problemas importantes, realizar un análisis pericial preventivo puede resultar mucho más útil que esperar a que el proyecto haya fracasado definitivamente.
Permite identificar qué evidencias existen, cuáles están desapareciendo, qué incumplimientos pueden demostrarse realmente y cuáles son simples percepciones difíciles de acreditar.
También permite detectar las debilidades de nuestra propia posición antes de adoptar decisiones irreversibles.
Porque una pericial útil no debería limitarse a confirmar la versión de quien la encarga.
Debe determinar qué puede demostrarse técnicamente.
¿Tiene pruebas suficientes para acudir a juicio?
Durante la jornada presentamos nuestro Test de suficiencia probatoria, basado en una pregunta aparentemente sencilla:
Si mañana tuviera que defender este proyecto ante un tribunal, ¿podría demostrar documentalmente lo que estoy afirmando?
Para responderla hay que comprobar, entre otros aspectos, si existe documentación contemporánea al proyecto, si cada incumplimiento puede relacionarse con una obligación concreta, si puede acreditarse la relación entre incumplimiento y perjuicio y si las evidencias electrónicas conservan suficientes garantías de integridad y trazabilidad.
También es fundamental comprobar algo que a veces se olvida:
que nuestra propia documentación no contradiga nuestra versión de los hechos.
Una jornada para responsables SAP, empresas, integradores, abogados y peritos
Todos estos asuntos fueron analizados durante la jornada organizada por AUSAPE con la participación de:
- 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 experiencia jurídica y pericial permitió abordar los conflictos ERP desde una perspectiva eminentemente práctica y analizar cómo se construye —o se debilita— una reclamación a partir de las evidencias generadas durante el propio proyecto.
Jornada completa disponible en YouTube
Si participa en proyectos SAP, ya sea como cliente, integrador, consultor, responsable tecnológico, director de proyecto, abogado o perito, puede acceder ahora a la grabación completa de la jornada.
Desde Legal Auditors agradecemos nuevamente a AUSAPE la organización de esta jornada y la oportunidad de compartir nuestra experiencia en el análisis pericial de proyectos ERP.
Y, sobre todo, esperamos que su contenido sirva para recordar una idea fundamental:
En un conflicto tecnológico no basta con tener razón. Hay que poder demostrarla.
Y esa prueba, en muchas ocasiones, comienza a construirse desde el primer día del proyecto.
