Software Procurement: Guida Completa per PA e B2B

Hai tre offerte sul tavolo per una nuova piattaforma software. Una sembra economica ma include poco più della licenza. Una seconda promette migrazione, assistenza e aggiornamenti continui. La terza è piena di personalizzazioni, ma non è chiaro chi manterrà quel codice tra due anni. Se lavori in un ufficio gare, in una funzione acquisti o in una direzione IT, il punto non è scegliere il preventivo “più bello”. Il punto è capire che cosa stai comprando davvero.

Nel software procurement, l'errore classico è trattare il software come un bene una tantum. Lo compri, lo installi, lo usi. In realtà quasi mai funziona così. Ci sono rinnovi, canoni, supporto, aggiornamenti, formazione, integrazioni, migrazioni e, prima o poi, anche un'uscita da governare. Nella PA italiana questo è ancora più evidente, perché la scelta tecnologica vive dentro un perimetro fatto di regole, piattaforme di acquisto e obblighi di trasparenza.

Il contesto italiano non è affatto povero di dati. La Banca Dati Nazionale dei Contratti Pubblici di ANAC raccoglie informazioni sui contratti pubblici firmati dal 2007 tra amministrazioni e imprese e la documentazione istituzionale indica oltre 60 milioni di procedure censite e quasi 3 miliardi di euro di valore complessivo, con aggiornamenti regolari e consultazione analitica nella documentazione ANAC sulla banca dati dei contratti pubblici. Questo cambia il modo di lavorare: chi acquista software oggi può leggere il mercato, non solo ascoltare i vendor.

Cos'è il Software Procurement e Perché Conta

Quando parlo di software procurement, non intendo solo la fase di gara o la firma del contratto. Intendo un processo completo: definizione del fabbisogno, analisi delle alternative, selezione del fornitore, impostazione delle clausole e governo del ciclo di vita successivo.

Per un Comune medio che deve scegliere una piattaforma documentale, la prima domanda utile non è “quanto costa?”. È “quale problema operativo dobbiamo risolvere e con quali vincoli?”. Se non chiarisci questo punto, il rischio è confrontare offerte che non sono comparabili.

Tre bussole da tenere insieme

La scelta software si regge su tre piani, e se ne salta uno il progetto si complica.

• Piano tecnico. Qui guardi interoperabilità, integrazione con protocollo, ERP, identità digitale, sicurezza, scalabilità, qualità delle API, facilità di manutenzione.
• Piano economico. Qui conti non solo il prezzo iniziale, ma canoni ricorrenti, manutenzione, assistenza, formazione, costi di migrazione e costi di uscita.
• Piano normativo. Qui entrano Codice Appalti, prescrizioni di trasparenza, linee guida AgID, obblighi documentali e regole dell'e-procurement.

Molti team si bloccano perché il fornitore parla quasi solo il linguaggio del prodotto, mentre acquisti e ufficio gare devono ragionare in termini di requisiti, comparabilità e rischio contrattuale.

Regola pratica: se un'offerta software non ti permette di stimare il costo di esercizio, non stai ancora valutando un acquisto. Stai leggendo marketing commerciale.

Perché non è una spesa una tantum

Il software genera spesa continua. Anche quando formalmente compri una licenza, restano aggiornamenti, supporto, adeguamenti tecnici, ambienti, utenti aggiuntivi e spesso servizi professionali.

Nel perimetro pubblico italiano, questo è coerente anche con il quadro AgID sulla spesa ICT, dove ricorrono voci come Licenze, Manutenzione HW e SW e Altri servizi nel triennio 2022-2025P, mentre gli strumenti di e-procurement come MEPA, SDAPA e Convenzioni Consip vengono usati in modo sistematico nel quadro descritto da Biddetail sul mercato italiano delle gare software. Tradotto in pratica: il problema non è solo acquistare il software, ma governarne continuità, rinnovi e standardizzazione.

La funzione di governo

Il procurement software fatto bene non è un passaggio amministrativo. È una funzione di governo. Decide se il tuo ente o la tua azienda resteranno liberi di evolvere i sistemi, oppure se diventeranno dipendenti da un unico fornitore.

Se la governance è debole, i segnali arrivano presto: capitolati scritti sulle brochure, SLA poco chiari, extra costi in esecuzione, proroghe tecniche ripetute, dati difficili da esportare, integrazioni che richiedono ogni volta una nuova trattativa. A quel punto non stai più gestendo un acquisto. Stai inseguendo il contratto.

