En el ámbito del peritaje informático de proyectos SAP solemos centrar el debate en el alcance funcional, en los BBP mal definidos, en las pruebas UAT inexistentes o en los incumplimientos contractuales del partner integrador. Sin embargo, existe una dimensión que con frecuencia queda en segundo plano y que, en sede judicial, puede resultar determinante: la base tecnológica sobre la que se ha construido y ejecutado el sistema SAP.
La ejecución de SAP y SAP S/4HANA sobre plataformas como Red Hat Enterprise Linux (RHEL), con automatización mediante Ansible y despliegues híbridos o multicloud, no es un mero detalle técnico. Es una decisión estratégica que impacta directamente en la estabilidad, la seguridad, la escalabilidad y, en última instancia, en la responsabilidad contractual de las partes. Cuando un proyecto fracasa, la infraestructura deja de ser invisible y pasa a convertirse en objeto de análisis pericial.
La infraestructura como elemento contractual implícito
En muchos contratos de implantación SAP, la infraestructura se describe de forma genérica: “entorno certificado por SAP”, “arquitectura cloud compatible” o “sistema operativo soportado”. Sin embargo, no siempre se detalla cómo esa infraestructura se ha dimensionado, configurado, automatizado o securizado. En un litigio, la cuestión clave es determinar si el fallo es funcional, metodológico o estructural.
Plataformas empresariales como RHEL se presentan en el mercado como entornos robustos, estables, con alta interoperabilidad y capacidad multicloud, integrando herramientas de automatización y mecanismos avanzados de seguridad como SELinux, control de acceso centralizado o perfiles de cumplimiento tipo OSCAP. Desde un punto de vista pericial, lo relevante no es la promesa comercial, sino si esas capacidades fueron realmente implementadas, configuradas y explotadas correctamente en el proyecto concreto.
Cuando el problema no es SAP, sino la base
En procedimientos judiciales relacionados con SAP IS-U, S/4HANA o entornos de alta criticidad, es habitual encontrar alegaciones cruzadas: el cliente sostiene que el sistema es inestable y no está listo para producción; el integrador argumenta que el software funciona, pero que la infraestructura del cliente no cumple los requisitos.
Aquí es donde el análisis técnico debe descender al detalle. ¿Se configuró adecuadamente el sistema operativo? ¿Se aplicaron parches de seguridad sin comprometer la estabilidad? ¿Se utilizaron mecanismos de automatización para garantizar repetibilidad en los entornos DEV, QAS y PRD? ¿Se diseñó correctamente la arquitectura híbrida o multicloud? ¿Se documentó la trazabilidad de cambios en el sistema base?
Una plataforma como RHEL ofrece herramientas para minimizar reinicios, gestionar vulnerabilidades, automatizar configuraciones y facilitar migraciones entre nube y centro de datos. Si, pese a ello, el entorno presenta caídas recurrentes, bajo rendimiento o problemas de escalabilidad, el perito debe analizar si estamos ante un defecto de diseño, una mala parametrización o una gestión negligente de la infraestructura.
Automatización y repetibilidad como prueba pericial
En un juicio, la repetibilidad es oro. Si un entorno puede reconstruirse automáticamente siguiendo playbooks versionados, se reduce el margen de error humano y se facilita la demostración técnica de que el sistema es consistente. Si, por el contrario, el proyecto depende de configuraciones manuales no documentadas, sin control de versiones ni trazabilidad, el riesgo técnico y jurídico se dispara.
Uno de los argumentos más sólidos en entornos empresariales modernos es la automatización. La utilización de plataformas como Red Hat Ansible Automation Platform permite desplegar entornos SAP de forma repetible, estandarizada y documentada. Desde el punto de vista probatorio, esto es crucial.
En más de un peritaje hemos comprobado cómo la ausencia de automatización ha provocado divergencias entre entornos que imposibilitan una UAT válida o generan incidencias que el integrador no sabe reproducir. La tecnología puede ofrecer estabilidad y ahorro de costes —incluso estudios de mercado hablan de retornos de inversión superiores al 400% y reducciones significativas del TCO—, pero si no se implementa con rigor metodológico, esas ventajas quedan en papel.
Seguridad y cumplimiento: del discurso a la evidencia
La seguridad es otro eje crítico. Las plataformas empresariales actuales integran mecanismos avanzados de mitigación de vulnerabilidades, control criptográfico, confinamiento de aplicaciones y herramientas de cumplimiento normativo. Sin embargo, en un peritaje no basta con que la tecnología lo permita; debe acreditarse que se configuró correctamente.
En proyectos SAP sometidos a marcos regulatorios exigentes —sector financiero, utilities, telecomunicaciones o entornos sujetos a normativa como ENS, NIS2 o requisitos internos de compliance—, la falta de configuración adecuada del sistema base puede generar brechas de seguridad o incumplimientos normativos que derivan en responsabilidad contractual.
El perito informático debe analizar logs, políticas de acceso, configuraciones de seguridad, ciclos de parcheo y evidencias de cumplimiento. Si el partner prometió una arquitectura segura, resiliente y preparada para el futuro, esa promesa debe contrastarse con configuraciones reales, no con presentaciones comerciales.
Escalabilidad y rendimiento: ¿limitación técnica o mala planificación?
Otro punto recurrente en litigios SAP es el rendimiento. El cliente alega que el sistema no soporta la carga real de usuarios o transacciones; el integrador responde que el dimensionamiento aprobado era inferior.
Plataformas como RHEL destacan por su capacidad de integración, su núcleo optimizado, sistemas de archivos robustos y herramientas de monitorización avanzada, además de soluciones de optimización como Red Hat Lightspeed. Pero el rendimiento final depende de cómo se haya diseñado la arquitectura, configurado los recursos y planificado el crecimiento.
En el análisis pericial es fundamental revisar documentos de sizing, actas de comité, informes de rendimiento, pruebas de estrés y decisiones de arquitectura. Muchas veces el problema no es la tecnología elegida, sino la ausencia de una gobernanza adecuada del proyecto.
Conclusión: la infraestructura también se perita
El mundo del peritaje informático de SAP no puede limitarse a revisar contratos, ofertas y desarrollos ABAP. La base tecnológica es parte integral del sistema y, por tanto, susceptible de análisis técnico y jurídico.
Cuando un proyecto SAP fracasa, el debate no debe quedarse en si el módulo FI o SD estaba bien parametrizado. Debe extenderse a la arquitectura, al sistema operativo, a la automatización, a la seguridad y a la escalabilidad. La promesa de estabilidad, rendimiento y ahorro de costes debe contrastarse con evidencias técnicas.
En peritajesap.es defendemos un enfoque integral: analizamos la capa funcional, la capa metodológica y la capa tecnológica. Porque en un procedimiento judicial no basta con decir que SAP no funciona. Hay que demostrar por qué no funciona, quién tomó cada decisión técnica y si esas decisiones fueron diligentes, proporcionadas y acordes con el estado del arte.
La infraestructura no es un mero soporte. En muchos litigios, es la pieza clave que explica el resultado del proyecto.
Contacta con nosotros en este formulario y le ayudaremos en su necesidad