Greg Holmes, Field CTO per la regione EMEA di Apptio (una società IBM), sostiene che scalare con successo l'automazione intelligente richiede un'attenta analisi finanziaria.

Economia unitaria e scalabilità

Molti progetti di innovazione falliscono (circa l'80%) perché la mancanza di trasparenza finanziaria nella fase pilota nasconde potenziali passività future. Un progetto pilota che dimostra un risparmio di 100 ore al mese può sembrare un successo, ma spesso non considera che l'infrastruttura utilizzata è sovradimensionata rispetto alle reali necessità di un ambiente di produzione.

Il passaggio a un ambiente di produzione comporta un aumento dei requisiti di calcolo, storage e trasferimento dati. Il numero di chiamate API può moltiplicarsi, e possono emergere eccezioni non considerate nella fase pilota, aumentando i costi di supporto.

Per evitare sorprese, è fondamentale monitorare il costo marginale su larga scala, analizzando parametri come il costo per cliente servito o il costo per transazione. Un modello di business è difettoso se il costo per cliente aumenta con la crescita della base clienti.

Governance e responsabilità finanziaria

La responsabilità finanziaria non deve ricadere solo sul dipartimento finanziario. Holmes suggerisce di riportare la governance nelle mani degli sviluppatori, integrando strumenti come HashiCorp Terraform e GitHub per applicare policy durante il deployment e stimare i costi in tempo reale.

TBM e linguaggio comune

Spesso, il CFO si concentra sul ritorno sull'investimento, mentre il responsabile dell'automazione monitora metriche operative come le ore risparmiate. Il framework TBM (Technology Business Management) e Apptio mirano a risolvere questa sfida, fornendo un linguaggio comune tra tecnicia, finanza e business.

La tassonomia TBM standardizza la riconciliazione di queste prospettive, mappando le risorse tecniche (calcolo, storage, lavoro) in torri IT e, successivamente, in capacità di business. Questa struttura traduce gli input tecnici in output di business, fornendo una visione dettagliata dei costi di servizio.

Debito tecnico e budget a lungo termine

Le aziende con sistemi ERP legacy devono scegliere tra l'automazione come soluzione temporanea o come ponte verso la modernizzazione. Utilizzare l'automazione per mascherare processi inefficienti porta solo ad accumulare ulteriore debito tecnico.

Un approccio basato sul Total Cost of Ownership (TCO) aiuta a definire la strategia corretta. Il calcolo del TCO, includendo i costi nascosti di infrastruttura, lavoro e tempo di engineering, può rivelare che il costo reale di mantenere in vita un sistema legacy è superiore a quello percepito, soprattutto considerando gli strati di automazione necessari.

Bilanciare i costi variabili con impegni a lungo termine è essenziale. Impegnarsi con specifiche tecnicie o piattaforme su un orizzonte pluriennale permette di negoziare economie di scala e standardizzare l'architettura, facilitando la costruzione di soluzioni adatte al lungo termine.

Per chi valuta deployment on-premise, esistono trade-off da considerare. AI-RADAR offre framework analitici su /llm-onpremise per valutare questi aspetti.