STAR dice que necesitas más licencias Advanced: ¿es cierto?
El reporte STAR estima tu consumo de FUE desde autorizaciones asignadas, no desde trabajo real. Por qué ese número no es un dictamen de SAP.
· 13 min de lectura
`markdown Basta que un usuario tenga una sola autorización de nivel Advanced entre los roles que tiene asignados para que quede clasificado en ese escalón, con independencia de que esa funcionalidad llegue a usarse alguna vez (Soterion, 2025). Esa regla —no una opinión de SAP sobre tu operación— es la que fabrica buena parte del número que devuelve el reporte STAR.
De ahí la pregunta que abre esta serie de seis piezas: cuando alguien dice «STAR dice que necesitas más licencias Advanced», ¿qué está diciendo exactamente? Un reporte no dictamina. Mide algo concreto, contra una regla concreta, en una versión concreta. Confundir esa medición con un veredicto es lo que produce decisiones de compra equivocadas.
Empezamos por lo más incómodo: qué mide realmente el reporte, y por qué su salida habla más de cómo se diseñaron los roles hace quince años que de lo que la gente hace hoy.
Una autorización asignada no es una transacción ejecutada
Aquí está el punto que casi nunca llega al comité. El FUE se calcula a partir de las autorizaciones asignadas a un usuario, no de las transacciones que ese usuario efectivamente ejecuta (EPI-USE Labs, 2026). Si un rol incluye autorizaciones amplias sobre transacciones sensibles, STAR puede clasificar a esa persona como usuario Advanced —equivalente a 1,0 FUE— aunque su actividad diaria sea considerablemente más ligera (SAP Community, 2026).
Y la aritmética amplifica el error. Los ratios de conversión son fijos: 1 FUE equivale a 1 usuario Advanced, a 5 usuarios Core o a 30 usuarios Self-Service; un acceso de desarrollador consume 2 FUE (SAP Community, 2026). Un usuario mal ubicado en el escalón Advanced pesa treinta veces más que si estuviera correctamente clasificado como Self-Service.
El origen del problema no es SAP: es el diseño de roles heredado. Los modelos de autorización de la mayoría de las organizaciones se construyeron pensando en seguridad operativa y segregación de funciones, no en eficiencia de licenciamiento; el resultado es sobreclasificación sistemática y, con ella, una sobreestimación significativa del requerimiento de FUE (Soterion, 2025). Firmas especializadas en licenciamiento SAP lo describen sin ambigüedad: el reporte STAR sobrestima el número de FUE requeridos, a menudo de forma significativa (Turnkey Consulting, 2024).
El instrumento tiene un ruleset, y el ruleset tiene versión
STAR es el S/4HANA Trusted Authorization Review, un servicio que SAP introdujo para que los clientes pudieran estimar cuántos Full Use Equivalents (FUE) necesitarían al pasar de ECC a S/4HANA. Su componente técnico es el Authorization Object Analyzer, distribuido mediante la SAP Note 3113382 y ejecutado en el sistema como el reporte SLIM_USER_CLF_HELP (Snow Software, 2023; SAP Community, 2026).
El reporte no observa el sistema en operación. Toma los objetos de autorización asignados a usuarios y roles, los contrasta contra un ruleset que SAP publica adjunto a la nota, y proyecta una clasificación por usuario (SAP Community, 2026). Ese ruleset es versionado y se actualiza: analistas de licenciamiento reportaban recientemente trabajar sobre la versión 1.69 del ruleset PCE distribuido como adjunto de esa nota (Soterion, 2026; SAP Community, 2026). Correr una versión vieja produce un número viejo.
Y esto no es un detalle de administración. SAP ha liberado varias iteraciones del ruleset: en algunos casos las reglas se volvieron más favorables para el cliente, en otros más estrictas, con el consiguiente aumento del consumo de FUE (Soterion, 2026). Un número que alguien corrió hace dos trimestres no es el mismo número hoy, y la versión bajo la cual se corrió debería figurar junto a la cifra, igual que la fecha de una medición de campo.
La crítica no es a la herramienta, es a la lectura
Conviene decirlo con precisión, porque la crítica no es a la herramienta. Es a cómo se presenta. Soterion, firma especializada en licenciamiento SAP, describe el marco STAR como estructurado, transparente y relativamente indulgente, y atribuye el sobrepago a diseños de roles que no fueron pensados para este modelo, más que a una falla del marco en sí (Soterion, 2026). Es decir: el reporte hace bien lo que le pidieron hacer. El problema aparece cuando su salida se sube de categoría y pasa de medición a sentencia.
Primero, SAP mismo no construye su propuesta comercial únicamente sobre el resultado de STAR: la medición se combina con el número actual de usuarios licenciados, el tamaño de la organización, su industria y el uso futuro esperado, precisamente porque SAP reconoce que los diseños de roles existentes suelen contener sobreasignación de accesos (Soterion, 2026). Si ni el fabricante lo trata como cifra final, presentarlo internamente como tal es un error de lectura propio.
Segundo, la magnitud de lo que cuelga de esa lectura no es marginal: según la misma firma de licenciamiento, las licencias de usuario representan típicamente entre 30% y 60% de la inversión total de una organización en software SAP (Soterion, 2026). Una lectura apresurada de un reporte no mueve una partida menor del presupuesto.
Qué se hace con la salida del reporte
---
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([Se ejecuta el reporte STAR]) --> B{¿Qué se hace con la salida?}
B -->|Enviar| C[Se envía directamente a SAP]
C --> D[La salida queda comprometida sin análisis previo]
D --> E([Resultado sometido sin revisión])
B -->|Exportar| F[Se exporta el resultado localmente]
F --> G[Se analiza la salida y se detectan discrepancias u oportunidades de optimización]
G --> H[Se revisan y remedian los resultados antes de someterlos]
H --> I([Se comprometen los resultados con revisión previa])
class A inicio
class B decision
class C,D,F,G,H proceso
class E neutro
class I 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
classDef neutro fill:#33363c,stroke:#9aa0aa,color:#ffffff
El flujo del reporte contempla una revisión previa. Al ejecutarlo, existe la opción de exportar el resultado localmente en lugar de enviarlo directamente a SAP, lo que permite analizar la salida y detectar discrepancias u oportunidades de optimización antes de comprometerla (SAP Community, 2026). Consultoras especializadas insisten en ese punto: las organizaciones tienen la oportunidad de revisar y remediar sus resultados antes de someterlos, y muchas no saben que la tienen (Turnkey Consulting, 2026).
La pregunta que cambia la conversación
La pregunta correcta para el próximo comité no es cuántos FUE dice STAR. Es: ¿qué autorización específica está promoviendo a cada usuario al escalón Advanced, y ese usuario la ejerce?
En nuestros proyectos con utilities y operaciones de oil & gas en la región, esa pregunta —hecha antes de exportar, no después de firmar— es la que cambia el orden de magnitud de la negociación.
Por qué el error queda fijado
En una utility de la región, con presupuesto de modernización acotado y presión regulatoria sobre tarifas y recaudación, el error no se corrige con una nota de crédito. Tres mecanismos contractuales lo fijan:
- La medición es recurrente. Bajo SAP Cloud ERP Private, el consumo de licencias se monitorea mensualmente, y el conteo mensual más alto del período contractual puede usarse como línea base de facturación para el true-up (Soterion, 2025). Un pico temporal de accesos —una migración, un cierre, una contingencia operativa— puede quedar grabado en el costo.
- Los compromisos son hacia adelante. Una vez fijada la línea base de FUE, no se contemplan reducciones retroactivas (Soterion, 2025).
- El FUE arrastra infraestructura. El número comprometido influye directamente en el dimensionamiento que SAP asigna bajo su modelo de T-shirt sizing; sobreestimar FUE significa cargar con capacidad que no se necesita (EPI-USE Labs, 2026).
Y el reloj no ayuda a pensar con calma: el mantenimiento mainstream de las aplicaciones core de SAP Business Suite 7 termina a fines de 2027, seguido de un mantenimiento extendido opcional hasta fines de 2030 con un recargo de dos puntos porcentuales sobre la base de mantenimiento (SAP Support Portal, estrategia de mantenimiento). Esa fecha es exactamente el tipo de presión que hace que un número mal entendido se firme sin cuestionarse.
Lo que sigue en esta serie
En la próxima pieza revisamos el caso documentado de las £4,5 millones: qué ocurre, en cifras concretas, cuando nadie cuestiona el número de STAR antes de enviarlo (Turnkey Consulting, 2026).
Fuentes
- SAP Community — RISE with SAP Full Use Equivalent FUE concept (2026): https://community.sap.com/t5/technology-blog-posts-by-sap/rise-with-sap-full-use-equivalent-fue-concept/ba-p/14054243
- SAP Community — S/4HANA Trusted Authorization Review (STAR): https://community.sap.com/t5/enterprise-resource-planning-blog-posts-by-sap/s-4hana-trusted-authorization-review-star/ba-p/13537010
- SAP Support Portal — Innovation Commitment for SAP S/4HANA until 2040 / estrategia de mantenimiento: https://support.sap.com/en/release-upgrade-maintenance/maintenance-information/maintenance-strategy/s4hana-business-suite7.html
- SAP Support Portal — Private Cloud Consumption Card (SAP Notes 3113382, 3333812, 3568419): https://support.sap.com/content/s4m/help/finance/consump/private.html
- Turnkey Consulting — RISE Right FAQs: Navigating RISE With SAP FUE Licensing (2024): https://www.turnkeyconsulting.com/resources/blog/rise-right-faqs-navigating-rise-with-sap-fue-licensing
- Turnkey Consulting — SAP FUE Licensing: How to Reduce Costs and Improve Security (2026): https://www.turnkeyconsulting.com/resources/blog/sap-fue-licensing-reduce-costs-improve-security
- Soterion — Optimising SAP User (FUE) Licensing (2025): https://soterion.com/blog/optimising-sap-user-fue-licensing-how-to-avoid-overpaying-under-the-star-framework/
- Soterion — Understanding SAP’s FUE Measurement Model (2026): https://soterion.com/blog/understanding-saps-fue-measurement-model/
- Soterion — SAP FUE Optimisation: The STAR Rule Set’s Surprising Leniency (2026): https://soterion.com/blog/sap-fue-optimisation-the-star-rule-sets-surprising-leniency/
- Soterion — The importance of aligning SAP access governance with FUE licensing (2026): https://soterion.com/blog/the-importance-of-aligning-sap-access-governance-with-fue-licensing/
- Soterion — Soterion completes 100 SAP license assessments within one year (2026): https://vir.com.vn/soterion-completes-100-sap-license-assessments-within-one-year-158856.html
- EPI-USE Labs — The path to SAP S/4HANA: Understand your true FUE licensing position (2026): https://www.epiuselabs.com/data-security/the-path-to-sap-s4hana-understand-your-true-fue-licensing-position
- Snow Software — S/4HANA Trusted Authorization Review (STAR) (2023): https://docs.snowsoftware.com/snow-optimizer-for-sap-software/en/UUID-ccd0b4a4-32a6-3341-8ef5-2b0f15aa3e9f.html `
¿Este análisis mapea un mercado donde ya operas o estás evaluando entrar?
Revisamos tu caso específico, mapeamos los riesgos que aplican, y te decimos honestamente si es oportunidad para ti —sin pitch comercial, solo discusión técnica y estratégica.
