31 Ago Peritaje informático de proyectos SAP: cómo analizar un conflicto ERP y convertirlo en evidencia ante un tribunal
Los conflictos derivados de grandes implantaciones ERP presentan una dificultad particular: para determinar qué ha ocurrido no basta con analizar el estado final del software. Es necesario reconstruir un proyecto que puede haberse desarrollado durante meses o años, con decenas de participantes, miles de comunicaciones, cambios de alcance, decisiones funcionales, pruebas, incidencias y entregables.
Esta fue precisamente la perspectiva que abordamos 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 8 de julio de 2026.
La sesión, en la que tuve la oportunidad de aportar mi experiencia como auditor CISA y perito informático judicial especializado en conflictos tecnológicos y ERP, está ahora disponible íntegramente en nuestro canal de YouTube.
▶ VER LA JORNADA COMPLETA EN YOUTUBE
[INSERTAR ENLACE AL VÍDEO]
¿Qué debe determinar realmente un perito en un conflicto SAP?
Cuando una implantación SAP termina en conflicto, es habitual encontrar afirmaciones aparentemente sencillas:
«El sistema no funciona.»
«El proyecto se entregó con retraso.»
«El integrador no cumplió lo contratado.»
«El cliente cambió continuamente el alcance.»
«Las funcionalidades estaban terminadas, pero el cliente no las validó.»
Desde una perspectiva pericial, ninguna de estas afirmaciones debería aceptarse automáticamente.
El trabajo del perito consiste precisamente en transformar esas afirmaciones en cuestiones técnicamente verificables.
Si se afirma que existe un retraso, habrá que determinar cuál era la planificación acordada, qué hitos existían, cómo evolucionaron, qué dependencias afectaban al calendario y qué parte era responsable de cada una de ellas.
Si se afirma que una funcionalidad no fue entregada, habrá que identificar el requisito original, comprobar si formaba parte del alcance contratado, analizar su diseño, desarrollo y pruebas y determinar si existió posteriormente alguna aceptación.
Y si el integrador sostiene que el cliente modificó el alcance, habrá que localizar las correspondientes solicitudes de cambio y analizar cuándo se produjeron, quién las solicitó y qué impacto tuvieron sobre coste y planificación.
La pericial convierte opiniones en hechos susceptibles de ser demostrados.
Reconstruir la historia del proyecto
Una pericial SAP puede asemejarse, en determinados aspectos, a una investigación técnica.
Cuando el perito comienza su trabajo, el proyecto normalmente ya ha terminado o se encuentra gravemente deteriorado.
Por ello, una de las primeras tareas consiste en reconstruir cronológicamente qué ocurrió.
Contrato y anexos.
Oferta técnica.
Planificación.
Kick-off.
Requisitos.
Diseños funcionales.
Desarrollos.
Migraciones.
Pruebas.
Incidencias.
Solicitudes de cambio.
Comités de seguimiento.
Aceptaciones.
Puesta en producción.
Cada uno de estos elementos permite reconstruir una parte de la historia.
El objetivo es poder establecer una línea temporal objetiva del proyecto que permita comprender cómo se pasó de la situación inicial al conflicto.
El alcance: uno de los principales campos de batalla
En mi experiencia pericial en proyectos ERP, uno de los aspectos que requiere mayor atención es determinar qué estaba realmente incluido en el alcance contratado.
Durante un proyecto pueden surgir necesidades que inicialmente no estaban contempladas.
El cliente puede entender que una determinada funcionalidad estaba implícitamente incluida.
El integrador puede considerar que constituye un desarrollo adicional.
Cuando estas diferencias no se formalizan correctamente, el conflicto puede aparecer meses después.
Por ello, el perito debe intentar reconstruir la trazabilidad:
Contrato → requisito → diseño → desarrollo → prueba → aceptación.
Cuando esta cadena puede reconstruirse documentalmente, resulta mucho más sencillo determinar qué ocurrió.
Cuando existen importantes vacíos documentales, el análisis se vuelve considerablemente más complejo.
SAP Activate como referencia metodológica
Durante la jornada de AUSAPE analizamos también el valor que puede adquirir SAP Activate dentro de una pericial.
Sus fases —Discover, Prepare, Explore, Realize, Deploy y Run— permiten estructurar el ciclo de vida del proyecto.
Desde una perspectiva pericial, la metodología puede resultar especialmente interesante porque permite formular preguntas objetivas.
¿Qué debía ocurrir en cada fase?
¿Qué entregables estaban previstos?
¿Qué documentación debía generarse?
¿Qué validaciones correspondían al cliente?
¿Qué responsabilidades tenía el integrador?
¿Qué decisiones permitieron avanzar a la siguiente fase?
Cuando SAP Activate forma parte de la metodología adoptada en el proyecto, puede convertirse en una referencia relevante para evaluar la ejecución y reconstruir posteriormente lo ocurrido.
La prueba de aceptación puede ser determinante
Uno de los momentos más importantes de cualquier implantación ERP es la aceptación.
En un procedimiento judicial puede existir una diferencia enorme entre afirmar que una funcionalidad fue entregada y poder demostrar que fue probada y aceptada.
Por ello, dentro de una pericial resulta necesario analizar cuidadosamente las pruebas realizadas.
Qué casos de prueba existían.
Quién los ejecutó.
Qué resultados se obtuvieron.
Qué incidencias aparecieron.
Cuáles fueron corregidas.
Qué incidencias quedaron pendientes.
Y, especialmente, quién aceptó finalmente el resultado.
Una aceptación formal puede tener un enorme valor probatorio.
Pero también deben analizarse las circunstancias en las que se produjo esa aceptación y qué alcance tenía exactamente.
Correos, Jira, actas y herramientas de proyecto: la verdadera memoria de la implantación
Una de las principales fuentes de evidencia en una pericial ERP es la documentación contemporánea al proyecto.
Los correos electrónicos pueden demostrar cuándo se comunicó una incidencia.
Las actas pueden acreditar qué decisiones adoptó un comité.
Los tickets pueden reconstruir la evolución de un problema.
Las herramientas de gestión pueden demostrar cuándo se asignó una tarea, cuándo cambió de estado o quién intervino.
Los repositorios documentales pueden contener diferentes versiones de requisitos o diseños.
Y herramientas como Jira, Azure DevOps, SAP Solution Manager u otros sistemas de gestión del proyecto pueden contener miles de registros relevantes.
Por eso resulta fundamental preservar las evidencias electrónicas cuando comienza a aparecer un conflicto.
La pericial debe analizar también a quien la encarga
Este es uno de los principios que considero fundamentales.
Una pericial técnicamente sólida no debería construirse buscando únicamente errores de la parte contraria.
Si el cliente encarga la pericial, también deben analizarse sus actuaciones.
¿Entregó los datos cuando correspondía?
¿Participó en las pruebas?
¿Validó documentos?
¿Solicitó cambios?
¿Retrasó decisiones?
¿Dispuso de los recursos internos comprometidos?
¿Aceptó hitos que posteriormente cuestiona?
Y si la pericial se realiza para el integrador, debe aplicarse exactamente el mismo criterio.
¿Cumplió la planificación?
¿Documentó correctamente los cambios?
¿Existieron desviaciones?
¿Se realizaron las pruebas previstas?
¿Las funcionalidades entregadas cumplían realmente los requisitos?
La independencia técnica del perito exige analizar las evidencias aunque algunas no favorezcan a la parte que ha solicitado el informe.
Del incumplimiento al daño: demostrar la causalidad
Detectar una desviación no significa automáticamente demostrar un daño.
Este es otro aspecto fundamental del análisis pericial.
Puede haberse producido un retraso, pero será necesario determinar qué consecuencias provocó realmente.
Puede existir una funcionalidad defectuosa, pero habrá que evaluar su impacto.
Puede haberse requerido contratar otro proveedor, repetir una migración, mantener sistemas anteriores o dedicar recursos adicionales.
Una pericial completa debe intentar establecer una cadena lógica:
Obligación → incumplimiento → evidencia → consecuencia → daño.
Cuanto más sólida sea esta cadena, mayor será la capacidad de explicar técnicamente la reclamación.
La evidencia debe poder defenderse ante un tribunal
No basta con disponer de miles de documentos.
También debemos poder explicar su procedencia y fiabilidad.
Por ello, en determinadas periciales resulta necesario analizar cuestiones relacionadas con integridad, autenticidad, metadatos y cadena de custodia de las evidencias electrónicas.
El perito debe poder explicar de dónde procede una determinada evidencia, cómo fue obtenida y por qué puede considerarse técnicamente fiable.
Esta cuestión adquiere especial importancia cuando determinados correos, registros o documentos constituyen elementos esenciales para reconstruir el proyecto.
No espere a que el proyecto haya fracasado
Una de las recomendaciones que trasladamos durante la jornada fue precisamente la conveniencia de realizar un análisis pericial preventivo cuando empiezan a aparecer desviaciones importantes.
Esperar a que el proyecto haya terminado completamente puede provocar la pérdida de evidencias.
Personas que abandonan la organización.
Correos que dejan de estar disponibles.
Accesos a herramientas que se cancelan.
Repositorios que se modifican.
Entornos que se eliminan.
Información que queda en poder de proveedores.
Realizar un análisis temprano permite preservar evidencias y, además, conocer la verdadera fortaleza técnica de nuestra posición.
En ocasiones, esta intervención puede incluso facilitar una negociación y evitar que el conflicto termine judicializándose.
El Test de suficiencia probatoria
Durante mi intervención en AUSAPE presenté también un Test de suficiencia probatoria destinado a formular una pregunta fundamental antes de iniciar un procedimiento:
¿Tenemos realmente pruebas suficientes para demostrar nuestra versión del proyecto?
Entre otras cuestiones, conviene comprobar:
- ¿Disponemos de documentación generada contemporáneamente al proyecto?
- ¿Podemos vincular cada incumplimiento alegado con una obligación, requisito o entregable concreto?
- ¿Existe evidencia objetiva de la desviación?
- ¿Podemos determinar quién tenía la responsabilidad sobre esa actividad?
- ¿Existe una relación causal demostrable entre la desviación y el perjuicio?
- ¿Podemos cuantificar técnicamente el daño?
- ¿Las evidencias electrónicas presentan garantías suficientes de integridad y trazabilidad?
- ¿Nuestra propia documentación resulta coherente con la posición que pretendemos defender?
Este análisis previo puede cambiar completamente la estrategia de un procedimiento.
Abogados y peritos deben trabajar conjuntamente
La jornada organizada por AUSAPE permitió precisamente combinar las dos perspectivas necesarias para abordar estos conflictos.
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.
El abogado determina la estrategia jurídica, interpreta el contrato y plantea las consecuencias legales.
El perito analiza técnicamente el proyecto y determina qué hechos pueden demostrarse mediante evidencias objetivas.
En litigios tecnológicos complejos, ambas perspectivas deben trabajar coordinadamente.
Vea la jornada completa sobre conflictos SAP
La grabación completa de «Conflictos en proyectos SAP: visión jurídica y pericial de los litigios ERP» ya está disponible en nuestro canal de YouTube.
Una sesión especialmente dirigida a empresas usuarias de SAP, CIO, responsables de sistemas, directores de proyecto, integradores, consultores SAP, departamentos jurídicos, abogados y profesionales relacionados con litigios tecnológicos.
▶ VER LA JORNADA COMPLETA EN YOUTUBE
Después de años interviniendo como perito informático en conflictos relacionados con proyectos ERP, considero que existe una recomendación especialmente importante tanto para clientes como para integradores:
Gestione y documente el proyecto como si algún día tuviera que reconstruirlo ante un tercero que no estuvo presente.
Probablemente ese momento nunca llegue.
Pero si aparece un conflicto, la diferencia entre una afirmación y un hecho demostrable estará, casi siempre, en la calidad de las evidencias que se hayan conservado.