Piattaforma Notifiche Digitali: è anche una questione matematica di sostenibilità

Torno sul tema d’attualità delle scelte logico-architetturali dell’implementazione della Piattaforma notifiche digitali (PND) nel sistema informativo di un ente pubblico (diciamo pure un comune). Ripeto un concetto già espresso: non si tratta di aggiungere un pezzo al sistema ma di adeguare un intero processo, che produce documenti, un debito da pagare e un’esigenza di notifica (o spedizione).

Qualche giorno fa su Linkedin ho chiesto di fornire qualche schema alternativo a quello più volte proposto su queste pagine e condiviso anche durante il webinar “Bussole digitali”, magari uno che escludesse la centralità del sistema di gestione documentale o che riducesse il numero di frecce,, cioè di connettori, fra le componenti del sistema informativo. Non ho ricevuto proposte alternative. Anzi, ho ricevuto qualche suggerimento per completare e ampliare quello proposto: aggiungere la fascicolazione e la conservazione a norma dei documenti prodotti. Ne è uscito un diagramma aggiornato:

Nel diagramma:

• la fascicolazione è un’attività contestuale alla registrazione nel sistema di gestione documentale;
• la conservazione è un’attività che, successiva alla corretta gestione, non può che essere condotta a partire dal sistema di gestione documentale e riguarda tutti i documenti ivi memorizzati e gestiti, a prescindere dal loro processo di formazione ed eventuale trasmissione all’esterno.

Sostenibilità: il problema matematico

Nel diagramma compare un unico software che produce output documentale con esigenze di pagamento e notifica. Nel sistema informativo software con tali esigenze sono certamente più di uno. Se pensiamo alla sostenibilità del sistema informativo, non si può che chiedersi cosa succede applicando la stessa logica a più software. In altri termini, quanti connettori sono da sviluppare e mantenere per consentire di notificare via PND e attualizzare gli importi dei pagamenti a partire da ciascun software?

Se quindi chiamiamo n il numero di software con esigenze di pagamento e notifica nel sistema informativo, la domanda è: per ogni logica di implementazione della PND, che relazione c’è fra il numero di connettori totali e il numero n di software?

Se nello schema proposto inseriamo gli n software ed evidenziamo con frecce bidirezionali i connettori fra componenti distinte, si ottiene la seguente situazione:

Per fare un confronto, vista la mancanza di proposte alternative prodotte dalla comunità, si può ipotizzare una logica implementativa in cui ogni software con output documentale ed esigenze di notifica e pagamento “faccia ente a sé” e si interfacci direttamente con PND, Nodo dei pagamenti SPC di pagoPA, sistema di conservazione a norma e sistema di contabilità dell’organizzazione. Ne esce un diagramma come segue:

Dovrebbe essere chiaro che, così come descritta, questa soluzione non è accettabile a meno di ulteriori accorgimenti (che la renderebbero accettabile ma poco ragionevole). Non è una soluzione accettabile perché:

1. frammenta l’archivio^[1]”Frammentare l’archivio” è in realtà un ossimoro. L’archivio è unitario per definizione, se lo si frammenta non c’è più archivio…, a meno che tutti i software che “si tengono documenti in pancia” non applichino le stesse logiche e misure del protocollo informatico, quanto a garantire sicurezza, integrità, immodificabilità e affidabilità in genere dei documenti. Siccome il sistema documentale deve comunque essere unico^[2]Lo dice il CAD, lo dice la ISO 15489, lo dice MoReq… manca comunque un ulteriore pezzo al sistema informativo che consenta di ricercare e raggiungere i documenti sparsi in qua e in là^[3]Dotati, fra l’altro, tutti dello stesso set di metadati, quelli stabiliti dell’organizzazione come prescrivono le linee guida AgID e la ISO 23081 (sui metadati)… a partire da un’unica interfaccia (questo implica aggiungere altri n connettori);
2. non consente di creare i fascicoli e, quindi , rende difficoltoso se non impossibile lavorare e documentare l’azione amministrativa e, al contempo, viola qualche obbligo di legge, come l’art. 41 del CAD o le norme discendenti dalla l. 241/1990 che richiedono partecipazione e accesso telematici dell’interessato al procedimento;
3. frammenta i pagamenti pagoPA nei sistemi di più intermediari/partner tecnologici, rendendo difficile creare una posizione debitoria unica complessiva a livello di ente per cittadini e imprese (anche qui, se volessimo recuperare l’unitarietà della posizione debitoria servirebbe un sistema che interroghi e raccolga le posizioni debitorie dagli n software, con altri n connettori da considerare).

