Cuando una implantación de SAP S/4HANA acumula retrasos, incidencias, sobrecostes o discrepancias sobre el alcance, la empresa suele empezar a plantearse una posible reclamación. Sin embargo, antes de discutir responsabilidades conviene hacer algo mucho más básico: reconstruir documentalmente cómo se ejecutó el proyecto.
Esta fase resulta especialmente importante antes de iniciar un MASC —medio adecuado de solución de controversias—. Llegar a una negociación con la documentación adecuada permite sustituir percepciones y recuerdos por evidencias verificables.
En un proyecto SAP, los documentos pueden explicar mucho más que las reuniones.
Antes de negociar, hay que reconstruir el proyecto
En numerosos conflictos tecnológicos se repite el mismo patrón.
El cliente afirma que determinados procesos no funcionaban correctamente, que el alcance inicialmente contratado cambió o que el sistema salió a producción sin estar suficientemente probado. El partner, por su parte, puede sostener que existieron cambios solicitados por el cliente, falta de disponibilidad de usuarios clave o aprobaciones dadas durante el proyecto.
Sin documentación resulta difícil comprobar qué ocurrió realmente.
Por eso, antes del MASC puede ser conveniente realizar un requerimiento formal de información que permita responder preguntas esenciales:
¿Quién aprobó cada decisión?
¿Qué cambios se introdujeron respecto al alcance inicial?
¿Qué pruebas se realizaron antes del Go-Live?
¿Qué riesgos estaban abiertos cuando se decidió arrancar?
¿Quién aceptó las desviaciones?
La respuesta debería encontrarse en los artefactos del proyecto.
SAP Activate como marco de referencia
Cuando el contrato establece que la implantación se desarrollará conforme a SAP Activate, la metodología puede convertirse en una referencia fundamental para el análisis pericial.
SAP Activate estructura los proyectos en distintas fases y contempla actividades, entregables, validaciones y mecanismos de control asociados a ellas.
Esto permite realizar una comparación entre dos realidades:
lo que debía haberse realizado conforme al marco metodológico acordado y lo que realmente puede acreditarse mediante documentación.
Desde el punto de vista pericial, esa diferencia puede resultar muy relevante.
Documentación de preparación y gobierno
La primera parte del requerimiento debería centrarse en cómo se definió y organizó inicialmente el proyecto.
Entre otros documentos, puede resultar necesario solicitar:
- oferta técnica y económica y sus anexos;
- alcance contractual y funcional;
- matriz de responsabilidades;
- acta de constitución del proyecto;
- planificación inicial y posteriores replanificaciones;
- composición del equipo de implantación;
- actas de comités de dirección y seguimiento;
- registro de riesgos;
- documentación de los controles o cierres de fase.
Las distintas versiones del cronograma son especialmente interesantes. Permiten comprobar cuándo comenzaron las desviaciones y qué motivos se utilizaron para justificar cada nueva fecha.
Diseño funcional y Fit-to-Standard
La fase de diseño permite comprobar cómo se trasladaron las necesidades del negocio a SAP.
Conviene solicitar las evidencias de los talleres Fit-to-Standard, las diferencias identificadas respecto al estándar, las decisiones de diseño y las desviaciones aprobadas.
También pueden resultar relevantes:
- diseño de la solución;
- especificaciones funcionales y técnicas;
- desarrollos personalizados;
- definición de datos maestros;
- estructuras financieras;
- estrategia de pruebas;
- peticiones de cambio.
Este último elemento puede ser decisivo cuando existen controversias sobre facturas de evolutivos o trabajos considerados posteriormente fuera de alcance.
Un coste adicional debería poder relacionarse con una necesidad identificada, una petición concreta y algún mecanismo de autorización.
Pruebas: uno de los puntos críticos
En muchos peritajes SAP, la documentación de pruebas constituye una de las principales fuentes de evidencia.
No basta con saber que después del Go-Live existieron numerosas incidencias. Hay que analizar qué había ocurrido antes.
Por ello pueden solicitarse:
- planes y estrategias de testing;
- guiones de prueba;
- resultados de pruebas unitarias e integradas;
- pruebas de aceptación de usuario;
- pruebas de interfaces;
- pruebas de migración;
- registro de defectos;
- evidencias de resolución;
- aceptaciones finales.
La cronología resulta particularmente importante.
Comparar la fecha en que terminaron las pruebas con la fecha prevista para la salida a producción puede revelar si existió tiempo suficiente para corregir los defectos detectados.
Migración, cutover y decisión de Go-Live
La salida a producción debería dejar también un rastro documental claro.
Entre las evidencias a revisar pueden encontrarse los ciclos de migración, conciliaciones, plan de cutover, resultados de los ensayos previos y la decisión formal de Go/No-Go.
Desde una perspectiva pericial interesa conocer qué información tenía disponible la dirección del proyecto cuando autorizó el arranque.
Si existían defectos abiertos, riesgos críticos o excepciones, debería poder determinarse quién los conocía y bajo qué criterios fueron aceptados.
También importa cómo se solicita la documentación
Un requerimiento útil no debería limitarse a enumerar documentos.
Conviene pedir los archivos en su formato original siempre que sea posible, conservando metadatos, fechas y versiones. En documentos que requieran aceptación debe solicitarse la versión efectivamente aprobada y su evidencia asociada.
Cuando la información se encuentre en plataformas como SAP Cloud ALM, Solution Manager, Jira u otras herramientas de gestión, puede ser necesario pedir exportaciones completas y no simples capturas de pantalla o listados parciales.
También resulta recomendable solicitar que, cuando un documento no pueda aportarse, se indique expresamente si nunca fue elaborado o si no se dispone actualmente de él.
La ausencia documental puede ser relevante para el análisis.
La documentación como base del peritaje SAP
El objetivo no consiste en acumular cientos de archivos.
Se trata de reconstruir de forma verificable cómo se gobernó, diseñó, construyó, probó y puso en producción el sistema.
Esa reconstrucción permite afrontar un MASC con una posición técnica mucho más sólida y, si posteriormente existe procedimiento judicial, facilita que el perito pueda fundamentar sus conclusiones en evidencias y no únicamente en declaraciones de las partes.
En Peritaje SAP analizamos la documentación de proyectos de implantación y elaboramos requerimientos adaptados al contrato, al alcance y a la metodología aplicable.
Si existe un conflicto con una implantación SAP, revisar las evidencias antes de iniciar el MASC puede marcar la diferencia entre negociar sobre opiniones o negociar sobre hechos.
Contáctanos en luis@luisvilanova.es