Interrogativi e problemi apertiProtocollo informaticoTrasformazione digitaleVetrina - critico

Digitalizzazione degli sportelli SUE e SUAP, rev. 2023. Cosa cambia

Dopo inquadramento, sguardo di massima al contenuto e qualche considerazione sugli aspetti di gestione documentale, prosegue l’analisi delle specifiche per la comunicazione di dati fra soggetti coinvolti nei procedimenti SUAP pubblicato lo scorso dicembre 2023 dal Dipartimento della funzione pubblica, con l’inevitabile contributo dell’AgID (Agenzia per l’Italia Digitale).

Qui si tenta di dare qualche indicazione pratica su cosa cambierà per i “soggetti coinvolti” e cosa dovrebbero o potrebbero fare per adeguarsi alla rinnovata cornice tecnologica entro la quale devono sviluppare i loro procedimenti. Va da sé che quanto segue va preso a puro livello di suggestione, essendo le realtà digitali degli enti molto diversificate fra loro. Non a caso l’homepage del blog larchivistagitale.it ospita la parafrasi di un celeberrimo incipit letterario: “ogni organizzazione digitale è digitale a modo suo“.

Si è detto che l’intervento incide direttamente sugli aspetti tecnico-informatici di SUAP e dintorni e l’impatto sull’operatività pratica varia in dipendenza del livello di digitalizzazione attuale e delle scelte fatte, tanto per i comuni quanto per gli “enti terzi”.

Lo scenario prossimo venturo: To Be (…or Not To Be)

L’allegato 1 del dpr 160/2010, rivisitato nel 2021, descrive già, discorsivamente quali funzioni spettano a ciascuno dei componenti informatici dell’universo SUAP, formalmente denominato “Sistema informatico degli Sportelli Unici”.

Il software di front-office SUAP (art. 8):

  • cura le interazioni fra impresa e SUAP, inclusa la messa a disposizione le informazioni sui procedimenti del SUAP;
  • identifica il richiedente (impresa) tramite SPID, CIE e altre identità digitali europee;
  • mette a disposizione la modulistica unificata e standardizzata approvata dalla Conferenza unificata;
  • usa pagoPA per i pagamenti;
  • associa a ogni istanza presentata un codice univoco che la seguirà ovunque[1]Ci torniamo, non è il numero di protocollo.;
  • consente l’integrazione dell’istanza da parte del richiedente su richiesta delle amministrazioni che partecipano al procedimento[2]Le amministrazioni partecipanti chiedono l’integrazione con la mediazione del SUAP comunale.;
  • mostra al richiedente (impresa) lo stato di avanzamento della pratica e rende disponibile al richiedente e a tutti le amministrazioni interessate gli atti della pratica, provvedimento conclusivo incluso;
  • comunica in interoperabilità con le altre componenti del Sistema Informatico degli Sportelli Unici, utilizza a tal fine i dati del Catalogo degli Sportelli Unici, comunica con le fonti dati certificate[3]Per acquisire dati relativi allo specifico procedimento, tramite PDND s’intende.;
  • si interfaccia anche con il sistema ComUnica per ricevere la segnalazioni (SCIA) depositate contestualmente alla Comunicazione unica per la nascita dell’impresa al Registro delle imprese[4]Di fatto il sistema ComUnica è un ulteriore punto di ingresso per alcune istanze, le SCIA (Segnalazione Certificata di Inizio Attività) che sono consegnate al Registro delle imprese contestualmente … Continue reading.

Il software di back-office SUAP (art. 9):

  • riceve le istanze e le inoltra agli enti terzi interessati (uffici comunali inclusi);
  • riceve le richieste di integrazioni dell’istanza da parte degli enti terzi e le inoltra al font-office SUAP;
  • riceve dal front-office SUAP le integrazioni e le inoltra agli enti terzi;
  • riceve i pareri dagli enti terzi;
  • inoltra al front-office l’atto conclusivo del procedimento (dove previsto);
  • traccia le informazioni utili a determinare lo stato del procedimento;
  • inoltra alle amministrazioni interessate e al richiedente la comunicazione di indizione della conferenza di servizi;
  • comunica in interoperabilità con le altre componenti del Sistema Informatico degli Sportelli Unici e utilizza a tal fine i dati del Catalogo degli Sportelli Unici.

