El sobrecosto evitable del FUE: presupuesta tu RISE desde un ECC normalizado
Calcular tu migración RISE con un ECC sucio infla los FUE y dispara el costo. Aprende a normalizar roles y usuarios antes de cotizar S/4HANA Cloud.
· 11 min de lectura
El error que nadie menciona en la primera reunión de presupuesto
Hay una escena que se repite en empresas de servicios públicos y oil & gas de América Latina cada vez que el CIO convoca la primera reunión de presupuesto para migrar a SAP S/4HANA: alguien abre el sistema ECC, extrae el reporte de usuarios activos y dice “tenemos X usuarios; con eso calculamos el costo de RISE”. La reunión avanza. Se construye un modelo financiero. Se presenta al CFO.
El problema es que ese modelo está edificado sobre arena.
El ECC que lleva diez, doce o quince años en producción no refleja la realidad operativa: refleja la historia acumulada de cada proyecto, cada reorganización, cada consultor que asignó roles por conveniencia. Roles inflados, usuarios que no han iniciado sesión en meses, autorizaciones Professional asignadas a perfiles que solo consultan reportes. Sobre esa base sucia, cualquier cálculo de licenciamiento RISE sale sobredimensionado — y el presupuesto, inflado.
En EvoTech Consulting hemos visto este patrón repetirse en organizaciones con operaciones complejas: la cifra que llega al comité directivo no es la que deberían pagar; es la que pagarían si no hicieran nada antes de firmar el contrato.
La bifurcación que cambia todo: Named Users vs. FUE
Antes de hablar de normalización, conviene entender por qué el cambio de métrica lo cambia todo.
En S/4HANA on-premise con licencias perpetuas, SAP sigue midiendo en Named Users: Professional, Functional (Limited Professional), Productivity. Cada usuario nombrado tiene un tipo, y ese tipo determina el costo. Los roles inflados sobre-clasifican usuarios nombrados, pero el impacto es relativamente contenido y manejable con ajustes manuales.
En RISE with SAP — que entrega S/4HANA Cloud Private Edition — la métrica cambia a FUE (Full Use Equivalent). Aquí la clasificación no es manual ni declarativa: es authorization-based automated. El sistema mapea las autorizaciones reales del usuario a un tipo de uso, y ese tipo de uso determina cuántos FUE consume. Los ratios de conversión son los siguientes (SAP Community, 2024):
La matemática es brutal: un usuario que debería clasificar como Core (0.2 FUE) pero que tiene autorizaciones infladas que lo empujan a Advanced (1 FUE) cuesta cinco veces más de lo necesario. Multiplica eso por decenas o cientos de usuarios mal clasificados y el impacto presupuestal es significativo.
Benchmarks de mercado registran que la sobre-clasificación infla el total de FUE entre un 20 % y un 35 % en poblaciones de usuarios SAP Cloud (Redress Compliance, 2024–2025). En una empresa mediana de utilities con presupuesto de tecnología acotado, esa diferencia puede ser determinante para la viabilidad del proyecto.
Por qué el ECC “sucio” es el origen del problema
La raíz del sobre-costo no está en la métrica FUE — está en el estado del sistema origen. Un ECC típico en LATAM acumula años de decisiones de seguridad subóptimas:
- Roles compuestos sobredimensionados: para simplificar la administración, se crean roles que agrupan autorizaciones de múltiples funciones. El usuario solo usa el 20 % del rol, pero el sistema ve el 100 % de las autorizaciones.
- Usuarios dormidos: personas que cambiaron de área, salieron de la empresa o cambiaron de función, pero cuya cuenta sigue activa y clasificada.
- Conflictos SoD no resueltos: autorizaciones cruzadas que se mantienen “provisionalmente” desde una implementación anterior y nunca se limpiaron.
- Asignaciones Professional por defecto: en muchos proyectos ECC, la práctica fue asignar el tipo más alto para evitar incidentes de acceso. Esa práctica, trasladada a FUE, se convierte en sobrecosto estructural.
SAP es explícito al respecto: los usuarios deben clasificarse antes de cada medición del sistema (SAP USMM documentation). La herramienta USMM ejecuta la medición en cada sistema individual; LAW y SLAW consolidan los resultados a nivel de landscape. La optimización de tipos de licencia debe realizarse en cada sistema antes de que LAW consolide — no es posible corregir la clasificación a nivel de consolidado (Redress Compliance, 2024). Dicho de otro modo: la normalización es un prerrequisito de la medición, no una actividad posterior.
Los costos que no entran al presupuesto inicial
Más allá de los FUE, hay dos líneas de costo que sistemáticamente quedan fuera del modelo financiero inicial cuando se proyecta desde un ECC perpetuo.
Digital Access: el acceso indirecto por documento
El modelo de Digital Access de SAP, vigente desde 2018, cobra por la creación inicial de documentos de negocio generados por sistemas externos que interactúan con SAP — no por usuarios nombrados (SAP Digital Access Overview, 2019). Aplica a 9 tipos de documentos: órdenes de venta, facturas, órdenes de compra, documentos de servicio y mantenimiento, documentos de manufactura, gestión de calidad, gestión de tiempo, documentos financieros y documentos de material.
Los multiplicadores no son uniformes. La mayoría de los tipos aplica un factor 1x (cada documento creado = 1 unidad de licencia). Los documentos financieros y los documentos de material aplican un factor 0.2x — es decir, se necesitan 5 documentos para equivaler a 1 unidad (SAP, 2019; SAP, 2020). Importante: solo cuenta la creación inicial; lecturas, actualizaciones y eliminaciones no generan cargo.
Para utilities y oil & gas en LATAM, esto tiene implicaciones directas: sistemas AMI, SCADA, plataformas de campo y portales de clientes que hoy interactúan con el ECC seguirán haciéndolo con S/4HANA — y cada documento que creen tendrá un costo de Digital Access. Este componente es frecuentemente subestimado en los modelos de presupuesto iniciales, porque el ECC perpetuo no tenía esta línea de costo.
Consumo de BTP: la línea nueva que el perpetuo nunca tuvo
RISE with SAP incluye un baseline de créditos de SAP Business Technology Platform bajo el modelo Cloud Platform Enterprise Agreement (CPEA) — un volumen prepago de créditos que se consumen entre los distintos servicios BTP (SAP, FAQ CPEA & Cloud Credits, 2021; SAP Licensing Experts, 2024). Sin embargo, las integraciones, extensiones y automatizaciones que se construyan sobre BTP consumen esos créditos — y el sobreconsumo se factura de forma adicional, mientras que los créditos no consumidos expiran al cierre del año. Una empresa que viene de un ECC perpetuo no tiene referencia histórica de este costo: sencillamente no existía en su estructura de costos.
Proyectar el consumo de BTP sin un inventario de integraciones y extensiones planeadas es operar a ciegas. En nuestra práctica SAP, incluimos el dimensionamiento de BTP como parte del assessment de licenciamiento, no como una actividad separada de arquitectura.
Qué normalizar antes de pedir cotización
El assessment de licenciamiento no empieza con una solicitud de propuesta a SAP. Empieza por limpiar la casa. Las tres acciones prioritarias son:
Solo después de completar estas tres acciones tiene sentido ejecutar USMM, consolidar con LAW/SLAW y llevar esa fotografía limpia a la mesa de negociación con SAP.
El costo real de no normalizar
En el contexto de utilities y oil & gas de LATAM, donde los presupuestos de tecnología compiten con inversión en infraestructura operativa, recaudación y reducción de pérdidas no técnicas, sobre-pagar licencias durante tres o cinco años de contrato RISE no es un error menor: es capital inmovilizado que no va a modernización de medición, integración de sistemas de campo o mejora de la experiencia del cliente.
La decisión de migrar a RISE es estratégica. La negociación de licencias es táctica. Pero ambas dependen de un prerequisito operativo que pocas organizaciones priorizan: tener un sistema lo suficientemente limpio como para que la fotografía que toman sea real.
En EvoTech Consulting acompañamos este proceso desde el assessment inicial — no desde la firma del contrato. La diferencia entre cotizar desde un ECC sucio y cotizar desde un ECC normalizado puede ser significativa en el total del contrato plurianual. Esa diferencia vale el esfuerzo de limpiar la casa primero.
¿Tu organización está planificando la migración a RISE? El primer paso no es una demo de producto — es un diagnóstico de tu base de licenciamiento actual.
Fuentes
- SAP Community. RISE with SAP Full Use Equivalent (FUE) concept. SAP Technology Blog Posts. 2024. community.sap.com
- MTC Skopos. SAP FUE Optimization: Cut RISE License Cost 30-50%. 2024. mtcskopos.com
- Redress Compliance / Filipsson, F. SAP FUE Licensing: 2026 User Count Calculation. 2024–2025. redresscompliance.com
- Redress Compliance. SAP License Tools: USMM, LAW, SLAW, STAR Guide. 2024. redresscompliance.com
- SAP. Digital Access Adoption Program Overview (DA_Offer_External-Master_V11). Mayo 2019. news.sap.com
- SAP. SAP Strategic Pricing and Commercialization — Digital Access. Abril 2020. news.sap.com
- SAP. FAQ — Consumption-based commercial model: CPEA & Cloud Credits. 2021. sap.com
- SAP Licensing Experts. SAP BTP Licensing — Cloud Platform Enterprise Agreement (CPEA) & Consumption Tips. 2024. saplicensingexperts.com
- SAP Licensing Experts. SAP Digital Access (Document Licensing): What CIOs and IT Procurement Leaders Need to Know. saplicensingexperts.com
¿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.
