Cuando una implantación SAP termina en desacuerdo entre cliente, integrador o proveedor tecnológico, determinar qué ha ocurrido no siempre resulta sencillo. Los proyectos SAP suelen extenderse durante meses o incluso años y generan una enorme cantidad de documentación, decisiones técnicas, modificaciones de alcance, incidencias y comunicaciones.
En este contexto, el peritaje informático SAP permite analizar técnicamente el proyecto y aportar evidencias que ayuden a determinar las causas de los problemas y, cuando sea posible, las responsabilidades asociadas.
Pero ¿qué revisa realmente un perito cuando recibe un proyecto SAP que ha terminado en conflicto?
El contrato y el alcance del proyecto
Uno de los primeros elementos que deben analizarse es el alcance acordado entre las partes.
El contrato, las propuestas técnicas, los anexos, los documentos de alcance y las posteriores modificaciones permiten establecer qué debía entregar el proveedor y bajo qué condiciones.
En proyectos complejos es frecuente que aparezcan discrepancias entre lo inicialmente contratado y lo que finalmente se esperaba del sistema.
Por este motivo, el perito debe diferenciar claramente entre requisitos originales, ampliaciones posteriores y trabajos adicionales.
Los Change Requests y cualquier documento utilizado para modificar formalmente el alcance adquieren aquí especial relevancia.
La metodología utilizada durante la implantación
El siguiente paso consiste en reconstruir cómo se desarrolló el proyecto.
Dependiendo de sus características, pueden haberse empleado metodologías como SAP Activate, modelos tradicionales o metodologías híbridas.
El análisis puede incluir hitos, planificación, asignación de responsabilidades, entregables, reuniones de seguimiento y procedimientos utilizados para validar cada fase.
No se trata únicamente de comprobar si existía una metodología definida, sino de determinar si realmente se aplicó y si las desviaciones quedaron documentadas.
Los requisitos funcionales
Una implantación SAP debe responder a determinadas necesidades de negocio.
Por ello, el perito puede revisar documentos funcionales, especificaciones, diseños, configuraciones y desarrollos para comprobar si la solución implementada correspondía con los requisitos acordados.
Una cuestión fundamental consiste en determinar si el supuesto fallo procede realmente del software o de una diferencia entre lo solicitado, lo diseñado y lo finalmente desarrollado.
Esta distinción puede resultar determinante en un procedimiento judicial.
Desarrollos y personalizaciones
Los desarrollos específicos constituyen otro punto relevante.
SAP permite adaptar determinados procesos mediante configuraciones y desarrollos personalizados. Sin embargo, cuanto mayor es la personalización, mayor puede ser también la complejidad técnica y de mantenimiento.
En una investigación pericial puede ser necesario estudiar determinados desarrollos Z, interfaces, integraciones, parametrizaciones o modificaciones específicas.
El objetivo es comprobar si funcionaban conforme a los requisitos establecidos y si pudieron contribuir a las incidencias denunciadas.
Migración y calidad de los datos
La migración de información desde sistemas anteriores es una de las fases más delicadas de cualquier implantación.
Datos incompletos, duplicados, inconsistentes o incorrectamente transformados pueden provocar numerosos problemas después de la puesta en producción.
El perito puede analizar los procedimientos de migración, las reglas de transformación, las pruebas realizadas y las validaciones efectuadas por las partes.
También debe determinarse quién tenía la responsabilidad sobre la calidad de los datos de origen y quién debía comprobar el resultado de la migración.
Las pruebas realizadas antes del Go-Live
Antes de poner un sistema SAP en producción deberían realizarse diferentes pruebas para comprobar su funcionamiento.
Las evidencias de testing permiten conocer qué se verificó, qué incidencias fueron detectadas y cuáles permanecían abiertas cuando se autorizó la salida a producción.
En un conflicto resulta especialmente relevante estudiar las pruebas de integración, pruebas de usuario, UAT, pruebas de rendimiento y documentos de aceptación.
También debe analizarse quién aprobó el Go-Live y qué información tenía disponible cuando tomó esa decisión.
Tickets e incidencias
Los sistemas de gestión de incidencias pueden convertirse en una fuente de evidencia muy importante.
Los tickets permiten reconstruir qué problemas aparecieron, cuándo fueron comunicados, su gravedad, quién debía resolverlos y cuánto tiempo permanecieron abiertos.
El análisis cronológico puede mostrar además si determinadas incidencias eran aisladas o si existía un problema recurrente que no estaba siendo solucionado adecuadamente.
Correos, actas y comunicaciones
Una parte importante de la historia de un proyecto se encuentra fuera de SAP.
Correos electrónicos, actas de reuniones, herramientas colaborativas y comunicaciones entre los equipos pueden ayudar a reconstruir decisiones y advertencias realizadas durante la implantación.
Por ejemplo, puede resultar relevante acreditar que un proveedor advirtió de un determinado riesgo o, por el contrario, que el cliente comunicó reiteradamente un problema sin obtener una solución adecuada.
Estas evidencias deben analizarse preservando su integridad, autenticidad y trazabilidad.
Logs y evidencias técnicas
Cuando el conflicto está relacionado con el funcionamiento del sistema, puede ser necesario recurrir a evidencias técnicas.
Logs, registros de modificaciones, configuraciones, usuarios, transportes entre entornos o información relativa a determinadas operaciones pueden ayudar a determinar qué ocurrió realmente.
El perito debe evitar basar sus conclusiones únicamente en declaraciones de las partes cuando existen registros técnicos que permiten contrastarlas.
La cronología completa del proyecto
Una de las tareas más importantes del peritaje consiste en convertir miles de documentos y registros dispersos en una cronología comprensible.
¿Qué se contrató? ¿Cuándo aparecieron los primeros retrasos? ¿Qué cambios se solicitaron? ¿Qué incidencias estaban abiertas? ¿Quién autorizó determinadas decisiones? ¿Qué sucedió después del Go-Live?
Reconstruir esta secuencia permite comprender las relaciones de causa y efecto.
De la documentación a las conclusiones periciales
El objetivo de un peritaje SAP no es decidir jurídicamente quién tiene razón. Esa función corresponde, en su caso, al tribunal.
La labor del perito consiste en aportar un análisis técnico objetivo, trazable y sustentado en evidencias.
En proyectos SAP conflictivos, rara vez existe un único documento que explique por sí solo lo sucedido. Las conclusiones suelen surgir de relacionar contratos, requisitos, desarrollos, pruebas, incidencias, comunicaciones y registros técnicos.
Por ello, cuanto antes se identifiquen y preserven las evidencias del proyecto, mayores serán las posibilidades de reconstruir de forma fiable qué ocurrió.
Cuando una implantación SAP termina en conflicto, la documentación técnica deja de ser únicamente documentación de proyecto y puede convertirse en una pieza fundamental de la prueba pericial.