Como perito judicial informático y único perito miembro de la asociación española de SAP, puedo afirmar que en el ámbito de los proyectos ERP, y muy especialmente en entornos complejos como los de SAP ERP, es relativamente habitual encontrarse con situaciones en las que un cliente, tras una implantación fallida o insatisfactoria, decide resolver la relación contractual con el primer partner y contratar a un segundo para reconducir o finalizar el proyecto. En estos escenarios surge una cuestión jurídica y técnica de enorme relevancia pericial: ¿estamos ante un proyecto nulo, es decir, inexistente desde el punto de vista funcional y contractual, o ante un proyecto no nulo, aunque defectuoso, incompleto o mal gestionado? La respuesta no puede basarse en percepciones subjetivas, sino en un análisis técnico estructurado y documentado.
Proyecto nulo
Desde el punto de vista de un perito informático especializado en ERP, el concepto de “proyecto nulo” no debe confundirse con “proyecto insatisfactorio” o “proyecto mal ejecutado”. Un proyecto podría considerarse técnicamente nulo cuando no existe ningún entregable funcional aprovechable, no hay parametrización válida en el sistema, no se ha construido ningún entorno mínimamente operativo (ni siquiera para pruebas internas), no existen desarrollos propios utilizables, y no se ha producido transferencia efectiva de conocimiento ni documentación técnica o funcional coherente. En estos casos, el sistema no permite ejecutar procesos reales de negocio, ni siquiera de forma parcial, y el esfuerzo invertido carece de valor técnico reutilizable.
Sin embargo, en la mayoría de controversias reales, especialmente en implantaciones de SAP S/4HANA o soluciones verticales sobre SAP, la situación es más matizada. Puede existir código fuente desarrollado (programas Z, ampliaciones en BTP, formularios, interfaces), parametrizaciones en determinados módulos, estructuras organizativas creadas, datos maestros cargados, integraciones parcialmente configuradas o licencias correctamente adquiridas y activas. Aunque el proyecto no haya alcanzado la fase de UAT válida o no esté en productivo, parte del trabajo técnico puede ser objetivamente aprovechable por un segundo partner. En estos casos, hablar de “proyecto nulo” desde una perspectiva pericial puede resultar técnicamente incorrecto.
Contratos, anexos,…
El análisis pericial debe comenzar siempre por la revisión exhaustiva del contrato y de sus anexos: alcance funcional, modelo de implantación (por ejemplo, Activate), definición de entregables, hitos de facturación, criterios de aceptación, SLAs, gestión de cambios y régimen de resolución contractual. Es esencial determinar si el contrato era de medios o de resultado, si se definieron KPIs objetivos, y si existía un documento de requerimientos firmado o un blueprint aprobado. La inexistencia de una definición clara del alcance no convierte automáticamente el proyecto en nulo, pero sí puede evidenciar una mala gobernanza o una corresponsabilidad en el fracaso.
A continuación, el perito debe analizar la trazabilidad entre requisitos y entregables. Esto implica revisar documentos de análisis funcional, especificaciones técnicas, listados de desarrollos, órdenes de transporte, repositorios de código, evidencias en el sistema (customizing, tablas, roles, workflows), así como la coherencia entre lo ofertado y lo realmente construido. Si, por ejemplo, se ofertó una solución estándar con pequeñas adaptaciones y finalmente se desarrollaron múltiples personalizaciones críticas sin cerrar el diseño previo, puede existir un problema de desviación metodológica, pero no necesariamente un proyecto inexistente.
Especial relevancia tiene el análisis de incidencias y tiquets. El histórico de tickets permite reconstruir la evolución real del proyecto: qué problemas se detectaron, si fueron resueltos, si existían bloqueos estructurales, si el cliente validó entregas parciales, o si se fueron acumulando incidencias sin cerrar. Un volumen elevado de tiquets abiertos no implica por sí mismo nulidad, pero sí puede evidenciar falta de control de calidad, insuficiente testing o carencias en la fase de diseño. Desde la óptica pericial, interesa especialmente verificar si las incidencias afectan al núcleo del modelo de negocio o si se trata de ajustes periféricos.
Grado de reutilización
Otro elemento crítico es la evaluación del grado de reutilización por parte del segundo partner. Si el nuevo integrador aprovecha parametrizaciones, reutiliza desarrollos, mantiene estructuras organizativas, conserva datos maestros cargados o continúa sobre la misma arquitectura técnica, resulta difícil sostener técnicamente que el primer proyecto fue nulo. Puede haber sido deficiente, económicamente desproporcionado o gestionado de forma negligente, pero la existencia de activos reutilizables implica que hubo creación de valor, aunque fuera parcial o mal encauzada.
En sede judicial, la diferencia entre proyecto nulo y proyecto no nulo tiene consecuencias económicas significativas. Si se acredita la nulidad técnica, podría justificarse una devolución prácticamente íntegra de importes abonados, al no existir contraprestación efectiva. En cambio, si se demuestra que parte del trabajo es aprovechable y ha sido integrado en la solución final, el análisis debe desplazarse hacia la cuantificación del daño: sobrecostes, retrasos, necesidad de rehacer desarrollos, pérdida de oportunidad o impacto reputacional, pero descontando el valor de lo reutilizado.
Desde la perspectiva del perito informático, la clave está en aplicar criterios objetivos y reproducibles. No se trata de valorar si el cliente está satisfecho o si el proyecto “funcionaba bien”, sino de determinar técnicamente qué existía, qué grado de completitud tenía, qué calidad presentaba, qué porcentaje del alcance contractual se ejecutó y qué parte fue efectivamente aprovechada posteriormente. Solo mediante un análisis detallado de contratos, requerimientos, desarrollos, configuraciones, documentación, actas de seguimiento y sistemas de ticketing puede establecerse con rigor la gravedad real del incumplimiento.
Conclusión
En conclusión, en el contexto de proyectos SAP fallidos que son continuados por un segundo partner, la categoría de “proyecto nulo” debe reservarse para supuestos extremos de inexistencia material de entregables utilizables. En la mayoría de los casos, el escenario es el de un proyecto no nulo pero gravemente defectuoso, incompleto o mal gobernado. La labor del perito consiste precisamente en separar la percepción de fracaso empresarial de la realidad técnica verificable, aportando al juez o a las partes un dictamen fundamentado que permita diferenciar entre inexistencia de proyecto y mala ejecución del mismo, con las correspondientes consecuencias jurídicas y económicas.
Puede contactar conmigo en el email luis.vilanova@legalauditors.es