Intro
Los programas brownfield de S/4HANA suelen presentarse como migraciones técnicas controladas: una ruta de conversión definida, un calendario seguro por parte del integrador y un business case basado en optimización de licencias, transición a cloud y reducción de riesgo ERP.
Doce o dieciocho meses después, la conversación puede ser muy distinta: presupuestos de remediación, retrasos en cutover, problemas de datos sin resolver, controles de cambio y preguntas incómodas sobre por qué finanzas, supply chain u operaciones siguen usando workarounds sobre el nuevo core.
El business case rara vez se equivoca al identificar la necesidad de modernizar el ERP. El riesgo está en subestimar lo que realmente cuesta una conversión cuando código a medida, calidad de datos, integración, pruebas y cambio operativo chocan bajo presión de calendario.
Resumen ejecutivo
Los sponsors ejecutivos deberían tratar un brownfield de S/4HANA como una transformación de negocio con columna vertebral técnica, no como un proyecto técnico con envoltorio de negocio.
El riesgo financiero se concentra en tres áreas:
1. Código a medida que se cuenta, pero no se entiende
2. Datos que deben migrarse, pero no tienen propiedad de negocio financiada
3. Decisiones de cutover que se aplazan hasta que ya no queda margen para negociar
Antes de liberar una inversión relevante, la dirección debería pedir evidencia de que la decisión sobre el código a medida está vinculada a criticidad de negocio, que la migración de datos tiene responsables ejecutivos fuera de IT y que el gobierno de cutover define quién puede parar, aplazar o reducir alcance antes del go-live.
Sin esos controles, los programas pueden parecer financiados sobre el papel mientras generan coste futuro mediante controles de cambio, remediación, disrupción operativa y daño reputacional.
El código a medida es donde se esconde el optimismo
Todo entorno SAP brownfield arrastra años de objetos a medida, interfaces, informes, ampliaciones y workarounds. Muchos se construyeron por buenas razones. Algunos ya no sirven. Otros protegen silenciosamente ingresos, cumplimiento, precios, reporting o compromisos con clientes.
Las herramientas técnicas pueden identificar y contar código a medida. No pueden decidir de qué sigue dependiendo el negocio. Esa valoración requiere que responsables de proceso, finanzas, operaciones, cumplimiento y arquitectura estén en la misma conversación.
El riesgo es asumir que una única ola de remediación será suficiente, para descubrir más tarde que extensiones aparentemente “simples” soportan rappels, reporting estatutario, operaciones de almacén o controles de cierre mensual.
La dirección debería esperar un modelo claro de decisión:
1. Retirar
2. Sustituir por estándar
3. Reconstruir o reimplementar
4. Mantener con un plan de mantenimiento financiado
Cada categoría necesita un responsable, una visión de coste, una fecha de decisión y una consecuencia si la decisión se retrasa.
La migración de datos es un problema de liderazgo
La migración de datos suele describirse como una actividad técnica. En realidad, es un problema de liderazgo con ejecución técnica.
Los planes de migración pueden listar objetos, volúmenes, cargas de prueba y ciclos de reconciliación. La pregunta cara es si los datos son suficientemente buenos para operar el negocio después del go-live. Clientes, productos, proveedores, precios, partidas financieras abiertas, activos e inventario pueden arrastrar años de inconsistencias del entorno legacy.
La dirección debería cuestionar tres puntos desde el principio:
1. ¿Quién firma la calidad de datos por dominio?
2. ¿Qué ocurre si un dominio no cumple la ventana de limpieza?
3. ¿La ejecución paralela, reconciliación o soporte adicional de negocio está financiado, o simplemente asumido?
Si la respuesta es “IT limpiará los datos”, el programa probablemente arrastra riesgo de negocio oculto. IT puede mover datos. El negocio debe asumir si esos datos son completos, correctos, utilizables y seguros para operar.
El gobierno de cutover supera a los fines de semana heroicos
Los planes de cutover suelen verse convincentes en los comités de seguimiento. La prueba real llega cuando defectos, problemas de datos, brechas de integración y dudas de preparación del negocio compiten contra una fecha fija de go-live.
Bajo presión, el alcance puede deslizarse hacia hypercare sin un registro claro de decisión. Los workarounds se aceptan. Los controles manuales se multiplican. Los equipos de soporte heredan decisiones de diseño no resueltas. La dirección escucha que el go-live se ha conseguido, mientras el negocio sigue pagando la estabilización.
Los ejecutivos deberían acordar de antemano los puntos de decisión de cutover antes de las últimas semanas:
1. ¿Qué problemas obligan a mover la fecha?
2. ¿Qué problemas obligan a reducir alcance?
3. ¿Quién tiene autoridad para tomar esa decisión?
4. ¿Qué conjunto mínimo de procesos debe funcionar el día uno?
5. ¿Qué debe ser cierto para que el negocio siga siendo legal, atienda a clientes, cobre y cierre los libros?
Un buen modelo de gobierno de cutover no es pesimismo. Es una protección frente a tomar las decisiones más caras cuando la organización está cansada, políticamente comprometida y con pocas opciones.
Conclusión práctica para la dirección
La pregunta correcta para la dirección no es “¿Es técnicamente posible la conversión a S/4HANA?”. La pregunta más útil es “¿Entendemos dónde aparecerán el coste, la propiedad y el riesgo operativo cuando el programa esté bajo presión?”.
Antes de aprobar un programa brownfield de S/4HANA, los equipos directivos deberían preguntarse:
1. ¿Qué objetos a medida son críticos para el negocio y quién ha aprobado su tratamiento futuro?
2. ¿Qué dominios de datos tienen más probabilidad de bloquear el go-live y quién los lidera fuera de IT?
3. ¿Qué supuestos se están haciendo sobre limpieza, reconciliación, pruebas y disponibilidad del negocio?
4. ¿Qué riesgos de cutover nos harían retrasar en lugar de forzar la fecha?
5. ¿Qué evidencia demostrará que el negocio puede operar de forma segura el día uno?
La revisión independiente de arquitectura es más valiosa en el primer tercio del programa, no en el ensayo final. Es entonces cuando los sponsors todavía tienen margen para cuestionar supuestos del integrador, corregir workstreams infrafinanciados y evitar que una migración controlada se convierta en un ejercicio largo y caro de recuperación.