Come trasformare la produttività che i tuoi fornitori IT ottengono grazie all’IA in risparmio e valore

È del tutto normale pensare che i nostri fornitori tecnologici stiano aumentando la propria produttività grazie ai nuovi strumenti e modelli di IA. Logico, perché non passa giorno senza che ne venga presentato uno nuovo, quasi sempre accompagnato da studi e previsioni sul tempo che può farci risparmiare nelle attività quotidiane.

E forse potresti pensare che, se grazie a questi strumenti sviluppare software richiede oggi meno tempo, allora anche il software dovrebbe costare meno.

Ma… è davvero così? Non necessariamente. Migliorare una specifica attività non comporta automaticamente una riduzione dei costi di un progetto, né significa che il software arrivi prima in produzione o con meno difetti.

E anche se fosse così, dovremmo porci un’altra domanda: come trasferire al servizio ricevuto dal cliente il miglioramento ottenuto grazie all’IA?

Per rispondere, dobbiamo prima capire quale incremento di produttività è stato effettivamente ottenuto, a quale costo e quali miglioramenti in termini di qualità, costi o capacità ne derivano.

La produttività sta cambiando, ma di quanto?

È questo il punto chiave, ma anche una delle maggiori difficoltà: non esiste una risposta univoca su quanto l’IA migliori la produttività nello sviluppo software. Gli studi mostrano risultati molto diversi a seconda delle attività, dei team e del contesto analizzato, come abbiamo visto in un precedente articolo dedicato all’impatto dell’IA sulla produttività nello sviluppo software.

È possibile che il tuo fornitore abbia introdotto l’IA e che alcune attività richiedano ora meno tempo. Questa capacità liberata può tradursi, per esempio, in più funzionalità, un backlog ridotto o tempi di consegna migliori.

Ma può anche accadere che il miglioramento non si concretizzi realmente. Il tempo risparmiato in una fase può infatti ricomparire in seguito sotto forma di attività di revisione, correzione, integrazione o rilavorazione.

Lo sviluppo software non termina quando viene generato il codice. Perché un miglioramento sia realmente rilevante per un’organizzazione, deve mantenersi anche nelle fasi successive.

Questo non significa che utilizzare l’IA peggiori necessariamente il processo di sviluppo. Significa però che migliorare una singola attività non porta automaticamente a un miglioramento dell’intero sistema.

Sarebbe come ampliare un tratto di autostrada senza intervenire su quello successivo: l’ingorgo semplicemente si sposta.

Il report DORA 2025 approfondisce proprio questo concetto e descrive l’IA come un amplificatore dei punti di forza e di debolezza di un’organizzazione. I risultati migliori non dipendono tanto dall’introduzione di questi strumenti, quanto dal sistema organizzativo nel quale vengono utilizzati.

La questione, quindi, non è se il fornitore utilizzi l’IA, ma se questa lo stia realmente aiutando a generare più valore e se siamo in grado di quantificarlo.

Misurare l’efficienza sul prodotto, non sull’utilizzo dello strumento

Contabilizzare licenze, token, prompt o righe di codice permette di misurare solo l’attività e il livello di adozione. Per misurare la produttività dobbiamo invece considerare il risultato: il prodotto software consegnato in rapporto all’effort e ai costi necessari per realizzarlo, oltre alla qualità ottenuta.

In termini pratici, dovremmo essere in grado di rispondere a queste domande:

• Viene consegnato più prodotto software? Il confronto deve basarsi sulla funzionalità accettata, non sul volume di codice prodotto o sul numero di task completati.
• Il costo unitario è diminuito? Una riduzione dell’effort rappresenta un miglioramento economico solo se consente di ridurre il costo o di realizzare un maggiore scope con lo stesso budget.
• Il software arriva prima in produzione? Anche in questo caso, l’accelerazione deve essere valutata sull’intero ciclo di sviluppo, non soltanto sulla fase di coding.
• La qualità viene mantenuta? Il risparmio perde valore se aumentano difetti, incidenti, attività di revisione aggiuntive o rilavorazioni.

Queste dimensioni devono essere analizzate insieme, per verificare che il miglioramento di una non avvenga a scapito delle altre.

Inoltre, per poter identificare il cambiamento abbiamo bisogno di un riferimento: una baseline. L’ideale è disporre di una baseline che rappresenti produttività, costo unitario, tempi di consegna e qualità prima dell’introduzione dell’IA.

In alternativa, possiamo utilizzare uno storico di progetti che, grazie alle metriche funzionali, ci permetta di normalizzare il prodotto consegnato e metterlo in relazione con effort e costi. In questo modo possiamo ottenere indicatori di produttività e costo unitario con cui confrontare la situazione precedente e successiva all’introduzione dell’IA.

Anche il contesto è importante. Non tutti i progetti, i team, i fornitori o le tecnologie rispondono allo stesso modo. Per questo è opportuno segmentare l’analisi e confrontare i risultati con riferimenti realmente comparabili.

Grazie al benchmarking, possiamo inoltre confrontare i risultati del fornitore non soltanto con il suo storico, ma anche con servizi e progetti analoghi presenti sul mercato. Diventa così più semplice distinguere un miglioramento strutturale da una variazione occasionale o da una differenza dovuta a un cambiamento di contesto.

Senza dimenticare che è fondamentale considerare il costo totale dell’IA. Licenze, consumo dei modelli, integrazione, formazione, revisione e governance possono ridurre il miglioramento osservato inizialmente. L’efficienza finale non corrisponde al guadagno lordo ottenuto in una singola attività, ma al miglioramento che rimane dopo aver incorporato questi costi e verificato che la qualità non sia peggiorata.

Dall’efficienza dimostrabile al contratto

Una volta quantificato il miglioramento, il confronto contrattuale cambia completamente. Un confronto che non deve essere interpretato come un conflitto tra cliente e fornitore.

Il fornitore deve poter recuperare il proprio investimento, assumersi i rischi necessari e mantenere gli incentivi per continuare a migliorare il servizio. Allo stesso tempo, il cliente deve poter verificare che l’efficienza tecnologica si traduca effettivamente in valore per la propria organizzazione.

È un processo che deve essere strutturato sulla base di criteri condivisi: definire quali attività verranno valutate, perché non tutte hanno lo stesso potenziale di miglioramento, e stabilire una baseline, indicatori comparabili e meccanismi di monitoraggio.

Infine, è necessario concordare come condividere quel valore: se il miglioramento debba tradursi in prezzo, capacità, scope, qualità o impegni verificabili.

Non si tratta di suddividere una cifra teorica, ma di costruire un modello nel quale entrambe le parti possano dimostrare che cosa è realmente migliorato e riesaminare periodicamente come quel valore viene condiviso.

Un modello che ci permetta di sapere quale prodotto stiamo ricevendo, quanto costa e come si posiziona rispetto a riferimenti comparabili.

La domanda non è se il tuo fornitore utilizzi l’intelligenza artificiale, ma:

Stiamo ottenendo più prodotto software, con una qualità uguale o migliore, per ogni euro investito?

Per un’organizzazione in grado di rispondere a questa domanda attraverso i dati, la produttività smette di essere una percezione. Diventa un risultato che può essere confrontato, trasferito nel contratto e governato.

E con Quanter puoi farlo.