Si può intanto osservare:

  1. verifiche acquisizioni d’ufficio da fonti certificate le fa il front-office e non il back-office, quasi a significare che queste sono acquisite in tempo reale durante la presentazione dell’istanza: si supera forse il concetto di verifica di dichiarazione e si va verso l’acquisizione d’ufficio;
  2. i requisiti individuati per il back-office sono limitati allo “spostamento” di documenti (richieste, pareri, provvedimenti) e non anche all’assistenza alla loro redazione[5]L’unico riferimento a funzioni del back-office di supporto agli operatori è nelle specifiche tecniche (paragrafo 3.2), “per la verifica di procedibilità delle istanze presentate”. … Continue reading. Almeno a livello di suggestione l’assistenza nella formazione degli atti è la funzione che solitamente si associa a un software di back-office, mentre la mera trasmissione è qualcosa che fa pensare al protocollo informatico…
  3. le specifiche tecniche descrivono front-office e back-office SUAP come componenti del tutto disaccoppiate e indipendenti, che comunicano fra loro tramite API. C’è però una sorta di clausola di salvaguardia (paragrafo 4[6]”Al fine di salvaguardare gli investimenti effettuati dai soggetti interessati, per le sole implementazioni già realizzate alla data di pubblicazione delle presenti specifiche tecniche, è … Continue reading) che consente di mantenere monolitiche le soluzioni esistenti che offrono funzioni di front-office e back-office SUAP integrate[7]C’è da sperare che questa deroga sia intesa per quello che è e non sia invece presa come giustificazione per non sviluppare le API di comunicazione con le altre componenti. Le uniche API che, … Continue reading.

Il software di back-office degli altri uffici comunali e degli enti terzi (art. 10, anche dualmente rispetto a quanto sopra):

  • riceve l’istanza inoltrata dal back-office SUAP e selezione e preleva i documenti di proprio interesse[8]Ricordo: il flusso informatico prevede che il back-office SUAP avvisi il back-office dell’ente terzo che c’è una istanza e poi il back-office dell’ente la preleva, evidentemente … Continue reading;
  • trasmette al back-office SUAP eventuali richieste di integrazioni e riceve le integrazioni;
  • trasmette al back-office SUAP i pareri di competenza;
  • realizza un servizio per dichiarare i pagamenti spettanti[9]I dati sui pagamenti spettanti confluiscono nel Catalogo del Sistema Informatico degli SPOrteli Unici e consentono alla componente front-office, in fase di compilazione e perfezionamento … Continue reading;
  • riceve la comunicazione di indizione della conferenza di servizi:
  • può realizzare, se necessario, servizi per migliorare le interazioni con il richiedente (qualunque cosa voglia dire[10]Ammetto che risulta difficile dare concretezza a questo requisito, anche perché la ratio di fondo è che con il richiedente interagisca il SUAP e solo il SUAP.;
  • comunica in interoperabilità con le altre componenti del Sistema Informatico degli Sportelli Unici e utilizza a tal fine i dati del Catalogo degli Sportelli Unici.

Anche a questo punto, si può fare qualche osservazione:

  • le specifiche tecniche stabiliscono esplicitamente (paragrafo 4) che della componente back-office Enti Terzi “si DEVONO dotare gli uffici comunali diversi dal SUAP e le altre pubbliche amministrazioni interessate dal procedimento, ai sensi del comma 2 dell’articolo 10 dell’Allegato DPR 160/2010″: la questione meriterebbe un approfondimento, ma ci sono uffici (comunali e di enti esterni al comune) che al momento non hanno un software di back-office dedicato ai procedimenti di ambito SUAP e gestiscono gli endoprocedimenti di propria competenza “a livello documentale”, cioè nel sistema di gestione informatica dei documenti, organizzando la documentazione di una pratica in fascicoli e relazionando domande e risposte;
  • anche questo back-office ha il solo requisito di spostare dati e documenti e non anche di assistere nella loro formazione[11]”Come il protocollo informatico!” – esclamò qualcuno dall’ultimo banco. Non anticipiamo, però, tutto sommato… niente esclude che il back-office possa essere il … Continue reading;
  • i servizi che migliorano l’interazione con l’utente, citati nell’allegato 1 ma non ripresi dalle specifiche tecniche, sembrerebbero aprire uno spiraglio a comunicazioni dirette con il richiedente che scavalcano il SUAP?
  • la raccolta di pagamenti verso più enti, coordinata dal front-office SUAP in fase di presentazione dell’istanza e necessariamente condotta tramite la piattaforma pagoPA, richiede uno studio attento per non bloccare la rendicontazione nei singoli enti. Si è detto (in una nota) che, secondo le attuali “Specifiche attuative del nodo dei pagamenti” (SANP), le strade percorribili sono diverse. Una potrebbe essere il pagamento cosiddetto multibeneficiario che, a livello di piattaforma pagoPA, è gestito da un unico ente creditore (in questo caso il SUAP) che suddivide il pagamento complessivo in quote da destinare agli enti terzi. Ciò richiede che gli enti terzi forniscano informazioni precise al Catalogo. Le specifiche tecniche non sembrano trattare l’argomento pagamenti[12]Anche una ricerca testuale per “pagoPA” o “paga*” non fornisce alcun risultato.. Tuttavia, le SANP stesse annoverano il caso SUAP come esempio di pagamento multibeneficiario. Perché tutto funzioni è necessario che i dati scambiati durante le transazioni pagoPA siano il più possibile completi, anche dei dati contabili, in modo che tutti gli enti abbiano a disposizione quanto necessario per rendicontare i pagamenti secondo le modalità che ciascuno ha individuato (che no, non sono standard)..

Il Catalogo del Sistema Informatico degli Sportelli Unici (art. 11 e specifiche tecniche):

  • consente la registrazione di tutte le componenti informatiche del Sistema Informatico;
  • permette ai soggetti coinvolti a consultazione dell’elenco delle componenti, dei servizi che espongono e delle regole per lo scambio di dati, dette metadati[13]Questi includono l’elenco di procedimenti amministrativi attivabili presso ciascun ente, il modulo digitale da usare, gli allegati da presentare, l’ufficio dell’ente da coinvolgere … Continue reading;
  • espone e rende consultabili l’elenco dei procedimenti amministrativi, messi in relazione con gli schemi della modulistica unificata e agli enti competenti.

I dati contenuti nel Catalogo sono descritti, nelle specifiche, da un accurato diagramma E-R (Entità-Relazioni), lo strumento concettuale tipico della progettazione dei database relazionali (significativo anche per i non esperti) che mostra le entità gestite dalla banca dati e, per ciascuna, gli attributi e le relazioni con altre entità.

A complemento dei componenti nel Sistema Informatico c’è anche il sistema ComUnica che assiste il mondo delle Camere di Commercio (Registro delle Imprese) nella gestione della cosiddetta “Comunicazione unica (di registrazione di un’impresa)”. Anche per questo componente, che di fatto è un punto di ingresso aggiuntivo per alcuni procedimenti SUAP, sono dettate regole precise di integrazione ai quali i front-office devono aderire.

Si conferma, e non può essere altrimenti, l’esistenza del portale camerale “Impresa in un giorno” che (art. 4) “mette a disposizione dei Comuni le componenti informatiche front-office SUAP e back-office SUAP.

Confronto con lo scenario attuale: As Is (…or As If)

Un confronto con l’attualità deve necessariamente svilupparsi su due versanti. Infatti, occorre distinguere fra la situazione attuale ideale, quella cioè ipotizzata dal precedente allegato 1 del dpr 160/2010[14]L’allegato 1 versione 20210 si addentrava anche in dettagli tecnici, oggi demandati alle apposite specifiche e alla modulistica., e la situazione reale, cioè quanto dell’ipotizzato è stato realmente implementato e messo in uso dai soggetti coinvolti[15]La situazione è comune ad altri ambiti, ma, quando si parla di trasformazione digitale, talvolta si ha l’impressione che il legislatore di turno dia sempre per scontato che tutto ciò che è … Continue reading.

Il precedente allegato 1, ancora applicato, è senza dubbio più vago nel definire le componenti informatiche coinvolte nei processi SUAP, non ha la visione di insieme del Sistema Informatico degli Sportelli Unici (di cui manca il Catalogo) e mescola indicazioni di massima a specifiche tecniche di dettaglio. Nel complesso il flusso logico di istanze e dati è invariato: c’è obbligatoriamente un front-office, che riceve l’istanza, ne verifica la completezza formale, rilascia la ricevuta, trasferisce l’istanza e successive integrazioni agli enti coinvolti (non si fa distinzione fra back-office SUAP e back-office di altri enti), mostra al richiedente lo stato di avanzamento e gli consente l’accesso alla documentazione.

Funzioni e requisiti dei back-office (di SUAP e enti terzi) non sono espresse in modo perentorio, si parla genericamente di “collegamenti fra SUAP e altri enti”, con un dettaglio nell’art. 10 (“Specifiche tecniche per la cooperazione tra Enti”) che, in una pagina, spiega come comporre i messaggi PEC (Posta Elettronica Certificata). La presenza di un un back-office inteso come componente informatico autonomo non è proprio prevista, non è un obbligo.

Lo scambio di dati è affidato al Sistema pubblico di connettività e alla (famigerata) Porta di dominio[16]Sistema pubblico di connettività (SPC) e Porta di dominio sono due entità che a lungo hanno animato la narrazione della trasformazione digitale della pubblica amministrazione italiana, senza però … Continue reading. Questo nella teoria, perché la frase ricorrente è “nelle more della definizione dei relativi accordi, [le comunicazioni sono inviate] tramite PEC“.

Qui veniamo quindi alla situazione reale: nel mondo attuale la comunicazione fra i soggetti coinvolti nel processo SUAP avviene principalmente via PEC. I motivi principali (fra loro collegati) sono, ricordiamolo: assenza di software di back-office e, mancanza di uno standard di interoperabilità, riferimento al Sistema Pubblico di Connettività mai veramente partito in maniera diffusa.

L’impresa si rivolge in prima battuta al Portale (camerale) o al “Sito istituzionale SUAP” (così si chiama un front-office diverso da Impresa in un giorno), per la presentazione dell’istanza. Da lì in avanti, però, complici i limiti strutturali della PEC, le comunicazioni fra i soggetti coinvolti possono viaggiare su canali diversi.

Di sicuro Impresa in un giorno trasmette l’istanza al SUAP comunale[17]Il SUAP comunale potrebbe anche scaricarsela dal back-office di Impresa in un giorno. e agli enti coinvolti tramite PEC[18]Anche più di una quando i file da inviare sono tanti, con conseguente difficoltà di gestione per chi riceve e, magari, ha la velleità di protocollare l’istanza: un protocollo per ogni PEC? … Continue reading.

Anche le comunicazioni fra SUAP comunale ed enti terzi avvengono via PEC. Se si usa Impresa in un giorno, di norma, il SUAP dovrebbe caricare le comunicazioni sul portale camerale e dare il comando di inviarle. In questo modo parte una PEC dalla casella della Camera di Commercio dedicato allo scopo. Talvolta però un ufficio comunale preferisce confezionare in proprio una comunicazione e farla partire in autonomia dalla PEC comunale piuttosto che comunicare il contenuto della comunicazione al SUAP comunale perché predisponga a sua volta una comunicazione e la carichi sul Portale per poi farla partire dalla PEC della Camera di Commercio (risulta difficile biasimare l’ufficio che lo fa, anche se non si attiene alle regole SUAP).

Gli enti rispondono via PEC, indirizzando alla casella PEC camerale un messaggio da confezionare (sempre a mano) con una certa sintassi per oggetto[19]Poiché mediamente l’oggetto della PEC coincide con quello della precedente registrazione di protocollo, già qui si crea un conflitto: l’oggetto richiesto dalla istruzioni è utile per … Continue reading e corpo del messaggio. La PEC viene poi processata dalla Camera di Commercio (non si sa quanto in modo automatizzato e quanto con intervento umano) e il contenuto della comunicazione aggiunto ai documenti della pratica sul Portale, a uso del richiedente e degli altri enti.

Se il SUAP usa un portale diverso (regionale o commerciale), le comunicazioni con gli enti terzi avvengono tout-court via PEC, risultando abbastanza difficile obbligare gli enti a collegarsi al front-office comunale o a sviluppare integrazioni ad hoc verso i loro software di back-office (che spesso non esistono proprio).

In definitiva, la mancanza di una comunicazione via API realizzabile (e di tutti i suoi prerequisiti) costringe a virare sulla PEC lo scambio di dati anche voluminosi[20]Curioso quanto indicato da un ulteriore decreto interministeriale del 2011 per trattare file troppo grandi: consegnarli direttamente al SUAP su una chiavetta! Questa indicazione sopravvive anche … Continue reading. I problemi operativi che ne scaturiscono determinano il divario fra la teoria delle regole e la situazione reale. In particolare, determinano anche il mancato sviluppo di soluzioni di back-office presso uffici ed enti terzi: se i documenti vanno trasferiti manualmente dal protocollo informatico al software di back-office (e ritorno) e se bisogna fare operazioni di data-entry (ancora manuali), tanto vale lavorare al di fuori di un software strutturato. Oppure, come già detto, meglio lavorare all’interno del sistema di gestione documentale e usare quello come back-office, organizzando le pratiche in fascicoli, relazionando documenti di richiesta e documenti di risposta ecc. Purtroppo si continua diffusamente a vedere il protocollo informatico e il sistema di gestione documentale con un orpello burocratico fastidioso e non come uno strumento di lavoro universale, per qualsiasi tipo di procedimento [21]La scarsa sensibilità archivistica è propria anche chi elabora specifiche di comunicazione di dati e documenti per domini specifici che talvolta, come in questo caso, addirittura il sistema di … Continue reading.

Cosa cambia

Le nuove specifiche, quindi, oltre a fare ordine dal punto di vista informatico, sono un’occasione imperdibile per superare gli attuali blocchi all’efficiente digitalizzazione dei processi SUAP[22]Ricordiamolo: passare del tempo a mettere insieme un puzzle di una dozzina di PEC o scaricare da un sistema un file ZIP per poi scompattarlo e ricarica i file uno a uno in altro sistema, anche se lo … Continue reading e, almeno nei contesti in cui non si è investito per sviluppare soluzioni di interoperabilità particolari, ciò avrà ripercussioni significative (in positivo, si spera) sull’operatività quotidiana. Non si tratta di niente che non fosse già stato pensato, ma adesso ci sono tutti gli strumenti per arrivare allo scopo. Le regole del 2010 davano delle indicazioni ma non dettavano regole. Adesso le regole ci sono, chiare e complete.

Infatti, vale la pena sottolineare come il successo di una federazione di sistemi informatici che concorrono a un processo (in questo caso, il processo SUAP), sia determinato dalla definizione completa di strumenti di interoperabilità standard. Lo strumento di interoperabilità non è, infatti, solo la API di tipo REST di turno o l’XML che veicola i dati acquisiti tramite un modulo HTML. Ci sono condizioni di contorno fondamentali: si parte dalla indicazione precisa di ruoli e funzioni dei componenti del Sistema Informatico (chi fa cosa) e dalla descrizione dei flussi di lavoro (quando e se si fa qualcosa)[23]I flussi di lavoro, a loro volta, si descrivono con metodi standard. In questo caso diagrammi BPMN – Business Process Modeling and Notation e diagrammi di sequenza, a loro volta relazionati con … Continue reading, si passa dalla definizione rigorosa dei nomi delle entità coinvolte e di vocabolari controllati (che indicano quali valori possono assumere le entità), si arriva a schemi XML che veicolano i dati presentati nei moduli, realizzate sulla base di modelli unificati a livello nazionale (con possibili varianti regionali, governabili). Se manca anche solo uno di questi ingredienti il risultato non può funzionare, perché ci saranno sempre margini di discrezionalità che creano incomunicabilità.

Inoltre, – e non poteva essere altrimenti, ma allegato 1 e specifiche lo ribadiscono – i sistemi e le interfacce grafiche sono da realizzare seguendo tutte le indicazioni, le linee guida e le regole tecniche che lo Stato ha prodotto in tema di usabilità dei servizi online (esperienza utente), accessibilità (sia per gli utenti esterni che per gli operatori), riuso[24]Il riuso dei software è un’altra pagina gioia e dolori, talvolta scritta con i colori della contraddizione: l’allegato 1 versione 2023 ricorda che le componenti software commissionate da … Continue reading, interoperabilità tecnica e relativa sicurezza.

Tutto rose e fiori?

Le specifiche per la comunicazione di dati nei processi SUAP nella versione 2023 sono senza dubbio un bell’esempio di come si produce uno standard di comunicazione all’interno di un ecosistema articolato e complesso in cui si muovono attori distinti, per natura giuridica, ruoli e dotazione tecnologica. Questo dovrebbe essere chiaro da quanto fin qui esposto.

Già nei due precedenti articoli si sono però evidenziate criticità e storture più o meno marcata.

In primo luogo la scarsa attenzione alla gestione documentale e alla formazione dell’archivio a norma di legge. Si è detto: se il procedimento SUAP è in capo al comune, questo può anche appoggiarsi su strumenti tecnologici realizzati, condotti e messi a disposizione da Unioncamere ma procedimento e relativo fascicolo completo di tutti i documenti dentro sono sotto la responsabilità del comune, che ha il dovere di gestirli e mantenerli sotto il proprio controllo. In più, un portale (camerale, regionale o commerciale) passa, i documenti che gli abbiamo (improvvidamente) affidato in via esclusiva invece devono restare. Vanno passati nell’archivio comunale, c’è poco da fare. Oppure vanno trovate soluzioni alternative, che vadano anche a incidere sull’impianto normativo attuale e su secoli di pratica amministrativa e archivistica: non devono esserci tabù, se non insistere a nascondere la testa sotto la sabbia.

A corollario della scarsa attenzione documentale c’è anche la scelta di fondo assunta per la circolazione di dati e documenti: almeno dal 2000 la norma stabilisce che i documenti di tutti i procedimenti circolano fra le amministrazioni partecipanti tramite i sistemi di gestione informatica dei documenti, in modo agnostico rispetto alla materia del procedimento. Qui si sceglie di usare come punto di smistamento la componente back-office SUAP senza però prescrivere alcun tipo di rigore documentale[25]Nello stesso periodo, un analogo intervento di definizione di regole di digitalizzazione del mondo dei contratti pubblici, quanto meno, ha elaborato la foglia di fico della “costituzione di un … Continue reading. Dobbiamo prendere questo percorso come un esercizio di avvicinamento oppure, piuttosto, come una deriva ormai non recuperabile che fa tramontare l’ipotesi (mai rinnegata dalle autorità centrali e dal legislatore) di rendere il sistema di gestione documentale, cioè l’archivio, il fulcro della cooperazione fra amministrazioni e dell’interoperabilità di dati e documenti? Personalmente propendo, con rammarico, per il “piuttosto”. Che se ne prenda atto e si elaborino strategie alternative per non disperdere il patrimonio informativo e documentale pubblico.

La centralità del sistema di gestione informatica dei documenti, comunque, non è solo un vezzo degli archivisti o il desiderio di affermare la supremazia di un approccio rispetto a un altro. Detto che comunque è ciò che dice la legge, pensiamo anche agli aspetti operativi. Anche in ambito SUAP, tutti i soggetti coinvolti [26]Da una personale e sommaria indagine gli enti terzi ricorrenti nelle pratiche SUAP sono: province e città metropolitane, aziende sanitarie locali, vigili del fuoco, camere di commercio e … Continue reading sono dotati sicuramente di un sistema di gestione documentale. Potrebbero invece non avere software di back-office specifici e, in taluni casi, la scelta di dotarsene potrebbe anche rivelarsi antieconomica o disfunzionale, soprattutto per quegli enti per i quali i procedimenti SUAP-correlati sono residuali rispetto alle funzioni istituzionali principali, alle quali si dà ragionevolmente priorità anche per interventi di trasformazione digitale. Perché allora non investire per ampliare le funzioni dei sistemi di gestione documentale? Detto e ridetto: già solo introdurre nei sistemi metodi efficaci di supporto alla creazione delle aggregazioni documentali (fascicoli) e implementare pienamente i metadati previsti dall’allegato 5 alle Linee guida sul documento informatico migliorerebbe la qualità del lavoro e porrebbe le basi per la circolazione effettiva dei documenti fra amministrazioni, per tutti i procedimenti. I mezzi per farlo ci sarebbero…

Sul tema del back-office degli enti terzi alcune notizie istituzionali (qui e qui), citano incidentalmente, una “soluzione sussidiaria per gli enti terzi” la cui realizzazione è affidata a Unioncamere. Forse che il portale “Impresa in un giorno” offrirà funzioni di back-office agli enti terzi che non hanno soluzioni autonome e ritengono non conveniente dotarsene? Lo farà anche nel caso in cui il SUAP di riferimento adotti un front-office SUAP diverso? Sono domande che, almeno per me, restano in sospeso.

Altro punto interrogativo è il ruolo che avrà la Piattaforma Digitale Nazionale Dati (PDND) nel flusso di comunicazione di dati nei processi SUAP. La PDND è uno strumento nuovo, di fatto ancora inutilizzato e messo sotto reale pressione. Già le prime esperienze ne stanno mostrando alcuni limiti operativi. Basti pensare al meccanismo degli accordi di fruizione da raggiungere punto-punto senza possibilità di accordi aggregati e al proliferare nel catalogo di e-service tutto sommato “tecnici” di scarso interesse per chi si trova a sfogliarlo.

Senza scendere in dettagli tecnici sarebbe auspicabile che per far funzionare il Sistema Informatico degli Sportelli Unici si pubblicasse uno e uno solo e-service sul Catalogo PDND: quello del Catalogo del Sistema Informatico degli Sportelli Unici. Gli enti coinvolti nei processi SUAP fanno accordo di fruizione per quello ed è poi il Catalogo a prendere in carico ulteriori adempimenti quali l’identificazione certa di mittente e destinatario (funzione di identity provider) e l’instradamento delle comunicazioni da un soggetto all’altro. Tuttavia, apparentemente, il modello di uso della PDND che si sta affermando sembra esigere comunicazioni dirette e non intermediate anche all’interno di ecosistemi di comunicazione “molti-a-molti“. Questo comporta che si debbano raggiungere “molti alla seconda” accordi di fruizione (lato giuridico-amministrativo), che si portano dietro “molti alla seconda” definizioni di finalità e valutazioni di impatto sulla protezione dei dati personali, “molti alla seconda” chiavi crittografiche da caricare e pubblicare sulla PDND…

Infine, è apparentemente singolare che anche l’interoperabilità interna sembra dover passare dalla PDND: in pratica, un comune fa un accordo di fruizione con se stesso per far passare dati e documenti dal software SUAP al software dell’Ufficio ambiente o a quello dell’Ufficio occupazione suolo pubblico (dove ci sono, si intende, sia gli uffici che i software!)…

Prossimamente

  • Cosa fare: indicazioni sui passi che attendono i comuni e gli altri attori coinvolti.
  • Finanziamenti: considerazioni sulla preannunciata erogazione ai comuni di contributi a valere sul PNRR.

Immagine rielaborata da Moondance da Pixabay

Note

Note
1 Ci torniamo, non è il numero di protocollo.
2 Le amministrazioni partecipanti chiedono l’integrazione con la mediazione del SUAP comunale.
3 Per acquisire dati relativi allo specifico procedimento, tramite PDND s’intende.
4 Di fatto il sistema ComUnica è un ulteriore punto di ingresso per alcune istanze, le SCIA (Segnalazione Certificata di Inizio Attività) che sono consegnate al Registro delle imprese contestualmente alla cosiddetta “Comunicazione unica (di registrazione di un’impresa)”, disciplinate dall’articolo 9 del decreto-legge 31 gennaio 2007, n. 7. Tramite il sistema ComUnica le SCIA arrivano al SUAP competente e “seguono lo stesso giro” di quelle presentate direttamente al SUAP.
5 L’unico riferimento a funzioni del back-office di supporto agli operatori è nelle specifiche tecniche (paragrafo 3.2), “per la verifica di procedibilità delle istanze presentate”. L’indicazione è piuttosto vaga ma lascia più pensare a qualche controllo di completezza formale.
6 ”Al fine di salvaguardare gli investimenti effettuati dai soggetti interessati, per le sole implementazioni già realizzate alla data di pubblicazione delle presenti specifiche tecniche, è ammessa la possibilità di realizzare sistemi informatici che implementano in maniera integrata le componenti informatiche Front-office SUAP e Back-office SUAP.”
7 C’è da sperare che questa deroga sia intesa per quello che è e non sia invece presa come giustificazione per non sviluppare le API di comunicazione con le altre componenti. Le uniche API che, apparentemente, una soluzione integrata non deve realizzare sono quelle di comunicazione fra front-office e back-office SUAP, perché in quel caso i due componenti condividono nativamente il database (dati e documenti).
8 Ricordo: il flusso informatico prevede che il back-office SUAP avvisi il back-office dell’ente terzo che c’è una istanza e poi il back-office dell’ente la preleva, evidentemente per le parti di interesse.
9 I dati sui pagamenti spettanti confluiscono nel Catalogo del Sistema Informatico degli SPOrteli Unici e consentono alla componente front-office, in fase di compilazione e perfezionamento dell’istanza, di raccogliere – tramite pagamenti pagoPA – tutti i pagamenti dovuti agli enti interessati. Per gli appassionati di pagoPA sarebbe interessante capire con quali strumenti messi a disposizione della piattaforma sono raccolti i pagamenti, visto che le opzioni sono diverse: pagamento multibeneficiario o pagamenti distinti verso ogni ente (con le conseguenti differenze in termini di implementazione e di configurazioni).
10 Ammetto che risulta difficile dare concretezza a questo requisito, anche perché la ratio di fondo è che con il richiedente interagisca il SUAP e solo il SUAP.
11 ”Come il protocollo informatico!” – esclamò qualcuno dall’ultimo banco. Non anticipiamo, però, tutto sommato… niente esclude che il back-office possa essere il protocollo informatico. Pensiamo il caso di una SABAP – Soprintendenza Archeologia, Belle Arti e Paesaggio che magari non ha un software ad hoc per rilasciare pareri sui colori delle facciate in centro storico ma scrive solo lettere. Peccato però dover implementare nel sistema di gestione documentale delle API settoriali e non generiche, che invece servirebbero come il pane…
12 Anche una ricerca testuale per “pagoPA” o “paga*” non fornisce alcun risultato.
13 Questi includono l’elenco di procedimenti amministrativi attivabili presso ciascun ente, il modulo digitale da usare, gli allegati da presentare, l’ufficio dell’ente da coinvolgere ecc. Fra le altre informazioni, ovviamente, c’è anche il “riferimento telematico” della componente informatica: dovrebbe trattarsi dell'”indirizzo” al quale raggiungere i servizi (API) esposti. Si è detto, le regole per chiamare i servizi, secondo le specifiche, sono standard, uguali per tutti, quello che varia è proprio l’indirizzo a cui rivolgersi.
14 L’allegato 1 versione 20210 si addentrava anche in dettagli tecnici, oggi demandati alle apposite specifiche e alla modulistica.
15 La situazione è comune ad altri ambiti, ma, quando si parla di trasformazione digitale, talvolta si ha l’impressione che il legislatore di turno dia sempre per scontato che tutto ciò che è stato scritto dal legislatore che lo ha preceduto sia concretamente applicato e diffuso, testato e gradito. Talvolta basterebbe affacciarsi un attimo fuori della porta e vedere come gira il mondo… Per esempio, il “Sistema di gestione deleghe” sta da qualche anno sul CAD: qualcuno lo ha mai visto? Per tacere del “Sistema pubblico di ricerca documentale”…
16 Sistema pubblico di connettività (SPC) e Porta di dominio sono due entità che a lungo hanno animato la narrazione della trasformazione digitale della pubblica amministrazione italiana, senza però mai decollare veramente. Il SPC, nel tempo, ha perso la sua fisicità infrastrutturale e si è, ragionevolmente, ridotto a un insieme di regole e specifiche di comunicazione che viaggiano su internet. A me personalmente, poi, già il nome “Porta di dominio” evoca artefatti immaginifici quali il “Mastro di chiavi” e il “Guardia di porta” della versione cinematografica di Ghostbusters degli anni ’80: che poi tutto torna, una delle frasi ricorrenti del film è “non incrociare i flussi” perché avvengono cose terribili, proprio quando gli archi del diagramma di un flusso di lavoro si incrociano troppo spesso…
17 Il SUAP comunale potrebbe anche scaricarsela dal back-office di Impresa in un giorno.
18 Anche più di una quando i file da inviare sono tanti, con conseguente difficoltà di gestione per chi riceve e, magari, ha la velleità di protocollare l’istanza: un protocollo per ogni PEC? Protocollo la prima e forzo manualmente l’aggiunta degli allegati mancanti? Tutta da fare “a mano” comunque.
19 Poiché mediamente l’oggetto della PEC coincide con quello della precedente registrazione di protocollo, già qui si crea un conflitto: l’oggetto richiesto dalla istruzioni è utile per il processamento automatico (più o meno) ma ben poco significativo a fini archivistici.
20 Curioso quanto indicato da un ulteriore decreto interministeriale del 2011 per trattare file troppo grandi: consegnarli direttamente al SUAP su una chiavetta! Questa indicazione sopravvive anche nelle nuove regole di comunicazione, come ruota di scorta in caso di sistemi non funzionanti e, ancora, di file troppo troppo grandi… Il decreto è del 10 novembre 2011 ed è firmato dal Ministro dello sviluppo economico e dal Ministro per la semplificazione normativa. Ecco se ci si fermasse un attimo a ragionare a quanto (per nulla) semplifichi la vita (lavorativa) ricevere una chiavetta piena di file…
21 La scarsa sensibilità archivistica è propria anche chi elabora specifiche di comunicazione di dati e documenti per domini specifici che talvolta, come in questo caso, addirittura il sistema di gestione documentale evita del tutto di considerarlo, come se non esistesse proprio!
22 Ricordiamolo: passare del tempo a mettere insieme un puzzle di una dozzina di PEC o scaricare da un sistema un file ZIP per poi scompattarlo e ricarica i file uno a uno in altro sistema, anche se lo si fa seduti a un PC, non è digitalizzazione, ma macabro senso dell’umorismo.
23 I flussi di lavoro, a loro volta, si descrivono con metodi standard. In questo caso diagrammi BPMN – Business Process Modeling and Notation e diagrammi di sequenza, a loro volta relazionati con le “operazioni” informatiche abilitate dalle API.
24 Il riuso dei software è un’altra pagina gioia e dolori, talvolta scritta con i colori della contraddizione: l’allegato 1 versione 2023 ricorda che le componenti software commissionate da pubbliche amministrazioni dovranno essere realizzate come open source e messe a riuso. Si stanno preparando contributi PNRR destinati alle amministrazioni per adeguare i propri componenti informatici, con avvisi che faranno tesoro anche delle interlocuzioni che i ministeri coinvolti hanno intrattenuto con gli sviluppatori di software a uso del SUAP. Dobbiamo attenderci di vedere pubblicato come open source il codice sorgente di tutte le soluzioni commerciali attuali?
25 Nello stesso periodo, un analogo intervento di definizione di regole di digitalizzazione del mondo dei contratti pubblici, quanto meno, ha elaborato la foglia di fico della “costituzione di un fascicolo di gara” e di una generica “predisposizione per il suo invio in conservazione a norma”, passando anche un meglio precisato codice identificativo per legarlo al piano di classificazione e fascicolazione della stazione appaltante.
26 Da una personale e sommaria indagine gli enti terzi ricorrenti nelle pratiche SUAP sono: province e città metropolitane, aziende sanitarie locali, vigili del fuoco, camere di commercio e soprintendenze.
Condividi

Lascia un commento

Il tuo indirizzo email non sarà pubblicato. I campi obbligatori sono contrassegnati *