[ Precedente ] [ Home ] [ Su ]

1 - Requisiti del Sistema del protocollo

In questa ultima parte dello speciale, vedremo il Sistema di Protocollo Informatico nel suo insieme, soffermandoci sulle norme del DPR 428/98 e del relativo "regolamento tecnico"  (RT) che ancora non abbiamo esaminato.

Ripetiamo ancora una volta che, nel momento in cui scriviamo, le norme del Regolamento Tecnico non sono ancora state approvate in via definitiva, e potrebbero quindi subire delle modifiche, che comunque non dovrebbero modificare la sostanza dei concetti riportati in questo speciale.

Riassumendo quanto abbiamo visto nelle parti precedenti, possiamo dire che ogni Pubblica Amministrazione italiana dovrà individuare al proprio interno almeno una Area Organizzativa Omogenea (AAO).

In ciascuna di queste dovrà essere istituito un "Servizio per la tenuta del Protocollo Informatico, della gestione dei Flussi documentali e degli Archivi", con la nomina di un responsabile che disponga di determinati requisiti.  

Abbiamo visto in dettaglio i compiti del responsabile, ed il "Manuale di Gestione" che descrive il funzionamento del servizio. 

Il servizio di Protocollo di ogni AOO dovrà dotarsi, entro la fine del 2003, di un sistema di protocollo informatico, che dovrà avere almeno delle caratteristiche minime, sufficienti a fornire i servizi del protocollo (art. 1.1 DPR e art. 4.1 comma 1 RT). 

I requisiti minimi, sia dal punto di vista delle regole organizzative che da quello delle caratteristiche dei sistemi tecnologici, sono definiti dal regolamento attuativo (DPR 428/98) e da quello tecnico.

La legge definisce inoltre un insieme di "funzionalità aggiuntive", che le Amministrazioni possono realizzare sulla base del "rapporto tra costi e benefici nell’ambito dei propri obiettivi di miglioramento dei servizi e di efficienza operativa" (art. 4.1 comma 2 RT).  

Vanno considerate funzionalità aggiuntive al sistema informatico del protocollo, e quindi con questo integrate, tutte le procedure informatiche preesistenti o successivamente realizzate, autonomamente o sulla base di altre leggi (ad esempio le norme sul documento elettronico e sulla firma digitale),  che coinvolgano la gestione dei flussi documentali (assegnazione e flusso di pratiche, gestione di procedimenti amministrativi, ecc.). 

Le funzionalità aggiuntive devono condividere con la funzionalità minima "almeno i dati di identificazione dei documenti" (art. 4.1, comma 3 RT).

2 - Requisiti minimi

I requisiti minimi sono quelli necessari e sufficienti a garantire i servizi del protocollo. 

Per ottemperare ai requisiti minimi ogni amministrazione dovrà identificare le aree organizzative omogenee, e per ognuna di queste istituire un servizio e nominare un responsabile; dovrà dotarsi di un registro informatico e dovrà scrivere il  "manuale di gestione".

Dovrà inoltre dotarsi di un sistema informatico in grado di immagazzinare i dati delle registrazioni di protocollo, e di consentirne l'inserimento e la ricerca.

La definizione nel testo della legge dei requisiti minimi, potrebbe far sorgere l'interpretazione che il sistema del protocollo informatico, una volta integrato con la firma digitale e con le funzioni di interoperabilità con la rete unitaria, possa essere l'unico sistema informatizzato presente all'interno di una Pubblica Amministrazione, che tratti le informazioni sui documenti, e che con esso si ottemperi  anche alle norme contenute nella legge sul documento informatico. 

Questa interpretazione può probabilmente essere presa in considerazione nel solo caso di AOO piccole, dove il livello di benefici ottenuti con un'espansione ulteriore del sistema informatico potrebbero non giustificare i costi da sostenere, ricorrendo all'art. 15, comma 2 del DPR, che afferma che "le pubbliche amministrazioni adottano sistemi per la gestione dei procedimenti amministrativi mediante sistemi informativi automatizzati, valutando i relativi progetti in termini di rapporto tra costi e benefici, sulla base delle indicazioni fornite dall'Autorità per l'informatica nella pubblica amministrazione", e, al comma 3, che "Il sistema per la gestione dei flussi documentali include il sistema di protocollo informatico

In ogni caso, tra i requisiti minimi del sistema di gestione informatizzata dei procedimenti amministrativi (che deve include il protocollo), oltre a quanto abbiamo visto nelle parti precedenti relativamente alla "registrazione di protocollo", devono essere incluse le funzionalità previste dall'art. 16 del DPR.

