Transformación hacia Clean Core · 7 de 8
Migración ECC a S/4HANA bajo principios Clean Core: RISE, Activate y Cloud ALM
En resumen
Una migración de ECC a S/4HANA alineada con Clean Core se estructura en cinco fases: evaluar el sistema actual con datos de uso reales, inventariar y clasificar el código propio, decidir el destino de cada personalización según el modelo de extensibilidad, ejecutar la conversión con el alcance ya acotado, y establecer la operación continua. SAP Activate aporta el marco metodológico, RISE with SAP el modelo comercial y de servicio, y SAP Cloud ALM las herramientas de seguimiento.
La mayor parte de lo que sale mal en una migración a S/4HANA no sale mal durante la migración. Sale mal antes, cuando se decide el alcance.
Las tres piezas y para qué sirve cada una
Se citan juntas y se confunden con frecuencia:
RISE with SAP es el envoltorio comercial y de servicio: agrupa suscripción, infraestructura, servicios gestionados y herramientas bajo un contrato. No dice cómo hacer el proyecto.
SAP Activate es la metodología: fases con entregables y puntos de control definidos. Aporta la secuencia; no toma las decisiones de arquitectura por ti.
SAP Cloud ALM son las herramientas de seguimiento del proyecto y de la operación posterior.
Tener las tres no garantiza nada si las decisiones de alcance se toman mal. Es la confusión más cara: creer que contratar RISE resuelve la transformación.
Conversión o implementación nueva
La primera decisión, y la más difícil de revertir.
| Conversión del sistema | Implementación nueva | |
|---|---|---|
| Datos e histórico | Se conservan | Migración selectiva |
| Configuración | Se conserva | Se rediseña |
| Complejidad acumulada | Se arrastra | Se deja atrás |
| Duración | Menor | Mayor |
| Impacto en el negocio | Contenido | Alto |
La conversión suele elegirse cuando los procesos actuales son válidos y el problema es tecnológico. La implementación nueva, cuando el proceso mismo es lo que se quiere cambiar.
El error consiste en elegir conversión por plazo y presupuesto, y luego esperar los beneficios de una implementación nueva.
La secuencia que funciona
1. Evaluar con datos, no con impresiones
Antes de cualquier plan hacen falta cifras: cuántos objetos propios hay, cuántos se ejecutan realmente, cuáles son modificaciones al estándar y cuáles desarrollos independientes, y qué integraciones acceden a tablas en lugar de a APIs publicadas.
SAP ofrece herramientas para levantar este inventario —el análisis de código propio y los chequeos automáticos, entre otras—. Lo relevante es que la conversación arranque con un número.
2. Retirar antes de migrar
De todo lo inventariado, una parte no se ejecuta desde hace años. Retirarlo es la actividad con mejor relación esfuerzo/beneficio de todo el proyecto: no requiere negociación con el negocio, solo evidencia de uso.
Migrar código muerto cuesta dinero dos veces: en la migración y en cada prueba posterior.
3. Clasificar lo que queda
Cada personalización superviviente se clasifica según el árbol de decisión de extensibilidad: qué lo cubre ya el estándar de S/4HANA, qué se resuelve con configuración, qué pasa a Key User Extensibility, qué se reconstruye con ABAP Cloud dentro del sistema y qué sale a BTP.
Esta clasificación es el alcance del proyecto. Hacerla después de empezar significa descubrir el alcance sobre la marcha.
4. Convertir con el alcance cerrado
Solo aquí empieza la parte técnica que la mayoría de la gente asocia con “la migración”.
5. Operación continua
Una migración termina el día del arranque; una transformación, no. Lo que determina si el core sigue limpio dentro de dos años no es cómo se hizo la conversión, sino qué reglas de decisión quedaron establecidas. Es el tema de Gobierno de extensiones.
Los tres errores que más se repiten
Tratarla como un proyecto de infraestructura. Si el éxito se mide en que el sistema arranque y todo funcione igual, la mejor migración posible es la que no cambia nada — y se habrá pagado una plataforma nueva para conservar la complejidad antigua.
Dejar la limpieza para después. La fase posterior nunca tiene el mismo presupuesto ni la misma atención de la dirección. Lo que no se limpia durante la migración, no se limpia.
Congelar la evolución del negocio durante el proyecto. Un proyecto largo con el negocio congelado acumula una lista de peticiones pendientes que se descarga íntegra el día después del arranque, casi siempre en forma de desarrollos urgentes. Y ahí vuelve la complejidad.
En una frase
El resultado de una migración se decide en el inventario, no en la conversión.
Acompañamos evaluaciones previas y decisiones de alcance. Reservar una sesión.