SaaS, On-Premises e Cloud Ibrido a Confronto

La domanda “meglio SaaS o on-premises?” è formulata male. La domanda corretta è: quale modello regge meglio il mio profilo di rischio, il mio assetto organizzativo e il mio capitolato?

Cinque dimensioni che contano davvero

Dimensione	SaaS	On-Premises	Cloud Ibrido
Modello di costo	Canone periodico, spesa più prevedibile, spesso OPEX	Licenza, infrastruttura, manutenzione e team interno	Spesa mista tra canoni e componenti gestite internamente
Lock-in tecnico e contrattuale	Alto se dati, workflow e API sono poco portabili	Più controllo sull'ambiente, ma possibile dipendenza da custom e integratori	Rischio distribuito, ma architettura più complessa da governare
Sicurezza e residenza dei dati	Dipende da architettura, clausole, localizzazione e audit	Maggior presidio interno, se esistono competenze adeguate	Utile quando alcuni dati o servizi devono restare separati
Integrazione con sistemi esistenti	Rapido su casi standard, più delicato su legacy complessi	Forte aderenza a sistemi interni consolidati	Spesso la scelta più realistica in ecosistemi misti
Responsabilità operative	Aggiornamenti, backup e parte dell'operatività in capo al fornitore	Maggiore carico su IT interno o outsourcer	Responsabilità condivise, con necessità di confini chiari

Quando il SaaS ha senso

Per una PMI B2B che vuole attivare rapidamente una piattaforma acquisti o un CRM tecnico, il SaaS funziona spesso bene. Riduce il tempo di avvio, distribuisce il costo nel tempo e alleggerisce il presidio operativo.

Il problema non è il canone. Il problema è capire cosa succede se tra due anni vuoi cambiare fornitore, integrare un ERP o recuperare lo storico in un formato utile.

Quando on-premises o ibrido sono più sensati

Nella PA, o in contesti con dati sanitari, finanziari o documentali sensibili, il tema non è solo sicurezza in astratto. Conta la capacità di dimostrare controllo, audit trail, localizzazione del dato, segregazione dei ruoli e continuità operativa.

Per questo alcune amministrazioni e alcune imprese con sistemi core complessi preferiscono modelli on-premises o ibridi. L'ibrido, in particolare, è spesso il compromesso più pragmatico quando una parte dei workload può stare su servizi cloud e un'altra deve restare integrata a sistemi interni.

Scegli l'architettura sul capitolato, non sulle slide del vendor. Se il fornitore non accetta di tradurre la promessa commerciale in clausole verificabili, la soluzione non è ancora matura per essere comprata.

Un altro punto spesso trascurato riguarda la ricorrenza dei modelli cloud e SaaS nel mercato italiano. Le gare recenti includono licenze SAP S/4HANA Cloud, recovery SaaS, endpoint protection e rinnovi di piattaforme come Pentaho ed Equitrac, segno di una domanda orientata sempre più a servizi continuativi e integrazione con ERP, compliance e analytics nel quadro qualitativo riportato da GlobalTenders sulle gare software in Italia.

Il Processo di Gara e RFP per il Software

Una gara software ben gestita non nasce dal disciplinare. Nasce molto prima, quando qualcuno mette ordine tra fabbisogno operativo, requisiti tecnici e sostenibilità economica.

Dalla domanda interna alla RFP

La fase iniziale richiede tavoli veri con utenti, IT, acquisti e, quando serve, legale e sicurezza. Devi mappare il processo attuale, capire dove si inceppa e definire il processo target. Solo dopo puoi scrivere requisiti utili.

Una richiesta di offerta ben impostata serve proprio a questo: rendere confrontabili offerte diverse e ridurre i margini di ambiguità.

Passaggi tipici:

1. Analisi dei fabbisogni. Processi AS-IS e TO-BE, utenti coinvolti, sistemi da integrare, vincoli documentali, stima del costo lungo il ciclo di vita.
2. Redazione del capitolato tecnico. Requisiti minimi, requisiti premianti, architettura attesa, SLA, sicurezza, interoperabilità, onboarding, formazione, exit plan.
3. Scelta della procedura e dello strumento. In base a soglia, categoria e oggetto dell'acquisto, puoi muoverti su MEPA, SDAPA, Convenzioni Consip o altre procedure applicabili.
4. Pubblicazione e chiarimenti. La qualità delle risposte ai quesiti incide molto sulla qualità delle offerte.
5. Valutazione tecnica ed economica. Serve una griglia leggibile, difendibile e coerente con il capitolato.
6. Aggiudicazione e avvio. Dopo la verifica dei requisiti, inizia la parte più importante: l'esecuzione.