Infatti l'art. 16 del DPR specifica che il sistema di gestione informatizzata dei procedimenti amministrativi, oltre a quanto previsto all'art. 3 per il protocollo informatico, deve anche:

1. fornire informazioni sul legame esistente tra ciascun documento registrato, il fascicolo ed il singolo procedimento cui esso è associato;
2. consentire il rapido reperimento delle informazioni riguardanti i fascicoli, il procedimento ed il relativo responsabile, nonché la gestione delle fasi del procedimento;
3. fornire informazioni statistiche sull'attività dell'ufficio;
4. consentire lo scambio di informazioni con sistemi per la gestione dei flussi documentali di altre amministrazioni al fine di determinare lo stato e l'iter dei procedimenti complessi.

3 - Le specifiche per la sicurezza

La legge definisce anche dei "requisiti minimi di sicurezza dei sistemi di protocollo informatico" (art. 4.2 RT).

Si tratta di specifiche tecniche che impongono al sistema operativo, dei cui servizi si avvale il sistema di protocollo informatico, di "essere conforme almeno alle specifiche previste dalla classe ITSEC F-C2/E2 o a quella C2 delle norme TCSEC". 

ITSEC è l'acronimo di "Information Technology Security Evaluation Criteria" (criteri di valutazione di sicurezza delle tecnologie dell'informazione), una organizzazione europea di certificazione della sicurezza dei prodotti informatici. 

Un prodotto che aderisce agli standard di sicurezza ITSEC dispone di un relativo certificato che lo attesta. 

Lo standard ITSEC dispone di 6 livelli di sicurezza, da E1 ad E6 (il massimo della sicurezza). Di fatto il livello E2 viene considerato accettabile nella stragrande maggioranza dei casi. Inoltre non si trovano programmi commerciali con livello E3 o superiore.

