Copiar roles de ECC a S/4HANA no es una migración neutral
ECC y SAP S/4HANA usan modelos de datos distintos: copiar los roles tal cual arrastra riesgo técnico y de licenciamiento al proyecto RISE.
En muchos comités de migración a RISE with SAP S/4HANA, la conversación sobre autorizaciones llega tarde y con una premisa que nadie escribe en el acta: los roles de ECC ya funcionan, así que basta con llevarlos. Esa premisa trata la copia de roles como una operación neutral, como mudar muebles de una casa a otra. No lo es. Las aplicaciones SAP legadas y SAP S/4HANA usan modelos de datos completamente distintos, y esa diferencia es precisamente lo que dificulta migrar roles y autorizaciones (Xiting, 2017).
Para una utility o una operadora de oil & gas en América Latina, el enfoque de autorizaciones no es un detalle técnico que pueda resolverse después del kickoff. Define quién puede facturar, cobrar o modificar datos de clientes y medidores en el sistema nuevo, y también condiciona el costo de la suscripción. Esta pieza abre una serie de seis artículos que recorre el problema por etapas: aquí se plantea por qué copiar roles arrastra riesgo técnico y de licenciamiento, y las siguientes piezas irán resolviendo cada frente.
El supuesto que nadie revisa: un rol es un rol
Durante años, el modelo de ECC fue fácil de razonar: el rol reunía lo que el usuario podía hacer desde SAP GUI, y los equipos de seguridad lo administraban con reglas que ya conocían. SAP S/4HANA reparte esa lógica entre el backend y un frontend Fiori que marca una diferencia significativa frente a SAP ERP (IBsolution, 2022). Por eso copiar el rol no resuelve el acceso: traslada una sola de las dos capas y deja la otra por diseñar.
Dónde se rompe la equivalencia
Transacciones que ya no son el camino
La depuración no es un paso opcional. Las transacciones reemplazadas por aplicaciones deben retirarse de los roles (IBsolution, 2022), y un rol que viaja intacto llega al sistema nuevo con accesos que sobran y sin los que hacen falta.
Funciones que se parten o se juntan
La correspondencia tampoco es uno a uno: una transacción puede repartirse entre varias apps Fiori, y varias transacciones pueden terminar en una sola, con efectos directos sobre las autorizaciones (IBsolution, 2022). Por eso rediseñar un rol exige entender primero el proceso que ese rol habilita.
Una guía extensa que no convierte nada por sí sola
La Simplification List documenta qué apps Fiori sustituyen a qué transacciones de SAP ERP, con una edición por cada versión de SAP S/4HANA (IBsolution, 2022). Es un mapa, no un convertidor: incluso un fabricante de herramientas de autorización describía la migración de roles como un esfuerzo manual aun con esa lista disponible (Xiting, 2017).
La autorización también es una decisión de licencia
El segundo riesgo es menos visible y suele aparecer cuando el contrato ya está en negociación. Para acompañar la transición de los contratos de usuarios nominales de ECC hacia SAP S/4HANA, SAP introdujo la revisión S/4HANA Trusted Authorization Review (STAR) (Flexera, s. f.). Dentro de ella, el reporte Authorization Object Analyzer, asociado a la Nota SAP 3113382, relaciona una clasificación de objetos de autorización con los nuevos tipos de usuario de SAP S/4HANA para simular el requerimiento de licencias (Flexera, s. f.).
Para el comité, la lectura es directa: el rol deja de ser solo un asunto de seguridad y pasa a ser también un insumo del contrato. Copiar roles sin revisarlos equivale a negociar el contrato RISE con decisiones de acceso que se tomaron hace años, en otro sistema y con otra lógica.
Qué le ocurre a un rol de ECC en una conversión
Incluso cuando el rol «se conserva», su recorrido documentado en una conversión de sistema muestra que hay trabajo en cada etapa.
Greenfield o brownfield: la decisión que se toma sin nombrarla
---
config:
theme: base
fontFamily: 'Inter Variable, system-ui, sans-serif'
themeVariables:
darkMode: true
fontFamily: 'Inter Variable, system-ui, sans-serif'
fontSize: '15px'
background: '#111113'
primaryColor: '#1A1A1D'
primaryTextColor: '#F4F5F8'
primaryBorderColor: '#B89C5C'
secondaryColor: '#242428'
tertiaryColor: '#1A1A1D'
mainBkg: '#1A1A1D'
secondBkg: '#242428'
tertiaryBkg: '#2E2E33'
lineColor: '#B89C5C'
textColor: '#F4F5F8'
titleColor: '#F4F5F8'
nodeBorder: '#B89C5C'
clusterBkg: '#1A1A1D'
clusterBorder: '#2E2E33'
edgeLabelBackground: '#242428'
pie1: '#B89C5C'
pie2: '#f59e0b'
pie3: '#22c55e'
pie4: '#d1bf95'
pie5: '#f97316'
pie6: '#ef4444'
pieTitleTextColor: '#F4F5F8'
pieSectionTextColor: '#F4F5F8'
pieLegendTextColor: '#F4F5F8'
pieStrokeColor: '#111113'
pieOuterStrokeColor: '#111113'
---
flowchart TD
A([¿Qué pasará con los roles?]) --> B{Enfoque de implementación}
B -->|Greenfield| C[Concepto de autorizaciones desde cero]
C --> D([Rediseño completo])
B -->|Brownfield| E[Roles del backend continúan]
E --> F[Limpieza de transacciones y roles Fiori nuevos]
F --> G([Depuración de lo heredado])
B -->|Greyfield| H[Limpieza de transacciones combinada con adaptación a procesos y participantes que cambiaron]
H --> J([Mezcla de ambos])
class A inicio
class B decision
class C,E,F,H proceso
class D,G,J neutro
classDef inicio fill:#3a352b,stroke:#B89C5C,color:#ffffff
classDef decision fill:#473519,stroke:#f59e0b,color:#ffffff
classDef proceso fill:#33363c,stroke:#9aa0aa,color:#ffffff
classDef neutro fill:#33363c,stroke:#9aa0aa,color:#ffffff
El alcance del trabajo de autorizaciones depende del enfoque de implementación. El greenfield construye el concepto desde cero, con la oportunidad de dejar atrás el legado de SAP ERP (IBsolution, 2022). El brownfield conserva los roles del backend, pero obliga a limpiarlos y a sumar los roles Fiori del frontend (IBsolution, 2022). El greyfield combina esa limpieza con la adaptación de las autorizaciones a procesos y participantes que cambiaron (IBsolution, 2022).
El riesgo no está en elegir una ruta u otra, sino en que el comité defina el enfoque de conversión del sistema sin decidir, de forma explícita, qué pasará con los roles.
Preguntas para el comité antes del kickoff técnico
Cada una de estas respuestas cambia el alcance, el cronograma y el costo del proyecto. Por eso, en nuestra práctica SAP, recomendamos que el comité las tenga resueltas antes del kickoff. En EvoTech Consulting acompañamos a utilities y operadores de oil & gas de América Latina a tomar esa decisión con evidencia del sistema actual, y no por inercia.
La próxima pieza de la serie aborda la ruta que muchos eligen por defecto: brownfield, llevarte tus roles contigo, con sus defectos incluidos.
Para profundizar: artículos relacionados
| Artículo | Frente | Qué aporta a esta discusión |
|---|---|---|
| Brownfield, Greenfield y SDT: las tres rutas a S/4HANA | Ruta | Explica sin jerga las rutas de migración que definen cuánto trabajo de autorizaciones habrá. |
| Brownfield por escrito: la decisión que el comité puede defender | Ruta | Cómo registrar la ruta elegida con criterios refutables, para que brownfield sea una decisión y no un default heredado. |
| Conversión a S/4HANA: el lenguaje correcto para el directorio | Comité | Por qué la conversión desde ECC es un reset arquitectónico y no un upgrade de versión. |
| RISE con SAP: tu FUE no depende de tu licencia ECC | Licencias | Por qué un usuario Professional en ECC no equivale a un usuario Advanced en RISE. |
| STAR dice que necesitas más licencias Advanced: ¿es cierto? | Licencias | Profundiza en la revisión STAR: estima el consumo desde autorizaciones asignadas, no desde el trabajo real. |
| Qué reportes revelan un rol inflado antes del true-up de SAP | Roles | Cómo detectar las autorizaciones que inflan un rol heredado antes de que lleguen al contrato. |
| Por qué este usuario es Advanced: leer la traza, no el total | Roles | Cómo convertir el ruleset oficial de SAP en una lectura propia y reproducible de la clasificación. |
| Checklist antes de renovar RISE: tu caso FUE frente a SAP | Contrato | Qué evidencia de roles preparar antes del true-up o la renovación del contrato RISE. |
Fuentes
- Xiting (2017). XITING Announces a New Release of the Xiting Authorizations Management Suite (XAMS), Its Flagship Automation and Security Solution for SAP Systems. GlobeNewswire. https://rss.globenewswire.com/news-release/2017/03/20/942248/0/en/XITING-Announces-a-New-Release-of-the-Xiting-Authorizations-Management-Suite-XAMS-Its-Flagship-Automation-and-Security-Solution-for-SAP-Systems.html
- IBsolution (2022). What changes in authorizations with SAP S/4HANA. Marc Röder. https://www.ibsolution.com/academy/blog_en/sap-s4hana/what-changes-in-authorizations-with-sap-s4hana
- Flexera (s. f.). Optimizer for SAP 4.3 — S/4HANA Trusted Authorization Review (STAR). https://docs.flexera.com/optimizer-for-sap/4.3/user-guide/reports/abap-reports/s4hana-trusted-authorization-review-star
Artículo de Edward Camacho Guerra, elaborado con apoyo de herramientas de inteligencia artificial y revisado y aprobado por el autor.
¿Este análisis describe un mercado donde ya opera o que está evaluando?
Revisamos su caso, mapeamos los riesgos que aplican y le decimos con franqueza si es una oportunidad para usted —sin presentación comercial, solo una conversación técnica y estratégica.
