En una asesoría fiscal multinacional con sede operativa en Sevilla, la implantación de SAP se planteó como un proyecto estratégico destinado a unificar criterios contables, fiscales y de reporting entre distintas filiales internacionales. El objetivo era claro: disponer de una plataforma robusta, homogénea y alineada con los requisitos normativos de varios países, capaz de soportar el crecimiento del grupo y mejorar el control financiero. Sin embargo, el proyecto acabó convirtiéndose en un ejemplo paradigmático de cómo una mala praxis por parte del partner implantador puede derivar en un fracaso técnico, funcional y, finalmente, jurídico.
Exceso de código Z
Uno de los primeros problemas detectados fue el abuso sistemático de personalizaciones. En lugar de partir de los procesos estándar de SAP y adaptarlos de forma razonada a las necesidades reales del negocio, el partner optó por desarrollar una gran cantidad de código Z para cubrir supuestas particularidades de la asesoría. Muchas de estas personalizaciones no estaban justificadas desde un punto de vista funcional ni fiscal, duplicaban funcionalidades estándar del sistema o resolvían problemas que podrían haberse abordado con parametrización. Este enfoque no solo incrementó de forma desproporcionada el coste y los plazos del proyecto, sino que generó una dependencia técnica muy elevada respecto del partner, dificultando el mantenimiento, las actualizaciones y la trazabilidad de los procesos críticos.
Alcance funcional insuficiente
A esta sobrepersonalización se sumó una deficiente definición del alcance funcional y de los requisitos. La documentación inicial del proyecto resultó ser incompleta, ambigua y, en algunos casos, contradictoria. No existía una clara distinción entre lo que era estándar SAP, lo que debía parametrizarse y lo que realmente requería desarrollo a medida. Desde un punto de vista pericial, esto es especialmente relevante, ya que impide demostrar que las soluciones implementadas respondían fielmente a lo contratado y a las necesidades reales del cliente. En la práctica, la asesoría fiscal se encontró con un sistema que no cubría correctamente procesos clave como la consolidación fiscal, la gestión de impuestos en distintos territorios o el reporting para la dirección.
Test unitarios y de integración, la clave
Otro de los fallos críticos del proyecto fue la inexistencia de una estrategia sólida de pruebas. Las pruebas unitarias no se definieron de forma formal ni estructurada, y en muchos casos se limitaron a comprobaciones superficiales realizadas por los propios desarrolladores sobre su código Z. No se documentaron casos de prueba, no se establecieron criterios de aceptación claros y no se generaron evidencias objetivas de que cada desarrollo cumpliera con los requisitos funcionales y técnicos. Desde el punto de vista pericial, esta carencia es especialmente grave, ya que imposibilita demostrar que el sistema fue entregado en condiciones de calidad razonables.
En cuanto a las pruebas de integración, la situación fue aún más problemática. SAP debía integrarse con otros sistemas corporativos de la asesoría fiscal, así como con herramientas externas utilizadas en distintos países. Sin embargo, no se diseñó un plan de pruebas de integración completo que validara los flujos de datos de extremo a extremo. Los errores aparecieron una vez el sistema estaba en uso real, afectando a la coherencia de la información financiera y fiscal. Esto generó reprocesos manuales, riesgos de incumplimiento normativo y una pérdida significativa de confianza por parte de los usuarios clave.
Ante este escenario, la asesoría fiscal decidió encargar un informe pericial informático para analizar de forma objetiva qué había fallado en el proyecto y determinar responsabilidades. El trabajo pericial se abordó desde una perspectiva técnica y metodológica, revisando la documentación contractual, las propuestas del partner, los entregables del proyecto y el propio sistema SAP implantado. Se realizó un análisis detallado del volumen y la naturaleza del código Z, evaluando si su existencia estaba justificada o si, por el contrario, suponía una desviación respecto a las buenas prácticas y a lo contratado.
Asimismo, se analizó el ciclo de pruebas definido —o más bien, la ausencia del mismo— comparándolo con los estándares habituales en proyectos SAP de este tipo. El informe puso de manifiesto que no se habían definido correctamente las pruebas unitarias ni las de integración, ni existían evidencias suficientes de que el sistema hubiera sido validado antes de su puesta en producción. Desde un punto de vista pericial, este aspecto es clave, ya que permite concluir que el partner no cumplió con sus obligaciones de diligencia profesional.
Conclusión
El informe técnico pericial también evaluó el impacto real de estos fallos en la operativa de la asesoría fiscal multinacional. No se trataba únicamente de errores técnicos, sino de consecuencias directas en la gestión fiscal, en el cumplimiento normativo y en la toma de decisiones de la dirección. Este análisis permitió cuantificar, al menos de forma aproximada, los perjuicios derivados de un proyecto que no cumplió las expectativas ni los estándares mínimos exigibles en una implantación SAP de este nivel.
Este caso, ocurrido en Sevilla, pone de manifiesto la importancia de abordar los proyectos SAP con un enfoque riguroso, alineado con las buenas prácticas y con una clara orientación a la calidad y a la trazabilidad. Desde la óptica pericial, demuestra también el valor de un informe técnico bien fundamentado para esclarecer responsabilidades cuando un partner no cumple con lo comprometido y el cliente se ve abocado a un conflicto contractual o judicial.
Contacta con nosotros en este formulario y analizaremos su necesidad