Infatti il TNO (l'organismo che fornisce i certificati), per fornire una certificazione di livello superiore, richiede di effettuare test che presuppongono la disponibilità del codice sorgente dei programmi stessi, cosa che non può avvenire per i programmi commerciali, il cui codice è protetto da copyright. 

TCSEC è l'acronimo di "Trusted Computer System Evaluation Criteria". La certificazione TCSEC prevede quattro divisioni, da A a D, con livelli di sicurezza decrescente (A è il massimo livello di sicurezza possibile). Le divisioni B e C sono a loro volta suddivise in classi (B1, B2 e B3; C1 e C2). B3 e C2 sono le classi di maggior sicurezza nelle rispettive divisioni.  

Il livello C2 è il livello di sicurezza più alto per i programmi commerciali. Certificazioni superiori richiedono la la diffusione del codice sorgente del software.

La certificazione per un determinato livello di sicurezza di un programma è valida solo se questi è configurato ed utilizzato in accordo con le procedure previste dall'autorità di certificazione.

In ogni caso il sistema di protocollo informatico "deve consentire il controllo differenziato dell’accesso alle risorse del sistema per ciascun utente o gruppo di utenti" (art. 4.2 comma 2 RT) e .deve anche "consentire il tracciamento di qualsiasi evento di modifica  delle informazioni trattate, assicurandone la corretta attribuzione al soggetto che lo ha causato" (art. 4.2 comma 2 RT).

Queste garanzie sono ottenibili utilizzando vari sistemi operativi disponibili sul mercato, incluso Microsoft Windows NT 4 e sopratutto Windows 2000, che implementa il nuovo sistema ad altissima sicurezza, riconosciuto come standard, denominato "Cerberus" (vedi i relativi articoli su ASM Tutor di agosto). 

E' opportuno che l'applicazione che forma il sistema di protocollo informatico si appoggi principalmente, per la gestione della sicurezza, sui servizi forniti dal sistema operativo.

4 - Il sistema informatico integrato

A parte il caso di piccoli comuni o enti, il sistema informatico del protocollo dovrà essere visto come un "componente" integrato all'interno del sistema informativo dell'amministrazione, che a sua volta esporrà varie funzionalità sulla porta applicativa aperta sulla Rete Unitaria. 

Il servizio protocollo sarà quindi accessibile da altre applicazioni, che recupereranno ed utilizzeranno i dati in esso contenuti.

5 - Accesso esterno al protocollo informatico

Infatti la legge prevede che deve essere garantito l'accesso dall'esterno dell'Amministrazione alle informazioni contenute nel protocollo informatico, come previsto dagli articoli 10 e 11 del DPR.

Tutti i soggetti che, secondo il capo V della legge 7 agosto 1990, n. 241, hanno diritto ad ottenere le informazioni contenute nel protocollo,  debbono poter accedere " anche mediante l'impiego di procedure applicative operanti al di fuori del sistema e strumenti che consentono l'acquisizione diretta delle informazioni da parte dell'interessato" (art. 10, comma 1 DPR).

Per garantire questo diritto, le amministrazioni determinano "i criteri tecnici ed organizzativi per l'impiego, anche per via telematica, del sistema di protocollo informatico per il reperimento, la visualizzazione e la stampa delle informazioni", nel rispetto della normativa sulla privacy (legge 31 dicembre 1996, n. 675), e nell'ambito delle più generali misure organizzative finalizzate a garantire il diritto di accesso, come previsto dall'articolo 22, comma 3, della legge 8 agosto 1990, n. 241 (art. 10, comma 2 DPR).

L'accesso dall'esterno dovrà avvenire dietro identificazione dell'utente, "anche mediante l'impiego di strumenti informatici per la firma digitale del documento informatico, come disciplinati dall'articolo 15, comma 2, della legge 15 marzo 1997, n. 59, dal decreto del Presidente della Repubblica 10 novembre 1997, n. 513 e dai relativi regolamenti di attuazione" (art. 10, comma 3 DPR).

"Nel caso di accesso effettuato da soggetti non appartenenti alla pubblica amministrazione possono utilizzarsi le funzioni di ricerca e di visualizzazione delle informazioni messe a disposizione – anche per via telematica – attraverso gli uffici relazioni col pubblico di cui all'articolo 12 del decreto legislativo 3 febbraio 1993, n. 29" (art. 10, comma 4).

6 - Accesso di altre Pubbliche Amministrazioni

Le altre pubbliche amministrazioni possono accedere al protocollo infomatico di una data AOO mediante proprie applicazioni, utilizzando "le modalità di interconnessione stabilite nell'ambito delle norme e dei criteri tecnici emanati per la realizzazione della rete unitaria delle pubbliche amministrazioni" (art. 11 comma 1 DPR).

Ogni AAO dovrà esporre sulla propria porta applicativa (vedi l'articolo sulla RUPA) un insieme di funzionalità minime (art. 11 comma 2 DPR), in modo da consentire alle altre Pubbliche Amministrazioni di ottenere:

1. numero e data di registrazione di protocollo dei documenti, ottenuti attraverso l'indicazione alternativa o congiunta dell'oggetto, della data di spedizione, del mittente, del destinatario;
2. numero e data di registrazione di protocollo del documento ricevuto, ottenuti attraverso l'indicazione della data e del numero di protocollo attribuiti dall'amministrazione al documento spedito.

(Figura tratta da gedoc2- bozza del 31 marzo 1999 (sul sito dell'AIPA), a proposito dell'interoperabilità dei sistemi di protocollo di amministrazioni diverse.)

Come abbiamo visto nella precedente sezione, i dati della segnatura di protocollo devono essere resi disponibili sulla RUPA in formato XML. 

Per lo scambio di documenti tra pubbliche amministrazioni, ogni AOO dovrà utilizzare "messaggi conformi ai sistemi di posta elettronica veicolabili dalla Rete Unitaria della Pubblica Amministrazione" (art. 5.2, comma 1 RT; gli standard Internet).

Infatti il comma 4 dell'articolo 5.2 delle Regole Tecniche, afferma che "ciascuna Area Organizzativa Omogenea istituisce una casella di posta elettronica adibita alla protocollazione dei messaggi ricevuti. L’indirizzo di tale casella è pubblicato sul Registro delle amministrazioni pubbliche di cui all’art. 3.1 delle RT.

"La registrazione di protocollo in uscita di un documento informatico può dare luogo ad un solo messaggio di posta elettronica per ogni destinatario dello stesso. Viceversa ad un messaggio di posta elettronica ricevuto da una amministrazione può corrispondere una sola operazione di registrazione di protocollo in ingresso" (art. 5.2, comma 2 RT).

Il messaggio di posta elettronica o un qualunque documento informatico da protocollare "può contenere uno o più documenti allegati". (art. 5.2, comma 4 RT).

7 - Gli standard internet

Risulta evidente che il modo più opportuno per ottemperare a queste norme consiste nel prevedere l'accesso ai dati del protocollo, in via riservata (dietro autenticazione) con tecnologie standard Internet (come avviene oggi per l'Home Banking o il commercio elettronico). 

Questa soluzione, valida sia per gli accessi da parte di altre Pubbliche Amministrazioni che da parte di esterni, ha il vantaggio di essere praticabile (per la diffusione di Internet) e basata su standard indiscussi.

La scelta di componenti e standard di mercato ampiamente diffusi è essenziale, in quanto si traduce in bassi costi e alti livelli di affidabilità e robustezza. Gli standard garantiscono inoltre maggiori funzionalità, facilità d'uso, e costi più bassi di formazione e di assistenza.

8 - L'archiviazione e la conservazione delle registrazioni di protocollo e dei documenti.

Le informazioni di protocollo relative ai procedimenti conclusi, vanno conservati su "supporto informatico rimovibile" (art. 13, comma 1 DPR) e devono sempre poter essere consultabili (art. 13, comma 3 DPR), e devono essere "parte integrante del sistema di indicizzazione e di organizzazione dei documenti che sono oggetto di procedure di archiviazione ottica sostitutiva" (art. 13, comma 4 DPR).

Per quanto riguarda i documenti, "ciascuna amministrazione garantisce la leggibilità nel tempo di tutti i documenti  trasmessi o ricevuti adottando i formati previsti all’art. 6, comma 1, lettera b della Delibera AIPA n. 24 1998 o comunque non proprietari" (art. 5.2, comma 5 RT).

I formati previsti dall''art. 6, comma 1, lettera b della Delibera AIPA n. 24 1998 sono quelli conformi "allo standard SGML, oppure in uno dei seguenti formati: PDF, AFP e Metacode. È altresì possibile la conservazione di tali documenti come puro testo purché questo ne rappresenti integralmente ed in maniera non ambigua il contenuto. Deve essere in ogni caso definito univocamente il set di caratteri utilizzato, del quale deve essere contestualmente registrata l’immagine, e, qualora la formattazione non sia già implicitamente contenuta nel formato del documento, debbono essere specificate almeno la divisione in righe e pagine e la dimensione delle spaziature. Un documento formato secondo i precedenti requisiti costituisce la rappresentazione digitale del documento archiviato. È inoltre consentita l’archiviazione dei documenti formati all’origine su supporto informatico attraverso la conservazione della corrispondente immagine ottenuta per conversione diretta dal formato testuale; è possibile conservare sul medesimo supporto anche il testo del documento per scopi gestionali e documentali".

Come commento a questo testo, possiamo dire che il formato SGML (Standard Generalized Markup Language) è un formato da cui deriva l'XML (vedi sezione precedente), ideale per contenere le informazioni sul formato di stampa. L'XML è di fatto un formato SGML semplificato e adattato al web. Un documento XML è anche necessariamente un documento SGML (ma non viceversa).

Un'altro formato molto diffuso è il PDF (Portable Document Format, formato dei documenti del programma Acrobat della Adobe). Pur essendo un formato proprietario, il lettore di documenti PDF è largamente diffuso e reperibile gratuitamente, anche come plug in (componente) del browser. E' un formato discretamente compresso, e garantisce la fedele riproduzione in stampa del documento.

Il formato AFP (Advanced Function Printing) è stato introdotto dall'IBM nel 1984 per i mainframe. Il formato metacode è quello dei sistemi di stampa Xeros ESS. 

Con questo pensiamo di aver trattato tutti gli aspetti più importanti legati al nuovo sistema di protocollo informatico.

La graduale sostituzione, in tempi ragionevoli (e comunque entro la scadenza di legge del 31 dicembre 2003), presso tutte le Amministrazioni pubbliche, dell'attuale sistema di registro cartaceo di protocollo dei documenti (anche se supportato da sistemi informatici) con il nuovo sistema di protocollo informatico, inclusa la digitalizzazione di eventuali originali cartacei, rappresenterà una svolta storica per la Pubblica Amministrazione Italiana. 

Fine dello speciale - torna alla copertina di ASM Tutor

[ Precedente ] [ Home ] [ Su ]

Torna alla Home Page di ASM ricerche

 Per informazioni e commenti: asm@asm-settimo.it - Note sul copyright

statistiche accessi al sito (dal 2 luglio 2003)

Statistiche complessive con il sito Centro di Competenza sul SUAP (dal 5/6/1999)