Gli strumenti italiani cambiano il metodo di lavoro

MEPA è spesso il primo ambiente da considerare per acquisti sotto soglia o per esigenze standardizzabili. SDAPA aiuta quando serve una cornice più strutturata e categorie merceologiche definite. Le Convenzioni Consip possono ridurre tempi e incertezze nei casi ricorrenti.

ANAC non è solo un presidio di vigilanza. È anche il luogo in cui la trasparenza diventa operativa. In Italia, l'obbligo introdotto dalla legge del 2012 impone alle amministrazioni di trasmettere ad ANAC i dati annuali sugli appalti entro il 31 gennaio dell'anno successivo in formato XML, mentre il dataset OCDS copre i contratti pubblici sopra i 40.000 euro ed è aggiornato mensilmente, con copertura del periodo gennaio 2020 – settembre 2025 nel registro OCDS dell'Open Contracting Data Standard dedicato all'Italia.

Dove le RFP si rompono

Le RFP software si indeboliscono quando mescolano desiderata generici e requisiti obbligatori. Oppure quando lasciano fuori aspetti essenziali come migrazione dati, livelli di servizio, tempi di presa in carico e responsabilità sugli ambienti.

Una buona RFP taglia il contenzioso prima che nasca. Obbliga il fornitore a rispondere punto per punto e obbliga la stazione appaltante a valutare su basi comparabili.

Criteri di Valutazione Tecnico-Economica

Nel software, il prezzo iniziale dice poco. Può perfino essere la parte meno importante della decisione. Quello che conta è il costo totale di possesso e la capacità della soluzione di reggere nel tempo, senza bloccare processi o creare dipendenze ingestibili.

Il prezzo da solo porta fuori strada

Una piattaforma può avere un'offerta economica apparentemente favorevole e diventare costosa dopo l'avvio. Succede quando il capitolato non isola bene i costi di migrazione, formazione, supporto evolutivo, ambienti aggiuntivi, API, reportistica o dismissione.

Per questo conviene lavorare con una griglia che separi almeno quattro aree:

• Funzionalità. Copertura dei processi, usabilità, workflow, configurabilità.
• Requisiti non funzionali. Performance, disponibilità, sicurezza, scalabilità, logging.
• Conformità. Aderenza a requisiti documentali, protezione dati, vincoli di interoperabilità, obblighi AgID quando applicabili.
• Economia complessiva. Canoni, manutenzione, servizi inclusi, servizi extra, costo di uscita.

Una griglia difendibile

Criterio	Sotto-criterio	Peso %	Soglia sbarramento	Metodo di attribuzione punteggio
Qualità funzionale	Copertura requisiti, workflow, usabilità	Da definire in gara	Sì, se requisito essenziale	Valutazione tecnica su sub-criteri descritti
Integrazione	API, interoperabilità, connettori, export dati	Da definire in gara	Sì, per sistemi core	Punteggio discrezionale con evidenze richieste
Sicurezza e continuità	Ruoli, audit trail, backup, recovery, segregazione	Da definire in gara	Sì	Verifica documentale e tecnica
Servizi di avvio	Migrazione, formazione, piano progetto	Da definire in gara	No, salvo casi critici	Punteggio su piano operativo
Offerta economica	Prezzo complessivo del ciclo di vita	Da definire in gara	No	Formula economica prevista negli atti

La colonna “Peso %” non va riempita in modo meccanico. Va costruita in base all'oggetto della gara. In un documentale, ad esempio, integrazione, conservazione, profilazione e gestione dei metadati possono valere più della semplice ergonomia.

Cosa rende la matrice robusta

Una matrice regge quando ogni criterio è accompagnato da prova attesa. Se attribuisci punteggio alla portabilità dei dati, devi chiedere formati di export, struttura dei metadati, tempi di rilascio e responsabilità del fornitore.

