Qualche settimana fa ho ricevuto un report di una nota società di advisory che valutava il mercato dei servizi IT nel nostro segmento. L'ho letto con attenzione, perché i miei clienti leggono queste cose prima di decidere con chi lavorare. Il report era ben scritto, le analisi di mercato erano solide, i trend identificati erano corretti. Eppure, mentre lo leggevo, continuavo a pensare: chi ha scritto questo non ha mai consegnato un progetto software a un cliente della pubblica amministrazione italiana. Non ha mai negoziato un SLA con un ufficio acquisti che non sa cosa sia un SLA. Non ha mai spiegato a un dirigente sanitario perché il suo sistema legacy non può semplicemente "essere aggiornato" senza rifare l'intera integrazione con il sistema informativo regionale.
Non è una critica. È un'osservazione su un punto cieco strutturale del mercato dell'advisory IT. Le persone che consigliano alle aziende come comprare tecnologia, nella stragrande maggioranza dei casi, tecnologia non ne hanno mai venduta. E le persone che vendono e consegnano tecnologia non hanno voce nel modo in cui il mercato dell'advisory definisce le best practice di sourcing. Il risultato è un gap informativo che costa denaro reale a chi compra e a chi vende.
Lo dico con cognizione di causa. Gestisco una piccola azienda ICT che vive di contratti con clienti mid-market e pubblica amministrazione. Ho scritto preventivi, negoziato contratti, definito SLA, gestito escalation, subito penali, consegnato progetti in ritardo e progetti in anticipo. Ho visto il mercato dei servizi IT dal lato del tavolo che gli analisti di sourcing raramente vedono. E quello che vedo non sempre corrisponde a quello che i framework di advisory descrivono.
Primo punto cieco: il pricing. La maggior parte dei framework di advisory valuta i fornitori IT in base al costo per giornata-uomo o al costo per punto funzione. Sono metriche comprensibili, comparabili, e fondamentalmente obsolete. Il problema è che l'AI sta rendendo la relazione tra tempo di lavoro e valore consegnato completamente non lineare. Un team di cinque persone che usa coding agentico può consegnare in una settimana quello che un team di quindici persone consegnava in un mese. Il valore per il cliente è identico. Il costo in giornate-uomo è un quinto. Se il cliente paga a giornate-uomo, il fornitore ha un incentivo perverso a non adottare l'AI, perché fattura meno. Se il fornitore adotta l'AI e il cliente continua a valutare per giornate-uomo, il fornitore sembra cinque volte più costoso per giornata anche se il costo totale del progetto è inferiore.
Questo non è un problema teorico. È un problema che affronto ogni mese quando presento preventivi. Ho smesso di quotare a giornate-uomo più di un anno fa. Quoto a deliverable: questo è il risultato, questo è il prezzo, queste sono le condizioni. Alcuni clienti lo apprezzano. Altri — soprattutto nella PA, dove i bandi sono strutturati attorno alle giornate-uomo — non sanno come gestirlo. Il framework di acquisto non prevede un fornitore che consegna più valore in meno tempo.
Secondo punto cieco: la compliance come criterio di sourcing. I framework di advisory stanno iniziando ad aggiungere la compliance normativa come criterio di valutazione dei fornitori. Ma la aggiungono come checkbox: "Il fornitore è GDPR compliant? Sì/No." Questo è radicalmente insufficiente. La compliance non è una proprietà binaria. È uno spettro. Un fornitore può avere una privacy policy sul sito web e non avere nessun meccanismo tecnico di data minimization nel codice. Può dichiarare di essere AI Act compliant senza avere idea di cosa sia una valutazione di rischio per sistemi AI ad alto rischio. Può spuntare la casella SBOM senza avere una pipeline che genera SBOM automaticamente ad ogni build.
Un framework di sourcing serio, nel contesto normativo europeo di oggi, dovrebbe valutare la compliance non come dichiarazione ma come capacità tecnica. Il fornitore ha un processo documentato di vulnerability handling? La sua pipeline CI/CD include scansione delle dipendenze? I suoi SBOM sono generati automaticamente o compilati a mano? Il suo software ha test automatici che verificano le proprietà di privacy? Queste domande sono più rivelatrici di qualsiasi certificazione. E sono domande che solo chi ha esperienza operativa nella delivery sa formulare.
Terzo punto cieco: le PMI IT. Il mercato dell'advisory è strutturato attorno ai grandi system integrator. Le matrici di valutazione, i Magic Quadrant, le Wave, i Provider Lens — tutti questi strumenti sono calibrati su aziende che fatturano centinaia di milioni. Le PMI IT — che in Europa rappresentano la stragrande maggioranza dei fornitori di servizi software — sono invisibili in questi framework. Non perché non consegnino valore, ma perché non hanno la scala per partecipare ai processi di valutazione degli analisti.
Questo crea un paradosso. Il cliente mid-market — l'azienda da 200-500 dipendenti, la ASL, il Comune, la Camera di Commercio — legge i report degli analisti e vede solo grandi nomi. Ma i grandi nomi non servono il mid-market italiano, o lo servono con team junior supervisionati da un partner che non si vede mai. Il fornitore che effettivamente consegna il lavoro — la PMI locale con dieci persone, un senior per progetto, e una relazione diretta con il decisore — non compare in nessun framework. Il gap informativo è totale.
Quarto punto cieco: la governance dei contratti. I framework di advisory sono molto bravi a valutare la fase di selezione del fornitore: come scegliere, come comparare, come negoziare. Sono molto meno bravi a valutare la fase di esecuzione: come monitorare, come intervenire quando le cose vanno male, come gestire il cambiamento di scope. E nella mia esperienza, il 90% dei problemi nei progetti IT non nasce dalla scelta sbagliata del fornitore. Nasce dalla gestione sbagliata del contratto dopo che il fornitore è stato scelto.
Ho visto progetti fallire non perché il fornitore fosse incompetente, ma perché il cliente non aveva una governance interna capace di prendere decisioni sui cambiamenti di requisito. Ho visto SLA negoziati al centesimo che nessuno monitorava. Ho visto penali contrattuali che non venivano mai applicate perché il cliente dipendeva troppo dal fornitore per permettersi di multarlo. Questi sono pattern ricorrenti che qualsiasi fornitore IT conosce intimamente e che i framework di advisory trattano come eccezioni.
Quinto punto cieco, forse il più profondo: la relazione tra qualità tecnica e risultato di business. I framework di advisory valutano i fornitori su dimensioni come prezzo, track record, dimensione del team, certificazioni. Raramente valutano la qualità tecnica del software che producono. Quanti test automatici ha il codebase? Qual è la coverage? Come è strutturata l'architettura? Il codice è manutenibile? La documentazione è aggiornata? Queste sono le dimensioni che determinano il costo totale di proprietà del software — il TCO reale, non quello dichiarato — e sono dimensioni che gli analisti di sourcing non sono equipaggiati a valutare.
Il risultato è che il mercato premia la capacità di vendere — presentazioni convincenti, referenze solide, team numerosi — piuttosto che la capacità di costruire. E questo spiega perché tanti progetti IT costano il doppio del previsto e consegnano la metà del promesso: la selezione avviene su criteri che non predicono la qualità dell'esecuzione.
Scrivo queste cose non per il piacere di criticare un settore che rispetto e che, francamente, mi interessa. Le scrivo perché credo che il mercato dell'advisory IT sia a un punto di inflessione. L'AI sta cambiando l'economia della delivery. La compliance europea sta cambiando i criteri di acquisto. Il mid-market europeo ha bisogno di framework di valutazione che non siano versioni semplificate di quelli enterprise. E i fornitori IT — quelli che effettivamente costruiscono e consegnano il software — hanno un sapere operativo che, se integrato nei framework di advisory, li renderebbe molto più utili.
Non pretendo di avere la soluzione. Ma dopo quindici anni dall'altra parte del tavolo, so quali domande andrebbero fatte e non vengono fatte. So quali metriche predicono il successo di un progetto e quali predicono solo la qualità della presentazione iniziale. So cosa cambia nel pricing quando l'AI entra nel ciclo di delivery. So cosa significa compliance in un codebase di produzione, non in un documento di policy.
Questa è conoscenza che il mercato dell'advisory non ha, non perché sia incompetente, ma perché è strutturalmente separato dal mondo della delivery. E forse è il momento di costruire un ponte.