Greg Holmes, Field CTO per l’EMEA presso Applicazioneuna società IBM, sostiene che per scalare con successo l’automazione intelligente è necessario rigore finanziario.
Il modello di adozione della tecnologia “costruiscilo e arriveranno” spesso lascia un buco nel budget quando viene applicato all’automazione. I dirigenti spesso scoprono che i programmi pilota di successo non si traducono in implementazioni sostenibili a livello aziendale perché la modellazione finanziaria iniziale ignorava le realtà della scalabilità della produzione.
“Quando integriamo le funzionalità FinOps con l’automazione, stiamo assistendo a un cambiamento da un essere molto reattivi sulla gestione dei costi ad essere molto proattivi riguardo all’ingegneria del valore”, afferma Holmes.
Ciò sposta i criteri di valutazione per i leader tecnici. Invece di aspettare “mesi o anni per valutare se le cose stanno ottenendo valore”, i team di ingegneri possono monitorare il consumo di risorse – come il costo per transazione o la chiamata API – “direttamente dall’inizio”.
L’economia unitaria della scalabilità dell’automazione intelligente
I progetti di innovazione sono soggetti a un tasso di mortalità elevato. Holmes osserva che circa l’80% dei nuovi progetti di innovazione falliscono, spesso perché l’opacità finanziaria durante la fase pilota maschera le passività future.
“Se un progetto pilota dimostra che l’automazione di un processo consente di risparmiare, ad esempio, 100 ore al mese, la leadership ritiene che sia un vero successo”, afferma Holmes. “Ma ciò che non riesce a monitorare è che il progetto pilota a volte viene eseguito su un’infrastruttura con provisioning eccessivo, quindi sembra che funzioni davvero bene. Ma non si eseguirebbe un provisioning eccessivo a quel livello durante un vero e proprio lancio di produzione.”
Lo spostamento del carico di lavoro in produzione modifica i calcoli. Aumentano i requisiti di elaborazione, archiviazione e trasferimento dati. “Le chiamate API possono moltiplicarsi, le eccezioni e i casi limite compaiono a un volume che avrebbe potuto essere fuori dall’ambito della fase pilota, e quindi crescono anche le spese generali di supporto”, aggiunge.
Per evitare ciò, le organizzazioni devono monitorare il costo marginale su larga scala. Ciò comporta il monitoraggio degli aspetti economici unitari, come il costo per cliente servito o il costo per transazione. Se il costo per cliente aumenta con la crescita della base clienti, il modello di business è difettoso.
Al contrario, un ridimensionamento efficace dovrebbe far diminuire questi costi unitari. Holmes cita un caso di studio di Liberty Mutual in cui l’assicuratore è riuscito a trovare circa 2,5 milioni di dollari di risparmi introducendo parametri di consumo e “non solo guardando le ore di lavoro che stavano risparmiando”.
Tuttavia, la responsabilità finanziaria non può spettare esclusivamente al dipartimento finanziario. Holmes sostiene la necessità di rimettere la governance “nelle mani degli sviluppatori nei loro strumenti di sviluppo e carichi di lavoro”.
L’integrazione con strumenti di infrastruttura come codice come HashiCorp Terraform e GitHub consente alle organizzazioni di applicare policy durante la distribuzione. I team possono aumentare le risorse in modo programmatico con stime dei costi immediate.
“Piuttosto che implementare le cose e poi sistemarle, il che porta a un problema del tutto assurdo”, spiega Holmes, le aziende possono verificare che stanno “implementando le cose giuste al momento giusto”.
Quando si scala l’automazione intelligente, spesso si crea tensione tra il CFO, che si concentra sul ritorno sull’investimento, e il responsabile dell’automazione, che tiene traccia dei parametri operativi come le ore risparmiate.
“Questa sfida di traduzione è esattamente ciò per cui TBM (Technology Business Management) e Apptio sono progettati per risolvere”, afferma Holmes. “Significa avere un linguaggio comune tra tecnologia, finanza e business.”
La tassonomia TBM fornisce un quadro standardizzato per conciliare queste opinioni. Mappa le risorse tecniche (come elaborazione, archiviazione e manodopera) nelle torri IT e oltre fino alle capacità aziendali. Questa struttura traduce gli input tecnici in output aziendali.
“Non so necessariamente cosa accada in tutti i livelli IT sottostanti”, afferma Holmes, descrivendo la prospettiva dell’utente aziendale. “Ma poiché disponiamo di questa tassonomia, posso ottenere una fattura dettagliata che mi informa sul consumo del mio servizio e esattamente quali costi lo rendono più costoso man mano che consumo di più.”
Affrontare il debito pregresso e definire il budget a lungo termine
Le organizzazioni gravate da sistemi ERP legacy si trovano di fronte a una scelta binaria: l’automazione come patch o come ponte verso la modernizzazione. Holmes avverte che se un’azienda “sta solo cercando di mascherare processi inefficienti e non di riprogettarli”, sta semplicemente “accumulando ulteriore debito tecnico”.
Un approccio basato sul costo totale di proprietà (TCO) aiuta a determinare la strategia corretta. La Commonwealth Bank of Australia ha utilizzato un modello TCO per 2.000 diverse applicazioni, di vari stadi di maturità, per valutare i costi dell’intero ciclo di vita. Questa analisi includeva costi nascosti come infrastruttura, manodopera e tempo di progettazione necessari per mantenere in funzione l’automazione.
“Solo a causa dell’eredità di qualcosa non significa che devi ritirarlo”, afferma Holmes. “Alcuni di questi sistemi legacy meritano di essere mantenuti solo perché il valore è così buono.”
In altri casi, il calcolo del costo degli wrapper di automazione necessari per mantenere funzionale un vecchio sistema rivela una realtà diversa. “A volte, quando si somma l’approccio TCO e si includono tutti questi livelli di automazione attorno ad esso, all’improvviso ci si rende conto che il costo reale per mantenere in vita quel vecchio sistema non è solo il vecchio sistema, ma anche quei livelli aggiuntivi”, sostiene Holmes.
Evitare lo shock adesivo richiede una strategia di budget che bilanci i costi variabili con gli impegni a lungo termine. Sebbene i costi variabili (OPEX) offrano flessibilità, possono variare notevolmente in base alla domanda e all’efficienza ingegneristica.
Holmes ritiene che la visibilità a lungo termine consenta migliori decisioni di investimento. Impegnarsi su tecnologie o piattaforme specifiche su un orizzonte pluriennale consente alle organizzazioni di negoziare economie di scala e standardizzare l’architettura.
“Poiché hai preso impegni a lungo termine e ti sei standardizzato su diverse piattaforme e cose del genere, è più facile costruire la cosa giusta a lungo termine”, afferma Holmes.
La combinazione di una gestione rigorosa dei costi variabili con impegni strategici aiuta le aziende a scalare l’automazione intelligente senza la volatilità che spesso ostacola la trasformazione.
IBM è uno sponsor chiave di quest’anno Conferenza globale sull’automazione intelligente a Londra il 4-5 febbraio 2026. Greg Holmes e altri esperti condivideranno le loro opinioni durante l’evento. Assicurati di dare un’occhiata alla sessione del panel del primo giorno, Scaling Intelligent Automation Successfully: Frameworks, Risks, and Real-World Lessons, per ascoltare di più da Holmes e passare allo stand IBM allo stand n. 362.
Vedi anche: Klarna sostiene Google UCP per potenziare i pagamenti degli agenti basati sull’intelligenza artificiale
Vuoi saperne di più sull’intelligenza artificiale e sui big data dai leader del settore? Guardare Fiera dell’intelligenza artificiale e dei big data che si svolge ad Amsterdam, in California, e a Londra. L’evento completo è parte di TechEx ed è situato in concomitanza con altri importanti eventi tecnologici tra cui Fiera sulla sicurezza informatica e sul cloud. Clic Qui per ulteriori informazioni
AI News è alimentato da Media TechForge. Esplora altri prossimi eventi e webinar sulla tecnologia aziendale Qui.
Fonte: www.artificialintelligence-news.com