Se premi l'integrazione, devi chiarire con quali sistemi e con quale perimetro. “Disponibilità ad integrare” non è un criterio utile. “Connettore documentato verso protocollo, ERP e identità federata” è già qualcosa che puoi verificare.

Requisiti Normativi per il Software nella PA

Nel procurement software pubblico, la norma non è un allegato separato. È parte della progettazione dell'acquisto. Se la consideri alla fine, il capitolato rischia di essere tecnicamente appetibile ma giuridicamente fragile.

Dalle regole alle clausole

Il quadro italiano va letto come un insieme coerente. C'è il perimetro procedurale del Codice dei contratti. C'è il ruolo di AgID nell'indirizzo tecnico. C'è la digitalizzazione operativa dei processi di acquisto. C'è la protezione dei dati.

Le Linee guida AgID sull'acquisizione e il riuso del software impongono una valutazione comparativa tecnico-economica prima dell'acquisto, con preferenza per open source e software già disponibile presso altre amministrazioni nelle linee guida AgID su acquisizione e riuso del software nella PA. Questo sposta la scelta da una logica centrata solo sul prezzo a una logica di riuso, tracciabilità architetturale e riduzione del lock-in.

Chi lavora su questi dossier dovrebbe anche tenere a portata di mano un quadro pratico sulla digitalizzazione della Pubblica Amministrazione, perché molti requisiti di procurement discendono dalla trasformazione digitale dei processi, non solo dalle regole di gara.

Cosa chiedere in capitolato

Un capitolato software per la PA dovrebbe tradurre i principi normativi in richieste operative precise.

• Portabilità dei dati. Formati di export, tempi di rilascio, completezza dei metadati, condizioni economiche di uscita.
• Audit trail. Tracciamento eventi, amministratori, modifiche, accessi e operazioni critiche.
• Interoperabilità. API, documentazione tecnica, standard di integrazione e responsabilità di collaudo.
• Servizio e continuità. SLA minimi, gestione incident, backup, ripristino, ruoli di escalation.
• Protezione dati. Ruoli privacy, misure tecniche, localizzazione, logiche di segregazione e supporto agli adempimenti.

Il ruolo di AgID e del Piano Triennale ICT

Il Piano triennale ICT richiama esplicitamente il monitoraggio del processo di approvvigionamento IT e l'uso di standard di interoperabilità, riuso e documentazione tecnica nel report AgID che richiama questi elementi di governo degli approvvigionamenti ICT. In pratica, non basta comprare una soluzione funzionante. Serve anche una soluzione documentabile, integrabile e riutilizzabile.

Se un requisito tecnico non è traducibile in una clausola contrattuale o in una prova di collaudo, per la PA quel requisito è ancora troppo vago.

Gestione Contrattuale Post-Aggiudicazione

La firma non chiude il lavoro. Lo apre. Nel software procurement, la perdita di controllo arriva quasi sempre dopo l'aggiudicazione, quando il progetto entra nella routine e nessuno presidia più milestone, livelli di servizio e finestre di rinnovo.

Un caso realistico

Prendi un Comune medio che aggiudica una piattaforma gestionale SaaS per trentasei mesi. Il progetto parte bene. Il fornitore attiva l'ambiente, programma la migrazione, prepara la formazione. Dopo pochi mesi, però, emergono i problemi classici: utenti abilitati ma poco formati, dati storici migrati in modo incompleto, ticket che restano aperti troppo a lungo, richieste di personalizzazione non previste.

In questa fase il contratto deve già dirti cosa fare. Se non hai previsto un piano di onboarding, criteri di collaudo, ruoli, tempi di presa in carico e disciplina delle varianti, ogni criticità si trasforma in trattativa.

Per orientarsi nelle implicazioni operative e giuridiche, è utile tenere presente anche il tema della contrattualistica nella Pubblica Amministrazione, perché proroghe tecniche, rinnovi e subappalti non si gestiscono con logiche informali.

Cosa monitorare davvero

Durante l'esecuzione, io guardo prima questi elementi:

• Collaudo. Criteri di accettazione, test di integrazione, verifica dei dati migrati, utenti pilota.
• SLA operativi. Tempi di presa in carico, tempi di risoluzione, classificazione delle priorità, finestre di manutenzione.
• Adozione interna. Formazione completata, ruoli abilitati, processi effettivamente spostati sul nuovo sistema.
• Consumi e scostamenti. Utenti attivi, moduli extra, richieste fuori perimetro, eventuali costi non pianificati.
• Subappalti e terze parti. Chi eroga infrastruttura, chi gestisce supporto specialistico, chi tratta i dati.

