Recuperación de proyectos SAP: rescatar un programa desviado

La recuperación de proyectos SAP consiste en detener una migración o implementación que se ha desviado, averiguar qué es realmente cierto sobre ella y replanificar a partir de esa verdad. La primera semana decide si funciona: evalúe el estado del programa, revise el diseño y evalúe lo que realmente está desplegado en el sistema.

Respuesta corta: si esas tres comprobaciones coinciden entre sí y con el plan, el programa necesita un empujón, no un rescate. Si no coinciden, ningún esfuerzo adicional sobre el plan actual lo arreglará, y necesita una recuperación formal con una nueva línea base.

Este artículo trata de ese diagnóstico y de lo que viene después. Es una pieza de mi guía de migración de ECC a S/4HANA, que cubre rutas, plazos y fechas límite. Aquí la pregunta es más concreta: su programa tiene problemas, ¿y ahora qué?

La mayoría de los programas que van con retraso no necesitan un rescate. Necesitan que se tomen decisiones más rápido, que se libere a un usuario clave o que se exija a un proveedor que cumpla una fecha. Eso es un empujón.

Un rescate es otra cosa. Las señales salen de las mismas tres comprobaciones que hago en la primera semana, y la señal es sencilla: el estado, el diseño y lo desplegado no coinciden entre sí ni con el plan.

Algunos patrones que yo trataría como señales de rescate:

1. El estado está en verde, el sistema no. Los informes dicen que la mayor parte de la construcción está hecha, pero el sistema de pruebas no puede ejecutar un order to cash básico.
2. El diseño está firmado, la construcción lo ignora. La configuración se hizo a partir de notas de los talleres, no del diseño aprobado.
3. El plan tiene una fecha de go-live, nadie sabe explicar cómo llegar a ella. Las pruebas, las cargas de datos y los ensayos de cutover no tienen un hueco realista.
4. El alcance no deja de crecer. La lista WRICEF (informes, interfaces, conversiones, ampliaciones, formularios y workflows) sigue aumentando mucho después de la fase Explore.

Cualquiera de estos se puede arreglar con un empujón. Dos o más a la vez, normalmente no.

La primera semana sirve para averiguar qué es cierto. No para arreglar, no para buscar culpables y no para escribir un plan nuevo. Evalúo tres cosas, en este orden: el estado, el diseño y lo que realmente está desplegado.

Esto es lo que cubre cada comprobación y lo que le dice un desacuerdo:

Comprobación	Qué miro	La pregunta que responde	Si no coincide con las demás
Estado del programa	Plan, informes de estado, registro RAID, solicitudes de cambio abiertas, gasto frente a presupuesto	¿Qué cree el programa sobre sí mismo?	Los informes son optimistas o están desconectados de la entrega
Diseño	Diseño de procesos de negocio, resultados de Fit-to-Standard, lista WRICEF, decisiones de diseño abiertas	¿Qué se le prometió al negocio?	La construcción se ha alejado de lo acordado, o el diseño nunca se terminó
Lo desplegado	Los sistemas de desarrollo y de pruebas, la configuración, los transportes, el código a medida, las cargas de datos hasta la fecha	¿Qué existe realmente hoy?	Se ha informado de avances sobre trabajo que no está en el sistema

La tercera comprobación es la que se saltan la mayoría de las revisiones. Significa sentarse delante del sistema y ejecutar procesos, no leer documentos sobre el sistema.

Los informes de estado y los documentos de diseño son afirmaciones. El sistema es la evidencia.

Quién debe hacer las comprobaciones

Las personas que escribieron los informes de estado no deberían ser las que los verifican. No es una acusación. Es la misma razón por la que los auditores no auditan su propio trabajo.

Yo pondría a alguien independiente del socio de implementación al frente de la primera semana, con acceso completo a los sistemas y derecho a hablar con cualquiera del programa. Si eso no es posible, al menos haga que el socio le muestre el sistema desplegado en vivo y no en diapositivas.

En 2018 trabajé en la recuperación de un programa de aviación. Los módulos se habían desplegado, pero no se había configurado nada a partir de los requisitos del negocio.

Esa es la situación que las tres comprobaciones de la primera semana existen para sacar a la luz. Unos módulos desplegados no son lo mismo que un diseño que funciona, y solo mirar dentro del sistema muestra la diferencia.

Las aerolíneas vinculan estrechamente mantenimiento, compras y finanzas, así que una brecha en un área se propaga. Explico cómo encaja SAP en ese sector en mi página sobre SAP para aviación.

