Una implantación SAP puede durar meses o incluso años y afectar a áreas críticas como finanzas, logística, compras, ventas, recursos humanos o producción.
Durante ese proceso se realizan numerosas pruebas antes de que el sistema llegue a producción. Sin embargo, cuando el proyecto termina en una disputa entre cliente y partner, una pregunta aparece con frecuencia:
¿el sistema fue realmente probado y aceptado antes de ponerse en marcha?
La respuesta puede resultar determinante para establecer qué ocurrió y dónde comenzaron los problemas.
¿Qué son las pruebas de aceptación?
Las pruebas de aceptación, habitualmente conocidas como UAT —User Acceptance Testing—, permiten comprobar si el sistema responde a las necesidades reales del negocio antes de su utilización definitiva.
No se trata únicamente de verificar que una pantalla funciona o que el usuario puede iniciar sesión.
El objetivo es comprobar procesos completos.
Por ejemplo, una empresa puede necesitar verificar que un pedido se genera correctamente, actualiza el stock, produce la entrega correspondiente, genera la factura y contabiliza la operación sin errores.
Si alguno de esos pasos falla, el proceso de negocio puede quedar comprometido aunque técnicamente determinadas partes del sistema funcionen.
Probar no es lo mismo que aceptar
Esta diferencia puede parecer pequeña, pero tiene una gran importancia en un procedimiento pericial.
Que se hayan realizado pruebas no significa necesariamente que el cliente haya aceptado el sistema.
Una prueba puede finalizar con incidencias pendientes, errores considerados críticos o funcionalidades todavía incompletas.
Por este motivo, resulta esencial conservar información como:
- casos de prueba realizados;
- usuarios que participaron;
- fecha de ejecución;
- resultado obtenido;
- incidencias detectadas;
- nivel de gravedad asignado;
- correcciones realizadas;
- nuevas pruebas posteriores;
- y documento final de aceptación.
Sin esta trazabilidad, reconstruir posteriormente el estado real del proyecto puede ser complicado.
El problema de las incidencias pendientes
Es habitual que un proyecto llegue a su fecha prevista de salida a producción con incidencias todavía abiertas.
Esto no significa necesariamente que el sistema no pueda ponerse en funcionamiento.
La cuestión está en conocer qué tipo de incidencias permanecían pendientes.
No tiene la misma importancia un pequeño problema visual que un error capaz de impedir la facturación, alterar inventarios o generar datos contables incorrectos.
En un análisis pericial, clasificar correctamente estas incidencias puede ayudar a determinar si la salida a producción fue razonable o si se asumió un riesgo excesivo.
¿Quién decidió el Go-Live?
Cuando un proyecto presenta problemas después de su puesta en marcha, cliente y proveedor pueden ofrecer versiones muy diferentes.
El cliente puede afirmar que el sistema no estaba preparado.
El partner puede sostener que el cliente autorizó expresamente el paso a producción.
Aquí adquieren especial relevancia las actas de reuniones, correos electrónicos, informes de situación y decisiones de los órganos de gobierno del proyecto.
El peritaje debe reconstruir quién conocía los riesgos existentes y quién participó en la decisión final.
Aceptar con reservas también importa
En ocasiones, el cliente firma una aceptación pero incluye determinadas reservas.
Por ejemplo, puede aceptar provisionalmente el sistema dejando pendientes varias funcionalidades o condicionando la aceptación definitiva a determinadas correcciones.
Estas situaciones deben analizarse con especial atención.
Una firma no siempre implica que el proyecto estuviera completamente terminado.
Hay que estudiar qué decía exactamente el documento y qué trabajos continuaron realizándose después.
Cuando no existe documentación suficiente
Uno de los problemas más frecuentes aparece cuando gran parte del proyecto se gestionó mediante conversaciones informales.
Reuniones sin actas, decisiones por teléfono o incidencias comunicadas sin herramientas de seguimiento pueden dificultar mucho la reconstrucción posterior.
En esos casos, el perito puede recurrir a otras fuentes de evidencia:
registros del sistema, herramientas de gestión de incidencias, repositorios de documentación, versiones de configuraciones, transportes SAP, correos electrónicos o evidencias del funcionamiento real del sistema.
El objetivo es establecer una cronología técnica lo más objetiva posible.
Las pruebas también permiten analizar responsabilidades
El análisis UAT puede revelar problemas muy diferentes.
Puede mostrar requisitos incorrectamente implementados, falta de pruebas por parte del cliente, errores que no fueron corregidos, cambios introducidos a última hora o decisiones de puesta en producción adoptadas pese a conocer determinados riesgos.
Por eso, el peritaje no debería partir de la idea de que el fallo pertenece necesariamente a una sola parte.
En proyectos complejos, las responsabilidades pueden estar repartidas.
La mejor prueba es la que se conserva durante el proyecto
Esperar a que aparezca un litigio para reconstruir las pruebas de aceptación suele ser demasiado tarde.
Los proyectos SAP deberían conservar una trazabilidad clara desde el principio: requisitos, pruebas, incidencias, correcciones, decisiones y aceptaciones.
Esta documentación no solo mejora la gestión del proyecto.
También permite demostrar posteriormente qué ocurrió realmente.
Porque cuando un proyecto SAP termina en conflicto, una de las preguntas fundamentales será siempre la misma:
¿el sistema estaba realmente preparado para ser aceptado y pasar a producción?
¿Prefieres que el próximo artículo se centre en contratos y responsabilidades del partner o en errores técnicos frecuentes durante una implantación SAP?
Contáctanos en info@luisvilanova.es