FinOps en SAP RISE: deja de pagar el escalón de arriba
FinOps en SAP RISE empieza con una pregunta: ¿paga por lo que realmente usa? FinOps es la disciplina de controlar el costo de la nube. Sin embargo, casi nadie mira el mayor contrato de TI de la empresa: el RISE with SAP. Y es justamente ahí donde vive el dinero escondido. El costo del RISE lo empujan tres palancas. Son la licencia (FUE), la memoria de HANA (sizing) y el consumo de nube. Quien gestiona las tres paga lo justo. Sin embargo, quien no las gestiona paga el escalón de arriba.
En esta guía explicamos FinOps en SAP RISE desde cero. El foco está en el modelo FUE, que casi nadie explica bien. Además, incluimos una calculadora para que estimes tu posición.
Palanca 1 — FUE: la moneda única de la licencia SAP
En el RISE, SAP abandonó la venta de licencias por tipo. En su lugar, creó una moneda única: el FUE (Full Use Equivalent). Todos los usuarios se convierten en FUEs, y el contrato define cuántos compraste. La conversión funciona así:
Calcula tus FUEs
Estimación didáctica según la conversión estándar — mandan el contrato y la medición oficial. Pide la radiografía real a Inove.
El detalle que atrapa a todo el mundo
La clasificación no depende de lo que el usuario hace. Depende de lo que PUEDE hacer, es decir, de las autorizaciones que tiene. La medición aplica reglas que mapean perfil → tipo de usuario. Por eso, haz clic en cada fuga para entenderla:
💸 Fuga 1 — Perfil ancho, uso pequeño
Hay usuarios que «solo consultan reportes», pero heredaron un perfil con transacciones de escritura. Por eso cuentan como Advanced (1 FUE) en vez de Self-Service (1/30 de FUE). Multiplicado por decenas de usuarios, es la fuga más común. Además, es la más fácil de cerrar con ingeniería de autorizaciones.
👻 Fuga 2 — Consumo invisible (el caso del workflow)
Lo vimos en la práctica. Había aprobadores de workflow que solo hacen clic en «aprobar», pero estaban clasificados en tipos altos. El motivo: el diseño del flujo les daba participación formal en el proceso de compras. Es decir, la lógica que define los agentes de aprobación. Nadie sabía explicar el excedente de FUE, hasta que miramos el diseño del workflow. Ajustado el diseño, el excedente cayó.
🧟 Fuga 3 — Usuarios olvidados
Los usuarios técnicos, de carga y de colaboradores desvinculados siguen contando. Basta con que existan sin tipificación correcta o fecha de expiración. Por lo tanto, la higiene de usuarios es dinero directo.
¿Y el Digital Access? La licencia de los «usuarios que no son personas»
El FUE cubre personas que inician sesión en SAP. Sin embargo, hoy buena parte del trabajo no la hacen personas. La hace el e-commerce creando pedidos y el robot (RPA) registrando facturas. También el portal de proveedores grabando documentos y el WMS de un tercero moviendo stock. Ese uso «por interpósita mano» se llama acceso indirecto. Es decir, sistemas externos que escriben en SAP sin nadie conectado. Además, SAP lo licencia con otra vara: el Digital Access.
La lógica es un peaje por documento creado. En vez de contar usuarios, se cuenta cuántos documentos generan los sistemas externos dentro de SAP. SAP definió nueve tipos de documento que pagan ese peaje. Entre ellos, pedido de venta, factura, pedido de compra y orden de producción. También la orden de servicio y el documento financiero. Cada tipo tiene su peso en la cuenta. Además, vale un detalle importante: se cobra la creación, no la lectura. Consultar datos desde afuera no genera peaje; crear un documento, sí.
⚠️ ¿Por qué sorprende a tantas empresas?
Porque la integración crece en silencio. El e-commerce que creaba 200 pedidos/día pasa a crear 5.000. Además, un robot nuevo empieza a registrar facturas y un marketplace entra en operación. Ninguno de ellos «compra licencia» — sin embargo, todos generan documentos. En la renovación (o en una auditoría), la cuenta llega de una sola vez. En el RISE, el volumen de Digital Access se negocia en el contrato. Por lo tanto, quien llega a la mesa sin saber cuántos documentos genera negocia a ciegas.
🧭 Cómo defenderse (y pagar lo justo)
Hay tres movimientos. Primero, inventariar las integraciones: todo lo que escribe en SAP desde afuera (interfaces, robots, portales, EDI). Segundo, medir la creación de documentos por origen, con las herramientas de estimación de la propia SAP. Así se conoce el número real. Tercero, negociar con evidencia: en la renovación del RISE, llevar el volumen medido y la proyección de crecimiento. Además, del lado de la arquitectura, diseñar integraciones que no creen documentos sin necesidad. Es decir, agrupamiento y validación antes de la grabación.
En resumen: el FUE licencia a las personas; el Digital Access licencia a las máquinas. Un programa completo de FinOps en SAP RISE mira ambos. Además, mira la memoria y el consumo, las palancas que siguen.
Palanca 2 — Memoria HANA (sizing)
El contrato RISE también se dimensiona por la memoria de la base HANA — y cada escalón de sizing tiene precio. Como HANA guarda los datos en la RAM, el crecimiento de la base empuja el contrato hacia arriba. La respuesta, por lo tanto, es la gestión de volumen (DVM). En concreto: archiving, housekeeping técnico, anexos fuera de la base y data tiering (NSE). Base ligera = escalón menor en la renovación.
Palanca 3 — Consumo de nube
BTP, ambientes adicionales, integraciones y servicios consumidos por uso completan la cuenta. Aquí aplica el FinOps clásico: medir, asignar un dueño y optimizar. Veamos un trabajo reciente de FinOps en nube pública. Allí encontramos compromisos de uso (CUDs) detenidos en 0% de utilización. Además, había familias de máquinas con menos de la mitad del descuento aprovechado. Es decir, dinero contratado y no usado. En el RISE ocurre el equivalente.
Cómo ayuda Inove
Hacemos FinOps en SAP RISE de punta a punta. Eso incluye la radiografía del contrato y de la medición FUE, más la retipificación e ingeniería de autorizaciones. Además, DVM para frenar el sizing y la gestión del consumo de nube. Todo con la vivencia real de quien ya redujo excedentes de FUE y opera FinOps multi-cloud.
Nuestra visión de siempre: queremos que el cliente no tenga dolores de cabeza con TI y sea feliz. En la práctica, eso es pagar lo justo, nunca el escalón de arriba.
Por dónde empezar con FinOps en SAP RISE
- Radiografía del contrato — FUEs comprados × medidos × necesarios.
- Plan de retipificación — luego, cerrar las tres fugas sin quitarle acceso a nadie.
- DVM — además, un plan de volumen para la renovación.
- FinOps continuo — por último, licencia, memoria y nube vigiladas todo el año.
Lee también
- RISE with SAP: lo que sigue siendo tu responsabilidad
- Archiving SAP y DVM: frena el sizing de HANA
- Migración del SAP NFE al DRC
¿Quieres saber cuántos FUEs realmente necesitas? Habla con Inove Solutions. Al fin y al cabo, la radiografía suele pagarse sola.