RFP sviluppo software GIS: cosa chiedere a un fornitore (guida pratica 2026)

Scrivere una richiesta di offerta (RFP) per un backend GIS enterprise è un esercizio diverso da un capitolato software generico. I dati geospaziali hanno caratteristiche di volume, performance query e complessità di indicizzazione che un fornitore senza esperienza specifica sottovaluta sistematicamente - spesso in buona fede, perché il problema non è visibile finché il sistema non è già in produzione con dati reali.

Questa guida raccoglie le domande tecniche che, nella nostra esperienza diretta di chi costruisce backend GIS per settori come le telecomunicazioni e la mobilità connessa, distinguono davvero un fornitore preparato da uno che si adatterà - a tue spese - durante il progetto.

tl;dr

• Un RFP GIS serio deve includere domande su indicizzazione spaziale, scala dei dati e performance delle query, non solo sullo stack tecnologico generico.
• La disponibilità e gli SLA contano quanto le funzionalità, soprattutto per prodotti che alimentano decisioni di business in tempo reale.
• Un template strutturato (contesto, requisiti funzionali, requisiti tecnici, criteri di valutazione, timeline, budget) rende le offerte dei fornitori comparabili tra loro.

Perché un RFP GIS è diverso

Un backend applicativo generico gestisce righe e colonne. Un backend GIS gestisce geometrie: punti, linee, poligoni, spesso con milioni o decine di milioni di record, interrogati con query spaziali (contenimento, intersezione, distanza, buffer) che hanno un costo computazionale molto diverso da un semplice WHERE id = ?. Un fornitore che non ha mai lavorato a questa scala tende a scoprire il problema di performance solo quando il dataset supera il volume del proof of concept - cioè in produzione, con clienti reali.

Le domande tecniche che quasi nessun capitolato generico include

Come gestite l'indicizzazione spaziale? Un database relazionale con estensione geospaziale (es. PostgreSQL + PostGIS) usa indici spaziali (GiST, SP-GiST) che vanno progettati e mantenuti in modo specifico. Chiedere quale tecnologia useranno e perché è una domanda che filtra rapidamente l'esperienza reale da quella dichiarata.

Vettoriale o raster, o entrambi? Dati come confini amministrativi, particelle catastali, reti stradali sono tipicamente vettoriali; dati come mappe di rischio, immagini satellitari, modelli di elevazione sono raster. Un'architettura che deve gestire entrambi ha esigenze di storage e serving diverse (es. tile server per il raster).

Come servite le geometrie a un frontend mappa in modo performante? Servire milioni di poligoni a un client web richiede tecniche specifiche (vector tiles, semplificazione geometrica per livello di zoom, clustering lato server). Un fornitore che risponde "restituiamo GeoJSON" senza altro dettaglio probabilmente non ha mai affrontato un dataset abbastanza grande da rendere quella risposta insufficiente.

Come gestite gli aggiornamenti incrementali dei dati geospaziali? Ricaricare un intero dataset ad ogni aggiornamento è accettabile a bassi volumi, ma diventa un collo di bottiglia operativo a scala enterprise. Chiedere se esiste una strategia di aggiornamento incrementale (diff, upsert su chiave stabile) è una domanda che rivela la maturità del fornitore.

Scalabilità e volumi: chiedere numeri, non aggettivi

Un errore comune nei capitolati è chiedere "il sistema deve essere scalabile" senza definire cosa significa in numeri concreti. Meglio specificare:

• Volume di dati atteso oggi e tra 18-24 mesi (numero di record, geometrie, dimensione totale).
• Numero di richieste concorrenti attese in condizioni normali e di picco.
• Tempo di risposta massimo accettabile per le query più frequenti (es. "ricerca per area" sotto i 500ms).

A titolo di riferimento di scala: un'infrastruttura come quella che usiamo per i dataset catastali italiani gestisce 85 milioni di particelle con query interattive sulla mappa - un ordine di grandezza che rende evidente, in fase di offerta, se un fornitore ha già affrontato problemi di questa natura o li affronterà per la prima volta sul tuo progetto.

Disponibilità e affidabilità: le domande da fare per prodotti mission-critical

Se il backend GIS alimenta decisioni operative o di business in tempo reale (un sistema di allerta, un tool usato quotidianamente da un team commerciale, un prodotto di monitoraggio), l'affidabilità non è un requisito accessorio.

• Qual è l'SLA di uptime proposto, ed è contrattualizzabile o solo dichiarato?
• Come viene gestito il monitoraggio (alerting automatico, dashboard di stato, escalation)?
• Cosa succede in caso di guasto: esiste un piano di disaster recovery testato, o solo teorico?
• Il sistema ha già superato un incidente reale in produzione? Come è stato gestito? È una domanda scomoda ma rivelatrice: nessun sistema è mai perfetto, e come un fornitore ha gestito un problema reale dice più di qualunque slide.

Sicurezza e compliance per dati geospaziali

I dati geospaziali spesso incrociano informazioni sensibili (localizzazione di asset, infrastrutture critiche, dati personali geolocalizzati). Un RFP serio include:

• Come vengono gestiti i permessi di accesso ai dati (per ruolo, per area geografica, per livello di dettaglio)?
• Dove sono ospitati i dati, e con quali garanzie di data residency se rilevante per il settore?
• Come vengono gestiti i dati pubblici vs. i dati proprietari del cliente all'interno della stessa architettura?

Template di RFP: le sezioni da includere

Un capitolato ben strutturato rende le offerte dei fornitori comparabili tra loro. Le sezioni minime:

1. Contesto: cosa fa la tua azienda, perché serve questo sistema, chi lo userà.
2. Requisiti funzionali: cosa deve fare il sistema dal punto di vista dell'utente (es. "visualizzare la copertura di rete per indirizzo", "generare un report di rischio per particella").
3. Requisiti tecnici: volumi attesi, tipo di dati (vettoriale/raster), integrazioni necessarie con sistemi esistenti, requisiti di performance.
4. Requisiti di affidabilità: SLA richiesto, piano di disaster recovery, monitoraggio.
5. Criteri di valutazione: come verranno giudicate le offerte (esperienza di dominio, referenze verificabili, architettura proposta, costo, timeline) - dichiararli in anticipo rende il processo più onesto per entrambe le parti.
6. Timeline: milestone attese, non solo la data di consegna finale.
7. Budget indicativo: un range, anche ampio, aiuta i fornitori seri a proporre soluzioni realistiche invece di sparare un numero a caso.

Come valutare le risposte: cosa distingue un'offerta seria da una generica

Una risposta seria a un RFP GIS cita tecnologie specifiche e il perché della scelta (non solo un elenco di buzzword), fa domande di chiarimento sui volumi e sui casi d'uso reali prima di proporre un'architettura, e include esempi concreti di progetti simili per scala e complessità - con dettagli tecnici verificabili, non solo nomi di clienti su una slide.

Un segnale d'allarme frequente: un'offerta che propone la stessa architettura generica indipendentemente dal contesto (telco, mobilità, immobiliare, ambientale) senza fare domande specifiche sul tuo dominio. I dati geospaziali cambiano comportamento a seconda del settore - un backend pensato per la copertura di rete Telco non ha automaticamente le stesse caratteristiche di uno pensato per il rischio idrogeologico o per la mobilità connessa.

Due esempi reali a cui facciamo riferimento quando parliamo di scala e affidabilità di questo tipo: la piattaforma di Network Intelligence per il mercato Telco italiano (dati di copertura rete, TowerCo, consolidamento FTTH) e il backend per mobilità connessa (elaborazione dati in tempo reale su scala nazionale). Sono i riferimenti che usiamo per capire, insieme a un cliente, quale classe di problema stiamo affrontando prima ancora di parlare di stack tecnologico.

Quando scriviamo o rispondiamo a un RFP per backend GIS enterprise, lo stack che proponiamo (Node.js/Python/Go per il backend, PostgreSQL/PostGIS, Redis, TimescaleDB per i dati, Docker/Kubernetes/AWS/Terraform per infrastruttura e deploy) è sempre una conseguenza dei requisiti discussi, non un pacchetto standard riproposto a prescindere dal contesto.

Domande frequenti

Quanto dovrebbe essere dettagliato un RFP per un backend GIS enterprise?

Abbastanza da rendere comparabili le offerte dei fornitori: contesto, requisiti funzionali, requisiti tecnici (volumi, performance attese), requisiti di affidabilità, criteri di valutazione, timeline e un budget indicativo. Un RFP troppo generico produce offerte troppo generiche.

PostGIS è sempre la scelta giusta per dati geospaziali?

È una scelta molto solida per la maggior parte dei casi enterprise, ma non universale: per volumi estremi o esigenze di serving cartografico specifiche (tile server, vector tiles) si affianca spesso ad altre componenti (cache, CDN, database specializzati per time-series se il dato ha anche una dimensione temporale).

Come faccio a capire se un fornitore ha davvero esperienza di scala, e non solo dichiarata?

Chiedi numeri concreti su progetti passati (volume di record, query al secondo, tempo di risposta), e verifica se le domande che il fornitore fa a te durante la fase di offerta sono specifiche sul tuo caso d'uso o generiche.

Serve sempre un SLA contrattuale sull'uptime?

Non sempre, ma è essenziale per sistemi che alimentano decisioni operative in tempo reale. Per strumenti di analisi non critici, un SLA meno stringente può essere accettabile e più economico.

Quanto costa indicativamente un progetto di backend GIS enterprise?

Dipende da scala e requisiti di disponibilità: un backend con integrazione singola parte in genere da qualche migliaio di euro; un'architettura completa con alta disponibilità, pipeline dati e postura di sicurezza per due diligence richiede tipicamente un budget a 5 cifre, spesso come partnership continuativa.

Cosa cambia in un RFP se i dati sono anche real-time (non solo storici)?

Vanno aggiunte domande specifiche su latenza di ingestione, throughput sostenibile, gestione dei picchi di carico e strategie di backpressure - requisiti che un'architettura pensata solo per dati statici non gestisce automaticamente.

Vale la pena coinvolgere un consulente indipendente per valutare le offerte tecniche?

Se in azienda non c'è competenza tecnica GIS specifica, sì: un secondo parere tecnico indipendente aiuta a distinguere un'offerta seria da una che suona bene ma nasconde lacune sulla scala o sull'affidabilità richieste.