En los 21 programas SAP que he dirigido o rescatado, el mayor error que veo es no planificar bien al inicio de la implementación. Un rescate suele ser esa planificación que faltó, hecha tarde y bajo presión.

Hay otras dos causas que aparecen una y otra vez:

1. El proveedor controla el alcance. Cuando el integrador de sistemas escribe el alcance, describe lo que el integrador piensa entregar. Las brechas llegan después como solicitudes de cambio, con el precio que pone el mismo proveedor.
2. El código a medida se desborda. En mi experiencia, el código a medida es la fase de la migración que más a menudo se desborda, y también el costo oculto que más se olvida.

La parte presupuestaria de todo esto, incluido por qué la fase Explore es donde se disparan los costos, la trato en mi artículo sobre por qué los proyectos SAP se salen del presupuesto. No la repetiré aquí.

El control débil es el otro hilo común. Si el programa nunca tuvo un ritmo semanal de seguimiento, escalado y control de cambios, el rescate tiene que implantarlo. Mi guía de planificación y control de proyectos SAP establece esa cadencia con responsables.

Una vez que sabe qué es cierto, la recuperación tiene una secuencia clara. Saltarse un paso suele significar hacer el rescate dos veces.

Secuencia de recuperación de un programa SAP

1. 01

   Diagnosticar

   Estado, diseño y lo desplegado, contrastados entre sí.

2. 02

   Recuperar el alcance

   Alcance en manos del cliente, congelado, con cada cambio presupuestado.

3. 03

   Nueva línea base

   Un único plan nuevo construido sobre evidencias, con la contingencia de su lado.

4. 04

   Fases con quality gates

   Un quality gate al final de cada fase restante.

5. 05

   Ensayar y hacer el cutover

   Ensayos completos antes de confirmar una fecha de go-live.

1. Recupere la responsabilidad sobre el alcance

Antes de que nadie replanifique, decida quién es responsable del alcance. Si la respuesta sigue siendo el proveedor, el plan nuevo fracasará igual que el antiguo.

Escriba el alcance del lado del cliente, compárelo con lo desplegado y congélelo. A partir de ahí, cada cambio es una decisión con precio y con un responsable.

2. Fije una nueva línea base una sola vez, sobre evidencias

Una recuperación tiene una única nueva línea base, no una serie de pequeños retrasos. Constrúyala a partir de lo que muestra el sistema, no de lo que esperaba el plan antiguo.

Vuelva a estimar primero el código a medida, porque es de donde vienen los desbordamientos con más frecuencia. Después los datos, ya que la migración de datos supone entre el 30 y el 40 % del esfuerzo y suele ir con retraso en un programa con problemas.

Mantenga una contingencia del 10 al 20 % de su lado, que solo se libere contra riesgos concretos. Mi artículo hermano sobre el costo de migración a S/4HANA explica qué mueve las cifras.

3. Ponga un quality gate al final de cada fase

Los programas con problemas suelen haber pasado de una fase a otra por fechas y no por evidencias. Corríjalo.

En SAP Activate, la fase Explore ejecuta talleres Fit-to-Standard, y los requisitos delta aprobados pasan al product backlog de Realize. Si el programa salió de Explore sin un diseño terminado, vuelva atrás y termínelo. SAP Cloud ALM admite quality gates como puntos de control con listas de verificación, visibles en la vista general del proyecto, así que el gate no tiene que vivir en una hoja de cálculo.

4. Ensaye antes de comprometerse con una fecha

En una conversión brownfield planifico tres conversiones de prueba antes del cutover. Los programas con problemas suelen recortar los ensayos para ganar tiempo, lo que traslada el riesgo al fin de semana del go-live.

El downtime de cutover que he visto va de un fin de semana a una semana. Un programa rescatado debería conocer su cifra por un ensayo, no por una estimación.

5. Compruebe la fecha límite con la que realmente trabaja

Para SAP ERP 6.0 en los enhancement packages 6 a 8, el mantenimiento estándar termina el 31 de diciembre de 2027, con mantenimiento ampliado opcional hasta finales de 2030 con un recargo de dos puntos porcentuales (SAP News). Una recuperación que lleve una migración de ECC más allá de 2027 debería presupuestar abiertamente el mantenimiento ampliado.

No deje que la fecha de 2027 fuerce un go-live que los ensayos no respaldan. Un go-live tardío cuesta tarifas de mantenimiento. Uno fallido cuesta mucho más.

