Los proyectos de implantación de sistemas ERP, especialmente aquellos de gran envergadura como SAP, presentan múltiples desafíos técnicos y organizativos. Como perito informático designado por el juzgado en un reciente juicio, he tenido la oportunidad de analizar las conclusiones de ambas partes y ofrecer una visión independiente sobre las causas del conflicto. A continuación, comparto las principales lecciones aprendidas, manteniendo el anonimato de las partes implicadas.
La estabilización tras el arranque requiere tiempo suficiente
Uno de los errores más comunes en grandes proyectos SAP es subestimar la fase de estabilización tras el arranque (GOLIVE). En este caso, quedó claro que un periodo de estabilización de apenas dos meses era absolutamente insuficiente para un proyecto de esta magnitud, lo que derivó en una acumulación de incidencias durante semanas posteriores.
Incidencias sustanciales y su impacto en el negocio
Durante el análisis técnico, se identificaron errores bloqueantes que afectaban procesos críticos y rendimiento del sistema. Este tipo de incidencias no solo ralentizan la operativa, sino que también reflejan una baja calidad del proyecto y una ejecución deficiente de las pruebas de aceptación (UAT), especialmente en lo referente a pruebas de rendimiento y bloqueos.
Volumetría y pruebas técnicas: aspectos críticos no abordados
La falta de pruebas de volumetría, rendimiento y bloqueos fue un punto clave. En sectores con alto volumen de pedidos y logística intensiva, no anticipar estos factores puede provocar graves disrupciones operativas. En este caso, el desconocimiento o la omisión de estos ensayos técnicos por parte del equipo implantador resultó en un impacto significativo en la calidad del servicio.
Personalizaciones excesivas y alejamiento del estándar
Aunque el software estándar cubría un amplio porcentaje de los procesos de negocio, el proyecto derivó en numerosas personalizaciones. Esto dificultó enormemente la estabilización posterior al arranque, y contribuyó al bajo grado de calidad funcional, fiabilidad y eficiencia detectado en el análisis de calidad del software.
Evaluación contractual y reparto de responsabilidades
El contrato marco contenía una distribución de responsabilidades claras tanto para el implantador como para el cliente. Sin embargo, se evidenció un incumplimiento generalizado de los compromisos de calidad, cronograma y pruebas. También se detectaron carencias en el soporte post-arranque, cuya duración y recursos asignados fueron claramente insuficientes.
La firma de acuerdos intermedios bajo presión
Uno de los momentos clave del caso fue la firma de un acuerdo intermedio, bajo una fuerte dependencia operativa del cliente respecto al proveedor. Este acuerdo redujo plazos de garantía y formalizó pagos adicionales por servicios que en realidad no se habían prestado con anterioridad, lo que se considera un error de gestión grave desde la perspectiva de ingeniería de software.
Formación, UAT y validación: una responsabilidad compartida
Aunque la formación a usuarios se realizó parcialmente, la validación de desarrollos y la ejecución de pruebas UAT no fue completa. Esta falta de pruebas impidió detectar errores críticos antes del GOLIVE. Si bien el cliente también es responsable de validar el sistema, el proveedor debió advertir de los riesgos de omitir pruebas esenciales en fases tempranas.
El soporte técnico y la gestión de incidencias
Durante el soporte post-arranque, se resolvieron cientos de incidencias, lo cual denota un esfuerzo considerable. Sin embargo, al finalizar este periodo aún quedaban más de 300 problemas abiertos. La gestión de incidencias no fue profesional ni conforme a estándares como ITIL, tanto por parte del proveedor como por la falta de supervisión activa del cliente.
El traspaso del proyecto a un nuevo equipo
El relevo en la gestión del proyecto por parte de un nuevo proveedor fue posible gracias a un traspaso de conocimiento que, aunque no óptimo, permitió la continuidad del proyecto sin bloqueos graves. Esto demuestra que los problemas existentes eran atribuibles a deficiencias previas más que a una mala transferencia.
Conclusiones finales sobre la calidad del proyecto
Aplicando métricas objetivas de calidad como el estándar ISO/IEC 25001, el resultado del proyecto evaluado fue insatisfactorio, especialmente en aspectos clave como adecuación funcional, rendimiento y fiabilidad. En definitiva, se trató de un proyecto de baja calidad, con incidencias sustanciales no resueltas y decisiones contractuales que favorecieron una resolución parcial y precipitada.