Migrar a S/4HANA: el roadmap empieza antes del kickoff

La migración no comienza con la configuración del ERP. Empieza al alinear al negocio, conocer los procesos, ordenar los datos y decidir la arquitectura que la organización quiere construir.

Durante años participé en transformaciones SAP desde el lado del proveedor. Esa experiencia me permitió ver problemas de alcance, diseño, integración y ejecución. Al asumir también la mirada del cliente confirmé varios de esos aprendizajes y apareció una dimensión todavía más importante: una migración hacia SAP S/4HANA no se gana únicamente con una buena implementación técnica. Se gana cuando la organización está preparada para tomar decisiones y sostener el cambio.

El primer trabajo es alinear el propósito. El CEO y las gerencias N1 necesitan compartir qué objetivo de negocio persigue la transformación, qué decisiones les corresponde tomar y qué nivel de participación exige. Cuando una gerencia no ha vivido un programa de esta envergadura, no basta con pedirle compromiso. Hay que explicar el alcance, las implicancias para su área y la información que deberá aportar. Ese entendimiento permite construir un business case realista y compartido.

Antes del diseño futuro debe existir una base de conocimiento confiable. Si los procesos actuales, sus responsables, reglas, excepciones, aplicaciones y datos no están actualizados, conviene ejecutar un anteproyecto de levantamiento y validación. No es documentación por cumplir: evita definir el alcance sobre supuestos y permite reconocer qué debe mantenerse, simplificarse o transformarse.

La evaluación debe seguir los procesos de extremo a extremo. Abastecimiento, planificación, producción, logística, ventas, mantenimiento y finanzas no pueden analizarse como islas. Una decisión local suele trasladar complejidad a otra área, aplicación o integración. Mirar el flujo completo ayuda a encontrar dependencias, controles duplicados y oportunidades que no aparecen en un análisis por módulos.

En paralelo hay que mapear la arquitectura de aplicaciones as-is y definir hacia dónde se quiere evolucionar. Cada sistema debe relacionarse con el proceso que soporta, sus integraciones, datos, criticidad, costos, obsolescencia y responsable. Con esa información se puede decidir qué conservar, retirar, reemplazar o desacoplar, y qué capacidades vivirán en S/4HANA, SAP BTP o aplicaciones satélite bajo principios de Clean Core.

Los datos requieren un frente de trabajo propio desde el inicio. La migración no corrige por sí sola años de duplicidad, definiciones distintas o responsabilidades difusas. Se necesitan propietarios, reglas de calidad, criterios para los datos maestros, seguridad, trazabilidad y decisiones sobre quién crea, modifica y aprueba. El gobierno de datos debe operar antes, durante y después de la salida en vivo.

La adopción tampoco puede dejarse para la capacitación final. Los usuarios necesitan entender los nuevos procesos, practicar con casos reales y participar en las decisiones que afectan su trabajo. La organización debe preparar líderes de cambio, mecanismos de feedback, materiales actualizados y una red de soporte que reduzca la dependencia del equipo de proyecto.

Con estas bases, el roadmap puede organizarse por olas de valor: primero conocer y estabilizar; luego simplificar procesos, datos y aplicaciones; después transformar el núcleo y sus integraciones; y finalmente consolidar el gobierno y la mejora continua. Cada ola debe tener un resultado de negocio, responsables claros, criterios de entrada y salida, y riesgos visibles para la dirección.

El programa necesita un gobierno integrado. Negocio, TI, arquitectura, datos, seguridad y los proveedores deben trabajar con una misma forma de decidir, gestionar dependencias y controlar el alcance. El gobierno de aplicaciones continúa después del proyecto para cuidar el Clean Core, priorizar evolutivos, medir valor y evitar que el nuevo ecosistema vuelva a acumular la complejidad que se quiso eliminar.

Migrar a S/4HANA es una transformación empresarial habilitada por tecnología. El ERP es una pieza central, pero el resultado depende de conectar liderazgo, procesos, aplicaciones, arquitectura, datos y personas. Preparar esas condiciones antes del kickoff no retrasa la implementación: reduce incertidumbre y aumenta la probabilidad de construir una capacidad sostenible para el negocio.