Non avevo pensato ai comuni, la mia ottica è quella di una PA centrale, ma hai ragione. Per loro si dovrebbe prevedere il commissariamento dell’ente. So che è terribilmente pesante, ma se veramente la digitalizzazione è strategica, un interesse pubblico considerato preminente, lo deve diventare anche nei fatti e non solo a parole.
2 Mi Piace
hai perfettamente ragione. ti trovi a dover incaricare un’azienda comunque esterna per un minimo di manutenzione, spendendo di più. se si deve imporre il riuso, allora piuttosto imponiamo software nazionali obbligatori e finita lì, preparati sentendo le esigenze anche dei comuni piccoli (e non sempre solo Roma Torino Milano…). Ci avevo sperato un po’ con ANPR, ma sono disillusa. Per questo auspichiamo (in un altro post) almeno regole generali per le API e le webservices. starndard per il protocollo, standard per l’anagrafe …
1 Mi Piace
grazie del conforto.
Sarebbe interessante analizzare in dettaglio le soluzioni presenti nel catalogo del riuso.
Io ho sentore che ci siano due estremi:
- da un lato software sviluppati internamente a una pubblica amministrazione per scopi specifici propri che sono messi a disposizione per adattamento da parte di altri;
- software sviluppati da software house strutturate su commissione di una pubblica amministrazione.
Nel caso 1), per forza di cose, viene meno il servizio accessorio al software: installazione, configurazione, eventuali (spesso necessari) adattamenti, supporto per l’avvio e la conduzione (la p.a. che sviluppa per se’ non puo’, pragmaticamente, fare helpdesk ai riutilizzatori) oppure per l’addestramento all’uso. Quindi, o l’amministrazione che riusa ha in casa personale esperto di quella specifica tecnologia utilizzata oppure ci si arena…
Nel caso 2), la software house (dietro pagamento, immagino, come del resto prevedono le linee guida) offre i servizi accessori, dall’installazione alla personalizzazione, passando dalla formazione. Di fatto, non cambia molto rispetto a un software commerciale, semplicemente - opinione personale - i costi di licenza sono assorbiti nei costi di assistenza. Certo, se poi un’amministrazione ha al suo interno esperti di quella specifica tecnologia in grado di entrare a pieno osservando il codice nelle logiche di funzionamento si puo’ anche bypassare il fornitore (la cosiddetta manutenzione evolutiva pero’ resta in capo all’amministrazione riutilizzatrice).
Ripetendomi, penso che un caso a parte siano i “massimi sistemi”, tipo i nominati FSE o i Sistemi di conservazione. Sono presi in riuso da amministrazioni forti, dotate di strutture ICT tecniche solide o di partenariati con soggetti esterni specialisti e, in entrambi i casi il riuso, oltre ad abbattere i costi di parte di progettazione e sviluppo puo’ davvero consentire di migliorare le soluzioni adottate a beneficio di tutti.
É indispensabile in sede di gara richiedere lo sviluppo di interconnessioni e integrazioni specificando con quali software e mi permetto di aggiungere anche specificare un costo orario massimo per le varie figure di sviluppatori.
Il riuso non è da demonizzare anche se molto spesso è necessario affidare la ‘manutenzione’ alla ditta che ha sviluppato originariamente il software e la rotazione dei manutentori è nella pratica svantaggiosa per la pa.
1 Mi Piace
A proposito dei sw nazionali obbligatori, leggevo su Italia Oggi che c’è un disegno di legge che prevede un unico sw nazionale di contabilità per tutti gli enti locali. Vedremo…
1 Mi Piace
magari… ma vuoi mai che le software house non facciano un gran casino ? accadrà come per NoiPa che io non conosco, ma il mio ufficio personale non vuole nemmeno sentire nominare, oppure come per ANPR dove alla fine dev mantenere due canali con maggiori costi perchè devono anche essere allineati…
Infatti non è da demonizzare, ma spesso non è realmente conveniente
NoiPA è un work in progress, io sospendo il giudizio fino a quando non sarà ‘finito’. Comunque rispetto a quello che stiamo tuttora usando noi non credo che sarà peggio. Forse è meglio già ora (non conosco il lato gestione presente di NoiPA ma vedo le funzionalità del sw che usiamo attualmente, che credo sia un riuso andato non troppo bene), certo che dipende sempre da dove si parte per capire se il cambiamento è positivo o no. Immagino che i sw degli enti locali siano molto completi.
Io la ritengo una pessima notizia: molti enti locali hanno già un software gestionale integrato con tutte le procedure (anagrafe, tributi, tecnico, protocollo, determine, a volte sociale, scolastico ecc…), ed è estremamente utile la possibilità di trasferire e aggiornare dati e informazioni con diversi automatismi, che fanno risparmiare anche molto tempo … con un gestionale separato dis-integrato 
si tornerebbe indietro… invece di interferire nell’operatività degli EE.LL. non sarebbe meglio che si preoccupassero di integrare meglio gli applicativi statali/regionali che gli Enti sono costretti ad usare per interloquire con organi centrali e di controllo? Si continua a cambiare per il gusto di cambiare? Che fine fa lo storico, non sempre facile da importare/trascodificare?
1 Mi Piace
Per ANPR, una volta che la transizione fosse completata da tutti i Comuni, basterebbe prevedere che periodicamente (magari giornalmente) ciascuna Anagrafe comunale si connettesse ad un sistema di interscambio centrale aggiornato e scaricasse le novità (nel formato previsto, xml o quant’altro) per tenere sincronizzata in tempo quasi reale la banca-dati locale e quella nazionale. La procedura all’interno del gestionale comunale dei servizi demografici potrebbe essere così stringata al minimo; per ridurla ancora di più all’essenziale sarebbe necessario che ANPR contenesse tutte le informazioni di interesse demografico (non è pensabile non avere una anagrafe localizzata, per le necessità degli altri uffici, specialmente…).
In realtà sarebbe pensabilissima, se ANPR fosse completo di tutti i servizi che vengono svolti dagli uffici demografici (ma è ancora be lontano). Come si è già detto in qualche altro post, prima o poi la consultazione di ANPR dovrà essere aperta anche ad altri che non siano le anagrafi, con profili ben precisi a norma GDPR, in base alle competenze (tributi, PL, ecc) in realtà non accadrà mai e ANPR sarà sempre una copia dell’anagrafe comunale (o viceversa) e la gestione rimarrà sempre complicata.
1 Mi Piace
Se esiste una banca dati nazionale dovrebbe esistere solo quella, nessuna replica locale.
I software locali attingono i dati dalla banca dati centrale.
ANPR (che e’ una banca dati, non un software gestionale, eccezione fatta per la webapp con tutti i limiti del caso) non dovrebbe sfuggire a questo schema, tanto che raccoglie dati abbastanza importanti: cosa succede in caso di difformita’ fra banca dati centrale e copia locale?
2 Mi Piace
sono d’accordo al 100%.
vero è che è una banca dati e non un gestionale, ma l’unico modo di eliminare i gestionali locali sarebbe quello di “collegare” il gestionale a quella banca dati, ma questo le software house non lo vogliono fare se non sono obbligate per legge e preferiscono agire su una copia, seppure, si spera, allineata.
stessa cosa che fanno quasi tutti i fornitori quando si chiede di sviluppare un collegamento all’anagrafe… tendono sempre a chiedere uno scarico DALL’anagrafe per poi gestirselo come vogliono, piuttosto che sviluppare richieste puntuali di dati attraverso webservice come dovrebbero…
2 Mi Piace
Mah, in teoria hai ragione ma in pratica la vedo molto dura.
Gli EE.LL. non possono interrompere o rallentare la loro (spesso già lenta) attività. E io fatico ad immaginarmi un’infrastruttura capace di sopportare l’urto di così tante connessioni contemporanee. Ti immagini tutte le anagrafi d’Italia, tutti gli uffici tributi, tutti gli uffici scolastici, le regioni, i tribunali, le forze dell’ordine, i messi, gli uffici UNEP, i ministeri… che inviano query e estraggono variamente dati? Non è che si pianta tutto? Se ognuno replica la base dati sui suoi sistemi alleggerisce il carico di quello che altrimenti rischia seriamente di diventare un collo di bottiglia per tutta Italia. Se poi il sistema è dimensionato adeguatamente, ok.
I gestionali comunque non sono eliminabili perchè dopo aver attinto alla base dati fanno un’infinità di cose che ANPR non fa.
1 Mi Piace
Diciamo che una sincronizzazione periodica che riguardi solo le variazioni intercorse (non tutto tutto) caricherebbe meno il server centrale di ANPR con una banca dati ragionevolmente aggiornata in locale, rispetto che far collegare il mondo ad ANPR direttamente. In fondo, è vero che stiamo parlando di più di 7000 anagrafi che aggiornano le movimentazioni demografiche ogni giorno ma le variazioni non sono migliaia per ogni Comune… se si ipotizzasse una sincronizzazione giornaliera (magari automatizzata) il flusso di dati, dopo la prima sincronizzazione massiva, sarebbe minimo, tale da escludere quasi ogni possibile discrasia significativa. P.S. non dimenticando peraltro che non pochi Comuni hanno connessioni a internet inadeguate (es. montani, isolani, in altre zone a c.d. fallimento di mercato, dove nessun fornitore provvede a offrire pacchetti decorosi…).
Ho appena trovato questa discussione.
Molto interessante.
Da tempo sto lavorando ad una proposta di progetto che ha come fine quello di standardizzare le interfacce tra gli applicativi utilizzati internamente nella PA.
Il software di stato lo trovo la morte dell’evoluzione tecnologica.
Ho partecipato al progetto ANPR permettendo il subentro del primo comune italiano (Bagnacavallo). A mio avviso la strada da percorrere sono il web-services mediante interfacce stabilite e manutenute a livello centrale.
Finisco di leggere tutti i post e vi sottopongo la mia proposta.
2 Mi Piace
Buon pomeriggio ragazzi, molto interessante questo post e mi avrebbe fatto molto comodo trovarlo prima 
.
Pensavo di essere solo in questa battaglia, invece vedo che siamo in tanti ad essere sulla stessa linea d’onda.
Il tema della standardizzazione dell’integrazione tra applicativi di fornitori diversi ritengo che sia la chiave di volta per innescare un processo di concorrenza virtuosa tra fornitori, che velocizza il processo di evoluzione degli applicativi da loro gestiti e distribuiti. Questo significa che generebbe delle ricadute positive per i fornitori in grado di offrire applicativi ricchi di funzionalità ed al passo con i tempi.
La nuova modalità di acquisizione software SaaS di fatto amplifica l’esigenza di integrazioni in tempo reale, perchè si può avere il protocollo nel SaaS di un fornitore ed i demografici, le segreterie, ecc in altri SaaS ed è giusto che possano dialogare tra loro.
Da tempo ho predisposto una bozza di progetto che a questo punto mi sembra giusto condividere con voi, ecco il link StandardIntegrazioni_v01.3.pdf
3 Mi Piace
@Lazlu Negli anni si è provato a portare avanti dei progetti centralizzazione delle banche dati della PA, ma le problematiche organizzative e normative erano tante e tali che la soluzione di piattaforme nazionali separate ed interoperabili si è dimostrata di più facile realizzazione.
L’Anpr, PagoPA, SPID e CIE e le altre piattaforme che verranno come l’Anagrafe nazionale degli assistiti comunicheranno in maniera più semplice tramite il sistema di interoperabilità previsto dal DL Semplificazioni.
Qui trovate una sessione di ForumPA sul tema: https://forumpa2020.eventifpa.it/it/event-details/?id=9346
@RaffaeleF Per quanto riguarda gli standard, sono da poco state rilasciate:
2 Mi Piace
Grazie @Roberto_Polli . Sicuramente l’ipotesi di individuare più banche-dati settoriali accessibili ad accesso riservato è vincente e crea meno problemi di carico di elaborazione, di trasmissione-ricezione, di inserimento, modifica, consultazione. Un’unica banca-dati centrale onnicomprensiva è effettivamente problematica. Si spera che gli attuali limiti di accesso e problemi organizzativi e di applicazione pratica delle regole normative in materia di operabilità vengano superati presto. 
Grazie @Roberto_Polli. Le linee guida per l’interoperabilità, che avevo già avuto modo di vedere, iniziano con il concetto che “Il nuovo Modello di Interoperabilità rende possibile la collaborazione tra Pubbliche amministrazioni e tra queste e soggetti terzi”. Purtroppo trascurano l’aspetto dell’interoperabilità tra applicativi all’interno della stessa PA. Sebbene condivida il fatto che possano essere adottate anche tra applicativi interni alla PA, sarebbe a mio avviso bene specificarlo in modo da rendere più facile il nostro ruolo verso i fornitori che vedono da questo modello, al posto di un’opportunità, un rischio per il loro mercato, da cui proteggersi.
1 Mi Piace