Rappresentazione dei dati in formato XML

Pubblicato sul sito di Pubblicaamministrazione.net

Analisi dell’evoluzione dei dati, dei documenti e dei processi informativi della Pubblica Amministrazione Locale

In Italia, come in altri paesi, vi è una grande attenzione alla diffusione della concorrenza a vantaggio di un mercato più trasparente e chiaramente favorevole agli utenti. Con l’obiettivo di ridurre la “dipendenza” da un particolare fornitore, le Autorità agiscono cancellando tutti quegli elementi capestro che contribuiscono a legare clienti a fornitori. Abbiamo casi lampanti in ogni settore: l’eliminazione delle penali in caso di cambio di mutuo, l’ereditarietà della classe di rischio in caso di cambio assicurazione, ecc. Sono tutti interventi che di fatto riducono il danno derivato dal cambio di fornitore, ottenendo come risultato una maggiore apertura del mercato.

Nel mondo dell’informatica della Pubblica Amministrazione questa logica non trova terreno fertile, soprattutto per quanto riguarda i software per la gestione di funzioni istituzionali: servizi demografici, segreteria e atti amministrativi, contabilità e bilancio, ecc. Ogni fornitore organizza a suo modo la gestione del dato, il che genera una serie di spiacevoli conseguenze per chi vuole cambiare applicativo:

  • il costo di migrazione della banca dati pregressa è una barriera all’ingresso non indifferente, spesso superiore al costo dell’applicativo stesso. Sovente il vecchio fornitore vince comunque la gara di nuova fornitura perché non deve affrontare questo costo;
  • chiaramente i fornitori hanno imparato come migrare le banche dati della concorrenza, ma l’operazione non sempre va a buon fine e il rischio di perdere qualche informazione non è basso;
  • chi non si sente di migrare la banca dati mantiene il vecchio applicativo in consultazione, spesso relegandolo sul vecchio server (anche migrarlo ad un nuovo server avrebbe il suo costo…), con costi di gestione forse non espliciti ma sicuramente non insignificanti e un alto rischio di perdere i dati e non poterli più recuperare (se non a fronte di forti emolumenti da corrispondere alla vecchia software house).

Qualcuno sostiene che questo fenomeno è inevitabile, a causa della complessità delle informazioni gestite e della difficoltà di elaborare degli standard di gestione delle banche dati a cui le software house dovrebbero adeguarsi. Ma è veramente così? In realtà no. In realtà è assolutamente vero che ci vorrebbero anni e cospicue risorse per elaborare una struttura dati standard per questi applicativi, ma è altrettanto vero che non è necessario. Questo perché non ci si deve fossilizzare sull’organizzazione dei dati, bensì ci si deve focalizzare sulle modalità di rappresentazione: le normative varie obbligano già a rappresentare questi dati secondo standard diffusi, che potrebbero essere utilizzati tranquillamente come “punto franco” per passare i dati da un’applicazione ad un’altra. Le informazioni sono rappresentate in un formato predisposto per l’interscambio trasparente tra applicazioni, attraverso l’utilizzo del formato XML.

La rappresentazione dei dati in formato XML consente di racchiudere all’interno di un file non solo i dati, ma anche le regole e le “etichette” (in gergo tecnico denominate “marcatori”) per rappresentarli. È più facile spiegarlo con un esempio:

I marcatori (, , , ecc) sono le proprietà identificative dei dati, che descriveranno i valori che gli elementi possono assumere. L’evoluzione dei sistemi informatici e la necessità di fare interagire sistemi differenti hanno di fatto definito un insieme di standard XML per la rappresentazione dei principali dati di un Ente, standard che le software house hanno dovuto necessariamente implementare. Mancano sicuramente dei dettagli, ma soprattutto manca una visione di insieme su ciò che già c’è. Vediamo degli esempi.

Protocollo informatico: sembra incredibile, ma le migrazioni dei dati di protocollo sono viste come il fumo negli occhi da parte delle software house. Eppure i dati sono pochi, semplici e sono indicati nel DPR 445/2000: mittente, destinatario, oggetto, data, numero di protocollo e altri dettagli. Le normative obbligano già le software house a rappresentare questi dati secondo standard diffusi; i software di protocollo informatico devono consentire l’interoperabilità, cioè un sistema di interscambio che consenta a mittente e destinatario di scambiarsi in maniera automatizzata i dettagli del messaggio attraverso un file XML. Un altro elemento importante è la spinta alla dematerializzazione, che prevede la creazione del registro giornaliero informatico (di solito viene creato un file pdf con la lista dei protocolli giornalieri). Se si producesse il registro giornaliero con un file XML che utilizza le regole dell’interoperabilità, avremmo già creato uno strato di dati facilmente leggibile ed esportabile verso altri applicativi.

Servizi demografici: gli applicativi dell’anagrafe di fatto gestiscono delle informazioni, storicizzandole, che in passato venivano riportate sul cartellino di famiglia. La struttura di un cartellino di famiglia potrebbe facilmente essere riportata in un file XML, in cui riportare i dati anagrafici dei singoli componenti. All’interno del file si potrebbe poi riportare ogni variazione dello stato di famiglia, indicando modifiche, cancellazioni e inserimenti tramite una sintassi facilmente definibile. Anzi, è già in stato avanzato di definizione: basti pensare al tracciato AP5 che i fornitori di software hanno dovuto predisporre per i flussi INA/SAIA. In tal modo, si costruirebbero gli equivalenti informatici degli attuali cartellini di famiglia, elementi leggibili da qualsiasi applicazione che potrebbe facilmente importare tali dati nella propria struttura. Per quanto riguarda la parte di stato civile si deve inoltre rilevare un progetto di digitalizzazione degli archivi di stato civile a cui si sta già lavorando da qualche anno: al momento sta ancora affrontando le problematiche relative alla conservazione dei documenti informatici, ma la sintassi per la gestione degli archivi informatizzati è già stata definita utilizzando il formato XML per la rappresentazione dei dati.