Clausole che evitano il lock-in

Un buon contratto software dovrebbe includere almeno tre paracadute: exit plan, portabilità dei dati e diritto di recesso con regole chiare. Senza questi elementi, il rinnovo smette di essere una scelta e diventa una necessità.

Attenzione anche alle proroghe tecniche. Possono essere legittime quando servono a garantire continuità, ma se diventano la scorciatoia abituale per prendere tempo, segnalano che il governo del contratto è arrivato tardi.

Il momento migliore per negoziare l'uscita è prima di entrare. Dopo l'avvio, il potere contrattuale si sposta quasi sempre verso chi controlla piattaforma, configurazioni e storico dati.

Checklist Operativa e Casi Pratici

Chi lavora bene nel software procurement usa checklist vive, non file dimenticati in cartella condivisa. Devono aiutare a decidere, non solo a “spuntare adempimenti”.

Checklist per l'analisi del fabbisogno

• Mappa il processo reale. Identifica chi usa il sistema, dove nascono i colli di bottiglia e quali passaggi devono cambiare.
• Distingui requisiti essenziali e desiderabili. Se li confondi, la valutazione tecnica si sporca.
• Stima il costo di ciclo di vita. Considera canoni, servizi, formazione, integrazioni, supporto ed eventuale uscita.
• Coinvolgi IT e utenti finali. L'ufficio acquisti da solo non può definire interoperabilità, profili autorizzativi o collaudo.
• Verifica il mercato storico. Guarda gare simili, aggiudicazioni e configurazioni ricorrenti prima di scrivere il capitolato.

Checklist per la preparazione della gara

• Scrivi un capitolato verificabile. Ogni requisito importante deve avere una prova attesa.
• Definisci la griglia di punteggio prima di pubblicare. Non dopo l'arrivo delle offerte.
• Scegli lo strumento giusto. MEPA, SDAPA, Convenzione o altra procedura devono essere coerenti con oggetto e complessità.
• Disciplina i chiarimenti. Risposte tardive o vaghe peggiorano la qualità delle offerte.
• Inserisci clausole di uscita e portabilità. Se mancano, stai comprando una dipendenza.

Checklist per l'esecuzione contrattuale

• Pianifica il collaudo. Con date, ruoli, test e criteri di accettazione.
• Monitora SLA e ticket. Non solo a fine trimestre. In modo continuativo.
• Controlla rinnovi e finestre di recesso. Molti costi evitabili nascono da mancato presidio delle scadenze.
• Traccia varianti e richieste extra. Ogni modifica va qualificata, autorizzata e valorizzata correttamente.
• Presidia obblighi di pubblicazione e trasparenza. La parte amministrativa continua anche dopo l'avvio tecnico.

Due casi pratici

Primo caso. Un Comune deve migrare un gestionale demografico in cloud attraverso una Convenzione Consip. L'errore tipico è pensare che la Convenzione risolva da sola il problema di implementazione. Non è così. La Convenzione accorcia alcuni passaggi di procurement, ma restano da governare perimetro dei servizi, migrazione dati, collaudo, formazione e integrazione con i sistemi già in uso.

Secondo caso. Una PMI B2B risponde a una RFP regionale per una piattaforma di e-procurement. L'errore più frequente è puntare tutto sull'offerta economica e lasciare generiche API, supporto applicativo ed exit strategy. In commissione tecnica questo pesa. Un'offerta ordinata, con allegati chiari, architettura leggibile e matrice di conformità ben compilata regge meglio anche a parità di prezzo.

Quando la pipeline di bandi e contratti è ampia, una piattaforma di monitoraggio può aiutare a tenere insieme opportunità e post-aggiudicazione. Horienta consente di seguire gare, aggiudicazioni, esecuzione, proroghe, subappalti e scadenze contrattuali, trasformando la checklist in un flusso di lavoro continuo invece che in un documento statico.

---

Se gestisci bandi software o vuoi costruire più controllo sul ciclo di vita dei contratti, Horienta ti aiuta a monitorare opportunità, aggiudicazioni e fasi esecutive in modo operativo. È utile sia per uffici gare sia per imprese B2B che devono seguire scadenze, rinnovi e movimenti del mercato con continuità.