11 Ene Peritaje informático de ERP en juicios por implantaciones fallidas: diferencias entre Odoo y SAP
Cuando una implantación de ERP fracasa y termina en un conflicto judicial, el peritaje informático deja de ser un “informe técnico” y se convierte en una prueba estructural para reconstruir lo ocurrido, objetivar responsabilidades y traducir un problema de negocio a un lenguaje que el juez pueda entender y valorar. Sin embargo, no todos los ERP se peritan igual. Odoo y SAP, por su naturaleza tecnológica, su ecosistema de partners, su forma de implantarse y su modelo de evolución, obligan a enfoques periciales distintos, aunque el objetivo final sea el mismo: demostrar hechos, con evidencias verificables, y conectarlos con obligaciones contractuales, expectativas legítimas y daños.
Diferencias de partida que condicionan todo el peritaje
La primera gran diferencia no es “técnica”, sino de modelo de implantación. En SAP, especialmente en entornos corporativos, suele existir una metodología más rígida, mayor formalización documental, y un stack tecnológico con trazabilidad y segregación más “industrializada”. En Odoo, aunque puede implantarse en grandes organizaciones, el patrón típico es más ágil, con más iteración, más personalización en Python y módulos, y una dependencia frecuente de decisiones operativas y cambios rápidos del cliente. Esto condiciona el peritaje desde el minuto uno: en SAP el perito suele reconstruir la historia a partir de procedimientos, transportes, diseños y evidencias de control; en Odoo, además de eso, muchas veces debe reconstruir un relato de decisiones, cambios y desarrollos incrementales donde el “alcance” se movió más.
En juicio, esta diferencia importa porque la discusión suele girar en torno a incumplimiento, alcance, validaciones, aceptación, control de cambios y deber de diligencia profesional. El perito debe adaptar la forma de probar cada punto al tipo de evidencias que el ERP deja, y a la cultura de implantación que suele acompañarlo.
Cuestiones clave en un peritaje de Odoo cuando el proyecto fracasa
En Odoo, el núcleo pericial suele concentrarse en cuatro focos.
El primero es la calidad del diseño funcional real frente a lo contratado. En muchos litigios de Odoo, el problema no es que “no funcione”, sino que funciona como estándar, pero no como el cliente esperaba. Por eso el perito debe verificar si hubo levantamiento de procesos suficiente, si existió documentación funcional clara, si se cerró un alcance verificable, y si las “expectativas” se convirtieron en requisitos trazables o quedaron en conversaciones y tickets.
El segundo foco es el desarrollo a medida y la modularidad. Odoo permite personalización rápida, pero eso aumenta el riesgo de deuda técnica, dependencias cruzadas y roturas en upgrades. La pericial debe analizar módulos desarrollados o adaptados, calidad del código, uso correcto de herencias, overrides, dependencias, y si las modificaciones rompieron flujos críticos (ventas, stock, contabilidad) o se hicieron sin pruebas. Aquí la evidencia típica incluye repositorios Git, historial de commits, pull requests, issues, pipelines de CI/CD si existen, y análisis del código y sus impactos.
El tercer foco es la trazabilidad de datos y configuraciones. Odoo concentra mucha lógica en parámetros, reglas de negocio y configuración de modelos. Cuando un proyecto falla, suele haber discusión sobre migración de datos, inconsistencias contables, fallos de inventario, o automatismos mal configurados. El perito debe revisar mapeos de migración, calidad de cargas, reglas de contabilidad (plan contable, impuestos, diarios), reglas de stock, unidades de medida, rutas y reaprovisionamientos, así como la coherencia entre el dato “real” y lo que el sistema muestra.
El cuarto foco es el ciclo de pruebas y aceptación. Odoo se implanta muchas veces con UAT “de facto” en el día a día. En juicio, esto es delicado: el proveedor puede alegar aceptación tácita; el cliente, que nunca validó formalmente y que “probó porque no tenía alternativa”. El perito debe buscar evidencias objetivas: actas, correos, tickets, fechas de despliegues, incidencias repetidas, y, sobre todo, si se trabajó en producción sin entornos de preproducción, sin plan de pruebas y sin criterios de aceptación.
Cuestiones clave en un peritaje de SAP cuando el proyecto fracasa
En SAP, el centro de gravedad pericial suele ser distinto y con mayor densidad de evidencias “estructuradas”.
El primer foco es la metodología de implantación y la gobernanza. En SAP es frecuente encontrar huellas claras de enfoque (por ejemplo, fases, entregables, aprobaciones), incluso aunque se haya ejecutado mal. En juicio, el perito debe analizar si la gobernanza existió y funcionó: comité de proyecto, control de cambios, gestión de riesgos, gestión de incidencias, y si se siguieron criterios razonables de planificación y validación. La falta de estas piezas en un proyecto SAP suele ser altamente relevante, porque se presupone un nivel de control acorde al coste y criticidad del sistema.
El segundo foco es la gestión de cambios y el sistema de transportes. En SAP, una implantación fallida suele tener señales claras en la cadena de transportes: qué se movió, cuándo, quién lo liberó, a qué sistemas, y con qué dependencias. El perito puede reconstruir cronológicamente el deterioro del sistema o el salto prematuro a productivo. La calidad de la segregación (desarrollo, calidad, producción) y de las autorizaciones para liberar transportes es clave, porque conecta directamente con diligencia técnica y control interno.
El tercer foco es la configuración funcional y su alineación con procesos. SAP permite enormes posibilidades de parametrización; el fracaso suele venir por desajuste entre diseño y realidad operativa, por exceso de “custom” (ABAP) o por un diseño estándar no adaptado a particularidades críticas del cliente. En pericial, se revisa la consistencia de la configuración, el modelo de datos, los flujos integrados entre módulos, y se busca evidencia de decisiones de diseño que provocaron errores de negocio. A diferencia de Odoo, el análisis suele pivotar más sobre configuración, integraciones, roles/autorizaciones y datos maestros.
El cuarto foco es el rendimiento, estabilidad e integraciones. Proyectos SAP fallidos suelen arrastrar integraciones con terceros, EDI, portales, retail, logística, etc. El perito debe evaluar si el dimensionamiento, la arquitectura, la monitorización y el rendimiento eran acordes a los volúmenes comprometidos. En SAP existe una cultura más “sistémica” de evidencias: logs, dumps, colas, monitorización, métricas históricas, que permiten probar degradaciones, caídas o saturación de forma robusta.
Diferencias prácticas al construir la prueba pericial
En Odoo, gran parte de la prueba se construye con repositorios, tickets, entornos, evidencias de despliegue, y análisis de código y configuración. El perito debe demostrar causalidad con un enfoque “forense de desarrollo”: una decisión o cambio de código provoca un fallo en un flujo, y ese fallo impacta en negocio. Es especialmente importante demostrar si el partner actuó sin control de versiones, sin revisiones, sin pruebas, o si el cliente exigía cambios continuos sin aceptar formalmente alcance y coste.
En SAP, la prueba suele apoyarse más en la reconstrucción del “ciclo de vida controlado”: transportes, sistemas, autorizaciones, documentación de blueprint, actas, evidencias de pruebas, y trazas del sistema. El perito demuestra, por ejemplo, que se liberaron cambios críticos sin pasar por calidad, que no existían segregaciones, que las autorizaciones eran inadecuadas o que el diseño aprobado no se correspondía con lo implementado. Aquí la narrativa probatoria suele ser más “gobernanza y control”, además de técnica.
Qué suele discutir cada parte en juicio según el ERP
En litigios Odoo, es muy habitual que el debate se centre en si el cliente “pidió cosas fuera de alcance”, si el partner “prometió” funcionalidades que no existen en estándar, si el desarrollo a medida estaba mal hecho o era inestable, y si la falta de formalización de entregables dejó a ambas partes sin una base clara. La pericial suele tener que definir qué era razonable exigir, qué se entregó realmente, y si la calidad del desarrollo y las pruebas fue acorde a la diligencia profesional.
En litigios SAP, el debate suele ser más pesado en “metodología, plazos, hitos, pruebas, rendimiento e integraciones”, además del clásico alcance. Las partes discuten si el retraso viene por mala planificación, por datos maestros mal gestionados, por integraciones mal especificadas, por falta de disponibilidad del negocio, o por errores graves de diseño/configuración. La pericial suele ser más amplia, con mayor volumen documental y con un componente organizativo muy marcado.
Indicadores típicos de mala praxis que el perito busca en cada caso
En Odoo, indicadores típicos son desarrollos sin control de versiones o sin entornos, cambios directos en producción, ausencia de pruebas, falta de documentación funcional, migraciones sin reconciliación y sin control de calidad de datos, y un uso excesivo de personalizaciones que bloquean upgrades y generan inestabilidad. También es frecuente detectar una dependencia excesiva de un desarrollador clave sin mecanismos de calidad.
En SAP, indicadores típicos incluyen ausencia de segregación de entornos o autorizaciones laxas, transportes liberados sin control, falta de plan de pruebas real, go-live precipitado, integraciones sin especificación técnica y sin pruebas end-to-end, dimensionamiento insuficiente, y mala gestión de datos maestros. También se analizan roles y autorizaciones porque en SAP eso es una pieza de control interno, no solo “técnica”.
Cómo se estructura un informe pericial comparativo sólido
Un informe pericial robusto en ambos mundos suele incluir una cronología factual, análisis del contrato y del alcance, análisis de metodología y control de cambios, verificación del estado funcional y técnico, evaluación de evidencias (documentación, repositorios, tickets, transportes, logs), y un apartado de causalidad que conecte fallos con impacto de negocio. La diferencia está en el peso de cada evidencia. En Odoo, el informe suele dedicar más espacio a repositorios, commits, módulos, y pruebas; en SAP, a la trazabilidad de cambios en el landscape, a la gobernanza, a la configuración y a las integraciones y rendimiento.
Conclusión: mismo objetivo, enfoques periciales distintos
Peritar una implantación fallida de Odoo y una de SAP persigue el mismo fin: demostrar qué se contrató, qué se entregó, qué falló, por qué falló y quién contribuyó causalmente al fracaso. Pero las herramientas probatorias y los puntos de ataque y defensa difieren. Odoo suele exigir un peritaje muy centrado en el “desarrollo real” y en la gestión práctica del cambio continuo. SAP suele exigir una pericial de alto volumen documental donde la gobernanza, la segregación, el sistema de transportes, la configuración y las integraciones aportan una trazabilidad técnica muy potente.
Cuando el conflicto llega a juicio, esta diferencia puede decidir el caso: no basta con saber del ERP, hay que saber qué evidencia produce cada plataforma, cómo se conserva y cómo se convierte en prueba judicial clara, reproducible y defendible en sala.
Contacta con nosotros si tienes cualquier situación que necesite un peritaje de ERP en info@legalauditors.es