El Costo Oculto de seguir haciendo las cosas como siempre
El mayor costo de tu proyecto SAP no está en las licencias — está en defender cómo se hacía antes. Las migraciones a S/4HANA exponen algo que nadie quiere decir en voz alta: muchos procesos que se customizaron durante años no eran buenas prácticas. Eran workarounds. Y migrarlos cuesta el doble.
Hay una conversación que ocurre en casi todos los proyectos de migración a SAP S/4HANA y que pocas veces aparece en las presentaciones de kickoff. Sucede cuando alguien del equipo técnico revisa un desarrollo Z que lleva 12 años funcionando y pregunta: ¿por qué se hace así?
La respuesta más frecuente es: "siempre se hizo así."
Esa frase es, en muchos casos, el verdadero punto de partida del sobrecosto.
El problema no es el sistema viejo. Es lo que se construyó encima.
SAP ECC fue durante décadas una plataforma robusta. Pero su flexibilidad tuvo un costo: permitió que cada empresa construyera sus propias soluciones a problemas que SAP ya tenía resueltos en estándar. Reports personalizados que duplican funcionalidad nativa. Interfaces que mueven datos por fuera de los flujos transaccionales. Validaciones escritas en ABAP que hoy podrían resolverse con parametrización.
Nada de eso era necesariamente un error en el contexto de su época. Pero en el contexto de una migración Brownfield a S/4HANA, cada uno de esos desarrollos es una decisión pendiente: ¿lo migramos tal como está, lo adaptamos al estándar, o lo reemplazamos?
El costo de migrar el workaround
Cuando una empresa decide mantener sus desarrollos "como siempre", el proyecto de migración se convierte en un ejercicio de conservación de deuda técnica. Se paga el costo de adaptar código que no debería existir, para mantener un proceso que podría hacerse de otra forma, con el estándar que ya está incluido en la licencia.
Las buenas prácticas en migraciones S/4HANA proponen algo distinto: **usar el proyecto como oportunidad de reingeniería**. Revisar qué procesos tienen soporte estándar en S/4HANA, cuáles se pueden resolver con Fiori sin una línea de código, y cuáles genuinamente necesitan desarrollo custom porque el negocio lo justifica.
La diferencia entre ambos enfoques no es ideológica. Es económica. Un desarrollo migrado "como estaba" puede costar entre 3 y 5 veces más en mantenimiento que uno rediseñado sobre el estándar S/4HANA.
El cambio cultural que nadie presupuesta
El mayor obstáculo no es técnico. Es que cambiar cómo se hacen las cosas requiere convencer a personas que llevan años haciendo funcionar un sistema a su manera. Los usuarios clave, los referentes de área, los que saben dónde está cada botón del ECC tienen una resistencia legítima al cambio — y esa resistencia, si no se gestiona, se traduce en requerimientos de customización innecesaria.
Los proyectos que mejor controlan el costo en una migración Brownfield son los que establecen desde el principio una política clara:
*El estándar es el punto de partida, el custom code es la excepción, y toda excepción se justifica con impacto de negocio medible.*
Ese criterio, aplicado con consistencia, es la diferencia entre un proyecto que llega al go-live dentro del presupuesto y uno que lo supera antes de la fase de pruebas.