Qué reportes revelan un rol inflado antes del true-up de SAP

En una empresa de servicios públicos de América Latina que lleva doce o dieciocho meses en producción sobre RISE with SAP, el primer true-up rara vez sorprende por consumo de infraestructura. Sorprende por los usuarios. Un grupo de operadores de campo que el proyecto dimensionó como perfiles livianos aparece clasificado en la categoría más cara, y nadie en el equipo de seguridad recuerda haber aprobado ese cambio.

No hizo falta una decisión. Bastó con la acumulación de ajustes menores que se hicieron para destrabar un cierre de facturación, habilitar una regional nueva o cubrir una ausencia. La entrega anterior de esta serie explicó por qué una revisión anual de accesos no alcanza para frenar esa deriva. Esta se ocupa del paso siguiente y más concreto: qué reportes muestran que un rol se está inflando mientras todavía es barato corregirlo.

La medición mira lo que el usuario puede hacer, no lo que hace

La unidad comercial de la suscripción es el Full Use Equivalent (FUE), y los ratios publicados marcan la distancia entre categorías: 1 FUE equivale a 1 usuario de advanced use, a 5 usuarios de core use o a 30 usuarios de self-service use, mientras que el acceso de desarrollador consume 2 FUE por usuario (SAP Community, 2025). Esa asimetría es la que convierte un error de clasificación en un renglón de factura.

La clasificación se obtiene ejecutando el reporte STAR —programa SLIM_USER_CLF_HELP— con el ruleset de la nota SAP 3113382; para sistemas de desarrollo el equivalente es el reporte SLIM_DEV_CLF_HELP con la nota 3333812 (SAP Support Portal, s.f.). Ese resultado permite verificar la medición que SAP publica en la tarjeta Private Cloud Consumption de SAP for Me, donde los valores negativos de la columna Delta señalan sobreuso potencial (SAP Support Portal, s.f.).

El detalle que decide todo: la clasificación se calcula sobre las autorizaciones asignadas. SAP advierte que asignar privilegios en exceso empuja usuarios a categorías de mayor costo y que el reporte puede revelar roles heredados que fueron “promovidos” a buckets FUE superiores (SAP Community, 2025). Por eso el objeto a vigilar es el rol, no el usuario. El usuario solo hereda la factura.

Categoría 1: autorizaciones manuales, abiertas y modificadas

Role Profiler agrupa sus reportes por categorías, y la primera —calidad y sostenibilidad del rol— apunta exactamente a la deriva: analiza roles con autorizaciones manuales, abiertas o modificadas, valores de campo organizacional cambiados y accesos con asterisco (*) (Xiting, 2022).

Cada una de esas condiciones tiene una lectura de licencia distinta:

• Manual: el objeto se agregó directamente en PFCG, por fuera de la propuesta SU24. Es el rastro típico del ajuste de emergencia que nunca se revirtió.
• Abierta: campos sin valor mantenido, que suelen resolverse con el valor más amplio disponible cuando alguien necesita que el rol funcione hoy.
• Modificada y accesos con asterisco: el rol dejó de coincidir con su plantilla y, en la práctica, habilita mucho más de lo que su nombre sugiere.

En una comercializadora, el caso repetido es el rol de gestión de lecturas al que se le agregó un objeto para desbloquear un cierre mensual. El cierre se salvó. El objeto se quedó. Un año después ese rol viaja en cientos de usuarios.

Categoría 2: roles derivados con cambios no distribuidos

Las utilities de la región casi siempre derivan roles por nivel organizacional: regional, centro, sociedad, comercializadora. Es la decisión correcta de diseño y, a la vez, el lugar donde la deriva se vuelve invisible.

Role Profiler dedica una categoría específica a esto: detectar cambios en roles hijos, cambios no distribuidos en roles padre y comparación completa de autorizaciones entre ambos (Xiting, 2022). Son dos fallas distintas con el mismo síntoma.

