STAR también puede subestimar tu FUE: el sesgo que nadie corrige

El hábito que cuesta caro: leer STAR en una sola dirección

Cuando un equipo de Basis o Finanzas de una utility u operadora de oil & gas en América Latina llega a la mesa de renovación o true-up de un contrato RISE with SAP, el número que trae suele venir de un solo lugar: el reporte del ruleset STAR. Y casi siempre se lee en una sola dirección: “el sistema dice que necesitamos más Full Use Equivalents (FUE), así que hay que pagarlos”.

En una entrega anterior de esta serie documentamos qué pasa cuando ese número se acepta sin cuestionarlo: el impacto económico puede ser considerable y, en la mayoría de los casos, evitable. Pero esta pieza aborda el otro lado de ese mismo sesgo, uno que rara vez se discute en la mesa de negociación: el ruleset STAR no solo puede sobreestimar. En actividades muy comunes, también puede ser sorprendentemente laxo.

El caso F_BKPF_BUK: cuando el ruleset clasifica hacia abajo

El objeto de autorización F_BKPF_BUK controla una parte central de las transacciones de contabilización financiera en SAP —códigos como FB01 y buena parte de los servicios Fiori de Finanzas asociados—. De acuerdo con el ruleset FUE vigente (SAP Note 3113382, versión 1.69), actividades tan usadas como ACTVT 01 (Crear) y ACTVT 02 (Modificar) sobre F_BKPF_BUK se clasifican como Self-Service, y no como Advanced (Soterion, 2026).

La implicación es directa: muchos usuarios que contabilizan asientos financieros a diario —perfiles que bajo SAP ECC casi cualquier organización habría etiquetado sin dudar como Full Professional— no necesariamente requieren la clasificación Advanced bajo RISE. Bajo el modelo de bloques FUE, esa diferencia de tier importa: un usuario Self-Service consume su bloque a razón de 30 a 1, uno Core a razón de 5 a 1, y uno Advanced consume un bloque completo, 1 a 1 (Soterion, 2025).

Para una utility o una operadora de oil & gas con miles de usuarios de Finanzas contabilizando en múltiples sociedades y países, la diferencia entre clasificar ese universo como Self-Service o como Advanced no es un matiz técnico: es la diferencia entre un true-up manejable y uno que dispara la renovación por encima del presupuesto aprobado.

Por qué esto importa en una renovación RISE en LATAM

El patrón regional es consistente: un equipo de Basis o de Finanzas recibe el output de STAR, lo interpreta como un veredicto cerrado y lo traslada tal cual a la negociación comercial con SAP o con el integrador. En ese proceso casi nunca se hace la pregunta inversa: ¿el ruleset está siendo demasiado generoso en alguna categoría de usuarios operativos?

Esto es particularmente relevante en organizaciones de utilities y O&G de la región, donde los roles de Finanzas suelen ser compartidos entre equipos centralizados de shared services que atienden varias sociedades del grupo a la vez. Si una parte de esa población de contabilización cae naturalmente en Self-Service bajo el ruleset vigente, pero el diseño de roles heredado de ECC la mantiene empaquetada junto con actividades Advanced no relacionadas, la organización paga por una clasificación que ni el propio ruleset exige.

El error, entonces, no es solo aceptar un número de STAR inflado sin cuestionarlo —el tema de la pieza anterior de esta serie—. El error simétrico es asumir que todo lo que STAR entrega ya está optimizado a favor del cliente, y dejar de revisar si el diseño de roles está generando Advanced innecesarios en actividades que el propio ruleset ya trata como Self-Service.

El análisis experto corrige en ambas direcciones

En nuestra práctica SAP, cuando acompañamos a un cliente en la fase de true-up o renovación de un contrato RISE, el ejercicio de validación del FUE nunca parte de la premisa de que STAR está sobreestimando o subestimando por defecto. Parte de auditar, objeto de autorización por objeto de autorización, qué actividades concretas están asignadas a cada rol y cómo las clasifica el ruleset vigente —no el que se recuerda de una versión anterior, ni el que asume el proveedor del contrato.

Eso significa, en la práctica, dos movimientos simultáneos:

• Identificar roles donde actividades Advanced innecesarias están infladas por diseño heredado de ECC, y que pueden reclasificarse hacia Core o Self-Service sin perder funcionalidad real.
• Verificar, como en el caso de F_BKPF_BUK, dónde el ruleset ya es más permisivo de lo que el equipo interno asumía, para no seguir presupuestando de más sobre un supuesto vencido.

Ninguno de los dos movimientos reemplaza al otro. Un análisis que solo busca “bajar” la clasificación de usuarios sobreestimados, sin verificar también dónde el ruleset ya es laxo, deja valor sobre la mesa en la negociación. Y uno que solo confía en la lenidad puntual del ruleset, sin auditar el diseño de roles, sigue expuesto a sobreestimaciones reales en otras áreas del sistema.

Antes de firmar el próximo true-up

Para un equipo de Basis o Finanzas de una utility o una operadora de oil & gas en la región que enfrenta una renovación de contrato RISE, el punto de partida no debería ser el número que entrega STAR, sino la pregunta de si ese número refleja el diseño real de roles de la organización o el diseño heredado de una plataforma distinta, con reglas de licenciamiento distintas.

Esa validación —objeto de autorización por objeto de autorización, en ambas direcciones— es justamente el trabajo que precede a cualquier cifra de true-up defendible frente a SAP.

La siguiente entrega de esta serie aborda otro supuesto costoso en esta misma conversación: por qué no existe una correlación directa entre la licencia Full Professional que un usuario tenía en ECC y la clasificación Advanced que ese mismo usuario recibe en RISE, y qué implica asumir que sí la hay.

Fuentes

• Soterion, Understanding SAP’s FUE Measurement Model, 2026.
• Soterion, SAP Licensing: Named Users and the New Measurement Approach, 2025.
• SAP Note 3113382, versión 1.69 (ruleset STAR / FUE).