Cuando una implantación de SAP termina en conflicto entre cliente y partner, resulta frecuente que las causas reales del problema no se encuentren en el Go-Live ni en la fase de construcción técnica, sino mucho antes. En una gran parte de los procedimientos judiciales y mediaciones en los que intervenimos como peritos informáticos especialistas en SAP, los problemas nacen durante la fase Explore de la metodología SAP Activate.
La fase Explore constituye probablemente la etapa más importante de todo el proyecto. Es el momento en el que se valida el alcance, se realizan los talleres Fit-to-Standard, se identifican los requisitos de negocio, se documentan los gaps respecto al estándar SAP, se definen las integraciones, las migraciones de datos y las posibles extensiones necesarias para cubrir las necesidades del cliente. SAP considera esta fase como un punto de control crítico antes de permitir el avance hacia Realize, mediante un Quality Gate específico que debe validar la calidad del diseño de la solución.
Desde el punto de vista pericial, una revisión exhaustiva de la fase Explore suele aportar una enorme cantidad de evidencias para determinar si el partner ha actuado diligentemente o si, por el contrario, existen errores metodológicos que han contribuido al fracaso del proyecto.
Alcance insuficientemente definido
Uno de los errores más habituales consiste en iniciar la fase Realize sin haber definido correctamente el alcance funcional.
SAP establece que durante Explore debe quedar perfectamente documentado el alcance de la solución, los procesos incluidos, los procesos excluidos y los requisitos diferenciales o gaps identificados respecto al estándar. Además, deben quedar confirmados los backlog de configuración y de desarrollos adicionales.
En numerosos proyectos analizados judicialmente encontramos documentos genéricos, incompletos o excesivamente ambiguos. Posteriormente aparecen discrepancias donde el cliente afirma que determinadas funcionalidades estaban incluidas mientras que el partner sostiene que nunca formaron parte del alcance contratado.
Desde una perspectiva pericial, la ausencia de una definición precisa del alcance constituye una de las principales fuentes de reclamaciones económicas por desviaciones presupuestarias, ampliaciones de alcance y sobrecostes.
Talleres Fit-to-Standard deficientemente ejecutados
La metodología SAP Activate se fundamenta en el principio de adaptar los procesos empresariales al estándar SAP siempre que sea posible.
Durante Explore deben realizarse talleres Fit-to-Standard donde los responsables de negocio validan cómo funcionan los procesos estándar y determinan qué adaptaciones son realmente necesarias. SAP exige además que los resultados de dichos talleres queden adecuadamente documentados y aprobados.
En muchos proyectos fallidos observamos situaciones como:
- Talleres excesivamente rápidos.
- Ausencia de usuarios clave.
- Falta de participación de responsables de negocio.
- Validaciones verbales sin documentación.
- Decisiones relevantes sin actas ni aprobaciones.
Cuando posteriormente aparecen incidencias funcionales, resulta imposible determinar qué se aprobó realmente durante el proyecto.
Para un perito SAP, la revisión de las actas de Fit-to-Standard suele ser una de las evidencias más importantes de todo el procedimiento.
Gaps funcionales no documentados
Otro error frecuente consiste en identificar necesidades especiales del cliente sin documentarlas formalmente.
SAP establece que durante Explore deben identificarse y registrarse los requisitos delta o diferencias respecto al estándar SAP.
Cuando un gap no queda documentado adecuadamente pueden producirse situaciones muy conflictivas:
- El cliente considera que la funcionalidad estaba comprometida.
- El partner considera que se trata de un cambio posterior.
- Aparecen desarrollos adicionales no presupuestados.
- Surgen reclamaciones económicas por ampliaciones de alcance.
En peritajes SAP es habitual analizar cientos de correos electrónicos, reuniones y documentos para reconstruir qué requisitos fueron realmente identificados durante Explore.
Ausencia de análisis de integración
SAP considera crítico que durante Explore quede definida la estrategia de integración con sistemas externos.
Muchas implantaciones fracasan porque se centra la atención en la parametrización del ERP y se minimiza la complejidad de las interfaces.
Entre los sistemas que suelen generar problemas destacan:
- Sistemas de nómina.
- Plataformas eCommerce.
- Sistemas de almacén (WMS).
- Herramientas de transporte.
- Sistemas de fabricación.
- Plataformas CRM.
- Soluciones de Business Intelligence.
- Aplicaciones satélite desarrolladas a medida.
Cuando las integraciones no son correctamente analizadas durante Explore aparecen posteriormente retrasos importantes, desarrollos urgentes y desviaciones presupuestarias significativas.
Análisis insuficiente de la migración de datos
SAP establece expresamente que durante Explore debe definirse la estrategia de migración de datos.
Sin embargo, en muchos proyectos observamos que la migración se aborda como una actividad secundaria cuando en realidad suele ser uno de los mayores riesgos de cualquier transformación digital.
Entre los errores más habituales encontramos:
- No analizar la calidad del dato origen.
- No identificar duplicidades.
- No depurar maestros.
- No validar estructuras organizativas.
- No estimar correctamente los volúmenes.
Cuando estos problemas aparecen en fases avanzadas del proyecto suelen provocar retrasos muy significativos e incluso aplazamientos del Go-Live.
Diseño incorrecto de estructuras financieras y organizativas
SAP considera especialmente crítica la validación temprana de elementos como:
- Company Codes.
- Plan de cuentas.
- Centros de coste.
- Centros de beneficio.
- Organizaciones de ventas.
- Canales de distribución.
- Divisiones.
Un error en estas definiciones puede obligar incluso a reprovisionar entornos completos y rediseñar configuraciones avanzadas.
Desde el punto de vista pericial, estas decisiones son especialmente relevantes porque suelen adoptarse durante Explore y generan consecuencias durante toda la vida útil del sistema.
Falta de definición de roles y responsabilidades
La documentación oficial de SAP insiste en la necesidad de establecer claramente:
- Propietarios de procesos.
- Responsables de negocio.
- Key Users.
- Órganos de decisión.
- Roles de gobierno del proyecto.
En numerosos litigios encontramos que nadie puede determinar quién tomó determinadas decisiones.
Cuando no existen responsables claramente identificados aparecen problemas como:
- Validaciones contradictorias.
- Requisitos inconsistentes.
- Cambios continuos de criterio.
- Falta de aprobación formal.
La gobernanza deficiente es una de las causas más habituales de deterioro progresivo de un proyecto SAP.
Personalizaciones excesivas y alejamiento del estándar
Los principios actuales de SAP promueven estrategias Clean Core, limitando desarrollos innecesarios y favoreciendo el uso del estándar.
En muchos proyectos fallidos observamos exactamente lo contrario:
- Multiplicación de desarrollos Z.
- Formularios personalizados innecesarios.
- Modificaciones complejas del estándar.
- Procesos heredados que se mantienen sin justificación.
Cada personalización incrementa:
- El coste del proyecto.
- El coste de mantenimiento.
- La complejidad de futuras actualizaciones.
- El riesgo de errores.
Durante nuestros peritajes analizamos si dichas personalizaciones estaban justificadas, fueron correctamente aprobadas y si existían alternativas estándar razonables.
Ausencia de gestión del cambio organizativo
La documentación de SAP exige identificar durante Explore el impacto organizativo y los cambios que experimentarán los usuarios.
Un proyecto SAP no consiste únicamente en implantar software.
Supone una auténtica transformación digital que afecta a:
- Procesos.
- Responsabilidades.
- Flujos de aprobación.
- Estructuras organizativas.
- Indicadores de rendimiento.
- Métodos de trabajo.
Cuando la organización no se prepara adecuadamente aparecen resistencias internas que posteriormente se interpretan erróneamente como fallos del sistema.
Qué revisamos los peritos SAP durante la fase Explore
Dentro de nuestra metodología pericial SAP Activate realizamos un análisis exhaustivo de la documentación generada durante Explore para determinar si la implantación se desarrolló conforme a las buenas prácticas de SAP.
Entre otros elementos revisamos:
- Actas de talleres Fit-to-Standard.
- Matrices de alcance.
- Documentos de diseño funcional.
- Backlogs de requisitos.
- Inventario de gaps.
- Estrategias de integración.
- Planes de migración.
- Definición organizativa.
- Roles y autorizaciones.
- Actas de aprobación.
- Gestión de cambios.
- Evidencias de Quality Gates.
- Riesgos identificados y mitigados.
El objetivo es determinar si el partner actuó conforme a la metodología SAP Activate y si las decisiones adoptadas durante Explore fueron adecuadas para garantizar el éxito del proyecto.
Conclusión
La experiencia acumulada en múltiples procedimientos judiciales demuestra que la mayoría de los proyectos SAP que terminan en conflicto presentan deficiencias relevantes durante la fase Explore. Una documentación insuficiente, talleres mal ejecutados, ausencia de definición de alcance, integración deficientemente analizada o una gobernanza inadecuada suelen convertirse posteriormente en retrasos, sobrecostes, incidencias funcionales y reclamaciones millonarias.
Por este motivo, cualquier peritaje SAP riguroso debe comenzar revisando en profundidad la fase Explore. Es precisamente en este punto donde se encuentran muchas de las evidencias que permiten determinar si el fracaso del proyecto fue consecuencia de una mala ejecución metodológica, de decisiones del cliente o de una combinación de ambos factores. La fase Explore no es únicamente una etapa de análisis; constituye la base probatoria sobre la que se construye el éxito o el fracaso de toda la implantación SAP. Contacte con nosotros en este formulario y le ayudaremos en su royecto.