FinOps no SAP RISE: FUE, Digital Access, memória e nuvem — pague o justo, não o degrau de cima
Quando se fala em FinOps, quase ninguém olha para o maior contrato de TI da empresa. Afinal, FinOps é a disciplina de controlar custo de nuvem. E esse contrato é o RISE with SAP. É justamente ali que mora dinheiro escondido. O custo do RISE é puxado por três alavancas. São elas: a licença (FUE), a memória do HANA (sizing) e o consumo de nuvem. Quem gerencia as três paga o justo. Quem não gerencia, por outro lado, paga o degrau de cima. E é exatamente isso que o FinOps SAP RISE resolve.
Por isso, neste guia explicamos o FinOps SAP RISE do zero. Damos destaque ao modelo FUE, que quase ninguém explica direito. Além disso, trazemos uma calculadora para você estimar a sua posição.
Alavanca 1 — FUE: a moeda única da licença SAP
Antes de tudo: no RISE, a SAP abandonou a venda de licenças por tipo. Em seu lugar, criou uma moeda única: o FUE (Full Use Equivalent). Ou seja, todos os usuários são convertidos em FUEs, e o contrato define quantos você comprou. Na prática, a conversão funciona assim:
Calcule os seus FUEs
Estimativa didática pela conversão padrão — o contrato e a medição oficial mandam. Peça o raio-X real à Inove.
O detalhe que pega todo mundo
A classificação não é pelo que o usuário faz — é pelo que ele PODE fazer. Ou seja, valem as autorizações que ele tem. A medição, então, aplica regras que mapeiam perfil → tipo de usuário. A seguir, clique em cada ralo para entender:
💸 Ralo 1 — Perfil largo, uso pequeno
Por exemplo: o usuário que “só consulta relatórios”, mas herdou um perfil com transações de escrita. Ele conta como Advanced (1 FUE) em vez de Self-Service (1/30 de FUE). Multiplicado por dezenas de usuários, portanto, é o ralo mais comum. Também é o mais fácil de fechar com engenharia de autorizações.
👻 Ralo 2 — Consumo invisível (o caso do workflow)
Vimos na prática: aprovadores de workflow que só clicam “aprovar” sendo classificados em tipos altos. O motivo era o desenho do fluxo (a lógica que define os agentes de aprovação). Ele lhes dava participação formal no processo de compras. Ninguém sabia explicar o excedente de FUE — até olharmos o desenho do workflow. Como resultado do ajuste, o excedente caiu.
🧟 Ralo 3 — Usuários esquecidos
Além disso, usuários técnicos, de carga e de colaboradores desligados continuam contando. Isso vale enquanto existirem sem tipificação correta ou data de expiração. Portanto, higiene de usuários é dinheiro direto.
E o Digital Access? A licença dos “usuários que não são pessoas”
O FUE cobre pessoas logando no SAP. No entanto, hoje boa parte do trabalho não é feita por pessoas. É o e-commerce criando pedidos e o robô (RPA) lançando faturas. É também o portal de fornecedores gravando documentos e o WMS de terceiro movimentando estoque. Esse uso “por tabela” — sistemas externos escrevendo no SAP sem ninguém logado — chama-se acesso indireto. E a SAP o licencia por outra régua: o Digital Access.
A lógica, por sua vez, é um pedágio por documento criado. Em vez de contar usuários, conta-se quantos documentos os sistemas externos geram dentro do SAP. A SAP definiu nove tipos de documento que pagam esse pedágio. Entre eles estão pedido de venda, fatura, pedido de compra, ordem de produção, ordem de serviço e documento financeiro. Cada tipo tem seu peso na conta. Além disso, vale um detalhe importante: cobra-se a criação, não a leitura. Consultar dados de fora não gera pedágio; criar documento, sim.
Digital Access na prática: a surpresa e a defesa
⚠️ Por que isso surpreende tanta empresa?
Porque, na prática, a integração cresce em silêncio. O e-commerce que criava 200 pedidos/dia passa a criar 5.000. Um robô novo começa a lançar notas. E um marketplace entra no ar. Nenhum deles “compra licença” — mas todos geram documentos. Como resultado, na renovação (ou numa auditoria) a conta chega de uma vez. No RISE, o volume de Digital Access se negocia em contrato. Portanto, quem chega à mesa sem saber quantos documentos gera negocia no escuro.
🧭 Como se defende (e se paga o justo)
Em resumo, são três movimentos. (1) Inventariar as integrações — tudo que escreve no SAP vindo de fora: interfaces, robôs, portais, EDI. (2) Medir a criação de documentos por origem, com as ferramentas de estimativa da própria SAP. Assim se chega ao número real. (3) Negociar com evidência — na renovação do RISE, levar o volume medido e a projeção de crescimento. E, do lado da arquitetura, desenhar integrações que não criem documento à toa (agrupamento, validação antes da gravação).
Em resumo: FUE licencia as pessoas; Digital Access licencia as máquinas. O FinOps SAP RISE completo, portanto, olha os dois. E olha também a memória e o consumo, as alavancas a seguir.
Alavanca 2 — Memória HANA (sizing)
Além da licença, o contrato RISE é dimensionado pela memória do banco HANA. E cada degrau de sizing tem preço. Como o HANA guarda os dados na RAM, o crescimento do banco, consequentemente, empurra o contrato para cima. A resposta, portanto, é a gestão de volume (DVM). Isso inclui archiving, housekeeping técnico, anexos fora do banco e data tiering (NSE). Banco enxuto = degrau menor na renovação.
Alavanca 3 — Consumo de nuvem
Por fim, BTP, ambientes adicionais, integrações e serviços consumidos por uso completam a conta. Aqui, então, vale o FinOps clássico: medir, atribuir dono e otimizar. Em um trabalho recente de FinOps em nuvem pública, por exemplo, encontramos duas surpresas. A primeira: compromissos de uso (CUDs) parados em 0% de utilização. A segunda: famílias de máquina com menos da metade do desconto aproveitado. Ou seja, dinheiro contratado e não usado. No RISE, igualmente, acontece o equivalente.
Como a Inove ajuda
Fazemos o FinOps SAP RISE completo. Isso inclui raio-X do contrato e da medição FUE, retipificação e engenharia de autorizações. Inclui ainda DVM para segurar o sizing e a gestão do consumo de nuvem. Tudo com a vivência real de quem já reduziu excedente de FUE e opera FinOps multi-cloud.
Nossa visão de sempre: queremos que o cliente não tenha dor de cabeça com TI e seja feliz. Ou seja, pagando o justo, nunca o degrau de cima.
FinOps SAP RISE na prática: por onde começar
- Raio-X do contrato — FUEs comprados × medidos × necessários.
- Plano de retipificação — em seguida, fechar os três ralos sem tirar acesso de ninguém.
- DVM — depois, o plano de volume para a renovação.
- FinOps contínuo — por fim, licença, memória e nuvem vigiados o ano todo.
Leia também
- RISE with SAP: o que continua sendo responsabilidade sua
- Archiving SAP e DVM: segure o sizing do HANA
- Migração do SAP NFE para o DRC
Então, quer saber quantos FUEs você realmente precisa? Fale com a Inove Solutions — o raio-X costuma se pagar sozinho.