Il bando PNRR Investimento 1.2 “Abilitazione al Cloud per le PA locali” – Comuni, di luglio 2022 prorogato al 10 febbraio 2023 con ulteriore proroga di tre mesi anche relativamente al tempo per l’affidamento ai fornitori, permette di aprire un dibattito su cosa vuol dire veramente “spostarsi in cloud” (in specifico in SaaS) per la PA. Cerchiamo di fare chiarezza.
Business Intelligence: i tool che dominano il mercato e come scegliere quello più adatto
Passaggio al cloud della PA, aspetti tecnici e contrattuali
Gli aspetti tecnici si traducono (semplificando) nella maggior parte dei casi in:
- acquisire una soluzione SaaS
- contrattualizzare con il fornitore la parte di:
- dati
- accesso
- sla (che fungono da riassunto per backup, disaster recovery e business continuity)
- condizioni di uscita dal servizio
Quello che viene acquistato infatti è:
- uno spazio dati
- uno strumento di elaborazione dei dati
- uno strumento di gestione dei processi
- possibilità di poter disporre dei dati in ogni momento e in particolare caso decida di cambiare servizio
- condizioni di continuità del servizio (sla).
Gli aspetti contrattuali derivano dagli aspetti tecnici. Vorremmo concentrarci più sul mancato cambiamento del modello di vendita, dovuto sia a scelte dei fornitori, che alla poca comprensione della PA della trasformazione che comporta andare in cloud. Andare in cloud non vuol infatti dire solo (parliamo sempre di SAAS) prendere il proprio software e portarlo nel cloud del fornitore, bensì molto di più.
Come usufruire dei servizi SAAS
Il primo aspetto che balza all’occhio è che i servizi SaaS più noti vengono venduti al costo mensile per utente. Attualmente i software della PA vengono ancora venduti a moduli, con relativo costo di attivazione e di manutenzione del modulo. Questo è probabilmente il punto più importante su cui ragionare. Proviamo con un esempio rapportato a Google Workspace e capiamo con un esempio quanti sono diversi i due modelli di ragionamento. Ipotizziamo che Google Workspace aggiunga il servizio della chat. Rapportandolo al modello attuale della PA italiana, per poterla utilizzare dovrebbe:
- far pagare un costo di attivazione della chat
- far pagare un costo di formazione della chat
- far pagare un costo di manutenzione della chat
Cosa fa invece Google? Fornisce la chat nel prodotto, eventualmente alzando il canone mensile per utente quando le funzionalità aggiunte non sostengono più il modello di business. Certo non è la stessa cosa di quello che avviene nella PA (nessuno ha obbligato Google ad aggiungere la chat, se non il “mercato”), ma crediamo di aver fatto comprendere un poco la differenza.
Cosa è incluso e cosa no
Un’applicazione della PA che voglia definirsi tale, ha dei requisiti previsti dal CAD, Piano Triennale, o altri Decreti (Semplificazioni, etc etc). Dovrebbe essere una feature necessaria l’accesso con SPID e CIE da avere nell’applicazione perché questa sia PA compliant, e non un modulo a parte per cui pagare : attivazione, formazione, manutenzione, altro.
Tali feature quindi stanno diventano un “must have” o “by design”:
- autenticazione con SPID (possibilmente con openidconnect)
- autenticazione con CIE (possibilmente con openidconnect)
- collegamento a pagoPA per i pagamenti
- invio dei messaggi con IO
- collegamento a Piattaforma Notifiche per le pagamenti
- collegamento a Piattaforma Nazionale Digitale Dati per la raccolta dati da basi di dati già esistenti (es. ANPR, es. ISEE)
- set di API disponibili
- set di opendata (meglio se “linked”) pubblicabili
- applicazione in cloud certificato oggi AGID in futuro ACN
E un “nice to have” o “valore aggiunto”?
- autenticazione con EIDAS
- possibilità di integrazione con altri partner tecnologici PagoPA
E invece (forse) da pagare
- personalizzazioni (che in ottica di opensource e riuso potrebbero essere rese disponibili a tutti gli altri enti che usano l’applicativo)
- integrazioni molto specifiche o naif
Al che, se si segue la linea sopra, si può approdare ad esempio ad un modello per profili:
- Abbonamento Starter – Tutto quanto indicato sopra
- Abbonamento Stansard – Basic + “nice to have”
- Abbonamento Plus – Professional + Personalizzazioni
Sempre per utente/per mese, non per modulo/per manutenzione!
Consigli per i fornitori
A questo ragionamento possiamo richiedere ai fornitori di seguire i principi di base del piano triennale nella progettazione e gli strumenti resi disponibili da Designers e Developers (i kit) nella realizzazione.
Principi:
- digital & mobile first
- digital identity only
- cloud first
- servizi inclusivi e accessibili
- dati pubblici un bene comune
- interoperabile by design
- sicurezza e privacy by design
- user-centric, data driven e agile
- once only
- transfrontaliero by design
- codice aperto
Strumenti:
- developers.italia.it
- designers.italia.it
- cloud.italia.it
Come fare i contratti
Tutto quanto sopra potrebbe inoltre essere completato dalle regole per i contratti ICT, che prevedono un iter ben definito dall’articolo 68 del CAD:
1. Le pubbliche amministrazioni acquisiscono programmi informatici o parti di essi nel rispetto dei principi di economicità e di efficienza, tutela degli investimenti, riuso e neutralità tecnologica, a seguito di una valutazione comparativa di tipo tecnico ed economico tra le seguenti soluzioni disponibili sul mercato:
a) software sviluppato per conto della pubblica amministrazione;
b) riutilizzo di software o parti di esso sviluppati per conto della pubblica amministrazione;
c) software libero o a codice sorgente aperto;
d) software fruibile in modalità cloud computing;
e) software di tipo proprietario mediante ricorso a licenza d’uso;
f) software combinazione delle precedenti soluzioni.
1-bis. A tal fine, le pubbliche amministrazioni prima di procedere all’acquisto, secondo le procedure di cui al codice di cui al decreto legislativo n. 50 del 2016, effettuano una valutazione comparativa delle diverse soluzioni disponibili sulla base dei seguenti criteri:
a) costo complessivo del programma o soluzione quale costo di acquisto, di implementazione, di mantenimento e supporto;
b) livello di utilizzo di formati di dati e di interfacce di tipo aperto nonché di standard in grado di assicurare l’interoperabilità e la cooperazione applicativa tra i diversi sistemi informatici della pubblica amministrazione;
c) garanzie del fornitore in materia di livelli di sicurezza, conformità alla normativa in materia di protezione dei dati personali, livelli di servizio tenuto conto della tipologia di software acquisito.
1-ter. Ove dalla valutazione comparativa di tipo tecnico ed economico, secondo i criteri di cui al comma 1-bis, risulti motivatamente l’impossibilità di accedere a soluzioni già disponibili all’interno della pubblica amministrazione, o a software liberi o a codici sorgente aperto, adeguati alle esigenze da soddisfare, è consentita l’acquisizione di programmi informatici di tipo proprietario mediante ricorso a licenza d’uso. La valutazione di cui al presente comma è effettuata secondo le modalità e i criteri definiti dall’AgID.
Conclusione
Riassumendo, per una corretta contrattualistica e migrazione al concetto di SAAS per la PA dovremmo:
- passare da un modello a moduli a un abbonamento per mese per utente che comprenda quanto ormai “è ovvio” ci sia in un software per la PA
- richiedere il rispetto del Piano Triennale (e dei suoi principi) e del CAD nella progettazione
- seguire l’iter di acquisizione dell’articolo 68 del CAD
E infine, vista la presenza di PAdigitale2026, richiedere la compliance:
- l’avviso per cui effettui l’acquisto
- suoi allegati
- linee guida di asseverazione se presenti
- chiarimenti all’avviso
- decreti di modifica dell’avviso
- faq
- eventuali ticket di modifica o di domanda
- regole dnsh
- nuove regole ACN in arrivo
senza dimenticare il Codice degli appalti e relative modificazioni successive. Pensare di andare in cloud e trovarsi ancora moduli obbligatori per normativa da pagare ha qualcosa di anomalo. Semplicemente se un sito non permette l’accesso con SPID e CIE (ad esempio) non è adatto alla PA, perché questa feature è obbligatoria da settembre 2021. L’accesso con SPID e CIE non è un plus, un optional, o una feature aggiuntiva, è un pezzo fondamentale di un software della PA che deve fare parte dell’ABBONAMENTO al servizio mensile, per utente. Così vale per tutto quanto elencato in questo articolo, che cerca di essere il più possibile esaustivo, ma soprattutto vuole essere uno spunto di ragionamento per un cambio di paradigma perlomeno da valutare.
