{"id":17105,"date":"2026-09-25T14:54:59","date_gmt":"2026-09-25T12:54:59","guid":{"rendered":"https:\/\/www.omniabpm.com\/2026\/09\/25\/software-innovativo-quante-referenze-servono-davvero\/"},"modified":"2026-09-25T15:35:48","modified_gmt":"2026-09-25T13:35:48","slug":"software-innovativo-quante-referenze-servono-davvero","status":"publish","type":"post","link":"https:\/\/www.omnia-platform.com\/it\/2026\/09\/25\/software-innovativo-quante-referenze-servono-davvero\/","title":{"rendered":"Software innovativo: quante referenze servono davvero?"},"content":{"rendered":"\t\t
\n\t\t\t\t\t\t
\n\t\t\t\t\t\t
\n\t\t\t\t\t
\n\t\t\t
\n\t\t\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t\t\t\t\t\t

Il paradosso del procurement nell’era dell’AI<\/strong><\/p>\n

In ogni trattativa per un software enterprise c’\u00e8 una domanda che arriva puntuale, come il caff\u00e8 a fine riunione: “Quante referenze avete?”<\/strong><\/p>\n

Domanda legittima, sia chiaro. Il problema \u00e8 quando arriva nel momento sbagliato. Per esempio, subito dopo che il software ha appena dimostrato di funzionare.<\/p>\n

La scena, pi\u00f9 o meno, \u00e8 questa:<\/p>\n

\u2014 Il Proof of Concept ha funzionato?<\/em><\/p>\n

\u2014 S\u00ec, tutti i KPI raggiunti.<\/em><\/p>\n

\u2014 La sicurezza?<\/em><\/p>\n

\u2014 Verificata.<\/em><\/p>\n

\u2014 L’integrazione con i nostri sistemi?<\/em><\/p>\n

\u2014 Fatta e testata.<\/em><\/p>\n

\u2014 Ottimo. E quante aziende come la nostra lo usano gi\u00e0?<\/em><\/p>\n

\u2014 \u2026<\/em><\/p>\n

E in quel silenzio, tutto ci\u00f2 che \u00e8 stato dimostrato sul campo rischia di pesare meno di una slide piena di loghi.<\/p>\n

Chiediamo alle aziende di innovare. Poi, al momento di scegliere, premiamo chi ha pi\u00f9 passato. \u00c8 un po’ come pretendere che un esordiente abbia gi\u00e0 vinto tre campionati.<\/p>\n

L’uovo, la gallina e l’ufficio acquisti<\/strong><\/p>\n

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.<\/p>\n

Il meccanismo, ridotto all’osso, funziona cos\u00ec:<\/p>\n

    \n
  • per ottenere la prima referenza serve qualcuno disposto a essere il primo;<\/li>\n
  • per trovare qualcuno disposto a essere il primo, gli si chiede una referenza.<\/li>\n<\/ul>\n

    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.<\/p>\n

    Una tecnologia appena arrivata sul mercato non pu\u00f2 avere dieci anni di storia. Non perch\u00e9 valga meno, ma perch\u00e9 \u00e8 nuova. Chiederle un lungo elenco di clienti significa, in pratica, chiederle di non essere innovativa.<\/p>\n

    “S\u00ec, ma nel nostro settore?” Il problema non \u00e8 solo delle banche<\/strong><\/p>\n

    Si potrebbe pensare che il tema riguardi solo le startup o solo il settore bancario. Non \u00e8 cos\u00ec.<\/p>\n

    Anche un software con molti clienti, prima o poi, incontra la variante pi\u00f9 diffusa della domanda: “Avete una referenza nel nostro settore?”<\/em> E se la risposta \u00e8 s\u00ec, arrivano i rilanci:<\/p>\n

      \n
    • nel nostro settore, ma della nostra dimensione?<\/li>\n
    • della nostra dimensione, ma nel nostro Paese?<\/li>\n
    • nel nostro Paese, ma con il nostro stesso ERP?<\/li>\n<\/ul>\n

      Di questo passo, la referenza perfetta \u00e8 un’azienda identica alla nostra. Che a quel punto, probabilmente, saremmo noi.<\/p>\n

      Il punto \u00e8 semplice: nessun software pu\u00f2 avere una referenza per ogni industry. Ogni volta che entra in un settore nuovo, torna a essere “senza referenze”, anche se \u00e8 sul mercato da anni. Succede nella manifattura, nelle utility, nella sanit\u00e0, nella Pubblica Amministrazione, nel retail, nell’energia, nella finanza.<\/p>\n

      E succede anche al contrario. Ogni azienda che \u00e8 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.<\/p>\n

      Per una piattaforma low-code questo \u00e8 ancora pi\u00f9 evidente. Il suo valore non sta nel settore in cui \u00e8 gi\u00e0 stata usata, ma nella capacit\u00e0 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 \u00e8 un’altra: funziona sui vostri<\/em> processi, con i vostri<\/em> sistemi?<\/p>\n

      Referenze e prove non sono la stessa cosa<\/strong><\/p>\n

      Le referenze servono. Dicono che un fornitore ha gi\u00e0 lavorato in contesti complessi, con volumi, integrazioni e requisiti di sicurezza impegnativi.<\/p>\n

      Ma una referenza racconta soprattutto una cosa: qualcuno ha gi\u00e0 usato quella soluzione.<\/strong><\/p>\n

      Un Proof of Concept racconta qualcosa di diverso: quella soluzione ha funzionato qui, con i nostri dati, i nostri processi e i nostri criteri.<\/strong><\/p>\n

      Sono due informazioni utili. Ma non sono la stessa informazione, e non dovrebbero escludersi a vicenda.<\/p>\n

      C’\u00e8 poi un’altra distinzione da tenere a mente: maturit\u00e0 non significa innovazione.<\/strong> Un software sul mercato da quindici anni pu\u00f2 essere eccellente. Uno nato da due anni pu\u00f2 esserlo altrettanto, con una storia di adozione inevitabilmente pi\u00f9 breve. Il numero di referenze misura la diffusione, non la capacit\u00e0 di risolvere il vostro problema.<\/p>\n

      Questo non vuol dire che il nuovo sia automaticamente migliore. Pu\u00f2 avere pi\u00f9 rischi, un ecosistema pi\u00f9 piccolo, richiedere pi\u00f9 verifiche. Ma la risposta a quei rischi dovrebbe essere “valutiamolo meglio”<\/em>, non “non valutiamolo”<\/em>.<\/p>\n

      Dalla referenza all’evidenza: gli Innovation Gate<\/strong><\/p>\n

      Il cambio di paradigma sta tutto in una freccia. Non pi\u00f9 referenze \u2192 decisione<\/em>, ma un percorso in cui il rischio si riduce passo dopo passo:<\/p>

      \"\"<\/p>\n

        \n
      1. Si valutano azienda, tecnologia, architettura, cybersecurity, trattamento dei dati, continuit\u00e0 operativa ed exit strategy. Le referenze si raccolgono, ma non fanno da cancello.<\/li>\n
      2. La tecnologia si prova in un ambiente controllato, con perimetro, accessi e dati definiti.<\/li>\n
      3. Proof of Concept.<\/strong> Prima si fissano obiettivi, KPI, casi d’uso, criteri di successo e criteri di stop. Poi si testa.<\/li>\n
      4. Test di sicurezza e resilienza.<\/strong> In base alla criticit\u00e0: performance, vulnerabilit\u00e0, logging, monitoring, controllo accessi, comportamento negli scenari anomali.<\/li>\n
      5. Se il PoC \u00e8 positivo, si passa a un perimetro reale ma limitato.<\/li>\n
      6. Contratto e industrializzazione.<\/strong> Entrano in gioco SLA, audit, continuit\u00e0, exit strategy, condizioni di rinnovo e, dove serve, escrow.<\/li>\n<\/ol>\n

        Non \u00e8 un’idea eccentrica. \u00c8 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.<\/p>\n

        Il risultato \u00e8 una decisione basata su evidenze + rischio + valore + governance<\/strong>. Non sul numero di loghi in una slide.<\/p>\n

        Il rischio si gestisce, non si delega ai loghi<\/strong><\/p>\n

        Se il vero timore \u00e8 il rischio di affidarsi a una PMI innovativa, perch\u00e9 non gestirlo con gli strumenti nati apposta?<\/p>\n

        Invece di usare la referenza come unico paracadute, si possono combinare:<\/p>\n

          \n
        • PoC e pilot con KPI misurabili;<\/li>\n
        • SLA e obblighi contrattuali chiari;<\/li>\n
        • diritti di audit e verifica;<\/li>\n
        • piani di continuit\u00e0, di exit e di rollback;<\/li>\n
        • dove appropriato, un accordo di escrow<\/strong>.<\/li>\n<\/ul>\n

          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\u00f9 in grado di garantire il servizio, il cliente non resta a mani vuote.<\/p>\n

          Non \u00e8 una bacchetta magica. Non sostituisce la due diligence, la valutazione finanziaria o i controlli di cybersecurity, e va progettato in base alla criticit\u00e0 della soluzione. Ma sposta la domanda: non si chiede pi\u00f9 alla PMI di dimostrare un passato che non pu\u00f2 avere, si costruiscono garanzie per governare il futuro.<\/p>\n

          Nei settori regolamentati: la resilienza si verifica, non si presume<\/strong><\/p>\n

          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\u00e0, diritti di audit e strategie di uscita.<\/p>\n

          Il messaggio implicito \u00e8 chiaro: la resilienza non si deduce da quanti altri usano un fornitore. Si verifica e si governa, con proporzionalit\u00e0.<\/p>\n

          E lo stesso principio vale ben oltre le banche. Qualsiasi azienda che affida processi critici a una piattaforma, dalla sanit\u00e0 alle utility, ha pi\u00f9 da guadagnare da un rischio misurato che da un elenco di loghi.<\/p>\n

          Sei domande pi\u00f9 utili di “quante referenze avete?”<\/strong><\/p>\n

          La domanda sulle referenze pu\u00f2 restare. Ma merita di essere affiancata da domande che misurano davvero il rischio:<\/p>\n

            \n
          1. Quali evidenze potete produrre nel nostro contesto?<\/li>\n
          2. Quali KPI e criteri di stop concordiamo prima di iniziare?<\/li>\n
          3. Qual \u00e8 il rischio ICT associato alla piattaforma, e come lo verifichiamo?<\/li>\n
          4. Quali condizioni contrattuali ci proteggono se qualcosa va storto?<\/li>\n
          5. Qual \u00e8 il piano in caso di mancato rispetto degli SLA o di interruzione del servizio?<\/li>\n
          6. Qual \u00e8 la nostra exit strategy?<\/li>\n<\/ol>\n

            E, alla fine, la domanda che le riassume tutte: come trasformiamo ci\u00f2 che ancora non sappiamo in un rischio che possiamo misurare, testare e governare?<\/em><\/p>\n

            Da “Trust me” a “Test me”<\/strong><\/p>\n

            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\u00f9 lungo.<\/p>\n

            La prima azienda di un settore che adotter\u00e0 una tecnologia innovativa non avr\u00e0 una referenza da citare. Potr\u00e0 per\u00f2 avere un PoC, test di sicurezza e performance, KPI, un pilot, un piano di rollback, garanzie contrattuali ed evidenze documentate.<\/p>\n

            In altre parole, potr\u00e0 avere qualcosa di pi\u00f9 utile di una referenza: delle prove.<\/strong><\/p>\n

            Innovare responsabilmente non significa comprare senza controlli. Ma nemmeno scartare il nuovo perch\u00e9 non ha ancora un passato abbastanza lungo. Significa smettere di chiedere fiducia sulla base della storia e iniziare a costruirla sulla base dei fatti.<\/p>\n

            Da “Trust me” a “Test me”.<\/strong><\/p>\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t\t<\/div>\n\t\t<\/div>\n\t\t\t\t\t<\/div>\n\t\t<\/section>\n\t\t\t\t<\/div>\n\t\t","protected":false},"excerpt":{"rendered":"

            Il paradosso del procurement nell’era dell’AI In ogni trattativa per un software enterprise c’\u00e8 una domanda che arriva puntuale, come il caff\u00e8 a fine riunione: […]<\/p>\n","protected":false},"author":1,"featured_media":17095,"comment_status":"closed","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[15],"tags":[],"class_list":["post-17105","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-generale"],"_links":{"self":[{"href":"https:\/\/www.omnia-platform.com\/it\/wp-json\/wp\/v2\/posts\/17105","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.omnia-platform.com\/it\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.omnia-platform.com\/it\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.omnia-platform.com\/it\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.omnia-platform.com\/it\/wp-json\/wp\/v2\/comments?post=17105"}],"version-history":[{"count":10,"href":"https:\/\/www.omnia-platform.com\/it\/wp-json\/wp\/v2\/posts\/17105\/revisions"}],"predecessor-version":[{"id":17120,"href":"https:\/\/www.omnia-platform.com\/it\/wp-json\/wp\/v2\/posts\/17105\/revisions\/17120"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.omnia-platform.com\/it\/wp-json\/wp\/v2\/media\/17095"}],"wp:attachment":[{"href":"https:\/\/www.omnia-platform.com\/it\/wp-json\/wp\/v2\/media?parent=17105"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.omnia-platform.com\/it\/wp-json\/wp\/v2\/categories?post=17105"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.omnia-platform.com\/it\/wp-json\/wp\/v2\/tags?post=17105"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}