Contabilità e bilancio: per quanto riguarda contabilità e bilancio, l’organizzazione dei dati nel DB è di competenza della software house. Tuttavia, ci sono già delle regole nella gestione dei dati in ingresso e in uscita, ed altre stanno per essere definite: nella finanziaria 2008 si sono poste le basi per la gestione delle fatture verso la PA in forma esclusivamente elettronica (tramite files in formato XML, naturalmente), la SOGEI sta implementando il sistema di interscambio con cui le fatture verranno inoltrate alle amministrazioni destinatarie. Un altro passo importante è stato fatto con la rilevazione telematica degli incassi e dei pagamenti tramite il Sistema Informativo delle Operazioni degli Enti Pubblici (SIOPE), per cui i dati delle operazioni sono classificati secondo codici uniformi su tutto il territorio nazionale. Infine, il progetto relativo all’introduzione dell’Ordinativo Informatico Locale (OIL) completerà l’automazione dei processi che alimentano il SIOPE, standardizzando i rapporti tra banche tesoriere ed Enti Locali tramite il passaggio di file in formato XML.

Sicuramente gli standard XML già definiti non costituiscono la panacea di tutti i mali, ma sono un ottimo punto di partenza per definire delle modalità di rappresentazione delle informazioni con cui superare il limite della migrazione dei dati e svincolarsi dai fornitori tecnologici. Detto questo, c’è una grande sottovalutazione di un problema riguardante i processi di gestione documentale nelle PA: al momento si dà un grande risalto alla loro dematerializzazione, grazie anche alla possibilità di allestire degli iter informatizzati per la gestione di pratiche amministrative. Quello che non si è considerato è che ogni software house sta implementando questi iter automatizzati secondo un proprio standard, che non è assolutamente esportabile in altri ambienti applicativi. Questo significa che, in caso di cambio di software, tutti gli iter automatizzati implementati andranno irrimediabilmente persi.

Il problema è duplice: in primo luogo i documenti informatici creati col vecchio applicativo saranno ancora disponibili, ma la loro gestione e interconnessione non sarà affatto semplice, poiché creati all’interno di iter che non sono di fatto più ricostruibili col nuovo applicativo. In secondo luogo, tutti i singoli passaggi relativi a un procedimento che sono stati “mappati” tramite un software di gestione documentale saranno visualizzabili solo con questo software (e non con altri). Di fatto, la mancanza di uno standard nazionale che indichi come costruire un iter informatizzato e come registrare i singoli passaggi secondo una codifica uniforme mette gli Enti nelle mani delle software house: si stanno poggiando le basi della futura gestione documentale della PA su una piattaforma galleggiante.

Come uscire da questa situazione? Anzitutto occorre estendere le basi dell’archivistica alle nuove frontiere della gestione documentale: fino ad ora la relazione fra documenti era realizzata attraverso l’associazione di questi a un fascicolo, che li raggruppava e ne sanciva il “nesso archivistico” riferendoli ad uno stesso procedimento amministrativo (l’appartenenza ad un fascicolo associava indirettamente un documento a tutti gli altri documenti che ne facevano parte). Nella nuova dimensione della gestione documentale l’iter di un procedimento ha la stessa importanza dei documenti creati, per cui occorrerà definire degli standard per la rappresentazione dei singoli passi dell’iter stesso. Anche in questo caso, XML è lo strumento adatto per costruire uno standard adeguato.

Un altro punto importante è l’interconnessione tra le informazioni contenute nei singoli archivi e documenti: una volta rappresentati i dati dei vari applicativi secondo standard XML, non è difficile pensare che questi standard utilizzeranno gli stessi marcatori per elementi comuni (es. , , , ecc), per cui sarà facile incrociare dati provenienti da fonti diverse, costruendo nuove aggregazioni di informazioni più complete, convergenti e strutturate. In conclusione, l’evoluzione dei sistemi informativi della PA deve passare attraverso un processo di standardizzazione delle informazioni, un processo che deve essere necessariamente pilotato da un’autorità che abbia le risorse, le conoscenze e il potere normativo necessari per gestirlo. Il CNIPA è l’unica autorità in grado di gestire tale processo, ma è necessario che lo faccia in tempi brevi, ne va della solidità dei futuri processi di gestione delle informazioni e dei documenti della PA.

Annunci

Pubblicato il 25 febbraio 2009, in Nella Rete con tag , . Aggiungi il permalink ai segnalibri. Lascia un commento.

Rispondi

Inserisci i tuoi dati qui sotto o clicca su un'icona per effettuare l'accesso:

Logo WordPress.com

Stai commentando usando il tuo account WordPress.com. Chiudi sessione / Modifica )

Foto Twitter

Stai commentando usando il tuo account Twitter. Chiudi sessione / Modifica )

Foto di Facebook

Stai commentando usando il tuo account Facebook. Chiudi sessione / Modifica )

Google+ photo

Stai commentando usando il tuo account Google+. Chiudi sessione / Modifica )

Connessione a %s...

%d blogger hanno fatto clic su Mi Piace per questo: