Il paradosso del procurement nell’era dell’AI
In ogni trattativa per un software enterprise c’è una domanda che arriva puntuale, come il caffè a fine riunione: “Quante referenze avete?”
Domanda legittima, sia chiaro. Il problema è quando arriva nel momento sbagliato. Per esempio, subito dopo che il software ha appena dimostrato di funzionare.
La scena, più o meno, è questa:
— Il Proof of Concept ha funzionato?
— Sì, tutti i KPI raggiunti.
— La sicurezza?
— Verificata.
— L’integrazione con i nostri sistemi?
— Fatta e testata.
— Ottimo. E quante aziende come la nostra lo usano già?
— …
E in quel silenzio, tutto ciò che è stato dimostrato sul campo rischia di pesare meno di una slide piena di loghi.
Chiediamo alle aziende di innovare. Poi, al momento di scegliere, premiamo chi ha più passato. È un po’ come pretendere che un esordiente abbia già vinto tre campionati.
L’uovo, la gallina e l’ufficio acquisti
Ogni software della storia, compresi quelli che oggi sono lo standard di mercato, ha avuto un primo cliente. E quel primo cliente, per definizione, non aveva referenze da consultare.
Il meccanismo, ridotto all’osso, funziona così:
- per ottenere la prima referenza serve qualcuno disposto a essere il primo;
- per trovare qualcuno disposto a essere il primo, gli si chiede una referenza.
Se tutti aspettano che qualcun altro faccia il primo passo, la prima referenza non arriva mai. E la tecnologia nuova non diventa mai matura: diventa semplicemente vecchia, senza essere mai stata adottata.
Una tecnologia appena arrivata sul mercato non può avere dieci anni di storia. Non perché valga meno, ma perché è nuova. Chiederle un lungo elenco di clienti significa, in pratica, chiederle di non essere innovativa.
“Sì, ma nel nostro settore?” Il problema non è solo delle banche
Si potrebbe pensare che il tema riguardi solo le startup o solo il settore bancario. Non è così.
Anche un software con molti clienti, prima o poi, incontra la variante più diffusa della domanda: “Avete una referenza nel nostro settore?” E se la risposta è sì, arrivano i rilanci:
- nel nostro settore, ma della nostra dimensione?
- della nostra dimensione, ma nel nostro Paese?
- nel nostro Paese, ma con il nostro stesso ERP?
Di questo passo, la referenza perfetta è un’azienda identica alla nostra. Che a quel punto, probabilmente, saremmo noi.
Il punto è semplice: nessun software può avere una referenza per ogni industry. Ogni volta che entra in un settore nuovo, torna a essere “senza referenze”, anche se è sul mercato da anni. Succede nella manifattura, nelle utility, nella sanità, nella Pubblica Amministrazione, nel retail, nell’energia, nella finanza.
E succede anche al contrario. Ogni azienda che è la prima del proprio settore ad adottare una certa tecnologia si trova nella stessa posizione della prima banca: non ha un “collega” a cui telefonare.
Per una piattaforma low-code questo è ancora più evidente. Il suo valore non sta nel settore in cui è già stata usata, ma nella capacità di adattarsi ai processi di chi la adotta. Che abbia funzionato in un’assicurazione dice poco su un’azienda di logistica, e viceversa. La domanda utile è un’altra: funziona sui vostri processi, con i vostri sistemi?
Referenze e prove non sono la stessa cosa
Le referenze servono. Dicono che un fornitore ha già lavorato in contesti complessi, con volumi, integrazioni e requisiti di sicurezza impegnativi.
Ma una referenza racconta soprattutto una cosa: qualcuno ha già usato quella soluzione.
Un Proof of Concept racconta qualcosa di diverso: quella soluzione ha funzionato qui, con i nostri dati, i nostri processi e i nostri criteri.
Sono due informazioni utili. Ma non sono la stessa informazione, e non dovrebbero escludersi a vicenda.
C’è poi un’altra distinzione da tenere a mente: maturità non significa innovazione. Un software sul mercato da quindici anni può essere eccellente. Uno nato da due anni può esserlo altrettanto, con una storia di adozione inevitabilmente più breve. Il numero di referenze misura la diffusione, non la capacità di risolvere il vostro problema.
Questo non vuol dire che il nuovo sia automaticamente migliore. Può avere più rischi, un ecosistema più piccolo, richiedere più verifiche. Ma la risposta a quei rischi dovrebbe essere “valutiamolo meglio”, non “non valutiamolo”.
Dalla referenza all’evidenza: gli Innovation Gate
Il cambio di paradigma sta tutto in una freccia. Non più referenze → decisione, ma un percorso in cui il rischio si riduce passo dopo passo:
- Si valutano azienda, tecnologia, architettura, cybersecurity, trattamento dei dati, continuità operativa ed exit strategy. Le referenze si raccolgono, ma non fanno da cancello.
- La tecnologia si prova in un ambiente controllato, con perimetro, accessi e dati definiti.
- Proof of Concept. Prima si fissano obiettivi, KPI, casi d’uso, criteri di successo e criteri di stop. Poi si testa.
- Test di sicurezza e resilienza. In base alla criticità: performance, vulnerabilità, logging, monitoring, controllo accessi, comportamento negli scenari anomali.
- Se il PoC è positivo, si passa a un perimetro reale ma limitato.
- Contratto e industrializzazione. Entrano in gioco SLA, audit, continuità, exit strategy, condizioni di rinnovo e, dove serve, escrow.
Non è un’idea eccentrica. È la stessa logica che la Commissione europea promuove con l’innovation procurement e il Pre-Commercial Procurement: confrontare soluzioni diverse e ridurre il rischio per fasi, tra prototipi, sviluppo e test, prima dell’adozione su larga scala.
Il risultato è una decisione basata su evidenze + rischio + valore + governance. Non sul numero di loghi in una slide.
Il rischio si gestisce, non si delega ai loghi
Se il vero timore è il rischio di affidarsi a una PMI innovativa, perché non gestirlo con gli strumenti nati apposta?
Invece di usare la referenza come unico paracadute, si possono combinare:
- PoC e pilot con KPI misurabili;
- SLA e obblighi contrattuali chiari;
- diritti di audit e verifica;
- piani di continuità, di exit e di rollback;
- dove appropriato, un accordo di escrow.
L’escrow prevede il deposito presso un soggetto terzo di asset concordati, come codice sorgente e documentazione tecnica, con condizioni precise per il loro rilascio. Se il fornitore non fosse più in grado di garantire il servizio, il cliente non resta a mani vuote.
Non è una bacchetta magica. Non sostituisce la due diligence, la valutazione finanziaria o i controlli di cybersecurity, e va progettato in base alla criticità della soluzione. Ma sposta la domanda: non si chiede più alla PMI di dimostrare un passato che non può avere, si costruiscono garanzie per governare il futuro.
Nei settori regolamentati: la resilienza si verifica, non si presume
Nel settore finanziario il tema ha anche un risvolto normativo. Il Regolamento europeo DORA (Digital Operational Resilience Act) mette al centro la gestione del rischio ICT, il testing e il controllo dei fornitori terzi, con requisiti contrattuali precisi: SLA, sicurezza, continuità, diritti di audit e strategie di uscita.
Il messaggio implicito è chiaro: la resilienza non si deduce da quanti altri usano un fornitore. Si verifica e si governa, con proporzionalità.
E lo stesso principio vale ben oltre le banche. Qualsiasi azienda che affida processi critici a una piattaforma, dalla sanità alle utility, ha più da guadagnare da un rischio misurato che da un elenco di loghi.
Sei domande più utili di “quante referenze avete?”
La domanda sulle referenze può restare. Ma merita di essere affiancata da domande che misurano davvero il rischio:
- Quali evidenze potete produrre nel nostro contesto?
- Quali KPI e criteri di stop concordiamo prima di iniziare?
- Qual è il rischio ICT associato alla piattaforma, e come lo verifichiamo?
- Quali condizioni contrattuali ci proteggono se qualcosa va storto?
- Qual è il piano in caso di mancato rispetto degli SLA o di interruzione del servizio?
- Qual è la nostra exit strategy?
E, alla fine, la domanda che le riassume tutte: come trasformiamo ciò che ancora non sappiamo in un rischio che possiamo misurare, testare e governare?
Da “Trust me” a “Test me”
Siamo nell’era dell’AI. Chiediamo alle organizzazioni di reinventare prodotti, processi e modelli operativi. E poi, al momento della scelta, rischiamo di premiare soprattutto chi ha il passato più lungo.
La prima azienda di un settore che adotterà una tecnologia innovativa non avrà una referenza da citare. Potrà però avere un PoC, test di sicurezza e performance, KPI, un pilot, un piano di rollback, garanzie contrattuali ed evidenze documentate.
In altre parole, potrà avere qualcosa di più utile di una referenza: delle prove.
Innovare responsabilmente non significa comprare senza controlli. Ma nemmeno scartare il nuovo perché non ha ancora un passato abbastanza lungo. Significa smettere di chiedere fiducia sulla base della storia e iniziare a costruirla sulla base dei fatti.
Da “Trust me” a “Test me”.
