Salta al contenuto principale

Metodo e fonti

Inviato da tuxsa il

Codice Pubblico nasce con un obiettivo preciso: conoscere e rendere comprensibili le scelte software della Pubblica Amministrazione attraverso dati verificabili, documenti pubblici e criteri di analisi dichiarati in anticipo.

Il progetto non parte dalla conclusione che ogni soluzione proprietaria debba necessariamente essere sostituita, né dall'idea che l'adozione del Software Libero produca automaticamente un risparmio pari al costo delle licenze eliminate. Parte invece da una domanda più semplice: quali strumenti digitali utilizza la Pubblica Amministrazione, quanto costano, da chi dipendono e quali alternative potrebbero essere concretamente valutate?

Per rispondere è necessario adottare un metodo che permetta a chiunque di verificare i dati raccolti e, quando possibile, di ripetere la stessa ricerca su un'altra amministrazione.

1. Prima i documenti, poi le conclusioni

Ogni informazione utilizzata nella mappatura dovrà essere ricondotta, per quanto possibile, alla fonte dalla quale è stata ricavata.

Una determina di affidamento, un contratto, un documento contabile, un CIG, una scheda pubblicata dall'amministrazione o un'altra fonte istituzionale costituiscono il punto di partenza della ricerca.

La presenza di un determinato prodotto o fornitore in un documento non sarà però sufficiente, da sola, per formulare conclusioni sulla complessiva infrastruttura informatica dell'ente.

Allo stesso modo, l'importo di un affidamento che comprende software, assistenza, migrazione, formazione, servizi cloud o altre prestazioni non sarà automaticamente classificato per intero come costo delle licenze software.

Quando i documenti non consentiranno questa distinzione, il dato sarà indicato come tale.

2. Le fonti

La ricerca utilizzerà prioritariamente fonti pubbliche e liberamente consultabili.

Tra queste rientrano i siti istituzionali degli enti, le sezioni di Amministrazione Trasparente, determine e deliberazioni, documenti di gara e affidamento, contratti pubblicati, documentazione contabile, dati relativi a CIG e CUP, piattaforme nazionali relative ai contratti pubblici, documentazione MePA disponibile, progetti finanziati attraverso PNRR o altri programmi pubblici e banche dati istituzionali.

Potranno essere utilizzate anche fonti secondarie per individuare informazioni da approfondire, ma un articolo di stampa, un comunicato commerciale o una dichiarazione di un fornitore non saranno considerati equivalenti a un documento amministrativo quando si tratterà di determinare una spesa sostenuta dall'ente.

Per ogni dato significativo cercheremo quindi di conservare il riferimento alla fonte primaria.

3. Il periodo della ricerca

La prima applicazione, Codice Pubblico / Salerno, partirà dagli anni più recenti e procederà progressivamente a ritroso.

In una prima fase prenderemo come riferimento il periodo 2021–2026. Questo intervallo potrà essere ampliato quando documenti precedenti risultino necessari per comprendere l'origine di un contratto, la continuità di un determinato fornitore o l'evoluzione di una scelta tecnologica.

L'obiettivo non è soltanto calcolare quanto sia stato speso in un determinato anno, ma comprendere anche la persistenza delle dipendenze tecnologiche nel tempo.

Un costo ricorrente, un rinnovo periodico o l'utilizzo dello stesso ecosistema software per molti anni possono infatti essere più significativi di un singolo affidamento di importo elevato.

4. Cosa raccoglieremo

Per ogni elemento individuato cercheremo, quando disponibili, almeno le seguenti informazioni:

amministrazione; anno; data del documento; oggetto dell'affidamento; software o servizio; produttore; fornitore; importo; durata; numero di licenze o utenti; CIG; CUP quando presente; modalità di acquisizione; documento di riferimento; collegamento alla fonte; categoria del software; eventuale rinnovo; informazioni disponibili sulla presenza di alternative libere o possibilità di riuso.

A questi dati potranno essere aggiunte annotazioni tecniche necessarie a comprenderne correttamente il significato.

La base informativa sarà progressivamente pubblicata in formati aperti, in modo che i dati possano essere controllati, elaborati e riutilizzati.

5. Come classificheremo il software

Non esiste una sola categoria di "spesa informatica". Per questo distingueremo almeno tra software per le postazioni di lavoro e produttività individuale; sistemi operativi; server e infrastrutture; database; posta elettronica e collaborazione; cloud e servizi SaaS; sicurezza informatica; protocollo e gestione documentale; gestionali amministrativi; applicativi specialistici; servizi web; software sviluppato specificamente per l'amministrazione; manutenzione, assistenza e servizi collegati.

Questa classificazione potrà essere perfezionata durante la ricerca.

Sarà inoltre importante distinguere software, servizi e infrastrutture. L'esistenza di un contratto con un'impresa informatica non significa necessariamente che l'amministrazione abbia acquistato una licenza proprietaria.

6. Software proprietario non significa automaticamente spesa evitabile

Codice Pubblico non considererà ogni costo relativo a software proprietario come un risparmio automaticamente conseguibile attraverso il Software Libero.

Per ogni possibile alternativa dovranno essere considerate compatibilità con i sistemi esistenti, interoperabilità, formati utilizzati, necessità formative, migrazione dei dati, assistenza, sicurezza, continuità operativa e costi di transizione.

Quando sarà possibile effettueremo quindi una valutazione basata sul costo complessivo nel tempo, e non soltanto sul prezzo iniziale della licenza.

Potrà accadere che una soluzione libera risulti chiaramente valutabile, che richieda una migrazione progressiva oppure che, nelle condizioni esistenti, non sia possibile indicare una sostituzione ragionevole.

Anche quest'ultimo risultato farà parte della ricerca.

7. Dipendenza tecnologica

Il costo economico costituisce soltanto una delle dimensioni analizzate.

Cercheremo di individuare anche situazioni nelle quali l'amministrazione risulti fortemente dipendente da uno specifico produttore, fornitore, formato o ecosistema tecnologico.

La dipendenza tecnologica può manifestarsi attraverso rinnovi obbligati, difficoltà nella migrazione dei dati, utilizzo di formati non pienamente interoperabili, applicazioni che funzionano esclusivamente all'interno di determinati ambienti o perdita delle competenze necessarie alla gestione autonoma dei sistemi.

L'analisi riguarderà quindi anche il problema del vendor lock-in e dell'autonomia tecnologica della Pubblica Amministrazione.

8. Software Libero già presente

La ricerca non cercherà soltanto software proprietario.

Uno degli obiettivi sarà individuare e documentare anche l'eventuale utilizzo di Software Libero e Open Source già presente nell'amministrazione: sistemi operativi, server web, database, CMS, librerie, strumenti di sviluppo, applicazioni o altre componenti.

Conoscere ciò che già funziona attraverso tecnologie aperte è indispensabile per evitare una rappresentazione incompleta della situazione e può fornire indicazioni utili per eventuali sviluppi futuri.

9. CAD, valutazione comparativa e riuso

Per le acquisizioni software significative cercheremo, quando possibile, di verificare la presenza della documentazione relativa alla valutazione comparativa prevista dal Codice dell'Amministrazione Digitale e dalle relative Linee guida.

Particolare attenzione sarà riservata alla considerazione delle soluzioni a codice sorgente aperto e delle possibilità di riuso.

Nel caso di software realizzato appositamente per un'amministrazione pubblica, verificheremo inoltre le informazioni disponibili sulla titolarità del codice, sulla sua eventuale pubblicazione e sulla possibilità di riutilizzarlo da parte di altre amministrazioni.

L'assenza di un documento nelle fonti pubblicamente consultabili non sarà tuttavia interpretata automaticamente come prova della sua inesistenza.

10. Dati mancanti e accesso civico

Durante la mappatura verrà mantenuto un elenco separato delle informazioni che non è stato possibile reperire.

Soltanto successivamente saranno valutate richieste di accesso civico semplice, accesso civico generalizzato o altre forme di accesso previste dall'ordinamento, scegliendo lo strumento appropriato in relazione al documento o all'informazione ricercata.

Le richieste saranno il più possibile circoscritte.

Invece di chiedere genericamente all'amministrazione di fornire tutte le informazioni relative al proprio sistema informatico, partiremo da ciò che abbiamo già ricostruito e chiederemo soltanto gli elementi necessari a completarlo o verificarlo.

L'accesso diventa così uno strumento di integrazione della ricerca, non una condizione necessaria per poterla svolgere.

11. Anche ciò che non troviamo è un'informazione, ma va descritto correttamente

Codice Pubblico distinguerà sempre tra:

dato documentato, quando disponiamo di una fonte che lo dimostra;

dato ricostruito, quando deriva dall'incrocio di più documenti e viene spiegato il procedimento seguito;

dato da verificare, quando esistono elementi indicativi ma insufficienti per una conclusione;

dato non reperito, quando l'informazione non è stata individuata nelle fonti pubblicamente consultate.

Quest'ultima definizione è particolarmente importante.

Scrivere che un documento non è stato reperito non equivale ad affermare che quel documento non esiste.

Quando necessario chiederemo all'amministrazione di chiarirlo.

12. Correzioni e aggiornamenti

Codice Pubblico sarà un progetto aperto e progressivo.

Documenti successivamente individuati, risposte delle amministrazioni, segnalazioni motivate o errori riscontrati potranno determinare l'aggiornamento dei dati e delle analisi.

Le correzioni sostanziali saranno rese riconoscibili e, quando opportuno, accompagnate dall'indicazione della data di aggiornamento.

Lo scopo non è difendere una conclusione, ma costruire una conoscenza pubblica verificabile.

13. Un metodo riutilizzabile

Salerno costituisce il primo campo di applicazione, ma il metodo è pensato per essere replicato.

Schede di rilevazione, classificazioni, modelli per gli accessi, criteri di analisi e dataset prodotti nell'ambito di Codice Pubblico saranno progressivamente organizzati affinché possano essere utilizzati anche per altre amministrazioni.

L'obiettivo finale non è soltanto conoscere quali software utilizza un Comune.

È rendere possibile ai cittadini comprendere come viene costruita l'infrastruttura digitale della propria amministrazione, quanto costa, quali dipendenze genera e quali alternative esistono.

Perché una scelta tecnologica pubblica è anche una scelta sull'accessibilità dei servizi, sulla conservazione dei dati, sull'autonomia delle istituzioni e sull'utilizzo futuro delle risorse collettive.

Codice Pubblico parte dai documenti perché soltanto dopo aver conosciuto ciò che esiste possiamo formulare proposte credibili per cambiarlo.