Un rescate suele plantear la cuestión de si mantener al integrador de sistemas actual. A veces sustituir al socio es lo correcto. A menudo el problema mayor es cómo se montó el programa, y un socio nuevo lo hereda.

Estas son las preguntas que yo haría antes de decidir:

1. ¿Pueden mostrarnos el sistema desplegado, en vivo, frente al diseño firmado? No un entorno de demostración ni diapositivas.
2. ¿Qué objetos WRICEF están construidos, probados y transportados, y cuáles solo figuran como terminados en los informes?
3. ¿Cuál es su diseño de alto nivel para terminar, y a qué referencias podemos llamar en las que hayan recuperado un programa como el nuestro? Las referencias y el diseño de alto nivel son las dos cosas que pido a cualquier socio antes de firmar.
4. ¿Qué necesitan de nosotros que no están recibiendo? Las decisiones pendientes y los usuarios clave a tiempo parcial suelen ser la mitad de la historia.
5. Para clientes de RISE with SAP: ¿qué problemas corresponden a SAP y no al socio, y quién los escala?

La señal de alarma es la misma que me hace descartar a un socio en la selección: las respuestas genéricas. Si el plan de recuperación podría aplicarse a cualquier empresa, no se escribió para la suya. Mi guía para elegir un socio de migración a S/4HANA cubre el lado de la selección.

Si el programa nunca tuvo una evaluación adecuada del sistema de origen, hágala ahora. El SAP Readiness Check analiza su sistema actual, y SAP recomienda ejecutarlo en producción para obtener una imagen precisa del uso real. Mi artículo sobre el SAP Readiness Check y la evaluación de migración explica lo que no detecta, empezando por los objetos a medida.

Reserve medio día con su director de programa y su responsable de SAP, y pídales que le muestren tres cosas una al lado de la otra: el último informe de estado, el diseño firmado y el sistema de pruebas ejecutando un proceso de negocio completo. Si las tres cuentan la misma historia, dé un empujón. Si no, inicie una recuperación formal antes del próximo comité directivo.

Si quiere una opinión independiente sobre un programa que se ha desviado, ayudo a las organizaciones exactamente con este tipo de diagnóstico. Puede reservar una llamada conmigo.

¿Qué es la recuperación de proyectos SAP?

La recuperación de proyectos SAP es el trabajo de volver a poner bajo control una implementación o migración SAP que se ha desviado. Empieza con un diagnóstico del estado del programa, del diseño y de lo que realmente está desplegado; después recupera la responsabilidad sobre el alcance, fija una única nueva línea base y añade quality gates a las fases restantes.

¿Cómo sé si mi proyecto SAP necesita un rescate?

Compare tres cosas: lo que dicen los informes de estado, lo que dice el diseño firmado y lo que realmente está desplegado en el sistema. Si coinciden entre sí y con el plan, el programa necesita un empujón. Si no coinciden, más esfuerzo sobre el plan actual no lo arreglará y necesita una recuperación formal.

¿Qué debería ocurrir en la primera semana de la recuperación de una implementación SAP?

Solo diagnóstico. Evalúe el estado del programa, revise el diseño y evalúe lo que realmente está desplegado, idealmente bajo la dirección de alguien independiente del socio de implementación. No escriba el plan nuevo hasta que esas tres comprobaciones estén hechas.

¿Debemos sustituir a nuestro socio de implementación SAP durante una recuperación?

No automáticamente. Pida al socio que muestre el sistema desplegado frente al diseño firmado, y que le dé un diseño de alto nivel para terminar con referencias de recuperaciones similares.

Si las respuestas son genéricas, es una señal clara para cambiar. Si el problema real es la responsabilidad sobre el alcance o las decisiones pendientes de su lado, un socio nuevo lo heredará.

¿Por qué se desvían las migraciones a SAP S/4HANA?

La causa de fondo más común que veo es no planificar bien al inicio de la implementación. Dejar que el proveedor controle el alcance es otra, y el código a medida es la fase que más a menudo se desborda. La migración de datos, que supone entre el 30 y el 40 % del esfuerzo, también suele ir con retraso.

¿Llevará una recuperación nuestra migración de ECC más allá de la fecha límite de 2027?

Puede que sí. El mantenimiento estándar de SAP ERP 6.0 en los enhancement packages 6 a 8 termina el 31 de diciembre de 2027, y el mantenimiento ampliado opcional llega hasta finales de 2030 con un recargo de dos puntos. Presupueste el mantenimiento ampliado en lugar de forzar un go-live que sus ensayos no respaldan.