Greg Holmes, CTO de campo para EMEA na Apptio, uma empresa IBM, argumenta que o dimensionamento bem-sucedido da automação inteligente requer rigor financeiro.
O modelo de adoção de tecnologia “construa e eles virão” muitas vezes deixa um buraco no orçamento quando aplicado à automação. Os executivos frequentemente descobrem que programas piloto bem-sucedidos não se traduzem em implantações sustentáveis em toda a empresa porque a modelagem financeira inicial ignorou a realidade do escalonamento da produção.
“Quando integramos recursos de FinOps com automação, observamos uma mudança de ser muito reativo no gerenciamento de custos para ser muito proativo em relação à engenharia de valor”, diz Holmes.
Isso muda os critérios de avaliação dos líderes técnicos. Em vez de esperar “meses ou anos para avaliar se as coisas estão obtendo valor”, as equipes de engenharia podem acompanhar o consumo de recursos – como custo por transação ou chamada de API – “direto desde o início”.
A economia unitária do dimensionamento da automação inteligente
Os projetos de inovação enfrentam uma elevada taxa de mortalidade. Holmes observa que cerca de 80% dos novos projetos de inovação falham, muitas vezes porque a opacidade financeira durante a fase piloto mascara responsabilidades futuras.
“Se um piloto demonstra que a automatização de um processo economiza, digamos, 100 horas por mês, a liderança considera que isso é realmente um sucesso”, diz Holmes. “Mas o que ele não consegue acompanhar é que o piloto às vezes está sendo executado em uma infraestrutura superprovisionada, então parece que ele tem um desempenho muito bom. Mas você não iria superprovisionar nesse nível durante uma implementação de produção real.”
Mover essa carga de trabalho para a produção altera o cálculo. Os requisitos de computação, armazenamento e transferência de dados aumentam. “As chamadas de API podem se multiplicar, exceções e casos extremos aparecem em volumes que poderiam estar fora do escopo da fase piloto e, em seguida, as despesas gerais de suporte também aumentam”, acrescenta.
Para evitar isso, as organizações devem acompanhar o custo marginal em grande escala. Isso envolve monitorar a economia unitária, como o custo por cliente atendido ou o custo por transação. Se o custo por cliente aumentar à medida que a base de clientes cresce, o modelo de negócios é falho.
Por outro lado, um dimensionamento eficaz deverá fazer com que esses custos unitários diminuam. Holmes cita um estudo de caso da Liberty Mutual onde a seguradora conseguiu encontrar cerca de 2,5 milhões de dólares em poupanças, introduzindo métricas de consumo e “não apenas olhando para as horas de trabalho que estavam a poupar”.
No entanto, a responsabilidade financeira não pode caber apenas ao departamento financeiro. Holmes defende colocar a governança “de volta nas mãos dos desenvolvedores em suas ferramentas de desenvolvimento e cargas de trabalho”.
A integração com ferramentas de infraestrutura como código, como HashiCorp Terraform e GitHub, permite que as organizações apliquem políticas durante a implantação. As equipes podem mobilizar recursos de forma programática com estimativas de custos imediatas.
“Em vez de implantar coisas e depois consertá-las, o que se transforma em um problema do tipo “bater uma toupeira”, explica Holmes, as empresas podem verificar se estão “implantando as coisas certas no momento certo”.
Ao dimensionar a automação inteligente, muitas vezes surge a tensão entre o CFO, que se concentra no retorno do investimento, e o Chefe de Automação, que monitora métricas operacionais como horas economizadas.
“Esse desafio de tradução é exatamente o que o TBM (Technology Business Management) e o Apptio foram projetados para resolver”, diz Holmes. “É ter uma linguagem comum entre tecnologia e finanças e com os negócios.”
A taxonomia TBM fornece uma estrutura padronizada para conciliar estas opiniões. Ele mapeia recursos técnicos (como computação, armazenamento e mão de obra) em torres de TI e até recursos de negócios. Essa estrutura traduz insumos técnicos em resultados de negócios.
“Não sei necessariamente o que acontece em todas as camadas de TI subjacentes”, diz Holmes, descrevendo a perspectiva do usuário empresarial. “Mas como temos esta taxonomia, posso obter uma fatura detalhada que me informa sobre o consumo do meu serviço e precisamente quais os custos que o tornam mais caro à medida que consumo mais.”
Abordar a dívida herdada e orçamentar a longo prazo
As organizações sobrecarregadas com sistemas ERP legados enfrentam uma escolha binária: a automação como um patch ou como uma ponte para a modernização. Holmes alerta que se uma empresa está “apenas tentando mascarar processos ineficientes e não redesenhá-los”, ela está apenas “acumulando mais dívida técnica”.
Uma abordagem de custo total de propriedade (TCO) ajuda a determinar a estratégia correta. O Commonwealth Bank of Australia utilizou um modelo de TCO em 2.000 aplicações diferentes – de vários estágios de maturidade – para avaliar os custos de todo o seu ciclo de vida. Esta análise incluiu custos ocultos, como infraestrutura, mão de obra e tempo de engenharia necessário para manter a automação em funcionamento.
“Só por causa do legado de algo não significa que você tenha que aposentá-lo”, diz Holmes. “Vale a pena manter alguns desses sistemas legados só porque o valor é muito bom.”
Em outros casos, calcular o custo dos invólucros de automação necessários para manter um sistema antigo funcional revela uma realidade diferente. “Às vezes, quando você soma a abordagem de TCO e inclui todas essas camadas de automação, você de repente percebe que o custo real de manter aquele sistema antigo ativo não é apenas o sistema antigo, são essas camadas extras”, argumenta Holmes.
Evitar surpresas exige uma estratégia orçamental que equilibre os custos variáveis com compromissos a longo prazo. Embora os custos variáveis (OPEX) ofereçam flexibilidade, eles podem flutuar enormemente com base na demanda e na eficiência da engenharia.
Holmes informa que a visibilidade a longo prazo permite melhores decisões de investimento. O compromisso com tecnologias ou plataformas específicas ao longo de um horizonte plurianual permite que as organizações negociem economias de escala e padronizem a arquitetura.
“Como você assumiu esses compromissos de longo prazo e padronizou diferentes plataformas e coisas assim, fica mais fácil construir a coisa certa para o longo prazo”, diz Holmes.
A combinação de uma gestão rigorosa de custos variáveis com compromissos estratégicos apoia as empresas no dimensionamento da automação inteligente sem a volatilidade que muitas vezes inviabiliza a transformação.
A IBM é um dos principais patrocinadores do evento deste ano Conferência Global de Automação Inteligente em Londres, de 4 a 5 de fevereiro de 2026. Greg Holmes e outros especialistas compartilharão suas ideias durante o evento. Não deixe de conferir a sessão do painel do primeiro dia, Escalando a Automação Inteligente com Sucesso: Estruturas, Riscos e Lições do Mundo Real, para ouvir mais de Holmes e passar pelo estande da IBM no estande nº 362.
Veja também: Klarna apóia o Google UCP para potencializar pagamentos de agentes de IA
Quer saber mais sobre IA e big data dos líderes do setor? Confira a AI & Big Data Expo que acontece em Amsterdã, Califórnia e Londres. O evento abrangente faz parte da TechEx e está localizado junto com outros eventos de tecnologia líderes, incluindo o Cyber Security & Cloud Expo. Clique aqui para mais informações.
AI News é desenvolvido pela TechForge Media. Explore outros eventos e webinars de tecnologia empresarial futuros aqui.
Fontesartificialintelligence