Nonostante il fatto che lo scenario alternativo proposto non sia conforme alla normativa, possiamo comunque prenderlo come termine di paragone, anche perché, purtroppo, è una situazione che esiste nel panorama della pubblica amministazione.

Sostenibilità: un confronto (matematico)

Contiamo i connettori per ognuno dei suoi scenari. Per comodità ne evidenziamo anche gli scopi.

Scopo	N. di connettori per soluzione “sana”	N. di connettori per soluzione “patologica”
Gestione documentale	n	non gestita
Gestione della posizione pagoPA	n	non gestita
Interazione con PND	1	n
Interazione con Nodo pagoPA	1	n
Conservazione doc.le a norma	1	n
Contabilità (rendicontazione)	1	n
	2n + 4	4n

Alcuni connettori, in entrambe le soluzioni, esistono già da prima della PND. Ma qui ci interessa valutare la sostenibilità del sistema informativo: mantenerlo semplice e con logiche uniformi e contenere il numero di componenti. Questo consente di governarlo con consapevolezza. Inoltre, ricordiamolo, un connettore è una spesa, un costo: basta scorrere i contratti in essere e le offerte. Ogni connettore ha un costo di sviluppo e configurazione e poi un canone di manutenzione, perché se ne deve garantire la continua funzionalità e va aggiornato quanto cambiano le specifiche, tanto di una piattaforma nazionale quanto di un sistema interno al sistema informativo.

Vediamo, quindi, cosa succede al variare di n, il numero di software che producono documenti da notificare.

N. di software (n)	N. di connettori per soluzione “sana”	N. di connettori per soluzione “patologica”
1	6	4
2	8	8
3	10	12
4	12	16
…	…	…
7	18	28
…	…	…

Non appena i software con i quali si producono documenti da notificare sono più di due, il paradigma patologico dell’interfacciamento diretto mostra inefficienza anche dal punto di vista della sostenibilità.

Si è detto sopra che il modello patologico potrebbe essere ricondotto a un comportamento accettabile aggiungendo altri due connettori per software. Si avrebbero quindi 6 connettori per software: n software, 6n connettori^[4]Ho dato per scontato che si sappiano leggere espressioni algebriche quali 2n, 4n, 6n come 2 moltiplicato per n, 4 moltiplicato per n ecc.. Già con due software il modello patologico coretto diventa meno efficiente, con quattro software si radoppia il numero di connettori.

Se si preferisce la comparazione grafica:

Conclusione

Se anche non siamo dei patiti dell’eleganza formale, se anche ci sembra che questa idea dell’archivio sia un anacronismo^[5]Qui dovrebbe partire l’invito a fare tre serie di venti flessioni per schiarirsi le idee, ma lasciamo perdere…, se anche “tanto le cose quando servono le trovo lo stesso”, se anche non vogliamo riconoscere che “le cose” devono stare insieme o almeno si deve essere in grado di raggrupparle all’istante a richiesta, se anche siamo dei pragmatici che mirano ad arrivare al sodo del risultato (e al bottino PNRR)… almeno la parte economica di quello che stiamo portandoci in casa ci tocca?

Certo, anche la strada meno efficiente non conduce alle pericolose crescite esponenziali a cui siamo tristemente abituati. Tuttavia, passata la sbornia PNRR, che tipo di (de)crescita ci possiamo attendere per il bilancio comunale e, soprattutto, per il budget assegnato alla trasformazione digitale?

Meditiamo, gente, meditiamo.

Foto di Pexels da Pixabay