Contenido
Este es mi caso práctico favorito. Un conocido retailer de moda y bienes de consumo de Oriente Medio pasó de SAP ECC 6.0 a S/4HANA. Tenía unos 18.000 empleados, más de 1200 tiendas en siete países y un canal de comercio electrónico en crecimiento. Llevaba años con ECC y el 44 % de sus objetos de sistema estaban personalizados. Elegimos una conversión brownfield con rediseño selectivo. El cierre mensual pasó de alargarse hasta los fines de semana a terminar antes del almuerzo, y el código personalizado se redujo casi a la mitad.
Si gestiona un sistema ECC muy personalizado y se pregunta cuánto de él conviene trasladar, así respondió un programa a esa pregunta.
La personalización se había ido acumulando poco a poco, una corrección urgente tras otra. Cuando empezamos, incluso las actualizaciones pequeñas entrañaban riesgo. Las integraciones eran frágiles: un cambio menor en finanzas podía romper algo en las operaciones de retail. El negocio quería flexibilidad y rapidez. TI vivía apagando incendios. Ambas partes reconocieron que remaban en direcciones opuestas.
Recuerdo una sesión en la que el equipo de cadena de suministro se rio un poco al admitir que decenas de sus informes «críticos» ya casi nadie los abría. Eliminarlos fue práctico y, curiosamente, liberador.
El detonante fue el fin del mantenimiento estándar de ECC. SAP ERP 6.0 con los paquetes de mejora 6 a 8 deja el mantenimiento estándar a finales de 2027 (SAP News). Los motivos de fondo eran más profundos. Finanzas hacía extracciones manuales cada cierre mensual. Las tiendas necesitaban una visibilidad del stock que los procesos batch nocturnos no podían ofrecer. La mayor parte del esfuerzo de TI se iba en mantener vivo el código personalizado.
El SAP Readiness Check confirmó lo que sospechábamos: un sistema muy personalizado, con un trabajo de corrección considerable por delante. La Simplification Item List mostró dónde el estándar de S/4HANA ya hacía lo que antes hacía el código personalizado de ECC. Finanzas descubrió que algunos informes a medida, mantenidos durante años, ya eran redundantes. El alivio en esa reunión era evidente.
Una conversión puramente técnica solo habría trasladado los problemas hacia delante. Una reconstrucción greenfield completa habría tirado a la basura una década de configuración que funcionaba. El brownfield con rediseño selectivo era el punto medio: conservar lo que estaba sólido, limpiar lo que había que limpiar y reconstruir solo lo que estaba roto. Mi guía de migración de ECC a S/4HANA explica cómo sopesar esas opciones.
| Reto | Qué hicimos |
|---|---|
| 44 % de objetos personalizados | Negocio y TI etiquetaron cada objeto juntos: retirar, reemplazar o adaptar; puntos de control de calidad por fase |
| Integraciones frágiles | Plan de regresión que cubría POS, WMS, finanzas, RR. HH. y portales de proveedores; los vínculos punto a punto pasaron a patrones de SAP Integration Suite |
| Calidad de los datos | Responsables de datos por función con SLA; seguimiento diario de defectos; limpieza terminada antes de QA |
| Adopción en varios países | Guías de puesto por rol, recorridos de acompañamiento cerca del go-live, formación vinculada a tareas reales |
Código personalizado a gran escala
Los resultados del Readiness Check funcionaron como un filtro. Negocio y TI se sentaron juntos a etiquetar cada objeto. Algunos eran claramente redundantes, como informes que nadie recordaba haber ejecutado. Otros daban soporte a procesos de retail realmente únicos y exigían un rediseño cuidadoso. Eso obligó a los equipos a decidir en lugar de aplazar. SAP Signavio ayudó a definir los nuevos procesos frente a las mejores prácticas, y smartShift se encargó de los análisis automáticos de código y de las correcciones de poco valor, lo que reservó el tiempo de los perfiles sénior para el rediseño. Mi guía de clean core explica cómo clasifico hoy el código personalizado.
Integraciones
ECC se conectaba con los sistemas de punto de venta (POS), el sistema de gestión de almacenes (WMS), finanzas, RR. HH. y varios portales de proveedores. Montamos un plan de regresión que abarcaba todos ellos y probamos después de cada cambio de configuración importante, no solo al final. Los procesos batch nocturnos tenían que terminar antes en S/4HANA, o los informes de la mañana del almacén no estarían listos.
Calidad de los datos
Los registros duplicados de proveedores y los datos maestros obsoletos alargaron las pruebas. La solución fue estructural: un responsable de datos (data steward) en cada función, con SLA de resolución. Si los datos no estaban limpios al empezar QA, volvían al responsable. A medida que se acercaba el cutover, ensayamos las cargas de principio a fin y seguimos los defectos a diario. Esa rutina tan simple funcionó mejor que cualquier panel sofisticado, y todavía me sorprende. Mi artículo sobre por qué fracasa la migración de datos en SAP explica el patrón.
Adopción
La formación llegó a 26.000 empleados. Finanzas y las operaciones de retail tenían prioridades distintas, algo que salió a la luz en un taller temprano y cambió el diseño de la formación. Cuando la presión subió cerca del go-live, recurrimos a guías de puesto por rol y a recorridos de acompañamiento. Más tarde, una jefa de tienda dijo que la guía de dos páginas había servido más que cualquier reunión general de la compañía. La creí.
Entrega por fases con SAP Activate. Primero se migraron el núcleo financiero y la cadena de suministro, y más tarde RR. HH. y los portales de proveedores, de modo que los equipos de soporte nunca se vieron desbordados. Cada entorno tenía una sola función. El sandbox validó el camino y fijó el alcance. Desarrollo consolidó los transportes. QA ejecutó volúmenes reales de negocio y afinó los procesos batch. Preproducción fue un ensayo general de verdad. Las fechas de despliegue se alinearon con las temporadas altas y bajas del retail.
Pruebas con el negocio. Los responsables de finanzas y de cadena de suministro probaron con cierres de periodo y ciclos de promociones reales, con guiones escritos según la realidad del negocio y no según la lógica del sistema. Las ejecuciones nocturnas dejaron al descubierto problemas de tiempos. Recuerdo a un responsable de almacén sonriendo cuando la segunda ejecución salió bien tras semanas de frustración.
Ensayos de cutover. Cada tarea se cronometró, se recortó o se fusionó. Solo el simulacro ya ahorró horas que ninguna hoja de cálculo habría revelado. Los planes de recuperación cabían en una hoja, y la gente decía que esa lista sencilla reducía el estrés más que cualquier panel. Un piloto en tienda demostró la estabilidad de POS y WMS antes del despliegue general.
Hypercare. Una war room compartida entre TI y negocio, SLA claros y registros diarios de acciones. Los turnos de fin de semana rotaban y los traspasos de soporte estaban guionizados al minuto. La gente suele acordarse de las cifras. Yo me acuerdo sobre todo de la primera noche tranquila.
Un responsable de finanzas bromeó con que el sistema por fin funcionaba más rápido que la máquina de café.
Cierre financiero. Los equipos decían que el cierre mensual ya terminaba antes del almuerzo, cuando antes se alargaba hasta el fin de semana. Lo que más agradeció el CFO fue recibir sus informes mucho antes. Un responsable de finanzas bromeó con que el sistema por fin iba «más rápido que la máquina de café». Un momento así genera más confianza que cualquier presentación.
Código personalizado. Se redujo casi a la mitad, lo que disminuyó la carga de soporte a largo plazo y el riesgo de regresión en cada futura actualización.
Reporting y experiencia de usuario. Los gerentes de tienda pasaron de las antiguas pantallas de transacción a las aplicaciones de SAP Fiori. El tiempo de formación bajó porque las aplicaciones funcionaban como la gente esperaba. Un gerente lo describió como «refrescante».
Integraciones. Las conexiones de POS, WMS y finanzas se volvieron más estables y los procesos nocturnos terminaban antes.
No todo aterrizó por igual. Algunos equipos se aferraron a los informes antiguos cuando ya existían otros mejores. Algunos opinaban que los talleres eran demasiado largos y los ensayos repetitivos. Visto ahora, esos pasos eran la red de seguridad.
| Lección | Qué pasó | Qué haría la próxima vez |
|---|---|---|
| Alinear pronto | En un taller, los gerentes de tienda dijeron que sus necesidades de reporting eran muy distintas de las de finanzas. Salió a la luz pronto y ajustamos; más tarde habría estallado en el cutover | Programar sesiones de alineación estructuradas antes de que empiece el diseño |
| Empezar la revisión del código desde el primer día | Varios objetos se rehicieron bajo presión cerca del go-live | Tomar las decisiones de retirar, reemplazar o adaptar desde el arranque del proyecto |
| Hacer de los datos una tarea del negocio | Los registros duplicados de proveedores frenaron las pruebas | Nombrar en la primera semana a responsables de datos por función, con SLA |
| Ensayar más de lo que parece necesario | Un simulacro reveló conflictos de secuencia entre POS y WMS que nadie había previsto | Planificar ensayos adicionales; el último antes del go-live debería resultar aburrido |
Si el mismo programa arrancara hoy, cambiarían tres cosas. La mayoría de las empresas en esta situación miraría ahora S/4HANA Cloud Private Edition bajo RISE with SAP en lugar de quedarse on-premise. Las decisiones de retirar, reemplazar o adaptar se plantearían según los niveles A a D de clean core de SAP. El seguimiento de cambios y despliegues se haría en SAP Cloud ALM, porque Solution Manager 7.2 sale del mantenimiento estándar a finales de 2027. Los responsables de datos, los ensayos, la war room conjunta y las guías de dos páginas se quedarían exactamente como estaban. Para la parte de las personas, vea mi guía de estrategias de formación en SAP.
¿Por qué las empresas pasan de SAP ECC a S/4HANA?
El detonante es el fin del mantenimiento estándar de ECC en 2027. Las razones de más peso son operativas: reporting en tiempo real, un cierre más rápido y menos esfuerzo dedicado a mantener código personalizado e integraciones frágiles. En este caso, el negocio quería analítica de retail en vivo y un cierre mensual más corto.
¿Qué mostró el SAP Readiness Check en este caso?
Confirmó que el 44 % de los objetos estaba personalizado y que muchos llevaban años sin usarse. Eso cambió cómo se estructuró el trabajo sobre el código personalizado: primero retirar, reemplazar por estándar siempre que fuera posible y adaptar solo lo que tuviera valor real para el negocio. La Simplification Item List también mostró informes que el estándar de S/4HANA volvía redundantes.
¿Por qué elegir brownfield con rediseño selectivo?
Una conversión puramente técnica habría arrastrado todos los problemas, y una reconstrucción greenfield completa habría descartado una década de configuración que funcionaba. El rediseño selectivo conservó lo que estaba sólido, usó SAP Signavio para definir nuevos procesos allí donde el estándar podía sustituir la lógica personalizada y reconstruyó solo lo que estaba roto.
¿Qué pasa si se deja la limpieza de datos para demasiado tarde?
Las pruebas se alargan, los ensayos fallan y el go-live se retrasa. Aquí, los registros duplicados de proveedores y los datos maestros obsoletos causaron semanas de fricción en las pruebas. La solución fueron responsables de datos en cada función con SLA, y el seguimiento de la limpieza como indicador de salud del programa.
¿Cómo se gestionaron las integraciones durante la migración?
Primero se mapeó cada conexión: POS, WMS, finanzas, RR. HH. y portales de proveedores. Un plan de regresión las cubría todas, se probó tras cada cambio de configuración importante y un piloto en tienda demostró la estabilidad de POS y WMS antes del despliegue general. Aun así, un simulacro encontró un conflicto de secuencia entre POS y WMS que nadie había previsto.
¿Cómo es un buen hypercare después del go-live de S/4HANA?
Una war room compartida entre TI y negocio, con SLA claros, registros diarios de acciones e incidencias cerradas con rapidez en lugar de aparcadas en un backlog. Las guías por rol y los recorridos de acompañamiento reducen las llamadas a soporte más rápido que la formación formal. Hay que rotar los turnos de fin de semana y guionizar los traspasos para que el equipo no se agote.
Escrito por
Noel D'Costa
SAP CX para la relación con la ciudadanía en el sector público europeo
Los ciudadanos querían servicios públicos que funcionaran como la banca en línea. Cómo lo logró un organismo europeo con SAP Service Cloud, Customer Data Cloud, Emarsys y Commerce Cloud, y qué fue lo que más importó.
Negociación de un contrato ERP: un CFO de MENA ahorra 850 mil USD
La propuesta ERP de 120 páginas del CFO de un fabricante de MENA parecía sólida, pero su estructura ocultaba el riesgo. Tres semanas de revisión del SOW y de cambios en el contrato evitaron 850.000 USD antes del arranque.
SAP Ariba en el sector público de los EAU: caso práctico de compras
Un ministerio federal de los EAU pasó de las licitaciones en papel a SAP Ariba. Los ciclos bajaron entre un 30 y un 40 %, pero lo difícil fue la residencia de datos, la confianza de los proveedores y los funcionarios que siguieron con el papel.
Recuperación de un ERP en FMCG: informes unificados con SAP Analytics Cloud
Un grupo FMCG de Singapur trabajaba con Oracle mientras su negocio británico de bebidas energéticas trabajaba con SAP, y las cifras nunca coincidían. Así es como la gobernanza, el control del alcance y SAP Analytics Cloud dieron la vuelta, en seis meses, a un proyecto de informes estancado.
Siguiente paso
¿Dirige ahora mismo un programa ERP?
Si este artículo toca un programa en el que está inmerso ahora mismo, una conversación de 30 minutos suele avanzar más que otra semana de análisis interno.