---
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([Roles derivados por nivel organizacional]) --> B{¿Dónde se mantuvo el cambio?}
  B -->|Rol padre| C[El rol padre se modificó y se generó]
  C --> D[La distribución a los hijos queda pendiente]
  D --> E[Cambios no distribuidos en roles padre]
  E --> Z([Los reportes de roles derivados detectan ambos síntomas])
  B -->|Rol hijo| F[Se mantienen autorizaciones en el rol hijo]
  F --> G[«Adjust derived / Generate derived roles» realinea los campos no organizacionales]
  G --> H[El cambio se vuelve a aplicar a mano]
  H -->|Repetir| F
  H --> Z
  class A inicio
  class B decision
  class C,D,E,F,G,H proceso
  class Z bueno
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 bueno fill:#193e2b,stroke:#22c55e,color:#ffffff

La primera es el rol padre que se modificó y generó, pero cuya distribución a los hijos quedó pendiente. La segunda es el inverso: alguien mantuvo autorizaciones directamente en el rol hijo. Esa modificación no sobrevive: la distribución mediante «Adjust derived / Generate derived roles», opción disponible únicamente desde el rol padre en PFCG (SAP Community, 2020), realinea los campos no organizacionales del rol hijo con la plantilla, así que se vuelve a aplicar a mano. Ese ciclo —tocar el hijo, perder el cambio, repetirlo— es la deriva en su forma más pura, y ninguna revisión de fin de año la reconstruye.

Las otras categorías que también leen como costo

El módulo supera los 100 reportes de análisis en total (Xiting, 2026), y varias categorías adicionales tienen lectura directa sobre el FUE: optimización de SU24 sobre campos abiertos; reportes de uso basados en datos ST03N para detectar transacciones no utilizadas dentro de un rol; Activity Watchdog para autorizaciones críticas, conflictos de segregación de funciones y acceso a datos maestros o de RR. HH.; verificación de menús de rol; y ejecución de reportes como parte del mecanismo de transporte (Xiting, 2022).

Esa última capacidad importa más de lo que parece: mueve el control desde la auditoría hacia el momento del cambio.

Cómo se ordena el circuito de detección

El circuito es corto y ordenado: detectar con los reportes de calidad de rol —autorizaciones manuales, abiertas, modificadas y accesos con asterisco—, contrastar la herencia entre roles padre e hijos, traducir el hallazgo a licencia ejecutando el reporte STAR para ubicar qué roles empujan usuarios a categorías superiores, remediar en el rol de origen y no en la asignación individual, y bloquear el reingreso ejecutando los reportes dentro del mecanismo de transporte.

Qué hacer en el primer año post-go-live

Antes de medir, hay higiene obligatoria: implementar la lista de precios correspondiente a la edición privada, eliminar la clasificación manual de usuarios en USMM y actualizar las fechas de validez de todos los usuarios (SAP Global License Audit & Compliance, 2024). Sin ese paso, el reporte mide un padrón que ya no existe.

Después, cadencia. Un reporte de autorizaciones manuales ejecutado cada mes es un hallazgo corregible; ejecutado una vez al año es un hecho consumado. Y una advertencia comercial: entregar resultados STAR sin revisión interna previa puede disparar ajustes de costo o acciones de cumplimiento sobre datos aún no optimizados (SAP Community, 2025).

En nuestros proyectos SAP en la región, esta es la diferencia entre discutir el true-up con evidencia propia o recibirlo como veredicto. La próxima entrega de esta serie muestra cómo conectar el análisis de licencia STAR con un proceso de recertificación continua de accesos.

Fuentes

• SAP Community (2025). RISE with SAP Full Use Equivalent (FUE) concept.
• SAP Community (2020). Parent - Derived Roles concept.
• SAP Support Portal (s.f.). Private Cloud Consumption Card — SAP for Me.
• SAP Global License Audit & Compliance (2024). SAP Private Cloud Metering.
• Xiting (2022). Role Profiler — Xiting Authorizations Management Suite (XAMS).
• Xiting (2026). Xiting Authorizations Management Suite (XAMS) — página vigente del módulo Role Profiler.