Migrar a S/4HANA sin rediseñar los roles: cuándo tiene sentido y cuándo solo traslada el problema

Conviene separar desde el principio dos ejercicios diferentes.

Podemos realizar correctamente el primer ejercicio sin resolver el segundo.

El usuario llegará a S/4HANA y podrá trabajar, pero si tenía autorizaciones que ya no necesitaba, roles construidos por acumulación o conflictos estructurales, esos problemas seguirán formando parte del modelo.

No todos los modelos heredados de ECC parten del mismo punto.

Hay organizaciones con una estructura relativamente ordenada, roles reconocibles, responsabilidades bien definidas y un mantenimiento razonablemente controlado.

En otras, explicar por qué un usuario tiene determinados accesos requiere reconstruir años de cambios, copias de roles, incidencias, excepciones y peticiones puntuales.

Por eso, antes de decidir si rediseñar o conservar, necesitamos una fotografía suficientemente clara del modelo actual.

No se trata necesariamente de iniciar una reingeniería completa. Se trata de disponer de información para responder preguntas básicas:

Lo importante es llegar a la migración sabiendo qué estamos conservando y por qué.

Rediseñar roles implica algo más que modificar autorizaciones.

Supone revisar funciones, responsabilidades, asignaciones, riesgos y, en muchos casos, involucrar al negocio para validar una nueva forma de representar los puestos de trabajo.

Introducir ese cambio al mismo tiempo que una migración a S/4HANA no siempre es la mejor decisión.

En ese escenario, separar ambos proyectos puede reducir el riesgo del go-live.

El escenario cambia cuando el modelo actual ya presenta síntomas claros de deterioro.

En estas situaciones, trasladar el modelo puede ser técnicamente más sencillo a corto plazo, pero la migración no elimina ninguna de esas dependencias.

Y existe además un riesgo práctico: una vez superado el go-live, aquello que se dejó “para después” tiene que competir con nuevas prioridades, evolutivos y necesidades del negocio.

El modelo heredado puede terminar convirtiéndose, de nuevo, en el modelo permanente.

Entre una reingeniería completa antes de migrar y trasladar el modelo sin cuestionarlo existe bastante espacio.

En algunos proyectos puede ser más razonable trabajar por capas.

manteniendo para una fase posterior el rediseño completo de puestos.

También podemos aprovechar la migración para construir correctamente aquellas áreas que cambian de forma significativa en S/4HANA, mientras mantenemos temporalmente otras partes del modelo con una transformación menor.

El alcance debería responder al estado real del modelo y al calendario del proyecto, no a una regla fija.

Cuando el diagnóstico indica que merece la pena replantear el modelo, migrar ofrece una oportunidad para dejar de utilizar los roles actuales como única referencia.

Partimos de las responsabilidades y de los usuarios que desempeñan cada puesto, analizamos los procesos que ejecutan y utilizamos el uso real como evidencia para entender qué actividades son habituales, cuáles aparecen únicamente en determinados usuarios y dónde existen accesos que han perdido sentido.

A partir de ahí se construyen funciones y puestos buscando un equilibrio entre mínimo privilegio, Segregación de Funciones, reutilización y operatividad.

Como norma general, los puestos deberían construirse libres de riesgos SoD y con las autorizaciones necesarias para desarrollar su responsabilidad.

Cuando un usuario necesita capacidades adicionales, podemos analizar si corresponde asignarle otra responsabilidad ya definida, reorganizar el proceso, retirar una función del puesto de origen o gestionar una excepción cuando la operativa no permite una segregación completa.

Hay otro motivo por el que una migración no debería plantearse únicamente como una conversión de los roles actuales: la experiencia de acceso puede cambiar.

Esto puede obligar a revisar la correspondencia entre función de negocio, acceso funcional y autorización técnica.

Si simplemente trasladamos la lógica histórica sin revisar estas relaciones, podemos acabar construyendo una nueva capa sobre un modelo que ya era difícil de gobernar.

Por eso conviene diferenciar qué parte del acceso sigue teniendo sentido y qué parte debería aprovechar la migración para evolucionar.

Cuando la migración forma parte de una transición a RISE, el modelo de roles tiene además una dimensión económica.

Esto refuerza la necesidad de conocer el modelo antes de trasladarlo, pero no significa que el licenciamiento deba convertirse en el único criterio de diseño.

Un rol debe responder primero a una necesidad real de negocio, con el nivel de acceso adecuado y un modelo de riesgo controlado. La optimización de licencias debe analizarse sobre esa misma base.

Decidir migrar primero y rediseñar más adelante puede ser perfectamente razonable.

Lo que suele generar problemas es que “después” no exista realmente como proyecto.

Si el rediseño se pospone, conviene llegar al go-live con una fotografía del punto de partida, los problemas identificados, el alcance pendiente y una estrategia definida para abordarlos.

Así, posponer el rediseño no significa volver a empezar meses después intentando reconstruir cómo funcionaba el entorno anterior.

Significa separar conscientemente dos transformaciones.

No existe una respuesta única.

Si el modelo actual es comprensible, está razonablemente ajustado a las necesidades del negocio y puede adaptarse al nuevo entorno sin arrastrar problemas relevantes, conservarlo puede ser la opción más eficiente.

Si ya presenta sobreautorización, riesgos estructurales, acumulación histórica o una arquitectura difícil de mantener, la migración puede ser un buen momento para intervenir antes de consolidar esa misma complejidad en S/4HANA.

Y si el modelo necesita evolucionar pero el proyecto no permite hacerlo con garantías antes del go-live, separar ambos trabajos también puede ser una decisión adecuada.

Antes de migrar deberíamos poder responder al menos a tres preguntas: