Tópico 6.5 — Gestão de custos de tecnologia e FinOps em nuvem

Na saúde e nos cuidados, o custo de funcionamento da tecnologia é dinheiro público gasto a cada hora, quer alguém esteja olhando ou não; gerir esse custo — sobretudo na nuvem — é, portanto, uma disciplina operacional de zelo, e não um exercício financeiro anual.

Por que isso importa na saúde e nos cuidados#

Durante a maior parte da história da tecnologia do NHS, o dinheiro era gasto uma vez. Comprava-se um servidor, uma matriz de armazenamento ou uma licença, capitalizava-se, e ele ficava num rack depreciando em silêncio por cinco anos. O custo era visível, delimitado e em grande parte fixo. A computação em nuvem quebrou esse modelo. Agora o medidor corre continuamente, a fatura muda todo dia, milhares de pequenas decisões de engenheiros movimentam dinheiro real e a nota chega um mês depois de o gasto já ter sido feito. Uma tarefa mal configurada deixada rodando num fim de semana prolongado, um ambiente de teste que ninguém desligou, um bucket de armazenamento que cresce em silêncio — cada um é dinheiro público vazando em tempo real.

Isso importa na saúde e nos cuidados por três razões além da parcimônia comum. Primeiro, é dinheiro público mantido em confiança: cada libra gasta em computação ociosa ou numa licença de software duplicada é uma libra que não é gasta em cuidado, e vocês respondem por ela a auditores, ao conselho e, em última instância, ao público (ver Tópico 6.4 — Governança e garantia). Segundo, o dinheiro segue regras peculiares. Os orçamentos do NHS se dividem rigidamente entre capital e custeio, e a passagem da compra de ativos para o aluguel de serviços converte, em silêncio, um no outro — uma decisão técnica com consequência orçamentária capaz de pegar de surpresa um diretor financeiro. Terceiro, o custo sem gestão é um risco de segurança e de continuidade disfarçado: as equipes que temem uma fatura surpresa subdimensionam a resiliência, adiam correções ou não conseguem arcar com os ambientes de que um serviço seguro precisa.

O modo de falha é distintivo e comum. As organizações migram para a nuvem esperando economias, celebram a migração e então, dezoito meses depois, descobrem que a fatura é maior do que o data center que substituiu — e ninguém sabe dizer por quê. O problema raramente é a tecnologia. É que ninguém é dono do custo de funcionamento como disciplina viva: os engenheiros otimizam a velocidade de entrega, as finanças veem uma única fatura opaca e o ciclo de retroalimentação entre uma decisão de projeto e seu custo nunca se fecha. Este tópico trata de fechar esse ciclo.

Conceitos centrais#

A computação em nuvem entrega recursos computacionais — servidores, armazenamento, bancos de dados, redes — como um serviço sob demanda e medido, e não como equipamento próprio. Sua característica comercial definidora é a elasticidade: é possível adquirir e liberar capacidade em minutos e pagar apenas pelo que se consome. Essa mesma elasticidade é a razão pela qual a gestão de custos é difícil. A arquitetura técnica da nuvem e do legado é tratada no Tópico 4.0 (ver Tópico 4.0 — Arquitetura técnica, nuvem e sistemas legados); este tópico é dono do que acontece com o custo uma vez que essa arquitetura está em funcionamento.

A mudança contábil central é da despesa de capital (capex) — dinheiro gasto para adquirir um ativo fixo, depois depreciado ao longo de anos — para a despesa operacional (opex), um custo corrente de operar um serviço. Comprar um servidor é capex; alugar a capacidade equivalente na nuvem é opex. No NHS isso não é um detalhe contábil neutro: capital e custeio são alocados separadamente, controlados separadamente e raramente fungíveis; deslocar gasto de capex para opex pode, portanto, aliviar uma pressão enquanto cria outra. A avaliação prévia dessas escolhas — o Five Case Model, noções básicas de capital versus custeio — pertence à gestão financeira e aos casos de negócio (ver Tópico 6.0 — Gestão financeira e casos de negócio); este tópico retoma onde o caso de negócio termina e o medidor começa.

FinOps — contração de "operações financeiras na nuvem" (cloud financial operations) — é a disciplina operacional que reúne as equipes de engenharia, finanças e negócio para gerir o custo da nuvem como uma responsabilidade compartilhada e guiada por dados. Promovida pela FinOps Foundation (parte da Linux Foundation), costuma ser descrita como um ciclo de vida com três fases iterativas: Informar (dar a todos visibilidade do que está sendo gasto e por quê, por meio de alocação e relatórios), Otimizar (agir sobre essa visibilidade para eliminar o desperdício e comprar mais barato) e Operar (incorporar a consciência de custos aos modos de trabalho e à governança do dia a dia). O FinOps não é deliberadamente só corte de custos; seu objetivo é maximizar o valor de negócio de cada libra de gasto em nuvem, o que às vezes significa gastar mais porque o retorno o justifica.

Dois mecanismos de alocação tornam o custo visível. O showback reporta a cada equipe ou serviço o que custa o seu consumo de tecnologia, para transparência e mudança de comportamento, sem movimentar dinheiro. O chargeback vai além e de fato recupera o custo do orçamento da unidade consumidora — uma forma de alocação de custos interna que atribui os custos de serviços compartilhados ao centro de custo que os consome. Ambos dependem de marcação (tagging): rotular cada recurso de nuvem com metadados (serviço, equipe, ambiente, voltado ao paciente ou não) para que uma fatura indiferenciada possa ser dividida em linhas significativas.

Três outras ideias atravessam o tópico. O custo total de propriedade (TCO) é o custo direto e indireto completo de uma tecnologia ao longo de toda a vida — não apenas a licença ou a computação, mas as pessoas, a integração, o suporte, a saída e a desativação ao redor. A gestão de ativos de software (SAM) é a disciplina de rastrear e otimizar o software que uma organização possui e aluga, cada vez mais dominada por assinaturas de software como serviço (SaaS) e por licenças de software por usuário que se renovam em silêncio. E a economia unitária expressa o custo como uma taxa frente a algo que importa à organização — custo por paciente, por consulta, por encaminhamento, por chamada de API —, para que uma fatura em alta possa ser julgada frente ao valor crescente e não no vácuo. O escalonamento automático (autoscaling), o ajuste automático da capacidade à carga, e as práticas mais amplas de gestão financeira do ITIL se situam ao lado dessas ideias como alavancas operacionais.

Boas práticas#

1. Tornem o custo visível antes de tentar cortá-lo — Informar primeiro. Não se pode gerir o que ninguém vê, e a fatura padrão da nuvem é um único número opaco que chega um mês atrasado. Estabeleçam visibilidade de custos quase em tempo real, desdobrada por serviço, equipe, ambiente e, quando puderem, por serviço clínico, para que as pessoas que tomam decisões de projeto vejam o custo dessas decisões em dias, e não em trimestres. A visibilidade, por si só, muda o comportamento: as equipes que enxergam o próprio gasto rotineiramente encontram desperdício que nenhum relatório financeiro central jamais teria captado.

2. Marquem tudo e tratem o gasto sem marcação como um defeito. A alocação de custos é tão boa quanto os metadados por baixo; um recurso sem marcação é dinheiro que não se pode atribuir, questionar nem recuperar. Acordem um padrão obrigatório de marcação — dono, serviço, ambiente, centro de custo, classificação de dados —, imponham-no por política automatizada para que recursos não conformes sejam sinalizados ou bloqueados na criação e reportem a proporção do gasto devidamente alocado como métrica principal. Num contexto de saúde, marcar se uma carga de trabalho é voltada ao paciente ou crítica clínica também permite proteger as coisas certas ao otimizar o resto.

3. Escolham showback ou chargeback deliberadamente e ajustem à sua responsabilização. O showback constrói a consciência de custos com suavidade e é o ponto de partida certo para a maioria das organizações; o chargeback cria consequência orçamentária real, mas precisa de alocação madura e da vontade política de defender os números. Decidam que comportamento estão tentando criar — consciência ou genuína propriedade financeira — e sejam honestos de que um chargeback prematuro, com dados frágeis, gerará disputas que desacreditam todo o esforço. Qualquer que seja a escolha, o objetivo é um ciclo fechado em que as decisões de uma equipe afetem visivelmente um orçamento que ela reconhece como seu.

4. Eliminem o desperdício sem trégua: redimensionem, agendem e apaguem. Uma grande parcela do gasto em nuvem na maioria dos parques é puro desperdício — instâncias superdimensionadas, bancos de dados grandes demais, armazenamento órfão e ambientes não produtivos rodando vinte e quatro horas por dia para uma equipe de nove às cinco. Redimensionem os recursos para a carga observada e não para um pico imaginado, agendem os ambientes de desenvolvimento e teste para desligar à noite e nos fins de semana e deem um ciclo de vida ao armazenamento e aos snapshots para que nada se acumule para sempre. Esta é a economia mais rápida e de menor risco disponível e se repete todo mês, uma vez automatizada.

5. Comprem capacidade comprometida para a sua linha de base previsível. Os provedores de nuvem dão grandes descontos — muitas vezes substanciais — em troca de um compromisso de um ou três anos por meio de instâncias reservadas, planos de economia ou acordos de uso comprometido, e a linha de base estável de um serviço de saúde (o prontuário eletrônico central, o motor de integração sempre ligado) é exatamente a carga previsível que esses instrumentos recompensam. Analisem o uso estável, comprometam-se com ele para capturar o desconto e mantenham capacidade sob demanda ou com escalonamento automático para o pico variável por cima. Revisem os compromissos regularmente para não travar capacidade que vocês já reprojetaram e coordenem as compras com os colegas de aquisições e comerciais (ver Tópico 6.3 — Aquisições e contratações).

6. Gerenciem a proliferação de SaaS e de licenças tão deliberadamente quanto a computação em nuvem. A fatura da nuvem é visível; as vinte assinaturas de SaaS compradas em cartões departamentais, as licenças por usuário atribuídas a quem saiu e as ferramentas sobrepostas que fazem o mesmo trabalho não são — e, juntas, muitas vezes rivalizam com o gasto de infraestrutura. Mantenham um registro vivo de assinaturas e direitos de software, reconciliem as licenças com os usuários nomeados e o uso reais, cancelem ou reduzam o que não é usado e consolidem as ferramentas duplicadas. A gestão de ativos de software aqui é tanto uma disciplina de custos quanto de segurança, porque o SaaS desconhecido é também fluxo de dados sem gestão (ver Tópico 1.7 — Governança da informação, proteção de dados e cibersegurança).

7. Julguem o custo pela economia unitária, e não pelo tamanho da fatura. Uma fatura em alta não é automaticamente ruim, e uma em queda não é automaticamente boa; o que importa é o custo relativo ao valor entregue. Definam métricas de custo unitário que façam sentido clínica e operacionalmente — custo por paciente monitorado, por consulta agendada, por encaminhamento processado, por mil chamadas de API — e acompanhem-nas ao longo do tempo para distinguir eficiência de mero crescimento e defender o gasto que genuinamente se paga (ver Tópico 6.2 — Realização de benefícios e gestão de valor e Tópico 10.1 — Indicadores-chave de desempenho (KPIs)). A economia unitária é também como vocês ligam o custo de funcionamento de volta ao caso econômico de saúde do serviço (ver Tópico 6.1 — Economia da saúde).

8. Pensem em custo total de propriedade em todo o parque, incluindo a saída. O preço de etiqueta de uma plataforma é uma fração do seu custo de vida inteira; integração, migração de dados, equipe de suporte, treinamento, taxas de saída de dados (egress) e o eventual custo de sair pertencem todos ao quadro. Avaliem as opções pelo custo total de propriedade ao longo de uma vida realista, desconfiem especialmente das taxas de saída de dados e dos serviços proprietários que elevam o custo de saída e lembrem que o aprisionamento é um custo futuro mesmo quando parece gratuito hoje (as aquisições são donas do lado contratual do aprisionamento — ver Tópico 6.3 — Aquisições e contratações). Uma visão de TCO também impede a organização de se congratular por uma plataforma barata que é, em silêncio, cara de operar.

9. Incorporem o custo à engenharia e à governança para que opere continuamente. O FinOps falha quando é uma campanha trimestral de limpeza e tem sucesso quando o custo é uma consideração permanente nas revisões de projeto, nas decisões de arquitetura e nos pipelines de entrega (ver Tópico 3.6 — DevOps e excelência em engenharia). Deem às equipes orçamentos de custo e alertas de anomalia, incluam o impacto estimado de custo nas decisões de arquitetura significativas e configurem alertas automatizados e barreiras rígidas de gasto para que uma tarefa descontrolada seja pega em horas, e não na fatura do mês seguinte. O objetivo da fase Operar é que a consciência de custos se torne higiene de engenharia comum e não uma auditoria externa.

10. Equilibrem o custo com o valor clínico e a sustentabilidade, e não apenas com o custo. A opção mais barata nem sempre é a certa: uma economia agressiva que remove resiliência, atrasa uma correção ou degrada um serviço voltado ao paciente troca dinheiro por risco na direção errada. Pesem as decisões de custo explicitamente frente ao valor clínico e ao carbono, já que a computação que vocês eliminam como desperdício é também emissão que evitam — a otimização de custos e a de sustentabilidade frequentemente apontam para o mesmo lado (ver Tópico 8.5 — Sustentabilidade e emissões líquidas zero). Tornem as concessões visíveis e com dono, em vez de deixar a pressão de custos corroer a segurança em silêncio.

Perguntas para discutir com a sua equipe#

1. Quem de fato é dono do custo de funcionamento da nossa tecnologia — e esse dono tem tanto a visibilidade quanto a autoridade para mudá-lo? Isto importa porque o custo sem dono é o que cresce sem controle: os engenheiros otimizam a entrega, as finanças veem uma fatura e ninguém é responsável pela lacuna entre elas. Debatam se a propriedade do custo está numa equipe central de finanças que não consegue influenciar decisões de engenharia, ou em engenheiros que não conseguem ver a fatura, ou, idealmente, numa capacidade conjunta que abranja ambos. Sondem se o dono consegue de fato agir — consegue desligar um ambiente ocioso, bloquear um recurso sem marcação ou recusar um projeto desnecessariamente caro — ou se só consegue reportar depois que o dinheiro foi gasto. Considerem a tensão específica da saúde: os donos de custos jamais devem poder comprometer a segurança clínica ou a continuidade em nome da economia; onde estão essas barreiras? Uma boa resposta, honesta, nomeia um dono ou fórum responsável específico, confirma que ele tem visibilidade quase em tempo real e direitos de decisão reais e admite com franqueza onde hoje a resposta é "a fatura simplesmente chega e nós pagamos".

2. Quanto do nosso gasto em nuvem e software está genuinamente entregando valor, e como saberíamos? A maioria das organizações não consegue responder a isso, porque acompanha a fatura total, mas não o valor que ela compra, de modo que todo custo parece igualmente justificado ou igualmente suspeito. Discutam se vocês têm métricas de custo unitário que liguem o gasto a algo clínico ou operacional — custo por paciente, por consulta, por chamada de API — ou se só têm um número indiferenciado que sobe. Tragam à tona a concessão entre corte de custos e valor: o objetivo não é a menor fatura, mas o melhor retorno, o que às vezes significa gastar mais num serviço que claramente se paga. Considerem quanto do gasto é desperdício mensurável — ambientes ociosos, instâncias superdimensionadas, licenças para quem saiu — versus carga genuinamente produtiva e sejam honestos sobre quanta confiança vocês têm nessa divisão. Uma boa resposta distingue desperdício de valor com evidências, tem ao menos algumas métricas reais de economia unitária e resiste ao reflexo de que uma fatura menor é automaticamente melhor.

3. Quando deslocamos (ou deslocarmos) gasto de capital para despesa operacional, quem entendeu as consequências orçamentárias e de longo prazo? A passagem de capex para opex é muitas vezes tratada como uma migração puramente técnica, mas muda de qual orçamento vem o dinheiro, converte um custo pontual num recorrente permanente e pode comprometer em silêncio a organização com um passivo crescente por anos. Debatam se as suas equipes de finanças e digital modelaram isso em conjunto antes de se comprometer — alguém mapeou a trajetória plurianual de opex, os custos de saída e o efeito sobre o equilíbrio entre capital e custeio que o NHS controla tão de perto? Considerem a armadilha da honestidade: as migrações para a nuvem são frequentemente vendidas com economias que pressupõem uma gestão de custos disciplinada que nunca se materializa; o seu caso de negócio se baseava numa capacidade de FinOps que vocês de fato construíram? Explorem o que acontece quando a fatura recorrente cresce mais depressa do que o orçamento que a financia e quem é responsável quando isso ocorre. Uma boa resposta mostra finanças e digital raciocinando juntos sobre todo o ciclo de vida, e não uma equipe técnica otimizando a velocidade da migração enquanto as finanças descobrem as consequências depois (ver Tópico 6.0 — Gestão financeira e casos de negócio).

4. Quão confiantes estamos de que um custo descontrolado seria pego em horas e não na fatura do mês seguinte? O perigo definidor da nuvem medida é a latência entre um erro e sua descoberta: uma tarefa mal configurada, um superprovisionamento acidental ou um ambiente de teste deixado ligado podem queimar dinheiro público em silêncio por semanas até que uma fatura mensal o revele. Discutam se vocês têm alertas de anomalia e barreiras rígidas de gasto ligados às pessoas que podem agir, ou se o único mecanismo de detecção é a fatura chegando um mês depois. Sondem o equilíbrio entre barreiras que genuinamente impedem o desperdício e controles tão agressivos que estrangulam uma carga clínica legítima no pior momento — o alerta que grita "lobo" é logo ignorado, e a barreira que bloqueia um serviço seguro é pior do que o gasto que evita. Considerem quem recebe um alerta de anomalia às 2 da manhã e se tem tanto a autoridade quanto a confiança para agir sobre ele sem medo de quebrar algo voltado ao paciente. Uma boa resposta descreve um ciclo testado de detecção e resposta medido em horas, nomeia quem é dono dele e é honesta sobre quantas surpresas passadas só foram descobertas quando a fatura chegou.

5. Quanto software estamos pagando que não conseguimos ver — e quem notaria se uma assinatura fosse renovada por uma ferramenta que ninguém usa? A fatura de computação em nuvem pelo menos é visível; a proliferação de assinaturas de SaaS compradas em cartões departamentais, de licenças por usuário ainda atribuídas a quem saiu e de ferramentas sobrepostas que fazem o mesmo trabalho não é, e no entanto, juntas, muitas vezes rivalizam com o gasto de infraestrutura. Discutam se vocês mantêm um registro vivo de direitos de software reconciliado com os usuários nomeados reais, ou se as renovações passam em silêncio porque nenhuma pessoa é dona do quadro inteiro. Tragam à tona a dimensão de segurança tanto quanto a de custo: o SaaS desconhecido é também fluxo de dados sem gestão; o software paralelo é, assim, dinheiro vazando e uma lacuna de governança da informação (ver Tópico 1.7 — Governança da informação, proteção de dados e cibersegurança). Considerem a razão organizacional disso — orçamentos descentralizados e pagamento fácil por cartão tornam sem atrito adquirir software e quase impossível aposentá-lo — e o que precisaria mudar para que alguém fosse responsável pelo total. Uma boa resposta admite quanto do gasto com software do parque está genuinamente mapeado, distingue ferramentas deliberadas de proliferação acumulada e consegue apontar uma reconciliação que de fato cancelou alguma coisa.

6. Quando a pressão de custos e a segurança clínica puxam em direções opostas, como garantimos que a segurança vença — e conseguimos provar que venceu? Toda alavanca de otimização deste tópico — redimensionar, desligar coisas, adiar gastos, comprar a opção mais barata — pode, aplicada sem cuidado, remover resiliência, atrasar uma correção ou degradar um serviço voltado ao paciente, trocando dinheiro por risco exatamente na direção errada. Debatam se as suas decisões de custo carregam uma verificação explícita de segurança, de modo que uma carga marcada como crítica clínica seja revista separadamente antes de qualquer mudança tocá-la, ou se as metas de custo podem corroer a segurança em silêncio e de forma invisível. Considerem o ângulo da sustentabilidade, que normalmente se alinha em vez de conflitar: a computação eliminada como desperdício é também carbono evitado; a otimização de custos e a de emissões líquidas zero frequentemente apontam, portanto, para o mesmo lado (ver Tópico 8.5 — Sustentabilidade e emissões líquidas zero) — mas sejam honestos sobre os casos em que divergem e algo precisa ceder. Explorem quem segura a linha quando uma meta de economia e uma exigência de resiliência colidem e se essa concessão é feita de modo visível e com dono, ou feita em silêncio sob pressão orçamentária. Uma boa resposta mostra a segurança e a continuidade tratadas como restrições que o custo não pode atropelar, com um mecanismo real para impô-las, e não meramente um valor declarado que verga quando a fatura cresce.

Na prática: um exemplo de saúde e cuidados#

O Northmarsh Integrated Care System migrou sua plataforma de análises, vários serviços voltados ao paciente e um grande data lake para a nuvem pública ao longo de dois anos, financiado por um caso de negócio que prometia uma economia modesta frente ao envelhecido data center que substituía. A migração foi entregue no prazo e celebrada. Dezoito meses depois, a fatura mensal da nuvem corria a quase o dobro do valor do caso de negócio, crescendo a cada trimestre, e quando o diretor financeiro pediu à equipe digital que explicasse o aumento, ninguém conseguiu detalhar o número. A fatura era uma única linha do provedor, e nada por baixo dela tinha marcação.

O conselho encomendou uma pequena iniciativa de FinOps em vez de uma ordem geral de corte de custos. Sua primeira tarefa foi Informar: a equipe montou uma ferramenta de visibilidade de custos, tornou obrigatório um padrão de marcação e passou seis semanas marcando retroativamente os recursos e reconciliando-os com os serviços que os possuíam. O quadro que emergiu era familiar. Os ambientes de desenvolvimento e teste da equipe de ciência de dados — instâncias grandes e caras — rodavam continuamente, inclusive de noite e nos fins de semana, quando ninguém os usava. O data lake migrado fora levantado e deslocado para armazenamento premium sem política de ciclo de vida, de modo que cinco anos de snapshots superados se acumulavam a preço cheio. Três equipes distintas pagavam por ferramentas sobrepostas de análises em SaaS compradas com orçamentos diferentes. E uma tarefa em lote mal configurada durante a migração reprocessava o mesmo conjunto de dados todas as noites havia meses.

A fase Otimizar foi deliberadamente escalonada por risco. Os ambientes não produtivos foram agendados para desligar fora do horário de trabalho, economizando uma grande soma recorrente sem nenhum impacto clínico. O armazenamento foi escalonado em camadas e recebeu um ciclo de vida para que os snapshots antigos expirassem automaticamente. A carga de linha de base estável dos serviços sempre ligados voltados ao paciente foi analisada e coberta por um desconto de uso comprometido de três anos, negociado com os colegas de aquisições. As ferramentas de SaaS duplicadas foram consolidadas numa só. De forma decisiva, antes que qualquer mudança tocasse uma carga voltada ao paciente ou crítica clínica, sua marcação a sinalizava para uma revisão separada e cautelosa — o custo nunca foi autorizado a se sobrepor à segurança ou à resiliência.

Então veio Operar, que foi o que mais importou. Cada equipe de serviço recebeu um relatório mensal de showback e um orçamento de custos, alertas de anomalia foram ligados para sinalizar em horas qualquer salto repentino e uma verificação leve de custo foi acrescentada à lista de verificação de revisão de arquitetura, para que os novos projetos carregassem uma estimativa de custo de funcionamento. Em dois trimestres, a fatura caiu de volta abaixo da linha de base do data center original e, mais importante, deixou de ser um mistério — cada libra era atribuível a um serviço, e o ICS passou a poder reportar o custo por usuário ativo de sua plataforma de análises e defendê-lo como valor. A economia foi real, mas a vitória durável foi o ciclo fechado: as decisões agora tinham consequências financeiras visíveis e com dono.

Perspectivas setoriais#

Startup#

Para uma startup de saúde digital, o custo da nuvem é matemática de sobrevivência: costuma ser a maior linha isolada de infraestrutura, e a taxa de queima de caixa determina diretamente a pista. A vantagem de quem está começando é que a disciplina de FinOps pode ser incorporada desde o primeiro commit — marcação desde o primeiro dia, painéis de custo que todo engenheiro vê e a economia unitária (custo para atender um paciente ou um cliente) acompanhada como métrica de negócio central, que os investidores escrutinarão. O risco é otimizar cedo demais, gastando escasso tempo de engenharia para raspar centavos de uma fatura ainda minúscula, ou travar-se em compromissos longos antes de a arquitetura se estabilizar. A disciplina que escala é cultural: tratem o custo como uma métrica de produto, e não como uma reflexão tardia das finanças, para que, quando a startup ganhar um contrato do NHS, seu custo de atendimento já seja conhecido e defensável.

Pequena empresa#

Um pequeno prestador estabelecido — um consultório de clínica geral, uma farmácia comunitária, uma casa de repouso, uma clínica de unidade única ou um pequeno fornecedor de tecnologia em saúde — paga as mesmas faturas medidas de nuvem e SaaS que um grande hospital, mas não tem capacidade dedicada de FinOps ou de TI para geri-las; a prioridade prática é, portanto, um punhado de hábitos de alta alavancagem, e não uma disciplina completa. As vitórias realistas são eliminar o desperdício óbvio (desligar o que não é usado, apagar armazenamento antigo), manter uma lista simples de toda assinatura e licença com sua data de renovação para que nada se renove despercebido e desconfiar de compromissos longos ou de aprisionamento que uma pequena organização não consegue desfazer com facilidade. A visibilidade de custos normalmente significa uma olhada mensal no console do provedor e não um painel em tempo real, e boa parte do parque pode ser SaaS escolhido para outra pessoa operar, o que desloca a disciplina de afinar infraestrutura para gerir assinaturas e ler contratos. A tensão inevitável é que os mesmos deveres de governança da informação e de continuidade se aplicam como a uma grande organização, mas, com caixa apertado e pouca equipe, a tentação de adiar uma correção ou abrir mão de resiliência para economizar é real — de modo que, mesmo aqui, importa uma regra clara de que a segurança não se troca por custo, idealmente apoiada por compras compartilhadas ou por acordos-quadro, para que o pequeno prestador não negocie sozinho preços de nuvem e de licenças (ver Tópico 4.1 — Plataformas e serviços compartilhados).

Grande organização#

Um grande hospital do NHS ou ICS opera um parque disperso e em expansão — data centers legados, várias contas de nuvem, centenas de assinaturas de SaaS compradas por dezenas de orçamentos — e seu desafio é a coordenação e a alocação em escala. O objetivo realista é uma capacidade central de FinOps que dê às equipes federadas visibilidade e barreiras sem se tornar um gargalo: um padrão comum de marcação, showback para todo serviço, compras de uso comprometido negociadas centralmente e o custo incorporado à governança de arquitetura. O problema mais difícil costuma ser organizacional, e não técnico — fazer com que a engenharia e as finanças, que falam línguas diferentes e se reportam a diretores diferentes, compartilhem uma visão única da verdade. Nessa escala, os maiores ganhos vêm de poucas disciplinas em todo o parque aplicadas de modo consistente (marcação, eliminação de desperdício, uso comprometido, racionalização de SaaS) e não da otimização heroica de qualquer serviço isolado, e o trabalho de custos deve ser explicitamente delimitado para jamais corroer a segurança clínica ou a continuidade.

Governo#

Um órgão nacional — NHS England, um departamento de saúde descentralizado, uma organização de serviços compartilhados — molda o ambiente de custos em que todo prestador opera. Sua alavancagem é a agregação: negociar acordos nacionais de nuvem e licenciamento para que os hospitais não barganhem cada um de uma posição fraca, publicar orientações de FinOps e TCO para que a boa prática seja o padrão e construir plataformas compartilhadas cujo custo unitário caia à medida que mais organizações as usem (ver Tópico 4.1 — Plataformas e serviços compartilhados). O governo também é dono das regras de capital versus custeio que tornam tão consequente a passagem de capex para opex e pode aliviar ou piorar esse atrito pela forma como aloca e flexibiliza orçamentos. Sua responsabilização é perante o Parlamento e o público pelo custo-benefício em todo o sistema; carrega, portanto, o dever de tornar o custo transparente e comparável entre organizações e de garantir que a pressão de custos não amplie em silêncio as iniquidades nos serviços que os pacientes recebem.

Modos de falha comuns#

• A fatura-mistério. Uma única fatura opaca chega todo mês, ninguém consegue detalhá-la e, quando é questionada, o dinheiro já foi gasto há muito. Corrijam com marcação e visibilidade quase em tempo real antes de qualquer outra coisa.
• Levantar-e-deslocar e depois fingir surpresa. Migrar servidores para a nuvem inalterados, mantê-los rodando em tamanho cheio o dia todo e esperar que a economia da nuvem apareça por mágica. A nuvem só economiza quando se usa a sua elasticidade — redimensionar, agendar e escalar.
• Corte de custos em vez de gestão de custos. Uma poda pontual de pânico que economiza dinheiro por um trimestre, danifica a resiliência e volta a crescer em silêncio porque nada mudou o comportamento de fundo. O FinOps é um ciclo contínuo, e não uma campanha.
• Otimizar a segurança para fora. Desligar redundância, atrasar correções ou subdimensionar um serviço clínico para atingir uma meta de custo. As decisões de custo devem ser pesadas explicitamente frente ao valor clínico e jamais atropelá-lo.
• SaaS nas sombras. Dezenas de assinaturas em cartões departamentais, licenças ainda atribuídas a quem saiu e três ferramentas fazendo um só trabalho — invisíveis porque não estão na fatura da nuvem. Mantenham um registro vivo de software e reconciliem-no.
• Chargeback prematuro. Recuperar custos das equipes usando dados de alocação imaturos e contestados, gerando discussões que desacreditam todo o esforço. Comecem pelo showback; conquistem a qualidade dos dados antes de movimentar dinheiro.
• Comprometer-se às cegas. Comprar reservas de três anos para capacidade que vocês reprojetam seis meses depois, ou nunca comprar compromissos para uma linha de base estável e pagar taxas cheias sob demanda para sempre. Combinem o compromisso com a carga genuinamente previsível e revisem-no.

Modelo de maturidade#

Lista de verificação#

• O gasto em nuvem e em tecnologia é visível quase em tempo real, desdobrado por serviço e equipe, para as pessoas que tomam decisões de projeto.
• Um padrão obrigatório de marcação é imposto automaticamente, e a proporção de gasto devidamente alocado é uma métrica acompanhada.
• O showback (ou, quando maduro, o chargeback) dá a cada serviço uma visão reconhecível do que sua tecnologia consome.
• Os ambientes não produtivos são agendados para desligar fora do horário de trabalho; os recursos são redimensionados para a carga observada; o armazenamento tem ciclo de vida.
• A linha de base previsível é coberta por descontos de uso comprometido ou capacidade reservada, revistos regularmente.
• Um registro vivo de ativos de software reconcilia as assinaturas e licenças de SaaS com os usuários e o uso reais.
• Métricas de custo unitário (custo por paciente, consulta, encaminhamento, chamada de API) são definidas e acompanhadas frente ao valor.
• As opções são avaliadas pelo custo total de propriedade ao longo de uma vida realista, incluindo custos de saída de dados e de saída.
• O impacto de custo é item permanente nas revisões de arquitetura, e barreiras automatizadas e alertas de anomalia pegam o gasto descontrolado em horas.
• As decisões de custo que afetam cargas voltadas ao paciente ou críticas clínicas são revistas separadamente e jamais se sobrepõem à segurança, à resiliência ou à sustentabilidade.
• Finanças e digital modelam em conjunto a trajetória de capex para opex, incluindo o passivo recorrente plurianual, antes de grandes compromissos.

Fontes-chave#

• FinOps Foundation — FinOps Framework (ciclo de vida Informar / Otimizar / Operar, princípios, capacidades e personas) — o corpo de conhecimento reconhecido para as operações financeiras na nuvem.
• HM Treasury — The Green Book (avaliação e apreciação) e regras de gasto público sobre a distinção entre despesa de capital e de custeio (recursos).
• NHS England — orientações de nuvem, tecnologia e gasto digital, incluindo a adoção de nuvem e o tratamento de capital e custeio no investimento digital do NHS.
• Orientações de otimização de custos bem arquitetadas dos provedores de nuvem — AWS Well-Architected Cost Optimization Pillar, Microsoft Azure Well-Architected Framework (Cost Optimization), Google Cloud Architecture Framework (Cost optimization).
• AXELOS / PeopleCert — ITIL 4, prática de IT financial management (orçamento, contabilidade e cobrança de serviços de TI).
• Technology Business Management (TBM) Council — taxonomia e padrões TBM para apurar e gerir de forma transparente o gasto em tecnologia.

Referências#

1. Cloud computing — Wikipedia — https://en.wikipedia.org/wiki/Cloud_computing
2. Capital expenditure — Wikipedia — https://en.wikipedia.org/wiki/Capital_expenditure
3. Operating expense — Wikipedia — https://en.wikipedia.org/wiki/Operating_expense
4. Cost allocation — Wikipedia — https://en.wikipedia.org/wiki/Cost_allocation
5. Cost centre — Wikipedia — https://en.wikipedia.org/wiki/Cost_centre_(business)
6. Total cost of ownership — Wikipedia — https://en.wikipedia.org/wiki/Total_cost_of_ownership
7. Software asset management — Wikipedia — https://en.wikipedia.org/wiki/Software_asset_management
8. Software as a service — Wikipedia — https://en.wikipedia.org/wiki/Software_as_a_service
9. Software license — Wikipedia — https://en.wikipedia.org/wiki/Software_license
10. Autoscaling — Wikipedia — https://en.wikipedia.org/wiki/Autoscaling
11. ITIL — Wikipedia — https://en.wikipedia.org/wiki/ITIL
12. Unit cost — Wikipedia — https://en.wikipedia.org/wiki/Unit_cost
13. FinOps Foundation — FinOps Framework — FinOps Foundation (Linux Foundation) — https://www.finops.org/framework/
14. HM Treasury — The Green Book: appraisal and evaluation in central government — GOV.UK — https://www.gov.uk/government/publications/the-green-book-appraisal-and-evaluation-in-central-government
15. NHS England — Cloud and technology guidance — NHS England — https://www.england.nhs.uk/
16. Amazon Web Services — Well-Architected Framework: Cost Optimization Pillar — AWS — https://docs.aws.amazon.com/wellarchitected/latest/cost-optimization-pillar/welcome.html
17. Microsoft — Azure Well-Architected Framework: Cost Optimization — Microsoft Learn — https://learn.microsoft.com/en-us/azure/well-architected/cost-optimization/
18. Technology Business Management Council — TBM Framework and taxonomy — TBM Council — https://www.tbmcouncil.org/